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

[Cullen Jennings <[e-mail]>]

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

Anyways, I've been bouncing ideas around with folks on how we might improve the situation. Here is a proposal that might improve it for SIP and could also be leveraged by RTCWeb. 

First, to review the current situation, the current algorithm is:

When two sides detect glare, they each pick a random integer from 1 to 10 and tell the other side to retry in that many seconds. two obvious problems with this: 1) it introduces, on average, over 7 seconds of delay which is a long time for a user 2) it has a non trivial chance of having glare a second time and needing to be repeat

I'm proposing an extension that would go something like this:

Both sides always include a random tie breaker number in their SDP that is used for glare resolution. If both sides support this and have the number, then glare is resolved by whoever has the lowest number. 

If neither side supports this, obviously the current things is what happens. 

if one side supports it but the other does not, the side that supports it tells the other side to retry after 0 seconds. So effectively it causes the other side to always "win" the tie and retry first. This reduces the latency of the glare resolution to the end user. The other side that does not support the new algorithm will still send a retry after some random number form 1 to 10 seconds. However, the side that supports this new mechanisms might want to decide that under some conditions, ti can short circuit that timer and retry sooner than that. It's not exactly clear to me when to short circuit this. Could it short circuit after receiving the retied transaction from the other side plus a one RTT delay? Could we just retry after 3 RTT or so knowing the other side won the race and was retying immediately? 

Even if the UA just runs out the full retry time, this algorithm still reduces the average delay significantly for cases where only one side supports it and gets really fast when both sides support it. 

Thoughts?

I suspect this would need an SDP extension to carry the tie breaker number or even if we used an existing number, it seems like we still need something that indicates support for this new extension.