I tried to use flags, it doesn’t work too. You a right, the way of ability to detect this by allowing «t_was_cancelled» at the any «routes» is a best way. I will open a issue. Thanks again for your reply! >Воскресенье, 5 апреля 2020, 22:15 +03:00 от Ben Newlin ><[email protected]>: > >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] >> >>To subscribe or unsubscribe via the World Wide Web, visit >>http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>or, via email, send a message with subject or body 'help' to >>[email protected] >> >>You can reach the person managing the list at >>[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] > >>To: Oleg Podguyko < [email protected] >, OpenSIPS users mailling list >>< [email protected] > >>Subject: Re: [OpenSIPS-Users] t_forward_nonack failed >>Message-ID: < [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 >>[2] https://opensips.org/docs/modules/3.0.x/tm.html#func_t_relay >> >>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 6:31 AM >>To: users < [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 >> > >> >>------------------------------ >> >>Message: 2 >>Date: Sun, 05 Apr 2020 23:54:29 +1000 >>From: Michael Vale < [email protected] > >>To: David Villasmil < [email protected] >, OpenSIPS users >>mailling list < [email protected] > >>Subject: Re: [OpenSIPS-Users] using load balancer and lookup together >>Message-ID: < [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 >>> >>> >>> and then start load balancing? >>> >>> >>> 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] > 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] >>> > >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> > >>> -- >>> Regards, >>> >>> David Villasmilemail: [email protected] >>> phone: +34669448337 >>-------------- next part -------------- >>An HTML attachment was scrubbed... >>URL: < >>http://lists.opensips.org/pipermail/users/attachments/20200405/6ef5eec8/attachment.html >> > >> >>------------------------------ >> >>Subject: Digest Footer >> >>_______________________________________________ >>Users mailing list >>[email protected] >>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
