Hi Daren,
Yes, correct, all the onreply_route and failure_route are 100% stateful,
provided by the tm module (transaction module). So, whenever you are in
one of those routes, you should do (if permitted) only stateful
signaling and not stateless, otherwise you will get unexpected behaviors
from OpenSIPS and the TM engine is not aware of your stateless ops (from
script).
In the stateful blocks, use t_reply() or send_reply() (which is actually
a wrapper over t_relay() + sl_send_reply()). But going back to the
failure of t_relay() - the function will automatically try to send back
a stateful reply and it will report error to script only if even this
replying failed - so makes no sense to try to send from script , again,
a negative reply (the t_relay() already tried it and failed to do it).
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
https://opensips.org/training/OpenSIPS_Bootcamp_2020/
On 1/7/20 1:27 AM, Daren FERREIRA wrote:
Hi Bogdan,
I have no idea on real changes between 2.3 and 3.0 but it seems that
there is much more script sanity checks (and that’s great) that now
blocks (erroneous) things that was not blocked before…
For example, that’s the reason why i had to replace sl_send_reply() by
send_reply().
But in my case, i’m already in a failure_route.
failure_route[GW_FAILOVER]{
route(CONTROLS);
if (t_was_cancelled()) {
exit;
}
do_accounting("db","failed");
$acc_extra(identity)=$hdr(P-Asserted-Identity);
$acc_extra(src)=$fU;
$acc_extra(dst)=$tU;
$acc_extra(src_ip) =$si; # source IP of the request
# failure detection with redirect to next available trunk
if (t_check_status("(408)|([56][0-9][0-9])")) {
xlog("L_INFO","Failed trunk $rd/$du detected \n");
if ( ds_next_dst() ) {
t_on_branch("CLEANING");
t_on_failure("GW_FAILOVER");
route(RELAY);
#this block is not usable there
if (!t_relay()) {
sl_reply_error();
};
exit;
}
send_reply(500,"All GW are down");
}
}
So do you think activating the failure_route inside the failure_route
is enough to manage the eventual t_relay failures? (and by the way, is
it safe to activate failure_routes inside failure_routes).
Reading your other posts (about 408 failover) makes me better
understand the opensips internal (i think so).
If i well understand, a failure_route is forcibly stateful, so it is
not logical to send stateless replies inside a stateful block.
On the opposite side i actually no idea how to send errors replies
inside stateful blocks (maybe that’s internally managed - there is my
limit).
I hope this is better now to understand my problem.
Thank you
Regards
Le 6 janv. 2020 à 18:41, Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>> a écrit :
Hi Daren,
I do not remember to have any changes between 2.3 and 3.0 when comes
to the sl_send_reply() usage - maybe you can be more explicit on the
differences you see between the versions.
Now, one using handling the failure of `t_relay()` - if the function
has some internal failure in sending out the request, it will
automatically send back a negative reply and return success to
script. The failure indication is returned to the script ONLY if the
both sending the request AND the negative reply ops failed.
The sending of the negative reply is done in stateful mode, so this
is the explanation of sl_reply_error() you see in examples - it will
try to report back a reply in a stateless mode (in a lighter way,
with a higher probability of success than the stateful attempt).
Why not doing this in failure route? as in failure route you are
already in stateful mode, so there are almost 0 chances to get a
failure indication from t_relay().
As a note, see the 0x02 flag for t_relay() -
https://opensips.org/html/docs/modules/3.0.x/tm.html#func_t_relay
Best Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
https://www.opensips.org/events/Summit-2020Amsterdam/
OpenSIPS Bootcamp, Miami, March 2020
https://opensips.org/training/OpenSIPS_Bootcamp_2020/
On 12/15/19 5:11 PM, Daren FERREIRA wrote:
Hello,
I’ve been using my configuration script for a while without problems
on 2.3.x releases, but, with 3.0.x some errors are coming.
Syntax changes are not a problem, as fortunately changes are well
documented on the wikis :)
My problem is relative to replies (sl_send_reply and sl_reply_error)
and the places where we’re allowed to use them.
For sl_send_reply, send_reply alternative has solved my problem, but
that’s not as easy for sl_reply_error.
In every documentation, examples or forums i read, we use to do
if (!t_relay()) {
sl_reply_error();
}
In order to send an error in case of any problem with t_relay.
But sl_reply_error is forbidden in failure routes, so, should we
consider there will never have any problems with t_relay in failure
routes?
In my case i use dispatcher, and, in case of failure, i try to find
another destination, and relay messages to it, until the call succeed…
If the first try fails, it triggers a failure route where i’m no
more able to send an error if the t_relay fails…
So is it safe not to check anymore the t_relay return on failure routes?
If not, is there any alternatives? I think about using send_reply
instead of sl_reply_error, but with what arguments? $err.rcode and
$err.rreason ?
Thank you for your help and comments.
Regards
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
