[Serdev] Re: [Devel] tm bug in t_hooks.c

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Dec 19 16:56:28 CET 2005


Hi Federico,

you are right - the root problem is the call of t_lookup_request() 
(which I was suspecting to be from script) - but it's called by TM 
register callback function.

The t_lookup_request() function sets a internal static variable which 
points to the found transaction (if any). t_relay() interprets the set 
variable as duplicated call of the function.

I will have to find a way to solve this.....good catch and thanks for 
the help!!

regards,
bogdan

Federico Giannici wrote:

> Bogdan-Andrei Iancu wrote:
>
>>
>> Hi Federico,
>>
>> what I'm asking is to remove completely from your script the 
>> retransmission tests (via t_lookup_request() and t_check_trans() ) 
>> .... remove them and see if you still get the error...
>
>
> I already replyed to you on 9th (with a private email)...
>
> Anyway, if you look at my last email, I have found that the problem is 
> in the uac_replace_from() that calls uac_tmb.register_tmcb() that 
> indirectly calls t_lookup_request()!
>
> t_lookup_request() estables a transaction for retrasmissions, so when 
> later I call t_relay... it gives the error!
>
> I added the following code just before the t_relay():
>
> if( !is_method("ACK|CANCEL") && t_lookup_request() )
>     {
>     log( 1, "Duplicate message, exiting..." );
>     exit;
>     }
>
> Do you think is ok?
>
> Bye.
>
>
>
>> Federico Giannici wrote:
>>
>>> Bogdan-Andrei Iancu wrote:
>>>
>>>> so, after all seams to be a scripting problem. try to remove 
>>>> t_lookup_request() and t_check_trans() from your script ( t_relay() 
>>>> will detect the retransmissions anyhow). If you still get the 
>>>> error, please send me the script - it will spare a lot of time.
>>>
>>>
>>>
>>>
>>> I put the following tests at the very start of the script, before 
>>> anything else:
>>>
>>> if( t_lookup_request() )
>>>     {
>>>     log( 1, "t_lookup_request: Yes" );
>>>     }
>>> else
>>>     {
>>>     log( 1, "t_lookup_request: No" );
>>>     }
>>> if( t_check_trans() )
>>>     {
>>>     log( 1, "t_check_trans: Yes" );
>>>     }
>>> else
>>>     {
>>>     log( 1, "t_check_trans: No" );
>>>     }
>>>
>>> For retrasmission messages both tests are "Yes".
>>>
>>> Is this the expected behaviour?
>>> Or that indicate that the retrasmissions have IMMEDIATLY associated 
>>> a trasaction?
>>>
>>>
>>> Bye.
>>>
>>>
>>>
>>>> Federico Giannici wrote:
>>>>
>>>>> Bogdan-Andrei Iancu wrote:
>>>>>
>>>>>> please try the following patch and let me know if solves the 
>>>>>> problem. ...just a fast guess...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No, the problem remain.
>>>>> When a retrasmission arrives, both t_lookup_request() and 
>>>>> t_check_trans() are TRUE, and the following error appears:
>>>>>
>>>>> Dec  8 16:44:15 eowyn OpenSER[7103]: ERROR: t_newtran: transaction 
>>>>> already in process 0x512a22e0
>>>>> Dec  8 16:44:15 eowyn OpenSER[7103]: ERROR: sl_reply_error used: 
>>>>> I'm terribly sorry, server error occurred (1/SL)
>>>>>
>>>>>
>>>>> Bye.
>>>>>
>>>>>
>>>>>
>>>>>> Federico Giannici wrote:
>>>>>>
>>>>>>> Bogdan-Andrei Iancu wrote:
>>>>>>>
>>>>>>>> Federico Giannici wrote:
>>>>>>>>
>>>>>>>>> Bogdan-Andrei Iancu wrote:
>>>>>>>>>
>>>>>>>>>> Hi Federico,
>>>>>>>>>>
>>>>>>>>>> I'm afraid you have a script error - you called twice some 
>>>>>>>>>> functions which create transactions...The error is generate 
>>>>>>>>>> most probably by t_relay() which found the transaction 
>>>>>>>>>> already created in the script (maybe via t_newtran).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, I know it.
>>>>>>>>> It is the UAC module that create a transaction (I don't know 
>>>>>>>>> if in any case or only in some cases).
>>>>>>>>>
>>>>>>>> the uac module does not create a transaction - 
>>>>>>>> uac_replace_from() performs just text mangling and installs 
>>>>>>>> some hooks.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You are right, this problem doesn't seem to be related to the 
>>>>>>> UAC module (I was confused by the previous AVPs vanishing bug).
>>>>>>>
>>>>>>> Anyway, when a retrasmission of an INVITE reaches the t_relay() 
>>>>>>> function, the following error appear:
>>>>>>>
>>>>>>> Dec  8 14:56:18 eowyn OpenSER[21824]: ERROR: t_newtran: 
>>>>>>> transaction already in process 0x50132480
>>>>>>> Dec  8 14:56:18 eowyn OpenSER[21824]: ERROR: sl_reply_error 
>>>>>>> used: I'm terribly sorry, server error occurred (1/SL)
>>>>>>>
>>>>>>> And the UAC closes the call (because of the 500 error)!
>>>>>>>
>>>>>>> Please note that there is no t_newtran() in the entire script, 
>>>>>>> and the problem occours only with the retrasmissions!
>>>>>>>
>>>>>>> What is the supposed way to avoid this?
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> So when the message arrives at the classic t_relay() part of 
>>>>>>>>> the script, I cannot know if a transactionis is already 
>>>>>>>>> established.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> To be able to help, please send the script (privately, if 
>>>>>>>>>> necessary) to take a look.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you still think that there is problem somewhere, I will 
>>>>>>>>> send the script to you...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bye.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> P.S.
>>>>>>>>> I sent a similar question at "serusers at iptel.org", but still 
>>>>>>>>> no usefull reply...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Federico Giannici wrote:
>>>>>>>>>>
>>>>>>>>>>> Bogdan-Andrei Iancu wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Frederico,
>>>>>>>>>>>>
>>>>>>>>>>>> that's good..one more down....
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Well.... the AVPs are no more disappearing, but I still have 
>>>>>>>>>>> some problem with the reinvites...
>>>>>>>>>>>
>>>>>>>>>>> It seems that uac_replace_from() creates a transaction when 
>>>>>>>>>>> an INVITE retrasmission is received. Infact in that case the 
>>>>>>>>>>> following errors are logged for the retrasmitted INVITEs:
>>>>>>>>>>>
>>>>>>>>>>> Dec  5 18:49:25 eowyn OpenSER[5654]: ERROR: t_newtran: 
>>>>>>>>>>> transaction already in process 0x502a56f8
>>>>>>>>>>> Dec  5 18:49:25 eowyn OpenSER[5654]: ERROR: sl_reply_error 
>>>>>>>>>>> used: I'm terribly sorry, server error occurred (1/SL)
>>>>>>>>>>>
>>>>>>>>>>> This is generated by this standard code:
>>>>>>>>>>>
>>>>>>>>>>> if ( !t_relay() ) {
>>>>>>>>>>>     sl_reply_error();
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I thought that I could find the retrasmissions (with the 
>>>>>>>>>>> t_lookup_request() function) and use the 
>>>>>>>>>>> t_forward_nonack_uri() function in that case, but I got the 
>>>>>>>>>>> following error:
>>>>>>>>>>>
>>>>>>>>>>> Dec  5 18:47:29 eowyn OpenSER[26647]: 
>>>>>>>>>>> ERROR:tm:t_forward_nonack: no branch for forwarding
>>>>>>>>>>>
>>>>>>>>>>> Obviously, I have not enought undestanding of TM functions 
>>>>>>>>>>> and transactions in general.
>>>>>>>>>>>
>>>>>>>>>>> So, the question is: can anybody post a correct fragment of 
>>>>>>>>>>> script code that relay a message, correctly handling 
>>>>>>>>>>> retrasmissions?
>>>>>>>>>>>
>>>>>>>>>>> Otherwise, could I simply discard retrasmissions (with a 
>>>>>>>>>>> simple exit)?
>>>>>>>>>>> And how I can recognize retrasmissions? Is 
>>>>>>>>>>> t_lookup_request() the correct function for a test?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Federico Giannici wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Bogdan-Andrei Iancu wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Cesc,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> right!! as the transaction list is set all the time 
>>>>>>>>>>>>>> (disregarding the presence of callbacks), it should be 
>>>>>>>>>>>>>> also unset all the time....
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This solves the bug of the AVPs disappearing with 
>>>>>>>>>>>>> retrasmitted INVITES too!!!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bogdan, now you can remove that bug from the ones to 
>>>>>>>>>>>>> search for...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you Cesc.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>> Index: modules/tm/tm.c
>>>>>> ===================================================================
>>>>>> RCS file: /cvsroot/openser/sip-server/modules/tm/tm.c,v
>>>>>> retrieving revision 1.15
>>>>>> diff -u -r1.15 tm.c
>>>>>> --- modules/tm/tm.c    18 Oct 2005 17:03:15 -0000    1.15
>>>>>> +++ modules/tm/tm.c    8 Dec 2005 15:29:41 -0000
>>>>>> @@ -490,6 +490,7 @@
>>>>>>      t_on_negative( 0 );
>>>>>>      t_on_reply(0);
>>>>>>      t_on_branch(0);
>>>>>> +    set_t(T_UNDEFINED);
>>>>>>      /* reset the kr status */
>>>>>>      set_kr(0);
>>>>>>      return 1;
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>




More information about the Devel mailing list