A proposal for RTP header extension control

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 
(https://github.com/w3c/webrtc-extensions)

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

*Harald*

**


  *RTP header extension control*

*

The standard RTP header extension mechanism is described in RFC 8285 
<https://tools.ietf.org/html/rfc8285>.


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.


    Proposal

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

IDL:


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 
“InvalidModificationError”.


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


      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 
setParameters().



*