Isn't it frustrating when everyone tells you that you should be running IP telephony because of the potential reduction in TCO, the great ROI, the productivity enhancements and how convergence is the way of the future, yet nobody actually tells you how it works?

How exactly are you supposed to connect IPT into your existing phone system? What are all these media servers and gateways and what's so special about an IP phone? Here we'll take a quick look at the basics of IPT operation.

Traditional PBX vs. IPT architectures
First off, think of an IPT setup as a sort of exploded PBX. We're talking here about a pure IP setup, not a hybrid where IP functionality is ported onto an existing PBX, as that keeps more of the traditional architecture. With a PBX, you have call processing, voice switching, line cards to connect to handsets and trunks to the outside world. IPT is much the same but does it in different boxes rather than (typically) one large set of co-located racks.

The call processing - ie who wants to talk to whom - is done by what's commonly called a softswitch, IP PBX or media server. The latter name gives it away. Typically, it is a server, running a cut-down or hardened version of the OS, be it Linux or Windows, with call handling software. Instead of the multiprocessor PBX, you have multiple softswitches, both for resilience and to allow scalability - to a large extent, these can be managed as one entity as far as configuration goes.

The voice switching, instead of being done on the backplane of the PBX, is done over your LAN. Once the softswitch tells a handset the IP address that relates to the phone number it's trying to contact, it can bow out, leaving IP to do its thing and let the two endpoints communicate directly. This is why softswitches are so much smaller, both in terms of processing power and physically, than a TDM-based PBX.

Line cards and handsets therefore become switch ports and IP handsets or, if you want to keep some of your existing analogue phones, you plug analogue to digital gateway boxes into your LAN and hang your phones off that. And for trunk connections, whether to the PSTN or to an existing PBX, you install media gateways that will convert your E1 PRIs to an RJ-45 based LAN port and do all the clever stuff to translate things.

Watch this last part though, especially if you want to integrate an IPT deployment into your existing PBX system. These gateways can be used to connect the IP environment to a PRI on your PBX so the two systems can be linked. Although this can work well, with feature transparency and common dial plans, not all types of inter-PBX connectivity are supported fully. For example, DPNSS, which is commonly used to interconnect PBXs in the UK, isn't an international standard, so some gateways and softswitches don't understand the signalling and formatting, in which case you need to add in third party gateways extra to do the translation for you.

Phone operation
While a softswitch works much the same way as the processor on a PBX, letting you configure route selection, digit translation, access rights, hunt groups etc, the handsets are significantly different. They've become, in effect, baby PCs, with operating systems, IP addresses and, on some, screens that offer web browser functionality.

IP phones have MAC addresses, which is about all they know when they boot up. Remember those diskless workstations that used to broadcast for a server to download what they needed to get them going? An IP phone will broadcast for a DHCP address and typically (though this can be vendor-dependent) will also be given other information such as a server that it can get new firmware loads from, if required, and a list of the softswitches it should communicate with.

So, you'll find that your DHCP suddenly needs to cater for many more devices than before. It's recommended that your phones go into different VLANs from your PCs - this helps management and QoS enforcement but it also lets you use different ranges of IP addresses that won't conflict with or use up valuable IP addressing space. Typically, RFC1918 addresses are used for phones.

The phone will register with a softswitch and often with a backup one too, using a TCP connection to ensure it can tell if its primary softswitch fails and it needs to fail over to use the secondary. When a phone wants to make a call, it will send a call request to the softswitch. This will figure out the IP address of the device being called, another handset or a gateway if it's an external call, say, and send a call setup request to the destination. Once the call is answered direct communication, using RTP, is set up between the endpoints and the softswitch disengages itself from the process until the handsets signal the end of the call, or need to use another service, such as call transfer.

Inline power from the LAN switches is a big selling point for IPT, since you don't need power bricks. But this really only gives any financial saving in a brand new building, where you can save on wiring. Similarly for the LAN connection, as most IP phones have a small internal switch (or sometimes hub) that lets you plug the LAN switch into the phone, and a PC into the phone too. That way you don't need separate ports for all your phones as well as the PC connections (although you can have them if you want). Of course, not all switches are capable of providing power, or of coping with having two devices hanging off one port and treating them differently in terms of VLAN allocation and QoS, so an IPT deployment may involve some major infrastructure upgrades (see So you think you have a voice-ready network?).

The more expensive phones support XML, which opens up a whole other subject on the things you can do with your phones, apart from making calls, but that's for another day - as is the complex world of unified messaging (voicemail but with email and fax support too). We'll look at these topics in a future article.