[OpenSIPS-Devel] [ opensips-Bugs-3139055 ] Wrong comparison in B2B_Entities

SourceForge.net noreply at sourceforge.net
Fri Dec 17 13:24:24 CET 2010


Bugs item #3139055, was opened at 2010-12-17 12:24
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3139055&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong comparison in B2B_Entities

Initial Comment:
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 at x.x.x.x and the next one is user at 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,

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3139055&group_id=232389



More information about the Devel mailing list