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, 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 administration of everything. Provided from corporate.
Basic Desktop.
Looking at Intel Xeon E3-1230 ivy-bridge processors. 8GB DDR 1333 for
Gateways and 16GB for PBX and support servers. 1TB drives in RAID 10
via LSI 3ware 9650 cards for PBX, 250GB for Gateways. Supermicro
X9SCM-F mobo.
OS of choice is Debian. Primarily because it appears to have the best
availability for non-Internet installations.
Now the Infrastructure
2-network switches in the phone room. Each set of "primary" servers to
one, and "secondary" servers to the other, and each switch connected
to the other. Each switch will have a different path to the network.
RTSP implemented for dual path to the campus. Only one location on
campus will have or require dual paths to the network.
Most buildings on campus have cat-3 for voice installed in the
mid-90s. Wired at the same time as the data network, I can generally
conclude they're the same length. It's terminated to 110-blocks on
walls. Some cabling is only 2-pair. I know I will find surprises.
Essentially, I plan to re-use this cable, knowing in some
circumstances I will need to make special patch cables. These
connections will be forced to 10BaseT at the switch.
I require PoE to the wire closets, no power sourced at the desktop. I
require a minimum eight-hours emergency power which will be in the
form of UPS in most cases. Why so much backup? Well if you ask, we can
start a new discussion about NEBS compliance, E911 Federal, local, and
state requirements, etc... etc...
So why not use existing data network? The current data network
consists primarily of 10+ year-old 100BaseT switches, no PoE. Barely
any backup power. I don't believe they're using QoS. The network
office is a separate department from the phone office. I question
their skills, and above all, network folks treat phones like
computers, not like multi-million dollar lawsuits when they don't work
in an emergency. We could make another thread out of this huh? To use
existing data network would require hundreds of thousands in Cisco
6500 and 4500 series switches. Network has already stated they'd want
phone on separate ports from computer, and I agree. (Yet another
thread). Thousands of computers across 23 buildings, and it must be
Cisco by corporate policy, where phone is a different animal that
doesn't have this limitation. You can see we're talking hundreds of
thousands in just switching gear. Then UPS requirements to support a
big hog of a switch vs a teeny 48-porter w/PoE, and you just cranked
up one-time and long term cost for that as well. Trying to replace the
network to support the phones is cost prohibitive and a non-starter.
Maybe we can talk about it in 5 years once they've replaced everything.
I plan to purchase lower-cost Layer-2 smart switches from vendors such
as DLink, Xyxel, Dell, etc... Many players in the market for 48-port
switches with PoE and multiple SFP.
I think that's probably enough... I apologize for the large email but
I couldn't think of a better way to get a qualified peer opinion
without laying out the facts.
Thanks in advance for your review and consideration...!!!
*Michelle Wrote*
"For redundant/failover of Asterisk checkout HAAST at
www.generationd.com <http://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."
*Then Carlos 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."
*Then Chris Wrote*
"Not to mention that installing Pacemaker/Heartbeat/Corosync or your
other HA solution of preference isn't particularly difficult, and is
agreeably free. "
*Answer to All - *Michelle, I sincerely appreciate the response.
However, I tend to lean toward what Chris is saying usually because I'll
try the low cost option first if it appears viable. I do that in-part,
because of the little "Gotchas" commercial software tends to have such
as the one Carlos mentioned. I've looked at the product before, but not
closely since I knew there was something out there for essentially free
that may do the job. If I get into it and down the road determine I need
something more or more refined, I would look at commercial options.
*Phillip Wrote*
"Have you given thought about how users are to access their voicemail,
change their forwarding and look into the called/received list of calls
status? For all these things you are likely to need a web interface,
which means your phone network will need to have at least a defined
bridge between the data network and the phone network."
*Answer - *Yes. It's all going to be accomplished at the phone, just as
they are currently accustomed to. No UC can even be considered. Even our
current voicemail supports fax and voicemail to email, but we can't use
it due to the separation of data network from phone. I hope in the
future, once this system is deployed and running smooth, I can look
toward convincing the network folks a little pipe between the two isn't
going to hurt. This is one of the things that excites me about Asterisk.
It seems like you could add a new feature every six months for the next
ten years. Unlike today where you get what you get, then you don't throw
a fit. ...and pay for it.
*Phillip Wrote
*"And then you will need to give a lot of thought about how to do the
provisioning. What phone type/model are you planning to employ?"
*Answer - *I'm leaning toward Polycom Soundpoint. They have the most
complete range of products and accessories available. I've tested an
Aastra 57i, Cisco 7962, Mitel 5320, and a number of the Polycoms. Every
single phone has their limitations. I've got to give credit to Mitel
here. They have the absolute best phones I've run into thus far, and
accessories such as cordless handsets that nobody else has considered.
However, they're a closed product, with no support for plugging into a
non-Mitel switch, and they want to charge for licensing and firmware.
Bummer. I've considered the Digium products, and they look very solid,
but I need sidecars. Aastra 57i I really like, but they use that
non-wideband, wideband instead of true G.722. I think I could live with
that, but their handset sounded like I was talking in a tunnel. Cisco
makes a nice phone, and would trick the users into thinking they're
driving a Cadillac when the reality is it's nothing but a glitzed-out
Chevy, but the Cisco's require extra work up-front to convert them to
SIP that I'd just as soon avoid, and to be legal I need to buy a
SmartNet contract for each phone similar to Mitel. I have to submit to
public bid my specifications, then let the market sort out what vendor
I'm left with, but I have my favorites. I would like to support any
phone a customer wants, but that would be an insane nightmare to manage.
In any case, the evil plan is to use the servers providing all the
ancillary services as my phone servers as well, storing the configs, etc...
*Phillip Wrote
*"Keeping the gateway machine speparated from the PBX is a very good
decision: If you intend to used PCI(e) cards then you will once in a
while get into driver issues hell, and there are might be older Asterisk
version that work well with the drivers, yet your PBX Asterisk requires
for whatever reasons a newer Asterisk version."
*Answer - *Call it crotchety old phone guy that makes me want to have
trunks separate from PBX. If you're gunnin' for 5-9's, you're not gonna
get it if you have to kill the entire switch every time you want to work
on the trunks. Thanks for the validation. Thanks for the heads up on the
cards. My plan is to get a solid system, then leave upgrades to
something like every couple years unless it's critical security. I say
that, but I know the geek-side of me wants to have the newest, biggest,
baddest, fastest driver I can dump onto it. It's a bad habit to get
into. Three years between upgrades seems to be a fairly accepted
practice in the phone world.
*Phillip Wrote
*"Personally I would look very closly at Patton gateways, though, PCI
cards I cannot really recommend do the never-ending driver quests,
version issues and other OS dependencies."
*Answer - *Thanks for the recommendation. I've used Patton products in
the past and have been happy. However, I look, and man they seem to be
pricey. Competitive to the other appliances I've looked at, but more
costly than what I'm looking at doing short-term. I may find myself
looking to make life easier in the future by replacing a couple server
boxes with appliances, but in the short-term, I've got to keep it as low
cost as possible since it will be a big purchase. I know I'm trading
labor for cost, but where I work, my labor is "free".
*Daniel Wrote*
"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)."
*Answer - *Thanks for the second response. If you see some glaring
ignorance in my email please let me know. I've not been able to try this
out in real life, so maybe you're seeing something I'm missing. Yup,
those gateway boxes will have no other job than to accept analog from
analog phones, or G.711 from the PRI, then convert it all to G.722, then
push it up to the PBX. My assumption, and maybe where I'm messing up, is
the PBX would merely passthru at that point unless it was voicemail.
Does that sound right? Essentially, I'm transferring the job of
transcoding to the gateway boxes, and leaving the PBX and voicemail work
to the PBX.
*Daniel Wrote
*"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)."
*Answer - *No regular recording. Case by case basis only, then only one
or two. ...and you just touched on one of my concerns as well. I've
built my large share of servers and desktops, and I know how you can
always do your best, but you'll never truly know how all the parts work
together until you plug it all in. Heck, as you noted, you can't even
trust commercial products completely. I would much prefer to test the
waters by purchasing and building one of these machines, then let it run
in a live environment for six months while I throw everything I can at
it, but the office thinks I need to just get the thing done. So I'm
banking on the fact that if I screw up the combination, it's going to be
one particular part that I can easily replace for relatively little money.
Sincere Thanks once again to everyone who has responded. It's been a
great help.
--
_____________________________________________________________________
-- 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
--
_____________________________________________________________________
-- 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
