Cisco Survivable Remote Site Telephony (SRST)
Cisco SRST Description
Cisco SRST provides Cisco CallManager with fallback support for Cisco IP phones that are attached to a Cisco router on your local network. Cisco SRST enables routers to provide call-handling support for Cisco IP phones when they lose connection to remote primary, secondary, or tertiary Cisco CallManager installations or when the WAN connection is down.
Cisco CallManager supports Cisco IP phones at remote sites attached to Cisco multiservice routers across the WAN. Prior to Cisco SRST, when the WAN connection between a router and the Cisco CallManager failed or when connectivity with Cisco CallManager was lost for some reason, Cisco IP phones on the network became unusable for the duration of the failure. Cisco SRST overcomes this problem and ensures that the Cisco IP phones offer continuous (although minimal) service by providing call-handling support for Cisco IP phones directly from the Cisco SRST router. The system automatically detects a failure and uses Simple Network Auto Provisioning (SNAP) technology to autoconfigure the branch office router to provide call processing for Cisco IP phones that are registered with the router. When the WAN link or connection to the primary Cisco CallManager is restored, call handling reverts back to the primary Cisco CallManager.
When Cisco IP phones lose contact with primary, secondary, and tertiary Cisco CallManagers, they must establish a connection to a local Cisco SRST router to sustain the call-processing capability necessary to place and receive calls. The Cisco IP phone retains the IP address of the local Cisco SRST router as a default router in the Network Configuration area of the Settings menu. The Settings menu supports a maximum of five default router entries; however, Cisco CallManager accommodates a maximum of three entries. When a secondary Cisco CallManager is not available on the network, the local Cisco SRST router's IP address is retained as the standby connection for Cisco CallManager during normal operation.
Note: Cisco CallManager fallback mode telephone service is available only to those Cisco IP phones that are supported by a Cisco SRST router. Other Cisco IP phones on the network remain out of service until they reestablish a connection with their primary, secondary, or tertiary Cisco CallManager.
Typically, it takes three times the keepalive period for a phone to discover that its connection to Cisco CallManager has failed. The default keepalive period is 30 seconds. If the phone has an active standby connection established with a Cisco SRST router, the fallback process takes 10 to 20 seconds after connection with Cisco CallManager is lost. An active standby connection to a Cisco SRST router exists only if the phone has the location of a single Cisco CallManager in its CallManager list. Otherwise, the phone activates a standby connection to its secondary Cisco CallManager.
Note: The time it takes for an IP phone to fallback to the SRST router can vary depending on the phone type. Phones such as the Cisco 7902, Cisco 7905, and Cisco 7912 can take approximately 2.5 minutes to fallback to SRST mode.
If a Cisco IP phone has multiple Cisco CallManagers in its CallManager list, it progresses through its list of secondary and tertiary Cisco CallManagers before attempting to connect with its local Cisco SRST router. Therefore, the time that passes before the Cisco IP phone eventually establishes a connection with the Cisco SRST router increases with each attempt to contact to a Cisco CallManager. Assuming that each attempt to connect to a Cisco CallManager takes about one minute, the Cisco IP phone in question could remain offline for three minutes or more following a WAN link failure.
Note: During a WAN connection failure, when Cisco SRST is enabled, Cisco IP phones display a message informing you that they are operating in Cisco CallManager fallback mode. The Cisco IP Phone 7960G and Cisco IP Phone 7940G display a "CM Fallback Service Operating" message, and the Cisco IP Phone 7910 displays a "CM Fallback Service" message when operating in Cisco CallManager fallback mode. When the Cisco CallManager is restored, the message goes away and full Cisco IP phone functionality is restored.
While in Cisco CallManager fallback mode, Cisco IP phones periodically attempt to reestablish a connection with Cisco CallManager at the central office. Generally the default time that Cisco IP phones wait before attempting to reestablish a connection to a remote Cisco CallManager is 120 seconds. The time can be changed in Cisco CallManager; see the "Device Pool Configuration Settings" chapter in the Cisco CallManager Administration Guide. A manual reboot can immediately reconnect Cisco IP phones to Cisco CallManager.
Once a connection is reestablished with Cisco CallManager, Cisco IP phones automatically cancel their registration with the Cisco SRST router. However, if a WAN link is unstable, Cisco IP phones can bounce between Cisco CallManager and Cisco SRST. A Cisco IP phone cannot reestablish a connection with the primary Cisco CallManager at the central office if it is currently engaged in an active call.
Figure 1 shows a branch office with several Cisco IP phones connected to a Cisco SRST router. The router provides connections to both a WAN link and the PSTN. The Cisco IP phones connect to their primary Cisco CallManager at the central office via this WAN link.
Figure 1 Branch Office Cisco IP Phones Connected to a Remote Central Cisco CallManager
Figure 2 shows the same branch office telephone network with the WAN connection down. In this situation, the Cisco IP phones use the Cisco SRST router as a fallback for their primary Cisco CallManager. The branch office Cisco IP phones are connected to the PSTN through the Cisco SRST router and are able to make and receive off-net calls.
Figure 2 Branch Office Cisco IP Phones Operating in SRST Mode
H.323 Gateways and SRST
On H.323 gateways, when the WAN link fails, active calls from Cisco IP phones to the PSTN are not maintained by default. Call preservation may work with the no h225 timeout keepalive command, but call preservation using the no h225 timeout keepalive command is not officially supported by Cisco Technical Support.
Under default configuration, the H.323 gateway maintains a keepalive signal with Cisco CallManager and terminates H.323-to-PSTN calls if the keepalive signal fails, for example if the WAN link fails. To disable this behavior and help preserve existing calls from local IP phones, you can use the no h225 timeout keepalive command. Disabling the keepalive mechanism only affects calls that will be torn down as a result of the loss of the H.225 keepalive signal.
MGCP Gateways and SRST
MGCP fallback is a different feature than SRST and, when configured as an individual feature, can be used by a PSTN gateway. To use SRST as your fallback mode on an MGCP gateway, SRST and MGCP fallback must both be configured on the same gateway. MGCP and SRST have had the capability to be configured on the same gateway since Cisco IOS Release 12.2(11)T.
To make outbound calls while in SRST mode on your MGCP gateway, two fallback commands must be configured on the MGCP gateway. These two commands allow SRST to assume control over the voice port and over call processing on the MGCP gateway. The two commands are ccm-manager fallback-mgcp and call application alternate. A complete configuration for these commands is shown in the "Enabling SRST on an MGCP Gateway" section.
Note: The commands listed above are ineffective unless both commands are configured. For instance, your configuration will not work if you only configure the ccm-manager fallback-mgcp command.
Enabling SRST on an MGCP Gateway
To use SRST as your fallback mode with an MGCP gateway, SRST and MGCP fallback must both be configured on the same gateway. The configuration below allows SRST to assume control over the voice port and over call processing on the MGCP gateway.
Note: The commands described in the configuration below are ineffective unless both commands are configured. For instance, your configuration will not work if you only configure the ccm-manager fallback-mgcp command.
SUMMARY STEPS
1. enable
2. configure terminal
3. ccm-manager fallback-mgcp
4. call application alternate [application-name]
5. exit
Cisco SRST provides Cisco CallManager with fallback support for Cisco IP phones that are attached to a Cisco router on your local network. Cisco SRST enables routers to provide call-handling support for Cisco IP phones when they lose connection to remote primary, secondary, or tertiary Cisco CallManager installations or when the WAN connection is down.
Cisco CallManager supports Cisco IP phones at remote sites attached to Cisco multiservice routers across the WAN. Prior to Cisco SRST, when the WAN connection between a router and the Cisco CallManager failed or when connectivity with Cisco CallManager was lost for some reason, Cisco IP phones on the network became unusable for the duration of the failure. Cisco SRST overcomes this problem and ensures that the Cisco IP phones offer continuous (although minimal) service by providing call-handling support for Cisco IP phones directly from the Cisco SRST router. The system automatically detects a failure and uses Simple Network Auto Provisioning (SNAP) technology to autoconfigure the branch office router to provide call processing for Cisco IP phones that are registered with the router. When the WAN link or connection to the primary Cisco CallManager is restored, call handling reverts back to the primary Cisco CallManager.
When Cisco IP phones lose contact with primary, secondary, and tertiary Cisco CallManagers, they must establish a connection to a local Cisco SRST router to sustain the call-processing capability necessary to place and receive calls. The Cisco IP phone retains the IP address of the local Cisco SRST router as a default router in the Network Configuration area of the Settings menu. The Settings menu supports a maximum of five default router entries; however, Cisco CallManager accommodates a maximum of three entries. When a secondary Cisco CallManager is not available on the network, the local Cisco SRST router's IP address is retained as the standby connection for Cisco CallManager during normal operation.
Note: Cisco CallManager fallback mode telephone service is available only to those Cisco IP phones that are supported by a Cisco SRST router. Other Cisco IP phones on the network remain out of service until they reestablish a connection with their primary, secondary, or tertiary Cisco CallManager.
Typically, it takes three times the keepalive period for a phone to discover that its connection to Cisco CallManager has failed. The default keepalive period is 30 seconds. If the phone has an active standby connection established with a Cisco SRST router, the fallback process takes 10 to 20 seconds after connection with Cisco CallManager is lost. An active standby connection to a Cisco SRST router exists only if the phone has the location of a single Cisco CallManager in its CallManager list. Otherwise, the phone activates a standby connection to its secondary Cisco CallManager.
Note: The time it takes for an IP phone to fallback to the SRST router can vary depending on the phone type. Phones such as the Cisco 7902, Cisco 7905, and Cisco 7912 can take approximately 2.5 minutes to fallback to SRST mode.
If a Cisco IP phone has multiple Cisco CallManagers in its CallManager list, it progresses through its list of secondary and tertiary Cisco CallManagers before attempting to connect with its local Cisco SRST router. Therefore, the time that passes before the Cisco IP phone eventually establishes a connection with the Cisco SRST router increases with each attempt to contact to a Cisco CallManager. Assuming that each attempt to connect to a Cisco CallManager takes about one minute, the Cisco IP phone in question could remain offline for three minutes or more following a WAN link failure.
Note: During a WAN connection failure, when Cisco SRST is enabled, Cisco IP phones display a message informing you that they are operating in Cisco CallManager fallback mode. The Cisco IP Phone 7960G and Cisco IP Phone 7940G display a "CM Fallback Service Operating" message, and the Cisco IP Phone 7910 displays a "CM Fallback Service" message when operating in Cisco CallManager fallback mode. When the Cisco CallManager is restored, the message goes away and full Cisco IP phone functionality is restored.
While in Cisco CallManager fallback mode, Cisco IP phones periodically attempt to reestablish a connection with Cisco CallManager at the central office. Generally the default time that Cisco IP phones wait before attempting to reestablish a connection to a remote Cisco CallManager is 120 seconds. The time can be changed in Cisco CallManager; see the "Device Pool Configuration Settings" chapter in the Cisco CallManager Administration Guide. A manual reboot can immediately reconnect Cisco IP phones to Cisco CallManager.
Once a connection is reestablished with Cisco CallManager, Cisco IP phones automatically cancel their registration with the Cisco SRST router. However, if a WAN link is unstable, Cisco IP phones can bounce between Cisco CallManager and Cisco SRST. A Cisco IP phone cannot reestablish a connection with the primary Cisco CallManager at the central office if it is currently engaged in an active call.
Figure 1 shows a branch office with several Cisco IP phones connected to a Cisco SRST router. The router provides connections to both a WAN link and the PSTN. The Cisco IP phones connect to their primary Cisco CallManager at the central office via this WAN link.
Figure 1 Branch Office Cisco IP Phones Connected to a Remote Central Cisco CallManager
Figure 2 shows the same branch office telephone network with the WAN connection down. In this situation, the Cisco IP phones use the Cisco SRST router as a fallback for their primary Cisco CallManager. The branch office Cisco IP phones are connected to the PSTN through the Cisco SRST router and are able to make and receive off-net calls.
Figure 2 Branch Office Cisco IP Phones Operating in SRST Mode
H.323 Gateways and SRST
On H.323 gateways, when the WAN link fails, active calls from Cisco IP phones to the PSTN are not maintained by default. Call preservation may work with the no h225 timeout keepalive command, but call preservation using the no h225 timeout keepalive command is not officially supported by Cisco Technical Support.
Under default configuration, the H.323 gateway maintains a keepalive signal with Cisco CallManager and terminates H.323-to-PSTN calls if the keepalive signal fails, for example if the WAN link fails. To disable this behavior and help preserve existing calls from local IP phones, you can use the no h225 timeout keepalive command. Disabling the keepalive mechanism only affects calls that will be torn down as a result of the loss of the H.225 keepalive signal.
MGCP Gateways and SRST
MGCP fallback is a different feature than SRST and, when configured as an individual feature, can be used by a PSTN gateway. To use SRST as your fallback mode on an MGCP gateway, SRST and MGCP fallback must both be configured on the same gateway. MGCP and SRST have had the capability to be configured on the same gateway since Cisco IOS Release 12.2(11)T.
To make outbound calls while in SRST mode on your MGCP gateway, two fallback commands must be configured on the MGCP gateway. These two commands allow SRST to assume control over the voice port and over call processing on the MGCP gateway. The two commands are ccm-manager fallback-mgcp and call application alternate. A complete configuration for these commands is shown in the "Enabling SRST on an MGCP Gateway" section.
Note: The commands listed above are ineffective unless both commands are configured. For instance, your configuration will not work if you only configure the ccm-manager fallback-mgcp command.
Enabling SRST on an MGCP Gateway
To use SRST as your fallback mode with an MGCP gateway, SRST and MGCP fallback must both be configured on the same gateway. The configuration below allows SRST to assume control over the voice port and over call processing on the MGCP gateway.
Note: The commands described in the configuration below are ineffective unless both commands are configured. For instance, your configuration will not work if you only configure the ccm-manager fallback-mgcp command.
SUMMARY STEPS
1. enable
2. configure terminal
3. ccm-manager fallback-mgcp
4. call application alternate [application-name]
5. exit
Comments