ossrs/srs

[Cannot Fix] Multi-party call: Unable to re-enter the room after switching networks

Closed this issue · 1 comments

ZHuiYan commented

Using WebRTC for multi-party calling, after joining the room, perform the following network switching operation:
（1）Connect only to the company's intranet, join the room for an audio conference
（2）Connect to the external Wi-Fi network and disconnect from the intranet.
（3）You will find that you cannot hear the voices of other people in the room, and the connection has been disconnected.

At this point, after closing SrsRtcPublisherAsync, SrsRtcPlayerAsync, and SrsRtcSignalingAsync, attempting to rejoin the room fails and the signaling log reports the following error:
2025-09-29T03:19:13.972615709Z [warn] 2025/09/29 11:19:13.972519 [1][8643] Handle {"tid":"6380588","msg":{"action":"join","room":"live","display":"zhy_ceshi"}} err join: Participant zhy_ceshi exists in room live

Attempting to send the following message:
sig.send({action: 'leave', room: "live", display: "zhy_ceshi"})

Still unable to join the room, the signaling log is as follows:
2025-09-29T03:19:52.279949393Z [warn] 2025/09/29 11:19:52.279695 [1][8638] Handle {"tid":"2163463","msg":{"action":"leave","room":"zhy_ceshi","display":"live"}} err Invalid message {"tid":"2163463","msg":{"action":"leave","room":"zhy_ceshi","display":"live"}}

After waiting for a while, the system should have cleaned up the connection, and then it becomes possible to enter the room again.
How should this situation be handled when switching networks?

SRS Version:
SRS/5.0.205

winlinvip commented

This is a known session cleanup issue when network switches occur. The server cannot detect the UDP connection break immediately, leaving a stale session that blocks rejoining.

Workarounds:

  1. Wait for the session timeout to expire (usually 30-60 seconds)
  2. Use unique display names with timestamps (e.g., "zhy_ceshi_" + Date.now()) to avoid collision with stale sessions
  3. Implement client-side retry logic with exponential backoff

Why not fixed:
Properly fixing this requires significant changes to the WebRTC signaling protocol, heartbeat mechanisms, and session management across server and all client SDKs. The complexity and maintenance cost is too high for this edge case.

We recommend using the workarounds above to handle network switching scenarios.