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

From: [email-masked]
Date: Mon, 10 Dec 2001 10:41:50 -0700

Agreed.  The UA that generated the Call-ID (owner) is a good way to resolve
who shall proceed on re-Invite glare, and should not need to do any
re-attempts of the re-Invite.  The UA that does not own the Call-ID MAY
re-attempt its re-Invite once the Call-ID owner's transaction has completed,
allowing his re-attempt to complete as quickly as possible without the need
for timers.
 
John Hearty
Level3

-----Original Message-----
From: Scott Orton [mailto:[email-masked]]
Sent: Monday, December 10, 2001 10:11 AM
To: 'brett'; sip
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. 

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. 

_______________________________________________ 
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
<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: Tue, 11 Dec 2001 12:14:54 -0500

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