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

Introduction

Lors du dépannage des problèmes de défaillance d'appel RNIS, il est important de garder à l'esprit que l'appel peut échouer en raison de l'une des raisons suivantes :

• Routage de numérotation sur demande (DDR)

• Couches RNIS 1, 2 et 3

• Protocole PPP (Point-to-Point Protocol) : notamment les problèmes liés au protocole de contrôle de liaison (LCP), à l'authentification ou au protocole de contrôle IP (IPCP).

Ce document se concentre spécifiquement sur les problèmes liés à RNIS qui provoquent des échecs d'appel. Ce document suppose également que vous avez vérifié que les couches RNIS 1 et 2 des deux extrémités du circuit fonctionnent. Référez-vous à Utilisation de la commande show isdn status pour le dépannage BRI pour plus d'informations sur la vérification de l'état des couches 1 et 2 RNIS.

Conditions préalables

Conditions requises

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

Components Used

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. All of the devices used in this document started with a cleared (default) configuration. 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.

Conditions requises pour le dépannage : Activation des débogages de couche 3 RNIS

Utilisez la commande debug isdn q931 aux deux extrémités pour activer les débogages de couche 3 RNIS. Vous devez également avoir des horodatages de millisecondes pour les débogages activés sur les deux routeurs. Les horodatages sont nécessaires pour fournir une entrée relative au processus de dépannage.

Remarque : activez les horodatages de millisecondes pour les débogages à l'aide des 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 les commandes de débogage, reportez-vous à Informations importantes sur les commandes de débogage.

Lancer l’appel RNIS

Générez une requête ping ICMP vers l’adresse IP du routeur distant. Ceci doit déclencher un appel RNIS vers ce routeur. Les deux routeurs génèrent des messages debug isdn q931.

Il peut y avoir de nombreuses variations dans les échanges Q.931 en raison de besoins spécifiques pour les types de commutateurs RNIS ou dans les cas où des paramètres supplémentaires sont nécessaires. Le schéma suivant illustre les transactions Q.931 courantes lors d'une configuration d'appel RNIS réussie.

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

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 

Lors de l'évaluation de la sortie debug isdn q931 sur l'appelant et les terminaisons appelées, gardez à l'esprit les points suivants :

• Faites attention à la direction des messages. Les débogages indiquent si les messages ont été générés par le routeur (indiqué par TX ->) ou s'ils ont été reçus par le routeur (indiqué par RX <—). Dans l’exemple ci-dessous, le premier message (CONNECT) est reçu par le routeur à partir du commutateur RNIS, tandis que le second (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 du problème en suivant la direction d'un message particulier et la réponse. Par exemple, si le routeur reçoit de manière inattendue un message RELEASE du commutateur RNIS de la compagnie de téléphone, il réinitialise également sa fin de connexion. Cela indique que le problème est lié au commutateur RNIS de la compagnie de téléphone ou au routeur distant

• Vérifiez que le message reçu ou envoyé est celui attendu. Par exemple, si l'appelé reçoit un message SETUP mais envoie un message DISCONNECT au lieu d'un message CONNECT, dépannez le routeur appelé et non le réseau RNIS. Le tableau suivant répertorie les messages Q.931 possibles vus lors de l'établissement et de la désactivation des appels :

Présentation du dépannage : Procédure de résolution et de symptôme

Analysez la sortie debug isdn q931 comme décrit dans les sections précédentes et passez au symptôme approprié décrit ci-dessous.

Remarque : Dans ce document, le routeur qui lance l'appel est appelé routeur appelant, tandis que le routeur qui accepte l'appel est appelé routeur appelé.

Dépannage : Procédure de résolution détaillée des symptômes

Le routeur appelant n'envoie pas de message SETUP

Si le routeur appelant n’envoie pas de message SETUP au réseau RNIS, le problème est probablement lié aux problèmes de routage à établissement de connexion à la demande (DDR) des couches 1, 2 ou 3 RNIS et non à ceux de la couche 3.

Effectuez les tâches suivantes sur le routeur appelant :

• Vérifiez que le type de commutateur RNIS est correctement configuré :

  Le type de commutateur RNIS peut être vérifié à l’aide de la commande show isdn status . La compagnie de téléphone doit indiquer explicitement le type de commutateur à configurer. Parfois (surtout en Amérique du Nord), la compagnie de téléphone peut indiquer que le type de commutateur est « personnalisé » ou « national ». Dans de tels cas, utilisez les instructions suivantes pour déterminer la configuration du type de commutateur :

  • Personnalisé : Si la compagnie de téléphone indique que son type de commutateur est Personnalisé, configurez le type de commutateur sur le routeur en tant que basic-5ess (pour BRI avec commutateur 5ess), primary-5ess (pour PRI avec 5ess), basic-dms (pour BRI avec commutateur DMS) ou primary-dms (pour PRI avec DMS).

  • National : Type de commutateur conforme à la norme NI-1 pour BRI et NI-2 pour PRI (il n'existe pas de norme NI-1 pour PRI). Si la compagnie de téléphone vous informe que le type de commutateur est National, la configuration du routeur Cisco doit être basic-ni (pour BRI) ou primary-ni (pour PRI).

  Pour configurer le type de commutateur, utilisez la commande isdn switch-type switch-type en mode de configuration d’interface BRI. Pour un exemple, référez-vous à Dépannage de la couche 1 BRI RNIS

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

  Vous pouvez vérifier que les couches RNIS 1 et 2 sont actives à l'aide de la commande show isdn status. Suivez la procédure décrite à la pour résoudre les problèmes liés aux couches 1 et 2 RNIS.

• Utilisez la commande show ip route pour vérifier que le routeur a une route vers la destination.

  La commande show ip route indique s'il existe une route vers le réseau du routeur distant. Si la route n'existe pas, utilisez la commande ip route pour ajouter une route statique pour le réseau distant. Assurez-vous que la route pointe vers l’interface correcte sur le routeur appelant.

  Dans un environnement DDR hérité (par exemple, les mappages de numérotation), le saut suivant doit être soit le réseau d'interface physique (interface BRI x), soit l'adresse IP du routeur distant (qui doit également avoir été configurée dans l'instruction de mappage de numérotation).

  Avec les profils de numérotation, le saut suivant est généralement l'interface Dialer x utilisée pour la numérotation. 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 saut suivant de la route par défaut est interface Dialer 1 (l'interface de numérotation logique pour cette connexion).

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

  Le routeur vérifie qu’un paquet entrant est un trafic intéressant avant d’initier la numérotation. Par conséquent, le routeur peut ne pas composer si le trafic intéressant n'est pas correctement défini, ou si le numéro dialer-list (la définition de trafic intéressante) n'est pas appliqué à l'interface physique ou de numérotation (à l'aide de la commande dialer-group number). Par exemple, si vous utilisez une requête ping ICMP pour initier la connexion DDR, vérifiez que l'ICMP est autorisé dans la définition de trafic intéressante.

  Référez-vous à Configuration d'une connexion commutée BRI à BRI avec des mappages de numérotation DDR pour plus d'informations.

• Vérifiez si la chaîne de numérotation appropriée (ou la carte de numérotation) inclut le numéro RNIS du périphérique distant.

  La chaîne de numérotation (ou le mappage de numérotation) doit inclure le numéro RNIS du 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 utilisez le numéroteur de débogage pour vérifier que le routeur lance l'appel :

  Vérifiez que la configuration DDR est correcte. Utilisez le document Technologie de numérotation : Présentations et explications pour une assistance supplémentaire sur la configuration DDR correcte.

  Vous devez également utiliser la commande debug dialer pour vérifier que le routeur reçoit un trafic intéressant et qu'il dispose de la carte de numérotation ou de la chaîne de numérotation appropriée pour initier la numérotation. Reportez-vous au document ci-dessus ainsi qu'à la technologie d'accès à distance : Techniques de dépannage pour plus d'informations.

  Reportez-vous à l'exemple de configuration suivante pour obtenir des exemples de configuration DDR appropriée :

  Profils de numérotation : Configuration du routage DDR RNIS avec les profils de numérotation DDR (Dialer Maps) hérités : Configuration de l'accès commuté de BRI à BRI à l'aide du routage DDR (Dialer Maps)

  Conseil : À des fins de test, vous pouvez éliminer le DDR en utilisant la commande isdn call (expliquée dans la section suivante) pour générer un appel RNIS vers le périphérique distant. Si cet appel réussit, vous pouvez être raisonnablement certain que le circuit RNIS fonctionne. Poursuivre le dépannage de DDR

• Effectuer un appel de test de bouclage

  Dans un appel de bouclage, le routeur compose le numéro RNIS de son propre BRI. L'appel est acheminé vers le cloud de l'opérateur téléphonique, où l'opérateur de télécommunications bascule l'appel vers le deuxième canal BRI. Cet appel est maintenant vu par le routeur comme un appel entrant sur le deuxième canal. Par conséquent, le routeur envoie et reçoit l’appel RNIS.

  Un appel de bouclage teste la capacité du routeur à initier et à mettre fin à un appel RNIS. Un appel de bouclage réussi indique clairement que le circuit RNIS vers le cloud de l'opérateur téléphonique fonctionne correctement.

  Voici un exemple annoté d'un appel de bouclage réussi. La commande isdn call (introduite dans la plate-forme logicielle Cisco IOS® 12.0(3)T) active les appels RNIS sortants sans nécessiter les exigences DDR telles que le trafic et les routes intéressants. Cette commande ne peut être utilisée que pour tester le circuit RNIS et ne peut pas être utilisée pour transmettre le trafic ou pour remplacer une configuration DDR appropriée. Cette commande nous permet de vérifier que le circuit RNIS, en particulier 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

Remarques :

• Au cours de l'appel de bouclage, le routeur fonctionne en tant que routeur appelé et routeur appelant (bien que sur différents canaux B). Il est important que vous gardiez un suivi de ces « rôles doubles » lors de l'interprétation de la sortie debug isdn q931. Par exemple, le routeur transmet un message de configuration (TX -> SETUP) et en reçoit également un (RX <- SETUP). Le message SETUP transmis doit être associé à l'appel sortant tandis que le message SETUP reçu est associé à l'appel entrant.

• Dans l'exemple ci-dessus, nous avons composé le numéro du premier canal B. Cependant, la compagnie de téléphone reconnaissant que le premier canal B était occupé (depuis qu'il a passé l'appel), a commuté l'appel vers le deuxième canal B et la connexion a été effectuée avec succès. Cependant, une mauvaise configuration dans le commutateur telco peut entraîner une défaillance de l'appel de bouclage, en raison de la tentative du commutateur d'attribuer l'appel au premier canal (occupé à passer l'appel). L'opérateur téléphonique doit corriger ce problème. Cependant, comme solution de contournement, spécifiez le deuxième numéro de canal B dans la commande isdn call.

• Si l'appel de bouclage réussit et que l'appel vers l'extrémité distante continue d'échouer, contactez l'opérateur téléphonique pour obtenir de l'aide au dépannage sur votre circuit BRI.

Le routeur appelé ne reçoit pas de message SETUP

Si vous déterminez que le routeur appelant envoie un message de configuration de couche 3 RNIS, mais que le routeur appelé ne le reçoit pas, le problème peut se poser avec les couches 1 et 2 RNIS sur le routeur appelé ou il peut s'agir d'un problème avec le cloud RNIS de la compagnie de téléphone.

Effectuez les tâches suivantes sur le routeur appelé :

• Vérifiez que le type de commutateur RNIS est correctement configuré :

  Le type de commutateur RNIS peut être vérifié à l’aide de la commande show isdn status . La compagnie de téléphone doit indiquer explicitement le type de commutateur à configurer. Parfois (surtout en Amérique du Nord), la compagnie de téléphone peut indiquer que le type de commutateur est « personnalisé » ou « national ». Dans de tels cas, utilisez les instructions suivantes pour déterminer la configuration du type de commutateur :

  • Personnalisé : Si la compagnie de téléphone indique que son type de commutateur est Personnalisé, configurez le type de commutateur sur le routeur en tant que basic-5ess (pour BRI avec commutateur 5ess), primary-5ess (pour PRI avec 5ess), basic-dms (pour BRI avec commutateur DMS) ou primary-dms (pour PRI avec DMS).

  • National : Type de commutateur conforme à la norme NI-1 pour BRI et NI-2 pour PRI (il n'existe pas de norme NI-1 pour PRI). Si la compagnie de téléphone vous informe que le type de commutateur est National, la configuration du routeur Cisco doit être basic-ni (pour BRI) ou primary-ni (pour PRI).

  Pour configurer le type de commutateur, utilisez la commande isdn switch-type switch type en mode de configuration d'interface BRI. Pour un exemple, référez-vous à Dépannage de la couche 1 BRI RNIS

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

  Vous pouvez vérifier que les couches RNIS 1 et 2 sont actives à l'aide de la commande show isdn status. Suivez la procédure décrite à la section Utilisation de la commande show isdn status pour le dépannage BRI pour résoudre les problèmes liés aux couches 1 et 2 RNIS.

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

  Certains types de commutateurs nécessitent que le spid et le ldn soient correctement configurés pour accepter les appels entrants. Référez-vous à Dépannage des SPID RNIS BRI pour plus d'informations.

Effectuez les tâches suivantes sur le routeur appelant :

• Utilisez un téléphone analogique ordinaire pour passer un appel de test sur le routeur distant.

  À l'aide d'un téléphone analogique classique, composez le numéro RNIS du routeur appelé exactement tel qu'il est configuré sur le routeur appelant. Le routeur appelé doit recevoir un message SETUP (bien que l'appel échouera ultérieurement car il ne s'agit pas d'un appel RNIS). Si le routeur appelé reçoit le message SETUP, nous pouvons supposer que le réseau RNIS côté appelé fonctionne. Le problème peut concerner le réseau RNIS local, le numéro RNIS de destination, le service longue distance, etc. Procédez comme suit.

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

  Vérifiez la configuration du routeur appelant et vérifiez que le numéro RNIS configuré pour le routeur distant est correct. Très souvent, les circuits RNIS derrière un PBX nécessitent un 9 précédant le numéro RNIS. En outre, si l'appel est longue distance (aux États-Unis), vous devez inclure le chiffre 1 avant le numéro RNIS du site distant (similaire à la numérotation longue distance normale du téléphone). Par exemple, considérez une situation où le site local est derrière un PBX et où l'appel vers le site distant doit être un appel longue distance. Le numéro RNIS d'extrémité distante est 555111 dans l'indicatif régional 512. Dans ce cas, y compris les chiffres appropriés pour le PBX et l'interurbain, le numéro composé est le 915125551111.

  La raison de déconnexion debug isdn q931 peut également être utilisée pour déterminer si l'échec de l'appel est dû à un numéro RNIS distant incorrect ou à un numéro mal formaté. Référez-vous au document Comprendre le débogage et les codes de cause de déconnexion q931 isdn pour plus d'informations sur l'interprétation des codes de cause de déconnexion RNIS q931.

  Une déconnexion due à un numéro RNIS incorrect peut être indiquée par :

  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 des codes cause de déconnexion référencé précédemment, nous pouvons déterminer que le code de déconnexion a été provoqué par une tentative de connexion à un équipement non RNIS. (Par exemple, une ligne analogique.)

  Une déconnexion due à un numéro mal formaté peut être indiquée 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 au document Understanding debug isdn q931 Disconnect Cause Codes , nous pouvons déterminer que le code de déconnexion a été causé par un format non valide pour le numéro RNIS distant. La connexion échoue car l'adresse de destination est présentée (au commutateur) dans un format non reconnaissable, ou l'adresse de destination est incomplète.

• Le cas échéant, déterminez si le service longue distance est actif :

  Vous devez contacter votre opérateur téléphonique local et votre fournisseur d'appels longue distance pour vérifier que le service est activé. Souvent, le circuit RNIS de l’opérateur téléphonique local est mal configuré de sorte que les appels longue distance RNIS sortants ne soient pas commutés vers le réseau du fournisseur d’accès longue distance approprié. Vous devez également vérifier que le réseau des fournisseurs de services longue distance fonctionne.

  Aux États-Unis et dans les situations où le fournisseur de services téléphoniques/longue distance n'est pas en mesure de résoudre le problème, vous pouvez utiliser un opérateur de téléphonie intercirconscriptions préabonné (PIC). Les codes PIC sont des préfixes à 7 chiffres qui identifient les opérateurs interurbains américains aux opérateurs de services locaux (LEC). Cela permet aux clients d'utiliser différents opérateurs longue distance pour des appels distincts. Le code PIC est configuré comme préfixe au numéro composé. La plupart des PIC sont au format 1010xxx. Pour obtenir une liste numérique des PIC, reportez-vous aux codes PIC américains, numériquement

• Configurez deux mappages de numérotation ou deux instructions de chaîne de numérotation ; un pour chaque numéro RNIS de canal B distant :

  La configuration d'une carte de numérotation (ou d'une chaîne de numérotation, si vous utilisez des profils de numérotation) pour chaque canal B distant permet à la connexion de continuer même si l'opérateur téléphonique n'est pas en mesure de commuter le deuxième appel vers le deuxième canal B RNIS.

  Remarque : Cette solution de contournement est requise si un seul canal B accepte des appels sur un BRI donné. Ce problème est souvent observé avec les connexions multiliaison.

  Un exemple de configuration (à l'aide de cartes de numérotation) est fourni :

  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. 
  
  

Le routeur appelé n'envoie pas de message CONNECT

Si le routeur appelé reçoit un message SETUP mais ne répond pas avec un message CONNECT, cela peut indiquer que le routeur (pour une raison indéterminée) choisit de ne pas accepter l'appel.

Effectuez les tâches suivantes sur le routeur appelé :

• Vérifiez si l'appel est rejeté en raison du filtrage basé sur l'ID de l'appelant/DNIS :

  Le filtrage basé sur l'ID de l'appelant ou sur DNIS permet au routeur d'accepter ou de refuser sélectivement un appel particulier sans frais de péage. Avec le filtrage basé sur l'ID de l'appelant, le routeur appelé reçoit (dans le message SETUP) le numéro de l'appelant. Cela permet au routeur d'autoriser les appels de certains numéros, assurant ainsi une certaine sécurité. Avec le filtrage DNIS, le routeur appelé différencie les appels entrants en fonction du numéro composé.

  Il y a deux points principaux à retenir au sujet du dépistage basé sur l’IEDTR/DNIS :

  1) La compagnie de téléphone doit fournir les informations CLID/DNIS appropriées dans le message SETUP. Si vous activez le filtrage de l'ID de l'appelant sur le routeur, mais que les numéros de l'ID de l'appelant ne sont pas transmis au routeur, tous les appels destinés au routeur seront filtrés et aucun appel ne sera accepté.

  2) Vérifiez le format des chiffres CLID/DNIS fournis par la compagnie de téléphone (dans la sortie debug isdn q931). Par exemple, certaines compagnies de téléphone incluent l'indicatif régional dans les chiffres CLID/DNIS fournis, tandis que d'autres ne le font pas. Corrigez toute configuration CLID/DNIS, le cas échéant.

  Voici un exemple d'appel ayant échoué. Cependant, le filtrage basé sur CLID est activé sur le routeur, puisque la compagnie de téléphone ne fournit pas les chiffres CLID que 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'ID de l'appelant, reportez-vous au document Authentification RNIS et rappel avec l'ID de l'appelant

• Vérifiez que les SPID sont corrects :

  Utilisez la commande show isdn status pour vérifier que les SPID du routeur appelé sont corrects. Référez-vous à Utilisation de la commande show isdn status pour le dépannage BRI pour plus d'informations sur le dépannage des problèmes liés à Spid.

• Assurez-vous qu'il existe des canaux B disponibles sur le circuit composé :

  Utilisez la commande show isdn status pour vérifier s'il existe des canaux disponibles sur le circuit composé. Si aucun canal n'est disponible, utilisez la commande clear pour libérer certains canaux.

• Si plusieurs BRI sont disponibles, demandez à l'opérateur téléphonique de les configurer dans un groupe de recherche :

  Le fait d’avoir plusieurs BRI dans un groupe de recherche permet à l’opérateur téléphonique de basculer l’appel vers n’importe quel circuit BRI libre sur ce routeur. Contactez l'opérateur de téléphonie pour cette fonction.

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

  La fonction de support (ou casquette de support) est l'indication de service de couche 3 qui définit les caractéristiques d'un appel donné. Le capuchon du porteur d'un appel est indiqué par la compagnie de téléphone dans les messages Q.931 SETUP. Le casque Bearer est souvent utilisé pour distinguer entre les appels voix (analogiques) de 64 k, les appels de données de 56 k et les appels de données de 64 k. Les messages de casquette de support les plus courants et leurs descriptions sont fournis ci-dessous :

  Plafond du porteur	Description
  0x8890	Appel RNIS 64 000
  0x8890218F	Appel RNIS 56 000
  0x8090A2	Appel voix/voix (droit)
  0x9090A2	Appel voix/voix (droit u) - Audio 3,1 kHz
  0x8090A3	Appel vocal/vocal (loi A)
  0x9090A3	Appel voix/voix (loi A) - Audio 3,1 kHz

  Voici un exemple d’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 en fonction de la limite de support de l'appel :

  La capacité du porteur est 0x8890218F : L'appel est numérique RNIS 56K :

  • Vérifiez que le type de commutateur RNIS est correctement configuré :

    Le type de commutateur RNIS peut être vérifié à l’aide de la commande show isdn status . La compagnie de téléphone doit indiquer explicitement le type de commutateur à configurer. Parfois (surtout en Amérique du Nord), la compagnie de téléphone peut indiquer que le type de commutateur est « personnalisé » ou « national ». Dans de tels cas, utilisez les instructions suivantes pour déterminer la configuration du type de commutateur :

    • Personnalisé : Si la compagnie de téléphone indique que son type de commutateur est Personnalisé, configurez le type de commutateur sur le routeur en tant que basic-5ess (pour BRI avec commutateur 5ess), primary-5ess (pour PRI avec 5ess), basic-dms (pour BRI avec commutateur DMS) ou primary-dms (pour PRI avec DMS).

    • National : Type de commutateur conforme à la norme NI-1 pour BRI et NI-2 pour PRI (il n'existe pas de norme NI-1 pour PRI). Si la compagnie de téléphone vous informe que le type de commutateur est National, la configuration du routeur Cisco doit être basic-ni (pour BRI) ou primary-ni (pour PRI).

    Pour configurer le type de commutateur, utilisez la commande isdn switch-type switch type en mode de configuration d'interface BRI. Pour un exemple, référez-vous à Dépannage de la couche 1 BRI RNIS

  • Sur le côté composition, vérifiez que la vitesse/la fréquence de l'appel est de 56 Ko. Cela est nécessaire car certains commutateurs RNIS hérités peuvent ne pas passer de canal clair et vous forcer à passer votre appel à 56 Ko pour passer.

    Utilisez le paramètre speed de la commande de configuration dialer map pour passer des appels sortants à 56 Kbits/s, comme indiqué dans 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 illustre comment configurer un profil de numérotation Cisco IOS pour passer des appels sortants à 56 Kbits/s :

    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)
    
    

  • Sur le côté récepteur, configurez la commande isdn not-end-to-end 56 sous l'interface BRI.

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

    Les fonctions de support Q.931 RNIS et d'autres éléments d'information (IE) permettent de déterminer la vitesse de l'appel entrant et, dans la plupart des cas, fonctionnent correctement. Cependant, dans certaines applications pays à pays (ou en raison de certains commutateurs hérités), le message de configuration d'appel entrant sera livré avec une capacité de support qui ne correspond pas à l'appel d'origine. Si un message indiquant isdn 'not end-to-end' est reçu, le routeur peut remplacer la fonctionnalité de support reçu à l'aide de la commande de configuration Cisco IOS isdn not end-to-End.

    La capacité du porteur est 0x8090A2 ou 0x9090A2 : Appel voix/voix (droit)

    La capacité du porteur est 0x8090A3 ou 0x9090A3 : Appel vocal/vocal (loi A)

    L'appel entrant est un appel analogique 64k. Pour les applications de modem, l'appel est envoyé aux modems internes, tandis que pour les applications vocales, l'appel peut être envoyé au module vocal approprié. Procédez comme suit :

    1. Sur le côté récepteur, vérifiez que l'interface physique RNIS (par exemple, interface bri 0) a un modem RNIS entrant-voix configuré.

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

    Pour un exemple de configuration, reportez-vous au document Configuration de la connectivité par modem avec un routeur BRI Cisco 3640

  • Interpréter le code de cause de déconnexion envoyé (du routeur appelé au routeur appelant) dans le message DISCONNECT ou RELEASE

    Si le routeur appelé n'envoie pas de message CONNECT au routeur appelant, il doit renvoyer un message DISCONNECT ou RELEASE. Ce message DISCONNECT ou RELEASE doit également inclure un code de cause de déconnexion. Dans l'exemple ci-dessous, le code de cause de déconnexion est 0x8090. Reportez-vous au document Compréhension des codes de cause de déconnexion debug isdn q931 pour interpréter le code de déconnexion.

    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 de message CONNECT

Si le routeur appelé envoie un message CONNECT, mais que ce message n'est pas reçu par le routeur appelant, le problème est probablement celui de la compagnie de téléphone.

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

  Cela indique que le commutateur de la compagnie de téléphone situé près du routeur appelé a accepté le message CONNECT et transmet le message CONNECT au routeur appelant. Un échec de l'appel est probablement un problème de compagnie de téléphone.

• Contactez l'opérateur de téléphonie pour obtenir de plus amples informations sur le dépannage.

Le routeur appelant reçoit une CONNEXION mais l'appel échoue toujours

Si le routeur appelant reçoit un message CONNECT, cela indique que la connexion RNIS est active et fonctionne correctement. Contactez l'opérateur de téléphonie pour déterminer s'il existe un problème de mappage correct du canal B pour les données. Toute défaillance de l'appel, au-delà de cette étape, est due à un problème de couche supérieure, tel que le protocole PPP, l'authentification ou la négociation d'adresse IP/PIP. Utilisez debug ppp negotiation pour le dépannage de ppp.

Vous devez également consulter le document Technologie de numérotation : Techniques de dépannage pour les techniques de dépannage PPP supplémentaires.

Informations connexes

• Accès aux pages d'assistance technologique
• Support technique - Cisco Systems

Historique de révision