[SIPForum-discussion] Why ACK is separate transaction for INVITE

[Ravikannan Alagarsamy]

Yes, it wont change the Cseq, it will chnage the branch parameters.

Thanks
Ravi

On Thu, Jun 23, 2011 at 1:00 PM, Perttu Ahvenainen <
mosseahvenainen at gmail.com> wrote:

> Hello all,
>
> Founfd from RFC following statement about this:
>
> *17 Transactions
>
>    SIP is a transactional protocol: interactions between components take
>    place in a series of independent message exchanges.  Specifically, a
>    SIP transaction consists of a single request and any responses to
>    that request, which include zero or more provisional responses and
>    one or more final responses.  In the case of a transaction where the
>    request was an INVITE (known as an INVITE transaction), the
>    transaction also includes the ACK only if the final response was not
>    a 2xx response.  If the response was a 2xx, the ACK is not considered
>    part of the transaction.
>
>       The reason for this separation is rooted in the importance of
>       delivering all 200 (OK) responses to an INVITE to the UAC.  To
>       deliver them all to the UAC, the UAS alone takes responsibility
>       for retransmitting them (see Section 13.3.1.4), and the UAC alone
>       takes responsibility for acknowledging them with ACK (see Section
>       13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is
>       effectively considered its own transaction.*
>
> -Perttu Ahvenainen
>
>
> 2011/6/22 Ravikannan Alagarsamy <ravikannanbe at gmail.com>
>
>> Hi,
>>
>> Hope you know that for every new transaction Cseq should increment if it
>> is not increment means that should be same transaction(non-successful call).
>>
>> So as per 3-way handshake policy once it gets 200ok response it sent ACK
>> with increment Cseq id and it is separate transaction. if it is not
>> incremented means the call is not successful we are sending ACK for some
>> error message.
>>
>> Thanks
>> Ravi
>>
>> On Tue, Jun 21, 2011 at 4:12 PM, Retesh <retesh.chadha at gmail.com> wrote:
>>
>>> Hi
>>>
>>> I think 1 of the reason is that ACK for 2xx can take a different network
>>> path then INVITE or 2xx messages based on the contact and route set received
>>> in 2xx and so it needs to be a separate transaction (different Via header
>>> and branch parameters), which is not the case with ACK for non-2xx final
>>> response.
>>>
>>> Hope this helps.
>>>
>>> Regards
>>> Retesh
>>>
>>> _______________________________________________
>>> This is the SIP Forum discussion mailing list
>>> TO UNSUBSCRIBE, or edit your delivery options, please visit
>>> http://sipforum.org/mailman/listinfo/discussion
>>> Post to the list at discussion at sipforum.org
>>>
>>>
>>
>> _______________________________________________
>> This is the SIP Forum discussion mailing list
>> TO UNSUBSCRIBE, or edit your delivery options, please visit
>> http://sipforum.org/mailman/listinfo/discussion
>> Post to the list at discussion at sipforum.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20110623/1eec4342/attachment.html