Reported during QA session.
What happened
When calls are placed in quick succession, a later call gets effectively ignored: the callee taps Accept, but the call never connects. Either the caller stays on the ringing/connecting screen, or both sides end up in a dead call room with no media. The Accept tap registers in the UI but the call does not come up.
It behaves like leftover state from the previous call cycle: the signaling channel, the peer connection, or the call-state machine has not finished tearing down before the next call's offer/answer arrives, so the answer is dropped or applied to a stale session.
What I expected
Every accepted call should connect, regardless of how recently the previous call ended. Rapid successive calls should not require a wait, an app restart, or a retry.
Steps to reproduce
- Device A calls device B; accept, then end the call.
- Immediately (within a few seconds) call again from A to B.
- Repeat several times in quick succession.
- Observe that one of the later calls stays stuck after Accept — the callee has accepted, but no media/connection is established.
Additional context
Needs on-device reproduction to pin down which layer drops it. Suspects, in the order worth checking:
WebrtcSessionManager / WebrtcAdapter — a previous RTCPeerConnection for the same peer not fully closed before the next is created.SignalingService / WsSignalingAdapter — an answer routed against a stale session or call id.CallService — call state not reset to idle on teardown, so the next incoming call is treated as a duplicate of the finished one.
Worth capturing logs with the call, webrtc, signaling, and ws scopes enabled while reproducing.
Related, previously seen in the same area (rapid/repeated call cycles): #304 (UI freeze during repeated call setup/teardown, closed), #298 (spurious "peer is busy", closed), #289 (first call after network regain fails on a stale WS socket). Check whether the fixes for those already changed the teardown path before digging in — this may be the residue of the same root cause rather than a new one.
Reported during QA session.
What happened
When calls are placed in quick succession, a later call gets effectively ignored: the callee taps Accept, but the call never connects. Either the caller stays on the ringing/connecting screen, or both sides end up in a dead call room with no media. The Accept tap registers in the UI but the call does not come up.
It behaves like leftover state from the previous call cycle: the signaling channel, the peer connection, or the call-state machine has not finished tearing down before the next call's offer/answer arrives, so the answer is dropped or applied to a stale session.
What I expected
Every accepted call should connect, regardless of how recently the previous call ended. Rapid successive calls should not require a wait, an app restart, or a retry.
Steps to reproduce
Additional context
Needs on-device reproduction to pin down which layer drops it. Suspects, in the order worth checking:
WebrtcSessionManager/WebrtcAdapter— a previousRTCPeerConnectionfor the same peer not fully closed before the next is created.SignalingService/WsSignalingAdapter— an answer routed against a stale session or call id.CallService— call state not reset to idle on teardown, so the next incoming call is treated as a duplicate of the finished one.Worth capturing logs with the
call,webrtc,signaling, andwsscopes enabled while reproducing.Related, previously seen in the same area (rapid/repeated call cycles): #304 (UI freeze during repeated call setup/teardown, closed), #298 (spurious "peer is busy", closed), #289 (first call after network regain fails on a stale WS socket). Check whether the fixes for those already changed the teardown path before digging in — this may be the residue of the same root cause rather than a new one.