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
