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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 22:17:53 -0500

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

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Dec 2001 22:34:05 -0500

> Go with 491 approach described above.

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.