[Asterisk-Users] Feedback from VON expo! Info on*HAandPolycomphone!!

[Gabriel Afana]

> > "Q:  What are the plans for HA?
> > That's BS. Last time I checked, Asterisk's support of SRV was
> > to only grab the first SRV entry. Period. If it doesn't try
> > any more SRV hosts after the first fails, just exactly how is
> > that redundant?
>
> This is for the phones to fail over NOT Asterisk, remember in
> this case
> Asterisk has died so no matter what order it 'resolves' it
> doesn't mater
> in this case.
>I disagree. Our Asterisk boxes talk to a proxy server in certain 
>situations. If those proxy servers where in a domain as SRV records, and 
>one of them failed, Asterisk should try each of them in an order >defined 
>by the priority and weight.

Yes, but like Alexander said, this scenerio was for the polycom to do the 
SRV lookup, not *.  For me, the only time I will need * to do a lookup is 
when to hand a call off to a carrier for termination.



> > "Q:  Whats the best way to program the phone to handle failover?
> >     A:  Use a DNS-SRV address for the primary server.  When
> > the phone queries the DNS server, it will receive a list of
> > all the possible servers "
> >
> > This is broken to some degree. When the phone refreshes it's
> > cache, and grabs the list of SRV servers again, it will
> > continue to use them in the same manner until it refreshes
> > it's cache again, or there is a failure, even when all SRV
> > hosts have the same priority and weight. It should round
> > robin in this case.
>
> Agreed.

This is how the polycom guy explain it.  Lets say you do an srv lookup and 
get:

sip1.test.com
sip2.test.com
sip3.test.com
sip4.test.com

The phone will try to register with sip1.test.com.  If it is successful, 
great.  If not, continue to sip2.test.com, then sip3, sip4 and then back 
again to sip1 and it will cycle untile it can find a server to register 
with.  Now lets say you are registered to sip1.test.com, if you pick up the 
phone to make a call, it will try to send it to sip1.test.com.  If the call 
fails to go through, the phone will then try to send the call through sip2, 
then sip3, sip4..until it can make the call (just like for registration). 
This will not cause it to re-register however.  It will not register until 
its registration expires and it has to re-register.  At this time it will 
refer back to the same SRV lookup and continue through the list.

I just thought now that this could cause issues because if all phones get 
the SRV lookup saying sip1, sip2, sip3 and sip4 in that order, all phones 
will register to sip1 if they can.  If the priority and weight is set the 
same, will the SRV lookup return these servers in a round-robin or even 
random way?




> > And in regards to Asterisk HA, and approach #2. If you have
> > your SER boxes use the send() command to stateless forward
> > registrations, you can send registrations from the phones to
> > ALL your Asterisk systems so that every Asterisk box knows
> > about every phone, and every Asterisk box can route calls
> > from/to any phone.
> >
>
> Then you have issues with hints, voicemail, and other features.
> Hints, voicemail and other features, to this point, are all working fine. 
> The OpenSER systems routes SUBSCRIBE/NOTIFY/MESSAGE etc messages to /from 
> the phones (we keep a copy of the > >registration in the OpenSER 
> 'location' table just for this). As far as voicemail is concerned, the 
> OpenSER system also uses send() to send the registration to the voicemail 
> server.

I would rather stay away from SER if I can because its complicated to get 
setup (no big deal though), but it ads another layer to the process and 
creates a single point of failure.  You can have a few SER machines in a 
linux cluster to fail-over, but this can take up to several seconds and is 
unacceptable since doing this time, *no* calls can go in or out.  At least 
with the DNS model, you know a DNS lookup will work (just have a primary, 
secondary...etc - something will work) and if a server fails, it doesn't 
criple the whole service.

- Gabe