SSRC Conflict #143

Closed
aboba opened this Issue Aug 5, 2014 · 8 comments

Projects

None yet

4 participants

@aboba
Contributor
aboba commented Aug 5, 2014

As noted in RFC 3550 Section 8.2:

Although the probability of SSRC identifier collision is low, all RTP
implementations MUST be prepared to detect collisions and take the
appropriate actions to resolve them. If a source discovers at any
time that another source is using the same SSRC identifier as its
own, it MUST send an RTCP BYE packet for the old identifier and
choose another random one. (As explained below, this step is taken
only once in case of a loop.) If a receiver discovers that two other
sources are colliding, it MAY keep the packets from one and discard
the packets from the other when this can be detected by different
source transport addresses or CNAMEs. The two sources are expected
to resolve the collision so that the situation doesn't last.

This implies that the SSRC provided in RTCRtpEncodingParameters could be reset by the browser at any time.

Do we need an event to indicate that an SSRC collision has been detected, and that a new value has been assigned?

@pthatcherg

It sounds like all the browser needs to do is:

  1. Stop sending with SSRC X and send RTCP BYE.
  2. Tell the JS that it can't send with SSRC X anymore.
  3. Let the JS take it from there.

Why get into complications of the browser picking new values? Let the JS
sort it out.

On Tue, Aug 5, 2014 at 2:30 PM, aboba notifications@github.com wrote:

As noted in RFC 3550 Section 8.2:

Although the probability of SSRC identifier collision is low, all RTP
implementations MUST be prepared to detect collisions and take the
appropriate actions to resolve them. If a source discovers at any
time that another source is using the same SSRC identifier as its
own, it MUST send an RTCP BYE packet for the old identifier and
choose another random one. (As explained below, this step is taken
only once in case of a loop.) If a receiver discovers that two other
sources are colliding, it MAY keep the packets from one and discard
the packets from the other when this can be detected by different
source transport addresses or CNAMEs. The two sources are expected
to resolve the collision so that the situation doesn't last.

This implies that the SSRC provided in RTCRtpEncodingParameters could be
reset by the browser at any time.

Do we need an event to indicate that an SSRC collision has been detected,
and that a new value has been assigned?


Reply to this email directly or view it on GitHub
#143.

@robin-raymond
Contributor

@pthatcherg I would prefer the browser just change myself since implementations are supposed to auto-change anyway. This is such a rare occurrence that asking a programmer to have to handle it will invite most people to ignore it. On an individual scale that's not a big deal but on a global usage scale you'll see needless failures happen. And when muxId/mid is specified, we just don't care about conflicts anyway.

We should be posting to the list, not here.

@aboba
Contributor
aboba commented Aug 6, 2014
@robin-raymond robin-raymond added the 1.1 label Aug 8, 2014
@aboba
Contributor
aboba commented Aug 18, 2014

The basic idea here is that if SSRCs were chosen by the application, then the application will receive an SSRC conflict event if a conflict is detected, and the application will then provide new SSRCs (e.g. via a new call to RTCRtpSender.send()). If SSRCs were chosen by the browser, then the browser will resolve the SSRC conflict, and no SSRC conflict event will be thrown.

@aboba aboba closed this Aug 18, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014
Robin Raymond Clarification of the ICE restart issue, as noted in:
w3c#93

Clarified onerror usage in sender and receiver objects, as noted in:
w3c#95

Clarified SST-MS capability issue noted in:
w3c#108

Clarification of send() and receive() usage as noted in:
w3c#119

Changed ICE state diagram as noted in:
w3c#122

Removed getParameters methods and changed send() method as noted in:
w3c#136

Changed definition of framerateScale and resolutionScale as noted in:
w3c#137

Substituted "muxId" for the "receiverId" as noted in:
w3c#138
w3c#140

Clarified the setting of track.kind as described in:
w3c#141

Added SSRC conflict event to the RTCRtpSender, as described in:
w3c#143

Addressed the "end of candidates" issues noted in:
w3c#142
w3c#144
4916cd5
@ibc
Contributor
ibc commented Aug 22, 2014

How is the application supposed to set the SSRC in case of rtx in which a different SSRC is required? See for example the SDP that Chrome Canary generates (some attributes filtered):

m=video 50171 RTP/SAVPF 100 116 117 96
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 627174652 1381966277
a=ssrc:627174652 cname:638pIYStIf81SFYg
a=ssrc:627174652 msid:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse 86db55fa-2187-4823-aa85-ebc45476e7ce
a=ssrc:627174652 mslabel:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse
a=ssrc:627174652 label:86db55fa-2187-4823-aa85-ebc45476e7ce
a=ssrc:1381966277 cname:638pIYStIf81SFYg
a=ssrc:1381966277 msid:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse 86db55fa-2187-4823-aa85-ebc45476e7ce
a=ssrc:1381966277 mslabel:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse
a=ssrc:1381966277 label:86db55fa-2187-4823-aa85-ebc45476e7ce

This is RFC 4588, which says:

Finally, the original and retransmission packets may be sent in two
separate streams. These two streams may be multiplexed either by
sending them in two different sessions , i.e., session-multiplexing,
or in the same session using different SSRC values, i.e., SSRC-
multiplexing.

@pthatcherg

RTCRtpEncodingParameters.rtx.ssrc

@robin-raymond
Contributor

@ibc Please post on list when possible, not on github. You can link to github issue on list if you like.

@aboba
Contributor
aboba commented Aug 22, 2014

If the application provided RTCRtpRtxParameters.ssrc to send() then an SSRC Conflict Event will be thrown in event of a conflict. The application would then substitute an alternate SSRC for the conflicting one and call send() again. Note that if ssrc is unset, the browser will choose it (see Section 9.11.1) and an SSRC Conflict Event will not be thrown - the browser will fix the conflict on its own.

As to how the application should choose a new SSRC, calling a cryptographic random number generator (e.g. RandomSource.getRandomValues in WebCrypto API, NOT Math.random()) would make sense. Example 7 in Section 6.5 could show how this would work.

On Aug 22, 2014, at 10:27 AM, Iñaki Baz Castillo <notifications@github.commailto:notifications@github.com> wrote:

How is the application supposed to set the SSRC in case of rtx in which a different SSRC is required? See for example the SDP that Chrome Canary generates (some attributes filtered):

m=video 50171 RTP/SAVPF 100 116 117 96
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 627174652 1381966277
a=ssrc:627174652 cname:638pIYStIf81SFYg
a=ssrc:627174652 msid:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse 86db55fa-2187-4823-aa85-ebc45476e7ce
a=ssrc:627174652 mslabel:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse
a=ssrc:627174652 label:86db55fa-2187-4823-aa85-ebc45476e7ce
a=ssrc:1381966277 cname:638pIYStIf81SFYg
a=ssrc:1381966277 msid:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse 86db55fa-2187-4823-aa85-ebc45476e7ce
a=ssrc:1381966277 mslabel:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse
a=ssrc:1381966277 label:86db55fa-2187-4823-aa85-ebc45476e7ce


Reply to this email directly or view it on GitHubhttps://github.com/openpeer/ortc/issues/143#issuecomment-53092848.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment