Hi Antoine,

Unfortunately the site is unavailable (I'll keep trying).

On the same token, I need to have some kind of redundancy. Someone on the list recommended the usage of NAPTR, SRV for that matter but as Bogdan pointed out that mechanism does not support automatic failover in its current state.

Let me re-iterate my question, is there any way I could implement the failover mechanism based on the DNS A records within the configuration file. I've been going through the documentations and been unable to spot such a setting. Does anyone have any configuration snippet that shows how to "try this destination first, if the destination is unreachable, then try that destination". Please note that the failover I'm looking for is only with regards to the IP-connectivity failure, meaning if the next hop is not there I want to failover, and not if the transaction to the next hop fails with some legitimate return code.

Thanks everyone for your time/help.

Ramin

On 9/20/06, Antoine Fressancourt af.devlist@gmail.com wrote:

I don't really know if it can help, but Jan Janak made a presentation at the last FOSDEM about such redundancy problematics. It is available at : http://www.iptel.org/jan/

I hope it helps a bit...

Antoine

Le 19 sept. 06 à 20:38, Ramin Dousti a écrit :

...

Hi,

A SIP INVITE to sip.mydoamin.com with sip.mydomain.com having two A- RR's, must be forwarded to the first IP and if that IP is unreachable then to the second IP. How can I achieve this?

My first problem is that I seem to not have the list of the two IP's available to me via a configuration key-word. So I need to hardcode the IP's in my conf file.

My second problem is I don't know how to iterate over these two IP's. Maybe I can use t_on_failure() and have the second IP processed in the failure_route[]. But then again, how can I distinguish between a timeout and a legitimate failure?

Thank you in advance,

-- Ramin

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

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.

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.

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

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