Proposal for controlling RTP header extensions for RtpSender and RtpReceiver #28

Closed
aboba opened this Issue Jan 31, 2014 · 1 comment

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Jan 31, 2014

From: Peter Thatcher pthatcher@google.com
To: public-orca@w3c.org
Date: Tue, 28 Jan 2014 17:39:24 -0800
URL: http://lists.w3.org/Archives/Public/public-orca/2014Jan/0057.html

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 headerExtensions; // Just the URIs
}

dictionary RTCRtpParameters {
// ... Codecs and stuff.
sequence 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.
}

I haven't bothered to write example code. Is it clear enough or does
anyone need an example?

@aboba
Contributor
aboba commented Feb 15, 2014

Please review the fixes relating to this issue in the latest ORTC Editor's draft:
http://ortc.org/wp-content/uploads/2014/02/ortc.html

If there are any remaining concerns, please post these to the public-orca@w3.org mailing list.

@aboba aboba closed this Feb 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment