Subject: [Sip] Re: Sip Digest, Vol 21, Issue 21

From: srinidhi n <[email-masked]>
Date: Fri, 27 Jan 2006 07:17:05 -0800 (PST)

Looks like there is some confusion on this timers.

1. You are right. Timers need not be of the same value
on UAS and UAC and need not start at the same time.

2. The discussion was if sending a Re-Invite
immediately to ACK was correct.

3. The question as to what would happen if the 'n'th
200 Ok was the one received by the UAC. In this case,
till the UAC recevies a 200 Ok , it wont send a ACK
and neither an Re-invite.So no problem as this is not
the issue we are discussing.

So my suggestion was merely that, whenever the UAC
recevied a 200 Ok, it would send ACK. Before initating
a reinvite if UAC waited for atleast  2*T1 (with T1
being UAC value and started after sending ACK), then
atleast 1 200 Ok retransmission would be recevied if
UAS never recevied ACK and then the UAC can safely
send Re-Invite without worrying about the UAS
problems.

Hope this clarifies.

Thanks,
Srinidhi
--- [email-masked] wrote:

> Send Sip mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	https://www1.ietf.org/mailman/listinfo/sip
> or, via email, send a message with subject or body
> 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Sip digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re: Re-Invite before ACK (Benny Prijono)
>    2. RE: Re: Re-Invite before ACK (Michael Hammer
> (mhammer))
>    3. Question about Forking in a Proxy (Diego B)
>    4. Re: Question about Forking in a Proxy (Bob
> Penfield)
>    5. Providing Delayed Call Information (David
> Benoit)
>    6. Re: Providing Delayed Call Information (David
> Benoit)
> 
> 
>
----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 25 Jan 2006 17:01:42 +0000
> From: Benny Prijono <[email-masked]>
> Subject: Re: [Sip] Re: Re-Invite before ACK
> To: "Michael Hammer (mhammer)" <[email-masked]>
> Cc: [email-masked], "James Polk \(jmpolk\)"
> <[email-masked]>,	srinidhi
> 	n <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1;
> format=flowed
> 
> 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?
> 
> 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
> 
> > 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.
> >>
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
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: Fri, 27 Jan 2006 19:32:01 +0000

> send Re-Invite without worrying about the UAS

We have discussed that this wouldn't work in all cases, and the 
example that I've given has proved it. If you care to read my post 
again carefully, perhaps you'll come to the same conclussion. Or 
perhaps no, in that case I'll be glad to hear it.

-benny