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]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
