-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refreshing /develop shows brief(?) VoIP inbound call notifications which may flicker on & off as it resyncs #3572
Comments
lampholder
added
T-Defect
X-Cannot-Reproduce
X-Needs-Info
This issue is blocked awaiting information from the reporter
labels
Apr 6, 2017
I tried refreshing /develop in a room that had had some VoIP activity and nothing popped up for me - have you got any more context you can add to help reproduce? |
ara4n
added
P1
A-VoIP
S-Minor
Impairs non-critical functionality or suitable workarounds exist
and removed
X-Cannot-Reproduce
X-Needs-Info
This issue is blocked awaiting information from the reporter
labels
Apr 22, 2017
Have two clients; keep placing calls from A to B, hanging up, and then refreshing B. Within about 5-10 attempts you'll find that B starts ringing during sync - and never shuts up even if you reject the call. |
ara4n
changed the title
refreshing /develop shows brief VoIP inbound call notifications which flicker on & off as it resyncs
refreshing /develop shows brief(?) VoIP inbound call notifications which may flicker on & off as it resyncs
Apr 22, 2017
Closed
Keywords: incoming call on start |
jryans
added
S-Major
Severely degrades major functionality or product features, with no satisfactory workaround
and removed
S-Minor
Impairs non-critical functionality or suitable workarounds exist
labels
Jun 3, 2019
dbkr
added a commit
to matrix-org/matrix-js-sdk
that referenced
this issue
Nov 21, 2019
We have a heap of logic to do the right thing when a call event arrives, eg. wait until the client is ready so we can see if there's already been a hangup event before saying there's an incoming call. Unfortunately it only waited until the client was prepared, not until it was syncing, so any events that arrived from the server in the catchup sync bypassed this logic altogether. This was probably broken back when we introduced the sync accumulator, since before then, "PREPARED" meant, "done initialsync" rather than "loaded fake initialsync from storage". Fixes element-hq/element-web#3572
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: