[reSIProcate] Leaking transactions
Byron Campen
bcampen at estacado.net
Fri May 25 08:53:13 CDT 2007
Ok, I'll give this a look. I have a theory of what's going on.
Best regards,
Byron Campen
> Thanks, and yes this is happening in repro. For comparison, I’ve
> attached two logs, one when the callee returns an OK and the other
> when the callee does not.
>
>
>
> In both cases the caller is sending a single BYE.
>
>
>
> BR,
>
> Jay Denkberg
>
>
>
> From: Byron Campen [mailto:bcampen at estacado.net]
> Sent: Thursday, May 24, 2007 8:39 PM
> To: Jay Denkberg
> Cc: Robert Sparks; resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] Leaking transactions
>
>
>
> It is up to the proxy to make this happen. When
> processClientNonInvite() is called, this will cause a 408 to be
> sent up to the TU (transaction user, in this case the proxy). When
> the proxy gets this 408, it should be turning around and forwarding
> it back down to the stack on the server transaction. This will
> cause the server transaction to be cleaned up. (Keep in mind; when
> a request comes up to the TU from the stack, the stack will not
> clean up until the TU gives it a response to the request.
> Forwarding the 408 accomplishes this.)
>
>
>
> I should ask, is this happening with repro? If so,
> there is a bug in repro, and I would like to see a trace.
>
>
>
> Best regards,
>
> Byron Campen
>
>
> I noticed that when the callee responds both processServerNonInvite
> () and processClientNonInvite() are called with causes the
> transaction count go to 0 and therefore it is freed.
>
>
>
> However when the callee does not respond with a 200OK
> processClientNonInvite() is eventually called after all the
> retransmits have been exhausted but processServerNonInvite() is
> never called so the transaction count never reaches 0 and is never
> released.
>
>
>
> I also see that when the OK is received both TimerK (client) and
> TimerJ (server) are invoked. However when no OK is ever received
> neither timers are set up. I’m thinking (but I’m not at all sure)
> that if Timer J would be added when the retransmits are exhausted
> then the server side would also release decrement the transaction
> count and the memory would be released.
>
>
>
> Is this analysis correct? What is the correct way to decrement the
> transaction count a second time, when the retransmits have been
> exhausted?
>
>
>
> Thx,
>
> Jay
>
>
>
> From: Brocha Strous
> Sent: Monday, May 21, 2007 8:49 PM
> To: Robert Sparks; Byron Campen
> Cc: resiprocate-devel at list.resiprocate.org; Jay Denkberg
> Subject: RE: [reSIProcate] Leaking transactions
>
>
>
> Byron+Robert,
>
> The situation Jay is describing involves repro functioning as a
> proxy. The caller sends a BYE which repro responds to with 200OK
> and then forwards to the callee. The callee happens to not respond.
> Repro keeps retransmitting for a while then stops but the server-
> side transaction is not cleaned up. (And after many of these the
> memory is also growing). (We are not using DUM).
>
>
>
> Thanks,
>
> Brocha
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf
> Of Robert Sparks
> Sent: Monday, May 21, 2007 5:41 PM
> To: Byron Campen
> Cc: resiprocate-devel at list.resiprocate.org; Jay Denkberg
> Subject: Re: [reSIProcate] Leaking transactions
>
>
>
> To push Byron's point a little further -
>
>
>
> Your text talks about a client transaction (sending the BYE and
> watching it being retransmitted).
>
>
>
> The log you point to is talking about a server transaction.
>
>
>
> Are you running the A-side and B-side (as you called them) in the
> same instance of resip? If so,
>
> the statistic you highlight is due to the B-side BYE handler not
> handing a response back to the stack.
>
>
>
> RjS
>
>
>
>
>
> On May 21, 2007, at 8:36 AM, Byron Campen wrote:
>
>
>
> 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
>
>
>
> _______________________________________________
>
> resiprocate-devel mailing list
>
> resiprocate-devel at list.resiprocate.org
>
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
>
>
>
>
>
>
> <BYE_NO_OK.txt>
> <BYE_WITH_OK.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070525/88abc5ba/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/20070525/88abc5ba/attachment.bin>
More information about the resiprocate-devel
mailing list