[OpenSIPS-Users] What is the role of t_check_trans at line 253 of opensips.cfg in SVN trunk

Bogdan-Andrei Iancu bogdan at voice-system.ro
Thu Jul 16 17:54:20 CEST 2009


Hi Alex,

No, t_check_trans() will NOT create a new transaction. Both function 
will check (for non-ACK and non-CANCEL) if it is retransmission and if 
so, it will sent (via TM) the last sent reply and stop the script 
exectution. If it is not a retransmission, t_check_trans() will not do 
anything else, but t_newtran() will create a new transaction.

I added this function in 1.0 (?!?) as it was mainly intended for proper 
CANCEL and ACK routing.

Regards,
Bogdan

Alex Balashov wrote:
> Bogdan,
>
> Are you saying that t_check_trans() will create a new transaction for 
> a non-ACK/CANCEL retransmission too?   Or that it retransmits the last 
> reply sent "statelessly" somehow?
>
> -- 
> Sent from mobile device
>
> On Jul 14, 2009, at 9:10 AM, Bogdan-Andrei Iancu 
> <bogdan at voice-system.ro> wrote:
>
>> Hi Stan,
>>
>> when comes to handling retransmissions  (and not CANCELs and ACKs
>> belonging to an INVITE transaction), both function do more or less the
>> same - handle the retransmission (by retransmitting the last sent reply)
>> and breaking the script execution - of course, the difference is if no
>> retransmission, t_newtran() will create a new transaction for the 
>> request.
>>
>> So :
>>
>> t_check_trans();
>> t_new_trans();
>>
>>
>> is a bit redundant. Only:
>>
>> t_new_trans();
>>
>>
>> will do exactly the same job.
>>
>> Again, this is true only in the context of non-CANCEL  and non-ACK 
>> requests!
>>
>> Regards,
>> Bogdan
>>
>> Stanisław Pitucha wrote:
>>> 2009/7/14 Alex Balashov <abalashov at evaristesys.com>:
>>>
>>>> http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id272150
>>>>
>>>
>>> A bit related question. Since the docs mention:
>>> "If the processing of requests may take long time (e.g. DB lookups)
>>> and the retransmission arrives before t_relay() is called, you can use
>>> the t_newtran() function to manually create a transaction."
>>>
>>> Is there any situation where:
>>>
>>> t_check_trans();
>>> t_new_trans();
>>>
>>> after all cancel / ack checks is a bad thing to do? Or maybe even:
>>>
>>> t_check_trans();
>>> if (is_method('INVITE|UPDATE|REFER')) t_new_trans();
>>>
>>> since everything else can be safely duplicated / is rather light in 
>>> processing.
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>




More information about the Users mailing list