[reSIProcate] Leaking transactions

Mon May 21 11:18:13 CDT 2007

Actually, I think I'm wrong about that. Sorry, just got up :)

On 5/21/07, Jason Fischl <jason at counterpath.com> wrote:
> The statistics are cumulative - so it will never decrease.
>
> On 5/21/07, Robert Sparks <rjsparks at nostrum.com> wrote:
> > 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
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.resiprocate.org
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
>