Closed Bug 1247188 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: WebRTC: Networking, defect, major)

44 Branch
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 929977

People

(Reporter: leticia.choo, Unassigned)

Details

Attachments

(1 file)

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
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
Severity: normal → major
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: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 929977
You need to log in before you can comment on or make changes to this bug.