[reSIProcate] Stale Transaction States
Hi everyone,
I'm having a small issue which relates to Server Transactions becoming
stale. I'm using resiprocate in a telephony gateway scenario. My
application takes invites from Call Manager and sends out invites to create
transfers and then the app listens for BYE's before tearing down a call.
The problem is that sometimes (on certain calls) resiprocate seems to ignore
the BYE's it receives and not pass them up to the application. Looking in
the resip logs, I get the following error on these calls:
DEBUG | 20060427-121645.859 | Application | RESIP:TRANSPORT | 6540 |
Transport.cxx:209 | incoming from: [ V4 180.201.200.1:5060 UDP received on:
Transport: [ V4 0.0.0.0:5060 UDP connectionId=0 ] connectionId=0 ]
ERR | 20060427-121645.859 | Application | RESIP:TRANSACTION | 6540 |
TransactionState.cxx:1252 | ServerStale unexpected condition, dropping
message.
ERR | 20060427-121645.859 | Application | RESIP:TRANSACTION | 6540 |
TransactionState.cxx:1255 | SipReq: BYE 180.201.200.4:5060 tid=18f031e
cseq=BYE / 102 from(wire)
It seems that the transaction becomes stale and the BYE's are therefore
disregarded. It happens very rarely, but most often when the application is
under a higher call volume (10+ simultaneous calls). Does anyone know what
causes a Transaction State to become stale? And what can be done to prevent
it from happening? I'm fairly new to SIP and I have been looking through
the RFC but I can't find much on Stale transactions. Note, that in the
scenario where a call successfully terminates with a BYE and the scenario
where the BYE is lost, the SIP messaging seems to be in the same order and
no messages are lost. This leads me to believe it could be a timing issue.
Thanks for any insights you can provide,
Take Care,
Teryl