Re: Issue 143: SSRC Conflict

Sorry, I replied to github.com instead of here.  This is a repost:

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.

And the JS only needs to handle this event/error if it specifies SSRCs.  If
it doesn't specify SSRCs and relies on payload type or muxId for demux
(which I hope will be most of the time), then the browser can change the
SSRC and not tell the JS.  If the JS has specified the SSRCs, then if it
does so correctly, there shouldn't be a collision in the first place.

I think that in practice this error/event will basically never get fired.
And if it is and the JS doesn't handle it, the worst case is that media
fails.  But there 100 other more likely reasons that media will fail, that
I'm really not that worried about this one.
On Aug 5, 2014 2:32 PM, "Bernard Aboba" <Bernard.Aboba@microsoft.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?
>