Windows Foundation

Hello, It's IP Telephony

IP telephony is no longer just for companies that do a lot of geographically disparate work. Our columnist gives you the long-distance view.

• By Bill Heldman
• 11/01/2002

What they were talking about was the advent of Voice Over IP (VoIP), a new way of packetizing telephone calls and sending them out over IP networks. In a large environment, VoIP could potentially have been the holy grail.

Why? Because if you work for a company that has a lot of geographically distant campuses (e.g. New York, Dallas, Tokyo, Hamburg) and there's a lot of calling going on between these campuses, the long distance (LD) charges can become enormous. Not to mention that there's a ton of overhead in maintaining the Post Branch Exchange (PBX), switch or key system equipment needed to handle the phone systems because there's a lot of proprietary gear to worry about and you need people who understand the gear and can keep up with the required changes. But if your employees could make phone calls over the Internet, then, with the exception of setting up some special telephones and making sure you had robust Internet connections, the freight would be very low cost to handle the calls.

Sounds logical, right? Problem was that in those early days, not many companies manufactured VoIP gear; the quality of the calls was pretty poor and as soon as the big telcos got wind of the idea, they began making sounds like they'd tack on a surcharge to companies who tried such a thing. On top of that, lots of companies had already negotiated long-term lease and maintenance agreements with their telcos in order to provide not only long distance service, but also the necessary equipment to make a functional telephony environment.

But the overall idea is still fundamentally sound. For example, consider the average corporate network today. You have a data network and a telephony network, the two of which do not talk with one another (see Figure 1).

Figure 1. Same company, two different networks.

There are some places in this model where there is room for better economic design. For example, if we were able to consolidate the two networks, we wouldn't need as many technical people to handle the operation. Although we'd still need some telephony people-folks who understand how telephone systems operate, especially the user database-we wouldn't need as many, instead offloading a lot of work to the server and network admins instead. Also we could narrow down the amount of network protocols in use and we could save money on hardware and cabling costs.

But there is a problem-applications. The PBXs and key systems have great voicemail programs and other applications such as unified messaging (being able to get your e-mail through your voice mail or vice-versa) that were not readily available in the early days of VoIP.

Suppose that we wanted to mimic the way that the phone systems work in order to get everything onto one network. What do we need? There are several things on the list that a conventional PBX has that we'd have to bring with us to the table.

• Switch fabric
• Some sort of mechanism to talk to the telco (called the "carrier" in the biz). This mechanism is referred to as a "voice gateway."
• Applications (such as voicemail)
• Phones
• Power supplies

If we were to come up with a network infrastructure that handled the switching and connections to the telco we'd be able to take care of items 1 and 2 without a PBX. Then, if we could invent an application or two we could pick up item 3. Also, we'd have to invent the telephones that would work on our new network system and finally we'd move the whole power supply thing onto UPS equipment. If we could do all this, we could shuck our PBX and key system gear (or, in some cases, keep it in the background to assist with other areas that have not yet converted). We'd dramatically downsize our costs in terms of both physical plant and human resources. Figure 2 shows how we've taken the guts of the PBX and offloaded its functionality in other ways.

In Figure 2 you can see that using IP telephony products we can emulate the functionality of the PBX. Instead of the PBX switch fabric, we use the network infrastructure switches instead. Note that the switch ports have to be specially powered to support voice traffic. Also we can slip a carrier card, such as a T1 or PRI ISDN board into the routers in order to talk to the carrier. Our conventional server room UPS gear takes the place of the PBX UPS. Our applications are supplied by application servers and the phone sets we use are a purchased item that is specially designed for IP telephony.

Figure 2. PBX functionality can be offloaded to a PBX emulator; devices must support voice traffic.

Taking the Implementation Call
With some judicious planning, good project management, the advice and counsel of vendors and consultants who've done this before and, of course, a healthy budget, you can set up an IP telephony system that will allow you to eventually unplug your expensive PBX equipment and/or augment it until that day. Your telephony folks will continue to set up the dialing plan and work as they might normally do, although their PBX green screens will be replaced with Windows-based interfaces and their method of doing things will be drag-and-drop instead of command line. Your server admins will handle the server farm, your internetworking folks will continue to manage the routers and switchgear and your apps team will work with any specialized applications.

IP telephony is very standards-driven and good quality gear, such as that sold by Cisco, travels in the standards circuit supporting such well-known standards as C++, XML, Clustering TAPI and JTAPI, to name a few.

An IP telephony system supports good convergence of video, voice and data. Your server farm and network infrastructure can handle the voice load as well as data and any video work that you do (such as streaming video for online classes).

Another issue that's of concern to telephony folks is that of Customer Resource Management (CRM), or its brand new successor Electronic Customer Resource Management (e-CRM). If you work for a company that has call-centers, where customers can call in for support, to order things, to get advice on their account and other such activities, then you're probably already familiar with CRM solutions. A good IP telephony environment should easily integrate with big CRM software providers such as Siebel and should support home-grown add-ons to CRM environments by allowing the use of snap-ins created with Visual Basic or Visual C++.

Call-center employees experience what are called "screen pops." The idea is that a screen pops up with information about a customer's account and order status. You can customize screen pops for a variety of things, and they're very effective in helping call-center folks quickly and efficiently deal with customers. A good quality IP telephony system should support screen pop capability. (The Cisco system screen pops can be built with a screen-pop wizard.)

Call for Help
The key to developing a good quality IP telephony solution is to seek wise counsel regarding such an effort. You first must get buy-in by decision-makers at high levels because the change to IP telephony can heavily impact lots of functional areas and chew up quite a few resources in its implementation.

Accomplish that big task and you can go to the next step: Getting all the stakeholders in a room to plan the design and deployment. Do this at a high level, thinking not in terms of gear at this point, but in terms of what you hope to accomplish. What is your mission? Is it to get rid of PBX equipment?

Next bring in a vendor. In the City of Denver's case, we chose Cisco gear through a vendor bidding process to find the best design and lowest cost implementation. The Cisco equipment is very high quality, comes with the R&D investment behind it so that you know it's going to work and is highly standards-based.

Finally, implement and deploy. Plan on several months of up-front work before you get to this stage and several more weeks as the stuff gets installed and set up. While this isn't rocket science, it's also not the easiest thing in the world to do and getting it right takes time. You'll need a parallel operation plan for your existing phone system while you set up the new system.

Can You Hear Me Now?
What's in it for you? Well IP telephony brings with it a new paradigm. First of all, you don't have to worry about a second set of cabling for your phones. Everything runs through the Ethernet system. In fact, in the City's case, the patch cable comes from the workstation jack to the phone set, then another patch cable goes out of the phone and into the PC! We use dual DHCP scopes, one to handle the phones, one to handle the PCs.

Also, if you go with Cisco gear, you'll have applications servers. These can be set up to handle a variety of (either bundled or separately purchased) applications such as unified messaging. The bare bones of the system allows for a call plan and the Web attendant so admins can monitor and maintain from anywhere that they can get to the private network.

The phone sets are clear in terms of their sound quality, and programmable for a variety of custom features.

The systems are able to easily interoperate with conventional PBX equipment and software.

With an IP Telephony system you can support a feature called Quality of Service (QoS), dedicating portions of bandwidth to certain kinds of activity. You may, for example, desire to give a higher priority to voice traffic than to data.

IP telephony, no longer just VoIP, is the thing to think about when considering a telephony system upgrade for your company.