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.

Sign up for GitHub

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

Jump to bottom

rtcp.ssrc advice for implementations #536

Closed
wants to merge 2 commits into from
Closed

rtcp.ssrc advice for implementations #536

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
85998a3
rtcp.ssrc advice for implementations
aboba May 5, 2016
5be2c4d
Typo fixes
aboba May 5, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 26 additions & 19 deletions ortc.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3351,16 +3351,16 @@ <h3>dictionary RTCRtpParameters</h3>
<dt>DOMString muxId=""</dt>
<dd>
<p>
The <var>muxId</var> assigned to the RTP stream, if any, empty string if unset.
In an <code><a>RTCRtpReceiver</a></code> or <code><a>RTCRtpSender</a></code> object, this corresponds to
<a>MID</a> RTP header extension defined in [[!BUNDLE]].
This is a stable identifier that permits the track corresponding to an RTP stream to be identified, rather than relying on an SSRC.
The <var>muxId</var> assigned to the RTP stream, if any, empty string if unset. In an
<code><a>RTCRtpReceiver</a></code> or <code><a>RTCRtpSender</a></code> object, this corresponds to
<a>MID</a> RTP header extension defined in [[!BUNDLE]]. This is a stable identifier that permits
the track corresponding to an RTP stream to be identified, rather than relying on an SSRC.
An SSRC is randomly generated and can change arbitrarily due to conflicts with other SSRCs, whereas
the <var>muxId</var> has a value
whose meaning can be defined in advance between RTP
sender and receiver, assisting in RTP demultiplexing.
Note that including <var>muxId</var> in <code><a>RTCRtpParameters</a></code> rather than in <code><a>RTCRtpEncodingParameters</a></code> implies that if it is desired to send simulcast streams with different <var>muxId</var> values for each stream, then multiple
<code><a>RTCRtpSender</a></code> objects are needed.
the <var>muxId</var> has a value whose meaning can be defined in advance between RTP
sender and receiver, assisting in RTP demultiplexing. Note that including <var>muxId</var> in
<code><a>RTCRtpParameters</a></code> rather than in <code><a>RTCRtpEncodingParameters</a></code>
implies that if it is desired to send simulcast streams with different <var>muxId</var> values
for each stream, then multiple <code><a>RTCRtpSender</a></code> objects are needed.
</p>
</dd>
<dt>sequence&lt;RTCRtpCodecParameters&gt; codecs</dt>
Expand All @@ -3378,10 +3378,10 @@ <h3>dictionary RTCRtpParameters</h3>
<dt>sequence&lt;RTCRtpEncodingParameters&gt; encodings</dt>
<dd>
<p>
The "encodings" or "layers" to be used for things like simulcast, Scalable Video Coding, RTX, FEC, etc.
When unset in a call to <code>send()</code>,
the browser behaves as though a single <code>encodings[0]</code> entry was provided, with
<var>encodings[0].ssrc</var> set to a browser-determined value, <var>encodings[0].active</var> set to "true",
The "encodings" or "layers" to be used for things like simulcast, Scalable Video Coding,
RTX, FEC, etc. When unset in a call to <code>send()</code>, the browser behaves
as though a single <code>encodings[0]</code> entry was provided, with <var>encodings[0].ssrc</var>
set to a browser-determined value, <var>encodings[0].active</var> set to "true",
<var>encodings[0].codecPayloadType</var> set to <var>codecs[j].payloadType</var> where <var>j</var> is the index
of the first codec that is not "cn", "dtmf", "red", "rtx" or a forward error correction codec, and all the other
<var>parameters.encodings[0]</var> attributes (e.g. fec, rtx, priority, maxBitrate, resolutionScale, etc.) unset.
Expand Down Expand Up @@ -3432,12 +3432,19 @@ <h3>dictionary RTCRtcpParameters</h3>
<dt>unsigned long ssrc</dt>
<dd>
<p>
The SSRC to be used in the "SSRC of packet sender" field defined in [[!RFC3550]] Section 6.4.2 (Receiver Report)
and [[!RFC4585]] Section 6.1 (Feedback Messages), as well as the "SSRC" field defined in [[!RFC3611]] Section 2 (Extended Reports).
It can only be set for an <code><a>RTCRtpReceiver</a></code>. Other than for debugging, or situations where <code>receive()</code>
is called before <code>send()</code> on the same <code><a>RTCDtlsTransport</a></code> it is best to leave it unset,
in which case <var>ssrc</var> is chosen by the browser, though the chosen value is not reflected in <code>RTCRtcpParameters.ssrc</code>.
If the browser chooses the <var>ssrc</var> it may change it in event of a collision, as described in [[!RFC3550]].
The SSRC to be used in the "SSRC of packet sender" field defined in [[!RFC3550]]
Section 6.4.2 (Receiver Report) and [[!RFC4585]] Section 6.1 (Feedback Messages),
as well as the "SSRC" field defined in [[!RFC3611]] Section 2 (Extended Reports).
It can only be set for an <code><a>RTCRtpReceiver</a></code>. Other than for
debugging, or situations where <code>receive()</code> is called before
on the same <code><a>RTCDtlsTransport</a></code>, it is best for the application
to leave it unset. If unset, the SSRC is chosen by the browser, and the browser
may change the SSRC in event of a collision, as described in [[!RFC3550]].
However, the chosen value is not reflected in <var>rtcp.ssrc</var>. Where
<code>send(<var>parameters</var>)</code> is called before <code>receive()</code>
on the same <code><a>RTCDtlsTransport</a></code>, the browser can choose one of the
SSRCs allocated to the <code><a>RTCRtpSender</a></code>. Where <code>receive()</code>
is called first, a random SSRC value can be chosen.
</p>
</dd>
<dt>DOMString cname</dt>
Expand Down