[OpenSIPS-Users] What is the role of t_check_trans at line 253 of opensips.cfg in SVN trunk
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>:
> 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:
> after all cancel / ack checks is a bad thing to do? Or maybe even:
> 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:
# slow database lookups, latent tasks that block the worker
# process, etc.
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?
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
More information about the Users