Re: Issue 143: SSRC Conflict

On Tue, Aug 5, 2014 at 9:09 PM, Bernard Aboba
<Bernard.Aboba@microsoft.com> wrote:
> 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?

In Chrome, you can munge the SDP and set all the SSRCs.  Whether
that's part of the standard for setLocalDescription or I'm not, I'm
not sure.

>
> 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.

If the JS chooses not to specify SSRCs, then the browser can pick a
new one, but doesn't need to fire an event.  If choosing SSRCs is to
hard for the app, then it won't choose them in the first place.

If the JS chooses to specify SSRCs, then presumably it knows how to
choose them, and when faced with the need to choose a new one,
presumably it could do it.  Further, if it chooses to specify SSRCs,
it probably doesn't want the browser to start sending packets that it
never told it to send.  If choosing SSRCs isn't hard for the app in
the first place, it won't be hard for the app in second.  Personally,
I think choosing SSRCs just isn't that hard.


>
> ________________________________________
> 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 14:14:28 UTC