Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

[Cullen Jennings <[e-mail]>]

Could you'd like to elaborate on how it works when one of the sides is an SIP endpoint, or we the two endpoint are at different domains that are federated?



On Sep 22, 2011, at 1:33 PM, Matthew Kaufman wrote:

> On 9/22/11 11:56 AM, Cullen Jennings wrote:
>> Tim, it happens a fair amount in our playing around with browser deployments.
> 
> You make my own arguments for me.
> 
>> Imagine you and I both using browsers and have an audio call set up. 
> 
> Sounds great. And the web server has sent down some javascript that was able to query the capabilities and so it knows which audio and video codecs are supported at each end, even before the audio call started.
> 
>> We are talking an I say "hey, lets, add video", then we both go and push our "enable video" buttons at roughly the same time.
> 
> Also good.
> 
>> In this case we often get glare. 
> 
> You shouldn't.
> 
> Each side is asking the server to tell the other end to start sending video, and the server knows what codecs and parameters will work, so there's no overlap at all.
> 
>> Part of the reasons is that the signaling path is not really fast as it involves waiting for web servers to deal with sending notifications down to other side. It's hard to guess what the signaling delay will be but it easy to imagine that it will be over 200 ms in many cases and pretty easy to imagine that both of use would would click the add video button within 1/4 of second of each other. The glare we are talking about here is any time browser A has sent an SDP offer to the other side, but before A has received an SDP answer, the other side sends A and SDP offer.
> 
> See, that's the problem.
> 
> IF there are SDP offers and answers, they shouldn't be tied to the peer connection object, they should be tied to the objects that represent the devices... that way you would have two separate offer/answer happening, one for each direction.
> 
> And if you *weren't* using offer/answer, but had instead collected the capabilities ahead of time, then the server could just immediately tell each end to start sending.
> 
> So instead of a 200 msec delay *and* the risk of glare, you'd have zero delay *and* zero chance of glare.
> 
> Matthew Kaufman
>