| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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: |