<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
<br>
<div class="moz-cite-prefix">On 6/14/2013 9:43 AM, Nunya Biznatch
wrote:<br>
</div>
<blockquote cite="mid:51BB3A21.9000903@ihearbanjos.com" type="cite">Howdy
All,
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
System will use G.722 for VoIP Phones.
<br>
<br>
So there's the groundwork. Here's the hardware plan.
<br>
<br>
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.
<br>
<br>
First the layout.
<br>
<br>
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.
<br>
<br>
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...
<br>
<br>
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.
<br>
<br>
1-Desktop for administration of everything. Provided from
corporate. Basic Desktop.
<br>
<br>
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.
<br>
<br>
OS of choice is Debian. Primarily because it appears to have the
best availability for non-Internet installations.
<br>
<br>
<br>
Now the Infrastructure
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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...
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Thanks in advance for your review and consideration...!!!
<br>
<br>
</blockquote>
<br>
<p><font face="Arial"><b>Michelle Wrote</b><br>
"For redundant/failover of Asterisk checkout HAAST at
<a href="http://www.generationd.com">www.generationd.com</a>
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."</font></p>
<p><font face="Arial"><b>Then Carlos Wrote</b><br>
"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."</font></p>
<p><font face="Arial"><b>Then Chris Wrote</b><br>
"Not to mention that installing Pacemaker/Heartbeat/Corosync or
your other HA solution of preference isn't particularly
difficult, and is agreeably free.
"</font></p>
<p><font face="Arial"><b>Answer to All - </b>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.</font></p>
<p><font face="Arial"><br>
<b>Phillip Wrote</b><br>
"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."</font></p>
<p><font face="Arial"><b>Answer - </b>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.<br>
</font></p>
<p><br>
<font face="Arial"><font face="Arial"><b>Phillip Wrote<br>
</b></font>"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?"</font></p>
<p wrap=""><font face="Arial"><b>Answer - </b>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...<br>
</font></p>
<p wrap=""><font face="Arial"><br>
</font><font face="Arial"><font face="Arial"><b>Phillip Wrote<br>
</b></font>"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."</font></p>
<p wrap=""><font face="Arial"><b>Answer - </b>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.<br>
</font></p>
<p wrap=""><font face="Arial"><br>
</font><font face="Arial"><font face="Arial"><b>Phillip Wrote<br>
</b></font>"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."<br>
<br>
<b>Answer - </b>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".<br>
<br>
<br>
<b>Daniel Wrote</b><br>
"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)."<br>
<br>
<b>Answer - </b>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. <br>
</font></p>
<p wrap=""><font face="Arial"><br>
</font><font face="Arial"><font face="Arial"><b>Daniel Wrote<br>
</b></font>"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)."</font></p>
<p><font face="Arial"><b>Answer - </b>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.</font></p>
<font face="Arial"><br>
Sincere Thanks once again to everyone who has responded. It's been
a great help.</font><br>
<br>
<blockquote cite="mid:51BB3A21.9000903@ihearbanjos.com" type="cite">
<br>
<br>
--
<br>
_____________________________________________________________________
<br>
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>
--
<br>
New to Asterisk? Join us for a live introductory webinar every
Thurs:
<br>
<a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>
<br>
<br>
asterisk-users mailing list
<br>
To UNSUBSCRIBE or update options visit:
<br>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
<br>
<br>
</blockquote>
<br>
<br>
</body>
</html>