Re: A proposal for RTP header extension control

On Mon, Jan 13, 2020 at 4:33 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

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

Agree - one of the goals for transceivers was to use them to 'firewall' SDP
so that the underlying APIs (e.g., sender/receiver) had no dependencies on
SDP, and could still function in a future SDP-less world.

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