Subject: RE: [Sipping] Is ACK needed for 2xx (INVITE) after sending

From: Jeroen Van Bemmel <[email-masked]>
Date: Fri, 20 Oct 2006 18:36:50 +0200

The ACK is needed to stop retransmissions of the INVITE 2xx (by the TU)

The other day there was a similar question about BYE stopping retransmission of INVITE or its 2xx, reasoning that it does not matter anymore. These kind of inter-transaction "optimizations" provide little benefit but much complexity (they introduce dependencies/logic). In general, the answer should be: don't do it

Regards,
Jeroen

--Oorspronkelijk bericht -----
Van: "Paul Kyzivat" <[email-masked]>
Aan: "Christer Holmberg (JO/LMF)" <[email-masked]>
CC: "Akihiro SHIMIZU" <[email-masked]>; "sipping" <[email-masked]>; "Miki Hasebe" <[email-masked]>
Verzonden: 20-10-06 15:32
Onderwerp: Re: [Sipping] Is ACK needed for 2xx (INVITE) after sending

Christer,

I think the point is that when a 200 is returned to an INVITE, that ends 
the *transaction*. In that case the ACK is a separate, though special, 
transaction. That is why there is a question about this case.

I'm not sure at this point what answer I prefer, so I'm waiting to see 
some compelling arguments one way or the other.

	Paul

Christer Holmberg (JO/LMF) wrote:
> Hi,
> 
> Yes, ACK is needed. The INVITE transaction shall complete even if you
> send a BYE, and sending ACK is part of that completion.
> 
> Regards,
> 
> Christer
>  
> 
>> -----Original Message-----
>> From: Jun KOSHIKO [mailto:[email-masked]] 
>> Sent: 20. lokakuuta 2006 9:47
>> To: sipping
>> Cc: Paul Kyzivat; Miki Hasebe; Akihiro SHIMIZU
>> Subject: [Sipping] Is ACK needed for 2xx (INVITE) after sending
>>
>> Folks,
>>
>> Is ACK for 2xx (INVITE) required in the following sequence?
>>
>>     Alice                             Bob
>>       |                                |
>>       |         ini-INVITE             |
>>       |------------------------------->|
>>       |            180                 |
>>       |<-------------------------------|
>>       |                                |
>>       |    BYE           200(INVITE)   |
>>       |-------------     --------------|
>>       |              \ /               |
>>       |               X                |
>>       |              / \               |
>>       |<------------     ------------->|
>>       |    ACK?             200(BYE)   |
>>       |-------------     --------------|
>>       |              \ /               |
>>       |               X                |
>>       |              / \               |
>>       |<------------     ------------->|
>>       |                                |
>>       |                                |
>>
>> I hope I would like to discuss
>> how the UA (Alice) should behave in this case.
>>
>> One way to understand this could be
>> that TU does not send ACK in the Terminated state because the 
>> ACK for 2xx is sent by TU, not the INVITE client transaction.
>>
>> Another might be that TU sends ACK even in the Terminated 
>> state, because it has to complete the INVITE transaction.
>>
>> According to RFC3261, either way seems to be possible.
>>
>> But, the latter option could be a bit awkward, since the TU 
>> has to control the ACK which does not relate to the 
>> transaction or the dialog.
>>
>> In writing of the race condition draft,
>> I am wondering what the best understanding of this case is.
>>
>> I appreciate comments and advice.
>>
>> Thank you.
>>
>> Jun KOSHIKO
>>
>> ---------------------------------------------------------
>> Jun KOSHIKO
>> Next Generation Strategy
>> Research and Development Center
>> NTT-east Corporation
>>
>> Telephone  +81 3 5359 5104
>> Facsimile  +81 3 5359 1236
>> E-mail: [email-masked]
>> 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
>> ---------------------------------------------------------
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP 
>> Use [email-masked] for questions on current 
>> sip Use [email-masked] for new developments of core SIP
>>
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 20 Oct 2006 13:31:07 -0400

Is there some reason this is a BYE and not a CANCEL?

Also, this seems like déjà vu.  Wasn't there an RFC covering these race conditions?

Mike

> Sent: Friday, October 20, 2006 2:47 AM
> To: sipping
> Cc: Paul Kyzivat (pkyzivat); Miki Hasebe; Akihiro SHIMIZU

---

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Thu, 26 Oct 2006 10:27:17 -0400

ACK for 200 OK is needed in case of re-Invite call flow also even if UAC
has sent BYE before getting 200 OK for Invite.
Also before the initial dialog is in confirmed state, CANCEL is sent
from UAC to terminate the session. A UAC can send BYE before initial
dialog is confirmed, but that is usually the case when the initial
Invite forks and multiple early sessions are established and UAC wants
to terminate some forked legs and not the session.

Sanjay

>Sent: Thursday, October 26, 2006 2:39 AM
>To: sipping; Robert Sparks
>Cc: Akihiro SHIMIZU; Paul Kyzivat (pkyzivat); Miki Hasebe
>Subject: [Sipping] Re: Is ACK needed for 2xx (INVITE) after sending
>
>Thank you for your comments. Sorry for the late reply.
>
>I understood that your point was that
>  "ACK to a final response to INVITE is a MUST."
>
>* If CANCEL request is successful, ACK to the final response is
>  handled by INVITE transaction.
>* If CANCEL request fails, Early-Dialogue exists in UAC,
>  and it will transition to Confirmed-Dialogue, so ACK shall be
>  transmitted.
>
>I understand that you are concerning the case in which user 
>terminal sends BYE on Early-Dialogue in spite of RFC3261's 
>recommendation.
>
>In case that 200OK to ini-INVITE is returned although UAC has 
>sent BYE, it would not send ACK because UAC has already been 
>in Mortal state, wouldn't it? And what you are concerning is 
>the point that it becomes inconsistent with the condition of 
>"ACK to a final response to INVITE is a MUST", isn't it?
>
>We are wondering whether race-example draft should cover the 
>behavior in such a case that UAC sends BYE before it receives 
>200OK to the ini-INVITE. 
>(because we think that BYE in that case is regulated under 
>RFC3261,  so that the problem in concern will not happen.)
>
>However, we might have to consider the following case.
>That is, if re-INVITE in Confirmed-Dialogue is used, the same 
>kind of sequence may happen.
>
>In case UAC sends re-INVITE and BYE nearly at the same time, 
>UAS will reply 200OK(INVITE) immediately.
>(Certainly, 200(BYE) will immediately follow.)
>
>In this case, since Dialogue in UAS becomes mortal, ACK to 
>200OK(INVITE) will not be sent by UAC.
>But, since UAS receives BYE, and the dilog transiton to 
>mortal, retransmission of 200OK from UAS will be stopped.
>Therefore, not replying an ACK doesn't occur a problem, does it?
>
>Now reconsidering the case of ini-INVITE, 200OK's 
>retransmission will not happen for the same reason, if BYE is 
>effective on UAS.
>
>Rather, proactive ACK to 200OK may cause the situation in 
>which UAS will transition to Confirmed-Dialogue and a conflict 
>of dialog state between UAC and UAS may happen.
>Therefore, I think that you should not adhere to the principle that
>  "ACK is a MUST to complete the INVITE transaction"
>  "ACK to a final response to INVITE is a MUST."
>in this case.
>
>What do you think about that?
>I hope I would like to have your opinions and thoughts.
>
>Thank you.
>
>Jun KOSHIKO
>
>> This ACK is still required.
>> The TU will continue to retransmit the 200-INVITE until it sees the 
>> ack or it runs its timers to exhaustion. The BYE will have no effect 
>> on that behavior.
>> 
>> RjS
>> 
>> On Oct 20, 2006, at 2:47 AM, Jun KOSHIKO wrote:
>> 
>> > Folks,
>> >
>> > that TU does not send ACK in the Terminated state because the ACK 
>> > for 2xx is sent by TU, not the INVITE client transaction.
>> >
>> > Another might be that TU sends ACK even in the Terminated state, 
>> > because it has to complete the INVITE transaction.
>> >
>> > But, the latter option could be a bit awkward, since the TU has to 
>> > control the ACK which does not relate to the transaction or the 
>> > dialog.
>> >
>> > In writing of the race condition draft, I am wondering 
>what the best 
>> > understanding of this case is.
>> >
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip