Subject: [Sip] branch parameter in CANCEL

From: murali foru <[email-masked]>
Date: Sun, 28 Nov 2004 20:31:56 -0800 (PST)

Hi, 

I wanted some clarification on the branch parameter in CANCEL. From what I Understand the branch parameter should be the same in the INVITE and the CANCEL(especially when using the magic cookie) so as to match the transaction being cancelled. 

>From RFC 3261 

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. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). 

The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if: 

1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 
2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 
3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. 

This matching rule applies to both INVITE and non-INVITE transactions alike. 

I would like to know if this is a correct CANCEL for the INVITE sent 

INVITE sip:[email-masked] SIP/2.0 
Max-Forwards: 10 
Record-Route: <sip:[email-masked];ftag=001201544d1a001b1f8360ea-1cbce160;lr=on> 
Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.484c8882.0 
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK39e838b9 
From: "55" <sip:[email-masked]>;tag=001201544d1a001b1f8360ea-1cbce160 
To: <sip:[email-masked]> 
Call-ID: [email-masked] 
CSeq: 101 INVITE 
User-Agent: CSCO/6 
Contact: <sip:[email-masked]:5060> 
Expires: 180 
Content-Type: application/sdp 
Content-Length: 247 
Accept: application/sdp 

v=0 
o=Cisco-SIPUA 14494 13084 IN IP4 172.20.22.75 
s=SIP Call 
c=IN IP4 172.20.22.75 
t=0 0 
m=audio 18990 RTP/AVP 0 8 18 101 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:18 G729/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-15 

SIP/2.0 180 Ringing 
Via: SIP/2.0/UDP 172.20.22.102;branch= z9hG4bK6ee8.484c8882.0, SIP/2.0/UDP 172.20.22.75:5060;branch= z9hG4bK39e838b9 
Record-Route: <sip:[email-masked];ftag=001201544d1a001b1f8360ea-1cbce160;lr=on> 
To: <sip:[email-masked]>; tag= 3e7ca296 
From: "55" <sip:[email-masked]>; tag= 001201544d1a001b1f8360ea-1cbce160 
Call-ID: [email-masked] 
CSeq: 101 INVITE 
Contact: <sip:[email-masked];transport=UDP> 
Content-Length: 0 

CANCEL sip:[email-masked] SIP/2.0 
Max-Forwards: 10 
Record-Route: <sip:[email-masked];ftag=001201544d1a001b1f8360ea-1cbce160;lr=on> 
Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.584c8882.0 
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK6a729507 
From: "55" <sip:[email-masked]>;tag=001201544d1a001b1f8360ea-1cbce160 
To: <sip:[email-masked]> 
Call-ID: [email-masked] 
CSeq: 101 CANCEL 
User-Agent: CSCO/6 
Content-Length: 0 

In the above case the branch parameter matching fails. 

Regards, 
Murali

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: "Ben Gatewood" <[email-masked]>
Date: Mon, 29 Nov 2004 08:43:30 -0000

Murali,

You are correct in your interpretation. The branch parameter for a
CANCEL does need to be the same as the request it is canceling. In fact,
it appears you are using a particular version of Cisco SIP firmware that
has already been the subject of a TAC case I logged for exactly this
problem.

I suggest that if you upgrade the firmware on that phone the issue will
be resolved.

Also, this type of post probably belongs on SIP-IMPLEMENTORS rather than
the IETF list.

HTH,

B

Ben Gatewood

Lead Architect - IP Telephony

Streamdoor Ltd.

114b Power Rd

London 

W4 5PY

+44 20 7422 0439

+44 7835 136 187

[email-masked]

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
murali foru
Sent: 29 November 2004 04:32
To: [email-masked]
Subject: [Sip] branch parameter in CANCEL

Hi, 

I wanted some clarification on the branch parameter in CANCEL. From what
I Understand the branch parameter should be the same in the INVITE and
the CANCEL(especially when using the magic cookie) so as to match the
transaction being cancelled. 

>From RFC 3261 

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. A CANCEL constructed by a client MUST
have only a single Via header field value matching the top Via value in
the request being cancelled. Using the same values for these header
fields allows the CANCEL to be matched with the request it cancels
(Section 9.2 indicates how such matching occurs). However, the method
part of the CSeq header field MUST have a value of CANCEL. This allows
it to be identified and processed as a transaction! in its own right
(See Section 17). 

The branch parameter in the topmost Via header field of the request is
examined. If it is present and begins with the magic cookie "z9hG4bK",
the request was generated by a client transaction compliant to this
specification. Therefore, the branch parameter will be unique across all
transactions sent by that client. The request matches a transaction if: 

1. the branch parameter in the request is equal to the one in the top
Via header field of the request that created the transaction, and 
2. the sent-by value in the top Via of the request is equal to the one
in the request that created the transaction, and 
3. the method of the request matches the one that created the
transaction, except for ACK, where the method of the request that
created the transaction is INVITE. 

This matching rule applies to both INVITE and non-INVITE transactions
alike. 

I would like to know if this is a correct CA! NCEL for the INVITE sent 

Record-Route:
<sip:[email-masked];ftag=001201544d1a001b1f8360ea-1cbce160;lr=on> 

v=0 

SIP/2.! 0 180 Ringing 
Via: SIP/2.0/UDP 172.20.22.102;branch= z9hG4bK6ee8.484c8882.0,
SIP/2.0/UDP 172.20.22.75:5060;branch= z9hG4bK39e838b9 
Record-Route:
<sip:[email-masked];ftag=001201544d1a001b1f8360ea-1cbce160;lr=on> 
To: <sip:[email-masked]>; tag= 3e7ca296 
From: "55" <sip:[email-masked]>; tag=
001201544d1a001b1f8360ea-1cbce160 
Call-ID: [email-masked] 
CSeq: 101 INVITE 
Contact: <sip:[email-masked];transport=UDP> 
Content-Length: 0 

CANCEL sip:[email-masked] SIP/2.0 
Max-Forwards: 10 
Record-Route:
<sip:[email-masked];ftag=001201544d1a001b1f8360ea-1cbce160;lr=on> 
Via: SIP/2.0/UDP 172.20.22.102;branch=z9hG4bK6ee8.584c8882.0 
Via: SIP/2.0/UDP 172.20.22.75:5060;branch=z9hG4bK6a729507 
From: "55" <sip:[email-masked]>;tag=001201544d1a001b1f8360ea-1cbce160 
To: <sip:[email-masked]> 
Call-ID: [email-masked].! 22.75 
CSeq: 101 CANCEL 
User-Agent: CSCO/6 
Content-Length: 0 

Regards, 
Murali

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com
************************************************************************
************** Disclaimer: This electronic message may contain
privileged or confidential information. If you are not the intended
recipient, be advised that any disclosure, copying, distribution or use
of this information is strictly prohibited. If you are not the intended
recipient, please notify the sender and delete this message. Views
expressed in this message are those of the individual sender, and are
not necessarily the views of the Streamdoor Limited, unless otherwise
stated. Although Streamdoor Limited has taken reasonable precautions to
ensure no viruses are present in this email, the company cannot accept
responsibility for any loss or damage arising from the use of this email
or attachement Employees of Streamdoor Limited and its affiliates are
expressly required not to make defamatory statements and not to infringe
or authorise any infringements of copyrights or any other legal right by
email communications. Any such communication is contrary to company
policy and outside the scope of the employment of the individual
concerned. For further assistance on email policy, or if you have
received this email in error, please contact Streamdoor Group IT&C
Helpdesk by email at [email-masked] or write to Streamdoor
Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4
5PY. www.streamdoor.com
************************************************************************
************** 

**************************************************************************************
Disclaimer:

This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement

Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this email in error, please contact  Streamdoor Group IT&C Helpdesk by email at [email-masked] or write to  Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com
**************************************************************************************