Yes, this is a bug in resiprocate, and a bug in rfc 3261. Same thing happens for UAS INVITE transaction.
----- Original Message ----
From: Greg Inglis <
Greg.Inglis@xxxxxxxxxxxxxxxxxxxxxx>
To:
resiprocate-devel@xxxxxxxxxxxxxxxxxxxxSent: Thursday, May 3, 2007 6:13:47 AM
Subject: [reSIProcate] Leaking transactions
Hi there,
I am getting a memory leak in my application when I end my UAC session while the session is in a 'UAC_Early' state
i.e. I've got a '180 Ringing' from the remote UAS endpoint but I haven't received a '200 OK' as yet.
I'm getting the following statistics message from the stack afterwards:
TU summary: 0 TRANSPORT 0 TRANSACTION 0 CLIENTTX 1 SERVERTX 0 TIMERS 0
Transaction summary: reqi 0 reqo 6 rspi 8 rspo 0
Details: INVi 0/S0/F0 INVo 2/S0/F1 ACKi 0 ACKo 1 BYEi 0/S0/F0 BYEo 1/S1/F0 CANi 0/S0/F0 CANo 0/S0/F0 MSGi 0/S0/F0 MSGo 0/S0/F0 OPTi 0/S0/F0 OPTo 0/S0/F0 REGi 0/S0/F0 REGo 2/S1/F1 PUBi 0/S0/F0 PUBo 0/S0/F0 SUBi 0/S0/F0 SUBo 0/S0/F0 NOTi 0/S0/F0 NOTo 0/S0/F0
Retransmissions: INVx 0 BYEx 0 CANx 0 MSGx 0 OPTx 0 REGx 0 finx 0 nonx 0 PUBx 0 SUBx 0 NOTx 0
The 'CLIENTTX 1' in the TU summary doesn't go away no matter how long I wait - I assume this means a transaction has leaked somehow?
I am ending the session by calling ClientInviteSession::end() and subsequently calling process() on the stack and DUM - is there some step I am missing here?
I'm using reSiprocate 1.1 built on VC8 SP1 and my SIP proxy is asterisk.
Any help would be appreciated