Cisco CME Architecture

Cisco CME Architecture

Historically, the evolution of voice support on Cisco routers first included Public Switched Telephone Network (PSTN) and Private Branch Exchange (PBX) connectivity into voice-over-packet networks, the traditional toll bypass voice over IP (VoIP) network architectures. This connectivity to legacy systems (the PSTN and PBXs) is often called PSTN gateway or voice gateway functionality. Support for IP phones followed next in the evolution with the development of Survivable Remote Site Telephony (SRST). When all these technologies were in place, a comprehensive standalone telephony solution such as Cisco CME was a natural next step. All the Cisco CME phone features are built on top of these two foundation elements: the router engine and the VoIP infrastructure first developed to provide PSTN and PBX gateway connectivity on a router. This is an important perspective to embrace in understanding Cisco CME and its architecture.

This inheritance has some advantages and also some disadvantages. The primary advantages include the fact that Cisco CME leverages the extensive base of Cisco IOS IP routing and voice technologies. This lets Cisco CME interoperate with a large installed base of IP network types and different voice protocols and technologies. It also means that new developments in the Cisco IOS IP and voice technology area tend to get bundled automatically with each new release of the Cisco CME software. This significantly reduces the risk of rapid marketplace obsolescence inherent in any new technology. Considering the ongoing competition in the VoIP marketplace between the International Telecommunication Union (ITU)-sponsored H.323 and Internet Engineering Task Force (IETF)-sponsored SIP technologies, this has particular importance for anyone concerned about picking the "wrong" technology. Because Cisco CME is based on Cisco IOS voice technology, it includes both H.323 and SIP support. It will continue to evolve as these technologies unfold in the industry.

The disadvantage of this integrated approach is that the Cisco CME platform was not originally designed to be a phone system. It was designed as a router with the ability to handle voice traffic. This means considerations and compromises are reflected in how Cisco CME is designed, configured, and managed and in how it operates. How you view these trade-offs may depend in part on whether you are looking for a phone system as a standalone technology purchasing decision or as part of a larger communications infrastructure and longer- term investment.

If you are approaching Cisco CME from the point of view of an integrated and converged voice and data communications infrastructure, you are more likely to see the extra complexity and capabilities that come with the Cisco IOS foundation as a good thing and as necessary to meet your business networking needs. The complexity that's inherent in Cisco IOS isn't arbitrary. It has evolved over many years of dealing with the real-world network intricacies that exist when you try to interconnect multiple pieces of equipment, and evolve your network in several phases over an extended period of time.

Cisco CME Software Architecture

The Cisco CME phone features in Cisco IOS are built on top of the Cisco IOS voice infrastructure foundation. This gives Cisco CME access to both H.323 and SIP interfaces. It also lets Cisco CME be protocol- agnostic regarding H.323 versus SIP for VoIP calls across intersite links. The protocol used to control local IP phones is the lightweight Cisco Skinny Client Control Protocol (SCCP), often simply called "Skinny." This protocol gives Cisco CME tight control over the IP phones and lets it offer a rich set of phone features from a call control, phone user interface, and provisioning point of view.

SCCP is a Cisco-specific interface that is used only internally between the Cisco CME router and the IP phones it controls. The external interface that Cisco CME exposes to phone connections across its public IP link to other sites uses the standards-based H.323 or SIP protocols. Figure 3-2 shows the VoIP protocols used by a Cisco CME system.

The internal use of SCCP to its attached IP phones also allows Cisco CME to bypass some of the significant challenges that often arise when Network Address Translation (NAT) is deployed with voice protocols such as H.323 and SIP. NAT is often required in VoIP networks to avoid the need for a large number of public IP addressesone for each IP phone. Cisco CME requires only a single public IP address to handle external H.323 or SIP calls, regardless of the number of IP phones deployed in the office.

The Cisco CME SCCP-based IP phones can be deployed using private IP addresses and still have access to external H.323 and SIP networks (without requiring the use of NAT). This approach provides Cisco CME with standard interfaces for connecting it to external devices. This approach also takes advantage of a Cisco-owned and -controlled protocol with which to build enhanced internal phone features.

Building advanced phone features using agreed-upon, fully ratified, interoperable standard protocols is very difficult. In many cases, no agreed-upon standards exist for implementing some phone features, especially in a fully peer-to-peer protocol environment. Getting even basic features such as call transfer, call hold, and call forwarding to work in a truly standards-based, vendor-independent manner is still a tough business and engineering challenge. Nevertheless, as the standards evolve to specify how these advanced features might be achieved, Cisco CME will also evolve to support them. Right now, however, a SCCP-based phone is the only way to accomplish advanced IP phone features.

Just as Cisco CME is built on top of the Cisco IOS voice infrastructure, the Cisco IOS voice infrastructure functions are, in turn , built on top of the underlying Cisco IOS IP infrastructure. This gives Cisco CME access to quality of service (QoS) facilities such as voice packet marking, classification, prioritization, and Resource Reservation Protocol (RSVP). The IOS IP infrastructure also includes many other useful elements, such as Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol. (TFTP), virtual LAN (VLAN), HTTP, access control lists (ACLs), and an extensive choice of WAN interface types and protocols. These include Ethernet, Frame Relay, Asynchronous Transfer Mode (ATM), DSL, fiber, ISDN, high-speed serial, and several more. These concepts and terms are briefly defined in the glossary near the end of this book. The following lists the layered components , top to bottom, that underlie Cisco CME:

• CME IP phone services SCCP, GUI interface

• IOS voice services Telephony interfaces, H.323, SIP, RSVP, RTP Control Protocol (RTCP)

• Cisco IOS protocols IP routing, TFTP, DHCP, HTTP, virtual private network (VPN), security, Telnet

• Cisco IOS network interfaces Ethernet, Frame Relay, ATM, DSL, VLAN, wireless LAN

The following sections introduce the Cisco IOS voice infrastructure functions that Cisco CME relies on to provide PSTN trunking and VoIP services.

Cisco IOS Voice Infrastructure

To understand Cisco CME fully, you should have at least a basic understanding of the Cisco IOS voice infrastructure functionality used for the Cisco IOS PSTN and PBX gateways. This section gives a brief overview of the Cisco IOS voice infrastructure. For additional resources that cover this topic in greater depth, see the "Recommended Reading" section at the end of this chapter.

The Cisco IOS voice infrastructure software has three primary components:

• Telephony interfaces (Foreign Exchange Office [FXO], ear and mouth [E&M], Foreign Exchange Station [FXS], T1, E1, Primary Rate Interface [PRI], and Basic Rate Interface [BRI])

• Application layer software (session application plus the Toolkit Command Language [TCL] and Voice Extensible Markup Language [VXML] scripting languages)

• Voice-over-packet interfaces (H.323, SIP, voice over Frame Relay [VoFR], voice over ATM [VoATM])

These components communicate with each other primarily through an internal IOS call control application interface called Call Control Application (CCAPI). CCAPI itself has two main interfaces:

• The first connects to the telephony and packet interfaces. These are collectively known as service provider interfaces (SPIs).

• The second connects to the application layers .

CCAPI acts primarily as a middle software layer. It attempts to provide a protocol-independent abstraction between the upper application software layer and the lower-layer SPIs. The intent of this design is two-fold. It allows the application layer to operate on the lower-level SPIs and to largely be able to manipulate call legs (bridged segments of an end-to-end call) without regard for their fundamental type (telephony, VoIP, and so on). For example, the topmost application layer can set up a telephone call to a particular phone number mostly without needing to know if the phone number corresponds to a PSTN or VoIP endpoint. The resolution of a telephone number as being either a PSTN or VoIP destination is usually determined by database-like command-line interface (CLI) configuration entries called dial peers. Figure 3-3 shows the layered design of the Cisco IOS voice infrastructure software.

A voice call that passes through a Cisco IOS PSTN gateway is typically composed of two call legs or call segments. One call leg normally exists between the physical telephony (PSTN) interface and the application layer. The second call leg exists between the application layer and the VoIP packet interface. The application layer joins (or bridges) the two call legs to create a composite call. This example describes a call consisting of one telephony leg and one VoIP leg, which is typical for a router used as a PSTN-to-VoIP voice gateway. However, calls can also be constructed that have two telephony call legs (for example, for analog phone-to-PSTN calls or fax-to-PSTN calls). Also, calls can be constructed that have two VoIP call legs. (You'll read more about this in Chapter 7, "Connecting Multiple Cisco CMEs with VoIP.")

The following sections discuss the telephony and VoIP call leg components in greater detail.

Cisco IOS Voice Telephony Interfaces

Cisco IOS voice-enabled routers provide a wide range of modular telephony interface options offering significant choices of analog and digital PSTN connectivity. More information on the hardware and signaling variations supported appears in Chapter 6, "Cisco CME PSTN Connectivity Options." Here the discussion centers on the Cisco software infrastructure that handles the Cisco IOS voice router telephony interfaces.

The Cisco IOS voice software architecture to a large extent mirrors the physical construction of the telephony interfaces. As shown in Figure 3-3, below the CCAPI layer on the telephony side is a telephony abstraction layer called Virtual Telephony Service Provider (VTSP). This layer provides a software abstraction layer that hides the telephony protocol specifics of the physical telephony interface. Below the VTSP layer are alternative software adapters that provide telephony-specific protocol support for the various types of telephony interfaces (such as FXO, FXS, and E&M). You will read more about this software layer shortly, when IP phone connectivity is discussed. This architecture is shown in Figure 3-4.

IOS Voice-Over-Packet Interfaces

The Cisco IOS voice infrastructure software includes support for a range of voice-over-packet interfaces, including the VoIP H.323 and SIP interfaces used by Cisco CME. Also included are protocols such as Media Gateway Control Protocol (MGCP) and VoATM using AAL2 (VoAAL2) encapsulation. Cisco CME does not support MGCP or VoAAL2. In addition, the Cisco IOS voice infrastructure software supports the older Layer 2 voice protocols, such as VoFR and VoATM using AAL5 encapsulation. Cisco CME provides some limited interworking with the VoFR and VoATM protocols. This interworking is primarily supported to provide a migration path for networks upgrading from VoFR/VoATM technologies to H.323/SIP VoIP. The primary interfaces of concern in the Cisco CME contextand those addressed in the rest of this bookare the H.323 and SIP VoIP interfaces.

An important point to highlight in this discussion of interfaces is that the various SPI interfaces are largely modular and independent of each other. The SIP and H.323 interfaces operate without significant awareness of the type of analog/digital telephony interface involved. This is an important point to be aware of for the discussion of the Cisco CME extensions to the Cisco IOS voice infrastructure.

In addition to the basic H.323 and SIP protocol support for making VoIP calls, the Cisco IOS VoIP SPIs provide access to voice QoS controls such as RSVP, IP precedence, or DiffServ Code Point (DSCP) marking of voice packets and low-latency queuing (LLQ) of voice media packets. Also included is support for H.323 gatekeeper (GK) (and SIP Registrar) registration of endpoint telephone numbers (for call routing purposes).

Cisco IOS Voice Application Software

The main purpose of the Cisco IOS voice application software layer is to handle call routing. This is in the context of a Cisco IOS voice-enabled router acting as a voice gateway between the VoIP and PSTN telephone call domains. The primary function of the voice gateway is to connect a call on the PSTN side with a call on the VoIP side.

Calls can be routed between the PSTN and VoIP domains based on fixed configurations contained in dial peer CLI entries as part of the router configuration. The dial peers can optionally reference external entities such as an H.323 GK for assistance in determining the correct call path (for example, IP address) for a particular phone number.

The application layer can also provide services in the context of acquiring the destination number for placing a call. In the simplest case, the destination called number is obtained en bloc (all digits delivered at once) from an incoming call setup message on a PSTN ISDN interface (a direct inward dial [DID] call). In other cases, the application layer may be responsible for providing simple dial tone to an analog phone connected to a router's FXS analog voice port. In this case, the application layer code collects dialed digits in one-digit-at-a-time mode from the phone user and progressively matches the dialed number string collected against the dial peer information until an unambiguous match is found. The application then routes the call based on the information in the matched dial peer (SIP, H.323, or plain old telephone service [POTS], for example).

The IOS voice application layer can provide an interactive voice response (IVR) interface to a caller. It also can operate a dialog in which the IVR plays voice prompts and collects the caller's response in the form of dual-tone multifrequency (DTMF) digits. An example of an IVR dialog would be to answer incoming calls by playing a voice prompt that presents the caller with a short list of menu choices, 1 to 9. For example, a prompt such as "Press 1 for sales; press 2 for support" can be used. The caller then presses a digit in the appropriate range, and the application layer routes the call to a preconfigured destination.

Phone dialogs for IVR can be constructed using either Tool Command Language (TCL) scripts or Voice Extensible Markup Language (VXML). TCL scripts are typically loaded into the router's internal Flash memory or can be fetched from a remote server using TFTP. VXML dialogs are typically accessed from a remote web server using HTTP. IVR dialogs can be used for both incoming PSTN calls and calls that arrive at the router over VoIP.

Cisco CME Extensions to the Cisco IOS Voice Infrastructure

Even though the Cisco CME IP phones use VoIP technology, an IP phone is first and foremost still a telephone . As a result, the IP phones fit within the set of Cisco IOS voice telephony interfaces, as shown in Figure 3-5.

From the perspective of the higher application software layers, the basic operations performed on an IP phone are the same as that for an analog phone connected to an FXS port on a router. Both types of phones signal an off-hook event when the handset is lifted for an outgoing call, and both types of phones expect to get dial tone in response. The logic that drives analog and IP phones is very similar. This is also the reason for some of the terminology that Cisco CME uses to describe its IP phones. In Cisco CME, the SCCP-based IP phones are called ephones (for Ethernet phones). This conceptually helps differentiate the SCCP-based IP phones from SIP- and H.323-based VoIP phones.

This may not be the architectural approach you might have expected. After all, an SCCP phone is indeed an IP phone, and it uses VoIP technology, so you might more reasonably expect it to be handled as part of the VoIP interface software infrastructure. One of the main reasons for this is that the Cisco CME IP phones use SCCP for control. SCCP is a master/slave-type protocol (and is similar in many ways to MGCP). The H.323 and SIP protocols are peer-to-peer protocols and behave in significantly different ways. From a purely logical point of view, there isn't much difference between using SCCP to control an IP phone and using a proprietary time-division multiplexing (TDM)-based (D channel) protocol to control a digital phone handset on a legacy digital PBX. The main difference between these two is in the physical transport layer used to convey the messages between the phone and the software that controls it. Consider the following basic operations that are communicated via SCCP to an IP phone, and compare them to the operations that are used in the peer-to-peer H.323/SIP context.

Analog phone and SCCP operation examples include

• On-hook and off-hook

• Dial tone on and off

• Digit press

• Ringer on and off

• Display caller ID

• Select line

• Press function key

H.323/SIP peer-to-peer protocol operations include

• Call setup

• Proceeding

• Alerting

• Connected

• Disconnected

Figure 3-6 shows a call from an SCCP IP phone attached to Cisco CME system 1 using H.323 to establish a call across a VoIP link to a second SCCP IP phone attached to Cisco CME system 2. This figure illustrates the relative roles of SCCP, which is used for local phone control, and H.323 (or SIP), which is used to make calls between independent peer systems. This figure provides only a simplified view of the message exchange for clarity. It does not include the SCCP messages for softkey selection, call state notification, and other functions.

It's worth noting that IP phones that natively support H.323 and SIP do indeed communicate with the Cisco IOS voice software through the H.323 and SIP voice-over-packet interfaces. In this case, operations such as dial tone and digit press are handled entirely and autonomously within the H.323/SIP phone itself. In this scenario, the IP phones act as fully independent VoIP network peers. They don't need assistance from the router for basic tasks such as collecting dialed digits before an outbound call is placed. This also means that the router can't easily control the phone actions and user interface over protocols such as H.323 and SIP because of the degree of autonomy that peer-to-peer protocols provide to the phone.

Note

A peer-to-peer protocol provides a means to establish communication between two equivalent devices. A master/slave protocol provides the means for one device (with more intelligence or network awareness) to control another (with less intelligence).

Using SCCP to control the Cisco CME IP phones provides some significant advantages, as explained in the following section.

Introducing SCCP

SCCP was developed by a company called Selsius, which Cisco acquired in 1998. This acquisition brought the Cisco CallManager IP PBX product to the Cisco product portfolio. Cisco CallManager primarily addresses the enterprise market for VoIP-based phone systems. SCCP was developed as a lower-cost alternative to H.323 given the larger CPU and memory demands of H.323 (because H.323 is designed as a peer-to-peer protocol and requires significant intelligence on both communicating devices). As such, H.323 doesn't directly support the operations needed to provide PBX phone features. Selsius developed SCCP to support the creation of low-cost VoIP phones using Ethernet interfaces to connect the phones to a system controller (a PC running Microsoft Windows). SCCP has remained mostly unchanged since the Selsius days, even though the IP phones themselves have gone through considerable changes from the original Selsius models. SCCP mostly predates the SIP and MGCP standards.

SCCP is designed to provide endpoint control of VoIP telephones. The key word here is control . In most private telephone networks, maintaining full and absolute control of the actions of telephones within the network is a key concern. Telephone system administrators need to control which features a particular phone can access, as well as which telephone numbers the phone is permitted to dial. This is a fundamentally different paradigm from true peer-to-peer operation. Normally the designation of a device as a peer implies that it largely can act independently of other peer devices in the network. Enforcing a degree of control over peer devices in a network from a central control point is possible, but it's harder to do, more complex, and more easily circumvented.

The easiest form of peer control that can be imposed is control of actions that cross network boundaries (such as controlling which external telephone numbers can be accessed). Controlling the actions that occur between peers in a local network is much more difficult, however. In addition, the need to assert different permissions for different peer devices also implies the need for a strong authentication mechanism to be able to positively identify which peer device is which.

SCCP does not provide just call control. It also provides a significant ability to control the IP phone user interface (softkey buttons and phone display). SCCP includes a number of provisioning functions as well. These two items are normally considered outside the scope of the H.323 and SIP peer-to-peer protocols and, therefore, are not readily subject to standardization. However, provisioning and user interface functions must be addressed when constructing a real phone system. From a call control perspective, SCCP has many things in common with the MGCP standard that is used in the telephony service provider and enterprise market spaces.

SCCP runs over TCP/IP and usually uses TCP port 2000. At startup, an SCCP IP phone runs through three main phases:

• Registration The phone locates a controller (such as Cisco CME or Cisco CallManager) and identifies itself to the controller. The newer -model SCCP phones can also perform certificate-based authentication as part of the registration process.

• Provisioning The controller gives the phone information about the functions of the phone's buttons (button template and softkey sets) as well as the phone numbers associated with the phone. Some provisioning steps also occur using TFTP in which the phone uses TFTP to read a phone configuration file from the controller.

• Operation The phone can make and receive calls.

Within the operational state, the phone acts mostly as a dumb endpoint. It signals the following discrete user actions to the controller as they occur:

• On-hook

• Off-hook

• Numeric keypad button press

• Softkey button press

• Line button press

The phone receives the following detailed command instructions from the SCCP controller:

• Ringer on

• Ringer off

• Call progress tone on or off

• Calling and called number display

• Softkey set display selection (per line context)

• Call state notification, including on-hook, off-hook, alerting, connected, ringing, hold, transfer, and so on

• Media control (voice path), including the voice compression codec selection, such as G.711 or G.729

The SCCP phone has autonomous control over some local context items such as speakerphone and headset activation, as well as some local provisioning such as ringer volume, ringer sound, and handset and speakerphone volume settings. Most SCCP phones also autonomously maintain internal directories of recently received, missed, and placed calls.

In addition to SCCP, most of the IP phones equipped with a display also support a simplified and limited web browser function using the HTTP and XML protocols. Operation of the HTTP protocol is largely independent of SCCP. In most cases, the web browser function is used only when the phone is not being used for telephone calls. The web browser function allows the IP phone to be used as an information access point. The HTTP and XML interfaces are made available to non-Cisco third-party developers to construct information services and applications. The phone also uses the web browser interface to provide access to the Cisco CME system's internal telephone directory.

Cisco CME as a Gateway to the PSTN

As covered in the previous sections, the voice gateway functions (providing PSTN connectivity) of a voice-enabled Cisco IOS router are mostly independent of the Cisco CME IP phone functions. This has its good points and its not-so-good points.

On the positive side, the independent functions may simplify the overall network architecture. You can use and provision the Cisco IOS PSTN trunk functions independent of whatever Cisco CME functions you choose to use. This means that a single router can fulfill the roles of phone system controller and PSTN gateway, rather than needing two separate devices for these roles. Perhaps you already have a Cisco IOS voice-enabled router you are using to provide a toll-bypass link between a key system or small PBX at a remote site and a central headquarters campus phone network. If so, you can turn on Cisco CME features without disrupting existing operations. In addition, you can continue to operate and administer your toll-bypass network without much regard for the presence of Cisco CME systems in your network. Of course, you will probably have to make some dial plan configuration changes simply to accommodate the phone numbers you choose to associate with the Cisco CME system.

The downside of this separation of Cisco CME and PSTN trunk functions is that you can't easily view Cisco CME as a single, simple, self-contained system. You have to embrace the modular nature of Cisco IOS functions, and this inevitably deprives you of a truly monolithic administration and management solution. This isn't surprising when you consider the huge breadth of features built into Cisco IOS and the fact that the voice features are only a small fraction of the services that Cisco IOS offers. Your Cisco CME router is probably also your Internet gateway and access concentrator, firewall, Ethernet switch, terminal server, and DHCP server or relay agent.

Cisco CME as a Gateway to SCCP Phones

In addition to seeing your Cisco IOS router as an Internet gateway, a PSTN gateway, and potentially a toll-bypass gateway, you can also view the router's Cisco CME functions as providing a gateway to SCCP and SCCP IP phones. This is consistent with the overall role of Cisco IOS to provide protocol conversion and interworking for a broad set of voice and data protocols.

Leveraging Cisco IOS Voice Infrastructure Functionality for SCCP

Cisco CME provides Cisco IOS with an interworking function that allows the connection of SCCP IP phones to other IP-based protocols such as SIP and H.323. This construction allows for evolution within the SIP and H.323 network environments without directly affecting SCCP-based phone services. At the same time, SCCP services and SCCP-based IP phones can evolve without the delay implied in the development and standardization processes of the IETF and ITU. This "divide and conquer" approach provides the best of both worlds : standardization and third-party interworking where that is required, and flexibility and rapid product innovation where those are needed. In addition, the modular separation of the local phone system internal protocols from the "long-distance" VoIP backbone network protocols provides a degree of insurance against future changes in the Internet and WAN connectivity environments.

Although H.323 and SIP are currently the protocols of primary interest in the small office and remote branch office market space, there's no guarantee that this direction will not change at some point in the future. For example, although Cisco CME 3.2 doesn't support direct interworking between SCCP and MGCP, there's no architectural reason that this cannot be added if needed in the future. The same is true of other protocols that may possibly evolve in the voice-over-DSL, voice-over-cable, and even voice-over-wireless network markets.

It is also worth noting the close relationship between the Cisco CME and SRST Cisco IOS feature set. SRST lets a Cisco IOS voice-enabled router act as a failover call controller for Cisco CallManager in voice networks that operate the SCCP protocol from a centralized Cisco CallManager cluster to SCCP IP phones located at remote sites (across a WAN link). SRST provides an enhanced degree of fault tolerance to guard against remote-site IP phones having no dial tone upon a WAN link or an IP connectivity outage to a central site Cisco CallManager network cluster. An SRST router provides a Cisco CallManager of last resort to the SCCP IP phones at a remote office site should WAN connectivity fail.

The core software engine that provides the SCCP support for Cisco CME is the same software that underpins SRST. The Cisco IOS product features licenses for the SRST and Cisco CME that are largely interchangeable. If you buy a Cisco CME system for an autonomous office environment, you can easily evolve the network into a centralized Cisco CallManager-based system later, and you can migrate your Cisco CME licenses to the SRST environment. The PSTN trunks on the router and the IP phones can simply be reconfigured to move a remote office from being a phone system under local Cisco CME control to a centralized Cisco CallManager system with SRST redundancy.

IP Phone Address Scope and NAT/Firewall

Another advantage of using SCCP as the protocol for local IP phone control is that it avoids problems with NAT and firewalls that often arise in the H.323 and SIP contexts. If you operate H.323 or SIP as your phone endpoint protocol, this usually means that the phone's IP address must be reachable by all other endpoints that need to exchange telephone calls with it. The simplest way of doing this is to give every H.323/SIP phone in your network a public IP address. This approach creates two problems:

• A shortage of 32-bit IPv4 addresses, which makes this approach unworkable for phone systems of any real size

• A need to protect any phone with a public IP address from hackers by using a firewall

If you introduce a firewall, the firewall software must be able to understand all the H.323/SIP messages that pass through it. The firewall must read all the H.323/SIP messages so that it can decide which messages are associated with legitimate phone calls it should pass and which messages are potentially hostile actions from a hacker. This means that every time a new feature or function is added to the H.323/SIP protocol, the firewall software potentially needs to be upgraded as well.

With SCCP used as the internal protocol, there is no need to allow the H.323/SIP messages to enter the internal network behind the firewall. You have the option of terminating the H.323/SIP messages outside the firewall in a less heavily protected area of your network.

The alternative approach to providing a public IP address for every H.323/SIP phone is to use NAT. NAT allows you to insert a NAT gateway device between a group of IP phones that use private IP addresses and the public Internet. NAT takes advantage of the fact that each IP address can be accessed on a range of different TCP/UDP port numbers. There are 65,536 port numbers available for each IP address. (Actually, there is effectively a separate pool of 65,536 port numbers for each distinct IP protocol, such as TCP and UDP.) NAT allows you to use the single IP address of the NAT gateway to represent the pool of IP phones, and then multiplex the IP connection between the phone and the Internet by using a different port number on the NAT gateway for each individual phone. This approach is used extensively within IP networks to significantly reduce the number of unique IPv4 addresses needed.

The problem with NAT is similar to the problem with firewalls. The NAT software also must understand every H.323/SIP message that passes through it so that it can provide the appropriate NAT translation for every IP address that is embedded in the H.323/SIP messages. This means that every time new fields and messages are added to the H.323/SIP protocols, the NAT software has to be upgraded as well.

Of course, another solution to the IPv4 address shortage issue is to use IPv6. However, this has widespread ramifications for your entire network infrastructure, and this topic is beyond the scope of this book.

The Cisco CME SCCP gateway architecture provides a solution similar to NAT. Like NAT, it lets the SCCP IP phones use private IP addresses. Where the SCCP gateway approach wins over the NAT approach is that there's no direct need to intercept and translate messages as they pass through. In the Cisco CME SCCP gateway router case, the H.323/SIP messages are terminated on the router instead of passing through. This hides the complicated detail of the H.323/SIP protocol implementation from the SCCP IP phones. What's more, not only are the H.323/SIP control messages terminated on the Cisco CME router, but so are the H.323/SIP media streams. The Cisco CME router public WAN IP address is used as the termination point for both the H.323/SIP control and media IP packets. Termination of the media stream using the Cisco CME router's external public IP address avoids the need for NAT to contend with the complexity of voice protocols. Passing the H.323/SIP protocol through NAT requires NAT to look at all H.323/SIP control messages, and then translate all the media IP addresses they contain. NAT may still be required for other nonvoice services such as HTTP, but NAT support for HTTP is generally much less complex.

Media Path Handling and QoS

The media path for calls between local IP phones on the same Cisco CME system runs directly between the IP phones. SCCP is used to set up the connection path and provide each IP phone with the IP address and port number to use when sending voice media packets intended for the other phone. The packets are then switched as needed by your Layer 2 Ethernet switch infrastructure, or perhaps they are Layer 3 IP routed if the phones are on different LAN segments. This is mostly pure IP connectivity. Basically, no voice-aware software is involved in transferring packets from one phone to the other. If you use a VLAN for your phone network (recommended), the phones may add priority marking of the packets using the VLAN Class of Service (CoS) priority field in the VLAN Layer 2 encapsulation. (VLAN CoS is set to five by the phones themselves for media stream packets.)

For calls between IP phones and the PSTN trunk voice ports, the media stream for a call flows from the IP phone to the router and then is internally routed to the router's PSTN voice port. For the reverse media flow direction from the router voice port to the phone, the media packets are given internal priority over most other packets to ensure that they are transmitted first on the Ethernet interface connecting to the phone LAN or VLAN. This avoids packet queuing and congestion caused by any contention between the voice media flow and other data flowing through the Ethernet interface (such as HTTP and FTP data traffic).

For a voice call that runs from the SCCP IP phone to the Cisco CME router's WAN connection using H.323/SIP, the voice packets are transmitted by the phone and addressed to the Cisco CME router's IP address (typically to the default gateway IP address for the LAN segment that the phone is on). The IP media packet from the phone is terminated on the router. The IP and UDP headers are stripped from the packet, leaving just the voice payload with its Real-Time Transport Protocol (RTP) encapsulation header. This packet is then passed to the H.323/SIP software stack in the router. The H.323/SIP software applies a new IP and UDP header using the destination media address and port number negotiated by the H.323/SIP protocol with the far-end H.323/SIP endpoint device. The H.323/SIP software also usually rewrites the RTP SSRC (the Synchronization Source field defined in IETF RFC 1889, which covers RTP) source identifier field. This address translation is shown in Figure 3-7.

Figure 3-7. Cisco CME Media Path Handling

Example 3-1 presents the relevant extract of the Cisco CME router's configuration for this figure.

Example 3-1. IP and DHCP Configuration for the Cisco CME Router

Router#

show running-config

ip dhcp pool cme-phones
   network 192.168.0.0 255.255.0.0
   default-router 192.168.0.1
   option 150 ip 192.168.0.1
!
interface FastEthernet0/0
 ip address 192.168.0.1 255.255.0.0
!
interface Multilink1
  ip address 172.16.10.1 255.255.255.0
  max-reserved-bandwidth 100
  service-policy output qos-policy
  ppp multilink
  ppp multilink group 1
!
interface Serial0/0:0
  no ip address
  max-reserved-bandwidth 100
  encapsulation ppp
  ppp multilink group 1

The H.323/SIP software sets up and maintains a RTCP connection for each media flow. This disassembly and reassembly process for the media stream packets allows H.323/SIP to apply independently whatever packet treatment it needs. This may include setting the IP precedence or DSCP marking for the packet flow and low-latency priority queuing in the context of the egress WAN interface. It also allows the H.323/SIP router software to apply Call Admission Control (CAC) policies to avoid oversubscription of the WAN bandwidth, plus make use of protocols such as RSVP to ensure appropriate QoS across the WAN connection.

Note that the SCCP IP phones do not natively support RSVP or RTCP. So the Cisco CME disassembly and reassembly operations allow the router to act as a proxy device to support RSVP and RTCP services where needed. The assumption here is that the media stream flow protection and strict prioritization provided by RSVP are needed only on the WAN segment of the media path. It is also assumed that RSVP per-flow management is not required within the high-bandwidth context of the local LAN (over the last hop between the router and phone).