Subject: RE: [Sip] Re: Re-Invite before ACK

From: Rocky Wang <[email-masked]>
Date: Tue, 07 Feb 2006 11:08:49 +0800

In Section 14.2 UAS Behavior of RFC 3261, it says:
   If a UAS generates a 2xx response and never receives an ACK, it
   SHOULD generate a BYE to terminate the dialog.

That is, the UAS SHOULD terminate the dialog. But because the misorder
of the SIP messages, sometimes the UAS SHOULD NOT terminate the dialog
as I considered.

The UAS can have several choices to handle in this case:
1. Terminate the dialog as the specification. This is not reasonable in
some cases and it is not a good idea.
2. UAS can accept the re-INVITE and wait for ACK. It can handle the
re-INVITE before the ACK comes or after ACK comes. If before ACK, the
case will becomes more complicated if maybe the ACK will take SDP answer
back. But if after ACK comes, it must buffer it. This is not a good
idea, I think.
3. UAS can ignore the re-INVITE because UAC will re-transmit again. UAS
can accept it after ACK comes simply.
4. As Section 14.2 of RFC3261:
   A UAS that receives an INVITE on a dialog while an INVITE it had sent
   on that dialog is in progress MUST return a 491 (Request Pending)
   response to the received INVITE.
UAS can reject the re-INVITE temporarily by 491 and UAC side will
initiate another try several seconds later.

I don't suggest taking Offer/Answer procedure into account because
session is limited into RTP relationships nowadays and maybe it will be
expanded into some other types of relationships, e.g. VPN session. If
you make a decision based on OA state, you must change your formula.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Hammer (mhammer)
> Sent: 2006年1月26日 1:43
> To: Benny Prijono
> Cc: [email-masked]; James Polk (jmpolk); srinidhi n
> Subject: RE: [Sip] Re: Re-Invite before ACK
> 
> 
>  
> 
> > -----Original Message-----
> > From: Benny Prijono [mailto:[email-masked]]
> > Sent: Wednesday, January 25, 2006 12:02 PM
> > To: Michael Hammer (mhammer)
> > Cc: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish 
> > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; [email-masked]
> > Subject: Re: [Sip] Re: Re-Invite before ACK
> > 
> > Michael,
> > 
> > even after your lengthy explanation, I still think it wouldn't work.
> > Perhaps it's because I didn't explain it clearly either. 
> More inline.
> > 
> > Michael Hammer (mhammer) wrote:
> > > Thanks.  More inline.
> > > 
> > > You misunderstood the actual suggestion because it was not clearly
> > > laid out.  The idea was that the UAS is going to 
> retransmit 200 OK 
> > > according to a Timer G' behavior.  Let us call what the 
> UAC thinks 
> > > this behavior is the Timer G".  Assuming T1=500 ms, Timer 
> G' at UAS 
> > > will send 200 OK
> > > at:
> > > 
> > > Interval: 0, .5, 1.0, 2.0, 4.0,  8.0, 16.0
> > > Times:    0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer H' fires 
> > at T1*64=32
> > > sec)
> > > 
> > > Timer G" at UAC can have identical behavior.  Assume
> > one-way transport
> > > time is .1 second.
> > > Interval: 0.0, .5, 1.0, 2.0, 4.0,  8.0, 16.0
> > > Times:    0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' 
> > fires at T1*64=32
> > > sec)
> > > 
> > 
> > The problem is, you assumed that timer G" starts in UAC at
> > the same time when timer G' starts in UAS. This is not 
> > possible (I think). 
> > Timer G" can only start at UAC when UAC receives the first 
> > 2xx response. Is this correct, or am I missing something here?
> 
> Yes, Timer G" only gets started once the 200 OK is received 
> and why I had to include the half RTT.
> 
> > If this is correct, then what if the first 2xx response
> > received by UAC is actually the n-th retransmission (because 
> > n-1 responses were lost). In this case, timer G' and G" won't 
> > be synchronized.
> > 
> > Let me illustrate with a diagram. We'll ignore RTT time, for
> > simplification.
> > 
> > Time   UAC                          UAS
> > 0.000       lost X <------ 200/OK --
> > 0.500       lost X <------ 200/OK --
> > 1.500       lost X <------ 200/OK --
> > 3.500  <------------------ 200/OK --
> >         -- ACK -----------> X lost
> > 7.500  <------------------ 200/OK --
> > 
> > At time 3.500, UAC starts timer G". After 2*T1, at time
> > 4.500, UAC thinks it's okay to send re-INVITE, because no 200 
> > retransmission is received. But this is wrong, since the 
> > retransmission WILL be received at time 7.500.
> > 
> > Am I missing something?
> > 
> > -benny
> 
> Yes, I see the problem now.  The UAS is further out in its 
> backoff interval than the UAC which started its backoff 
> interval later, but more aggressive.  Thus, the UAC would 
> always beat the UAS to the punch.  Of course once you have 
> two 200 OKs, you would know where in this sequence you were, 
> but that is too complex.
> 
> This suggested hypothetical behavior would work better (thinking out
> loud) if Timer G' and G" were more like Timer E and retrans 
> at MIN(2*T1, T2), that is at regular intervals.  Or, even 
> just define a T5 value say, 2 seconds, with no back off.  
> 
> Makes me wonder if INVITE response retransmissions in general 
> should not exhibit a backoff.  That is Timer G, G', G" should 
> all be at some fixed interval.  This would speed up comletion 
> of the INVITE transaction. But, that would require a change 
> to RFC-3261.  Would have to think what the downside to that is.
> 
> The current alternative seems to be keep pounding the UAS 
> with re-INVITEs until one gets through.  That is more brute 
> force and would seem to aggravate overload conditions.
> 
> BTW, I can't claim any credit for this Timer G" idea, I was 
> only following through the thought introduced earlier by someone else.
> 
> Mike
> 
> > 
> > > At time 0 the 200 OK is sent.  At time 0.1 it is received
> > at the UAC.
> > > 
> > > If the ACK is not received the UAS would send again at 
> time 0.5 and
> > > the UAC would receive it at time 0.6
> > > 
> > > At time 0.6, if a second 200 OK is received, UAC
> > retransmits the ACK
> > > and sets Timer G"=1 so that it fires at time 1.6.
> > > 
> > > At time 1.6, if a third 200 OK is received, UAC 
> retransmits the ACK
> > > and sets Timer G"=2 so that it fires at time 3.6 and so on.
> > > 
> > > This is the theoretical minimum.  The actual suggestion was
> > to start
> > > the Timer G" at 2*T1:
> > > Interval: 0.0, 1.0, 2.0, 4.0,  8.0, 16.0
> > > Times:    0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" fires 
> at T1*64=32
> > > sec)
> > > 
> > > Compare with the Timer G' behavior adjusted with .1 cross-network
> > > transmit time.
> > > Times:    0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' 
> > fires at T1*64=32
> > > sec)
> > > 
> > > Note that the "200 OK expected" times are increasingly larger than
> > > what the actual 200 OK receipt times at the UAC should be.  The 
> > > end-game for Timer H" would need to be handled, but you get 
> > the idea now, I hope.
> > > 
> > > 
> > >>So in general, I think this type of solution will not 
> work, because
> > >>there is no way for UAC to know when the next response 
> will arrive.
> > > 
> > > 
> > > I would state this the other way.  There is no way for the
> > UAC to know
> > > that the ACK was received and therefore that a 200 OK will not be
> > > forthcoming.  The issue still is answering the question 
> > (rather than
> > > waiting some very long time) when is the earliest it is
> > reasonable to
> > > try to send the re-INVITE with high probability of success?
> > > 
> > > If you send immediately and get a 491 in return, this 
> just puts the
> > > UAC in the same situation of needing to decide when to 
> > retranmit.  The
> > > ACK could be received immediately after the 491 was sent.
> > So, sending
> > > the re-INVITE immediately after ACK has only postponed this
> > decision
> > > *IF* the network delivery and handling at the UAS is misordered.
> > > 
> > > Perhaps a compromise is to wait an RTT before sending the 
> re-INVITE
> > > and allow Timer A to take care of the rest.  (Note Timer A 
> > will fire
> > > quicker than Timer G'.)
> > > 
> > > Mike
> > > 
> > > 
> > >>Thus for UAC, the only thing that works is to handle 491 (Request
> > >>Pending) response when it arrives.
> > >>
> > >>-benny
> > >>
> > >>
> > >>>UAS:  Reject any re-INVITE before ACK received with 491 Request
> > >>>Pending, since Answer to Offer in 200 OK was not 
> received.  Accept 
> > >>>re-INVITE with new offer only after ACK received.
> > >>>
> > >>>Where UAS wants to re-INVITE, wait for ACK with Answer 
> to complete
> > >>>Offer in 200 OK before sending re-INVITE.
> > >>>
> > >>>My only question is that Timer G starts with T1 not 2*T1,
> > >>
> > >>so is this
> > >>
> > >>>for margin of safety?  Also, doesn't this assume that both
> > >>
> > >>UAC and UAS
> > >>
> > >>>use same T1 value?
> > >>>
> > >>>Mike
> > >>>
> > >>>
> > >>
> > > 
> > 
> 
> _______________________________________________
> Sip mailing list  https://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  https://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