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
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.
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
Don't arm the onreply_route. Doesn't the failure_route get called?
On September 7, 2017 1:08:55 PM EDT, Blagovest Buyukliev
wrote:
>Which functions need to be used for that?
>
>The current routing logic is roughly what's listed below and the
>problematic issues are
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");
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:
Hello,
We are using OpenSIPS 2.3.1 as a proxy to dispatch requests between an external
network (referred to as "EN") and a few different destination sets of local SIP
servers (referred to as "LS1", "LS2", "LS3", etc.).
The basic architecture looks like this:
EN <-> OSIPS <-> (LS1, LS2, LS3,