Gabe,
I'm the guy with the three SER boxes. All three SER boxes are active. Polycom
phones point to a DNS domain with SRV lookups for all outbound requests. The
SRV queries return the three SER boxes. The three boxes authenticate a user and
then store the user in it's 'location' database before using the send() command
to forward the registration to all three asterisk systems (as well as the
voicemail server). Each SER box is configured with a different
primary/secondary teriaty asterisk host. Failover times are only a few seconds.
By storing the user in SER's location database, we can still route SUBSCRIBE,
NOTIFY and MESSAGE requests and by having every phone provisioned on every
Asterisk box, any asterisk box can go down, and the two other will seamlessly
terminate the call. Oh yeah, almost forgot... Asterisk doesnt send the calls
back to SER... It terminates the calls directly. Yes, SER uses a common central
MySQL database, but at least MySQL has the facility to manage that (ie
replication or clustering) where Asterisk doesn't.
We're having a bit of a security issue with this config, that we have to work
out, but I'd better not go into too much detail on that.
Doug.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thu 3/16/2006 10:30 PM
To: [email protected]
Cc:
Subject: RE: [Asterisk-Users] Feedback from VON
expo!Infoon*HAandPolycomphone!!
Hey,
You know, the Digium guys said both are good. They said the the DNS
method is better because you dont have the extra point of failure (SER) but
said the SER method is better in that it gives you more exact control in the
handling of the calls and registration.
They did acknowledge there would be a possible downtime only for
incoming calls to users with dynamic IPs if the server they are registered to
fails. The downtime would only be the time until the next registration (up to
1 min. max if your reg expiration is set to 1 minute).
My idea was to have * check if the channel is available before
making the call. If it is, then all is good. If unavailable, send to n+101
which can call to an alternative phone number (i.e. Cell phone). This could be
the backup solution for incoming calls. Of course the Polycom pho nes will not
have any problems sending outgoing calls in the event of a failed registration
server.
..::THE BIG QUESTION::..
=> How would this be any different for a config using SER? If your SER
box fails, wouldn't all the phones have to re-register to the backup SER box?
I mean, even if you fail-over the IP and everything else between the
active/passive servers, do all the SER servers share registration info?
=> For the guy saying he has 3 SER boxes, are all 3 active or is it an
Active box with two backups?
=> If they are all active...are they exact replicas that share all
the info between eachother (which I wish * did well)
Based on this I think I will know where to do the DNS/DUNDi setup or
the SER setup.
- Gabe
>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.
>
>-----Orig inal 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 wh ere 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 cal ls
> > > 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 ca n 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
>
_______________________________________________
--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
