< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Mapping SipMessage to TransactionState


On 9/12/05, Sandeep Sharma <ssharma@xxxxxxxxxx> wrote:
> Hi,
> 
> I am trying to understand some of ther inner workings of the stack..
> Especially the mapping of a SipMessage to a TransactionState.
> SipMessage::getTransactionId() is used to see if an existing
> TransactionState exists fot this tid. Looking at
> SipMessage::getTransactionId(), it just looks up the transactionId on
> the BranchParameter on the Via header.
> 
> As per a suggestion earlier, I am now calling
> msg.header(h_Vias).front().param(p_branch).reset();
> for each SUBSCRIBE.
> 
> My question is: I expected transactionId to be a function of some of the
> headers in the message (like cseq, callid etc), but from the following
> code, it looks like it is a random number.
> 
> Can someone explain please?

Take a look at rfc 3261 (section 8.1.1.7)


   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.

and from section 28.1

   o  The branch parameter of the Via header field value is now
      mandatory for all elements to use.  It now plays the role of a
      unique transaction identifier.  This avoids the complex and bug-
      laden transaction identification rules from RFC 2543.  A magic
      cookie is used in the parameter value to determine if the previous
      hop has made the parameter globally unique, and comparison falls
      back to the old rules when it is not present.  Thus,
      interoperability is assured.