Upon completing this chapter, you will be able to describe the mechanisms for providing call survivability and device failover at remote sites, including the functions, operation, and limitations of each mechanism. You will be able to meet these objectives:
- Describe remote-site redundancy options and compare their characteristics
- Describe how Cisco Unified SRST works
- Describe how MGCP fallback works
- Describe SRST versions, their protocol support and features, and the required Cisco IOS Software release
- Describe dial plan requirements for MGCP fallback and SRST with the option of using CUCM Express
Remote-Site Redundancy Overview
Two different technologies are used to provide remote-site redundancy for small and medium remote sites in a Cisco Unified Communications Manager (CUCM) environment. Survivable Remote Site Telephony (SRST) and Media Gateway Control Protocol (MGCP) gateway fallback are the key components of delivering fail-safe communication services, as shown in Figure 5-1.
)
Figure 5-1 SRST and MGCP Fallback
CUCM supports Cisco Unified IP Phones at remote sites that are attached to Cisco multiservice routers across the WAN. Before Cisco Unified SRST, when the WAN connection between a router and the CUCM failed, or when connectivity with the CUCM was lost for any reason, Cisco Unified IP Phones on the network became unusable for the duration of the failure. The reason is that Cisco IP Phones demand Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) connectivity to a call-processing agent such as CUCM, and in the absence of signaling connectivity, the phones become fully unusable.
Cisco Unified SRST overcomes this problem and ensures that Cisco Unified IP Phones offer continuous, although reduced, service by providing call-handling support for Cisco Unified IP Phones directly from the Cisco Unified SRST router. The system automatically detects a failure and uses Simple Network-Enabled Auto-Provision (SNAP) technology to autoconfigure the branch office router to provide call processing for Cisco Unified IP Phones that are registered with the router. When the WAN link or connection to the primary CUCM subscriber is restored, call handling reverts to the primary CUCM.
MGCP gateway fallback is a mechanism that allows a Cisco IOS router to continue providing voice gateway functions, even when the MGCP call agent is not in control of the media gateway. These voice gateway functions are implemented through a fallback mechanism that activates the so-called default technology application. The gateway then works in the same way as a standalone H.323 or SIP gateway by using its configured dial peers.
Remote-Site Redundancy Technologies
Table 5-1 lists the capabilities of different remote-site redundancy technologies.
Table 5-1. Remote-Site Redundancy Technologies
|
MGCP Fallback |
Cisco Unified SRST |
|||
|
Cisco Unified SIP SRST |
Cisco Unified SIP SRST |
Cisco Unified Communications Manager Express in SRST Mode |
||
|
Provides redundancy for |
MGCP controlled gateways |
SCCP phones |
SIP phones |
SCCP phones |
|
Delivered service |
Fallback to Cisco IOS default technology |
Basic telephony service |
Basic SIP proxy service |
CUCM Express |
|
ISDN call preservation |
No |
Yes (no MGCP) |
Yes (no MGCP) |
Yes (no MGCP) |
|
Analog/CAS call preservation |
Yes |
Yes |
Yes |
Yes |
|
Maximum number of phones |
N/A |
1500 |
1500 |
450 |
To use SRST as your fallback mode on an MGCP gateway, SRST and MGCP fallback have to be configured on the same gateway.
Cisco Unified SIP SRST provides a basic set of features to SIP-based IP Phones. This set of Cisco Unified SRST basic features is also known as Cisco Unified SIP SRST. Cisco Unified SIP SRST must be enabled and configured separately on Cisco IOS routers.
Cisco Unified SIP SRST versions 3.3 and earlier provide a SIP Redirect Server function; in subsequent versions, this function acts as a back-to-back user agent (B2BUA).
CUCM Express in Cisco Unified SRST mode provides more features to a smaller maximum number of IP Phones by falling back to CUCM Express mode. The main feature enhancements include Presence, Cisco Extension Mobility, and support of local voice-mail integrations.
VoIP call preservation sustains connectivity for topologies in which signaling is managed by an entity (such as CUCM). For example, if an existing call is setup between two Cisco IP Phones with CUCM performing signaling, and CUCM goes down during the call, then the audio will stay connected since skinny has call preservation.
Call preservation is also useful when a gateway and the other endpoint (typically a Cisco Unified IP Phone) are colocated at the same site and the call agent is remote. In such a scenario, the call agent (the gateway with the remote endpoint) is more likely to experience connectivity failures.
CUCM Express version 8.0 supports a maximum of 450 IP Phones (Cisco IOS 3945E router), whereas Cisco Unified SRST version 8.0 supports up to 1500 IP Phones on the same platform. Refer to Cisco Unified Communications Manager Express 8.0, www.cisco.com/en/US/docs/voice_ip_comm/cucme/requirements/guide/cme80spc.htm, for more details.
SIP is an Internet standard discussed in many Request for Comments (RFC). If you want to supplement your knowledge of SIP, here is a good RFC to start with: www.ietf.org/rfc/rfc3261.txt.
MGCP Fallback Usage
A public switched telephone network (PSTN) gateway can use MGCP gateway fallback configured as an individual feature if H.323 or SIP is configured as a backup service. SRST and MGCP fallback must be configured on the same gateway with Cisco IOS Software Release 12.2(11)T or later if this single gateway will provide SRST fallback service to phones and MGCP gateway fallback.
Although MGCP gateway fallback is most often used with SRST to provide gateway functions to IP Phones in SRST mode, it can also be used as a standalone feature. For example, when a call using a T-1 channel-associated signaling (CAS) interface controlled by MGCP exists during a CUCM failure, connectivity to the PSTN or another private branch exchange (PBX) can be preserved by MGCP gateway fallback. An MGCP fallback standalone configuration can also be used to allow analog interfaces that are controlled by SCCP to stay in service even when the WAN connection to the CUCM is down.
MGCP gateway fallback preserves active calls from remote-site IP Phones to the PSTN when analog or CAS protocols are used. For ISDN protocols, call preservation is impossible because Layer 3 of the ISDN stack is disconnected from the MGCP call agent and is restarted on the local Cisco IOS gateway. This means that for active ISDN calls, all call-state information is lost in cases of switchover to fallback operation.
Basic Cisco Unified SRST Usage
Cisco Unified SRST provides CUCM with fallback support for Cisco Unified IP Phones that are attached to a Cisco router on a local network.
Cisco Unified SRST enables routers to provide basic call-handling support for Cisco Unified IP Phones when they lose connection to remote primary, secondary, and tertiary CUCM servers or when the WAN connection is down.
Cisco Unified SIP SRST Usage
Cisco Unified SIP SRST provides backup to an external SIP proxy server by providing basic registrar and redirect server services earlier than Cisco Unified SIP SRST version 3.4 or B2BUA for Cisco Unified SIP SRST version 3.4 and higher services.
A SIP phone uses these services when it is unable to communicate with its primary SIP proxy of CUCM in the event of a WAN connection outage.
Cisco Unified SIP SRST can support SIP phones with standard RFC 3261 feature support locally and across SIP WAN networks. With Cisco Unified SIP SRST, SIP phones can place calls across SIP networks in the same way that SCCP phones do.
Cisco Unified SIP SRST supports the following call combinations: SIP phone to SIP phone, SIP phone to PSTN or router voice port, SIP phone to SCCP phone, and SIP phone to WAN VoIP using SIP.
SIP proxy, registrar, and B2BUA servers are key components of a SIP VoIP network. These servers usually are located in the core of a VoIP network. If SIP phones located at remote sites at the edge of the VoIP network lose connectivity to the network core (because of a WAN outage), they may be unable to make or receive calls. Cisco Unified SIP SRST functionality on a SIP PSTN gateway provides service reliability for SIP-based IP Phones in the event of a WAN outage. Cisco Unified SIP SRST enables the SIP IP Phones to continue making and receiving calls to and from the PSTN. They also can continue making and receiving calls to and from other SIP IP Phones by using the dial peers configured on the router.
When the IP WAN is up, the SIP phone registers with the SIP proxy server and establishes a connection to the B2BUA SIP registrar (B2BUA router). But, any calls from the SIP phone go to the SIP proxy server through the WAN and out to the PSTN.
When the IP WAN fails or the SIP proxy server goes down, the call from the SIP phone cannot get to the SIP proxy server. Instead, it goes through the B2BUA router out to the PSTN.
Cisco Unified SRST does not support enhanced features, such as Presence or Cisco Extension Mobility. Message Waiting Indicator (MWI) is also not supported in fallback mode.
CUCME in SRST Mode Usage
CUCME in SRST mode enables routers to provide basic call-handling support for Cisco Unified IP Phones if they lose connection to remote primary, secondary, and tertiary CUCM installations or if the WAN connection is down.
When Cisco Unified SRST functionality is provided by CUCM Express, you can use automatic provisioning of phones like you do with standard Cisco Unified SRST. However, because of the wide feature support of CUCM Express, more features can be used compared to the standard Cisco Unified SRST.
Examples of features that are provided only by CUCM Express in SRST mode are Call Park, Presence, Cisco Extension Mobility, and access to Cisco Unity Voice Messaging services using SCCP.
These features, however, cannot be configured automatically when a phone falls back to SRST mode. If a certain feature is applicable to all phones or directory numbers (DN), the configuration can be applied by a corresponding template. If features have to be enabled on a per-phone (or per-DN) basis, they have to be statically configured.
Phones that do not require unique feature configuration can be configured automatically so that only those phones that require individual configuration have to be statically configured in CUCM Express.
Cisco Unified SRST Operation
Figure 5-2 illustrates the function of Cisco Unified SRST.
)
Figure 5-2 SRST Function in a Normal Situation
CUCM supports Cisco Unified IP Phones at remote sites attached to Cisco multiservice routers across the WAN. The remote-site IP Phones register with CUCM. Keepalive messages are exchanged between IP Phones and the central CUCM server across the WAN. CUCM at the main site handles the call processing for the branch IP Phones. Note that Cisco IP Phones cannot register SCCP or SIP through the PSTN to CUCM even if the PSTN is functional because SCCP and SIP must run over an IP network.
SRST Function of Switchover Signaling
When Cisco Unified IP Phones lose contact with CUCM, as shown in Figure 5-3, because of any kind of IP WAN failure, they register with the local Cisco Unified SRST router to sustain the call-processing capability that is necessary to place and receive calls.
)
Figure 5-3 Cisco Unified SRST Function of Switchover Signaling
Cisco Unified SRST configuration provides the IP Phones with the alternative call control destination of the Cisco Unified SRST gateway.
When the WAN link fails, the IP Phones lose contact with the central CUCM but then register with the local Cisco Unified SRST gateway.
The Cisco Unified SRST gateway detects newly registered IP Phones, queries these IP Phones for their configuration, and then autoconfigures itself. The Cisco Unified SRST gateway uses SNAP technology to autoconfigure the branch office router to provide call processing for Cisco Unified IP Phones that are registered with the router.
SRST Function of the Call Flow After Switchover
Cisco Unified SRST ensures that Cisco Unified IP Phones offer continuous service by providing call-handling support directly from the Cisco Unified SRST router using a basic set of call-handling features, as shown in Figure 5-4.
)
Figure 5-4 SRST Function of the Call Flow After Switchover
The Cisco Unified SRST gateway uses the local PSTN breakout with configured dial peers. Cisco Unified SRST features such as call preservation, autoprovisioning, and failover are supported.
During a WAN connection failure, when Cisco Unified SRST is enabled, Cisco Unified IP Phones display a message informing users that the phone is operating in CUCM fallback mode. This message can be adjusted.
While in CUCM fallback mode, Cisco Unified IP Phones continue sending keepalive messages in an attempt to reestablish a connection with the CUCM server at the main site.
SRST Function of Switchback
Figure 5-5 shows Cisco Unified IP Phones attempting to reestablish a connection over the WAN link with CUCM at the main site periodically when they are registered with a Cisco Unified SRST gateway.
)
Figure 5-5 SRST Function of Switchback
Cisco IP Phones, by default, wait up to 120 seconds before attempting to reestablish a connection to a remote CUCM.
When the WAN link or connection to the primary CUCM is restored, the Cisco Unified IP Phones reregister with their primary CUCM. Three switchback methods are available on the Cisco IOS router: immediate switchback, graceful switchback (after all outgoing calls on the gateway are completed), or switchback after a configured delay. When switchback is completed, call handling reverts to the primary CUCM, and SRST returns to standby mode. The phones then return to their full functionality provided by CUCM.
SRST Timing
Typically, a phone takes three times the keepalive period to discover that its connection to CUCM has failed. The default keepalive period is 30 seconds, as shown in Figure 5-6.
)
Figure 5-6 Cisco Unified SRST Timing
If the IP Phone has an active standby connection established with a Cisco Unified SRST router, the fallback process takes 10 to 20 seconds after the connection with CUCM is lost. An active standby connection to a Cisco Unified SRST router exists only if the phone has a single CUCM in its Cisco Unified CM group. Otherwise, the phone activates a standby connection to its secondary CUCM.
If a Cisco Unified IP Phone has multiple CUCM systems in its Cisco Unified CM group, the phone progresses through its list before attempting to connect with its local Cisco Unified SRST router. Therefore, the time that passes before the Cisco Unified IP Phone eventually establishes a connection with the Cisco Unified SRST router increases with each attempt to connect to a CUCM. Assuming that each attempt to connect to a CUCM takes about 1 minute, the Cisco Unified IP Phone in question could remain offline for 3 minutes or more following a WAN link failure. You can decrease this time by setting the keepalive timer to a smaller value. You can configure the keepalive timer using the CUCM service parameter Station Keepalive Interval.
While in SRST mode, Cisco Unified IP Phones periodically attempt to reestablish a connection with CUCM at the main site. The default time that Cisco Unified IP Phones wait before attempting to reestablish a connection to CUCM is 120 seconds.
MGCP Fallback Operation
MGCP gateway fallback, as shown in Figure 5-7, is a feature that improves the reliability of MGCP remote site networks. A WAN link connects the MGCP gateway at a remote site to the Cisco Communications Manager at a main site, which is the MGCP call agent. If the WAN link fails, the fallback feature keeps the gateway working as an H.323 or SIP gateway and rehomes to the MGCP call agent when the WAN link is active again. MGCP gateway fallback works in conjunction with the SRST feature.
)
Figure 5-7 MGCP Gateway Fallback in a Normal Situation
Cisco IOS gateways can maintain links to up to two backup CUCM servers in addition to a primary CUCM. This redundancy enables a voice gateway to switch over to a backup server if the gateway loses communication with the primary server. The secondary backup server takes control of the devices that are registered with the primary CUCM. The tertiary backup takes control of the registered devices if both the primary and secondary backup CUCM systems fail. The gateway preserves existing connections during a switchover to a backup CUCM server.
When the primary CUCM server becomes available again, control reverts to that server. Reverting to the primary server can occur in several ways: immediately, after a configurable amount of time, or only when all connected sessions are released.
MGCP Gateway Fallback During Switchover
The MGCP gateway performs a switchover to its default technology of H.323 or SIP, as shown in Figure 5-8, when the keepalives between CUCM and the Cisco MGCP gateway are missing.
)
Figure 5-8 MGCP Gateway Fallback During Switchover
The MGCP gateway fallback feature provides the following functionality:
- MGCP gateway fallback support: All active MGCP analog, E1 CAS, and T1 CAS calls are maintained during the fallback transition. Callers are unaware of the fallback transition, and the active MGCP calls are cleared only when the callers hang up. Active MGCP PRI backhaul calls are released during fallback. Any transient MGCP calls that are not in the connected state are cleared at the onset of the fallback transition and must be attempted again later.
- Basic connection services in fallback mode: Basic connection services are provided for IP telephony traffic that passes through the gateway. When the local MGCP gateway transitions into fallback mode, the default H.323 or SIP session application assumes responsibility for handling new calls. Only basic two-party voice calls are supported during the fallback period. When a user completes (hangs up) an active MGCP call, the MGCP application handles the on-hook event and clears all call resources.
MGCP Gateway Fallback During Switchback
The MGCP-gateway-fallback feature provides the rehome functionality to switch back to MGCP mode. As shown in Figure 5-9, the switchback or rehome mechanism is triggered by the reestablishment of the TCP connection between CUCM and the Cisco MGCP gateway.
)
Figure 5-9 MGCP Gateway Fallback During Switchback
Rehome function in gateway-fallback mode detects the restoration of a WAN TCP connection to any CUCM server. When the fallback mode is in effect, the affected MGCP gateway repeatedly tries to open a TCP connection to a CUCM server that is included in the prioritized list of call agents. This process continues until a CUCM server in the prioritized list responds. The TCP open request from the MGCP gateway is honored, and the gateway reverts to MGCP mode. The gateway sends a RestartInProgress (RSIP) message to begin registration with the responding CUCM.
All currently active calls that are initiated and set up during the fallback period are maintained by the default H.323 session application, except ISDN T1 and E1 PRI calls. Transient calls are released. After rehome occurs, the new CUCM assumes responsibility for controlling new IP telephony activity.
MGCP Gateway Fallback Process
The MGCP gateway maintains a remote connection to a centralized CUCM cluster, as shown in Figure 5-10, by sending MGCP keepalive messages to the CUCM server at 15-second intervals.
)
Figure 5-10 MGCP Gateway Fallback Process
If the active CUCM server fails to acknowledge receipt of the keepalive message within 30 seconds, the gateway attempts to switch over to the next available CUCM server.
If none of the CUCM servers responds, the gateway switches into fallback mode and reverts to the default H.323 or SIP session application for basic call control.
The gateway processes calls on its own using H.323 until one of the CUCM connections is restored. The same occurs if SIP is used instead of H.323 on the gateway.
Cisco Unified SRST Versions and Feature Support
Table 5-2 describes Cisco Unified SRST versions, their protocol support and features, and the required Cisco IOS Software release.
Table 5-2. Cisco Unified SRST Versions
|
Feature |
CUCM Express in SRST Mode |
Cisco Unified SRST 8.0 |
Cisco Unified SRST 7.2 |
Cisco Unified SRST 4.3 |
|
Minimum Cisco IOS Software Release |
12.3(11)XJ 15.0(1) for version 8.0 |
15.0(1)XA |
12.4(22)YB 15.0(1)M on ISR G2 |
12.4(11)XZ |
|
Presence |
|
|||
|
Extension Mobility |
|
|||
|
Eight active calls per line |
|
|
|
|
|
Support for E.164 numbers with + prefix |
|
|
|
|
|
Five additional MOH* streams (SCCP only) |
|
|
The version of the Cisco Unified SRST application depends on which release of the Cisco IOS Software is running on the router. Each Cisco IOS Software release implements a particular SRST version. You upgrade to a newer version of SRST through a Cisco IOS update into router flash. Recent Cisco IOS Software releases often have higher memory requirements than older ones, so make sure that you look into this before upgrading.
For detailed information about Cisco Unified SRST versions and their hardware and feature support, refer to the Cisco Unified Survivable Remote Site Telephony Version 8.0 data sheet at www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/data_sheet_c78-570481.html.
SRST 4.0 Platform Density
The maximum number of IP Phones and directory numbers supported by the Cisco Unified SRST 8.0 feature depends on which Cisco IOS router platform is used, as shown in Table 5-3.
Table 5-3. SRST 8.0 Platform Density
|
Platform |
Maximum Number of IP Phones |
|
800 Series |
4 |
|
1861 |
15 |
|
2801–2851 |
25–100 |
|
2901–2951 |
35–250 |
|
3825, 3845 |
350, 730 |
|
3925–3945E |
730–1500 |
Table 5-3 shows the maximum number of phones and DNs on phones that a Cisco Unified SRST router can accommodate For more details, such as minimum memory requirements, see Cisco Unified SRST 8.0 Supported Firmware, Platforms, Memory, and Voice Products at www.cisco.com/en/US/docs/voice_ip_comm/cusrst/requirements/guide/srs80spc.html.
Plus (+) Prefix and E.164 Support in Cisco Unified SRST
Cisco Unified SRST version 8.0 introduces support for DNs in E.164 format with a plus (+) prefix. SIP and SCCP IP phones can fallback to SRST and register with a DN in E.164 format with a + prefix. Assigning DNs in E.164 format ensures globally unique numbers; the + sign is prefixed in order to indicate that the number is in E.164 format.
Cisco Unified SRST and CUCM Express in SRST mode allow internal callers to use internal extensions for calling IP Phones that have numbers in E.164 format. A new dial plan pattern command has been introduced with Cisco Unified SRST v8.x to achieve the demotion of the E.164 number to the internally used shorter numbers. Although the standard dial plan pattern command expands to a longer PSTN format, for any DNs that are applied to phone lines, the new dial plan pattern command has the opposite function. In this case it allows internal callers to dial shorter, internally used extensions, which are expanded to the applied DNs in E.164 format. Outside callers dial the IP Phone directory numbers as configured—with a + prefix and the complete E.164 number. At the IP Phones, the calling-party number that is shown on the phone display can be transformed independently from the number that will be used for callback. This transformation is possible because of a newly introduced translation type in the voice translation profile, which is a translation rule of the callback number.
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 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 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 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 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 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.
Summary
The following key points were discussed in this chapter:
- MGCP fallback works in conjunction with SRST to provide telephony service to remote IP Phones during WAN failure.
- Making the Cisco IP Phone CUCM list shorter results in faster SRST switchover.
- The Cisco Unified SRST version is linked with the Cisco IOS Software release.
- The MGCP gateway fallback default application is H.323 or SIP.
- When SRST is active, several measures must be taken to ensure connectivity from remote sites to PSTN destinations, between different sites, and inside the site itself.
References
For additional information, refer to these resources:
- Cisco Systems, Inc. Cisco Unified Communications System 8.x SRND, April 2010. www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html.
- Cisco Systems, Inc. Cisco Unified Communications Manager Administration Guide Release 8.0(1), February 2010. www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_1/ccmcfg/bccm-801-cm.html.
- Cisco Systems, Inc. Cisco Unified Survivable Remote Site Telephony Version 8.0, November 2009. www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/data_sheet_c78-570481.html.
Review Questions
Use these questions to review what you've learned in this chapter. The answers appear in the Answers Appendix.
-
Which of the following CUCM and IOS gateway features provides failover for MGCP controlled gateways?
- MGCP SRST
- SRST fallback
- MGCP fallback
- MGCP in SRST mode
- MGCP failover
-
Which two show the correct numbers of supported phones in Cisco Unified SRST 8.0 for the given platform?
- 800: 24
- 2801–2851: 25-100
- 2901–2951: 400-800
- 3825, 3845: 350,730
-
What can you use to configure the dial plan at the remote-site gateway so that branch users can still reach the headquarters when dialing internal directory numbers during fallback?
- This is not possible. Users have to dial headquarters users by their E.164 PSTN number while in fallback mode.
- Translation profiles modifying the calling number.
- The dialplan-pattern command.
- Translation profiles modifying the called number.
- Although this is possible, it should be avoided, because it may confuse users.
-
Which two signaling protocols can be used on a remote gateway with MGCP fallback when in fallback mode?
- MGCP
- SCCP
- SIP
- H.323
- Megaco
- RTP
-
What IOS commands are used on a remote gateway configured with MGCP fallback to give PSTN access for IP Phones during fallback mode?
- This feature is unavailable. Remote phones can only dial each other.
- H.323 or SIP dial peers.
- Static routes.
- Dynamic dial peers.
- MGCP dial peers.
-
What protocol is used between the remote-office Cisco IP Phones and CUCM during fallback to send keepalives to CUCM for SRST?
- MGCP
- SCCP
- H.323
- OSPF hello packets
- EIGRP keepalives
-
What method maintains SIP connectivity from remote-office Cisco IP Phones to CUCM during a complete WAN failure?
- This is not possible. Remote-office Cisco IP Phones will fail over to the SRST remote-office router.
- SIP can be routed through the PSTN with POTS dial peers.
- SIP can be routed through the PSTN if the local exchange carrier enables SIP through the PSTN connection.
- SIP can be routed through the PSTN with POTS dial peers combined with the local exchange carrier, enabling SIP through the PSTN connection.
-
What are two requirements to have multiple MOH sources in SRST?
- This is not possible.
- SRST v8.x must be implemented.
- Configure MOH groups.
- Only use SIP phones.