This chapter is from the book
This chapter is from the book
This chapter is from the book
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.