Razones para la desconexión y estados del módem MICA

Introducción

Este documento describe cómo interpretar los códigos de razón de desconexión de llamada informados por los módem de agrupamiento de canales ISDN de módem (MICA) de Cisco.

Nota: Este documento contiene muchos términos definidos en las normas de la UIT, como V.90, V.44, V.42bis y V.34. Para obtener más información sobre estos términos, consulte la norma ITU-T correspondiente. Los términos especificados en las normas ITU-T no se explican en este documento.

Prerequisites

Requirements

Los lectores de este documento deben tener en cuenta lo siguiente:

Siempre que se elimina o desconecta una llamada que utiliza partes específicas del dominio (DSP) MICA, MICA registra la razón de la desconexión. Puede utilizar este motivo para determinar si la desconexión fue normal. Si no lo fue, puede usarla para rastrear las causas posibles de la falla. Los módems pueden desconectarse debido a una variedad de factores tales como, desconecta el cliente, errores Telco, y caídas de llamadas en el servidor de acceso a la red (NAS). Una razón de desconexión típica es que el DTE (módem cliente o NAS) en un extremo desea cerrarlo. Esta desconexión "normal" indica que la desconexión no se produjo por errores de nivel del módem o de la transmisión. Para mayor información para poder determinar si el motivo de la desconexión es normal, consulte la sección Control del módem general y la calidad de la línea NAS.

Componentes Utilizados

Los módems MICA son utilizados en los siguientes servidores de acceso.

• Cisco 3600 Series routers

• AS5200

• AS5300

• AS5800

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

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

Determinación del estado del módem

Utilice el comando show modem log slot/port para determinar el estado actual de un módem MICA. En este resultado de registro, las entradas más recientes aparecen cerca del final del registro. El estado actual del módem MICA se muestra en el último evento (de cambio) de estado del módem. En el siguiente ejemplo de salida, el estado del módem está inactivo, indicado por el evento de estado del módem marcado 00:00:28. Refiérase a la tabla estados del módem MICA para obtener más información sobre los posibles estados del módem 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

Determinación de la razón de desconexión

Cuando se termina una conexión de módem, el NAS informa dos razones de desconexión: los motivos DTE (IOS) y DCE (MICA). Para comunicar estas razones de desconexión, pueden utilizarse tres métodos primarios:

1. Registros de llamadas del módem Estos informes indican los motivos de desconexión del módem MICA y del software IOS®.

2. Registros de contabilidad de AAA: Éstos informan sólo la razón de desconexión del software IOS.

3. Comandos del IOS: Los comandos tales como show modem operational-status y show modem log informan solamente de la razón de desconexión del módem MICA.

Registros de llamadas del módem

El IOS y el motivo de desconexión del módem para una conexión determinada se muestran en el registro de llamada del módem (MCR). El MCR se envía a un servidor del sistema de registro a través del NAS durante la terminación de cada llamada. Los registros de llamadas del módem fueron introducidos en el software IOS de Cisco 11.3AA y 12.0T y se activan (en NAS) con el comando modem call-record terse. Para obtener más información sobre la implementación de registros de llamadas del módem, consulte el documento Uso de Syslog, NTP y Registros de llamadas del módem para aislar y resolver fallas.

En el registro de llamada del módem de ejemplo que se muestra a continuación, la razón de desconexión del IOS indicada por disk(radius) es Lost Carrier/Lost Carrier, mientras que la razón de desconexión del módem indicada por disk(modem) es:

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

Refiérase a la tabla Motivos de Desconexión del Módem Mica para obtener más información sobre la interpretación del motivo de desconexión del módem.

*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

Registros contables de AAA

Los registros contables AAA también pueden ser utilizados para determinar el motivo de desconexión del IOS. En el ejemplo de consulta SQL AAA a continuación, podemos ver la causa de desconexión del RADIUS:

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

 LOG_ID BLOB_ORDINAL BLOB_DATA
 -------------------------------------------------------------------------------
      
 172.22.87.3  rad_dial     Async20 65004   stop    server=danvers  time=17:36:33   
 date=04/17/2000    task_id=40      timezone=CST    service=ppp     protocol=ip     
 addr=172.22.83.12     disc-cause=4     disc-cause-ext=1021     pre-bytes-in=132        
 pre-bytes-out=139 pre-paks-in=5   pre-paks-out=7 bytes_i

El código de desconexión (disk-cause=4), en el ejemplo anterior, indica que la desconexión fue causada por el vencimiento del tiempo de espera inactivo.

Nota: Los registros de contabilidad AAA no muestran la razón de desconexión de MICA, por lo tanto la tabla proporcionada en este documento no se puede utilizar para interpretar la razón de desconexión de Radius.

Para obtener más información acerca de la implementación de la contabilidad AAA, consulte el documento Implementación de contabilidad AAA basada en el servidor.

Comandos show modem operational-status y show modem log

Pueden utilizarse los comandos del IOS show modem operational-status slot/port y show modem log slot/port para determinar la razón de la desconexión de MICA.

El resultado de este comando muestra por qué se perdió la conexión o por qué la conexión actual no es la esperada. Vea las razones de desconexión a continuación para obtener explicaciones sobre los diferentes tipos de desconexión.

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.

El show modem log slot/port también muestra la razón de desconexión

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 de razón de desconexión

La razón de desconexión consiste en cuatro dígitos hexadecimales. Los tres dígitos hexadecimales de bajo orden pueden usarse para identificar la razón de desconexión. El dígito hexadecimal de orden alto generalmente indica el tipo de motivo de desconexión o la hora en la que ocurrió la razón de desconexión. Estas opciones se describen en la sección Razón de desconexión: Tipos. Por ejemplo, si la razón de desconexión es 0xWXYZ, entonces 0xXYZ puede identificar la razón de la desconexión mientras que 0xW indica cuando ésta ocurre.

En los ejemplos anteriores, 0xF03 y 0x220 identifican la razón de desconexión mientras que 0xD y 0x8 indican cuándo ocurrió la razón de desconexión. Las definiciones de las razones de desconexión del módem MICA se brindan en la sección Razones de desconexión del módem MICA.

Para obtener más información sobre las operaciones del módem MICA, vea la documentación Verificación del Rendimiento del Módem y Operaciones de Administración del Módem en el Caso Práctico de Cisco AS5x00 para Servicios Básicos del Módem IP.

Estados de módem MICA

Estado	Descripción
IDLE (#0)	En este estado, la sesión del módem está inactiva actualmente. El estado IDLE (de inactividad) ingresa a partir del estado TERMINATING (de terminación) al recibir la verificación del DSP de que todas las operaciones se han cerrado.
CALL_SETUP (n.º 5)	En este estado, el procesador de señal del módem se prepara para recibir y generar T1, frecuencia múltiple (MF), multifrecuencia de tono dual (DTMF), R1, R2 y señales de progreso de la llamada. El módem permanece en el estado CALL_SETUP hasta que recibe un mensaje LINK_TERMINATE, SOFTWARE_RESET o INITIATE_LINK desde el host.
CONNECT (n.º 10)	El estado CONNECT se ingresa desde el estado CALL_SETUP(#5) sólo después de recibir el comando host para iniciar. En el modo de respuesta, la sesión del módem ha iniciado la actividad, pero todavía no ha comenzado a producir un tono de respuesta. En el modo Originar, la sesión del módem ha iniciado la actividad, pero aún no ha detectado un tono de respuesta.
LINK (N.º 15)	Este estado de link se ingresa desde el estado CONECTAR sólo tras detectar un Tono de contestación (origen) o la iniciación de un Tono de contestación (respuesta). En modo de respuesta, la sesión del módem le transmite un tono de contestación a la línea. En el modo Originar, la sesión del módem ha detectado la cantidad mínima (configurable) requerida de tono de respuesta. Esto indica que existe un par remoto.
QC (n.º 16)	Puede ingresarse a Quick Connect (QC) ya sea desde el estado LINK o V.8 bis Exchange si QC está habilitado y al recibir una secuencia QCA (modo Originar) o enviar una secuencia QCA (modo Responder).
TRAINUP (n.º 20)	En este estado, la sesión del módem negocia el estándar de modulación física (tal y como está configurado) utilizado durante el link. El estado TRAINUP se ingresa desde el estado LINK sólo en: Identificación del final de un Tono de respuesta (origen). Finalización de la transmisión de un tono distintivo (respuesta).
EC_NEGOTIATING (n.º 25)	En este estado, la sesión del módem negocia la corrección del error y el protocolo de compresión de datos que se usará durante el link. Cuando los parámetros son aceptables para ambos módems (la intersección de las funciones y la configuración de los dos módems), se alcanza una negociación exitosa. Si la intersección es nula, el módem se desconecta o inicia una sesión conectada sin errores. El estado EC_NEGOTIATING se ingresa desde el estado TRAINUP cuando se completa correctamente la sincronización de modulación física.
STEADY_STATE (#30)	En este estado, la sesión del módem puede pasar datos en el link. El estado STEADY_STATE se ingresa desde el estado EC_NEGOTIATING: Luego de una negociación de protocolo exitosa (como fue configurada). Desde los estados STEADY_STATE_RETRAINING (Estado estable de Reconversión) y STEADY_STATE_SHIFTINGSPEED (Estado estable de velocidad variable), dado que el link físico es renegociado en forma exitosa. En el modo Fax; este estado significa que el motor T30 se está ejecutando. Durante una llamada de fax, hay una alternancia entre STEADY_STATE y STEADY_STATE_ESCAPE. Representa la llamada de fax que atraviesa las diferentes fases de una sesión de fax (T30).
STEADY_STATE_RETRAINING (#35)	En este estado, la sesión del módem se está volviendo a preparar. El estado STEADY_STATE_RETRAINING se ingresa desde los estados STEADY_STATE o STEADY_STATE_SHIFTINGSPEED: Upon Host Link_Control: [reacondicionamiento] comando. Ejecutando un umbral interno (configurable).
STEADY_STATE_SHIFTINGSPEED (#40)	En este estado, la sesión del módem está cambiando de velocidad actualmente. Se ingresa al estado STEADY_STATE_SHIFTINGSPEED desde el estado STEADY_STATE: Con Host_Link_Control - [Fallback, Fall-Forward]. Ejecutando un umbral interno (configurable).
STEADY_STATE_ESCAPE (#45)	En este estado, el módem todavía está conectado con el par remoto, pero la interfaz host está en el modo de comando AT. Únicamente se entra en este estado cuando se recibe una secuencia de escape Hayes válida. En modo de Fax este estado significa que el motor T30 está aceptando comandos AT desde el host. Consulte el estado STEADY_STATE (#30) para obtener información sobre una llamada de fax.
TERMINACIÓN (#50)	En este estado, la sesión del módem intenta vaciar los datos del usuario y desconectar el procesador de señales digitales (DSP). En un reinicio por software, no hay una purga ordenada, y el DSP es REINICIADO. El estado TERMINATE se ingresa desde cualquier estado: En LINK_TERMINATE o Software_reset desde el host. Por pérdida de portador del DSP. Al recibir un comando ATH del DTE. Al recibir una trama de corrección de errores DISK/LD (desconexión) de la línea. Al activar diversos umbrales internos (configurable).
EN ESPERA ( n.º 55)	La sesión del módem se encuentra en espera y no se transmiten datos por el link. El estado En espera se ingresa desde el estado Estable cuando se recibe el mensaje de solicitud Módem en espera (MoH) (MHReq). Si el módem se encuentra en espera (Register S62), el módem transmitirá la secuencia de reconocimiento de módem en espera (MHack) para conceder la solicitud y transmitir el tono de respuesta (ANSam) cuando se detecta silencio o RT. Si se detecta una señal de Call Menu (CM) (para V.8) o una secuencia Quick Connect Acknowledge-QCA (QC - Registro S63) en el estado en espera, el módem deberá salir del estado en espera y responder a la secuencia de inicio siguiente a las recomendaciones V.8 o QC (Registro S63), respectivamente. Si no se detecta ninguna secuencia de inicialización luego de definir el valor de agotamiento del tiempo de espera, el módem saldrá del estado On Hold (En espera) y se desconectará. Si el módem en espera está desactivado, el módem transmitirá MHnack. Si se detecta MHcda después de la transmisión de MHnack, el módem se desconectará. Si se detecta MHfrr después de la transmisión de MHnack, el módem transmitirá el tono de respuesta y se prepara para detectar las secuencias CM (V.8) o QCA (QC - Registro S63) desde el módem remoto. Para obtener más información sobre el módem en espera, consulte las especificaciones ITU-T V.92. Nota: El estado MICA #55 era antes el estado VOICE, que ahora ha sido eliminado de las versiones portware 2.9.1.0 y superiores.
V.8bis EXCHANGE(#71)	Este estado se ingresa desde el estado CONNECT solamente después de detectar CRe (Modo de origen) o el inicio de CRe (Modo de respuesta). Modo de respuesta: La sesión del módem está transmitiendo una respuesta automática de capacidad (CRe) a la línea. Iniciar modo: La sesión del módem ha detectado la respuesta automática de solicitud de capacidad (CRe). Esto indica que hay un par remoto.
RANGING(#72)	RANGING se ingresa desde el estado LINK o QC (Registro S63) una vez iniciada la estimación del retardo de ida y vuelta (RTDEd). Este estado sólo se aplica a los estándares V.32 y superiores.
RANGING SHORT(#73)	El RANGING SHORT se ingresa desde QC (Registro S63) al iniciar la estimación de retraso de viaje de ida y vuelta - Módem digital (RTDEd)
TREN HD (n.º 74)	Se ingresa en HD TRAIN (Preparación semidúplex) ya sea desde RANGING o RANGING SHORT cuando se inicia la capacitación de filtro de adaptación. Esto se aplica al V.22bis y a categorías superiores.
STEADY_STATE_PIAFS_RESYNC(#80)	La entrada STEADY_STATE_PIAFS_RESYNC indica que una llamada Personal Handyphone Internet Access Forum Standard (PIAFS) ha perdido sincronización y está realizando una nueva sincronización.
STEADY_STATE_PIAFS_SPEEDSHIFT(#85)	El ingreso de STEADY_STATE_PIAFS_SPEEDSHIFT indica que una llamada PIAFS está negociando un cambio de velocidad. Este es un estado momentáneo, de transición. MICA nunca permanecerá en este estado. Si al sincronizar nuevamente ocurre un cambio de velocidad, entonces MICA hace una transición a este estado desde STEADY_STATE_PIAFS_RESYNC y luego continúa a STEADY_STATE. Si la resincronización NO resulta en un cambio de velocidad, entonces STEADY_STATE_PIAFS_RESYNC pasa directamente a STEADY_STATE cuando se completa.

Razones de Desconexión del Módem MICA

Una razón de desconexión del módem MICA está formada de cuatro dígitos hexadecimales. Los tres dígitos hexadecimales de menor orden únicamente identifican la razón de desconexión. El dígito hexadecimal de alto orden indica el tipo de motivo de desconexión o la hora en la que ocurrió ese motivo de desconexión. En el ejemplo anterior, donde el código de desconexión es hexadecimal 0xDF03, el 0xF03 identifica la razón de desconexión mientras que 0xD indica cuándo ocurrió la razón de desconexión (Motivo de desconexión: Tipos).

Las razones de desconexión que se describen a continuación no incluyen el tipo de desconexión. Por lo tanto, del motivo de desconexión que tiene, elimine el dígito hexadecimal situado más a la izquierda y compare los dígitos restantes con las opciones siguientes. A partir del ejemplo anterior, busque 0xF03 en la sección siguiente.

Nota: En este documento, el módem host es el módem MICA en el servidor de acceso de Cisco, mientras que el módem cliente es el módem de dispositivo remoto (por ejemplo, un módem de PC cliente).

Tipo de desconexión	Código de motivo de desconexión	Descripción
-	0	No ha habido ninguna desconexión aún. Verá este código si se pregunta el motivo de desconexión inmediatamente después de cargar Portware o durante una llamada, antes del estado estable.
Motivos generales de desconexión (clase 0)
2	0x001	Cisco IOS terminó la llamada de forma repentina por alguna razón, por ejemplo, porque la capa 1 se cayó en el tramo físico que contiene la llamada.
2	0x002	Terminación de capa de corrección de errores (EC).
2	0x003	La tarea de descompresión de Microcom Network Protocol 5 (MNP5) recibió un indicador ilegal en la secuencia de datos. Esta razón de desconexión ocurre durante el modo de datos (0x3003). Probablemente exista un error lógico en el módem o la instrumentación de la compresión/descompresión del socio o corrección de errores. (También existe la posibilidad de un impacto de línea fortuito o de un error en la memoria RAM).
2,4,6	0x004	La tarea de descompresión V.42bis o V.44 recibió un testigo ilegal en la secuencia de datos. Esta razón de desconexión puede ocurrir durante el modo de datos (0x4004). Probablemente exista un error lógico en el módem o la instrumentación de la compresión/descompresión del socio o corrección de errores. (También existe la posibilidad de un impacto de línea fortuito o de un error en la memoria RAM). Para V.44, este código se complementa con el índice 119 del campo de información de link de diagnóstico (un campo de información de ocho bytes utilizado como herramienta para la depuración).
2	0x005	Error de software MICA. El código de error para esta razón de desconexión es 0x4005. Ocurrió un error de software MICA que indica una falla en la variable de estado del co-procesador.
6	0x006	El comando ATH fue detectado por el módem local. Esta razón de desconexión ocurre durante el modo de datos (0xC006 y 0xE006). El módem local (MICA) detectó el comando ATH (Hangup). Por ejemplo, durante un marcado de salida desde el IOS, luego de conectada la llamada, la interfaz IOS DTE elimina la llamada transmitiendo un comando ATH dentro de la banda.
3	0x007	El comando AT dial fue abortado . El comando AT dial fue anulado por el comando any key abort. Por ejemplo, el módem host origina una llamada. Durante el establecimiento de la conexión, antes del ESTADO CONSTANTE, al pulsar cualquier tecla, se anulará el comando AT dial.
3	0x008	La llamada demoró demasiado para completar la conexión. Tenga en cuenta que el temporizador S7 (espera al transportista después de marcar) ha caducado para esta desconexión. Este motivo de desconexión se produce durante la configuración de la llamada (0x6008). El módem host tardó demasiado en establecer una conexión tras varios intentos. Las causas son las siguientes: dificultad al seleccionar (negociar) un estándar de Capa I (por ejemplo, detener la llamada antes de la devolución de la razón de desconexión 0x6102) o demora excesiva de una combinación de establecimiento de Capa I y Capa II. Por ejemplo, la negociación de corrección de errores toma una cantidad de tiempo extendida sobre un retren o debido a errores de bits introducidos cuando el módem cliente intenta conectarse a una velocidad agresiva (el receptor del módem del cliente intenta conectarse a una velocidad que no puede mantener). Este tipo de desconexión juega en contra de CSR. Esta desconexión también se puede producir si el módem de respuesta no recibe ningún tono del canal (por ejemplo, el originador no fue un módem).
2	0x009	Se restableció el DSP (comando, interno o espontáneo). El código de error para esta razón de desconexión es 0x4009. El CP (Procesador de control) o el SP (Procesador de señal) reinició el DSP dentro del módem host. El CP restablecerá el DSP si no se reconocen los mensajes de correo de CP a SP. El SP se restablecerá a sí mismo si recibe un error de inconsistencia interna.
4,6	0x00A	Recepción de una palabra de código STEPUP ilegal. Especifica la recepción de una palabra de código STEPUP cuando haría que el valor de C2 (tamaño de palabra de código actual) excediera N1 (tamaño máximo de palabra de código: negociado) y es válido sólo para V.44 y V.42bis.
4,6	0x00 B	Recepción de una palabra de código V.42bis ilegal. Especifica la recepción de una palabra de código, en cualquier momento, igual a C1 (siguiente entrada de diccionario vacía) y es válida para V.42bis. (La recepción de una palabra clave = C1 es ilegal en V.42bis, pero legal en V.44).
4,6	0x00C	Recepción de un token ilegal (demasiado grande) en V.44 o V.42bis. Esto significa que el tamaño de palabra de código V.42bis o V.44 recibido excedió el máximo negociado. Especifica la recepción de una palabra de código, en cualquier momento, más grande que C1 (próxima entrada vacía en el diccionario) y tiene validez para V.44 y V.42bis.
4,6	0x00D	Recepción de un código de comando reservado V.44 o V.42bis. Especifica la recepción de un código de comando reservado y es válido para V.44 y V.42bis.
4,6	0x00E	V.42bis o V.44 recibieron una palabra de código mayor que la siguiente entrada vacía del diccionario. Recepción de carácter STEPUP ilegal V.44. Esto indica la recepción de un código de control STEPUP que haría que el valor de C5 (tamaño normal) excediera de ocho. Esto es válido sólo para V.44.
4,6	0x00F	Diccionario V.44 Rx Completo. Especifica la recepción de una palabra de código que no se restablece en el diccionario cuando el árbol de nodos Rx está lleno. Válido sólo para V.44.
4,6	0x010	Historial De V.44 Rx Completo. Especifica la recepción de una palabra de código que no se restablece en el diccionario cuando el historial de Rx está lleno. Válido sólo para V.44.
4,6	0x011	V.44/V.42bis Se Excedió El Tamaño Ilegal De Cadena Rx. Especifica la recepción de una palabra de código que hace que se exceda el tamaño máximo de cadena negociada. Es válido para V.44 y V.42bis.
4,6	0x012	Se ha producido un error de negociación V.44 Especifica que se ha producido un error de negociación V.44. Para V.44, este código se complementa con el índice 119 del campo de información de link de diagnóstico. El índice de campo de información de links de diagnóstico consiste en un campo de información de ocho bytes utilizado como herramienta de depuración.
4,6	0x013	Se ha producido un error de compresión V.44 Especifica que se ha producido un error de compresión V.44. Para V.44, este código se complementa con el índice 119 del campo de información de link de diagnóstico. El índice de campo de información de links de diagnóstico consiste en un campo de información de ocho bytes utilizado como herramienta de depuración.
Condiciones de DSP informadas (Clase 1)
	0x1xx	Condiciones de DSP informadas por SPE
3,4,5	0x100	El DSP perdió la señal de la portadora. Es decir, MICA detectó una pérdida de la portadora del módem cliente. Esta razón de desconexión ocurre durante la configuración de la llamada y el modo de datos (0x6100, 0x8100 y 0xA100). El MICA DSP dejó de oír al portador durante un período superior al valor especificado en el Registro S10 (retraso de colgado tras pérdida del portador). Esto puede significar que el trayecto de conversación desapareció o que el cliente detuvo la transmisión. Si se aplica un protocolo de capa II (V.42 y/o V.42bis), sería anormal ver tal desconexión. Este motivo de desconexión a veces ocurre durante la negociación EC (antes del modo de datos). Es decir, la capa I se ha negociado exitosamente (lo que ha dado como resultado la detección de una señal portadora) y se produce la desconexión mientras se intenta establecer el protocolo de la capa II (V.42 y/o V42bis). Una de las causas comunes es que los usuarios abortan la llamada antes de que tenga lugar la conexión. El marcado incidental, los inicios abortados y las aplicaciones cliente que expiran en función del tiempo excesivo de conexión (por ejemplo, los intentos múltiples durante la negociación de la Capa I). Este tipo de falla cuenta con CSR. La condición de pérdida de la portadora puede ocurrir también durante el modo de datos normal cuando el cliente suelta la portadora abruptamente. La causa común es una desconexión no negociada o sucia del módem cliente (es decir, el módem cliente simplemente suelta la señal de la portadora). Esto puede ocurrir si el link cae abruptamente (es decir, un error de red), se desconecta la alimentación del módem del cliente para desconectar la llamada. Esto también puede ocurrir con módems del cliente más económicos que no implementan los protocolos de limpieza de Capa I y/o II en una interrupción de DTR. Para una gran cantidad de módems clientes, esta desconexión se considera normal. Cuando el módem del cliente realiza una desconexión defectuosa, existe una condición Race entre 0xA103, 0xA100 y 0xDF06. Si el DSP dentro del módem host detecta una pérdida de portadora, 0xA100 gana y es señalado como la razón de desconexión. Si el DSP no detecta una pérdida de la portadora y restablece el sincronismo hasta que alcanza el límite S40 del registro, entonces gana 0xA103. Si la red detecta que la llamada se ha desconectado y le indica al router que se desconecte, entonces 0xDF06 gana. El motivo de esta desconexión no cuenta contra CSR cuando el módem del host está en modo de datos.
3	0x101	Esto ocurre cuando el procesador de señales (SP) se encuentra en la fase de detección de Tono de respuesta (ABT) cuando se produce una falla en la llamada.
3	0X102	Falla de llamada durante la preparación del módem debido a modulación incompatible o línea defectuosa. Esta razón de desconexión ocurre durante la configuración de la llamada(0x6102). Esto puede ser indicativo de intentos para negociar una modulación no admitida tal como una modulación propietaria heredada de Rockwell (D56Plus, V.FC, etc). Otras causas posibles son las fallas de DSP en la preparación debido a graves desperfectos en la línea, ruidos del impulso, interrupciones en la capacitación, parámetros de modulación incompatibles y, posiblemente, la incapacidad de seleccionar correctamente una norma de Capa I. Este tipo de desconexión juega en contra de CSR.
4,5	0x103	Demasiados reintentos o cambios de velocidad consecutivos. El límite de reacondicionamiento se especifica por medio del Register S40. Esta razón de desconexión ocurre durante la configuración de la llamada y el modo de datos (0x6103, 0x8103 y 0xA103). Durante el proceso de una llamada, se produjeron demasiados reacondicionamientos que resultaron en una llamada no efectiva, dado que la velocidad de datos podría ser lo suficientemente lenta como para que no sea válida. Hay condiciones posibles en que el módem cliente no completa el protocolo de limpieza (por ejemplo, el telco cerró la llamada en medio de la conexión) y MICA intenta recuperar la llamada enviando reacondicionamientos. Una vez que se alcanza el límite de recapacitación (el límite de recambio se puede alterar usando el registro S40), MICA descarta la llamada e informa este motivo de desconexión. En algunas circunstancias (T1/E1 canalizado), este tipo de desconexión puede considerarse una desconexión normal del estado STEADY. como alternativa, esto podría ser simplemente el resultado de una desconexión defectuosa debido a posibles errores de línea de los que MICA no puede recuperarse. Por lo tanto, este tipo de desconexión no cuenta con CSR ya que la llamada ya está establecida. Este motivo de desconexión también puede ocurrir durante la negociación EC cuando el módem del cliente es excesivamente agresivo con la velocidad de conexión inicial y no puede mantener la llamada (como se explicó para los viejos módems de cliente USRobotics). Este tipo de desconexión juega en contra del CSR. Cuando el módem del cliente realiza una desconexión defectuosa, existe una condición Race entre 0xA103, 0xA100 y 0xDF06. Si el Procesador de señales digitales (DSP) dentro del módem host detecta una pérdida de portadora, 0xA100 gana y es señalado como la razón de desconexión. Si el DSP no detecta una pérdida de la portadora y restablece el sincronismo hasta que alcanza el límite S40 del registro, entonces gana 0xA103. Si la red detecta que la llamada se ha desconectado y le indica al router que se desconecte, entonces 0xDF06 gana. El motivo de esta desconexión no cuenta contra CSR cuando el módem del host está en modo de datos.
3	0x104	Problema al detectar el final del tono de respuesta (ABT). Falla de negociación o ruido excesivo durante el entrenamiento V.34. Los módems host responden y envían V.8bis y los tonos de respuesta modulados de 2100 Hz (ABT) con reversiones de fase, pero se topan con un ruido excesivo durante la secuencia de entrenamiento. Buscan errores en el trayecto desde el módem que llama hasta el que contesta en una dirección o en ambas. Un comportamiento similar ocurre cuando hay latencia en la red de telefonía pública conmutada (PSTN) para marcación que supera un segundo y provoca que los módems no puedan preparar los canceladores de eco. Otras posibles causas son: Los niveles de energía de TX actuales son incorrectos y, por lo tanto, los tonos no son administrados por el lado remoto. Hay demasiado ruido en las Fases III y IV durante la capacitación V.34. Existe error del operador. Hay interferencia en la red durante la capacitación V.34 (alguien recoge la extensión). Este tipo de desconexión juega en contra de CSR.
3	0x105	La operación SS7/COT (Continuity Test) ha finalizado correctamente. Esta razón de desconexión ocurre durante la configuración de la llamada (0x6105). La operación SS7/COT (prueba de continuidad) fue completamente exitosa.
3	0x106	Falló la operación SS7/COT (Prueba de continuidad): Tiempo de espera T8/T24 esperando el tono encendido. Esta causa de desconexión ocurre durante la configuración de la llamada (esto es, 0x6106). La operación SS7/COT (Prueba de continuidad) falló debido a que el temporizador T8/T24 agotó el tiempo de espera mientras aguardaba el tono.
3	0x107	Falló la operación SS7/COT (Prueba de continuidad): Tiempo de espera T8/T24 en espera de tono apagado. Esta razón de desconexión ocurre durante la configuración de la llamada (0x6107). La operación SS7/COT ha fallado porque el temporizador T8/T24 ha agotado el tiempo de espera mientras esperaba el tono de apagado.
4	0x108	Terminación de módem en espera (MOH) por MICA. La petición Modem On Hold Cleardown se recibió desde el módem cliente. V.92 especifica que la razón de limpieza puede ser: Cleardown debido a llamada entrante. Apagado debido a una llamada saliente. Terminación debido a otro motivo.
4	0x109	Se ha alcanzado el valor de tiempo de espera del módem en espera (MOH).
Condiciones EC locales (clase 2)
	0x2xx	Condiciones de EC locales
3	0x201	Nunca se recibió la trama LR (Petición de link) durante la negociación. Este motivo de desconexión se produce durante la configuración de la llamada (es decir, 0x6201). Esto significa que el módem host no recibió la trama LR durante la negociación de corrección de errores. Puede ser que el módem de entidad par no admita MNP dentro de V.42.
3	0x202	Recepción de una trama LR con un parámetro incorrecto (PARAM1). La trama de Solicitud de link (LR) MNP recibida tenía un parámetro PARAM1 erróneo o inesperado. Para más información acerca de PARAM1, consulte la especificación V.42.
3	0x203	Recibió una trama de LR (Petición de link) incompatible. Esta causa de desconexión ocurre durante la configuración de la llamada (0x6203). El marco MNP LR recibido no es compatible con la configuración del módem del host correspondiente a EC.
4,5	0x204	Demasiadas retransmisiones consecutivas. Esta razón de desconexión ocurre durante la configuración de la llamada y el modo de datos (0x8204, 0xA204 y 0x6204). Esta razón de desconexión puede ser causada por un ruido en la línea. Por ejemplo, el módem del host transmite datos al módem del cliente pero el ruido que hay en la línea hace que el cliente reciba los datos de manera incorrecta (o incompleta). Un ruido muy excesivo puede provocar retransmisiones excesivas. El módem cliente también podría haberse desconectado sin que el módem MICA lo notara. Por lo tanto, el módem del host retransmite continuamente, sin detectar que el módem del cliente ya no está presente. A veces, cuando la llamada se conecta en un protocolo de compresión de errores (EC) (procedimiento de acceso de enlace para módems (LAPM) o protocolo de red de microcom (MNP)), MICA no puede transmitir una trama al módem cliente. El módem del cliente no logra reconocer la transmisión inicial MICA y luego no logra responder a las consultas S19 (límite de retransmisión de corrección de error) (el valor predeterminado es 12), y por lo tanto MICA desconecta la llamada. Una causa puede ser que la portadora en el trayecto de transmisión se haya degradado sustancialmente mientras el cliente no pudo reducir la velocidad. Otra causa puede ser un problema con el motor EC del cliente (como ocurriría en un sistema Winmodem si Windows deja de responder).
6,7	0x205	Tiempo de espera inactiva, MNP LD (link desconectado) enviado. Este motivo de desconexión ocurre durante el modo datos (0x8206 y 0xA206). El módem host envía al módem cliente una trama LD, mediante la cual indica que se ha agotado el tiempo de espera por inactividad.
4,5	0x206	Error de protocolo EC. Este motivo de desconexión ocurre en modo de datos (0x8206 y 0xA206). Este es un error de protocolo general común. Indica que ha ocurrido un error en el protocolo LAPM o MNP EC.
3	0x210	No hay ningún protocolo de repliegue EC disponible. Esta razón de desconexión ocurre durante la configuración de la llamada (0x6210). La negociación de corrección de errores no fue exitosa. La llamada finaliza porque no hay un protocolo de corrección de errores como sistema de soporte disponible. S-register S25 (protocolo de seguridad de link) determina el protocolo de seguridad disponible. Las opciones son alineación de tramas asincrónica, alineación de tramas sincrónica o desconectar (cortar).
3	0x211	No se recibió la trama eXchange IDentification (XID) durante la negociación. Esta causa de desconexión ocurre durante la configuración de la llamada (0x6211). Esto significa que el módem host nunca recibió la trama XID durante la negociación de corrección de error. Es posible que el módem del cliente no admita LAPM con V.42.
3	0x212	La trama XID recibida es incompatible con la configuración local. Esta razón de desconexión ocurre durante la configuración de la llamada (0x6210). La trama XID recibida es incompatible con la configuración del módem host. Por ejemplo, el módem del cliente puede indicar MNP5, mientras que el módem del host indica solamente V.42 y V.42bis.
3,4,5	0x220	Trama de desconexión recibida (DISC). Ésta es la desconexión normal de LAP-M. Esta razón de desconexión ocurre durante la configuración de la llamada y en el modo de datos (0x 6220, 0x8220 y 0xA220). La llamada finalizó normalmente con una liberación de llamada correcta por parte del cliente. (es decir, se envió un paquete de desconexión V.42 del módem cliente al módem NAS). El módem del cliente dejó de transmitir DTR y negoció un protocolo de limpieza total de manera limpia.
3,4,5	0x221	Trama de DM recibida. Es posible que el par se desconecte. Esta razón de desconexión ocurre en la configuración de la llamada y el modo de datos (0x6221, 0x8221 y 0xA221). El módem de cliente indica que se está desconectando. Durante la configuración de la llamada, este motivo indica que el módem del cliente abandona la corrección de errores de negociación.
4,5	0x222	Recibió un número de secuencia incorrecto. Este motivo de desconexión ocurre en modo de datos (0x8222 y 0xA222). El módem del host recibió una trama de correción de errores LAPM o MNP con una mala sequencia de números o números de reconocimiento. Se envía LD o trama de rechazo de trama (FRMR) al módem del cliente para indicarle que el módem del host está desconectando.
4,5	0x223	Trama SABME recibida en estado estable. Este motivo de desconexión ocurre en modo de datos (0x8223 y 0xA223). Esto se interpreta como un error del protocolo de corrección de errores en estado constante. Significa que el módem cliente puede haberse reiniciado porque recibió un Rechazo de trama (FRMR).
4,5	0x224	Trama MNP XID recibida en estado estable. Este motivo de desconexión ocurre en modo de datos (0x8224 y 0xA224). Esto se interpreta como un error del protocolo de corrección de errores en estado constante. Significa que el módem cliente puede haberse reiniciado porque recibió un Rechazo de trama (FRMR).
4,5	0x225	Recepción de trama MNP LR en estado constante. Esta razón de desconexión ocurre en el modo de datos (0x8225 y 0xA225). Esto se interpreta como un error del protocolo de corrección de errores de protocolos MNP en estado constante. Significa que el módem del cliente se ha restablecido.
Condiciones específicas del protocolo de PIAFS (Clase 2, continuación)
3,4	0x230	Un mensaje recibido es más corto que la longitud mínima definida para ese tipo de mensajes.
3,4	0x231	Se recibió el tipo de trama PIAFS desconocido o no implementado. Esto incluye la clase FI (tipo de trama principal) y la clase de negociación, sincronización o control (subtipo).
3,4	0x232	Identificador de trama de control (CFI) de PIAFS desconocido. Se recibió una trama de control con una ID desconocida o no implementada para su clase. Tenga en cuenta que las tramas continua y de usuario no están implementadas y que no hay tramas de notificación conocidas.
3,4	0x233	La negociación de la comunicación PIAFS falló. Después de la sincronización inicial, se intercambian las tramas Req/Ack del parámetro de comunicación. Los parámetros eran inaceptables o el iniciador detectó una respuesta NAK (Reconocimiento negativo). Nota: MICA sólo puede funcionar como cliente/iniciador para fines de prueba
3,4	0x234	Falló la negociación PIAFS ARQ. Después de la resincronización, se intercambian las tramas de Solicitud ARQ (Req)/Reconocimiento (Ack). Los parámetros eran inaceptables o el iniciador detectó una respuesta Nak. Nota: MICA sólo puede funcionar como cliente/iniciador para fines de prueba
3,4	0x235	Se detectaron problemas del PIAFS Control Transfer Protocol . El iniciador recibió un Ack/Nak/Rsp cuya identificación, clase y secuencia no coincidió con el Req/Ntf original. Nota: MICA sólo puede funcionar como cliente o iniciador con fines de prueba
3,4	0x236	Este motivo de desconexión ya no indica la recepción de una trama de solicitud de DataLinkRelease. Indica ahora una desconexión sin que se haya generado una razón de desconexión. Esto significa que MICA desconecta la llamada, pero detecta que no se ha enviado ningún motivo.
3,4	0x237	El temporizador de espera de recepción sincronizada del PIAFS (T001) se venció. Este temporizador comienza cuando se envía una trama de petición de sincronización y se detiene cuando se detecta una trama de recepción de sincronización. Este error sólo ocurrirá cuando el puerto MICA esté funcionando como cliente o iniciador, lo que ocurre sólo durante la prueba. El valor predeterminado es 15 segundos.’
3,4	0x238	El temporizador de transmisión de recepción posteriormente sincronizada del PIAFS (T002) caducó. Este temporizador comienza cuando se envía una trama de recepción sincronizada y se detiene cuando se detecta una recepción sincronizada (caso de colisión) o una trama de control. Este error sólo ocurrirá cuando el puerto MICA esté funcionando como servidor (modo de respuesta), que es el modo de funcionamiento normal. El valor predeterminado es 15 segundos.’
3,4	0x239	El temporizador de espera de petición sincronizada del PIAFS T003 caducó. Este temporizador se inicia cuando se detectan errores FCS continuos, y se detiene cuando se detecta una trama de petición de sincronización válida. Este error sólo ocurrirá con el puerto MICA funcionando como servidor (modo de respuesta), que el es modo de operación normal. El valor predeterminado es 15 segundos.’
3,4	0 x 23 A	El temporizador PIAFS T101 caducó: temporizador de espera de confirmación de tramas de control. Comienza cuando se envía un pedido o notificación de la trama de control y se detiene cuando se confirma la trama. Este error sólo ocurrirá cuando el puerto MICA esté funcionando como cliente o iniciador, lo que ocurre sólo durante la prueba (diez segundos).
3,4	0x23B	PIAFS: FBI (número de secuencia ACK) recibido fuera del rango negociado, o FBI =0 recibido con una trama de datos no vacía.
3,4	0x23C	PIAFS: FFI (número de secuencia MSG) recibido fuera del rango negociado o FFI=0.
3,4	0x23D	PIAFS: la ventana de datos negociados es menor que el valor RTF (retraso de ida y vuelta). Este error ya no es publicado por Portware y nunca debería observarse.
3,4	0x23E	PIAFS: el campo de longitud de datos del mensaje es demasiado grande. Puede ser 0-73.
3,4	0x23F	Error interno de PIAFS: La llamada SREJ produjo un código de error.
3,4	0x240	Error de protocolo general de PIAFS. Este es un comodín para errores que no poseen un motivo de desconexión asociado.
3,4	0x241	PIAFS: la negociación del protocolo falló. Ningún protocolo (por ejemplo, Velocidad fija del protocolo de transferencia de datos, Velocidad variable DTP Tipo1) era aceptable para ambas estaciones. Los protocolos no aceptables serían Velocidad variable tipo 3 de DTP o Protocolo de tiempo real.
3,4	0x242	PIAFS: el valor de RTF (retardo de ida y vuelta) medido no se encontraba dentro del rango (aceptable) definido.
3,4	0x243	Error interno de PIAFS: evento desconocido en el controlador de eventos. Un enunciado de switch cayó a su caso predeterminado.
3,4	0x244	Ocurre un tiempo de espera de respuesta agotado del Procesador de señal (SP) durante un cambio de velocidad de PIAFS 2.1. El CP de Mica no vio la respuesta de cambio de velocidad dentro de 200 mseg.
3,4	0x245	El CP de Mica vio información de control inconsistente en las estructuras de control compartidas CP/SP. En particular, el búfer de datos tuvo un desplazamiento de cabecera o pie que estuvo fuera de los límites del búfer de datos (0-63).
Comando MNP o protocolo LAPM erróneo recibido del partner (clase 3)
4.5	0x3xx	EC detectó un código de comando defectuoso. El comando desconocido recibido se encuentra en los últimos dos dígitos. Se envía una trama de rechazo de tramas MNP LD o LAP-M (FRMR) en respuesta.
El socio LAPM indica un error en el protocolo MICA (Clase 4)
4,5	0x4xx	Condiciones EC indicadas por cliente en la trama LAP-M FRMR. El motivo del mapa de bits se encuentra en los últimos dos dígitos.
4,5	0x401	LAPM: Comando peer reports bad. El módem del host recibió una trama FRMR del módem del cliente La trama FRMR recibida indica que el módem del cliente recibió una trama de corrección de error del módem del host que contenía un comando incorrecto.
4,5	0x403	LAPM: el par informa que no se permite el campo de datos o que tiene un tamaño incorrecto (tramas U). El módem del host recibió una trama FRMR del módem del cliente La trama FRMR recibida indica que el módem cliente recibió una trama de corrección de error del módem del host con un campo de datos que no está permitido o con una extensión incorrecta (trama U).
4,5	0x404	LAPM: la longitud del campo de datos de informes de pares es mayor que N401 (la longitud máxima del campo de información especificada en V.42), pero tiene una buena secuencia de verificación de tramas (FCS). El módem NextPort recibió una trama FRMR del módem del cliente La trama FRMR recibida indica que el módem del cliente recibió una trama de corrección de errores desde NextPort que contenía una longitud de campo de datos superior al número máximo de octetos que puede contener el campo de información (N401) de una trama I, una trama SREJ, una trama XID, una trama UI o una trama TEST. La secuencia de verificación de tramas es buena.
4,5	0x408	LAPM: número de secuencia de recepción incorrecta de informes sobre entidades pares o N(R). El módem del host recibió una trama FRMR del módem del cliente El marco FRMR indica que el módem del cliente recibió un marco de corrección de error del módem host que contenía un número de secuencia de mala recepción.
El socio MNP indica un error de desconexión o del protocolo MICA (Clase 5)
4,5	0x5xx	Condiciones de EC indicadas por el cliente en la trama LD de MNP. El campo Motivo se encuentra en los últimos dos dígitos
3	0x501	MNP: El par nunca recibió la trama LR. El módem del host recibió una trama LD del módem cliente La trama LD recibida indica que el módem del cliente nunca recibió una petición de link del módem host.
3	0x502	MNP: la trama LR de informes de peer tiene el parámetro incorrecto #1. El módem del host recibió una trama FRMR del módem del cliente. La trama LD recibida indica que el módem cliente recibió una trama de solicitud de link del módem host que contenía una PARAM1 incorrecta (es decir, inesperada). Para más información acerca de PARAM1, consulte la especificación V.42.
3	0x503	MNP: la trama LR de informes de peer es incompatible con su configuración. El módem del host recibió una trama FRMR del módem del cliente. La trama LD recibida indica que el módem cliente recibió una trama LR del módem host que es incompatible con la configuración del módem cliente.
4,5	0x504	MNP: entidades pares informan demasiadas retransmisiones consecutivas. El módem del host recibió una trama LD del módem cliente La trama LD recibida indica que el módem del cliente recibió demasiadas retransmisiones consecutivas.
4,5	0x505	MNP: el temporizador de inactividad de informes de peer ha caducado. El módem del host recibió una trama FRMR del módem del cliente. La trama LD recibida indica que el host (DTE) del módem cliente no ha pasado datos al módem cliente en un período de tiempo.
3	0x506	MNP: error de informes de peer. El módem del host recibió una trama LD del módem cliente La trama LD recibida indica que el módem del cliente recibió un error de protocolo MNP.
3	0x5FF	Desconexión normal de MNP. El módem del host recibió una trama FRMR del módem del cliente. La trama LD recibida indica una terminación MNP normal, lo que indica que el DTR del módem del cliente cayó o que recibió un comando ++ o ATH. Esta razón de desconexión ocurre en el modo de configuración de llamada y datos (0x65FF, 0x85FF y 0xA5FF). El módem host recibió una LD, lo que indica una finalización normal. El llamado finalizó en forma normal con un corte adecuado y claro del lado del cliente (por ejemplo, un paquete de desconexión fue enviado desde el módem del cliente al módem host). El módem del cliente dejó de transmitir DTR y negoció un protocolo de limpieza total de manera limpia.
El partner PIAFS indica un error de desconexión o del protocolo MICA (clase 6)
3,4	0x6xx	MICA recibió un PIAFS DataLinkRelease (PDLR) con motivo xx (ver los valores detallados a continuación).
3,4	0x61x	Clase Normal para PIAFS DataLinkRelease (PDLR): 0 - Versión normal. 1 - Versión normal, la continuación del link de datos está prohibida. 2 – Versión normal, continuación del link de datos. ... Otras clases normales: clases no definidas peculiares de algunos dispositivos cliente.
3,4	0x62x	Uso no posible de clase de recurso para PIAFS DLR (condiciones de ocupado): 8 - DTE ocupado. 9 - Obstrucción temporal ... Otras clases de recursos no son posibles: clases no definidas peculiares de algunos dispositivos cliente.
3,4	0x63x	La utilización del servicio no es una clase posible para PIAFS DLR (parámetros incorrectos). 9 - No se puede solicitar la configuración del parámetro. R: No se puede establecer el parámetro de solicitud en este momento. .. Clases no posibles de utilización en otro servicio - clases no definidas peculiares a los dispositivos de algunos clientes.
3,4	0x64x	El servicio aún no ha proporcionado la clase para PIAFS DLR. 1- indicación de parámetro aún no proporcionada. ... Otros servicios aún no han proporcionado clases: clases no definidas peculiares de algunos dispositivos cliente.
3,4	0x65x	Clase de contenido de la información no válido para PIAFS DLR. 8 - Atributo del terminal no coincidente. ... Otras clases de contenido de información no válidas: clases no definidas peculiares a algunos dispositivos cliente.
3,4	0x66x	Clase de error de secuencia para PIAFS DLR 0 - Parámetros esenciales insuficientes. 1 - contenido de la información no definido o aún no proporcionado. 5 – La condición de ARQ y la señal no coinciden. 6 - El temporizador caduca. ... Otras clases de error de secuencia: clases no definidas peculiares de algunos dispositivos cliente.
3,4	0x67x	Otra clase de peculiaridades para PIAFS DLR. 1 - Durante una llamada de voz. ... Otras clases peculiares: clases no definidas peculiares de algunos dispositivos cliente.
Desconexión solicitada por host/IOS (Clase 31)
6,7	0x1fxx	Desconexión del host iniciado. El valor es una suma de 0x1F00 y del valor de SessionStopCommand. Ésta es la otra razón de terminación del host. La razón del host se indica en los bytes xx de bajo orden.
3,6,7	0x1f00	Host no específico inició la desconexión. El valor es una suma de 0x1F00 y del valor de SessionStopCommand. Esta es la razón por la que se desconecta el catch-all iniciado en IOS. Se utiliza para todas las desconexiones no estándar. Por ejemplo, esto podría ser el resultado del software de administración del módem que decide finalizar la llamada. Una posible explicación es una falla de autenticación a nivel superior en RADIUS, TACACS u otra aplicación que emite una interrupción de DTR al módem host. Este tipo de desconexión no influirá en el CSR cuando el módem del host esté en modo de datos.
3	0x1f01	El número marcado estaba ocupado. Se ha producido la desconexión porque el host indica que el número marcado está ocupado.
3	0x1f02	El número marcado no responde. Se ha producido un corte en la conexión porque el host está indicando que el número marcado no responde.
3,6,7	0x1f03	DTR virtual descartado. Este estado es reflejado desde el redireccionador de puerto I/O que está utilizando el módem actualmente. Se ha producido la desconexión porque el host interrumpió la línea DTR virtual. El software del IOS de Cisco inicia esta desconexión genérica. Las causas posibles son tiempo de espera inactivo, PPP LCP TERMREQ recibido, falla de autenticación, corte de Telnet, etc. Para determinar el motivo de desconexión, analice el motivo de desconexión de Radius desde el comando modem call-record terse o desde Autenticación, autorización y contabilidad (AAA).
6,7	0x1f04	El host local detectó el comando ATH (hangup).
3	0x1f05	Sin acceso a la red de la compañía telefónica. Se ha producido una desconexión porque el host no pudo acceder a la red (ISDN).
3,4,5 ,	0x1f06	Desconexión indicada por la red. Esto puede suceder antes o durante el modo de datos. Un desconexión 0x1f06 significa que el IOS recibió una señal de corte de circuito de una red de circuito (es decir, una desconexión Q.931 o una señal de enganche CAS) y, entonces, el IOS lo comunicó a MICA cuando indicó a MICA que cuelgue. Si MICA alcanza el modo de datos y no se negoció un protocolo de EC (LAPM o MNP4), se podría generar una desconexión normal. Este motivo también puede ser generado cuando los usuarios de interconexión de redes de marcación manual (DUN) de Windows 95 o 98 presionan cancelar durante la preparación de la conexión y antes de que la llamada alcance el estado estable. Además, si el cliente desconectara abruptamente la línea telefónica o apagara el módem, este motivo de desconexión se consideraría normal. Sin embargo, si la conexión ha negociado EC (LAPM o MNP4) y, por consiguiente en modalidad de datos, entonces este motivo de desconexión puede ser generado por una desconexión defectuosa (es decir, una desconexión que no implica una terminación de llamada de cortesía). Esto se debe al hecho de que si el DTE del cliente (en modo datos) desconecta la llamada en una forma ordenada (con DTR drop o +++/ATH), entonces el módem del cliente nos enviará un LAPM DISC (o MNP LD) antes de colgar, de esta forma genera un motivo de desconexión 0x220 en lugar de 0x1f06. Por lo tanto, la desconexión indicada por la red es, en este caso, probablemente indicativa de un módem cliente infeliz, uno que decidió que ya no podía soportar la portadora por alguna razón.
3	0x1f07	Operación del SS7/COT terminado en NAS. Se produjo la desconexión debido a que NAS ha finalizado la operación SS7/COT (Prueba de continuidad).
3	0x1f08	La operación SS7/COT fue finalizada por el router debido a un tiempo de espera de T8/T24.
-	0x1fff	No solicitado. TERMINATING. El host envía este motivo de desconexión cuando recibe un mensaje de terminación no solicitado.

Motivo de desconexión: Tipos

El motivo de desconexión:los tipos describen cuándo se produjo realmente la desconexión de la llamada. Se pueden clasificar en dos tipos principales:durante la configuración de la llamada y durante el modo de datos (estado fijo). La siguiente tabla especifica los tipos más comunes de razones de desconexión más comunes y sus valores según se indica en la razón de desconexión.

Tipo de desconexión	Tipo de desconexión (Hex)	Descripción
0	0x0...	(sin utilizar)
1	0x2...	(sin utilizar)
2	0x4...	Otras situaciones.
3	0x6...	Esta condición ocurrió durante la configuración de la llamada.
4	0x8...	En el modo de datos. Los datos Rx (línea a host) vacian OK. La condición de desconexión apareció en el modo de datos. MICA intenta enviar cualquiera de los datos recibidos al host (IOS). Para algunas desconexiones (por ejemplo, PIAFS), este es el único tipo de modo de datos utilizado; no se indica la dirección de vaciado de los datos.
5	0xA...	En el modo de datos. La vaciado de datos Rx (línea a host) no es correcta. La condición de desconexión apareció en el modo de datos. MICA intenta enviar cualquiera de los datos recibidos al host (IOS). En un código MICA heredado, este tipo es equivalente al tipo 4 anterior. Si bien IOS muestra estas desconexiones como correctas, en realidad no ha ocurrido ningún problema.
6	0xC...	En el modo de datos. Los datos TX (host a línea) vacian OK. La condición de desconexión apareció en el modo de datos. MICA trata de transmitir datos del host almacenados en la memoria intermedia (IOS) al módem asociado.
7	0xE...	En el modo de datos. La vaciado de datos TX (host a línea) no es correcta. La condición de desconexión apareció en el modo de datos. MICA trata de transmitir datos del host almacenados en la memoria intermedia (IOS) al módem asociado. En el código MICA heredado, este tipo equivale al tipo 6 antes mencionado. Si bien IOS muestra estas desconexiones como correctas, en realidad no ha ocurrido ningún problema.

Información Relacionada

• Conjunto de comandos MICA AT
• Conjunto de Comandos MICA AT con PIAFS
• Notas de la versión del software MICA
• Referencia de Comandos AT y Registros S de NextPort
• Soporte Técnico - Cisco Systems