Re: A proposal for RTP header extension control

Den 13.01.2020 11:11, skrev Youenn Fablet:
> 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.


My rule of thumb is that APIs that don't depend on SDP negotiation
belong to sender/receiver, while APIs that chiefly exist to influence
SDP negotiation belong to transceiver.

I still have a long term hope that we'll get to a state where we can
have sender/receiver objects whose configuration can be managed without
reference to SDP (but for the moment, I'm just trying to not make that
goal be further away).

> 
>> On 13 Jan 2020, at 10:51, Harald Alvestrand <harald@alvestrand.no
>> <mailto: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#
>>
>>
>> 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().
>>>
>>>
>>> * 
>

Received on Monday, 13 January 2020 12:31:14 UTC