| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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 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@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx]
On Behalf Of Robert Sparks 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 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]
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 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 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 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 For
Technical Support / Fault Logging please use support@xxxxxxxxxxxxxxxxxxxxxx
Emails
to my personal address will not be managed in my absence. 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: _______________________________________________ resiprocate-devel mailing list _______________________________________________ resiprocate-devel mailing list |