Home > Articles > Cisco Certification > CCNP > Implementing Cisco Unified Communications Manager, Part 2 (CCNP Voice): Examining Remote-Site Redundancy Options

Implementing Cisco Unified Communications Manager, Part 2 (CCNP Voice): Examining Remote-Site Redundancy Options

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Aug 25, 2011.

Chapter Description

This chapter provides an overview of the different options with remote-site redundancy in CUCM multisite installations. These different mechanisms are illustrated to help you understand how the technologies interact to deliver reliable communication services. This includes Media Gateway Control Protocol (MGCP) and Cisco Unified Survivable Remote Site Telephony (SRST).

Support for Multiple MOH Sources

Cisco Unified SRST v8.x also introduces support for multiple Music On Hold (MOH) sources.

Before Cisco Unified SRST v8.x, only a single MOH file was supported by Cisco Unified SRST, CUCM Express in SRST mode, and CUCM Express in standalone mode. Cisco Unified SRST v8.x allows you to configure up to five additional MOH sources by configuring MOH groups. Only SCCP IP Phones support these newly introduced MOH groups. You can configure each MOH group with an individual MOH file that is located in the flash memory of the router, and you can enable multicast MOH for each MOH group. Each MOH group is configured with the DN ranges that should use the corresponding MOH group when callers are put on hold, as described in Chapter 7, "Implementing Cisco Unified Communications Manager Express (CUCME) in SRST Mode."

The traditional MOH configuration for Cisco Unified SRST and CUCM Express is still supported. It is used by all phones that do not have a MOH group assigned. All these phones are SIP and SCCP phones whose DNs have not been specified in any MOH group. MOH files can be cached in router RAM. This process reduces the amount of read operations in flash, but it requires enough available RAM at the router. You can limit RAM usage for MOH file caching by using smaller MOH files.

Dial Plan Requirements for MGCP Fallback and SRST Scenarios

Figure 5-11 illustrates the requirements of standalone dial plans to work with MGCP fallback and SRST.

Figure 5-11

Figure 5-11 SRST Dial Plan Requirements for Calls from the Remote Site

SRST failover leaves the remote site independent from the complex dial plan implemented in CUCM at the main site. The SRST router needs to have a dial plan implemented to allow all remote-site phones, all main-site phones, and all PSTN destinations to be reached with the same numbers as in standard mode.

During fallback, users should be able to dial main-site directory numbers as usual. Because these calls have to be routed over the PSTN during fallback, main-site extensions have to be translated to E.164 PSTN numbers at the PSTN gateway.

Most enterprises limit the range of destinations that can be reached from specific extensions by applying class of service (CoS) to the extensions. This limitation should still be valid during times in SRST mode by applying IOS class of restriction (COR), as described in the next chapter.

Ensuring Connectivity for Remote Sites

When SRST is active, you must take several measures to ensure connectivity from remote sites to PSTN destinations, between different sites, and inside the site itself.

To guarantee PSTN connectivity, dial peers with destination patterns corresponding to the PSTN access code have to be implemented. In H.323 or SIP gateways, these dial peers must be present for normal operation. When MGCP gateways are used, dial peers are activated by the MGCP-gateway-fallback mechanism. Interdigit timeout adopts open numbering plans that do not have a fixed number of digits.

Voice translation profiles that are applied to dial peers, the voice interface, or the voice port modify the calling party ID to enable callback from call lists.

For intrasite and intersite connectivity, voice translation profiles are configured to expand called numbers to PSTN format during fallback.

The Cisco IOS command dialplan-pattern in CallManager-Fallback configuration mode performs digit manipulation on the incoming called numbers to match the remote-site extensions. It ensures that internal extensions can be dialed even though the lines are configured with the site code and extension. The Line Text Label settings defined in CUCM are not applied to the SRST phones, so the complete DN applied to the line is visible to the user.

Ensuring Connectivity from the Main Site Using Call Forward Unregistered

During fallback, main-site users should still be able to call remote-site users by using their extension numbers, as shown in Figure 5-12.

Figure 5-12

Figure 5-12 Ensure Connectivity from the Main Site Using Call Forward Unregistered

CUCM considers the remotesite phones unregistered and cannot route calls to the affected IP Phone DNs. Therefore, if mainsite users dial internal extensions during the IP WAN outage, the calls fail or go to voice mail.

To allow remote IP Phones to be reached from mainsite IP Phones, Call Forward Unregistered (CFUR) can be configured for the remotesite phones. CFUR should be configured with the PSTN number of the remotesite gateway so that internal calls for remote IP Phones get forwarded to the appropriate PSTN number.

CFUR Considerations

CFUR was first implemented in CCM Release 4.2.

As mentioned earlier, the CFUR feature allows calls placed to a temporarily unregistered IP Phone to be rerouted to a configurable number. The configuration of CFUR has two main elements:

  • Destination selection: When the DN is unregistered, calls can be rerouted to voice mail or to the DN that was used to reach the IP Phone through the PSTN.
  • Calling Search Space (CSS): CUCM attempts to route the call to the configured destination number using the CFUR CSS of the directory number that was called. The CFUR CSS is configured on the target IP Phone and is used by all devices calling the unregistered IP Phone. This means that all calling devices use the same combination of route pattern, route list, route group, and gateway to place the call. In addition, all CFUR calls to a given unregistered device are routed through the same unique gateway, regardless of the location of the calling IP Phone. It is recommended that you select a centralized gateway as the egress point to the PSTN for CFUR calls and configure the CFUR CSS to route calls to the CFUR destination through this centralized gateway.

If an IP Phone is unregistered while the gateway that is associated with the direct inward dialing (DID) number of that phone is still under the control of CUCM, CFUR functionality can result in telephony routing loops. For example, if an IP Phone is simply disconnected from the network, the initial call to the phone would prompt the system to attempt a CFUR call to the DID of the phone through the PSTN. The resulting incoming PSTN call would in turn trigger another CFUR attempt to reach the directory number of the same phone, triggering yet another CFUR call from the central PSTN gateway through the PSTN. This cycle potentially could repeat itself until system resources are exhausted.

The CUCM service parameter Max Forward UnRegistered Hops to DN in the Clusterwide Parameters (Feature—Forward) section in CUCM Administration controls the maximum number of CFUR calls that are allowed for a directory number at one time. The default value of 0 means that the counter is disabled. If any DNs are configured to reroute CFUR calls through the PSTN, loop prevention is required. Configuring this service parameter to a value of 1 would stop CFUR attempts as soon as a single call was placed through the CFUR mechanism. This setting would also allow only one call to be forwarded to voice mail, if CFUR is so configured. Configuring this service parameter to a value of 2 would allow up to two simultaneous callers to reach the voice mail of a DN whose CFUR setting is configured for voice mail. It would also limit potential loops to two for DNs whose CFUR configuration sends calls through the PSTN.

CFUR Interaction with Globalized Call Routing

CFUR can benefit as follows from globalized call routing when a CUCM cluster serves multiple countries if a globalized number is used as a CFUR destination number:

  • CFUR calls are placed to global number.
  • Single route pattern (\+!) sufficient for all CFUR calls.
  • Same route pattern can be used for Automated Alternate Routing (AAR) and PSTN access.
  • Route pattern refers to single route list.
  • Route list includes only Standard Local Route Group.
  • CFUR CSS can be the same for all phones.

If globalized numbers are used as CFUR destinations, calls to unregistered phones (for example, phones that lost IP connectivity to CUCM and are in SRST mode) are using the only configured off-net route pattern \+! for CFUR. All calling devices will use the same route pattern, route list, and route group to place the call. This route pattern is a general off-net route pattern and is used for PSTN calls, AAR calls, and CFUR calls. The CFUR CSS can be the same for all phones, and the local gateway will be used for the CFUR call because local route groups are configured.

Without using local route groups, the CFUR CSS determines the gateway that is used for the CFUR call. The CFUR CSS of the phone that is unregistered is used—not the one of the phone that tries to reach the unregistered phone. This means that all callers use the same CFUR CSS when calling an unregistered phone (the CFUR CSS configured at the destination phone). Consequently, if callers are located at different sites, they will all use the same gateway for the CFUR call. Usually, the main site gateway is used for that purpose, which means that the CFUR CSS (applied to all phones) provides access to PSTN route patterns that use the main site gateway (via the referenced route list and route group). With local route groups, each caller can use its local gateway for CFUR calls; there is no need to use the IP WAN toward the main site and then break out to the PSTN with the CFUR call at the main site gateway. Depending on the deployment, this can be a huge improvement for reaching sites that lost IP connectivity to CUCM.

CFUR Example Without Globalized Call Routing

Figure 5-13 illustrates the call flow with CFUR without local route groups.

Figure 5-13

Figure 5-13 CFUR Example Without Globalized Call Routing

Three sites are in the figure: HQ, Site 1, and Site 2. The remote sites are backed up by SRST gateways. If IP connectivity between Site 1 and the HQ fails, Site 1 phones will failover to SRST mode. They can still call the HQ and Site 2 via the PSTN. When an HQ phone attempts to call a phone at Site 1 that is unregistered in CUCM, the call is placed to the CFUR destination configured at the Site 1 phone (915215553001 in this example). The CFUR CSS of the Site 1 phone ensures that route pattern 9.@ is used, which refers to how the HQ gateway is accessed. Therefore, the call is redirected to the PSTN number of the called phone and sent to the HQ gateway.

When a user at Site 2 attempts to call a phone at Site 1, the same thing happens. The CFUR destination 915215553001 is called using the CFUR CSS configured at the Site 1 phone and therefore matches the 9.@ route pattern that refers to the HQ gateway and not to a 9.@ route pattern referring to a Site 2 gateway. Therefore, the call uses the IP WAN to get from Site 2 to the HQ and, from there, it breaks out to the PSTN toward Site 1. If more sites existed, they would all use the HQ gateway for CFUR calls to Site 1. This can lead to suboptimal routing. In addition, different route patterns may be needed, depending on the destination of the CFUR call. In an international deployment, the CFUR destination number may be a mix of national and international numbers. Each destination number has to be specified in a way that it can be routed by the CFUR CSS. There is no common format for all CFUR destinations, in that some may be specified in national format and others in international format.

CFUR Example with Globalized Call Routing

Figure 5-14 shows the same scenario, but with globalized call routing.

Figure 5-14

Figure 5-14 CFUR Example With Globalized Call Routing

There is only a single \+! route pattern; the referenced route list has local route groups enabled. All phones use the same CFUR CSS, which provides access to the partition of the global route pattern. The egress gateway is selected by the local route group feature. Localization of the called number occurs at the egress gateway by global transformations. If a called is placed to an unregistered phone of Site 1, the CFUR destination +15215553001 is called using the single off-net route pattern, which is configured to use the local route group (in the referenced route list). Consequently, like any other PSTN call, CFUR calls use the local gateway instead of the HQ gateway, regardless of the caller's location. There is no need for all callers to use the same gateway for CFUR calls. In addition, all CFUR destination numbers are specified in a global format (E.164 with + prefix).

Keeping Calling Privileges Active in SRST Mode

Under normal conditions in multisite deployments with centralized call processing, calling privileges are implemented using partitions and CSSs within CUCM.

However, when IP WAN connectivity is lost between a branch site and the central site, Cisco Unified SRST takes control of the branch IP Phones, and the entire configuration that is related to partitions and CSSs is unavailable until IP WAN connectivity is restored. Therefore, it is desirable to implement CoSs within the branch router when running in SRST mode.

For this application, you must define CoSs in Cisco IOS routers using the COR functionality. You can adapt the COR functionality to replicate the CUCM concepts of partitions and CSSs by following these guidelines:

  • Named tags have to be defined for each type of call that you want to distinguish.
  • Outgoing COR lists containing a single tag each have to be assigned to the outgoing dial peers that should not be available to all users. These outgoing COR lists are equivalent to partitions in CUCM.
  • Incoming COR lists containing one or more tags have to be assigned to the directory numbers that belong to the various CoSs. Incoming COR lists are equivalent to CSSs in CUCM.

SRST Dial Plan Example

Call-routing components on Cisco IOS routers and CUCM are necessary before a dial plan will work in SRST mode, as shown in Figure 5-15.

Figure 5-15

Figure 5-15 Cisco Unified SRST Dial Plan Requirement Example

CFUR must be defined on the CUCM side. Configuring the Cisco IOS router is more complex when you use dial peers, COR, dial plan pattern, and voice translation profiles to define the simplified SRST dial plan. Note how this example lets you dial 9 to get out to all numbers on the PSTN from the remote sites but limits 900 calls with COR to align with the same restrictions set in CUCM.

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