You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
robertlong opened this issue
Oct 16, 2021
· 2 comments
Labels
p1Must fix/implement before this is usable as a productT-DefectSomething isn't working: bugs, crashes, hangs, vulnerabilities, or other reported problems
When we transitioned to to-device events users who leave a call without properly removing the call id from their member state event get stuck where they will not be called by other users in a call if their username is also lexicographically lesser than the other members currently in the room.
Here's an example:
I have a call I'd like to join with 3 users: User 1, User 2, and User 3
All three users join the call.
One user drops but does not reset their member event to remove the call. The members events now look like this:
User 3's video tile still appears on User 1 and User 2's screen until the WebRTC call drops.
User 3 enters the call again 2 minutes later and the member state is still set as it was before.
User 3 expects users 1 and 2 to start the call with them because they have lexicographically lesser user ids. They never receive a call invite because to users 1 and 2, that user's WebRTC call was disconnected and their state event never changes.
I see a couple different solutions to this:
Once a WebRTC call drops but the user's state hasn't been reset, keep sending invite messages to all of their devices.
Store a session id in the member event. This is how I was handing things before. When you join, you set a new session id. If the session id changes, the other participants can initiate a new call with that user.
If you are about to enter a group call and there's already that call's id in your member state, remove that call send it, and then add it and send it again.
The text was updated successfully, but these errors were encountered:
robertlong
added
the
T-Defect
Something isn't working: bugs, crashes, hangs, vulnerabilities, or other reported problems
label
Oct 16, 2021
Fixed by moving from avoiding glare by only calling from one direction based on user ids to purposely using glare to resolve duplicate calls. This means we call all the members in a call when joining regardless of their id unless we already have an ongoing call with them. Incoming calls may glare and automatically cancel out the outgoing calls.
p1Must fix/implement before this is usable as a productT-DefectSomething isn't working: bugs, crashes, hangs, vulnerabilities, or other reported problems
When we transitioned to to-device events users who leave a call without properly removing the call id from their member state event get stuck where they will not be called by other users in a call if their username is also lexicographically lesser than the other members currently in the room.
Here's an example:
I have a call I'd like to join with 3 users: User 1, User 2, and User 3
All three users join the call.
One user drops but does not reset their member event to remove the call. The members events now look like this:
User 3's video tile still appears on User 1 and User 2's screen until the WebRTC call drops.
User 3 enters the call again 2 minutes later and the member state is still set as it was before.
User 3 expects users 1 and 2 to start the call with them because they have lexicographically lesser user ids. They never receive a call invite because to users 1 and 2, that user's WebRTC call was disconnected and their state event never changes.
I see a couple different solutions to this:
The text was updated successfully, but these errors were encountered: