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
voice over IP (VoIP) network architectures. This connectivity to legacy systems (the PSTN and PBXs) is often called
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
This inheritance has some advantages and also some disadvantages. The primary advantages include the fact that Cisco CME
If you are approaching Cisco CME from the point of view of an integrated and
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-
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.
Figure 3-2. 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,
Just as Cisco CME is built on top of the Cisco IOS voice infrastructure, the Cisco IOS voice infrastructure functions are, in
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:
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:
CCAPI acts primarily as a middle software layer. It attempts to provide a
Figure 3-3. Basic IOS Voice Gateway Software Structure
A voice call that
The following sections discuss the telephony and VoIP call leg components in greater detail.
Cisco IOS Voice 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.
Figure 3-4. Telephony Interface Internals
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
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
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
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
(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
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
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
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.
Figure 3-5. SCCP IP Phone Extension to Cisco IOS Voice
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
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
Analog phone and SCCP operation examples include
H.323/SIP peer-to-peer protocol operations include
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
Figure 3-6. SCCP IP Phone Call Between Two Cisco CME Systems Using H.323
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
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
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.
SCCP was developed by a company called Selsius, which Cisco
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.
SCCP does not provide just call control. It also provides a significant ability to control the IP phone user interface (softkey
SCCP runs over TCP/IP and usually uses TCP port 2000. At startup, an SCCP IP phone runs through three main phases:
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:
The phone receives the following detailed command instructions from the SCCP controller:
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
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
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
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
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
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
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
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
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
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
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).