Stanisław Pitucha wrote: > 2009/7/14 Alex Balashov <abalas...@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 _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users