Bugs item #1996441, was opened at 2008-06-17 13:26 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1996441&group_id=139143
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anatoly Pidruchny (apidruchny) Assigned to: Nobody/Anonymous (nobody) Summary: t_check_trans not always detects retransmissions Initial Comment: Let's say OpenSER received an INVITE request and is doing some time-consuming operation on it, such as retrieving some information from the database. At this time a re-transmission of this INVITE message comes. In this case t_check_trans() just returns false and so another OpenSER worker process will just start processing this INVITE and will start doing the same time-consuming operation. It could be highly undesirable to do this. In my opinion, there should be a way to recognize and drop the second INVITE that is a re-transmission of the first INVITE, if we have not finished processing the first INVITE yet. It looks like t_check_trans() starts to work properly only after the first worker process finished all the time-consuming work and called t_relay(). I think one (dangerous) way of fixing this is for t_check_trans(), if it does not find the transaction, to memorize it and break the script the next time it is called with the same transaction. Another way is to add a new function (something like t_register_trans) that would just register the transaction in TM so that later t_check_trans() can break the script if it is called with this transaction. Please move this submission to a feature request if you think it is a new feature. I just thought that it can be viewed as a bug in t_check_trans(). /Anatoly Pidruchny ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-18 01:14 Message: Logged In: NO Have you tried t_newtran() to create the transaction manually before doing the time consuming operation? klaus ---------------------------------------------------------------------- Comment By: Anatoly Pidruchny (apidruchny) Date: 2008-06-17 14:41 Message: Logged In: YES user_id=1759384 Originator: YES Some additional info about the problem. In the described scenario, a worker process finishes processing and relays the first INVITE successfully. But later when the second worker process tries to relay literally the same message (that was originally the re-transmitted INVITE), it gets the following error: Jun 17 17:00:01.385827 2008 [4546] ERROR:tm:t_forward_nonack: no branch for forwarding Jun 17 17:00:01.385837 2008 [4546] ERROR:tm:w_t_relay: t_forward_nonack failed Jun 17 17:00:01.385844 2008 [4546] ERROR:tm:t_forward_nonack: no branch for forwarding Jun 17 17:00:01.385849 2008 [4546] ERROR:tm:w_t_relay: t_forward_nonack failed I think calling t_check_trans() before calling t_relay() would help in this case. But I already called t_check_trans() earlier in the script. It is very unfortunate that a transaction can "appear" after I called t_check_trans(), but before I call t_relay() and cause t_relay() to fail. This problem would be avoided if I can register the transaction when the first INVITE comes and then drop the retransmitted INVITE if the first INVITE is still being processed. /Anatoly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1996441&group_id=139143 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel