< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Leaking transactions


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

On 5/21/07, Jason Fischl <jason@xxxxxxxxxxxxxxx> wrote:
The statistics are cumulative - so it will never decrease.

On 5/21/07, Robert Sparks <rjsparks@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Scott Godin
>  Sent: Tuesday, May 08, 2007 4:36 PM
>  To: Greg Inglis; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>  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@xxxxxxxxxxxxxxxxxxxxxx]
>  Sent: Tuesday, May 08, 2007 9:31 AM
>  To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>  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@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
>
>
>
>
>
>
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Greg Inglis
>  Sent: Thursday, May 03, 2007 8:14 AM
>  To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>  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@xxxxxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxxxxx> applies to
> this email.
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>