[reSIProcate] Leaking transactions

Thu May 3 13:39:42 CDT 2007

I do not want to repeat the beat-to-death argument again, at least resiprcoate should document it in the code or somewhere, :).

For sake of perfection,

kaiduan

----- Original Message ----
From: Robert Sparks <rjsparks at nostrum.com>
To: kaiduan xie <kaiduanx at yahoo.ca>
Cc: Byron Campen <bcampen at estacado.net>; Greg Inglis <Greg.Inglis at TelephoneticsVIP.co.uk>; resiprocate-devel at list.resiprocate.org
Sent: Thursday, May 3, 2007 11:44:08 AM
Subject: Re: [reSIProcate] Leaking transactions

The bug link in the mail pointed to below is stale. The current version is http://bugs.sipit.net/show_bug.cgi?id=706You'll note the bug is for a clarification - not a change in normative behavior.

But again, the point is that 

1) When you are an endpoint, it is your decision when to abandon an INVITE client transaction - the spec _explicitly and on purpose_
does not mandate an exit from the proceeding state. In code, this means the user of the stack has the responsibility
to terminate an INVITE transaction in that state. The stack CANNOT do that by itself.

2) When you are a proxy, you have timer C around to help you make that decision. You can look at the way repro uses timer C
as an example of how a TU tells the stack that its no longer willing to leave the INVITE transaction in that state.

I do not see a bug in the resiprocate code here.

RjS

On May 3, 2007, at 11:20 AM, kaiduan xie wrote:

Please see a very old debate on sip implementor list,
https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-December/005785.html kaiduan

----- Original Message ----
From: Byron Campen <bcampen at estacado.net>
To: kaiduan xie <kaiduanx at yahoo.ca>
Cc: Greg Inglis <Greg.Inglis at TelephoneticsVIP.co.uk>; resiprocate-devel at list.resiprocate.org
Sent: Thursday, May 3, 2007 9:48:46 AM
Subject: Re: [reSIProcate] Leaking transactions

	Well, that isn't exactly the case. For endpoints, we tear down the transaction when the _user_ decides to stop pursuing it. For proxies, we use Timer C. There is no defined mechanism for B2BUAs, but I would expect that something like Timer C could be used.

Best regards,
Byron Campen

Yes, this is a bug in resiprocate, and a bug in rfc 3261. Same thing happens for UAS INVITE transaction.

kaiduan

----- Original Message ----
From: Greg Inglis <Greg.Inglis at TelephoneticsVIP.co.uk>
To: resiprocate-devel at list.resiprocate.org
Sent: Thursday, May 3, 2007 6:13:47 AM
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

      Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail _______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

      Ask a question on any topic and get answers from real people. Go to Yahoo! Answers._______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

      Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070503/c122e1fa/attachment.htm>