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
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
