W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2020

Re: A proposal for RTP header extension control

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 14 Jan 2020 16:57:32 +0100
To: public-webrtc@w3.org
Message-ID: <5628a932-8c6b-6040-a923-d0e85fefd23b@alvestrand.no>

On 1/14/20 4:15 PM, Henrik Boström wrote:
> 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.

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16#section-5.13 
says that they're in category SPECIAL - one must understand the 
extension in order to figure out what makes sense.

But numbers used on a single transport can't collide, so in that sense, 
they're negotiated for the whole transport - the number allocator has to 
be per-transport.

Just-generated example:

Audio section:

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id

Video section:

a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id

As you can see, the same extension in the two media sections uses the same number.




>
> On Mon, Jan 13, 2020 at 1:33 PM Harald Alvestrand 
> <harald@alvestrand.no <mailto: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>
>     >> <mailto: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 Tuesday, 14 January 2020 15:57:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:51 UTC