W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: Proposal for controlling RTP header extensions for RtpSender and RtpReceiver

From: Justin Uberti <juberti@google.com>
Date: Sun, 2 Feb 2014 23:16:25 -0800
Message-ID: <CAOJ7v-0y9DdBEfMDEDhSZy-4dwkYrJNZvCp5PRtEyNhKPAWX8g@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: "public-orca@w3.org" <public-orca@w3.org>
How would one know if an extension that isn't configured but supported
shows up? The only way to identify extensions are the numeric IDs in the
header, and those could correspond to anything, unless they have been
explicitly associated with a defined URI.


On Sun, Feb 2, 2014 at 8:43 PM, Bernard Aboba
<Bernard.Aboba@microsoft.com>wrote:

> It makes sense to enable support for RTP header extensions to be
> discovered.
>
> It also makes sense to me for RTP header extensions to be configured on a
> sender object; presumably that would cause the referenced RTP extensions to
> be included in RTP packets that are sent.
>
> Question #1: What does it mean to configure RTP header extensions on a
> receiver object?     If RTP header extensions are configured on a receiver
> object, and an RTP extension that isn't configured but is supported shows
> up, what happens?  I would argue that the RTP extension should be processed
> anyway (rather than treating this as an error).
>
> Question #2:  RTCRtpCapabilities is referenced in the
> RtpSender/RtpReceiver split proposal (
> http://lists.w3.org/Archives/Public/public-orca/2014Jan/0000.html),
> but is only defined in this proposal.  Any more thoughts on "Codecs" and
> "stuff"?  For example,  is "Codecs" referring to sequence<RTCRtpCodec>
> codecs; ?
>
>
> ===========
> An area of the current API which needs a little improvement is RTP
> header extensions.  Before we changed to RtpSender/RtpReceiver, it
> only allowed for setting the key/value pairs for header extensions,
> but it didn't specify what the keys or values should be, nor did it
> allow an easy way for good defaults to be set, or for even knowing
> what header extensions were supported by the browser.
> Now that we have RtpSender/RtpReceiver, there is no way to control it
> at all.  But we can fix that, I think, very easily.  I propose we do
> so by adding fields to RTCRtpCapabilities and RTCRtpParameters like
> so:
>
>
> dictionary RTCRtpCapabilities {
>  // ... Codecs and stuff.
>  sequence<DOMString> headerExtensions; // Just the URIs
> }
>
>
> dictionary RTCRtpParameters {
>  // ... Codecs and stuff.
>  sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
> }
>
>
> dictionary RTCRtpHeaderExtensionParameters {
>  DOMString uri;
>  unsigned short id;  // The value that goes in the packet.
>  bool encrypt;  // If true, encrypt the value in the header.
> }
>
>
Received on Monday, 3 February 2014 07:17:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC