[reSIProcate] Leaking transactions

[Robert Sparks]

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 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070503/3d6a6041/attachment.htm>