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

[Magnus Westerlund <[e-mail]>]

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.

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]
----------------------------------------------------------------------