[reSIProcate] Stale Transaction States

[Teryl Taylor]

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