Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

IP Telephony Components

So far this chapter has focused on analyzing how legacy networks are migrating to integrated voice and data networks and on describing the various protocols used in the new multiservice networks. This section discusses the main components of Cisco AVVID and some of the key areas to look for when deploying the Cisco IPT solution. Key areas include the following:

Network infrastructure

Call processing

CallManager Directory Services

IPT endpoints

Call admission control

Fax

Media resources

Applications

Understanding the features and capabilities of these components will help you to design the network that meets the targeted organization's requirements.

Network Infrastructure

Network infrastructure plays a key role in building multiservice networks such as Cisco AVVID. Integration of data and voice traffic puts strong requirements on packet loss, delay, and jitter (variable delay). When designing IPT networks, you should choose network infrastructure components in the LAN and WAN that support QoS mechanisms, in addition to faster convergence in case of network failures to avoid the delay, jitter, and so forth.

The addition of voice traffic on top of the existing data traffic increases the bandwidth requirements in both LANs and WANs. The bandwidth within the LAN is not a challenging issue because of the availability of the high-speed LAN switching technologies. However, when transporting the voice traffic across the WAN links, you need to ensure that adequate bandwidth is available to support the additional bandwidth required to transport voice calls. If the WAN links do not have adequate bandwidth, you need to increase their bandwidth to support the additional voice traffic. After the bandwidth is available, you can use QoS mechanisms to prioritize the voice traffic and reserve the bandwidth.

Chapter 4, "Planning Phase," discusses the infrastructure requirement analysis in depth.

Call Processing

CallManager software is the main component of the Cisco IPT solution. CallManager handles all the call-processing requests received from various clients in the IPT network. CallManager software runs on the Microsoft Windows 2000 Server/Windows 2000 Advanced Server operating systems.

CallManager is installed on the Cisco Media Convergence Server (MCS). The selection of the hardware platforms depends on the size of the network in which they are going to be deployed, including its high-availability and performance requirements. Table 1-2 lists the maximum number of devices supported per server platform.

CallManager Clustering

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.

Tip

In a large IPT deployment, the recommendation is to have a dedicated publisher server that does not participate in the call processing and a separate server that provides TFTP services.

Device Weights

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).

^[1] Cumulative weight of the CTI (Computer Telephony Integration) route point depends on the associated CT ports used by the application.

^[2] Includes the associated IP phone.

^[3] When MoH is installed on the same server as CallManager, the maximum number of media streams is 20.

^[4] When installed on the same server as CallManager, the maximum number of conference sessions is 24.

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.

Tip

In Table 1-2, the number provided in the Maximum Number of IP Phones per Server column is based on the assumption that all phones are configured with a single directory number. If the network that you are deploying is complex and involves multiple lines/directory numbers per IP phone or dial plan that includes numerous route patterns and translational patterns, you have to understand the concept of dial plan weights, as discussed in the following section.

Dial Plan Weights

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:

Subscriber dial plan weights (include line appearances)

Global dial plan weights (include route patterns and translational patterns)

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:

IP phone weight Associated with the subscriber server to which the IP phone is normally registered. This weight is for the base device. The dial plan weight of an IP phone is independent of its device weight. (See Table 1-3.)

Line weight (unique or shared appearance) Associated with the subscriber server to which the device is normally registered.

Reachability weight Associated with all other subscribers in the cluster that have to be able to reach (call) a given line. Consider a CallManager cluster with two CallManager servers: CCM1 and CCM2. An IP phone 'A' is registered to CCM1. Even though the IP phone is registered to CCM1, the CCM2, which is part of the same cluster, needs to know how to reach the phone 'A.' CCM2 keeps this information in the memory. Reachability Weight accounts for this memory utilization on CCM2.

Global dial plan weights Consist of route pattern and translation pattern weights.

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.

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.

Tip

When determining the server hardware and number of servers in the cluster, you should choose a server based on the size of the network, performance, and high-availability requirements. A properly sized cluster must satisfy both the device weight and dial plan weight requirements.

Starting with CallManager 4.0, Cisco has introduced a Cisco CallManager Capacity Tool to size the CallManager clusters. This is a web-based tool and is currently not available on Cisco Connection Online (CCO). In the back end, the tool uses device weights, dial plan weights, and the BHCA multipliers concept to calculate cluster sizing. The device weights and BHCA factors could change from one version of CallManager to another, but the concept remains the same.

CallManager Directory Services

CallManager is bundled with a Lightweight Directory Access Protocol (LDAP) compliant directory called DC Directory (DCD). DCD is a Cisco OEM product from Data Connection Limited.

CallManager stores system and device configurations in a Microsoft SQL database. The application scripts and the following information are stored in DCD:

User authentication and authorization

Extension Mobility profiles

Personal Assistant profiles

Internationalization information

Personal Address Book (PAB)

Spoken name

Fast dial

Call Forward All information

The DCD process replicates the information among the members of the cluster, as shown in Figure 1-11. This process is similar to Microsoft SQL replication.

Many organizations have already deployed LDAP-based directories to store the user-related information, such as user ID, password, authentication information, authorization information, e-mail ID, phone number, and address. There are two possible deployment scenarios for the CallManager directory:

Use the embedded DCD, which is part of CallManager

Use corporate directory integration, which allows CallManager to store the user-related information in a centralized, existing directory, instead of using DCD. CallManager supports the directory integration with Microsoft Active Directory 2000/2003, Netscape 4.x, iPlanet 4.x, or SunOne 5.x Server.

You do not need to perform additional planning or design tasks when using the embedded DCD. The publisher server stores the master copy of the directory database, and the subscribers have the replica of the publisher server's directory database.

However, if you are considering integration of CallManager with an existing corporate directory, you must take extra care to achieve successful integration and functioning of the CallManager cluster. Corporate directory integration requires schema extensions to the existing corporate directory schema structure. The schema extension creates new objects and attributes in the existing corporate directory schema structure to store CallManager-specific information in the directory. The CallManager schema extensions use official object identifiers (OIDs) that are approved by the Internet Assigned Numbers Authority (IANA).

Many other Cisco IPT applications, such as Cisco Unity, IPCC Express, Personal Assistant (PA), and Cisco Emergency Responder (CER), support directory integration with external directories. Cisco Unity requires a special set of schema extensions when integrated with an external directory, and other applications create special directory trees and attributes in the corporate directory.

Note

The IPT planning team must consult the corporate directory team to discuss the effects of this schema extension and to determine the effects of the extra size of the directory database because of the addition of new objects and attributes. Note that the directory schema extension process requires higher user privileges.

CallManager integration with the corporate directory includes the following benefits:

You do not need to maintain two separate directories (one for the corporate directory and another for the CallManager directory), which results in minimal administration overhead

When deploying multiple CallManager clusters, you do not need to provide different services to look up users in different clusters.

Moves, adds, and changes are centralized.

IP Telephony Endpoints

In a Cisco IPT network, endpoints are the devices that accept or initiate a VoIP session. This section introduces the following endpoints that are used in a Cisco IPT network.

Cisco IP Phones

SoftPhones

Wireless IP Phones

Voice gateways

Survivable Remote Site Telephony (SRST)

CallManager Express (CME)

Cisco IP Phones

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.

Tip

Best practice is to keep the DHCP databases mirrored or backed up on a continual basis. In addition, have a plan in case DHCP services fail. In large deployments, separate the DHCP and TFTP server functionality to achieve stability and reliability.

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.

Tip

To build a standalone TFTP server, you simply need to install the CallManager software, as you would do with any other subscriber, but activate only the TFTP and DataBase Layer (DBL) monitor services on that server.

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

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

Cisco IP Communicator

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.

Chapter 4 discusses the QoS and markings in detail.

Wireless IP Phones

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:

Preparing a site survey to do the following:

Determine the location of the access points

Identify and eliminate the sources of interference

Determine the power levels of the access points

Identify and eliminate the rogue access points

Determining the number of access points required

Configuring QoS policy on access points

Configuring security

Voice Gateways

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

H.323

SIP

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

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.

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

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.

Call Admission Control

In VoIP networks, CAC does the bandwidth management. CAC ensures that enough bandwidth is available before granting permission to a gateway for placing the call across the IP WAN. When deploying IPT solutions with multiple locations, you have two choices for implementing the CAC:

CallManager locations-based CAC

Gatekeeper CAC

CallManager Locations-Based CAC

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.

Gatekeeper CAC

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:

It simplifies the dial plan management by enabling you to quickly add or remove routes and devices.

It provides CAC between calls from different clusters, ensuring that the WAN bandwidth allocation is strictly enforced.

It reduces configuration overhead by eliminating the need to configure a separate H.323 device for each remote CallManager that is connected to the IP WAN.

It offers a choice of protocols for communicating with CallManager or H.225 gateways.

It can perform basic call routing in addition to call admission control.

You have two choices of deploying a gatekeeper with CAC:

Gatekeepers deployed with the Hot Standby Router Protocol (HSRP)

Gatekeeper clustering

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.

Fax

One of the most important pieces in the transition to converged networks is support for fax communication. As network implementations increasingly provide for e-mail attachments and web-downloadable documents, fax communication nonetheless is still a significant method of immediate document delivery worldwide. Studies have shown that a large portion of long-distance minutes is fax traffic.

The frequent use and customer expectations of fax functionality and reliability demand a support for reliable fax transmissions across a converged network. Most Cisco voice gateways currently support three methods to transmit fax traffic across the IP network:

Fax Pass-Through In Fax Pass-Through mode, the gateways do not distinguish a fax call from a voice call

Cisco Fax Relay In Cisco Fax Relay mode, the gateways terminate the T.30 fax signaling.

T.38 Fax Relay This standard provides standards-based Fax Relay.

Fax Relay mode is the preferred method to transmit fax traffic. Because the T.38 Fax Relay protocol is standards-based, fax gateways that use this protocol can interoperate with third-party T.38-enabled gateways and gatekeepers in a mixed-vendor network. As of CallManager 4.0, T.38 Fax Relay is not supported. When deploying the fax over IP by using the CallManager, Cisco Fax Relay or Fax Pass-Through are the only choices that you can use on the gateways.

Similar to voice traffic, fax traffic is also sensitive to delay, jitter (variable delay), and packet loss. Hence, the network must be QoS enabled.

Media Resources

The function of media resource devices is to mix the multiple streams into a single output stream, converting the data stream from one compression type to another, and so forth. Examples of media resources are conferencing, transcoding, and MoH.

The media resources can be hardware or software. CallManager has built-in software media resources for conferencing, transcoding, and media termination. The limitation of software media resources is that they can't combine the streams that use different compression techniques.

Hardware media resources have the same features as software media resources with an additional advantage of mixing the streams that use different compression types. Hardware media resources offer good performance and quality because the processing is done in the hardware.

MoH is another example of a media resource. MoH is an application that is installed by default on the CallManager servers (or you can install a standalone MoH server on a dedicated server for large deployments). As the name implies, MoH provides music or announcements when the users are put on hold.

When you are designing the IPT network, one of the tasks is to size the media resources and determine their placement within the network.

Applications

Cisco has a wide range of applications that can be deployed in an IPT network. These applications are optional, and their deployment adds more features and capabilities to the overall IPT network. Design and deployment of the applications, such as CRS and IP phone services, are discussed in Chapters 6, "Design of Call Processing Infrastructure and Applications," and 7, "Voice-Mail System Design."

Customer Response Solution

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:

Cisco IP Auto Attendant (IP AA)

Cisco Interactive Voice Response (IP IVR)

Cisco IP Contact Center (IPCC) Express (formerly known as Integrated Contact Distribution, or ICD)

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

IVR

IVR queues the callers, accepts the input, and does a database lookup based on the input. The open standardsbased design of the CRS platform supports connectivity to various databases, such as Microsoft SQL, Oracle, Sybase, and IBM DB2 via Open DataBase Connection (ODBC) interface.

IPCC Express

Cisco IPCC Express provides enterprises with a contact management solution that is ideal to implement a small-scale contact center or internal help desk. IPCC Express provides Automated Call Distribution (ACD), IVR, and CTI functionality. The ACD queues and distributes incoming calls that are destined for groups of CallManager users. The IVR gathers caller data and classifies incoming calls based on user-entered information. IPCC Express includes a web-based real-time reporting system that monitors the system performance, Contact Service Queue (CSQ), and resource performance.

A Java Telephony API (JTAPI) connection manages communication between the CRS engine and CallManager Computer Telephony Integration Manager (CTIM) service.

The sizing of the CRS platform depends on the organization's call volume.

Cisco Unity

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.

Cisco Emergency Responder

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

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.

IP Phone Services

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

Calendar

Weather information

Airline information

Corporate directory lookup

Stock quotes

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.

Note

In the Figure 1-14, "Step 2. HTTP Request" and "Step 3. HTTP Response" are used when accessing the IP phone services that require connection to the external web server. Examples of such services are stock quote and airline information.

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.