By definition, analog signals are sent over wires or through air and carry information through some combination of frequency, phase, and amplitude. You can find trunks that use analog signaling in small offices or in offices where the telco switch does not support digital signaling. Analog signaling types usually fall under the subscriber-to-network signaling category. The three common analog trunk types are loop start, ground start, and ear and mouth (E&M).

Loop-start and ground-start trunks use the same wire pair for both audio and signaling. Most of the telephone connections to households around the world use loop-start signaling. E&M uses separate wire pairs for audio and signaling. You can find E&M signaling trunks in older PBX/central office switches.

The telephone system usually uses dual-tone multifrequency (DTMF) or dial pulse/digit transmission methods to transmit the digits that the subscriber dials. DTMF, which is the most popular method, uses two simultaneous voice-band tones for dialing, such as touch-tones. Dial pulse, which is an older method, uses a series of make and brake pulses to represent digits. In pulse dialing, an off-hook state is represented by a make state of the pulse, and an on-hook state is represented by a break state of the pulse.

Analog trunks require a physical set of wires per trunk and thus might not be the best method when provisioning a large number of trunks. Hence, higher-density digital trunks are used in larger organizations that have higher call volumes. There are two varieties of digital signaling trunk types: T1 and E1 circuits. When a network supports voice on T1 and E1 circuits (also used for data transmission), two types of signaling mechanisms are used:

Channel-associated signaling (CAS)

Common channel signaling (CCS)

CAS falls into the subscriber-to-network and CCS into intranetwork signaling.

H.323 is an International Telecommunication Union (ITU) specification to carry real-time voice traffic such as telephone calls, video, and data over an IP network. The H.323 protocol specification describes how a session between two H.323 endpoints is created and maintained. The following are the main components of H.323:

The preceding three components use TCP for transport. The H.323 standard has gone through many revisions. The current standard is H.323 Version 4. Cisco CallManager 4.0 is compliant with H.323 Version 2 standards.

The “Call-Flow Scenarios” section later in this chapter discusses the call flow sequence between the IP phone and a voice gateway using the H.323 protocol.

SIP is an RFC standard (RFC 3261) from the Internet Engineering Task Force (IETF), the body responsible for administering and developing the mechanisms that comprise the Internet. SIP is one of the most talked about protocols these days because of its wide interoperability with other products.

SIP is a peer-to-peer protocol. The peers in a session are called user agents (UAs). A user agent can function in one of the following roles:

Typically, a SIP endpoint is capable of functioning as both a UAC and a UAS, but it functions only as one or the other per transaction. Whether the endpoint functions as a UAC or a UAS depends on the UA that initiated the request. From an architectural standpoint, the physical components of a SIP network can be grouped into two categories: clients (endpoints) and servers. Figure 1-6 shows the SIP architecture.

Figure 1-6. SIP Architecture

In Figure 1-6, the SIP clients are phones such as Cisco SIP phones (7960, 7940, and ATA-18x can be configured as SIP phones by loading SIP firmware) and SoftPhones that are loaded on the user’s PC/laptop. The routing entities within the SIP architecture are called SIP servers. The following are the three types of SIP servers:

SIP uses six main messages for its basic functionality:

Users in the SIP network are identified by a unique SIP address such as an e-mail ID. Figure 1-7 shows the basic call setup diagram of a successful call when a SIP proxy server is present in the network.

Figure 1-7. SIP Call Flow Using SIP Proxy Server

Figure 1-7 shows the following sequence of events:

After SIP successfully completes the signaling, a media path between the two endpoints is established.

Starting with CallManager 4.0, CallManager can communicate with SIP endpoints (SIP IP phones, SIP gateways) via SIP Proxy server. This feature, referred to as “SIP Trunk” and shown in Figure 1-8, allows any CallManager-controlled device to communicate with a SIP network. Future releases of CallManager might include the direct support of SIP so that CallManager can talk to the SIP endpoints directly without the need for a SIP proxy server.

Figure 1-8. SIP Support in CallManager

As previously discussed, H.323 and SIP are based on the peer-to-peer model, whereas MGCP is based on a client/server model. As defined in RFC 2705, “MGCP is designed as an internal protocol within a distributed system that appears to the outside as a single VoIP gateway.”

MGCP uses the Session Description Protocol (SDP, RFC 2327) to describe and negotiate media capabilities, which is also used in SIP. SDP functionality is similar to H.245 capability in H.323.

There are two main components of MGCP:

MGCP messages are sent over UDP/IP between the CA and MG. The client/server relationship is maintained between the CA and MG. Voice traffic (bearer channels) is carried over RTP/UDP/IP or other transmission media (e.g., ATM). MGCP is independent of transport media and can be used to control ATM or circuit-switched gateways.

Similar to H.323, MGCP has undergone several revisions. As of CallManager 4.0, support for MGCP 0.1 is included. The current revision of MGCP is 1.0.

MGCP uses very simple commands in the negotiation process between the MG and CA and uses UDP as a transport layer protocol. The default port is UDP 2427, although it is configurable in the CallManager. Examples of the commands are CRCX (CreateConnection), MDCX (ModifyConnection), etc., and every command requires an acknowledgement. The following list describes commonly used MGCP commands, and Figure 1-8 shows the usage of these commands:

Table 1-1 shows the directions of the signaling messages exchanged between the CA and the endpoint or MG.

The “Call-Flow Scenarios” section later in this chapter discusses the call-flow sequence between the IP phone and a voice gateway using the MGCP protocol.

SCCP is a “lightweight” Cisco proprietary protocol that is based on a client/server model. In this model, all the intelligence is built into the server, which is a CallManager in the Cisco IPT solution. The client, which is a Cisco IP Phone, has minimal intelligence. In other words, the Cisco IP Phones have to do less work, thus requiring less memory and processing power. The CallManager, being the intelligent server, learns client capabilities, controls call establishment, clears calls, sends notify signals (i.e. message waiting indication (MWI), reacts to signals from the client (after the user presses the directory button on the phone), and so forth. CallManager communicates with the IP phones using SCCP and, if the call has to go through a gateway, communicates with the gateway using H.323 or MGCP.

By now you should have a good operational understanding of signaling protocols such as H.323, SIP, MGCP, and SCCP. These protocols provide call-signaling and control functionality and are responsible for setting up and tearing down the connection between the endpoints. After the connection is set up between the two endpoints, the source and destination endpoints can transmit and receive data by using RTP/RTCP. As discussed in the “Next-Generation Multiservice Networks” section earlier in this chapter, RTP/RTCP uses UDP for transport.

Figure 1-9 shows the IP packet header information that transports the RTP/RTCP packets. As you can see, the IPv4 header is 20 bytes, the UDP header is 8 bytes, and the RTP header is 12 bytes, which means that a total of 40 bytes of header information is required to transport the single RTP packet. After this 40 bytes of IP header information, two 10-byte frames (10 bytes per frame for G.729 codec voice samples) of real voice payload are carried, for a total of 20 bytes of voice payload. (The Cisco implementation puts two frames into one packet.) A simple math calculation shows that the header has twice the number of bytes that are in the real payload. To address this particular issue, you can use RTP header compression technique on point-to-point links. You must apply the RTP header compression on a link-by-link basis. When enabled on a gateway, you can use the RTP header compression technique compresses the 40-byte header into 2 or 4 bytes. However, enabling compression increases the load of the CPU on the router. You need to make a decision based on the number of calls that you need to send out through that gateway.

Figure 1-9. RTP, UDP, and IP Protocol Headers

CallManager servers are grouped to form clusters to support more devices (IP phones, gateways, and so forth). Starting with CallManager Version 3.3, a CallManager cluster can have up to eight CallManager servers running the CallManager service.

In addition to eight call-processing servers, the cluster can have servers such as a publisher server, a Trivial File Transfer Protocol (TFTP) server, and a Music on Hold (MoH) server. A publisher server has the read/write database of Microsoft SQL that stores the CallManager configuration information. There can be only one publisher server in a cluster. All other servers in the cluster, referred to as subscribers, have the read-only database. Subscribers pull their up-to-date subscriptions from the publisher server. During normal operating conditions, when the publisher server is available, the subscriber database is not used.

If a publisher is offline, you cannot perform updates such as adding new devices, changing user passwords, speed dials, or any other features that require a write operation on the database, because it is the only server that has the read-write database. However, the phones and other devices will continue to function normally.

CallManager stores the configuration of the IP phones in the TFTP server. (The default is to store it in the memory. You can change this default by modifying the service parameters. Chapter 9, “Operations and Optimization,” discusses these techniques.) The configuration information is stored in the XML format. The configuration file contains information such as device pool associations, directory URLs, authentication URLs, language-specific information, and so forth. IP phones and many other endpoints in the Cisco IPT network download the firmware and configuration information from the TFTP server.

Failure of a TFTP server is not an issue for the devices that were already configured and functioning before the failure. The devices store the previously loaded configuration and firmware in memory and use the same if they fail to contact the TFTP server during the reboot. However, an update to a phone’s configuration information that is stored in the TFTP configuration file will fail if the TFTP server is unavailable. In addition, provisioning of new devices fails if a TFTP server is not available.

For networks that require high availability, you can deploy two TFTP servers to provide redundancy and load balancing in the network. Cisco IP Phones and other Cisco IPT endpoints receive the TFTP server information via the DHCP server in the custom option 150. You can configure an array of IP addresses for option 150 in the DHCP server, instead of one IP address, to communicate to the Cisco IPT endpoints the existence of the secondary TFTP server.

The devices in the IPT network consume different amounts of memory and CPU resources on the CallManager servers. Based on the amount of resource consumption, Cisco has assigned a weight to each device, as shown in Table 1-3. This information is based on CallManager Version 3.3.(3).

The devices that are registered with CallManager consume additional server resources during transactions, which are in the form of calls. A device that makes only 6 calls per hour consumes fewer resources than a device that makes 12 calls per hour. The device weights that are assigned to the devices in Table 1-3 are based on the assumption that the device makes 6 or fewer calls during the busy hour call attempts (BHCA).

BHCA is the number of call attempts made during the busiest hour of the day. Before deploying a Cisco IPT solution, you must determine the busiest hour of the day for an organization and then scale the type of devices that are going to be deployed within the Cisco IPT solution. The BHCA varies from organization to organization and depends on the type of business (which can vary by season) and on the sales/promotional periods. A thorough network audit or analysis of historical call detail records is required to determine an organization’s BHCA.

Each device that requires more than six BHCA has a multiplier applied to its base weight. Based on the BHCA multiplier table, Table 1-4, if an IP phone is making 16 BHCA, its multiplier is 3. The total weight of the IP phone with 16 BHCA is equal to its base weight 1 (refer to Table 1-3) multiplied by 3. The multiplier is applied only to station/client devices and not to devices that are a media resource or gateway.

The total number of device units that a single CallManager can control depends on the server platform. Table 1-2 gives the details of the maximum number of devices per platform based on CallManager Version 4.0. You have to deploy multiple CallManager clusters if the number of IP phones plus other devices exceeds the device weights limit supported by a single cluster.

Device weights determine the maximum number of physical devices that can be registered to a CallManager subscriber. Some IP phone models support multiple lines (directory numbers or line appearances). Many IPT deployments have directory numbers that are shared across multiple IP phones and a large number of dial plan entries that include route patterns; translational patterns require an extra amount of resources (CPU, memory) on the CallManager.

Dial plan weights provide the limit on the number of such dial plan entries configured in a CallManager subscriber. Dial plan weight calculations provide guidelines to size the cluster. Two types of dial plan weights are available:

In larger IPT deployments, you should register all the endpoints to the subscribers and none to the publisher server. That way, you can prevent the publisher server from doing call-processing activity. Subscriber dial plan weights consist of the following main types:

In summary, dial plan components contribute the weights outlined in Table 1-5.

To understand more about the dial plan weight calculations, consider Figure 1-10. When IP phone A (primary extension 2000), which is a unique line appearance, is registered with subscriber CCM A, the dial plan weight on subscriber CCM A is 10 units (5 units for the IP phone and 5 units for the unique line appearance (primary extension 2000). Subscriber CCM B in cluster 1 has a dial plan reachability weight of 3 units to reach extension 2000 on subscriber CCM A.

Figure 1-10. Dial Plan Weight Calculations

The secondary unique line appearance on IP phone A (secondary extension 2001) adds a dial plan weight of 5 units to subscriber CCM A and 3 units to subscriber CCM B located in cluster 1. Each shared line appearance (shared extension 2002) on IP phone A adds a dial plan weight of 4 units to subscriber CCM A and 3 units to subscriber CCM B located in cluster 1. A line appearance is called “shared” when the same unique line appears on multiple devices in the same partition.

Figure 1-10 also shows IP phone B with primary extension 2004, secondary extension 2005, and shared extension 2002, registered with subscriber CCM B in cluster 1. Note that shared extension 2002 has a dial plan weight of 4 units on subscriber CCM A and 3 units on subscriber CCM B, since the shared extension 2002 is primarily controlled by subscriber CCM A, thus requiring more resources.

In each cluster, the global dial plan weights apply to all subscriber servers. For example, a route pattern of 9.1xxxxxxxxxxx adds a dial plan weight of 2 units to each subscriber server in the cluster (refer to Table 1-5).

Table 1-6 lists guidelines for how much physical memory to install on a subscriber server, based on the number of phones, number of line appearances, and complexity of the dial plan that is configured on that server.

IP phones are one of the endpoints in Cisco AVVID. Various IP phone models are available, the selection of which depends on the end-user requirements and the overall budget for the project. Appendix A, “IP Phone Models and Selection Criteria,” provides a list of currently available IP phone models and selection criteria.

IP phones keep the connection to the primary and standby CallManager servers. CallManager redundancy groups (device pools) that are configured on the CallManager administration page provide this feature. Each CallManager redundancy group consists of more than one CallManager. The first CallManager listed in the CallManager redundancy group has the highest priority. IP phones attempt to register with the higher priority CallManager.

Just like any other networking device, IP phones require an IP address, subnet mask, default gateway, DNS server, and TFTP server information to communicate with CallManager. By default, IP phones are configured to obtain the IP address and the other network settings via the Dynamic Host Configuration Protocol (DHCP). This allows mobility and improves IP address manageability. The only downside is that critical IP address allocation information for many nodes is stored within one file or database on the DHCP server. You should have adequate support for DHCP services and treat the DHCP data as highly critical data.

If an organization has an existing DHCP server, it can extend the services to IPT endpoints, such as IP Phones. The only requirement is that the DHCP servers should also support adding custom option 150 or 66 for IP phone provisioning. The DHCP server uses one of these option fields to forward to the IP phones information about the TFTP server or array of TFTP servers.

Only option 150 supports specifying an array of IP addresses. Hence, if you are planning to use more than one TFTP server, you should use option 150. Specifying more than one TFTP server allows the endpoints to use the secondary server if the primary server fails. Also, you can achieve load balancing by configuring these TFTP servers in different orders in the DHCP scopes.

The DHCP and TFTP services can be collocated on the CallManager publisher server in a small IPT deployment. However, for larger deployments, separating these services from the publisher server provides greater performance.

Domain Name Service (DNS) is not mandatory in IPT environments. IP phones can use IP addresses to communicate with CallManager. However, DNS is useful for managing the overall network environment and provides redundancy/load balancing for the IP phones that require access to the application servers.

SoftPhones are software-based applications that turn your computer into a full-featured Cisco IP Phone, allowing you to place, receive, and otherwise handle calls. These types of applications are useful for telecommuters or users who move within the campus. With the wireless connectivity to the PC, users can freely move to any location within the reach of the wireless and thus carry the phone with them.

Two types of soft phone applications are available:

Cisco IP SoftPhone is a Telephony Application Programming Interface (TAPI) application that communicates with CallManager via the Computer Telephony Interface (CTI), whereas Cisco IP Communicator communicates with CallManager via SCCP. The user interface for the Communicator phone looks like a Cisco 7970G IP Phone.

Table 1-7 lists the major differences between Cisco IP SoftPhone and Cisco IP Communicator.

As Table 1-7 indicates, Cisco IP SoftPhone uses CTI to communicate with CallManager. When deploying Cisco IP SoftPhone, you need to note the limitations on the number of CTI devices that can be provisioned on the CallManager depending on the hardware platform. Table 1-8 shows the CTI device limitations for CallManager 4.0 and assumes that the Cisco IP SoftPhones are configured with one line appearance, and no more than six BHCAs are made from the Cisco IP SoftPhones.

The maximum CTI limits are shown in Table 1-8 and include any other provisioned CTI devices such as IP-IVR or third-party CTI-enabled applications.

Because Cisco IP Communicator uses SCCP, it is treated like any other Cisco IP Phone; hence, you can deploy Cisco IP Communicator phones up to the maximum allowed IP phone device limits per server.

Both Cisco IP SoftPhone and Cisco IP Communicator mark the voice and signaling packets (0xB8/EF for media and 0x60/CS3 for signaling). These applications run on the user’s laptop/PC connected to the PC port that is on the back of the IP Phone. Because the packets coming from the PC port on the IP phone are not trusted, when deploying these applications, you need to create the access lists on the access or distribution switches to identify and mark with proper Differentiated Services Code Point (DSCP) values the signaling and media packets coming from these applications. Chapter 4 discusses the QoS and markings in detail.

Cisco Wireless IP Phone 7920 works in conjunction with CallManager and Cisco Aironet 1200, 1100, and 350 Series Wi-Fi (IEEE 802.11b) access points.

The planning procedures for deploying wireless voice are different from those used to deploy wired IP phones. Wireless IP phone deployment involves the following major tasks:

Voice gateways connect the IPT network to the PSTN or a PBX. CallManager supports a variety of voice gateways. Selection of the gateway depends on the specific site requirements. Geographical placement of the voice gateways determines the type of interfaces and link layer protocol selection.

CallManager communicates with gateways using any of the following protocols:

MGCP-based gateways provide call survivability and do not require a local dial plan. All the dial plan configurations are required to be made on the CallManager, whereas with H.323 gateways, you need to configure the local dial plan on the router by configuring the voice dial peers.

Cisco offers a variety of voice gateways, which are essentially the routers and switch modules with interfaces that can connect to the PSTN or a PBX. These routers and switch modules support two types of signaling interfaces: analog and digital. Analog signaling interfaces use Foreign eXchange Office (FXO), Foreign eXchange Station (FXS), and E&M signaling protocols. Digital signaling interfaces use T1/E1 Primary Rate Interface (PRI), ISDN Basic Rate Interface (BRI), or T1 CAS. Most of the Cisco IOS voice gateways support H.323, MGCP, and SIP, whereas the majority of the Catalyst voice gateways support MGCP.

Survivable Remote Site Telephony (SRST) provides the fallback support for the IP phones that are connected behind a router running the Cisco IOS software version that supports SRST. This feature enables you to deploy the IPT at small branch offices with a centralized call-processing model. Figure 1-12 depicts a branch office deployment with SRST.

Figure 1-12. SRST Operation in a Branch Office

During normal operation, when the CallManager is active and the WAN link is available, IP phones at the branch behave the same way as the IP phones at the central site. The SRST feature on the router becomes active as soon as the IP Phones detect the failure of the WAN link. (The IP Phones miss three consecutive acknowledgements from the CallManager.) The IP phones attempt to register with the other CallManagers in the redundancy group before attempting the registration with the SRST router. So, the fallback process to the SRST router could take longer if other CallManagers are in the IP phone’s redundancy group. SRST provides the basic call handling and minimal features to the IP phones during the WAN failure. Without this feature, the IP phone users at these locations would not be able to make outside calls.

When the WAN link comes back online, IP phones detect the keep-alive acknowledgements from the CallManager and attempt to re-home back to the CallManager servers.

The number of IP phones supported in the SRST mode depends on the router platform, the Cisco IOS version, and the amount of memory. You have to choose the appropriate router model and amount of memory based on the number of phones being deployed at the branch office.

Cisco CallManager Express (CME) is the new name given to the feature formerly known as IOS Telephony Services (ITS) on the Cisco IOS routers. CME is a licensed feature of Cisco IOS software that is available on many router hardware platforms. CME delivers key system functionality for small and midsize branch offices. In the CME solution, IP phones are registered to the CME router all the time. As shown in Figure 1-13, for a branch office/retail store that operates independently, the CME-based solution provides flexibility. Like SRST, the number of phones supported by the CME gateway depends on the router hardware, the Cisco IOS version, and the amount of memory.

Figure 1-13. CME Operation in a Branch Office

CallManager locations-based CAC is one mechanism to limit the calls sent across an IP WAN in a single CallManager cluster deployment. Locations are configured in the CallManager and assigned a maximum bandwidth. The bandwidth assigned per location depends on the number of calls that are allowed to be made to a particular location and the type of codec used for that location. Before placing a new call, CallManager checks its location tables to determine if enough bandwidth is available to place the new call. If enough is available, the call is allowed and CallManager updates the available bandwidth for that location. Locations-based CAC is ideal for centralized call-processing deployments with a hub-and-spoke topology.

CallManager locations-based CAC is not scalable for multicluster CallManager deployments; gatekeeper CAC, discussed next, is recommended for such deployments.

A Cisco IOS gatekeeper in Cisco AVVID networks provides call admission and call routing between the CallManager clusters in distributed call processing deployments. Gatekeeper CAC is suited for deployments that follow the hub-and-spoke topology and does not work with the meshed topologies. The following are some of the advantages of using the gatekeeper:

You have two choices of deploying a gatekeeper with CAC:

Gatekeepers in HSRP mode do not share the CAC information, whereas gatekeeper clustering enables true redundancy and load balancing. Gatekeepers that are deployed in a cluster mode exchange the CAC information via the gatekeeper Update Protocol (GUP) and are the recommended deployment method.

The Customer Response Solution (CRS) platform provides interactive telephony and multimedia services. It provides a multimedia (voice, data, and web) IP-enabled customer-care application environment. The CRS platform uses VoIP technology, so an organization’s telephony network can share resources with the data network.

The CRS platform uses an open architecture that supports industry standards. This enables application designers to integrate applications with a wide variety of technologies and products.

The CRS platform includes the following applications:

CRS has add-on components, including Automatic Speech Recognition (ASR) and Text-to-Speech (TTS).

CallManager integrates with many existing voice-mail systems that use the Simplified Message Desk Interface (SMDI) standard and other voice-mail systems from Lucent, Avaya, or Nortel that use proprietary protocols. CallManager uses the Cisco Digital PBX Adapter (DPA) 7630 to integrate with Lucent or Avaya voice-mail systems and DPA 7610 to integrate with Nortel voice-mail systems.

Cisco Unity is a voice-mail/unified messaging solution that delivers powerful unified messaging (e-mail, voice, and fax messages sent to one inbox) for Microsoft Exchange or Lotus Domino environments. Cisco Unity can integrate with CallManager and with many legacy PBXs. Cisco Unity communicates with CallManager via SCCP.

Likewise, CallManager server has guidelines on the maximum number of devices that can be registered; Cisco Unity server has guidelines on the number of subscriber accounts per Unity server. The capacity depends on the hardware platforms.

Redundancy is achieved in an IPT network by deploying the CallManagers in cluster configuration. To build the redundancy for Cisco Unity deployment, two Unity servers are deployed. Unlike CallManager, where the load can be shared on all the servers in the cluster, the Cisco Unity servers deployed in the failover model do not share the load. Only one server is active at a time.

An IPT network provides fiexibility to move the IP phones from one location to another location without the involvement of an administrator. This is attractive to many organizations and network administrators because it reduces the cost.

However, careful planning is required, which varies depending on the country where the telephony system is deployed and local government rules and regulations for routing emergency calls.

In the United States and Canada, users dial 911 (in other countries, this number varies) to make emergency calls to get the services of police, ambulance, and fire personnel. In a regular 911 system, also called a Basic-9-1-1 system, the emergency calls are sent to a public safety answering point (PSAP). No mechanism ensures that the call is sent to the correct PSAP, and the PSAP does not receive information about the location of the 911 caller. Enhanced 9-1-1, or E-9-1-1, sends 911 calls to the correct PSAP based on the location of the caller, and it ensures that the PSAP knows where the 911 caller is located (even without the caller providing directions). The location is determined by querying an Automatic Location Information (ALI) database that maps the phone number of the 911 caller to the caller’s physical location.

Large organizations that maintain their own phone systems (e.g. key systems, PBXs, and Cisco CallManagers) are responsible for maintaining the ALI database information and providing the updates to the ALI database to the local exchange carrier (LEC) from time to time.

Cisco Emergency Responder (CER) is designed to address the E-9-1-1 functionality requirements for multiline telephone systems (MLTSs) deployed in North America. CER dynamically tracks the device (IP phone or SoftPhone) movements and routes the emergency calls to the right PSAP based on the device’s current physical location.

Consider a case in which an employee in New York office location 1 moves the phone to New York office location 2. Assume that these two offices are served by different PSAPs. After the employee moves the phone to New York office location 2, if a user makes an emergency call, the call is routed to the PSAP for location 1. Because the user’s phone number originally registered with New York office location 1, the PSAP for location 1 dispatches emergency staff to New York office location 1, and the user at location 2 waits indefinitely for the help.

CER in an IPT network enables emergency agencies to identify the location of callers and eliminates the need for administration when phones or people move from one location to another.

The phone’s location is dynamically tracked by CER based on the switch ports to which the phone is attached. CER polls the switches via the Simple Network Management Protocol (SNMP) and updates the location database. Thus, in the previous example, when the phone is moved to New York office location 2, CER detects that the phone is now in New York office location 2, because it is connected to a switch that is in New York office location 2, and it routes the emergency calls to the PSAP that services New York office location 2.

Cisco Conference Connection (CCC) is an application that allows users to schedule conferences. Users can schedule conferences via a simple web-based interface. Conference participants call in to a central number, enter a meeting identification, and are then placed into the conference.

You can provide additional services such as those listed here to the end users from their IP phones:

Offering these services on the IP phones requires a connection through an external web server such as Microsoft Internet Information Server (IIS) or Apache, as shown in Figure 1-14. The IP phone sends the requests in the HTTP packet to the web server. The request could be to get the latest stock quote, flight arrival/departure information, or some other information. The IP Phone services web server contacts the external web servers and sends the response in XML format back to the IP phones. IP phones parse the information contained within the XML tags and display it on the phone.

Figure 1-14. IP Phone Services

The preceding concept can be extended to provide IP phone service to do a corporate directory lookup from the IP phone. The following steps explain how this service works:

For more information on providing such services, refer to the IP phone services Software Development Kit (SDK) documentation, available at http://www.cisco.com/pcgi-bin/dev_support/access_level/product_support.

In this model, each site contains a primary CallManager subscriber and at least one backup subscriber. All the servers are part of the same CallManager cluster. As depicted in Figure 1-18, the headquarters has a publisher server, a DHCP and TFTP server, subscriber 1, subscriber 2, and the backup subscriber 12. Branch A houses subscriber 3, subscriber 4, and backup subscriber 34.

Figure 1-18. Clustering over the IP WAN—Local Failover Deployment Model

In this model, shown in Figure 1-19, each site contains at least one primary CallManager subscriber and might or might not have a backup subscriber. Branch A and branch B have only primary subscribers, and the backup subscriber is not located in each site.

Figure 1-19. Clustering over the IP WAN—Remote Failover Deployment Model

The fourth scenario is similar to the third scenario except for the addition of the gatekeeper for CAC purposes. Gatekeeper-controlled ICTs are required when the clusters are separated by a WAN link and you need to control the number of calls that can go through the WAN link. In a large deployment involving multiple CallManager clusters, the gatekeeper can also perform the call routing via the locally configured dial plan.

Figure 1-24 shows the call flow for this scenario. The IP phones communicate with the CallManager using SCCP. The CallManager communicates with the gatekeeper using the H.323 RAS protocol. CCM A and CCM B are part of CallManager Cluster 1, and CCM C and CCM D are part of CallManager Cluster 2. These two clusters are connected via the ICT through the gatekeeper. Phone 1 is registered with CCMB, and Phone 2 is registered with CCMC.

Figure 1-24. Intercluster Call Flow with Gatekeeper

In Figure 1-24, the following sequence of events takes place:

Before analyzing the off-net call flow with MGCP, it is important to understand how the CallManager achieves call survivability with MGCP-based gateways. CallManager uses the MGCP PRI backhaul mechanism to receive the signaling information from the ISDN PRI gateway to provide the call-control functionality and preserve the D channel (and thus call survivability) during the CallManager failover and switchover event. Figure 1-25 shows this mechanism.

Figure 1-25. MGCP PRI Backhaul with CallManager

As shown in Figure 1-25, the MGCP PRI gateway terminates the D channel link layer (Q.921) signaling. The Q.931 termination remains in the CallManager. The CallManager backhaul function transports the Q.931 messages over the IP network to and from the gateway.

With this backhaul functionality, during the CallManager switchover, because the Q.921 layer is terminated on the gateway, the D channel stays active during the CallManager failure; hence, the active calls are not dropped on that interface.

A UDP logical (UDP port 2427) connection exchanges MGCP messages, and a TCP connection (TCP port 2428) backhauls the Q.931 messages. The values of both default ports are configurable on the CallManager. The source port from the gateway is randomly chosen.

In Figure 1-25, if the physical interface to the PSTN central office switch on the MGCP gateway is other than PRI, such as T1 CAS, FXS, or FXO, the gateway translates these signaling types into MGCP messages and sends them to CallManager for call control.

You should take into account the call-survivability feature with MGCP gateways when choosing the signaling protocol for the voice gateways.

Now look at a call-flow example from an IP phone to a PSTN phone via an MGCP voice gateway. Figure 1-26 shows the CallManager cluster with a registered IP phone 1 and a MGCP gateway with a PRI interface to the PSTN CO switch. The IP phone user makes an off-net call to a PSTN phone (Phone Z). The CallManager routes the call via the MGCP gateway.

Figure 1-26. Off-Net Call Scenario with MGCP Gateway

CallManager communicates with IP phones via SCCP and with the gateway via MGCP. Figure 1-27 shows the signaling messages exchanged between the IP phone, CallManager, and the MGCP gateway to route this call.

Figure 1-27. Off-Net Call Flow Using MGCP Gateway

For purposes of clarity, in Figure 1-27, the initial messages from the phone, beginning with the off-hook event until the end of dialing, are not included. These steps are the same as the ones shown in Figure 1-21 that are labeled as Step 1.

The following steps describe the events of messages that take place when IP Phone 1 makes an off-net call through the MGCP gateway:

Figure 1-28 shows the CallManager cluster with a registered IP phone 1 and an H.323 gateway. A gatekeeper is also registered with the cluster, and the off-net calls contact the gatekeeper before placing the call. The IP phone user makes an off-net call to a PSTN phone (Phone Z). The CallManager routes the call via the H.323 gateway.

Figure 1-28. Off-Net Call Scenario with H.323 Gateway

The following steps describe the events of messages that take place when IP phone 1 makes an off-net call via the gatekeeper through the H.323 gateway. Figure 1-29 shows the exact call-signaling sequence.

Figure 1-29. Off-Net Call Flow Using H.323 Gateway