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

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Fri, 20 Oct 2006 09:46:21 -0400

I do not think 200 OK to INVITE ends the transaction, ACK is needed to
complete it. If ACK was not needed to complete it, then UAS would not
keep retransmitting the 200 OK.

Sanjay

>-----Original Message-----
>From: Paul Kyzivat (pkyzivat) 
>Sent: Friday, October 20, 2006 9:32 AM
>To: Christer Holmberg (JO/LMF)
>Cc: Akihiro SHIMIZU; sipping; Miki Hasebe
>Subject: 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: Benny Prijono <[email-masked]>
Date: Fri, 20 Oct 2006 15:07:25 +0100

I also tend to agree with this. IMO the reason why RFC 3261 says to 
terminate and destroy the UAS transaction upon sending 2xx response is 
to make the transaction layer "generic" for both User Agent and Proxy 
use. But for UA, although the transaction *object* itself has been 
destroyed, I would argue that the transaction "concept" is still there, 
thus it needs to be terminated with ACK.

In my UA implementation, actually I let the UAS INVITE transaction runs 
even after 2xx is sent, until ACK is received by TU. This way I save 
myself from having to implement retransmission logic in the TU.

-benny

-- 
Benny Prijono
http://www.pjsip.org