RE: Issue 143: SSRC Conflict

In WebRTC 1.0, the SSRCs are chosen by the browser and provided in the SDP produced by createOffer(), and AFAIK they cannot be changed.  So if ORTC was to be implemented on top of WebRTC 1.0, how could the ORTC JS library set the SSRCs to be used in the underlying WebRTC 1.0 implementation?    

RFC 3550 Appendix A.6 contains sample code for SSRC generation but even the sample code has some tricky aspects (e.g. the routine produces the same result on repeated calls until the value of the system clock changes unless different values are supplied for the type argument).  So to make the routine safe for the average developer, it would probably be prudent to add some additional safety (e.g. automatically setting the type value differently on each call).  

Given the above issue,  I would prefer if the browser picked a new SSRC and evented the old failed SSRC and the new SSRC, rather than just eventing the old failed SSRC. 

________________________________________
From: Robin Raymond [robin@hookflash.com]
Sent: Tuesday, August 05, 2014 7:33 PM
To: Peter Thatcher; Bernard Aboba
Cc: public-ortc@w3.org
Subject: 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<mailto:pthatcher@google.com>) wrote:

Sorry, I replied to github.com<http://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<mailto: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?

Received on Wednesday, 6 August 2014 04:09:55 UTC