Re: [reSIProcate] Mapping SipMessage to TransactionState
Hello,
Thanks for the explanation. On further testing, I find that under a load
test, I always end up with a scenario when the transaction id is
repeated. An example: A SUBSCRIBE was sent, it was assigned a
transaction id (getRandomHex()), and stored in transaction map. While we
are still waiting for the response for this (after about 12 seconds),
another message, (say INVITE) gets allocated the same transaction id as
the earlier SUBSCRIBE causing all sorts of asserts.
So I am seeing strong evidence that the getRandomHex() is not returning
"unique" values, which is against the intended behavior as per my
understanding of the stuff. It always seems to happen under load test.
Before I dig more into it, I would like to ask if anyone has seen this
sort of issue. Anything I could be missing at the application layer? I
am not using DUM, using version of resiprocate from April. I am calling
reset() on the branch parameter on the Via header of all my messages.
Any help is appreciated.
Thanks
Sandeep
On Mon, 2005-09-12 at 10:43 -0700, Jason Fischl wrote:
> 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.
--
Sandeep Sharma <ssharma@xxxxxxxxxx>