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

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

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 3 Feb 2014 10:27:03 -0800
Message-ID: <CAJrXDUG_tYzVvh0zK=oEpi1yn+=hMPLRWZNcG=g_NwQgxhLgoA@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: "public-orca@w3.org" <public-orca@w3.org>
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).

The configuration gives you the mapping from ID in the packet to what
header extension it is.  Without that mapping, how would the browser
know what header extension the ID in the packet represents?  Or in
other words, what Justin said :).

> 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; ?

My original RtpSender/RtpReceiver proposal referred to an
RtpCapabilities, but never defined it.  Indeed, I have some more
thoughts about that.  I'll send another email to the list soon.

> ===========
> 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 18:28:11 UTC

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