Re: [reSIProcate] Leaking transactions
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