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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 23 Jan 2006 10:08:41 -0500

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.  

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.

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

> -----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: "Nataraju A B" <[email-masked]>
Date: Tue, 24 Jan 2006 14:01:49 +0530

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

[ABN] we can't assume implicitly, reception re-INVITE does not mean
200OK was received. 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...). 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 ?

[ABN] TRUE (this is already covered in 3261), again based on some logic
mentioned earlier (ACK_EXPECTED)

[ABN] TRUE

[ABN] TRUE

[ABN] Timer G applicable only for failure responses.. not for 2xx, so
not an issue... 

Mike

---

From: Benny Prijono <[email-masked]>
Date: Wed, 25 Jan 2006 12:19:43 +0000

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.

> as an implied ACK to the 200 OK, because otherwise the UAC would have

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

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

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. 
Thus for UAC, the only thing that works is to handle 491 (Request 
Pending) response when it arrives.

-benny