[reSIProcate] Leaking transactions
Byron Campen
bcampen at estacado.net
Mon May 21 08:36:24 CDT 2007
For server transactions, the TU is responsible for sending a
response to the stack no matter what. Failure to do so will cause
that transaction to hang around indefinitely. The stack ensures that
the request is well-formed enough to at least forge a failure
response before passing the request to the TU, meaning that it is
possible to give some sort of response to everything that is passed up.
This is, as far as I can tell, the number one cause of leaks in
resip-based applications.
Best regards,
Byron Campen
> 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?
>
>
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf
> Of Scott Godin
> Sent: Tuesday, May 08, 2007 4:36 PM
> To: Greg Inglis; resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] Leaking transactions
>
>
>
> 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
>
>
>
> From: Greg Inglis [mailto:Greg.Inglis at TelephoneticsVIP.co.uk]
> Sent: Tuesday, May 08, 2007 9:31 AM
> To: Scott Godin; resiprocate-devel at list.resiprocate.org
> Subject: RE: [reSIProcate] Leaking transactions
>
>
>
> 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())
>
> {
>
> // send CANCEL
>
> AppDialogSet::end();
>
> }
>
> else
>
> {
>
> // send BYE
>
> 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.
>
>
>
> Thanks for your help
>
>
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf
> Of Scott Godin
> Sent: 03 May 2007 13:46
> To: Greg Inglis; resiprocate-devel at list.resiprocate.org
> 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
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf
> Of Greg Inglis
> Sent: Thursday, May 03, 2007 8:14 AM
> To: resiprocate-devel at list.resiprocate.org
> 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
>
>
>
> Greg Inglis
> Software Engineer
>
> Telephonetics VIP Ltd
> "making sound
> business sense"
>
> Simply dial +44 (0) 1442 242 242 and ask for me by name.
> For Technical Support / Fault Logging please use
> support at telephoneticsvip.co.uk
>
> Emails to my personal address will not be managed in my absence.
>
> www.telephoneticsVIP.co.uk
>
> Providing innovative hosted and customer premises speech
> recognition and voice automation solutions.
>
> Winner of the National Business Awards (SE Region) Business
> Innovation of the Year 2004 & 2005 and Dacorum Business Of The Year
> Award 2003 & 2006.
>
> Disclaimer:
> The disclaimer available at http://www.telephoneticsVIP.co.uk/
> telephonetics/emaildisclaimer.jsp or by sending email to
> <mailto:email-disclaimer at telephoneticsVIP.co.uk> applies to this
> email.
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070521/ef1ee9fc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070521/ef1ee9fc/attachment.bin>
More information about the resiprocate-devel
mailing list