Hi Rajanagam,
AS per Section: 9.2, RFC-3261,
9.2 Server Behavior
The CANCEL method requests that the TU at the server side cancel a
pending transaction. The TU determines the transaction to be
cancelled by taking the CANCEL request, and then assuming that the
request method is anything but CANCEL or ACK and applying the
transaction matching procedures of Section 17.2.3. The matching
transaction is the one to be cancelled.
The transaction matching procedure mentioned in Section 17.2.3, only uses the
sent-By and Branch Parameter in Via header.
17.2.3 Matching Requests to Server Transactions
When a request is received from the network by the server, it has to
be matched to an existing transaction. This is accomplished in the
following manner.
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.
The sent-by value is used as part of the matching process because
there could be accidental or malicious duplication of branch
parameters from different clients.
If the branch parameter in the top Via header field is not present,
or does not contain the magic cookie, the following procedures are
used. These exist to handle backwards compatibility with RFC 2543
compliant implementations.
As per above, in this scenario, CANCEL should be responded with a success
response and parameter X-example=1009 should be ignored.
Regards,
Alok Tiwari
Aricent
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, March 07, 2012 9:49 AM
To: [email protected]
Subject: [Sip-implementors] Reg via header in CANCEL request
Hello all,
A client sends an INVITE with the following top via header
"Via: SIP/2.0/UDP
10.223.96.4:5060;branch=z9hG4bKrhhclcinkkir2kgrgfrljgcjk;X-example=1009"
The client sends a CANCEL request to cancel the INVITE with the
following via header
"Via: SIP/2.0/UDP
10.223.96.4:5060;branch=z9hG4bKrhhclcinkkir2kgrgfrljgcjk"
The server replies with response 481 Call Leg/Transaction Does not
Exist. Is it right on the part of the server to reject the CANCEL.
When we read sec 9.1 of RFC 3261 in isolation the behavior of the server
seems to be right ("CANCEL constructed by a client MUST have only a
single Via header field value matching the top Via value in the request
being cancelled."). But when read along with section 9.2/17.2.3 it can
be seen that the server needs to match only the sent-by value and the
branch parameter to find the transaction to be cancelled. Any other
parameter is not required to match the transaction.
Kindly clarify whether sending of 481 by server in this case is correct
or not?
Regards,
Rajangam
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
