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

Guide de dépannage de la téléphonie IP Cisco pour Cisco CallManager version 3.0(x)

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce guide de dépannage décrit les outils et les utilitaires utilisés pour configurer, surveiller, et dépanner les passerelles de la version 3.0(1), du Cisco IOSÝ de Cisco CallManager et le garde-porte. Ce document fournit des exemples détaillés de trois écoulements différents d'appel, et des études de cas sont fournies d'expliquer plus loin des concepts.

Dans la première étude de cas, un téléphone IP de Cisco appelle un autre téléphone IP de Cisco dans une batterie (appel intra-cluster). Dans la deuxième étude de cas, un téléphone IP de Cisco fait appel par une passerelle de Cisco IOS à un téléphone connecté par des gens du pays PBX ou au réseau téléphonique public commuté (PSTN). Dans la troisième étude de cas, un téléphone IP de Cisco appelle un autre téléphone IP de Cisco dans une batterie différente (appel inter-cluster).

Une fois que vous comprenez l'écoulement d'appel et mettez au point des suivis, il sera plus facile d'isoler un problème et de déterminer quel composant pose le problème. Ce document décrit les outils disponibles pour dépanner des problèmes potentiels. Il décrit également comment les suivis et les sorties de débogage d'appel peuvent vous aider à comprendre des écoulements d'appel et des séries d'événements.

Au cas où vous devriez entrer en contact avec le centre d'assistance technique Cisco (TAC), plusieurs des outils expliqués ici seront instrumentaux en recueillant les données exigées par TAC. La résolution des problèmes sera plus rapide si vous avez déjà recueilli ces données avant d'appeler le TAC.

Conditions préalables

Conditions requises

Employez la liste de contrôle suivante pour être sûr que vous avez la documentation appropriée sur votre topologie du réseau.

  • Topologie qui affiche tous les périphériques et éléments essentiels de réseau avec les nombres de port/interface auxquels ils sont reliés et à quel VLAN ils appartiennent (si c'est approprié). Des désignations spéciales devraient être utilisées pour les ports qui sont dans la jonction ou le mode channeling.

  • La racine du spanning-tree devrait être configurée et tous les ports de normal-blocage devraient être identifiés.

  • Tous les circuits BLÊMES devraient être identifiés avec la quantité de bande passante (CIR dans le cas de Relais de trames).

Remarque: Le téléphone IP 7960 de Cisco a un port de réseau 10/100-switched et un port PC de 10/100. Cisco ne prend en charge pas les téléphones « montants en cascade » hors fonction du port PC. Nous ne recommandons pas relier le réseau et des ports PC à un commutateur (créant de ce fait une boucle physique dans le réseau).

N'importe quelle interface WAN exigera la considération spéciale, puisque c'est une source possible d'encombrement. Les Téléphones IP et les passerelles de Cisco placent le champ de priorité IP de flot de Protocole RTP (Real-Time Transport Protocol) à cinq, toutefois ceci étiquette seulement le paquet de RTP. Il incombe à l'administrateur réseau pour s'assurer que le réseau est configuré pour le contrôle d'admission de hiérarchisation et d'appel de sorte que le trafic de la voix sur ip (VoIP) puisse être entretenu avec le retard et le conflit minimaux pour des ressources. Pour des informations supplémentaires sur ce thème, référez-vous :

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans 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 vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Remarque: Toutes les discussions dans ce document sont écrites pour la version de Cisco CallManager 3.0(1), sauf indication contraire.

Conventions

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

Informations générales

Topologie

Vous devriez avoir une topologie du réseau précise contenant les ports auxquels de divers composants sont connectés, comme des VLAN, des Routeurs, des Commutateurs, des passerelles, et ainsi de suite. Une topologie bien documentée aide des problèmes de pour le dépannage avec le système. Soyez sûr que vous avez une topologie précise, avec l'accès à tous les périphériques et services de terminaux de réseau pour la Gestion du Cisco CallManager.

La planification significative est exigée afin d'ajouter avec succès la Téléphonie sur IP à un nouveau ou à un réseau existant. Puisque le trafic en temps réel a des demandes différentes que le trafic de données, le réseau doit être conçu avec la basse latence et le Qualité de service (QoS) à l'esprit. Comme avec n'importe quel réseau qui porte le trafic crucial, il est impératif que l'administrateur réseau mette à jour les diagrammes précis et détaillés de la topologie du réseau. Dans une situation de crise il est important de connaître pas simplement le large panorama du réseau, mais également que des ports sont connecté aux parties du réseau (Routeurs, Commutateurs, serveurs Cisco CallManagers, passerelles, et d'autres périphériques essentiels). Il est important de prévoir le réseau avec la Redondance et l'évolutivité à l'esprit.

attention Attention : Cisco ne prend en charge pas l'utilisation des Concentrateurs pour la Connectivité partagée aux Commutateurs. Les Concentrateurs peuvent gêner l'exécution correcte du système de téléphonie IP.

En fonctionnant avec des réseaux commutés, il est essentiel que vous connaissiez l'état du spanning-tree (pour la Redondance). L'état du réseau devrait être documenté avant que n'importe quelle panne se produise.

Glossaire

Le tableau ci-dessous présente quelques termes et acronymes communs qui peuvent être utilisés dans ce document.

Glossaire
Acronyme/terme Définition
.cnf Fichier de configuration utilisé par des périphériques.
Ý-loi (« MU-loi ») Technique de compression-extension utilisée généralement en Amérique du Nord. la Ý-loi est normalisée comme codec 64-kbps dans ITU-T G.711.
A-law Norme de compression-extension ITU-T utilisée dans la conversion entre l'analogue et les signaux numériques dans des systèmes de la modulation par impulsions et codage (PCM). L'a-law est utilisé principalement dans les réseaux téléphoniques européens et est semblable à la norme nord-américaine de Ý-loi.
ACF L'admission confirment.
ANI Le numéro d'appel.
ARQ Demande d'admission.
Canal B Canal de support. Dans le RNIS, c'est un bidirectionnel simultané, le canal 64-kbps utilisé pour envoyer des données d'utilisateur.
J'appelle l'espace de recherche L'espace de recherche appelant définit que les nombres et l'artère de répertoire modèle un périphérique indiqué peuvent appeler. C'est un groupement des partitions par lesquelles pour regarder en faisant un appel. Par exemple, supposez qu'il y a plusieurs partitions dans un espace de recherche appelant qui sont nommées « cadre. » Dans cet exemple, un numéro de téléphone IP de Cisco est dans le « cadre » appelle l'espace de recherche. En initiant un appel, les recherches de numéro de téléphone IP de Cisco par le « NYInternationalCall, » « NYLongDistance », « NYLocalCall, » et partitions disponibles de "NY911". On pourrait seulement permettre à un un numéro de téléphone IP de Cisco qui a un « invité » appelle l'espace de recherche, par exemple, pour le rechercher par le « NYLocalCall » et des partitions de "NY911". Par conséquent, si l'utilisateur essaye de composer un numéro international, le nombre ne trouvera pas une correspondance et l'appel ne sera pas conduit.
CCAPi API de contrôle d'appel. Utilisé par le Cisco IOS pour manipuler le Traitement des appels VoIP.
CCO Cisco Connection Online (http://www.cisco.com). Fournit les dernières informations sur des Produits Cisco, des informations de support technique, et la documentation technique.
CDR Article mouvement d'appel. Fournit des informations au sujet d'initialisation d'appel, de destination, et de durée. Ceci est utilisé pour créer des enregistrements de facturation.
Cisco IOS Logiciel système de Cisco qui fournit la fonctionnalité, l'évolutivité, et la Sécurité communes pour tous les Produits sous l'architecture de CiscoFusion. Le Cisco IOS tient compte installation et Gestion des interréseaux, tout en assurant support d'une grande variété de protocoles, medias, services, et Plateformes centralisés, intégrés, et automatisés.
Batterie Batterie de Cisco CallManager. Un groupement logique de plusieurs serveurs Cisco CallManagers.
CMR Enregistrements de programme de maintenance, également connus sous le nom de diagnostic CDR. Ce sont des enregistrements qui contiennent le compte d'octets envoyés, des paquets envoyés, jitter, latence, les paquets relâchés, et ainsi de suite.
codecs Codeur-décodeur. Un algorithme de logiciel de la partie spécifique au domaine (DSP) utilisé pour compresser/décompressent la parole ou des signaux audios.
Canal D Voie de transmission de données. Canal bidirectionnel simultané, 16-kbps (BRI) ou 64-kbps (PRI) le RNIS. Utilisé pour la signalisation et le contrôle.
DCF Le désengagement confirment.
DHCP Protocole DHCP. Fournit un mécanisme pour allouer des adresses IP dynamiquement de sorte que des adresses puissent être réutilisées quand les hôtes n'ont besoin plus de elles.
DN Nombre de répertoire. C'est le numéro de téléphone d'un périphérique d'extrémité. Ce peut être un nombre assigné à un téléphone IP de Cisco, à un Cisco IP SoftPhone, au télécopieur, ou au téléphone analogique relié à une passerelle. Les exemples incluent 1000 et 24231.
DNIS Service d'identification du numéro composé.
DN Système de noms de domaine. C'est le système utilisé en Internet pour traduire des noms des Noeuds de réseau dans des adresses.
DRQ Demande de désengagement.
DTMF Double tonalité multifréquence. C'est l'utilisation de deux tonalités simultanées de bande accoustique pour composer (telle que par boutons-poussoirs).
Écoulement Un flux de données voyageant entre deux points finaux à travers un réseau (d'une station de RÉSEAU LOCAL à l'autre, par exemple). De plusieurs écoulements peuvent être transmis sur un circuit simple.
Bidirectionnel simultané La capacité pour la transmission de données simultanée d'une station émettrice et d'une station de réception.
G.711 Décrit la technique de codage de Voix PCM 64-kbps. Dans G.711, la voix encodée est déjà dans le format correct pour la livraison de voix numérique dans le PSTN ou par des PBX. Ceci est décrit dans la norme ITU-T dans ses recommandation de la série G.
G.729 Décrit le compactage de la prédiction linéaire excité par code (CELP) où la Voix est codée dans les flots 8-kbps. Il y a deux variations de cette norme (G.729 et G.729 annexe A) qui diffèrent principalement dans la complexité de calcul ; chacun des deux fournissent la qualité de la parole semblable à la modulation par impulsions et codage différentiel 32-kbps (ADPCM). Ceci est décrit dans la norme ITU-T dans ses recommandation de la série G.
H.225 Une norme ITU qui régit l'établissement de session H.225 et le packetization. H.225 décrit réellement plusieurs différents protocoles : RAS, l'utilisation de Q.931, et l'utilisation du RTP.
H.245 Une norme ITU qui régit le contrôle de point final H.245.
H.323 Une extension d'ITU-T H.320 standard qui active la Vidéoconférence au-dessus des réseaux locaux et d'autres réseaux de commutation de paquets, aussi bien que vidéo sur Internet.
Semi duplex La capacité pour la transmission de données dans seulement une direction à la fois entre une station émettrice et une station de réception. La communication binaire synchrone (BSC) est un exemple d'un protocole bidirectionnel-alterné.
Hookflash Une période avec combiné raccroché courte, habituellement générée par un périphérique comme un téléphone pendant un appel, pour indiquer que le téléphone tente d'exécuter un rappel de tonalité d'un PBX. Hookflash est employé souvent pour exécuter le transfert d'appel.
ICCP Control Protocol d'Intra-batterie
LE RNIS Integrated Services Digital Network. Un protocole de communication, offert par des opérateurs téléphoniques, qui permet à des réseaux téléphoniques pour porter des données, expriment, et l'autre trafic source.
Jitter La variation des heures d'arrivée des paquets vocaux.
MGCP Protocole de contrôle de passerelle multimédia. Un protocole pour que le Cisco CallManager contrôle des passerelles VoIP (points finaux MGCP).
MTP Media Termination Point.
Partition Une partition est un groupement logique des nombres de répertoire (DN) et des modèles d'artère avec les caractéristiques semblables d'accessibilité. Pour la simplicité, ceux-ci sont habituellement nommés pour leur caractéristique, telle que « NYLongDistance », "NY911", et ainsi de suite. Quand un modèle de DN ou d'artère est placé dans une certaine partition, ceci crée une règle pour qui peut appeler ce périphérique ou liste de routage.
PBX Autocommutateur privé. Digital ou standard téléphonique analogique situé sur les sites d'abonné et utilisé pour connecter privé et des réseaux publics de téléphonie.
PRI Accès primaire. L'accès de débit primaire se compose d'un canal D 64-Kbps simple plus 23 (t1) ou 30 (E1) canaux B pour la Voix ou les données.
PSTN Réseau téléphonique public commuté. Condition générale se rapportant à la variété de réseaux téléphoniques et de services en place dans le monde entier.
Q.931 Norme ITU qui décrit la signalisation RNIS. La norme H.225.0 emploie une variante de Q.931 pour établir et déconnecter H.323 des sessions.
RAS Protocole d'enregistrement, d'admission, et d'état. C'est le protocole utilisé dans H.323 la suite de protocole pour découvrir et interagir avec un garde-porte.
Filtre d'artère Un filtre d'artère peut être utilisé non seulement pour limiter la composition, mais pour identifier également un sous-ensemble d'un modèle de masque (en utilisant @ le masque dans le plan de numérotation nord-américain). Par exemple, il pourrait être utilisé pour bloquer la composition de 900 codes postaux. Dans la boîte également soyez utilisé en même temps que des partitions et les espaces de recherche de appeler pour installer des règles complexes. Par exemple, supposez que vous faites établir trois groupes d'utilisateurs : Cadre, personnel, et invité. Un filtre d'artère peut laisser le groupe d'utilisateurs exécutif pour composer les numéros internationaux, le groupe d'utilisateurs de personnel pour composer des numéros locaux ou des appels longue distance, et le groupe d'utilisateurs d'invité pour composer seulement 911, et 800 les numéros de numéros locaux.
Groupe d'artère Un groupe d'artère est une liste d'un ou plusieurs passerelles ou ports sur les passerelles qui sont vues comme à égalité d'accès. Il est analogue à un groupe de joncteur réseau en terminologie traditionnelle PBX. Par exemple, vous pouvez avoir deux circuits PRI au même transporteur qui peut être utilisé arbitrairement. Une passerelle (ou un port particulier sur une passerelle) peut seulement être ajoutée à un groupe d'artère.
Liste de routage Le point d'acheminement autrefois appelé, la liste de routage permet au Cisco CallManager pour chasser par une liste de groupes d'artère dans un ordre de préférence configuré. Les plusieurs listes de routage peuvent indiquer les mêmes groupes d'artère.
Modèle d'artère Un nombre spécifique ou, généralement, une plage des nombres composés qui seront utilisés pour conduire des appels à un périphérique (tel qu'une passerelle de Cisco Access DT-24+ ou un routeur capable de gérer la voix) ou indirectement par l'intermédiaire d'une liste de routage. Par exemple, 1XXX signifie 1000 à 1999. Le « x » dans 1XXX signifie un chiffre unique ; un masque. Il y a d'autres tels masques (comme @. ! , et ainsi de suite). Un modèle d'artère ne doit pas être seul dans une partition tant que le filtre d'artère est différent.
RRJ Anomalie d'enregistrement.
RTP Real-Time Transport Protocol, un des protocoles d'IPv6. Le RTP est conçu pour fournir des fonctions de transport de réseau de bout en bout pour des applications transmettant des données en temps réel, telles que l'audio, le vidéo, ou les données de simulation, au-dessus des services réseau de Multidiffusion ou d'Unicast. Le RTP fournit des services tels que l'identification du type de charge utile, la numérotation d'ordre, le temps emboutissant, et la livraison surveillant aux applications en temps réel.
SEPT Téléphone d'Ethernets de Selsius. Cet acronyme précède des adresses MAC sur des Téléphones IP de Cisco, et représente un seul identifiant de périphérique.
Suppression de silence (détection d'activation de Voix) La suppression de silence permet à un téléphone IP de Cisco pour détecter l'absence de son et donc ne transmet pas des paquets au-dessus du réseau. La qualité de son peut être légèrement dégradée mais la connexion peut également utiliser moins de bande passante. La suppression de silence est désactivée par défaut.
SNMP Protocole SNMP. Le protocole de gestion de réseau est utilisé presque exclusivement dans les réseaux TCP/IP. Le SNMP fournit des moyens de surveiller et contrôler des périphériques de réseau, et de gérer les configurations, la collecte de statistiques, la représentation, et la Sécurité.
SQL SQL. Langage de norme internationale pour définir et accéder à des bases de données relationnelles.
T1/CAS Le t1 est un service de porteuse de réseau étendu numérique, transmettant des données DS-1-formatted à 1.544 Mbits/s par le réseau de commutation téléphonique, utilisant le codage AMI ou B8ZS. CAS est une interface de canal de signalisation associé.
T1/PRI Le t1 est un service de porteuse de réseau étendu numérique, transmettant des données DS-1-formatted à 1.544 Mbits/s par le réseau de commutation téléphonique, utilisant le codage AMI ou B8ZS. Le PRI est accès primaire. L'accès de débit primaire se compose d'un canal D 64-Kbps simple plus 23 (t1) ou 30 (E1) canaux B pour la Voix ou les données.
TCP Transmission Control Protocol. C'est le protocole de la couche transport connecté qui fournit fiable, transmission de données en full-duplex. Le TCP fait partie de la pile de protocoles TCP/IP.
TFTP Trivial File Transfer Protocol. Version simplifiée de FTP qui permet des fichiers à transférer à partir d'un ordinateur à l'autre au-dessus d'un réseau.
Modèle de traduction Utilisé pour se traduire appelé (DNIS) et demandant les numéros automatiques d'identification du numéro (ANI) avant de conduire l'appel. Par exemple, un appel peut entrer à un ensemble de nombres (919 392-3XXX) ce besoin d'être traduit à un ensemble de Téléphones IP de Cisco qui sont de l'ordre de 2XXX. Le Cisco CallManager a un modèle de traduction installé pour 919 392-3XXX. Ce modèle traduit les 919 392-3 principal simplement à 2, tout en laissant les autres chiffres intacts. Alors l'appel est conduit au téléphone IP approprié de Cisco. Des modèles de traduction sont utilisés seulement pour des vraies traductions et ne devraient pas être utilisés pour le découpage et préfixage de chiffres.
UDP User Datagram Protocol. C'est un protocole de la couche transport sans connexion dans la pile de protocoles TCP/IP. L'UDP est un protocole simple qui permute des datagrammes sans accusés de réception ou distribution garantie, exigeant que le traitement des erreurs et la retransmission soient traités par d'autres protocoles. L'UDP est défini dans RFC 768.
Détection d'activation de Voix (suppression de silence) La détection d'activation de Voix permet à un téléphone IP de Cisco pour détecter l'absence de son et donc ne transmet pas des paquets au-dessus du réseau. La qualité de son peut être légèrement dégradée mais la connexion peut également utiliser moins de bande passante. La suppression VAD/Silence est désactivée par défaut.
VoIP Voix sur ip.
VLAN RÉSEAU LOCAL virtuel. Un groupe de périphériques sur un ou plusieurs réseaux locaux qui sont configurés (utilisant le logiciel de gestion) de sorte qu'ils puissent communiquer comme si ils ont été reliés au même fil, quand en fait ils se trouvent sur un certain nombre de différents segments de RÉSEAU LOCAL. Puisque des VLAN sont basés sur logique au lieu des connexions physiques, ils sont extrêmement flexibles.

Outils et utilitaires pour surveiller et dépanner le Cisco CallManager

Cette section adresse les outils et les utilitaires pour configurer, surveiller et dépanner le Cisco CallManager.

Petits groupes de Cisco CallManager Administration

Le Cisco CallManager Administration fournit les informations de version pour le système, la base de données, et d'autres composants. À la page d'ouverture, cliquez sur en fonction les détails boutonnent et notent les versions en service.

ccm_admin.gif

Une explication plus détaillée de Cisco CallManager Administration est disponible dans la documentation en ligne de Cisco CallManager.

Microsoft Performance

La représentation (moniteur) est un serveur d'application de Windows 2000 qui peut afficher les activités et le statut de votre système Cisco CallManager. Il signale les informations générales et spécifiques en temps réel. Vous pouvez employer la représentation de Windows 2000 pour collecter et des statistiques de système d'affichage et de périphérique pour n'importe quelle installation de Cisco CallManager. Cet outil d'administration te permet pour gagner une pleine compréhension d'un système sans étudier l'exécution de chacun de ses composants.

Vous pouvez employer la représentation pour surveiller un grand choix de variables système en temps réel. Après avoir ajouté les paramètres de Cisco CallManager, vous pouvez définir les termes sous lesquels le Cisco CallManager affichera des statistiques générées par le système. Par exemple, vous pouvez surveiller le nombre d'appels en cours à tout moment, ou le nombre d'appels traversant actuellement une passerelle spécifique. La représentation affiche les informations d'état de général et de CallManager-particularité de Cisco en temps réel.

/image/gif/paws/30266/ms_perf.gif

Ouvrir la Microsoft Performance

Pour ouvrir la représentation sur le Cisco CallManager courant PC de serveur, début de clic > configurations > panneau de configuration > outils d'administration > représentation.

Personnaliser la représentation

Le moniteur de performances doit être personnalisé pour visualiser les paramètres liés au CallManager de Cisco que vous souhaitez surveiller. Choisissez l'objet, compteur, et citez-vous veulent inclure. Référez-vous à l'utilité à distance de configuration pour le Cisco CallManager, version 3.0 pour des instructions sur la façon dont utiliser des objets et des compteurs pour personnaliser la Microsoft Performance pour des exécutions de Cisco CallManager.

Microsoft Event Viewer

Microsoft Event Viewer est une application serveuse windows nt qui système d'affichage, Sécurité, et événements d'application (Cisco CallManager y compris) pour le serveur windows nt. Si un service (TFTP y compris) ne peut pas lire la base de données (où il obtient la configuration de suivi), il ajoutera des erreurs au visualisateur d'événements. Le visualisateur d'événements est le seul endroit où ces types d'erreurs apparaîtront. L'illustration suivante affiche les journaux d'application s'exécutant sur un serveur windows nt.

ms_event_viewer.gif

Ouvrir le visualisateur d'événements

Pour ouvrir la manifestation ouvrez une session le Cisco CallManager courant PC de serveur, début de clic > configurations > panneau de configuration > Administrative Tools > Event Viewer. Le visualisateur d'événements fournit des journaux des erreurs pour le système, la Sécurité, et les applications. Les erreurs de Cisco CallManager sont enregistré sous le journal d'application.

Les informations détaillées au sujet des événements

Vous pouvez double-cliquer un événement dans le log pour apprendre plus d'informations sur l'événement.

/image/gif/paws/30266/event_prop.gif

Suivi de SDI

Les suivis de SDI sont les fichiers journal locaux. L'adresse IP, le traitement de TCP, le nom du périphérique, ou le groupe date/heure peuvent être utilisés en passant en revue le suivi de SDI pour surveiller l'occurrence ou la disposition d'une demande. Ce nom du périphérique pourrait être dépisté de nouveau au bâtiment du fichier, qui affiche le Pool d'appareils et le modèle. Le Pool d'appareils et le modèle peuvent être dépistés de nouveau au bâtiment du prototype de fichier de configuration, qui répertoriera l'adresse réseau du Cisco CallManager et du port de connexion TCP.

Quand observer le SDI trace, note que la classe de C++ et les noms courants sont inclus avec la plupart des lignes de suivi. La plupart des routines associées avec le service d'une demande particulière incluent l'ID de thread dans un format standard.

Des suivis de SDI seront expliqués en détail dans les études de cas.

Informations de suivi de SDI

Les suivis de SDI génèrent des fichiers (par exemple, CCM000000000) des suivis de cette mémoire des activités de Cisco CallManager. Ces suivis fournissent des informations au sujet du processus d'initialisation de Cisco CallManager, de la procédure d'enregistrement, du processus de keepalive, de l'écoulement d'appel, de l'analyse de chiffre, et des périphériques relatifs tels que des Téléphones IP, des passerelles, des garde-portes, et plus de Cisco. Ces informations peuvent vous aider à isoler le Cisco CallManager de pour le dépannage de problèmes. Pour dépister correctement les informations que vous avez besoin et seulement les informations vous avez besoin, il sont importantes pour comprendre comment placer les options sur l'interface de configuration de suivi.

Les fichiers de suivi sont enregistrés dans l'emplacement par défaut suivant : C:\Program Files\cisco\bin. Un nouveau fichier de suivi est commencé chaque fois que des reprises de Cisco CallManager, ou quand le nombre de lignes indiqué a été atteint.

Être suit une illustration de l'interface de configuration de suivi de Cisco CallManager Administration. Vous devez activer le suivi, choisir le niveau sur les informations requises, et vérifier le masque d'utilisateur pour obtenir le niveau désiré des informations.

/image/gif/paws/30266/trace_config.gif

Si le suivi n'est pas configuré correctement, il génèrera un grand nombre d'informations le rendant très difficile d'isoler des problèmes. La section suivante explique comment configurer correctement un suivi utile.

Configurer des suivis

Des suivis se composent d'indicateurs de masque d'utilisateur (également connus sous le nom de bits) et de niveaux de suivi. Ouvrez le Cisco CallManager Administration. Pour activer le suivi, placez vos paramètres de suivi (service configuré y compris, bits, et ainsi de suite) dans l'écran de service > de suivi. Référez-vous au guide de Cisco CallManager Administration, libérez 3.0(1) pour des informations complètes sur tourner la découverte en marche et en arrêt, et pour des descriptions des masques d'utilisateur et des niveaux pour chaque service configuré, et davantage.

Être suivent deux exemples des bits de masque de suivi qui seraient activés ont basé sur le problème particulier.

  • Pour l'élimination des imperfections normale de message, activez les bits de sous-système 5, 6, 7, 8, 11, et 12

  • Pour des passerelles de débogage, activez les bits de sous-système 3, 4, 5, 6, 7, 8, 9, 11, 12, et 13

Être suivent deux exemples des niveaux de suivi désirés basés sur le problème particulier

  • Pour l'élimination des imperfections normale, le niveau de suivi devrait être placé à SDI_LEVEL_ARBITRARY

  • Pour le système d'exécution normale, le niveau de suivi devrait être placé à SDI_LEVEL_ERROR

Suivi SDL

Les ingénieurs de Cisco emploient des suivis SDL pour trouver la cause d'une erreur. On ne s'attend pas à ce que vous comprenniez entièrement les informations contenues dans un suivi SDL. Cependant, tout en fonctionnant avec le TAC, vous pouvez être invité à activer le suivi SDL et au fournir au TAC. Des fichiers de suivi SDL peuvent être enregistrés aux répertoires locaux, au visualisateur d'événements de Windows NT, et aux CiscoWorks 2000. Pour éviter n'importe quelle dégradation de représentation sur le serveur, soyez sûr que vous arrêtez le suivi SDL après que le suivi ait été capturé.

Le suivi SDL fournit l'interface courant alternatif pour tracer et les alarmes. Des alarmes sont utilisées pour informer l'administrateur des événements inattendus, tels que ne pouvoir pas accéder à un fichier, une base de données, un Winsock, ou ne pouvoir pas allouer d'autres ressources du système d'exploitation.

Activation du suivi SDL

Des suivis SDL sont activés dans la région de service > de paramètre de service au Cisco CallManager Administration. Souvenez-vous que ces suivis devraient être activés seulement une fois demandés par un ingénieur TAC. Notez les valeurs choisies pour activer le suivi SDL dans l'illustration suivante.

/image/gif/paws/30266/serv_param_config.gif

Une fois que des suivis SDL sont activés, collectez les suivis. Si les suivis sont envoyés au lecteur local, alors vous pouvez les récupérer dans le sous-répertoire de Cisco \ suivi. Alternativement, les fichiers de suivi peuvent être envoyés à un journal d'événements ou aux CiscoWorks 2000.

Des bits d'indicateur SDL décrits dans le tableau suivant sont placés dans la région de Service > Service Parameters au Cisco CallManager Administration. Être suivent deux exemples des valeurs désirées basées sur le problème particulier.

  • La valeur recommandée pour l'élimination des imperfections d'appel normal est SdlTraceTypeFlags=0x00000b04

  • La valeur recommandée pour l'élimination des imperfections inférieure ou les passerelles d'élimination des imperfections est SdlTraceTypeFlags=0x00004b05

Définitions de SdlTraceTypeFlags
SDLTraceTypeFlag Valeur Définition
traceLayer1 = 0x00000001 Tout le suivi de la couche 1 en fonction
TraceDetailLayer1 = 0x00000002 Suivi de la couche 1 de détail en fonction
TraceSdlLinkAdmin = 0x00000004 Liens de CallManager d'inter-Cisco de suivi dans une batterie
traceUnused = 0x00000008 Non utilisé
traceLayer2 = 0x00000010 Tout le suivi de la couche 2 en fonction
traceLayer2Interface = 0x00000020 Suivi d'interface de couche 2 en fonction
traceLayer2TCP = 0x00000040 Suivi de TCP de la couche 2 en fonction
TraceDetailLayer2 = 0x00000080 Plus de vidage mémoire de détail des trames de la couche 2.
traceLayer3 = 0x00000100 Tout le suivi de la couche 3 en fonction
traceCc = 0x00000200 Tout le suivi de Contrôle d'appel en fonction
traceMiscPolls = 0x00000400 Balayages de divers de suivi
traceMisc = 0x00000800 Suivi divers sur (signaux de base de données)
traceMsgtrans = 0x00001000 Signaux de traduction de message (TranslateIsdnToSdlReq, TranslateIsdnToSdlRes TranslateSdlToIsdnReq, TranslateSdlToIsdnRes)
traceUuie = 0x00002000 Suivi de sortie UUIE en fonction
traceGateway = 0x00004000 Signaux de passerelle

Des bits de données décrits dans le tableau suivant sont placés dans la région de Service > Service Parameters au Cisco CallManager Administration. Être suivent deux exemples des valeurs désirées basées sur le problème particulier.

  • La valeur recommandée pour l'élimination des imperfections normale de système est SdlTraceDataFlags=0x110

  • La valeur recommandée en dépistant des problèmes avec des liens SDL est 0x13D (suivi non-compact ; si un suivi compact est désiré, 0x200 mordu doit être placé. Il peut être placé en combination avec tous les autres bits)

Définitions de SDLTraceDataFlags
SDLTraceDataFlag Valeur Définition
TraceSdlLinkState = 0x001 Suivi d'enable d'initialisation de lien SDL
TraceSdlLowLevel = 0x002 Activez le suivi des événements inférieurs SDL, fileOpen et des événements de socket (par exemple)
TraceSdlLinkPoll = 0x004 Suivi d'enable de message de balayage de lien SDL
TraceSdlLinkMsg = 0x008 Suivi d'enable de message de lien SDL
traceRawData = 0x010 Les données brutes de signal d'enable tracent sur tous les signaux
TraceSdlTagMap = 0x020 Mappage de balise d'enable
traceCreate = 0x100 Le processus d'enable créent et arrêtent des suivis
TraceNoPrettyPrint = 0x200 Jolie impression de débronchement des fichiers de suivi

Avertissement d'espace disque

avertissement Avertissement : Soyez informé que les informations obtenues de cette interface pourraient être très détaillées, et consommez donc un grand nombre d'espace disque. Pour cette raison, nous vous informons activer le fichier de suivi pour une durée spécifique, examiner les informations, et arrêter le suivi.

Tracé de l'analyseur de réseau

Un renifleur est une application logicielle qui surveille le trafic IP sur un réseau et fournit des informations sous forme de suivi. Les tracés de renifleur fournissent des informations au sujet de la quantité et du type de trafic réseau sur votre réseau. Le TCP/IP ou les paquets UDP sont des protocoles utilisés par Cisco CallManager et par des périphériques d'extrémité, tels que des téléphones et des passerelles. Les tracés de renifleur peuvent également vous aider à identifier les hauts niveaux du trafic d'émission qui pourraient avoir comme conséquence des problèmes ou des appels abandonnés sonores de Voix. Les applications communes de renifleur incluent les networks associates SnifferPro, le conseiller d'Internet de Hewlett Packard, et le domino d'Acterna. Le domino offre le matériel de reniflement et les solutions logicielles et un analyseur de réseau. Si vous voulez utiliser le domino, nous recommandons utilisant le logiciel d'analyse d'évaluer un fichier capturé de renifleur (comme de l'application de SnifferPro).

Enregistrements détaillés des appels (CDR) et enregistrements de programme de maintenance (CMR)

Le CDR est une option d'enregistrement qui se connecte chaque appel passé (ou tenté) de tout téléphone IP de Cisco. Il y a deux genres de CDR : CDR de base et diagnostic CDR (ou CMR). Une fois qu'activé, vous pouvez ouvrir CDR ou diagnostic CDR (CMR) dans le gestionnaire d'entreprise de Serveur SQL. Des fichiers CDR sont enregistrés dans une base de données SQL qui peut être exportée à presque n'importe quelle application, y compris Microsoft Access ou Exceler.

Les enregistrements CDR contiennent les informations requises pour générer des enregistrements de facturation. Dans un environnement distribué, toutes les données CDR sont collectées dans un site central, ou un ensemble d'emplacements. La panne d'un noeud de Cisco CallManager ne rend pas les données CDR associées avec ce noeud indisponibles. Les données ne sont plus enregistrées sur le disque de Cisco CallManager comme fichier plat, mais sont à la place enregistrées dans un fichier central dans les tables.

Si le Cisco CallManager échoue avant que tous les enregistrements soient écrits, aucun enregistrement de l'appel n'existera. Ceci signifie qu'aucun enregistrement ne sera écrit pour les appels qui sont en activité sur un Cisco CallManager donné quand ils échouent avant que les appels se terminent.

Référez-vous à la section d'articles mouvement d'appel de ce document pour des informations détaillées sur des CDR et des CMR.

Les informations fournies incluent :

  • Enregistrements de lecture et d'écriture

  • Problèmes connus

  • Liste de types d'enregistrement générés

  • Liste de champs contenus dans chaque enregistrement et une description de ce que représente ce champ

  • La description des types d'appels connectés, et les champs se sont connectés avec chacun d'eux

  • La liste de codes de cause qui peuvent apparaître dans le CDR enregistre

Activation ou désactivation CDR

La création record CDR est désactivée par défaut quand le système est installé. Si vous souhaitez avoir des données CDR, vous devez activer des CDR dans le domaine de Service > Service Parameters du Cisco CallManager Administration. Le traitement CDR peut être activé et désactivé à tout moment tandis que le système est en fonction. Vous n'avez pas besoin de redémarrer le Cisco CallManager pour l'activation ou désactivation des CDR pour prendre effet. Le système répondra à toutes les modifications dans quelques secondes. Le CMR ou les données diagnostiques est activé séparément des données CDR. Des données CMR ne seront pas générées à moins que les deux CDR et diagnostics d'appel soient activés, mais des données CDR peuvent être générées et connectées sans données CMR.

Employez les étapes suivantes pour activer des CDR.

  1. Ouvrez le Cisco CallManager Administration.

  2. Sélectionnez Service > Service Parameters.

  3. Sélectionnez l'adresse IP de votre installation de Cisco CallManager.

  4. De la liste de paramètres, CDREnabled choisi.

  5. Définissez le type comme booléen.

  6. T choisi pour vrai.

    /image/gif/paws/30266/serv_param_config2.gif

  7. Mise à jour.

    Résultat : Les articles mouvement d'appel mettront en marche se connecter immédiatement.

    attention Attention : La Connectivité de découverte de Voix exige que se connecter CDR soit activé sur chaque installation de Cisco CallManager dans une batterie.

    /image/gif/paws/30266/log_enable.gif

CDR

Les CDR fournissent les informations de base qui peuvent vous aider à comprendre plus d'informations détaillées contenues dans des suivis de SDI. Les CDR de base fournissent des informations telles que le numéro d'appel, numéro appelé, lançant l'adresse IP, adresse IP de destination, durée de l'appel, et ainsi de suite. Les CDR peuvent vous aider à dépanner des problèmes de téléphone. Par exemple, si un utilisateur signale un problème avec un appel se produisant à une heure précise, vous pouvez consulter les CDR qui se sont produits autour du temps indiqué pour apprendre les informations complémentaires au sujet de cet appel et d'autres. Les CDR sont utilisés généralement pour l'affichage.

Diagnostic CDR (également connu sous le nom de CMR)

Le diagnostic CDR fournissent des informations d'appel détaillé telles que le nombre de paquets envoyés, reçus, et perdus, et la quantité de jitter et de latence. Ce niveau de précision peut fournir des explications pour quelques problèmes, tels que l'audio à sens unique. Par exemple, un problème sonore à sens unique est indiqué si une longueur de paquet de 10,000 est envoyée, mais la taille reçue est seulement 10.

Résolution des problèmes CallManager avec Windows NT et Internet Information Server (IIS)

Cette section adresse quelques catégories de problème courant qui peuvent se produire avec le Cisco CallManager et les périphériques relatifs. Chaque catégorie de problème suggère que dépannant vous usine devrait l'utiliser pour aider à isoler le problème. Ce document fournit des catégories générales de problèmes potentiels et de suggestions sur la façon dont dépanner ces problèmes. Il ne fournit pas une liste exhaustive de problèmes et de résolutions. Si vous rencontrez un problème qui ne peut pas être résolu utilisant les outils et les utilitaires décrits dans ce document, consultez le centre d'assistance technique Cisco (TAC) pour l'assistance. Soyez sûr les petits groupes avoir Cisco CallManager Administration disponibles, plus les n'importe quelles informations de diagnostic (telles que des suivis) que vous vous êtes réuni jusqu'au point d'appeler le TAC.

Qualité vocale

Les problèmes de qualité voix incluent l'audio perdu ou tordu pendant les appels téléphoniques. Les problèmes courants incluent les ruptures dans le bruit qui rendent l'audio intermittent (comme des mots cassés), ou la présence des bruits impairs qui tordent l'audio (écho) ou les effets qui font sembler des mots parlés aqueux ou robotiques. L'audio à sens unique, c.-à-d., une conversation entre deux personnes où seulement une personne peut entendre n'importe quoi, n'est pas réellement un problème de qualité voix. Ceci sera discuté plus tard dans cette section.

Un ou plusieurs des composants suivants peuvent poser des problèmes sonores :

  • Passerelle

  • Téléphone

  • Réseau

Pour dépanner correctement des problèmes de qualité voix, vous devez considérer l'infrastructure et tous les périphériques pour des baisses et des retards.

Audio perdu ou tordu

Un des la plupart des problèmes courants produits est une « rupture » de l'audio (souvent décrit comme discours déformé ou perte de syllabes dans un mot ou une phrase). Il y a deux causes classiques pour ceci : perte de paquets et/ou jitter. La perte de paquets signifie que les paquets sonores n'arrivent pas à leur destination parce qu'ils ont été lâchés ou arrivés trop tard pour être utiles. Le jitter est la variation des heures d'arrivée des paquets. Dans la situation idéale, tous les paquets VoIP d'un téléphone à l'autre arriveraient exactement à un taux de 1 chaque 20 ms. Notez que ceci ne mentionne pas combien de temps il prend pour qu'un paquet obtienne du point A de diriger B, simplement la variation des heures d'arrivée.

Il y a beaucoup de sources de retard variable dans un réseau réel. Certaines de ces derniers ne peuvent pas être commandées, et les autres peuvent. Le retard variable ne peut pas être éliminé entièrement dans un réseau de voix en paquets. Les processeurs de signaux numériques (DSP) sur des téléphones et d'autres périphériques Voix-capables sont conçus pour mettre en mémoire tampon une partie de l'audio, en prévision du retard variable. Ceci « qui dejittering » est fait seulement quand le paquet sonore a atteint sa destination et est prêt à être mis dans un flux audio conventionnel (c'est-à-dire, lu dans l'oreille de l'utilisateur, envoyée au PSTN par l'intermédiaire d'un flot numérique PCM). Le téléphone IP 7960 de Cisco peut mettre en mémoire tampon pas moins d'une seconde d'échantillons de Voix. La mémoire tampon de jitter est adaptative, signifiant si une rafale des paquets est reçue, le téléphone IP 7960 de Cisco peut les jouer afin d'essayer de contrôler le jitter. L'administrateur réseau doit réduire la variation entre les heures d'arrivée de paquet en appliquant le Qualité de service (QoS) et d'autres mesures à l'avance (particulièrement si les appels croisent un réseau d'étendu).

Une fois confronté à un problème sonore perdu ou tordu, vous devriez d'abord essayer d'isoler le chemin de l'audio. Essayez d'identifier chaque périphérique de réseau (des Commutateurs et des Routeurs) dans le chemin du flux audio de l'appel. Maintenez dans l'esprit que l'audio peut être entre deux téléphones, entre un téléphone et une passerelle, ou il pourrait avoir de plusieurs tronçons (d'un téléphone à un périphérique de transcodage et de là à un autre téléphone). Essayez de l'identifier si le problème se pose seulement entre deux sites, seulement par une certaine passerelle, sur un certain sous-réseau, et ainsi de suite. Ceci aidera à se rétrécir vers le bas que les périphériques vous doivent examiner plus soigneusement. Ensuite, il est souvent le meilleur de désactiver la suppression de silence (également connue sous le nom de détection d'activation de Voix ou VAD) si ceci n'a pas été déjà fait. Ce mécanisme sauvegarde la bande passante en ne transmettant pas n'importe quel audio quand il y a silence, mais peut entraîner le découpage apparent (et inacceptable) au début des mots. Vous pouvez désactiver ceci au Cisco CallManager Administration, sous le Service > Service Parameters. De là, sélectionnent le serveur et le service de Cisco CallManager. Placez SilenceSuppressionSystemWide à « F » (alternativement vous pouvez placer SilenceSuppressionWithGateways à « F », mais ceci n'applique pas aux Passerelles H.323 ou aux passerelles MGCP). En cas de doute, arrêtez chacun des deux en sélectionnant la valeur F pour chacun.

/image/gif/paws/30266/serv_param.gif

Si un analyseur de réseau est disponible, un appel moniteur entre deux téléphones devrait avoir 50 paquets par seconde (ou 1paquet chaque 20 ms) quand la suppression de silence est désactivée. Avec le filtrage approprié, il devrait être possible de l'identifier si des paquets sont perdus ou retardés excessivement.

Souvenez-vous ce retard par lui-même n'entraînera pas le découpage, seulement le retard variable va le faire. Dans la table ci-dessous, qui représente un suivi parfait, les heures d'arrivée entre les paquets sonores (qui auront une en-tête de RTP) seront 20 ms. Dans un appel de mauvaise qualité (tel qu'un appel avec beaucoup de jitter), les heures d'arrivée varieraient considérablement.

Un suivi parfait
Nombre de paquet Temps : absolu (ms) Temps : delta (ms)
1 0
2 0.02 20
3 0.04 20
4 0.06 20
5 0.08 20

Le placement de l'analyseur de paquet dans de divers points dans le réseau aidera à se rétrécir vers le bas d'où le retard est livré. Si aucun analyseur n'est disponible, d'autres méthodes seront exigées. Il est important d'examiner la statistique d'interface de chaque périphérique dans le chemin de l'audio. Un autre outil pour dépister des appels avec la médiocre qualité de voix est les articles mouvement diagnostiques d'appel (CDR). Voyez la section d'outils et d'utilitaires et la section d'articles mouvement d'appel pour plus d'informations sur des CDR.

Les valeurs pour le jitter et la latence peuvent être récupérées pour tous les appels (mais seulement après que l'appel s'est terminé). Être suit un diagnostic CDR d'échantillon (CallDetailRecordDiagnostic est le nom de la table réel). Le nombre de paquets envoyés, reçu, perdu, jitter, et latence tous sont enregistrés. La valeur de globalCallID peut être utilisée pour trouver l'appel dans la table du militaire de carrière CDR de sorte que la cause de débranchement et d'autres informations puissent être obtenues. Le diagramme ci-dessous affiche les deux tables ouvertes. Notez que dans le diagnostic CDR, chaque périphérique qui peut probablement signaler ces informations est inclus. Ainsi, si le problème est entre deux Téléphones IP de Cisco, nous voyons deux entrées de table par appel. Si nous avons un appel par une passerelle de Cisco IOS, par exemple, nous voyons seulement les informations de diagnostic du téléphone IP de Cisco, pas la passerelle parce qu'il n'y a aucun mécanisme pour qu'il informe la base de données SQL avec ces informations.

ibutton.gif

j'aide de bouton

Le téléphone IP 7960 de Cisco fournit un autre outil pour diagnostiquer des problèmes sonores possibles. Sur un appel actif, vous pouvez appuyer sur le bouton I deux fois (rapidement) et les affichages du téléphone qu'un écran des informations qui contient le paquet reçoivent et transmettent des statistiques, aussi bien que les compteurs moyens et maximum de jitter. Sur cet écran, non ce jitter est la moyenne des cinq derniers paquets qui sont arrivés ; le jitter maximum est la marque des grandes marées pour le jitter moyen.

Les sources les plus communes pour le retard et la perte de paquets sont des périphériques où une interface de vitesse supérieure introduit dans une interface plus à vitesse réduite. Par exemple, un routeur peut avoir une interface Ethernet rapide de 100 mis-bande connectée au RÉSEAU LOCAL et un Relais de trames lent connecté au WAN. Quand la mauvaise qualité se produit seulement en communiquant au site distant (seulement le site distant peut signaler la médiocre qualité de voix tandis que dans l'autre direction tout semble être bon), sont ci-dessous les causes le plus susceptibles du problème :

  • Le routeur n'a pas été correctement configuré pour accorder la priorité du trafic vocal au-dessus du trafic de données.

  • Il y a trop d'appels actifs pour que le WAN le prenne en charge (c'est-à-dire, il n'y a aucun contrôle d'admission d'appel pour limiter le nombre d'appels qui peuvent être placés).

  • Il y a des erreurs de port physique.

  • Il y a de l'encombrement dans le WAN lui-même.

Sur le RÉSEAU LOCAL, les la plupart des problèmes courants sont des erreurs niveau physique (telles que des erreurs de CRC) provoquées par des câbles défectueux et des interfaces, ou par les périphériques incorrect-configurés (tels qu'une vitesse du port ou un conflit du mode bidirectionnel). Assurez-vous que le trafic ne croise aucun périphérique de médias communs, tel qu'un hub. Il pourrait également y avoir des situations où le trafic prend un chemin plus lent par le réseau que prévu. Si QoS a été configuré correctement, il est possible qu'il n'y ait aucun contrôle d'admission d'appel. Selon votre topologie, ceci peut faire par l'utilisation des emplacements dans la configuration de Cisco CallManager Administration, ou à l'aide d'un routeur Cisco IOS en tant que garde-porte. En tous cas, vous devriez toujours savoir combien d'appels pourraient être pris en charge à travers votre WAN. Si possible, testez ceci en désactivant la suppression de silence comme plus tôt décrit, alors placez les appels entre les deux sites. Ne placez pas invite l'attente ou sur la coupure micro, puisque ceci arrêtera des paquets de l'transmission. Avec le nombre maximal d'appels à travers le WAN, les appels devraient tout avoir la qualité acceptable. Testez pour s'assurer qu'un occupé rapide est retourné en essayant de faire un davantage appel.

Crépiter

Un autre symptôme de « mauvaise qualité » peut être un crépitement, qui est parfois provoqué par un bloc d'alimentation défectueux ou un certain genre d'interférence électrique forte près du téléphone. Essayez permuter le bloc d'alimentation et déplacer le téléphone à un endroit différent.

Vérifiez vos chargements

En outre, vous devriez toujours vérifier les téléphones et les passerelles pour assurer les dernières charges logicielles sont en service. En cas de doute, contrôle CCO (Cisco Connection Online chez www.cisco.com) pour les dernières charges logicielles, nouveaux correctifs, ou notes de mise à jour concernant le problème.

Écho

L'écho (également connu sous le nom de « écho de locuteur ») se produit quand de l'énergie de la parole d'un locuteur, transmise en bas du chemin de signaux primaire, est couplée dans le chemin de réception de l'extrémité. Le locuteur entend alors sa propre Voix, retardée par tout le temps de retard de chemin d'écho.

/image/gif/paws/30266/voice.gif

Dans le diagramme ci-dessus, la Voix de John (dans le bleu) est reflétée de retour. Ceci peut se produire mais passer inapperçu dans un réseau voix traditionnel parce que le retard est si bas. À l'utilisateur, il retentit plutôt un effet local qu'un écho. Dans un réseau VoIP, il sera toujours apparent, puisque le packetization et le compactage contribuent toujours assez de retard. La chose importante à se souvenir est que la cause de l'écho est toujours avec les composants et le câblage analogiques. Par exemple, les paquets IP ne peuvent pas simplement tourner autour et s'attaquer de retour à la source à un niveau audio plus bas. Le même est impossible sur les circuits T1/E1 numériques. Ainsi à un appel d'un téléphone IP de Cisco à l'autre, il devrait jamais ne y avoir n'importe quel problème. La seule exception peut être si un interlocuteur utilise un haut-parleur qui a l'ensemble de volumes trop élevé ou une autre situation où une boucle sonore est créée.

Les problèmes d'écho de pour le dépannage, s'assurent que les téléphones qui sont testés ou examiné n'utilisent pas le haut-parleur et qu'ils ont le positionnement de volume du casque aux niveaux raisonnables (début avec 50 pour cent du niveau audio maximum). Le plus souvent, les problèmes se poseront quand se reliant au PSTN par une passerelle numérique ou analogique. Les utilisateurs de téléphone IP de Cisco peuvent se plaindre qu'ils entendent leur propre Voix étant reflétée de nouveau à eux. Bien que la source vraie de problème soit presque toujours à l'extrémité, il est presque toujours impossible de changer n'importe quoi dans le PSTN. Ainsi, la première étape est de déterminer quelle passerelle est utilisée. Si une passerelle numérique est en service, il peut être possible d'ajouter la remplissage supplémentaire dans la direction de transmission (vers le PSTN) dans les espoirs que la force du signal inférieure rapportera moins d'énergie réfléchie. Supplémentaire, vous pouvez ajuster le niveau de réception de sorte que n'importe quel audio reflété soit encore autre réduit. Il est très important de se souvenir pour faire de petits réglages à la fois. Trop d'atténuation du signal rendra l'audio impossible à entendre des deux côtés. Alternativement, vous pouvez entrer en contact avec le transporteur et la demande pour faire vérifier les lignes. Sur un circuit typique T1/PRI en Amérique du Nord, le signal d'entrée devrait être le dB -15. Si le niveau de signal est beaucoup plus élevé (dB -5, par exemple), l'écho sera le résultat probable.

Gardez un log de tous les appels qui éprouvent l'écho. La période du problème, le numéro de téléphone de source, et le nombre appelé devraient tout être enregistrés. Les passerelles ont un temps fixe de 16 ms de l'annulation d'écho. Si le retard dans l'audio reflété est plus long que ceci, le chancelier d'écho ne pourra pas fonctionner correctement. Ceci ne devrait pas être une question pour des appels locaux, et les appels longue distance devraient avoir des chanceliers d'écho externe construits dans le réseau au bureau central. C'est l'une des raisons pour lesquelles il est important de noter le numéro de téléphone externe d'un appel que les expériences font écho.

Vérifiez vos chargements

Des chargements de passerelle et de téléphone devraient être vérifiés. Vérifiez CCO (Cisco Connection Online chez www.cisco.com) pour les dernières charges logicielles, les nouveaux correctifs, ou les notes de mise à jour concernant le problème.

Audio à sens unique ou aucun audio

L'audio à sens unique se produit quand une personne ne peut pas entendre une autre personne pendant un appel. Ceci peut sont provoqué par par une passerelle inexact-configurée de Cisco IOS, un Pare-feu, ou un routage ou un problème de passerelle par défaut, notamment.

Il y a un certain nombre de causes pour l'audio à sens unique ou aucun audio pendant un appel. La plupart de cause classique est un périphérique inexact-configuré. Par exemple, le Cisco CallManager manipule l'établissement d'appel pour un téléphone IP de Cisco. Le flux audio réel se produit entre les deux Téléphones IP de Cisco (ou entre le téléphone IP de Cisco et une passerelle). Ainsi, il est entièrement possible que le Cisco CallManager puisse signaler à un téléphone de destination (lui faisant la sonnerie) quand le téléphone lançant l'appel n'a pas une artère IP au téléphone de destination. Ceci se produit généralement quand la passerelle par défaut dans le téléphone est incorrectement configurée (manuellement ou sur le serveur de protocole DHCP (DHCP)).

Si un appel a uniformément l'audio à sens unique, essayez de cingler le téléphone IP de Cisco de destination utilisant un PC qui est sur le même sous-réseau que le téléphone et a la même passerelle par défaut. Prenez un PC qui est sur le même sous-réseau que le téléphone de destination (avec la même passerelle par défaut que le téléphone de destination) et cinglez le téléphone de source. Chacun des deux ces tests devraient fonctionner. Le trafic sonore peut également être affecté par un filtre de Pare-feu ou de paquet (tel que des Listes d'accès sur un routeur) qui peut bloquer l'audio dans une ou les deux directions. Si l'audio à sens unique se produit seulement par une passerelle à commande vocale de Cisco IOS, vérifiez la configuration soigneusement. Le Routage IP doit être activé (examinez la configuration pour s'assurer qu'aucun Routage IP n'est trouvé près du début de la configuration). Également, si vous employez la Compression d'en-tête RTP pour sauvegarder la bande passante à travers le WAN, assurez-vous qu'il est activé sur chaque trafic vocal de transport de routeur qui se relie au circuit BLÊME. Il ne devrait pas y a une situation où l'en-tête de RTP est compressée sur une extrémité mais ne peut pas être décomprimé de l'autre côté du WAN. Un renifleur est des problèmes sonores à sens unique de pour le dépannage d'un outil très utile parce que vous pouvez vérifier que le téléphone ou la passerelle est réellement envoyante ou recevante des paquets. Le diagnostic CDR sont utile en déterminant si un appel éprouve l'audio à sens unique parce qu'ils se connectent les paquets transmis et reçus (référez-vous à l'audio perdu ou tordu). Vous pouvez également appuyer sur le bouton I deux fois (rapidement) sur un téléphone IP 7960 de Cisco pendant un appel actif pour visualiser des détails sur les paquets transmis et reçus.

Remarque: Quand un appel est amorti (bouton muet appuyé sur à un téléphone), aucun paquet ne sera transmis. Le bouton de mise en attente arrête le flux audio, ainsi aucun paquet n'est introduit l'un ou l'autre de direction. Quand le bouton de mise en attente est relâché, tous les compteurs de paquet sont remis à l'état initial. Souvenez-vous que la suppression de silence doit être désactivée sur des périphériques pour que les compteurs TX et RX restent égale. Désactiver la suppression de silence au niveau système n'affectera pas des passerelles de Cisco IOS.

MTP et audio à sens unique

Si vous utilisez le Media Termination Point (MTP) dans un appel (pour prendre en charge des services supplémentaires tels que l'attente et le transfert avec H.323 les périphériques qui ne prennent en charge pas H.323 la version 2), vérifiez pour voir si le MTP alloué fonctionne correctement. Les routeurs Cisco IOS prennent en charge H.323 le début de version 2 dans la version 11.3(9)NA et 12.0(3)T. Commençant par la Cisco IOS version 12.0(7)T, LogicalChannel H.323 ouvert/étroit facultatif est pris en charge, de sorte que MTP articulé autour d'un logiciel ne soit plus exigé pour des services supplémentaires.

Le périphérique MTP, aussi bien que passerelle de conférence et transcodeur, jettera un pont sur deux flux audios ou plus. Si le MTP, la passerelle de conférence, ou le transcodeur ne fonctionne pas correctement, l'audio ou la perte à sens unique d'audio pourrait être expérimentée. Arrêtez MTP pour découvrir si MTP pose le problème.

Remises de téléphone

Les téléphones veulent l'arrêt et redémarrage ou la remise pour une des deux raisons suivantes :

  • Panne de TCP se connectant au Cisco CallManager, ou

  • Manque de recevoir un accusé de réception aux messages de la keepalive du téléphone.

Sont ci-dessous les étapes pour dépannage des remises de téléphone :

  1. Vérifiez les téléphones et les passerelles pour s'assurer que vous utilisez les dernières charges logicielles.

  2. Vérifiez CCO (Cisco Connection Online chez www.cisco.com) pour les dernières charges logicielles, les nouveaux correctifs, ou les notes de mise à jour concernant le problème.

  3. Vérifiez le visualisateur d'événements pour des exemples de la remise à l'état initial de téléphones. Des remises de téléphone sont considérées des événements de l'information, suivant les indications de l'illustration suivante.

    /image/gif/paws/30266/event_prop.gif

  4. Recherchez ces derniers et toutes les erreurs qui ont pu s'être produits autour du temps ce la remise de téléphones.

  5. Commencez un suivi de SDI et l'essayez d'isoler le problème en identifiant toutes les caractéristiques communes dans les téléphones qui remettent à l'état initial. Par exemple, vérifiez s'ils tous sont situés sur le même sous-réseau, le même VLAN, et ainsi de suite. Regardez le suivi et déterminez si :

    • les remises se produisent pendant un appel ou se produisent par intermittence, ou

    • il y a toutes les similitudes de modèle de téléphone : Téléphone IP 7960 de Cisco, téléphone IP 30VIP de Cisco, et ainsi de suite.

  6. Commencez un tracé de renifleur à un téléphone qui remet à l'état initial fréquemment. Après qu'il ait remis à l'état initial, regardez le suivi pour déterminer s'il y a l'occurrence de relances de TCP. Si oui, ceci indique un problème de réseau. Le suivi peut afficher quelques cohérences dans les remises, telles que le téléphone remettant à l'état initial tous les sept jours. Ceci pourrait indiquer une expiration de bail DHCP tous les sept jours (cette valeur est utilisateur-configurable et pourrait être toutes les deux minutes, et ainsi de suite).

Appels abandonnés

Les appels abandonnés se produisent quand un appel est pr3maturément terminé. Vous pouvez employer des CDR pour déterminer la cause possible des appels abandonnés, en particulier si le problème est intermittent. Les appels abandonnés peuvent être le résultat d'une remise à l'état initial de téléphone ou de passerelle (voir ci-dessus la section) ou un problème de circuit, tel que la configuration incorrecte PRI ou l'erreur.

La première étape est de déterminer si ce problème est localisé dans un téléphone ou un groupe de téléphones. Peut-être tous les téléphones affectés sont sur un sous-réseau ou un emplacement particulier. L'étape suivante est de vérifier le visualisateur d'événements pour des remises de téléphone ou de passerelle.

/image/gif/paws/30266/drop_call.gif

Il devrait y avoir un avertissement et un message d'erreur pour chaque téléphone qui remet à l'état initial. Dans ce cas, le problème est souvent que le téléphone ne peut pas maintenir sa connexion TCP au Cisco CallManager active, ainsi le Cisco CallManager remet à l'état initial la connexion. Ceci peut se produire parce qu'un téléphone a été arrêté ou il peut y a un problème dans le réseau. Si c'est un problème intermittent, il peut être utile d'employer la Microsoft Performance pour enregistrer des enregistrements de téléphone.

/image/gif/paws/30266/drop_call2.gif

Si le problème semble se poser seulement par une certaine passerelle, telle que Cisco Access DT-24+, la meilleure ligne de conduite est d'activer le suivi et/ou de visualiser les CDR. Les fichiers CDR donneront une cause d'arrêt (COT) qui peut aider à déterminer la cause du problème.

drop_call3.gif

Les valeurs de cause de débranchement (l'origCause_value et le destCause_value, selon lesquels côté arrêté vers le haut de l'appel), tracent à codes de motif de déconnexion Q.931 (dans la décimale) qui peuvent être trouvés aux types, aux codes, et aux valeurs de commutateur RNIS. Dans l'exemple ci-dessus, la cause 16 se rapporte à un effacement d'appel normal. Si l'appel sort une passerelle au PSTN, le CDR peut être utilisé pour déterminer quel côté s'arrête vers le haut de l'appel. Une grande partie des mêmes informations peut être obtenue en activant le suivi sur le Cisco CallManager. Utilisez l'outil de suivi seulement en dernier recours ou si le réseau n'est pas encore dans la production.

Vérifiez vos chargements

Comme avec n'importe quel problème, vérifiez les chargements de téléphone et de passerelle et CCO (Cisco Connection Online chez www.cisco.com) pour les dernières charges logicielles, les nouveaux correctifs, ou les notes de mise à jour concernant le problème.

Questions de caractéristique de Cisco CallManager

Les problèmes peuvent se poser avec les configurations, telles que la passerelle de conférence ou le Media Termination Point, qui sont utilisées en même temps que le Cisco CallManager. Certains de ces problèmes de caractéristique sont provoqué par par des erreurs de configuration ou un manque de ressources. Par exemple, les utilisateurs peuvent ne pas pouvoir aux conférences téléphoniques si le nombre spécifié de ressources ad hoc en conférence a été dépassé. Le résultat serait un appel abandonné quand l'utilisateur tenté pour initier la caractéristique de conférence. Ceci pourrait sembler être une question de caractéristique de Cisco CallManager, quand en fait c'est un problème avec le nombre de ressources disponibles en conférence. Le nombre de fois où une ressource en conférence a été exigée, mais non disponible, est un de la Microsoft Performance ouverte une session par compteurs. Le même comportement se produit s'il y a des ressources en conférence disponibles, mais le service de conférences avait arrêté.

Codecs/régions : Non-concordance de codecs

Si un utilisateur obtient une tonalité de réarrangement en allant le hors fonction-crochet, ce pourrait être le résultat du désaccord de codecs entre les régions. Vérifiez que chacun des deux des extrémités d'appel prennent en charge au moins un codec commun (par exemple, G.711). Sinon, vous devrez utiliser des transcodeurs.

Une région spécifie la plage des codecs pris en charge qui peuvent être utilisés avec chacune des autres régions. Chaque périphérique appartient à une région.

Remarque:  La négociation de codecs avec un routeur Cisco IOS n'est pas prise en charge.

Region1<->Region2 = signifie G.711 qu'un appel entre un périphérique dans Region1 et un périphérique dans Region2 peut l'utiliser G.711 ou n'importe quel autre codec pris en charge qui exige la bande passante égale ou inférieure en tant que G.711 (tous codecs pris en charge en dedans G.711, G.729, G.723, et ainsi de suite).

Remarque:  Les codecs suivants sont pris en charge pour chaque périphérique :

  • Téléphone IP de Cisco 7960 G.711A-law/Ý-law, G.729AnnexB

  • Gamme SP12 et VIP de téléphone IP de Cisco 30 G.711A-law/Ý-law, G.723.1

  • Cisco accèdent à la passerelle DE30 et DT-24+ G.711A-law/Ý-law, G.723.1

Emplacements

Si un utilisateur reçoit une tonalité de réarrangement après composition d'un numéro, il pourrait être parce que l'allocation de bande passante de Cisco CallManager pour l'emplacement d'un des périphériques d'extrémité d'appel a été dépassée (moins que 24k). Le Cisco CallManager vérifie la bande passante disponible 24k pour chaque périphérique avant de faire un appel. Si moins que la bande passante 24k est disponible, le Cisco CallManager n'installera pas l'appel et l'utilisateur entendra une tonalité de réarrangement.

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 
(-1 implies infinite bw available)

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallState tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=,
 CalledParty=5005, tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98 

Une fois l'appel est établi, le Cisco CallManager soustrait la bande passante des emplacements selon les codecs utilisés dans cet appel. Si l'appel utilise G.711, le Cisco CallManager soustrait 80k ; si l'appel utilise G.723, le Cisco CallManager soustrait 24k ; si l'appel utilise G729, le Cisco CallManager soustrait 24k.

Passerelle de conférence

Employez les informations suivantes pour aider à ne dépanner un « aucun problème disponible de passerelle de conférence ». Ceci a pu être un logiciel ou un problème matériel.

D'abord, contrôle pour voir si vous avez n'importe quelles ressources disponibles en passerelle de conférence inscrites au Cisco CallManager (l'un ou l'autre de matériel ou logiciel). Pour faire ainsi, vous pouvez employer la Microsoft Performance pour vérifier le nombre de « Unicast AvailableConferences. »

Les applications de diffusion de supports vocaux IP de Cisco remplissent la fonction de passerelle de conférence. Une installation de logiciel de couler de supports vocaux IP de Cisco prendra en charge 16 conférences disponibles d'Unicast (3 personnes/conférences), suivant les indications du suivi suivant.

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB_kirribilli - Registered - ConfBridges= 16,
 Streams= 48, tcpHandle=4f12738

10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??%? - DeviceType= 50, ResourcesAvailable= 16, 
deviceTblIndex= 0 

Un port E1 (la carte WS-X6608-E1 contient des ports de l'E1 8x) fournit cinq conférences disponibles d'Unicast (taille maximum de conférence = 6), suivant les indications du suivi suivant.

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, 
tcpHandle=4f19d64

11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??% - DeviceType= 51, ResourcesAvailable= 5,
 deviceTblIndex= 0 

Le suivi suivant de matériel sur le port voice 8 T1/E1 de Cisco Catalyst 6000 et le Module de services indique que le port E1 4/1 dans la carte s'est enregistré comme passerelle de conférence avec le Cisco CallManager.

greece-sup (enable) sh port 4/1

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/1 enabled 1 full - Conf Bridge


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/1 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/1 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/1 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/1 disabled disabled

En second lieu, vérifiez le nombre maximal d'utilisateurs configurés dans la conférence (ad hoc ou Meet-Me) pour déterminer si le problème se posait parce que ce nombre a été dépassé.

Problèmes de transcodage

Si vous avez installé un transcodeur de matériel dans le port voice 8 T1/E1 de Cisco Catalyst 6000 et le Module de services, et cela ne fonctionne pas en tant que prévu (la signification de vous ne peut pas faire des appels entre deux utilisateurs sans des codecs communs), vérifiez pour voir si vous avez n'importe quelles ressources disponibles en transcodeur inscrites au Cisco CallManager (ceci doit être matériel). Employez la Microsoft Performance pour vérifier le nombre de « MediaTermPointsAvailable » disponible.

Un port E1 (la carte WS-X6608-E1 contient des ports de l'E1 8x) fournit des ressources Transcoder/MTP pour 16 appels, suivant les indications du suivi suivant.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

Le suivi suivant de matériel sur le port voice 8 T1/E1 de Cisco Catalyst 6000 et le Module de services indique que le port E1 4/2 dans la carte s'est enregistré comme MTP/transcoder avec le Cisco CallManager.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

Remarque: Le même port E1 ne peut pas être configuré pour la passerelle de conférence et le Transcoder/MTP

Afin de faire un appel entre deux périphériques utilisant un bas code de débit binaire (tel que G.729 et G.723) qui ne prennent en charge pas les mêmes codecs, une ressource en transcodeur est exigée. Considérez l'illustration suivante :

/image/gif/paws/30266/ccm_ill.gif

Supposez que le Cisco CallManager a été configuré tels que le codec entre Region1 et Region2 est G.729. Les scénarios suivants sont possibles :

  • Si l'appelant téléphonent en fonction des initiés un appel, le Cisco CallManager se rend compte que c'est un téléphone IP 7960 de Cisco, qui s'avère justement le prendre en charge G.729. Après que les chiffres aient été collectés, le Cisco CallManager détermine que l'appel est destiné à l'utilisateur D qui est dans la région 2. Puisque le périphérique de destination le prend en charge également G.729, l'appel est installé et les écoulements d'audio directement entre le téléphone A et le téléphone D.

  • Si un appelant au téléphone B, qui a un téléphone IP 12SP+ de Cisco, devaient initier un appel pour téléphoner D, cette fois le Cisco CallManager se rendrait compte que le téléphone d'origine le prend en charge seulement G.723 ou G.711. Le Cisco CallManager devrait allouer une ressource en transcodage de sorte que l'audio circule aussi G.711 entre le téléphone B et le transcodeur, mais que G.729 entre le transcodeur et le téléphone D. Si aucun transcodeur n'étaient disponible, téléphonez le téléphone du d sonnerait, mais dès que l'appel a été répondu, l'appel déconnecterait.

  • Si un utilisateur au téléphone B devaient appeler le téléphone F (téléphone IP 12SP+ de Cisco), les deux téléphones les utiliseraient réellement G.723, quoique G.729 soit configuré comme codecs pour l'utiliser entre les régions. G.723 est utilisé parce que les deux points finaux le prennent en charge et il utilise moins de bande passante que G.729.

  • Si un système de messagerie vocale de Cisco uOne est ajouté (qui seulement des supports G.711) ou un routeur Cisco IOS configuré pour G.711 à la région 1, alors un périphérique de transcodage doit être utilisé si appelant de la région 2. Si aucun n'est disponible, alors l'appel échouera.

Problèmes de ressource MTP

Un problème de ressource MTP pourrait être le coupable si un appel est établi et les services supplémentaires ne sont pas disponibles sur H.323 un périphérique qui ne prend en charge pas H323v2. D'abord, déterminez si vous avez n'importe quelles ressources disponibles MTP (l'un ou l'autre de matériel ou logiciel) inscrites au Cisco CallManager. Vous pouvez faire ainsi à l'aide de la Microsoft Performance pour vérifier le nombre de « MediaTermPointsAvailable. »

Une application logicielle MTP prend en charge 24 appels (utilisant MTP pour prendre en charge des services supplémentaires avec H.323 les périphériques qui pas prennent en charge H.323v2), suivant les indications du suivi suivant.

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP_kirribilli. - Registered - Supports 24 calls

Un port E1 (la carte WS-X6608-E1 contient des ports de l'E1 8x) fournit des ressources MTP pour 16 appels, suivant les indications du suivi suivant.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

Le suivi suivant de matériel, du port voice 8 T1/E1 de Cisco Catalyst 6000 et du Module de services, indique que le port E1 4/2 dans la carte s'est enregistré comme MTP/transcoder avec le Cisco CallManager.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

En second lieu, voyez si la case à cocher de Media Termination Point Required est sélectionnée dans l'écran de configuration de passerelle du Cisco CallManager Administration.

Troisièmement, vérifiez que le Cisco CallManager a alloué le nombre exigé de périphériques MTP.

À partir du fichier de SDI :

15:22:23.848 Cisco CallManager|MediaManager(40) started

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder 
  Enabled

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), 
  party2(16777358), proxies=1, connections=2, current proxies=0

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy 
  connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating 
  MTP(ci=16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - start 2 connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777357) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777358) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - 
  CI=16777359 count=1

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource 
  - CI=16777359 count=2

Plans de composition

Un Plan de composition est une liste de nombres (et de groupes de nombres) qui indique le Cisco CallManager auquel des périphériques (téléphones, passerelles, et ainsi de suite) pour envoyer des appels quand une certaine chaîne de chiffres est collectée. Il est analogue à une table de routage statique dans un routeur. Veuillez être certain que vos concepts de Plan de composition, routage d'appels de base, et planification ont été soigneusement considérés et correctement configurés avant d'essayer pour dépanner une question potentielle de Plan de composition. Très souvent, le problème se trouve avec la planification et la configuration.

Considérez les problèmes suivants de Plans de composition de pour le dépannage de questions :

  • Quel est le nombre de répertoire (DN) lançant l'appel ?

  • Quel est l'espace de recherche appelant de ce DN ?

  • Si c'est approprié, quel est l'espace de recherche appelant du périphérique (tel qu'un téléphone IP de Cisco) avec lequel le DN est associé ? Assurez-vous que vous identifiez le périphérique correct ; des apparences de plusieurs lignes sont prises en charge, et il est possible d'avoir un DN sur de plusieurs périphériques. Notez l'espace de recherche appelant du périphérique. Si l'appel est lancé par un téléphone IP de Cisco, souvenez-vous que la ligne particulière (DN) et le périphérique auquel cette ligne est associée chacun aura appeler les espaces de recherche. Ils seront combinés quand faisant un appel. Comme exemple, supposez que la ligne l'exemple 1000 a un espace de recherche appelant d'AccessLevelX et le téléphone IP de Cisco qui a l'extension 1000 configurée là-dessus a AccessLevelY en tant que son espace de recherche appelant. Par conséquent, quand faisant un appel à partir de cette ligne apparence, le Cisco CallManager le recherchera par des partitions contenues en appelant l'espace de recherche AccessLevelX et AccessLevelY.

  • Quelles partitions sont associées avec l'espace de recherche appelant ?

  • Quelle est la partition du périphérique auquel l'appel devrait (ou ne devriez pas) aller ?

  • Quel est le numéro qui est composé ? Note si et quand les appelants obtiennent une tonalité secondaire, à toute étape. En outre, que les appelants entendent-ils après tout les chiffres avoir été entré (commandez à nouveau, rapide-occupé) ? Obtiennent-ils les tonalités de progression avant qu'ils comptent entendre n'importe quoi ? Assurez-vous que les appelants attendent au moins 10 secondes après avoir écrit le dernier chiffre, puisqu'ils peuvent devoir attendre le temporisateur d'inter-chiffre pour expirer.

  • Générez un état de plan de routage au Cisco CallManager Administration. Employez-le pour examiner tous les modèles d'artère pour les partitions qui sont dans l'espace de recherche appelant pour l'appel.

  • S'il y a lieu, ajoutez ou modifiez les modèles d'artère ou conduisez les filtres.

  • Si vous pouvez trouver le modèle d'artère auquel l'appel est envoyé, notez la liste de routage ou la passerelle lesquelles le modèle indique.

  • Pour une liste de routage, le contrôle qui conduisent des groupes font partie de la liste et qui les passerelles font partie des groupes d'artère.

  • Vérifiez que les périphériques applicables sont inscrits au Cisco CallManager.

  • S'il n'y a aucun accès au Cisco CallManager, obtenez le tech d'exposition pour saisir ces informations et pour les vérifier.

  • Observez pour @ le signe. C'est une macro-instruction qui peut développer pour inclure beaucoup de différentes choses. Il est employé souvent en combination avec des options de filtrage.

  • Si un périphérique n'est pas une partie d'une partition, il est dit une partie de la partition de null ou de par défaut. Chaque utilisateur devrait pouvoir appeler ce périphérique. La partition nulle est toujours recherchée pour la dernière fois.

  • Si vous composez un numéro d'extérieur qui apparie un modèle 9.@ et il prend 10 secondes avant que l'appel intervient, vérifiez les options de filtrage. Un modèle 9.@, quand composant un numéro à 7 chiffres, (par défaut) attendra 10 secondes. Vous devez appliquer un filtre d'artère au modèle qui indique que LOCAL-AREA-CODE DOES-NOT- EXISTENT et END-OF-DIALING DOES-NOT-EXIST.

Partitions

Les partitions de routage héritent des capacités de traitement des erreurs du logiciel Cisco CallManager. C'est-à-dire, une console et suivi d'un fichier de SDI sont donnés pour les informations de journalisation et des messages d'erreur. Ces messages feront partie du composant d'analyse de chiffre des suivis. Même avec les suivis ci-dessous, une compréhension des partitions et appeler des configurations des espaces de recherche et qui des périphériques sont dans chaque partition, avec son espace de recherche appelant associé, est essentiel en déterminant le problème.

Le suivi ci-dessous est un exemple d'un numéro composé qui est dans l'espace de recherche appelant du périphérique. Pour des explications plus détaillées au sujet des suivis de SDI, examinez s'il vous plaît les études de cas dans ce document.

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028|

  08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

Dans le composant d'analyse de chiffre du suivi (ci-dessus), les « pss » (l'espace de recherche de partition, également connu sous le nom d'appeler l'espace de recherche) est répertoriés pour le périphérique plaçant l'appel. Ci-dessous, vous pouvez voir cela « RTP_NC_Hardwood ; RTP_NC_Woodland ; Local_RTP » sont les partitions on permet qu'à ce périphérique pour appeler.

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 5 tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

  08:38:55.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

  08:38:56.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

  08:38:56.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 3 tcpHandle=0x6b88028

  08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

  08:38:56.515 Cisco CallManager|Digit analysis: analysis results

  08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

De l'exemple ci-dessus, il est principal que vous notiez que « PotentialMatchesExist » est le résultat d'une analyse de chiffre des numéros qui ont été composés jusqu'à ce que le précis - la correspondance est trouvée et l'appel est conduit en conséquence.

Est ci-dessous un suivi où le nombre qui a été tenté pour être composé (1001) n'est pas dans l'espace de recherche appelant du périphérique. De nouveau, il est principal que vous notiez que la routine d'analyse de chiffre a eu les correspondances potentielles jusqu'à ce que seulement le premier chiffre ait été composé. Le modèle d'artère associé avec le chiffre "1" est dans une partition qui n'est pas dans l'espace de recherche appelant du périphérique, « RTP_NC_Hardwood ; RTP_NC_Woodland ; Local_RTP ». Par conséquent le téléphone a été envoyé commandent à nouveau la tonalité.

08:38:58.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

  08:38:58.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 1 tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

  08:38:59.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist

  08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone 
  tcpHandle=0x6b88028

Les partitions de routage fonctionnent à côté d'associer un nom de partition avec chaque nombre de répertoire dans le système. Le nombre de répertoire peut s'appeler seulement si le périphérique appelant contient la partition dans une liste de partitions auxquelles elle est permise de placer des appels dans son espace de recherche de partition. Ceci fournit le contrôle extrêmement puissant du routage.

Quand un appel est placé, des tentatives d'analyse de chiffre de résoudre l'adresse composée seulement dans des ces partitions que l'espace de recherche de partition spécifie. Chaque nom de partition comporte un sous-ensemble discret de l'espace d'adressage dialable global. De chaque partition énumérée, l'analyse de chiffre récupère le modèle que ce meilleur apparie l'ordre des chiffres composés. Puis, de parmi les modèles assortis, l'analyse de chiffre choisit la meilleure correspondance. Si deux modèles apparient également l'ordre des chiffres composés, l'analyse de chiffre sélectionne le modèle associé avec la partition répertoriée d'abord dans l'espace de recherche de partition (le pour en savoir plus, passent en revue la documentation au sujet du routage d'Étroit-correspondance).

Sécurité

Le Cisco CallManager peut être configuré pour créer un plan de numérotation sécurisé pour des utilisateurs. Ceci peut être fait par l'utilisation des partitions et les espaces de recherche de appeler, en plus d'un filtrage plus commun basé sur des sections « @ » de la macro-instruction (qui signifie le North American Numbering Plan) dans un modèle d'artère, tel que l'indicatif régional. Les partitions et les espaces de recherche de appeler sont une partie intégrante de Sécurité et sont particulièrement utiles pour des environnements de multi-locataire et créer un niveau d'utilisateur individuel. Le filtrage est un sous-ensemble du concept appelant de l'espace de recherche/partition qui peut ajouter la finesse supplémentaire au plan de la sécurité.

C'est une extension à la section de Plan de composition, en haut. Soyez informé, il n'est pas recommandé pour exécuter un suivi de SDI en essayant de réparer un problème de filtrage. Il n'y a pas assez d'informations et le potentiel pour entraîner le mal supplémentaire est trop grand.

Exécutez un tech d'exposition sur le Cisco CallManager. Les informations suivantes apparaissent dans la section de filtre d'artère.

Exposition-tech
Nom dialPlanWizardG Clause
CiscoDallasInte 1 (INTERNATIONAL-
CiscoRTPTollByP 1 (== 9 d'INDICATIF RÉGIONAL
CiscoRTPLongDis 1 (INDICATIF RÉGIONAL EXIS
CiscoDallasToll 1 (== 9 d'INDICATIF RÉGIONAL
CiscoDallas911R 1 (== 911 de SERVICE
CiscoRTPLocal7D 1 (L'INDICATIF RÉGIONAL FAIT
CiscoDallasLong 1 (INDICATIF RÉGIONAL EXIS
CiscoRTP911RF 1 (== 911 de SERVICE
CiscoRTPInterna 1 (INTERNATIONAL-
CiscoDallasLoca 1 (LOCAL-AREA-COD

Malheureusement, cet affichage est inachevé. Il, cependant, donne une liste de tous les filtres d'artère dans le système. La commande show ne te permet pas pour voir quels filtres sont associés avec lesquels modèle d'artère. Une autre méthode pour comprendre mieux le Plan de composition est d'aller à la page d'état de plan de routage. Est ci-dessous une option du côté droit lointain « de visualiser dans le fichier ».

file_dl.gif

La sortie sera un fichier virgule-séparé qui peut être visualisé dans Microsoft Excel ou une application semblable :

sortie de fichier d'Exposition-tech
Pattern/DN Partition Utilisation de modèle Nom du périphérique Description du périphérique
1000 Périphérique SEP003094C2635E Telecaster
1010   Périphérique SEP003094C2635E Telecaster
1111   Périphérique SEP00308062CDF1 SEP00308062CDF1
1211   Périphérique SEP00308062CDF1 SEP00308062CDF1
2999   Périphérique SAA0010EB007FFE SAA0010EB007FFE
4444   Périphérique SEP003094C26302 Invité
4500   Conférence  
9.@ CiscoRTPLocalPT Artère CiscoRTPLocalRL
9.@ CiscoDallasLocalPT Artère CiscoDallasLocalRL
9.@ CiscoRTPIntlPT Artère CiscoRTPIntlRL
9.@ CiscoDallasLongDistPT Artère CiscoDallasLongDistRL
9.@ CiscoRTP911PT Artère CiscoRTP911RL
9.@ CiscoRTPLongDistPT Artère CiscoRTPLongDistRL
9.@ CiscoTollByPassToDallasPT Artère CiscoTollByPassToDallasRL
9.@ CiscoDallasIntlPT Artère CiscoDallasIntlRL
9.@ CiscoDallas911PT Artère CiscoDallas911RL
9.@ CiscoTollByPassToRTPPT Artère CiscoTollByPassToRTPRL

Ceci affiche les modèles d'artère et leurs partitions correspondantes. Il n'affiche pas les filtres d'artère ou les espaces de recherche appelants des nombres de répertoire. Plus d'informations sont disponibles sur l'état réel de plan de routage. Si vous devez contacter Cisco TAC, vous devriez envoyer cette page par l'intermédiaire de l'email (si le Cisco CallManager est inaccessible).

Est ci-dessous un affichage des modèles d'artère, des partitions, et de la liste de routage/du groupe d'artère/passerelle.

route_plan_rpt.gif

Réponse lente de serveur

La réponse lente du serveur pourrait résulter si le duplex du commutateur n'apparie pas le duplex du serveur Cisco CallManager. Pour des performances optimales, placez le commutateur et le serveur à "100/Full." que nous ne recommandons pas utilisant le « automatique » sur le commutateur ou le serveur. Vous devez redémarrer le serveur Cisco CallManager pour que la modification la prenne effet.

Commandez à nouveau la tonalité par des passerelles

Les utilisateurs plaçant un appel par la passerelle pourraient obtenir une tonalité de réarrangement s'ils tentent de faire un appel restreint ou de demander un numéro qui a été bloqué. Une tonalité de réarrangement peut se produire si le numéro composé est hors service ou si le PSTN a un problème de matériel ou de service. Soyez sûr que le périphérique donnant la tonalité de réarrangement s'est enregistré. En outre, vérifiez votre configuration de Plan de composition pour s'assurer que l'appel peut être avec succès conduit.

Les étapes pour dépanner commandent à nouveau des tonalités par des passerelles :

  1. Vérifiez les passerelles pour s'assurer que vous utilisez les dernières charges logicielles.

  2. Vérifiez CCO (Cisco Connection Online chez www.cisco.com) pour les dernières charges logicielles, les nouveaux correctifs, ou les notes de mise à jour concernant le problème.

  3. Commencez un suivi de SDI et recréez le problème. Commandez à nouveau les tonalités pourrait être le résultat d'une question de configuration avec le contrôle d'admission géolocalisé ou le contrôle d'admission garde-porte garde-porte où le Cisco CallManager pourrait limiter le nombre d'appels permis. Dans le suivi de SDI, localisez l'appel pour déterminer s'il était bloqué intentionnellement par un modèle d'artère ou l'espace de recherche appelant, ou par n'importe quel autre paramètre de configuration.

  4. Commandez à nouveau les tonalités peut également se produire en appelant par le PSTN. Vérifiez le suivi de SDI pour des messages du débranchement Q.931. Si un message du débranchement Q.931 est présent, il signifie que l'autre interlocuteur a entraîné le débranchement et nous ne pouvons pas corriger cela.

Problèmes d'enregistrement de passerelle

Un des la plupart des problèmes courants produits avec des passerelles sur un Cisco CallManager est un problème d'enregistrement. L'enregistrement peut échouer pour des raisons diverses.

Cette section traite deux semblables, mais différents, des catégories de passerelles. Access analogique AS-X, AT-X et Digital Access DT-24+ et DE-30+ appartiennent à une catégorie. Ces passerelles sont des unités autonomes qui ne sont pas directement connectées à un processeur de gestion de réseau (NMP). La deuxième catégorie inclut Access analogique WS-X6624 et Digital Access WS-X6608. Ces passerelles sont des lames installées dans un châssis du Catalyst 6000 avec la connexion en direct sur le NMP pour le contrôle et statusing.

Dans les exemples ci-dessous, les messages étant expliqués sont identifiés utilisant le texte bolded. C'est de le faciliter pour que vous voyiez. Dans la sortie réelle d'affichage, le texte n'est pas bolded. Les exemples sont d'un WS-X6624.

La première chose à vérifier est que la passerelle est en service. Toutes les passerelles ont une « pulsation » DEL qui clignote 1-second en fonction, 1-second outre de quand le logiciel de passerelle s'exécute normalement. Si cette DEL ne clignote pas du tout, ou clignote très rapidement, alors le logiciel de passerelle ne s'exécute pas. Normalement, ceci aura comme conséquence une remise automatique de la passerelle. En outre, il est normal que la passerelle se remette à l'état initial s'il ne peut pas compléter la procédure d'enregistrement après environ 2 à 3 minutes. Ainsi, vous pouvez s'avérer justement regarder la pulsation DEL tandis que le périphérique remet à l'état initial. Si le modèle de clignotement normal n'apparaît pas en 10 à 15 secondes, alors la passerelle a souffert une panne sérieuse. Sur la passerelle AS-X ou AT-X, la pulsation DEL est le LED vert d'extrême droite affichant sur le panneau avant. Sur la passerelle DT-24+ ou DE-30+, c'est le LED rouge d'extrême gauche sur la périphérie supérieure de la carte. Sur Access analogique WS-X6624, c'est un LED vert à l'intérieur de la lame (non visible du panneau avant) du côté droit la périphérie de carte d'extrême droite près de l'avant. En conclusion, sur Digital Access WS-X6608 il y a une pulsation distincte DEL pour chacune des 8 envergures sur la lame. Il y a 8 LED rouges à travers la carte (non visible du panneau avant) environ 2/3 de la manière vers l'arrière.

La deuxième chose à vérifier est que la passerelle a reçu son adresse IP. Une passerelle autonome doit recevoir son adresse IP par l'intermédiaire du DHCP ou du Protocole BOOTP. Une passerelle de Catalyst peut recevoir son adresse IP par DHCP, Protocole BOOTP, ou par configuration manuelle par le NMP. Si vous avez accès au serveur DHCP, la meilleure manière de vérifier une passerelle autonome est de vérifier que le périphérique a un bail exceptionnel sur une adresse IP. Si la passerelle apparaît sur votre serveur, c'est une bonne indication, mais non définitive. Supprimez le bail au serveur DHCP, et puis remettez à l'état initial la passerelle. Si la passerelle réapparaît sur le serveur avec un bail dans quelques minutes, alors tout fonctionne bien dans cette zone. Sinon, alors ou la passerelle ne peut pas entrer en contact avec le serveur DHCP (est-il un routeur incorrectement configuré et n'expédiant pas des diffusions DHCP ? Est le serveur exécutant ?), ou ne peut pas obtenir une réaction favorable (est le groupe d'adresse IP épuisé ?). Si vérifier ces suggestions ne rapporte pas la réponse, employez un tracé de renifleur pour déterminer le problème spécifique.

Pour une passerelle du Catalyst 6000, vous devriez s'assurer que le NMP peut communiquer avec la passerelle. Vous pouvez vérifier ceci en essayant pour cingler son adresse IP interne du NMP. L'adresse IP est dans le format :

127.1.module.port

Ainsi, dans notre exemple, nous ferions :

Console (enable) ping 127.1.7.1

127.1.7.1 is alive

Si cinglant des travaux, alors la commande de show port affichera les informations d'adresse IP. Assurez-vous que les informations d'adresse IP et l'adresse IP TFTP sont correctes aussi bien. Si la passerelle n'obtient pas les informations valides DHCP, l'utilitaire de tracy (qui peut être fourni par Cisco TAC) peut être utilisé pour déterminer le problème. Émettez la commande du Cat6000 CLI :

port modèle de tracy_start

Dans cet exemple, le WS-X6624 est le module 7 et il a seulement un processeur 860 simple, ainsi c'est le port 1. La commande que nous émettrions est le tracy_start 7 1

La sortie suivante est réellement 860-console du port sur le panneau de passerelle lui-même. Cependant, la sortie de la commande de tracy n'est rien davantage qu'une copie distante du port 860-console.

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT

Si le message ci-dessus de délai d'attente continue à faire défiler par, alors il y a un problème contactant le serveur DHCP. Vérifiez que le port de passerelle du Catalyst 6000 est dans le VLAN correct.

Ces informations sont dans la commande de port show-++ d'avant. Si le serveur DHCP n'est pas sur le même VLAN que la passerelle du Catalyst 6000, alors veillez les adresses auxiliaires appropriées IP pour avoir été configuré pour expédier les requêtes DHCP au serveur DHCP. Il est possible que la passerelle soit bloqué dans l'état Init après qu'une modification de nombre VLAN jusqu'aux remises de passerelle. Quand dans cet état, vous pouvez essayer remettre à l'état initial la passerelle. Chaque fois que les 860 est remis à l'état initial, votre session de tracy sera perdue. Par conséquent, vous devez clôturer votre session existante et rétablir un neuf en émettant les commandes suivantes :

port modèle de tracy_close

port modèle de tracy_start

Si tout ce les contrôles et vous voient toujours les messages de DHCPState = INIT, alors contrôle pour voir si le serveur DHCP fonctionne correctement. Si oui, commencez un tracé de renifleur pour voir si les demandes sont envoyées et si le serveur répond.

Une fois que le DHCP fonctionne correctement, la passerelle aura une adresse IP qui permettra l'utilisation de l'utilitaire de mise au point de tracy. Cet utilitaire est une fonctionnalité intégrée de la commande NMP réglée pour les passerelles de Catalyst et est disponible comme application d'aide qui fonctionne sur Windows 98/NT/2000 pour les passerelles autonomes. Pour utiliser l'utilitaire de tracy d'application d'aide, vous avez besoin « vous connectez » à la passerelle à l'aide de l'adresse IP à laquelle elle est assignée. Cette application de tracy travaille à toutes les passerelles, fournit une fenêtre distincte de suivi pour chaque passerelle (jusqu'à huit peuvent être tracés immédiatement), et permet des suivis sont enregistré directement à un fichier que vous spécifiez.

L'étape suivante est de vérifier que l'adresse IP pour serveur TFTP a été correctement fournie à la passerelle. Ceci est normalement fourni par DHCP dans l'option 66 (de nom ou adresse IP), l'option 150 (adresse IP seulement), ou le si_addr (adresse IP seulement). Si votre serveur fait configurer des nombreuses options, le si_addr aura la priorité au-dessus de l'option 150, qui aura la priorité au-dessus de l'option 66. Si l'option 66 fournit le DNS_NAME du serveur TFTP, alors l'adresse IP de serveurs de DN doit avoir été spécifiée par DHCP, et le nom écrit dans l'option 66 doit le résoudre à l'adresse IP pour serveur TFTP correcte. Une passerelle de Catalyst pourrait être configurée par le NMP pour désactiver le DHCP, et l'opérateur NMP doit alors entrer tous les paramètres de configuration à la main à la console, y compris l'adresse du serveur TFTP.

Supplémentaire, les passerelles tenteront toujours de résoudre le nom "CiscoCM1" par l'intermédiaire des DN. Si réussi, l'adresse IP CiscoCM1 prendra à priorité au-dessus de n'importe quoi le serveur DHCP ou NMP l'indique pour l'adresse du serveur TFTP, même si le NMP a le DHCP désactivé.

Vous pouvez vérifier l'adresse IP pour serveur TFTP en cours dans une passerelle à l'aide de l'utilitaire de tracy. Sélectionnez la commande suivante d'obtenir le nombre de tâche de configuration :

TaskID : 0

Cmd : affichez le tl

Recherchez une ligne avec le « config » ou le « CFG » et utilisez le numéro correspondant comme taskID pour la prochaine ligne. Par exemple, pour la passerelle de Digital Access WS-X6624, la commande de vider les informations DHCP est :

TaskID : 6

Cmd : show dhcp

L'adresse IP pour serveur TFTP alors est clairement affichée. S'il n'est pas correct, vérifiez que vos options DHCP et d'autres informations qu'elles fournissent sont correctes.

Une fois que l'adresse TFTP est correcte, l'étape suivante est de s'assurer que la passerelle obtient son fichier de configuration du serveur TFTP. Si vous voyez le suivant dans la sortie de tracy, votre service TFTP peut ne pas fonctionner correctement ou la passerelle ne pourrait pas être configurée sur le Cisco CallManager :

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server

    00:09:18.620 (CFG) TFTP 
    Error: Timeout Awaiting Server Response for .cnf File!

La passerelle tentera de se connecter à la même adresse IP que le serveur TFTP si elle ne reçoit pas un fichier de configuration. C'est bien à moins que vous soyez dans un environnement groupé dans lequel la passerelle doit recevoir sa liste de Cisco CallManagers redondants. Si la carte ne reçoit pas ses informations TFTP correctement, vérifiez le service TFTP sur le Cisco CallManager et assurez-vous qu'il s'exécute. En outre, vérifiez le suivi TFTP sur le Cisco CallManager aussi bien.

Un autre problème courant est que la passerelle n'est pas configurée correctement sur le Cisco CallManager. Une erreur typique écrit une adresse MAC incorrecte pour la passerelle. Si c'est la caisse, pour une passerelle du Catalyst 6000, vous recevrez probablement les messages suivants sur le NMP consolez toutes les deux minutes :

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously

Est ce ce que la sortie de tracy ressemblerait à si la passerelle n'est pas dans la base de données Cisco CallManager :

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM

Un autre problème possible d'enregistrement pourrait être si les informations de chargement sont incorrectes ou le fichier de chargement est corrompu. Le problème pourrait également se poser si le serveur TFTP ne fonctionne pas. Dans ce cas, le tracy prouve clairement que le serveur TFTP a signalé que le fichier n'est pas trouvé :

00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse

Dans ce cas, vous pouvez voir que la passerelle demande le chargement A0021300 d'application, bien que le nom de chargement correct soit A0020300. Pour une passerelle du Catalyst 6000, le même problème peut se poser quand un chargement de nouvelle application doit obtenir son chargement correspondant DSP aussi bien. Si le nouveau chargement DSP n'est pas trouvé, un message semblable apparaîtra.

Les expositions suivantes la sortie quand Access analogique WS-X6224 a été configuré pour récupérer un chargement incorrect d'application. La sortie semble semblable à celle d'une passerelle qui n'a pas été configurée sur le Cisco CallManager :

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse

La différence ici est que la passerelle est bloqué dans l'étape de LoadResponse et chronomètre par la suite. Ce problème peut être résolu en corrigeant le nom du fichier de chargement dans le domaine de par défaut de périphérique du Cisco CallManager Administration.

Problèmes de garde-porte

Avant de commencer n'importe quel dépannage de passerelle-à-garde-porte, vérifiez qu'il y a de connectivité IP dans le réseau. En supposant qu'il y a de connectivité IP, employez les informations dans cette section pour dépanner votre passerelle.

Joncteurs réseau d'Inter-batterie seulement

Notez que le contrôle de garde-porte pour la version de Cisco CallManager 3.0(1) est seulement disponible pour des joncteurs réseau d'inter-batterie. Le contrôle de garde-porte est configurable pour d'autres périphériques, mais la configuration n'est pas prise en charge.

Anomalies d'admission (ARJ)

ARJs sont émis quand le Cisco CallManager s'est inscrit au garde-porte, mais ne peuvent pas envoyer un appel téléphonique. Les questions de configuration sur le garde-porte devraient être le foyer primaire quand le garde-porte émet un ARJ. Cependant, sont ci-dessous les directives générales pour le dépannage :

  1. Vérifiez la connectivité IP de la passerelle au garde-porte.

  2. Show gatekeeper status : vérifiez le garde-porte que l'état est en hausse.

  3. Y a-t-il une zone subnet définie sur le garde-porte ? Si oui, vérifiez que le sous-réseau de la passerelle est dans les sous-réseaux permis.

Anomalies d'enregistrement (RRJ)

RRJs sont émis quand le Cisco CallManager ne peut pas s'inscrire au garde-porte. Les questions de configuration sur le garde-porte devraient être le foyer primaire quand le garde-porte émet un RRJ.

Cependant, voici les directives générales pour le dépannage :

  1. Vérifiez la connectivité IP de la passerelle au garde-porte.

  2. Show gatekeeper status : vérifiez le garde-porte que l'état est en hausse.

  3. Y a-t-il une zone subnet définie sur le garde-porte ? Si oui, vérifiez que le sous-réseau de la passerelle est dans les sous-réseaux permis.

Jeûnez occupé en composant le numéro pilote de messagerie vocale

Si vous avez arrêté et gestionnaire d'appel commencé après avoir apporté à certains les modifications, assurez-vous que vous commencez des processus d'utel, d'ulite, d'ulogremover et d'upilot. Ceci a été testé dans le laboratoire par l'expéditeur pour cm 2.4.3 et uone 4.1e. Essentiellement les périphériques UM pas reregister avec le gestionnaire d'appel à moins que les processus soient redémarrés.

Étude de cas I : Appels de téléphone IP IP Téléphone-à-Cisco de Cisco d'Intra-batterie

Cette étude de cas discute en détail l'écoulement d'appel entre deux Téléphones IP de Cisco dans une batterie, appelée un appel intra-cluster. Cette étude de cas se concentre également sur le Cisco CallManager et l'initialisation de téléphone IP de Cisco, l'enregistrement, et les processus de keepalive. Cela est suivi par une explication détaillée d'un écoulement d'appel intra-cluster. Ces processus sont expliqués utilisant des utilitaires et des outils de suivi discutés dans une section précédente.

Exemple de topologie

Le diagramme suivant dépeint l'exemple de topologie pour cette étude de cas. Dans le diagramme il y a deux batteries nommées Cluster 1 et batterie 2. Les deux Cisco CallManagers dans la batterie 1 s'appellent CCM3 et le CCM4, alors que les deux Cisco CallManagers dans la batterie 1 sont nommés CCM1 et CCM2. Les suivis collectés pour cette étude de cas sont de CCM1, qui se trouve dans la batterie 2. L'écoulement d'appel est basé sur les deux Téléphones IP de Cisco dans la batterie 2. Les adresses IP de ces deux Téléphones IP de Cisco sont 172.16.70.230 (répertoire numéro 1000) et 172.16.70.231 (répertoire numéro 1001), respectivement.

ios_gatekeeper.gif

Processus d'initialisation de téléphone IP de Cisco

Processus d'initialisation de téléphone IP de Cisco (ou le « amorce ») est expliqué en détail ci-dessous.

  1. À l'initialisation, le téléphone IP de Cisco envoie une demande au serveur DHCP d'obtenir une adresse IP, une adresse de serveur de DNS, et un nom du serveur ou une adresse TFTP, si approprié. Des options sont placées dans le serveur DHCP (option 066, option 150, et ainsi de suite). Il obtient également une adresse de passerelle par défaut si réglé dans le serveur DHCP (option 003).

  2. Si un nom DNS du TFTP divisent est envoyé par DHCP, alors les DN divisent l'adresse IP est exigés pour tracer le nom à une adresse IP. Cette étape est sautée si le serveur DHCP envoie l'adresse IP du serveur TFTP. Étudiez dans ce cas, le serveur DHCP envoyé l'adresse IP du TFTP parce que des DN n'ont pas été configurés.

  3. Si un nom du serveur TFTP n'est pas inclus dans la réponse DHCP, alors le téléphone IP de Cisco utilise le nom du serveur par défaut.

  4. Le fichier du fichier de configuration (.cnf) est récupéré du serveur TFTP. Tous les fichiers .cnf ont le nom SEP<mac_address>.cnf, où « SEPT » est un acronyme pour le téléphone d'Ethernets de Selsius. Si c'est la première fois le téléphone s'inscrit au Cisco CallManager, alors un fichier par défaut, SEPdefault.cnf, est téléchargé au téléphone IP de Cisco. Étudiez dans ce cas, le premier téléphone IP de Cisco utilise l'adresse IP 172.16.70.230 (son adresse MAC est SEP0010EB001720), et le deuxième téléphone IP de Cisco utilise l'adresse IP 172.16.70.231 (son adresse MAC est SEP003094C26105).

  5. Tous les fichiers .cnf incluent l'adresse IP du Cisco CallManager primaire et secondaire. Le téléphone IP de Cisco emploie l'adresse IP pour entrer en contact avec le Cisco CallManager primaire et pour s'enregistrer.

  6. Une fois que le téléphone IP de Cisco s'est connecté et s'est inscrit au Cisco CallManager, le Cisco CallManager indique au téléphone IP de Cisco quelle version exécutable (appelée un ID de chargement) à s'exécuter. Si la version spécifiée n'apparie pas la version exécutante sur le téléphone IP de Cisco, le téléphone IP de Cisco demandera le nouvel exécutable du serveur TFTP et le remettra à l'état initial automatiquement.

L'exemple suivant de tracé de renifleur récapitule le processus d'initialisation de téléphone. Cet exemple de suivi n'est pas pris pour l'exemple de topologie de cette étude de cas, mais il fournit un exemple de la gamme d'événements qui se produisent pendant le processus d'initialisation de téléphone IP de Cisco.

sniffer_trace.gif

Procédure d'enregistrement maigre de station

Les Téléphones IP de Cisco communiquent avec le Cisco CallManager utilisant la station maigre Protocol de Cisco. La procédure d'enregistrement permet à une station maigre, telle qu'un téléphone IP de Cisco, pour informer le Cisco CallManager de son existence et pour faire l'appel possible. La figure suivante affiche les différents messages qui sont permutés entre le téléphone IP de Cisco (la « station ») et le Cisco CallManager.

/image/gif/paws/30266/skinny.gif

Les messages primaires dans la procédure d'enregistrement maigre de station sont décrits dans le tableau suivant.

Descriptions de procédure d'enregistrement maigres de station
Message Description
Registre de station La station envoie ce message pour annoncer son existence au Cisco CallManager de contrôle.
Remise de station Le Cisco CallManager envoie ce message pour commander la station pour remettre à l'état initial ses processus.
Port IP de station La station envoie ce message pour fournir au Cisco CallManager le port de Protocole UDP (User Datagram Protocol) à utiliser avec le flot de RTP.
Le registre de station reconnaissent Le Cisco CallManager envoie ce message pour reconnaître l'enregistrement d'une station.
Anomalie de registre de station Le Cisco CallManager envoie ce message pour rejeter une tentative d'enregistrement du téléphone indiqué.
 
char text[StationMaxDisplayTextSize]; 

};
Où : le texte est une chaîne de caractères, longueur maximale de 33 octets, contenant une description textuelle de la raison pour laquelle l'enregistrement est rejeté.
Demande de capacités de station Le Cisco CallManager envoie ce message pour demander les capacités en cours de la station. Les capacités de station peuvent inclure le compactage standard et d'autres H.323 capacités.
Demande de version de station La station envoie ce message pour demander le numéro de version de la charge logicielle pour la station.
Réponse de version de station Le Cisco CallManager envoie ce message pour informer la station du numéro de version logicielle approprié.
Réponse de capacités de station La station envoie ce message au Cisco CallManager en réponse à une demande de capacités de station. Les capacités de la station sont cachées dans le Cisco CallManager et utilisées pour être en pourparlers des capacités terminales avec un terminal H.323 conforme.
Demande de modèle de bouton de station La station envoie ce message pour demander la définition de modèle de bouton pour ce terminal spécifique ou téléphone IP de Cisco.
Réponse de modèle de bouton de station Le Cisco CallManager envoie ce message pour mettre à jour les informations de modèle de bouton contenues dans la station.
Demande de date de temps de station La station envoie ce message pour demander la date et heure actuelles pour l'utilisation interne et pour afficher comme chaîne de texte.
La station définissent la date et heure Le Cisco CallManager emploie ce message pour fournir la date et les informations horaires à la station. Il fournit la synchronisation horaire pour les stations.

Écoulement d'appel de téléphone IP IP Téléphone-à-Cisco de Cisco dans une batterie

Cette section décrit un téléphone IP de Cisco (répertoire numéro 1000) appelle un autre téléphone IP de Cisco (répertoire numéro 1001) dans la même batterie. La batterie est un groupe de Cisco CallManagers ayant une base de données SQL de Publisher de terrain communal et beaucoup de bases de données SQL d'abonné.

En notre exemple de topologie, CCM1 est l'éditeur et CCM2 est un abonné. Les deux Téléphones IP de Cisco (1000 et 1001) sont enregistrés à CCM1 et à CCM2, respectivement. L'écoulement d'appel est affiché dans le diagramme ci-dessous. Les deux Cisco CallManagers dans une batterie communiquent les uns avec les autres utilisant le Control Protocol d'Intra-batterie (ICCP). Quand un téléphone IP de Cisco disparaît le hors fonction-crochet, il ouvre une session maigre de station de contrôle (avec le TCP comme protocole sous-jacent) avec le Cisco CallManager. Après que la signalisation de Contrôle d'appel soit établie entre les deux Téléphones IP de Cisco et leurs Cisco CallManagers respectifs, le flot de RTP commence circuler directement entre les deux téléphones, suivant les indications du diagramme ci-dessous. Les messages maigres d'écoulement d'appel de station pour cet appel intra-cluster sont expliqués dans la section suivante.

/image/gif/paws/30266/1000_calls_1001.gif

Échange de téléphone IP IP Téléphone-à-Cisco de Cisco des messages maigres de station pendant l'écoulement d'appel

La figure suivante affiche un échange d'échantillon des messages entre deux stations maigres. La station maigre, ou le téléphone IP de Cisco, initie une connexion au Cisco CallManager, et alors le Cisco CallManager exécute l'analyse de chiffre avant d'ouvrir une session de contrôle avec la station maigre de destination. Pendant que le diagramme suivant indique, les messages maigres de station sont écrits utilisant l'anglais simple ainsi ils peuvent être aisément compris par des utilisateurs. Pour cette raison, ces messages ne sont pas expliqués dans cette section. Cependant, ces messages maigres de station d'écoulement d'appel sont expliqués plus en détail dans les sections postérieures quand des suivis sont examinés.

/image/gif/paws/30266/call_flow.gif

Processus d'initialisation de Cisco CallManager

Dans cette section le processus d'initialisation du Cisco CallManager sera expliqué avec l'aide des suivis qui sont capturés de CCM1 (identifié par l'adresse IP 172.16.70.228). Comme décrit précédemment, les suivis de SDI sont un outil très efficace de dépannage parce qu'ils détaillent chaque paquet envoyé entre les points finaux. Cette section décrira les événements qui se produisent quand le Cisco CallManager est initialisé. La compréhension comment lire le suivi aide vous à dépanner correctement les divers processus de Cisco CallManager, et l'effet de ces processus sur des services tels que des Conférences, transfert d'appel, et ainsi de suite.

Les messages suivants de l'exposition de service de suivi de SDI de Cisco CallManager le processus d'initialisation sur un des Cisco CallManagers, dans ce cas, CCM1. Passez en revue les descriptions de chaque message ci-dessous.

  • Le premier message indique que le Cisco CallManager a commencé son processus d'initialisation.

  • Le deuxième message indique que le Cisco CallManager a lu les valeurs par défaut de base de données, qui seraient la base de données primaire ou d'éditeur (pour ce cas).

  • Le troisième message indique que le Cisco CallManager a écouté les divers messages sur le port TCP 8002.

  • Le quatrième message prouve que, après avoir écouté ces messages, le Cisco CallManager a ajouté un deuxième Cisco CallManager à sa liste : CCM2 (172.16.70.229).

  • Le cinquième message indique que le Cisco CallManager a commencé et est version 3.0.20 courante de Cisco CallManager.

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3.0(0.20)> started

Auto-démarrer des processus

Une fois que le Cisco CallManager est en service, il commence plusieurs autres processus dans lui-même. Certains de ces processus sont affichés ci-dessous, y compris le gestionnaire de MulticastPoint, le gestionnaire d'UnicastBridge, l'analyse de chiffre, et la liste de routage. Les messages décrits pendant ces processus peuvent être pour le dépannage très utile par problème lié aux caractéristiques dans le Cisco CallManager.

Par exemple, supposez que les listes de routage ne fonctionnent pas et sont inutilisables. Pour dépanner ce problème, vous surveilleriez ces suivis pour déterminer si le Cisco CallManager a commencé RoutePlanManager et s'il essaye de charger les listes de routage. Dans la configuration d'échantillon ci-dessous, RouteListName= '' ipwan » et RouteGroupName= '' ipwan » chargent et commencent.

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''

Le suivi suivant affiche le RouteGroup ajoutant le périphérique 172.16.70.245, qui est CCM3 situé dans la batterie 1 et a considéré H.323 un périphérique. Dans ce cas, le RouteGroup est créé pour conduire des appels à CCM3 dans la batterie 1 avec l'autorisation de garde-porte de Cisco IOS. S'il y a un problème conduisant l'appel à un téléphone IP de Cisco situé dans la batterie 1, alors les messages suivants vous aideraient à trouver la cause du problème.

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts

Une partie du processus d'initialisation prouve que le Cisco CallManager ajoute des dn. En passant en revue ces messages, vous pouvez déterminer si le Cisco CallManager a lu le nombre de répertoire de la base de données.

16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, 
NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started

Dans les suivis suivants le gestionnaire de périphériques dans le Cisco CallManager initialise statiquement deux périphériques. Le périphérique avec l'adresse IP 172.17.70.226 est un garde-porte et le périphérique avec l'adresse IP 172.17.70.245 est un autre Cisco CallManager dans une batterie différente. Ce Cisco CallManager est enregistré comme passerelle H.323 avec ce Cisco CallManager.

16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245

Procédure d'enregistrement de Cisco CallManager

Une autre partie importante du suivi de SDI est la procédure d'enregistrement. Quand un périphérique est mis sous tension, il obtient les informations par l'intermédiaire du DHCP, se connecte au serveur TFTP pour son fichier .cnf, et puis se connecte au Cisco CallManager spécifié dans le fichier .cnf. Le périphérique a pu être une passerelle MGCP, un skinny gateway, ou un téléphone IP de Cisco. Par conséquent, il est important de pouvoir découvrir si les périphériques se sont avec succès enregistrés sur le réseau de Cisco AVVID.

Dans le suivi suivant, le Cisco CallManager a reçu de nouvelles connexions pour l'enregistrement. Les périphériques de enregistrement sont "MTP_nsa-cm1" (services MTP sur CCM1), et "CFB_nsa-cm1" (service de passerelle de conférence sur CCM1). Ce sont des assistances logiciel s'exécutant sur le Cisco CallManager mais sont traitées intérieurement en tant que différents services externes et sont donc assignées un TCPHandle, numéro de prise, et numéro de port aussi bien qu'un nom du périphérique.

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, 
Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, 
Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

Dans le suivi suivant, des messages maigres de station sont envoyés entre un téléphone IP de Cisco et un Cisco CallManager. Le téléphone IP de Cisco (172.16.70.231) s'inscrit au Cisco CallManager. Référez-vous aux descriptions des messages maigres de station plus tôt dans ce pour en savoir plus de section. Dès que le Cisco CallManager recevra la demande d'enregistrement d'un téléphone IP de Cisco, il assigne un nombre de TCPHandle à ce périphérique. Ce nombre demeure le même jusqu'au périphérique ou le Cisco CallManager est redémarré. Par conséquent, vous pouvez suivre tous les événements liés à un périphérique particulier en recherchant ou en maintenant le nombre de TCPHandle du périphérique, qui apparaît dans l'hexa. En outre, notez que le Cisco CallManager fournit l'ID de chargement au téléphone IP de Cisco. Basé sur cet ID de chargement, le téléphone IP de Cisco exécute le fichier exécutable (saisi du serveur TFTP) qui correspond au périphérique.

16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, 
Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:57.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, 
TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr 
LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" 
Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) 
tcpHandle=0x4fbbc30

Processus de keepalive de Cisco CallManager

La les deux la station, le périphérique, ou le service et le Cisco CallManager emploient les messages suivants pour mettre à jour une connaissance de la voie de transmissions entre eux. Les messages sont utilisés pour commencer l'ordre de keepalive qui s'assure que la liaison entre le Cisco CallManager et la station demeure active. Les messages suivants peuvent provenir du Cisco CallManager ou de la station.

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=
[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=
[1,85,1]

Les messages dans le suivi suivant dépeignent l'ordre de keepalive qui indique que la liaison entre le Cisco CallManager et la station est en activité. De nouveau, ces messages peuvent commencer par le Cisco CallManager ou la station.

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Suivis d'écoulement d'appel intra-cluster de Cisco CallManager

Les suivis suivants de SDI explorent en détail l'écoulement d'appel intra-cluster. Les Téléphones IP de Cisco dans l'écoulement d'appel peuvent être identifiés par le DN, le tcpHandle, et l'adresse IP. Un téléphone IP de Cisco (DN=1001, tcpHandle=0x4fbbc30, IP address=172.16.70.231) situé dans la batterie 2 appelle un autre téléphone IP de Cisco dans la même batterie (DN=1000, tcpHandle= 0x4fbb150, adresse IP = 172.16.70.230). Souvenez-vous que vous pouvez suivre un périphérique par le suivi en regardant la valeur de traitement de TCP, le groupe date/heure, ou le nom du périphérique. La valeur de traitement de TCP pour le périphérique demeure la même jusqu'à ce que le périphérique soit redémarré ou va off-line.

Les suivis suivants prouvent que le téléphone IP de Cisco (1001) a disparu le hors fonction-crochet. Le suivi ci-dessous affiche les seuls messages, le traitement de TCP, et le numéro appelé ce qui sont affichés sur le téléphone IP de Cisco. Il n'y a aucun numéro d'appel en ce moment, parce que l'utilisateur n'a pas essayé de ne composer aucun chiffre. Les informations ci-dessous sont sous forme de messages maigres de station entre les Téléphones IP de Cisco et le Cisco CallManager.

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

Le prochain suivi affiche les messages maigres de station allant du Cisco CallManager à un téléphone IP de Cisco. Le premier message est d'activer la lampe sur le téléphone IP de Cisco de l'appelant.

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

Le message de stationOutputCallState est utilisé par Cisco CallManager pour informer la station de certaines informations liées à l'appel.

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

Le message de stationOutputDisplayPromptStatus est utilisé par Cisco CallManager pour causer un message prompt lié à l'appel d'être affiché sur le téléphone IP de Cisco.

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

Le message de stationOutputSelectSoftKey est utilisé par Cisco CallManager pour faire sélectionner la station maigre un ensemble spécifique de clés douces.

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

Le prochain message est utilisé par Cisco CallManager pour instruire la station maigre quant à la ligne correcte contexte pour l'affichage.

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

Dans le message suivant, le processus d'analyse de chiffre est prêt à identifier les chiffres entrants et aux examiner pour assurer les correspondances potentielles de routage dans la base de données. L'entrée, cn=1001, représente le numéro de l'appelant. le "" de dd= représente le chiffre composé, qui afficherait le numéro de pièce appelé. Notez que des messages de StationInit sont envoyés par le téléphone, des messages de StationD sont envoyés par Cisco CallManager, et l'analyse de chiffre est exécutée par Cisco CallManager.

16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

Le message de débogage suivant prouve que le Cisco CallManager fournit la tonalité intérieure au téléphone IP de Cisco d'appelant.

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

Une fois que le Cisco CallManager détecte un message entrant et identifie le bouton 1 de pavé numérique a été appuyé sur sur le téléphone IP de Cisco, il arrête immédiatement la tonalité de sortie.

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

Une fois que le Cisco CallManager a reçu assez de chiffres pour s'assortir, il fournit les résultats d'analyse de chiffre dans un format de table. Tous chiffres supplémentaires appuyés sur au téléphone après que ce point soit ignoré par Cisco CallManager, puisqu'une correspondance a été déjà trouvée.

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

Le prochain suivi prouve que le Cisco CallManager envoie ces informations à un téléphone d'appelé (le téléphone est identifié par le nombre de tcpHandle).

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150

Le prochain suivi indique que le Cisco CallManager commande la lampe clignoter pour l'indication d'appel entrant sur le téléphone IP de Cisco de l'appelé.

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampBlink tcpHandle=0x4fbb150

Dans les suivis suivants, le Cisco CallManager fournit la sonnerie, affiche la notification, et d'autres informations liées à l'appel au téléphone IP de Cisco de l'appelé. De nouveau, vous pouvez voir que tous les messages sont dirigés vers le même téléphone IP de Cisco parce que le même tcpHandle est utilisé dans tous les suivis.

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

Notez que le Cisco CallManager fournit également les informations semblables au téléphone IP de Cisco de l'appelant. De nouveau, le tcpHandle est utilisé pour différencier entre les Téléphones IP de Cisco.

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30

Dans le prochain suivi, le Cisco CallManager fournit une tonalité d'alerte ou de sonnerie au téléphone IP de Cisco de l'appelant, annonçant que la connexion a été établie.

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

En ce moment, le téléphone IP de Cisco de l'appelé disparaît le hors fonction-crochet. Par conséquent, le Cisco CallManager cesse de générer la tonalité de sonnerie à l'appelant.

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

Dans les messages suivants, le Cisco CallManager fait commencer la station maigre recevant un flot de RTP d'Unicast. Pour faire ainsi, le Cisco CallManager fournit l'adresse IP des informations d'appelé aussi bien que de codecs, et de la longueur de paquet dans la milliseconde (millisecondes). PacketSize est un entier contenant le temps d'échantillonnage en quelques millisecondes utilisées pour créer les paquets de RTP.

Remarque: Cette valeur est normalement placée à 30msec. Dans ce cas, il est placé à 20msec.

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 
myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

De même, le Cisco CallManager fournit des informations à l'appelé (1000).

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 
myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

Le Cisco CallManager a reçu le message d'accusé de réception de l'appelé pour établir le canal ouvert pour le flot de RTP, aussi bien que l'adresse IP de l'appelé. Ce message est d'informer le Cisco CallManager de deux informations au sujet de la station maigre. D'abord, il contient le statut de l'action ouverte. En second lieu, il contient l'adresse du port et le nombre de réception pour la transmission à l'extrémité distante. L'adresse IP de l'émetteur (appelle la partie) du flot de RTP est ipAddr, et PortNumber est le numéro de port IP de l'émetteur de flot de RTP (appelant).

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2

Les messages suivants sont utilisés par Cisco CallManager pour commander la station pour commencer transmettant le flux audio à l'adresse IP distante et au numéro de port du téléphone IP indiqué de Cisco.

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 
myIP: e74610ac 
(172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

Dans les suivis suivants, les messages précédemment expliqués sont envoyés à l'appelé. Ces messages sont suivis par les messages indiquant que le flux multimédia de RTP a commencé entre appelé et l'appelant.

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 
myIP: e64610ac 
(172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Le téléphone IP de Cisco de l'appelant va finalement avec combiné raccroché, qui termine tous les messages de contrôle entre la station et le Cisco CallManager maigres, aussi bien que le flot de RTP entre les stations maigres.

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Étude de cas II : Appels de passerelle IOS IP Téléphone-à-Cisco de Cisco

Dans l'étude de cas précédente, l'écoulement d'appel et les techniques de dépannage d'un appel intra-cluster ont été discutés en détail. Cette étude de cas examine un téléphone IP de Cisco faisant appel par une passerelle de Cisco IOS à un téléphone connecté par des gens du pays PBX ou quelque part au PSTN. Conceptuellement, quand l'appel atteint la passerelle de Cisco IOS, la passerelle expédiera à l'appel l'un ou l'autre à un téléphone s'arrêtant hors fonction de son port de devises étrangères de la station (FXS), ou au PBX. Si l'appel est expédié au PBX, il pourrait se terminer à un téléphone s'arrêtant hors fonction des gens du pays PBX ou le PBX les expédiera au-dessus du PSTN et l'appel se terminera quelque part sur le PSTN.

Exemple de topologie

Le diagramme suivant affiche l'exemple de topologie pour cette étude de cas. Des appels sont conduits par les passerelles de Cisco IOS et l'interface au PSTN, ou le PBX est T1/CAS ou T1/PRI. Les passerelles peuvent être les modèles 26XX, 36XX, 53XX ou 6K.

/image/gif/paws/30266/ios_gatekeeper2.gif

Traces des appels

Cette section discute l'appel traversent des exemples à partir du fichier de suivi CCM000000000 de Cisco CallManager (référez-vous à la section précédente pour l'emplacement du fichier). Les suivis étudient dans ce cas le foyer seulement sur l'écoulement d'appel lui-même, car les informations plus détaillées de suivi ont été déjà expliquées dans l'étude de cas précédente (initialisation, enregistrement, mécanisme de keepalive, et ainsi de suite).

Dans cet écoulement d'appel, un téléphone IP de Cisco (répertoire numéro 1001) situé dans la batterie 2 appelle un téléphone (répertoire numéro 3333) situé quelque part sur le PSTN. Souvenez-vous que vous pouvez suivre un périphérique par le suivi en regardant la valeur de traitement de TCP, le groupe date/heure, ou le nom du périphérique. La valeur de traitement de TCP pour le périphérique demeure la même jusqu'à ce que le périphérique soit redémarré ou va off-line.

Dans les suivis suivants, le téléphone IP de Cisco (1001) a disparu le hors fonction-crochet. Le suivi affiche les seuls messages, le traitement de TCP, et le numéro d'appel, qui est affiché sur le téléphone IP de Cisco. Il n'y a aucun numéro appelé en ce moment parce que l'utilisateur n'a pas essayé de ne composer aucun chiffre.

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim ? OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001 

Dans les suivis suivants, l'utilisateur compose les 3333, un chiffre à la fois. Le numéro 3333 est le numéro de destination du téléphone, qui se trouve quelque part sur le réseau PSTN. Le processus d'analyse de chiffre du Cisco CallManager est actuellement - active et analyse les chiffres pour découvrir où l'appel doit être conduit. Une explication plus détaillée de l'analyse de chiffre a été fournie dans l'étude de cas précédente.

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

Dans les suivis suivants, l'analyse de chiffre a été terminée, appeler et appelé a été concurrencé, et les informations ont été analysées.

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

Dans les suivis suivants, le numéro 0 indique l'emplacement d'origine, et le numéro 1 indique l'emplacement de destination. La bande passante de l'emplacement d'origine est déterminée par BW = 1. La valeur 1 implique que la bande passante est infinie. La bande passante est infinie parce que l'appel a été provenu d'un téléphone IP de Cisco situé dans un environnement de RÉSEAU LOCAL. La bande passante de l'emplacement de destination est déterminée par BW = 64. La destination d'appel est à un téléphone situé dans un PSTN, et le type de codecs est utilisé est G.711 (des 64 Kbits/s).

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

Les suivis suivants affichent appeler et les informations d'appelé. Dans cet exemple, le nom et le nombre d'appelant est identique parce que l'administrateur n'a pas configuré un nom d'affichage, tel que « John Smith. »

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98

Avant de passer en revue les suivis suivants, il est important de comprendre la signification du terme H.323. Par une brève explication, il y a plusieurs protocoles qui sont utilisés en établissant H.323 une session. Un protocole est H.225, qui est principalement utilisé pour la signalisation d'appel et est un sous-ensemble de Q.931. Un autre protocole est H.245, qui est utilisé pour l'échange de capacité. Une des fonctions plus importantes de H.245 est la négociation de type de compresseur/décompresseur (codec), telle que G.711, G.729, et ainsi de suite, entre appeler et le côté appelé. Une fois que l'échange de capacité est complet, la prochaine importante fonction de H.245 exécute une négociation de port UDP entre appeler et les côtés appelés.

Le suivi suivant prouve que H.323 le code a été initialisé et envoie un message de configuration H.225. Vous pouvez également voir les messages traditionnels HDLC SAPI, l'adresse IP du côté appelé dans l'hexa, et les numéros de port.

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)

Le suivi suivant affiche appeler et les informations d'appelé, aussi bien que le message d'alerte H.225. Également affiché est le mappage de la valeur hexadécimale d'un téléphone IP de Cisco à l'adresse IP. 172.16.70.231 est l'adresse IP du téléphone IP de Cisco (1001).

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)

Le suivi suivant affiche le type de compactage utilisé pour cet appel (G.711 Ý-loi).

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Une fois que le message d'alerte H.225 a été envoyé, la prochaine partie de H.323 est initialisent : H.245. Le suivi suivant affiche les informations de appeler et d'appelé et les messages H.245. Notez que la valeur de traitement de TCP est identique qu'avant, le témoin de ceci est la suite du même appel.

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding

Le suivi suivant affiche que les H.225 connectent le message, aussi bien que d'autres informations qui ont été expliquées plus tôt. Quand les H.225 se connectent le message est reçu, l'appel a été connecté.

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 
myIP: e74610ac 
(172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 
16758 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)

Le message suivant prouve qu'un message avec combiné raccroché du téléphone IP de Cisco (1001) est reçu. Dès qu'un message avec combiné raccroché sera reçu, les H.225 et les messages maigres de débranchement sont envoyés et le message H.225 entier est vu. Ce message final indique que l'appel a été terminé.

15:20:27.296 CCM|StationInit - InboundStim ? OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending 
disconnect to (64,5) and remove 
connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP:
 e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol

Messages de débogage et commandes show sur le garde-porte de Cisco IOS

Dans la section précédente, le suivi de SDI de Cisco CallManager a été discuté en détail. Dans la topologie pour cette étude de cas, le debug ras a été activé dans le garde-porte de Cisco IOS.

Les messages de débogage suivants prouvent que le garde-porte de Cisco IOS reçoit la demande d'admission (ARQ) du Cisco CallManager (172.16.70.228), suivi d'autres messages réussis RAS. En conclusion, le garde-porte de Cisco IOS envoie un message (ACF) confirmé par admission au Cisco CallManager.

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

Les messages de débogage suivants prouvent que l'appel est en cours.

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 
55 from 172.16.70.228883

Les messages de débogage suivants prouvent que le garde-porte de Cisco IOS a reçu une demande désengagée (DRQ) du Cisco CallManager (172.16.70.228), et le garde-porte de Cisco IOS a envoyé un désengagement confirmé (DCF) au Cisco CallManager.

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 
from 172.16.70.228883

Le show gatekeeper endpoints de commande sur le garde-porte de Cisco IOS prouve que chacun des quatre Cisco CallManagers est inscrit au garde-porte de Cisco IOS. Souvenez-vous cela dans la topologie pour cette étude de cas, là soyez quatre Cisco CallManagers, deux dans chaque batterie. Ce garde-porte de Cisco IOS a deux zones et chaque zone a deux Cisco CallManagers.

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW
H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW
H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4

Messages de débogage et commandes show sur la passerelle de Cisco IOS

Dans la section précédente, les commandes show et les sorties de débogage de garde-porte de Cisco IOS ont été discutées en détail. Cette section se concentre sur la sortie de débogage et les commandes show sur la passerelle de Cisco IOS. Dans la topologie pour cette étude de cas, les appels vont par les passerelles de Cisco IOS. La passerelle de Cisco IOS se connecte par interface au PSTN ou au PBX aux interfaces T1/CAS ou T1/PRI. La sortie de débogage des commandes telles que le debug voip ccapi inout, le debug h225 events, et le debug h225 asn1 sont affichés ci-dessous.

Dans la sortie de débogage suivante, la passerelle de Cisco IOS reçoit la demande de connexion TCP du Cisco CallManager (172.16.70.228) sur le port 2328 pour H.225.

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 
172.16.70.228:2328 on socket [1]
*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

La sortie de débogage suivante prouve que les données H.225 proviennent le Cisco CallManager sur cette session TCP. Dans cette sortie de débogage il est important de noter l'identificateur de protocole, qui indique H.323 la version étant utilisée. Ce qui suit met au point prouve que H.323 la version 2 est utilisée. Appelé et les numéros de l'appelant sont également affichés.

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:57.177: H225Lib::h225RecvData: Q.931 SETUP received from socket 
[1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:57.185: destinationAddress
*Mar 12 04:03:57.185: {
*Mar 12 04:03:57.185: e164 : "3333"
*Mar 12 04:03:57.185: },
*Mar 12 04:03:57.189: H225Lib::h225RecvData: State changed to [Call Present].

Ce qui suit est sortie de débogage pour l'interface de programmation de Contrôle d'appel (CCAPi). CCAPi indique un appel entrant. Les informations appelé et d'appelant peuvent également être vues dans la sortie suivante. CCAPi apparie le pair de cadran 0, qui est l'homologue de numérotation par défaut. Il apparie le pair de cadran 0 parce que le CCAPi ne pourrait trouver aucun autre pair de cadran pour le numéro d'appel, ainsi il utilise l'homologue de numérotation par défaut.

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, 
calling=1001, fdest=1 
peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, 
*callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, 
guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

Le CCAPi apparie le cadran-pair 1 avec le modèle de destination, qui est le numéro appelé 3333. Souvenez-vous que le peer_tag signifie le pair de cadran. Notez appeler et le numéro appelé dans le paquet de demandes.

*Mar 12 04:03:57.193: peer_tag=1
*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, 
callParams={called=3333, calling=1001, 
fdest=1, voice_peer_tag=1}, mode=0x0)

La sortie de débogage suivante prouve que les messages d'alerte H.225 reviennent au Cisco CallManager.

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12,
 prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)
-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0
)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, 
dstCallID=0x12, 
disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205: destinationInfo
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: mc FALSE,
*Mar 12 04:03:57.205: undefinedNode FALSE
*Mar 12 04:03:57.205: },

Avis en ce paquet que le Cisco IOS envoie également l'adresse H.245 et le numéro de port au Cisco CallManager. Parfois la passerelle de Cisco IOS enverra l'adresse inaccessible, qui ne pourrait entraîner aucun audio sonore ou à sens unique.

*Mar 12 04:03:57.205: h245Address ipAddress :
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: ip 'AC1046E2'H,
*Mar 12 04:03:57.205: port 011008
*Mar 12 04:03:57.205: },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213:
*Mar 12 04:03:57.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. 
Call state changed to [Call 
Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12,
 dstCallID=0x11, 
disposition=0, tag=0x0)

La sortie de débogage suivante prouve que la session H.245 est soulevée. Vous pouvez voir l'indication de capacité pour la négociation de codecs, aussi bien que combien d'octets seront présents dans chaque paquet vocal.

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12,
 caps={codec=0xEBFB, 
fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)
-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

La sortie de débogage suivante prouve que les deux interlocuteurs ont négocié correctement et étaient d'accord sur G.711 des codecs avec 160 octets de données.

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, 
srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323 les messages de connecter et de débranchement peuvent être vus ci-dessous.

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)
-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-uu-pdu
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-message-body connect :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373: h245Address ipAddress :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.377: ip 'AC1046E2'H,
*Mar 12 04:03:59.377: port 011008
*Mar 12 04:03:59.377: },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)

Passerelle de Cisco IOS avec l'interface T1/PRI

Comme expliqué plus tôt, il y a deux types d'appels allant par les passerelles de Cisco IOS : la passerelle de Cisco IOS se connecte par interface au PSTN ou au PBX, aux interfaces T1/CAS ou T1/PRI. Ce qui suit sont les sorties de débogage quand les passerelles de Cisco IOS utilisent l'interface T1/PRI.

La commande de debug isdn q931 sur la passerelle de Cisco IOS a été activée. Ceci active Q.931, un protocole de signalisation de la couche trois pour le canal D dans l'environnement RNIS. Chaque fois que un appel est placé hors de l'interface T1/PRI, un paquet d'installation doit être envoyé. Le paquet d'installation a toujours (descripteur de protocole) palladium = 8, et il génère une valeur hexadécimale aléatoire pour le callref. Le callref est utilisé pour dépister l'appel. Par exemple, si deux appels sont placés, la valeur de callref peut déterminer l'appel pour lequel le message RX (reçu) est destiné. La capacité de support 0x8890 signifie un appel des données 64kb/s. Si c'étaient un 0x8890218F, ce serait un appel des données 56kb/s. Ce serait 0x8090A3 si c'étaient une communication voix. Dans la sortie de débogage ci-dessous, la capacité de support est 0x8090A3, qui est pour la Voix. Appelé et des numéros de l'appelant sont également affichés.

Le callref emploie une valeur différente pour le premier chiffre (pour différencier entre TX et RX) et la deuxième valeur est identique (l'INSTALLATION a eu un 0 pour le dernier chiffre, et CONNECT_ACK a également un 0). Le routeur dépend complètement du PSTN ou du PBX pour assigner un canal de support (la Manche). Si le PSTN ou le PBX n'assigne pas un canal au routeur, l'appel ne sera pas conduit. Dans notre cas, un message de CONNECTER est reçu du commutateur avec le même numéro de référence qu'a été reçu pour ALERTER (0x800B). En conclusion, vous pouvez voir l'échange du message de DÉBRANCHEMENT suivi de la VERSION et RELÂCHER des messages _COMP pendant que l'appel est déconnecté. Des messages RELEASE_COMP sont suivis par un ID de cause pour le rejet d'appel. L'ID de cause est une valeur hexadécimale. La signification de la cause peut être trouvée en décodant la valeur hexadécimale et la continuation avec votre fournisseur.

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ?1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ?3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept,
 call blocked group restriction 

Passerelle de Cisco IOS avec l'interface T1/CAS

Comme expliqué plus tôt, il y a deux types d'appels allant par les passerelles de Cisco IOS : l'interface de passerelle de Cisco IOS au PSTN ou au PBX, avec des interfaces T1/CAS ou T1/PRI. Ce qui suit sont les sorties de débogage quand les passerelles de Cisco IOS a l'interface T1/CAS. Le debug cas sur la passerelle de Cisco IOS a été activé.

Le message de débogage suivant prouve que la passerelle de Cisco IOS envoie un signal décroché au commutateur.

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111) 

Le message de débogage suivant indique que le commutateur envoie le clin d'oeil après réception du signal de fermeture de boucle de la passerelle de Cisco IOS.

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

Le message de débogage suivant indique que la passerelle de Cisco IOS va le hors fonction-crochet.

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

Ce qui suit est la sortie du brief de show call active voice sur la passerelle de Cisco IOS quand l'appel est en cours. Appelé et le numéro de l'appelant et d'autres informations utiles sont également affichés.

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid: <peer_id> <dir> <addr> <state> tx: <packets>/<bytes>
 rx:<packets>/<bytes>
<state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> 
delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> (payload size) 
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548 
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm

Éprouvant le signal d'occupation après composition des numéros internationaux

Problème

L'utilisateur a cm 2.4.4 avec un modèle approprié d'artère assigné à sa passerelle DT-24+. Il peut composer des gens du pays et des numéros interurbains des USA sans des problèmes. Cependant quand il poinçonne les chiffres pour un numéro international, il entend une pause, et puis un signal d'occupation.

Solution

Ceci a été vu dans le passé où le commutateur CO ne sait pas traiter correctement l'IE d'appel (élément d'information). Ceci peut être réparé en plaçant l'appelant de gestionnaire d'appel que le type IE « a placé le DN de appeler et de type appelé à l'inconnu » sous les paramètres d'envergure DT24+.

Étude de cas III : Appels de téléphone IP IP Téléphone-à-Cisco de Cisco d'Inter-batterie

Dans les études de cas précédentes, l'écoulement d'appel et les techniques de dépannage d'un appel intra-cluster et d'un téléphone IP de Cisco appellent par une passerelle de Cisco IOS à un téléphone s'arrêtant hors fonction des gens du pays PBX ou quelque part sur le PSTN ont été discutés en détail. Cette étude de cas examine un téléphone IP de Cisco appelle un autre téléphone IP de Cisco situé dans une batterie différente. Ce type d'appel est également connu comme appel de téléphone IP de Cisco d'inter-batterie.

Exemple de topologie

Ce qui suit est l'exemple de topologie utilisé dans ce cas étudie. Cette topologie a deux batteries, chacun qui a deux Cisco CallManagers. Il y a également des passerelles de Cisco IOS et un garde-porte de Cisco IOS en place.

/image/gif/paws/30266/ios_gatekeeper3.gif

D'Inter-batterie transmission H.323

Comme vous pouvez voir dans la topologie, le téléphone IP de Cisco dans la batterie 1 fait un appel au téléphone IP de Cisco dans la transmission de Cisco CallManager d'Inter-batterie de la batterie 2. a lieu utilisant H.323 le protocole de version 2. Il y a également un garde-porte de Cisco IOS pour le contrôle d'admission. L'explication détaillée de la sortie de débogage et des commandes show, et l'interaction entre le garde-porte de Cisco IOS et la passerelle de Cisco IOS et les périphériques de Cisco CallManager, peuvent être passées en revue dans les sections précédentes.

Le procédé d'écoulement d'appel est affiché dans le diagramme ci-dessous. Le téléphone IP de Cisco peut parler au Cisco CallManager par l'intermédiaire du protocole maigre de station, et le Cisco CallManager peut parler avec le garde-porte de Cisco IOS utilisant H.323 le protocole RAS. Le message de demande d'admission (ARQ) est envoyé au garde-porte de Cisco IOS, qui envoie le message confirmé par admission (ACF) après vérification que l'appel inter-cluster peut être fait utilisant H.323 le protocole de version 2. Une fois que fait, le chemin audio est fait utilisant le protocole de RTP entre les Téléphones IP de Cisco dans différentes batteries.

/image/gif/paws/30266/gatekeeper_flow.gif

Traces des appels

Cette section discute l'écoulement d'appel utilisant des exemples de suivi de SDI capturés dans le fichier CCM000000000. L'emplacement de ce fichier peut être trouvé dans la section précédente. Les suivis discutés dans ce cas étudient le foyer seulement sur l'écoulement d'appel lui-même, parce que les informations plus détaillées de suivi ont été déjà expliquées dans l'étude de cas précédente (initialisation, enregistrement, mécanisme de keepalive, et ainsi de suite.)

Dans cet écoulement d'appel, un téléphone IP de Cisco (2002) situé dans la batterie 2 appelle un téléphone IP de Cisco (1001) situé dans la batterie 1. se souviennent que vous pouvez suivre un périphérique par le suivi en regardant la valeur de traitement de TCP, le groupe date/heure, ou le nom du périphérique. La valeur de traitement de TCP pour le périphérique demeure la même jusqu'à ce que le périphérique soit redémarré ou va off-line.

Dans les suivis suivants, le téléphone IP de Cisco (2002) a disparu le hors fonction-crochet. Le suivi affiche les seuls messages, le traitement de TCP, et le numéro d'appel, qui est affiché sur le téléphone IP de Cisco. Le numéro appelé (1001), H.225 se connectent, et H.245 confirment des messages peuvent être vus dans la sortie de débogage suivante. Le type de codecs est G.711 Ý-loi.

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310,
 Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

Appeler et le numéro appelé, qui est associé avec une adresse IP et une valeur hexadécimale, peuvent être vus dans les suivis suivants.

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310
 myIP: e74610ac 
(172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 

Les suivis suivants affichent les longueurs de paquet et l'adresse MAC du téléphone IP de Cisco (2002). Ces suivis sont suivis par le débranchement, puis les messages avec combiné raccroché.

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to 
(64,2) and remove 
connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2)
 from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

Écoulement d'appel défaillant

La section suivante décrit un écoulement infructueux d'appel inter-cluster, comme vu dans le suivi de SDI. Dans les suivis ci-dessous, le téléphone IP de Cisco (1001) a disparu le hors fonction-crochet. Un traitement de TCP est assigné au téléphone IP de Cisco.

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampOn tcpHandle=0x4fbbc30

Dans les suivis suivants l'utilisateur compose le numéro appelé (2000) du téléphone IP de Cisco, et le processus de l'analyse de chiffre essaye d'apparier le nombre.

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

L'analyse de chiffre a été maintenant terminée et les résultats sont affichés dans les suivis suivants. Il est important de noter que la référence de PotentialMatches=NoPotentialMatchesExist ci-dessous indique que le Cisco CallManager ne peut pas apparier ce nombre de répertoire. En conclusion, une tonalité de réarrangement est envoyée à l'appelant (1001), qui est suivi par un message avec combiné raccroché.

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Articles mouvement d'appel

Cette section fournit les informations détaillées au sujet des enregistrements des articles mouvement d'appel (CDR) et du programme de maintenance (CMR, également connus sous le nom de diagnostic CDR).

Des enregistrements CDR sont écrits à une base de données pour l'usage dans des activités de post traitement. Ces activités incluent beaucoup de fonctions, mais principalement les afficheront et des analyses réseau.

La base de données est une base de données de la Microsoft SQL Server 7.0. Access à la base de données peut être fait par l'intermédiaire de la Connectivité de base de données ouverte (ODBC).

Access est fourni à toutes les tables dans la base de données d'une mode en lecture seule et aux tables CDR et CMR d'une mode lecture/écriture.

Pour utiliser des données record CDR, vous pouvez vouloir lire d'autres tables dans la base de données dans un effort d'obtenir des informations sur le type d'appareil que le CDR est environ. Cette corrélation entre les périphériques dans le tableau des périphériques et l'adresse IP répertoriée dans l'enregistrement CDR n'est pas simple et est répertoriée car un problème connu plus tard dans cette section.

Inscription des enregistrements

Le Cisco CallManager écrit des enregistrements CDR à la base de données SQL comme des appels sont faits en quelque sorte compatibles à la configuration de chaque Cisco CallManager individuel. Cette configuration est faite par l'intermédiaire de l'écran de paramètres de service au Cisco CallManager Administration.

Tous les enregistrements sont écrits à la base de données primaire pour une batterie. Si la base de données primaire n'est pas disponible, les enregistrements seront écrits à l'un des d'autres bases de données de sauvegarde. Une fois que la base de données primaire devient disponible, puis les nouveaux records d'écriture continueront sur la base de données primaire et les enregistrements local-écrits seront déplacés au primaire.

Lecture des enregistrements

Le moyen le plus simple de lire des données de la base de données SQL peut être d'utiliser ODBC. Une bonne chaîne de connexion ressemblerait à :

DRIVER= {SQL Server};SERVER=machineX;DATABASE=CCM0300

Soyez sûr d'utiliser le nom de la base de données correct. Si une version de la version de Cisco CallManager 3.0(1) du logiciel est installée au-dessus d'une installation existante, la base de données pourrait être migrée si nécessité par la nouvelle installation. Dans ce cas la vieille base de données existera toujours, et la nouvelle base de données existera également. Les noms différeront en additionnant un au nombre du nom. Par exemple, le nom d'origine est CCM0300. Après un transfert, le nom de la base de données plus nouveau sera CCM0301. La base de données du nombre le plus élevé devrait être utilisée.

La base de données primaire (ordinateur et nom) actuellement en service par la batterie peut être trouvée en cliquant sur sur le bouton de détails du Cisco CallManager Administration (aide de clic pour atteindre l'écran de bienvenue où le bouton de détails se trouve). Le registre sur des ordinateurs accueillant une base de données peut également être vérifié. Regardez la clé de registre : \ \ HKEY_LOCAL_MACHINE \ logiciel \ Cisco Systems Inc. \ DBL pour l'élément a appelé DBConnection0. Cet élément de chaîne contient une chaîne de connexion semblable à cela affichée ci-dessus avec le nom d'ordinateur et le nom de la base de données de la base de données primaire.

Access est commandé au moyen des utilisateurs SQL. Le tableau suivant spécifie l'ID utilisateur et le mot de passe qui devraient être utilisés en accédant à la base de données Cisco CallManager.

Tableaux ID utilisateur SQL Mot de passe Capacité
CallDetailRecord, CallDetailRecordDiagnostic CiscoCCMCDR dipsy Lecture/écriture
(Autre) CiscoCCMReader cowboys Lu seulement

Retirer des enregistrements

Puisque le Cisco CallManager se fonde sur des applications de tiers pour post-traiter les données CDR, vous devriez enlever les données CDR quand toutes les applications sont terminées avec les données. Puisque ceci implique de modifier la base de données, l'utilisateur de CiscoCCMCDR devrait être utilisé.

Si les enregistrements CDR s'accumulent à un maximum configuré (10,000,000 enregistrements CDR), les enregistrements CDR les plus anciens seront retirés avec les enregistrements CMR relatifs une fois par jour.

En enlevant des données CDR après analyse, soyez sûr de retirer tous les enregistrements CMR relatifs, aussi bien.

Schéma de Tableau

Les informations détaillées au sujet du format et de l'utilisation de chaque champ dans le CDR sont fournies plus tard dans cette section.

Les tables primaires utilisées sont la table de CallDetailRecord (qui détient des records CDR) et la table de CallDetailRecordDiagnostic (qui détient des enregistrements CMR). La table de CallDetailRecord est liée à la table de CallDetailRecordDiagnostic par l'intermédiaire des deux colonnes, GlobalCallID_callManagerId, et GlobalCallID_callId de GlobalCallID. Il peut y avoir plus d'un CMR par CDR.

La table de CallDetailRecord tient des informations sur les points finaux de l'appel et d'autres aspects de Contrôle d'appel/routage de l'appel. La table de CallDetailRecordDiagnostic tient des informations sur la qualité de l'audio coulé de l'appel.

Problèmes identifiés

La version de Cisco CallManager 3.0(1) a plusieurs problèmes connus avec les données CDR. Quelques uns de ces derniers sont répertoriés ci-dessous.

IP à la traduction de nom du périphérique

Le tableau CDR présente des adresses IP pour les points finaux d'un appel. Ces adresses IP ne sont pas facilement converties en noms du périphérique de sorte que le type d'appareil puisse être déterminé.

OnNet contre OffNet

Il est difficile de savoir si l'appel restait complètement sur le réseau IP, ou au moins interne au système local. Un indice est de vérifier le type de périphérique des deux fins de l'appel. Si chacun des deux sont des téléphones, alors vous pouvez supposer qu'il est resté OnNet. Cependant, si on est une passerelle, plus de suppositions doivent être faites. Si la passerelle est un type d'appareil analogique d'Access avec les POTS ou le port de station, l'appel pourrait être juste allé à un téléphone analogique local, ou pourrait être sorti au PSTN. Regardez le numéro composé et corrélez ceci au Plan de composition connu d'estimer si l'appel disparaissait OffNet. Autrement, l'appel est probablement allé OnNet.

Numéroteur de chiffres d'OffNet

Si un appel est placé une passerelle, les chiffres composés pour obtenir à la passerelle peuvent ne pas être les chiffres envoyés au PSTN. La passerelle peut être intelligente et modifier le nombre de répertoire plus loin. Si c'est le cas, le Cisco CallManager ne sait pas, et le CDR ne reflétera pas les chiffres réels envoyés OffNet.

Champs dans un article mouvement d'appel

Cette section définit tous les champs dans les articles courants. Les types de champ sont ceux utilisés par Cisco CallManager, et pas nécessairement ceux définis dans l'enregistrement CDR dans la base de données. Les définitions de champ de la base de données sont adéquates pour enregistrer les données, mais la traduction des données devrait prendre en considération les types de champ définis ici.

Tous les entiers non signés sont les entiers non signés 32bit.

Conversions des données de champ

Il y a quelques champs qui exigent la conversion du format décimal en un autre format pour des affichages. Cette section définit leurs valeurs, et comment les convertir ou où obtenir les informations sur la façon dont les convertir.

Valeurs temporelles

Toutes les valeurs temporelles sont représentées en tant que 32 entiers non signés de bit. Cette valeur d'entier non signé est affichée de la base de données comme entier signé.

Ce champ est une valeur de time_t qui est obtenue des 2000) routines de système de Windows NT (. La valeur est une valeur coordonnée du temps universel (UTC) et représente le nombre de secondes depuis le 1er janvier de minuit (de 00:00:00), 1970.

Déchiffrement du groupe date/heure

Utilisant Microsoft Excel, vous pouvez écrire une formule pour faciliter convertissant ce groupe date/heure un peu. Si la valeur est en cellule A1, vous pouvez faire une autre cellule :

=A1/86400+DATE(1970,1,1)

Il y a 86400 secondes dans un jour.

Puis, formatez la cellule en résultant comme champ de date/heure dans Exceler.

Adresses IP

Toutes les adresses IP sont enregistrées dans le système comme entiers non signés. La base de données les affiche en tant qu'entiers signés. Pour convertir la valeur décimale signée en adresse IP, convertissez d'abord la valeur en nombre hexadécimal (prenant en compte que c'est vraiment un nombre non signé). La valeur de l'hexa 32bit représente quatre octets. Les quatre octets sont en ordre inverse (norme d'Intel). Pour obtenir l'adresse IP, renversez la commande des octets et convertissez chaque octet en nombre décimal. Les quatre octets en résultant représentent les champs de quatre octets de l'adresse IP dans la notation pointillée.

Remarque: La base de données l'affiche comme numéro négatif quand le bas octet de l'adresse IP a le bit le plus significatif réglé.

Conversion des adresses IP

  • Exemple 1 :

    Par exemple, l'adresse IP 192.168.18.188 serait affichée comme suit :

    Affichage de base de données = -1139627840.

    Ceci convertit en valeur hexadécimale de 0xBC12A8C0.

    Renversez les octets = le C0A812BC hexadécimaux

    CO A8 12 BC

    Les octets ont converti de l'hexa en décimale = 192 168 18 188, qui seraient affichés comme 192.168.18.188.

  • Exemple 2 :

    Adresse IP 192.168.18.59

    Affichage de base de données = 991078592

    Ceci convertit en valeur hexadécimale de 0x3B12A8C0

    Renversez la commande d'octet = le C0A8123B

    C0 A8 12 3B

    Les octets ont converti de l'hexa en décimale = 192 168 18 59 qui seraient affichés comme 192.168.18.59.

Définition de champ CDR

Le tableau suivant fournit des définitions de champ pour des CDR.

Définitions de champ
Champ Définition
cdrRecordType Le type de cet entier non signé record spécifie le type de cet enregistrement spécifique. C'a pu être un appel de début record(0), la fin de l'appel record(1), ou un CMR record(2).
globalCallIdentifier L'identifiant global d'appel l'identifiant global d'appel se compose de deux champs qui sont les deux entiers non signés. Les valeurs doivent être traitées comme entiers non signés. Les deux champs sont : L'entier non signé GlobalCallID_CallManagerID de GlobalCallID_CallID d'entier non signé ceci est l'identifiant d'appel qui est assigné à l'appel entier. Tout enregistre associé à un appel standard aura le même identifiant global d'appel.
origLegCallIdentifier L'entier non signé d'identifiant d'appel de tronçon d'origines ceci est un identifiant unique qui est utilisé pour dépister le tronçon d'origines d'un appel. Il est seul dans une batterie.
dateTimeOrigination Date/heure d'entier non signé d'initialisation d'appel ceci représente le temps que le périphérique d'origine de l'appel est allé outre du crochet, ou le temps qu'un appel d'extérieur a été identifié la première fois par le système (il a reçu le message de configuration). La valeur est une valeur coordonnée du temps universel (UTC), et représente le nombre de secondes depuis le 1er janvier de minuit (de 00:00:00), 1970.
origNodeId L'entier non signé d'ID du noeud du créateur ce champ représente le noeud dans la batterie de Cisco CallManager où l'émetteur d'appel a été enregistré au moment de cet appel.
origSpan L'envergure du créateur ou l'entier non signé de port ce champ contient le nombre du port ou de l'envergure du créateur si l'appel commençait par une passerelle. Sinon, ce champ contient zéro (0).
callingPartyNumber Le numéro de l'appelant jusqu'à 25 caractères ceci est le nombre de répertoire du périphérique duquel l'appel a commencé.
origIpPort L'entier non signé de port IP de l'appelant ce champ contient le port IP du périphérique duquel l'appel a commencé.
origIpAddr L'entier non signé de l'adresse IP de l'appelant ce champ contient l'adresse IP du périphérique duquel l'appel a commencé.
originalCallingPartyNumberPartition La partition de l'appelant jusqu'à 50 caractères ce champ contient la partition associée avec l'appelant.
origCause_Location L'entier non signé de valeur d'emplacement RNIS ce champ contient la valeur d'emplacement de l'élément d'information de cause.
origCause_Value La cause d'appelant de l'entier non signé de terminaison d'appel cette cause représente la raison que l'appel au périphérique d'origine a été terminé. Dans le cas des transferts, en avant, et ainsi de suite, la cause de la terminaison d'appel peut être différente pour le périphérique d'origine et le périphérique de terminaison. Ainsi, il y a deux champs de cause associés avec chaque appel. Habituellement ils seront identiques.
origMediaTransportAddress_IP L'adresse IP pour l'entier non signé de connexion des medias du créateur ceci est l'adresse IP de destination à laquelle le flux multimédia du créateur a été connecté.
origMediaTransportAddress_Port Le port pour l'entier non signé de connexion des medias du créateur ceci est la destination port à laquelle le flux multimédia du créateur a été connecté.
origMediaCap_payloadCapability Le type de codecs l'a utilisé par l'entier non signé de créateur que ce champ contient le type de codecs (compactage ou type de charge utile) que le créateur a utilisé du côté émission pendant cet appel. Il peut être différent que les codecs tapent utilisé de son côté réception.
origMediaCap_maxFramesPerPacket Le nombre de millisecondes des données par entier non signé de paquet ce champ contient le nombre de millisecondes des données par paquet envoyé à la destination, par le créateur de cet appel. La taille de données réelle dépend du type de codecs étant utilisé pour générer les données.
origMediaCap_g723BitRate Le débit binaire à utiliser par G.723 l'entier non signé définit le débit binaire à utiliser par G.723. Il y a deux valeurs de débit binaire : 1 débit binaire et 2 =5.3K = débit binaire 6.3K.
lastRedirectDn Le nombre de répertoire de l'interlocuteur que pour la dernière fois réorienté ceci appelez à 25 caractères ceci est le nombre de répertoire du dernier périphérique qui a réorienté cet appel. Ce champ s'applique seulement aux appels qui ont été réorientés, comme des conférences téléphoniques, des appels transférés d'appel, et ainsi de suite.
lastRedirectDnPartition La partition du téléphone que pour la dernière fois réorienté ceci appelez à 50 caractères ceci est la partition du dernier périphérique qui a réorienté cet appel. Ce champ s'applique seulement aux appels qui ont été réorientés comme des conférences téléphoniques, des appels transférés d'appel, et ainsi de suite.
destLegIdentifier L'identifiant d'appel pour le tronçon de destination de l'entier non signé d'appel ceci est un identifiant unique qui est utilisé pour dépister le tronçon de destination de cet appel. Il est seul dans une batterie.
destNodeId L'identifiant de noeud pour le noeud où la destination de l'appel était entier non signé enregistré le noeud dans la batterie de Cisco CallManager où le périphérique de destination a été enregistré au moment de cet appel.
envergure DEST L'entier non signé d'envergure ou de port de destination ce champ contient le nombre de destination port ou d'envergure si l'appel était terminé par une passerelle. Sinon, ce champ contient a (0) zéros.
destIpAddr L'adresse IP à laquelle l'appel était entier non signé fourni ce champ contient l'adresse IP de la connexion de signalisation sur le périphérique qui a terminé l'appel.
destIpPort Le port IP auquel l'appel était entier non signé fourni ce champ contient le port IP de la connexion de signalisation sur le périphérique qui a terminé l'appel.
originalCalledPartyNumber La destination a reçu de l'émetteur d'appel jusqu'à 25 caractères que ce champ contient le nombre de répertoire auquel l'appel a été initialement étendu basé sur les chiffres a composé par le créateur de l'appel. Si l'appel se termine normalement (la signification de lui n'a pas été expédiée), ce nombre de répertoire devrait toujours être identique que le « finalCalledPartyNumber ». Si l'appel était expédié, ce champ contient la destination d'origine de l'appel avant qu'il ait été expédié.
originalCalledPartyNumberPartition La partition de l'appelé jusqu'à 50 caractères ce champ contient la partition associée avec l'appelé.
finalCalledPartyNumber La destination à laquelle l'appel a été fourni jusqu'à 25 caractères ce champ contient le nombre de répertoire auquel l'appel a été étendu réellement. Si l'appel se termine normalement (la signification de lui n'a pas été expédiée), ce nombre de répertoire devrait toujours être identique que le « originalCalledPartyNumber ». Si l'appel était expédié, ce champ contient le nombre de répertoire de la destination définitive de l'appel après tout en avant ont été terminés.
finalCalledPartyNumberPartition La partition a associé avec la destination définitive de l'appel. jusqu'à 50 caractères ce champ contient la partition associée avec la destination à laquelle l'appel a été étendu réellement. Dans un appel normal, ce champ devrait être identique en tant que « originalCalledPartyNumberPartition ». Si l'appel était expédié, ce champ contient la partition de la destination définitive de l'appel après tout en avant ont été terminés.
destCause_location L'entier non signé d'emplacement de cause d'appelé ceci est la valeur d'emplacement RNIS de l'élément d'information de cause.
destCause_value La cause d'appelé de l'entier non signé de terminaison d'appel cette cause représente pourquoi l'appel au périphérique de terminaison a été terminé. Dans le cas des transferts, en avant, et ainsi de suite, la cause de la terminaison d'appel peut être différente pour le destinataire de l'appel et du créateur de l'appel. Ainsi, il y a deux champs de cause associés avec chaque appel. Habituellement ils seront identiques. Quand une tentative est faite pour étendre un appel à un périphérique occupé qui est expédié, code de cause reflétera « occupé » quoique l'appel ait été connecté à une destination en avant.
destMediaTransportAddress_IP L'adresse IP pour l'entier non signé sortant de connexion de medias de destination ceci est l'adresse IP d'origines dont le flux multimédia de la destination a été connecté.
destMediaTransportAddress_Port Le port pour l'entier non signé sortant de connexion de medias de destination ceci est le port du créateur dont le flux multimédia de la destination a été connecté.
destMediaCap_payloadCapability Le type de codecs l'a utilisé par la destination sur l'entier non signé de côté émission que ce champ contient le type de codecs (compactage ou type de charge utile) que la destination a utilisé de son côté émission pendant cet appel. Il peut être différent que les codecs tapent utilisé de son côté réception.
destMediaCap_maxFramesPerPacket Le nombre de millisecondes des données par entier non signé de paquet ce champ contient le nombre de millisecondes des données par paquet envoyé au créateur par la destination de cet appel. La taille de données réelle dépend du type de codecs étant utilisé pour générer les données.
destMediaCap_g723BitRate Le débit binaire à utiliser par G.723 l'entier non signé définit le débit binaire à utiliser par G.723. Il y a deux valeurs de débit binaire : 1 débit binaire et 2 =5.3K = débit binaire 6.3K.
dateTimeConnect Le date/heure de connectent l'entier non signé que c'est la date et l'heure que l'appel a été connecté entre le commencement et les périphériques de terminaison. La valeur est une valeur coordonnée du temps universel (UTC), et représente le nombre de secondes depuis le 1er janvier de minuit (de 00:00:00), 1970.
dateTimeDisconnect Date/heure d'entier non signé de débranchement c'est le temps que l'appel a été déconnecté entre le commencement et les périphériques de terminaison, ou où l'appel a été démoli même si il n'a été jamais connecté. La valeur est une valeur coordonnée du temps universel (UTC), et représente le nombre de secondes depuis le 1er janvier de minuit (de 00:00:00), 1970.
durée Durée de l'appel c'est le nombre de secondes que l'appel a été connectées. C'est la différence entre le date/heure de se connectent et le date/heure du débranchement.

Définitions de champ CMR

Le tableau suivant fournit des définitions de champ pour CMR (diagnostic CDR).

Définitions de champ
Champ Définition
cdrRecordType Le type de cet entier non signé record spécifie le type de cet enregistrement spécifique. Il sera placé à l'enregistrement CMR.
globalCallIdentifier L'identifiant global d'appel pour cet appel l'identifiant global d'appel se compose de deux champs qui sont les deux entiers non signés. Les valeurs doivent être traitées comme entiers non signés. Les deux champs sont : L'entier non signé GlobalCallID_CallManagerID de GlobalCallID_CallID d'entier non signé ceci est l'identifiant d'appel qui est assigné à l'appel entier. Tout enregistre associé à un appel standard aura le même identifiant global d'appel.
nodeID L'identifiant de noeud de Cisco CallManager le noeud dans la batterie de Cisco CallManager où cet enregistrement a été généré.
callIdentifier L'entier non signé d'identifiant d'appel ceci est un identifiant de tronçon d'appel qui l'identifie à quel tronçon d'appel cet enregistrement concerne.
directoryNum Le nombre de répertoire utilisé à cet appel ceci est le nombre de répertoire du périphérique duquel ces diagnostics ont été collectés.
directoryNumPartition La partition associée avec le nombre de répertoire ceci est la partition du nombre de répertoire dans cet enregistrement.
dateTimeStamp Date/heure de la terminaison d'appel ceci représente le temps approximatif que le périphérique a disparu raccroché. Le temps est mis dans l'enregistrement quand le téléphone répond à une demande des informations de diagnostic. C'est une valeur de time_t.
numberPacketsSent Le nombre de paquets a envoyé le nombre total de paquets de données de RTP transmis par le périphérique depuis commencer la transmission sur cette connexion. La valeur est zéro si la connexion était placée en mode « uniquement récepteur ».
numberOctetsSent Nombre d'octets (octets) de données transmises à l'autre interlocuteur le nombre total d'octets de charge utile (c'est-à-dire, pas comprenant l'en-tête ou la remplissage) transmis dans des paquets de données de RTP par le périphérique depuis commencer la transmission sur cette connexion. La valeur est zéro si la connexion était placée en mode « uniquement récepteur ».
numberPacketsReceived Le nombre de paquets de données reçus pendant cet appel que le nombre total de paquets de données de RTP a reçu par le périphérique depuis commencer la réception sur cette connexion. Le compte inclut des paquets reçus de différentes sources si c'est un appel de Multidiffusion. La valeur est zéro si la connexion était placée dans « envoient seulement » le mode.
numberOctetsReceived Le nombre d'octets (octets) de données reçues pendant cet appel le nombre total d'octets de charge utile (c'est-à-dire, pas comprenant l'en-tête ou la remplissage) a reçu dans des paquets de données de RTP par le périphérique depuis commencer la réception sur cette connexion. Le compte inclut des paquets reçus de différentes sources, si c'est un appel de Multidiffusion. La valeur est zéro si la connexion était placée dans « envoient seulement » le mode.
numberPacketsLost Paquets perdus de RTP pendant cette connexion le nombre total de paquets de données de RTP qui ont été perdus depuis le début de la réception. Ce nombre est défini comme nombre de paquets prévus, moins le nombre de paquets réellement reçus, où le nombre de paquets reçus en inclut qui sont tardifs ou reproduit. Ainsi, des paquets qui arrivent tard ne sont pas comptés comme perdu, et la perte peuvent être négatifs s'il y a des doublons. Le nombre de paquets prévus est défini pour être le dernier numéro de séquence étendu reçu, en tant que défini ensuite, moins le nombre de séquence initiale reçu. La valeur est zéro si la connexion était placée dans « envoient seulement » le mode. (Pour des détails, voir le RFC 1889)
jitter Le jitter entre arrivées pendant cette connexion une évaluation de la variance statistique du temps entre arrivées de paquet de données de RTP, mesurée en millisecondes et exprimée comme un entier non signé. Le jitter entre arrivées J est défini pour être la moyenne déviation (valeur absolue douce) de la différence D dans l'interligne de paquet au récepteur comparé à l'expéditeur pour une paire de paquets. Des algorithmes détaillés de calcul sont trouvés dans le RFC 1889. La valeur est zéro si la connexion était placée dans « envoient seulement » le mode.
latence La latence a éprouvé pendant cette connexion que la valeur est une évaluation de la latence de réseau, exprimée en quelques millisecondes. C'est la valeur moyenne de la différence entre l'horodateur de Protocole NTP (Network Time Protocol) indiqué par les expéditeurs des messages du Control Protocol de RTP (RTCP) et l'horodateur de NTP des récepteurs, mesuré quand ces messages sont reçus. La moyenne est obtenue en additionnant toutes les évaluations, puis la division par le nombre de messages RTCP qui ont été reçus. (Pour des détails voir le Request For Comments (RFC) 1889)

Enregistrements d'appel connectés par le type d'appel

Chaque appel normal entre deux interlocuteurs se connecte un enregistrement de fin de l'appel CDR. Chaque enregistrement de fin de l'appel contient tous les champs identifiés ci-dessus, mais quelques champs ne peuvent être utilisés. Si un champ n'est pas utilisé, il sera vide si c'est un champ de chaîne ASCII, ou "0" si c'est un champ numérique. Quand des services supplémentaires sont impliqués dans un appel, plus d'enregistrements de fin de l'appel peuvent être écrits.

En plus de l'enregistrement de fin de l'appel CDR, il peut y avoir jusqu'à un enregistrement CMR par point final impliqué dans un appel. Dans un appel normal entre deux interlocuteurs chacun utilisant un téléphone IP de Cisco, il y aura deux enregistrements CMR écrits : un pour le créateur et un pour la destination de l'appel.

Cette section décrit les enregistrements écrits pour l'appel différent saisit le système.

Appels normaux (téléphone IP IP Téléphone-à-Cisco de Cisco)

Enregistrements du log trois d'appels normaux par appel. Ils sont EndCall plus deux enregistrements diagnostiques, un pour chaque point final. Dans l'enregistrement d'EndCall, tous les champs peuvent contenir les informations valides. La durée sera toujours différente de zéro à moins que l'indicateur de « CdrLogCallsWithZeroDurationFlag » soit activé (placez pour rectifier). Le champ de « originalCalledPartyNumber » contiendra le même nombre de répertoire que le champ de « finalCalledPartyNumber ».

Appels abandonnés

Se connecter des appels avec la durée nulle est facultatif. Normalement, ces enregistrements pas sont enregistré. Si se connecter des appels avec la durée nulle est activé, les choses suivantes devrait être noté.

  • Si l'appel était abandonné (comme quand un téléphone est crochet enlevé et de retour placé raccroché), les divers champs ne contiendront pas des données. Dans ce cas, le « originalCalledPartyNumber, » « finalCalledPartyNumber, » les partitions associées avec eux, le « destIpAddr, » et les champs de dateTimeConnect sera vide. Tous les appels qui n'ont pas été connectés auront une « durée » des zéros secondes. Quand un appel est abandonné, code de cause est "0".

  • Si l'utilisateur composait un numéro de répertoire et puis abandonnait l'appel avant qu'il ait été connecté, les « premiers champs DEST » et de « finale DEST » et leurs partitions associées contiendront le nombre et la partition de répertoire auxquels l'appel aurait été étendu. Le champ « d'IP DEST » sera vide, et la durée sera zéro.

Appels expédiés ou réorientés

Les enregistrements d'appel pour des appels transférés seront identiques que ceux pour des appels normaux excepté le champ de « originalCalledPartyNumber » et les champs de « originalCalledPartyNumberPartition ». Ces champs contiendront le nombre et la partition de répertoire pour la destination qui a été initialement composée par le créateur de l'appel. Si l'appel était expédié, les champs de « finalCalledPartyNumber » et de « finalCalledpartyNumberPartition » seront différents et contiendront le nombre de répertoire et la partition de la destination définitive de l'appel. En outre, quand un appel est expédié, les champs de « lastRedirectDn » et de « lastRedirectDnPartition » contiendront le nombre de répertoire et la partition du dernier téléphone qui a expédié ou a réorienté cet appel.

Appels avec les destinations occupées ou mauvaises

Ces appels veulent sont enregistré comme appel normal avec tous les champs appropriés contenant des données. Le champ de cause d'appelé contiendra code de cause indiquant pourquoi l'appel n'a pas été connecté, et l'IP d'appelé et le date/heure connectent des champs seront vides. Si le créateur abandonnait l'appel, la cause sera « NO_ERROR » (0). La durée sera toujours des zéros secondes. Ces appels pas sont enregistré à moins que « CdrLogCallsWithZeroDurationFlag » soit activé.

Enregistrements de programme de maintenance connectés par le type d'appel

Chaque appel normal entre deux logs de Téléphones IP de Cisco exactement deux enregistrements CMR. Chaque enregistrement CMR d'appel contient tous les champs identifiés ci-dessus. Quand des services supplémentaires sont impliqués dans un appel, plus d'un enregistrement peut être écrit. Cette section décrit quand des enregistrements diagnostiques sont écrits pour l'appel différent saisit le système.

Appels normaux

Les appels normaux se connectent exactement deux enregistrements CMR par appel, un pour chaque téléphone impliqué dans l'appel. Actuellement, seulement les Téléphones IP de Cisco et les passerelles MGCP sont capables de répondre à la demande des informations de diagnostic. Tous les champs contiendront les informations valides.

Appels abandonnés

Si l'appel était abandonné (comme quand un téléphone est pris le hors fonction-crochet et de retour placé raccroché), tout met en place connexe à couler des données sera le blanc (zéro). C'est parce qu'aucune connexion coulante n'a été établie, et donc aucune donnée n'a été transférée. Enregistrement avec des champs vides ne veut pas est enregistré si le « CdrLogCallsWithZeroDurationFlag » est désactivé.

Appels transférés

Les enregistrements d'appel pour des appels transférés seront identiques que ceux pour des appels normaux.

Appels avec les destinations occupées ou mauvaises

Dans le cas normal, seulement les enregistrements qui représentent les appels qui ont été connectés réellement sont enregistré. Afin de se connecter des appels avec de mauvaises destinations, vous devez activer « CdrLogCallsWithZeroDurationFlag. » S'il est activé, alors tous les appels veulent sont enregistré comprenant le cas où l'utilisateur va le hors fonction-crochet et puis avec combiné raccroché de nouveau.

Si les appels sont enregistré, ils sont enregistré en tant qu'appels normaux avec tous les champs appropriés contenant des données. Il y aura seulement un enregistrement par appel puisque les appels n'ont été jamais connectés à une destination. L'enregistrement sera pour le créateur de l'appel.

Le codec tape (les types de compactage/charge utile)

Le tableau suivant fournit des valeurs et des descriptions pour des types de codecs.

Description de codecs
Codecs Description
1 Non standard
2 G711A-law 64k
3 56K G711A-law
4 G711Ý-law 64k
5 56K G711Ý-law
6 G722 64k
7 56K G722
8 G722 48k
9 G7231
10 G728
11 G729
12 G729AnnexA
13 Is11172AudioCap
14 Is13818AudioCap
15 G729AnnexB
32 Données 64k
33 56K de données
80 GSM
81 ActiveVoice
82 G726_32K
83 G726_24K
84 G726_16K

Codes de cause

Le tableau suivant fournit une liste de codes de cause qui peuvent apparaître dans les domaines de cause.

Descriptions de code de cause
Code de cause Description
0 Aucune erreur
1 Nombre (non affecté) non affecté
2 Aucune artère au transit network spécifié (utilisation nationale)
3 Aucune route vers la destination
4 Tonalité d'information spéciale d'envoi
5 Préfixe de joncteur réseau composé un faux numéro (utilisation nationale)
6 Canal inacceptable
7 Appel attribué et étant livré dans un canal établi
8 Préemption
9 Préemption - circuit réservé pour la réutilisation
16 Effacement d'appel normal
17 Utilisateur occupé
18 Aucun répondre d'utilisateur
19 Pas de réponse d'utilisateur (utilisateur alerté)
20 Abonné absent
21 Appel rejeté
22 Numéro modifié
26 Effacement de l'utilisateur non sélectionné
27 Destination en panne
28 Format de numéro incorrect (adresse inachevée)
29 Installation rejetée
30 Réponse à une demande de renseignements sur l'état
31 Normal, non spécifié
34 Aucun circuit/canal disponible
38 Réseau en panne
39 Connexion en mode trame permanente hors service
40 Connexion en mode trame permanente opérationnelle
41 Défaillance provisoire
42 Encombrement de l'équipement de commutation
43 Informations d'accès ignorées
44 Circuit/canal demandés non disponible
46 Appel prioritaire bloqué
47 Ressource indisponible, non spécifié
49 Qualité de service non disponible
50 Installation demandée non abonnée
53 Exécution de service violée
54 Appels entrants non autorisés
55 Appels entrant barrés au sein du groupe d'utilisateurs fermé (CUG)
57 Capacité de support non autorisée
58 Capacité de support non disponible actuellement
62 Incohérence dans les informations d'accès et la classe sortantes indiquées d'abonné
63 Service ou option non disponible, non spécifié
65 Capacité de support non mise en application
66 Type de canal non mis en application
69 Installation demandée non mise en application
70 Seulement la capacité de support restreinte des informations numériques est disponible (l'utilisation nationale)
79 Service ou option non mise en application, non spécifié
81 Valeur de référence d'appel non valide
82 Le canal identifié n'existe pas
83 Un appel interrompu existe, mais cette identité d'appel ne fait pas
84 Appelez l'identité en service
85 Aucun appel interrompu
86 L'appel ayant l'identité demandée d'appel a été effacé
87 Membre d'utilisateur pas du groupe d'utilisateurs fermé (CUG)
88 Destination incompatible
90 Disparus de numéro de destination et C.C non abonnés
91 Sélection non valide de transit network (utilisation nationale)
95 Message incorrect, non spécifié
96 L'élément d'information obligatoire manque
97 Type de message inexistant ou non mis en application
98 Le message n'est pas compatible avec l'état d'appel, ou le type de message est inexistant ou non mis en application
99 Un élément d'information ou un paramètre n'existe pas ou n'est pas mis en application
100 Contenus avec éléments d'informations incorrectes
101 Le message n'est pas compatible avec l'état d'appel
102 L'appel a été terminé quand un temporisateur a expiré et une routine de reprise a été exécutée pour récupérer de l'erreur
103 Paramètre inexistant ou non mis en application - passé sur (utilisation nationale)
110 Message avec le paramètre non reconnu jeté
111 Erreur de protocole, non spécifiée
126 Fractionnement d'appel. C'est un code de Cisco-particularité. Il est utilisé quand un appel est terminé pendant une opération de transfert parce qu'il a été séparé hors fonction et terminé (n'était pas une partie du transfert d'appel final). Ceci peut aider à déterminer quels appels ont été terminés en tant qu'élément d'une opération de transfert.
127 Interopérabilité, non spécifiée

Alarmes

Une alarme est émise quand le CDR ou les données diagnostiques est activé, et le système ne peut pas écrire les données dans la base de données.

Incapable d'écrire des données CDR. (Alarme # 1711 - Alarme principale)

Le système tenté pour ouvrir la base de données, et était infructueux. Les causes probables incluent :

  • Le Cisco CallManager n'a pas des privilèges suffisants d'ouvrir le fichier pour écrire à la base de données. Assurez-vous que le Cisco CallManager a les privilèges qui laisseront écrivent des exécutions.

  • Le chemin n'est pas installé, ou le serveur de base de données est en panne.

Appelant le centre d'assistance technique Cisco (TAC)

Si vous avez un problème qui ne peut pas être résolu par votre propre dépannage, appelez s'il vous plaît le TAC pour l'assistance. Avant d'appeler le TAC, ayez les informations disponibles suivantes :

  • Détails de Cisco CallManager

  • Topologie

  • Les logs et vous trace se sont exécutés pendant le dépannage, y compris des suivis de SDI et SDL

  • Les fichiers de Stackwalk.txt du répertoire WINNT\system32 et du Cisco CallManager tracent le sous-répertoire

  • sh--tech sur des passerelles de Cisco IOS, si c'est approprié

  • sh--tech sur le Cisco CallManager

  • Si le problème est avec des appels par une passerelle de Cisco IOS, fournissez s'il vous plaît également :

    • mettez au point l'inout de ccapi de Voix

    • debug isdn q931

    • seulement] xboard SH du vfc [AS5300

    • [AS5300 seulement] dspware SH de version du vfc X

    • [AS5300 seulement] vcware SH de version du vfc X

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 30266