Voix et communications unifiées : Commutateur logiciel Cisco PGW 2200

Dépannage des appels silencieux sur Cisco PGW 2200

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


Contenu


Introduction

Ce document fournit l'information de dépannage pour les communications voix qui sont mises en sommeil dans une direction sur la passerelle PSTN de Cisco PGW 2200 (Cisco PGW 2200). Les informations dans ce document s'appliquent spécifiquement à la solution de passerelle PSTN de Cisco utilisant des passerelles du contrôleur (MGC) et du Cisco AS5x00 de passerelle de medias en combination avec Cisco PGW 2200.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur les versions de logiciel et de matériel ci-dessous.

Plate-forme Nom de plate-forme Libérez
Noeud PGW 2200 Cisco MGC 9.2(2) [de correctif S(29)] 9.3(2) [de correctif S(7)] 9.4(1)
Passerelle PSTN AS5x00 12.2T ou plus élevé

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.

Écoulements d'appel

La compréhension des différentes configurations sur le cut-through par l'intermédiaire du routing.mml peut vous aider à comprendre les différents écoulements d'appel pour le concept de Cisco PGW 2200.

Écoulement typique d'appel avec le cut-through sur ANM

Un écoulement typique d'appel avec le cut-through sur ANM (tel que 3) est affiché ci-dessous :

Originating TDM Originating Gateway PGW Terminating Gateway            Terminating TDM
                       --------------IAM-------------> 
                                                    <-CRCX-- 
                                                 (M: inactive) 
                                                    --- OK----> 
                                                                                      ---CRCX-> 
                                                                                 (M: sendrecv) 
                                                                                       <--OK----- 
                                                                                      --------------------IAM---------> 
                                                                                       <---------------- ACM----------- 
                       <--------------ACM-------------- 
                                                    <-MDCX-- 
                                                (M: recvonly) 
                                                     --OK------> 
                                                                                       <-----------------ANM----------- 
                       <--------------ANM-------------- 
                                                      <--MDCX--- 
                                                (M: sendrecv) 
                                                     ----OK----> 
                                                                                         ----MDCX--> 
                                                                                  (M: sendrecv) [See note below] 
                                                                                         <---OK--[See note below]

Remarque: Le MDCX facultatif est envoyé à la dernière passerelle pour activer l'annulation d'écho seulement si :

  • la propriété « EchoCanRequired » de groupe de joncteur réseau est placée, et

  • le commutateur du terme TDM n'a pas fourni l'annulation d'écho (par exemple, le paramètre d'Echo_control_device_indicator dans le message ACM du terme TDM a été placé à zéro).

Écoulement typique d'appel avec le cut-through sur ACM

Un écoulement typique d'appel avec le cut-through sur ACM (tel que des égaux de cut-through 2) est affiché ci-dessous :

Originating TDM Originating Gateway             PGW           Terminating Gateway            Terminating TDM 
                           --------------IAM-------------> 
                                                        <--CRCX--- 
                                                           (M: inactive) 
                                                        --- OK-----> 
                                                                                          ---CRCX---> 
                                                                                      (M: sendrecv) 
                                                                                           <--OK---- 
                                                                                           --------------------IAM---------> 
                                                                                            <---------------- ACM----------- 
                          <-------------ACM----------------- 
                                                          <---MDCX---- 
                                                           (M: sendrecv) 
                                                           ----OK----> 
                                                                                             ----MDCX--> 
                                                                                            (M: sendrecv) [OPTIONAL, see note 1] 
                                                                                             <---OK---[OPTIONAL, see note 1] 
                                                                                              <------------------ANM------------ 
                          <-------------ANM------------------ 

Remarque: Quand l'appel est occupé ou il y a un certain tri de l'annonce à la lire à l'appelant, il n'y a aucune raison d'ouvrir le chemin voix dans les deux directions. Si vous pensez vous avez un appel muet signalé, émettez une commande de paquet de debug mgcp sur le commencement et la dernière passerelle en combination avec une commande de show call history voice liée aux messages avec un zéro envoyé compte de paquet, une commande brief de show call history voice, et un suivi de langage de définition de message de Cisco (MDL) sur le PGW 2200 de comprendre le problème. Un suivi de fouineur vous aidera également à comprendre le problème. Le suivi de MDL fournit un écoulement complet d'appel SS7 et de Protocole MGCP (Media Gateway Control Protocol).

Les clients signalent des appels amortis

Les conditions suivantes font signaler le PGW 2200 des appels muets (pendant la connexion d'effacement [DLCX]) et la détection dans platform.log. Ces logs contiennent un ID d'appel qui a les informations de passerelle et les informations CIC.

  1. PGW 2200 est configuré en mode insensible aux défaillances.

  2. L'appel a été répondu (l'appel était avec succès cut-through.).

  3. Le message de 250 OKS a été reçu avec (P :) en réponse à DLCX.

  4. Ou le paquet a envoyé les égaux (picoseconde) 0 ou le paquet a reçu les égaux (RP) 0 dedans (P :).

  5. La durée de l'appel était plus de 1 seconde.

Collecter les informations d'appel supplémentaires

Pour collecter les informations d'appel supplémentaires, utilisez les étapes suivantes :

  1. Établissez un rapport de telnet à la passerelle as5xxx-1.

  2. Émettez la commande suivante de trouver l'ID d'appel de retour de nouveau qui est joint avec le point final et le message muet d'appel de platform.log :

    as5xxx-1 > show mgcp connection
    

    Ce qui suit est sortie témoin de la commande de show mgcp connection pour des connexions de la voix sur ip (VoIP) :

    Endpoint Call_ID(C) Conn_ID(I) (P)ort (M)ode (S)tate (C)odec (E)vent[SIFL] (R)esult[EA] 
    1. S0/DS1-0/1 C=103,23,24 I=0x8 P=16586,16634 M=3 S=4,4 C=5 E=2,0,0,2 R=0,0

Des descriptions du champ de la commande de show mgcp connection pour le VoIP sont affichées ci-dessous.

  • Point final — Le point final pour chaque appel, affiché dans la convention d'endpoint naming numérique du nombre d'emplacement (S0) et de la ligne numérique (DS1-0) numéro (1).

  • Call_ID (C) — L'ID d'appel MGCP envoyé par l'agent d'appel, l'ID d'appel de l'interface de programmation de Contrôle d'appel interne (CCAPI) pour ce point final, et l'ID d'appel CCAPI pour les segments d'appel de homologue. CCAPI est un API qui fournit des équipements de Contrôle d'appel aux applications.

  • Conn_ID (I) — L'ID de connexion généré par la passerelle et introduit le message ACK.

  • Ort (P) — les ports utilisés pour cette connexion. Le premier port est le port local de Protocole UDP (User Datagram Protocol). Le deuxième port est le port UDP distant.

  • Ode (M) — le mode d'appel, où :

    • 0 — Indique une valeur non valide pour le mode.

    • 1 — Indique que la passerelle devrait seulement envoyer des paquets.

    • 2 — Indique que la passerelle devrait seulement recevoir des paquets.

    • 3 — Indique que la passerelle peut envoyer et recevoir des paquets.

    • 4 — Indique que la passerelle ne devrait ni envoyer ni recevoir des paquets. [Inactif]

    • 5 — Indique que la passerelle devrait placer le circuit dans le mode de bouclage.

    • 6 — Indique que la passerelle devrait placer le circuit dans le mode test.

    • 7 — Indique que la passerelle devrait utiliser le circuit pour l'accès au réseau pour des données.

    • 8 — Indique que la passerelle devrait placer la connexion dans le mode de bouclage de réseau.

    • 9 — Indique que la passerelle devrait placer la connexion dans le mode de test de continuité de réseau.

    • 10 — Indique que la passerelle devrait placer la connexion dans le mode de conférence.

  • les INFORMATIONS du tate (S) — exemple : S=4,4 que l'entier de poing affiche que l'état d'appel des gens du pays MGCP et le deuxième entier affiche l'état d'appel du distant MGCP.

    MGCP_CALL_IDLE = 0, inactif
    MGCP_CALL_SETTING = 1, appel entrant de PSTN
    MGCP_CALL_CONNECTING = 2, MGCP CRCX reçu
    MGCP_CALL_CONFERENCING = 3, appel connecté, attendent le conf
    MGCP_CALL_ACTIVE = 4, conférence créée
    MGCP_CALL_CONF_DESTROYING = 5, conférence de destruction
    MGCP_CALL_DISCONNECTING = 6, téléconférence détruit, appel de débranchement
    MGCP_CALL_INACTIVE = 7, appel en mode inactif
    MGCP_CALL_VOICE_CONNECTING = 8, créant le tronçon d'appel de téléphonie seulement
    MGCP_CALL_VOICE_ACTIVE = 9, tronçon d'appel de téléphonie créé
    MGCP_CALL_CONF_DISSOCIATING = 10, conf de destruction
    MGCP_CALL_CALLLEGS_DISSOCIATED =11, téléconférence détruit, aucun discon d'appel
    MGCP_CALL_HP_CONNECTING = 12, connecter le tronçon d'appel d'épingle à cheveux TDM
    MGCP_CALL_HP_CONNECTED = 13, un tronçon d'appel de HP connecté
    MGCP_CALL_HP_CONFERENCING = 14, tronçon d'appel d'épingle à cheveux des Conférences TDM
    MGCP_CALL_HP_ACTIVE = 15, état active hairpining TDM
    MGCP_CALL_VOIP_CONF_DESTROY = 16, téléconférence détruit, font l'appel de HP
    MGCP_CALL_ERROR_STATE = 17, appel dans l'état d'erreur
    MGCP_CALL_CONNECTING_INACTIVE = 18, créant la connexion inactive
    MGCP_CALL_CONF_DESTROYING_INACTIVE = 19, détruisent téléconférence les conn. inactives
    MGCP_CALL_CONT_TEST = 20, test de continuité AAL2/IP (xrbk)
    MGCP_CALL_SETUP_WAIT = 21, attendant l'information de configuration
    MGCP_CALL_WAIT_NSE_SENT = 22, attente l'événement NSE à envoyer
    MGCP_CALL_TWC_ACTIVE = 23, appel est actif TWC
    MGCP_CALL_WAIT_STATE = 24, app attend le Contrôle d'appel
    MGCP_CALL_HANDOVER = 25, app saisit soutiennent le contrôle
    MGCP_CALL_EM_DISCONNECTING = 26, appel de débranchement, points finaux E&M
    MGCP_CALL_MAX_STATE = 27

  • les INFORMATIONS d'odec (de C) — exemple : C=1

    MGCP_CODEC_UNDEFINED 0
    MGCP_G711_U, 1 = G.711 MU-loi
    MGCP_G711_A, 2 = G.711 a-law
    MGCP_G726_32K, 3 = G.726 32K
    MGCP_G726_24K, 4 = G.726 24K
    MGCP_G726_16K, 5 = G.726 16K
    MGCP_G729, 6 = G.729
    MGCP_G729_A, 7 = G.729-A
    MGCP_G729_B, 8 = G.729-B
    MGCP_G729_B_LOW_COMPLEXITY, 9 = G.729-B
    MGCP_G728, 10 = G.728
    MGCP_G7231_HIGH_RATE, 11 = haut débit G.723.1
    MGCP_G7231_A_HIGH_RATE, 12 = haut débit de l'annexe A G.723.1
    MGCP_G7231_LOW_RATE, 13 = G.723.1 à bas taux
    MGCP_G7231_A_LOW_RATE, 14 = annexe A G.723.1 à bas taux
    MGCP_GSM_FULL_RATE, 15 = GSM à toute vitesse
    MGCP_GSM_HALF_RATE, 16 = GSM à moitié vitesse
    MGCP_GSM_ENHANCED_FULL_RATE, 17 = à toute vitesse amélioré GSM
    MGCP_GSM_ENHANCED_HALF_RATE, 18 = à moitié vitesse amélioré GSM
    MGCP_CLEAR_CHANNEL = 128, 128 = canal Nx64 clair
    MGCP_NSE = 129 Pour NSE

  • Aération (E) — exemple : E=3,0,2,3 le champ d'événement est lu en tant que : E=last_successful_mgcp_event, last_successful_internal_event, last_failed_app_event, last_requested_app_event

    MGCP_APP_EV_ACK = -1, MGCP ACK
    MGCP_APP_EV_CREATE_CONN = 0, Le MGCP créent des msg de connexion
    MGCP_APP_EV_DELETE_CONN, =1 Msg de connexion d'effacement MGCP
    MGCP_APP_EV_MODIFY_CONN, =2 Le MGCP modifient des msg de connexion
    MGCP_APP_EV_NOTIFY_REQ, =3 Le MGCP informent des msg de demande
    MGCP_APP_EV_ALERT, =4 Événement vigilant CCAPI
    MGCP_APP_EV_CALL_CONNECT,=5 L'appel CCAPI connectent l'événement
    MGCP_APP_EV_CONF_RDY,=6 Conférence CCAPI prête
    MGCP_APP_EV_CONF_DESTROY,=7 Conférence CCAPI détruite
    MGCP_APP_EV_CALL_DISCONNECT,=8 Débranchement d'appel CCAPI
    MGCP_APP_EV_CALL_PROCEED, =9 Démarche d'appel CCAPI
    MGCP_APP_EV_OFF_HOOK,=10 Hors fonction-crochet CCAPI/établissement d'appel Ind
    MGCP_APP_EV_ON_HOOK, =11 CCAPI avec combiné raccroché/appel déconnecté
    MGCP_APP_EV_MEDIA_EVT,=12 Événements de medias MGCP
    MGCP_APP_EV_INT_EVT,=13 Événements internes MGCP
    MGCP_APP_EV_DISSOC_CONF,=14  
    MGCP_APP_EV_ASSOC_CONF,=15  
    MGCP_APP_EV_MODIFY_DONE,=16 L'appel CCAPI modifient l'ev fait
    MGCP_APP_EV_VOICE_MODE_DONE,=17 La Voix Coupe-à travers s'est produite
    MGCP_APP_EV_NSE,=18 Événements CCAPI NSE
    MGCP_APP_EV_CALL_HANDOFF,=19 Appel de transfert à un autre app
    MGCP_APP_EV_MAX_EVENT  

  • Esult (R) — exemple : R=0,0 le champ de résultat est interprété en tant que : R=Event_result, (booléen) font nous doit envoyer l'ACK ?

    MGCP_APP_EVR_NORMAL_OK = 0, Événement normal MGCP traité CORRECT
    MGCP_APP_EVR_INVALID_OK, Événement non valide MGCP traité CORRECT
    MGCP_APP_EVR_CALLP_REL, l'enregistrement d'appel est sorti
    Erreurs de protocole/* MGCP *
    MGCP_APP_EVR_INVALID_CALL_ID = 10, Id d'appel non valide de découverte TGW
    MGCP_APP_EVR_INVALID_CONNECTION_ID, Le TGW trouvent l'id non valide de connexion
    MGCP_APP_EVR_DUPLICATED_MESSAGE, Msg de sgcp reproduits par découverte TGW
    MGCP_APP_EVR_MGCP_ACK_FAILURE, Le TGW ne peut pas envoyer des msg du sgcp ACK
    MGCP_APP_EVR_MGCP_DELETE_FAILURE, Le TGW ne peut pas envoyer des msg d'effacement de sgcp
    MGCP_APP_EVR_MGCP_CREATE_ACK_FAILURE, Le TGW ne peut pas envoyer créent des msg ACK
    MGCP_APP_EVR_MGCP_CREATE_ACK_MISSING, Le TGW n'a pas envoyé des msg du sgcp ACK
    MGCP_APP_EVR_MGCP_DELETE_ACK_FAILURE, Le TGW ne peut pas envoyer des msg de l'effacement ACK
    MGCP_APP_EVR_MGCP_NOTIFY_FAILURE, Le TGW ne peut pas envoyer le sgcp informent des msg
    MGCP_APP_EVR_INVALID_STATE, Événement de découverte TGW dans l'état faux
    Problème de ressource/* *
    MGCP_APP_EVR_TGW_DOWN = 30, TGW en mode gracieux d'arrêt
    MGCP_APP_EVR_TGW_NOT_READY, TGW non prêt pour l'événement
    MGCP_APP_EVR_CALL_VDB_FAILURE, Le TGW ne peut pas obtenir le vdbptr
    MGCP_APP_EVR_PREV_RTP_PORT_LOCKED, Le TGW trouvent le port précédent de rtp verrouillé
    MGCP_APP_EVT_CONN_RECORD_MISSING, Le TGW ne peut pas trouver l'enregistrement conn.
    MGCP_APP_EVR_ENDP_NOT_READY, TGW non prêt pour l'événement
    MGCP_APP_EVR_MEM_RSRC_ERROR, Le TGW fait errer l'alloc passager de mem
    MGCP_APP_EVR_CALL_CAC_FAILURE, Le gw n'a pas la bande passante
    MGCP_APP_EVR_CONF_RSRC_ERROR, Le gw ne peut pas obtenir la ressource en conf
    Panne d'événement/* *
    MGCP_APP_EVR_REQ_EVENT_FAILURE = 40, Le TGW ne peut pas manipuler l'événement demandé
    MGCP_APP_EVR_INVALID_CCAPI_EVENT, Le TGW ne peut pas manipuler l'événement de ccapi
    MGCP_APP_EVR_IGNORE_CCAPI_EVENT, Le TGW ignorera l'événement de ccapi
    Panne de signal/* *  
    MGCP_APP_EVR_SIGNAL_FAILURE = 50, Le TGW ne peut pas manipuler le signal
    MGCP_APP_EVR_ABNORMAL_ONHOOK, Le TGW trouvent l'onhook anormal
    MGCP_APP_EVR_INVALID_OFFHOOK, Le TGW trouvent l'offhook non valide
    MGCP_APP_EVR_INVALID_COT, Le TGW trouvent le COT non valide
    MGCP_APP_EVR_COT_FAILURE, Le TGW n'a pas fait le COT
    MGCP_APP_EVR_COT_DISABLE_FAILURE, Le TGW n'a pas désactivé le COT
    Panne d'établissement d'appel/* *
    MGCP_APP_EVR_CALL_SETUP_REQ_FAILURE = 60, Le TGW ne peut pas installer la demande d'appel
    MGCP_APP_EVR_CALL_SETUP_IND_FAILURE, Le TGW ne peut pas manipuler l'indication d'appel
    MGCP_APP_EVR_CALL_CONTEXT_FAILURE, Le TGW ne peut pas installer le contexte
    MGCP_APP_EVR_CALL_PEER_FAILURE, Le TGW ne peut pas installer le pair
    MGCP_APP_EVR_CALL_VOX_CALL_FAILURE, Le TGW ne peut pas installer l'appel voip/voaal2
    MGCP_APP_EVR_CALL_VOIP_CALL_FAILURE, Le TGW ne peut pas installer l'appel de voip
    MGCP_APP_EVR_CALL_DISCONNECT_FAILURE, Le TGW ne peut pas déconnecter l'appel
    MGCP_APP_EVR_CALL_MODIFY_FAILURE, Le TGW ne peut pas modifier le parm d'appel
    MGCP_APP_EVR_CALL_ALERT_FAILURE, Le TGW ne peut pas alerter l'appel
    MGCP_APP_EVR_CALL_DELETE_FAILURE, Le TGW ne peut pas supprimer l'appel
    MGCP_APP_EVR_CALL_UNKNOWN_FEATURE, Le TGW ne peut pas manipuler la caractéristique d'unknow
    MGCP_APP_EVR_UNSUPPORTED_CODEC, Le TGW trouvent des codecs sans support
    MGCP_APP_EVR_NO_DIGIT_MAP, Le TGW ne peut pas trouver la carte de chiffre
    MGCP_APP_EVR_IGNORE_DIGIT, Le TGW ne peut pas traiter les chiffres
    MGCP_APP_EVR_DIGITS_OVERFLOW, Le TGW ne peut pas manipuler trop de chiffres
    MGCP_APP_EVR_DIGITS_NOTIFY_FAILURE, Le TGW ne peut pas envoyer les chiffres
    MGCP_APP_EVR_CODEC_NOT_MATCHED, Le codec TGW n'apparie pas le TGW de rmt
    MGCP_APP_EVR_INVALID_CONN_MODE, Le TGW ne peut pas comprendre le mode d'escroquerie
    Panne de pair/* *
    MGCP_APP_EVR_PEER_MISSING = 90, Découverte TGW ne pas trouver le pair
    MGCP_APP_EVR_PEER_NOT_READY, Pair de découverte TGW non prêt
    MGCP_APP_EVR_PEER_IN_WRONG_STATE, Le TGW trouvent le pair dans l'état faux
    MGCP_APP_EVR_PEER_DISCONNECT_FAILURE, Le TGW ne peut pas déconnecter le pair
    MGCP_APP_EVR_NO_CONFERENCE_ID, Le TGW ne peut pas trouver l'ID de conférence
    MGCP_APP_EVR_CONF_CREATE_FAILURE, Le TGW ne peut pas créer la conférence
    MGCP_APP_EVR_CONF_DESTROY_FAILURE, Le TGW ne peut pas détruire la conférence
    MGCP_APP_EVR_UNKNOWN_CONN_TYPE, Le TGW ne peut pas manipuler le type d'escroquerie
    MGCP_APP_EVR_INVALID_ENDPOINT, Le TGW ne peut pas se connecter au point final
    MGCP_APP_EVR_INVALID_NSE_EVENT = 100, Événement non valide NSE
    MGCP_APP_EVR_NSE_RCVD_ON_WRONG_LEG, Les événements NSE été livré à un tronçon faux
    MGCP_APP_EVR_SEND_NSE_FAILURE, Ne peut pas envoyer un événement NSE
    MGCP_APP_EVR_PLAY_TONE_FAILURE, Ne peut pas jouer la tonalité NSE-demandée
    Erreur passagère/* *
    MGCP_APP_EVR_TRANS_ERROR = 110, Point final TGW dans l'état de transition
    MGCP_APP_EVR_MAX_RESULT  

Causes possibles et actions recommandées

Comprenant et définissant votre problème

Des appels de coupure micro peuvent être liés aux problèmes logiciels ou à d'autres questions. Employez les étapes suivantes pour commencer à dépanner des faire appel muets à Cisco PGW 2200.

  1. Comprenez la description du problème du client. Les appels de coupure micro peuvent être liés à d'autres éléments qui ne sont pas liés aux erreurs logicielles telles que le Routage IP et poser les problèmes 1. La solution de chaque cause principale expose souvent les problèmes plus élémentaires supplémentaires qui doivent être réparés d'abord.

  2. Calculez le rapport des appels défaillants pour mettre en sommeil des appels au site client par surveillance de 24 heures.

  3. Évitez de définir exactement quel pourcentage d'appels sont alarmants.

  4. Essayez de reproduire cette situation pour comprendre la vraie cause du problème.

Vérifier le chargement CPU sur PGW 2200

Pour vérifier le chargement CPU sur le PGW 2200, émettez la commande suivante :

mml> rtrv-ne-health

Cette commande affiche le type suivant d'informations :

MGC-01 - Media Gateway Controller 2003-02-14 15:36:50.788 GMT 
M RTRV 
"Platform State:ACTIVE" 
"Machine Congestion Level = MCL 0 (No Congestion)" 
"Current in progress calls = 83, call attempts = 2 cps" 
"CPU 0 Utilization = 1 % CPU 1 Utilization = 0 %" 
"CPU 2 Utilization = 2 % CPU 3 Utilization = 0 %" 
"Memory (KB):3715344 Free virtual, 8390328 Total virtual, 4194304 
Total rea" 
"Filesystem kbytes used avail capacity Mounted on" 
"/dev/dsk/c0t0d0s0 494235 47099 397713 11% /" 
"/dev/dsk/c0t0d0s4 10678328 5494165 5077380 52% /opt" 
;

Vérifiez les appels par informations et essai de la seconde (CPS) pour calculer ceci en combination avec les passerelles que vous utilisez. Peut-être quelques passerelles ont un chargement CPU de haute dû à la quantité d'appels étant livré dedans. L'affichage suivant de résultat dans platform.log peut également expliquer le statut du système.

Fri Nov 13 10:18:28:119 2002 CET | engine (PID 14488) <Error>engMclMgrImpl::updateSystemMcl:
 System Mcl = 1, MclName = cpu, Load = 84 AvgLoad = 68

Remarque: Dans cet exemple, il y avait une surcharge CPU due au trafic élevé qui a diminué en quelques minutes. C'a lieu en raison de la période d'heure de pointe. À ce moment là, essai pour joindre ces informations avec des appels muets.

Vérifier le chargement CPU sur les passerelles

Pour obtenir un état avec une heure, émettez la commande suivante :

as5xxx-1> show proc cpu history

Un chargement CPU de haute peut sont provoqué par par un des éléments étant joints pour traiter la commutation. Pour vérifier ceci, émettez le show running-config | y compris la commande d'artère.

as5xxx-1> show running-config | incl route 

Pour éviter un chargement CPU de haute sur la passerelle, n'ayez pas les commandes suivantes dans vos configurations :

no ip route-cache
no ip route-cache cef 

Remarque: La commande d'ip route-cache ou de cef d'ip route-cache devrait être configurée sur les passerelles.

Si vous voyez ci-dessus l'un des, vous êtes commutation de processus le plus susceptible au lieu de commutation rapide et la charge du système sera extrêmement élevée, des appels peuvent être perdus, et la Qualité vocale sera pauvre. Supplémentaire, le message MGCP ne peut être reconnu (ACK) ou être généré.

Messages RSIP non envoyés sur des Ethernets secondaires

Selon la manière que la commande d'hôte d'IP est configurée sur les passerelles, il n'enverra pas des messages RSIP sur les Ethernets secondaires. La raison que la passerelle essaye d'envoyer à la première adresse IP pour un deuxième rond des essais avant de basculer à la deuxième adresse IP est liée à la configuration du logiciel de Cisco IOSÝ. Ceci force une consultation de DN (qui regarde une commande d'hôte d'IP quand aucune commande d'ip domain-lookup n'est configurée). Quand ceci se produit, la première adresse IP est retournée et utilisée de nouveau. Pour éviter ce comportement, utilisez la commande suivante dans le mgcp profile :

as5xxx-1> mgcp profile 
as5xxx-1> no max1 lookup 

Remarque: Vous devez recharger le routeur pour l'aucune configuration de commande de max1 lookup pour prendre effet.

Suggestions muettes de dépannage d'appel

Exécutez les étapes suivantes pour déterminer s'il y a les questions supplémentaires dans votre réseau.

  1. Déterminez si la durée de l'appel est moins de 10 secondes.

  2. Déterminez si les paquets de transmission (Tx) ou recevez les paquets (de Rx) sont zéro.

    as5xxx-1> show mgcp connection 

    Et contrôle sur Call_ID, qui est 3334373 pour cet exemple.

    Endpoint            Call_ID(C)   Conn_ID(I)                                 (P)ort                 (M)ode (S)tate (CO)dec (E)vent[SIFL] (R)esult[EA] 
                1. S6/DS1-1/31 C=345F3D,3334373,3334374  I=0x197074  P=19544,18424  M=3  S=4,4 CO=6 E=2,0,0,2  R=0,0
  3. Essayez de joindre Call_ID utilisant ce qui suit :

    as5xxx-1 > show call active voice brief | incl Call_ID
     
    Tele 0/0:0 (call_id): tx:0/0/0ms None noise:0 acom:0  i/0:0/0 dBm 
    
  4. En ce moment, vous pouvez trouver les informations de la commande de show call active voice, jointe sur Conn_ID les informations pour trouver des paquets de Tx, des octets de Tx, des paquets de Rx, et de Rx octets. Ces informations peuvent t'indiquer les nombres de paquets étant envoyés et reçus.

    Telephony call-legs: 1 
    SIP call-legs: 0 
    H323 call-legs: 0 
    Total call-legs: 2 
    0    : 482619719hs.1 +0 pid:0 Originate  active 
     dur 00:12:35 tx:42517/711257 rx:24197/661142 
     Tele 6/1:0 (3334373): tx:755060/278000/0ms g729r8 noise:-120 acom:90  i/0:-51/-12 dBm 
    0    : 482619719hs.2 +-1 pid:0 Originate  connecting 
     dur 00:00:00 tx:24192/660942 rx:42517/711257 
     IP 0.0.0.0:18424 rtt:1ms pl:280000/37390ms lost:347/1/0 delay:40/30/120ms g729r8 

    Dans ce cas, vous pouvez trouver les détails de gens du pays et de passerelle distante.

    as5xxx-1 > show voip rtp connections 
    VoIP RTP active connections : 
    No. CallId  dstCallId  LocalRTP RmtRTP LocalIP         RemoteIP 
    1   3334374 3334373    19544    18424  193.41.31.2     193.41.24.5
  5. Déterminez si un plus grand pourcentage des appels muets se produisent au cours des périodes d'activité.

Dans des situations rares, des paquets envoyés par Cisco AS5400 ne peuvent être reçus par l'interface de Cisco AS5300 TDM. Si ceci se produit, Cisco AS5400 DLCX ACK affiche des paquets de Tx, mais Cisco AS5300 n'affiche aucun paquet de Rx. L'interface de bouclage est importante pour la connexion MGCP en combination avec la commande de mgcp bind.

Remarque: L'implémentation MGCP emploie la meilleure adresse IP disponible sur le MGC comme adresse source pour communiquer avec l'agent d'appel. Le flux multimédia utilise l'adresse de bouclage si configuré, autrement la meilleure adresse IP disponible en tant que son adresse source. Il n'y a aucune manière définie de changer ce comportement. La commande de grippage laisse plus de flexibilité pour choisir l'adresse source pour des paquets de contrôle et de medias.

Répertoriées ci-dessous sont quelques situations qui expliquent le comportement de la commande. Pour tous ces cas, le message d'avertissement approprié sera affiché selon la situation.

  • Quand il y a en activité le MGCP fait appel à la passerelle, la commande de grippage sera rejetée pour le contrôle et les medias.

  • Si le bind interface n'est pas en hausse, alors la commande est reçue, mais elle ne prend pas l'affect jusqu'à ce que l'interface soit soulevée.

  • Si l'adresse IP n'est pas assignée sur le bind interface, la commande de grippage est reçue mais elle la prend effet seulement après que l'adresse IP valide est assignée, pendant ce temps si les appels MGCP sont en hausse, la commande de grippage est retirée.

  • Quand l'interface attachée descend, ou en raison d'un manuel fermez sur l'interface ou en raison d'une panne opérationnelle, l'activité de grippage est désactivée sur cette interface.

  • Quand le grippage n'est pas configuré sur le MGC, l'adresse IP l'a utilisé pour le contrôle de l'approvisionnement MGCP et le support est mieux adresse IP disponible.

Tâches supplémentaires rapportées pour mettre en sommeil des appels

Un des critères que le PGW 2200 l'utilise pour signaler un appel muet est que l'appel devrait être dans l'état de réponse, ainsi ce signifie que le message ANM devrait avoir été envoyé par le PGW 2200 au commutateur SS7 d'origine. Avant d'envoyer le message ANM au commutateur SS7 d'origine, le PGW 2200 transmet le MDCX au gw pour placer le mode pour envoyer-Recv. Si le MDCX n'est pas reconnu par le gw dû à la Connectivité ou à d'autres questions, l'appel n'atteint pas l'état de réponse, par conséquent il n'est pas dépisté car un appel muet. À ce moment là, un journal des erreurs sera envoyé au fichier de platform.log à choisissent/CiscoMGC/distributeur intégrant son logiciel au matériel/log.

Commande MGCP renvoyée

Si le message de commande MGCP (CRCX, DLCX, MDCX) est dû renvoyé à une minuterie (par exemple PGW 2200 MDCX envoyé [sendrecv] quatre fois), mais la passerelle n'a pas fait ACK il, l'appel échoue et qu'il n'est pas considéré un appel muet par le PGW 2200. PGW 2200 signale un appel muet (coupure micro-message dans platform.log) pendant le DLCX si :

  1. L'appel a été répondu, et

  2. un message de 250 OKS a eu le paramètre de connexion (P :), et

  3. La picoseconde ou les RP était 0 dans (P :)

Remarque: Ceci peut être lié à d'autres éléments non joints comme un vrai appel muet. Par exemple, si l'appelant raccroche quand les réponses d'appelé, vous voient ce message et il est correct. Mais ce n'est pas un appel muet. Pour des appels d'épingle à cheveux (le hairpinning est le nom donné aux appels qui commencent et se terminent sur le même routeur ou passerelle), le message de 250 OKS en réponse à DLCX n'a pas le paramètre de connexion (P :). Ces appels sont ne sont pas signalés en tant que coupure micro.

Compréhension du journal des erreurs

Une erreur est écrite dans le format suivant pour renvoyer les informations :

mgcp_link_comp_id ioCcMgcpConnMgr: mgcpCmdRequestTimeout: Successfully resent txn:transaction_id msg:
 message cnt:no_of_retry remaning

Exemple :

Tue Jul 16 11:05:46:219 2002 EST | mgcp-1 (PID 20828) <Error> 
00100001 ioCcMgcpConnMgr: mgcpCmdRequestTimeout: Successfully resent txn:1718 msg:DLCX 1718 s13/ds1-20/28@tasty-7 MGCP 0.1 
C: 72 
I: 16 
R: 
S: 
X: 6B5 
 cnt:1.

Transaction supprimée

Si une transaction est supprimée après que le maximum relance, une erreur est écrite dans le format suivant :

MGCP Link Comp Id ioCcMgcpConnMgr: mgcpCmdRequestTimeout: type message type, cnt: <-1>,
 txn:transaction_id, connMsgPtr pointer to message

Exemple :

Tue Jul 16 11:05:50:218 2002 EST | mgcp-1 (PID 20828) <Error> 
00100001 ioCcMgcpConnMgr: mgcpCmdRequestTimeout: type 5, cnt:-1, txn: 1718, connMsgPtr 0027b718

Émettez la commande stat de show mgcp de vérifier les éléments défectueux et l'essai pour comprendre pourquoi une transaction a été supprimée.

Collecter un suivi de MDL sur le PGW 2200

Si tous les éléments sont corrects, exécutez un suivi de MDL et collectez tous les détails du show log command sur le gw. Les étapes suivantes affichent comment collecter le suivi de MDL :

  1. Identifiez le nombre d'origine SS7 SigPath ou lancer le nombre de TrunkGroup sur lequel des appels sont placés.

  2. Commencez le suivi de MDL par émettre la commande suivante :

    mml> sta-sc-trc:ss7sigPath name | orig
    		  trunkgroup number
    
    
  3. Réalisez un essai.

  4. Arrêtez le suivi de MDL en émettant la commande suivante :

    mml> stp-sc-trc:all
    
  5. Identifiez l'id d'appel (C :) du mauvais appel du MGCP mettent au point sur la passerelle.

  6. Convertissez le suivi de MDL en format accessible en lecture :

    mml> get_trc.sh trace file name
    
    
  7. Id d'appel de type à la demande à brancher au suivi de MDL du mauvais appel.

  8. Choisissez le C d'option pour convertir le fichier de suivi.

  9. Le fichier de suivi est dans /opt/CiscoMGC/var/trace.

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: 44183