Document ID: 82478 |
Introduction
This document provides information on how to troubleshoot when the Cisco CallManager Conference Bridge fails with the KEEPALIVE_FAILED error message. The conference bridge becomes unavailable for a potentially indefinite period of time until it is fixed.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on the Cisco CallManager 4.1(3) and Cisco 2800 Series Router that runs Cisco IOSĀ® Software Release 12.3.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Background Information
Hardware-enabled conferencing provides the ability to support voice conferences in hardware. Digital Signaling Processors (DSPs) convert multiple Voice over IP Media Streams into TDM streams that are mixed into a single conference call stream. The number of conferences supported depends on the number of DSPs available. So, if the conference bridges are not terminated properly, the DSPs cannot be reused. For more details about how to configure a conference bridge on an IOS gateway, refer to CallManager and IOS Gateway DSP Farm Configuration Example.
Conference Bridge Stuck in KEEPALIVE_FAILED State
If a Cisco CallManager becomes unreachable to the conference bridge it was registered to while a conference was active, the conference bridge ends up in the KEEPALIVE_FAILED state. The conference bridge also continues to send media signals, potentially over the WAN for a long time after all parties have left the conference and the DSP resources are not able to be reused for more conferences.
Solution
The KEEPALIVE_FAILED error is found because the conference bridge does not switch back to another CallManager that is available in the cluster. In order to solve this problem, you need to mention the switchover method to use in the gateway.
When the communication link between the active Cisco Unified CallManager and the Skinny Call Control Protocol (SCCP) client goes down, the SCCP client tries to connect to one of the secondary Cisco Unified CallManagers with the use of one of these switchover methods:
-
Graceful—The Cisco Unified CallManager switchover happens only after all the active sessions are terminated gracefully. This is the default method.
-
Immediate—Regardless of whether there is an active connection or not, the SCCP client switches over to one of the secondary Cisco Unified CallManagers immediately. If the SCCP Client is not able to connect to a secondary Cisco Unified CallManager, it continues to poll for a Cisco Unified CallManager connection.
-
The switchover method can be mentioned under the sccp ccm group configuration.
gateway(config)#sccp ccm group 1
gateway(config-sccp-ccm)#switchover method immediate
Note: If you have multiple profiles configured for conferencing in the dspfarm, use the switchover method as graceful.
-
In order to terminate the conference bridges that send media messages, the RTP message should timeout. This can be done when you change the receive RTP timer in the gateway configuration.
gateway(config)#gateway
gateway(config-gateway)#timer receive-rtp 180
The default timeout happens only after 1200 secs (20 minutes).
Cisco Support Community - Featured Conversations
Related Information
- Hardware Conference Bridge Configuration and Use with CallManager and a Catalyst 6000/6500 WS-X6608 Port
- Conference Bridge Configuration
- Voice Technology Support
- Voice and Unified Communications Product Support
-
Troubleshooting Cisco IP Telephony
- Technical Support & Documentation - Cisco Systems
| Updated: Mar 28, 2007 | Document ID: 82478 |
Feedback