Stati del modem MICA e motivi della disconnessione
Sommario
Introduzione
In questo documento viene descritto come interpretare i codici motivo di disconnessione delle chiamate segnalati dai modem Cisco Modem ISDN Channel Aggregation (MICA).
Nota: Questo documento contiene molti termini definiti negli standard ITU, come V.90, V.44, V.42bis e V.34. Per ulteriori informazioni su questi termini, fare riferimento allo standard ITU-T 
appropriato. I termini specificati negli standard ITU-T non sono spiegati nel presente documento.
Prerequisiti
Requisiti
I lettori di questo documento devono tenere presente quanto segue:
Ogni volta che una chiamata che utilizza DSP (Domain Specific Parts) MICA viene cancellata o disconnessa, MICA registra il motivo della disconnessione. È possibile utilizzare questo motivo per determinare se la disconnessione è stata normale. In caso contrario, è possibile utilizzarlo per individuare le possibili cause del problema. I modem possono essere disconnessi a causa di una serie di fattori, quali disconnessioni dei client, errori di Telco e interruzioni delle chiamate al server di accesso alla rete (NAS). Un motivo tipico per la disconnessione è che il DTE (client modem o NAS) a un'estremità desidera arrestarlo. Tali disconnessioni "normali" indicano che la disconnessione non è il risultato di errori del modem o del livello di trasmissione. Per ulteriori informazioni su come determinare se il motivo della disconnessione è normale, vedere Panoramica generale sulla qualità della linea del modem e del NAS.
Componenti usati
I modem MICA vengono utilizzati nei seguenti server di accesso:
-
Cisco serie 3600 Router
-
AS5200
-
AS5300
-
AS5800
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Determinazione dello stato del modem
Utilizzare il comando show modem log slot/port per trovare lo stato corrente di un modem MICA. In questo output di log, le voci più recenti si verificano verso la fine del log. Lo stato corrente del modem MICA viene visualizzato nell'ultimo evento relativo allo stato del modem (modifica). Nell'esempio riportato di seguito, lo stato del modem è inattivo, indicato dall'evento Modem State contrassegnato con 00:00:28. Fare riferimento alla tabella MICA Modem States per ulteriori informazioni sui possibili stati del modem MICA.
maui-nas-02#show modem log 1/0
Modem 1/0 Events Log:
00:03:33:Startup event:MICA Hex modem (Managed)
Modem firmware = 2.7.3.0
!--- This modem is using portware 2.7.3.0
00:03:33:RS232 event: noRTS, noDTR, CTS, noDCD
...
...
!--- This output was removed for brevity.
...
00:00:28:Modem State event:
State: Terminate
00:00:28:RS232 event: noRTS, DTR, CTS, noDCD
00:00:28:RS232 event: RTS, DTR, CTS, noDCD
00:00:28:Modem State event:
State: Idle
!--- The last modem state event !--- This indicates that the modem is in state Idle
Determinazione del motivo della disconnessione
Ogni volta che si interrompe una connessione modem, il server NAS indica due motivi di disconnessione: i motivi DTE (IOS) e DCE (MICA). I motivi di disconnessione possono essere indicati utilizzando tre metodi principali:
-
Record chiamate modem: In questi report vengono indicati i motivi di disconnessione del software IOS® e del modem MICA.
-
Registri accounting AAA: In questi casi viene riportato solo il motivo della disconnessione del software IOS.
-
Comandi IOS: Comandi quali show modem operating-status e show modem log indicano solo il motivo della disconnessione del modem MICA.
Record chiamate modem
Il motivo di disconnessione IOS e modem per una particolare connessione viene visualizzato nel record di chiamata del modem (MCR). L'MCR viene inviato dal server NAS a un server syslog al termine di ogni chiamata. I record delle chiamate modem sono stati introdotti nel software Cisco IOS versione 11.3A e 12.0T e vengono attivati (sul NAS) utilizzando il comando modem call-record terse. Per ulteriori informazioni sull'implementazione dei record delle chiamate modem, consultare il documento relativo all'utilizzo dei record di chiamata Syslog, NTP e Modem per isolare e risolvere gli errori.
Nell'esempio di record di chiamata del modem mostrato di seguito, il motivo di disconnessione IOS indicato dal disco (raggio) è Lost Carrier/Lost Carrier, mentre il motivo di disconnessione del modem indicato dal disco (modem) è:
A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received DISC frame -- normal LAPM termination
Per ulteriori informazioni sull'interpretazione del motivo della disconnessione del modem, consultare la tabella Motivi di disconnessione del modem Mica.
*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
Registri accounting AAA
I log di accounting AAA possono essere utilizzati anche per determinare il motivo della disconnessione da IOS. Nell'esempio di query SQL AAA seguente è possibile vedere la causa della disconnessione del raggio:
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
Il codice di disconnessione (disk-cause=4), nell'esempio precedente, indica che la disconnessione è stata causata dalla scadenza del timeout di inattività.
Nota: nei log di accounting AAA non viene visualizzato il motivo della disconnessione MICA. La tabella riportata in questo documento non può essere utilizzata per interpretare il motivo della disconnessione Radius.
Per ulteriori informazioni sull'implementazione dell'accounting AAA, consultare il documento sull'implementazione dell'accounting AAA basato su server.
I comandi show modem operating-status e show modem log
Per stabilire il motivo della disconnessione MICA, è possibile usare i comandi IOS show modem operating-status slot/port e show modem log slot/port.
L'output di questo comando mostra il motivo per cui la connessione è stata interrotta o non è quella prevista. Vedere i motivi di disconnessione seguenti per le spiegazioni sui diversi tipi di disconnessione.
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.
Il comando show modem log slot/port visualizza anche il motivo della disconnessione
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
Formato motivo disconnessione
Un motivo di disconnessione è costituito da quattro cifre esadecimali. Le tre cifre esadecimali di ordine inferiore possono essere utilizzate per identificare il motivo della disconnessione. La cifra esadecimale di ordine superiore indica in genere il tipo di motivo di disconnessione o l'ora in cui si è verificato. Le opzioni seguenti sono descritte nella sezione Motivo della disconnessione: Tipi. Ad esempio, se il motivo della disconnessione è 0xWXYZ, 0xXYZ può identificare il motivo della disconnessione mentre 0xW indica quando si è verificato il motivo della disconnessione.
Negli esempi precedenti, 0xF03 e 0x220 identificano il motivo di disconnessione, mentre 0xD e 0x8 indicano quando si è verificato il motivo. Le definizioni dei motivi di disconnessione da MICA sono disponibili nella sezione Motivi di disconnessione da modem MICA.
Per ulteriori informazioni sul funzionamento del modem MICA, vedere la documentazione Verifying Modem Performance and Modem Management Operations (Verifica delle prestazioni del modem e delle operazioni di gestione del modem) nel caso di studio Cisco AS5x00 for Basic IP Modem Services.
Stati modem MICA
| State | Descrizione |
|---|---|
| INATTIVO (#0) | In questo stato, la sessione modem è attualmente inattiva. Lo stato IDLE viene immesso dallo stato TERMINATING dopo aver ricevuto la verifica dal DSP che tutte le operazioni sono state chiuse. |
| CALL_SETUP (#5) | In questo stato, il processore del segnale del modem è preparato per ricevere e generare T1, frequenza multipla (MF), multi-frequenza a doppio tono (DTMF), R1, R2 e segnali di avanzamento delle chiamate. Il modem rimane nello stato CALL_SETUP finché non riceve un messaggio LINK_TERMINATE, SOFTWARE_RESET o INITIATE_LINK dall'host. |
| CONNETTI (#10) | Lo stato CONNECT viene immesso dallo stato CALL_SETUP(#5) solo dopo aver ricevuto il comando host Initiate. In modalità di risposta, la sessione modem ha avviato un'attività, ma non ha ancora iniziato a produrre un tono di risposta. In modalità Origine, la sessione modem ha avviato un'attività, ma non ha ancora rilevato un segnale di risposta. |
| COLLEGAMENTO (#15) | Lo stato LINK viene immesso dallo stato CONNECT solo dopo il rilevamento di un segnale di risposta (origine) o l'avvio di un segnale di risposta (risposta). In modalità di risposta, la sessione modem trasmette un segnale di risposta alla linea. In modalità Origine, la sessione modem ha rilevato la quantità minima (configurabile) di tono di risposta richiesto. Ciò indica che è presente un peer remoto. |
| QC (n. 16) | La connessione rapida (QC) viene attivata o dallo stato LINK o V.8 bis Exchange se QC è abilitato e dopo la ricezione di una sequenza QCA (modalità di origine) o l'invio di una sequenza QCA (modalità di risposta). |
| TRAINING (N. 20) | In questo stato, la sessione modem negozia lo standard di modulazione fisica (configurato) utilizzato durante il collegamento. Lo stato TRAINING viene immesso dallo stato LINK solo in corrispondenza di:
|
| EC_NEGOTIATING (#25) | In questo stato, la sessione modem negozia la correzione dell'errore e il protocollo di compressione dei dati da utilizzare durante il collegamento. Quando le impostazioni sono accettabili per entrambi i modem (l'intersezione tra le funzionalità e la configurazione dei due modem), la negoziazione ha esito positivo. Se l'intersezione è null, il modem disconnette o avvia una sessione connessa senza errori. Lo stato EC_NEGOTIATING viene immesso dallo stato TRAINUP al completamento della sincronizzazione della modulazione fisica. |
| STEADY_STATE (#30) | In questo stato, la sessione modem è in grado di passare i dati sul collegamento. Lo stato STEADY_STATE viene immesso dallo stato EC_NEGOTIATING:
|
| STEADY_STATE_RETRAINING (#35) | In questo stato, la sessione modem è in fase di aggiornamento. Lo stato STEADY_STATE_RETRAINING viene immesso dagli stati STEADY_STATE o STEADY_STATE_SHIFTINGSPEED:
|
| STEADY_STATE_SHIFTINGSPEED (#40) | In questo stato, la sessione modem sta cambiando velocità. Lo stato STEADY_STATE_SHIFTINGSPEED viene immesso dallo stato STEADY_STATE:
|
| STEADY_STATE_ESCAPE (#45) | In questo stato, il modem è ancora connesso al peer remoto, ma l'interfaccia host è in modalità di comando AT. Questo stato viene immesso solo dopo aver ricevuto una sequenza di escape Hayes valida. In modalità fax, questo stato indica che il motore T30 accetta comandi AT dall'host. Per informazioni su una chiamata fax, vedere lo stato STEADY_STATE (#30). |
| IN CHIUSURA (#50) | In questo stato, la sessione modem tenta di scaricare i dati utente e cancellare il contenuto del DSP (Digital Signal Processor). In un Software_reset, non è disponibile uno scaricamento ordinato e il DSP è RESET. Lo stato TERMINATE viene immesso da qualsiasi stato:
|
| IN ATTESA ( #55 ) | La sessione modem è in attesa e sul collegamento non passa alcun dato. Lo stato Bloccato viene immesso dallo stato stabile alla ricezione del messaggio di richiesta MoH (Modem on Hold) (MHReq). Se il modem in attesa è abilitato (Registra S62), il modem trasmette la sequenza MHack (Modem on Hold Acknowledgment) per concedere la richiesta e trasmettere il segnale di risposta (ANSam) quando viene rilevato il silenzio o RT. Se viene rilevato un segnale del menu di chiamata (CM) (per V.8) o una sequenza Quick Connect Acknowledge-QCA (QC - Register S63) nello stato di attesa, il modem deve uscire dallo stato di attesa e rispondere alla sequenza di avvio seguendo rispettivamente le raccomandazioni V.8 o QC (Register S63). Se non viene rilevata alcuna sequenza di avvio dopo il valore di timeout di attesa definito, il modem esce dallo stato di attesa e si disconnette. Se il modem in attesa è disattivato, il modem trasmette MHnack. Se viene rilevato un MHcda dopo la trasmissione di MHnack, il modem si disconnette. Se viene rilevato MHfrr dopo la trasmissione di MHnack, il modem trasmette il segnale di risposta e si prepara a rilevare le sequenze CM (V.8) o QCA (QC - Register S63) dal modem remoto. Per ulteriori informazioni sul modem in attesa, fare riferimento alle specifiche ITU-T V.92 . Nota: lo stato MICA n. 55 in precedenza era lo stato VOICE, che ora è stato rimosso dalle versioni portware 2.9.1.0 e successive. |
| V.8bis EXCHANGE (n. 71) | Questo stato viene immesso dallo stato CONNECT solo dopo il rilevamento di CRe (modalità di origine) o l'avvio di CRe (modalità di risposta). Modalità di risposta: La sessione modem sta trasmettendo alla linea una richiesta di capacità-risposta automatica (CRe). Modalità origine: La sessione modem ha rilevato la funzionalità di richiesta-risposta automatica (CRe). Ciò indica la presenza di un peer remoto. |
| INTERVALLO(#72) | L'intervallo viene immesso dallo stato LINK o QC (Registra S63) all'inizio della stima del ritardo di andata e ritorno (RTDEd). Questo stato si applica solo agli standard V.32 e superiori. |
| INTERVALLO BREVE(#73) | RANGING SHORT viene immesso da QC (Register S63) all'avvio del Round Trip Delay Estimate-Digital Modem (RTDEd) |
| TRENO HD (n. 74) | Il treno HD (Half Duplex Trainup) può essere preso da RANGING o da RANGING SHORT all'inizio dell'allenamento del filtro di adattamento. Ciò vale per V.22bis e versioni successive. |
| STEADY_STATE_PIAFS_RESYNC(#80) | Se si immette STEADY_STATE_PIAFS_RESYNC, una chiamata Personal Handyphone Internet Access Forum Standard (PIAFS) ha perso la sincronizzazione ed esegue una risincronizzazione. |
| STEADY_STATE_PIAFS_SPEEDSHIFT(#85) | L'immissione di STEADY_STATE_PIAFS_SPEEDSHIFT indica che una chiamata PIAFS sta negoziando un cambio di velocità. Questo è uno stato momentaneo, di transizione. La MICA non rimarrà mai in questo stato. Se la risincronizzazione determina uno spostamento di velocità, MICA passa a questo stato da STEADY_STATE_PIAFS_RESYNC e quindi a STEADY_STATE. Se la risincronizzazione NON determina uno spostamento di velocità, al termine della procedura STEADY_STATE_PIAFS_RESYNC esegue la transizione direttamente a STEADY_STATE. |
Motivi disconnessione modem MICA
Un motivo di disconnessione del modem MICA è costituito da quattro cifre esadecimali. Le tre cifre esadecimali di ordine inferiore identificano in modo univoco il motivo della disconnessione. La cifra esadecimale di ordine superiore indica il tipo di motivo di disconnessione o l'ora in cui si è verificato. Nell'esempio precedente, dove il codice di disconnessione è esadecimale 0xDF03, 0xF03 identifica il motivo della disconnessione, mentre 0xD indica quando si è verificato il motivo della disconnessione (motivo disconnessione: Tipi).
I motivi di disconnessione descritti di seguito non includono il tipo di disconnessione. Per questo motivo, rimuovere la cifra esadecimale all'estrema sinistra e confrontare le cifre rimanenti con le opzioni seguenti. Dall'esempio precedente, cercare 0xF03 nella sezione seguente.
Nota: in questo documento, il modem host è il modem MICA sul Cisco Access Server, mentre il modem client è il modem della periferica remota (ad esempio, un modem PC client).
| Tipo disconnessione | Codice motivo disconnessione | Descrizione |
|---|---|---|
| - | 0 | Non si è ancora verificata alcuna disconnessione. Questo codice è visibile se il motivo della disconnessione viene richiesto subito dopo il caricamento del software o durante una chiamata, prima dello stato stabile. |
| Motivi generali di disconnessione (classe 0) | ||
| 2 | 0x001 | Cisco IOS ha terminato bruscamente la chiamata per qualche motivo, ad esempio perché il layer 1 si è abbassato sull'intervallo fisico contenente la chiamata. |
| 2 | 0x002 | Terminazione livello di correzione errori (EC). |
| 2 | 0x003 | L'attività di decompressione MNP5 (Microcom Network Protocol 5) ha ricevuto un token non valido nel flusso di dati. Il motivo della disconnessione si verifica durante la modalità dati (0x3003). È probabile che si sia verificato un errore logico nell'implementazione della decompressione o della correzione degli errori da parte del modem o del partner. (C'è anche la possibilità di un errore di linea fortuito o di memoria RAM). |
| 2,4,6 | 0x004 | L'attività di decompressione V.42bis o V.44 ha ricevuto un token non valido nel flusso di dati. Questo motivo di disconnessione può verificarsi durante la modalità dati (0x4004). È probabile che si sia verificato un errore logico nell'implementazione della decompressione o della correzione degli errori da parte del modem o del partner. (C'è anche la possibilità di un errore di linea fortuito o di memoria RAM). Per V.44, questo codice è integrato dal campo di informazioni di collegamento diagnostico index 119 (un campo di informazioni a otto byte utilizzato come strumento per il debug). |
| 2 | 0x005 | Errore software MICA. Il codice di errore per questo motivo di disconnessione è 0x4005. Si è verificato un errore software MICA che indica una variabile di stato del coprocessore non valida. |
| 6 | 0x006 | Il comando ATH è stato rilevato dal modem locale. Questo motivo di disconnessione si verifica durante la modalità dati (0xC006 e 0xE006). Il comando ATH (Hangup) è stato rilevato dal modem locale (MICA). Ad esempio, durante una chiamata in uscita da IOS, dopo la connessione della chiamata, l'interfaccia IOS DTE ha cancellato la chiamata trasmettendo un comando ATH in banda. |
| 3 | 0x007 | Comando AT dial interrotto. Il comando AT dial è stato interrotto dal comando any key abort. Ad esempio, il modem host genera una chiamata. Durante la connessione, prima di STEADY STATE, premendo un tasto qualsiasi il comando AT dial viene interrotto. |
| 3 | 0x008 | La chiamata ha impiegato troppo tempo per completare la connessione. Si noti che il timer S7 (attendere il vettore dopo la composizione) è scaduto per questa disconnessione. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (0x6008). Il modem host ha impiegato troppo tempo per stabilire una connessione a causa di un nuovo training. Le cause sono: difficoltà a scegliere (negoziare) uno standard di livello I (ad esempio, interrompere la chiamata prima di tornare con motivo di disconnessione 0x6102) o una combinazione di livelli I e II che richiede troppo tempo. Ad esempio, la negoziazione della correzione degli errori richiede molto tempo prima di una nuova preparazione o a causa di errori di bit introdotti quando il modem client tenta di connettersi a una velocità aggressiva (il ricevitore del modem client tenta di connettersi a una velocità che non è in grado di sostenere). Questo tipo di sconto viene applicato al CSR. La disconnessione può inoltre verificarsi se il modem di risposta non sente alcun segnale proveniente dal canale (ad esempio se il mittente non è un modem). |
| 2 | 0x009 | DSP reimpostato (comando, interno o spontaneo). Il codice di errore per questo motivo di disconnessione è 0x4009. Il DSP all'interno del modem host è stato reimpostato dal processore di controllo (CP) o dal processore di segnale (SP). Il CP reimposta il DSP se i messaggi di posta dal CP all'SP non vengono riconosciuti. Se si verifica un errore di incoerenza interno, l'SP viene reimpostato automaticamente. |
| 4,6 | 0x00A | Ricezione di una parola di codice STEPUP non valida. Specifica la ricezione di una parola di codice STEPUP quando il valore di C2 (dimensione parola di codice corrente) supera N1 (dimensione massima parola di codice: negoziato) ed è valido solo per V.44 e V.42bis. |
| 4,6 | 0x00B | Ricezione di una parola in codice V.42bis non valida. Specifica la ricezione di una parola in codice, in qualsiasi momento, uguale a C1 (voce di dizionario vuota successiva) ed è valida per V.42bis. (La ricezione di una parola in codice = C1 non è consentita in V.42bis, ma è consentita in V.44). |
| 4,6 | 0x00C | Ricezione di un token non valido (troppo grande) in V.44 o V.42bis. Ciò significa che le dimensioni della parola in codice V.42bis o V.44 ricevute superano il massimo negoziato. Specifica la ricezione di una parola di codice, in qualsiasi momento, maggiore di C1 (voce di dizionario vuota successiva) ed è valida per V.44 e V.42bis. |
| 4,6 | 0x00D | Ricezione di un codice di comando riservato V.44 o V.42bis. Specifica la ricezione di un codice di comando riservato ed è valido per V.44 e V.42bis. |
| 4,6 | 0x00E | V.42bis o V.44 ha ricevuto una parola in codice maggiore della successiva voce di dizionario vuota. Ricezione di un carattere STEPUP V.44 non valido. Indica la ricezione di un codice di controllo STEPUP che causerebbe il superamento del valore di C5 (dimensione ordinale). Questa opzione è valida solo per V.44. |
| 4,6 | 0x00F | Dizionario V.44 Rx completo. Specifica la ricezione di una parola di codice che non è un dizionario reimpostato quando l'albero dei nodi Rx è pieno. Valido solo per V.44. |
| 4,6 | 0x010 | Cronologia Rx V.44 Completa. Specifica la ricezione di una parola di codice che non è un dizionario reimpostato quando la cronologia Rx è piena. Valido solo per V.44. |
| 4,6 | 0x011 | Superate Le Dimensioni Della Stringa Rx Non Valide Di V.44/V.42bis. Specifica la ricezione di una parola di codice che causa il superamento della dimensione massima negoziata della stringa. È valido per V.44 e V.42bis. |
| 4,6 | 0x012 | Errore di negoziazione V.44 Specifica che si è verificato un errore di negoziazione V.44. Per V.44, questo codice è completato dall'indice 119 del campo delle informazioni di collegamento diagnostico. L'indice del campo delle informazioni di collegamento diagnostico è un campo di informazioni di otto byte utilizzato come strumento di debug. |
| 4,6 | 0x013 | Si è verificato un errore di compressione V.44 Specifica che si è verificato un errore di compressione V.44. Per V.44, questo codice è completato dall'indice 119 del campo delle informazioni di collegamento diagnostico. L'indice del campo delle informazioni di collegamento diagnostico è un campo di informazioni di otto byte utilizzato come strumento di debug. |
| Condizioni segnalate dal DSP (Classe 1) | ||
| 0x1xx | Condizioni DSP segnalate da SPE | |
| 3,4,5 | 0x100 | Il DSP ha perso il segnale vettore. ovvero MICA ha rilevato una perdita del vettore del modem client. Questo motivo di disconnessione si verifica durante la configurazione della chiamata e la modalità dati (ovvero 0x6100, 0x8100 e 0xA100). Il DSP MICA ha interrotto l'ascolto della portante per un periodo superiore al valore specificato nel registro S10 (ritardo di interruzione dopo la perdita della portante). Ciò può significare che il percorso di conversazione è andato via o che il client ha smesso di trasmettere. Se è attivo un protocollo di layer II (V.42 e/o V.42bis), sarebbe anormale vedere una tale disconnessione. Questo motivo di disconnessione si verifica talvolta durante la negoziazione EC (prima della modalità dati). In altre parole, il layer I è stato negoziato con successo (determinando un rilevamento del segnale portante) e la disconnessione si verifica durante il tentativo di stabilire il protocollo di layer II (V.42 e/o V.42bis). Le cause più comuni sono l'interruzione della chiamata da parte degli utenti prima che venga stabilita una connessione. Chiamata accidentale, avvii interrotti e timeout delle applicazioni client a causa di tempi di connessione eccessivamente lunghi (ad esempio, ripetizione di più sessioni durante la negoziazione di layer I). Questo tipo di errore viene valutato rispetto a CSR. La condizione di perdita della portante può verificarsi anche durante la normale modalità dati quando il client lascia improvvisamente la portante. La causa più comune è una disconnessione non negoziata o sporca da parte del modem client, ovvero il modem client rifiuta il segnale vettore. Questo problema può verificarsi se il collegamento viene interrotto in modo improvviso (ovvero a causa di un errore di rete) e il modem client viene spento per interrompere la chiamata. Questa condizione si può anche verificare con modem client più economici che non implementano i protocolli di cancellazione di layer I e/o II su un drop DTR. Per un numero elevato di modem client, si tratta di una disconnessione normale. Quando il modem client esegue una disconnessione sporca, si verifica una race condition tra 0xA103, 0xA100 e 0xDF06. Se il DSP nel modem host rileva una perdita della portante, 0xA100 prevale ed è indicato come motivo della disconnessione. Se il DSP non rileva una perdita della portante e si riallena fino a raggiungere il limite Register S40, 0xA103 vince. Se la rete rileva che la chiamata è stata disconnessa e segnala al router di disconnettersi, 0xDF06 ha la precedenza. Questo motivo di disconnessione non viene preso in considerazione nel caso in cui il modem host sia in modalità dati. |
| 3 | 0x101 | Questo si verifica quando il processore di segnale (SP) si trova nella fase di rilevamento della risposta al tono (ABT) quando si verifica un errore di chiamata. |
| 3 | 0x102 | Chiamata interrotta durante l'attivazione del modem a causa di modulazione incompatibile o linea difettosa. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (0x6102). Ciò può essere indicativo di tentativi di negoziare una modulazione non supportata, come una modulazione proprietaria Rockwell legacy (K56Plus, V.FC e così via). Altre possibili cause sono i guasti del DSP dovuti a gravi disfunzioni della linea, rumori di impulso, interruzione dell'addestramento, parametri di modulazione incompatibili, e forse l'impossibilità di selezionare correttamente uno standard Layer I. Questo tipo di sconnessione è da considerarsi come una contropartita della RSI. |
| 4,5 | 0x103 | Troppi cambi di velocità o ritreni consecutivi. Il limite di riavvio è specificato con Register S40. Questo motivo di disconnessione si verifica durante la configurazione della chiamata e la modalità dati (0x6103, 0x8103 e 0xA103). Durante l'avanzamento di una chiamata, si sono verificati troppi ritorni che hanno reso la chiamata inefficace, in quanto la velocità dei dati sarebbe stata così scarsa da essere inutile. Le condizioni possibili sono il caso in cui il modem client non completa il protocollo di cancellazione (ad esempio, il telefono ha interrotto la chiamata al centro della connessione) e MICA tenta di recuperare la chiamata effettuando dei riavvii. Una volta raggiunto il limite di ricongiungimento (il limite di ricongiungimento può essere modificato utilizzando il registro S40), MICA rifiuta la chiamata e segnala il motivo della disconnessione. In alcune circostanze (channelized T1/E1) questo tipo di disconnessione può essere considerato una normale disconnessione a stato STABILE. in alternativa, ciò potrebbe semplicemente essere il risultato di una disconnessione sporca dovuta a possibili errori di linea da cui MICA non può recuperare. Pertanto, questo tipo di disconnessione non è considerato ai fini della RSI, poiché la chiamata è già stata stabilita. Questo motivo di disconnessione può verificarsi anche durante la negoziazione EC quando il modem client è eccessivamente aggressivo con la velocità di connessione iniziale e non è in grado di mantenere la chiamata (come è stato osservato con i vecchi modem client USRobotics). Questo tipo di disconnessione non è valido per la CSR. Quando il modem client esegue una disconnessione sporca, si verifica una race condition tra 0xA103, 0xA100 e 0xDF06. Se il DSP (Digital Signal Processor) all'interno del modem host rileva una perdita della portante, 0xA100 prevale ed è indicato come motivo della disconnessione. Se il DSP non rileva una perdita della portante e si riallena fino a raggiungere il limite S40 del registro, 0xA103 vince. Se la rete rileva che la chiamata è stata disconnessa e segnala al router di disconnettersi, 0xDF06 ha la precedenza. Questo motivo di disconnessione non viene preso in considerazione nel caso in cui il modem host sia in modalità dati. |
| 3 | 0x104 | Problema durante il rilevamento della fine del segnale di risposta (ABT). Errore di negoziazione o rumore eccessivo durante l'addestramento V.34. I modem host rispondono ed inviano V.8bis e modulati 2100Hz answer tones (ABT) con inversione di fase, ma incontrano un rumore eccessivo durante la sequenza di allenamento. Cercare gli errori sul percorso dal modem chiamante al modem rispondente in una o in entrambe le direzioni. Un comportamento simile si verifica quando la latenza della PSTN (Public Switched Telephone Network) per la connessione remota supera un secondo e i modem non sono in grado di addestrare le funzioni di eliminazione dell'eco. Altre possibili cause sono:
|
| 3 | 0x105 | Operazione SS7/COT (Continuity Test) completata. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (0x6105). Operazione SS7/COT (Continuity Test) completata. |
| 3 | 0x106 | Operazione SS7/COT (Continuity Test) non riuscita: Timeout T8/T24 in attesa del segnale attivato. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (ovvero 0x6106). Operazione SS7/COT (Continuity Test) non riuscita. Timeout del timer T8/T24 durante l'attesa del segnale. |
| 3 | 0x107 | Operazione SS7/COT (Continuity Test) non riuscita: Timeout T8/T24 in attesa del segnale disattivato. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (0x6107). Operazione SS7/COT non riuscita. Timeout del timer T8/T24 durante l'attesa del segnale disattivato. |
| 4 | 0x108 | Modem On Hold (MOH) eliminato da MICA. Il modem client ha ricevuto la richiesta di cancellazione del modem in attesa. V.92 specifica che il motivo della liquidazione può essere:
|
| 4 | 0x109 | È stato raggiunto il valore di timeout MOH (Modem On Hold). |
| Condizioni locali CE (Classe 2) | ||
| 0x2xx | Condizioni locali CE | |
| 3 | 0x201 | Mai ricevuto un frame LR (richiesta di collegamento) durante la negoziazione. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (ovvero 0x6201). Ciò significa che il modem host non ha mai ricevuto il frame LR durante la negoziazione della correzione degli errori. Il modem peer potrebbe non supportare MNP nella versione V.42. |
| 3 | 0x202 | Ricevuto un frame LR con un parametro non valido (PARAM1). Il frame LR (Received MNP Link Request) contiene un PARAM1 errato o imprevisto. Per ulteriori informazioni su PARAM1, fare riferimento alla specifica V.42. |
| 3 | 0x203 | Ricevuto frame LR (Link Request) incompatibile. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (0x6203). Il frame MNP LR ricevuto non è compatibile con le impostazioni del modem host per EC. |
| 4,5 | 0x204 | Troppe ritrasmissioni consecutive. Questo motivo di disconnessione si verifica durante la configurazione della chiamata e la modalità dati (0x8204, 0xA204 e 0x6204). Questo motivo di disconnessione può essere causato da rumore sulla linea. Ad esempio, il modem host trasmette i dati al modem client, ma la presenza di rumori sulla linea causa la ricezione errata o non corretta dei dati da parte del client. Un rumore eccessivo può portare a ritrasmissioni eccessive. Il modem client potrebbe anche essersi disconnesso senza che il modem MICA se ne accorga. Pertanto, il modem host ritrasmette continuamente, senza sapere che il modem client non è più presente. A volte, quando la chiamata si connette in un protocollo di compressione (EC) (procedura di accesso al collegamento per modem (LAPM) o protocollo di rete Microcom (MNP)), MICA non è in grado di trasmettere un frame al modem client. Il modem client non riconosce la trasmissione iniziale di MICA, quindi non risponde ai polling S19 (Error Correction Retransmission Limit) (l'impostazione predefinita è 12), quindi MICA disconnette la chiamata. Una causa può essere che la portante nel percorso di trasmissione si è deteriorata notevolmente mentre il client non è riuscito a eseguire il downshift. Un'altra causa potrebbe essere un problema con il motore EC del client (come accade su un sistema Winmodem se Windows non risponde). |
| 6,7 | 0x205 | Timeout di inattività, MNP Link Disconnect (LD) inviato. Questo motivo di disconnessione si verifica durante la modalità dati (0xC205 e 0xE205). Il modem host invia al modem client un frame LD che indica che si è verificato un timeout di inattività. |
| 4,5 | 0x206 | Errore del protocollo EC. Questo motivo di disconnessione si verifica durante la modalità dati (0x8206 e 0xA206). Errore generale del protocollo catch-all. Indica che si è verificato un errore del protocollo LAPM o MNP EC. |
| 3 | 0x210 | Nessun protocollo di fallback EC disponibile. Questo motivo di disconnessione si verifica nella configurazione delle chiamate (0x6210). Negoziazione della correzione degli errori non riuscita. Chiamata terminata. Nessun protocollo di fallback per la correzione degli errori disponibile. S25 (fallback del protocollo di collegamento) determina il protocollo di fallback disponibile. Le opzioni sono frame asincrono, frame sincrono o disconnetti (hangup). |
| 3 | 0x211 | Frame di identificazione ID di eXchange (XID) non ricevuto durante la negoziazione. Questo motivo di disconnessione si verifica durante la configurazione della chiamata (0x6211). Ciò significa che il modem host non ha mai ricevuto il frame XID durante la negoziazione della correzione degli errori. Il modem client potrebbe non supportare LAPM all'interno di V.42. |
| 3 | 0x212 | Il frame XID ricevuto non è compatibile con le impostazioni locali. Questo motivo di disconnessione si verifica nella configurazione delle chiamate (0x6212). Il frame XID ricevuto non è compatibile con le impostazioni del modem host. Ad esempio, il modem client può indicare MNP5, mentre il modem host indica solo V.42 e V.42bis. |
| 3,4,5 | 0x220 | Frame Disconnect (DISK) ricevuto. Si tratta del normale scollegamento LAP-M. Questo motivo di disconnessione si verifica durante la configurazione della chiamata e la modalità dati (0x6220, 0x8220 e 0xA220). La chiamata è terminata normalmente con una cancellazione dal lato client. (ovvero, un pacchetto di disconnessione V.42 è stato inviato dal modem client al modem NAS.) Il modem client ha eliminato il DTR e ha negoziato in modo pulito un protocollo di cancellazione. |
| 3,4,5 | 0x221 | Frame DM ricevuto. Il peer potrebbe disconnettersi. Il motivo della disconnessione si verifica nella configurazione delle chiamate e nella modalità dati (0x6221, 0x8221 e 0xA221). Il modem client indica che è in corso la disconnessione. Durante la configurazione della chiamata, questo motivo indica che il modem client rinuncia alla negoziazione della correzione degli errori. |
| 4,5 | 0x222 | È stato ricevuto un numero di sequenza non valido. Il motivo della disconnessione si verifica in modalità dati (0x822 e 0xA222). Il modem host ha ricevuto un frame di correzione errori LAPM o MNP con un numero di sequenza o un numero di riconoscimento errato. Un frame LD o Frame Reject (FRMR) viene inviato al modem client per indicare che il modem host si sta disconnettendo. |
| 4,5 | 0x223 | Ricevuto frame SABME in stato stazionario. Il motivo della disconnessione si verifica in modalità dati (0x8223 e 0xA223). Questo errore viene interpretato come un errore del protocollo di correzione dell'errore LAPM in stato stabile. Significa che il modem client potrebbe essere stato reimpostato a causa della ricezione di un Frame Reject (FRMR). |
| 4,5 | 0x224 | Ricevuto frame MNP XID in stato stabile. Il motivo della disconnessione si verifica in modalità dati (0x8224 e 0xA224). Questo errore viene interpretato come un errore del protocollo di correzione dell'errore LAPM in stato stabile. Significa che il modem client potrebbe essere stato reimpostato a causa della ricezione di un Frame Reject (FRMR). |
| 4,5 | 0x225 | Ricevuto frame LR MNP in stato stazionario. Il motivo della disconnessione si verifica in modalità dati (0x8225 e 0xA225). Questo errore viene interpretato come un errore del protocollo di correzione dell'errore MNP in stato stabile. Significa che il modem client è stato reimpostato. |
| Condizioni specifiche del protocollo PIAFS (Classe 2, continua) | ||
| 3,4 | 0x230 | La lunghezza di un messaggio ricevuto è inferiore alla lunghezza minima definita per quel tipo di messaggio. |
| 3,4 | 0x231 | Ricevuto tipo di frame PIAFS sconosciuto o non implementato. Sono inclusi FI (tipo di frame principale) e la classe di negoziazione, sincronizzazione o controllo (sottotipo). |
| 3,4 | 0x232 | CFI (Control Frame Identifier) PIAFS sconosciuto. È stato ricevuto un frame di controllo con un ID sconosciuto o non implementato per la relativa classe. Si noti che i frame continui e utente non sono implementati e che non esistono frame di notifica noti. |
| 3,4 | 0x233 | Negoziazione della comunicazione PIAFS non riuscita. Dopo la sincronizzazione iniziale, vengono scambiati i frame Req/Ack dei parametri di comunicazione. Parametri inaccettabili o risposta NAK (Negative Acknowledgment) rilevata dall'iniziatore. Nota: MICA può funzionare solo come client/iniziatore a scopo di test |
| 3,4 | 0x234 | Negoziazione PIAFS ARQ non riuscita. Dopo la risincronizzazione, i frame ARQ Request (Req)/Acknowledgment (Ack) vengono scambiati. Parametri inaccettabili o risposta Nak rilevata dall'iniziatore. Nota: MICA può funzionare solo come client/iniziatore a scopo di test |
| 3,4 | 0x235 | Rilevati problemi relativi al protocollo di trasferimento del controllo PIAFS. L'iniziatore ha ricevuto un Ack/Nak/Rsp il cui ID, classe e sequenza non corrispondono all'originale Req/Ntf. Nota: MICA può operare solo come client o iniziatore a scopo di test |
| 3,4 | 0x236 | Questo motivo di disconnessione non indica più la ricezione di un frame di richiesta DataLinkRelease. Ora indica una disconnessione senza un motivo di disconnessione generato in precedenza. Ciò significa che MICA sta scollegando una chiamata, ma scopre che non è stato inserito alcun motivo. |
| 3,4 | 0x237 | Il timer di attesa ricezione sincronizzazione PIAFS (T001) è scaduto. Questo timer inizia quando viene inviato un frame di richiesta di sincronizzazione e si arresta quando viene rilevato un frame di ricezione di sincronizzazione. Questo errore si verifica solo quando la porta MICA funziona come client o come iniziatore e si verifica solo durante il test. Il valore predefinito è 15 secondi. |
| 3,4 | 0x238 | Il timer di trasmissione di ricezione post-sincronizzazione PIAFS T002 è scaduto. Il timer inizia quando viene inviato un frame di ricezione sincrona e si arresta quando viene rilevata una ricezione sincrona (collisione) o un frame di controllo. Questo errore si verifica solo quando la porta MICA funziona come server (modalità di risposta), che è la modalità operativa normale. Il valore predefinito è 15 secondi. |
| 3,4 | 0x239 | Il timer di attesa per la richiesta di sincronizzazione PIAFS T003 è scaduto. Questo timer viene avviato quando vengono rilevati errori FCS continui e si arresta quando viene rilevato un frame di richiesta di sincronizzazione valido. Questo errore si verifica solo quando la porta MICA funziona come server (modalità di risposta), che è la normale modalità operativa. Il valore predefinito è 15 secondi. |
| 3,4 | 0x23A | Timer PIAFS T101 scaduto: timer di attesa conferma frame di controllo. Avvia quando viene inviata una richiesta o una notifica del frame di controllo, si arresta quando il frame viene confermato. Questo errore si verifica solo quando la porta MICA funziona come client o come iniziatore e si verifica solo durante il test (dieci secondi). |
| 3,4 | 0x23B | PIAFS: è stato ricevuto il numero di sequenza FBI (ACK) fuori dall'intervallo negoziato o il valore FBI=0 con un frame di dati non vuoto. |
| 3,4 | 0x23C | PIAFS: ricevuto FFI (numero di sequenza MSG) non compreso nell'intervallo negoziato o FFI=0. |
| 3,4 | 0x23D | PIAFS: la finestra dei dati negoziati è minore del valore RTF (round trip delay). Questo errore non viene più pubblicato da Portware e non deve essere mai visualizzato. |
| 3,4 | 0x23E | PIAFS: il campo lunghezza dati del messaggio è troppo grande. Deve essere 0-73. |
| 3,4 | 0x23F | Errore interno PIAFS: La chiamata SREJ ha restituito un codice di errore. |
| 3,4 | 0x240 | Errore generale del protocollo PIAFS. Attivazione per gli errori a cui non è associato un motivo di disconnessione. |
| 3,4 | 0x241 | PIAFS: negoziazione del protocollo non riuscita. Nessun protocollo (ad esempio, Protocollo di trasferimento dati a velocità fissa, Velocità variabile DTP di tipo 1) era accettabile per entrambe le stazioni. Protocolli non accettabili sono DTP Variable Speed Type3 o Real Time Protocol. |
| 3,4 | 0x242 | PIAFS: il valore RTF (round trip delay) misurato non è compreso nell'intervallo definito (accettabile). |
| 3,4 | 0x243 | Errore interno PIAFS: evento sconosciuto nel gestore eventi. Un'istruzione switch è passata al caso predefinito. |
| 3,4 | 0x244 | Timeout di risposta SP (Signal Processor) durante uno spostamento di velocità PIAFS 2.1. Il CP di Mica non ha visto la risposta del cambio di velocità entro 200 msec. |
| 3,4 | 0x245 | Il CP di Mica ha rilevato informazioni di controllo incoerenti nelle strutture di controllo condivise del CP/SP. In particolare, il buffer di dati presenta un offset di testa o di coda che non rientra nei limiti del buffer di dati (0-63). |
| Ricevuto comando MNP o LAPM Protocol non valido dal partner (classe 3) | ||
| 4.5 | 0x3xx | È stato rilevato un codice di comando non valido. Il comando sconosciuto ricevuto è nelle ultime due cifre. In risposta, viene inviato un frame MNP LD o LAP-M Frame Reject (FRMR). |
| Il partner LAPM indica un errore del protocollo MICA (Classe 4) | ||
| 4,5 | 0x4xx | Condizioni EC indicate dal client nel frame LAP-M FRMR. Il motivo della mappatura dei bit è nelle ultime due cifre. |
| 4,5 | 0x401 | LAPM: il peer segnala un comando errato. Il modem host ha ricevuto un frame FRMR dal modem client. Il frame FRMR ricevuto indica che il modem client ha ricevuto un frame di correzione dell'errore dal modem host che conteneva un comando errato. |
| 4,5 | 0x403 | LAPM: il peer segnala che il campo dati non è consentito o ha una lunghezza errata (U frame). Il modem host ha ricevuto un frame FRMR dal modem client. Il frame FRMR ricevuto indica che il modem client ha ricevuto un frame di correzione dell'errore dal modem host che conteneva un campo dati non consentito o contenente un campo dati di lunghezza non corretta (frame U). |
| 4,5 | 0x404 | LAPM: La lunghezza del campo dati dei report peer è maggiore di N401 (la lunghezza massima del campo di informazioni specificata in V.42), ma dispone di una sequenza FCS (Frame Check Sequence) valida. Il modem NextPort ha ricevuto un frame FRMR dal modem client. Il frame FRMR ricevuto indica che il modem client ha ricevuto un frame di correzione dell'errore da NextPort che conteneva una lunghezza del campo dati maggiore del numero massimo di ottetti che possono essere trasportati nel campo di informazioni (N401) di un frame IP, un frame SREJ, un frame XID, un frame UI o un frame TEST. La sequenza di controllo del fotogramma è buona. |
| 4,5 | 0x408 | LAPM: il peer segnala un numero di sequenza di ricezione errato o N(R). Il modem host ha ricevuto un frame FRMR dal modem client. Il frame FRMR ricevuto indica che il modem client ha ricevuto un frame di correzione dell'errore dal modem host che conteneva un numero di sequenza di ricezione errato. |
| Il partner MNP indica un errore di disconnessione o di protocollo MICA (Classe 5) | ||
| 4,5 | 0x5xx | Condizioni EC indicate dal client nel frame MNP LD. Il campo Motivo è nelle ultime due cifre |
| 3 | 0x501 | MNP: peer non ha mai ricevuto il frame LR. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica che il modem client non ha mai ricevuto una richiesta di collegamento dal modem host. |
| 3 | 0x502 | MNP: peer segnala che il frame LR ha un parametro errato #1. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica che il modem client ha ricevuto un frame di richiesta di collegamento dal modem host contenente un PARAM1 errato (ovvero imprevisto). Per ulteriori informazioni su PARAM1, fare riferimento alla specifica V.42. |
| 3 | 0x503 | MNP: il frame LR dei report peer non è compatibile con la relativa configurazione. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica che il modem client ha ricevuto un frame LR dal modem host che non è compatibile con la configurazione del modem client. |
| 4,5 | 0x504 | MNP: peer segnala troppe ritrasmissioni CE consecutive. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica che il modem client ha ricevuto troppe ritrasmissioni consecutive. |
| 4,5 | 0x505 | MNP: timer inattività report peer scaduto. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica che l'host del modem client (DTE) non ha trasmesso i dati al modem client entro un determinato periodo di tempo. |
| 3 | 0x506 | MNP: peer segnala errori. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica che il modem client ha ricevuto un errore di protocollo MNP. |
| 3 | 0x5FF | Disconnessione MNP normale. Il modem host ha ricevuto un frame LD dal modem client. Il frame LD ricevuto indica una normale terminazione MNP, che indica che il DTR del modem client è stato interrotto o che ha ricevuto un comando +++ o ATH. Questo motivo di disconnessione si verifica nella configurazione della chiamata e in modalità dati (0x65FF, 0x85FF e 0xA5FF). Il modem host ha ricevuto un LED, che indica la terminazione normale. La chiamata è terminata normalmente con una corretta cancellazione dal lato client (ad esempio, un pacchetto di disconnessione è stato inviato dal modem client al modem host). Il modem client ha eliminato il DTR e ha negoziato in modo pulito un protocollo di cancellazione. |
| Il partner PIAFS indica un errore di disconnessione o di protocollo MICA (classe 6) | ||
| 3,4 | 0x6xx | MICA ha ricevuto un PIAFS DataLinkRelease (PDLR) con motivo xx (vedere i valori dettagliati di seguito). |
| 3,4 | 0x61x | Classe normale per PIAFS DataLinkRelease (PDLR): 0 - Rilascio normale. 1 - Versione normale. Continuazione del collegamento dati non consentita. 2 - Versione normale, continuazione del collegamento dati. ... Altre classi normali: classi non definite specifiche di alcuni dispositivi client. |
| 3,4 | 0x62x | Classe utilizzo risorse non consentito per PIAFS DLR (condizioni di disponibilità): 8 - DTE occupato. 9 - Ostruzione temporanea. ... Altre risorse utilizzano classi non possibili - classi non definite specifiche di alcuni dispositivi client. |
| 3,4 | 0x63x | Classe di utilizzo del servizio non consentita per DLR PIAFS (parametri non validi). 9 - Impossibile impostare il parametro della richiesta. A - Impossibile impostare il parametro della richiesta al momento. .. Altre classi di utilizzo del servizio non possibili - classi non definite specifiche di alcuni dispositivi client. |
| 3,4 | 0x64x | Classe servizio non ancora fornita per PIAFS DLR. 1 - Indicazione parametro non ancora fornita. ... Altri servizi classi non ancora fornite - classi non definite specifiche di alcuni dispositivi client. |
| 3,4 | 0x65x | Classe di contenuto delle informazioni non valida per PIAFS DLR. 8 - Attributo del terminale non corrispondente. ... Altre classi di contenuto delle informazioni non valide: classi non definite specifiche di alcuni dispositivi client. |
| 3,4 | 0x66x | Classe di errore di sequenza per PIAFS DLR 0 - Parametri essenziali insufficienti. 1 - Contenuto delle informazioni non definito o non ancora fornito. 5 - La condizione e il segnale ARQ non corrispondono. 6 - Il timer scade. ... Altre classi di errore Sequence: classi non definite specifiche di alcuni dispositivi client. |
| 3,4 | 0x67x | Altre peculiarità classe per PIAFS DLR. 1 - Durante chiamata vocale. ... Altre classi particolari: classi non definite specifiche di alcuni dispositivi client. |
| Disconnessione richiesta da host/IOS (classe 31) | ||
| 6,7 | 0x1fxx | Disconnessione avviata dall'host. Il valore è la somma del valore 0x1F00 e del valore SessionStopCommand. Questo è l'altro motivo per cui l'host viene terminato. Il motivo dell'host è indicato nei byte di ordine inferiore xx. |
| 3,6,7 | 0x1f00 | Disconnessione avviata da un host non specifico. Il valore è la somma del valore 0x1F00 e del valore SessionStopCommand. Motivo della disconnessione avviata da IOS catch-all. Viene utilizzato per tutte le disconnessioni non standard. Ad esempio, la causa potrebbe essere la decisione del software di gestione del modem di terminare la chiamata. Una possibile spiegazione è un errore di autenticazione di livello superiore RADIUS, TACACS o un'altra applicazione che invia un segnale DTR al modem host. Questo tipo di disconnessione non viene considerato in CSR quando il modem host è in modalità dati. |
| 3 | 0x1f01 | Numero composto occupato. L'host indica che il numero composto è occupato. La connessione è stata interrotta. |
| 3 | 0x1f02 | Il numero composto non ha risposto. L'host indica che il numero composto non ha risposto. La connessione è stata interrotta. |
| 3,6,7 | 0x1f03 | DTR virtuale eliminato. Questo stato viene riflesso dal redirector della porta I/O che attualmente utilizza il modem. Disconnessione interrotta. L'host ha eliminato la riga DTR virtuale. Questa causa generica di disconnessione è inizializzata dal software Cisco IOS. Le possibili cause sono il timeout di inattività, la ricezione di TERMREQ LCP PPP, un errore di autenticazione, l'interruzione Telnet e così via. Per determinare il motivo della disconnessione, esaminare il motivo della disconnessione Radius dal comando call-record del modem o da Authentication, Authorization, and Accounting (AAA). |
| 6,7 | 0x1f04 | Comando ATH (hangup) rilevato dall'host locale. |
| 3 | 0x1f05 | Nessun accesso alla rete di telecomunicazioni. L'host non è riuscito ad accedere alla rete (ISDN). Disconnessione effettuata. |
| 3,4,5 , | 0x1f06 | La rete ha indicato la disconnessione. Questa situazione può verificarsi prima o durante la modalità dati. Una disconnessione 0x1f06 significa che IOS ha ricevuto un segnale di interruzione del circuito dalla rete del circuito (ossia, un segnale di disconnessione Q.931 o un segnale di connessione CAS), e IOS ha quindi comunicato questo a MICA quando ha indicato a MICA di interrompere. Se MICA raggiunge la modalità dati e non è stato negoziato un protocollo EC (LAPM o MNP4), potrebbe trattarsi di una normale disconnessione. Questo motivo può essere generato anche quando gli utenti di Windows 95 o 98 DUN (Dial Up Networking) premono Annulla durante l'allenamento e prima che la chiamata raggiunga lo stato stabile. Inoltre, se il client disconnette improvvisamente la linea telefonica o spegne il modem, il motivo della disconnessione è considerato normale. Tuttavia, se la connessione ha negoziato EC (LAPM o MNP4), e quindi in modalità dati, questo motivo di disconnessione potrebbe essere generato da una disconnessione dirty (ossia, una disconnessione che non è una terminazione di chiamata normale). Ciò è dovuto al fatto che se il client DTE (in modalità dati) disconnette la chiamata in modo ordinato (con DTR drop o +++/ATH), il modem client invierà un LAPM DISK (o MNP LD) prima che si agganci, generando così un motivo di disconnessione 0x220 piuttosto che 0x1f06. Quindi la disconnessione indicata dalla rete è, in questo caso, probabilmente indicativa di un modem client infelice, uno che ha deciso che non poteva più sostenere il vettore per qualche motivo. |
| 3 | 0x1f07 | NAS ha terminato il funzionamento di SS7/COT. Disconnessione interrotta. Il server NAS ha terminato l'operazione SS7/COT (Continuity Test). |
| 3 | 0x1f08 | L'operazione SS7/COT è stata terminata dal router a causa di un timeout T8/T24. |
| - | 0x1fff | Non richiesto. IN CHIUSURA. L'host invia questo motivo di disconnessione quando riceve un messaggio di chiusura non richiesto. |
Motivo disconnessione: Tipi
Il motivo della disconnessione:tipi descrive quando si è effettivamente verificata la disconnessione della chiamata. Possono essere classificati in due tipi principali:durante la configurazione della chiamata e durante la modalità dati (stato stabile). Nella tabella seguente vengono specificati i tipi di motivi di disconnessione più comuni e i relativi valori, come indicato nel motivo di disconnessione.
| Tipo disconnessione | Tipo disconnessione (esadecimale) | Descrizione |
|---|---|---|
| 0 | 0x0... | (non utilizzato) |
| 1 | 0x2... | (non utilizzato) |
| 2 | 0x4... | Altre situazioni. |
| 3 | 0x6... | Condizione durante la configurazione della chiamata. |
| 4 | 0x8... | In modalità dati. Scaricamento dati Rx (da linea a host) OK. La condizione di disconnessione si è verificata in modalità dati. MICA tenta di inviare i dati ricevuti all'host (IOS). Per alcune disconnessioni (ad esempio, PIAFS), questo è l'unico tipo di modalità dati utilizzato; non viene indicata la direzione di cancellazione dei dati. |
| 5 | 0xA... | In modalità dati. Svuotamento dei dati Rx (da linea a host) non riuscito. La condizione di disconnessione si è verificata in modalità dati. MICA tenta di inviare i dati ricevuti all'host (IOS). Nel codice MICA legacy, questo tipo è equivalente al tipo 4 precedente. Anche se IOS visualizza tali disconnessioni come non OK, in realtà non si sono verificati problemi. |
| 6 | 0xC... | In modalità dati. Svuotamento dei dati TX (da host a riga) completato. La condizione di disconnessione si è verificata in modalità dati. MICA tenta di trasmettere i dati dell'host nel buffer (IOS) al modem partner. |
| 7 | 0xE... | In modalità dati. Svuotamento dei dati TX (da host a riga) non corretto. La condizione di disconnessione si è verificata in modalità dati. MICA tenta di trasmettere i dati dell'host nel buffer (IOS) al modem partner. Nel codice MICA legacy, questo tipo è equivalente al tipo 6 precedente. Anche se IOS visualizza tali disconnessioni come non OK, in realtà non si sono verificati problemi. |
Feedback