I sent this yesterday:
In function b2bl_search_iteratively, if tag and callid match, you compare ruri if it is not NULL.
But this comparison is false, if first RURI is email@example.com and the next one is firstname.lastname@example.org:5060;transport=UDP, the test is false
but RURI are the same.
I agree with your answer, but my question was clumsy;
My real question is: why do you check Request URI in this case ?
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.
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
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
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
Sorry for my clumsy answer again,