I did not think so much about watching URIs, rather just keeping some internal status associated with transaction in progress.
A possibility would be to cascade through failure_routes:
failure_route[1] { t_on_failure(2); # if this fails, try 2 ... }
failure_route[2] { t_on_failure(3); # if this fails, try 3 ... }
etc.
Other possibilty I thought of would be
route[1] { ... setflag(1); # state == 1 t_relay(); ...
failure_route[1] {
if (isflagset(1)) { # try 2 resetflag(1); setflag(2); break; }; if (isflagset(2)) { # try 3 resetflag(2); setflag(3); break; }; ...
-jiri
At 03:21 AM 7/14/2004, Michael Przybylski wrote:
I was thinking along the lines of using the textops.so search() function.
Will that let me see what "Contact" headers have already been appended as branches?
Best regards, Mike Przybylski
On Wed, 14 Jul 2004, Jiri Kuthan wrote:
A possibility to keep status would be to use flags -- a poor variable substitute till support for variables appears.
-jiri
At 10:14 PM 7/13/2004, Michael Przybylski wrote:
Hello everyone,
I've got a recursing failure_route block that I'm trying to usefor voice over IP gateway failover. The recursion bit works without any problem, but I could really use some hints on examining the branches appended by previous calls to the failure route so that it can know when to stop.
Here's the pseudo-code version of what I'm trying to do.if(examing previously appended branches shows IP of last-chance gateway already there){ give up; }
Any suggestions would be greatly appreciated.Best regards, Mike Przybylski
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/