Re: A proposal for RTP header extension control

For those who like Google docs, there's a document with public comments 
enabled here:


https://docs.google.com/document/d/1y1hTsMeav5ijPvoqu1R6U4YC564i1QzgkMeIqWhgiis/edit#


On 1/13/20 2:11 AM, Harald Alvestrand wrote:
>
> 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().
>
>
>
> *