[reSIProcate] Duplicate transaction ids on Windows

[Robert Mansfield]

All,
 
I've read through the previous correspondance on this issue and am hoping
someone can clarify the best practice for a multithreaded application on
widows. In particular the use of the 'Random' class for generating unique
transaction ids. 
 
I'm running two windows applications on seperate hosts, one acting as a UAC,
the other a UAS. There are 60 simumtaneous dialogs being created.
 
During load testing I submit a BYE request to the stack but the stack
doesn't transmit the message to the wire, claiming the transaction id
already exists in the transaction map.
 
The application has two threads, one processing SIP messages from the stack
(g_SipStack->receive()) and the other thread sending messages to the stack
(g_SipStack->send(sipMessage). The stack object is global to both threads,
but only one thread is responsible for creating and submitting SIP requests.

 
On the UAC side I have seen a duplicate transaction ids submitted to the
TransactionManager from the application, typically a BYE is discarded
because the tid has been used for an ACK from a different dialog.
 
In the creation of both the ACK  and the BYE message the 'via' header branch
parameter is instantiated with a call to "via.param(p_branch)".
 
In this particular stack trace instance the transaction id appears to have
been added from a received response, here is a fragment from the stack
trace:
 
############################################################################
########################################
DEBUG | 20051221-152514.156 | RT-SIP-00-19-07-5.bb.cc.dd.exe | RESIP | 1940
| SipStack.cxx:375 | RECV: SipResp: 200 tid=8664a730b52dc246 cseq=INVITE
contact=RedwoodDevEngC1P18 at 10.0.0.126
<mailto:contact=RedwoodDevEngC1P18 at 10.0.0.126>  / 1 from(wire)
 
DEBUG | 20051221-152521.562 | RT-SIP-00-19-07-5.bb.cc.dd.exe | RESIP | 1196
| SipStack.cxx:269 | SEND: SipReq:  BYE RedwoodDevEngC1P21 at 10.0.0.126
<mailto:RedwoodDevEngC1P21 at 10.0.0.126>  tid=8664a730b52dc246 cseq=BYE / 2
from(tu)
 
STACK | 20051221-152522.281 | RT-SIP-00-19-07-5.bb.cc.dd.exe |
RESIP:TRANSACTION | 1940 | TransactionState.cxx:155 | Found matching
transaction for SipReq:  BYE RedwoodDevEngC1P21 at 10.0.0.126
<mailto:RedwoodDevEngC1P21 at 10.0.0.126>  tid=8664a730b52dc246 cseq=BYE / 2
from(tu) -> tid=8664a730b52dc246 [ ClientStale/Terminated unreliable
target=[ V4 0.0.0.0:0 UNKNOWN_TRANSPORT connectionId=0 ]]
STACK | 20051221-152522.281 | RT-SIP-00-19-07-5.bb.cc.dd.exe |
RESIP:TRANSACTION | 1940 | TransactionState.cxx:1151 |
TransactionState::processClientStale: SipReq:  BYE
RedwoodDevEngC1P21 at 10.0.0.126 <mailto:RedwoodDevEngC1P21 at 10.0.0.126>
tid=8664a730b52dc246 cseq=BYE / 2 from(tu)
STACK | 20051221-152522.281 | RT-SIP-00-19-07-5.bb.cc.dd.exe |
RESIP:TRANSACTION | 1940 | TransactionState.cxx:1185 | Discarding extra
response: BYE sip:RedwoodDevEngC1P21 at 10.0.0.126 SIP/2.0
 
To: <sip:P335544401223 at 10.0.0.126>;tag=3c6fe50d
 
From: <sip:DNX_TESTC2P8 at 10.0.0.212>;tag=9b540c2f
 
Via: SIP/2.0/UDP
10.0.0.212:5060;branch=z9hG4bK-d87543-8664a730b52dc246-1--d87543-;rport
 
Call-ID: 4767b466384e6543 at UmVkVk9JUA <mailto:4767b466384e6543 at UmVkVk9JUA> ..
 
CSeq: 2 BYE
 
Content-Length: 0
############################################################################
#########################################
 
So I guess I have two questions:
a) if two resiprocate applications are running back to back would a received
tid (generated remotely for dialog A) confuse the stack when submitting a
request with the same tid generated locally for dialog B (branch parameter
unique across space and time)?
b) just how random is the tid generated via the Random class. Should I
expect so many 'duplicates' after running just one iteration of the test?
 
Regards,
 
Rob Mansfield.
 
============================

Robert Mansfield

Senior Software Engineer

Redwood Technologies Limited

Tel +[44] (0)1344 304 344

Fax +[44] (0)1344 304 345

E:mail  <mailto:rjm at redwoodtech.com> mailto:rjm at redwoodtech.com

Web  <http://www.redwoodtech.com/> http://www.redwoodtech.com

============================

Email Disclaimer

The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it is prohibited and may be unlawful. When addressed to our clients any
opinions or advice contained in this email are subject to the limitations of
Redwood Technologies Limited's standard terms and conditions of contract.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051221/f4779b23/attachment.htm>