Overview
Stateful switchover provides protection for network edge devices with dual Route Processors (RPs) that represent a single point of failure in the network design, and where an outage might result in loss of service for customers.
In specific Cisco networking devices that support dual RPs, stateful switchover takes advantage of Route Processor redundancy to increase network availability. When two route processors (RPs) are installed, one RP acts as the active RP, and the other acts as a backup, or standby RP. Following an initial synchronization between the two processors if the active RP fails, or is manually taken down for maintenance or removed, the standby RP detects the failure and initiates a switchover. During a switchover, the standby RP assumes control of the router, connects with the network interfaces, and activates the local network management interface and system console. Stateful switchover dynamically maintains Route Processor state information between them.
The following conditions and restrictions apply to the current implementation of SSO:
-
Calls that are handled by nondefault session application (TCL/VXML) will not be checkpointed prebridge.
-
Flow-through calls whose state has not been accurately checkpointed will be cleared with media inactivity-based clean up. This condition could occur if active failure happens when:
-
Some check point data has not yet been sent to the standby.
-
The call leg was in the middle of a transaction.
-
Flow around calls whose state has not been accurately checkpointed (due to either of the reasons mentioned above) can be cleared with the clear call voice causecode command.
-
For more information about the Stateful Switchover feature and for detailed procedures for enabling this feature, see the "Configuring Stateful Switchover" chapter of the Cisco IOS High Availability Configuration Guide, Release 12.2SR.
Feature Information
|
Feature Name |
Releases |
Feature Information |
|---|---|---|
|
Stateful Switchover Between Redundancy Paired Intra or Inter-box Devices |
Baseline Functionality |
Provides protection for network edge devices with dual Route Processors (RPs) that represent a single point of failure in the network design, and where an outage might result in loss of service for customers. |
Call Escalation with Stateful Switchover
The call escalation workflow is as follows:
-
The call starts as an audio call between Phone A (video-capable) and Phone B (only audio-capable) registered to two different Cisco Unified Communications Manager (CUCM) clusters connected using Cisco Unified Border Element (CUBE).
-
The call is then transferred to Phone C, which is a video-capable phone.
-
The media parameters within the reinvite are renegotiated end-to-end.
-
The call is escalated to a video call.
 Note |
If the CUBE switchover happens at any instance, then audio calls will be preserved before escalation and video calls will be preserved after escalation. |
Call De-escalation with Stateful Switchover
The call de-escalation workflow is as follows:
-
The call starts as a video call between Phone A and Phone B registered to two different Cisco Unified Communications Manager (CUCM) clusters connected using Cisco Unified Border Element (CUBE).
-
The call is then transferred to Phone C, which is an audio-only phone.
-
The media parameters within the reinvite are renegotiated end-to-end.
-
The call is de-escalated to an audio-only call.
Note |
If the CUBE switchover happens at any instance, then video calls will be preserved before de-escalation and audio calls will be preserved after de-escalation. |
Media Forking with High Availability
Media forking with high availability is supported on ISR G2, ISR G3 and ASR platforms. When a primary call is connected and a forked call-leg is established on an active CUBE device, both the primary and the forked call-leg will be checkpointed in the standby CUBE device. If the active device goes down, the standby device ensures that the forking call is active and is able to exchange further transactions with the recording server with preserved calls such as hold/resume, transfer, conference, and so on. A recording server is a Session Initiation Protocol (SIP) user agent that archives media for extended durations, providing search and retrieval of the archived media. The recording server is a storage place of the recorded session metadata.
The active and standby devices must have the same configurations for checkpointing to happen correctly. The recorder can be configured both ways with a media profile and directly on a media class. The media profile can be associated under media class, and the media class can be applied to the incoming or outgoing dial-peer to start recording.
For more information, see the “Network-based Recording Using CUBE” module in the CUBE Protocol-Independent Features and Setup Configuration Guide.
Feedback