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

[Alex Balashov]

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."
(http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271606)

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")) {
           sl_reply_error();
           exit;
       }
    }

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