Steps to reproduce
Steps to reproduce
Self-hosted MatrixRTC (LiveKit SFU + lk-jwt-service), homeserver is tuwunel. Room has exactly two human participants.
User A (Element X iOS) starts a call in a 1:1 room.
User B joins, the call connects, audio works both ways.
User B leaves the call normally — their client empties its own org.matrix.msc3401.call.member state event and disconnects from the SFU.
User A is now the only participant.
Outcome
What did you expect?
The call ends on A's device and the call screen closes, the way it does in every mainstream messenger (WhatsApp, Signal, WeChat…): in a 1:1 call, when the only other party hangs up, the call is over for both sides.
What happened instead?
A's call screen stays open indefinitely. It either keeps showing the call as ongoing, or switches to "Reconnecting…" and stays there. The only way out is for A to tap the red hang-up button.
Why this looks like a bug rather than "conference semantics"
I checked the room state from the server side after B left:
There is no non-empty org.matrix.msc3401.call.member event left in the room — B's was emptied by B's own client, and I separately verified A's was empty too. So from the room state's point of view, the call has already ended, yet A's UI does not reflect that.
I also tried removing A from the LiveKit room server-side (RoomService/RemoveParticipant). That succeeded (confirmed in the SFU logs), but the UI reacted by showing "Reconnecting…" forever rather than ending the call.
So neither the Matrix-level signal (no remaining call members) nor the media-level signal (removed from the SFU) causes the call screen to end.
Expected behaviour / request
For a room with two participants, when the last remaining other participant leaves, end the call locally instead of keeping the screen open. If the conference semantics are intentional for larger rooms, an option (or a 1:1-specific behaviour) would still solve this.
Practically, this means every 1:1 call needs both sides to hang up manually, and if one side forgets, the other is left on a call screen that never resolves.
Related
#3656 asks for an "End call" control, but that one is about calls that get stuck due to connection problems. This report is about the other party leaving normally — the clean path — and the screen still not closing.
Operating system
iPhone (iOS)
Browser information
N/A — native app: Element X iOS 28.08.4 (243)...
URL for webapp
self-hosted Element Call, embedded in Element X iOS
Will you send logs?
Yes
Steps to reproduce
Steps to reproduce
Self-hosted MatrixRTC (LiveKit SFU + lk-jwt-service), homeserver is tuwunel. Room has exactly two human participants.
User A (Element X iOS) starts a call in a 1:1 room.
User B joins, the call connects, audio works both ways.
User B leaves the call normally — their client empties its own org.matrix.msc3401.call.member state event and disconnects from the SFU.
User A is now the only participant.
Outcome
What did you expect?
The call ends on A's device and the call screen closes, the way it does in every mainstream messenger (WhatsApp, Signal, WeChat…): in a 1:1 call, when the only other party hangs up, the call is over for both sides.
What happened instead?
A's call screen stays open indefinitely. It either keeps showing the call as ongoing, or switches to "Reconnecting…" and stays there. The only way out is for A to tap the red hang-up button.
Why this looks like a bug rather than "conference semantics"
I checked the room state from the server side after B left:
There is no non-empty org.matrix.msc3401.call.member event left in the room — B's was emptied by B's own client, and I separately verified A's was empty too. So from the room state's point of view, the call has already ended, yet A's UI does not reflect that.
I also tried removing A from the LiveKit room server-side (RoomService/RemoveParticipant). That succeeded (confirmed in the SFU logs), but the UI reacted by showing "Reconnecting…" forever rather than ending the call.
So neither the Matrix-level signal (no remaining call members) nor the media-level signal (removed from the SFU) causes the call screen to end.
Expected behaviour / request
For a room with two participants, when the last remaining other participant leaves, end the call locally instead of keeping the screen open. If the conference semantics are intentional for larger rooms, an option (or a 1:1-specific behaviour) would still solve this.
Practically, this means every 1:1 call needs both sides to hang up manually, and if one side forgets, the other is left on a call screen that never resolves.
Related
#3656 asks for an "End call" control, but that one is about calls that get stuck due to connection problems. This report is about the other party leaving normally — the clean path — and the screen still not closing.
Operating system
iPhone (iOS)
Browser information
N/A — native app: Element X iOS 28.08.4 (243)...
URL for webapp
self-hosted Element Call, embedded in Element X iOS
Will you send logs?
Yes