MICA-Modemstatus und Trennungsgründe

Einführung

In diesem Dokument wird beschrieben, wie die von Cisco Modem ISDN Channel Aggregation (MICA)-Modems gemeldeten Ursachencodes für Anrufe interpretiert werden.

Hinweis: Dieses Dokument enthält viele Begriffe, die in den ITU-Standards wie V.90, V.44, V.42bis und V.34 definiert sind. Weitere Informationen zu diesen Bedingungen finden Sie im entsprechenden ITU-T -Standard. Die in den ITU-T-Standards angegebenen Begriffe werden in diesem Dokument nicht erläutert.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten Folgendes berücksichtigen:

Wenn ein Anruf, der die MICA-domänenspezifischen Teile (DSPs) verwendet, gelöscht oder getrennt wird, zeichnet MICA den Grund für die Trennung auf. Anhand dieses Grundes können Sie feststellen, ob die Verbindung normal getrennt wurde. Wenn nicht, können Sie damit die möglichen Fehlerquellen ermitteln. Modems können aufgrund verschiedener Faktoren getrennt werden, z. B. durch Client-Disconnects, Telco-Fehler und Anrufverluste auf dem Netzwerkzugriffsserver (NAS). Ein typischer Trennungsgrund besteht darin, dass das DTE (Client-Modem oder NAS) an einem Ende das Gerät abschalten möchte. Solche "normalen" Unterbrechungen deuten darauf hin, dass die Trennung nicht auf Modem- oder Übertragungsebenenfehler zurückzuführen ist. Weitere Informationen zum Bestimmen, ob ein Trennungsgrund normal ist, finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität.

Verwendete Komponenten

MICA-Modems werden in den folgenden Access-Servern verwendet:

• Cisco Router der Serie 3600

• AS5200

• AS5300

• AS5800

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Bestimmen des Modemstatus

Verwenden Sie den Befehl show modem log slot/port, um den aktuellen Status eines MICA-Modems zu ermitteln. In dieser Protokollausgabe treten die letzten Einträge am Ende des Protokolls auf. Der aktuelle Status des MICA-Modems wird im letzten Modemstatus (Change) angezeigt. In der unten gezeigten Beispielausgabe ist der Modemstatus inaktiv. Der Status des Modems wird durch das 00:00:28 gestempelte Modem State Event angezeigt. Weitere Informationen zu den möglichen MICA-Modemzuständen finden Sie in der MICA-Modemzustandstabelle.

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

Bestimmen des Trennungsgrunds

Wenn eine Modemverbindung beendet wird, meldet das NAS-Gerät zwei Trennungsgründe: Gründe für DTE (IOS) und Gründe für DCE (MICA). Diese Trennungsgründe können mit drei primären Methoden gemeldet werden:

1. Modem-Anrufaufzeichnungen: Diese Berichte enthalten Informationen zur Trennung der IOS®-Software und des MICA-Modems.

2. AAA-Accounting-Protokolle: Diese Berichte enthalten nur den Grund für die Trennung der IOS-Software.

3. IOS-Befehle: Befehle wie Anzeigen des Modembetriebs und Anzeigen des Modemprotokolls melden nur den Grund für die Trennung des MICA-Modems.

Modemanrufaufzeichnungen

Der Grund für die Trennung von IOS und Modem für eine bestimmte Verbindung wird im Modem Call Record (MCR) angezeigt. Der MCR wird beim Beenden jedes Anrufs vom NAS an einen Syslog-Server gesendet. Die Anrufaufzeichnungen für Modems wurden in Version 11.3AA und 12.0T der Cisco IOS-Software eingeführt und (auf dem NAS) mithilfe des Befehls Modem Call Record terse aktiviert. Weitere Informationen zur Implementierung von Modem-Anrufaufzeichnungen finden Sie im Dokument Using Syslog, NTP and Modem Call Records (Verwenden von Syslog, NTP und Modem Call Records), um Fehler zu isolieren und zu beheben.

Im unten gezeigten Modem-Anrufprotokoll lautet der IOS-Trennungsgrund, der durch disk(radius) angegeben ist, Lost Carrier/Lost Carrier, während der durch disk(modem) angegebene Modem-Trennungsgrund lautet:

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

In der Tabelle Gründe für die Trennung des Mikromodems finden Sie weitere Informationen zur Interpretation des Modem-Trennungsgrunds.

*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

AAA-Accounting-Protokolle

Die AAA-Accounting-Protokolle können auch verwendet werden, um den IOS-Trennungsgrund zu ermitteln. In der unten stehenden AAA sql-Beispielabfrage wird die Ursache für die Radiustrennung angezeigt:

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

Der Trennungscode (disk-Cause=4) im obigen Beispiel gibt an, dass die Verbindung durch das Auslaufen der Leerlaufzeit getrennt wurde.

Hinweis: Die AAA-Abrechnungsprotokolle zeigen den Grund für die Verbindungstrennung nicht an, daher kann die in diesem Dokument bereitgestellte Tabelle nicht zur Interpretation des RADIUS disconnect-Grundes verwendet werden.

Weitere Informationen zur Implementierung von AAA-Accounting finden Sie im Dokument Implementing Server-Based AAA Accounting.

Das Fenster zeigt den Betriebsstatus des Modems an und zeigt die Modemprotokollbefehle an.

Die IOS-Befehle zeigen den Steckplatz/Port des Modems bzw. den Steckplatz bzw. Port des Modemprotokolls an, um den Grund für die Verbindungstrennung zu ermitteln.

Die Ausgabe dieses Befehls zeigt an, warum die Verbindung verloren gegangen ist oder warum die aktuelle Verbindung nicht das ist, was Sie erwarten. Erklärungen zu den verschiedenen Trennungstypen finden Sie unten in den Gründen für die Verbindungstrennung.

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.

Der Steckplatz/Port des Modemprotokolls anzeigen zeigt auch den Grund für die Verbindungstrennung an.

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

Trennungsursachenformat

Ein Trennungsgrund besteht aus vier Hexadezimalziffern. Die drei Hexadezimalziffern in niedriger Reihenfolge können verwendet werden, um den Trennungsgrund zu identifizieren. Die Hexadezimalziffer mit hoher Reihenfolge gibt in der Regel den Trennungsgrund oder den Zeitpunkt an, zu dem der Trennungsgrund aufgetreten ist. Diese Optionen werden im Abschnitt Disconnect-Grund beschrieben: Typen. Wenn der Grund für die Trennung beispielsweise 0xWXYZ ist, kann 0xXYZ den Grund für die Trennung identifizieren, während 0xW angibt, wann die Verbindung getrennt wurde.

In den obigen Beispielen geben 0xF03 und 0x220 den Trennungsgrund an, während 0xD und 0x8 den Grund für die Trennung angeben. Die Definitionen für die MICA-Trennungsgründe finden Sie im Abschnitt MICA Modem Disconnect GRÜNDE.

Weitere Informationen zu MICA-Modemvorgängen finden Sie in der Dokumentation Verifying Modem Performance and Modem Management Operations in der Cisco AS5x00-Fallstudie für grundlegende IP-Modemdienste.

MICA-Modemstatus

Staat	Beschreibung
IDLE (#0)	In diesem Zustand ist die Modemsitzung derzeit inaktiv. Der IDLE-Status wird vom TERMINIERUNGSstatus eingegeben, sobald der DSP überprüft hat, ob alle Vorgänge beendet wurden.
CALL_SETUP (#5)	In diesem Zustand ist der Modemsignalprozessor so vorbereitet, dass er T1, MF (Multiple Frequency), DTMF (Dual Tone Multi Frequency), R1, R2 und Anruffortschrittsignale empfängt und erzeugt. Das Modem bleibt im Status CALL_SETUP, bis es vom Host eine LINK_TERMINATE-, SOFTWARE_RESET- oder INITIATE_LINK-Nachricht empfängt.
CONNECT (Nr. 10)	Der CONNECT-Status wird nur beim Empfang des Host-Befehls Initiate aus dem Status CALL_SETUP(#5) eingegeben. Im Antwortmodus wurde in der Modemsitzung zwar eine Aktivität gestartet, aber noch nicht mit der Ausgabe eines Antworttons begonnen. Im ursprünglichen Modus hat die Modemsitzung zwar eine Aktivität initiiert, aber noch keinen Antwortton erkannt.
LINK (#15)	Der LINK-Status wird nur dann aus dem CONNECT-Status eingegeben, wenn ein Answerback Tone (Origate) erkannt oder ein Answerback Tone (Answerback Tone (Answerback Tone, Antwort) initiiert wird. Im Antwortmodus überträgt die Modemsitzung einen Antwortton an die Leitung. Im ursprünglichen Modus hat die Modemsitzung die (konfigurierbare) Mindestmenge des erforderlichen Antworttons erkannt. Dies weist darauf hin, dass ein Remote-Peer vorhanden ist.
QC (Nr. 16)	Quick Connect (QC) wird entweder aus dem LINK- oder V.8-bis-Exchange-Status eingegeben, wenn QC aktiviert ist, und beim Empfang einer QCA-Sequenz (ursprünglicher Modus) oder beim Senden einer QCA-Sequenz (Antwortmodus).
SCHULUNG (#20)	In diesem Zustand handelt die Modemsitzung den physischen Modulationsstandard (wie konfiguriert) aus, der während der Verbindung verwendet wird. Der TRAINUP-Status wird nur aus dem LINK-Status eingegeben, wenn: Erkennen des Endes eines Antworttons (Ausgangston). Abschließen der Übertragung eines Antworttons (Antwort).
EG-VERHANDLUNG (Nr. 25)	In diesem Zustand handelt die Modemsitzung das Fehlerbehebungs- und Datenkomprimierungsprotokoll aus, das während der Verbindung verwendet wird. Wenn die Einstellungen für beide Modems akzeptabel sind (Schnittpunkt der beiden Modems-Funktionen und -Konfiguration), wird eine erfolgreiche Verhandlung erreicht. Wenn die Schnittstellenkombination null ist, trennt das Modem die Verbindung oder startet eine nicht fehlerfreie verbundene Sitzung. Nach erfolgreicher Synchronisierung der physischen Modulation wird der Status EC_NEGOTIATING aus dem TRAINUP-Status eingegeben.
STEADY_STATE (#30)	In diesem Zustand kann die Modemsitzung Daten über die Verbindung weitergeben. Der Status STEADY_STATE wird aus dem Status EC_NEGOTIATING eingegeben: Nach erfolgreicher Protokollverhandlung (wie konfiguriert). Aus dem Zustand STEADY_STATE_RETRAINING und STEADY_STATE_SHIFTINGSPEED, da die physische Verbindung erfolgreich neu ausgehandelt wurde. Im Faxmodus dieser Zustand bedeutet, dass der T30-Motor läuft. Während eines Faxanrufs wird zwischen STEADY_STATE und STEADY_STATE_ESCAPE umgeschaltet. Dies ist der Faxanruf, der in den verschiedenen Phasen einer Fax-T30-Sitzung ausgeführt wird.
STEADY_STATE_RETRAINING (#35)	In diesem Zustand wird die Modemsitzung gerade neu trainiert. Der Status STEADY_STATE_RETRAINING wird aus den Zuständen STEADY_STATE oder STEADY_STATE_SHIFTINGSPEED eingegeben: Auf Host Link_Control - [Retrain]-Befehl. Indem Sie einen internen Grenzwert (konfigurierbar) überschreiten.
STEADY_STATE_SHIFTINGSPEED (#40)	In diesem Zustand verschiebt sich die Modemsitzung derzeit. Der Status STEADY_STATE_SHIFTINGSPEED wird aus dem Status STEADY_STATE eingegeben: Auf Host_Link_Control - [Fallback, Fall-Forward]. Indem Sie einen internen Grenzwert (konfigurierbar) überschreiten.
STEADY_STATE_ESCAPE (#45)	In diesem Zustand ist das Modem immer noch mit dem Remote-Peer verbunden, aber die Host-Schnittstelle befindet sich im AT-Befehlsmodus. Dieser Status wird nur nach Erhalt einer gültigen Hayes-Fluchtsequenz eingegeben. Im Faxmodus bedeutet dieser Status, dass das T30-Modul AT-Befehle vom Host akzeptiert. Informationen zu Faxanrufen finden Sie im Status STEADY_STATE (#30).
BEENDEN (#50)	In diesem Zustand versucht die Modemsitzung, Benutzerdaten zu leeren und den digitalen Signalprozessor (DSP) zu löschen. Bei einem Software_reset wird keine geordnete Leerung ausgeführt, und der DSP ist RESET. Der TERMINATE-Status wird aus einem beliebigen Zustand eingegeben: Bei LINK_TERMINATE oder Software_reset vom Host. Bei einem vom DSP verlorenen Carrier. Nach Erhalt eines ATH-Befehls von der DTE. Nach Erhalt eines DISK/LD (disconnect) Fehlerkorrektur-Frames von der Leitung. Durch Auslösen verschiedener interner Schwellenwerte (konfigurierbar).
HALTEN ( Nr. 55 )	Die Modemsitzung ist in der Warteschleife, und der Link enthält keine Daten. Der On Hold-Status wird beim Empfang der MoH-Anforderungsnachricht (MHReq) aus dem Steady State eingegeben. Wenn Modem on hold (Register S62) aktiviert ist, muss das Modem-on-Hold-Acknowledgment (MHack)-Sequenz übertragen, um die Anfrage zu senden und den Answer Back Tone (ANSam) zu übertragen, wenn Stille oder RT erkannt werden. Wenn eine Call Menu (CM)-Signalleitung (für V.8) oder eine Quick Connect Acknowley-QCA (QC - Register S63)-Sequenz im "On Hold"-Status erkannt wird, muss das Modem den "On Hold"-Status verlassen und auf die Initialisierungssequenz entsprechend den V.8- oder QC-Empfehlungen (Register S63) reagieren. Wenn nach dem definierten Wert für die Haltezeit keine Initialisierungssequenz erkannt wird, muss das Modem den Status "On Hold" (Halten) verlassen und die Verbindung trennen. Wenn das Modem in Haltestellung deaktiviert ist, muss das Modem MHnack übertragen. Wird MHcda nach dem Übertragen von MHnack erkannt, muss das Modem die Verbindung trennen. Wird MHfrr erkannt, nachdem MHnack übertragen wurde, muss das Modem Antwortback-Tone übertragen und bereit sein, CM (V.8)- oder QCA (QC - Register S63)-Sequenzen vom Remote-Modem zu erkennen. Weitere Informationen zu Modem on Hold finden Sie in den ITU-T V.92 Spezifikationen . Hinweis: Der MICA-Status #55 war früher der VOICE-Status, der nun aus den Portware-Versionen 2.9.1.0 und höher entfernt wurde.
V.8bis EXCHANGE(#71)	Dieser Zustand wird nur bei der Erkennung von CRe (ursprünglicher Modus) oder beim Starten von CRe (Antwortmodus) aus dem CONNECT-Status eingegeben. Antwortmodus: Die Modemsitzung überträgt eine Capability Request-Autoanswer (CRe) an die Leitung. Ursprungsmodus: Die Modemsitzung hat die Funktion Request-Autoanswer (CRe) erkannt. Dies weist darauf hin, dass ein Remote-Peer vorhanden ist.
RANGING(#72)	RANGING wird beim Starten des RTDEd (Round Trip Delay Estimate) aus dem Status LINK oder QC (Register S63) eingegeben. Dieser Status gilt nur für die Standards V.32 und höher.
KURZ VERÄNDERN(#73)	RANGING SHORT wird vom QC (Register S63) beim Start des Round Trip Delay Estimate-Digital Modems (RTDEd) eingegeben.
HD-ZUG(Nr. 74)	HD-ZUG (Halbduplex-Training) wird entweder von RANGING oder RANGING SHORT bei Beginn der Adaptive Filter Training eingegeben. Dies gilt für V.22bis und höher.
STEADY_STATE_PIAFS_RESYNC(#80)	Die Eingabe von STEADY_STATE_PIAFS_RESYNC weist darauf hin, dass ein PIAFS-Aufruf (Personal Handyphone Internet Access Forum Standard) nicht synchronisiert wurde und eine Resynchronisierung durchführt.
STEADY_STATE_PIAFS_SPEEDSHIFT(#85)	Die Eingabe von STEADY_STATE_PIAFS_SPEEDSHIFT weist darauf hin, dass bei einem PIAFS-Anruf eine Kurzwellenänderung verhandelt wird. Dies ist ein vorübergehender Übergangsstaat. MICA wird nie in diesem Zustand bleiben. Wenn die Resynchronisierung zu einer Geschwindigkeitsverschiebung führt, wechselt MICA von STEADY_STATE_PIAFS_RESYNC zu diesem Zustand und fährt dann zu STEADY_STATE. Wenn die Resynchronisierung NICHT zu einer Geschwindigkeitsverschiebung führt, wechselt STEADY_STATE_PIAFS_RESYNC direkt zu STEADY_STATE, wenn der Vorgang abgeschlossen ist.

Gründe für die Trennung des MICA-Modems

Ein MICA-Modem-Trennungsgrund besteht aus vier Hexadezimalziffern. Die drei Hexadezimalziffern in niedriger Reihenfolge geben den Trennungsgrund eindeutig an. Die Hexadezimalziffer mit hoher Reihenfolge gibt den Trennungsgrund oder den Zeitpunkt an, zu dem der Trennungsgrund aufgetreten ist. Im obigen Beispiel, wo der Trenncode hexadezimal 0xDF03 ist, gibt der 0xF03 den Trennungsgrund an, während 0xD angibt, wann der Trennungsgrund aufgetreten ist (Trennungsgrund: Typen).

Die im Folgenden beschriebenen Trennungsgründe schließen den Trennungstyp nicht ein. Entfernen Sie daher aus dem Grund, aus dem Sie die Verbindung trennen, die linke Hexadezimalziffer, und vergleichen Sie die verbleibenden Ziffern mit den nachfolgenden Optionen. Suchen Sie im obigen Beispiel im Abschnitt unten nach 0xF03.

Hinweis: In diesem Dokument ist das Host-Modem das MICA-Modem auf dem Cisco Access Server, während das Client-Modem das Remote-Gerätemodem ist (z. B. ein Client-PC-Modem).

Trennungstyp	Trennungsursachencode	Beschreibung
-	0	Die Verbindung wurde noch nicht getrennt. Sie sehen diesen Code, wenn der Trennungsgrund unmittelbar nach dem Laden von Portware oder während eines Anrufs abgefragt wird, bevor der Zustand stabil ist.
Allgemeine Trennungsgründe (Klasse 0)
2	0 x 001	Cisco IOS hat den Anruf aus einem bestimmten Grund abrupt beendet, z. B. weil Layer 1 in der physischen Spanne des Anrufs heruntergefallen ist.
2	0 x 002	Layer-Terminierung der Fehlerkorrektur (EC).
2	0 x 003	Die Dekomprimierungsaufgabe Microcom Network Protocol 5 (MNP5) erhielt ein illegales Token im Datenstrom. Dieser Trennungsgrund tritt im Datenmodus (0x3003) auf. Möglicherweise liegt ein logischer Fehler vor, entweder beim Modem oder bei der Implementierung von Dekomprimierung oder Fehlerkorrektur durch den Partner. (Es besteht auch die Möglichkeit, einen Zeilenschlag oder einen RAM-Speicherfehler zu verursachen.)
2, 4, 6	0 x 004	Die V.42bis- oder V.44-Dekomprimierungsaufgabe erhielt ein illegales Token im Datenstrom. Dieser Trennungsgrund kann im Datenmodus (0x4004) auftreten. Möglicherweise liegt ein logischer Fehler vor, entweder beim Modem oder bei der Implementierung von Dekomprimierung oder Fehlerkorrektur durch den Partner. (Es besteht auch die Möglichkeit, einen Zeilenschlag oder einen RAM-Speicherfehler zu verursachen.) Für V.44 wird dieser Code durch den Diagnoseverbindungsinformationsfeldindex 119 ergänzt (ein Achtbyte-Informationsfeld, das als Debugtool verwendet wird).
2	0 x 005	MICA-Softwarefehler. Der Fehlercode für diesen Trennungsgrund lautet 0x4005. Es ist ein MICA-Softwarefehler aufgetreten, der auf eine fehlerhafte Co-Prozessor-Zustandsvariable hinweist.
6	0 x 006	Der Befehl ATH wurde vom lokalen Modem erkannt. Dieser Trennungsgrund tritt im Datenmodus (0xC006 und 0xE006) auf. Der Befehl ATH (Hangup) wurde vom lokalen Modem (MICA) erkannt. Während eines Wählvorgangs von IOS, nach dem der Anruf verbunden wurde, löscht die IOS DTE-Schnittstelle den Anruf, indem sie einen In-Band-ATH-Befehl überträgt.
1	0 x 007	Der AT-Wählbefehl wurde abgebrochen. Der AT-Wählbefehl wurde durch den Befehl any key abort abgebrochen. Beispielsweise leitet das Host-Modem einen Anruf ein. Während des Verbindungsaufbaus vor dem STEADY-STATE-Schritt wird durch Drücken einer beliebigen Taste der AT-Wählbefehl abgebrochen.
1	0 x 008	Der Anruf dauerte zu lange, um die Verbindung abzuschließen. Beachten Sie, dass der S7-Timer (Warten auf den Carrier nach dem Wählen) für diese Trennung abgelaufen ist. Dieser Trennungsgrund tritt bei der Anrufeinrichtung (0x6008) auf. Aufgrund einer Umschulung dauerte es zu lange, bis das Host-Modem eine Verbindung hergestellt hatte. Die Ursachen sind: Schwierigkeiten bei der Auswahl (Verhandlung) eines Layer-I-Standards (z. B. Abbrechen des Anrufs, bevor der Anruf mit dem Trennungsgrund 0x6102 zurückgesendet wird) oder einer Kombination aus Layer-I- und Layer-II-Einrichtung, die zu lange dauert. So dauert beispielsweise die Aushandlung von Fehlerkorrekturen eine längere Zeit über eine Umschulung hinaus oder aufgrund von Bitfehlern, die beim Versuch des Client-Modems, eine Verbindung mit einer aggressiven Geschwindigkeit herzustellen, eingeführt wurden (der Empfänger des Client-Modems versucht, eine Verbindung mit einer Geschwindigkeit herzustellen, die er nicht aufrechterhalten kann). Diese Rabattart wird mit CSR verglichen. Diese Trennung kann auch auftreten, wenn das Antwortmodem vom Kanal keinen Ton hörte (z. B. war der Ausgangspunkt kein Modem).
2	0 x 009	DSP wurde zurückgesetzt (Befehl, intern oder spontan). Der Fehlercode für diesen Trennungsgrund lautet 0x4009. Der DSP im Host-Modem wurde vom Control Processor (CP) oder Signal Processor (SP) zurückgesetzt. Der CP setzt den DSP zurück, wenn keine E-Mail-Nachrichten vom CP zum SP bestätigt werden. Der SP setzt sich selbst zurück, wenn ein interner Inkonsistenzfehler auftritt.
4,6	0 x 00 A	Eingang eines illegalen STEPUP-Codeworts. Gibt den Empfang eines STEPUP-Codeworts an, wenn der Wert von C2 (aktuelle Codewortgröße) N1 (maximale Codewortgröße: Negotiated) und gilt nur für V.44 und V.42bis.
4,6	0 x 00 Mrd.	Empfang eines illegalen V.42bis-Codeworts. Gibt den Empfang eines Codeworts an, das zu einem beliebigen Zeitpunkt C1 (nächster leerer Wörterbucheintrag) entspricht und für V.42bis gültig ist. (Der Empfang eines Codeworts = C1 ist in V.42bis illegal, in V.44 jedoch legal).
4,6	0 x 00 C	Eingang eines illegalen Tokens (zu groß) in V.44 oder V.42bis. Dies bedeutet, dass die Größe des erhaltenen V.42bis- oder V.44-Codes die vereinbarte Höchstzahl überschreitet. Gibt den Empfang eines Codeworts an, das jederzeit größer ist als C1 (nächster leerer Wörterbucheintrag) und für V.44 und V.42bis gültig ist.
4,6	0 x 00 D	Erhalt eines reservierten V.44- oder V.42bis-Befehlscodes. Gibt den Empfang eines reservierten Befehlscodes an und gilt für V.44 und V.42bis.
4,6	0 x 00 C	V.42bis oder V.44 empfing ein Codewort, das größer ist als der nächste leere Wörterbucheintrag. Empfang eines V.44-ungültigen STEPUP-Zeichens. Dies zeigt den Empfang eines STEPUP-Steuerelementcodes an, der dazu führt, dass der Wert von C5 (Ordinalgröße) acht überschreitet. Dies gilt nur für V.44.
4,6	0 x 00 F	V.44 Rx Dictionary Full. Gibt den Empfang eines Codeworts an, das kein Zurücksetzen des Wörterbuchs ist, wenn die Rx-Knotenstruktur voll ist. Nur für V.44 gültig.
4,6	0 x 010	V.44 Rx History Full. Gibt den Empfang eines Codeworts an, das kein Zurücksetzen des Wörterbuchs ist, wenn der Rx-Verlauf voll ist. Nur für V.44 gültig.
4,6	0 x 011	V.44/V.42bis Unzulässige Rx-Zeichenfolgengröße überschritten. Gibt den Empfang eines Codeworts an, durch das die maximale ausgehandelte Zeichenfolgengröße überschritten wird. Sie gilt für V.44 und V.42bis.
4,6	0 x 012	Ein V.44-Verhandlungsfehler ist aufgetreten Gibt einen V.44-Verhandlungsfehler an. Für V.44 wird dieser Code durch den Diagnoseverbindungsinformationsfeldindex 119 ergänzt. Der Index der Diagnoseverbindungsinformationen ist ein Informationsfeld mit acht Byte, das als Tool für das Debuggen verwendet wird.
4,6	0 x 013	Ein V.44-Komprimierungsfehler ist aufgetreten Gibt einen V.44-Komprimierungsfehler an. Für V.44 wird dieser Code durch den Diagnoseverbindungsinformationsfeldindex 119 ergänzt. Der Index der Diagnoseverbindungsinformationen ist ein Informationsfeld mit acht Byte, das als Tool für das Debuggen verwendet wird.
Von DSP gemeldete Bedingungen (Class 1)
	0 x 1 x xx	Von SPE gemeldete DSP-Bedingungen
3, 4, 5	0 x 100	Der DSP hat das Trägersignal verloren. Das heißt, MICA erkannte ein Verwerfen des Client-Modem-Carriers. Dieser Trennungsgrund tritt während der Anrufeinrichtung und im Datenmodus (d. h. 0x6100, 0x8100 und 0xA100) auf. Der MICA DSP hörte den Hörer für einen Zeitraum ab, der den in Register S10 angegebenen Wert übersteigt (Auflegen nach Carrier Loss). Dies kann bedeuten, dass der Gesprächspfad verschwunden ist oder dass der Client die Übertragung beendet hat. Wenn ein Layer-II-Protokoll (V.42 und/oder V.42bis) in Kraft ist, wäre eine solche Trennung unnormal. Dieser Trennungsgrund tritt manchmal während der EG-Aushandlung (vor dem Datenmodus) auf. D.h. Layer I wurde erfolgreich ausgehandelt (was zu einer Carrier-Signal-Erkennung führt), und die Verbindung wird getrennt, wenn versucht wird, das Layer-II-Protokoll (V.42 und/oder V.42bis) einzurichten. Häufige Ursachen sind, dass Benutzer den Anruf abbrechen, bevor eine Verbindung hergestellt wird. Anrufzufälle, abgebrochene Starts und Zeitüberschreitung bei Client-Anwendungen, da die Verbindung zu lange dauert (z. B. mehrfache Neuzuweisungen während der Layer-I-Aushandlung). Diese Art von Ausfall wird mit CSR verglichen. Der Zustand des Carriers kann auch im normalen Datenmodus auftreten, wenn der Client den Carrier abrupt verwirft. Die häufige Ursache hierfür ist eine nicht ausgehandelte oder verschmutzte Trennung vom Client-Modem (d. h. das Client-Modem verwirft lediglich das Trägersignal). Dies kann auftreten, wenn die Verbindung plötzlich getrennt wird (d. h. ein Netzwerkfehler), das Netzkabel des Client-Modems abgeschaltet wird, um den Anruf zu trennen. Dies kann auch bei günstigeren Client-Modems auftreten, die die Clear-Down-Protokolle für Layer I und/oder Layer II auf einem DTR-Dropdown-Menü nicht implementieren. Bei einer großen Anzahl von Client-Modems gilt dies als normale Trennung. Wenn das Client-Modem eine schmutzige Trennung vornimmt, liegt die Startbedingung zwischen 0xA103, 0xA100 und 0xDF06. Wenn der DSP im Host-Modem einen Carrier-Verlust erkennt, gewinnt 0xA100 und wird als Trennungsgrund angegeben. Wenn der DSP keinen Carrier-Verlust erkennt und erst dann eine Neuschulung durchführt, wenn er den Register S40-Grenzwert erreicht, gewinnt 0xA103. Wenn das Netzwerk erkennt, dass der Anruf getrennt wurde, und den Router signalisiert, die Verbindung zu trennen, gewinnt 0xDF06. Dieser Trennungsgrund gilt nicht für CSR, wenn sich das Host-Modem im Datenmodus befindet.
1	0 x 101	Dies tritt auf, wenn sich der Signalprozessor (SP) in der Erkennungsphase des Answer Back Tone (ABT) befindet, wenn der Anruf ausfällt.
1	0 x 104	Anrufausfall während des Modemzugs aufgrund inkompatibler Modulation oder schlechter Leitung. Dieser Trennungsgrund tritt beim Einrichten der Gesprächsverbindung (0x6102) auf. Dies kann ein Hinweis auf Versuche sein, eine nicht unterstützte Modulation wie eine proprietäre Legacy-Rockwell-Modulation (K56Plus, V.FC usw.) auszuhandeln. Weitere mögliche Ursachen sind DSP-Ausfälle bei der Zugeinrichtung aufgrund schwerer Leitungsstörungen, Impulsgeräusche, Unterbrechungsschulungen, inkompatible Modulationsparameter und möglicherweise die Unfähigkeit, einen Layer-I-Standard korrekt auszuwählen. Diese Art der Disverbindung wird mit CSR verglichen.
4,5	0 x 103	Zu viele aufeinander folgende Züge oder Geschwindigkeitsverschiebungen. Der Umzugsgrenzwert wird mit Register S40 festgelegt. Dieser Trennungsgrund tritt während der Anrufeinrichtung und im Datenmodus (0x6103, 0x8103 und 0xA103) auf. Während eines Anrufs kam es zu zu vielen Neuschulungen, die den Anruf unwirksam machten, da die Datenrate so schlecht war, dass sie nutzlos war. Mögliche Bedingungen sind, unter denen das Client-Modem das Clear-Down-Protokoll (z. B. das Telco-Gerät den Anruf in der Mitte der Verbindung aufnimmt) nicht vollständig ausführt und MICA versucht, den Anruf durch Neuzuweisungen wiederherzustellen. Sobald der Umzugsgrenzwert erreicht ist (die Umzugsgrenze kann mithilfe des S40-Registers geändert werden), verwirft MICA den Anruf und meldet diesen Trennungsgrund. Unter bestimmten Umständen (Channelized T1/E1) kann diese Art der Trennung als normale STEADY-Zustandstrennung betrachtet werden. Alternativ könnte dies einfach das Ergebnis einer schmutzigen Trennung aufgrund möglicher Leitungsfehler sein, von denen MICA nicht wiederhergestellt werden kann. Daher wird diese Art der Trennung nicht für CSR angerechnet, da der Anruf bereits eingerichtet wurde. Dieser Trennungsgrund kann auch bei EC-Verhandlungen auftreten, wenn das Client-Modem gegenüber der ursprünglichen Verbindungsrate übermäßig aggressiv ist und den Anruf nicht aufrechterhalten kann (wie bei alten USRobotics-Client-Modems beobachtet). Diese Art der Trennung zählt nicht zu CSR. Wenn das Client-Modem eine schmutzige Trennung vornimmt, liegt die Startbedingung zwischen 0xA103, 0xA100 und 0xDF06. Wenn der Digital Signal Processor (DSP) des Host-Modems einen Carrier-Verlust erkennt, gewinnt 0xA100 und wird als Trennungsgrund angegeben. Wenn der DSP keinen Carrier-Verlust erkennt und erst dann eine Neuschulung durchführt, wenn er den S40-Grenzwert erreicht, gewinnt 0xA103. Wenn das Netzwerk erkennt, dass der Anruf getrennt wurde, und den Router signalisiert, die Verbindung zu trennen, gewinnt 0xDF06. Dieser Trennungsgrund gilt nicht für CSR, wenn sich das Host-Modem im Datenmodus befindet.
1	0 x 104	Problem bei der Erkennung des Endes des Answer-Back Tone (ABT). Verhandlungsversagen oder übermäßiges Geräusch während der V.34-Ausbildung. Host-Modems antworten und senden V.8bis- und modulierte 2100Hz-Rückwärtstöne (ABTs) mit Phasenrückwandlern aus, treten jedoch während der Trainingssequenz auf ein lautes Geräusch. Suchen Sie auf Fehler im Pfad vom anrufenden Modem zum beantwortenden Modem in eine oder beide Richtungen. Ein ähnliches Verhalten tritt auf, wenn im öffentlichen Telefonnetz (PSTN) eine Latenz für die Einwahlverbindung besteht, die eine Sekunde überschreitet und dazu führt, dass die Modems die Echounterdrückung nicht trainieren können. Weitere mögliche Ursachen sind: Die tatsächlichen TX-Leistungsstufen sind falsch, und die Töne werden dann nicht von der Remote-Seite behandelt. Während der V.34-Ausbildung gibt es in den Phasen III und IV zu viel Rauschen. Es liegt ein Operatorfehler vor. Während der V.34-Schulung kommt es zu Netzwerkstörungen (jemand nimmt die Durchwahl an). Diese Rabattart wird mit CSR verglichen.
1	0 x 105	SS7/COT (Continuity Test)-Vorgang erfolgreich abgeschlossen Dieser Trennungsgrund tritt beim Einrichten der Gesprächsverbindung (0x6105) auf. Der SS7/COT (Continuity Test) Vorgang wurde erfolgreich abgeschlossen.
1	0 x 106	SS7/COT (Continuity Test)-Vorgang fehlgeschlagen: T8/T24-Timeout beim Warten auf den Ton. Dieser Trennungsgrund tritt während der Anrufeinrichtung (d. h. 0x6106) auf. Der SS7/COT-Vorgang (Continuity Test) ist fehlgeschlagen, weil der T8/T24-Timer beim Warten auf den Ton abgelaufen ist.
1	0 x 107	SS7/COT (Continuity Test)-Vorgang fehlgeschlagen: T8/T24-Timeout für das Warten auf Ton aus. Dieser Trennungsgrund tritt beim Einrichten der Gesprächsverbindung (0x6107) auf. Der SS7/COT-Vorgang ist fehlgeschlagen, weil der T8/T24-Timer beim Warten auf die Tonfreigabe abgelaufen ist.
4	0 x 108	Modem On Hold (MOH)-Cleardown durch MICA. Die Modem On Hold Cleardown-Anfrage wurde vom Client-Modem empfangen. V.92 gibt an, dass der Grund für die Entfernung folgendermaßen lauten kann: Bereinigen aufgrund eines eingehenden Anrufs Bereinigen aufgrund eines ausgehenden Anrufs Löschen aus anderen Gründen.
4	0 x 109	Modem On Hold (MOH) Timeout-Wert erreicht.
Lokale EC-Bedingungen (Class 2)
	0x2xx	Lokale EG-Bedingungen
1	0 x 201	Sie haben während der Verhandlung nie einen LR-Frame (Link Request) erhalten. Dieser Trennungsgrund tritt während der Anrufeinrichtung (d. h. 0x6201) auf. Das bedeutet, dass das Host-Modem den LR-Frame während der Fehlerbehebungsaushandlung nie erhalten hat. Das Peer-Modem unterstützt MNP innerhalb von V.42 möglicherweise nicht.
1	0 x 202	LR-Frame mit schlechtem Parameter (PARAM1) empfangen. Der Frame der empfangenen MNP-Verbindungsanforderung (LR) weist einen fehlerhaften oder unerwarteten PARAM1 auf. Weitere Informationen zu PARAM1 finden Sie in der V.42-Spezifikation.
1	0 x 203	Inkompatibles LR-Frame (Link Request) empfangen. Dieser Trennungsgrund tritt beim Verbindungsaufbau (0x6203) auf. Der empfangene MNP LR-Frame ist nicht mit den EC-Einstellungen des Host-Modems kompatibel.
4,5	0 x 204	Zu viele aufeinander folgende Übertragungen. Dieser Trennungsgrund tritt beim Einrichten von Gesprächen und im Datenmodus (0x8204, 0xA204 und 0x6204) auf. Dieser Trennungsgrund kann durch Geräusche auf der Leitung verursacht werden. Beispielsweise überträgt das Host-Modem Daten an das Client-Modem, aber Geräusche in der Leitung führen dazu, dass die Daten von der Client-Seite falsch (oder gar nicht) empfangen werden. Übermäßiges Geräusch kann also zu übermäßigen Neuübertragungen führen. Das Client-Modem hätte auch getrennt werden können, ohne dass das MICA-Modem dies bemerkt. Das Host-Modem überträgt also kontinuierlich weiter, ohne zu wissen, dass das Client-Modem nicht mehr vorhanden ist. Wenn der Anruf in einem EC-Protokoll (Error Compression) (Verbindungs-Zugriffsverfahren für Modems (LAPM) oder Microcom Networking Protocol (MNP)) verbunden wird, kann MICA manchmal keinen Frame an das Client-Modem übertragen. Das Client-Modem bestätigt die erste Übertragung von MICA nicht und reagiert dann nicht auf S19-Abfragen (Error Correction Retransmission Limit) (der Standardwert ist 12), sodass MICA den Anruf trennt. Eine Ursache kann sein, dass der Carrier im Übertragungspfad erheblich heruntergefallen ist, während der Client nicht umschalten konnte. Eine andere Ursache könnte ein Problem mit der EC-Engine des Clients sein (wie es bei einem Winmodem-System der Fall wäre, wenn Windows nicht mehr reagiert).
6,7	0 x 205	Timeout bei Inaktivität, LD (MNP Link Disconnect) gesendet. Dieser Trennungsgrund tritt im Datenmodus (0xC205 und 0xE205) auf. Das Host-Modem sendet dem Client-Modem einen LD-Frame, der anzeigt, dass ein Timeout bei Inaktivität aufgetreten ist.
4,5	0 x 206	EC-Protokollfehler. Dieser Trennungsgrund tritt im Datenmodus (0x8206 und 0xA206) auf. Dies ist ein allgemeiner catch-all-Protokollfehler. Sie weist darauf hin, dass ein LAPM- oder MNP EC-Protokollfehler aufgetreten ist.
1	0 x 210	Es ist kein EC-Fallback-Protokoll verfügbar. Dieser Trennungsgrund tritt beim Verbindungsaufbau (0x6210) auf. Die Verhandlung zur Fehlerkorrektur wurde nicht erfolgreich durchgeführt. Der Anruf wird beendet, da kein Fallback-Protokoll zur Fehlerbehebung verfügbar ist. S-Register S25 (Link Protocol Fallback) bestimmt das verfügbare Fallback-Protokoll. Die Optionen sind asynchrones Framing, synchrones Framing oder Disconnect (auflegen).
1	0 x 211	Sie haben während der Aushandlung nie den Frame eXchange IDentification (XID) erhalten. Dieser Trennungsgrund tritt beim Verbindungsaufbau (0x6211) auf. Das bedeutet, dass das Host-Modem den XID-Frame während der Fehlerbehebungsaushandlung nie erhalten hat. Das Client-Modem unterstützt LAPM unter V.42 möglicherweise nicht.
1	0 x 212	Der empfangene XID-Frame ist nicht mit den lokalen Einstellungen kompatibel. Dieser Trennungsgrund tritt beim Verbindungsaufbau (0x6212) auf. Der empfangene XID-Frame ist nicht mit den Einstellungen des Host-Modems kompatibel. Beispielsweise kann das Client-Modem MNP5 angeben, während das Host-Modem nur V.42 und V.42bis angibt.
3, 4, 5	0 x 220	Empfänger Disconnect (DISK)-Frame. Dies ist die normale LAP-M-Trennung. Dieser Trennungsgrund tritt beim Einrichten von Gesprächen und im Datenmodus (0x 6220, 0x8220 und 0xA220) auf. Der Anruf wurde normal beendet, wobei der Client eine ordnungsgemäße, von der Client-Seite abgeschlossene Verbindung aufweist. (Das heißt, ein V.42-Trennpaket wurde vom Client-Modem an das NAS-Modem gesendet.) Das Client-Modem verließ DTR und handelte ein Clear-Down-Protokoll sauber aus.
3, 4, 5	0 x 221	Empfangener DM-Frame. Peer trennt möglicherweise die Verbindung. Dieser Trennungsgrund tritt im Anruf- und Datenmodus (0x6221, 0x8221 und 0xA221) auf. Das Client-Modem zeigt an, dass die Verbindung getrennt wird. Während der Anrufeinrichtung deutet dies darauf hin, dass das Client-Modem die Aushandlung der Fehlerkorrektur aufgibt.
4,5	0 x 222	Eine ungültige Sequenznummer erhalten. Dieser Trennungsgrund tritt im Datenmodus (0x822 und 0xA222) auf. Das Host-Modem erhielt einen LAPM- oder MNP-Fehlerkorrektur-Frame mit einer falschen Sequenznummer oder Bestätigungsnummer. Ein LD- oder Frame Reject (FRMR)-Frame wird an das Client-Modem gesendet, um anzuzeigen, dass das Host-Modem die Verbindung trennt.
4,5	0 x 223	SABME-Frame im Steady-State empfangen. Dieser Trennungsgrund tritt im Datenmodus (0x8223 und 0xA223) auf. Dies wird als LAPM-Fehlerkorrekturfehler im stationären Zustand interpretiert. Das bedeutet, dass das Client-Modem möglicherweise zurückgesetzt wurde, weil ein Frame Reject (FRMR) empfangen wurde.
4,5	0 x 224	Empfangener MNP XID-Frame im Steady-State. Dieser Trennungsgrund tritt im Datenmodus (0x8224 und 0xA224) auf. Dies wird als LAPM-Fehlerkorrekturfehler im stationären Zustand interpretiert. Das bedeutet, dass das Client-Modem möglicherweise zurückgesetzt wurde, weil ein Frame Reject (FRMR) empfangen wurde.
4,5	0 x 225	Empfangs-MNP-LR-Frame im stationären Zustand. Dieser Trennungsgrund tritt im Datenmodus (0x8225 und 0xA225) auf. Dies wird als Fehler bei der MNP-Fehlerkorrektur im stationären Zustand interpretiert. Das bedeutet, dass das Client-Modem zurückgesetzt wurde.
Spezifische Bedingungen für das PIAFS-Protokoll (Class 2, Fortsetzung)
3,4	0 x 230	Eine empfangene Nachricht ist kleiner als die für diesen Meldungstyp definierte Mindestlänge.
3,4	0 x 231	Unbekannter oder nicht implementierter PIAFS-Frame-Typ wird empfangen. Dazu gehören die FI (Haupt-Frame-Typ) sowie die Aushandeln-, Synchronisierungs- oder Steuerelementklasse (Subtyp).
3,4	0 x 232	Unbekannter PIAFS Control Frame Identifier (CFI). Ein Steuerelementrahmen wurde mit einer unbekannten oder nicht implementierten ID für seine Klasse empfangen. Beachten Sie, dass fortlaufende Frames und Benutzer-Frames nicht implementiert sind und dass es keine bekannten Benachrichtigungs-Frames gibt.
3,4	0 x 233	Verhandlung der PIAFS-Kommunikation fehlgeschlagen. Nach der ersten Synchronisierung werden Frames für den Kommunikationsparameter "REQ/Ack" ausgetauscht. Entweder waren die Parameter inakzeptabel, oder der Initiator erkannte eine NAK-Antwort (Negative Acknowledgment). Hinweis: MICA kann nur zu Testzwecken als Client/Initiator fungieren.
3,4	0 x 234	PIAFS-ARQ-Verhandlung fehlgeschlagen. Nach der Re-Synchronisierung werden Frames für ARQ-Anfragen (Request)/Bestätigungen (Ack) ausgetauscht. Entweder waren die Parameter inakzeptabel, oder der Initiator erkannte eine Nak-Antwort. Hinweis: MICA kann nur zu Testzwecken als Client/Initiator fungieren.
3,4	0 x 235	Probleme mit dem PIAFS Control Transfer Protocol erkannt. Der Initiator erhielt ein Ack/Nak/Rsp, dessen ID, Klasse und Sequenz nicht mit den ursprünglichen Req/Ntf übereinstimmen. Hinweis: MICA kann nur zu Testzwecken als Client oder Initiator fungieren.
3,4	0 x 236	Dieser Trennungsgrund zeigt nicht mehr den Empfang eines DataLinkRelease-Anforderungsrahmens an. Sie weist jetzt auf eine Trennung hin, ohne dass zuvor ein Trennungsgrund generiert wurde. Dies bedeutet, dass MICA einen Anruf trennt, aber feststellt, dass kein Grund angegeben wurde.
3,4	0 x 237	Der Wartezeitgeber für den synchronisierten Empfang (T001) ist abgelaufen. Dieser Timer startet beim Senden eines Sync-Request-Frames und stoppt, wenn ein Sync-Receiver erkannt wird. Dieser Fehler tritt nur dann auf, wenn der MICA-Port als Client oder Initiator betrieben wird, was nur beim Testen auftritt. Der Standardwert ist 15 Sekunden.
3,4	0 x 238	Der PIAFS-Empfangs-Übertragungs-Timer für die Post-Synchronisierung ist abgelaufen. Dieser Timer startet, wenn ein Sync-Receiver gesendet wird, und stoppt, wenn ein Sync-Empfang (Kollisionsfall) oder ein Kontrollrahmen erkannt wird. Dieser Fehler tritt nur dann auf, wenn der MICA-Port als Server (Antwortmodus) betrieben wird, d. h. im normalen Betriebsmodus. Der Standardwert ist 15 Sekunden.
3,4	0 x 239	Der Timer T003 für die PIAFS-Synchronisierungsanforderung ist abgelaufen. Dieser Timer startet, wenn kontinuierliche FCS-Fehler erkannt werden, und stoppt, wenn ein gültiger Sync-Request-Frame erkannt wird. Dieser Fehler tritt nur auf, wenn der MICA-Port als Server (Antwortmodus) betrieben wird, d. h. der normale Betriebsmodus. Der Standardwert ist 15 Sekunden.
3,4	0 x 23 A	Der PIAFS-Timer T101 ist abgelaufen: Wartezeit-Timer für die Steuerungsrahmenbestätigung. Startet, wenn eine Anforderung oder Benachrichtigung für den Steuerrahmen gesendet wird, wird angehalten, wenn der Frame bestätigt wird. Dieser Fehler tritt nur dann auf, wenn der MICA-Port als Client oder Initiator betrieben wird, was nur während des Testens (zehn Sekunden) auftritt.
3,4	0 x 23 Mrd.	PIAFS: empfing FBI (ACK Sequence #) außerhalb des vereinbarten Bereichs oder erhielt FBI=0 mit einem nicht leeren Datenrahmen.
3,4	0 x 23 C	PIAFS: FFI (MSG Sequence #) außerhalb des vereinbarten Bereichs erhalten, oder FFI=0.
3,4	0 x 23 D	PIAFS: Das Datenfenster für ausgehandelte Daten ist kleiner als der RTF-Wert (Round Trip Delay). Dieser Fehler wird nicht mehr von Portware veröffentlicht und sollte nie gesehen werden.
3,4	0 x 23 E	PIAFS: Das Feld für die Datenlänge der Nachricht ist zu groß. Muss 0-73 sein.
3,4	0 x 23 F	Interner PIAFS-Fehler: SREJ-Anruf hat einen Fehlercode zurückgegeben.
3,4	0 x 240	Genereller PIAFS-Protokollfehler. Dies ist ein Abruf für Fehler, die nicht mit einem getrennten Grund verbunden sind.
3,4	0 x 241	PIAFS: Protokollverhandlung fehlgeschlagen. Für beide Stationen war kein Protokoll zulässig (z. B. Fixed Speed Data Transfer Protocol, DTP Variable Speed Type1). Nicht akzeptable Protokolle wären DTP Variable Speed Type3 oder Real Time Protocol.
3,4	0 x 242	PIAFS: der gemessene RTF-Wert (Round Trip Delay) lag nicht im festgelegten (akzeptablen) Bereich.
3,4	0 x 243	Interner PIAFS-Fehler: unbekanntes Ereignis im Ereignishandler. Eine Switch-Anweisung wurde auf den Standardfall zurückgesetzt.
3,4	0 x 244	Das Signal Processor (SP)-Response Timeout trat während einer PIAFS 2.1-SpeedShift auf. Micas CP konnte die Geschwindigkeit nicht innerhalb von 200 ms ändern.
3,4	0 x 245	Der CP von Mica sah inkonsistente Kontrollinformationen in den Strukturen der gemeinsamen Kontrolle von CP/SP. Insbesondere hatte der Datenpuffer einen Kopf- oder Schwanzversatz, der außerhalb der Datenpuffergrenzen lag (0-63).
Ungültiger MNP- oder LAPM-Protokollbefehl vom Partner empfangen (Class 3)
4,5	0x3xx	EC hat einen ungültigen Befehlscode erkannt. Der empfangene unbekannte Befehl befindet sich in den letzten zwei Ziffern. Als Antwort wird ein MNP LD- oder LAP-M Frame Reject (FRMR)-Frame-Frame gesendet.
LAPM-Partner gibt MICA-Protokollfehler (Class 4) an
4,5	0x4xx	EC-Bedingungen, die vom Kunden im LAP-M FRMR-Frame angegeben werden. Der bitzugeordnete Grund befindet sich in den letzten zwei Ziffern.
4,5	0 x 401	LAPM: Peer meldet einen ungültigen Befehl. Das Host-Modem erhielt einen FRMR-Frame vom Client-Modem. Der erhaltene FRMR-Frame weist darauf hin, dass das Client-Modem einen Fehlerkorrekturrahmen vom Host-Modem erhalten hat, der einen fehlerhaften Befehl enthielt.
4,5	0 x 403	LAPM: Peer berichtet, dass Datenfelder nicht zugelassen sind oder eine falsche Länge aufweisen (U-Frames). Das Host-Modem erhielt einen FRMR-Frame vom Client-Modem. Der erhaltene FRMR-Frame gibt an, dass das Client-Modem einen Fehlerkorrekturrahmen vom Host-Modem erhalten hat, der ein Datenfeld enthielt, das nicht zulässig ist oder ein Datenfeld mit falscher Länge enthielt (U-Frame).
4,5	0 x 404	LAPM: Die Länge des Datenfelds für Peer-Berichte ist größer als N401 (die in V.42 angegebene maximale Länge des Informationsfelds), verfügt aber über eine gute Frame Check Sequence (FCS). Das NextPort-Modem erhielt einen FRMR-Frame vom Client-Modem. Der empfangene FRMR-Frame gibt an, dass das Clientmodem einen Fehlerkorrekturrahmen von NextPort erhalten hat, der eine Datenfeldlänge enthält, die größer ist als die maximale Anzahl von Oktetten, die im Informationsfeld (N401) eines I-Frames, eines SREJ-Frames, eines XID-Frames, eines UI-Frames oder eines TEST-Frames übertragen werden können. Die Rahmenprüfsequenz ist gut.
4,5	0 x 408	LAPM: Peer-Berichte erhalten eine ungültige Empfangssequenznummer oder N(R). Das Host-Modem erhielt einen FRMR-Frame vom Client-Modem. Der empfangene FRMR-Frame gibt an, dass das Client-Modem einen Fehlerkorrekturrahmen vom Host-Modem erhalten hat, der eine fehlerhafte Empfangssequenznummer enthielt.
MNP-Partner gibt Verbindungsabbruch oder MICA-Protokollfehler an (Class 5)
4,5	0x5xx	EC-Bedingungen, die vom Kunden im MNP LD Frame angegeben werden. Das Feld "Grund" befindet sich in den letzten zwei Ziffern.
1	0 x 501	MNP: Peer hat nie LR-Frame empfangen. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt an, dass das Client-Modem nie eine Verbindungsanforderung vom Host-Modem erhalten hat.
1	0 x 502	MNP: Peer-Reports LR-Frame hat schlechten Parameter 1. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame gibt an, dass das Client-Modem einen Link-Request-Frame vom Host-Modem erhalten hat, der einen fehlerhaften (d. h. unerwarteten) PARAM1 enthielt. Weitere Informationen zu PARAM1 finden Sie in der V.42-Spezifikation.
1	0 x 503	MNP: Peer Reports LR Frame ist nicht mit seiner Konfiguration kompatibel. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame gibt an, dass das Client-Modem einen LR-Frame vom Host-Modem erhalten hat, der nicht mit der Konfiguration des Client-Modems kompatibel ist.
4,5	0 x 504	MNP: zu viele aufeinander folgende EG-Übertragungen. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt an, dass das Client-Modem zu viele aufeinander folgende Übertragungen erhalten hat.
4,5	0 x 505	MNP: Der Inaktivitäts-Timer für Peer-Berichte ist abgelaufen. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt an, dass der Host des Client-Modems (DTE) innerhalb eines Zeitraums keine Daten an das Client-Modem weitergegeben hat.
1	0 x 506	MNP: Peer-Berichte-Fehler. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame gibt an, dass das Client-Modem einen MNP-Protokollfehler erhalten hat.
1	0 x 5 FF	Normale MNP-Trennung. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt eine normale MNP-Terminierung an, die anzeigt, dass die DTR-Nummer des Client-Modems verworfen wurde oder dass ein +++- oder ATH-Befehl empfangen wurde. Dieser Trennungsgrund tritt im Anruf- und Datenmodus (0x65FF, 0x85FF und 0xA5FF) auf. Das Host-Modem erhielt eine LD, die auf eine normale Terminierung hinweist. Der Anruf wurde normal beendet, wobei der Anruf von der Client-Seite ordnungsgemäß abgebrochen wurde (z. B. wurde vom Client-Modem ein Trennungspaket an das Host-Modem gesendet). Das Client-Modem verließ DTR und handelte ein Clear-Down-Protokoll sauber aus.
PIAFS-Partner gibt Disconnect- oder MICA-Protokollfehler an (Class 6)
3,4	0x6xx	MICA erhielt eine PIAFS DataLinkRelease (PDLR) mit dem Grund xx (siehe unten stehende detaillierte Werte).
3,4	0 x 61 x	Normale Klasse für PIAFS DataLinkRelease (PDLR): 0 - Normaler Release. 1 - Normale Freigabe, Datenverbindungsverlängerung verboten. 2 - Normale Freigabe, Datenverbindung wird fortgesetzt. ... Andere Normale Klassen - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
3,4	0 x 62 x	Ressourcenverwendung für PIAFS DLR nicht möglich (Besetztzeichen): 8 - DTE beschäftigt. 9 - Vorübergehende Behinderung. ... Andere Ressourcen verwenden keine möglichen Klassen - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
3,4	0 x 63 x	Dienstauslastung für PIAFS DLR nicht möglich (schlechte Parameter). 9 - Einstellung der Request-Parameter nicht möglich. A - Die Einstellung des Request-Parameters ist derzeit nicht möglich. ... Andere Dienstauslastung ist nicht möglich - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
3,4	0 x 64 x	Service noch nicht bereitgestellt Klasse für PIAFS DLR. 1 - Die Parameterangabe ist noch nicht enthalten. ... Andere Dienste haben noch keine Klassen bereitgestellt - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
3,4	0 x 65 x	Ungültige Informationsinhaltsklasse für PIAFS DLR. 8 - Terminalattribut nicht zugeordnet. ... Andere Ungültige Informationsinhaltsklassen - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
3,4	0 x 66 x	Sequenzfehlerklasse für PIAFS DLR 0 - Unzureichende wesentliche Parameter. 1 - Informationsinhalte nicht definiert oder noch nicht bereitgestellt. 5 - ARQ-Bedingung und Signal nicht zugeordnet. 6 - Der Zeitgeber läuft ab. ... Andere Sequence-Fehlerklassen - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
3,4	0 x 67 x	Weitere Eigenheiten Klasse für PIAFS DLR. 1 - Während eines Sprachanrufs ... Andere merkwürdige Klassen - nicht definierte Klassen, die sich auf einige Clientgeräte beziehen.
Host/IOS verlangte Trennung (Class 31)
6,7	0 x 1 fxx	Vom Host initiierte Trennung Value ist eine Summe aus 0x1F00 und dem SessionStopCommand-Wert. Dies ist der Grund für die Beendigung des Hosts. Der Hostgrund wird in den Bytes xx mit niedriger Reihenfolge angegeben.
3, 6, 7	0 x 1 f00	Die Verbindung wurde vom unspezifischen Host initiiert. Value ist eine Summe aus 0x1F00 und dem SessionStopCommand-Wert. Dies ist der Grund für die vom IOS initiierte "catch-all"-Trennung. Sie wird für alle nicht standardmäßigen Verbindungen verwendet. Dies könnte beispielsweise darauf zurückzuführen sein, dass die Modemverwaltungssoftware beschließt, den Anruf zu beenden. Eine mögliche Erklärung ist ein Fehler bei der Authentifizierung auf höherer Ebene (RADIUS, TACACS) oder eine andere Anwendung, die dem Host-Modem einen DTR-Drop ausgibt. Dieser Trennungstyp wird nicht auf CSR angerechnet, wenn sich das Host-Modem im Datenmodus befindet.
1	0 x 1 f01	Die gewählte Nummer war besetzt. Die Verbindung wurde getrennt, weil der Host anzeigt, dass die gewählte Nummer besetzt ist.
1	0 x 1 f02	Die gewählte Nummer konnte nicht beantwortet werden. Die Verbindung wurde getrennt, weil der Host angibt, dass die gewählte Nummer nicht geantwortet hat.
3, 6, 7	0 x 1 f03	Virtuelle DTR wurde entfernt. Dieser Status spiegelt sich in der Umleitung des E/A-Ports wider, der derzeit das Modem verwendet. Die Verbindung wurde getrennt, weil der Host die virtuelle DTR-Leitung verworfen hat. Diese generische Trennungsursache wird von der Cisco IOS Software initiiert. Mögliche Ursachen sind Timeout im Leerlauf, empfangene PPP-LCP-TERMREQ, Authentifizierungsfehler, Telnet-Auflegen usw. Um den Grund für das Auflegen zu ermitteln, überprüfen Sie den Radius-Trennungsgrund vom Terminus-Befehl für den Modem-Aufrufdatensatz oder von Authentication, Authorization, and Accounting (AAA).
6,7	0 x 1 f04	Der Befehl ATH (hangup) wurde vom lokalen Host erkannt.
1	0 x 1 f05	Kein Zugriff auf das Telco-Netzwerk. Die Verbindung wurde getrennt, weil der Host nicht auf das Netzwerk (ISDN) zugreifen konnte.
3,4,5	0 x 1 f06	Das Netzwerk hat die Verbindung unterbrochen. Dies kann vor oder während des Datenmodus geschehen. Eine 0 x 1 f06-Trennung bedeutet, dass IOS ein Schaltungsaufhängesignal vom Schaltungsnetzwerk (also eine Q.931-Trennung oder ein CAS-Aufstecksignal) empfangen hat, und IOS diese Nachricht dann an MICA weiterleitete, wenn MICA angewiesen wurde, aufzulegen. Wenn MICA den Datenmodus erreicht und kein EC-Protokoll (LAPM oder MNP4) ausgehandelt wurde, kann dies eine normale Trennung sein. Dieser Grund kann auch generiert werden, wenn Benutzer von Windows 95 oder 98 Dial Up Networking (DUN) während des Trainings und bevor der Anruf den Steady-State erreicht, auf Cancel klicken. Wenn der Client die Telefonleitung abrupt abziehen/das Modem ausschalten sollte, gilt dieser Trennungsgrund ebenfalls als normal. Wenn die Verbindung jedoch EC (LAPM oder MNP4) ausgehandelt hat und somit im Datenmodus, kann dieser Trennungsgrund durch eine schmutzige Trennung (d. h. eine Trennung, die keine anständige Anrufbeendigung ist) erzeugt werden. Dies liegt daran, dass, wenn die Client-DTE (im Datenmodus) den Anruf ordnungsgemäß unterbricht (mit DTR-Drop oder +++/ATH), das Client-Modem uns eine LAPM-DISK (oder MNP-LD) sendet, bevor der Hörer aufgelegt wird, wodurch ein Trennungsgrund von 0x220 und nicht von 0x1f06 entsteht. Das Netzwerk deutete also an, dass in diesem Fall eine Trennung wahrscheinlich auf ein unzufriedenes Client-Modem hindeuten würde, das beschloss, dass es aus irgendeinem Grund keine Carrier mehr aufrechterhalten konnte.
1	0 x 1 f07	NAS beendet SS7/COT Betrieb. Die Verbindung wurde getrennt, weil das NAS-Gerät den SS7/COT-Vorgang (Continuity Test) beendet hat.
1	0 x 1 f08	Der SS7/COT-Vorgang wurde vom Router wegen eines T8/T24-Timeouts abgebrochen.
-	0 x 1 fff	Unaufgefordert. BEENDEN. Der Host sendet diesen Trennungsgrund, wenn er eine nicht angeforderte Abschlussmeldung erhält.

Trennungsgrund: Typen

Der Trennungsgrund:type beschreibt, wann die Verbindung tatsächlich getrennt wurde. Sie können in zwei Hauptkategorien eingeteilt werden: während der Anrufeinrichtung und im Datenmodus (stationär). In der folgenden Tabelle werden die häufigsten Trennungsgrund-Typen und deren Werte angegeben, die im Trennungsgrund angegeben sind.

Trennungstyp	Trennungstyp (Hex)	Beschreibung
0	0x0..	(nicht verwendet)
1	0x2 ...	(nicht verwendet)
2	0x4..	Andere Situationen.
1	0x6..	Die Bedingung trat während der Anrufeinrichtung auf.
4	0x8..	Im Datenmodus. Rx (Leitung zu Host) Daten leeren OK. Der Trennungszustand trat im Datenmodus auf. MICA versucht, empfangene Daten an den Host (IOS) zu übermitteln. Bei einigen Unterbrechungen (z. B. PIAFS) wird nur dieser Datentyp verwendet. Es gibt keine Hinweise auf eine Datenflush-Richtung.
5	0xA ...	Im Datenmodus. Rx-Datenflush (Leitung zu Host) nicht OK. Der Trennungszustand trat im Datenmodus auf. MICA versucht, empfangene Daten an den Host (IOS) zu übermitteln. Im älteren MICA-Code entspricht dieser Typ dem oben angegebenen Typ 4. Obwohl IOS derartige Trennlinien als nicht OK anzeigt, sind keine Probleme aufgetreten.
6	0 x C	Im Datenmodus. TX-Daten (Host to Line) leeren OK. Der Trennungszustand trat im Datenmodus auf. MICA versucht, gepufferte Host-Daten (IOS) an das Partnermodem zu übertragen.
7	0 x E	Im Datenmodus. TX-Datenflush (Host an Line) nicht OK. Der Trennungszustand trat im Datenmodus auf. MICA versucht, gepufferte Host-Daten (IOS) an das Partnermodem zu übertragen. Im älteren MICA-Code entspricht dieser Typ dem oben angegebenen Typ 6. Obwohl IOS derartige Trennlinien als nicht OK anzeigt, sind keine Probleme aufgetreten.

Zugehörige Informationen

• MICA AT-Befehlssatz
• MICA AT-Befehlssatz mit PIAFS
• Versionshinweise für MICA-Portfolio
• Referenz zu NextPort AT-Befehlen und S Registern
• Technischer Support - Cisco Systems