Intent to Prototype: WebRTC RTP header extension control

101 views
Skip to first unread message

Harald Alvestrand

unread,
Feb 13, 2020, 2:47:45 AM2/13/20
to blink-dev
h...@chromium.org,hand...@chromium.org https://docs.google.com/document/d/1y1hTsMeav5ijPvoqu1R6U4YC564i1QzgkMeIqWhgiis/edit# Specification: https://github.com/w3c/webrtc-extensions/pull/25 None None; minor extension Extend the WebRTC RTCRTPTransceiver API to offer control over which RTP header extensions are negotiated. Extend the WebRTC RTCRTPSender API to offer control over which RTP header extensions are sent. With the number of RTP header extensions being proposed, experimented with or included in implementations, sending them all all the time will incur considerable overhead, and trying to negotiate too many of them has led to interoperability issues. A mechanism for negotiating them is available in SDP, but a control mechanism for this negotiation has not been available.
Adding the feature has low interoperability risk; the feature is easily detectable, and will not lead to negotiation failures with browsers that don't support it. The feature has not seen opposition from other browsers, more a sense of "it's not the top of our priority list". If they see the need, it is likely they will implement this. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals This is a part of the WebRTC PeerConnection API. No particular challenges known. The feature makes a few bits of information about the platform (implemented header extensions) available more easily, which aids in fingerprinting to browser release; this information is already available in RTCPeerConnection.createOffer() in a less obvious form, so there is very little new information being exposed.
Yes Yes WPT tests will be added. https://chromestatus.com/feature/5680189201711104
This intent message was generated by Chrome Platform Status.

Reply all
Reply to author
Forward
0 new messages