Intent to Implement & Ship: RTCRtpSender

238 views
Skip to first unread message

Henrik Boström

unread,
May 2, 2017, 6:09:58 AM5/2/17
to blink-dev
Contact emails

Spec

Motivation
The W4C WebRTC working group has consensus on adding this API. It is partially supported by Firefox: https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&q=RTCRtpSender (note: Edge does not have getSenders() so its listed support of RTCRtpSender is misleading).

Compatibility Risk
Low risk. addTrack and removeTrack is close to existing addStream/removeStream methods, replaceTrack is similar to remove+add.

Ongoing technical constraints
None.

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

OWP launch tracking bug

Link to entry on the Chrome Platform Status

Requesting approval to ship?
Yes.

I suggest shipping each part that is useful on its own as soon as its implemented rather than waiting for the everything to be fully implemented, e.g:
- RTCPeerConnection.getSenders(), addTrack(), removeTrack() and RTCRtpSender.track, replaceTrack, setParameters, getParameters, RTCRtpParameters (what Firefox has)
- RTCRtpSender.transport, rtcpTransport (not implemented by either browser)
- RTCRtpSender.getCapabilities (not implemented by either browser)

Philipp Hancke

unread,
May 2, 2017, 6:59:59 AM5/2/17
to Henrik Boström, blink-dev
\o/

2017-05-02 12:09 GMT+02:00 Henrik Boström <hb...@chromium.org>:
Contact emails

Spec

Motivation
The W4C WebRTC working group has consensus on adding this API. It is partially supported by Firefox: https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&q=RTCRtpSender (note: Edge does not have getSenders() so its listed support of RTCRtpSender is misleading).

RTCRtpSender described there is from ORTC.
 

Compatibility Risk
Low risk. addTrack and removeTrack is close to existing addStream/removeStream methods, replaceTrack is similar to remove+add.

Ongoing technical constraints
None.

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

OWP launch tracking bug

Link to entry on the Chrome Platform Status

Requesting approval to ship?
Yes.

I suggest shipping each part that is useful on its own as soon as its implemented rather than waiting for the everything to be fully implemented, e.g:
- RTCPeerConnection.getSenders(), addTrack(), removeTrack() and RTCRtpSender.track, replaceTrack, setParameters, getParameters, RTCRtpParameters (what Firefox has)
- RTCRtpSender.transport, rtcpTransport (not implemented by either browser)
- RTCRtpSender.getCapabilities (not implemented by either browser)

it would be great if you can prioritize getSenders() and replaceTrack. That is currently much easier in Firefox (where it has been available since... 2014) and would therefore close a major compability gap.
While there exist ways in Chrome to do it they require heavy SDP mangling (remove the track, add the new track, createOffer, mangle SSRCs and call SLD + SRD) and don't play nicely with the peerconnections signaling state.
 

--
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+unsubscribe@chromium.org.

Rick Byers

unread,
May 2, 2017, 10:20:26 AM5/2/17
to Philipp Hancke, Henrik Boström, blink-dev
What can you say about the interop risk and testing status?  Here's the relevant parts from the template that are missing:

Interoperability and Compatibility Risk

Describe the degree of interoperability and compatibility risk. For a new feature, the main risk is that it fails to become an interoperable part of the web platform, if other do not implement it.


Edge: Shipped/In development/Public support/No signals/Negative signals/Opposed

Firefox: Shipped/In development/Public support/No signals/Negative signals/Opposed

Safari: Shipped/In development/Public support/No signals/Negative signals/Opposed

Web developers: Positive/No signals/Negative


Please include links where possible.


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

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

  • A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. (example)

  • A spec issue for some change that would make it possible to test. (example)

  • A Chromium issue to upstream some existing tests. (example)

An Intent to Ship requires either a web platform test suite or such issues to be filed explaining why such a test suite is currently impossible or in the progress of being upstreamed.

Henrik Boström

unread,
May 2, 2017, 1:16:28 PM5/2/17
to blink-dev, philipp...@googlemail.com, hb...@chromium.org
Interoperability
The main functionality is shipped in Firefox (RTCPeerConnection.getSenders(), addTrack(), removeTrack() and RTCRtpSender.track, replaceTrack, setParameters, getParameters, RTCRtpParameters).
Looks like in-development for Edge?
Safari: no public signals.
Web developers: positive.

Is this feature fully tested by web-platform-tests?
It looks like only the idl is tested to ensure getSenders(), addTrack() and removeTrack() exist. I filed: https://github.com/w3c/web-platform-tests/issues/5760
These tests can be added to web-platform-tests as part of implementing RTCRtpSender. (I recently become a web-platform-tests/webrtc owner.)
\o/

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.


Philip Jägenstedt

unread,
May 3, 2017, 5:22:06 AM5/3/17
to Henrik Boström, blink-dev, you...@apple.com, philipp...@googlemail.com
While we have no signals for actually shipping WebRTC in Safari, WebKit does have this interface:

It was added by +Youenn Fablet, who I know has been doing some work on WebRTC recently, so that's a good sign.

Regarding web-platform-tests, simply writing the tests together with the implementation SGTM, and if there are things that turn out to be impossible to test, please make sure to file issues to track getting that coverage eventually.

LGTM1

Philipp Hancke

unread,
May 3, 2017, 7:01:50 AM5/3/17
to Henrik Boström, blink-dev
2017-05-02 19:16 GMT+02:00 Henrik Boström <hb...@chromium.org>:
Interoperability
The main functionality is shipped in Firefox (RTCPeerConnection.getSenders(), addTrack(), removeTrack() and RTCRtpSender.track, replaceTrack, setParameters, getParameters, RTCRtpParameters).
Looks like in-development for Edge?

    "Advanced functionality like multi-stream support, provisional answers, or the WebRTC 1.0 object model, are currently out of scope for our implementation"

addTrack is on the roadmap for the shim in adapter.js though.

PhistucK

unread,
May 3, 2017, 7:08:49 AM5/3/17
to Philipp Hancke, Henrik Boström, blink-dev
Plus, Microsoft has announced that it does not have any plans to advance its WebRTC implementation further. The focus was and is on ORTC.


PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Chris Harrelson

unread,
May 3, 2017, 4:47:13 PM5/3/17
to PhistucK, Philipp Hancke, Henrik Boström, blink-dev
LGTM2

Chris Harrelson

unread,
May 3, 2017, 5:54:08 PM5/3/17
to PhistucK, Philipp Hancke, Henrik Boström, blink-dev
LGTM2

On Wed, May 3, 2017 at 4:08 AM, PhistucK <phis...@gmail.com> wrote:

Henrik Boström

unread,
May 8, 2017, 4:49:33 AM5/8/17
to blink-dev, phis...@gmail.com, philipp...@googlemail.com, hb...@chromium.org, chri...@chromium.org
Bump. Third LGTM one anyone?

Jochen Eisinger

unread,
May 9, 2017, 12:32:47 PM5/9/17
to Henrik Boström, blink-dev, phis...@gmail.com, philipp...@googlemail.com, chri...@chromium.org
lgtm3

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Henrik Boström

unread,
Nov 24, 2017, 11:55:39 AM11/24/17
to blink-dev, hb...@chromium.org, phis...@gmail.com, philipp...@googlemail.com, chri...@chromium.org
This work required a lot more changes than anticipated. I still intend to ship this.

I intend to first ship (next cut):
RTCRtpSender with just the track attribute.
RTCPeerConnection.getSenders(), addTrack(), removeTrack().

And follow that up with shipping RTCRtpSender.replaceTrack().
lgtm3

LGTM2



PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

PhistucK

unread,
Nov 25, 2017, 3:46:34 AM11/25/17
to Henrik Boström, blink-dev, Philipp Hancke, Chris Harrelson
Can you search GitHub and HTTPArchive for unguarded usage of replaceTrack (only checking for RTCRtpSender, for example)?
Does adapter.js already accommodate incomplete RTCRtpSender implementations?


PhistucK

Henrik Boström

unread,
Nov 27, 2017, 6:02:09 AM11/27/17
to blink-dev, hb...@chromium.org, philipp...@googlemail.com, chri...@chromium.org
Adding partial support this way should be relatively safe and the right approach.
adapter.js does not implement replaceTrack. This is good, that means for adapter.js nobody is relying on replaceTrack and unflagging won't break this.
adapter.js shims addTrack/removeTrack behaviors and these are the things we've implemented and are unflagging.
The adapter tests are under control, the only failures are expected or have PRs to fix and mostly have to do with mixing legacy and non-legacy API calls and doing mad things.

Philipp Hancke

unread,
Nov 27, 2017, 7:01:42 AM11/27/17
to Henrik Boström, blink-dev
hbos, this is amazing. Finally one can write http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example in Chrome!

PhistucK

unread,
Nov 27, 2017, 8:26:08 AM11/27/17
to Henrik Boström, blink-dev, Philipp Hancke, Chris Harrelson
From a quick glance, looks like some code already uses it without a method detection (and I am not sure why not) -

I guess you simply assume most developers use adapter.js and therefore there is no reason to worry? Is it quantified with use counters (not sure how)?

Partial implementations are generally discouraged, precisely because of this. Web developers suffer when they need to handle partial implementations.
Waiting a release or two and shipping everything altogether would be much better, in my opinion.


PhistucK

Harald Alvestrand

unread,
Nov 27, 2017, 8:31:47 AM11/27/17
to PhistucK, Henrik Boström, blink-dev, Philipp Hancke, Chris Harrelson
That particular example will fail anyway, because transceivers aren't implemented yet.


Henrik Boström

unread,
Nov 27, 2017, 8:35:30 AM11/27/17
to blink-dev, phis...@gmail.com, hb...@chromium.org, philipp...@googlemail.com, chri...@chromium.org
Like Harald says yes, that would not work before unflagging and it would not work after unflagging.
The only code that could break as a result of partial sender (that wasn't already broken) is code that guards against using senders but if senders are available then start using them without guarding for replaceTrack. So websites or shims that trigger experimenting with a new code path when anything sender is unflagged.

Henrik Boström

unread,
Nov 27, 2017, 8:52:49 AM11/27/17
to blink-dev, phis...@gmail.com, hb...@chromium.org, philipp...@googlemail.com, chri...@chromium.org
Generally speaking I do agree with waiting to implement all of an interface before unflagging, but WebRTC is a dinosaur that is slowly changing, an "all or nothing" can delay progress of the web and end up hurting the platform. For new APIs, WebRTC is a case where partial shipping is sometimes the appropriate thing to do. The sooner we can get this out the door the sooner we can deprecate Chrome-only APIs. The unflagged APIs cover all usage case of the legacy APIs. replaceTrack and other members are new additional features, we expect very low reliance on this. If adapter.js doesn't break, we should be in a good state.

A complete support for sender, including transport, rtcpTransport, get/setParameters and getStats is a lot of work, it's not a matter of waiting a release or two. replaceTrack() in particular though would be a case of waiting a release, most likely, but getting addTrack/removeTrack out there is more important.
Delaying spec-compliant ways of handling media in WebRTC on a whole due to not supporting more special case usages of some features that are not implemented will hurt the platform more than protecting it. The current way of adding and removing tracks in Chrome are APIs that are not even in the spec's legacy notes.

PhistucK

unread,
Nov 27, 2017, 9:15:44 AM11/27/17
to Henrik Boström, blink-dev, Philipp Hancke, Chris Harrelson
My only concern is breaking (legitimate feature detection) code (legitimate being feature detecting an interface rather than a method). If you researched enough code that is already out there and saw no issue with it, I do not have a strong concern here.


PhistucK

Henrik Boström

unread,
Nov 27, 2017, 9:18:09 AM11/27/17
to blink-dev, hb...@chromium.org, philipp...@googlemail.com, chri...@chromium.org
Ack. Looking into http archive queries with foolip.

PhistucK

unread,
Nov 27, 2017, 9:38:42 AM11/27/17
to Henrik Boström, blink-dev, Philipp Hancke, Chris Harrelson
Thank you very much!


PhistucK

Philip Jägenstedt

unread,
Nov 27, 2017, 10:14:14 AM11/27/17
to Henrik Boström, blink-dev, phis...@gmail.com, philipp...@googlemail.com, chri...@chromium.org
hbos@ and I took a look at httparchive together, finding 215 results that have both "RTCPeerConnection" and "replaceTrack". Taking a random sample of 13. All 13 had this bit of shimReplaceTrack code:

That URL was also the only one that had something interesting beyond that, namely some api._demoOnlyFindAndReplaceTrack code and defaultReplaceTrackLogic. It's a bit tricky to see what's being shimmed and not there, so just trying the site (http://www.teamfind.com/) with the changes might be the quickest way to find out the implications.



PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Henrik Boström

unread,
Nov 27, 2017, 11:29:41 AM11/27/17
to blink-dev, hb...@chromium.org, phis...@gmail.com, philipp...@googlemail.com, chri...@chromium.org
Not sure but it looks like that the replaceTrack stuff of that website is part of shimming stuff they pull in, not that it's actually used. I can't test calling on that website without signing up two http://store.steampowered.com/ accounts and doing a call.


PhistucK



PhistucK

lgtm3

LGTM2



PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.


--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages