Closed Bug 1247188 Opened 5 years ago Closed 5 years ago
After network disconnection, RTCPeer
Connection signaling State goes to "closed" instead of ice Connection State going to "disconnected"
14.19 KB, text/x-log
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36 Steps to reproduce: This is reproduced in demo: https://apprtc.appspot.com 1. Open a tab in Chrome 48 and join a room 2. Open a tab in Firefox 44 and join a room 3. Get connection established - able to see both parties video 4. Disconnect from the network for about 30s Actual results: signalingState goes to "closed" Expected results: iceConnectionState to "disconnected" instead of signalingState going to "closed" What I am aware of is that signalingState going to "closed" only happens after RTCPeerConnection.close() is invoked
I'm pretty sure that the change to closed is not coming from Firefox code. Most likely the network disconnect results in connection error for web socket signaling connection, which then the apprtc JS code translates into hangup/close. The feature to transition the ICE connection state after network timeout as per ICE Consent Refresh RFC 7675 is being worked on in bug 929977.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 929977
You need to log in before you can comment on or make changes to this bug.