#334 Wrong comparison in B2B_Entities

[Anonymous]

Hi,
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 user@x.x.x.x and the next one is user@x.x.x.x: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 ?

RFC says:
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
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.

Sorry for my clumsy answer again,

Regards,

[Anca Vamanu]

Hi,

In fact the cancel matching section is here:

9.1 Client Behavior

A CANCEL request SHOULD NOT be sent to cancel a request other than
INVITE.

Since requests other than INVITE are responded to immediately,
sending a CANCEL for a non-INVITE request would always create a
race condition.

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.

and RURI must be matched.

Regards,
Anca