1247188 - After network disconnection, RTCPeerConnection signalingState goes to "closed" instead of iceConnectionState going to "disconnected"

Status: RESOLVED DUPLICATE of bug 929977

(Core :: WebRTC: Networking, defect)

Description

[leticia.choo]

Attachment: Contains both the Firefox logs and Chrome logs from apprtc.appspot.com

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

Comment 1

[Nils Ohlmeier [:drno]]

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.