Intent to Implement and Ship: RTCConfiguration.offerExtmapAllowMixed

478 views
Skip to first unread message

Florent Castelli

unread,
Dec 10, 2018, 9:15:23 AM12/10/18
to blin...@chromium.org, kr...@chromium.org

Contact emails

kr...@chromium.org, orp...@chromium.org


Design doc/Spec

Design doc

RFC8285


Summary

Add a boolean property RTCConfiguration.offerExtmapAllowMixed to enable the attribute extmap-allow-mixed in WebRTC SDP offers.


The SDP attribute extmap-allow-mixed, as defined in RFC8285, will be included in the SDP offer if this property is set to true. The SDP attribute extmap-allow-mixed is supported from Chrome M-71, but due to backward compatibility problems with older Chrome releases it is not included in the SDP offer by default for now.


Motivation

New features in the future will require the use of 2-bytes RTP header extensions and the matching signaling in SDP offers, but we can’t create any offer right now including them as valid inputs would be rejected by our old SDP parser and prevent negotiation.


This property is added to help with the backward compatibility problems and make it possible to start using 2-bytes RTP header extensions for some specific applications.


This property would be purely transitional, first off by default, switched to on by default when enough clients have updated to a compatible Chrome release and later removed. It is similar to the RTCConfiguration.sdpSemantics transitional property added to help the transition to Unified-Plan SDP.


Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Not needed

Safari: Not needed

Web / Framework developers: No signals


Safari is actually impacted by the same issue since we share the same SDP parser, but they don’t plan on exposing this property, even with an updated native WebRTC parser. Since they don’t currently use any 2-bytes RTP header extensions, the matching native property would be off by default, at least in the next version.


Most Web developers will probably not need to use this feature and rely on the default behavior. Other than early adopters of 2-bytes RTP header extensions, it will only be relevant to future clients with the feature enabled by default, trying to create an SDP offer for older versions of Chrome (M70 and below) or current versions of Safari.


Ergonomics

The underlying feature will be optionally used by the future RTP extensions for HDR rendering and WebRTC simulcast API.


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

Yes


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

No, but WPT tests will be written to ensure browsers can properly negotiate SDP offers using the underlying feature, and Chrome specific tests will be written to test this property.


Link to entry on the feature dashboard

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


Requesting approval to ship?

Yes


Chris Harrelson

unread,
Dec 11, 2018, 12:20:03 PM12/11/18
to Florent Castelli, blink-dev, kr...@chromium.org
Hi Florent,

What do you mean by "not needed' for Firefox and Safari? Does that mean that those vendors are opposed to the proposed new property?

--
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/CADRnnSVmvQLi4Najzw%2BWG4FP47e54O0JOTV_aQ%2BNJBPeCodpuQ%40mail.gmail.com.

Florent Castelli

unread,
Dec 11, 2018, 2:05:34 PM12/11/18
to chri...@chromium.org, blin...@chromium.org, kr...@chromium.org
Since this API is to handle a backwards compatibility bug in a part of the WebRTC library that Firefox doesn't use (SDP parser), they are not impacted.
Moreover, Firefox doesn't support right now any RTP header extensions that require 2-bytes. They do not support the SDP line to enable this and properly negotiate the feature, by essentially ignoring it without rejecting the whole SDP.

Safari does use the same SDP parser as Chrome and is impacted by the issue (having the offending line in SDP offers will trigger the bug).
Their next release will have the fix. But since they do not use any 2-bytes RTP header extensions, they don't need to announce the feature right now as it would add unnecessary complexity and break compatibility with older browser versions.
The situation might change in the future if they decide to announce the feature in their SDP and want compatibility with the current version of Safari and they can reevaluate then.

Hence, they don't need any compatibility property right now. 

As far as I am aware, most APIs only deal with a single browser in isolation, but this requires a pairing of 2 browsers, potentially of different versions (maybe ancient) or from another vendor. And it makes it a bit more complex than usual.

Chris Harrelson

unread,
Dec 11, 2018, 7:57:52 PM12/11/18
to Florent Castelli, blink-dev, kr...@chromium.org
Thanks for explaining, this makes sense. It seems this new field is actually part of the standard, but is just a temporary fix to bridge an otherwise-unfixable backwards compatibility issue? 

LGTM1 to ship this new field during the upgrade period.

Philip Jägenstedt

unread,
Dec 12, 2018, 5:59:33 AM12/12/18
to Chris Harrelson, Florent Castelli, blink-dev, kr...@chromium.org
LGTM2

I presume that Chrome's SDP parser has been fixed so that future additions like this don't require an opt-in and long migration? Is SDP parsing itself specified and tested? I think the answer is no, but that seems like a bug that's caused some pain in this case.

Florent Castelli

unread,
Dec 12, 2018, 8:22:29 AM12/12/18
to chri...@chromium.org, blin...@chromium.org, kr...@chromium.org
Correct, the underlying feature "2 bytes RTP header extension mixed mode" is part of the standard, which we implemented recently at the RTP level and at the SDP level (beside adding it to SDP offers).

Yes, this property is meant to be a temporary fix. 

On Wed, Dec 12, 2018 at 1:57 AM Chris Harrelson <chri...@chromium.org> wrote:

Daniel Bratell

unread,
Dec 12, 2018, 8:34:56 AM12/12/18
to chri...@chromium.org, Florent Castelli, blin...@chromium.org, kr...@chromium.org
LGTM3 hoping it doesn't stick

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSW9-Zczn8aUkEXftbMmt2Q5Vh69WuhOKk8%3Dqwkm2Ln_jA%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */
Reply all
Reply to author
Forward
0 new messages