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

[Alex Balashov]

Thanks Bogdan. Appreciate your followup.

So let me put the question this way:

What is the benefit of creating a new transaction on top of the  
retrans checks?  Why would I not just want to wait until I call  
t_relay(), which will also create a transaction if it does not already  
exist.  Why it would be beneficial to have it exist beforehand?It  
seems that retransmission detection works the same way regardless.

--
Sent from mobile device

On Jul 16, 2009, at 11:54 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro 
 > wrote:

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