linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] OPTIONS transaction handling


From: Thomas Reitmayr
Subject: Re: [Linphone-developers] OPTIONS transaction handling
Date: Wed, 31 Jan 2007 09:36:42 -0800 (PST)

Hi Aymeric,
regarding the first issue - I later saw myself that it was fixed in some 
version quite a while ago, but it still seems to be a potential memory leak as 
the "kill" callback for IST never gets initialized and therefore never called 
(if I haven't overlooked something). Therefore I appended the fix below.

About the second problem, I am aware that the eXosip version used for linphone 
is a snapshot with some of the bugs at that time. As this memory leak problem 
was quite serious on my embedded system due to the frequent options requests my 
VOIP service provider sends, I eventually found a fix which works for me. If 
there could be a problem needing the OPTIONS later in the call context (as you 
describe it), it did not happen with linphone for me - and I am still happy ;)
Anyway, it is somehow what the latest eXosip does and it is appended below, too.

--- linphone-1.6.0/exosip/jcallback.c    2006-08-09 15:01:57.000000000 +0200
+++ linphone-1.6.0-yea/exosip/jcallback.c    2007-01-28 18:45:12.000000000 +0100
@@ -1874,7 +1874,7 @@ eXosip_set_callbacks(osip_t *osip)
   
   osip_set_kill_transaction_callback(osip ,OSIP_ICT_KILL_TRANSACTION,
                  &cb_ict_kill_transaction);
-  osip_set_kill_transaction_callback(osip ,OSIP_NIST_KILL_TRANSACTION,
+  osip_set_kill_transaction_callback(osip ,OSIP_IST_KILL_TRANSACTION,
                  &cb_ist_kill_transaction);
   osip_set_kill_transaction_callback(osip ,OSIP_NICT_KILL_TRANSACTION,
                  &cb_nict_kill_transaction);
--- linphone-1.6.0/exosip/udp.c    2006-08-25 15:32:39.000000000 +0200
+++ linphone-1.6.0-yea/exosip/udp.c    2007-01-28 18:45:12.000000000 +0100
@@ -783,6 +783,8 @@ static void eXosip_process_new_options(o
       return ;
     }
 
+  osip_list_add(eXosip.j_transactions, transaction, 0);
+  
   evt_answer = osip_new_outgoing_sipmessage(answer);
   evt_answer->transactionid =  transaction->transactionid;
 
Thanks for your answer,
-Thomas


----- Ursprüngliche Mail ----
Von: Aymeric Moizard <address@hidden>
An: Simon Morlat <address@hidden>
CC: address@hidden
Gesendet: Mittwoch, den 31. Januar 2007, 11:48:52 Uhr
Betreff: [***SPAM***] Re: [Linphone-developers] OPTIONS transaction handling


On Wed, 31 Jan 2007, Simon Morlat wrote:

> Hi Thomas,
>
> Thanks for your deep study inside eXosip and libosip2.
> I cc Aymeric Moizard, maintainer of libosip2:

I'm registred to the linphone's mailing list :)

> Actually I plan to move linphone to eXosip2, so the question for me are the
> following memory leak and bugs fixed in eXosip2 ?
> Aymeric, can you answer this question ?

The second issue you have with setting callback with 
"osip_set_kill_transaction_callback" has been fixed in newer version long 
time ago. It was not generating bug at run time because the code within 
the callback methods are identical.

For your OPTIONS issue, I guess it's fixed in eXosip2. In initial
version of eXosip1, OPTIONS was stored in "call" context so that it
was potentially used later for a call: in eXosip2, it's managed outside
any call context and stored in the list of "unknown" transaction
managed by eXosip2. Once those transaction reach the completed state,
ressource are released automatically within eXosip2. (osip never
release transaction ressource)

I won't solve memory issue in eXosip1: it's more than two years old
for me....

Aymeric

> Thanks
>
> Simon
>
> Le mercredi 24 janvier 2007 21:58, Thomas Reitmayr a écrit :
>> Hi Simon,
>> I still try to track down how transaction handling works for an OPTIONS
>> dialog in linphone, respectively eXosip, to find out about the memory leak
>> I wrote about earlier.
>>
>> The following is what I think happens for this kind of transaction:
>> 1. The OPTIONS request is received. No matching transaction is found in
>> libosip2 so it gets accepted and a transaction record is allocated. 2. The
>> NIST state machine is executed until the transaction reaches the
>> 'Completed' state. 3. The transaction is removed from the libosip2's list
>> of transactions by one of the cb_*_kill_transaction routines, however at
>> that exact point it cannot be removed from memory as libosip2 still needs
>> it internally (in the loop going through all transactions). 4. Now after
>> processing in libosip2 the transaction record could be removed from memory.
>>
>> For other types of transactions the last step (4) seems to be performed
>> using a copy of a pointer to the transaction record and investigating the
>> transaction's state. However I have not found the OPTIONS transaction being
>> referenced by one of these lists in eXosip, so with removing the pointer in
>> libosip2 all references are gone and the memory is lost.
>>
>> I have also performed some tests using netcat to confirm that steps 1 - 3
>> are executed, but 4 seems to be missing. However I might be wrong in some
>> points of my investigation, so please correct me. My main question is still
>> about step 4 - how it works or how it is supposed to work to finally
>> release the allocated memory. Thanks in advance,
>> -Thomas
>>
>> PS: A bit off-topic: During studying the code I found a possible bug in the
>> following code: osip_set_kill_transaction_callback(osip
>> ,OSIP_ICT_KILL_TRANSACTION, &cb_ict_kill_transaction);
>>   osip_set_kill_transaction_callback(osip ,OSIP_NIST_KILL_TRANSACTION,
>>                  &cb_ist_kill_transaction);
>>   osip_set_kill_transaction_callback(osip ,OSIP_NICT_KILL_TRANSACTION,
>>                  &cb_nict_kill_transaction);
>>   osip_set_kill_transaction_callback(osip ,OSIP_NIST_KILL_TRANSACTION,
>>                  &cb_nist_kill_transaction);
>> The second function call should use OSIP_IST_KILL_TRANSACTION, otherwise
>> IST transactions might not be removed from libosip2's list.
>>
>>
>>
>>
>>
>>
>>
>>
>> ___________________________________________________________
>> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
>> http://mail.yahoo.de
>>
>>
>> _______________________________________________
>> Linphone-developers mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/linphone-developers
>
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers
>
>
_______________________________________________
Linphone-developers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/linphone-developers





                
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de




reply via email to

[Prev in Thread] Current Thread [Next in Thread]