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

From: "Jin, Haipeng" <[email-masked]>
Date: Fri, 20 Jan 2006 13:48:50 -0800

If you look at the following sections from the RFC:
 
13.2.2.4
" The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response. "

13.3.1.4

" The 2xx response is passed to the transport with an
   interval that starts at T1 seconds and doubles for each
   retransmission until it reaches T2 seconds (T1 and T2 are defined in
   Section 17).  Response retransmissions cease when an ACK request for
   the response is received.  This is independent of whatever transport
   protocols are used to send the response.
 
      Since 2xx is retransmitted end-to-end, there may be hops between
      UAS and UAC that are UDP.  To ensure reliable delivery across
      these hops, the response is retransmitted periodically even if the
      transport at the UAS is reliable.
 
   If the server retransmits the 2xx response for 64*T1 seconds without
   receiving an ACK, the dialog is confirmed, but the session SHOULD be
   terminated.  This is accomplished with a BYE, as described in Section
   15.

"

One the UAC side, the INVITE transaction is considered completed only
after 64*T1 of the first 2xx. On the UAS side, the server is expecting
ACK within 64*T1 after the 2xx is sent, otherwise the session will be
terminated. This, in essence, means that INVITE transaction will not
complete until the ACK is sent and received. As a result I don't think
the "reinvite before ack" makes practical sense.

Thanks,

Haipeng

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Xiao Wang
Sent: Thursday, January 19, 2006 5:57 PM
To: 'Manish Joshi'; 'James M. Polk'; 'Miloslavsky Evgeny'; [email-masked]
Subject: RE: [Sip] Re-Invite before ACK

I  consider that ACK to INVITE's 200 OK is a individual transaction, but
it must send rapidly after receive

200 OK, otherwise it is no significance to acknowledge the INVITE
transaction. Even ACK send before the 

re-INVITE, for the reason of network delay, UAS may receive ACK after
re-INVITE.

 Deal with this scenario may be an implementation or client policy.

Xiao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Manish Joshi
Sent: Thursday, January 19, 2006 3:42 AM
To: James M. Polk; Miloslavsky Evgeny; [email-masked]
Subject: Re: [Sip] Re-Invite before ACK

Iniline..

"James M. Polk" <[email-masked]> wrote: 

At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote:
>Hi,
>
>The spec seems doesnt seem to be very clear on this.
>An ACK to first Invite is a new transaction as the Invite transaction 
>completed as soon as UAS sends final response as 200OK. UAC is now free
to 
>send a new re-invite along with the ACK to the first Invite.

>>I don't believe so. I believe the stated behavior of the UAC is that
it 
>>cannot send a new INVITE within a dialog until the ACK is sent. The
UAC >>is free to send any new INVITE outside of an existing dialog
though. >>Section 14.1 covers this I believe.

Actually I think 14.1 supports more what I mentioned above:

Quote:

"   Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.

      1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the transaction reaches the completed or terminated
         state before initiating the new INVITE."

UNQUOTE

ACK is a new transaction and receiving a final response (200OK) actually
completes the INVITE transaction and hence UAC is free to Initiate a new
(re)Invite transaction.

>Now since the packet ordering is not _ensured_, a reinvite can always
come 
>to UAS before ACK and hence UAS should be able to accept it.

>>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in
this 
>>situation (prior to receiving the ACK to the original INVITE/200 OK
exchange)

>
>BTW, this might also be an implementation option, where you chose to 
>Ignore the re-invite in case the first INVITE did not have an offer and

>200 OK was the one with the offer and ACK will contain the
media-answer.
>
>My two cents.
>-Manish
>
>Miloslavsky Evgeny wrote:
>Yahoo! Photos - Showcase holiday pictures in hardcover
>Photo 
>Books. You design it and we'll bind it!
>_______________________________________________
>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
>

________________________________

Yahoo! Photos
Got holiday prints? See all the ways
<http://us.rd.yahoo.com/mail_us/taglines/holidayprints/*http:/pa.yahoo.c
om/*http:/us.rd.yahoo.com/mail_us/taglines/photos/evt=38089/*http:/pg.ph
otos.yahoo.com/ph/print_splash>  to get quality prints in your hands
ASAP.

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Fri, 20 Jan 2006 16:40:00 -0600

It seems to me that a well behaving UAC will send an UPDATE before sending 
a reINVITE if it has not sent the ACK yet.

Can the UAS assume (or is this stated somewhere explicitly?) the UAC has 
sent the ACK if it receives a reINVITE? This seems to mean the reINVITE 
should not be processed until the ACK arrives, or the timer triggers, which 
causes the UAS to BYE the original INVITE, and reject the reINVITE.

At 01:48 PM 1/20/2006 -0800, Jin, Haipeng wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C61E0B.4D177E65"
>
>
>  The UAC core considers the INVITE transaction completed 64*T1 seconds
>    after the reception of the first 2xx response.
>
>
>13.3.1.4
>
>  The 2xx response is passed to the transport with an
>after 64*T1 of the first 2xx. On the UAS side, the server is expecting ACK 
>within 64*T1 after the 2xx is sent, otherwise the session will be 
>complete until the ACK is sent and received. As a result I don t think the 
>reinvite before ack makes practical sense.
>
>
>
>Thanks,
>
>Haipeng
>
>
>
>
>
>
>
>----------
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao 
>Wang
>I  consider that ACK to INVITE s 200 OK is a individual transaction, but 
> >completed as soon as UAS sends final response as 200OK. UAC is now free to
> >>I don't believe so. I believe the stated behavior of the UAC is that it
> >Now since the packet ordering is not _ensured_, a reinvite can always come
> >>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this
> >200 OK was the one with the offer and ACK will contain the media-answer.
> >
> >My two cents.
> >-Manish
> >
> >Yahoo! Photos Showcase holiday pictures in hardcover
> >Photo
> >Books. You design it and we ll bind it!
>Got holiday prints? 
><http://us.rd.yahoo.com/mail_us/taglines/holidayprints/*http:/pa.yahoo.com/*http:/us.rd.yahoo.com/mail_us/taglines/photos/evt=38089/*http:/pg.photos.yahoo.com/ph/print_splash>See 
>all the ways to get quality prints in your hands ASAP.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 25 Jan 2006 09:44:49 -0500

BTW, I was not suggesting that this behavior was necessary, only that it
could work.  If from an implementation standpoint, and still compliant
to RFC-3261, you have another way to handle this, then go for it.  The
crux of the matter for me was that there was an open-endedness to when
to send the re-INVITE that could lead to sub-optimal performance from
the user experience in terms of getting the SDP to converge on the
desired stable state, whatever it was that required the re-INVITE.

More in the other emails.

Mike

> From: Xiao Wang [mailto:[email-masked]] 
> Sent: Tuesday, January 24, 2006 9:18 PM
> To: Michael Hammer (mhammer); 'Nataraju A B'; 'srinidhi n'; 
> 'Jin, Haipeng'; 'Manish Joshi'; James Polk (jmpolk); 
> 'Miloslavsky Evgeny'; [email-masked]
> Subject: RE: [Sip] Re: Re-Invite before ACK
> 
> Inline
> 
> Xiao
> 
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Tuesday, January 24, 2006 11:13 PM
> > To: 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
> > 
> > Inline.
> > 
> > > From: Nataraju A B [mailto:[email-masked]]
> > > Sent: Tuesday, January 24, 2006 3:32 AM
> > > To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang'; 'Jin, 
> > > Haipeng'; 'Manish Joshi'; James Polk (jmpolk); 
> 'Miloslavsky Evgeny'; 
> > > [email-masked]
> > > Subject: RE: [Sip] Re: Re-Invite before ACK
> > >
> 
> > > Comments inline...
> > >
> > > Thanks & Regards,
> > > Nataraju A.B.
> > >
> > > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > > Sent: Monday, January 23, 2006 8:39 PM
> > > To: 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
> > >
> > > 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.
> > >
> > > [ABN] we can't assume implicitly, reception re-INVITE 
> does not mean 
> > > 200OK was received.
> > 
> > Why not?  If the rule for UAC above were followed, a re-INVITE would
> > *ONLY* be sent if the 200 OK had been received.  Thus, 
> receipt of the 
> > re-INVITE also implies the UAC received the 200 OK.  This 
> is straight 
> > forward logic contingent on that UAC behavior.
> [Xiao] I fully agree with you. I guess that Nataraju points 
> to a particular instance for SIP stack.
> For UAS, the retransmissions of 2xx response are handled by 
> TU, but the requests are handled by server transaction(ST). 
> For a  particular instance, drop re-INVITE before ACK is very 
> simple on coding, but to SIP protocol handles  re-INVITE 
> before ACK not only dropping is logical and not very complex.
> 
> 
> > > For UAS to process re-INVITE,
> > > ACK should be received @ UAS. So only I mentioned we will 
> drop the 
> > > re-INVITE received @ UAS before ACK. For instance UAS have some 
> > > flags like ACK_EXPECTED, (similar to SDP_SENT/SDP_RECEIVED which 
> > > would be used to decide about delayed or early media negotiation 
> > > cases...).
> > 
> > This internal ACK_Expected flag would only be needed if the 
> ACK needed 
> > to carry an SDP Answer as in Case 2 below.
> > 
> > > any way
> > > transaction match does not happen since transaction would have 
> > > terminated soon after sending the 200OK, and dialog matches where 
> > > based on flags like these we can decide to accept the 
> re-INVITE or 
> > > not ?
> > >
> > > Where UAS wants to re-INVITE, wait for ACK to 200 OK with Answer 
> > > before sending re-INVITE to confirm Answer received.
> > >
> > > [ABN] TRUE (this is already covered in 3261), again based on some 
> > > logic mentioned earlier (ACK_EXPECTED)
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > [ABN] TRUE
> > >
> > > Where UAS wants to re-INVITE, wait for ACK with Answer to 
> complete 
> > > Offer in 200 OK before sending re-INVITE.
> > >
> > > [ABN] TRUE
> > >
> > > 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?
> > >
> > > [ABN] Timer G applicable only for failure responses.. not 
> for 2xx, 
> > > so not an issue...
> > 
> > I think RFC-3261 could be more rigorous here.  The table in 
> the back 
> > says INVITE responses, period.  I thought it was clear that the UAS 
> > upon sending a 200 OK will need to retransmit that 200 OK, if it 
> > doesn't get an ACK within some timeframe.  The UAC could 
> have sent the 
> > ACK and won't retranmit it unless it gets another 200 OK.  
> So, there 
> > is definitely a timer for 200 OK retranmits.  I am contending it is 
> > Timer G.  If you say it is not, then please identify the 
> name of the Timer.
> > 
> > Mike
> >
> [Xiao] I know your meaning. What time does UAC send re-INVITE 
> after ACK has not a exact time. I think this may be a 
> regulative parameter for user that people can base on a 
> average value of TTL between UACs and UASs add T1, and set 
> this value to SIP stack.
> 
> 
> > >
> > > Mike
> > >
> > >
> > > > Nataraju A B
> > > > Sent: Monday, January 23, 2006 8:52 AM
> > > > To: 'srinidhi n'; 'Xiao Wang'; 'Jin, Haipeng'; 'Manish
> > > Joshi'; James
> > > > Polk (jmpolk); 'Miloslavsky Evgeny'; [email-masked]
> > > > Subject: RE: [Sip] Re: Re-Invite before ACK
> > > >
> > > > RFC does not forbid sending re-INVITE soon after sent the
> > > ACK for the
> > > > 200OK.
> > > >
> > > > I guess it would be reasonable to drop that particular
> > > retransmitted
> > > > INVITE when UAS was in expectation of ACK for the initial
> > > INVITE. If
> > > > so, the ACK Might reaches the UAS and the actual 
> intention of the 
> > > > re-INVITE would be taken care by the subsequent retransmitted 
> > > > re-INVITE.
> > > >
> > > > Here we are assuming, if re-INVITE can reach UAS, for sure
> > > ACK might
> > > > also reach UAS,
> > > >
> > > > Assume if all the re-INVITEs were dropped because ACK was
> > > not received
> > > > for the earlier INVITE transaction, that lead to call
> > > termination (BYE
> > > > &
> > > > 200) that is very much inline RFC.
> > > >
> > > > Thanks & Regards,
> > > > Nataraju A.B.
> > > >
> > > > srinidhi n
> > > > Sent: Sunday, January 22, 2006 10:38 PM
> > > > To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M.
> > > > Polk'; 'Miloslavsky Evgeny'; [email-masked]
> > > > Subject: RE: [Sip] Re: Re-Invite before ACK
> > > >
> > > > 1. In case an SDP ofer was not made in the original Invite,
> > > there is
> > > > no way we can honour this Reinvite before an ACK and the
> > > session must
> > > > be terminated. On the other side, if a offer was made  in
> > > the Invite,
> > > > the reinvite either could be accepted/rejected(as being 
> discussed).
> > > >
> > > > Thus, the UAS needs to  exhibit a different behavior in
> > > cases where an
> > > > offer was made in Invite and when it wasn't. This apart from 
> > > > cancelling the re-transmission of 200 OK on recepton of ACK
> > > and also
> > > > reinvites.
> > > >
> > > > 2. 64*T1 is the worst case time period before which a ACK
> > > is to reach
> > > > the UAS. For every T1 and doubling thereafter till T2, the UAS 
> > > > retransmits a 200 OK.
> > > > Hence, the UAC can safely transmit the next message 
> from ACK after 
> > > > 2*T1, provided a 200 Ok is not retransmitted, without
> > > worrying about
> > > > any kind of UAS problems.
> > > >
> > > > 3.Another problem from UAC side would be how it would handle a 
> > > > retransmitted 200 OK(assuming the ACK is
> > > > lost) after initating a Re-Invite.
> > > >
> > > > Considering UAS behavior differences it would be easier 
> to not to 
> > > > handle the reinvite at the UAS.
> > > >
> > > > -Srinidhi
> > > > --- Xiao Wang <[email-masked]> wrote:
> > > >
> > > > > inline
> > > > >
> > > > > Xiao
> > > > >
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of
> > > > > > srinidhi n
> > > > > > Sent: Saturday, January 21, 2006 1:19 AM
> > > > > > To: [email-masked]; [email-masked]
> > > > > > Cc: [email-masked]
> > > > > > Subject: [Sip] Re: Re-Invite before ACK
> > > > > >
> > > > > > Do Correct me if I am wrong.
> > > > > >
> > > > > > 1. I think unless an ACK is receved by the UAS,
> > > > > its
> > > > > > transaction will not be complete and the UAS will 
> continue to 
> > > > > > re-transmit the original 200 OK.
> > > > > good
> > > > > > 2. As per sec.13 of RFC 3261,
> > > > > >   If the server retransmits the 2xx response for
> > > > > 64*T1
> > > > > > seconds without receiving an ACK, the dialog is
> > > > confirmed, but the
> > > > > > session SHOULD be terminated.
> > > > > This
> > > > > > is accomplished with a BYE, as described in
> > > > > Section15.
> > > > > Note " but the session SHOULD be terminated ",there use "
> > > > SHOULD" not
> > > > > "MUST".
> > > > > That is the protocol allow other cases to the session isn't 
> > > > > terminated.
> > > > > I think if ACK is used to acknowledge that UAC received 200
> > > > OK and not
> > > > > taking SDP, the session may not be terminated if the timer
> > > > fired and
> > > > > UAS received re-INVITE.
> > > > > Why may UAC send re-INVITE after send ACK?
> > > > > Because the protocol doesn't forbid. If the protocol
> > > explicit set a
> > > > > rule that UAC MUST wait 64*T1 after received the first 200
> > > > OK before
> > > > > send re-INVITE, this will not be flexible.
> > > > > In many cases, UAC need rapidly to send re-INVITE to UAS
> > > > for exchange
> > > > > new SDP after old INVITE transaction complete.
> > > > > Another cases, the value of T1 set in UAC may not equal to 
> > > > > UAS's, therefore, UAC don't know wait how long.
> > > > > Alternatively, if UAS receive re-INVITE before ACK that
> > > > means to UAC
> > > > > already received 200 OK of old INVITE, and UAS must deal with 
> > > > > the re-INVITE and not simple to return 491 or else 
> failure response.
> > > > >
> > > > > > In this case, it is really difficult from the UAS
> > > perspective to
> > > > > > predict if it will receive a "ACK"
> > > > > > after the "Re-Invite" although its more likely to 
> receive it.
> > > > > >
> > > > > > Hence, the UAS may chose to send 491 response.
> > > > > >
> > > > > > -Srinidhi
> > > > > >
> > > > > > __________________________________________________
> > > > > > 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
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > > > http://mail.yahoo.com
> > > >
> > > > 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
> > > >
> > > >
> > > > 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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 25 Jan 2006 09:56:37 -0500

> Sent: Wednesday, January 25, 2006 4:01 AM
> To: Michael Hammer (mhammer); 'srinidhi n'; 'Xiao Wang'; 
> Sent: Tuesday, January 24, 2006 8:43 PM
> To: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish 
> Joshi; James Polk (jmpolk); Miloslavsky Evgeny; [email-masked]
> > Haipeng'; 'Manish Joshi'; James Polk (jmpolk); 'Miloslavsky 
> Evgeny'; 
> > [email-masked]
> > So, let us see if I understood the two cases correctly based on this
> > thread:
> > 
> > [ABN] we can't assume implicitly, reception re-INVITE does not mean 
> > 200OK was received.
> 
> receipt of the re-INVITE also implies the UAC received the 
> 200 OK.  This is straight forward logic contingent on that 
> UAC behavior.
> 
> [ABN] if we decide to accept the re-INVITE, before ACK might 
> lead to a loop hole in the implementations where your stack 
> assumes ACK is received but actually not. This might lead 
> some scenarios use to happen in 2543 complaint stacks 
> (INVITE, CANCEL scenarios, I mean 200 for CANCEL closes INV 
> transaction also)

I agree it may be questionable to rely on the compliance of the UAC to
standards.  The re-INVITE MUST not be sent unless the Offer was Answered
in the 200 OK.  I could argue that all bets are off if the UAC is
violating multiple requirements.  But, that is beside the point.  There
is nothing complelling one to do the above optimization.  So, if it
hurts you, don't do it.  :)

> [ABN] its always preferred to make sure you have got what you 
> want within yourself instead of assuming other entity might 
> have sent but not been received... 

I was only suggesting that the sole thing that the ACK tells you is
identical to what the re-INVITE would tell you.  Nothing more.  Of
course, I could be overlooking something.

> > ACK should be received @ UAS. So only I mentioned we will drop the 
> > re-INVITE received @ UAS before ACK. For instance UAS have 
> some flags 
> > like ACK_EXPECTED, (similar to SDP_SENT/SDP_RECEIVED which would be 
> > used to decide about delayed or early media negotiation cases...).
> 
> ACK needed to carry an SDP Answer as in Case 2 below.
> 
> > any way
> re-INVITE or not 
> > ?
> retransmitted, 
> > meaning the ACK was not received.  Thus, wait
> > If no 200 OK, then can assume that ACK was received, and proceed to 
> > send the re-INVITE.
> > 
> > Pending, since Answer to Offer in 200 OK was not received.  Accept 
> > Where UAS wants to re-INVITE, wait for ACK with Answer to complete 
> > for margin of safety?  Also, doesn't this assume that both 
> UAC and UAS 
> > use same T1 value?
> > 
> for 2xx, so 
> > not an issue...
> the back says INVITE responses, period.  I thought it was 
> clear that the UAS upon sending a 200 OK will need to 
> retransmit that 200 OK, if it doesn't get an ACK within some 
> timeframe.  The UAC could have sent the ACK and won't 
> retranmit it unless it gets another 200 OK.  So, there is 
> definitely a timer for 200 OK retranmits.  I am contending it 
> is Timer G.  If you say it is not, then please identify the 
> name of the Timer.
> 
> [ABN] there is no timer name defined as such, but how often 
> UAS has to retransmit the 2xx response is mentioned in sec 13.3.1.4.

I re-read the section.  The behavior is identical to the Timer G.  There
seems to be some suggestion that because RFC-3261 split the behavior
into three layers, these timers should be layer specific.  So be it.
Then the Timer table should identify which timers belong to which
layers, and we could call the timer defined in Section 13.3.1.4 Timer G'
or some other letter.  Maybe on the next version.

Mike

> 
> The table at the end says only brief about the timers being 
> used in SIP stack implementations... but what is mentioned in 
> the particular section carries more detailed information... 
> 
> Mike
> 
> > 
> > Mike
> > 
> > 
> > > so, the ACK Might reaches the UAS and the actual intention of the 
> > > Hence, the UAC can safely transmit the next message from 
> ACK after 
> > > Considering UAS behavior differences it would be easier to not to 
> > > > > transaction will not be complete and the UAS will continue to 
> > > > Another cases, the value of T1 set in UAC may not equal 
> to UAS's, 
> > > > therefore, UAC don't know wait how long.
> > > > already received 200 OK of old INVITE, and UAS must 
> deal with the 
> > > > re-INVITE and not simple to return 491 or else failure response.
> > > > 
> > > > > after the "Re-Invite" although its more likely to receive it.
> > > > > 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for questions on current sip Use

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 25 Jan 2006 12:42:30 -0500

> 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 
> 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
> >>
> >>