Intent to Implement & Ship: RTCRtpTransceiver

275 views
Skip to first unread message

Henrik Boström

unread,
May 9, 2018, 6:20:59 AM5/9/18
to blink-dev
Contact emails

Spec

Summary
RTCRtpTransceiver is a big piece of WebRTC 1.0 and it is heavily tied to the spec's agreed-upon SDP format, "Unified Plan" or "JSEP". See "RTP Media API" in spec.
A transceiver is a sender-receiver pair and Chrome has already shipped RTCRtpSender and RTCRtpReceiver. The transceiver gets tied to an m-section in the SDP and its direction negotiated to decide whether to send, receiver or both. Benefits of the transceiver model include possibility to receive media early and more control of the SDP generation. This also bridges the gap between Chrome and Firefox's implementation of WebRTC.

However, Chrome is currently using the nonstandard format, "Plan B", by default. This does not just affect how the SDP is formatted, but the behavior of senders and receivers as well.
In Unified Plan, senders and receivers are always added in pairs - as transceivers - and transceivers are never removed (though they can be made inactive).
In Plan B, there is an asymmetry between senders and receivers. They can be added independently of each other and they can also be removed when no longer used. Furthermore, this SDP format allows multiple senders and/or receivers per m-section. This makes the RTCRtpTransceiver, which essentially represents an m-section, inadequate for the Plan B model.

Because of this, RTCRtpTransceiver will only be usable when the application opts-in for the "Unified Plan" behavior, which they do with the sdpSemantics configuration passed to the RTCPeerConnection constructor, see the intent for sdpSemantics.
The new APIs are:
  • interface RTCRtpTransceiver (everything except setCodecPreferences() which will be shipped separately).
  • RTCPeerConnection.getTransceivers().
  • RTCPeerConnection.addTransceiver().
  • Existing interface RTCTrackEvent (fired by RTCPeerConnection.ontrack) will get its missing attribute "readonly attribute RTCRtpTransceiver transceiver".
Because we are not shipping transceivers in "Plan B", getTransceivers() and addTransceiver() will throw an exception if invoked in this mode.

Note that the plan is to make "Unified Plan" the default behavior, but this will require a separate intent to ship.

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

Risks

Interoperability and Compatibility

Switching from "Plan B" to "Unified Plan" entails some risk since behavior changes, the biggest concern being around the switching point when different clients are on different formats and the formats only being compatible for the single track per m-section case. Switching the default will require a separate intent to ship and a separate discussion.

For this intent: Transceivers have to be opted-in to which makes this intent less risky. The sooner we allow developers to use the new APIs the better.

One concern is that this breaks feature detection. An application that checks for the existence of the RTCRtpTransceiver interface or if getTransceivers()/addTransceiver() is in the RTCPeerConnection prototype will start to see them there, only to find out that an exception is thrown if they are invoked unless sdpSemantics: "unified-plan" is used (which applications currently don't do).
Currently transceivers are not widely adopted. Most applications use legacy addStream()/removeStream() or addTrack(). Sample searches for usages in real apps:

Support and interoperability testing for Unified Plan
 

Firefox: Shipped

Safari: Positive

Web developers: In favor of interoperability. 186 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

This intent is for shipping the feature behind the "sdpSemantics" configuration, allowing people to test transceivers by changing the default semantics to Unified Plan. The application has to opt-in by passing { sdpSemantics: "unified-plan" } to the RTCPeerConnection constructor.

Is this feature fully tested by web-platform-tests?
There are a lot of testing of transceivers as well as tests that rely on transceivers in wpt/webrtc/.
However, the Unified Plan implies a large number of behaviors and it would be wrong to say that this is fully tested yet. We have plans to add extensive testing support in WPTs; all our JavaScript layer tests will be written as WPTs.

Link to entry on the feature dashboard

Philip Jägenstedt

unread,
May 9, 2018, 7:10:54 AM5/9/18
to Henrik Boström, blink-dev
LGTM1

Thank you for the very detailed background and motivation. This isn't shipping unified plan but an important step towards it, and the "186 stars" bit is important here: web developers want to be able to write the same WebRTC code and have it work on all browsers.

The intent for sdpSemantics was to implement, so for the opt-in to exist I take it this intent also covers flipping the "RTCUnifiedPlan" REF to stable? Seems like it only covers the sdpSemantics, dictionary member, so the name is a bit confusing :)

On the testing situation, I presume that some of this will require peeking at generated SDP or perhaps other bits of the network layer, where the specs either aren't pedantically clear, or WPT doesn't have the testing infrastructure. If the latter is the case and you have idea, please file bugs :)

--
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/7b33355f-7c33-4e3e-bb99-95a0f5e510b1%40chromium.org.

Harald Alvestrand

unread,
May 9, 2018, 7:16:50 AM5/9/18
to Philip Jägenstedt, Henrik Boström, blink-dev
I'm preparing a separate Intent-To-Ship for the sdpSemantics flag, since I expect any concerns that are voiced there to be largely orthogonal to the ones about RtpTransceiver (apart from the comments on the overall introduction plan for Unified Plan). Watch this space...


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
 To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeVrYJz3%2BhS6DSnp83dieLW-bfc3wdN%3Dmh12swAZ2xmpw%40mail.gmail.com.

Alex Russell

unread,
May 10, 2018, 12:24:03 PM5/10/18
to blink-dev
LGTM 2.

Chris Harrelson

unread,
May 10, 2018, 12:24:42 PM5/10/18
to Alex Russell, blink-dev
LGTM3

On Thu, May 10, 2018 at 9:24 AM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:
LGTM 2.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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/ab89f6d3-1769-40f2-b8ac-7aca1a5df52d%40chromium.org.
Reply all
Reply to author
Forward
0 new messages