Intent to Implement & Ship: RTCRtpSender

[Henrik Boström]

Contact emails

hb...@chromium.org, gui...@chromium.org, dead...@chromium.org

Spec

https://w3c.github.io/webrtc-pc/#rtcrtpsender-interface

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

https://crbug.com/700916

Link to entry on the Chrome Platform Status

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

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]

\o/

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

Contact emails

hb...@chromium.org, gui...@chromium.org, dead...@chromium.org

Spec

https://w3c.github.io/webrtc-pc/#rtcrtpsender-interface

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

https://crbug.com/700916

Link to entry on the Chrome Platform Status

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

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]

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]

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.

https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&q=RTCRtpSender.

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]

While we have no signals for actually shipping WebRTC in Safari, WebKit does have this interface:

https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/mediastream/RTCRtpSender.idl

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]

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?

Not currently, see http://internaut.com:8080/~baboba/iit-tutorial/slides/edge.pdf

    "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]

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]

LGTM2

[Chris Harrelson]

LGTM2

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

[Henrik Boström]

Bump. Third LGTM one anyone?

[Jochen Eisinger]

lgtm3

LGTM2

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

[Henrik Boström]

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]

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]

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]

hbos, this is amazing. Finally one can write http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example in Chrome!

[PhistucK]

From a quick glance, looks like some code already uses it without a method detection (and I am not sure why not) -

https://github.com/Jxck/jxck.io/blob/7a809813b0a165df73bd0b7c86a3c399ca2dbe28/labs.jxck.io/webrtc/stream/p2p/warmup.js#L42

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/767dd284-c782-4cd1-8e9d-0a8f2ef91c84%40chromium.org.

[Harald Alvestrand]

That particular example will fail anyway, because transceivers aren't implemented yet.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Lfxr-ZRLzfNePzBtPS1ruyDjA5O3%2BrS4Fvv6RL-CkXaQ%40mail.gmail.com.

[Henrik Boström]

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]

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]

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]

Ack. Looking into http archive queries with foolip.

[PhistucK]

Thank you very much!

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c0a35d51-905c-46f6-a25a-cbaeffb649f4%40chromium.org.

[Philip Jägenstedt]

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:

https://static.opentok.com/v2/js/opentok.js

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/767dd284-c782-4cd1-8e9d-0a8f2ef91c84%40chromium.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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Lfxr-ZRLzfNePzBtPS1ruyDjA5O3%2BrS4Fvv6RL-CkXaQ%40mail.gmail.com.

--
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/db773013-4218-4758-9b7b-8283b2c12747%40chromium.org.

[Henrik Boström]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/767dd284-c782-4cd1-8e9d-0a8f2ef91c84%40chromium.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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Lfxr-ZRLzfNePzBtPS1ruyDjA5O3%2BrS4Fvv6RL-CkXaQ%40mail.gmail.com.