reSIProcate

Mailing Lists

Source Code

Google Search:



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

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=706
You'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@xxxxxxxxxxxx>
To: kaiduan xie <kaiduanx@xxxxxxxx>
Cc: Greg Inglis <Greg.Inglis@xxxxxxxxxxxxxxxxxxxxxx>; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxx>
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@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


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



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