Re: A proposal for RTP header extension control

I like the idea of exposing more things through API.
I am curious about the reasons behind surfacing the API at transceiver instead of sender/receiver level.

> On 13 Jan 2020, at 10:51, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> For those who like Google docs, there's a document with public comments enabled here:
> 
> 
> 
> https://docs.google.com/document/d/1y1hTsMeav5ijPvoqu1R6U4YC564i1QzgkMeIqWhgiis/edit# <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 <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 RTCRtpHeaderExtensionParameters element 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().
>> 
>>