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

[Cullen Jennings <[e-mail]>]

On Sep 22, 2011, at 7:57 AM, Tim Panton wrote:

> 
> On 22 Sep 2011, at 06:44, Cullen Jennings wrote:
> 
>> 
>> On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote:
>> 
>>> And why, did you design such a poor glare handling algorithm for SIP? ;-)
>> 
>> So, the SIP glare algorithm leaves much to be desired, no questions about it. I'm going to claim I was not there at the time until someone proves otherwise then switch my story to I was drunk not stupid. (in fairness we were trying to be backwards compatible with 2543 equipment).
> 
> Which is an important lesson for rtcweb, backward compatibility has longterm costs.
> 
> At the risk of showing my ignorance - why are we expecting glare to be a problem? 
> To my mind glare only happens when you have a locked resource e.g. a busy line
> or number . Rtcweb does not contain either of those concepts, what's the resource
> that is being competed for here ?
> 
> Tim (speaking entirely for his own ignorance)

Tim, it happens a fair amount in our playing around with browser deployments. Imagine you and I both using browsers and have an audio call set up.  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. In this case we often get glare. 

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.