Hi,
In our config we don't use presence, but I do have a question about transactions.
We're using dialogs as well as transactions in the routing. To keep things simplyfied, let's assume we have the following stripped out route setup:
request_route {
if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); } exit; }
# As stated in documentation, this call could stop further # routing from here on out t_check_trans();
if (is_method("INVITE")) { if (ds_is_from_list()) { setflag(DLG_FLAG); } setflag(FLT_ACC); }
if (lookup("loction") == -1 ) {
if(load_gws(1)) { t_newtran();
t_on_failure("TFAIL"); } } }
route[TFAIL] { xlog("L_ERR", "Failed setting up transaction"); }
What I'd like to know is when or even if we need to be releasing the transaction at some point. From what I understand in the presence example I should be releasing a transaction when I use t_newtran, but I haven't found any evidence of needing it when working with t_relay or t_check_trans.
For example, could it be needed to do a t_release() on a dialog_terminated or dialog_end event?
In the above example, would it just be enough to add t_release() to the failure route TFAIL?
Further details about how and/or when the transactions are cleaned up internally would be greatly appreciated!
Dirk,
Why do you need to create new transactions yourself with t_newtran()? Nonexotic applications of Kamailio usually don't require this. A transaction is automatically created after t_relay() is called, and its lifecycle is automatically managed - including destruction - based on the replies received to the transaction-forming request, and based on RFC 3261 rules in cases of timeouts.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
Hi,
I think one would like to create transaction ASAP to absorb retransmissions. In some scenarios, processing a message can take time and retransmissions are likely to happen, and you don't want the retransmissions to be processed again (which can lead to errors in some scenarios). t_relay is generally called at the end for relaying the message.
Mickael
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov Sent: Thursday, April 30, 2015 11:26 AM To: Dirk Teurlings - SIGNET B.V. Subject: Re: [SR-Users] Transaction good practices with t_relay t_newtran and t_release
Dirk,
Why do you need to create new transactions yourself with t_newtran()? Nonexotic applications of Kamailio usually don't require this. A transaction is automatically created after t_relay() is called, and its lifecycle is automatically managed - including destruction - based on the replies received to the transaction-forming request, and based on RFC 3261 rules in cases of timeouts.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
There are really no healthy applications of Kamailio in which processing of a request should take a long time, due to Kamailio's limited number (necessarily so) of SIP worker threads. So, the temporal delta from initial message receipt to t_relay() should not be high, and once t_relay() is called, a transaction is created anyway, allowing you to dampen retransmissions with t_check_trans() & friends.
If you must use high-delay processing, use of the TM async capabilities is highly recommended. The suspend/continue required to shuttle request processing off to another thread does require explicit transaction creation up-front, true enough. However, most retransmissions can be dampened by preemptively sending a stateless 100 Trying first. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry. Original Message From: Mickael Marrache Sent: Thursday, April 30, 2015 04:32 To: 'Kamailio (SER) - Users Mailing List' Reply To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Transaction good practices with t_relay t_newtran and t_release
Hi,
I think one would like to create transaction ASAP to absorb retransmissions. In some scenarios, processing a message can take time and retransmissions are likely to happen, and you don't want the retransmissions to be processed again (which can lead to errors in some scenarios). t_relay is generally called at the end for relaying the message.
Mickael
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov Sent: Thursday, April 30, 2015 11:26 AM To: Dirk Teurlings - SIGNET B.V. Subject: Re: [SR-Users] Transaction good practices with t_relay t_newtran and t_release
Dirk,
Why do you need to create new transactions yourself with t_newtran()? Nonexotic applications of Kamailio usually don't require this. A transaction is automatically created after t_relay() is called, and its lifecycle is automatically managed - including destruction - based on the replies received to the transaction-forming request, and based on RFC 3261 rules in cases of timeouts.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
there is a rather new lightweight mechanism to detect retransmissions without creating the transaction before relaying. It is already part of 4.2 and in the default configuration file -- see t_precheck_trans() from tmx module.
Cheers, Daniel
On 30/04/15 10:31, Mickael Marrache wrote:
Hi,
I think one would like to create transaction ASAP to absorb retransmissions. In some scenarios, processing a message can take time and retransmissions are likely to happen, and you don't want the retransmissions to be processed again (which can lead to errors in some scenarios). t_relay is generally called at the end for relaying the message.
Mickael
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov Sent: Thursday, April 30, 2015 11:26 AM To: Dirk Teurlings - SIGNET B.V. Subject: Re: [SR-Users] Transaction good practices with t_relay t_newtran and t_release
Dirk,
Why do you need to create new transactions yourself with t_newtran()? Nonexotic applications of Kamailio usually don't require this. A transaction is automatically created after t_relay() is called, and its lifecycle is automatically managed - including destruction - based on the replies received to the transaction-forming request, and based on RFC 3261 rules in cases of timeouts.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi,
Thanks for all responses, I think we can do completely without the t_newtran too now. We got it originally from one of the older CNXCC routing examples. But it seems we can skip it entirely indeed.
TMX might also be good for us to use earlier transaction detection. I'll look into that as well.
Cheers, Dirk
On 30-04-15 12:23, Daniel-Constantin Mierla wrote:
Hello,
there is a rather new lightweight mechanism to detect retransmissions without creating the transaction before relaying. It is already part of 4.2 and in the default configuration file -- see t_precheck_trans() from tmx module.
Cheers, Daniel
On 30/04/15 10:31, Mickael Marrache wrote:
Hi,
I think one would like to create transaction ASAP to absorb retransmissions. In some scenarios, processing a message can take time and retransmissions are likely to happen, and you don't want the retransmissions to be processed again (which can lead to errors in some scenarios). t_relay is generally called at the end for relaying the message.
Mickael
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov Sent: Thursday, April 30, 2015 11:26 AM To: Dirk Teurlings - SIGNET B.V. Subject: Re: [SR-Users] Transaction good practices with t_relay t_newtran and t_release
Dirk,
Why do you need to create new transactions yourself with t_newtran()? Nonexotic applications of Kamailio usually don't require this. A transaction is automatically created after t_relay() is called, and its lifecycle is automatically managed - including destruction - based on the replies received to the transaction-forming request, and based on RFC 3261 rules in cases of timeouts.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Daniel-Constantin Mierla -
Dirk Teurlings - SIGNET B.V. -
Mickael Marrache