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

From: [email-masked]
Date: Tue, 8 Jan 2002 10:48:39 -0700

Your points are all valid.  I cannot think of a good alternative to be
certain both sides agree there is glare.  Since the probability of glare is
not particularly high anyway, and in the interests of timely resolution of
open issues, the latest timer solution seems acceptable.

John Hearty
Level3

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, January 01, 2002 9:42 PM
> To: Hearty, John
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Open Issue #139: re-INVITE Glare
> 
> 
> 
> 
> [email-masked] wrote:
> 
> > 
> 
> >>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.
> >>
> > 
> > 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.
> 
> 
> Its not reordering, so much as packet loss. All it takes is 
> one or two 
> lost 200 OK's, and the above scenario can happen without the network 
> doing any packet reordering.
> 
> 
> > 
> > 
> >>   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.
> >>
> > 
> > B better not think everything is fine, it just got an 
> Invite with the
> > same
> > Cseq it just used. 
> 
> 
> Same CSeq? These are in opposite directions. There is no relationship 
> between the CSeq in each direction.
> 
> > Again, this scenario requires packet re-ordering
> > between
> > the same end points, not a highly likely thing to happen. 
> 
> 
> Packet loss is the problem, as I mentioned above.
> 
>  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.
> 
> 
> I welcome alternatives, but I am pretty sure anything that relies on 
> both sides agreeing that there was glare is not going to work.
> 
> 
> > 
> > 
> >>
> >>Now, Brett had proposed a variant:
> >>
> >>
> >>>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.
> >>>
> >>>
> >>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.
> >>
> > 
> >  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.
> 
> 
> Thats fair enough. This was definitely a minor point in 
> either case; I 
> thought Brett's proposal was reasonable, this issue aside.
> 
> -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
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jan 2002 13:30:42 -0500

Great. I will amend the proposal, so that it uses Brett's modified timer 
setting (one side chooses to retry in 0-2s, the other in 2-4s, based on 
a belief in which side is the originator of the dialog).

Issue resolved.

Thanks,
Jonathan R.