[OpenSIPS-Users] t_forward_nonack failed

Ben Newlin Ben.Newlin at genesys.com
Sun Apr 5 13:11:34 EST 2020


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 <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 6:31 AM
To: users <users at 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.html>


More information about the Users mailing list