Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Détermination de l'état du modem

Détermination du motif de déconnexion

Enregistrements d'appels du modem

Journaux comptables AAA

Commandes show modem Operational-status et show modem log

Déconnecter le format de raison

États du modem MICA

Raisons de déconnexion du modem MICA

Motif de déconnexion : Types

Informations connexes

Introduction

Ce document décrit comment interpréter les codes de raison de déconnexion d'appel signalés par les modems d'agrégation de canaux RNIS (MICA) de modem Cisco.

Note : Ce document contient de nombreux termes définis dans les normes de l'UIT telles que V.90, V.44, V.42bis et V.34. Pour plus d'informations sur ces termes, reportez-vous à la norme UIT-T appropriée. Les termes spécifiés dans les normes de l'UIT-T ne sont pas expliqués dans ce document.

Conditions préalables

Conditions requises

Les lecteurs de ce document doivent être au courant des points suivants :

Chaque fois qu'un appel qui utilise des DSP (Domain Specific Parts) MICA est effacé ou déconnecté, MICA enregistre la raison de la déconnexion. Vous pouvez utiliser cette raison pour déterminer si la déconnexion était normale. Si ce n'est pas le cas, vous pouvez l'utiliser pour identifier les sources possibles de défaillance. Les modems peuvent être déconnectés en raison de divers facteurs, tels que les déconnexions des clients, les erreurs Telco et les abandons d'appels au niveau du serveur d'accès au réseau (NAS). Une raison typique de déconnexion est que l’ETTD (modem client ou NAS) à une extrémité veut l’arrêter. Ces déconnexions « normales » indiquent que la déconnexion n'est pas le résultat d'erreurs de modem ou de niveau de transmission. Pour plus d'informations sur la détermination d'une raison de déconnexion normale, référez-vous à Vue d'ensemble de la qualité générale des lignes de modem et NAS.

Components Used

Les modems MICA sont utilisés dans les serveurs d'accès suivants :

- Routeurs de la gamme Cisco 3600

- AS5200

- AS5300

- AS5800

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Détermination de l'état du modem

Utilisez la commande show modem log slot/port pour trouver l'état actuel d'un modem MICA. Dans cette sortie de journal, les entrées les plus récentes se produisent vers la fin du journal. L'état actuel du modem MICA s'affiche dans le dernier événement d'état (modification) du modem. Dans l'exemple de sortie ci-dessous, l'état du modem est inactif, indiqué par l'événement Modem State marqué 00:00:28. Reportez-vous au tableau États des modems MICA pour plus d'informations sur les états possibles des modems MICA.

maui-nas-02#show modem log 1/0

Modem 1/0 Events Log:

00:03:33:Startup event:MICA Hex modem (Managed)

Modem firmware = 2.7.3.0

!--- This modem is using portware 2.7.3.0

00:03:33:RS232 event:  noRTS, noDTR, CTS, noDCD

...

...

!--- This output was removed for brevity.

...

00:00:28:Modem State event:

State: Terminate

00:00:28:RS232 event:  noRTS, DTR, CTS, noDCD

00:00:28:RS232 event:  RTS, DTR, CTS, noDCD

00:00:28:Modem State event:

State: Idle

!--- The last modem state event !--- This indicates that the modem is in state Idle

Détermination du motif de déconnexion

Chaque fois qu'une connexion modem est interrompue, le NAS signale deux raisons de déconnexion : les raisons de l’ETTD (IOS) et de l’ETCD (MICA). Ces raisons de déconnexion peuvent être signalées à l'aide de trois méthodes principales :

1. Enregistrements d'appels du modem : Ces rapports indiquent les raisons de déconnexion du logiciel IOS® et du modem MICA.

2. Journaux de comptabilité AAA : Ces rapports indiquent uniquement le motif de déconnexion du logiciel IOS.

3. Commandes IOS : Les commandes telles que show modem Operational-status et show modem log signalent uniquement le motif de déconnexion du modem MICA.

Enregistrements d'appels du modem

Le motif de déconnexion de l'IOS et du modem pour une connexion particulière est affiché dans l'enregistrement d'appel du modem (MCR). Le MCR est envoyé à un serveur syslog par le NAS lors de la fin de chaque appel. Les enregistrements d'appels de modem ont été introduits dans le logiciel Cisco IOS versions 11.3AA et 12.0T et sont activés (sur le NAS) à l'aide de la commande modem call-record terse. Pour plus d'informations sur la mise en oeuvre des enregistrements d'appels de modem, référez-vous au document Utilisation des enregistrements d'appels Syslog, NTP et Modem pour isoler et dépanner les pannes.

Dans l'exemple d'enregistrement d'appel de modem présenté ci-dessous, le motif de déconnexion IOS indiqué par disk(radius) est Perdu Carrier/Lost Carrier, tandis que le motif de déconnexion de modem indiqué par disk(modem) est le suivant :

A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received

DISC frame -- normal LAPM termination

Référez-vous au tableau Motifs de déconnexion du modem Mica pour plus d'informations sur l'interprétation du motif de déconnexion du modem.

*May 31 18:11:09.558: %CALLRECORD-3-MICA_TERSE_CALL_REC: DS0 slot/contr/chan=2/0/18,

slot/port=1/29, call_id=378, userid=cisco, ip=0.0.0.0, calling=5205554099,

called=4085553932, std=V.90, prot=LAP-M, comp=V.42bis both, init-rx/tx b-rate=26400/41333,

finl-rx/TX brate=28800/41333, rbs=0, d-pad=6.0   dB, retr=1, sq=4, snr=29, rx/TX chars=93501/94046,

bad=5, rx/TX ec=1612/732, bad=0, time=337, finl-state=Steady,

disc(radius)=Lost Carrier/Lost Carrier, disc(modem)=A220 Rx (line to host)

data flushing - not OK/EC condition - locally detected/received

DISC frame -- normal LAPM termination

Journaux comptables AAA

Les journaux de comptabilité AAA peuvent également être utilisés pour déterminer le motif de déconnexion de l'IOS. Dans l'exemple de requête SQL AAA ci-dessous, nous pouvons voir la cause de déconnexion de rayon :

SQL> select * from cs_accounting_log where blob_data like '%rad_dial%';

LOG_ID BLOB_ORDINAL BLOB_DATA

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

172.22.87.3  rad_dial     Async20 65004   stop    server=danvers  time=17:36:33

date=04/17/2000    task_id=40      timezone=CST    service=ppp     protocol=ip

addr=172.22.83.12     disc-cause=4     disc-cause-ext=1021     pre-bytes-in=132

pre-bytes-out=139 pre-paks-in=5   pre-paks-out=7 bytes_i

Le code de déconnexion (disk-cause=4), dans l'exemple ci-dessus, indique que la déconnexion a été causée par l'expiration du délai d'inactivité.

Remarque : Les journaux de comptabilité AAA n'affichent pas le motif de déconnexion MICA. Par conséquent, le tableau fourni dans ce document ne peut pas être utilisé pour interpréter le motif de déconnexion Radius.

Pour plus d'informations sur la mise en oeuvre de la comptabilité AAA, reportez-vous au document Implémentation de la comptabilité AAA basée sur le serveur.

Commandes show modem Operational-status et show modem log

Les commandes IOS show modem Operational-status slot/port et show modem log slot/port peuvent être utilisées pour déterminer le motif de déconnexion MICA.

Le résultat de cette commande montre pourquoi votre connexion a été perdue ou pourquoi la connexion actuelle n'est pas ce que vous attendez. Voir les motifs de déconnexion ci-dessous pour des explications sur les différents types de déconnexion.

as5300-2#show modem operational-status 1/1

Modem(1/1) Operational-Status:

Parameter #0  Disconnect Reason Info:  (0xDF03)

Type (=6 ):  TX (host to line) data flushing - OK

Class (=31):  Requested by host

Reason (=3 ):  DTR dropped

! --- This output was shortened for brevity.

La commande show modem log slot/port affiche également le motif de déconnexion

maui-nas-02#show modem log 1/0

Modem 1/0 Events Log:

00:03:33:Startup event:MICA Hex modem (Managed)

Modem firmware = 2.7.3.0

...

...

! --- This output was removed for brevity.

...

00:00:26:End Connect event:

Call Timer:  124 secs

Disconnect Reason Info:  (0x8220)

Type (=4 ):  Rx (line to host) data flushing - OK

Class (=2 ):  EC condition - locally detected

Reason (=32):  received DISC frame -- normal LAPM termination

Déconnecter le format de raison

Une raison de déconnexion se compose de quatre chiffres hexadécimaux. Les trois chiffres hexadécimaux de bas ordre peuvent être utilisés pour identifier la raison de la déconnexion. Le chiffre hexadécimal d'ordre élevé indique généralement le type de raison de déconnexion ou l'heure à laquelle la raison de déconnexion s'est produite. Ces options sont décrites dans la section Motif de déconnexion : Types. Par exemple, si la raison de déconnexion est 0xWXYZ, 0xXYZ peut identifier la raison de déconnexion tandis que 0xW indique quand la raison de déconnexion s'est produite.

Dans les exemples ci-dessus, 0xF03 et 0x220 identifient le motif de déconnexion tandis que 0xD et 0x8 indiquent quand le motif de déconnexion s'est produit. Les définitions des motifs de déconnexion MICA sont fournies dans la section Motifs de déconnexion de modem MICA.

Pour plus d'informations sur le fonctionnement des modems MICA, reportez-vous à la documentation Vérification des performances des modems et Opérations de gestion des modems dans l'étude de cas Cisco AS5x00 pour les services de modems IP de base.

États du modem MICA

Province

Description

INACTIF (#0)

Dans cet état, la session du modem est actuellement inactive. L'état IDLE est saisi à partir de l'état TERMINATING lors de la réception de la vérification par le DSP que toutes les opérations ont été arrêtées.

CALL_SETUP (#5)

Dans cet état, le processeur de signal du modem est prêt à recevoir et à générer des signaux T1, MF (Multiple Frequency), DTMF (Dual tone Multi-Frequency), R1, R2 et de progression d'appel. Le modem reste à l'état CALL_SETUP jusqu'à ce qu'il reçoive un message LINK_TERMINATE, SOFTWARE_RESET ou INITIATE_LINK de l'hôte.

CONNECTER (#10)

L'état CONNECT est entré à partir de l'état CALL_SETUP(#5) uniquement à la réception de la commande host à Initiate. En mode Réponse, la session du modem a démarré l'activité, mais n'a pas encore commencé à produire une tonalité de réponse. En mode d'origine, la session du modem a démarré une activité, mais n'a pas encore détecté de tonalité de réponse.

LIEN (#15)

L'état LINK est saisi à partir de l'état CONNECT uniquement lors de la détection d'une tonalité de réponse (source) ou lors de l'amorçage d'une tonalité de réponse (réponse). En mode Réponse, la session du modem transmet une tonalité de réponse à la ligne. En mode Originate, la session modem a détecté la quantité minimale (configurable) de tonalité de réponse requise. Cela indique qu'il existe un homologue distant.

QC (#16)

Quick Connect (QC) est entré soit à partir de l'état d'échange LINK ou V.8 bis si QC est activé et lors de la réception d'une séquence QCA (mode d'origine) ou lors de l'envoi d'une séquence QCA (mode réponse).

FORMATION (#20)

Dans cet état, la session modem négocie la norme de modulation physique (telle que configurée) utilisée lors de la liaison. L'état TRAINUP est saisi à partir de l'état LINK uniquement sur :

- Détection de la fin d'une tonalité de réponse (source).

- Fin de la transmission d'une tonalité de réponse (réponse).

EC_NÉGOCIATION (#25)

Dans cet état, la session du modem négocie le protocole de correction d’erreur et de compression de données à utiliser pendant la liaison. Lorsque les paramètres sont acceptables pour les deux modems (l'intersection des fonctions et de la configuration des deux modems), une négociation réussie est atteinte. Si l'intersection est nulle, le modem se déconnecte ou démarre une session connectée sans erreur. L'état EC_NEGOTIATING est entré à partir de l'état TRAINUP après avoir réussi la synchronisation de modulation physique.

STEADY_STATE (#30)

Dans cet état, la session modem peut transmettre des données sur la liaison. L'état STEADY_STATE est saisi à partir de l'état EC_NEGOTIATING :

- Lors de la négociation de protocole réussie (comme configuré).

- À partir des états STEADY_STATE_RETRAINING et STEADY_STATE_SHIFTINGSPEED, lorsque la liaison physique est correctement négociée.

- En mode Télécopie ; cet état signifie que le moteur T30 fonctionne. Pendant un appel de télécopie, il y a un basculement entre STEADY_STATE et STEADY_STATE_ESCAPE. Il s'agit de l'appel de télécopie passant par les différentes phases d'une session de télécopie (T30).

STATE_RETRAINING (#35)

Dans cet état, la session de modem est en cours de recyclage. L'état STEADY_STATE_RETRAINING est saisi à partir des états STEADY_STATE ou STEADY_STATE_SHIFTINGSPEED :

- Sur la commande Host Link_Control - [Retrain].

- En contournant un seuil interne (configurable).

STEADY_STATE_SHIFTINGSPEED (#40)

Dans cet état, la session du modem est en cours de transfert de vitesse. L'état STEADY_STATE_SHIFTINGSPEED est saisi à partir de l'état STEADY_STATE :

- Sur Host_Link_Control - [Fallback, Fall-Forward].

- En contournant un seuil interne (configurable).

STEADY_STATE_ESCAPE (#45)

Dans cet état, le modem est toujours connecté à l'homologue distant, mais l'interface hôte est en mode de commande AT. Cet état n'est entré qu'à la réception d'une séquence d'échappement Hayes valide. En mode Télécopie, cet état signifie que le moteur T30 accepte les commandes AT de l'hôte. Reportez-vous à l'état STEADY_STATE (#30) pour plus d'informations sur un appel de télécopie.

TERMINAISON (#50)

Dans cet état, la session modem tente de vider les données utilisateur et de supprimer le processeur de signal numérique (DSP). Sur un Software_reset, il n'y a pas de vidage ordonné et le DSP est RESET. L'état TERMINATE est saisi à partir de n'importe quel état :

- Sur LINK_TERMINATE ou Software_reset à partir de l'hôte.

- En cas de perte du transporteur du DSP.

- À réception d’une commande ATH de l’ETTD.

- À la réception d'une trame de correction d'erreurs DISK/LD (déconnexion) de la ligne.

- En contournant différents seuils internes (configurables).

EN ATTENTE ( #55 )

La session du modem est en attente et aucune donnée ne passe sur la liaison. L'état En attente est entré à partir de l'état stabilisé lors de la réception du message de demande de modem en attente (MHReq). Si le modem en attente est activé (Register S62), le modem doit transmettre la séquence d'accusé de réception du modem en attente (MHack) pour accorder la demande et transmettre la tonalité de réponse (ANSam) en cas de silence ou de RT. Si un signal du menu d'appel (CM) (pour V.8) ou une séquence Quick Connect AcKnowledge-QCA (QC - Register S63) est détecté dans l'état En attente, le modem doit quitter l'état En attente et répondre à la séquence d'amorçage suivant les Recommandations V.8 ou QC (Register S63) respectivement. Si aucune séquence d'amorçage n'est détectée après la valeur de délai d'attente en attente définie, le modem doit quitter l'état En attente et se déconnecter. Si le modem en attente est désactivé, le modem doit transmettre le MHnack. Si le MHcda est détecté après la transmission du MHnack, le modem doit se déconnecter. Si le MHfrr est détecté après la transmission du MHnack, le modem doit transmettre la tonalité de retour de réponse et se préparer à détecter les séquences CM (V.8) ou QCA (QC - Register S63) du modem distant. Pour plus d'informations sur le modem en attente, reportez-vous aux spécifications ITU-T V.92.
Remarque : l'état MICA #55 était auparavant l'état VOICE, qui a été supprimé des versions 2.9.1.0 et ultérieures de portware.

ÉCHANGE V.8bis(n° 71)

Cet état est entré à partir de l'état CONNECT uniquement lors de la détection de CRe (mode d'origine) ou du lancement de CRe (mode réponse). Mode de réponse : La session du modem transmet une réponse automatique de requête de capacité (CRe) à la ligne. Mode d'origine : La session modem a détecté la réponse automatique de requête de capacité (CRe). Cela indique qu'il existe un homologue distant.

CLASSEMENT (#72)

L'ÉTIQUETAGE est saisi à partir de l'état LINK ou QC (Register S63) au début de l'estimation du délai aller-retour (RTDEd). Cet état ne s'applique qu'aux normes V.32 et ultérieures.

COURT DE CLASSE(#73)

COURT DE LA PLAGE est saisi à partir de QC (S63) au démarrage du modem numérique RTDE (Round Trip Delay Estimate-Digital Modem)

TRAIN HD (n° 74)

HD TRAIN (Half Duplex Trainup) est entré à partir de RANGING ou RANGING SHORT au début de la formation sur les filtres d'adaptation. Cela s'applique à V.22bis et plus.

STEADY_STATE_PIAFS_RESYNC(#80)

La saisie de STEADY_STATE_PIAFS_RESYNC indique qu'un appel Personal Handyphone Internet Access Forum Standard (PIAFS) a perdu la synchronisation et effectue une resynchronisation.

STEADY_STATE_PIAFS_SPEEDSHIFT(#85)

La saisie de STEADY_STATE_PIAFS_SPEEDSHIFT indique qu'un appel PIAFS négocie un changement de vitesse. Il s'agit d'un état transitoire momentané. MICA ne restera jamais dans cet état. Si la resynchronisation entraîne un déplacement de vitesse, MICA passe à cet état à partir de STEADY_STATE_PIAFS_RESYNC, puis passe à STEADY_STATE. Si la resynchronisation n'entraîne PAS de changement de vitesse, STEADY_STATE_PIAFS_RESYNC passe directement à STEADY_STATE une fois terminé.

Raisons de déconnexion du modem MICA

Une raison de déconnexion du modem MICA se compose de quatre chiffres hexadécimaux. Les trois chiffres hexadécimaux de bas ordre identifient de manière unique la raison de la déconnexion. Le chiffre hexadécimal d'ordre élevé indique le type de raison de déconnexion ou l'heure à laquelle la raison de déconnexion s'est produite. Dans l'exemple ci-dessus, où le code de déconnexion est hexadécimal 0xDF03, le 0xF03 identifie le motif de déconnexion tandis que 0xD indique quand le motif de déconnexion s'est produit (Motif de déconnexion : Types).

Les raisons de déconnexion décrites ci-dessous n'incluent pas le type de déconnexion. Par conséquent, à partir de la raison de déconnexion que vous avez, retirez le chiffre hexadécimal le plus à gauche et comparez les chiffres restants aux options ci-dessous. Dans l'exemple ci-dessus, recherchez 0xF03 dans la section ci-dessous.

Remarque : Dans ce document, le modem hôte est le modem MICA sur le serveur d'accès Cisco, tandis que le modem client est le modem périphérique distant (par exemple, un modem PC client).

Type de déconnexion

Code raison de déconnexion

Description

-

0

Aucune déconnexion n'a encore eu lieu. Ce code s'affiche si la raison de déconnexion est demandée immédiatement après le chargement du logiciel ou pendant un appel, avant l'état stabilisé.

Motifs généraux de déconnexion (classe 0)

2

0x001

Cisco IOS a brusquement interrompu l'appel pour une raison quelconque, par exemple parce que la couche 1 est tombée sur l'étendue physique contenant l'appel.

2

0x002

Terminaison de la couche de correction d'erreurs (EC).

2

0x003

La tâche de décompression MNP5 (Microcom Network Protocol 5) a reçu un jeton illégal dans le flux de données. Cette raison de déconnexion se produit en mode données (0x3003). Il y a probablement une erreur logique dans l'implémentation du modem ou du partenaire de décompression ou de correction d'erreurs. (Il est également possible qu'une ligne se renverse ou qu'une erreur de mémoire vive se produise.)

2,4,6

0x004

La tâche de décompression V.42bis ou V.44 a reçu un jeton illégal dans le flux de données. Cette raison de déconnexion peut se produire en mode données (0x4004). Il y a probablement une erreur logique dans l'implémentation du modem ou du partenaire de décompression ou de correction d'erreurs. (Il est également possible qu'une ligne se renverse ou qu'une erreur de mémoire vive se produise.) Pour V.44, ce code est complété par l'index 119 du champ d'informations de liaison de diagnostic (un champ d'informations de huit octets utilisé comme outil de débogage).

2

0x005

Erreur logicielle MICA. Le code d'erreur pour cette raison de déconnexion est 0x4005. Une erreur logicielle MICA s'est produite qui indique une variable d'état de coprocesseur incorrecte.

6

0x006

La commande ATH a été détectée par le modem local. Cette raison de déconnexion se produit en mode données (0xC006 et 0xE006). La commande ATH (Hangup) a été détectée par le modem local (MICA). Par exemple, lors d’une numérotation à partir d’IOS, une fois l’appel connecté, l’interface DTE IOS a effacé l’appel en transmettant une commande ATH intrabande.

3

0x007

La commande AT dial a été abandonnée. La commande AT dial a été abandonnée par la commande any key abort. Par exemple, le modem hôte émet un appel. Lors de l'établissement de la connexion, avant STEADY STATE, l'annulation de la commande de numérotation AT s'effectue en appuyant sur n'importe quelle touche.

3

0x008

L'appel a pris trop de temps pour terminer la connexion. Notez que le minuteur S7 (attendez l'opérateur après la numérotation) a expiré pour cette déconnexion. Cette raison de déconnexion se produit lors de la configuration de l'appel (0x6008). Le modem hôte a mis trop de temps à établir une connexion en raison d'un recyclage. Les causes sont les suivantes : difficulté à choisir (négocier) une norme de couche I (par exemple, abandonner l'appel avant de revenir avec la raison de déconnexion 0x6102), ou une combinaison d'établissement de couche I et de couche II prenant trop de temps. Par exemple, la négociation de la correction d'erreur prend un long temps en plus d'une remise en forme ou en raison d'erreurs de bits introduites lorsque le modem client tente de se connecter à un débit agressif (le récepteur du modem client tente de se connecter à un débit qu'il ne peut pas supporter). Ce type de déconnexion est pris en compte par rapport à CSR. Cette déconnexion peut également se produire si le modem de réponse n'a entendu aucune tonalité du canal (par exemple, l'initiateur n'était pas un modem).

2

0x009

DSP a été réinitialisé (commande, interne ou spontané). Le code d'erreur pour cette raison de déconnexion est 0x4009. Le DSP du modem hôte a été réinitialisé par le processeur de contrôle (CP) ou le processeur de signal (SP). Le CP réinitialise le DSP si les messages du CP vers le SP ne sont pas reçus. Le SP se réinitialise lui-même s'il obtient une erreur d'incohérence interne.

4,6

0 x 00 A

Réception d'un mot de code STEPUP illégal. Spécifie la réception d'un mot de code STEPUP lorsqu'il entraîne le dépassement de N1 de la valeur C2 (taille de mot de code actuelle) (taille maximale de mot de code : négocié) et est valable uniquement pour V.44 et V.42bis.

4,6

0 x 00 B

Réception d'un mot de code V.42bis illégal. Spécifie la réception d'un mot de code, à tout moment, égal à C1 (prochaine entrée de dictionnaire vide) et est valide pour V.42bis. (La réception d'un mot de code = C1 est illégale en V.42bis, mais légale en V.44).

4,6

0 x 00 C

Réception d'un jeton illégal (trop grand) en V.44 ou V.42bis. Cela signifie que la taille du mot de code V.42bis ou V.44 reçu dépasse la limite négociée. Spécifie la réception d'un mot de code, à tout moment, supérieur à C1 (prochaine entrée de dictionnaire vide) et valide pour V.44 et V.42bis.

4,6

0x00D

Réception d'un code de commande réservé V.44 ou V.42bis. Spécifie la réception d'un code de commande réservé et est valide pour V.44 et V.42bis.

4,6

0x00E

V.42bis ou V.44 a reçu un mot de code supérieur à la prochaine entrée vide du dictionnaire. Réception d'un caractère STEPUP V.44 non autorisé. Cela indique la réception d'un code de contrôle STEPUP qui ferait que la valeur de C5 (taille ordinale) dépasserait huit. Ceci est valable uniquement pour V.44.

4,6

0 x 00 F

Dictionnaire V.44 Rx Complet. Spécifie la réception d'un mot de code qui n'est pas un dictionnaire réinitialisé lorsque l'arborescence de noeuds Rx est pleine. Valide uniquement pour V.44.

4,6

0x010

Historique Rx V.44 Complet. Spécifie la réception d'un mot de code qui n'est pas un dictionnaire réinitialisé lorsque l'historique Rx est plein. Valide uniquement pour V.44.

4,6

0x011

La Taille De Chaîne Rx Illégale V.44/V.42bis A Dépassé. Spécifie la réception d'un mot de code qui provoque le dépassement de la taille maximale de chaîne négociée. Il est valable pour V.44 et V.42bis.

4,6

0x012

Une erreur de négociation V.44 s'est produite Spécifie qu'une erreur de négociation V.44 s'est produite. Pour V.44, ce code est complété par l'index 119 du champ d'informations de liaison de diagnostic. L'index du champ d'informations de liaison de diagnostic est un champ d'informations de huit octets utilisé comme outil de débogage.

4,6

0x013

Une erreur de compression V.44 s'est produite Spécifie qu'une erreur de compression V.44 s'est produite. Pour V.44, ce code est complété par l'index 119 du champ d'informations de liaison de diagnostic. L'index du champ d'informations de liaison de diagnostic est un champ d'informations de huit octets utilisé comme outil de débogage.

Conditions signalées par DSP (classe 1)

0x1xx

Conditions DSP signalées par SPE

3,4,5

0x100

Le DSP a perdu le signal de porteuse. En d'autres termes, MICA a détecté une perte d'opérateur de modem client. Cette raison de déconnexion se produit lors de la configuration des appels et en mode données (0x6100, 0x8100 et 0xA100). Le DSP MICA a cessé d'entendre le porteur pendant une période supérieure à la valeur spécifiée dans le registre S10 (délai de raccrochage après perte du porteur). Cela peut signifier que le chemin de conversation a disparu ou que le client a arrêté de transmettre. Si un protocole de couche II (V.42 et/ou V.42bis) est en vigueur, il serait anormal de voir une telle déconnexion. Cette raison de déconnexion se produit parfois pendant la négociation EC (avant le mode données). En d'autres termes, la couche I a été négociée avec succès (ce qui a entraîné une détection du signal porteur) et la déconnexion se produit lors de la tentative d'établissement du protocole de couche II (V.42 et/ou V.42bis). Les causes les plus courantes sont l'abandon de l'appel avant qu'une connexion n'ait lieu. La numérotation par incident, les démarrages abandonnés et le délai d'attente des applications clientes sont interrompus en raison du temps trop long nécessaire à la connexion (par exemple, plusieurs retrains lors de la négociation de couche I). Ce type d'échec est pris en compte par rapport à CSR. La perte de porteuse peut également se produire en mode de données normal lorsque le client abandonne brusquement le porteur. La cause courante est une déconnexion non négociée ou sale de la part du modem client (c'est-à-dire que le modem client abandonne simplement le signal porteur). Cela peut se produire si la liaison est brusquement interrompue (erreur réseau), l'alimentation du modem client est éteinte pour déconnecter l'appel. Cela peut également se produire avec des modems clients moins chers qui n'implémentent pas les protocoles de suppression de couche I et/ou de couche II sur une DTR. Pour un grand nombre de modems clients, il s’agit d’une déconnexion normale. Lorsque le modem client effectue une déconnexion sale, une condition de course existe entre 0xA103, 0xA100 et 0xDF06. Si le DSP du modem hôte détecte une perte de porteuse, 0xA100 gagne et est indiqué comme raison de déconnexion. Si le DSP ne détecte pas de perte de porteuse et se retire jusqu'à ce qu'il atteigne la limite Register S40, 0xA103 gagne. Si le réseau détecte que l'appel a été déconnecté et indique au routeur de se déconnecter, 0xDF06 gagne. Cette raison de déconnexion ne compte pas sur CSR lorsque le modem hôte est en mode données.

3

0x101

Cela se produit lorsque le processeur de signal (SP) est dans la phase de détection ABT (Answer Back Tone) lorsque l'appel échoue.

3

0x102

Échec de l'appel pendant la mise en service du modem en raison d'une modulation incompatible ou d'une mauvaise ligne. Cette raison de déconnexion se produit lors de la configuration de l'appel (0x6102). Cela peut être révélateur des tentatives de négociation d'une modulation non prise en charge telle qu'une modulation propriétaire existante de Rockwell (K56Plus, V.FC, etc.). D'autres causes possibles sont les échecs de formation des DSP dus à de graves déficiences de ligne, des bruits de poussée, l'interruption de la formation, des paramètres de modulation incompatibles, et peut-être l'incapacité à sélectionner correctement une norme de couche I. Ce type de déconnexion est pris en compte par rapport à CSR.

4,5

0x103

Trop de trains ou de vitesses consécutifs. La limite de retenue est spécifiée au registre S40. Cette raison de déconnexion se produit lors de la configuration des appels et du mode données (0x6103, 0x8103 et 0xA103). Au cours de la progression d'un appel, trop de reprises ont eu lieu, ce qui a rendu l'appel inefficace car le débit de données était si faible qu'il n'était plus utile. Dans certaines conditions, le modem client ne complète pas le protocole de déconnexion (par exemple, l’opérateur téléphonique a arrêté l’appel au milieu de la connexion) et MICA tente de récupérer l’appel en effectuant des retrains. Une fois que la limite de retenue est atteinte (la limite de retenue peut être modifiée à l'aide du registre S40), MICA abandonne l'appel et signale cette raison de déconnexion. Dans certaines circonstances (T1/E1 multicanaux fractionnés), ce type de déconnexion peut être considéré comme une déconnexion d'état STANDARD. autrement, cela pourrait simplement être le résultat d'une déconnexion sale due à d'éventuelles erreurs de ligne dont MICA ne peut pas se remettre. Par conséquent, ce type de déconnexion ne compte pas pour CSR puisque l'appel est déjà établi. Cette raison de déconnexion peut également se produire lors de la négociation EC lorsque le modem client est trop agressif avec le taux de connexion initial et ne peut pas maintenir l'appel (comme observé avec les anciens modems client USRobotics). Ce type de déconnexion est pris en compte par rapport à CSR. Lorsque le modem client effectue une déconnexion sale, une condition de course existe entre 0xA103, 0xA100 et 0xDF06. Si le DSP (Digital Signal Processor) du modem hôte détecte une perte de porteuse, 0xA100 gagne et est indiqué comme raison de déconnexion. Si le DSP ne détecte pas de perte de porteuse et se retire jusqu'à ce qu'il atteigne la limite S40 du registre, 0xA103 gagne. Si le réseau détecte que l'appel a été déconnecté et indique au routeur de se déconnecter, 0xDF06 gagne. Cette raison de déconnexion ne compte pas sur CSR lorsque le modem hôte est en mode données.

3

0x104

Problème de détection de fin de tonalité de réponse (ABT). Échec de négociation ou bruit excessif pendant la formation V.34. Les modems hôtes répondent et envoient V.8bis et des tonalités de réponse modulées de 2100Hz (ABT) avec des inversions de phase, mais rencontrent un bruit excessif pendant la séquence de préparation. Recherchez des erreurs sur le chemin du modem appelant au modem répondant dans l'une ou l'autre des directions. Un comportement similaire se produit lorsque le réseau téléphonique public commuté (RTPC) présente une latence supérieure à une seconde et que les modems ne sont pas en mesure de former les suppresseurs d'écho. Les autres causes possibles sont les suivantes :

- Les niveaux d'alimentation TX réels sont incorrects et les tonalités ne sont pas alors gérées par le côté distant.

- Il y a trop de bruit excessif dans les phases III et IV pendant la formation V.34.

- Erreur de l'opérateur.

- Il y a des interférences réseau pendant la formation V.34 (quelqu'un prend le poste).

Ce type de déconnexion est pris en compte par rapport à CSR.

3

0x105

Opération SS7/COT (test de continuité) terminée avec succès Cette raison de déconnexion se produit lors de la configuration de l'appel (0x6105). L'opération SS7/COT (test de continuité) a été effectuée avec succès.

3

0x106

Échec de l'opération SS7/COT (test de continuité) : Délai d'attente T8/T24 en attente de tonalité. Cette raison de déconnexion se produit lors de la configuration de l'appel (c'est-à-dire 0x6106). L'opération SS7/COT (test de continuité) a échoué car le délai du compteur T8/T24 a expiré en attendant la tonalité.

3

0x107

Échec de l'opération SS7/COT (test de continuité) : Délai d'attente T8/T24 en attente de l'arrêt du signal sonore. Cette raison de déconnexion se produit lors de la configuration de l'appel (0x6107). L'opération SS7/COT a échoué car le délai du minuteur T8/T24 a expiré en attendant la tonalité.

4

0x108

Modem en attente (MOH) désactivé par MICA. La demande de désactivation du modem a été reçue du modem client. V.92 spécifie que la raison de la suppression peut être :

- Effacement dû à un appel entrant.

- Effacement dû à un appel sortant.

- Défrichement dû à une autre raison.

4

0 x 109

La valeur du délai d'attente MOH (Modem On Hold) a été atteinte.

Conditions CE locales (classe 2)

0x2xx

Conditions locales de la CE

3

0x201

Jamais reçu de trame LR (Link Request) lors de la négociation. Cette raison de déconnexion se produit lors de la configuration de l'appel (c'est-à-dire 0x6201). Cela signifie que le modem hôte n’a jamais reçu la trame LR lors de la négociation de correction d’erreur. Le modem homologue peut ne pas prendre en charge MNP dans V.42.

3

0x202

Réception d'une trame LR avec un paramètre incorrect (PARAM1). La trame LR (Received MNP Link Request) avait un PARAM1 incorrect ou inattendu. Pour plus d'informations sur PARAM1, reportez-vous à la spécification V.42.

3

0x203

Réception d'une trame LR (Link Request) incompatible. Cette raison de déconnexion se produit lors de la configuration de l'appel (0x6203). La trame MNP LR reçue est incompatible avec les paramètres du modem hôte pour EC.

4,5

0x204

Trop de retransmissions consécutives. Cette raison de déconnexion se produit lors de la configuration des appels et du mode données (0x8204, 0xA204 et 0x6204). Cette raison de déconnexion peut être causée par le bruit sur la ligne. Par exemple, le modem hôte transmet des données au modem client, mais le bruit sur la ligne entraîne la réception incorrecte (ou pas du tout) des données par le côté client. Ainsi, un bruit excessif peut conduire à des retransmissions excessives. Le modem client aurait également pu se déconnecter sans que le modem MICA ne s'en rende compte. Ainsi, le modem hôte retransmet continuellement, sans savoir que le modem client n'est plus présent. Parfois, lorsque l'appel se connecte dans un protocole de compression d'erreur (EC) (Link Access Procedure for Modems (LAPM) ou MNP (Microcom Networking Protocol)), MICA ne peut pas transmettre une trame au modem client. Le modem client ne parvient pas à reconnaître la transmission initiale de MICA, puis ne répond pas aux sondages S19 (Error Correction Retransmission Limit) (la valeur par défaut est 12), de sorte que MICA déconnecte l'appel. L’une des causes peut être que l’opérateur du chemin de transmission s’est considérablement dégradé alors que le client n’a pas réussi à basculer. Une autre cause pourrait être un problème avec le moteur EC du client (comme cela se produirait sur un système Winmodem si Windows cessait de répondre).

6,7

0 x 205

Délai d'inactivité, Déconnexion de liaison MNP (LD) envoyé. Cette raison de déconnexion se produit en mode données (0xC205 et 0xE205). Le modem hôte envoie au modem client une trame LD indiquant un délai d’inactivité.

4,5

0x206

Erreur de protocole EC. Cette raison de déconnexion se produit en mode données (0x8206 et 0xA206). Il s'agit d'une erreur générale de protocole catch-all. Il indique qu'une erreur de protocole LAPM ou MNP EC s'est produite.

3

0x210

Aucun protocole de secours EC n'est disponible. Cette raison de déconnexion se produit dans la configuration des appels (0x6210). La négociation de correction d'erreur n'a pas réussi. L'appel est interrompu car aucun protocole de secours de correction d'erreur n'est disponible. S-register S25 (Link Protocol fallback) détermine le protocole de secours disponible. Les options sont le tramage asynchrone, le tramage synchrone ou la déconnexion (raccrochage).

3

0x211

La trame XID (eXchange IDentification) n'a jamais été reçue lors de la négociation. Cette raison de déconnexion se produit lors de la configuration de l'appel (0x6211). Cela signifie que le modem hôte n'a jamais reçu la trame XID lors de la négociation de correction d'erreur. Le modem client peut ne pas prendre en charge le LAPM dans V.42.

3

0x212

La trame XID reçue est incompatible avec les paramètres locaux. Cette raison de déconnexion se produit dans la configuration des appels (0x6212). La trame XID reçue est incompatible avec les paramètres du modem hôte. Par exemple, le modem client peut indiquer MNP5, alors que le modem hôte indique uniquement V.42 et V.42bis.

3,4,5

0x220

Trame de déconnexion reçue (DISK). Il s'agit de la déconnexion LAP-M normale. Cette raison de déconnexion se produit lors de la configuration des appels et du mode données (0x 6220, 0x8220 et 0xA220). L'appel s'est terminé normalement avec un effacement approprié du côté client. (c'est-à-dire qu'un paquet de déconnexion V.42 a été envoyé du modem client au modem NAS.) Le modem client a abandonné DTR et a négocié proprement un protocole de déconnexion.

3,4,5

0x221

Trame DM reçue. L'homologue se déconnecte probablement. Cette raison de déconnexion se produit en mode de configuration d'appel et de données (0x6221, 0x8221 et 0xA221). Le modem client indique qu'il se déconnecte. Lors de la configuration de l'appel, cette raison indique que le modem client abandonne la négociation de la correction d'erreur.

4,5

0x222

Un numéro de séquence incorrect a été reçu. Cette raison de déconnexion se produit en mode données (0x8222 et 0xA222). Le modem hôte a reçu une trame de correction d'erreur LAPM ou MNP avec un numéro d'ordre ou d'accusé de réception incorrect. Une trame LD ou FRMR (Frame Reject) est envoyée au modem client pour indiquer que le modem hôte se déconnecte.

4,5

0x223

Trame SABME reçue en état stabilisé. Cette raison de déconnexion se produit en mode données (0x8223 et 0xA223). Ceci est interprété comme une erreur de protocole de correction d'erreur LAPM en état d'équilibre. Cela signifie que le modem client peut avoir été réinitialisé en raison de la réception d'un FRMR (Frame Reject).

4,5

0 x 224

Trame XID MNP reçue en état stable. Cette raison de déconnexion se produit en mode données (0x8224 et 0xA224). Ceci est interprété comme une erreur de protocole de correction d'erreur LAPM en état d'équilibre. Cela signifie que le modem client peut avoir été réinitialisé en raison de la réception d'un FRMR (Frame Reject).

4,5

0 x 225

Trame MNP LR reçue en état stabilisé. Cette raison de déconnexion se produit en mode données (0x8225 et 0xA225). Ceci est interprété comme une erreur de protocole de correction d'erreur MNP en état d'équilibre. Cela signifie que le modem client a été réinitialisé.

Conditions spécifiques au protocole PIAFS (classe 2, suite)

3,4

0x230

Un message reçu est plus court que la longueur minimale définie pour ce type de message.

3,4

0x231

Type de trame PIAFS inconnu ou non implémenté reçu. Cela inclut le FI (type de trame principal) et la classe de négociation, de synchronisation ou de contrôle (sous-type).

3,4

0x232

Identificateur de trame de contrôle PIAFS inconnu (CFI). Une trame de contrôle a été reçue avec un ID inconnu ou non implémenté pour sa classe. Notez que les trames utilisateur et continues ne sont pas implémentées et qu'il n'existe aucune trame de notification connue.

3,4

0 x 233

Échec de la négociation de la communication PIAFS. Après la synchronisation initiale, les trames Req/Ack de paramètre de communication sont échangées. Soit les paramètres étaient inacceptables, soit l'initiateur a détecté une réponse NAK (accusé de réception négatif).
Remarque : MICA ne peut fonctionner qu'en tant que client/initiateur à des fins de test

3,4

0 x 234

Échec de la négociation ARQ PIAFS. Après resynchronisation, les trames ARQ Request (Req)/Acknowledgment (Ack) sont échangées. Soit les paramètres étaient inacceptables, soit l'initiateur a détecté une réponse Nak.
Remarque : MICA ne peut fonctionner qu'en tant que client/initiateur à des fins de test

3,4

0 x 235

Problèmes de protocole de transfert de contrôle PIAFS détectés. L'initiateur a reçu un accusé de réception/Nak/Rsp dont l'ID, la classe et la séquence ne correspondaient pas à la demande/Ntf d'origine.
Remarque : MICA ne peut fonctionner qu'en tant que client ou initiateur à des fins de test

3,4

0 x 236

Ce motif de déconnexion n'indique plus la réception d'une trame de demande DataLinkRelease. Il indique maintenant une déconnexion sans raison de déconnexion précédemment générée. Cela signifie que MICA déconnecte un appel, mais constate qu'aucune raison n'a été validée.

3,4

0 x 237

Le temporisateur d'attente de réception de synchronisation PIAFS (T001) a expiré. Ce compteur démarre lorsqu'une trame de demande de synchronisation est envoyée et s'arrête lorsqu'une trame de réception de synchronisation est détectée. Cette erreur ne se produira que lorsque le port MICA fonctionne en tant que client ou initiateur, ce qui se produit uniquement lors du test. La valeur par défaut est de 15 secondes.

3,4

0 x 238

Le temporisateur T002 de réception post-synchronisation PIAFS a expiré. Ce compteur démarre lorsqu'une trame de réception synchrone est envoyée, et s'arrête lorsqu'une trame de réception synchrone (cas de collision) ou une trame de contrôle est détectée. Cette erreur ne se produira que lorsque le port MICA fonctionne en tant que serveur (mode de réponse), qui est le mode de fonctionnement normal. La valeur par défaut est de 15 secondes.

3,4

0 x 239

Le temporisateur d'attente de la demande de synchronisation PIAFS T003 a expiré. Ce compteur démarre lorsqu'une erreur FCS continue est détectée et s'arrête lorsqu'une trame de demande de synchronisation valide est détectée. Cette erreur ne se produira que si le port MICA fonctionne en tant que serveur (mode de réponse), qui est le mode de fonctionnement normal. La valeur par défaut est de 15 secondes.

3,4

0 x 23 A

Le minuteur PIAFS T101 a expiré : temporisateur d'attente de confirmation de trame de contrôle. Commence lorsque la demande de trame de contrôle ou la notification est envoyée, s'arrête lorsque la trame est confirmée. Cette erreur ne se produira que lorsque le port MICA fonctionne en tant que client ou initiateur, ce qui se produit uniquement pendant le test (dix secondes).

3,4

0 x 23 B

PIAFS : reçu FBI (numéro de séquence ACK) hors plage négociée, ou reçu FBI=0 avec une trame de données non vide.

3,4

0 x 23 C

PIAFS : FFI reçu (numéro de séquence MSG) hors plage négociée, ou FFI=0.

3,4

0x23D

PIAFS : la fenêtre de données négociée est inférieure à la valeur RTF (round-trip delay). Cette erreur n'est plus postée par le logiciel et ne devrait jamais être vue.

3,4

0 x 23 E

PIAFS : le champ de longueur des données du message est trop grand. Doit être compris entre 0 et 73.

3,4

0 x 23 F

Erreur interne PIAFS : L'appel SREJ a renvoyé un code d'erreur.

3,4

0 x 240

Erreur de protocole général PIAFS. Il s'agit d'un catalogue pour les erreurs qui n'ont pas de raison de déconnexion associée.

3,4

0x241

PIAFS : échec de la négociation de protocole. Aucun protocole (par exemple, Data Transfer Protocol Fixed Speed, DTP Variable Speed Type1) n’était acceptable pour les deux stations. Les protocoles inacceptables sont DTP Variable Speed Type3 ou Real Time Protocol.

3,4

0x242

PIAFS : la valeur mesurée RTF (retard aller-retour) n'était pas dans la plage définie (acceptable).

3,4

0 x 243

Erreur interne PIAFS : événement inconnu dans le gestionnaire d'événements. Une instruction switch est passée à son cas par défaut.

3,4

0 x 244

Le délai de réponse du processeur de signal (SP) s'est produit lors d'un déplacement de vitesse PIAFS 2.1. Le CP de Mica n'a pas vu la réponse de changement de vitesse dans les 200 ms.

3,4

0 x 245

Le CP de Mica a vu des informations de contrôle incohérentes dans les structures de contrôle partagées CP/SP. En particulier, le tampon de données avait un décalage de tête ou de queue qui se trouvait en dehors des limites du tampon de données (0-63).

Commande MNP ou LAPM incorrecte reçue du partenaire (classe 3)

4.5

0x3xx

EC a détecté un code de commande incorrect. La commande reçue inconnue se trouve dans les deux derniers chiffres. Une trame MNP LD ou LAP-M Frame Reject (FRMR) est envoyée en réponse.

Le partenaire LAPM signale une erreur de protocole MICA (classe 4)

4,5

0x4xx

Conditions CE indiquées par le client dans le cadre de FRMR LAP-M. La raison du bit mappé se trouve dans les deux derniers chiffres.

4,5

0x401

LAPM : pair signale une mauvaise commande. Le modem hôte a reçu une trame FRMR du modem client. La trame FRMR reçue indique que le modem client a reçu une trame de correction d’erreur du modem hôte contenant une commande incorrecte.

4,5

0x403

LAPM : d'homologues signalent que le champ de données n'est pas autorisé ou qu'il a une longueur incorrecte (trames U). Le modem hôte a reçu une trame FRMR du modem client. La trame FRMR reçue indique que le modem client a reçu une trame de correction d'erreur du modem hôte contenant un champ de données non autorisé ou contenant un champ de données de longueur incorrecte (trame U).

4,5

0x404

LAPM : la longueur du champ de données des rapports homologues est supérieure à N401 (la longueur maximale du champ d'informations spécifiée dans V.42), mais présente une séquence de contrôle de trame (FCS) correcte. Le modem NextPort a reçu une trame FRMR du modem client. La trame FRMR reçue indique que le modem client a reçu une trame de correction d'erreur de NextPort qui contenait une longueur de champ de données supérieure au nombre maximal d'octets pouvant être transportés dans le champ d'informations (N401) d'une trame I, d'une trame SREJ, d'une trame XID, d'une trame UI ou d'une trame TEST. La séquence de contrôle de trame est correcte.

4,5

0x408

LAPM : les homologues signalent un numéro de séquence de réception incorrect ou N(R). Le modem hôte a reçu une trame FRMR du modem client. La trame FRMR reçue indique que le modem client a reçu une trame de correction d’erreur du modem hôte contenant un numéro de séquence de réception incorrect.

Le partenaire MNP signale une erreur de protocole de déconnexion ou MICA (classe 5)

4,5

0x5xx

Conditions EC indiquées par le client dans la trame MNP LD. Le champ Motif se trouve dans les deux derniers chiffres

3

0x501

MNP : homologue n'a jamais reçu de trame LR. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique que le modem client n’a jamais reçu de demande de liaison du modem hôte.

3

0x502

MNP : la trame LR des rapports d'homologues a un paramètre n° 1 incorrect. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique que le modem client a reçu une trame de demande de liaison du modem hôte contenant un PARAM1 incorrect (inattendu). Pour plus d'informations sur PARAM1, reportez-vous à la spécification V.42.

3

0x503

MNP : la trame LR des rapports homologues est incompatible avec sa configuration. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique que le modem client a reçu une trame LR du modem hôte qui est incompatible avec la configuration du modem client.

4,5

0x504

MNP : Les pairs signalent trop de retransmissions EC consécutives. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique que le modem client a reçu trop de retransmissions consécutives.

4,5

0x505

MNP : le compteur d'inactivité des rapports homologues a expiré. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique que l’hôte du modem client (ETTD) n’a pas transmis de données au modem client dans un délai donné.

3

0x506

MNP : erreur de rapports homologues. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique que le modem client a reçu une erreur de protocole MNP.

3

0x5FF

Déconnexion MNP normale. Le modem hôte a reçu une trame LD du modem client. La trame LD reçue indique une terminaison MNP normale, indiquant que la DTR du modem client a été abandonnée ou qu'il a reçu une commande +++ ou ATH. Cette raison de déconnexion se produit en mode de configuration d'appel et de données (0x65FF, 0x85FF et 0xA5FF). Le modem hôte a reçu un LD, qui indique une terminaison normale. L'appel s'est terminé normalement avec un effacement approprié du côté client (par exemple, un paquet de déconnexion a été envoyé du modem client au modem hôte). Le modem client a abandonné DTR et a négocié proprement un protocole de déconnexion.

Le partenaire PIAFS indique une erreur de déconnexion ou de protocole MICA (classe 6)

3,4

0x6xx

MICA a reçu un PDLR (DataLinkRelease) PIAFS avec la raison xx (voir les valeurs détaillées ci-dessous).

3,4

0x61x

Classe normale pour PIAFS DataLinkRelease (PDLR) : 0 - Version normale. 1 - Libération normale, poursuite de liaison de données interdite. 2 - Libération normale, poursuite de la liaison de données. ... Autres classes normales - classes non définies propres à certains périphériques clients.

3,4

0x62x

Classe d'utilisation des ressources non possible pour DLR PIAFS (conditions d'occupation) : 8 - ETTD occupé. 9 - Obstruction temporaire. ... Autres classes d'utilisation de ressources non possibles - classes non définies propres à certains périphériques clients.

3,4

0x63x

Classe d'utilisation du service impossible pour PIAFS DLR (mauvais paramètres). 9 - Paramètre de requête impossible. A - Le paramètre de requête n'est pas possible pour le moment. . Autres classes d'utilisation du service non possibles - classes non définies propres à certains périphériques clients.

3,4

0x64x

Le service n'a pas encore fourni de classe pour PIAFS DLR. 1 - Indication de paramètre non encore fournie. ... Autres classes de service non encore fournies - classes non définies propres à certains périphériques clients.

3,4

0x65x

Classe de contenu d'informations non valide pour le DLR PIAFS. 8 - L'attribut de terminal ne correspond pas. ... Autres classes de contenu d'informations non valides - classes non définies propres à certains périphériques clients.

3,4

0x66x

Classe d'erreur de séquence pour PIAFS DLR 0 - Paramètres essentiels insuffisants. 1 - Contenu d'information non défini ou non encore fourni. 5 - Condition ARQ et signal non correspondant. 6 - Le temporisateur expire. ... Autres classes d'erreur de séquence - classes non définies propres à certains périphériques clients.

3,4

0x67x

Autre classe de particularité pour DLR PIAFS. 1 - Pendant l'appel vocal. ... Autres classes particulières - classes non définies propres à certains périphériques clients.

Déconnexion demandée par l'hôte/IOS (classe 31)

6,7

0x1fxx

Déconnexion initiée par l’hôte. La valeur est une somme de 0x1F00 et de la valeur SessionStopCommand. Il s’agit de l’autre raison de fin d’hôte. La raison de l'hôte est indiquée dans l'ordre inférieur octets xx.

3,6,7

0x1f00

Déconnexion initiée par un hôte non spécifique. La valeur est une somme de 0x1F00 et de la valeur SessionStopCommand. Il s’agit de la raison de déconnexion initiale de l’IOS. Il est utilisé pour toutes les déconnexions non standard. Par exemple, cela peut être dû au fait que le logiciel de gestion de modem décide de mettre fin à l'appel. Une explication possible est un échec d'authentification de niveau supérieur RADIUS, TACACS, ou une autre application qui émet une DTR abandonnée au modem hôte. Ce type de déconnexion ne compte pas pour CSR lorsque le modem hôte est en mode données.

3

0x1f01

Le numéro composé était occupé. La déconnexion s'est produite car l'hôte indique que le numéro composé est occupé.

3

0x1f02

Le numéro composé n'a pas répondu. La déconnexion s'est produite car l'hôte indique que le numéro composé n'a pas répondu.

3,6,7

0x1f03

DTR virtuel abandonné. Cet état est reflété par le redirecteur du port d'E/S qui utilise actuellement le modem. La déconnexion s'est produite car l'hôte a abandonné la ligne DTR virtuelle. Cette cause de déconnexion générique est initiée par le logiciel Cisco IOS. Les causes possibles sont le délai d’inactivité, la réception de PPP LCP TERMREQ, l’échec d’authentification, la raccrochage Telnet, etc. Pour déterminer la raison du raccrochage, examinez la raison de déconnexion Radius à partir de la commande modem call-record terse ou de Authentication, Authorization, and Accounting (AAA).

6,7

0x1f04

La commande ATH (hangup) a été détectée par l'hôte local.

3

0x1f05

Aucun accès au réseau de l'opérateur téléphonique. La déconnexion s'est produite car l'hôte n'a pas pu accéder au réseau (RNIS).

3,4,5 ,

0x1f06

Déconnexion indiquée par le réseau. Cela peut se produire avant ou pendant le mode données. Une déconnexion 0x1f06 signifie que l’IOS a reçu un signal de raccrochage de circuit du réseau de circuit (c’est-à-dire un signal de déconnexion Q.931 ou un signal de raccrochage CAS), et qu’IOS l’a ensuite communiqué à MICA lorsqu’il a demandé à MICA de raccrocher. Si MICA atteint le mode de données et qu'un protocole EC (LAPM ou MNP4) n'a pas été négocié, il peut s'agir d'une déconnexion normale. Cette raison peut également être générée lorsque les utilisateurs de Windows 95 ou 98 Dial Up Networking (DUN) cliquent sur annuler pendant la formation et avant que l'appel n'atteigne l'état stabilisé. En outre, si le client devait débrancher brusquement la ligne téléphonique ou désactiver le modem, cette raison de déconnexion serait considérée comme normale. Cependant, si la connexion a négocié EC (LAPM ou MNP4), et donc en mode données, cette raison de déconnexion peut être générée par une déconnexion sale (c'est-à-dire une déconnexion qui n'est pas une fin d'appel gracieuse). Ceci est dû au fait que si l’ETTD client (en mode données) déconnecte l’appel de manière ordonnée (avec DTR drop ou +++/ATH), le modem client nous envoie un DISQUE LAPM (ou MNP LD) avant de raccrocher, générant ainsi une raison de déconnexion 0x220 plutôt que 0x1f06. Ainsi, la déconnexion indiquée par le réseau est, dans ce cas, probablement révélatrice d'un modem client malheureux, qui a décidé qu'il ne pouvait plus supporter l'opérateur pour une raison quelconque.

3

0x1f07

Opération SS7/COT terminée par le NAS. La déconnexion s'est produite car le NAS a mis fin à l'opération SS7/COT (Continuity Test).

3

0x1f08

L'opération SS7/COT a été interrompue par le routeur en raison d'un délai d'attente T8/T24.

-

0x1fff

Non sollicité. TERMINAISON. L’hôte envoie cette raison de déconnexion lorsqu’il reçoit un message de fin non sollicité.

Motif de déconnexion : Types

La raison de déconnexion:types décrit quand l'appel s'est réellement déconnecté. Ils peuvent être classés en deux types principaux : pendant la configuration des appels et pendant le mode données (état stable). Le tableau suivant indique les types de motif de déconnexion les plus courants et leurs valeurs, comme indiqué dans le motif de déconnexion.

Type de déconnexion

Type de déconnexion (hexadécimal)

Description

0

0x0..

(inutilisé)

1

0x2...

(inutilisé)

2

0x4...

Autres situations.

3

0x6..

Une condition s'est produite lors de la configuration de l'appel.

4

0x8..

En mode données. Rx (ligne à hôte) vidage des données OK. La condition de déconnexion s'est produite en mode données. MICA tente de transmettre les données reçues à l’hôte (IOS). Pour certaines déconnexions (par exemple, PIAFS), il s'agit du seul type de mode de données utilisé ; aucune indication n'est faite de la direction du vidage des données.

5

0xA...

En mode données. Le vidage des données Rx (ligne à hôte) n'est pas correct. La condition de déconnexion s'est produite en mode données. MICA tente de transmettre les données reçues à l’hôte (IOS). Dans le code MICA hérité, ce type est équivalent au type 4 ci-dessus. Bien que IOS affiche des déconnexions telles que non OK, aucun problème ne s’est produit.

6

0xC...

En mode données. TX (hôte à ligne) vidage des données OK. La condition de déconnexion s'est produite en mode données. MICA tente de transmettre des données IOS (buffered host) au modem partenaire.

7

0xE...

En mode données. Le vidage des données TX (hôte à ligne) n'est pas correct. La condition de déconnexion s'est produite en mode données. MICA tente de transmettre des données IOS (buffered host) au modem partenaire. Dans le code MICA hérité, ce type est équivalent au type 6 ci-dessus. Bien que IOS affiche des déconnexions telles que non OK, aucun problème ne s’est produit.

Informations connexes

- Jeu de commandes MICA AT

- Jeu de commandes MICA AT avec PIAFS

- Notes de version du logiciel MICA

- Référence des commandes et registres NextPort AT

- Support technique - Cisco Systems