Subject: RE: [Sip] Open Issue #139: re-INVITE Glare

From: [email-masked]
Date: Thu, 6 Dec 2001 09:21:49 -0700

I like the 491 response, but am still not completely happy with the retry
mechanism which is  still essentially the same as before.  I would prefer
something that both sides would know definitively who proceeds on the glare
(or whatever it will be called).  Perhaps converting the Contact header
value of both UAs to an integer, highest value wins.  There may be a better
way than this, but something that definitively decides which UA's Invite
gets 200 OK'd and which gets 491'd is preferable.  This completely
eliminates retry time for one of the UAs, and the other can do its retry
after the OK'd transaction completes.

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 8:18 PM
To: [email-masked]'
Subject: [Sip] Open Issue #139: re-INVITE Glare

Issue:

A sends an re-INVITE to B. B sends a re-INVITE to A. These cross on the
wire. If both respond with 2xx, we have a problem. There is no way to order,
at A, the INVITE from B and the 2xx from B, as each contain SDP, and
potentially other information as well. What to do to deal with this?

Discussion:

The current spec says that when you receive a re-INVITE whilst one is in
progress, you respond to that reinvite with a 5xx and a Retry-After header
randomly distributed between 1 and 10s (in units of 1s). Unfortunately, the
problem with this is it will take 5s on average to try again, with a 10%
probability of another glare. This could mean it takes a while to resolve
the glare. So, the issue is if there is a better way.

There is. The better way is to be explicit. We define a new response code,
491 (Request Pending), which says "I got your request, but I have one
pending to you that interacts". There would be two recommended behaviors. If
A sends an INVITE to B, and gets a 491 back before the request from B that
"glared", A simply responds to that glared request with a 2xx and everything
works. If A sends an INVITE to B, and then receives the request from B, it
responds to that request with a 491. If the response to its own request was
491, it chooses a random number between 0 and 3s, in units of 10ms, and
tries again at that time. This will work much faster than before, and since
its explicit about what happened, potentially other strategies could be
used.

We also need to generalize it beyond re-INVITEs, and call it something less
telephony centric.

Proposal:

Go with 491 approach described above.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Scott Orton" <[email-masked]>
Date: Mon, 10 Dec 2001 11:11:07 -0600

I like the 491 response code. I also prefer the idea of using the owner of
the Call-ID as Brett proposed below. I would suggest taking it a little
further. 

Lets assume that A is the owner of the Call-ID and B is the other party. 
If A receives the re-invite from B it should send a 491 to the Invite from
B. If B on receives a re-Invite from A it should process the request, rather
than sending the 491, and wait for the 491 for its own re-invite. 

This reduces the message traffic in the network and the delay in processing
the re-invite for the originator of the dialog.

Scott Orton
Nortel Networks  

-----Original Message-----
---snip ---

Using an explicit response code sounds fine, 
especially to avoid an accidental SRV next-hop 
occurrence from a 503 with Retry-After 
related to issue #128. :)

However I agree with John that something 
should produce an early winner of the 
re-INVITE glare.  How about allowing the 
owner of the Call-ID to have the random 
0 to 2 seconds (by 10ms) and the other 
gets random between 2.1 and 4 seconds 
(by 10ms)?  Session refreshing induced 
reinvites should choose higher random 
backoff intervals assuming that there 
is time left to accommodate it.

---

From: [email-masked]
Date: Tue, 11 Dec 2001 11:01:53 -0700

It would seem your first point could be worked around if there was
documentation defining the interpretation of a refer-to with Call-ID, rather
than leaving the interpretation up to the implementor.  I am not clear on
your second point.

 I'm open to suggestions for an alternate way to do this, or improvements to
the proposal.  My concern is that we determine a mechanism that produces a
definitive winner during glare in which both ends arrive at the same result.
I do not prefer the original proposal using timers.  It wastes time and
increases messaging traffic.

John Hearty
Level3

-----Original Message-----
From: Brett Tate [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 10:15 AM
To: [email-masked]
Subject: RE: [Sip] Open Issue #139: re-INVITE Glare

> I like the 491 response code. I also prefer 
> the idea of using the owner of the Call-ID 
> as Brett proposed below. I would suggest 
> taking it a little further. 
>
> If A receives the re-invite from B it 
> should send a 491 to the Invite from B. 
> If B on receives a re-Invite from A it 
> should process the request, rather than 
> sending the 491, and wait for the 491 
> for its own re-invite. 

This would typically work.  However 
sometimes neither or both are the owner 
depending on the interpretation of a 
refer-to with Call-ID.
In addition the non-owner can't be
certain that a 200 will not be sent
by the owner (unless a re-invite MUST
queued until ACK received from UAC).

---

From: "Chiou, Mark" <[email-masked]>
Date: Tue, 11 Dec 2001 12:58:26 -0600

Hi,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 12:02 PM
To: [email-masked]; [email-masked]
Subject: RE: [Sip] Open Issue #139: re-INVITE Glare

 It would seem your first point could be worked around if there was
documentation defining the interpretation of a refer-to with Call-ID,
rather
than leaving the interpretation up to the implementor.  I am not clear
on
your second point.

 I'm open to suggestions for an alternate way to do this, or
improvements to
the proposal.  My concern is that we determine a mechanism that produces
a
definitive winner during glare in which both ends arrive at the same
result.
I do not prefer the original proposal using timers.  It wastes time and
increases messaging traffic.

[MC] I like the mechanism purposal, which is similar to SS7 Glare
handling.
Can we suggest that if the re-INVITE glare condition occurs, the
original UAC get the control and the UAS must give in? I mean if A calls
B, then A is UAC and B is UAS. when A and B both send a re-INVITE at the
same time, the B should backup.

John Hearty
Level3

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 11:05:53 -0500

inline.

Scott Orton wrote:

 > I like the 491 response code. I also prefer the idea of using the
 > owner of the Call-ID as Brett proposed below. I would suggest
 > Lets assume that A is the owner of the Call-ID and B is the other
 > party.  If A receives the re-invite from B it should send a 491 to
 > the Invite from B. If B on receives a re-Invite from A it should
 > process the request, rather than sending the 491, and wait for the
 > 491 for its own re-invite.

Alas, were it that simple, we would have resolved this long ago.

The problem with this, and Brett's solutions (although his will still 
work, just may not produce an early winner as expected), is that they 
rely on a *shared view* of whether there is glare or not. Turns out that 
you cannot guarantee it. So, let me give two examples where there is not 
a shared view, and having an algorithm for choosing a winner fails.

I actually posted this to the list over a year back:

   I'm afraid this solution does not work as specified. It only works
   if both sides agree they are in a glare situation. Consider the
   following case. A sends a reinvite to B. B receives it, and responds
   with a 200. This response takes a while to get to A. Now, B sends a
   re-INVITE to A (as far as B is concerned, the reinvite it received
   has been responded to, thus there is no glare, and it can send a new
   re-INVITE). A receives that re-invite. A thinks there is glare, and
   decides its the winner, so it responds. Then, A gets the non-500
   response from B. Now A is really confused.

   You could argue that B shouldn't even send that re-INVITE until the
   ACK is received for the re-INVITE B got first. However, there is
   still a race condition that makes it not work, although its even
   less likely. Heres the case: A sends a re-invite to B that gets
   lost. B sends a re-invite to A. A sees glare, and decides A should
   win, so it responds with a 200 OK. B ACKs, and A gets the ACK. Then, that
   lost reinvite arrives at B. B thinks everything is fine, since the
   previous reinvite it sent has been ACKed. So, it sends a 200
   OK. Now, A is once again confused. It expected B to reject that first
   INVITE, since A was declared the winner.

> is time left to accommodate it.

There are cases where the "owner of the call-id" is also not known. 
Consider the case where A calls B. A crashes. B detects this through 
ICMP on the media channel, and does a re-INVITE to re-establish. A 
backup for A reconstitutes the state, and the call continues. Now, A 
thinks that B owns the Call-ID, and B thinks A owns it. Hmmm.

In this case, what you are proposing will still work, it just may 
require another round. I'm assuming the reason you are proposing one of 
them using 2-4 seconds is to avoid a second glare condition, in the 
event both sides choose the same random number. Despite the case above, 
I think its a reasonable idea, since the above situation is a corner 
case, and the odds of another glare are still fairly high (I think the 
odds of it are something like the RTT over the randomization interval).

So, I would propose amending my original proposal to incorporate Brett's 
idea of having one side choose a larger value for the range based on a 
heuristic.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Thu, 27 Dec 2001 14:30:30 -0700

> Sent: Thursday, December 27, 2001 9:06 AM
> To: Scott Orton
> Cc: 'brett'; sip
> Subject: Re: [Sip] Open Issue #139: re-INVITE Glare
> 
> 
> inline.
> 
> Scott Orton wrote:
> 

This scenario would require packet re-ordering, with B's 200 arriving at A
after B's re-Invite.  These are both going to the same place, and these
days, the likelyhood of packets between the same two places getting
re-ordered is not that high.  Granted, there are probabally proxies between
increasing the likelyhood of the messages getting re-ordered.  However, do
we really want to discard a cleaner solution for a small percentage of
negative scenarios?  I have seen arguments in other threads against solving
problems resulting when the network is totally hosed.

>    INVITE, since A was declared the winner.

B better not think everything is fine, it just got an Invite with the same
Cseq it just used.  Again, this scenario requires packet re-ordering between
the same end points, not a highly likely thing to happen.  The proposed
argument of not re-Inviting until after ACK seems to tie back to the
overlapping Invite open issue #113, I am unclear where that left off other
than it got ugly quickly and it seemed too late to resolve in bis.  This
might be another reason to avoid overlapping Invites unless it becomes a
pressing need.  I still feel we should avoid timers to resolve glare if we
can.  They are inefficient.

> thinks that B owns the Call-ID, and B thinks A owns it. Hmmm.

 If A is smart enough to reconstitute state, it ought to be smart enough to
know if it owned the Call-ID.  This could be a condition of the proposal for
issue #207.  Otherwise, we don't have to stick with the "owner of the
Call-ID", there are other things unique to the transactions that could be
used to derive a definitive early winner.