Intent to Implement: WebRTC Unified Plan SDP

[Harald Alvestrand]

Contact emails

h...@chromium.org, ptha...@chromium.org

Explainer

None. Feature is already in spec.

Design doc/Spec

http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24

In addition to the spec, we’ll add an enum called “SdpFormat” into the RTCConfiguration dictionary, with an initial default of “plan-b”. When we change the default generated SDP, the default will be changed to “unified-plan; when usage of the “plan-b” value is sufficiently low, the item will be removed.

This feature will be behind the “WebRTCUnifiedPlan” runtime enabled feature flag.

Summary

Under this label, we’ll switch the RTCPeerConnection SDP mode for initial SDP offers from our current nonstandard format (“Plan B”) to the agreed-upon format (“Unified Plan” or “JSEP”).

Motivation

In the development of WebRTC, a long debate was had about the way multiple streams of audio or video data should be represented in SDP (“Plan A” and “Plan B”). While the bodies debated, Google shipped “Plan B”. The various standards bodies agreed on a variant of “Plan A”, now known as “Unified Plan”, and Firefox shipped according to that plan.

Chrome, Edge and Safari all ship “Plan B” in the default first offer, which creates interoperability problems.

Eradicating PlanB and fully supporting Unified Plan will unlock several features that

Risks

Interoperability and Compatibility

The biggest interoperabillity risk is with installed Chrome when the default is changed. Chrome versions older than <number> will not be able to parse Unified Plan, and thus will be unable to set up WebRTC sessions with Chrome unless the flag is used to force “old mode” (which is undesirable).

Edge: Under consideration

Firefox: Shipped

Safari: No signals

Web developers: In favor of interoperability. 177 stars on https://bugs.chromium.org/p/chromium/issues/detail?id=465349

Interoperability can be tested using KITE: http://dashboard.cosmosoftware.io:4443/testing/public#

Ergonomics

This is part of the WebRTC API.

Activation

The intent is to take a phased approach - first to allow people to test the feature by changing the default, then changing the default and allowing people to opt out (hopefully few do), and then by removing the ability to use the old style (and rip out the code).

Debuggability

SDP produced and consumed, and errors, can be observed using chrome://webrtc-internals

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

Yes

OWP Launch tracking bug:

https://crbug.com/799030

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

Chrome to Chrome: Yes. web-platform-tests’ webrtc/ subdirectory is the impacted test suite.

We believe shipping this feature will improve the number of tests passed, since the tests assume that Unified Plan is in effect.

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5723303167655936

Requesting approval to ship?

No. The transition plan needs fleshing out before we ship this.

[Philipp Hancke]

Harald,

2018-01-04 14:21 GMT+01:00 'Harald Alvestrand' via blink-dev <blin...@chromium.org>:

Contact emails

h...@chromium.org, ptha...@chromium.org

Explainer

None. Feature is already in spec.

Design doc/Spec

http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24

In addition to the spec, we’ll add an enum called “SdpFormat” into the RTCConfiguration dictionary, with an initial default of “plan-b”. When we change the default generated SDP, the default will be changed to “unified-plan; when usage of the “plan-b” value is sufficiently low, the item will be removed.

This feature will be behind the “WebRTCUnifiedPlan” runtime enabled feature flag.

Summary

Under this label, we’ll switch the RTCPeerConnection SDP mode for initial SDP offers from our current nonstandard format (“Plan B”) to the agreed-upon format (“Unified Plan” or “JSEP”).

Motivation

In the development of WebRTC, a long debate was had about the way multiple streams of audio or video data should be represented in SDP (“Plan A” and “Plan B”). While the bodies debated, Google shipped “Plan B”. The various standards bodies agreed on a variant of “Plan A”, now known as “Unified Plan”, and Firefox shipped according to that plan.

Chrome, Edge and Safari all ship “Plan B” in the default first offer, which creates interoperability problems.

Eradicating PlanB and fully supporting Unified Plan will unlock several features that

Let me describe a feature since you could not think of one :-)

Say you have a p2p video chat and want to add a screensharing track.

Currently, this is not interoperable between Chrome and anything that is compliant (basically Firefox).

There are ways to do it by mangling or munging the SDP but... there is a reason either of these terms is used.

I am very much looking forward to testing this and phasing out my current hacks.

 

[...]

Interoperability and Compatibility

The biggest interoperabillity risk is with installed Chrome when the default is changed. Chrome versions older than <number> will not be able to parse Unified Plan, and thus will be unable to set up WebRTC sessions with Chrome unless the flag is used to force “old mode” (which is undesirable).

Edge: Under consideration

Actually it says "not supported" in the native 1.0. adapter.js supports unified plan.

[...] 

Requesting approval to ship?

No. The transition plan needs fleshing out before we ship this.

The transition plan outlined under "design doc/spec" sounds reasonable to me.

cheers

Philipp

[Philip Jägenstedt]

From what I've heard from web developers working with WebRTC, Unified Plan vs. Plan B is one of the big pain points, so I hope this will result in happier web developers down the line.

When we get to shipping this, will the "SdpFormat" enum ("sdpFormat" member on RTCConfiguration?) be added to some spec? It'll probably be a long transition, and other browsers might then want to follow the same path.

This also matters to web-platform-tests/webrtc/, where if it's described by a spec, we could sprinkle it around as needed. (As long as it's off by default, otherwise the test results will stay unchanged.)

--
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/CAOqqYVE383T2uu-4SEr%3DGSV_ZMXJkTLRv4Myq%2BS6wp4JXuRZEQ%40mail.gmail.com.

[Harald Alvestrand]

Hm.

I've thought about documenting Plan B as part of the transition - there are certain things that become easier if we can have a public spec on the transition, including having a cross-browser way of saying "I'm sending you plan B, but I can handle Unified Plan if you send it to me".

After the transition is over, I want this flag to go away and never be seen again - once the flag is flipped, it's only usefull for those whose peering partners can't handle Unified Plan yet.

Is there a tradition for writing specs that one expects to have a sharply limited lifetime, and therefore move to "SHOULD NOT be implemented"?

[Philip Jägenstedt]

For things that we want to remove from the web platform (all implementations), negative tests (usually called historical.html) in web-platform-tests is one "tradition". But that's not what you want here, rather you want to add some bit of API in order to easy the removal of another together with the addition.

I think that if we just describe that addition in terms of IDL somewhere, that'll be enough for others who want to follow the same path.

But negative tests for plan B itself might be good? There are already negative tests for things like RTCPeerConnection#addStream.

[Harald Alvestrand]

It may make sense to emit a spec describing the transition strategy, even if it's just a "personal submission".

that can include the IDL for the extension.

(Which has been submitted as an experimental feature named sdpSemantics, but it's not ready to start testing yet)