SSRC Conflict

[aboba]

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]

@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]

Potential proposed resolution:
http://lists.w3.org/Archives/Public/public-ortc/2014Aug/0031.html

[aboba]

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.

[ibc]

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]

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

[aboba]

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//issues/143#issuecomment-53092848.