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

SourceForge.net noreply at sourceforge.net
Fri Jun 20 10:05:08 CEST 2008


Bugs item #1996441, was opened at 2008-06-17 22:26
Message generated for change (Comment added) made by klaus_darilion
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: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Anatoly Pidruchny (apidruchny)
>Assigned to: Klaus Darilion (klaus_darilion)
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: Klaus Darilion (klaus_darilion)
Date: 2008-06-20 10:05

Message:
Logged In: YES 
user_id=1318360
Originator: NO

extended documentation (trunk only)

----------------------------------------------------------------------

Comment By: Anatoly Pidruchny (apidruchny)
Date: 2008-06-19 19:30

Message:
Logged In: YES 
user_id=1759384
Originator: YES

I tested t_newtran() function and came to conclusion that this is exactly
the function that I was looking for. Everything works as I wanted with
t_newtran(). I am sorry that I was too quick to submit a bug report. I
should have tried to ask in the users list first. I am OK if this bug
report is closed as invalid. But may be a note/hint can be added in the
documentation that t_check_trans() will not detect the retransmission if a
transaction was not created for the original message and t_newtran() can be
used to create the transaction early if it could take much time to reach
t_relay().

/Anatoly


----------------------------------------------------------------------

Comment By: Anatoly Pidruchny (apidruchny)
Date: 2008-06-18 18:18

Message:
Logged In: YES 
user_id=1759384
Originator: YES

Klaus, thanks. I did not try t_newtran(). I never used it and, frankly, do
not quite understand how exactly it works. Will it register the incoming
INVITE as a new transaction in TM module (so that later t_check_trans()
will be able to detect retransmissions)?  Should I call t_reply("100",
"Trying") immediately after t_newtran()? Will t_relay work fine after
t_newtran()?

Another idea worked for me. As Juha suggested (and I got the same idea),
if I send "100 Trying" using sl_send_reply() before time-consuming
operations then UAC does not retransmit the INVITE and the problem is
avoided.

--
Anatoly

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-06-18 10: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 23: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



More information about the Devel mailing list