[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 <dousti at gmail.com> wrote:
>
>> On 9/21/06, Steve Blair <blairs at 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 at 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 at net.isc.upenn.edu