Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Estatus del Bridge de conferencia del CallManager: KEEPALIVE_FAILED

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (17 Abril 2008) | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento proporciona la información sobre cómo resolver problemas cuando el Bridge de conferencia del Cisco CallManager falla con el mensaje de error KEEPALIVE_FAILED. El Bridge de conferencia llega a ser inasequible por potencialmente un período indeterminado de tiempo hasta que se repare.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información en este documento se basa en el Cisco CallManager 4.1(3) y el Cisco 2800 Series Router que funciona con el Software Release 12.3 del ½ del ¿Â de Cisco IOSïÂ.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

la Conferencia Hardware-habilitada proporciona la capacidad de soportar las conferencias de la Voz en hardware. Los procesadores de la señalización digital (DSPs) convierten las secuencias de medios múltiples de la voz sobre IP en las secuencias TDM que son mezcladas en una sola secuencia de la llamada en conferencia. El número de conferencias soportadas depende del número de DSPs disponible. Así pues, si los Bridge de conferencia no se terminan correctamente, el DSPs no puede ser reutilizado. Para más detalles sobre cómo configurar un Bridge de conferencia en un gateway del IOS, refiera al ejemplo de configuración del dsp farm del CallManager y del gateway del IOS.

Bridge de conferencia pegado en el estado KEEPALIVE_FAILED

Si un Cisco CallManager llega a ser inalcanzable al Bridge de conferencia que fue registrado mientras que una conferencia era activa, el Bridge de conferencia termina para arriba en el estado KEEPALIVE_FAILED. El Bridge de conferencia también continúa enviando las señales de los media, potencialmente sobre los partidos de WAN después de todo han dejado durante mucho tiempo la conferencia y los recursos DSP no pueden ser reutilizado para más conferencias.

Solución

Se encuentra el error KEEPALIVE_FAILED porque el Bridge de conferencia no vuelve a otro CallManager que esté disponible en el cluster. Para solucionar este problema, usted necesita mencionar el método del intercambio para utilizar en el gateway.

Cuando va el link de comunicación entre el Cisco Unified CallManager activo y el cliente del Skinny Call Control Protocol (SCCP) abajo, el cliente SCCP intenta conectar con uno de los CallManageres unificados Cisco secundarios con el uso de uno de estos métodos del intercambio:

  • Agraciado — El intercambio del Cisco Unified CallManager sucede solamente después de todo las sesiones activas se termina agraciado. Éste es el método predeterminado.

  • Inmediato — Sin importar si hay una conexión activa o no, los cambios del cliente SCCP a uno de Cisco secundario unificaron los CallManageres inmediatamente. Si el cliente SCCP no puede conectar con un Cisco Unified CallManager secundario, continúa sondeando para una conexión del Cisco Unified CallManager.

  1. El método del intercambio se puede mencionar bajo configuración de grupo del ccm del sccp.

    gateway(config)#sccp ccm group 1
    
    gateway(config-sccp-ccm)#switchover method immediate
    

    Nota: Si usted tiene perfiles múltiples configurados para la Conferencia en el dspfarm, utilice el método del intercambio como agraciado.

  2. Para terminar los Bridge de conferencia que envían los mensajes de los media, el mensaje RTP si el descanso. Esto puede ser hecha cuando usted cambia el temporizador de la recepción RTP en la configuración de gateway.

    gateway(config)#gateway
    
    gateway(config-gateway)#timer receive-rtp 180
    

    El tiempo de espera predeterminado sucede solamente después de 1200 los secs (20 minutos).


Información Relacionada


Document ID: 82478