Composition et accès : Connexions asynchrones

États et raisons de déconnexion du modem MICA

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


Contenu


Introduction

Ce document décrit comment interpréter codes de raison de débranchement d'appel signalés par des Modems d'agrégation de canaux RNIS du modem de Cisco (MICA).

Remarque:  Ce document contient beaucoup de termes qui sont définis dans les normes ITU telles que V.90, V.44, V.42bis, et V.34. Pour plus d'informations sur ces termes veuillez se rapportent à la norme appropriéeleavingcisco.com ITU-T. Des termes spécifiés dans les normes ITU-T ne sont pas expliqués dans ce document.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient se rendre compte de ce qui suit :

Toutes les fois qu'un appel qui utilise les parties spécifiques au domaine de MICA (DSP) est effacé ou déconnecté, le MICA enregistre la raison pour le débranchement. Vous pouvez utiliser cette raison de déterminer si la déconnexion était normale. Sinon, vous pouvez l'employer pour dépister les sources possibles de panne. Les Modems peuvent être dus déconnecté à un grand choix de facteurs tels que des débranchements de client, des erreurs de compagnie de téléphone et des baisses d'appel au serveur d'accès à distance (NAS). Une raison typique de débranchement est que le DTE (modem client ou NAS) à une extrémité veut la fermer. De tels débranchements de « normale » indiquent que le débranchement n'était pas un résultat des erreurs de niveau de modem ou de transmission. Pour plus d'informations sur déterminer si une raison de débranchement est normale, référez-vous à l'aperçu du modem général et le NAS raye la qualité.

Composants utilisés

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

  • Routeurs de 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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Détermination de l'état de modem

Utilisez la commande d'emplacement/port de show modem log de trouver l'état actuel d'un modem MICA. Dans cette sortie de log, les entrées les plus récentes se produisent vers l'extrémité du log. L'état du modem MICA en cours est affiché dans le dernier événement d'état de modem (modification). Dans l'exemple de sortie ci-dessous, l'état de modem est inactif, indiqué par l'événement d'état de modem a embouti 00:00:28. Référez-vous à la table d'états du modem MICA pour plus d'informations sur les états du modem MICA possibles.

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 de la raison de débranchement

Toutes les fois qu'une connexion modem est terminée, les états deux de NAS déconnectent des raisons : les raisons DTE (IOS) et les raisons DCI (MICA). Ces raisons de débranchement peuvent être signalées suivre trois méthodes primaires :

  1. Enregistrements d'appel par modem : Ceux-ci signalent le logiciel et des motifs de déconnexion du modem MICA de ½ du ¿  IOSïÂ.

  2. Journaux de comptabilisation AAA : Ceux-ci signalent seulement la raison de débranchement d'IOS Software.

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

Enregistrements d'appel par modem

L'IOS et le motif de déconnexion du modem pour une connexion particulière sont affichés dans l'enregistrement d'appel par modem (MCR). Le MCR est envoyé à un serveur de Syslog par le NAS pendant l'arrêt de chaque appel. Des enregistrements d'appel par modem ont été introduits dans le Logiciel Cisco IOS version 11.3AA et le 12.0T et sont lancés (sur le NAS) utilisant le modem call-record de commande laconique. Pour plus d'informations sur mettre en application des enregistrements d'appel par modem, référez-vous au document utilisant le Syslog, le NTP, et les enregistrements d'appel par modem pour isoler et dépanner des défauts.

Dans l'enregistrement d'appel par modem d'échantillon affiché ci-dessous, le motif de déconnexion d'IOS indiqué par le disc(radius) est transporteur perdu/transporteur perdu, alors que le motif de déconnexion du modem indiqué par le disc(modem) est :

A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received    
DISC frame -- normal LAPM termination

Référez-vous aux motifs de déconnexion du modem de mica de table pour plus d'informations sur interpréter le 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 de comptabilisation AAA

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

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ébranchement (disc-cause=4), dans l'exemple ci-dessus, indique que le débranchement a été provoqué par par l'expiration de la minuterie de veille.

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

Pour plus d'informations sur mettre en application l'aaa accounting référez-vous au document mettant en application la comptabilité d'AAA sur serveur.

Les commandes de show modem operational-status et de show modem log

L'emplacement de show modem operational-status de commandes IOS/emplacement de port et de show modem log/port peuvent être utilisés pour déterminer le motif de déconnexion du MICA.

La sortie du cette commande montre pourquoi votre connexion a été perdue ou pourquoi n'est pas la connexion en cours ce que vous comptez. Voyez les raisons de débranchement 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.

L'emplacement/port de show modem log affiche également la raison de débranchement

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

Format de raison de débranchement

Une raison de débranchement se compose de quatre chiffres hexadécimaux. Les trois chiffres hexadécimaux de poids faible peuvent être utilisés pour identifier la raison de débranchement. Le chiffre hexadécimal de poids fort indique généralement le type de la raison de débranchement ou du temps auquel la raison de débranchement s'est produite. Ces options sont décrites dans la raison de débranchement de section : Types. Par exemple, si la raison de débranchement est 0xWXYZ, puis 0xXYZ peut identifier la raison de débranchement tandis que 0xW indique quand la raison de débranchement s'est produite.

Dans les exemples ci-dessus, 0xF03 et 0x220 identifient la raison de débranchement tandis que 0xD et 0x8 indiquent quand la raison de débranchement s'est produite. Les définitions pour les motifs de déconnexion du MICA sont fournies dans les motifs de déconnexion du modem MICA de section.

Pour plus d'informations sur des exécutions de modem MICA, voyez la documentation vérifiante de performances du modem et d'Opérations de gestion de modem dans l'étude de cas de Cisco AS5x00 pour des services de base de modem IP.

États du modem MICA

État Description
INACTIF (#0) Dans cet état, la session de modem est actuellement inactive. L'état libre est entré de l'état de TERMINAISON lors de recevoir la vérification du DSP que toutes les exécutions ont arrêté.
CALL_SETUP (#5) Dans cet état, le processeur de signal de modem est préparé recevoir et générer le t1, la plusieurs fréquence (MF), la double tonalité multifréquence (DTMF), le R1, le R2 et les signaux de progression de l'appel. Le modem reste dans l'état CALL_SETUP jusqu'à ce qu'il reçoive un message LINK_TERMINATE, SOFTWARE_RESET, ou INITIATE_LINK de l'hôte.
CONNECTEZ (#10) L'état de CONNECTER est écrit CALL_SETUP(#5) de l'état seulement lors de recevoir la commande d'hôte d'initier. En mode réponse, la session de modem a initié l'activité, mais n'a pas encore commencé à produire une tonalité de réponse. Dans lancez le mode, la session de modem a initié l'activité, mais n'a pas encore détecté une tonalité de réponse.
LIEN (#15) L'état de lien est entré de l'état de CONNECTER seulement en détectant une tonalité de réponse (commencez) ou l'initiation d'une tonalité de réponse (réponse). En mode réponse, la session de modem transmet une tonalité de réponse à la ligne. Dans lancez le mode, la session de modem a détecté la quantité (configurable) minimum de tonalité de réponse requise. Ceci indique qu'il y a un pair distant.
QC (#16) Connectez vite (QC) est commenc de l'état de LIEN ou d'échange BRI V.8 si le QC est activé et lors de recevoir un ordre QCA (lancez le mode) ou d'envoyer un ordre QCA (mode réponse).
TRAINUP (#20) Dans cet état, la session de modem négocie la norme physique de modulation (comme configuré) utilisée pendant le lien. L'état d'apprentissage est entré de l'état de lien seulement au moment :
  • Détecter la fin d'une tonalité de réponse (commencez).
  • Se terminer la transmission d'une tonalité de réponse (réponse).
EC_NEGOTIATING (#25) Dans cet état, la session de modem négocie la correction d'erreurs et le protocole de compression de données à utiliser pendant le lien. Quand les configurations sont agréables aux deux Modems (l'intersection des deux capacités et configurations de Modems), une négociation réussie est atteinte. Si l'intersection est nulle, le modem déconnecte ou commence une session connectée parerreur. L'état EC_NEGOTIATING est écrit de l'état d'apprentissage en se terminant avec succès la synchronisation physique de modulation.
STEADY_STATE (#30) Dans cet état, la session de modem peut passer des données sur le lien. L'état STEADY_STATE est entré de l'état EC_NEGOTIATING :
  • Sur la négociation réussie de protocole (comme configuré).
  • Des états STEADY_STATE_RETRAINING et STEADY_STATE_SHIFTINGSPEED, comme lien physique est avec succès renégocié.
  • Dans le mode 'fax'; cet état signifie que l'engine T30 s'exécute. Pendant un appel de télécopie, il y a un basculeur entre STEADY_STATE à STEADY_STATE_ESCAPE. Ceci représente l'appel de télécopie allant par ses différentes phases d'une session de la télécopie (T30).
STEADY_STATE_RETRAINING (#35) Dans cet état, la session de modem recycle actuellement. L'état STEADY_STATE_RETRAINING est écrit des états STEADY_STATE ou STEADY_STATE_SHIFTINGSPEED :
  • Sur l'hôte Link_Control - [commande de recyclage].
  • En se déclenchant un seuil interne (configurable).
STEADY_STATE_SHIFTINGSPEED (#40) Dans cet état, la session de modem est actuellement vitesse-changeante. L'état STEADY_STATE_SHIFTINGSPEED est écrit de l'état STEADY_STATE :
  • Sur Host_Link_Control - [retour, Chute-en avant].
  • En se déclenchant un seuil interne (configurable).
STEADY_STATE_ESCAPE (#45) Dans cet état, le modem est encore connecté au pair distant, mais l'interface d'hôte est en mode de commande AT. Cet état est seulement écrit lors de recevoir une séquence d'échappement valide de Hayes. Dans le mode 'fax', cet état signifie que l'engine T30 reçoit des commandes AT de l'hôte. Voyez l'état STEADY_STATE (#30) pour des informations sur un appel de télécopie.
TERMINAISON (#50) Dans cet état, les tentatives de session de modem de vider des données d'utilisateur et clair-vers le bas le processeur de signaux numériques (DSP). Sur un Software_reset, il n'y a aucune annulation ordonnée, et le DSP EST REMIS À L'ÉTAT INITIAL. L'état de TERMINAISON est écrit de n'importe quel état :
  • Sur LINK_TERMINATE ou Software_reset de l'hôte.
  • Sur le transporteur perdu du DSP.
  • À la réception d'une commande ATH du DTE.
  • À la réception d'une trame de correction des erreurs DISC/LD (débranchement) de la ligne.
  • En se déclenchant de divers seuils internes (configurables).
SUR L'ATTENTE (#55) La session de modem est sur l'attente, et donnée ne transmet pas le lien. En fonction l'état en attente est entré d'équilibré lors de recevoir le modem sur le message de demande de l'attente (MoH) (MHReq). Si le modem sur l'attente est activé (registre S62), le modem transmettra le modem sur l'ordre d'accusé de réception d'attente (MHack) pour accorder la demande et transmettre la réponse de retour modifiez la tonalité (ANSam) quand le silence ou la droite est détecté. Si un signal du menu d'appel (cm) (pour V.8) ou se connectent vite reconnaissent-QCA (QC - registre S63) l'ordre est détecté dans en fonction l'état en attente, le modem quittera en fonction l'état en attente et répondra à l'ordre initiant suivant le V.8 ou des recommandations QC (registre S63) respectivement. Si aucun ordre initiant n'est détecté après qu'en fonction la valeur du dépassement de durée de tenir définie, le modem quitte en fonction l'état en attente et le débranchement. Si le modem sur l'attente est désactivé, le modem transmettra MHnack. Si MHcda est détecté après que MHnack soit transmis, le modem déconnectera. Si MHfrr est détecté après que MHnack soit transmis, le modem transmettra la réponse de retour modifient la tonalité et obtiennent prêt à détecter des ordres cm (V.8) ou QCA (QC - enregistrez S63) du modem distant. Pour plus d'informations sur le modem sur l'attente, référez-vous aux caractéristiques ITU-T V.92leavingcisco.com .

Remarque: L'état #55 de MICA était autrefois l'état de VOIX, qui a été maintenant retiré des versions de portware 2.9.1.0 et en haut.

V.8bis EXCHANGE(#71) Cet état est écrit de CONNECTENT l'état seulement en détectant CRe (lancez le mode) ou l'initiation de CRe (mode réponse). Mode réponse : La session de modem transmet une capacité Demande-autoanswer (CRe) à la ligne. Lancez le mode : La session de modem a détecté la capacité Demande-autoanswer (CRe). Ceci indique qu'il y a un pair distant.
RANGING(#72) Le RANGEMENT est écrit de l'état de LIEN ou QC (registre S63) en commençant l'évaluation de délai d'aller-retour (RTDEd). Cet état s'applique seulement aux normes V.32 et se lève.
SHORT(#73) DE RANGEMENT Le RANGEMENT SOUS PEU est écrit du QC (registre S63) en démarrant le modem Évaluation-numérique de délai d'aller-retour (RTDEd)
HD TRAIN(#74) La SÉRIE HD (Trainup bidirectionnel-alterné) est entrée du RANGEMENT ou du RANGEMENT SOUS PEU sur le début de la formation de filtre d'adaptation. Ceci s'applique à V.22bis et se lève.
STEADY_STATE_PIAFS_RESYNC(#80) Écrire STEADY_STATE_PIAFS_RESYNC indique qu'un appel standard de Handyphone de forum personnel d'accès Internet (PIAFS) a perdu le sync et exécute une resync.
STEADY_STATE_PIAFS_SPEEDSHIFT(#85) Écrire STEADY_STATE_PIAFS_SPEEDSHIFT indique qu'un appel PIAFS négocie une modification de shift de vitesse. C'est un état momentané et transitoire. Le MICA ne restera jamais dans cet état. Si les résultats de resyncronisation dans une vitesse décalent, alors les transitions de MICA à cet état de STEADY_STATE_PIAFS_RESYNC, et continue alors à STEADY_STATE. Si la resynchronisation n'a pas comme conséquence un shift de vitesse, alors des transitions STEADY_STATE_PIAFS_RESYNC directement à STEADY_STATE si complet.

Raisons de déconnexion du modem MICA

Un motif de déconnexion du modem MICA se compose de quatre chiffres hexadécimaux. Les trois chiffres hexadécimaux de poids faible identifie seulement la raison de débranchement. Le chiffre hexadécimal de poids fort indique le type de la raison de débranchement ou du temps auquel la raison de débranchement s'est produite. Dans l'exemple ci-dessus, où le code de débranchement est 0xDF03 hexadécimal, le 0xF03 identifie la raison de débranchement tandis que 0xD indique quand la raison de débranchement s'est produite (raison de débranchement : Types).

Les raisons de débranchement décrites ci-dessous n'incluent pas le type de débranchement. Par conséquent, de la raison de débranchement vous avez, décollez le chiffre hexadécimal extrême gauche et comparez les autres chiffres aux options ci-dessous. De l'exemple ci-dessus, recherchez 0xF03 dans la section ci-dessous.

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

Type de débranchement Code de raison de débranchement Description
- 0 Aucun débranchement ne s'est encore produit. Vous voyez ce code si la raison de débranchement est questionnée juste après le chargement de Portware ou pendant un appel, avant équilibré.
Le débranchement général raisonne (classe 0)
2 0x001 Le Cisco IOS abruptement a terminé l'appel pour quelque raison - par exemple, parce que la couche 1 est allée vers le bas sur l'envergure physique contenant l'appel.
2 0x002 Arrêt de correction d'erreurs de la couche (l'EC).
2 0x003 La tâche de décompression du protocole réseau 5 de Microcom (MNP5) a reçu un jeton illégal dans le flux de données. Cette raison de débranchement se produit pendant le mode Données (0x3003). Il y a probablement une erreur de logique dans le modem ou l'implémentation du partenaire de/compression ou de correction d'erreurs. (Il y a également la possibilité d'une perturbation de ligne fortuite ou d'une erreur de mémoire RAM.)
2,4,6 0x004 La tâche de la décompression V.42bis ou V.44 a reçu un jeton illégal dans le flux de données. Cette raison de débranchement peut se produire pendant le mode Données (0x4004). Il y a probablement une erreur de logique dans le modem ou l'implémentation du partenaire de/compression ou de correction d'erreurs. (Il y a également la possibilité d'une perturbation de ligne fortuite ou d'une erreur de mémoire RAM.) Pour V.44, ce code est complété par l'index diagnostique 119 (une zone d'informations de champ de l'information de liaison de huit octets utilisée comme outil pour mettre au point).
2 0x005 Erreur logicielle de MICA. Code d'erreur pour cette raison de débranchement est 0x4005. Une erreur logicielle de MICA s'est produite qui indique une mauvaise variable d'état de coprocesseur.
6 0x006 La commande ATH a été détectée par le modem local. Cette raison de débranchement se produit pendant le mode Données (0xC006 et 0xE006). La commande ATH (raccrocher) a été détectée par le modem local (MICA). Par exemple, pendant un dialout d'IOS, après que l'appel ait été connecté, l'interface IOS DTE a effacé l'appel en transmettant une commande intrabande ATH.
3 0x007 À la commande de cadran a été abandonné. À la commande de cadran a été abandonné par la n'importe quelle commande principale d'arrêt. Par exemple, le modem d'hôte lance un appel. Pendant l'établissement de la connexion, avant ÉQUILIBRÉ, appuyer sur n'importe quelle clé entraînera à la commande de cadran d'être abandonné.
3 0x008 L'appel a pris trop long pour se terminer la connexion. Notez que le temporisateur S7 (attente le transporteur après cadran) expiré pour ce débranchement. Cette raison de débranchement se produit pendant l'établissement d'appel (0x6008). Le modem d'hôte a pris trop long pour établir une connexion due au recyclage. Les causes sont : difficulté choisissant (négociation) une norme de la couche I (par exemple, abandonnant l'appel avant le renvoi avec raison 0x6102 de débranchement), ou une combinaison de l'établissement de la couche I et de la couche II prenant trop long. Par exemple, la négociation de correction des erreurs prend une quantité étendue de temps sur un recyclage ou en raison des erreurs de bit l'a introduit quand les essais de modem client pour se connecter à un débit agressif (les essais du récepteur du modem client à connecter à un débit qu'il ne peut pas soutenir). Ce type de comptes de débranchement contre le CSR. Ce débranchement peut également se produire si le modem de réponse n'entendait aucune tonalité du canal (par exemple, le créateur n'était pas un modem).
2 0x009 Le DSP a été remis à l'état initial (commande, interne ou spontané). Code d'erreur pour cette raison de débranchement est 0x4009. Le DSP dans le modem d'hôte a été remis à l'état initial par le processeur de contrôle (CP) ou le processeur de signal (fournisseur de services). Le CP remettra à l'état initial le DSP si des messages du CP au fournisseur de services ne sont pas reconnus. Le fournisseur de services se remettra à l'état initial s'il obtient une erreur interne d'incohérence.
4,6 0x00A Réception d'un mot de code de STEPUP illégal. Spécifie la réception d'un mot de code STEPUP quand elle ferait dépasser la valeur de C2 (taille de mot de code en cours) N1 (taille de mot de code maximum : est négocié) et valide pour V.44 et V.42bis seulement.
4,6 0x00B Réception d'un mot illégal de code V.42bis. 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 = d'un C1 est illégale dans V.42bis, mais légale dans V.44).
4,6 0x00C Acquittez d'un jeton illégal (trop grand) dans V.44 ou V.42bis. Ceci signifie que la taille de mot de code V.42bis ou V.44 reçue a dépassé le maximum négocié. Spécifie la réception d'un mot de code, à tout moment, plus grand que C1 (prochaine entrée de dictionnaire vide) et est valide pour V.44 et V.42bis.
4,6 0x00D Réception de code de commande réservée V.44 ou V.42bis. Spécifie la réception de code de commande réservée et est valide pour V.44 et V.42bis.
4,6 0x00E V.42bis ou V.44 a reçu le mot de code plus grand que la prochaine entrée de dictionnaire vide. Réception d'un caractère du STEPUP illégal V.44. Ceci indique la réception d'un code de contrôle SURVOLTEUR qui ferait dépasser la valeur de C5 (taille ordinale) huit. C'est valide pour V.44 seulement.
4,6 0x00F Dictionnaire V.44 Rx complètement. Spécifie la réception d'un mot de code qui n'est pas une réinitialisation du dictionnaire quand la noeud-arborescence de Rx est pleine. Valide pour V.44 seulement.
4,6 0x010 Historique V.44 Rx complètement. Spécifie la réception d'un mot de code qui n'est pas une réinitialisation du dictionnaire quand l'historique de Rx est plein. Valide pour V.44 seulement.
4,6 0x011 Taille de chaîne illégale V.44/V.42bis Rx dépassée. Spécifie la réception d'un mot de code qui cause la taille de chaîne négociée par maximum d'être dépassée. Il est valide pour V.44 et V.42bis.
4,6 0x012 Une erreur de la négociation V.44 s'est produite spécifie une erreur de la négociation V.44 s'est produite. Pour V.44, ce code est complété par l'index diagnostique 119 de champ de l'information de liaison. L'index diagnostique de champ de l'information de liaison est une zone d'informations de huit octets utilisée comme outil pour le débogage.
4,6 0x013 Une erreur de compression V.44 s'est produite spécifie une erreur de compression V.44 s'est produite. Pour V.44, ce code est complété par l'index diagnostique 119 de champ de l'information de liaison. L'index diagnostique de champ de l'information de liaison est une zone d'informations de huit octets utilisée comme outil pour le débogage.
Conditions signalées par DSP (classe 1)
  0x1xx États DSP signalés par SPE
3,4,5 0x100 Le DSP a perdu le signal de porteuse. C'est-à-dire, le MICA a détecté une baisse de transporteur de modem client. Cette raison de débranchement se produit pendant l'établissement d'appel et le mode Données (c'est-à-dire, 0x6100, 0x8100, et 0xA100). Le MICA DSP a arrêté entendre le transporteur pendant une période plus grande que la valeur spécifique dans le registre S10 (retard d'arrêt imprévu après la perte de transporteur). Ceci peut signifier que le chemin vocal est parti ou que le client a arrêté la transmission. Si un protocole de la couche II (V.42 et/ou V.42bis) est en vigueur, il serait anormal pour voir un tel débranchement. Cette raison de débranchement se produit parfois pendant la négociation EC (avant mode Données). C'est-à-dire, la couche I a été avec succès négociée (ayant pour résultat une détection de signal de porteuse) et la déconnexion se produit tout en essayant d'établir le protocole de la couche II (V.42 et/ou V.42bis). Les causes classiques sont des utilisateurs abandonnant l'appel avant qu'une connexion ait lieu. Composition fortuite, débuts abandonnés, et applications cliente chronométrant en raison de la prise trop longue pour se connecter (par exemple, recyclages de multiple pendant la négociation de couche I). Ce type de décomptes de pannes contre le CSR. L'état perdu par transporteur peut également se produire pendant le mode Données normal quand le client relâche abruptement le transporteur. La cause classique est non-négociée ou une déconnexion non standard de la part du modem client (c'est-à-dire, le modem client relâche juste le signal de porteuse). Ceci peut se produire si le lien est abruptement abandonné (c'est-à-dire, erreur réseau), l'alimentation du modem client est coupé pour déconnecter l'appel. Ceci peut également se produire avec des modems client meilleur marché qui n'implémentent pas les protocoles clairs-vers le bas de la couche I et/ou de la couche II relatif à une suppression DTR. Pour un grand nombre de modems client, ceci est considéré une déconnexion normale. Quand le modem client fait une déconnexion non standard, une condition de compétitivité existe entre 0xA103, 0xA100, et 0xDF06. Si le DSP dans le modem d'hôte détecte une perte de transporteur, 0xA100 gagne et est indiqué pendant que la raison de débranchement. Si le DSP ne détecte pas une perte et des recyclages de transporteur jusqu'à ce qu'il frappe la limite du registre S40, alors 0xA103 gagne. Si le réseau le détecte que l'appel a été déconnecté et signale le routeur pour déconnecter, alors 0xDF06 gagne. Cette raison de débranchement ne compte pas contre le CSR quand le modem d'hôte est dans le mode Données.
3 0x101 Ceci se produit quand le processeur de signal (fournisseur de services) est dans la réponse de retour modifient la tonalité une phase de la détection (ABT) où l'échec d'appel se produit.
3 0x102 Échec d'appel pendant la série de modem vers le haut d'en raison de la modulation incompatible ou de la mauvaise ligne. Cette raison de débranchement se produit pendant l'appel setup(0x6102). Ceci peut être indicatif des tentatives de négocier une modulation non vérifiée telle qu'un Rockwell existant modulation(K56Plus, V.FC de propriété industrielle, et ainsi de suite). D'autres causes possibles sont série- de pannes DSP due aux affaiblissements graves des lignes, bruits impulsifs, formation de interruption, paramètres de modulation incompatible, et peut-être l'incapacité de sélectionner correctement une norme de la couche I. Ce type de comptes de déconnexion contre le CSR.
4,5 0x103 Trop de resynchronisations consécutives ou de vitesse-shifts. La limite de recyclage est spécifiée avec le registre S40. Cette raison de débranchement se produit pendant l'établissement d'appel et le mode Données (0x6103, 0x8103, et 0xA103). Pendant la progression d'un appel, trop de recyclages se sont produits qui ont rendu l'appel inefficace puisque le débit de données serait si pauvre quant à soit inutile. Les conditions possibles sont où le modem client ne se termine pas le protocole clair-vers le bas (par exemple, la compagnie de téléphone a démoli l'appel au milieu de la connexion) et des tentatives de MICA de récupérer l'appel en émettant des recyclages. Une fois la limite de recyclage est atteinte (la limite de recyclage peut être modifiée utilisant le registre S40), MICA relâche l'appel et signale cette raison de débranchement. Dans certaines circonstances (T1/E1 canalisé) ce type de débranchement peut être considéré un débranchement équilibré normal. alternativement, ceci pourrait simplement être le résultat d'une déconnexion non standard due à la ligne erreurs possible de la laquelle le MICA ne peut pas récupérer. Par conséquent, ce type de déconnexion ne compte pas vers le CSR puisque l'appel est déjà établi. Cette raison de débranchement peut également se produire pendant la négociation EC quand le modem client est terminé agressif avec du débit de connexion initiale et ne peut pas mettre à jour l'appel (comme observé avec de vieux modems client d'USRobotics). Ce type de déconnexion compte contre le CSR. Quand le modem client fait une déconnexion non standard, une condition de compétitivité existe entre 0xA103, 0xA100, et 0xDF06. Si le processeur de signaux numériques (DSP) dans le modem d'hôte détecte une perte de transporteur, 0xA100 gagne et est indiqué pendant que la raison de débranchement. Si le DSP ne détecte pas une perte et des recyclages de transporteur jusqu'à ce qu'il frappe la limite du registre S40, alors 0xA103 gagne. Si le réseau le détecte que l'appel a été déconnecté et signale le routeur pour déconnecter, alors 0xDF06 gagne. Cette raison de débranchement ne compte pas contre le CSR quand le modem d'hôte est dans le mode Données.
3 0x104 Problème détectant la fin de la réponse câblée Tone(ABT). Panne ou bruit excessif de négociation pendant la formation V.34. Les Modems d'hôte répondent et envoient à V.8bis et la réponse 2100Hz modulée de retour modifie la tonalité (ABTs) avec des inversions de phase, mais le bruit excessif de rencontre pendant l'ordre d'apprentissage. Recherchez les erreurs sur le chemin du modem appelant au modem de réponse dans chacun de directions. Le comportement semblable se produit quand il y a de latence dans le réseau téléphonique public commuté (PSTN) pour l'appel qui dépasse une seconde et rend les Modems s'exercer vers le haut des annuleurs d'écho. D'autres causes possibles sont :
  • Les niveaux de puissance de l'effectif TX sont incorrects et les tonalités ne sont pas alors manipulées par le côté distant.
  • Il y a trop de bruit excessif dans la phase III et IV pendant la formation V.34.
  • Il y a erreur d'opérateur.
  • Il y a interférence de réseau pendant la formation V.34 (quelqu'un prend l'extension).
Ce type de comptes de débranchement contre le CSR.
3 0x105 L'exécution SS7/COT (test de continuité) s'est terminée avec succès cette raison de débranchement se produit pendant l'établissement d'appel (0x6105). L'exécution SS7/COT (test de continuité) a été terminée avec succès.
3 0x106 Échec de l'opération SS7/COT (test de continuité) : Délai d'attente T8/T24 attendant la tonalité en fonction. Cette raison de débranchement se produit pendant l'établissement d'appel (c'est-à-dire, 0x6106). L'exécution SS7/COT (test de continuité) a manqué parce que le temporisateur T8/T24 a chronométré tout en attendant la tonalité en fonction.
3 0x107 Échec de l'opération SS7/COT (test de continuité) : Délai d'attente T8/T24 attendant la tonalité hors fonction. Cette raison de débranchement se produit pendant l'établissement d'appel (0x6107). L'exécution SS7/COT a manqué parce que le temporisateur T8/T24 a chronométré tout en attendant la tonalité hors fonction.
4 0x108 Modem sur le cleardown de l'attente (MOH) par le MICA. Le modem sur la demande de Cleardown d'attente a été reçu du modem client. V.92 spécifie que la raison de cleardown peut être :
  • Cleardown dû à l'appel entrant.
  • Cleardown dû à l'appel sortant.
  • Cleardown dû à autre raison.
4 0x109 Modem sur la valeur du dépassement de durée de l'attente (MOH) atteint.
L'EC locale conditionne (classe 2)
  0x2xx États locaux EC
3 0x201 N'a jamais reçu une trame de la LR (demande de lien) pendant la négociation. Cette raison de débranchement se produit pendant l'établissement d'appel (c'est-à-dire, 0x6201). Ceci signifie que le modem d'hôte n'a jamais reçu la trame de la LR pendant la négociation de correction des erreurs. Le modem homologue peut ne pas prendre en charge MNP dans V.42.
3 0x202 A reçu une trame de la LR avec un mauvais paramètre (PARAM1). La trame reçue de demande de lien MNP (LR) a eu un mauvais ou inattendu PARAM1. Pour plus d'informations sur PARAM1 référez-vous à la spécification V.42.
3 0x203 A reçu une trame incompatible de la LR (demande de lien). Cette raison de débranchement se produit pendant l'établissement d'appel (0x6203). La trame reçue de la LR MNP est incompatible avec les configurations du modem d'hôte pour l'EC.
4,5 0x204 Trop de retransmissions consécutives. Cette raison de débranchement se produit pendant l'établissement d'appel et le mode Données (0x8204, 0xA204 et 0x6204). Cette raison de débranchement peut sont provoqué par par bruit sur la ligne. Par exemple, le modem d'hôte transmet des données au modem client, mais le bruit sur la ligne cause les données d'être reçues inexactement (ou pas du tout) par le côté client. Ainsi le bruit excessif peut mener aux retransmissions excessives. Le modem client pourrait également avoir déconnecté sans modem MICA réalisant ceci. Ainsi le modem d'hôte le retransmet continuellement, sans savoir que le modem client n'est plus présent. Parfois, quand l'appel se connecte dans un protocole du compactage d'erreur (l'EC) (procédure de Link Access pour Modems (LAPM) ou protocole de réseau de Microcom (MNP)), le MICA ne peut pas transmettre une trame au modem client. Le modem client ne reconnaît pas la transmission initiale du MICA, puis ne répond pas (limite de correction d'erreurs de retransmission) aux balayages S19 (le par défaut est 12), ainsi le MICA déconnecte l'appel. Une cause peut être que le transporteur dans le chemin de transmission dégradé sensiblement tandis que le client ne rétrogradait pas. Une autre cause pourrait être un problème avec l'engine EC du client (comme se produirait sur un système de Winmodem si Windows cesse de répondre).
6,7 0x205 Temporisation d'inactivité, débranchement de lien MNP (LD) envoyé. Cette raison de débranchement se produit pendant le mode Données (0xC205 et 0xE205). Le modem d'hôte envoie au modem client une trame LD indiquant qu'une temporisation d'inactivité s'est produite.
4,5 0x206 Erreur de protocole EC. Cette raison de débranchement se produit pendant le mode Données (0x8206 et 0xA206). C'est une erreur de protocole générale de fourre-tout. Il indique qu'une erreur de protocole EC LAPM ou MNP s'est produite.
3 0x210 Aucun protocole de repli EC disponible. Cette raison de débranchement se produit dans l'établissement d'appel (0x6210). La négociation de correction des erreurs n'a pas été réussie. L'appel est terminé parce qu'il n'y a aucun protocole de repli sur correction des erreurs disponible. le S-registre S25 (retour du protocole de communication) détermine le protocole de repli disponible. Les options sont tramage asynchrone, tramage synchrone, ou débranchement (raccrocher).
3 0x211 Trame non jamais reçue de l'identification d'échange (XID) pendant la négociation. Cette raison de débranchement se produit pendant l'établissement d'appel (0x6211). Ceci signifie que le modem d'hôte n'a jamais reçu le trame xid pendant la négociation de correction des erreurs. Le modem client peut ne pas prendre en charge LAPM dans V.42.
3 0x212 Le trame xid reçu est incompatible avec les configurations locales. Cette raison de débranchement se produit dans l'établissement d'appel (0x6212). Le trame xid reçu est incompatible avec les configurations du modem d'hôte. Par exemple, le modem client peut indiquer MNP5, tandis que le modem d'hôte indique V.42 et V.42bis seulement.
3,4,5 0x220 Trame reçue de débranchement (DISQUE). C'est le débranchement normal LAP-M. Cette raison de débranchement se produit pendant l'établissement d'appel et le mode Données (0x 6220, 0x8220, et 0xA220). L'appel s'est terminé normalement avec un bas clair approprié du côté client. (c'est-à-dire, un paquet du débranchement V.42 a été envoyé du modem client au modem de NAS.). Le modem client a relâché le DTR et a proprement négocié un protocole clair-vers le bas.
3,4,5 0x221 Trame reçue DM. Le pair déconnecte probablement. Cette raison de débranchement se produit dans l'établissement d'appel et le mode Données (0x6221, 0x8221, et 0xA221). Le modem client indique qu'il déconnecte. Pendant l'établissement d'appel, cette raison indique que le modem client abandonne sur la correction d'erreurs de négociation.
4,5 0x222 A reçu un mauvais numéro de séquence. Cette raison de débranchement se produit dans le mode Données (0x8222 et 0xA222). Le modem d'hôte a reçu une trame de correction des erreurs LAPM ou MNP avec un mauvais nombre de numéro de séquence ou d'accusé de réception. Une trame LD ou de rejet de trame (FRMR) est envoyée au modem client indiquant que le modem d'hôte déconnecte.
4,5 0x223 Trame reçue SABME dans équilibré. Cette raison de débranchement se produit dans le mode Données (0x8223 et 0xA223). Ceci est interprété comme erreur du protocole de correction des erreurs LAPM dans équilibré. Il signifie que le modem client a pu avoir remis à l'état initial en raison de recevoir un rejet de trame (FRMR).
4,5 0x224 Trame xid reçu MNP dans équilibré. Cette raison de débranchement se produit dans le mode Données (0x8224 et 0xA224). Ceci est interprété comme erreur du protocole de correction des erreurs LAPM dans équilibré. Il signifie que le modem client a pu avoir remis à l'état initial en raison de recevoir un rejet de trame (FRMR).
4,5 0x225 Trame reçue de la LR MNP tandis que dans équilibré. Cette raison de débranchement se produit dans le mode Données (0x8225 et 0xA225). Ceci est interprété comme erreur du protocole de correction des erreurs MNP dans équilibré. Il signifie que le modem client a remis à l'état initial.
États spécifiques PIAFS Protocol (Classe 2, continu)
3,4 0x230 Un message reçu est plus court que la longueur définie par minimum pour ce type de message.
3,4 0x231 Type de trame inconnu ou unimplemented PIAFS reçu. Ceci inclut le fi (principal type de trame), et classe négocie, de sync ou de contrôle (sous-type).
3,4 0x232 Identifiant inconnu de trame de contrôle PIAFS (TPI). Une trame de contrôle a été reçue avec un ID inconnu ou unimplemented pour sa classe. Notez que les trames continues et d'utilisateur sont unimplemented, et qu'il n'y a aucune trame connue de notification.
3,4 0x233 La négociation de transmission PIAFS a manqué. Après synchronisation initiale, des trames de Req de paramètre de transmission/ACK sont permutées. L'un ou l'autre les paramètres étaient inacceptables, ou le demandeur a détecté une réponse NAK (Negative Acknowledgment).

Remarque: Le MICA peut seulement fonctionner en tant qu'un client/demandeur afin de tester

3,4 0x234 La négociation PIAFS ARQ a manqué. Après resynchronisation, des trames de demande ARQ (Req) /Acknowledgment (ACK) sont permutées. L'un ou l'autre les paramètres étaient inacceptables, ou le demandeur a détecté une réponse NAK.

Remarque: Le MICA peut seulement fonctionner en tant qu'un client/demandeur afin de tester

3,4 0x235 Problèmes de Transfer Protocol de contrôle PIAFS détectés. Le demandeur a reçu un ACK/NAK/Rsp dont ID, classe et l'ordre n'a pas apparié l'original Req/Ntf.

Remarque: Le MICA peut seulement fonctionner en tant qu'un client ou demandeur afin de tester

3,4 0x236 Cette raison de déconnexion n'indique plus la réception d'une trame de demande de DataLinkRelease. Il indique maintenant un débranchement sans raison de débranchement précédemment étant générée. Ceci signifie que le MICA déconnecte un appel, mais des découvertes qu'aucune raison n'a été signalée.
3,4 0x237 Le temporisateur d'attente de réception de sync PIAFS (T001) a expiré. Les débuts de ce temporisateur quand une trame de demande synchrone est envoyée, et lui arrête quand une trame de synchronisation-réception est détectée. Cette erreur se produira seulement quand le port MICA fonctionne en tant qu'un client ou demandeur, qui se produisent seulement pendant le test. La valeur par défaut est de 15 secondes.
3,4 0x238 Le temporisateur T002 de réception-transmission de POST-sync PIAFS a expiré. Les débuts de ce temporisateur quand une trame de synchronisation-réception est envoyée, la poncent arrête quand une synchronisation-réception (cas de collision) ou une trame de contrôle est détectée. Cette erreur se produira seulement quand le port MICA fonctionne en tant que serveur (mode réponse), qui est le mode de fonctionnement normal. La valeur par défaut est de 15 secondes.
3,4 0x239 Le temporisateur T003 d'attente de demande de sync PIAFS a expiré. Les débuts de ce temporisateur quand des erreurs continues FCS sont détectées, et lui arrête quand une trame de demande synchrone valide est détectée. Cette erreur se produira seulement avec le port MICA fonctionne en tant que serveur (mode réponse), qui est le mode de fonctionnement normal. La valeur par défaut est de 15 secondes.
3,4 0x23A Le temporisateur T101 PIAFS a expiré : contrôlez le temporisateur d'attente de confirmation de trame. Les débuts quand la demande ou la notification de trame de contrôle est envoyée, arrête quand la trame est confirmée. Cette erreur se produira seulement quand le port MICA fonctionne en tant qu'un client ou demandeur, qui se produisent seulement pendant le test (dix secondes).
3,4 0x23B PIAFS : FBI reçu (ordre ACK #) hors de plage négociée, ou FBI=0 reçu avec une trame de données non vide.
3,4 0x23C PIAFS : FFI reçu (ordre MSG #) hors de plage négociée, ou FFI=0.
3,4 0x23D PIAFS : la fenêtre négociée de données est moins que la valeur RTF (délai d'aller-retour). Cette erreur n'est plus signalée par Portware, et devrait ne jamais être vue.
3,4 0x23E PIAFS : le champ de la longueur des données du message est trop grand. Devrait être 0-73.
3,4 0x23F Erreur interne PIAFS : L'appel SREJ a renvoyé code d'erreur.
3,4 0x240 Erreur de protocole général PIAFS. C'est un fourre-tout pour les erreurs qui n'ont pas une raison associée de débranchement.
3,4 0x241 PIAFS : la négociation de protocole a manqué. Aucun protocole (par exemple, vitesse fixe de Protocol de transfert des données, type 1 variable de vitesse DTP) ne semblait acceptable aux deux stations. Les protocoles inacceptables seraient la vitesse variable Type3 DTP, ou le Protocol en temps réel.
3,4 0x242 PIAFS : la valeur mesurée RTF (délai d'aller-retour) n'était pas dans la plage (acceptable) définie.
3,4 0x243 Erreur interne PIAFS : événement inconnu dans le gestionnaire d'événement. Une déclaration de commutateur est tombée dans son cas par défaut.
3,4 0x244 La temporisation de réponse de processeur de signal (fournisseur de services) s'est produite pendant un speedshift PIAFS 2.1. Le CP du mica n'a pas vu la réponse de modification de vitesse dans un délai de 200 millisecondes.
3,4 0x245 Le CP du mica a vu l'information de contrôle contradictoire dans les structures de gestion partagées par CP/SP. En particulier, le tampon de données a eu une tête ou la queue compensée qui était en dehors du tampon de données bondit (0-63).
Mauvaise commande reçue MNP ou LAPM Protocol du partenaire (classe 3)
4.5 0x3xx Mauvais code opération détecté parEC. La commande inconnue reçue est dans les deux derniers chiffres. La trame d'un rejet de trame MNP LD ou LAP-M (FRMR) est introduite la réponse.
Le partenaire LAPM indique l'erreur de protocole MICA (classe 4)
4,5 0x4xx États EC indiqués par le client dans la trame LAP-M FRMR. La raison établie une correspondance de bits est dans les deux derniers chiffres.
4,5 0x401 LAPM : le pair signale la mauvaise commande. Le modem d'hôte a reçu une trame FRMR du modem client. La trame reçue FRMR indique que le modem client a reçu une trame de correction des erreurs du modem d'hôte qui a contenu une mauvaise commande.
4,5 0x403 LAPM : états de pair que la zone d'information n'est pas permise ou est longueur incorrecte (trames U). Le modem d'hôte a reçu une trame FRMR du modem client. La trame reçue FRMR indique que le modem client a reçu une trame de correction des erreurs du modem d'hôte qui a contenu une zone d'information qui n'est pas permise ou a contenu une zone d'information avec une longueur incorrecte (trame U).
4,5 0x404 LAPM : la longueur du champ de données d'états de pair est plus grande que N401 (la longueur de zone d'informations maximum spécifiée dans V.42), mais a le bon contrôle Sequence(FCS) de vue. Le modem Nextport a reçu une trame FRMR du modem client. La trame reçue FRMR indique que le modem client a reçu une trame de correction des erreurs du NextPort qui a contenu une longueur du champ de données qui est plus grande que le nombre maximal d'octets qui peuvent être portés dedans la zone d'informations (N401) d'une trame I, d'une trame SREJ, d'un trame xid, d'une trame UI, ou d'une trame de test. Le Frame Check Sequence est bon.
4,5 0x408 LAPM : le pair signale le mauvais reçoivent le numéro de séquence ou le N (R). Le modem d'hôte a reçu une trame FRMR du modem client. La trame reçue FRMR indique que le modem client a reçu une trame de correction des erreurs du modem d'hôte qui a contenu un mauvais reçoivent le numéro de séquence.
Le partenaire MNP indique le débranchement ou l'erreur de protocole MICA (classe 5)
4,5 0x5xx États EC indiqués par le client dans la trame MNP LD. Le champ de raison est dans les deux derniers chiffres
3 0x501 MNP : le pair n'a jamais reçu la trame de la LR. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique que le modem client n'a jamais reçu une demande de lien du modem d'hôte.
3 0x502 MNP : la trame de la LR d'états de pair a le mauvais paramètre #1. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique que le modem client a reçu une trame de demande de lien du modem d'hôte qui a contenu un mauvais (c'est-à-dire, inattendu) PARAM1. Pour plus d'informations sur PARAM1 référez-vous à la spécification V.42.
3 0x503 MNP : la trame de la LR d'états de pair est incompatible avec sa configuration. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique que le modem client a reçu une trame de la LR du modem d'hôte qui est incompatible avec le modem client, configuration s.
4,5 0x504 MNP : le pair signale trop de retransmissions consécutives EC. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique que le modem client a reçu trop de retransmissions consécutives.
4,5 0x505 MNP : le pair signale le temporisateur d'inactivité a expiré. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique que le modem client ? hasn de l'hôte s (DTE) ? t a passé des données au modem client au cours d'une période.
3 0x506 MNP : le pair signale l'erreur. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique que le modem client a reçu une erreur de protocole MNP.
3 0x5FF Débranchement normal MNP. Le modem d'hôte a reçu une trame LD du modem client. La trame reçue LD indique un arrêt normal MNP, indiquant que le DTR du modem client abandonné ou qu'elle a reçu un +++ ou la commande ATH. Cette raison de débranchement se produit dans l'établissement d'appel et le mode Données (0x65FF, 0x85FF, et 0xA5FF). Le modem d'hôte a reçu un LD, qui indique l'arrêt normal. L'appel s'est terminé normalement avec un bas clair approprié du côté client (par exemple, un paquet de débranchement a été envoyé du modem client au modem d'hôte). Le modem client a relâché le DTR et a proprement négocié un protocole clair-vers le bas.
Le partenaire PIAFS indique le débranchement ou l'erreur de protocole MICA (classe 6)
3,4 0x6xx Le MICA a reçu un PIAFS DataLinkRelease (PDLR) avec la raison xx (voir les valeurs détaillées ci-dessous).
3,4 0x61x Classe normale pour PIAFS DataLinkRelease (PDLR) : 0 - Release normale. 1 - Release normale, continuation de connexion logique interdite. 2 - Release normale, continuation de connexion logique. … L'autre normale classe - les classes non définies particulières à quelques périphériques de client.
3,4 0x62x Classe non possible d'utilisation de ressource pour le DOLLAR PIAFS (conditions occupées) : 8 - DTE occupé. 9 - Obstacle provisoire. … D'autres classes non possibles d'utilisation de ressource - classes non définies particulières à quelques périphériques de client.
3,4 0x63x Entretenez la classe non possible d'utilisation pour le DOLLAR PIAFS (mauvais paramètres). 9 - Définition du paramètre de demande non possible. A - Définition du paramètre de demande non possible actuellement. D'autres classes non possibles d'utilisation de service - classes non définies particulières à quelques périphériques de client.
3,4 0x64x Entretenez la classe pas encore fournie pour le DOLLAR PIAFS. 1 - Indication de paramètre pas encore fournie. … D'autres classes pas encore fournies de service - classes non définies particulières à quelques périphériques de client.
3,4 0x65x Classe de contenu d'informations non valides pour le DOLLAR PIAFS. 8 - Attribut terminal non apparié. … L'autre contenu d'informations non valides classe - les classes non définies particulières à quelques périphériques de client.
3,4 0x66x Catégorie d'erreur d'ordre pour le DOLLAR 0 PIAFS - paramètres essentiels insuffisants. 1 - Contenu de l'information éliminé ou pas encore fourni. 5 - État et signal ARQ non appariés. 6 - Le temporisateur expire. … D'autres catégories d'erreur d'ordre - classes non définies particulières à quelques périphériques de client.
3,4 0x67x L'autre classe de particularités pour le DOLLAR PIAFS. 1 - Pendant la communication voix. … D'autres autres classes particulières ont éliminé des classes particulières à quelques périphériques de client.
Débranchement demandé par Host/IOS (classe 31)
6,7 0x1fxx Débranchement initié par hôte. La valeur est une somme de 0x1F00 et de valeur de SessionStopCommand. C'est l'autre hôte terminent la raison. La raison d'hôte est indiquée dans les octets d'ordre réduit xx.
3,6,7 0x1f00 Débranchement initié par hôte non spécifique. La valeur est une somme de 0x1F00 et de valeur de SessionStopCommand. C'est la raison de débranchement initiée par IOS de fourre-tout. Il est utilisé pour tous les débranchements non standard. Par exemple, ceci a pu être un résultat de logiciel de gestion de modems décidant de terminer l'appel. Une explication possible est un RAYON de plus haut niveau d'échec d'authentification, un TACACS, ou une application différente fournissant une suppression DTR au modem d'hôte. Ce type de débranchement ne comptera pas vers le CSR quand le modem d'hôte est dans le mode Données.
3 0x1f01 Le numéro composé était occupé. La déconnexion s'est produite parce que 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 parce que l'hôte indique que le numéro composé n'a pas répondu.
3,6,7 0x1f03 DTR virtuel relâché. Cet état est reflété de la redirection de port d'I/O qui utilise actuellement le modem. La déconnexion s'est produite parce que l'hôte a relâché la ligne virtuelle DTR. Cette cause générique de débranchement est initiée par le logiciel de Cisco IOS. Les causes possibles sont délai d'attente de veille, le PPP LCP TERMREQ reçu, échec d'authentification, raccrocher de telnet, et ainsi de suite. Pour déterminer la raison pour le coup, examinez le motif de la déconnexion RADIUS de la commande laconique de modem call-record ou de l'Authentification, autorisation et comptabilité (AAA).
6,7 0x1f04 La commande ATH (raccrocher) a été détectée par l'hôte local.
3 0x1f05 Aucun accès au réseau de l'opérateur de téléphonie. La déconnexion s'est produite parce que l'hôte ne pourrait pas accéder au réseau (le RNIS).
3,4,5, 0x1f06 Débranchement indiqué par réseau. Ceci peut se produire l'un ou l'autre avant ou pendant le mode Données. Un débranchement 0x1f06 signifie que l'IOS a reçu un signal de raccrocher de circuit du réseau de circuit (c'est-à-dire, un débranchement Q.931 ou un signal d'onhook de CAS), et l'IOS puis a communiqué ceci au MICA quand il a demandé au MICA de raccrocher. Si le MICA atteint le mode Données et un protocole EC (LAPM ou MNP4) n'était pas négocié, alors ceci pourrait être un débranchement normal. Cette raison peut également être générée quand les utilisateurs du Windows 95 ou de l'appel 98 le réseau (BRUN GRISÂTRE) frappent l'annulation pendant le trainup et avant que l'appel atteigne équilibré. En outre, si le client devaient abruptement débrancher la ligne téléphonique/arrêtent le modem, puis cette raison de débranchement serait considéré normal. Cependant, si la connexion a négocié l'EC (LAPM ou MNP4), et par conséquent dans le mode Données, puis cette raison de débranchement pourrait être généré par une déconnexion non standard (c'est-à-dire, une déconnexion qui n'est pas une terminaison d'appel gracieuse). C'est dû au fait que si le client DTE (dans le mode Données) déconnecte l'appel d'une manière ordonnée (avec la suppression DTR ou le +++/ATH), alors le modem client nous enverra un DISQUE LAPM (ou MNP LD) avant qu'il disparaisse l'onhook, de ce fait générant une raison 0x220 de débranchement plutôt que 0x1f06. Ainsi le débranchement indiqué par réseau est, dans ce cas, probablement indicatif d'un modem client malheureux, un qui a décidé qu'il pourrait plus ne soutenir le transporteur pour quelque raison.
3 0x1f07 Le NAS a terminé l'exécution SS7/COT. La déconnexion s'est produite parce que le NAS a terminé l'exécution SS7/COT (test de continuité).
3 0x1f08 L'exécution SS7/COT a été terminée 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ébranchement quand il reçoit un message de terminaison non sollicité.

Raison de débranchement : Types

La raison de débranchement : les types décrit quand le débranchement d'appel s'est produit réellement. Ils peuvent être classés par catégorie dans deux types principaux : pendant l'établissement d'appel et pendant le mode Données (équilibré). Le tableau suivant spécifie les types de raison de débranchement les plus communs et leurs valeurs comme indiqué dans la raison de débranchement.

Type de débranchement Type de débranchement (hexa) Description
0 0x0… (inutilisé)
1 0x2… (inutilisé)
2 0x4… D'autres situations.
3 0x6… La condition s'est produite pendant l'établissement d'appel.
4 0x8… Dans le mode Données. Données de Rx (ligne à héberger) vidant CORRECT. L'état de débranchement s'est produit dans le mode Données. Tentatives de MICA de fournir toutes données reçues à l'hôte (IOS). Pour quelques débranchements (par exemple, PIAFS), c'est le seul type de mode Données utilisé ; aucune indication n'est faite en direction vidante de données.
5 0xA… Dans le mode Données. Données de Rx (ligne à héberger) vidant PAS CORRECT. L'état de débranchement s'est produit dans le mode Données. Tentatives de MICA de fournir toutes données reçues à l'hôte (IOS). En code MICA traditionnel, ce type est équivalent au type 4 ci-dessus. Bien que l'IOS affiche des débranchements tels que NON CORRECTS, problème ne s'est pas posé réellement.
6 0xC… Dans le mode Données. Données TX (hôte à rayer) vidant CORRECT. L'état de débranchement s'est produit dans le mode Données. Les tentatives de MICA de transmettre ont mis en mémoire tampon des données de l'hôte (IOS) au modem associé.
7 0xE… Dans le mode Données. Données TX (hôte à rayer) vidant PAS CORRECT. L'état de débranchement s'est produit dans le mode Données. Les tentatives de MICA de transmettre ont mis en mémoire tampon des données de l'hôte (IOS) au modem associé. En code MICA traditionnel, ce type est équivalent au type 6 ci-dessus. Bien que l'IOS affiche des débranchements tels que NON CORRECTS, problème ne s'est pas posé réellement.


Informations connexes


Document ID: 5135