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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 25 Jan 2006 10:55:52 -0500

Thanks.  More inline. 

> -----Original Message-----
> From: Benny Prijono [mailto:[email-masked]] 
> Sent: Wednesday, January 25, 2006 7:20 AM
> 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,
> 
> I very much like the way you structurized the problem, it 
> makes it very easy to read. Unfortunately the second case 
> doesn't work.
> 
> More inline.
> 
> 
> Michael Hammer (mhammer) wrote:
> > So, let us see if I understood the two cases correctly based on this
> > thread:
> > 
> > 1.  Offer-Answer complete (no SDP needed in ACK) case:
> > 
> > UAC:  Upon receipt of 200 OK and transmission of ACK, can send 
> > re-INVITE with new Offer.
> > 
> > UAS:  After sending 200 OK (with Answer), can treat receipt of 
> > re-INVITE as an implied ACK to the 200 OK, because 
> otherwise the UAC 
> > would have never sent the INVITE.
> > 
> 
> Yes, this may work. Although this would be at best seen as 
> "optimization" trick in the implementation, not a change in 
> the standard. I mean, if you choose to do this, then it may 
> work. If you don't want to do this, then it's fine too.
> 
> But still I don't like the "implied" bits, it sounds like 
> we're violating the standard INVITE cycle. I propose to add 
> additional text to your solution:
> 
> (UAS): .. But UAS MUST still retransmit the 200 OK until ACK 
> is received, and it SHOULD terminate the dialog usage with 
> BYE if ACK is not received.
> 
> This way we're not violating the standard (I hope).

Agree.  I was only thinking of whether the Post Dial Delay could be
minimized.  I think the implication is sound, but all the same, it is
probably best to verify with continued 200 OK and ACK retransmissions as
you suggest.  It could still be possible that the ACK arrives in time to
end the Timer G' behavior.

> > Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer 
> > before sending re-INVITE to confirm Answer received.
> > 
> > 2.  Offer-Answer not complete (SDP needed in ACK) case:
> > 
> > UAC:  Send Answer in ACK, then wait to see if 200 OK is 
> retransmitted, 
> > meaning the ACK was not received.  Thus, wait 2*T1 
> (expected bound for 
> > Timer G?) after receipt of previous 200 OK.  If no 200 OK, then can 
> > assume that ACK was received, and proceed to send the re-INVITE.
> > 
> 
> This will not work in all situations. It will only work in 
> the ideal situation where the first 200 OK transmission is 
> received by UAC and the ACK is not lost either.
> 
> But what if the first three 200 OK responses are lost? The 
> 2*T1 will be useless, since the second 200 response seen by 
> UAC will be received
>   2 seconds after it received the first one.

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)

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

---

From: Benny Prijono <[email-masked]>
Date: Wed, 25 Jan 2006 17:01:42 +0000

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.

> Times:    0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H' fires at T1*64=32

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?

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