[OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

[Ben Newlin]

It’s also important to note that the onreply_route you are using is the global reply route that is always called for all replies. This is why it is being called even though you did not arm a reply route using t_on_reply. If you don’t wish to do any processing at that stage, simply do not implement the route. If you implement it, it will always be called.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Bogdan-Andrei Iancu <bogdan at opensips.org>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Friday, October 13, 2017 at 10:08 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>, Blagovest Buyukliev <blagovest at voipfone.co.uk>
Subject: Re: [OpenSIPS-Users] Intercepting a 302 response and dispatching an INVITE to a new destination set

Hi,

As Alex said, in failure_route (for calls via dispatcher) test for a 3xx reply and if the case simply set a new RURI (as you normally do when routing requests) and do t_relay() again - by sending the call out to a new destination, the received 3xx will be automatically discarded.

Regards,


Bogdan-Andrei Iancu

  OpenSIPS Founder and Developer

  http://www.opensips-solutions.com<http://www.opensips-solutions.com>
On 09/07/2017 08:34 PM, Blagovest Buyukliev wrote:
The onreply_route is never armed, but gets executed.

The failure_route[initial_request] is armed via t_on_failure("initial_request") and actually gets executed after the onreply_route (as per my last test).

Can we stop the propagation of the 302 from within failure_route, or is it considered already sent after the execution of onreply_route?

On Sep 7, 2017, at 8:12 PM, Alex Balashov <abalashov at evaristesys.com<mailto:abalashov at evaristesys.com>> wrote:

Don't arm the onreply_route. Doesn't the failure_route get called?

On September 7, 2017 1:08:55 PM EDT, Blagovest Buyukliev <blagovest at voipfone.co.uk<mailto:blagovest at voipfone.co.uk>> wrote:

Which functions need to be used for that?

The current routing logic is roughly what's listed below and the
problematic issues are commented.

How can it be modified to accomplish what you've described?

route {
  ...
  loose_route();
  record_route();
  t_on_failure("initial_request");
  t_relay();

  # We are okay here, the initial INVITE is passed to a local server.
}

onreply_route {
  if ($rs == 302) {
# The 302 is caught here, but we are pretty much handicapped to do
anything in this block.
# The response is passed back to the external network, which is
undesired.
  }
}

failure_route[initial_request] {
# How can we arrive here right upon the receipt of the 302, not in
onreply_route?
}


On Sep 5, 2017, at 4:54 PM, Alex Balashov <abalashov at evaristesys.com<mailto:abalashov at evaristesys.com>>
wrote:


Yes, failure_route is the answer to all your objectives here. You can
intercept the 302, extract what you want from it, create a new branch
and fork the call elsewhere.

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/<http://www.evaristesys.com/>, http://www.csrpswitch.com/<http://www.csrpswitch.com/>

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

-- Alex

--
Sent via mobile, please forgive typos and brevity.

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>





_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171013/bd7dbec4/attachment.html>