IP Telephony Components and Protocols
IP Telephony solutions are applicable in all environments in which legacy telephony installations can be found, including home users, SOHOs, SMBs, large enterprises, and carriers. Even though the deployment environment and customer requirements for IP Telephony solutions differ, the design approach remains the same. Topology, performance, and budget considerations drive the choices of equipment and protocols following the identification of the stakeholder requirements. The key solution components, although they differ in scalability and capability, share the same characteristics and principles of operation. Viewing voice as an application implies that a viable IP infrastructure must be in place to support any successful IP Telephony solution deployment.
In developing an IP Telephony solution, you must also maintain a clear distinction between IP Telephony and Voice over IP (VoIP). Although the two expressions are frequently used as synonyms in casual technical discussions, consider VoIP as an enabler of IP Telephony in the context of design. An IP Telephony solution relies on VoIP standards, protocols, and equipment to create as complex or as simple a telephony system as has been determined by the user requirements and the available budget.
Consider the following key IP Telephony components:
Gateways
Gatekeepers
Software-based PBXes
IP phones
VoIP protocols
Gateways
Generically, a gateway converts between the same layer protocols from different computing architectures or technologies. The H.323 recommendation identifies a number of gateway types (access, trunking, media, composite, decomposed) that reflect a high degree of gateway versatility in packet-based multimedia communications systems that include IP Telephony. Yet, this gateway versatility inevitably implies that in the course of designing IP Telephony or any other communications solution, you need a clear understanding of each gateway's functionality. In the context of H.323, gateways are also referred to as endpoints, meaning that they can initiate and terminate calls.
Cisco offers two categories of IP Telephony gateways:
Universal series gateways (AS53xx/AS54xx/AS58xx). They are frequently deployed in the ISP and carrier environments.
Several models of digital and analog voice gateways. They cater to the SMB and enterprise markets.
Both types of gateways convert voice traffic between the circuit-switched and packet-switched networks. The circuit-switched network is commonly referred to as the TDM network, the PSTN, or the plain old telephone service (POTS), regardless of whether the network is analog or digital. Packet-switched networks are now mostly IP based.
In an IP Telephony deployment without TDM, PSTN, or POTS interfaces, gateways are not needed. If an SMB's internal phone system is entirely IP-based, and the interface to the provider for local, long-distance, and international calls outside of the SMB network is also via IP, that SMB will not require gateways. To integrate legacy phone instruments into an IP-based telephone system, a voice gateway is required. The Cisco VG248 analog voice gateway allows for the integration of analog phones, faxes, and modems with the Cisco IP-based CallManager platforms, which are discussed later in this chapter.
If the SMB's internal phone system is entirely IP based, and the interface to a provider is via TDM instead of IP, a gateway is required for routing calls outside of the SMB network. That gateway is still considered a voice gateway, but it is also a PSTN gateway (integrating PSTN with an IP-based telephone system), in contrast to a voice gateway that is needed to integrate individual instruments into an IP-based phone system.
Topology and performance considerations are always factors in choosing gateways, but the choice is also driven by the technologies and protocols that need to be integrated into a cohesive IP-based communications system. It's generally hard to find a large SMB IP Telephony deployment without gateways, even if they are used only for backup service to PSTN.
In addition to dedicated voice gateways, Cisco offers modular routers (2600/3600 series, for example) that can be turned into VoIP gateways when equipped with appropriate voice and WAN interface cards, and an IOS that supports VoIP protocols. For the Catalyst 6500 series switches, Cisco offers T1/E1 service modules that turn the Catalyst into a VoIP gateway, integrating an IP-based phone system (CallManager) with a traditional PBX, PSTN, or both.
Because gateways represent the points of convergence between different communications systems, they can be deployed individually or in groups as a function of the size of the networks and the number of points (locations) where the different networks need to interconnect.
Gatekeepers
A gatekeeper is an optional element in a packet-switched H.323 network. Gatekeepers are effectively gateway managers. Gateways must be configured to register with a gatekeeper, just as the gatekeeper requires configuration to recognize the gateways.
In a multigateway H.323 deployment with multiple interfaces between the PSTN and IP networks, gatekeepers facilitate greater scalability by easing gateway configuration. In smaller deployments, VoIP gateways can be configured to exchange voice traffic over the IP network without having a gatekeeper as part of the network. However, as the number of gateways increases, you might quickly bump into high levels of configuration complexity of the dialing plan on the gateways if the design does not include a gatekeeper.
It follows that in complex networks, the gatekeeper becomes the repository of the dialing plan. The CallManager deployment models that are discussed later in this chapter allow for the presence of a dedicated gatekeeper or for the configuring of CallManager to perform call admission, which is one of the gatekeeper functions.
Assume the presence of a properly configured and functional gatekeeper on an H.323 network. Its functions are to manage the gateways, perform call admission into the IP network by monitoring and managing the available bandwidth for the anticipated call path, and to translate between IP addresses and E.164 numbers. E.164 is the ITU-T recommendation that specifies the international public telecommunications numbering plan or the generic structure of globally usable telephone numbers.
E.164 numbers are variable in length and consist of a country code (designation for a country), destination code (typically, a city or an area within a country) and the subscriber number (the number that is assigned to the end user by a local telco). Numerous configuration commands are available on gateways and gatekeepers to configure dial plans that include E.164 numbers.
In Cisco-based H.323 deployments, a gatekeeper is typically a router with an appropriate IOS. Even though gatekeepers can be involved in actual routing (switching packets between multiple interfaces), consider connecting the gatekeeper to the network via a single (preferably high-speed) interface and allowing it to perform the gatekeeping functions only without being burdened by other responsibilities, such as routing.
From a physical connectivity perspective, the gatekeeper becomes a “router on a stick” that is using the capabilities of the IOS and the router's processing power to perform its function as gateway manager. If the gatekeeping functionality embedded into IOS could be ported to a generic OS and hardware platform, the gatekeeper would not have to be a router.
In the gatekeeper-based H.323 networks, gatekeepers assume a critical function, and the issue of gatekeeper redundancy becomes equally critical. Alternate gatekeepers increase redundancy, whereas directory gatekeepers improve scalability. Multiple techniques exist for designing gatekeeper redundancy, including the following:
The use of multiple gatekeepers to manage smaller groups of gateways, which translates into a partial versus full network outage in case of single gatekeeper failure
Configuration of Hot Standby Routing Protocol (HSRP) for the pairing of gatekeepers
Software-Based PBXes
Consider that telephony as a communications technology has been evolving for more than a century and that PBXes as private mini replicas of the phone companies' central switching offices represent a key element of that technology.
In designing an IP Telephony solution, it's not critical to be fully aware of either the history of PBXes or all of their proprietary features, developed over many decades by many telephony equipment vendors. It is critical, however, to be aware of the general functions of a PBX. These functions include the following and more:
Call routing within the SMB or enterprise networks based on extensions (think dialing plan here!)
Automatic Call Distribution (ACD) based on the Dial Number Identification Service (DNIS) or Automatic Number Identification (ANI)
Any SMB IP Telephony solution either replaces a PBX by a common-OS platform with call processing software or has to integrate with it via gateways. In either case, you need to map the key features of the existing PBX to those offered by the IP solution and ensure that user training is offered during the deployment stage to elucidate feature differences, new capabilities, or the absence of old, familiar features.
If a PBX is software based, it does not mean that there is no hardware involved; it means the use of call processing software on a common hardware platform running a common OS. The Cisco CallManager using an Intel-based computer with a Windows OS falls into the category of a software-based PBX. Programming via a web-based interface is easier than setting jumpers on printed circuit boards or using a cryptic command-line interface (CLI) language with the older, traditional PBXes. When the software-based PBX is further integrated with voice gateways and/or data networks and/or voice applications, it becomes an integrated communications solution, of which the Cisco MCS 7800 series and ICS 7750 are examples.
IP Phones
IP phones replace their TDM siblings in an IP Telephony solution. In choosing an IP phone, you need to consider the following:
The protocols and even the version of the same protocol that the phone supports
Codec support
Number of Ethernet ports on the phone
Phone power requirements
Phone features (programmable buttons, number of lines, LCD screen, and so on)
Any safety or emissions regulatory requirements
If you have an active RJ-11 jack supplied by the CO, you will get a dial tone if you plug an analog instrument into it, no matter who manufactured the phone. In addition, you don't need an external power source for your phone, and, of course, your calling features, if any, are limited. IP phones are network devices (minicomputers), and there is no guarantee of interoperability in terms of IP phones from different vendors working with a single software-based PBX or call agent.
As part of any generic IP Telephony design, consider the preceding characteristics of IP phones and verify IP phone interoperability with a specific call agent. IP phones use a protocol to communicate with the call agent for call control. A SIP phone will not work with an H.323-capable call agent that does not support SIP. A gateway function is needed to allow a SIP phone to integrate into an H.323 network. The job of avoiding interoperability problems gets easier, of course, when the entire IP Telephony solution (call agent, gateways, gatekeepers, IP phones, and voice applications) comes from a single vendor, as is the case with the Cisco IP Telephony solutions presented later in this chapter.
A simple analog phone does not require an external power source. A more complex instrument (a cordless phone with an answering machine built into it, for example) does require a source of power to function, even if batteries supply that power. IP phones require power. In all deployment scenarios, the source of power for IP phones is a design consideration. If the IP phone instrument comes with an external power adapter, consider the number of outlets and/or power strips and extension cords that might be needed to accommodate any sizable deployment. It's best if the phone accepts inline power delivered over the network cabling from a LAN switch.
The IEEE 802.3af standard defines the requirements for inline power delivery over network cabling. Inline power can be delivered via a power-enabled switch module residing directly in a LAN switch, or via an external power patch panel that resides between the switch and the wall outlet.
An additional consideration when choosing an IP phone is the number of RJ-45 ports on the phone. One port is needed to connect the phone to the network, but if two ports are present, it means that a PC or some other network device could utilize it. IP phones with two RJ-45 ports are definitely preferable because they give you more options for accommodating other network devices present in user work areas. However, in the case of an IP phone that is installed in an unrestricted guest area, having a phone with two RJ-45 ports could be an invitation for someone to try to hack into the network.
VoIP Protocols
The ITU-T H.323 recommendation and the IETF's SIP and SIP-related RFCs are the dominant sources for IP Telephony protocols. H.323 has normative references to 58 other recommendations, which means that those recommendations contain provisions that, through a reference in H.323, also become provisions of H.323. The list of normative references in SIP's RFC 3261 is 43.
For H.323 and SIP, there are thousands of pages of specifications for many aspects of multimedia communications over packet networks. Keep in mind, however, that only parts of the totality of these specifications apply to IP Telephony, which represents only one aspect of multimedia communications over packet-switched networks. When H.323 and SIP are complemented with the Media Gateway Control Protocol (MGCP), Megaco/H.248, and the Skinny Client Control Protocol (SCCP) from Cisco, it might seem like you have plenty of protocol choices when considering an IP Telephony solution deployment. But are these choices really that plentiful?
H.323 and SIP are competitors, but these two “families” (or umbrellas) of protocols are also complementary. It follows that H.323 and SIP are responsible for somewhat similar functions. Both H.323 and SIP are used to set up and to control communication sessions on packet-switched networks. Given the fact that gateways convert between same-layer or similar-function protocols from different architectures, if the functionality of a composite IP Telephony solution dictates the use of products based on both protocols, H.323/SIP gateways should save you from the painful choice between SIP and H.323.
As a general rule of thumb, H.323 is more prevalent and robust in the wide area deployments (ISP/carrier solutions), whereas SIP holds its own with H.323 in the LAN-based (SMB, enterprise) IP Telephony. With respect to H.323, you always need to be aware of the versions that a product supports if H.323 products from different vendors are to interoperate in multivendor environments. As IP Telephony matures, interoperability issues should decrease.
MGCP and Megaco/H.248 can also be viewed as competitors, but their functions are quite different from H.323 and SIP. When the call setup and control functions are removed from a gateway and incorporated into another device that possibly controls many different types of gateways, that device becomes a Media Gateway Controller (MGC), which is also referred to as a softswitch.
The gateway without control functions becomes a media gateway, which means that its functionality has been reduced to converting between media signals. MGCP and Megaco/H.248 operate between media gateways and MGCs. They facilitate greater scalability in complex IP Telephony deployments. The Internet community has proposed MGCP, whereas H.248/Megaco represents a joint (and rare!) effort between the Internet community and ITU-T. (Note the combined name.)