Re: [reSIProcate] Load testing issue with RESIP. Any comments ?

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

On 17-Sep-05, at 05:57 , Asheesh Joshi wrote:

> You did mention branch ids being different.  I tried that and it  
> solves the
> problem.  However I am wondering why has branch id gotta be  
> different in
> next cycle of hundred calls ?.  The tool currently sends out same  
> branch id
> for same user in every cycle. Eg. Ie. every INVITE sent from nth  
> user  will
> have the same branch id in every cycle after Y seconds.

Not to put to fine a point on it, but reusing branch parameters is a  
no-no if you are complying with RFC 3261.

From RFC 3261, section 8(.1.1.7):


8.1.1.7 Via

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

   The branch parameter value MUST be unique across space and time for
   all requests sent by the UA.  The exceptions to this rule are CANCEL
   and ACK for non-2xx responses.  As discussed below, a CANCEL request
   will have the same value of the branch parameter as the request it
   cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx
   response will also have the same branch ID as the INVITE whose
   response it acknowledges.

      The uniqueness property of the branch ID parameter, to facilitate
      its use as a transaction ID, was not part of RFC 2543.

   The branch ID inserted by an element compliant with this
   specification MUST always begin with the characters "z9hG4bK".   
These
   7 characters are used as a magic cookie (7 is deemed sufficient to
   ensure that an older RFC 2543 implementation would not pick such a
   value), so that servers receiving the request can determine that the
   branch ID was constructed in the fashion described by this
   specification (that is, globally unique).  Beyond this requirement,
   the precise format of the branch token is implementation-defined.


Thus, as an optimization for the transaction layer of the SIP stack,  
we can use the branch parameter as a 'transaction identifier'.  
RFC3261 stacks take full advantage of this so they do not have to  
compute a transaction id synthetically from the message contents.   
The specification effectively says:

    The branch parameter is unique for all requests in space and time.

If you do not adhere to this, very strange bugs will appear in your  
server and/or clients. Imagine if your client chose a unique sequence  
of tids that never repeated, however, all copies of your client would  
use the same sequence. You could not successfully have them  
communicate with the same server since the server would see multiple  
copies of the same transaction.

It is a REALLY, REALLY good idea to make your branch parameters as  
unique as possible (in a global sense).


Section 17.2.3 has the logic for server side matching and also  
mentions the importance of uniqueness and how to leverage it in the  
server-side.  It is widely regarded by the SIP implementation  
community that globally unique is strongly preferred to " unique  
across all transactions sent by that client", for the reasons  
mentioned above (multiple copies of the same client connecting to a  
single device acting as UAS).

Hope this helps,

Alan Hawrylyshen
reSIProcate Project Administrator
http://sipfoundry.org/reSIProcate/
a l a n a t j a s o m i d o t c o m