[unisog] VOIP considerations checklist?
pete at shadows.uottawa.ca
Wed May 21 21:34:41 GMT 2008
A couple things Peter missed in his most excellent rant.
Cost: So far, I've gotten 12 years out of my TDM/copper phone
system. No way do I expect that kind of life from VoIP phones...
need more RAM.. better display.. etc..
Early in its life, manufacturers were claiming that you would
save money switching to VoIP. They stopped claiming that, whhich
should tell you something.
It IS great when you have remote locations... places you can't
run your own wires to. Also great for quick setups (conference,
911: We have a reasonable setup that works reasonably well.
Our 911 is programmed to call our security people but it
transfers to the city's 911 if not answered in 0.1 seconds.
That is enough time to pick up the calling line ID. Manual
maintenance of a database and network restrictions on just
plugging a phone anywhere, let us keep a database which enables
us to translate phone ID to location. Local 911 center calls
our security (agreement) whenever a call originates from our site.
Our VoIP is on a seperate netowrk with almost no connectivity to
anything else. This elinimates some of the advantages. In a
business, with a trusted internal network, you could do more.
I don't trust my internal network.
As far as power/redundancy.. It used to be that people expected
phones to work even when the power was gone. These days, they
are expecting the network (certainly the wireless) to work when
power is down, and they couldn't care less about the phone. At
least that is the feedback I'm getting.
On Wed, May 21, 2008 at 01:35:50PM -0700, Peter Van Epp wrote:
> On Wed, May 21, 2008 at 03:25:39PM -0300, Matt Ashfield wrote:
> > Hi,
> > 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 deployment.
> > Things like Power, Redundancy, etc.
> > I'm just wondering if anyone on this list has any useful resources/links
> > they could pass along. Thanks
> > Matt Ashfield
> > Network Analyst
> > ITS Communications & Network Services
> > University of New Brunswick
> > mda at unb.ca
> > _______________________________________________
> > unisog mailing list
> > unisog at lists.dshield.org
> > https://lists.sans.org/mailman/listinfo/unisog
> With the disclaimer that my own site routinely ignores me and has
> implemented VOIP my advise is keep the copper :-). I'd usually say there is
> no business case for VOIP but that isn't really true we do have a few good
> uses for it (travelling faculty / staff and working from home where home may
> be very far away being two reasonable uses). It just sucks big time as the
> only play. You have introduced a single point of failure, with VOIP the network
> being down means the entire place stops (instead of only most of it with analog
> phones these days :-)) Its one potential advantage is network uptime
> statistics: "If the network is down, just pickup that VOIP phone and call us".
> Voila instant %100 uptime (at least on paper which is usually all the managers
> care about :-) ).
> Somewhat more seriously 3 or 4 years ago when we did this, the deployed
> cost of the phone side of this (which ignores the network side of it) was
> twice the equivelent analog implementation. It was done anyway on the (bogus
> in my view) theory that we wouldn't be able to buy analog phone gear in a few
> years (in fact I expect to be long dead before that happens). Then as you note
> you get in to the network costs: POE (ugh!), redundancy in the network which we
> hadn't been doing because it wasn't funded. Here a UPS there a UPS everywhere
> a UPS and generator. All along any network path that your VOIP calls may follow
> which came as a big ugly suprise to our implementation fanboys when I pointed
> it out and in fact cancelled a deployment because the path was to expensive /
> to long to secure in an appropriate time frame. Again in general our entire
> network is not life safety UPS / generatored (and maybe our entire VOIP
> installation isn't either, having pointed out the problems I figure my job is
> done) perhaps yours already is, in which case this won't be an issue. Perhaps
> you won't have an emergency (we haven't so far, praying that happy state of
> affairs continues til I retire :-)) that is attributable to VOIP.
> The number one fun question to ask of both your VOIP vendor and your
> risk manager is "what about 911?". Get ready to see the most amazing soft shoe
> dance from your VOIP vendor because this is very hard and ugly to get right.
> I believe our current implementation depends on poking in to switch MIBS to
> aquire the physical location of the set run the phone is currently connected
> to, I don't know if anyone has ever tried it ... An appropriate (loaded)
> question for your risk manager is "if we deploy this VOIP thing which looks
> like a phone and sometimes if the network is up, acts sort of like a phone,
> how much will we get sued for if it doesn't work in an emergency?". The answer
> ours got back when he asked this at the paranoids (I mean risk managers :-))
> convention is "There is no current case law, so you will be creating it, making
> the answer lots and yes we expect that you will lose in the end!". The one sort
> of advantage you have is that being in Canada like us, as far as we can
> determine there is no law or regulation on the provision of 911 service that
> you are violating by doing or not doing something (if any Canadian is aware
> of one we would be most interested in a pointer!). We can get guidelines from
> the E911 folks but they can't point us at any law or regulation that covers us,
> as not a telephone company, we seem to fall between the cracks. I beleive that
> will drop us in to common law and is likely in turn to lead to that "it looks
> like a phone but isn't and you may be negligent in not pointing out it isn't a
> phone" senario. Happy VOIPing (and buy stock in the analog phone switch
> manufacturers :-) ).
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
> unisog mailing list
> unisog at lists.dshield.org
Pete Hickey October Blend:
The University of Ottawa The duck
Ottawa, Ontario flavored
More information about the unisog