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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 24 Jan 2006 10:12:45 -0500

Inline. 

> -----Original Message-----
> 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.
> 
> -----Original Message-----
> 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.

> 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

> 
> Mike
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > 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.
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > 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
> > > 
> > > > -----Original Message-----
> > > > 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
> > > > 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
> > > 
> > > 
> > 
> > 
> > __________________________________________________
> > 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
> > 
> > 
> > _______________________________________________
> > 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

---

From: Xiao Wang <[email-masked]>
Date: Wed, 25 Jan 2006 10:17:59 +0800

Inline

Xiao

> 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]
[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.

> it is not, then please identify the name of the Timer.
[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.

---

From: "Nataraju A B" <[email-masked]>
Date: Wed, 25 Jan 2006 14:31:27 +0530

Comments inline... 

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
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]
Subject: RE: [Sip] Re: Re-Invite before ACK

Inline. 

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

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

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

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