Re: [rtcweb] Minimal SDP negotiation mechanism

[Harald Alvestrand <[e-mail]>]

On 09/20/2011 03:24 PM, Magnus Westerlund wrote:
> On 2011-09-19 18:59, Harald Alvestrand wrote:
>
>> We need to handle glare - when one sends an OFFER and gets back an
>> OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send
>> out an offer again.
>>
> I think that is a bad design for glare handling. I agree it needs to be
> handled. I think the ICE version of glare handling could work pretty
> well here. Any offer needs to include a random 32 bit number. If the
> end-point receive an offer in relation to a peer-connection while it has
> an outstanding offer then it compares these codes. Who ever has the
> greatest numerical value wins and that offer is handled the other is
> responded with an error stating GLARE. Thus there is no extra delay and
> more clear resolution of the glare case.
Hm... thinking about it, I think this can be incorporated.
The reason it works is that the signalling channel is supposed to 
guarantee reliable, ordered delivery, so we know that both parties agree 
that a glare condition exists. (actually, that condition doesn't hold 
for ICE, so I'm a bit surprised it works there.)

If we specify that the random number is 1 < N < MAXINT, we can even 
incorporate the SIP interworking case by saying that a gateway can force 
the party into GLARE by specifying one of the edge cases - whatever 
makes interworking happy.