Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling

[Cullen Jennings <[e-mail]>]

I'm going to slowly reply to a bunch of these comments in backwards order … 

But main thing on how to handle glare … I would love to see something better but I don't want to describe it in this draft so we just pointed at what we had.  If we can come up with a better way I'd like to have ROAP point at the draft that describes how to do with for things that use SDP offer / answer. 

End summary is however we decide to handle glare, I think we can fit that into ROAP but as we did not really have have a scheme written down yet, we just reused the existing stuff for now. Glad to update as we sort out what we need to do. 



On Oct 18, 2011, at 7:30 , Magnus Westerlund wrote:

> Cullen,
> 
> I would like to bring back my proposal for glare handling and propose
> that it be included in ROAP. The reason is that I don't think the SIP
> time based solution interact well with RTCWEB requirements at all.
> 
> The biggest issue is that one is likely to end up in glare condition
> again due to that the transport of the ROAP messages between
> end-points/Gateways can have properties that erases the randomization of
> the timer.
> 
> For example an JS application that uses short polling for retrieving any
> incomming ROAP messages, as that is timer based and done lets say every
> 5 seconds, then the polling is clearly done on a longer time scales,
> many times longer than what the random glare resolution happens at. Thus
> timer based solutions for resolving glare is use-less in RTCWEB context
> where we don't know how timely the transport is.
> 
> Thus I would propose that the following mechanism is include in ROAP.
> When generating an offer a 32-bit unsigned random integer value is
> generated (GlareResolution) and attached to the ROAP message. The random
> value may not be 0 and MAX_uint32.

So I like this types of scheme, but it seems if we put the random number in the SDP would allow this work for things beyond just RTCWeb.


> 
> What ever mechanism that inspects the message and is on the path of the
> ROAP message and sees a second offer in the opposite direction when one
> offer is outstanding in either direction can detect a glare. If the
> glare condition is detected the two offer's GlareResolution values are
> compared. The offer with the greater value wins. The other is discarded.
> As long as the winning offer is forwarded all the way to the offerer we
> can be certain that one signaling message wins.
> 
> In the case the two values are equal, both are discarded, but a error
> message must be returned for both messages to cause the end-points to
> generate new resolution values.
> 
> When interacting with a SIP gateway, the SIP gateway that create a ROAP
> message can chose how to generate the tie-breaker. Either it can pick
> MAX_uint32 to ensure that the message from the SIP side always wins, or
> it can select to always loose using 0 or have a random value be sent.
> Which is the right depends on where the glare occurs. But unless a glare
> condition already have been detected, a random value is used.
> 
> This mechanism could also be retrofitted into SIP by adding either a SIP
> header or a attribute in the SDP. That is what is referred as Cullen's
> proposal below.
> 
> Secondly the glare condition will be detected in various cases depending
> on in what state of signaling the glare occurs.
> 
> 1) If A sends an offer that left A, but not arrived at the GW, while B's
> are on its way between the GW and A.
> 
> 2) IF A sends an offer that has passed the GW, while B's are on its way
> between B and the GW.
> 
> 3) Both A and Bs Offers are at the GW while neither has been forwarded.
> 
> 4) Like 2) but B supports Cullen's behavior.
> 
> 
> 1) If A sends an offer that left A, but not arrived at the GW, while B's
> are on its way between the GW and A.
> 
> Assuming the GW sent a random value:
> 
> In case 1, entity A (a RTCWEB browser) will receive the Offer from B
> when itself has an outstanding offer. It perform the local tie-breaking
> of the SDP and determine that either A or Bs Offer is the winning. If A
> wins it just discards B, alternatively send an error (but that doesn't
> appear necessary). If B wins it abandons its Offer and process B's.
> 
> In case 1, the GW when A's Offer arrive at the GW, it has already sent
> B's offer with its tie-breaking value. It immediately determine who won
> the tie-breaking and then continue acting according to it. If A's won
> then it sends a SIP 491 with a significant large delay value. Then it
> sends A's offer with some small delay just as it got lucky with a low
> value. If B won, then it just discards A's Offer and waits for A's
> answer to B's offer.
> 
> 2) IF A sends an offer that has passed the GW, while B's are on its way
> between B and the GW.
> 
> In case 2) the GW could look for a tie-breaker value according to
> Cullen's proposal and if present then determine the winner. Considering
> that the quickest way to resolve the tie-breaking towards the RTCWEB
> client if the value isn't present is to fold for the RTCWEB client's
> behalf. Thus set B's tie-breker value to max. Then respond with a 491
> with delay 0 to B. When B come back with an new offer it assigns this
> the highest tie-breaker value and send it to A. A will then abort its
> offer and accept B's.
> 
> In case 2) in B, it will be completely in the SIP domain and it will
> respond with a 491 with a random delay value back to the GW. The GW will
> consume this message when it arrives.
> 
> 3) Both A and Bs Offers are at the GW while neither has been forwarded.
> 
> In case 3) the GW can avoid having the SIP UA (B) know there was any
> glare at all. This by setting the tie-breaking value for B's offer to
> MAX assuring it wins over A, and then send it to A to replace the offer.
> 
> In case 4) the GW will have sent a tie-breaker value with A's offer to B
> in the SDP. B's offer with a tie-breaker value arrives at the GW. The GW
> determine who wins. If B wins it forwards B's offer to A. If A wins it
> will do something to make B's offer being canceled. Maybe a 491 answer
> is the simplest. Except that it will not be retired.
> 
> 4) Like 2) but B supports Cullen's behavior.
> 
> In case 4) the UA (B) will have sent an invite with a tie-breaker value.
> When A's Invite with a tie-breaking value arrive it can perform the
> tie-breaking. If A wins then it immediately process it as if no
> outstanding Invite exist. (Question: how will the proxies react on that
> B responds immediately?). If B wins it sends a 491 for A's Invite. Then
> it continues waiting for the response.
> 
> 
> So independent of the optimization this can work as long as a GW is
> allowed to override a random selection mechanism in cases where the
> other protocol will resolve quicker if it does.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>