Would the same thing be true on the server side. Namely when resip send tries to pass on a BYE to the B-side and the BSide does not reponsd.
I see that resip is re-transmitting (that’s a good thing) After the internal timeout it stops retransmitting (another good thing) however the transaction count is not decremented (isn’t this a bad thing?).
Even after 15 minutes, the statistics message displays the following:
WARNING | 20070521-043519.633 | xxxxxx | repro | RESIP:STATS | 12134 | 3054312368 | StatisticsMessage.cxx:152 | RESIP:TRANSACTION
TU summary: 0 TRANSPORT 0 TRANSACTION 0 CLIENTTX 0 SERVERTX 1 TIMERS 0
Transaction summary: reqi 1 reqo 11 rspi 0 rspo 1
Details: INVi 0/S0/F0 INVo 0/S0/F0 ACKi 0 ACKo 0 BYEi 1/S0/F0 BYEo 1/S0/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 0/S0/F0 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 10 CANx 0 MSGx 0 OPTx 0 REGx 0 finx 0 nonx 0 PUBx 0 SUBx 0 NOTx 0
What can the A Side do? Resip already sent out the OK to the A side and it has no idea that the B-side never esponded?
I agree it needs to be documented better. : )
BTW: You don’t really need to do the mMyClientInviteSessionHanlde.isValid and the isEarly check – it is OK to call AppDialogSet::end() in both cases – it will dispatch the CANCEL vs BYE appropriately.
Scott
Scott, thanks for that. I changed my UAC app to do the following as you suggested and the memory leak has gone away:
MyAppDialogSet::EndSession()
if (mMyClientInviteSessionHandle.isValid())
if (mMyClientInviteSessionHandle->isEarly())
mMyClientInviteSessionHandle->end();
I forgot to mention, previously in my leaky app (where I was calling ClientInviteSession::end() only), I was still getting the expected AppDialogSet::destroy() call back from the DUM at the end of each session. This is a bit misleading as it implied the session had successfully 'ended' which wasn't the case? This behaviour isn't at all obvious.
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin
Sent: 03 May 2007 13:46
To: Greg Inglis; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Leaking transactions
Hmm – calling ClientInviteSession::end() will cause a BYE to sent, and the original INVITE transaction should still be active, since the invite was not CANCELED. I would have thought that the transaction state would have been cleaned up after some timeout – but there may currently be a requirement for the application to cancel the transaction completely since you did receive a provisional response.
You could try switching your call to AppDialogSet()->end() or DialogUsageManager::end(), which should send a CANCEL instead to see if the problem goes away.
Scott
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