Grrr. I'm using outlook web access and there's no way to do inline replies.
Anyway...
Gabriel.
Using SER does not create a single point of failure. You install three SER
boxes. Single point of failure gone.
It does not take several seconds.
If your phones are configured for SRV, and 2/3 of your SER boxes down, it takes
about 2s. That's not bad for a 2/3 system failure. You can also configure the
timeout and number of retries at least on the Polycom phones. You can make this
value as small as you want. You can also configure the timeout on SER. With
testing of 3 SER systems and 3 Asterisk systems, we've seen a pause of 5s when
2 of the SER boxes where down and 2 of the Asterisk boxes where down. That's
not slow
Not sure I quite follow about the whole service thing being down. :)
But your right about it being friggin complicated to set SER up.
-----Original Message-----
From: Gabriel Afana [mailto:[EMAIL PROTECTED]
Sent: Thu 3/16/2006 11:15 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc:
Subject: Re: [Asterisk-Users] Feedback from VON expo! Infoon*HAandPolycomphone!!
> > "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
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
