asterisk@gafana.com
2006-Mar-16 22:30 UTC
[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 phones 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.
>
>-----Original Message-----
>From: Gabriel Afana [mailto:asterisk@gafana.com]
>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20060316/15b7c9ca/attachment.htm
Douglas Garstang
2006-Mar-16 23:19 UTC
[Asterisk-Users] Feedback from VON expo!Infoon*HAandPolycomphone!!
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: asterisk@gafana.com [mailto:asterisk@gafana.com] Sent: Thu 3/16/2006 10:30 PM To: asterisk-users@lists.digium.com 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:asterisk@gafana.com] >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 >