Configuring Globalized Call Routing in Cisco Unified Communications Manager

Call Routing and Path Selection

Chapter 18, “Cisco Unified Communications Manager Call Admission Control (CAC),” introduced the concept of call routing within the Cisco Unified Communications Manager. Routing calls involves several aspects, some of which were covered in that chapter. Chapter 18 covered how to allow or block calls based on the Class of Service of the calling entity, and began identifying dialing habits based on the structure of the dial string. This chapter will expand on these concepts as calls reach beyond the local call control system. Call routing is about selecting a route to the called destination, establishing the call, and presenting the identity of the parties involved in the expected format. Route selection also involves selecting alternate routes if the primary route is not available for some reason. It also involves applying modifications to the dial string and applying modifications to the calling party identification. An end-to-end enterprise dial plan needs to consider all of these aspects and is not limited only to establishing a route between the calling and called entities. Calls must be routed and interconnected according to the dialed number. There are three main types of call routing:

• Intrasite routing: This type of call routing occurs within a single site.

• Intersite routing: This type of call routing occurs between multiple sites.

  • A translation pattern is used for both centralized and distributed call-processing deployment models.

  • A route pattern is used only for a distributed call-processing deployment.

• PSTN routing: This type of call routing occurs between a site and the PSTN.

The Cisco Unified Communications Manager can automatically route calls to internal destinations within the same cluster because Cisco Unified Communications Manager is configured with the directory numbers of its associated devices. For external destinations, an explicit route—called a route pattern—must be configured. External destinations are PSTN destinations or other VoIP domains such as an ITSP or another Cisco Unified Communications Manager cluster. PSTN destinations can include off-net intersite calls, which are effectively PSTN destinations because they are addressed by their PSTN numbers. The Cisco Unified Communications Manager call-routing table is built using connected devices. The table consists of directory numbers of registered IP phones and of statically entered route patterns that point to external destinations. Regardless of the call-routing type, the call-routing process itself can be summarized as follows:

1. Cisco Unified Communications Manager receives a call setup request from a local endpoint or from another call control system such as a remote Cisco Unified Communications Manager cluster or a PSTN gateway.

2. Cisco Unified Communications Manager analyzes the target of the received request to find the best matching entry in its call-routing table. The type of analysis depends on the addressing method that is used by the source of the call setup request (digit-by-digit or en bloc) and the address type (number versus URI).

3. Cisco Unified Communications Manager forwards the call setup request to the destination device that is associated with the matched call-routing table entry. This destination device can be a local endpoint or another remote call control system.

Many different settings within the Cisco Unified Communications Manager require an administrator to understand the difference between call-routing sources and call-routing targets. Five different sources of call-routing requests require a call-routing table lookup. The simplest are the IP phone, gateways, and trunks. The following sources of call-routing requests also require a call-routing table lookup:

• Translation patterns: A translation pattern is like a route pattern. A translation pattern includes a pattern that when matched provides an entry to the call-routing table. If the dialed number matches the pattern, another number, which is the translated number that is configured at the translation pattern, is looked up in the call-routing table. A translation pattern, therefore, combines both roles in one entity. The translation pattern is both a call-routing table target when it is matched by a dialed number and the basis of a second lookup for the translated number.

• Voicemail ports: When a call is sent to a voicemail system, that system can request that the call be transferred to another directory number, to a PSTN destination, such as the cell phone of a user, or to an assistant. In all these scenarios, the voicemail port is the entity that requests the call that the Cisco Unified Communications Manager is routing.

By contrast, several other components within the Cisco Unified Communications Manager are call-routing targets, such as directory numbers, route patterns, translation patterns, and more. Table 19-2 identifies components that are call-routing sources and targets. If a dialed number matches one of these entries, the call is routed to the appropriate entity. That entity can be a phone line, a trunk, a gateway, a feature, or an application. For URI-based call routing, only directory URIs and SIP route patterns are applicable. All other components refer to call routing for numbered targets. However, calls placed to directory URIs can be routed only to a local phone, if the directory URI is associated with a directory number.

Table 19-2 Call-Routing Source and Target Components

When a number is dialed, the Cisco Unified Communications Manager uses closest-match logic to select which pattern to match from among all the patterns in its call-routing table. In practice, when multiple potentially matching patterns are present, the destination pattern is chosen based on the following criteria:

• The pattern matches the dialed string.

• The pattern represents the smallest number of endpoints.

Some entries of the call-routing table can include wildcards, such as an X in a numbered pattern that represents one digit. If the exclamation point (!) is used in a numbered pattern, it stands for one or more digits. Figure 19-1 illustrates an example in which the call-routing table includes the numbered patterns 12XX, 121X, and 1234.

Figure 19-1 Closest-Match Logic

When a user dials the string 1234, the Cisco Unified Communications Manager compares the string to the patterns in its call-routing table. In this case, there are two potentially matching patterns: 12XX and 1234. Both of these patterns match the dialed string, but 12XX matches a total of 100 numbers from 1200 to 1299, whereas 1234 does not include any wildcard characters and therefore is one exact number. Therefore, 1234 is selected as the destination of this call because it is the closest match. When a user dials the string 1210, then pattern 121X is chosen because out of the two potential matches, 121X and 12XX, 121X is the better match as it represents only 10 possible numbers while 12XX represents 100 possible numbers. The same is also true for URI pattern matching. When a user dials the URI alice@cisco.com, the Cisco Unified Communications Manager chooses the locally configured URI that is an exact match of the dialed URI. However, when a user dials the URI bob@cisco.com, the only match is the SIP route pattern *, which stands for any URI. If there were a SIP route pattern *.cisco.com, then a call to bob@cisco.com would find a better match in the *.cisco.com SIP route pattern because it is more specific than the * SIP route pattern.

From the phone that is placing the call, there are different dialing methods as to how dialed aliases are sent to the Cisco Unified Communications Manager. In SIP, you can use en bloc dialing or KPML. In en bloc dialing, the whole dialed string is sent in a single SIP INVITE message. KPML allows digits to be sent one by one. SIP dial rules are also supported, which allow part of the call attempt to be processed inside the SIP phone. Therefore, a SIP phone can detect invalid numbers and play a reorder tone, without sending any signaling messages to the Cisco Unified Communications Manager. If dialed digits match an entry of a SIP dial rule, the dialed string is sent in a single SIP INVITE message to the Cisco Unified Communications Manager en bloc. If the Cisco Unified Communications Manager requires more digits, KPML can be used to send the remaining digits one by one from the SIP phone to the Cisco Unified Communications Manager.

Trunks, gateways, and ISDN PRIs can be configured for overlap sending and receiving, in addition to en bloc, allowing digits to be sent or received one by one over an ISDN PRI. The difference between trunks and gateways in regard to addressing methods is the protocols each supports. So, the Cisco Unified Communications Manager does not always receive all dialed digits at once. Table 19-3 shows the addressing methods that the Cisco Unified Communications Manager supports for different devices.

Table 19-3 Addressing Methods for Destination Numbers

Be aware that if a phone sends dialed digits one by one, the Cisco Unified Communications Manager starts digit analysis immediately upon receiving the first digit. In fact, digit analysis starts one step earlier, when a phone indicates an off-hook state to the Cisco Unified Communications Manager. At that point, the Cisco Unified Communications Manager looks up a null string dialed number that matches all available routes in the call-routing table. By analyzing each additional digit that is received, the Cisco Unified Communications Manager can reduce the list of potential matches within the call-routing table. After a single entry is matched, such as the directory number 1234 from Figure 19-1, the call is then sent to the corresponding device. The Cisco Unified Communications Manager does not always receive dialed digits one by one. If digits are received en bloc, the whole received dial string is checked at once against the call-routing table.

An international call prefix or dial-out code is a trunk prefix used to select an international telephone circuit for placing an international call. It is now called an International Direct Dialing (IDD) prefix. A country will typically have a National Direct Dialing (NDD) prefix as well. The ITU recommends the sequence 00 as a standard for an IDD prefix, and this sequence has been implemented by most countries, but not all of them. Calls for any country that follows the North American Numbering Plan (NANP), such as the United States and Canada, use 011 as the IDD. Japan uses 010, Australia uses 0011, and Russia uses a predefined international call operator with 810. International destinations are usually configured by using the exclamation point (!) wildcard, which represents any quantity of digits, also referred to as variable-length patterns. In North America, the route pattern 9.011! is typically configured for international calls. The 9. (note the dot) is significant because the 9 is representative of an IP PBX prefix used to obtain an outside line. Dialing behaviors called “pre dot” that can be configured in the Cisco Unified Communications Manager allow any digits that precede a dot in a dial pattern to be stripped off. Therefore, the 9 is used to obtain an outside line and then removed from the dial string so that it does not interfere with how the call should be routed. The 011 is the IDD number in this same example, and the exclamation point (!) is the wildcard signifying any additional digits that are dialed, regardless of how long or short the dial string is. In most European countries, the same result is accomplished by using the 0.00! route pattern.

When phone numbers are published for use abroad, they typically show a plus sign (+) prefix in place of any international call prefix, to signify that callers should use the prefix code appropriate for their country. Many phones allow the plus sign to be entered in their saved number lists. Holding down the zero (0) key will enter a plus sign on most GSM mobile phones, while other phones, such as Cisco Unified IP phones, require two consecutive presses of the star (*) key. When a call is made, the system then automatically converts the plus sign to the correct IDD prefix, depending on where the phone is being used. This enables callers to use the same stored number when calling from either their own country or any other.

When matching a variable-length pattern, the Cisco Unified Communications Manager does not know when dialing is complete, so it will wait for 15 seconds by default before processing the call. This post-dial delay can be reduced or eliminated as follows:

• Reduce the Cisco CallManager service parameter called the T302 Timer to allow earlier detection of the end of dialing. However, do not set this timer to less than 4 seconds, to prevent premature transmission of the call before the user finishes dialing.

• Configure a second route pattern, followed by the pound sign (#) wildcard, such as 9.011!# for North America or 0.00!# for Europe. Then educate users that they can indicate end of dialing by terminating the number with the # key. This action is analogous to pressing the Send button on a cell phone.

The implementation of the interdigit timeout termination in the Cisco Unified Communications Manager is different from the implementation in Cisco IOS dial peers. In the Cisco Unified Communications Manager, the # is not only the instruction to stop digit collection but is also part of the dialed number. Therefore, if you use the # to avoid waiting for the expiration of the interdigit timeout, all route patterns must be configured twice—once with the # and once without.

A dial plan may include overlaps. Overlaps occur when a pattern overlaps with another, longer pattern. Figure 19-2 illustrates an overlap scenario within a dial plan: 131 overlaps with 13!.

Figure 19-2 Overlaps and Interdigit Timeout

Digit collection is stopped as soon as an entry in the call-routing table is matched in its complete length and no other potential matches exist. In Figure 19-2, a user dials 13115. The Cisco Unified Communications Manager interprets the number digit by digit as the user enters the digits on the keypad of the phone. After all received digits are analyzed, the only match is 13!. Although there is only a single matching pattern, the Cisco Unified Communications Manager must wait for additional digits because the matched pattern is of variable length. The (!) wildcard represents one or more digits. The call can be sent to the device that is associated with pattern 13! only after the interdigit timeout expires. In this scenario, you could lower the T302 timer or add a pattern 13!# to reduce or eliminate post-dial delays. If the user dials 131, the user will also experience a post-dial delay. After these three digits are analyzed, two longer potential matches remain (1[2–4]XX and 13!). The Cisco Unified Communications Manager detects that the end user finished dialing and that the longer matches are not applicable only after the interdigit timeout expires. If the user dials 1415, the only matching pattern is 1[2–4]XX. This pattern does not include the (!) wildcard, and the Cisco Unified Communications Manager does not have to wait for additional dialed digits. The call to 1415 can be routed immediately after receiving the fourth digit.

Route patterns, translation patterns, and directory numbers have a check box labeled Urgent Priority. The Urgent Priority check box can be used to force immediate routing of certain calls as soon as a match is detected, without waiting for the interdigit timeout to expire when additional longer potential matches exist. The most applicable scenario in North America pertains to emergency 911 calls. If the patterns 9.911 and 9.[2–9]XXXXXX are configured and a user dials 9911, the Cisco Unified Communications Manager must wait for the interdigit timeout before routing the call because further digits might cause the 9.[2–9]XXXXXX pattern to match. However, when urgent priority is enabled for the 9.911 route pattern, the Cisco Unified Communications Manager makes its routing decision as soon as the user has finished dialing 9911, without causing any post-dial delay. When urgent priority has been enabled, the specified route pattern is excluded from other, longer route pattern matches. If en bloc dialing is used and the provided number is longer than the urgent pattern, the urgent pattern is not considered.

Route Groups and Local Route Groups

In larger enterprise networks, a number of IP PBXs might be deployed over several clusters. These independent IP PBX or PBX clusters are interconnected using trunks. The possible topologies include hub and spoke, full mesh, or many different combinations of these. Each one of these IP PBXs is capable of independently routing calls initiated by either endpoints, applications registered locally, or internal and external trunks. Connections to voice gateways, session border controllers, and other devices can also provide connections between the enterprise IP network and the PSTN for business-to-business (B2B) communications. Some structural method must be used to map out how these complex systems can communicate successfully with one another.

The Cisco Unified Communications Manager uses route plans to determine how to route calls between clusters and how to route external calls to a private network or to the public switched telephone network (PSTN). The route plan configured specifies the path that the system uses to route each type of call. For example, a route plan can be created to use the IP network for on-net calls and then use one carrier for local PSTN calls and a different carrier for international calls. The Cisco Unified Communications Manager has a three-tiered approach to route planning that uses the following components:

• Route Patterns: The system searches for a configured route pattern that matches the external dialed string and uses it to select a gateway or a corresponding route list.

• Route Lists: These are prioritized lists of the available paths for the call.

• Route Groups: These are the available paths; the route group distributes the call to gateways and trunks.

In addition to these building blocks, the route plan can also include the following components. Not all of these additional routing components will be discussed in this section:

• Local Route Groups: Decouple the location of a PSTN gateway from the route patterns that are used to access the gateway.

• Route Filters: Restrict certain numbers that are otherwise allowed by the route pattern.

• Automated Alternate Routing (AAR): Automatically reroute calls through the PSTN or another network when the system blocks a call due to insufficient bandwidth.

• Time-of-Day Routing: Create a time schedule that specifies when a partition is available to receive incoming calls. This topic will be discussed more later in a section on call privileges.

A local route group can reduce the number of route lists that are required within an enterprise network. Route lists point to the PSTN gateway that the system uses to route the call, based on the location of the PSTN gateway. As an alternative, you can use local route groups to decouple the location of a PSTN gateway from the route patterns that are used to access the gateway. This configuration allows phones and other devices from different locations to use a single set of route patterns, while the Cisco Unified Communications Manager selects the correct gateway to route the call.

The Cisco Unified Communications Manager provides a default local route group called standard local route group, but additional local route groups can be configured. To configure new local route groups, follow these steps:

• Step 1. Configure local route group names.

  1. From Cisco Unified CM Administration, navigate to Call Routing > Route/Hunt > Local Route Group Names.

  2. Click Add Row.

  3. Enter a name and description for the new local route group, and then click Save.

• Step 2. Associate a local route group with a device pool.

  1. Navigate to System > Device Pool.

  2. Enter search criteria if necessary, and then click Find. Select a device pool from the resulting list.

  3. In the Local Route Group Settings area, select a route group from the Standard Local Route Group drop-down list.

  4. Click Save.

• Step 3. Add a local route group to a route list.

  1. Navigate to Call Routing > Route/Hunt > Route List.

  2. Choose one of the following options:

     • Click the Add New button to add a new route list.

     • Click Find and select a route list from the resulting list to modify the settings for an existing route list.

  3. The Route List Configuration window appears. To add a local route group to the route list, click the Add Route Group button.

  4. From the Route Group drop-down list, select a local route group to add to the route list. You can add the standard local route group, or you can add a custom local route group that you have created.

  5. Click Save, and then click Apply Config.

A route group can be configured to prioritize the order in which the Cisco Unified Communications Manager selects gateways for outgoing calls. Use the following procedure to group together gateways that have similar characteristics, so that any gateway in the group can dial the call. The Cisco Unified Communications Manager will select a gateway to use based on the order that was specified when the route group was configured. A single gateway or other device can be assigned to multiple route groups.

• Step 1. From Cisco Unified CM Administration, navigate to Call Routing > Route/Hunt > Route Group.

• Step 2. Choose one of the following options:

  • Click Add New to add a new route group.

  • Click Find and choose a route group from the resulting list to modify the settings for an existing route group.

• Step 3. When the Route Group Configuration window appears, configure the following fields:

  • Route Group Name: Enter a name for the route group.

  • Distribution Algorithm: Choose between Circular and Top Down.

  • Find Devices to Add to Route Group: There will be a list of available trunks and gateways in the Available Devices window. You can search this list by using the Device Name Contains menu option. Select a gateway from the list, and then click the Add to Route Group button.

  • Current Route Group Members: Any devices added to the route group will be added to this box. This is a prioritized list and will be searched based on the Distribution Algorithm configuration. Select a device from the list and use the arrow keys to the right of the box to change the order within the list.

• Step 4. Click Save.

  Figure 19-3 illustrates the Route Group Configuration menu options.

  

  Figure 19-3 Route Group Configuration Menu

Route Lists

A route list can be configured to identify a set of route groups and order them by priority. The Cisco Unified Communications Manager uses the order in the route list to search for available devices for outgoing calls. If you configure a route list, you must configure at least one route group first. A route list can contain only route groups and local route groups.

When an outbound call is sent through a route list, the route list process locks the outbound device to prevent sending an alert message before the call is completed. After the outbound device is locked, the hunt list, if any is configured, will stop hunting down the incoming calls. Use the following steps to configure a route list in the Cisco Unified Communications Manager:

• Step 1. From Cisco Unified CM Administration, navigate to Call Routing > Route/Hunt > Route List.

• Step 2. Choose one of the following options:

  • Click Add New to add a new route list.

  • Click Find and select a route list from the resulting list to modify the settings for an existing route list.

• Step 3. Configure the following fields in the Route List Configuration window.

  • Name

  • Description (Optional)

  • Cisco Unified Communications Manager Group

  • Enable This Route List check box

  • Run on All Active Unified CM Nodes check box

• Step 4. To add a route group to the route list, click the Add Route Group button.

• Step 5. From the Route Group drop-down list, choose a route group to add to the route list.

• Step 6. Click Save.

• Step 7. Click Apply Config.

  Figure 19-4 illustrates the Route List Configuration menu options.

  

  Figure 19-4 Route List Configuration Menu

Route Patterns and SIP Route Patterns

As mentioned in the previous section, the Cisco Unified Communications Manager does not require route patterns or SIP route patterns when routing locally within the Cisco Unified Communications Manager itself. These pattern types are used to match dialed aliases intended to route outside the Cisco Unified Communications Manager, whether that call attempt is on-net or off-net. Route patterns are used to route numeric digits only. SIP route patterns are used to route SIP URIs only. The following instructions describe the basic settings needed to configure each of these pattern types in the Cisco Unified Communications Manager. Although the route pattern can point directly to a gateway, Cisco does recommend that route patterns be configured with route lists and route groups. This approach provides the greatest flexibility in call routing and scalability.

• Step 1. From Cisco Unified CM Administration, navigate to Call Routing > Route/Hunt > Route Pattern.

• Step 2. Perform one of the following:

  • Click Add New to create a new route pattern.

  • Click Find and select an existing route pattern.

• Step 3. The Route Pattern Configuration window appears. Configure the following fields at a minimum:

  • In the Route Pattern field, enter the number pattern that the dial string must match.

  • From the Gateway/Route drop-down list, select the destination where you want to send calls that match this route pattern.

  • Complete the remaining fields in the Route Pattern Configuration window. For more information on the fields and their configuration options, see the system’s Online Help.

• Step 4. Click Save.

  Figure 19-5 illustrates the Route Pattern Configuration menu options.

  

  Figure 19-5 Route Pattern Configuration Menu

Wildcards and special characters in route patterns allow a single route pattern to match a range of numbers (addresses). You can use these wildcards and special characters to build instructions that enable the Cisco Unified Communications Manager to manipulate a number before sending it to an adjacent system. Table 19-4 describes the wildcards and special characters that Cisco Unified Communications Manager supports.

SIP route patterns are configured in the Cisco Unified Communications Manager to route or block calls to external entities based on the host portion, otherwise known as the domain portion, of directory URIs. A SIP route pattern can point directly to a SIP trunk or point to a route list that then refers to one or more route groups and finally to SIP trunks. The use of the full SIP route pattern, route list, route group construct is highly recommended because it offers more flexibility.

Table 19-4 Wildcards and Special Characters in Route Patterns

SIP route patterns matching on the host part of the directory URI can match on a domain name or an IP address, both of which can be configured after the @ on directory URIs. Wildcards can be used in the IPv4 patterns to match on multiple domains, such as *.cisco.com and ccm[1-4].uc.cisco.com. In IP address SIP route patterns, a subnet notation can be used, such as 192.168.10.0/24. To create a SIP route pattern that matches any domain, you can just put * (star) in the pattern string field.