Cisco Service Ready Architecture for Schools Design Guide

Unified Communications Design

Introduction

While many school networks still use legacy PBX phone systems, many are migrating to the advantages of IP-based voice. Lower in cost, and more flexible and reliable, the Cisco Unified Communications suite of solutions provides great benefits to a school network. Based on years of best practice recommendations, this chapter provides information on the advanced suite of communications, collaboration, and mobility features in the Cisco Unified Communications solution set.

This chapter provides guidance for deploying Cisco Unified Communications. It covers the dial-plan principles recommended for a school district, along with recommended solutions for ensuring communications survivability during a WAN outage, and emergency 911 call capabilities.

School Service Ready Architecture Dial Plan

The CUCM dial plan discussed here is appropriate for deployments supporting up to 100 schools. This dial plan is for a centralized CUCM cluster in the school District Office supporting up to 100 schools over a 100Mbps Metro Ethernet WAN.

Note This document is based on the UC SRND version 7 that can be accessed at the following URL: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/uc7_0.html. The dial plan chapter of the UC SRND is the authoritative source for dial plan guidance and should be referenced for more details and more options than are provided in the example deployment provided in this chapter.

Design Assumptions

The following design aspects and requirements are assumed:

•Connectivity between schools and district office is via hub-and-spoke Metro Ethernet WAN.

•Metro Ethernet provides sufficient bandwidth and low enough latency to support centralization of CUCM at the district office for all sites in the network.

•The network is configured with the appropriate QoS policy to support a voice deployment.

•CUCM provides centralized call control for all sites in the network.

•Call processing redundancy at the district office is provided by a CUCM cluster.

•Access to the PSTN is provided by PSTN gateway functionality running on a Cisco Integrated Services Router (ISR) router at each school and in the district office.

•At the school sites, additional call processing redundancy is provided by SRST in the Cisco ISR at that site. If phones at a remote sites lose connectivity with the CUCM over the WAN link, they can fall back to SRST mode whereby they register with the SRST function in the Cisco ISR router local to that site

•Same site calling; every phone can call any other internal phone at the same site using four-digit extension.

•Inter-site calling; calls between phones in different sites of the same school district use 8 as an access code, followed by a site code, followed by the four-digit extension.

•PSTN gateways at the district office and remote sites provide PSTN connectivity.

Example Deployment

Dial-plan testing was performed on an example network of three sites in a deployment designed to scale up to 100 sites. The example deployment is shown in Figure 7-1.

Figure 7-1 Sample Dial-Plan

In the example deployment, each of the sites has less than 8,000 phones and can therefore use a 4-digit internal extension. The following Direct Inward Dial DID blocks are assumed to have been issued by the local telecoms operator:

•District office DID block 333-456-1000 through 333-456-1799

•School 1 DID block 444-567-1000 through 444-567-1799

•School 2 DID block 222-345-1000 through 222-345-1799

Within each of the three sites, dialing will be by four-digit extension (x1000 through x1799)

Between sites, dialing will use 8 as an access code, followed by a site-code (in the example, this is area code assigned to that sites PSTN gateway), followed by the four-digit extension.

•District office phones dialed from school 1 or school 2 will be dialed as 8-333-1000 through 8-333-1799.

•School 1 phones dialed from district office of school 2 will be dialed as 8-444-1000 through 8-444-1799.

•School 2 phones dialed from district office of school 1 will be dialed as 8-222-1000 through 8-222-1799.

Note In the example above, each site has a unique area code that is mapped directly to a site code. In a typical deployment, the expectation is to see multiple schools using the same area code; this requires site codes to be assigned by other means.

Note You must ensure that the on-net access code and site code combination do not overlap with the local abbreviated dialing range at any site. This is accomplished by ensuring that no abbreviated dial extension start with the digit 8.

Variable-Length On-Net Dial Plans with Flat Addressing

This document discusses a dial plan that is appropriate for deployments where the CUCM cluster in the school district office supports up to 100 schools over a 100Mbps Metro Ethernet WAN.

There are two main approaches to a dial plan for internal destinations within an IP Telephony system:

•Uniform on-net dial plan—All extensions in a uniform on-net dial plan are reached in a uniform way. Every internal call destination has a unique number of defined length. Uniform on-net dial plans are the easiest to design and configure; however, they become impractical when the number of sites and users increases due to the following reasons:

–All on-net extension dialing must be globally unique. For example, in a system using an abbreviated 4-digit on-net dial plan, there cannot be an extension 1000 in site A and another extension 1000 in site B. This requirement is very difficult to satisfy in large deployments where the extension is derived from the DID blocks obtained from local telecoms companies.

–There cannot be any partial overlap between different dial strings. For example, if 9 is used as an off-net access code in a 4-digit abbreviated dial plan (for example, to make PSTN calls), there cannot be any extensions in the 9XXX range. Attempting to do so would create situations where calls are not routed immediately. For example, if a user dialed 9141, the system would have to wait for either more digits (if the user were dialing 9 1 415 555 1234, for example) or the expiration of the inter-digit timeout before routing the call to extension 9141. Likewise, if an operator code is used (for example, 0), the entire 0XXX extension range would have to be excluded from a four-digit uniform dial plan.

–There cannot be overlapping strings of different length. For example, a system with extensions 1000 and 10000 would force users to wait for the inter-digit timeout when they dial 1000.

•Variable-length on-net dial plan—This is where internal destinations are dialed differently within a site than across sites. Typically, this approach uses four or five-digit abbreviated dialing for calls within a site and an on-net access code followed by a site code and the extension for calls across sites.

–Variable-length on-net dial plans are more scalable and better allow for future expansion or changes to the dial plan. For this reason, variable-length on-net dial plans are used in this design guide.

–A variable-length on-net dial plan with flat addressing is implemented by defining internal call destinations as unique strings containing an on-net access code, a site code, and the extension (for example, 8-123-1000). Flat addressing places all the directory numbers in the same global partition, thus enabling inter-site calls using the site code. Translation patterns are defined in site-specific partitions (one translation pattern and one partition per site) to enable abbreviated dialing within a site.

•Alternative to using site codes—The UC7.x SRND discusses a variant of the flat addressing approach that does not rely on the definition of an on-net numbering plan based on site codes. In this scheme, internal call destinations are defined with their full E.164 number. Intra-site calls use translations patterns to ensure they can still dialed as four-digit numbers. Inter-site calls are dialed using the E.164 number and are then recognized and routed across the IP WAN by Unified CM.This option was not used in this document because the site code approach results in numbers that are shorter and easier to remember; for example, the dial plan could be set up so that every school principal has a non-DID second extension of 7000. With this scheme in place, it is possible to dial the principal at any school by dialing 8, the site code, and 7000. The site code approach is also preferred because many schools do not have E.164 DID numbers assigned to each phone; instead they route calls through an IVR or an operator.

Call Routing

The dial plan in this document is designed with the following structure:

•Localized Call Ingress—Accept calls in the local format preferred by the originating users and carriers. Convert called and calling numbers to a globalized format.

•Globalized Call routing—Route the calls on-net using global representations of the called and calling numbers.

•Localized Call Egress—Deliver the calls to phones or gateways and convert the called and calling numbers from the globalized format to the local format required by the destination user or network.

The benefits of the dial-plan design approach are most compelling when deploying UC across diverse countries and telephony carriers, but as a Cisco UC best practice, the new design approach still has benefits to a smaller network such as that which would be used by a school district. Some of those benefits include the following:

•Dial plan is consistent with Cisco best practice recommendations and scales globally

•Simplified configuration of call routing, especially when considering local egress to the PSTN

•Simplified configuration and enhanced functionality of system functions such as:

–Automated Alternate Routing (AAR)

–Emergency Responder (ER) site-specific failover

–Call Forward Unregistered (CFUR)

–Tail End Hop Off (TEHO)

–Click-to-dial of E.164 numbers (including the + sign) from soft clients such as Cisco Unified Personal Communicator

–Adaptive call routing for speed dials originating from roaming extension mobility users or roaming devices

–One-touch dialing from phone directory entries, including dual-mode phones

–One-touch dialing from missed and received call lists in IP phone directories

Note The dial plan in this document uses several features introduced in CUCM 7.0.

Localized Call Ingress

Localized call ingress is where the UC system accept calls in the local format preferred by the originating users and carriers and then converts called and calling numbers into 8-digit local phone numbers for CUCM on-cluster numbers, and to the full E.164 format for PSTN numbers.

Using the + Sign on E.164 Numbers

When an external called or calling number is converted to the globalized representation on input, a + sign is used to represent the international dialing access code needed to reach a destination from different countries.

For calls that egress via a PSTN gateway, localized call egress will replace the + in a called number with the appropriate off-net access code (as required by the enterprise telephony system) and international access code (as required by the PSTN carrier) relevant for each caller.

Even though the Telephony User Interface (TUI) does not allow for dialing + from the keypad, the missed and received calls directories can contain entries where the number includes a +. On 7911, 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, and 7975 phones, if the user dials from those directories, the resulting call into Unified CM will have a called number beginning with +. (7905, 7912, 7940, and 7960 phones do not support storing or displaying the + sign).

This section discusses the following:

•Localized call ingress on IP phones

–Localized called number on IP phones

•IP phones called number is a 4-digit local extension

•IP phones called number is on the external PSTN

–Localized calling number on IP phones

•Localized call ingress on gateways

–Localized called number on gateways

–Localized calling number on gateways

Localized Call Ingress on IP Phones

This section discusses localized call ingress on IP phones and Soft phones.

Localized Called Number on IP Phones

If a user dials the full 8-digit directory number of an on-cluster phone line, the called number does not need to be manipulated, and is routed directly. This section will discuss the cases where the called number is one of the following:

•A 4-digit local extension

•A full E.164 PSTN number

IP Phones Called Number is a 4-digit Local Extension

For on-net destinations, such as calls between two users in the same site, translation patterns are used to derive the globalized on-net form of the destination number. For example, assume two users in the Site 1 use 4-digit abbreviated dialing to call each other. User A calls user B by dialing 1234. A translation pattern specific to this site is configured to recognize any 4-digit string beginning with 1 and to translate the called number to the globalized on-net form of 84441234. The translation pattern is configured as: 1XXX, prefix 8444.

The translation pattern must be site-specific (included in the CSS of only the phones in Site 1) to avoid confusion with extension 1234 at other sites in the system. In the example above, the on-net global form is implemented using an inter-site access code (8) and a site code (444). After the call has been translated into a 8-digit global on-net number, the CSS of the translation pattern is used to direct the call to the destination partition and route pattern.

Figure 7-2 shows an example configuration for intra-site calls within the CUCM cluster used in the sample network.

Figure 7-2 Localized Call Ingress for On-net Calls

To provide connectivity between sites and partitions, the sample network used the following guidelines:

•Place all unique DNs, including the on-net access code 8, in a global partition (named Internal_pt in this example).

•Create one partition per site, each containing a translation pattern that expands four-digit numbers into the fully qualified eight-digit number for that site, thus enabling abbreviated dialing within the site.

•For each site, include both the Internal_pt partition and the local translation partition in the phone's calling search space. The inclusion of the on-net access code in the DN configured in Unified CM enables you to place all internal extensions in a partition directly accessible by all phones, and at the same time ensures that all call directories on the IP phones are populated with numbers that can be directly redialed.

IP Phones Called Number is on the External PSTN

For calls to numbers on the PSTN, translation patterns should be used to derive the globalized on form of the destination number.

•Add the local area code to any 7-digit PSTN numbers.

•Replace the PSTN access code (for example, 9) and any international dialing access code (eg 011), with a + sign.

With these changes to the called number, the call could be routed or re-routed to any gateway globally, and the gateway would be able to route the call successfully.

Figure 7-3 Localized Call Input; IP Phone Calling Off-net Dstination

Figure 7-3 shows the following partitions:

•NANP_Loc2glob—The system has one translation pattern, used by all sites, to perform the following modifications to called numbers:

–Remove the PSTN access code of 9 on emergency numbers

–Replace the PSTN access code of 9 with the + code, on National numbers

–Replace the PSTN access code and the international dialing access code with the + code on international calls.

•xx_loc2glob—Each site has a site-specific partition containing a translation pattern to replace the PSTN access code for 7 digit local dialing with the + code and the NNAP country code of 1, and the local area code for that site.

•NNAP_pstn_part—The translation patterns in the other partitions translated numbers into a globalized number. After the call has been translated into a E.162 off-net number, the CSS of the translation pattern is used to direct the call to the NNAP_pstn_part partition. The NNAP_pstn_part partition is used by all sites, to route globalized called numbers out the appropriate gateway. The Globalized call routing section will detail how the gateways are used for each of the patterns in this partition.

–There are patterns for each sites local area code so that Tail End Hop Off may be used to route the call to the gateway local to that area code.

–The +1xxxxxxxxxx pattern is for NNAP numbers

–The +! pattern will route international calls.

–Emergency numbers (911) should always be routed out the local gateway of the calling phone, when available.

Localized Calling Number on IP Phones

On cluster IP phones are configured with a directory number that is in the global on-net format. In this example the directory number is an 8-digit number that includes the access code, the site number, and the 4-digit extension. This directory number is already in the globalized format and is therefore not changed on ingress. If the call is directed out a gateway, the calling number will be changed by the gateway to a full E.164 number.

Localized Call Ingress on Gateways

Just as with IP phones discussed previously, we need to localize call ingress on gateways. We accept incoming calls on gateways in the local format of the telephone network to which the gateway is connected, and we convert the called and calling numbers to a globalized format. The global format is later used to route the call within the voice over IP network to its destination.

Localized Called Number on Gateways

Incoming PSTN calls require that the E.164 number be manipulated to obtain the eight-digit internal number in order to reach the destination phone. Within this example dial-plan, this requirement has been implemented by configuring the Num Digits and Prefix Digits fields within the Gateway Configuration page in Unified CM. These fields strip and then prefix the needed digits.

In Figure 7-4, the Significant Digits field maps the last 4 digits of the incoming called DID number to the local 4-digit extension. The Prefix DN field adds the inter-site access code (8) and a site code (222).

Figure 7-4 Converting from localized PSTN called DID number format to globalized on-net directory number format

Localized Calling Number on Gateways

Incoming calling party settings can be configured on individual gateways, at the device pool level, or at the service parameter level, in order of precedence. For each numbering type (Subscriber, National, International, or Unknown), Unified CM allows for the appropriate prefix digits to be configured. Digits can be stripped from and prefixed to the string provided as the incoming party number. The notation takes the form PP:SS, where PP represents the digits to be prefixed and SS represents a quantity of digits to be stripped. The digit stripping operation is performed first on the incoming calling party number, and then the prefix digits are added to the resulting string. For example, if the prefix digits field is configured as +33:1 and the incoming calling party number is 01 58 40 58 58, the resulting string will be +33 1 58 40 58 58.

Figure 7-5 shows the incoming calling-party settings for the gateway at school 2.

Figure 7-5 Localized calling party number on gateways

For the example dial plan above, the following actions are taken:

•Incoming national calls have the area code included in the calling number, and the gateway is configured to add the + and the 1 for North America.

•Incoming international calls have the international country code included in the calling number, and the gateway is configured to just add the +.

•For incoming unknown calls, the gateway is configured to just add the +.

•For incoming subscriber calls, and the gateway is configured to add the + and then the 1 for North America, and then the local area code for that gateway.

Globalized Call Routing

In this section, we assume the calling number has been manipulated into one of the following:

•Globalized to an 8-digit on-net number

•Globalized to an E.164 external number

This section discusses how the call is routed to the appropriate destination.

Globalized Call Routing to an 8-digit On-net Number

The sample network is deployed as a single CUCM cluster the CUCM cluster has full knowledge of every 8-digit on-net number, and can route calls directly to the destination phone.

Globalized Call Routing to an E.164 External Number

Where the destination is an external PSTN number, we have to route the call to the appropriate PSTN gateway. Figure 7-6 shows how calls are routed in our example deployment. Route patterns point to route lists that in turn point to egress gateways.

Figure 7-6 Call Routing Example

The following discussion of the dial plan in Figure 7-6 includes the use of local route groups which are discussed further in the section following this one.

The route patterns that include the area code implement Tail End Hop Off (TEHO) by pointing to a route list which is comprised of the following route groups:

•A route group containing the gateways at the local site in which the directly connected gateways are connected.

•A route group containing the local route group which will route calls out a gateway connected to the site the calling phone is dialing from. For more details on local route group, refer to "Using Local Route Group" section.

•A route group containing the gateways at a different site. This provides redundancy in the event that the previous two route groups both point to the gateways at the same site.

The route patterns in Figure 7-6 for national, international, and emergency calls point to a route list that is comprised of the following route groups:

•A route group containing the Local Route Group which will route calls out a gateway connected to the site the calling phone is dialing from. For more details on Local Route Group, refer to "Using Local Route Group" section.

•A route group containing the gateways at the district office.

•A route group containing the gateways at Site 1. This provides redundancy in the event that the previous two route groups both point to the gateways at the same site.

Other variations are possible in a real deployment. For example, it might be preferable to route some calls out the district office as a first choice, and out the Local route group if the district office gateways are unavailable.

Using Local Route Group

Local Route Group is a Cisco Unified CM 7.0 feature that simplifies the configuration of site-specific routing of off-net calls. Route patterns using the local route group allow for dynamic selection of the egress gateway, based on the device originating the call.

Before local route group route patterns were site specific. For example, before local route groups:

•The 911 route pattern for site 1 would point to site 1's PSTN gateway

•The 911 route pattern for site 2 would point to site 2's PSTN gateway.

With local route groups, a single 911 route pattern can be configured pointing to the Local Route Group.

•Phones in sites 1 and 2 will use the PSTN gateway pointed to by the Local Route Group field in each sites device pool.

•Phones acquire their local route group from the Local Route Group field in the phones' device pool.

Localized Call Egress

Calls are routed to a destination using the global form of the called and the calling numbers. These numbers need to be transformed into the format expected by the telephone network to which the gateway is connected.

Localized Call Egress to an IP Phone

Called Number

In this dial plan, IP phones directory numbers are the same as the globalized on-net number format; no conversion of the called number is required.

Calling Number

As a call is delivered to a phone, the calling number will be in its global form, which might not be recognizable to the called party. Typically, users prefer to see calls from callers within their country presented with an abbreviated form of the caller's number.

For example, users in the US want to see incoming calls from US callers with a ten-digit national number, without the + sign or the country code (1). If a user whose global phone number is +1 222 345 1234 calls +1 333 456 4000, the called phone would like to receive 222 345 1234 as the calling-party number while the phone is ringing.

To achieve this, the system administrator should configure a calling-party transformation pattern of: +1.!, strip pre-dot. The calling-party transformation pattern is placed in a partition included in the destination phone's calling-party transformation pattern CSS, configured at the device-pool level. As a call from +1 222 345 1234 is offered to the phone, it matches the configured calling-party transformation pattern, which removes the +1 and presents a calling-party number of 222 345 1234 as the call rings.

Figure 7-7 shows how the device pool of the destination phone determines the calling party transformation

Figure 7-7 IP Phone Outgoing Calling-Party Transformation

Note The calling-party number stored in the missed and received calls directories is left in its globalized form to allow one-touch dialing from the directories without requiring manual editing of the directory's stored number string.

Note Many phone users are becoming accustomed to the globalized form of PSTN numbers, mainly due to the common use of mobile phones across international boundaries. The system administrator can forgo the configuration of calling-party transformation patterns for phones if displaying the global form of incoming numbers is preferred.

Localized Call Egress to a Gateway

Gateway Called-Party Number Localization

As a call is delivered to a gateway, the called party number must be adapted to the requirements of the PSTN service provider providing the trunk group to which the gateway is connected. Called-party number transformation patterns can be used to change the called-party number digit-string and numbering type. Typically, a called-party number featuring the gateway's country code should be changed to remove the + sign and the explicit country code, and they should be replaced with the national prefix. Also, the numbering type of the called-party number should be changed to national. If the gateway is connected to a trunk group featuring a specific area, region, or city code, the specific combination of + sign, country code, and local area code usually must be replaced by the applicable local prefix. Also, the numbering type must be adjusted to subscriber.

For example, assume that a call to an external user in site 1s area code (+1 444 555 2222) is routed through a route list featuring a Site 1 gateway (San Francisco) as a first choice and a Site 2 (Chicago) gateway as a second choice. The Site 1 gateway is configured with two called-party transformation patterns:

•+1444.XXXXXXX, strip pre-dot, numbering type: subscriber

•+1.!, strip pre-dot, numbering type: national

As the call is delivered to the Site 1 gateway, the called-party number matches both of the called-party transformation patterns. However, the first one is a more precise match and is selected to process the called party number. Thus, the resulting transformed number is 5552222, with a called party type set to subscriber.

If the gateway had not been able to process the call (for example, if all ports were busy), the call would have been sent to the Site 2 gateway to egress to the PSTN. The Chicago gateway is configured with the following two called-party transformation patterns:

•+1222.XXXXXXX, strip pre-dot, numbering type: subscriber

•+1.!, strip pre-dot, numbering type: national

As the call is delivered into the Chicago gateway, the called-party number matches only the second called-party transformation pattern. Therefore, the resulting called-party number offered to the gateway is 4445552222, with a called-party number type set to national.

Figure 7-8 shows how the device pool of the destination gateways determines the calling-party transformation.

Figure 7-8 Gateway Called-Party Transformation

Gateway Calling Party Number Localization

As a call is delivered to a gateway, the calling-party number must be adapted to the requirements of the PSTN service provider providing the trunk group that the gateway is connected to. The calling-party number transformation patterns can be used to change the calling-party number digit-string and numbering type. Typically, a calling-party number featuring the gateway's country code should be changed to remove the + sign and the explicit country code, and they should be replaced with the national prefix. Also, the numbering type of the calling-party number should be changed to national. If the gateway is connected to a trunk group featuring a specific area, region, or city code, the specific combination of + sign, country code, and local area code usually must be replaced by the applicable local prefix. Also, the numbering type must be adjusted to subscriber.

For example, assume that a call from a Site 1 user (+1 444 567 1234) is routed through a route list featuring a San Francisco gateway as a first choice and a Chicago gateway as a second choice. The San Francisco gateway is configured with two calling-party transformation patterns:

•+1444.XXXXXXX, strip pre-dot, numbering type: subscriber

•+1.!, strip pre-dot, numbering type: national

As the call is delivered to the Site 1 gateway, the calling-party number matches both calling-party transformation patterns. However, the first one is a more precise match and is selected to process the calling-party number. Thus, the resulting transformed number is 5671234, with a calling-party type set to subscriber.

If the gateway had not been able to process the call (for example, if all ports were busy), the call would have been sent to the Site 2 gateway to egress to the PSTN. The Site 2 gateway is configured with the following two calling-party transformation patterns:

•+1222.XXXXXXX, strip pre-dot, numbering type: subscriber

•+1.!, strip pre-dot, numbering type: national

As the call is delivered into the Chicago gateway, the calling-party number matches only the second calling-party transformation pattern. Therefore, the resulting calling-party number offered to the gateway is 4445671234, with a calling-party number type set to national.

Figure 7-9 shows how the device pool of the destination gateways determines the calling-party transformation pattern.

Figure 7-9 Gateway Calling-Party Transformation Pattern

Building Classes of Service for Unified CM with the Line/Device Approach

Class-of-Service (CoS) for the Cisco Unified CM refers to the ability to apply call restrictions to certain users and/or phones in the dial plan. The dial plan outlined above allows every IP phone to dial any destination; local, long distance, or international. When it is necessary to dial restrictions to certain phones, this document uses the line/device approach.

The line/device approach works by appending the line CSS to the device CSS on each phone. If the same route pattern appears in two partitions, one contained in the line's calling search space and one contained in the device's calling search space, then the Cisco Unified CM selects the route pattern listed first in the concatenated list of partitions (in this case, the route pattern associated with the line's calling search space).

In the route plan listed above, every phone had a device CSS that allowed it to call any destination. CoS will be applied by defining a line CSS for the restricted lines, that will override the device CSS and deny access to defined call destinations.

To better understand how to apply these rules, consider the example shown in Figure 7-10, where the device calling search space contains a partition with route patterns to all PSTN numbers, including international numbers. The route patterns point to a PSTN gateway via the route list and route group construct.

Figure 7-10 Line/Device Approach

At the same time, the line calling search space contains a partition with a single translation pattern that matches international numbers and that has been configured as a blocked pattern. The resulting calling search space therefore contains two identical patterns matching international numbers, with the blocked pattern in the line calling search space appearing first. The result is that international calls from this line will be blocked.

Survivable Remote Site Telephony (SRST)

When deploying the Cisco Unified Communications across a WAN with the centralized call processing model, additional steps must be taken to ensure that data and voice services at the remote sites are highly available.

The Schools SRA design uses SRST to provide high availability for voice services, by providing a subset of the call processing capabilities within the remote office router and enhancing the IP phones with the ability to "rehome" to the call processing functions in the local router if a WAN failure is detected. Figure 7-11 illustrates a typical call scenario with SRST.

Figure 7-11 Survivable Remote Site Telephony (SRST)

Under normal operations shown in the left part of Figure 7-11, the branch office connects to the central site via an IP WAN, which carries data traffic, voice traffic, and call signaling. The IP phones at the branch office exchange call signaling information with the Cisco Unified CM cluster at the central site and place their calls across the IP WAN. The branch router or gateway forwards both types of traffic (call signaling and voice) transparently and has no knowledge of the IP phones.

If the WAN link to the branch office fails, or if some other event causes loss of connectivity to the Cisco Unified CM cluster, the branch IP phones reregister with the branch router in SRST mode. The branch router SRST queries the IP phones for their configuration and uses this information to build its own configuration automatically. The branch IP phones can then make and receive calls either internally or through the PSTN. The phone displays the message "Unified CM fallback mode," and some advanced Unified CM features are unavailable and are grayed out on the phone display.

When WAN connectivity to the central site is reestablished, the branch IP phones automatically reregister with the Unified CM cluster and resume normal operation. The branch SRST router deletes its information about the IP phones and reverts to its standard routing or gateway configuration. Unified CME running in SRST mode at the branch can choose to save the learned phone and line configuration to the running configuration on the Unified CME router by using the auto-provision option. If auto-provision none is configured, none of the auto-provisioned phone or line configuration information is written to the running configuration of the Unified CME router. Therefore, no configuration change is required on Unified CME if the IP phone is replaced and the MAC address changes.

Note When WAN connectivity to the central site is reestablished, or when Unified CM is reachable again, phones in SRST mode with active calls will not immediately re-register to Unified CM until those active calls are terminated.

SRST CUCM Configuration

Figure 7-12 Configuring SRST Reference

Figure 7-13 Configuring Call Forward Unreachable in CUCM for Remote Phones in SRST Mode

SRST Router Configuration

The sections of Site2 ISR router configuration that are relevant to the SRST configuration are provided below.

ccm-manager fallback-mgcp  
! — This command causes the gateway to fall back and provide call processing services if 
connectivity is lost between the gateway and all Cisco CallManager servers. 
application 
global 
service alternate default 
! — If the MGCP application is not available, the default application (H.323) takes over. 
call-manager-fallback 
!--- Enables SRST support and enters Cisco CallManager fallback mode. 
max-conferences 12 gain -6 
transfer-system full-consult 
ip source-address 10.40.63.9 port 2000 
! — The IP address used by SRST must match the IP phones default gateway, or if an SRST 
reference is configured the phones device pool in CUCM, it must match that. 
max-ephones 10 
max-dn 20 
! 
! 
dial-peer voice 1 pots 
description srst incoming 
translation-profile incoming S2-SRST-in 
service mgcpapp 
incoming called-number . 
direct-inward-dial 
port 2/0/1:23 
forward-digits 8 
dial-peer voice 91 pots 
description SRST; Any long distance number 
destination-pattern 91.......... 
port 2/0/1:23 
forward-digits 10 
dial-peer voice 91444 pots 
description SRST; PSTN School2 to School1 
destination-pattern 91444....... 
port 2/0/1:23 
forward-digits 10 
dial-peer voice 91333 pots 
description SRST; PSTN School2 to district office 
destination-pattern 91333....... 
port 2/0/1:23 
forward-digits 10 
dial-peer voice 91222 pots 
description SRST; School2 local dialing with area code 
destination-pattern 91222....... 
port 2/0/1:23 
forward-digits 10 
dial-peer voice 9345 pots 
description SRST; School2 local dialing (PSTN-router num-exp adds area code) 
destination-pattern 9345.... 
port 2/0/1:23 
forward-digits 7 
dial-peer voice 911 pots 
description SRST; Emergency call without External access code 
destination-pattern 911 
port 2/0/1:23 
forward-digits 3 
dial-peer voice 84441 pots 
description SRST; translate calls to School1 using internal number format 
translation-profile outgoing S2-SRST-out 
destination-pattern 84441... 
port 2/0/1:23 
forward-digits 10 
dial-peer voice 83331 pots 
description SRST; translate calls to District office using internal number f 
translation-profile outgoing S2-SRST-out 
destination-pattern 83331... 
port 2/0/1:23 
forward-digits 10 
dial-peer voice 9911 pots 
description SRST; Emergency call with External access code 
destination-pattern 9911 
port 2/0/1:23 
forward-digits 3 
! 
! 
voice translation-rule 1 
rule 1 /^222345/ /8222/ 
voice translation-rule 10 
rule 1 /^84441/ /4445671/ 
rule 2 /^83331/ /3334561/ 
voice translation-profile S2-SRST-in 
translate called 1 
! — Called by Dial-peer 1 to translate incoming calls from E.164 format to local CUCM 
phone number format 
voice translation-profile S2-SRST-out 
translate called 10 
! — Called by Dial-peers 8333 and 8444 to translate outgoing calls to phones at another 
CUCM site from local CUCM phone number format to E.164 format.

Emergency Notification of 911 Calls with Cisco Emergency Responder

Ease of administration for adds, moves, and changes is one of the key advantages of IP telephony technology. To provide for adds, moves, and changes that automatically update 911 information without user intervention, Cisco has developed a product called the Cisco Emergency Responder (Cisco ER).

The Schools SRA design uses Cisco ER to provide the following primary functionality:

•Dynamic association of a phone to an ERL, based on the detected physical location of the phone.

•Dynamic association of the emergency location identification number (ELIN) to the calling phone, for callback purposes. Cisco ER enables the callback to ring the exact phone that initiated the 911 call.

•On-site notification to designated parties (by pager, web page, or phone call) to inform them that there is an emergency call in progress. The pager and web page notifications include the calling-party name and number, the emergency response location (ERL), and the date and time details associated with the call. Phone notification provides the information about the calling number from which the emergency call was placed.

Note For more information on Cisco ER, refer to the Unified Communications SRND and to the Cisco ER product documentation available online at the following URL: http://www.cisco.com/en/US/products/sw/voicesw/ps842/tsd_products_support_series_home.html

The key functionality of Cisco ER relies on the detection of the phone's location by discovery of the network port (Layer-2 port, such as a Fast Ethernet switched port) from which the phone made the 911 call. The discovery mechanism relies on two main assumptions:

•The wired infrastructure of the enterprise is well established and does not change sporadically.

•The infrastructure is available for Cisco ER to browse; that is, Cisco ER can establish Simple Network Management Protocol (SNMP) sessions to the underlying network infrastructure and can scan the network ports for the discovery of connected phones.

Once the Cisco ER discovers the originating port for the call, it associates the call with the preestablished ERL for the location of that port. This process also yields an association with a preestablished ELIN for the location and the selection of the appropriate egress point to the E911 infrastructure, based on the originating ERL.

The School SRA dial plan is configured so that the system easily recognizes emergency calls, whether an access code (for example, 9) is used or not; the system has been configured to recognize both the strings 911 and 9911. The emergency route patterns have also been explicitly marked with urgent priority so that Unified CM does not wait for the inter-digit timeout (Timer T.302) before routing the call.

Voice Messaging

The Cisco Unified Communications messaging portfolio consists of three main messaging products: Cisco Unity, Cisco Unity Connection, and Cisco Unity Express. Each product fits different requirements, yet each one contains overlapping features and scalability with regard to the others. They also have the ability to interwork with one another using Voice Mail Networking and can also leverage the Cisco Unified Messaging gateway to achieve this in a highly scalable fashion, as discussed later in this chapter. When considering these products, it helps to think of the messaging types that the products apply to in order to understand the messaging options they include and to determine which options could fit your deployment requirements. The following definitions help define these messaging types:

•Voicemail-only—Refers to a telephony voicemail integration where there is no access to the voicemail via any messaging client.

•Integrated messaging—Refers to voicemail with telephony access as well as voicemail-only access via a messaging client.

•Unified messaging—Refers to voicemail with telephony access as well as voicemail, E-mail, and fax access via a messaging client.

Based on the above messaging types and definitions, the three messaging product options are as follows:

•Cisco Unity—This solution option scales to meet the needs of large enterprise organizations and delivers powerful voice, integrated, and unified messaging options that integrate with Microsoft Exchange (including Exchange 2007) and Lotus Domino.

•Cisco Unity Connection—This option combines integrated messaging, voice recognition, and call transfer rules into an easy-to-manage system for medium-sized businesses with up to 10,000 users, or it can network up to 5 systems to support larger-sized businesses with up to 50,000 users. For organizations with up to 500 users, Cisco Unity Connection is available as a single-server solution with Cisco Unified Communications Manager Business Edition.

•Cisco Unity Express—This option provides cost-effective voice and integrated messaging, automated attendant, and interactive voice response (IVR) capabilities in certain Cisco Integrated Services Routers for small and medium-sized businesses and enterprise branch offices with up to 250 users.

For the Schools SRA test network, Cisco Unity 7.0 for Microsoft Exchange was deployed. Deploying Unity allows for a centralized deployment with the greatest scalability and broadest feature set. The following Unity collaboration capabilities are important in this decision;

•Unified messaging—Cisco Unity unified messaging integrates transparently with Microsoft Exchange, allowing you to handle all your messages - E-mail, voice, and fax - through a single inbox using the Outlook E-mail client. Icons provide simple visual descriptions of each message type, and because every message is delivered to one inbox, you can see the number, type, and status of all your communications at a single glance. You also can reply to, forward, and save your messages - regardless of media type - in public or personal Microsoft Outlook folders with just a click of the mouse, decreasing response times and increasing organizational agility and customer service.

•Mobile access to voice messages—Cisco Unity unified messaging delivers all-in-one messaging for mobile users. Mobile workers using a Palm Treo or RIM BlackBerry device can simply double-click to play voice messages within their smartphone E-mail applications. The Cisco Unity solution supports a variety of notification options that allow you to customize the way you are notified of new voice messages. Cisco Unity Unified Messaging for Microsoft Exchange users can access their voice messages using Cisco Unified Mobile Communicator, which integrates with Exchange to provide mobile access to messages. Even for users with basic mobile phones, the Cisco Unity solution is optimized to enhance mobile productivity. When you call in from a mobile phone, speech recognition allows for hands-free usage of the system. If a call is dropped because of a less-than-fully reliable mobile phone network, the Interrupted Session Recovery feature resumes, on the next call-in, the session where the call left off, reducing lost time.

Note Unity requires integration with Microsoft Active Directory and Exchange, smaller school districts might opt for a simpler Cisco Unity Connections deployment instead of deploying Unity.

Cisco Unified Personal Communicator 7.0

Cisco Unified Personal Communicator provides a very versatile communications platform to the schools SRA. Cisco Unified Personal Communicator is a Microsoft Windows or Apple Mac application that operates in one of two modes, Desk Phone (CTI control of the user's desk phone for click to call) and Soft Phone (software client operation), and it is supported on Apple Macintosh and Microsoft Windows platforms.

Cisco Unified Personal Communicator integrates the most frequently used communications applications and services into a single desktop software application. Cisco Unified Personal Communicator facilitates streamlined communications from your desktop or laptop computer, including integrated contact lists, click to call, instant messaging, voicemail playback, inbound call notification, and media escalation. By being able to control your communications from a single window, you can communicate more effectively and be more productive.

Figure 7-14 Cisco Unified Personal Communicator

Cisco Unified Personal Communicator Features and Benefits

•Communication integration—Take advantage of a single, intuitive interface for voice and video calls, instant messaging, voicemail playback, web conferencing, and integrated directories.

•Presence—View real-time availability of other Cisco Unified Personal Communicator and Cisco Unified IP Phone users. You can also display customized messages, set an out-of-office message, and automatically show your availability based on free and busy status on your Microsoft Outlook Calendar.

•Do not disturb (DND)—Easily block incoming calls with synchronized DND status from your Cisco Unified Personal Communicator or Cisco Unified IP Phone or use the privacy preference setting to block instant messages when you need additional privacy.

•Contact list—Search your corporate directory from one easy-to-use interface to locate contacts quickly and simply click to call. Add your most frequently contacted personal contacts, co-workers, and federated business contacts

•Media escalation—Add communication methods during a conversation; for example, you can add video to an audio conversation or add web conferencing or white-boarding to an existing audio or video conversation.

•Click to call—Dial from the contact list, using either the integrated softphone or an associated Cisco Unified IP Phone. You can also click to call directly from Microsoft Outlook using an Outlook toolbar.

•Integrated voice and video calling—Exchange ideas face-to-face with a coordinated video display on the PC screen and audio conversation with the softphone. You can place video calls using Cisco Unified Personal Communicator, Cisco Unified Video Advantage, or the Cisco Unified IP Phone 7985G, a personal desktop videophone.

•IP phone association—Use Cisco Unified Personal Communicator to control your desktop Cisco Unified IP Phone to make, receive, or merge calls.

•Instant messaging—Chat in real time using instant messaging with other Cisco Unified Personal Communicator users to save time and reduce phone tag. In addition, enable business-to-business federation between Cisco Unified Presence and Microsoft Live Communications or Microsoft Office Communications server to exchange presence information and instant messages with Microsoft Office Communicator and Cisco Unified Personal Communicator users.

•Conferencing—Create voice or video conferencing sessions by simply merging conversation sessions. There is no need to call into a separate conference bridge.

•Web conferencing—Launch a Cisco Unified MeetingPlace, Cisco Unified MeetingPlace Express, or Cisco WebEx web conferencing session at a moment's notice to share content, such as a presentation, with others.

•Voice messages—Access secure Cisco Unity® or Cisco Unity Connection encrypted voicemail messages - view, play back, sort, and delete messages - all from within the application.

•Languages supported for both Microsoft Windows and Apple Macintosh desktops include—Arabic, Chinese (Traditional Chinese and Simplified Chinese), Danish, Dutch, English, French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Spanish, Russian, and Swedish.

Cisco Unified Mobility

Cisco Unified Mobility is natively available with Cisco Unified CM on the school SRA network. Cisco Unified Mobility extends rich call control capabilities of Cisco Unified Communications Manager from a mobile worker's primary workplace desk phone to any location or device of their choosing.

Some of the key benefits of enabling Cisco Unified Mobility capabilities with Cisco Unified Communications Manager include:

•Single Business Number Reach and Single Business Voicemail—Cisco Unified Mobility makes it possible for workers to consolidate all their incoming business calls (i.e. incoming business calls to mobile phones, home office phone, or any temporary telework phone) into a single business phone number and immediately receive them wherever they are working. Coworkers, business partners, and customers now only need a single business phone number to reach workers who can be more responsive without additional effort. If mobile workers are unable to answer the call extended to one of the many user-defined alternative phone numbers, they can rely on Cisco Unified Mobility to store the unanswered calls into a single business voicemail on Cisco Unity ® or other business voicemail system. Cisco Unified Mobility reduces the burden on workers of having to share multiple phone numbers with business contacts and having to check multiple voicemail boxes at the end of the day.

•Seamless Transition of Ongoing Extended Communications—Mobile phones are great when moving from location to location, but when a mobile worker arrives at the office, they would rather take advantage of speakerphone or other IP Phone services on their Cisco Unified IP Phone at their desk. Cisco Unified Mobility provides seamless transition of extended ongoing calls from mobile phones to desk phone and vice versa. This provides workers with the ability to maintain business communications continuity while taking advantage of least cost routing of mobile calls across company's IP communications infrastructure while in the office. Hence they can start the conversation from their mobile phone and seamlessly transition that conversation to a desk phone upon arrival in the office without needing to call back. Similarly they can transition the call seamlessly back to the mobile phone and wander away at will for another appointment.

•Cisco Mobile Voice Access—With Cisco Unified Mobility, workers who need to place national or international calls from their mobile phone can use the Cisco Mobile Voice Access line to place the call as if they are placing the call from their business extension on their desk. The worker dials the Cisco Mobile Voice Access line from the mobile phone and places the call on the IP communications network over a tie line. The call is connected and remains in control of Cisco Unified Communications Manager providing the opportunity to reduce mobile communications costs associated with national or international calls placed directly from mobile phone. With Cisco Mobile Voice Access, the person being called sees the caller-id as coming from a desk phone in the office rather than from the personal cell phone that may have actually initiated the call.

•Access to Mid Call Control Cisco Unified Communications Manager Capabilities—Cisco Unified Mobility extends key call control features of Cisco Unified Communications Manager (such as hold, resume, transfer, and conferencing) on calls extended to devices and locations of the workers choice. For workers who have become accustomed to such productivity capabilities in the office can now access them while they are away from their desk.

•Personalized Access Lists—Mobile workers can access the secure user profile webpage to enter mobile and other alternate phone numbers and create filters that restrict the types of calls that are extended using Cisco Unified Mobility. Cisco Unified Mobility intelligently manages, filters, and routes each call between a worker's business extension and alternate phone numbers based on rules defined by the worker on their profile. Unanswered calls are consolidated into single business voicemail and voice communications resources are only used to extend relevant calls as determined by rules specified by the worker.

•Web-Based System Administration—Cisco Unified Mobility provides system administrators with the flexible to define and manage user profiles. System administrators can use the secure Administration Webpage to determine how much control users will have over their profiles and make user profile changes when needed. Users enjoy the advantages of personal choice, while the system administrator retains control over resource use and can provide backup support.

Cisco Unified Mobile Communicator

Cisco Unified Mobile Communicator (see Figure 7-15) is an easy-to-use software application for mobile handsets that facilitates more effective communications for mobile employees. By extending enterprise communications applications and services to mobile phones and smartphones, Cisco Unified Mobile Communicator streamlines the communication experience, facilitating real-time collaboration across the enterprise. With Cisco Unified Mobile Communicator, you can place and receive calls, access company directory contacts, check presence information, and review voicemail messages, as well as receive Cisco Unified MeetingPlace® notifications and other vital information-all from a single, intuitive interface connected to Cisco Unified Communications.

Figure 7-15 Cisco Unified Mobile Communicator

Using Cisco Unified Mobile Communicator, employees have the Key Features and Benefits available on the mobile cellular phone;

•Communication integration—Use one intuitive interface for mobile calls, directory and presence information, voicemail playback, text messaging, and conferencing.

•Unified contact list—Search your corporate directory (Active Directory) and personal contacts (Microsoft Outlook) from one easy-to-use interface to locate contacts quickly. Simply select a name to call.

•Presence—Find a contact and see whether the person is available to talk-before placing the call. View a person's availability status from the directory on the mobile handset.

•Select to call—Dial from the directory by simply selecting a name.

•Single-business-number reach—Provide colleagues with a single number to reach you. Supported by Cisco Unified Mobility, calls to your desk phone can be answered from your mobile phone. If you are busy, simply decline or ignore the call and it will be diverted to your office voicemail.

•Secure text messaging—Send and receive text messages from colleagues when they are unavailable to talk. A visual list on your mobile handset shows at a glance who is trying to reach you. Incoming messages are conveniently grouped by person, showing the sender, the priority, and a brief subject line, if available.

•Voice messages—Access Cisco Unity® voicemail messages to select, view, play back, and delete messages in any order, all from the mobile handset.

•Conferencing—Receive notifications of conference calls on your mobile phone from the Cisco Unified MeetingPlace solution. Simply press a button to call the conference bridge.

•Call logs—View a list of recent calls on your mobile phone and learn what calls were missed, placed, and received from your mobile phone or your Cisco Unified IP Phone.

•Security—Cisco Unified Mobile Communicator is deployed securely behind the enterprise firewall. Cisco Unified Mobile Communicator uses industry-standard, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption to protect transmission of data between handsets and your data center. End users authenticate with existing Lightweight Directory Access Protocol (LDAP) directories. If a mobile handset is lost or stolen, IT staff can remotely deactivate the device and erase sensitive company information.

•Management—Simple, Web-based management allows IT staff to manage user activation, configuration, and administration; set system privileges and security; report statistics; and manage devices. The end-user portal allows provisioning, directory management, and configuration of user preferences.

•Broad operator and device support—Working simultaneously across multiple networks, mobile operators, and handset platforms, Cisco Unified Mobile Communicator helps ensure end-user choice and delivery of consistent performance at work, at home, and on the road.