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

I was thinking they should just be ignored. We could fire some
onunknownextensionheader event, but is there any scenario where this would
be necessary? Would like to avoid introducing a lot of API surface for
corner cases.


On Mon, Feb 3, 2014 at 7:10 AM, Bernard Aboba
<Bernard.Aboba@microsoft.com>wrote:

>  You would know if an unconfigured extension event (or error) occurred as
> a result. My question is what approach should be taken.
>
> On Feb 2, 2014, at 11:16 PM, "Justin Uberti" <juberti@google.com> wrote:
>
>   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.
>> }
>>
>>
>