Skip to content
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

Member state event stuck with call id #60

Closed
robertlong opened this issue Oct 16, 2021 · 2 comments
Closed

Member state event stuck with call id #60

robertlong opened this issue Oct 16, 2021 · 2 comments
Labels
p1 Must fix/implement before this is usable as a product T-Defect Something isn't working: bugs, crashes, hangs, vulnerabilities, or other reported problems

Comments

@robertlong
Copy link
Contributor

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:

{
  "@user1": { "m.calls": ["123"] },
  "@user2": { "m.calls": ["123"] },
  "@user3": { "m.calls": ["123"] },
}

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:

  1. Once a WebRTC call drops but the user's state hasn't been reset, keep sending invite messages to all of their devices.
  2. 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.
  3. 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.
@robertlong robertlong added the T-Defect Something isn't working: bugs, crashes, hangs, vulnerabilities, or other reported problems label Oct 16, 2021
@robertlong robertlong added this to In progress in Element Call Oct 16, 2021
@robertlong robertlong added the p1 Must fix/implement before this is usable as a product label Oct 16, 2021
@robertlong
Copy link
Contributor Author

In talking with @ara4n, we both agree that option 2 sounds like the best option.

@robertlong
Copy link
Contributor Author

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.

Element Call automation moved this from In progress to Done Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p1 Must fix/implement before this is usable as a product T-Defect Something isn't working: bugs, crashes, hangs, vulnerabilities, or other reported problems
Projects
Development

No branches or pull requests

1 participant