Re: A proposal for RTP header extension control

These APIs are on a per-transceiver basis. Are RTP header extensions
negotiated on a per-transceiver basis, or is it on a "for all m= sections
in the offer"-, "the offerer tagged m= section" or "per transport"-basis?
If they're negotiated per m= section always then usage seems clear,
otherwise I think we need to figure out what to do. For example, maybe we'd
be forced to negotiate an RTP header extension for transceiver0 because
transceiver1 needs it if RTP header extensions are negotiated for the
entire offer, in which case we'd need to make
transceiver0.[sender/receiver].getParameters() default to "inactive" values.

On Mon, Jan 13, 2020 at 1:33 PM 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).
>
> >
> >> 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().
> >>>
> >>>
> >>> *
> >
>
>
>