[unisog] unisog Digest, Vol 50, Issue 16
YorkJ at brcc.edu
Thu May 22 14:05:22 GMT 2008
Don't know if attachments are allowed on the list, but I've attached a
simpleminded ppt on VoIP security I made a while ago--can send it direct
if anyone is interested.
As an IT grunt, I've found I can rant about this system or that, but I
always wind up installing the system I'm told to install ;-)
Notes/Lessons Learned from my VoIP installation:
1) plan the network component in advance, and implement it the way you
planned. We let the voice vlan part go "until later" and I'm just now
(this was written in 2006) getting it installed.
1a) design security into plan from beginning. Much voip stuff is
unencrypted/unprotected by default
1b) UPS takes *lots* of planning--power phones by POE--closets only had
110V, some needed 220 to power all the phones. POE comes in lots of
flavors--try to get the most recent so you can handle it when they add
AP's, security cameras, IP speakers, gumball machines and skateboard
2) good excuse to upgrade network infrastructure--may get new equipment
out of it
3) same vendor across network equip is helpful--most standards aren't
quite. Even so, our older Cisco stuff doesn't work the same way the
newer stuff does.
4) bandwidth--we are 100mb switched, GB backbone (and small), so local
bandwidth was not a problem, no QOS needed (in 2006--may need to
reevaluate in 2008). WAN links between campuses could be a problem.
For these, research traffic levels, QOS. Ditto for backbone links in
really big locations
5) Keep things as simple as possible--just one compression scheme, one
time zone, etc
6) There may be capabilities the old PBX had that your voip solution
does not. Research this carefully before selecting a vendor, and get
users to buy in if there are differences. (Fortunately our 30 year old
PBX stank, so not much problem here.)
7) Interfacing with the phone company was sometimes a problem. Took
years to get outgoing caller ID to work, etc. When we had problems, the
telco answer was often "our switch doesn't do what you want," or "our
stuff is working fine, it must be on your end."
8) Phone configuration for different offices nearly drove us crazy in
the beginning. Getting the users to agree to what numbers are on what
phones, which numbers ring, where they ring, call waiting/no call
waiting, hunt groups, ... , might have helped. Often once they have
what they asked for they decide it needs to change anyway. Flexibility
of voip systems is both a blessing and a curse.
9) I *love* having redundant callmanager servers. Some installations
put it all on one beefy box--one bonehead mistake at the console and
10) Analog lines are a pain (fax's), but now have control over modems!!!
11) time sync is critical--a local ntp time source is a good thing
12) redundancy for remote sites takes lots of planning
13) BACKUP!!! It's easier to sleep at night if you know you can rebuild
the system from cinders
14) test redundancy
15) training for your people--consultants vs supportability
16) If you go Cisco, go to CallManager 6.x and avoid the Microsoft
security patch headaches that come with 4.x and below.
17) Be **very** careful to avoid glitches or downtime--the users will
punish you unmercifully. We get enough help desk calls about the phone
system when the user just dialed a wrong number. One glitch or hiccup
and those calls increase 10-fold for 3 months or more.
Blue Ridge Community College (the one in VA)
> To: "'UNIversity Security Operations Group'"
> <unisog at lists.dshield.org>
> Message-ID: <020d01c8bb70$12648d10$372da730$@ca>
> Content-Type: text/plain; charset="us-ascii"
> We're looking at the business case for voip on campus. As
> part of this,
> we're trying to make sure we take into consideration all areas of the
> network which would be affected/necessary to support such a
> Things like Power, Redundancy, etc.
> I'm just wondering if anyone on this list has any useful
> they could pass along. Thanks
> Matt Ashfield
> Network Analyst
> ITS Communications & Network Services
> University of New Brunswick
> mda at unb.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 465408 bytes
Url : http://lists.sans.org/pipermail/unisog/attachments/20080522/c279a8b4/attachment-0001.ppt
More information about the unisog