Hi Federico,
you are right - the root problem is the call of t_lookup_request()
(which I was suspecting to be from script) - but it's called by TM
register callback function.
The t_lookup_request() function sets a internal static variable which
points to the found transaction (if any). t_relay() interprets the set
variable as duplicated call of the function.
I will have to find a way to solve this.....good catch and thanks for
the help!!
regards,
bogdan
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
Hi Federico,
what I'm asking is to remove completely from your script the
retransmission tests (via t_lookup_request() and t_check_trans() )
.... remove them and see if you still get the error...
I already replyed to you on 9th (with a private email)...
Anyway, if you look at my last email, I have found that the problem is
in the uac_replace_from() that calls uac_tmb.register_tmcb() that
indirectly calls t_lookup_request()!
t_lookup_request() estables a transaction for retrasmissions, so when
later I call t_relay... it gives the error!
I added the following code just before the t_relay():
if( !is_method("ACK|CANCEL") && t_lookup_request() )
{
log( 1, "Duplicate message, exiting..." );
exit;
}
Do you think is ok?
Bye.
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
so, after all seams to be a scripting problem. try to remove
t_lookup_request() and t_check_trans() from your script ( t_relay()
will detect the retransmissions anyhow). If you still get the
error, please send me the script - it will spare a lot of time.
I put the following tests at the very start of the script, before
anything else:
if( t_lookup_request() )
{
log( 1, "t_lookup_request: Yes" );
}
else
{
log( 1, "t_lookup_request: No" );
}
if( t_check_trans() )
{
log( 1, "t_check_trans: Yes" );
}
else
{
log( 1, "t_check_trans: No" );
}
For retrasmission messages both tests are "Yes".
Is this the expected behaviour?
Or that indicate that the retrasmissions have IMMEDIATLY associated
a trasaction?
Bye.
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
please try the following patch and let me know if solves the
problem. ...just a fast guess...
No, the problem remain.
When a retrasmission arrives, both t_lookup_request() and
t_check_trans() are TRUE, and the following error appears:
Dec 8 16:44:15 eowyn OpenSER[7103]: ERROR: t_newtran: transaction
already in process 0x512a22e0
Dec 8 16:44:15 eowyn OpenSER[7103]: ERROR: sl_reply_error used:
I'm terribly sorry, server error occurred (1/SL)
Bye.
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
Hi Federico,
I'm afraid you have a script error - you called twice some
functions which create transactions...The error is generate
most probably by t_relay() which found the transaction
already created in the script (maybe via t_newtran).
Yes, I know it.
It is the UAC module that create a transaction (I don't know
if in any case or only in some cases).
the uac module does not create a transaction -
uac_replace_from() performs just text mangling and installs
some hooks.
You are right, this problem doesn't seem to be related to the
UAC module (I was confused by the previous AVPs vanishing bug).
Anyway, when a retrasmission of an INVITE reaches the t_relay()
function, the following error appear:
Dec 8 14:56:18 eowyn OpenSER[21824]: ERROR: t_newtran:
transaction already in process 0x50132480
Dec 8 14:56:18 eowyn OpenSER[21824]: ERROR: sl_reply_error
used: I'm terribly sorry, server error occurred (1/SL)
And the UAC closes the call (because of the 500 error)!
Please note that there is no t_newtran() in the entire script,
and the problem occours only with the retrasmissions!
What is the supposed way to avoid this?
Thanks.
So when the message arrives at the classic t_relay() part of
the script, I cannot know if a transactionis is already
established.
To be able to help, please send the script (privately, if
necessary) to take a look.
If you still think that there is problem somewhere, I will
send the script to you...
Bye.
P.S.
I sent a similar question at "[EMAIL PROTECTED]", but still
no usefull reply...
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
Hi Frederico,
that's good..one more down....
Well.... the AVPs are no more disappearing, but I still have
some problem with the reinvites...
It seems that uac_replace_from() creates a transaction when
an INVITE retrasmission is received. Infact in that case the
following errors are logged for the retrasmitted INVITEs:
Dec 5 18:49:25 eowyn OpenSER[5654]: ERROR: t_newtran:
transaction already in process 0x502a56f8
Dec 5 18:49:25 eowyn OpenSER[5654]: ERROR: sl_reply_error
used: I'm terribly sorry, server error occurred (1/SL)
This is generated by this standard code:
if ( !t_relay() ) {
sl_reply_error();
}
I thought that I could find the retrasmissions (with the
t_lookup_request() function) and use the
t_forward_nonack_uri() function in that case, but I got the
following error:
Dec 5 18:47:29 eowyn OpenSER[26647]:
ERROR:tm:t_forward_nonack: no branch for forwarding
Obviously, I have not enought undestanding of TM functions
and transactions in general.
So, the question is: can anybody post a correct fragment of
script code that relay a message, correctly handling
retrasmissions?
Otherwise, could I simply discard retrasmissions (with a
simple exit)?
And how I can recognize retrasmissions? Is
t_lookup_request() the correct function for a test?
Thanks.
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
Hi Cesc,
right!! as the transaction list is set all the time
(disregarding the presence of callbacks), it should be
also unset all the time....
This solves the bug of the AVPs disappearing with
retrasmitted INVITES too!!!
Bogdan, now you can remove that bug from the ones to
search for...
Thank you Cesc.
------------------------------------------------------------------------
Index: modules/tm/tm.c
===================================================================
RCS file: /cvsroot/openser/sip-server/modules/tm/tm.c,v
retrieving revision 1.15
diff -u -r1.15 tm.c
--- modules/tm/tm.c 18 Oct 2005 17:03:15 -0000 1.15
+++ modules/tm/tm.c 8 Dec 2005 15:29:41 -0000
@@ -490,6 +490,7 @@
t_on_negative( 0 );
t_on_reply(0);
t_on_branch(0);
+ set_t(T_UNDEFINED);
/* reset the kr status */
set_kr(0);
return 1;
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
