Ramin,
Search the archives for serialize_branches(), next_branch(), etc..
First, I think you want to do an enum lookup before the t_relay().
With any luck, the result can be serialized using serialize_branches(),
I haven't tried this, but it makes sense. Then you set
t_on_failure(1) to
catch the subsequent t_relay() failure. Finally, you need to write
failure function to load the next branch (if any) with
next_branches(), set another
on failure, then t_relay().
I looked around in the archives, there are examples with serial/next
with redirect,
but I didn't see any with srv records...should work though.
-g
On 9/21/06, Ramin Dousti <dousti(a)gmail.com> wrote:
On 9/21/06, Steve Blair
<blairs(a)isc.upenn.edu> wrote:
Hi Steve,
In the proxy you can check the status of the
t_relay and take
corrective
action based on the result. Something like
"if (t_check_status("403"))
... do something... " should work. What action you take will depend
upon
> the desired outcome. You could send the call to voicemail, a greeting
> server, a different gateway, etc.
Yes, that's exactly what I'm looking for. But there are some problems
I'm
facing, which most probably is due to my own lack of understanding about
the available knobs:
1- When t-relay() return, the proxy already send the failure notice to
the client. This is not what I want, the "corrective action" must be
transparant
to the user.
Are you defining a failure route before calling t_relay? If so
comment
out the t_on_failure statement. Then from a route block try t_relay
followed by if (t_check_status...) command. Depending upon the result
you may then want to set the t_on_failure route to handle any subsequent
2xx status conditions.
>
> 2- I have two SRV's with the same weight, I do not see any kind of
> round-robin.
> The request goes to only one of them.
>
I did not mean to suggest that SRV would enable round robin. Sorry about
that. I use SRV records in the way I described to provide failure over
on initial invite. It works well but it will not handle round robin.
You may want to try a redirect. Have the phone register to a server
which can replicate the registration to other servers. Then when the
primary receives the initial invite reply with a redirect statement to
instruct the phone to try another proxy. Replication should eliminate
any registration questions. You will need to develop a weighting
algorithm which can be shared across all proxy servers. I think a 305
Use Proxy response should be sufficient to handle the redirect.
-Steve
Here is the
(probably faulty) config:
route {
...
rewriteport ("");
#t_on_failure("1");
xlog("L_INFO", "Got the call\n");
if (! t_relay()) {
if (t_check_status("(403|487)|(408|477)")) {
xlog("L_ERR", "initial call failed\n");
if (t_newtran()) {
xlog("L_ERR", "Let's try again\n");
t_relay();
}
}
}
...
}
Can you help?
Ramin
In the phones you can use SRV records to present
a weighted list of
proxy servers. The phone would register to a domain name which is a
SRV
record. This record resolves into the A records
for each viable proxy.
You could weight and prioritize the A records thereby giving the
phones
an ordered list of servers to try.
-Steve
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@net.isc.upenn.edu