1265827 - Add support for RTCPeerConnectionState in RTCPeerConnection

Status: NEW

(Core :: WebRTC, defect, P2)

Description

[Rajmohan Banavi]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36

Steps to reproduce:

The current WebRTC spec mentions about RTCPeerConnectionState read only attribute in the peer connection object.


Actual results:

Did not locate this attribute in the pc object


Expected results:

Need to add support for the same.

Comment 1

[Rajmohan Banavi]

https://www.w3.org/TR/webrtc/#rtcpeerconnectionstate-enum

Comment 2

[Eric Shepherd [:sheppy]]

The RTCPeerConnectionState enum has been documented: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection#RTCPeerConnectionState_enum

RTCPeerConnection.connectionState has also been documented: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/connectionState

The compatibility table on connectionState indicates the lack of implementation.

Leaving this in doc-needed state, however, because additions will have to be made to Firefox X for developers once it's implemented.

Comment 3

[Diwakar]

There has been no update to this bug in a few months.
Can this be prioritized please?
Thanks!

Comment 4

[Danilo B]

Any update on this?

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 8

[Philipp Hancke [:fippo]]

Chrome just landed connectionState in Chrome 72.

Comment 9

[Nils Ohlmeier [:drno]]

Since the PeerConnectionState appears to be an aggregate of ICE connection state and DTLS connection state I'm not sure if it makes sense to try to implement this without implementing the DTLS connection object as well.

Comment 10

[Byron Campen [:bwc]]

This is already causing timeouts in at least some web-platform-tests from upstream.

Comment 11

[mfatihmar]

Hello!
Coming back to this in 2021, I wonder if there is a particular reason why this API is sitting at P2 (for years!) and not getting implemented?

Related:

• WebRTC 1.0 is moved from Candidate Recommentation to Recommentation
• Standard RTCPeerConnection Interface Definition from the W3C Draft

I was also iterating through some links over MDN docs & GitHub side, someone suggested using RTCPeerConnection.iceConnectionState as a workaround but according to the standard (and also MDN covers this very well), that wouldn't cover the exact same connection state information & behavior.

So, I wanted to bump this thread up to get more information.
Hopefully, this ticket would be triaged to higher priority so that an implementation might get into the next FF release cycle :)

Comment 12

[Rudi Floren [:valkum]]

Attachment: Bug 1265827 - Add connectionState to RTCPeerConnection. r=jib

Subscribes to dtls changes and aggragates them together with the iceConnectionState.
The aggregates state is exposed as RTCPeerConnection.connectionState.
The respective events are dispatched for connectionstatechange

Comment 13

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Sorry for taking so long with this. Will try to get to review tomorrow.

Comment 14

[Release mgmt bot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has priority 'P2'.
:mjf, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 15

[Michael Froman [:mjf]]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #13)

Sorry for taking so long with this. Will try to get to review tomorrow.

:jib - have you had a chance to look at the patch?