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

Alex Balashov abalashov at evaristesys.com
Tue Jul 14 13:56:22 CEST 2009

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.

The only authoritative answer to this can come from the developers, but 
if I were to follow what I consider a reasonable interpretation of the 
documentation you quoted, the answer would be that it is safe to always 
create a new transaction.

However, there is a caveat in the documentation for t_newtran():

"NOTE that the changes on the request that are made after this function 
call will not be saved into transaction!!!"

I am not sure what precisely is meant by "changes on the request," but 
if I read this rather naively and literally, it seems to mean that it is 
necessary to make changes to the request body such as rewriting the 
Request URI prior to invoking t_newtran().  Since the information needed 
to make such changes often comes from "latent" operations such as 
database lookups, I would conclude that this makes t_newtran() rather 
useless as a retransmission dampening measure.

I use a different - and more canonical - way to prevent retransmissions. 
  By default, a "100 Trying" provisional response is not sent until 
t_relay() is called, which is what provides acknowledgment to the near 
end that the request was received and that further retransmissions are 
not needed.  However, t_relay() has a flag:

"0x01 - do not generate an 100 trying provisional reply when building 
the transaction. By default one is generated. Useful if you already 
pushed an stateless 100 reply from script."

Since it is possible to suppress a second provisional response, the 
first one can be sent pre-emptively:

    route {

       sl_send_reply("100", "Trying");

       # slow database lookups, latent tasks that block the worker
       # process, etc.


       if(!t_relay("1")) {

In light of this, I am not sure what to make of the retransmission 
dampening application of t_newtran().  This is a good question.  Perhaps 
someone like Bogdan or someone else with more intricate knowledge of the 
design intent can weigh in?

-- Alex

Alex Balashov
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

More information about the Users mailing list