Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

État du pont de conférence CallManager : KEEPALIVE_FAILED

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document fournit des informations sur la façon dont dépanner quand la passerelle de conférence de Cisco CallManager échoue avec le message d'erreur KEEPALIVE_FAILED. La passerelle de conférence devient indisponible pendant potentiellement une durée indéterminée de temps jusqu'à ce qu'elle soit réparée.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur le Cisco CallManager 4.1(3) et le routeur de gamme Cisco 2800 qui exécute la version de logiciel 12.3 de ½ du ¿  de Cisco IOSïÂ.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

les Conférences Matériel-activées fournissent la capacité de prendre en charge des conférences vocales dans le matériel. Les processeurs de signalisation de Digital (DSP) convertissent de plusieurs flux multimédias de voix sur ip en flots TDM qui sont mélangés dans un flot simple de conférence téléphonique. Le nombre de conférences prises en charge dépend du nombre de DSP disponibles. Ainsi, si les passerelles de conférence ne sont pas terminées correctement, les DSP ne peuvent pas être réutilisés. Pour plus de détails au sujet de la façon configurer une passerelle de conférence sur une passerelle IOS, référez-vous à l'exemple de configuration de ferme de CallManager et de passerelle IOS DSP.

Passerelle de conférence coincée dans l'état KEEPALIVE_FAILED

Si un Cisco CallManager devient inaccessible à la passerelle de conférence qu'il a été enregistré tandis qu'une conférence était en activité, la passerelle de conférence finit par dans l'état KEEPALIVE_FAILED. La passerelle de conférence continue également à envoyer des signaux de medias, potentiellement au-dessus des interlocuteurs de WAN pendant longtemps après tout ont laissé la conférence et les ressources DSP ne peuvent pas être réutilisé pour plus de conférences.

Solution

L'erreur KEEPALIVE_FAILED est trouvée parce que la passerelle de conférence ne commute pas de nouveau à un autre CallManager qui est disponible dans la batterie. Afin de résoudre ce problème, vous devez mentionner le switchover method pour utiliser dans la passerelle.

Quand la liaison de communication entre le Cisco Unified CallManager actif et le client de Protocole SCCP (Skinny Call Control Protocol) descend, les essais de client de SCCP à connecter à un des Cisco Unified CallManagers secondaires à l'utilisation d'un de ces switchovers method :

  • Gracieux — Le basculement de Cisco Unified CallManager se produit seulement après tout les sessions actives sont terminés avec élégance. C'est la méthode par défaut.

  • Immédiat — Indépendamment de, qu'il y ait une connexion active ou pas, les commutateurs client de SCCP plus d'à un des Cisco Unified CallManagers secondaires immédiatement. Si le client de SCCP ne peut pas se connecter à un Cisco Unified CallManager secondaire, il continue à voter pour une connexion de Cisco Unified CallManager.

  1. Le switchover method peut être mentionné sous la configuration de sccp ccm group.

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

    Remarque: Si vous avez de plusieurs profils configurés pour des Conférences dans le dspfarm, utilisez le switchover method comme gracieux.

  2. Afin de terminer les passerelles de conférence qui envoient des messages de medias, le message de RTP si le délai d'attente. Ceci peut être fait quand vous changez le temporisateur de RTP de réception en configuration de passerelle.

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

    Le délai d'attente par défaut se produit seulement après 1200 sec (20 minutes).


Informations connexes


Document ID: 82478