Re: Issue 143: SSRC Conflict

The issue is less about who picks and more about the time it takes to pick. There can be a delay between the conflict and the time the JS has time to respond and start sending again. That will cause an interruption in the media. That’s one of the reason I favour the browser picking for conflicts. But I don’t have a strong opinion and I can appreciate that some developers might want full control before sending.

I think really it should come down to the use cases. When an SSRC conflict happens in the use cases where the JS set the SSRC manually, what does the JS need to do in the conflict case? Do we know? can we guess? Seems like legacy use cases where we should be able to know the expected usage(s) since muxId is the forward looking solution here.

Curious, in WebRTC 1.0, what happen in SSRC conflict? “re-invite required”? We also need to shim so I’m curious what is required.

-- 
Robin Raymond

On August 6, 2014 at 12:23:42 PM, Peter Thatcher (pthatcher@google.com) wrote:

On Wed, Aug 6, 2014 at 8:07 AM, Bernard Aboba  
<Bernard.Aboba@microsoft.com> wrote:  
> On Aug 6, 2014, at 7:14 AM, "Peter Thatcher" <pthatcher@google.com> wrote:  
>>  
>> If the JS chooses not to specify SSRCs, then the browser can pick a  
>> new one, but doesn't need to fire an event.  
>  
> [BA] Question: SSRC not present in send.RTCRtpParameters.RTCRtpEncodingParameters means "browser chooses". For receive it means "wildcard". Correct?  

Correct. Although, "wildcard" when used with muxId means "any SSRC  
with the given muxId, including latching behavior", and even without  
muxId still means "demux by payload type if necessary".  

>  
>> If choosing SSRCs is to hard for the app, then it won't choose them in the first place.  
>  
> [BA] With "muxId" the application won't need to choose them on the sender or specify them on the receiver. Correct?  

Correct. If they still do, what was the point of muxId?  

>  
>  
>> 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.  
>  
> [BA] So media sending would be interrupted until send() is called again with the new SSRC?  

Yes, but if you're signalling SSRCs for demux, the receiver probably  
isn't going to handle the media into the new SSRCs are signalled  
anyway, so I don't see there being a big loss here. And as I've  
stated a few times, I think an SSRC collision will be a very unlikely  
event. You'll much more likely see media interrupted for many other  
reasons.  

>  
>>  
>>>  
>>> ________________________________________  
>>> 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 Raymo