| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
I’m afraid they’re
both running in a single thread, well to be completely correct my application runs
several threads but it’s only dealing with creating requests in the main
thread. From what I understand from the resiprocate code the branch-parameter
is created by the call to makeReqeustInternal() when I call makeAck(). So the
tid-part of the branch is final after this call? I’ve had a look
through the posting archives but I found nothing of interest. Från: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] Perhaps your app is
generating random numbers from multiple threads and your test program
isn’t. From:
Thanks for the reply! I’ll have a look at
the archives! I’ve broken out the
code generating the branch and run a couple of million tests without running
into a double. In our application this happens after ~100 dialogs. So I’m
kind of confused here. /kj Från: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] Hi Krister, Sorry for the lack
of responses – I’ve never seen this behavior, but there was some
discussion about random number generation on some platforms a few months
back. You may want to try a search through the posting archives and see
if anything rings a bell: http://www.resiprocate.org/Searching_the_Mailing_Lists Scott From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Hello again! I still haven’t
received any response to this so I’m rephrasing myself: Has anybody else experienced
that reciprocate generates the same branch for different requests in different
dialogs? Is it known to happen? If anybody would have the
time to look at this I would much appreciate it! /kj Från: Hi! We’re experiencing some problems with
resiprocate-1.2. The scenario is described below: Our implementation sends an INVITE which is answered
with 100 Trying. After this we receive a 200 ok to another INVITE sent to
another destination. We respond to this by calling createDialogAsUAC() and then
makeAck(). This works fine in most cases (99%) but sometimes the ACK gets the
same tid as the first INVITE. This results in an incorrect state and we get an
assert at line 253 in TransactionState.cxx. Any ideas on what might be wrong? Please find the logs attached. Thanks! /kj |