Re: [Users] redundancy

[Steve Blair]

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 <[EMAIL PROTECTED]> wrote:

On 9/21/06, Steve Blair <[EMAIL PROTECTED]> 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




--
 
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:[EMAIL PROTECTED]


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