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

[Alan Hawrylyshen]

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