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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 27 Jan 2006 11:00:33 -0500

There is some confusion about what does 2*T1 mean.  I think the intent
of the language in RFC 3261 was that a given timer would copy the
configured value of T1=0.5 sec, then timer x variable gets doubled after
each iteration.  So, T1 remains a constant, but the timer start value
doubles each time.

That said, what I think you are saying is that what I called Timer G"
exhibits this behavior:
Interval: 0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, ...
Times:    0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, ... until BYE received or 7
ACKs sent

Event [re-]setting timer:  receipt of 200 OK and sending of ACK
Event upon timer expiry:  Send re-INVITE
Event disabling timer:  7 ACKs sent or BYE received

Does that capture it?

Mike

> -----Original Message-----
> From: srinidhi n [mailto:[email-masked]] 
> Sent: Friday, January 27, 2006 10:17 AM
> To: [email-masked]; Michael Hammer (mhammer)
> Subject: Re: Sip Digest, Vol 21, Issue 21
> 
> 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