W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2020

A proposal for RTP header extension control

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 13 Jan 2020 02:11:12 +0100
To: public-webrtc@w3.org
Message-ID: <ecda4dbc-0d12-8831-d8c9-1c3addaa995a@alvestrand.no>
This is a proposal for an extension to the WebRTC-PC specification in 
order to allow control of which RTP headers are negotiated and used.

If time allows, I'll present this at the Tuesday Virtual Interim meeting.

If the group finds the proposal reasonable, I'll prepare a pull request 
against the WebRTC extensions document 

This proposal is NOT meant to be merged with the WEBRTC-PC document that 
we're currently trying to get to Proposed Recommendation.



  *RTP header extension control*


The standard RTP header extension mechanism is described in RFC 8285 

We have two issues with RTP headers:


    There are so many of them, and so many supported in browsers, that
    we’re running into issues in SDP parsers with just offering every
    RTP header extension that there is support for.


    There are extensions that we don’t want enabled by default, or not
    enabled all the time. Sometimes they are alternates and we want to
    pick one.

An extension API is needed for this. It needs to:


    Be able to figure out what extensions (by name) the platform supports


    Enable the negotiation of these extensions on initial SDP negotiation


    Enable or disable these extensions on a specific RTP stream.


This proposal seems to satisfy the requirements above.

It consists of two new functions on the RTCRtpTransceiver, to control 
the SDP negotiation, and one new attribute in 
RTCRtpHeaderExtensionParameters, which allows the enabling or disabling 
of an extension using setParameters().

      Controlling the SDP negotiation


partial dictionary RTCRtpHeaderExtensionParameters {

RTCRtpTransceiverDirection direction = “sendrecv”;

             // Sendonly, recvonly, sendrecv, inactive, stopped


// This also redefines RTCRtpHeaderExtensionList

dictionary RTCRtpHeaderExtensionCapabilityWithDirection

   : RTCRtpHeaderExtensionCapability {

      RTCRtpTransceiverDirection direction = “sendrecv”;


partial interface RTCRtpTransceiver {

    void setOfferedRtpHeaderExtensions(

     RTCRtpHeaderExtensionCapabilityWithDirection headerExtensionsToOffer);

    readonly attribute RTCRtpHeaderExtensionList headerExtensionsAccepted;


The “headerExtensionsToOffer” argument will control what is offered in 
the next negotiation.

The following meanings attach to the “direction” attribute:


    Sendonly, recvonly, sendrecv, inactive: These will be signalled in
    the SDP. If the attribute is “sendonly” or “sendrecv”, the attribute
    will be used by the attached sender on this transceiver.


    stopped : Will NOT be signalled in the SDP.

The URIs listed in the argument to “setOffered” MUST be a subset of the 
union of the capabilities listed by sender.getCapabilities / 
receiver.getCapabilities. If an unrecognized URI is present, “typeError” 
will be thrown.

If any RTP header extension that the platform regards as mandatory to 
send is set to “recvonly”, “inactive” or “stopped”, or an RTP header 
extension that the platform regards as mandatory to receive is set to 
“sendonly”, “inactive” or “stopped”, the call will thrown a 

The “accepted” attribute will be empty until an offer/answer has been 

      Controlling the RTP extensions in use

Reporting what’s in use is already handled by the 
RTCRtpHeaderExtensionParameterselement on the sender/receiver. This also 
gives the extension numbers, if needed.

To figure out what’s available, one can use 
RTCRtpSender.getCapabilities() and look at the header extensions 
section; this returns a sequence<RTCRtpHeaderExtensionCapability>.

To control what extensions are being sent, modify the “direction” 
attribute - setting it to “stopped” will prevent the RTP header 
extension from being sent.

For this, one can use the usual getParameters/setParameters functions.

Attempting to modify the receiver’s “direction”, or attempting to 
disable a mandatory parameter, will lead to rejection of the 

Received on Monday, 13 January 2020 01:11:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:51 UTC