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

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<mailto: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<mailto: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.
}