Hi Stan,
That is exactly the pointcreating a transaction as soon as possible,
helps you in identifying retransmissions as soon as possible and to
avoid useless computation (so, reducing the load on your server).
With the current implementation, the penalty is (as per warning I put in
the T
Hi Alex,
To detect a retransmission you need to have the transaction created by
the initial request - otherwise you cannot detect a retransmission. So,
if you create the transaction very late in the script (t_relay() time),
whatever retransmission you might get in the mean while will not be
de
2009/7/16 Alex Balashov :
> What is the benefit of creating a new transaction on top of the retrans
> checks? Why would I not just want to wait until I call t_relay(), which
> will also create a transaction if it does not already exist. Why it would
> be beneficial to have it exist beforehand?It
Thanks Bogdan. Appreciate your followup.
So let me put the question this way:
What is the benefit of creating a new transaction on top of the
retrans checks? Why would I not just want to wait until I call
t_relay(), which will also create a transaction if it does not already
exist. Why it
Hi Alex,
No, t_check_trans() will NOT create a new transaction. Both function
will check (for non-ACK and non-CANCEL) if it is retransmission and if
so, it will sent (via TM) the last sent reply and stop the script
exectution. If it is not a retransmission, t_check_trans() will not do
anything
Stanisław Pitucha wrote:
> bogdan_vs: second statement is the correct oneboth first check if
> retransmission (and if so resend the reply). If no retransmission,
> only t_newtran() will force the creation of the transaction;
> tr_check_tran() will do nothing
And what is the practical effect o
2009/7/14 Alex Balashov :
> Are you saying that t_check_trans() will create a new transaction for a
> non-ACK/CANCEL retransmission too? Or that it retransmits the last reply
> sent "statelessly" somehow?
I was confused about it too at the beginning. Let me paste what Bogdan
said on IRC - it's e
Bogdan,
Are you saying that t_check_trans() will create a new transaction for
a non-ACK/CANCEL retransmission too? Or that it retransmits the last
reply sent "statelessly" somehow?
--
Sent from mobile device
On Jul 14, 2009, at 9:10 AM, Bogdan-Andrei Iancu wrote:
> Hi Stan,
>
> when come
Hi Stan,
when comes to handling retransmissions (and not CANCELs and ACKs
belonging to an INVITE transaction), both function do more or less the
same - handle the retransmission (by retransmitting the last sent reply)
and breaking the script execution - of course, the difference is if no
retr
Stanisław Pitucha wrote:
> 2009/7/14 Alex Balashov :
>> http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id272150
>
> A bit related question. Since the docs mention:
> "If the processing of requests may take long time (e.g. DB lookups)
> and the retransmission arrives before t_relay() is ca
2009/7/14 Alex Balashov :
> http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id272150
A bit related question. Since the docs mention:
"If the processing of requests may take long time (e.g. DB lookups)
and the retransmission arrives before t_relay() is called, you can use
the t_newtran() fu
Marc Leurent wrote:
> Hello,
> What is the purpose of t_check_trans(); at line 253 in opensips.cfg
> trunk version.
> This function is only a check so should not be necessary here?
> No?
>
>
> # CANCEL processing
> if (is_method("CANCEL"))
> {
> if (t_
Hello,
What is the purpose of t_check_trans(); at line 253 in opensips.cfg trunk
version.
This function is only a check so should not be necessary here?
No?
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_rel
13 matches
Mail list logo
