Enterprise IP telephony is mature and ready for prime time


Recently, I had the opportunity to write a white paper on the topic of

IP Telephony (IPT) security.

In talking with executives from Cisco and 3Com, the two leaders in

enterprise IPT, one key point became very clear: Telephony should be

viewed as simply another way to leverage a corporation's IP network

infrastructure. Bits are bits, after all. Layer 3 of the seven-layer OSI

reference model, the network layer, cares not one bit (sorry about that)

whether the bits it transports are from a telephone conversation, word

processing documents, or pictures of little Patrick's soccer game.

When you look at IPT this way, it's not that far of a leap for solutions

integrators with the appropriate resources to ponder the benefits of

offering telephony solutions.

We're not talking VoIP, the "voice over IP" technology that has come to

be associated mostly with consumer-level products. IPT is different. IPT

is telephony solutions for the corporate enterprise. Is the Internet

involved? Not necessarily. IPT is perfect for the corporate campus,

running within the corporate network. In that regard, it is unfortunate

IP is short for Internet Protocol. Perhaps calling it RCP (really cool

protocol) would have been better. But the Internet is there, so

connecting to branch offices, of course, can be accomplished rather


The beauties of IPT are several.

For the corporation, there's no longer a need to run separate, distinct

networks for voice and data. The old PBX-based system and its switching

equipment can be removed and put out with the trash. Those closets full

of wire bundles with their thousands of ultrathin twisted pairs that

lead to individual phone extensions can be reclaimed as space usable for

a more productive purpose. Besides, walking into one of those wiring

closets usually results in an experience akin to entering a church

sanctuary: awe, mysticism, and, of course, an immediate yielding to a

higher authority, in this case the third-party "telephone guy." Why deal

with that when the existing IP network is willing?

For the integrator, you get to sell IP telephony servers, lots of

IP-based desktop telephones, firewalls for the necessary bolstering of

security (more about that later), and wonderful telephony applications

that leverage not just the network, but the data files already living

there. You also get to run more Cat5 cabling, probably sell more

switches, offer training, management software, and more.

Not surprisingly, security plays a big role in designing and

implementing an IPT system. The risks are no greater than with a PBX

system, but they are different. IPT is safest when run on a different

network segment than data. Hardening the network helps secure it against

the ills data can fall prey to --- denial of service, spoofing, packet

sniffing, viruses, worms, and others. Hardening the underlying data

network at Layer 2 and Layer 3 includes bolstering security on routers

and switches with technologies including stateful firewalls,

intrusion-detection systems, and intrusion-prevention systems.

Security encompasses many facets, not all of them technical.

Corporatewide policies regarding access control, authentication

practices, and forced password rotation are essential.

I can understand the reluctance for integrators to shy away from

telephony. It's vastly different than the network-based applications

we're used to. But since it amounts to another service running on the IP

network, a few integrator colleagues are expressing what I'd

characterize as cautious interest. That's probably a good way to dangle

a toe in the water.

You can download the white paper from Network World (registration

required). The paper, "Protection, Privacy and Control - A Comprehensive

Security Strategy," is dated Aug. 11, 2004.


Additionally, both of the aforementioned vendors, and others including

Avaya, Nortel, Erricson have lots of information you can digest.

Free Course: JavaScript: The Good Parts
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies