[reSIProcate] Leaking transactions
Robert Sparks
rjsparks at nostrum.com
Mon May 21 09:40:51 CDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070521/5da18596/attachment.htm>
More information about the resiprocate-devel
mailing list