Re: Issue 143: SSRC Conflict

Over all it’s a good strategy.

I would also be okay if the browser just picked a new SSRC and evented the old failed SSRC and the new SSRC. But I can appreciate if a JS developer may want to allocate their own new SSRC from JS and then signal that before attempting to send with it.

-- 
Robin Raymond

On August 5, 2014 at 7:20:29 PM, Peter Thatcher (pthatcher@google.com) wrote:

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?