Hi Gaurav,

As you quoted as per RFC 3261 Section 9.1 refers that;

"The Request-URI, Call-ID, To, the numeric part of CSeq, and From header
   fields in the CANCEL request MUST be identical to those in the
   request being cancelled, including tags."

Now in case I quoted in my initial mail, since initial INVITE is not having
any To tag value, in result CANCEL should also not include To tag value
whereas CANCEL message shown below includes To tag. IMO, if CANCEL and
INVITE should be same, To tag should not be included in CANCEL.

Best Regards,
Vivek Batra


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Gaurav
Khare
Sent: Tuesday, January 22, 2013 10:34 AM
To: Vivek Batra; [email protected]
Subject: Re: [Sip-implementors] Canceling INVITE Transaction...

Hi Vivek,
As per RFC 3261 Section 9.1, To tag is compulsary for all the requests. See
the snippet below ....

The following procedures are used to construct a CANCEL request. The

Request-URI, Call-ID, To, the numeric part of CSeq, and From header

fields in the CANCEL request MUST be identical to those in the

request being cancelled, including tags.

....

Now as per your question, If UAS is sending 481, it means it does not have
any matching transaction i.e. it has not received INVITE or the headers in
CANCEL do not match with that of any present INVITE transactions in server.
Solution: For the first part, UAC must ensure not to send CANCEL before
receiving provisional response from UAS. For the second part, UAC must
ensure the header values to be same as described in above snippet.

Thanks and Regards
Gaurav Khare

----- Original Message -----
From: "Vivek Batra" <[email protected]>
To: <[email protected]>
Sent: Tuesday, January 22, 2013 9:37 AM
Subject: [Sip-implementors] Canceling INVITE Transaction...


> Hi folks,
>
>
>
> I am facing issue with one specific service provider where caller 
> wants to cancel the transaction and sends CANCEL message but UAS 
> responds with 481 Call Leg/Transaction Does Not Exist. I assume that 
> as per RFC 3261, CANCEL message should not contain the To tag however 
> in the below message, I can see To tag coming in CANCEL message from
service provider.
>
> Do you think UAS should ignore the To tag and complete the CANCEL 
> transaction?
>
>
>
> Best Regards,
>
> Vivek Batra
>
>
>
> Request-Line: INVITE sip:[email protected]:5060 SIP/2.0
>
> From:
> sip:[email protected]:5060;user=phone;tag=ccid-615150755-355499422
>
> Via: SIP/2.0/UDP 69.132.136.5:5060;branch=z9hG4bK-355499422-1
>
> To: sip:[email protected]:5060
>
> Call-ID: [email protected]
>
> CSeq: 1 INVITE
>
>
>
> Status-Line: SIP/2.0 180 Ringing
>
> From:
> <sip:[email protected]:5060>;tag=ccid-615150755-355499422;user=phon
> e
>
> To:
> <sip:[email protected]:5060>;tag=5ffef8-8801a8c0-13c4-50efa08
> 7-15a2
> dc08-50efa087
>
> Call-ID: [email protected]
>
> CSeq: 1 INVITE
>
> Via: SIP/2.0/UDP
> 69.132.136.5:5060;received=69.132.196.11;branch=z9hG4bK-355499422-1
>
> Contact: <sip:[email protected]:5060;transport=udp>
>
>
>
> Request-Line: CANCEL sip:[email protected]:5060 SIP/2.0
>
> Via: SIP/2.0/UDP 69.132.196.11:5060;branch=z9hG4bK-355499422-1
>
> From:
> sip:[email protected]:5060;user=phone;tag=ccid-615150755-355499422
>
> To:
> <sip:[email protected]:5060>;tag=5ffef8-8801a8c0-13c4-50efa08
> 7-15a2
> dc08-50efa087
>
> Call-ID: [email protected]
>
> CSeq: 1 CANCEL
>
> Contact: sip:69.132.196.11:5060
>
>
>
> Status-Line: SIP/2.0 481 Call Leg/Transaction Does Not Exist
>
> From:
> <sip:[email protected]:5060>;tag=ccid-615150755-355499422;user=phon
> e
>
> To:
> <sip:[email protected]:5060>;tag=5ffef8-8801a8c0-13c4-50efa08
> 7-15a2
> dc08-50efa087
>
> Call-ID: [email protected]
>
> CSeq: 1 CANCEL
>
> Via: SIP/2.0/UDP 69.132.196.11:5060;branch=z9hG4bK-355499422-1
>
>
>
>
>
> Best Regards,
>
> Vivek Batra
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>



________________________________

DISCLAIMER: The information in this message is confidential and may be
legally privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, or distribution of the message, or any
action or omission taken by you in reliance on it, is prohibited and may be
unlawful. Please immediately contact the sender if you have received this
message in error. Further, this e-mail may contain viruses and all
reasonable precaution to minimize the risk arising there from is taken by
OnMobile. OnMobile is not liable for any damage sustained by you as a result
of any virus in this e-mail. All applicable virus checks should be carried
out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to