Home > Articles > Configuring Globalized Call Routing in Cisco Unified Communications Manager

Configuring Globalized Call Routing in Cisco Unified Communications Manager

Chapter Description

In this sample chapter from CCNP and CCIE Collaboration Core CLCOR 350-801 Official Cert Guide, you will examine Cisco Unified Communications Manager call-routing tools, such as route patterns, SIP route patterns, route groups, and route lists.

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

Routing Component


Call-Routing Source, Target, or Both

IP Phones

A number dialed by an IP phone is looked up in the call-routing table.



A call request received through a trunk is looked up in the call-routing table.



A call request received from a gateway is looked up in the call-routing table.


Translation Patterns

After a translation pattern is best matched (as a target of a call-routing table lookup), the transformed number is looked up again in the call-routing table. The entry that generates this lookup is the translation pattern.


Voicemail Ports

A voicemail system can be configured to allow calling of other extensions or PSTN numbers (such as the mobile phone of an employee). In these cases, the call-routing request is received from the voicemail port of the CUCM.


Directory Numbers

Assigned to endpoints.


Directory URIs

Assigned to directory numbers.


Route Patterns, SIP Route Patterns

Used to route calls to off-net destinations (via a gateway) or to other CUCM clusters via a trunk.


Call Park Numbers

Allows a call on hold to be sent to a number and retrieved from another phone by dialing that number.


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

Device Type

Signaling Protocol(s)

Addressing Method

IP Phones


Digit-by-digit analysis

En bloc (not on type-A phones)


En bloc

KPML (not on type-A phones)

SIP dial rules


MGCP, SIP, H.323

En bloc

Overlap sending and receiving


SIP, H.323

En bloc

Overlap sending and receiving

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

    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

    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

    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




The at symbol (@) wildcard matches all National Numbering Plan numbers. Each route pattern can have only one @ wildcard.


The X wildcard matches any single digit in the range 0 through 9.


The exclamation point (!) wildcard matches one or more digits in the range 0 through 9.


The question mark (?) wildcard matches zero or more occurrences of the preceding digit or wildcard value.


The plus sign (+) wildcard matches one or more occurrences of the preceding digit or wildcard value.

[ ]

The square bracket ([ ]) characters enclose a range of values. Only one value in the range can represent a dialed character.


The hyphen (-) character, used with the square brackets, denotes a range of values.


The circumflex (^) character, used with the square brackets, negates a range of values. Ensure that it is the first character following the opening bracket ([). Each route pattern can have only one ^ character.


The dot (.) character, used as a delimiter, separates the Cisco Unified Communications Manager access code from the directory number. Use this special character, with the discard digits instructions, to strip off the Cisco Unified Communications Manager access code before sending the number to an adjacent system. Each route pattern can have only one dot (.) character.


The asterisk (*) character can provide an extra digit for special dialed numbers.


The octothorpe (#) character, often called the pound sign, generally identifies the end of the dialing sequence. Ensure the # character is the last character in the pattern.


A plus sign preceded by a backslash, that is, \+, indicates that you want to configure the international escape character +. Using \+ means that the international escape character + is used as a dialable digit, not as a wildcard.

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 To create a SIP route pattern that matches any domain, you can just put * (star) in the pattern string field.

3. Digit Manipulation | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020