[OpenSER-Devel] [ openser-Bugs-1996441 ] t_check_trans not always detects retransmissions

[SourceForge.net]

Bugs item #1996441, was opened at 2008-06-17 16:26
Message generated for change (Comment added) made by apidruchny
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: Anatoly Pidruchny (apidruchny)
Date: 2008-06-17 17: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