Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Michel Verbraak]

Please also have a look at the gateway boxes from berofix
(http://wiki.beronet.com/index.php/Main_Page). I am not affiliated but
have used different products from them over last few yeas and all have
survived and are stable.

Documentation is open and free on their wiki. They provide updates. They
are not the cheapest but they have different vendors and they are sold
in online webshops. You can choose for the inside PCI(e) cards or their
external boxes. Last few years I went for the external boxes. They can
be fitted in a server rack or you mount them against the wall with screws.

Regards,

Michel.

On 16-06-13 16:55, Nunya Biznatch wrote:
> Thanks again to everyone that's responded thus far. I have once again
> bundled the questions and answers into a single email, and am
> responding below.
>
>
> On 6/14/2013 9:43 AM, Nunya Biznatch wrote:
>> Howdy All,
>>They say opinions are like belly buttons, everybody has one.
>> (that's the "clean" version of the saying). So I'm asking for yours.
>> I hope you see it as a fun exercise.
>>
>> I'm designing a phone system from the ground up. Will be about
>> 1000-1300 seats mixed 80/20 VoIP/Analog. 58-acre campus environment
>> with 23 buildings. Userbase is emergency services organization,
>> 24/7/365 operation. Down time is not an option, but "blips" are
>> acceptable. Repair time is immediate. We need failover for the
>> failover essentially. However, money is a major factor, so I have to
>> do it all for nothing. So here's what I'm thinking. Please throw in
>> your 2 cents.
>>
>> Network will be separate for phones. Fiber infrastructure available
>> between buildings as well as copper. Internet access will be limited
>> to a single administrative console on a temporary basis, and then
>> only when remote 3rd party support is required. Access for 3rd party
>> support will be supervised through remote access tools such as VNC,
>> GoToMeeting, etc... etc... System will have zero access to local data
>> network. This means all ancillary support servers such as DHCP, DNS,
>> NTP, FTP, etc...etc... will be specific to the phone system. Yes, I
>> know some responders at this time will become fixated on me gaining
>> this connectivity. It ain't gonna happen. It's not an option. Period,
>> end of story. These are the parameters I must work within. Trying to
>> "fix" that will be a non-starter.
>>
>> The phone system will upgrade an existing TDM-based system. Mitel
>> SX2000 with NuPoint Voicemail. This will not be a dump-trunk
>> replacement. I expect at least a one to two-year transition, meaning
>> we will have time to find problems,  work bugs, and learn over time,
>> with minimized impacts. It also means we'll be supporting two systems
>> for some time.
>>
>> PBX is 97% serving your basic phone on the desk. Nothing special.
>> Customers expect the usual list of features. There will be a goodly
>> number of hints required for BLF on maybe 150 phones. There is one
>> office of about 30 phones in a call-center environment that will need
>> that service. They would be considered low volume (but don't tell
>> them that).
>>
>> My Skills... I am not a Linux kung fu master, but I have built and
>> managed my share of Linux servers on mutiple Linux flavors. I am a
>> DCAA, having been through formal training, and have been playing with
>> Asterisk for years, but always in fits and spurts and never in a live
>> environment so I am by no means a kung fu master there either. I have
>> started dabbling with virtualizations via XEN, but I am not
>> comfortable enough with it to go live this first round. I can see
>> myself implementing it in about three years once we're totally
>> comfortable with what we have, so I can then have time to get that
>> skill sorted. I was a network engineer for the US no3. telecom for a
>> number of years, 10-years in comm-electronics in the military before
>> that. Telecom my entire career. I've got the kung-fu to handle the
>> network side of the house, and having administrated multiple PBXs for
>> decade-plus, I've got the concepts down.
>>
>> No plans to build databases for things like directories, etc... I'm
>> not greatly confident in those skills, and to date, haven't found
>> anything that really stands out that would make me require that. You
>> may think otherwise, so please chime in. I say that, but at the same
>> time I recognize I may require a GUI interface once fully deployed to
>> allow lower-skilled people to follow the motions to complete simple
>> moves, adds, and changes. I'm fighting the uphill battle that is the
>> "GUI is new, CLI is old" mentality.
>>
>> System will use G.722 for VoIP Phones.
>>
>> So there's the groundwork. Here's the hardware plan.
>>
>> Plan is to build my own servers following industry standards (ATX)
>> and using industry standard equipment. Why? Spares? Whether redundant
>> or not, I will still have spares for the most common elements on the
>> shelf so equipment can be returned to service as quickl

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Michel Verbraak]

Please also have a look at the gateway boxes from berofix
(http://wiki.beronet.com/index.php/Main_Page). I am not affiliated but
have used different products from them over last few yeas and all have
survived and are stable.

Documentation is open and free on their wiki. They provide updates. They
are not the cheapest but they have different vendors and they are sold
in online webshops. You can choose for the inside PCI(e) cards or their
external boxes. Last few years I went for the external boxes. They can
be fitted in a server rack or you mount them against the wall with screws.

Regards,

Michel.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Nunya Biznatch]

Thanks again to everyone that's responded thus far. I have once again 
bundled the questions and answers into a single email, and am responding 
below.



On 6/14/2013 9:43 AM, Nunya Biznatch wrote:

Howdy All,
   They say opinions are like belly buttons, everybody has one. 
(that's the "clean" version of the saying). So I'm asking for yours. I 
hope you see it as a fun exercise.


I'm designing a phone system from the ground up. Will be about 
1000-1300 seats mixed 80/20 VoIP/Analog. 58-acre campus environment 
with 23 buildings. Userbase is emergency services organization, 
24/7/365 operation. Down time is not an option, but "blips" are 
acceptable. Repair time is immediate. We need failover for the 
failover essentially. However, money is a major factor, so I have to 
do it all for nothing. So here's what I'm thinking. Please throw in 
your 2 cents.


Network will be separate for phones. Fiber infrastructure available 
between buildings as well as copper. Internet access will be limited 
to a single administrative console on a temporary basis, and then only 
when remote 3rd party support is required. Access for 3rd party 
support will be supervised through remote access tools such as VNC, 
GoToMeeting, etc... etc... System will have zero access to local data 
network. This means all ancillary support servers such as DHCP, DNS, 
NTP, FTP, etc...etc... will be specific to the phone system. Yes, I 
know some responders at this time will become fixated on me gaining 
this connectivity. It ain't gonna happen. It's not an option. Period, 
end of story. These are the parameters I must work within. Trying to 
"fix" that will be a non-starter.


The phone system will upgrade an existing TDM-based system. Mitel 
SX2000 with NuPoint Voicemail. This will not be a dump-trunk 
replacement. I expect at least a one to two-year transition, meaning 
we will have time to find problems,  work bugs, and learn over time, 
with minimized impacts. It also means we'll be supporting two systems 
for some time.


PBX is 97% serving your basic phone on the desk. Nothing special. 
Customers expect the usual list of features. There will be a goodly 
number of hints required for BLF on maybe 150 phones. There is one 
office of about 30 phones in a call-center environment that will need 
that service. They would be considered low volume (but don't tell them 
that).


My Skills... I am not a Linux kung fu master, but I have built and 
managed my share of Linux servers on mutiple Linux flavors. I am a 
DCAA, having been through formal training, and have been playing with 
Asterisk for years, but always in fits and spurts and never in a live 
environment so I am by no means a kung fu master there either. I have 
started dabbling with virtualizations via XEN, but I am not 
comfortable enough with it to go live this first round. I can see 
myself implementing it in about three years once we're totally 
comfortable with what we have, so I can then have time to get that 
skill sorted. I was a network engineer for the US no3. telecom for a 
number of years, 10-years in comm-electronics in the military before 
that. Telecom my entire career. I've got the kung-fu to handle the 
network side of the house, and having administrated multiple PBXs for 
decade-plus, I've got the concepts down.


No plans to build databases for things like directories, etc... I'm 
not greatly confident in those skills, and to date, haven't found 
anything that really stands out that would make me require that. You 
may think otherwise, so please chime in. I say that, but at the same 
time I recognize I may require a GUI interface once fully deployed to 
allow lower-skilled people to follow the motions to complete simple 
moves, adds, and changes. I'm fighting the uphill battle that is the 
"GUI is new, CLI is old" mentality.


System will use G.722 for VoIP Phones.

So there's the groundwork. Here's the hardware plan.

Plan is to build my own servers following industry standards (ATX) and 
using industry standard equipment. Why? Spares? Whether redundant or 
not, I will still have spares for the most common elements on the 
shelf so equipment can be returned to service as quickly as possible. 
This will also allow me to be comfortable with more "basic server" 
configurations and help keep cost down. For example, Servers with 
single power supplies vs. dual. Also, components will be standardized 
for all equipment to aid in supply requirements.


First the layout.

2-servers acting as gateways. Each handling 2 PRIs for outside trunks. 
They'll also handle the analog ports. Failover will be in the form of 
degraded trunk access if one should fail, but the second will be able 
to support services in degraded fashion.


2-servers acting as VoIP PBX. A primary and a spare. Meaning one will 
be capable of handling the load of the entire system, and the other 
will pickup when the other dies, an active/passive cluster. Will also 
take care of voicemail. Use of heartbeat, pac

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Daniel Tryba]

On Sat, Jun 15, 2013 at 10:28:50AM -0600, Nunya Biznatch wrote:
> Answer - There's a couple reasons I'm thinking this way, which may be
> misguided so thanks for making me think about it. First is redundancy.
> Offloading the PRIs and analog phones from the primary PBX means if
> there's an issue, I can take one of those PRI boxes down and not
> affect the PBX, and the other PRI box will continue to provide
> trunking services. Only the analog lines on that specific PRI box
> would be impacted. Second, I know I'll be transcoding G.711 to G.722
> on those machines, 46 PRI channels, and 48 analog lines. I've been
> unable to find anything solid that gives me a definitive idea as to
> how much horsepower I need. 

If you do it correctly (g722 as primary codec and fallback to g711) and
only accept g711 on the pri machines it costs you next to nothing. You
can't buy a new machine to slow for the job of filling those channels by
just bridging. But like others noted, you should really look into some
device to handle that for you. My choice of hardware is Patton
SmartNodes. They aren't cheap but in the past 8 years I have only seen 1
die (bad PSU).

You didn't mention it yet, but will there be recordings of calls?
Monitoring calls will keep the PBX in the loop. And I have been stung by
bad controllers resulting in bad performance (HP cciss comes to mind
with Debian/squeeze).


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Chris Bagnall]

On 15/6/13 7:00 pm, Carlos Alvarez wrote:

Interesting product that I was very interested in, but the licensing has
one huge glaring problem.  Be sure to read the FAQ carefully.  If your
hardware fails and you replace almost anything in the machine, you have to
pay for the product again.


Not to mention that installing Pacemaker/Heartbeat/Corosync or your 
other HA solution of preference isn't particularly difficult, and is 
agreeably free.


Kind regards,

Chris
--
This email is made from 100% recycled electrons

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Carlos Alvarez]

Interesting product that I was very interested in, but the licensing has
one huge glaring problem.  Be sure to read the FAQ carefully.  If your
hardware fails and you replace almost anything in the machine, you have to
pay for the product again.


On Sat, Jun 15, 2013 at 10:42 AM, Michelle Dupuis  wrote:

>  ...
>
> For redundant/failover of Asterisk checkout HAAST at www.generationd.com
> The HAAST product sits between Linux and Asterisk, monitors for failures
> etc, and then fails over to another Asterisk box.  It effectively creates a
> low-cost cluster, moving IP's etc to active peer.  It runs with most Linux
> and Asterisk distro's, and avoids the issues of single point of failure.
> etc.
>
> Michelle
> (generationD)
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
>



-- 
Carlos Alvarez
TelEvolve
602-889-3003
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Michelle Dupuis]

...

For redundant/failover of Asterisk checkout HAAST at 
www.generationd.com  The HAAST product sits between 
Linux and Asterisk, monitors for failures etc, and then fails over to another 
Asterisk box.  It effectively creates a low-cost cluster, moving IP's etc to 
active peer.  It runs with most Linux and Asterisk distro's, and avoids the 
issues of single point of failure. etc.

Michelle
(generationD)
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Nunya Biznatch]

Thanks to everyone for the responses. I really appreciate it. I'll 
answer all questions and suggestions in this one email. (at the bottom)



On 6/14/2013 9:43 AM, Nunya Biznatch wrote:

Howdy All,
   They say opinions are like belly buttons, everybody has one. 
(that's the "clean" version of the saying). So I'm asking for yours. I 
hope you see it as a fun exercise.


I'm designing a phone system from the ground up. Will be about 
1000-1300 seats mixed 80/20 VoIP/Analog. 58-acre campus environment 
with 23 buildings. Userbase is emergency services organization, 
24/7/365 operation. Down time is not an option, but "blips" are 
acceptable. Repair time is immediate. We need failover for the 
failover essentially. However, money is a major factor, so I have to 
do it all for nothing. So here's what I'm thinking. Please throw in 
your 2 cents.


Network will be separate for phones. Fiber infrastructure available 
between buildings as well as copper. Internet access will be limited 
to a single administrative console on a temporary basis, and then only 
when remote 3rd party support is required. Access for 3rd party 
support will be supervised through remote access tools such as VNC, 
GoToMeeting, etc... etc... System will have zero access to local data 
network. This means all ancillary support servers such as DHCP, DNS, 
NTP, FTP, etc...etc... will be specific to the phone system. Yes, I 
know some responders at this time will become fixated on me gaining 
this connectivity. It ain't gonna happen. It's not an option. Period, 
end of story. These are the parameters I must work within. Trying to 
"fix" that will be a non-starter.


The phone system will upgrade an existing TDM-based system. Mitel 
SX2000 with NuPoint Voicemail. This will not be a dump-trunk 
replacement. I expect at least a one to two-year transition, meaning 
we will have time to find problems,  work bugs, and learn over time, 
with minimized impacts. It also means we'll be supporting two systems 
for some time.


PBX is 97% serving your basic phone on the desk. Nothing special. 
Customers expect the usual list of features. There will be a goodly 
number of hints required for BLF on maybe 150 phones. There is one 
office of about 30 phones in a call-center environment that will need 
that service. They would be considered low volume (but don't tell them 
that).


My Skills... I am not a Linux kung fu master, but I have built and 
managed my share of Linux servers on mutiple Linux flavors. I am a 
DCAA, having been through formal training, and have been playing with 
Asterisk for years, but always in fits and spurts and never in a live 
environment so I am by no means a kung fu master there either. I have 
started dabbling with virtualizations via XEN, but I am not 
comfortable enough with it to go live this first round. I can see 
myself implementing it in about three years once we're totally 
comfortable with what we have, so I can then have time to get that 
skill sorted. I was a network engineer for the US no3. telecom for a 
number of years, 10-years in comm-electronics in the military before 
that. Telecom my entire career. I've got the kung-fu to handle the 
network side of the house, and having administrated multiple PBXs for 
decade-plus, I've got the concepts down.


No plans to build databases for things like directories, etc... I'm 
not greatly confident in those skills, and to date, haven't found 
anything that really stands out that would make me require that. You 
may think otherwise, so please chime in. I say that, but at the same 
time I recognize I may require a GUI interface once fully deployed to 
allow lower-skilled people to follow the motions to complete simple 
moves, adds, and changes. I'm fighting the uphill battle that is the 
"GUI is new, CLI is old" mentality.


System will use G.722 for VoIP Phones.

So there's the groundwork. Here's the hardware plan.

Plan is to build my own servers following industry standards (ATX) and 
using industry standard equipment. Why? Spares? Whether redundant or 
not, I will still have spares for the most common elements on the 
shelf so equipment can be returned to service as quickly as possible. 
This will also allow me to be comfortable with more "basic server" 
configurations and help keep cost down. For example, Servers with 
single power supplies vs. dual. Also, components will be standardized 
for all equipment to aid in supply requirements.


First the layout.

2-servers acting as gateways. Each handling 2 PRIs for outside trunks. 
They'll also handle the analog ports. Failover will be in the form of 
degraded trunk access if one should fail, but the second will be able 
to support services in degraded fashion.


2-servers acting as VoIP PBX. A primary and a spare. Meaning one will 
be capable of handling the load of the entire system, and the other 
will pickup when the other dies, an active/passive cluster. Will also 
take care of voicemail. Use of heartbeat, pacemaker, etc.

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Steve Totaro]

http://red-fone.com  might be
a good place look and see if other ideas pop up.  They have good products.
 I am not affiliated with them, just a happy user on a couple of
deployments.


On Fri, Jun 14, 2013 at 11:43 AM, Nunya Biznatch
wrote:

> Howdy All,
>They say opinions are like belly buttons, everybody has one. (that's
> the "clean" version of the saying). So I'm asking for yours. I hope you see
> it as a fun exercise.
>
> I'm designing a phone system from the ground up. Will be about 1000-1300
> seats mixed 80/20 VoIP/Analog. 58-acre campus environment with 23
> buildings. Userbase is emergency services organization, 24/7/365 operation.
> Down time is not an option, but "blips" are acceptable. Repair time is
> immediate. We need failover for the failover essentially. However, money is
> a major factor, so I have to do it all for nothing. So here's what I'm
> thinking. Please throw in your 2 cents.
>
> Network will be separate for phones. Fiber infrastructure available
> between buildings as well as copper. Internet access will be limited to a
> single administrative console on a temporary basis, and then only when
> remote 3rd party support is required. Access for 3rd party support will be
> supervised through remote access tools such as VNC, GoToMeeting, etc...
> etc... System will have zero access to local data network. This means all
> ancillary support servers such as DHCP, DNS, NTP, FTP, etc...etc... will be
> specific to the phone system. Yes, I know some responders at this time will
> become fixated on me gaining this connectivity. It ain't gonna happen. It's
> not an option. Period, end of story. These are the parameters I must work
> within. Trying to "fix" that will be a non-starter.
>
> The phone system will upgrade an existing TDM-based system. Mitel SX2000
> with NuPoint Voicemail. This will not be a dump-trunk replacement. I expect
> at least a one to two-year transition, meaning we will have time to find
> problems,  work bugs, and learn over time, with minimized impacts. It also
> means we'll be supporting two systems for some time.
>
> PBX is 97% serving your basic phone on the desk. Nothing special.
> Customers expect the usual list of features. There will be a goodly number
> of hints required for BLF on maybe 150 phones. There is one office of about
> 30 phones in a call-center environment that will need that service. They
> would be considered low volume (but don't tell them that).
>
> My Skills... I am not a Linux kung fu master, but I have built and managed
> my share of Linux servers on mutiple Linux flavors. I am a DCAA, having
> been through formal training, and have been playing with Asterisk for
> years, but always in fits and spurts and never in a live environment so I
> am by no means a kung fu master there either. I have started dabbling with
> virtualizations via XEN, but I am not comfortable enough with it to go live
> this first round. I can see myself implementing it in about three years
> once we're totally comfortable with what we have, so I can then have time
> to get that skill sorted. I was a network engineer for the US no3. telecom
> for a number of years, 10-years in comm-electronics in the military before
> that. Telecom my entire career. I've got the kung-fu to handle the network
> side of the house, and having administrated multiple PBXs for decade-plus,
> I've got the concepts down.
>
> No plans to build databases for things like directories, etc... I'm not
> greatly confident in those skills, and to date, haven't found anything that
> really stands out that would make me require that. You may think otherwise,
> so please chime in. I say that, but at the same time I recognize I may
> require a GUI interface once fully deployed to allow lower-skilled people
> to follow the motions to complete simple moves, adds, and changes. I'm
> fighting the uphill battle that is the "GUI is new, CLI is old" mentality.
>
> System will use G.722 for VoIP Phones.
>
> So there's the groundwork. Here's the hardware plan.
>
> Plan is to build my own servers following industry standards (ATX) and
> using industry standard equipment. Why? Spares? Whether redundant or not, I
> will still have spares for the most common elements on the shelf so
> equipment can be returned to service as quickly as possible. This will also
> allow me to be comfortable with more "basic server" configurations and help
> keep cost down. For example, Servers with single power supplies vs. dual.
> Also, components will be standardized for all equipment to aid in supply
> requirements.
>
> First the layout.
>
> 2-servers acting as gateways. Each handling 2 PRIs for outside trunks.
> They'll also handle the analog ports. Failover will be in the form of
> degraded trunk access if one should fail, but the second will be able to
> support services in degraded fashion.
>
> 2-servers acting as VoIP PBX. A primary and a spare. Meaning one will be
> capable of han

Re: [asterisk-users] I need a second opinion on a new phone system deployment

[Daniel Tryba]

On Fri, Jun 14, 2013 at 09:43:29AM -0600, Nunya Biznatch wrote:
> System will use G.722 for VoIP Phones.
[...]
> 2-servers acting as gateways. Each handling 2 PRIs for outside
> trunks.

So why use g722? Just use your local g711 law and thus avoid the
transcoding impact to/from the PSTN and calls between the voip and analog
users.

And why would you seperate the PBX and PRI machines? Those few extra
channels don't really matter.


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] I need a second opinion on a new phone system deployment

[Nunya Biznatch]

Howdy All,
   They say opinions are like belly buttons, everybody has one. (that's 
the "clean" version of the saying). So I'm asking for yours. I hope you 
see it as a fun exercise.


I'm designing a phone system from the ground up. Will be about 1000-1300 
seats mixed 80/20 VoIP/Analog. 58-acre campus environment with 23 
buildings. Userbase is emergency services organization, 24/7/365 
operation. Down time is not an option, but "blips" are acceptable. 
Repair time is immediate. We need failover for the failover essentially. 
However, money is a major factor, so I have to do it all for nothing. So 
here's what I'm thinking. Please throw in your 2 cents.


Network will be separate for phones. Fiber infrastructure available 
between buildings as well as copper. Internet access will be limited to 
a single administrative console on a temporary basis, and then only when 
remote 3rd party support is required. Access for 3rd party support will 
be supervised through remote access tools such as VNC, GoToMeeting, 
etc... etc... System will have zero access to local data network. This 
means all ancillary support servers such as DHCP, DNS, NTP, FTP, 
etc...etc... will be specific to the phone system. Yes, I know some 
responders at this time will become fixated on me gaining this 
connectivity. It ain't gonna happen. It's not an option. Period, end of 
story. These are the parameters I must work within. Trying to "fix" that 
will be a non-starter.


The phone system will upgrade an existing TDM-based system. Mitel SX2000 
with NuPoint Voicemail. This will not be a dump-trunk replacement. I 
expect at least a one to two-year transition, meaning we will have time 
to find problems,  work bugs, and learn over time, with minimized 
impacts. It also means we'll be supporting two systems for some time.


PBX is 97% serving your basic phone on the desk. Nothing special. 
Customers expect the usual list of features. There will be a goodly 
number of hints required for BLF on maybe 150 phones. There is one 
office of about 30 phones in a call-center environment that will need 
that service. They would be considered low volume (but don't tell them 
that).


My Skills... I am not a Linux kung fu master, but I have built and 
managed my share of Linux servers on mutiple Linux flavors. I am a DCAA, 
having been through formal training, and have been playing with Asterisk 
for years, but always in fits and spurts and never in a live environment 
so I am by no means a kung fu master there either. I have started 
dabbling with virtualizations via XEN, but I am not comfortable enough 
with it to go live this first round. I can see myself implementing it in 
about three years once we're totally comfortable with what we have, so I 
can then have time to get that skill sorted. I was a network engineer 
for the US no3. telecom for a number of years, 10-years in 
comm-electronics in the military before that. Telecom my entire career. 
I've got the kung-fu to handle the network side of the house, and having 
administrated multiple PBXs for decade-plus, I've got the concepts down.


No plans to build databases for things like directories, etc... I'm not 
greatly confident in those skills, and to date, haven't found anything 
that really stands out that would make me require that. You may think 
otherwise, so please chime in. I say that, but at the same time I 
recognize I may require a GUI interface once fully deployed to allow 
lower-skilled people to follow the motions to complete simple moves, 
adds, and changes. I'm fighting the uphill battle that is the "GUI is 
new, CLI is old" mentality.


System will use G.722 for VoIP Phones.

So there's the groundwork. Here's the hardware plan.

Plan is to build my own servers following industry standards (ATX) and 
using industry standard equipment. Why? Spares? Whether redundant or 
not, I will still have spares for the most common elements on the shelf 
so equipment can be returned to service as quickly as possible. This 
will also allow me to be comfortable with more "basic server" 
configurations and help keep cost down. For example, Servers with single 
power supplies vs. dual. Also, components will be standardized for all 
equipment to aid in supply requirements.


First the layout.

2-servers acting as gateways. Each handling 2 PRIs for outside trunks. 
They'll also handle the analog ports. Failover will be in the form of 
degraded trunk access if one should fail, but the second will be able to 
support services in degraded fashion.


2-servers acting as VoIP PBX. A primary and a spare. Meaning one will be 
capable of handling the load of the entire system, and the other will 
pickup when the other dies, an active/passive cluster. Will also take 
care of voicemail. Use of heartbeat, pacemaker, etc... etc...


2-servers for support services. DNS, DHCP, FTP, NTP, etc... 
etc...Basically, everything the phones need to run plus system 
monitoring via something like Nagios.


1-Desktop for