Intent to Implement and Ship: RTCRtpParameters.headerExtensions

[Florent Castelli]

Contact emails orp...@chromium.org Spec https://w3c.github.io/webrtc-pc/#rtcrtpparameters

Summary Add support for the required dictionary entry RTCRtpParameters.headerExtensions that is returned by RTCRtpSender.getParameters().

This is a read-only field that allows inspection of the parameters that are set on a PeerConnection after negotiation.

Interoperability risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Low interoperability risk. The API is in the spec and is easy to feature-detect. It has also been stable for a while and is not controversial.

Compatibility risk None. This is the first implementation.

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/803494

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

Yes

Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6675724865896448 Requesting approval to ship? Yes

[Philip Jägenstedt]

Have the other browser vendors been at all involved in designing this feature, and are there bugs on those engines to implement this? How about web developers, what is made possible by this API that was previously not possible?

--
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/CAHQbFaemCW9phC-OK--kPqz6PoiKXW%2B3u07%3DQVZtkYLCX8Ln5A%40mail.gmail.com.

[Ian Kilpatrick]

Also as per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit

Please file a TAG review for this feature.

Thanks,

Ian

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/CAARdPYcJB8b_d%3DRbDeHmxgGcgVx6PJZWAoLp1fiAyLSy2j68rQ%40mail.gmail.com.

[Harald Alvestrand]

We've avoided asking for TAG reviews for individual pieces of the overall WebRTC spec, since there has been TAG review of the whole spec a long time ago (https://github.com/w3ctag/design-reviews/issues/14)

The chief usefulness is to check "are the things I expected present" in terms of functionality available on an RTP connection.

git blame for this feature in the spec shows Jan-Ivar Bruarøy (Mozilla) and Bernard Aboba (Microsoft) as the last to have modified those lines in the spec; this is not a Google-centric specification.

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/CAARdPYcJB8b_d%3DRbDeHmxgGcgVx6PJZWAoLp1fiAyLSy2j68rQ%40mail.gmail.com.

--

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/CAJL3UpR-%2BmAyQb41v5sGvWQws2PJ_7KSb07VDMWJkEFJ259sqQ%40mail.gmail.com.

[Ian Kilpatrick]

It seems like headerExtensions was added to the spec after the initial TAG reivew?

https://github.com/w3c/webrtc-pc/commit/be6c9c9b8cc2ec9806a27626084b09e61aa162f2

If so, it would probably be wise to file for this and/or the updated sections of the spec.

Thanks,

Ian

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/CAARdPYcJB8b_d%3DRbDeHmxgGcgVx6PJZWAoLp1fiAyLSy2j68rQ%40mail.gmail.com.

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

[Philipp Hancke]

RTP headerextensions are part of the RTP and SDP standards are designed by the IETF. They are defined in https://tools.ietf.org/html/rfc5285

Edge has shipped http://draft.ortc.org/#rtcrtpheaderextension* as part of ORTC in 2015 which is returned by the static RTCRtpSender.getCapabilities method.

http://draft.ortc.org/#rtcrtpheaderextensionparameters* is more similar to https://w3c.github.io/webrtc-pc/#rtcrtpheaderextensionparameters in semantics but afaics RTCRtpSender.getParameters has not shipped in Edge.

The Mozila folks are generally aware of this and would probably applaude chrome/webrtc prioritizing https://bugs.chromium.org/p/webrtc/issues/detail?id=7477 a fair bit higher.

Check https://webrtchacks.com/sdp-anatomy/ if you want to learn more about the "wonders and perils of the Session Description Protocol" :-)

Requiring a TAG review for every line in the SDP and the corresponding JS objects needed does not sound very productive.

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/CAARdPYcJB8b_d%3DRbDeHmxgGcgVx6PJZWAoLp1fiAyLSy2j68rQ%40mail.gmail.com.

[Philip Jägenstedt]

+Jan-Ivar Bruaroey +Bernard Aboba +youenn fablet for Gecko/Edge/WebKit. If you have any concerns around shipping this API, please raise them now!

Even though the original TAG review was a long time ago and this bit of the spec didn't exist then, I agree with Harald and Philipp that requesting a review doesn't seem worthwhile. The template asks for "Link to a tag review or a description about why the tag review process is being skipped." Here, the reason is that the underlying protocol has already shipped, and that this is just exposing a read-only view of what's been negotiated. (API-wise it's possible to call setParameters, but headerExtensions is a read-only parameter, so doing so should throw an exceptions.)

Florent, the test doesn't verify that the headerExtensions member is an array, or that if it's non-empty that the members of RTCRtpHeaderExtensionParameters exist. It seems therefore that the test is need of much improvement. If it's not possible in a test to cause the array to be non-empty, then that seems like a problem, a type:untestable issue would be great, or a solution even better. Whatever can't be tested in WPT will presumably need to be tested using unit tests instead.

LGTM1

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

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfT1O43PVq6kcYXEno8kowVQYt_D-S1WsHykucDiHe3JA%40mail.gmail.com.

[Florent Castelli]

Hi Philip,

The WPT tests are checking that headerExtensions is an array here: https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCRtpParameters-helper.js#L115

Each field is then checked. The tests are against an older version of the standard and need updating to reflect some fields are now required, which I'll do when implementating of the feature.

Is there anything else missing?

[Philip Jägenstedt]

Aha, I missed the `validateRtpParameters(param)` in the helper called, never mind me.

The test would still pass if an implementation always returned an empty array, so can a test be written where any conforming implementation would have a non-empty array, and assert as much?

But now we're almost in code review territory. If the tests are updated to cover what is implemented and would fail if the important part of the implementation were removed, then all is well.

[sligh...@chromium.org]

LGTM3 with a few procedural comments:

• While I'm in general super supportive of telling developers what we know from the implementation perspective, and this feature improves on that, the discussion around motivation in this thread is pretty unsatisfying. Having something like an explainer that outlines who needs this feature and why would have made the OWNERS deliberation much smoother.
• This is a generic extension mechanism! Will individual extensions also see Intents?
• Similar to the first point, the lack of example code in either the spec or a related explainer document (or even in this thread) leaves lots of questions open that don't need to be. I.e., who needs this and why?
• A feature like this could have a deep implication (as it's a generic extension mechanism). At a minimum, please file FYI pointers on the TAG design review repo to help ensure that the folks who have a responsibility to the overall architecture stay informed.

Thanks

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

[Harald Alvestrand]

This is a mirror into a different spec-space - IETF RTP extensions.

The list of required and recommended RTP header extensions created by the IETF RTCWEB WG is here, for instance:

https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26#section-5.2

You can see that a number of them are REQUIRED to implement, others are RECOMMENDED. In a specific session, some of them may be negotiated to be used; some of them may be negotiated away. Use or non-use will likely have some quality impact on the session (for instance, the CVO extension is required in order to flip the picture when the other guy on the call turns his phone).

The actual implementation of each individual extension is deep in the WebRTC codebase.

The scope of the TAG's responsibility in this area is unclear to me. TAG doesn't review TCP congestion control algorithms either.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9ed5da3-3ebc-499b-87b7-d9cc7cfd6741%40chromium.org.

[jbru...@mozilla.com]

Lgtm.

[win...@gmail.com]

Lgtm.