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 use
for 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan
http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan
http://iptel.org/~jiri/