> Kindly clarify whether sending of 481 by server in this
> case is correct or not?
It mostly depends upon how forgiving you are willing to be when a vendor builds
a non compliant CANCEL.
If the UAS follows RFC 3261 section 17.2.3's transaction matching rules, the
CANCEL's Call-ID, CSeq, To, From, and Via can all be incorrect as long as the
Via's sent-by and magic cookie branch match the INVITE. Thus if you want to be
that flexible, do so. If you think accommodating such non compliant devices is
a ridicules interoperability nightmare, don't be that flexible. Concerning the
specific question, the matching rules depend upon if the magic cookie is
present. Concerning Via matching, I recommend being as strict or lenient as
you'd be if the magic cookie was not present; for interoperability reasons, I
recommend being lenient instead of returning 481.
RFC 3261 section 9.1:
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).
RFC 3261 section 9.2:
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.
RFC 3261 17.2.3:
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.
The INVITE request matches a transaction if the Request-URI, To tag,
From tag, Call-ID, CSeq, and top Via header field match those of the
INVITE request which created the transaction. In this case, the
INVITE is a retransmission of the original one that created the
transaction. The ACK request matches a transaction if the Request-
URI, From tag, Call-ID, CSeq number (not the method), and top Via
header field match those of the INVITE request which created the
transaction, and the To tag of the ACK matches the To tag of the
response sent by the server transaction. Matching is done based on
the matching rules defined for each of those header fields.
Inclusion of the tag in the To header field in the ACK matching
process helps disambiguate ACK for 2xx from ACK for other responses
at a proxy, which may have forwarded both responses (This can occur
in unusual conditions. Specifically, when a proxy forked a request,
and then crashes, the responses may be delivered to another proxy,
which might end up forwarding multiple responses upstream). An ACK
request that matches an INVITE transaction matched by a previous ACK
is considered a retransmission of that previous ACK.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
