On 10/11/06, Douglas Garstang <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: C F [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 11, 2006 10:59 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] How big is *your* dialplan??
>
>
> Douglas, it seems to me that you don't understand how the extensions
> of an asterisk dialplan relate to real life. As an example:
> -= 135 extensions (657 priorities) in 31 contexts. =-
> This from a box (yes one box) that has just 10 phones, and 6 lines.
> Every s extension is considered an extension. Which makes every macro
> a context and at least one extension. If one has:
> exten => s,n,Dial(whatever)
> exten => s,n,Goto(s-${DIALSTATUS},1)
> Then that context (macro) has at least 2 extensions.
> Calling Voicemail in my dialplan has 7 extensions (yes just pressing
> the message button). For real life it's only 1 extension.
I understand how asterisk extensions relate to real life perfectly fine.
>
> Another example:
> This is for a system with around 75 different offices hosted on the
> same box, using 3 T1s, and each office with at least 2 extensions, the
> biggest one being around 15 extensions.
> -= 1110 extensions (2279 priorities) in 138 contexts. =-
Ok.
>
> That's for around 90 phones and 150 published active phone numbers
> (some of the phone numbers are just IVRs). Why would the fact that
> it's on one box matter? If the main incoming T1 is down (which
> happens), there is no incoming calls anyhow. What would clustering
> help in this case?
You are looking at this from an Enterprise level, not a carrier level. Have you
ever heard of NFAS? We have multiple IP-SIP/PSTN gateways connected to our
Lucent 5E switch. It allows a T-1 to go down, and we still have connectivity to
our 5E switch. What about calls from phones on the IP side? If the Asterisk box
they are pointing to dies, you want another Asterisk box to be able to service
its calls and therefore you need some form of redundancy.
OK, I'll agree with you that I'm looking at a point of view from
Enterprise lever and not carrier level, BTW, NFAS for redundancy is in
most cases a waste of money (again enterprise POV), since if one T1 is
down usually all of them from the same provider will be down.
The fact that they you have multiple IP-SIP/PSTN gateways should not
imply that you can't have 16k extens on all of them.
I agree that if an asterisk box dies (I don't know how such a thing in
a well controlled stable system will happen, but I guess with a bug in
an agi it could happen, then that will be another reason not to use
AGIs for me) you need another one to take over, but again why would it
die to begin with?
>
> Why would someone have to build a new box if a system went down? A
> system should never be built with a single point of failure. The only
> thing that should be allowed to bring down a system is a fire. The CPU
> fan should be noticed making noise way before it dies, which gives
> enough time for a planned shutdown, in any case that doesn't require
> (if/when the CPU dies) rebuilding the whole box.
> Any asterisk system that has more than 50-60 users should NEVER be
> built in a way that if it doesn't get physically damaged it needs to
> be rebuilt if/when it goes down.
Are you serious? Would you really just wait until a system looked like it was
on shaky ground before deciding to build a new one? What about if some other
component failed? What about the myriad of other failures you didn't think of
ahead of time? Do you really think that it's ok for a system that hosts less
than 50-60 users to be unavailable while a new system is built? We're talking
about VOICE service here, not someones email access. People can do without
email for a period of time but they are very sensitive to a lack of dialtone.
No, you didn't read it quite well. what I said was, it should never
reach a state that it is on shaky ground, it should be well
maintained.
What other component could or fails out of the blue? Surge protection
with even a cheap UPS will protect from lightening. Motherboards in a
well regulated maintained system that is ventilated good, don't just
die. Hard drives should be installed in an array (have you ever heard
of RAID). CPUs when the heat is taken care of, don't just die. It's
something one can see before hand that something is wrong with it,
like temperature monitoring. Memory if the right motherboard is used,
and you have more than one bank, it will just isolate the bad bank.
PRI cards if the proper surge protection is on it (and if it's after
fiber the surge is not so important) it shouldn't die, an extra one
around for at least the vital T1 in a big system (more than one T1) is
again a most. Power supply, have you ever heard of Dual Power Supply?
So I ask you, what component could fail in a way that it should take
more than an hour to bring it back up?
Less than 50-60 users, again most of the problems could be worked out
and seen before they happen on even the cheapest system. The only
thing that usually does fail quickly (after 2-4 years in a not so well
ventilated system) is the HDD, did you know that Panasonic, Avaya,
Toshiba, NEC and almost every other provider out there use Proprietary
HDDs that take at least 24 hours to replace? While with an asterisk
system you just take a not so important computer yank the HDD out of
it and you are up and running in around an hour, and that's only if
it's Sunday evening, on Monday you can actually buy a brand new HDD in
less than 20 minutes?
What about load? Asterisk can supposedly handle about 120 calls. What happens
when you get more than about 1000 provisioned users (assuming a 10/1 ratio)?
Asterisk has no ability to stop taking new calls, and will keep taking new ones
until the load makes the quality of calls unacceptable. A cluster can spread
out load between multiple boxes and alleviate this problem.
Wow, what ever happened to SetGroup and CheckGroup? that will make
sure that it does stop taking calls by 120. and BTW, where did you
take those numbers from? Have you done some benchmarking?
Btw, I showed this email to a senior telecom guy here in the office. Initially
his eyes widened, and then he laughed and said he'd certainly never get you to
build his telecom infrastructure.
BTW, I'm not looking for a job. I wouldn't work for your boss anyhow,
and the senior guy working with you, judging from you, he doesn't seem
to be good at judging people.
Doug.
> On 10/11/06, Douglas Garstang <[EMAIL PROTECTED]> wrote:
> > I see some awefully large dialplans here. Are people
> putting all this on one box or clustering it amongst a number
> of boxes? I think any business is going to be pretty annoyed
> if they suddenly lost access to 16,000+ extensions, and had
> to wait for a new box to be built and configured.
> >
> > -----Original Message-----
> > From: George Pajari [mailto:[EMAIL PROTECTED]
> > Sent: Tue 10/10/2006 10:48 PM
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Cc:
> > Subject: Re: [asterisk-users] How big is *your* dialplan??
> >
> >
> >
> > Single server, dual P3 866Mhz, 1.5Gb, TE407P, two
> PRIs to telco, one PRI
> > to fax server, one PRI to T.38 gateway:
> >
> > 1791 extensions (4378 priorities) in 240 contexts
> >
> > --
> > George Pajari, netVOICE communications 604 484
> VOIP (484 8647 x102)
> > Open Source VoIP/Telephony Specialists 1 877 NET
> VOIP (638 8647 x102)
> > Hosted IP PBX Services for SOHO & Small Businesses
> - www.ip-centrex.ca
> > VoIP Service, Equipment, Systems, and Consulting -
www.netvoice.ca
>
> _______________________________________________
> --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
_______________________________________________
--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
