Intent to Implement and Ship: RTCPeerConnection.connectionState and RTCPeerConnection.onconnectionstatechanged

[jonas...@chromium.org]

Contact emails

jonas...@chromium.org

Design doc/Spec

https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-connectionstate

https://w3c.github.io/webrtc-pc/#event-connectionstatechange

Summary

Expose the aggregated peerconnectionstate from WebRTC, as the standard requires. This state is an aggrated state computed from the states of the underlying ICE and DTLS transports.

Motivation

The connectionState is intended to provide a more complete overview of the peerconnection's state than iceConnectionState, which is only supposed to aggregate ICE transports. Implementing it would bring us closer to conformance with the spec, and would also allow us to update the iceConnectionState to follow the spec.

Risks

Interoperability and Compatibility

These features are covered by web platform tests and a agreed-upon spec, so hopefully we'll not run into any interop problems.

Edge: No signals

Firefox: No signals

Safari: Shipped

Web / Framework developers: We've received a few bug reports requesting these changes, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=823144

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

There's some very limited tests in place: https://wpt.fyi/results/webrtc/RTCPeerConnection-connectionState.html?label=stable&aligned

I intend to extend them a bit to cover the initial state, connection and closure of a peerconnection: https://chromium-review.googlesource.com/c/chromium/src/+/1292560/6/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCPeerConnection-connectionState.html

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6001211660566528

[Philip Jägenstedt]

LGTM1

I had a look at this with Jonas. Given that Safari has already shipped this, the main thing is to make sure that we match Safari as closely as possible in observable behavior, and that this matches the spec and tests are as complete as possible. There is something a bit odd with the spec which Jonas already filed an issue about to resolve: https://github.com/w3c/webrtc-pc/issues/2031

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/588e3799-199b-4942-a5bd-197ef920a24f%40chromium.org.

[mk...@chromium.org]

LGTM2. Matching Safari is reasonable here, and thanks for filing the spec bug to clean up the oddness around `connecting` and `new`.

-mike

[Daniel Bratell]

LGTM3

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36ab0b88-0350-423a-a5d2-9f770227739b%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */