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

[Magnus Westerlund <[e-mail]>]

Hi,

Here is an analysis of what happens including Cullen's SIP side
optimization if one uses a random value attached to the offer as
tiebreaker and interop with SIP.

Lets start with the general scenario.

A <-RTCWEB-> WS/SGW <-SIP-> B

So lets look at the glare conditions that can occur.

a) Initially in regards to the creation of a PeerConnection/call where
both sides attempt to create a session with its peer.

b) During a re-Offer/re-inivite in an existing session.

However, I don't think this really matters for the glare resolution
mechanism. It might effect which SIP messages are sent in which case.

Secondly the glare condition will be detected in various cases depending
on in what state of signalling 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.

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

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.

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.

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.

I think the optimization makes sense, but is more a question of fixing
SIP than really being needed for RTCWEB. I also wonder why not a SIP
header for the tie-breaking? There appear also to be some more cases to
analyze in detail and to figure out if the scheme breaks with some
middleboxes.

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