Composition et accès : "Réseaux numériques à intégration de services (RNIS), canal de signalisation associé (CAS)"

Dépannage de la couche 3 de l'accès de base RNIS à l'aide de la commande debug isdn q931

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


Contenu


Introduction

Des questions d'échec d'appel RNIS de pour le dépannage, il est important de maintenir dans l'esprit que l'appel pourrait être manquer dû à suivre l'un des :

  • Routage à établissement de connexion à la demande (DDR)

  • Couches RNIS 1, 2 et 3

  • Protocole point à point (PPP) : y compris le Link Control Protocol (LCP), les questions connexes d'authentification ou de protocole de contrôle IP (IPCP).

Ce document se concentre spécifiquement sur les questions connexes RNIS qui entraînent des échecs d'appel. Ce document suppose également que vous avez vérifié que les couches RNIS 1 et 2 sur les deux extrémités du circuit fonctionnent. Référez-vous utilisant la commande d'état de show isdn pour le dépannage BRI pour plus d'informations sur vérifier la couche RNIS 1 et l'état 2.

Conditions préalables

Conditions requises

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

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.

Conventions

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

Configurations requises pour le dépannage : La couche RNIS de lancement 3 met au point

Employez le debug isdn q931 de commande sur les deux extrémités pour lancer la couche RNIS 3 met au point. Vous devriez également avoir des horodatages en millisecondes pour met au point activé sur les deux Routeurs. Les horodateurs sont nécessaires pour fournir les données relatives au processus de dépannage.

Remarque: Lancez les horodatages en millisecondes pour met au point utilisant les commandes suivantes :

maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec

Pour plus d'informations sur des commandes de débogage référez-vous aux informations importantes sur des commandes de debug.

Initiez l'appel RNIS

Générez un ping d'ICMP à l'adresse IP du routeur distante. Ceci devrait initier un appel RNIS à ce routeur. Les deux Routeurs génèreront des messages de debug isdn q931.

Il peut y avoir beaucoup de variations des échanges Q.931 dus aux conditions requises spécifiques pour des types de commutateur RNIS ou dans les cas où des paramètres supplémentaires sont exigés. Le diagramme suivant montre les transactions Q.931 communes pendant un établissement d'appel réussi RNIS.

/image/gif/paws/9495/isdn_q931_ts_1.gif

Remarque: Certaines des lignes suivantes de sortie de débogage sont divisées en plusieurs lignes pour des raisons d'impression.

J'appelle le routeur Router appelé
maui-soho-01#
18:39:29.425: ISDN BR0: TX -> SETUP
    pd = 8  callref = 0x10

!-- The Calling Router Transmits
!-- (indicated by TX) the SETUP message

18:39:29.433:
         Bearer Capability i = 0x8890
18:39:29.441: Channel ID i = 0x83
18:39:29.449:
         Keypad Facility i = '5558888'
18:39:29.822: ISDN BR0: RX <- CALL_PROC
    pd = 8  callref = 0x90

!-- The telco switch responds with a
!-- Call Proceeding. This indicates the 
!-- network is processing the call.

18:39:29.830:
         Channel ID i = 0x89
.
.
.

!-- Nothing has been omitted here. The
!-- dots were put in place to align
!-- the Called and Calling Routers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18:39:30.000: ISDN BR0: RX <- CONNECT
    pd = 8  callref = 0x90

!-- Received a CONNECT from the remote 
!-- router. The ISDN connection has been
!-- established. Any failures of the call
!-- past this point are due to higher
!-- level issues such as DDR, PPP, 
!-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK
    pd = 8  callref = 0x10

!--- The Router responds with a Connect
!--- Acknowledgment (CONNECT_ACK) 
!--- to the telco.

maui-nas-08#
18:39:29.647: ISDN BR2/0: RX <- SETUP
    pd = 8  callref = 0x08

!-- The Called Router receives
!-- (indicated by RX) a SETUP message 
!-- from the switch

18:39:29.647:
    Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital. 

18:39:29.647: Channel ID i = 0x89
18:39:29.647:
    Signal i = 0x40 - Alerting on -
    pattern 0 
18:39:29.647:
    Called Party Number i = 0xC1,'5558888',
    Plan:ISDN, Type:Subscriber(local)
18:39:29.647:
    Locking Shift to Codeset 5
18:39:29.647:
    Codeset 5 IE 0x2A  
    i = 0x808001038001118001, '<'
18:39:29.651:
    ISDN BR2/0: Event: Received a DATA 
    call from  on B1 at 64 Kb/s
18:39:29.651: ISDN BR2/0: TX -> CALL_PROC
    pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding
 
18:39:29.655:
         Channel ID i = 0x89
18:39:29.655: %LINK-3-UPDOWN:
 Interface BRI2/0:1, changed state to up
18:39:29.955: ISDN BR2/0: TX -> CONNECT
    pd = 8  callref = 0x88

!--- Call is accepted and the routers sends
!--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89
18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK
    pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK
!--- from the switch

18:39:29.995:
         Channel ID i = 0x89
18:39:29.995:
         Signal i = 0x4F - Alerting off 
18:39:35.655: %ISDN-6-CONNECT:
 Interface BRI2/0:1 is now
 connected to unknown 

En évaluant la sortie de debug isdn q931 sur appeler et les extrémités appelées, maintenez les points suivants dans l'esprit :

  • Prêtez l'attention à la direction des messages. Met au point indiquent si les messages ont été générés par le routeur (indiqué par TX - >) ou s'ils étaient reçus par le routeur (indiqué par RX <--. Dans l'exemple ci-dessous, le premier message (CONNECTEZ) est reçu par le routeur du commutateur RNIS, alors que le deuxième (CONNECT_ACK) est envoyé par le routeur :

    18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90
    18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10
    
    

    Vous pouvez identifier la source de problème en suivant la direction d'un message particulier et de la réponse. Par exemple, si le routeur reçoit inopinément un message de RELEASE du commutateur RNIS de l'opérateur de téléphonie, puis il remettra à l'état initial son extrémité de la connexion aussi bien. Ceci indique que la question se trouve avec le commutateur RNIS de l'opérateur de téléphonie ou le routeur distant

  • Vérifiez que le message reçu ou envoyé est prévu. Par exemple, si l'appelé reçoit un message de configuration mais envoie un DÉBRANCHEMENT au lieu d'un CONNECTER, puis dépannez Router appelé et pas réseau RNIS. Le tableau suivant a une liste des messages Q.931 possibles vus pendant l'établissement et la désinstallation d'appel :

Message Description
INSTALLATION Installation -- Indique qu'un périphérique souhaite établir un appel de la couche 3
CALL_PROC Démarche d'appel -- L'établissement d'appel a été reçu et est traité par le réseau et/ou le périphérique distant
ALERTE Alerte -- Informe le réseau que le routeur d'extrémité maintenant « alerte » l'utilisateur ; ce serait normalement la caisse pour un téléphone et l'alerte serait la « sonnerie » sur le combiné téléphonique. Ce message est normalement associé avec le matériel utilisant un combiné téléphonique, tel qu'un téléphone RNIS ou MERCI et n'est pas habituellement vu pour des appels de données.
CONNECTEZ Connectez -- L'appel est reçu
CONNECT_ACK Connectez reconnaissent -- Le périphérique a reçu le message de CONNECTER. Les protocoles de couche plus élevée (ex. Le PPP) devrait maintenant commencer la négociation
DÉBRANCHEMENT Débranchement -- Message de débranchement initié par routeur. Ce message indique habituellement que le circuit RNIS fonctionne et que le débranchement était le résultat de quelques questions plus élevées de couche (DDR, PPP tellement en avant et ainsi de suite). La prise de contact à trois voies de débranchement sera accompagnée des messages de RELEASE et RELEASE_COMP. Le message de DÉBRANCHEMENT est également accompagné de code de motif de déconnexion. Ce code de débranchement peut être utilisé pour indiquer exactement d'où l'appel a été déconnecté (par exemple, l'appel a été déconnecté du routeur, du commutateur de l'opérateur de téléphonie local, du commutateur de l'opérateur de téléphonie distant tellement en avant et ainsi de suite.). Pour plus de détails référez-vous compréhension derrière codes de motif de déconnexion de debug isdn q931
RELEASE Libérez -- Reconnaît le DÉBRANCHEMENT et continue la désinstallation de circuit. Le message de RELEASE est serré entre les messages de DÉBRANCHEMENT et RELEASE_COMP. Le message de RELEASE peut être accompagné de code de motif de déconnexion. Ce code de débranchement peut également être utilisé pour indiquer exactement d'où l'appel a été déconnecté (par exemple, l'appel a été déconnecté du routeur, du commutateur de l'opérateur de téléphonie local, du commutateur de l'opérateur de téléphonie distant). Pour plus de détails référez-vous compréhension derrière codes de motif de déconnexion de debug isdn q931
RELEASE_COMP Libérez complet -- La désinstallation d'appel est complète. Ce message est généralement - vu : a) Pendant une terminaison d'appel de normale initiée par un des Routeurs b) en réponse à un message de configuration du routeur appelant. Ceci est souvent provoqué par la non-concordance de la capacité de support entre le le commutateur et le routeur. Un RELEASE_COMP peut également être dû aux erreurs de protocole si le codage du message de configuration n'est pas conforme au Q.931 standard ou la configuration du commutateur le message RELEASE_COMP peut être accompagnée de code de motif de déconnexion. Ce code de débranchement peut également être utilisé pour indiquer exactement d'où l'appel a été déconnecté (par exemple, l'appel a été déconnecté du routeur, du commutateur de l'opérateur de téléphonie local, du commutateur de l'opérateur de téléphonie distant). Pour plus de détails référez-vous compréhension derrière codes de motif de déconnexion de debug isdn q931

Vue d'ensemble du dépannage : Procédure de symptôme et de résolution

Analysez le debug isdn q931 sorti comme décrit dans les sections précédentes, et poursuivez au symptôme approprié discuté ci-dessous.

Remarque: Dans ce document, le routeur qui initie l'appel désigné sous le nom du routeur appelant, alors que le routeur qui reçoit l'appel désigné sous le nom de Router appelé.

Dépannage : Symptôme et procédure détaillée de résolution

Le routeur appelant n'envoie pas un message de configuration

/image/gif/paws/9495/isdn_q931_ts_table1.gif

Si le routeur appelant n'envoie pas un message de configuration au réseau RNIS, le problème est vraisemblablement lié aux couches RNIS 1, 2 ou le Routage à établissement de connexion à la demande (DDR) émet, et n'est pas la couche 3 associée

Effectuez les tâches suivantes sur le routeur appelant :

  • Vérifiez que le switchtype RNIS est correctement configuré :

    Le switchtype RNIS peut être vérifié utilisant l'état de show isdn de commande. La compagnie de téléphone devrait explicitement indiquer le switchtype qui doit être configuré. De temps en temps (particulièrement en Amérique du Nord) la compagnie de téléphone peut indiquer que le switchtype est « coutume » ou « ressortissant ». En pareil cas, employez les instructions suivantes pour déterminer la configuration switchtype :

    • Coutume : Si la compagnie de téléphone indique que leur commutateur-type est fait sur commande, alors configurez le switchtype sur le routeur comme basic-5ess (pour BRI avec commutateur 5ess), primary-5ess (pour le PRI avec 5ess), de base-SGD (pour BRI avec le commutateur de SGD), ou primaire-SGD (pour le PRI avec de la SGD).

    • Ressortissant : Switchtype conformément à la norme NI-1 pour la norme BRI et NI-2 pour le PRI (il n'y a aucune norme NI-1 pour PRIs). Si la compagnie de téléphone vous informe que le switchtype est national, alors la configuration de routeur Cisco devrait être de base-Ni (pour BRI) ou primaire-Ni (pour le PRI).

    Pour configurer le switchtype utilisez le commutateur-type de commutateur-type de la commande le RNIS dans le mode de configuration d'interface BRI. Pour un exemple référez-vous dépannage derrière la couche 1 RNIS BRI

  • Vérifiez que les couches RNIS 1 et 2 sur le routeur appelant fonctionnent :

    Vous pouvez vérifier que les couches RNIS 1 et 2 sont en hausse utiliser l'état de show isdn de commande. Utilisez la procédure tracée les grandes lignes dedans pour dépanner des questions connexes de la couche RNIS 1 et 2.

  • Utilisez la commande de show ip route de vérifier que le le routeur a une artère à la destination.

    La commande de show ip route indiquera s'il y a une artère au réseau de routeurs distant. Si l'artère n'existe pas, utilisez la commande d'artère d'IP d'ajouter une artère statique pour le réseau distant. Assurez-vous les points d'acheminement à l'interface appropriée sur le routeur appelant.

    Dans un environnement de DDR hérité (par exemple, des Cartes de composeur) le prochain saut devrait être l'un ou l'autre le réseau d'interface physique (interface bri x) ou l'adresse IP du routeur distante (qui devraient également avoir été configurés dans l'instruction de mappage de numéroteur).

    Avec des Profils de composeur, le prochain saut est habituellement l'interface dialer X utilisé pour le dialout. Exemple :

    maui-soho-01#show ip route
    ...
    ...
    !-- Output omitted
    
    ...
    
         10.0.0.0/24 is subnetted, 1 subnets
    C       10.0.0.0 is directly connected, Ethernet0
    S*   0.0.0.0/0 is directly connected, Dialer1
    

    Dans l'exemple ci-dessus, notez que le prochain saut de default route est l'interface dialer 1 (l'interface de routeur d'appels logique pour cette connexion).

  • Vérifiez que le trafic intéressant est correctement identifié.

    Le routeur vérifie pour vérifier qu'un paquet entrant est le trafic intéressant avant d'initier le cadran. Par conséquent, le routeur peut ne pas composer si le trafic intéressant est inexactement défini, ou si le numéro de la liste de numérotation (la définition du trafic intéressant) n'est pas appliqué à l'examen médical ou à l'interface de numérotation (utilisant la commande de nombre de dialer-group). Par exemple, si vous employez un ping d'ICMP pour initier la connexion DDR, vérifiez qu'on permet l'ICMP dans la définition du trafic intéressant.

    Référez-vous à configurer la numérotation de BRI à BRI avec le pour en savoir plus de dialer map DDR.

  • Vérifiez si la chaîne appropriée de numéroteur (ou la carte de numéroteur) inclut l'isdn number du périphérique distant.

    La chaîne de numéroteur (ou la carte de numéroteur) doit inclure l'isdn number de routeur distant. Exemple :

    dialer string 5551111
    or
    dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
    
  • Vérifiez la configuration DDR et l'utilisation mettent au point le numéroteur pour vérifier que le routeur initie l'appel :

    Vérifiez que la configuration DDR est correcte. Utilisez le document Technologie d'appel commuté : Aperçus et explications pour davantage d'assistance sur la configuration correcte DDR.

    Vous devriez également utiliser la commande mettez au point le numéroteur pour vérifier que le routeur reçoit le trafic intéressant et a la carte de numéroteur ou la chaîne appropriée de numéroteur pour initier le cadran. Référez-vous au document ci-dessus aussi bien qu'à la technologie d'accès commuté : Pour en savoir plus de techniques de dépannage.

    Référez-vous à la configuration d'échantillon suivante pour des exemples de la configuration de DDR approprié :

    Profils de composeur : Configurer le RNIS DDR avec le legs DDR (Cartes de composeur) de Profils de composeur : Configuration de l'accès commuté de BRI à BRI à l'aide du routage DDR (Dialer Maps)

    Conseil : Afin de tester, vous pouvez éliminer le DDR à l'aide de la commande d'appel RNIS (expliquée dans la section suivante) de générer un appel RNIS au périphérique distant. Si cet appel réussit alors vous pouvez être raisonnablement sûr que le circuit RNIS fonctionne. Continuez de dépanner le DDR.

  • Exécutez un appel de test de boucle locale

    Dans un appel en boucle, le routeur compose l'isdn number de son propre BRI. L'appel poursuit à l'entité de l'opérateur de téléphonie, où les commutateurs de la compagnie de téléphone l'appel au deuxième canal BRI. Cet appel est maintenant vu par le routeur comme appel entrant au deuxième canal. Par conséquent, le routeur envoie et reçoit l'appel RNIS.

    Un appel en boucle teste la capacité du routeur d'initier et terminer un appel RNIS. Un appel en boucle réussi te donne une indication forte que le circuit RNIS à l'entité de l'opérateur de téléphonie fonctionne correctement.

    Ce qui suit est un exemple annoté d'un appel en boucle réussi. Les enables le RNIS sortant d'appel de la commande le RNIS (introduit en logiciel 12.0(3)T de ½ de ¿  de Cisco IOSïÂ) appelle sans exiger les conditions requises DDR telles que le trafic intéressant et des artères. Cette commande peut seulement être utilisée pour le test du circuit RNIS et ne peut pas être utilisée pour passer le trafic ou comme substitution pour une configuration de DDR approprié. Cette commande nous permet pour vérifier que le circuit RNIS, particulièrement la couche 3, fonctionne.

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch.
!--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the 
!--- incoming call. Remember that the router sent a Setup message (for the
!--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: 
Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: 
Interface BRI0:1 is now connected to 5551111 

! ---  Call is now connected. Loopback call is successful

Notes :

  • Pendant l'appel en boucle, le routeur exécute en tant que Router appelé aussi bien que routeur appelant (quoique sur différents canaux B). Il est important que vous mainteniez ces « doubles rôles » en interprétant la sortie de debug isdn q931. Par exemple, le routeur transmet un message de configuration (TX - > INSTALLÉ) et reçoit un aussi bien (RX < - INSTALLATION). L'INSTALLATION transmise devrait être associée avec l'appel sortant tandis que le message SETUP reçu est associé avec l'appel entrant.

  • Dans l'exemple ci-dessus, nous avons composé le numéro pour le premier canal B. Cependant, la compagnie de téléphone identifiant que le premier canal B était occupé (puisqu'il faisait l'appel), commuté l'appel au deuxième canal B et la connexion a été terminée avec succès. Cependant, une mauvaise configuration dans le commutateur de la compagnie de téléphone peut avoir comme conséquence une panne de l'appel en boucle, due au commutateur essayant d'assigner l'appel au premier canal (qui est occupé à faire l'appel). La compagnie de téléphone devrait corriger ce problème. Cependant, comme une solution de contournement spécifient le deuxième nombre de canal B dans l'appel de la commande le RNIS.

  • Si l'appel en boucle réussit et l'appel à l'extrémité distante continue à échouer, entrez en contact avec la compagnie de téléphone pour davantage d'assistance de dépannage avec votre circuit BRI.

Router appelé ne reçoit pas un message de configuration

/image/gif/paws/9495/isdn_q931_ts_table2.gif

Si vous déterminez que le routeur appelant envoie un message de configuration de la couche RNIS 3, mais que Router appelé ne le reçoit pas, alors la question pourrait être avec les couches RNIS 1 et 2 sur Router appelé ou ce pourrait être un problème avec l'entité RNIS de l'opérateur de téléphonie.

Effectuez les tâches suivantes sur Router appelé :

  • Vérifiez que le switchtype RNIS est correctement configuré :

    Le switchtype RNIS peut être vérifié utilisant l'état de show isdn de commande. La compagnie de téléphone devrait explicitement indiquer le switchtype qui doit être configuré. De temps en temps (particulièrement en Amérique du Nord) la compagnie de téléphone peut indiquer que le switchtype est « coutume » ou « ressortissant ». En pareil cas, employez les instructions suivantes pour déterminer la configuration switchtype :

    • Coutume : Si la compagnie de téléphone indique que leur commutateur-type est fait sur commande, alors configurez le switchtype sur le routeur comme basic-5ess (pour BRI avec commutateur 5ess), primary-5ess (pour le PRI avec 5ess), de base-SGD (pour BRI avec le commutateur de SGD), ou primaire-SGD (pour le PRI avec de la SGD).

    • Ressortissant : Switchtype conformément à la norme NI-1 pour la norme BRI et NI-2 pour le PRI (il n'y a aucune norme NI-1 pour PRIs). Si la compagnie de téléphone vous informe que le switchtype est national, alors la configuration de routeur Cisco devrait être de base-Ni (pour BRI) ou primaire-Ni (pour le PRI).

    Pour configurer le switchtype utilisez le commutateur de commutateur-type de la commande le RNIS saisissent le mode de configuration d'interface BRI. Pour un exemple référez-vous dépannage derrière la couche 1 RNIS BRI

  • Vérifiez que les couches RNIS 1 et 2 sur le routeur appelant fonctionnent :

    Vous pouvez vérifier que les couches RNIS 1 et 2 sont en hausse utiliser l'état de show isdn de commande. Utilisez la procédure tracée les grandes lignes en utilisant la commande d'état de show isdn pour que le dépannage BRI dépanne des questions connexes de la couche RNIS 1 et 2.

  • Vérifiez que le numéro dans le répertoire local SPID (LDN) est correctement configuré

    Certains switchtypes exigent que le spid et le ldn sont correctement configurés afin de recevoir des appels entrant. Référez-vous dépannage derrière le pour en savoir plus RNIS BRI SPID.

Effectuez les tâches suivantes sur le routeur appelant :

  • Utilisez un téléphone analogique traditionnel pour faire un appel d'essai au routeur distant.

    Utilisant un téléphone analogique traditionnel, composez l'isdn number de Router appelé exactement comme il est configuré sur le routeur appelant. Router appelé devrait recevoir un message de configuration (bien que l'appel échouera plus tard puisque ce n'est pas un appel RNIS). Si Router appelé reçoit le message de configuration puis nous pouvons supposer que le réseau appelé de side ISDN fonctionne. La question a pu être avec le réseau du côté local le RNIS, le numéro RNIS de destination, le service interurbain, tellement en avant et ainsi de suite. Poursuivez utilisant les étapes ci-dessous.

  • Assurez-vous que le numéro RNIS de destination est configuré correctement :

    Vérifiez la configuration de routeur appelante et la vérifiez que l'isdn number configuré pour le routeur distant est correct. Très souvent les circuits RNIS derrière un PBX exigent des 9 précédant l'isdn number. En outre, si l'appel est de fond (aux USA), puis vous devriez inclure le chiffre 1 avant l'isdn number de site distant (semblable à la longue distance normale de téléphone composant). Par exemple, considérez une situation où le site local est derrière un PBX et l'appel au site distant doit être un appel longue distance. L'isdn number d'extrémité distante est 5551111 dans code postal 512. Dans ce cas, y compris les chiffres appropriés pour le PBX et la longue distance, le numéro composé est 915125551111.

    La raison de débranchement de debug isdn q931 peut également être utilisée pour déterminer à si l'échec d'appel est dû, un numéro RNIS distant incorrect ou en raison incorrectement d'un nombre formaté. Référez-vous derrière codes de motif de déconnexion de debug isdn q931 de document compréhension pour plus d'informations sur interpréter codes de motif de déconnexion RNIS q931.

    Un débranchement dû à un isdn number incorrect peut être indiqué avec :

    Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85
    Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination
    

    En référence au document de codes de motif de déconnexion référencé précédemment, nous pouvons déterminer que le code de débranchement a été provoqué par par une tentative de se connecter à un matériel le non-RNIS. (Par exemple, une ligne analogique.).

    Un débranchement dû incorrectement à un nombre formaté peut être indiqué avec :

    Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
    Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format 
    (incomplete number)
    

    En référence derrière codes de motif de déconnexion de debug isdn q931 de document compréhension, nous pouvons déterminer que le code de débranchement a été provoqué par par un format non valide pour le numéro RNIS distant. La connexion échoue parce que l'adresse de destination est présentée (au commutateur) dans un format non identifiable, ou l'adresse de destination est inachevée.

  • Si c'est approprié, déterminez si le service interurbain est en activité :

    Vous devriez entrer en contact avec votre compagnie de téléphone et fournisseur de services interurbains locaux pour vérifier que le service est lancé. Souvent, la compagnie de téléphone locale a le circuit RNIS misconfigured tels que des appels longue distance sortants RNIS ne sont pas orientés vers le réseau du fournisseur de services interurbains approprié. Vous devriez également vérifier que le réseau de fournisseurs de services interurbains fonctionne.

    Aux USA et dans les situations où la compagnie de téléphone/fournisseur de services interurbains ne peut pas rectifier le problème, vous pouvez souhaiter utiliser un pré-abonnement auprès d'un opérateur interurbain (PIC). Les codes PIC sont des préfixes à 7 chiffres qui identifient des opérateurs interurbains des USA aux entreprises de téléphonie locale (LEC). Ceci permet à des clients pour utiliser différents opérateurs interurbains pour des appels distincts. Le code PIC est configuré comme un préfixe au numéro composé. La plupart de PICS sont du format 1010xxx. Pour une liste numérique de PICS référez-vous aux codes PIC des USA, numériquement /images/exit.gif

  • Configurez la carte de deux numéroteurs ou deux instructions de numérotation ; un pour l'isdn number distant de chaque canal B :

    Configurer une carte de numéroteur (ou une chaîne de numéroteur, si en utilisant des Profils de composeur) pour chaque canal B distant permet à la connexion pour poursuivre même si la compagnie de téléphone n'est pas capable de commuter le deuxième appel au deuxième canal RNIS B.

    Remarque: Ce contournement est exigé si seulement 1 canal B reçoit des faire appel à un BRI donné. Cette question est souvent vue avec des connexions multiliaison.

    Une configuration d'échantillon (utilisant des Cartes de composeur) est fournie :

    dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
    dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112
    
    !--- dialer map statements for the remote router 
    !--- The two different phone numbers correspond
    !--- to the b-channels of the remote side. The multiple statements allow
    !--- the router to dial the second number if the first number is busy. 
    
    

Router appelé n'envoie pas un message de CONNECTER

/image/gif/paws/9495/isdn_q931_ts_table3.gif

Si Router appelé reçoit un message de configuration mais ne répond pas avec un message de CONNECTER, alors ceci pourrait indiquer que le routeur (pour une certaine raison indéterminée) choisissent de ne pas recevoir l'appel.

Effectuez les tâches suivantes sur Router appelé :

  • Vérifiez si l'appel est dû rejeté au filtrage basé par ID/DNIS d'appelant :

    L'Identification de l'appelant ou le filtrage basé par DNIS permet au routeur sélectivement pour recevoir ou refuser des appels d'un détail sans occasionner des taxations. L'Identification de l'appelant étant basé le filtrage, Router appelé reçoit (dans le message de configuration) le nombre de l'appelant. Ceci permet au routeur pour permettre des appels de certains nombres fournissant de ce fait une certaine Sécurité. Le DNIS étant basé l'interview de Router appelé distingue des appels entrant basés sur le numéro composé.

    Il y a quelques questions principales à se souvenir concernant le filtrage basé par CLID/DNIS :

    1) La compagnie de téléphone doit fournir les informations appropriées CLID/DNIS dans le message de configuration. Si vous activez le filtrage d'Identification de l'appelant sur le routeur, mais n'avez pas des chiffres d'Identification de l'appelant étant passés au routeur, alors tous les appels au routeur « seront examinés » et aucun appel ne sera reçu.

    2) Vérifiez le format des chiffres CLID/DNIS fournis par la compagnie de téléphone (dans le debug isdn q931 sorti). Par exemple, quelques compagnies de téléphone incluent code postal dans les chiffres fournis CLID/DNIS, alors que d'autres ne font pas. Corrigez n'importe quelle configuration CLID/DNIS comme appropriée.

    Ce qui suit est un exemple d'un appel défaillant. Le routeur fait activer le filtrage basé par CLID, cependant, puisque la compagnie de téléphone ne fournit pas les chiffres de CLID le routeur rejette l'appel.

    maui-nas-08#
    05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E
    
    ! --- The router receives (RX) a SETUP message
    
    05:46:33:         Bearer Capability i = 0x8890
    05:46:33:         Channel ID i = 0x89
    05:46:33:         Signal i = 0x40 - Alerting on - pattern 0 
    05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,
      Type:Subscriber(local)
    
    ! --- The Called Number (DNIS) is delivered to the router
    ! --- Note that CLID information is not delivered
    
    05:46:33:         Locking Shift to Codeset 5
    05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
    05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE
    05:46:33:         Cause i = 0x8095 - Call rejected
    
    ! --- Calls is Rejected due to screening
    
    

    Pour plus d'informations sur l'Identification de l'appelant référez-vous à l'authentification RNIS et au rappel de document avec l'Identification de l'appelant

  • Vérifiez que les SPID sont corrects :

    Utilisez la commande d'état de show isdn de vérifier que les SPID sur Router appelé est correct. Référez-vous utilisant la commande d'état de show isdn pour le dépannage BRI pour plus d'informations sur dépanner des questions connexes de Spid.

  • Assurez-vous qu'il y a les canaux B disponibles sur le circuit qui a été composé :

    Utilisez la commande d'état de show isdn de vérifier s'il y a des canaux disponibles sur le circuit qui a été composé. S'il y a canal disponible n'utilise pas la commande claire de libérer quelques canaux.

  • Si plusieurs BRIs sont disponible, faites les configurer la compagnie de téléphone à un groupe de recherche :

    Avoir plusieurs BRIs à un groupe de recherche en tient compte pour que la compagnie de téléphone commute l'appel à circuit BRI libre sur ce routeur. Entrez en contact avec la compagnie de téléphone pour cette caractéristique.

  • Vérifiez si vous rencontrez des problèmes relatifs à la capacité du support :

    La capacité de support (ou la capacité du support) est l'indication de service de la couche 3 qui définit les caractéristiques d'un appel donné. La capacité du support d'un appel est indiquée par la compagnie de téléphone dans les messages de configuration Q.931. La capacité du support est employée souvent pour distinguer parmi la Voix 64k (analogique), les appels des données 56K et les appels des données 64k. Le plus généralement - des messages de capacité du support vus et leurs descriptions sont fournis ci-dessous :

    Capacité du support Description
    0x8890 Appel RNIS 64K
    0x8890218F Appel 56K RNIS
    0x8090A2 Appel de Voix/parole (u-law)
    0x9090A2 Appel de Voix/parole (u-law) - audio du KHZ 3.1
    0x8090A3 Appel de Voix/parole (a-law)
    0x9090A3 Appel de Voix/parole (a-law) - audio du KHZ 3.1

    Ce qui suit est un exemple d'un appel RNIS 64k :

    Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F
    
    !-- Incoming SETUP messages
    
    Aug  8 18:49:48.246:         Bearer Capability i = 0x8890
    
    !-- The bearer cap indicates the incoming call is ISDN 64k
    
    Aug  8 18:49:48.246:         Channel ID i = 0x89......
    

    Suivez les étapes ci-dessous selon la capacité du support de l'appel :

    La capacité de support est 0x8890218F : L'appel est 56K RNIS numérique :

    • Vérifiez que le switchtype RNIS est correctement configuré :

      Le switchtype RNIS peut être vérifié utilisant l'état de show isdn de commande. La compagnie de téléphone devrait explicitement indiquer le switchtype qui doit être configuré. De temps en temps (particulièrement en Amérique du Nord) la compagnie de téléphone peut indiquer que le switchtype est « coutume » ou « ressortissant ». En pareil cas, employez les instructions suivantes pour déterminer la configuration switchtype :

      • Coutume : Si la compagnie de téléphone indique que leur commutateur-type est fait sur commande, alors configurez le switchtype sur le routeur comme basic-5ess (pour BRI avec commutateur 5ess), primary-5ess (pour le PRI avec 5ess), de base-SGD (pour BRI avec le commutateur de SGD), ou primaire-SGD (pour le PRI avec de la SGD).

      • Ressortissant : Switchtype conformément à la norme NI-1 pour la norme BRI et NI-2 pour le PRI (il n'y a aucune norme NI-1 pour PRIs). Si la compagnie de téléphone vous informe que le switchtype est national, alors la configuration de routeur Cisco devrait être de base-Ni (pour BRI) ou primaire-Ni (pour le PRI).

      Pour configurer le switchtype utilisez le commutateur de commutateur-type de la commande le RNIS saisissent le mode de configuration d'interface BRI. Pour un exemple référez-vous dépannage derrière la couche 1 RNIS BRI

    • Du côté appelant, vérifiez que la vitesse/débit de l'appel est 56K. C'est nécessaire parce que quelques Commutateurs du legs le RNIS peuvent ne pas passer le canal clair et peuvent vous forcer pour faire votre appel au 56K pour obtenir.

      Utilisez le paramètre de vitesse sur la commande de configuration de carte de numéroteur de faire des appels sortants à 56 Kbps suivant les indications de l'exemple suivant :

      maui-soho-01(config)#interface bri 0
      maui-soho-01(config-if)#dialer map ip 10.1.1.1 name 
      Maui-NAS-08 speed 56 5551111
      
      !-- The keyword speed 56 sets the outgoing call rate at 56k
      
      

      L'exemple suivant montre comment configurer un profil du numéroteur de Cisco IOS pour faire des appels sortants à 56 Kbps :

      maui-soho-01(config)#interface dialer 1
      maui-soho-01(config-if)#dialer string 5558888 class 56k     
      
      !-- Use the map-class named "56k" when dialing number 5558888   
                 
      maui-soho-01(config-if)#exit
      maui-soho-01(config)#map-class dialer 56k
      
      !-- map-class named "56k" that was used with the dialer string above
      
      maui-soho-01(config-map-clas)#dialer isdn speed 56
      
      !-- Set the speed of the call to be 56k (default is 64k)
      
      
    • Du côté réception, configurez l'isdn not-end-to-end 56 de commande sous l'interface BRI.

      Maui-NAS-08(config)#interface bri 2/0
      Maui-NAS-08(config-if)#isdn not-end-to-end 56
      

      La capacité de support RNIS Q.931 et tout autre élément d'information (IE) s sont utilisés pour déterminer la vitesse de l'appel entrant et dans la plupart des cas fonctionneront correctement. Cependant, dans quelques applications de pays-à-pays (ou en raison de quelques Commutateurs existants), le message de configuration d'appel entrant sera fourni avec une capacité de support qui n'apparie pas l'appel au départ. Si un message indiquant le RNIS « non de bout en bout » est reçu, le routeur peut ignorer la capacité de support reçue utilisant la commande de configuration Cisco IOS le RNIS non de bout en bout.

      La capacité de support est 0x8090A2 ou 0x9090A2 : Appel de Voix/parole (u-law)

      La capacité de support est 0x8090A3 ou 0x9090A3 : Appel de Voix/parole (a-law)

      L'appel entrant est un appel 64k analogique. Pour des applications de modem l'appel sera envoyé aux modems internes, alors que pour des Applications voix l'appel peut être envoyé au module approprié de Voix. Exécutez les étapes suivantes :

      1. Du côté réception, vérifiez que l'interface physique RNIS (par exemple, interface bri 0) a le modem d'isdn incoming-voice configuré.

      2. Vérifiez que les lignes du modem ont le modem inout de commande.

      Pour un exemple de configuration référez-vous au document configurant la Connectivité de modem avec un Cisco 3640 BRI

    • Interprétez code de motif de déconnexion envoyé (de Router appelé au routeur appelant) dans le DÉBRANCHEMENT ou LIBÉREZ le message

      Si Router appelé n'envoie pas un message de CONNECTER au routeur appelant, il devrait renvoyer un DÉBRANCHEMENT ou LIBÉRER le message. Ce message de DÉBRANCHEMENT ou de RELEASE devrait également inclure code de motif de déconnexion. Dans l'exemple ci-dessous, code de motif de déconnexion est 0x8090. Référez-vous derrière codes de motif de déconnexion de debug isdn q931 de document compréhension pour interpréter le code de débranchement.

      Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8  
      callref = 0x06
      Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing
      

Le routeur appelant ne reçoit pas un message de CONNECTER

/image/gif/paws/9495/isdn_q931_ts_table4.gif

Si Router appelé envoie un message de CONNECTER, mais ce message n'est pas reçu par le routeur appelant, alors la question se trouve très probablement avec la compagnie de téléphone.

  • Déterminez si le routeur reçoit un CONNECT_ACK du commutateur des gens du pays le RNIS :

    Ceci indique que le le commutateur de la compagnie de téléphone près de Router appelé a reçu le message de CONNECTER et passe le message de CONNECTER au routeur appelant. Une panne de l'appel est probable une question de compagnie de téléphone.

  • Entrez en contact avec la compagnie de téléphone pour davantage de dépannage.

Le routeur appelant reçoit un CONNECTER mais l'appel échoue toujours

Si le routeur appelant reçoit un message de CONNECTER, cela indique que la connexion RNIS est en activité et fonctionnante correctement. Entrez en contact avec la compagnie de téléphone pour déterminer s'il y a un problème avec le canal B n'étant pas correctement tracé à travers pour des données. N'importe quelle panne de l'appel, après cette étape, est due à une question plus élevée de couche négociation comme avec le PPP, l'authentification ou IPCP/adresse IP. Debug ppp negotiation d'utilisation pour davantage de dépannage de ppp.

Vous devriez également consulter le document Technologie d'appel commuté : Techniques de dépannage pour d'autres techniques de dépannage de PPP.


Informations connexes


Document ID: 9495