[SIPForum-discussion] Why CANCEL cannot be in Same trasaction like ACK for Non 2xx response

[Abhisek Acharya]

Hi Folks,

We had discussed a lot about the CANCEL transaction.What I believe RFC
mentions this as a different transaction even if there is always a touch n
go logic against this.
So shall we agree to the line mentioned in the RFC or can we get some reply
from the official person from IETF.

But I believe there should not be any problem of any kind in the call
processing due to this.

I believe we all need a bit of official clarity on this part.

Regards
Abhisek Acharya

On Sat, Jan 12, 2013 at 3:44 AM, Gottfried, Hal F <hal.gottfried at verizon.com
> wrote:

> I believe that he was speaking of this section ::****
>
> ** **
>
>    The layer above the transaction layer is called the transaction user***
> *
>
>    (TU).  Each of the SIP entities, except the stateless proxy, is a****
>
>    transaction user.  When a TU wishes to send a request, it creates a****
>
>    client transaction instance and passes it the request along with the***
> *
>
>    destination IP address, port, and transport to which to send the****
>
>    request.  A TU that creates a client transaction can also cancel it.***
> *
>
>    When a client cancels a transaction, it requests that the server stop**
> **
>
>    further processing, revert to the state that existed before the****
>
>    transaction was initiated, and generate a specific error response to***
> *
>
>    that transaction.  This is done with a CANCEL request, which****
>
>    constitutes its own transaction, but references the transaction to be**
> **
>
>    cancelled (Section 9).****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *Hal *****
>
> ** **
>
> ** **
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *Abhisek Acharya
> *Sent:* Friday, January 11, 2013 2:09 AM
> *To:* Vijay Kumar
> *Cc:* discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] Why CANCEL cannot be in Same
> trasaction like ACK for Non 2xx response****
>
> ** **
>
> Vijay,****
>
> ** **
>
> We identify transactions from branch-ids and CANCEL also has the same
> branch id as INVITE ...So theoretically it should be part of the INVITE
> transactions.****
>
> Please correct me if I am wrong.Also i want to see the segment where it
> says that CANCEL is a different transaction in RFC 3261.Please let me know
> the excat segment.****
>
> ** **
>
> Abhisek Acharya****
>
> ** **
>
> On Thu, Jan 10, 2013 at 11:51 PM, Vijay Kumar <vj.tech776 at gmail.com>
> wrote:****
>
> Hi all****
>
> Can any one throw light on this please.****
>
> ** **
>
> Agreed that as per 3261 INVITE and ACK for 2xx response are in
> different transaction ****
>
> Agreed that ACK for NON 2xx response and INVITE are in same transaction***
> *
>
> ** **
>
> Same Via branch as INVITE,Same Cseq(Only Numeric part Cseq=1 ACK)  in ACK
> for NON 2xx response .(Hence ACK is for Non 2xx reponse if in same
> transaction as of INVITE)****
>
> ** **
>
> BUT ****
>
> Why not CANCEL be in same transaction as INVITE because of ****
>
> Same Via branch,Same Cseq(Only Numeric part like Cseq= 1 CANCEL)****
>
> ** **
>
> (Agreed RFC 3261 says CANCEL and INVITE are different transactions)****
>
> Thanks in advance****
>
> Vijay****
>
>
> _______________________________________________
> 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/20130114/16a85789/attachment-0002.html>