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 <[email protected]> on behalf of Oleg Podguyko via Users <[email protected]> Reply-To: Oleg Podguyko <[email protected]>, OpenSIPS users mailling list <[email protected]> Date: Sunday, April 5, 2020 at 2:01 PM To: "[email protected]" <[email protected]> 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 от [email protected]: Send Users mailing list submissions to [email protected]<file:////compose%[email protected]> 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 [email protected]<file:////compose%3fTo=users%[email protected]> You can reach the person managing the list at [email protected]<file:////compose%3fTo=users%[email protected]> 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 <[email protected]<file:////compose%[email protected]>> To: Oleg Podguyko <[email protected]<file:////compose%[email protected]>>, OpenSIPS users mailling list <[email protected]<file:////compose%[email protected]>> Subject: Re: [OpenSIPS-Users] t_forward_nonack failed Message-ID: <[email protected]<file:////compose%3fTo=00be023f%252dda3a%252d45ee%252d988f%[email protected]>> 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 <[email protected]<file:////compose%3fTo=users%[email protected]>> on behalf of Oleg Podguyko via Users <[email protected]<file:////compose%[email protected]>> Reply-To: Oleg Podguyko <[email protected]<file:////compose%[email protected]>>, OpenSIPS users mailling list <[email protected]<file:////compose%[email protected]>> Date: Sunday, April 5, 2020 at 6:31 AM To: users <[email protected]<file:////compose%[email protected]>> 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 <[email protected]<file:////compose%[email protected]>> To: David Villasmil <[email protected]<file:////compose%[email protected]>>, OpenSIPS users mailling list <[email protected]<file:////compose%[email protected]>> Subject: Re: [OpenSIPS-Users] using load balancer and lookup together Message-ID: <[email protected]<file:////compose%[email protected]>> 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 < > [email protected]<file:////compose%[email protected]>> > 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 > > > > [email protected]<file:////compose%[email protected]> > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users> > > > -- > Regards, > > David Villasmilemail: > [email protected]<file:////compose%[email protected]> > 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 [email protected]<file:////compose%[email protected]> 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 ************************************* -- Олег Подгуйко
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
