[OpenSIPS-Users] t_forward_nonack failed (Ben Newlin)
Ben Newlin
Ben.Newlin at genesys.com
Sun Apr 5 19:15:05 EST 2020
I am not positive whether flags or AVPs set within the CANCEL transaction would be visible back in the INVITE transaction. It was just a thought. You might try a flag instead. But also in your code snippet you do have a typo. It should be:
$avp(ci)=$ci;
If flags and avps don’t work you may have to use something like a local cache to store the CANCEL data. I can’t think of any other solutions. It does seem OpenSIPS should provide the ability to detect this by allowing t_was_cancelled (and possibly t_cancel_branch) outside of just onreply_route.
Ben Newlin
From: Users <users-bounces at lists.opensips.org> on behalf of Oleg Podguyko via Users <users at lists.opensips.org>
Reply-To: Oleg Podguyko <podguiko at mail.ru>, OpenSIPS users mailling list <users at lists.opensips.org>
Date: Sunday, April 5, 2020 at 2:01 PM
To: "users at lists.opensips.org" <users at lists.opensips.org>
Subject: [OpenSIPS-Users] Re: t_forward_nonack failed (Ben Newlin)
Hello Ben,
Thank you for answer.
This is my RELAY route
route[RELAY] {
if (!t_relay())
{
sl_reply_error();
}
exit;
}
I did the following experiment. Commented out the line
#sl_reply_error();
Sent Invite and Cancel. Opensips did not send 500.
In fact, it is «sl_reply_error» that sends 500.
it looks like:
SIP/2.0 500 No destination available (18/SL)
It is clear now.
Following your advice I tried to use avp variable.
## CANCEL processing
if (is_method("CANCEL"))
{
## returns true if the current request is associated to a transaction
if (t_check_trans())
{
$avp(ci)=&ci
t_relay();
}
exit;
}
But when I try to use this variable( $avp(ci)) at the [resume] route of rest_client, it is <null>
Воскресенье, 5 апреля 2020, 16:55 +03:00 от users-request at lists.opensips.org:
Send Users mailing list submissions to
users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
or, via email, send a message with subject or body 'help' to
users-request at lists.opensips.org<file:////compose%3fTo=users%252drequest@lists.opensips.org>
You can reach the person managing the list at
users-owner at lists.opensips.org<file:////compose%3fTo=users%252downer@lists.opensips.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:
1. Re: t_forward_nonack failed (Ben Newlin)
2. Re: using load balancer and lookup together (Michael Vale)
----------------------------------------------------------------------
Message: 1
Date: Sun, 5 Apr 2020 13:11:34 +0000
From: Ben Newlin <Ben.Newlin at genesys.com<file:////compose%3fTo=Ben.Newlin@genesys.com>>
To: Oleg Podguyko <podguiko at mail.ru<file:////compose%3fTo=podguiko@mail.ru>>, OpenSIPS users mailling list
<users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] t_forward_nonack failed
Message-ID: <00BE023F-DA3A-45EE-988F-BA4891FB9E04 at genesys.com<file:////compose%3fTo=00BE023F%252dDA3A%252d45EE%252d988F%252dBA4891FB9E04@genesys.com>>
Content-Type: text/plain; charset="utf-8"
Oleg,
At first glance, it seems like t_was_cancelled [1] is exactly what you want. However, it can only be called from onreply_route or failure_route, which makes it unusable for this case. This has caused problems for me as well, as it makes it very hard to detect cancellation when working in asynchronous routes that don’t involve SIP messages. Similarly, t_cancel_branch can only be called from onreply_route, which also causes issues with not being able to manage branches with non-SIP async operations. It may be a good feature request to add the ability to use those functions in async resume routes, but for now they will not work.
However, t_relay itself does not ever generate a 500 error back to the client as far as I know. It can only send a 477 response automatically. Are you sure you are not generating the 500 in your script when handling the error from t_relay? The documentation for the function [2] notes that a -3 response from t_relay indicates the request may have already been cancelled. In that case, you can just exit if you know the 487 has already been sent, or you can send a 487 reply yourself. To be honest, I’m not sure where the 487 is coming from in your case since I didn’t think OpenSIPS would automatically respond with a 487 for a cancelled transaction; I have always had to do that from the script myself. So in addition to sending the 500 reply yourself, you may have some code in your script which is also sending the 487.
If none of that works, another option would be to set a flag or an avp in the transaction when processing the CANCEL. Then you can check the flag when you receive the HTTP response and if it is set just don’t call t_relay.
[1] https://opensips.org/docs/modules/3.0.x/tm.html#func_t_was_cancelled<https://opensips.org/docs/modules/3.0.x/tm.html#func_t_was_cancelled>
[2] https://opensips.org/docs/modules/3.0.x/tm.html#func_t_relay<https://opensips.org/docs/modules/3.0.x/tm.html#func_t_relay>
Ben Newlin
From: Users <users-bounces at lists.opensips.org<file:////compose%3fTo=users%252dbounces@lists.opensips.org>> on behalf of Oleg Podguyko via Users <users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>>
Reply-To: Oleg Podguyko <podguiko at mail.ru<file:////compose%3fTo=podguiko@mail.ru>>, OpenSIPS users mailling list <users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>>
Date: Sunday, April 5, 2020 at 6:31 AM
To: users <users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>>
Subject: [OpenSIPS-Users] t_forward_nonack failed
Opensips works like a proxy. Gets an Invite. In the process of processing it, opensips makes a request via http (rest_client module) and receives a response.
Adds the received information to Invite (as X-header) and sends through the dispatcher module to freeswitch.
Everything is working fine.
However, there is a scenario in which everything goes a little wrong.
Opensips receives an Invite, starts processing it, sends a request via http. At this time, Cancel arrives at Invite. The transaction is being destroyed. Opensips sends 200 Cancelling, and then 487. And here comes the response via HTTP, but since the transaction is no longer there, this call ends with an error 500 no route to destination when the t_relay function is executed. In this case, a message appears in the log
/ usr / sbin / opensips [5577]: ERROR: tm: w_t_relay: t_forward_nonack failed.
How to correctly handle such cases in order to prevent such errors in the logs?
--
Oleg Podguyko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200405/8680c7ac/attachment-0001.html<http://lists.opensips.org/pipermail/users/attachments/20200405/8680c7ac/attachment-0001.html>>
------------------------------
Message: 2
Date: Sun, 05 Apr 2020 23:54:29 +1000
From: Michael Vale <masked at vale.ski<file:////compose%3fTo=masked@vale.ski>>
To: David Villasmil <david.villasmil.work at gmail.com<file:////compose%3fTo=david.villasmil.work@gmail.com>>, OpenSIPS users
mailling list <users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] using load balancer and lookup together
Message-ID: <6342fd559df4c9765b17270d07bc04f11ad93b36.camel at vale.ski<file:////compose%3fTo=6342fd559df4c9765b17270d07bc04f11ad93b36.camel@vale.ski>>
Content-Type: text/plain; charset="utf-8"
Ok, to explain,
Using your logic,
To call say '555' will goto Voicemail, if I disable voicemail it will
return a 404 instead of going to the load balancer.
That's fine, if 555 is an extension, but if it's (for this example) a
PSTN number (or a all-else catch all, like I'm trying to achieve) thats
not OK because I get a 404 rather than it getting routed to the load
balancer.
If 555 is an extension/user the call will go through to the registered
extension, but if it's not registered in the usrloc table, it goes to
404, instead of the load balancer.
If I reverse the logic, It will goto the load balancer even if it's a
registered extension, or Too Many Hops, depending on how I adjust the
logic.
I cannot seem to create a catch all for non-usrloc registered extension
calls to goto the load balancer otherwise return a 404.
I hope I explained it well enough. I will keep trying,
Regards,
Michael.
On Sun, 2020-04-05 at 11:47 +0100, David Villasmil wrote:
> Why are you trying to do all at once?
>
> Why not first do the lookup
>
> https://github.com/davidcsi/kamailio-private-public/blob/a81d7f777a8c5ee2dbb32311f7e6b5a3cf94bf32/kamailio.cfg#L771<https://github.com/davidcsi/kamailio-private-public/blob/a81d7f777a8c5ee2dbb32311f7e6b5a3cf94bf32/kamailio.cfg#L771>
>
>
> and then start load balancing?
>
> https://github.com/davidcsi/kamailio-private-public/blob/a81d7f777a8c5ee2dbb32311f7e6b5a3cf94bf32/kamailio.cfg#L1109<https://github.com/davidcsi/kamailio-private-public/blob/a81d7f777a8c5ee2dbb32311f7e6b5a3cf94bf32/kamailio.cfg#L1109>
>
> Do you have some special need to fulfill?
>
> David
> On Sun, 5 Apr 2020 at 06:34, Michael Vale via Users <
> users at lists.opensips.org<file:////compose%3fTo=users@lists.opensips.org>> wrote:
> > hi,
> >
> >
> >
> > perhaps this can be solved with a failure route and or a check
> > status
> >
> > but i dont know and it would be nice if i could do it without it.
> >
> >
> >
> > no matter how i write the script, either a uac to uac call goes to
> > the
> >
> > load balancer or the load balancer is stuck with a 404 reply from
> > the
> >
> > script or uac to uac works but when one end is not registered it
> > goes
> >
> > to the load balancer instead of getting a 404.
> >
> >
> >
> > i've tried failure routes and get the same problem. here is a
> > snippet.
> >
> >
> >
> > if (!lb_start(1,"pstn")) && (!lookup("location","m",)) {
> >
> > lb_disable_dst();
> >
> > #route(relay);
> >
> > #send_reply(404,"No user or gateway");
> >
> > if (lb_start(1,"pstn")) {
> >
> > send_reply(500,"SIPSIPSIPS");
> >
> > # t_relay();
> >
> > exit;
> >
> > }
> >
> > # exit;
> >
> > } else if (lookup("location","m")) &&
> >
> > (!lb_start(1,"pstn")) {
> >
> > lb_disable_dst();
> >
> > route(relay);
> >
> > exit;
> >
> > } else if (lb_start(1,"pstn")) &&
> >
> > (lookup("location","m")) {
> >
> > lb_disable_dst();
> >
> > route(relay);
> >
> > exit;
> >
> > } else if (!lookup("location","m")) &&
> >
> > (!lb_start(1,"pstn")) {
> >
> > send_reply(404,"Not Found");
> >
> > exit;
> >
> > } else if (lb_start(1,"pstn")) &&
> >
> > (!lookup("location","m")) {
> >
> > # #lb_disable_dst();
> >
> > if (!lookup("location","m")) {
> >
> > route(relay);
> >
> > exit;
> >
> > }
> >
> > if (lookup("location","m")) {
> >
> > lb_disable_dst();
> >
> > route(relay);
> >
> > exit;
> >
> > }
> >
> > }
> >
> >
> >
> > thanks in advance,
> >
> >
> >
> > michael.
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > Users mailing list
> >
> > Users at lists.opensips.org<file:////compose%3fTo=Users@lists.opensips.org>
> >
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> >
> --
> Regards,
>
> David Villasmilemail: david.villasmil.work at gmail.com<file:////compose%3fTo=david.villasmil.work@gmail.com>
> phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200405/6ef5eec8/attachment.html<http://lists.opensips.org/pipermail/users/attachments/20200405/6ef5eec8/attachment.html>>
------------------------------
Subject: Digest Footer
_______________________________________________
Users mailing list
Users at lists.opensips.org<file:////compose%3fTo=Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
------------------------------
End of Users Digest, Vol 141, Issue 8
*************************************
--
Олег Подгуйко
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200405/1fae1be8/attachment-0001.html>
More information about the Users
mailing list