Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: A more full RTCRtpParameters (RTCRtpCodecParams, RTX, FEC, SSRCs, and the beginnings of simulcast) #33

aboba opened this issue Feb 15, 2014 · 1 comment


Copy link

@aboba aboba commented Feb 15, 2014

From: Peter Thatcher
Date: Wed, 12 Feb 2014 17:53:11 -0800
To: ""

In various email threads, we've referred to RTCRtpParameters, specifically
for RTCRtpSender.send(RTCRtpParameters) and
RTCRtpReceiver.receive(RTCRtpParameters). But we've never fully proposed
what it should look like. Meanwhile, there's been discussion of the
RTCCodec in RTCRtpCapabilities and RTCRtpParameters, which aren't quite the

So, I propose we make an RTCRtpParameters like so, which is combining
various other emails threads, and adding a few things:

It covers I think all of what we need except for specifying quality,
resolution, framerate, and inter-layer depenencies, which is a big topic
that requires a separate email.

dictionary RTCRtpParameters {
​ // ​The value that goes in the "APPID header extension".

DOMString? receiverId;

​ // The codecs to send or receive.
​ // We need more than one send codec because of RTX, CN, etc ​

sequence codecs;

​ // The header extensions to send or receive​.

sequence headerExtensions;

​ // The various "encodings" or "layers"
// (
​simulcast, ​
etc). ​
sequence encodings;

dictionary RTCRtpCodecParameters {
// The value that goes in the RTP Payload Type field.

unsigned byte payloadType;

​ // ​The same value that goes in the RTCRtpCapabilities.

RTCRtpCodec codec;

​ // Format parameters that are only used for controlling
// what is sent, and shouldn't be signalled.

​ // For example, with opus, stereo=1

sequence formatParameters;

​ // Because they are so different,
// RTCP feedback params are separated out.​

sequence rtcpFeedbackParameters;

dictionary RTCRtcpFeedbackParam {
DOMString type; // e.g. "nack", "ccm", "tmmbr", "goog-remb"
​, etc​

DOMString parameters; // e.g. "rpsi", "fir"
​, etc​


dictionary RTCRtpHeaderExtensionParameters {
DOMString uri;
unsigned short id;
bool encrypt;

dictionary RTCRtpEncodingParameters {
// The "main" ssrc for this layer/encoding.

unsigned int ssrc;

// F
​or per-enconding codec specfications, give the codec name here.
// If null, the browser will choose.​


// If you want FEC or RTX, assign one of these.

RTCRtpFecParameters? fec;

RTCRtpRtxParameters? rtx;

​​ // TODO: Control resolution, quality, framerate, and
​ // Inter-layer depenencies. ​
​ // It's a topic all on its own :).​


dictionary RTCRtpFecParameters {
​ ​
// The ssrc to use for FEC.
​ ​
unsigned int ssrc;​
​ ​


dictionary RTCRtpRtxParameters {
​ ​
// The ssrc to use for

​ ​
unsigned int ssrc;

Copy link
Contributor Author

@aboba aboba commented Feb 26, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 12, 2014

Support for control of quality, resolution, framerate and layering added, as described in
RTCRtpListener object added and figure in Section 1 updated, as described in w3c#32
More complete support for RTP and Codec Parameters added, as described in w3c#33
Data Channel transport problem fixed, as described in w3c#34
Various NITs fixed, as described in w3c#37
Section 2.2 and 2.3 issues fixed, as described in w3c#38
Default values of some dictionary attributes added, to partially address the issue described in w3c#39
Support for ICE TCP added, as described in w3c#41
Fixed issue with sequences as attributes, as described in w3c#43
Fix for issues with onlocalcandidate, as described in w3c#44
Initial stab at a Stats API, as requested in w3c#46
Added support for ICE gather policy, as described in w3c#47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants