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.