États et raisons de déconnexion du modem MICA
Contenu
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 :
-
Enregistrements d'appels du modem : Ces rapports indiquent les raisons de déconnexion du logiciel IOS® et du modem MICA.
-
Journaux de comptabilité AAA : Ces rapports indiquent uniquement le motif de déconnexion du logiciel IOS.
-
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 :
|
| 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 :
|
| 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 :
|
| 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 :
|
| 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 :
|
| 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 :
|
| 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 :
|
| 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
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)