Greg Fausak wrote:
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@gmail.com wrote:
On 9/21/06, Steve Blair blairs@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users