Marcado y acceso remotos : Conexiones asíncronas

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

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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 que se definan en los estándares de ITU tales como v.90, V.44, V.42bis, y V.34. Para más información sobre estos términos satisfaga refieren al estándar apropiadoleavingcisco.com ITU-T. Los términos especificados en los estándares ITU-T no se explican en este documento.

prerrequisitos

Requisitos

Los Quien lea este documento deben ser conscientes del 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). Un motivo de desconexión típico es que el DTE (modem del cliente o NAS) en un extremo quiere 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 Router

  • 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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

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 la salida de ejemplo abajo, el estado del módem es marcha lenta, indicada por el estado del módem que el evento selló 00:00:28. Refiera a la tabla de los estados del módem MICA para más información sobre los estados del módem MICA posibles.

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

Siempre que se termine una conexión del módem, el NAS señala dos motivos de desconexión: las razones DTE (IOS) y las razones DCE (MICA). Para comunicar estas razones de desconexión, pueden utilizarse tres métodos primarios:

  1. Registros de llamadas del módem Éstos señalan el software y las razones de desconexión del módem MICA del ½ del ¿Â 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 modem operational-status de la demostración y registro del módem de la demostración señalan solamente la razón de desconexión del módem MICA.

Registros de llamadas del módem

El IOS y la razón de la desconexión del módem para una conexión determinada se visualizan 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 la muestra mostrado abajo, el motivo de desconexión de IOS indicado por el disc(radius) es portador perdido/portador perdido, mientras que es la razón de la desconexión del módem indicada por el disc(modem):

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

Refiera a los motivos de desconexión del módem MICA de la tabla para más información sobre la interpretación de la razón de la 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 la interrogación de la muestra AAA sql abajo, podemos ver la causa de la desconexión de 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 la desconexión (disc-cause=4), en el ejemplo antedicho, indica que la desconexión fue causada por la expiración del descanso ocioso.

Nota: Los registros contables de AAA no muestran la razón de desconexión del MICA y, por lo tanto, la tabla que se suministra en este documento no puede utilizarse para interpretar el motivo de desconexión del 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 los motivos de desconexión abajo para las explicaciones en los diversos 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 /port de la demostración modem log slot también visualiza el motivo 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 alto orden indica generalmente el tipo de motivo de desconexión o del tiempo en quien el motivo de desconexión ocurrió. 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 el motivo de desconexión mientras que 0xD y 0x8 indican cuando ocurrió el motivo 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 más información sobre las operaciones del módem MICA, vea la documentación del rendimiento del módem que verifica y de las operaciones de administración del módem en el caso práctico del Cisco AS5x00 para los servicios del módem básicos IP.

Estados de módem MICA

Estado Descripción
MARCHA LENTA (#0) En este estado, la sesión del módem está actualmente inactiva. 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 (#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.
CONECTE (#10) El estado de la CONEXIÓN se ingresa CALL_SETUP(#5) del estado solamente sobre la recepción del comando host de iniciar. En el modo contestar, la sesión del módem ha iniciado la actividad, pero todavía no ha comenzado a producir un tono distintivo. En origine el modo, la sesión del módem ha iniciado la actividad, pero todavía no ha detectado un tono distintivo.
LINK (#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 (#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 (#20) En este estado, la sesión del módem negocia el estándar de modulación física (según lo configurado) usado durante el link. Ingresan al estado TRAINUP del estado del LINK solamente sobre:
  • Identificación del final de un Tono de respuesta (origen).
  • Finalización de la transmisión de un tono distintivo (respuesta).
EC_NEGOTIATING (#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 las configuraciones son conformes a ambos módems (la intersección de las dos capacidades de los módems y configuraciones), 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 del EC_NEGOTIATING se ingresa del estado TRAINUP sobre con éxito completar la sincronización física de la modulación.
STEADY_STATE (#30) En este estado, la sesión del módem puede pasar los datos sobre 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 palanca entre el STEADY_STATE a STEADY_STATE_ESCAPE. Esto representa la llamada de fax que pasa con sus diversas fases de una sesión del fax (T30).
STEADY_STATE_RETRAINING (#35) En este estado, la sesión del módem se está volviendo a preparar. El estado del STEADY_STATE_RETRAINING se ingresa de los estados del STEADY_STATE o del 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 peer remoto, pero la interfaz del host está adentro EN el modo de comando. Ú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. Vea el estado del STEADY_STATE (#30) para la información sobre una llamada de fax.
El TERMINAR (#50) En este estado, la sesión del módem intenta vaciar los datos del usuario y claro-abajo 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:
  • Sobre el LINK_TERMINATE o Software_reset del host.
  • Por pérdida de portador del DSP.
  • Al recibir un comando ATH del DTE.
  • En el recibo de una trama de corrección de errores DISC/LD (desconexión) de la línea.
  • Al activar diversos umbrales internos (configurable).
EN EL CONTROL (#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 se habilita el Modem On Hold (registro S62), el módem transmitirá la secuencia del acuse de recibo del Modem On Hold (MHack) para conceder la petición y para transmitir el Answer Back Tone (ANSam) cuando se detecta el silencio o el 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 se inhabilita el Modem On Hold, el módem transmitirá el 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 más información sobre el Modem On Hold, refiera a las especificaciones ITU-T V.92leavingcisco.com .

Nota: El estado MICA #55 era antes el estado VOICE que ahora fue eliminado de las versiones portware 2.9.1.0 y anteriores.

V.8bis EXCHANGE(#71) Este estado se ingresa de CONECTA el estado solamente sobre la detección de CRe (origine el modo) o del lanzamiento de CRe (modo contestar). 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 capacidad Petición-para autoanswer (CRe). Esto indica que hay un peer 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.
SHORT(#73) DE ALCANCE El ALCANCE BREVEMENTE se ingresa de QC (registro S63) sobre encender el módem Estimación-digital del retardo de ida y vuelta (RTDEd)
HD TRAIN(#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 sube.
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 está 0xDF03 el código de la desconexión hexadecimal, el 0xF03 identifica el motivo de desconexión mientras que 0xD indica cuando ocurrió el motivo 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 usted tiene, pela el primer dígito hexadecimal desde la izquierda y compara los dígitos restantes con las opciones abajo. 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 Cisco, mientras que el módem cliente es el módem del dispositivo remoto (por ejemplo, el módem de una 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 El Cisco IOS terminó precipitadamente la llamada por alguna razón - por ejemplo, porque la capa 1 fue abajo en el palmo físico que contenía 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. Este motivo 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. Este motivo 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 el V.44, este código es complementado por el índice de campo de información de links de diagnóstico 119 (un campo de información del byte ocho usado como herramienta para hacer el debug de).
2 0x005 Error de software de MICA. El código de error por este motivo 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 módem local detectó al comando ATH. Este motivo de desconexión ocurre durante el modo de datos (0xC006 y 0xE006). El módem local (MICA) detectó al comando ATH (desconexión). 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 Abortaron al comando AT dial. Al comando any key abort abortó al comando AT dial. Por ejemplo, el módem del host origina una llamada. Durante el establecimiento de la conexión, antes del ESTADO CONSTANTE, pulsar cualquier tecla causará el comando AT dial de ser abortado.
3 0x008 La llamada demoró demasiado para completar la conexión. Observe que el temporizador S7 (espera para el portador después del dial) expirado 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: 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 tarda una extensa cantidad de hora encima de un reentrenamiento o debido a los errores de bit la introdujo cuando el modem del cliente intenta conectar a una velocidad agresiva (el receptor del modem del cliente intenta conectar a una tarifa que no puede sostener). 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 El DSP fue reajustado (comando, interno o espontáneo). El código de error por este motivo 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 reajustará el DSP si los mensajes del correo del CP al SP no se están reconociendo. El SP se reajustará si consigue un error de inconsistencia interna.
4,6 0x00A Recibo de una palabra del código del STEPUP ilegal. Especifica el recibo de una palabra de código STEPUP cuando haría el valor de C2 (tamaño de la palabra del código actual) exceder el n1 (tamaño de la palabra del código máximo: se negocia) y válido para el V.44 y el V.42bis solamente.
4,6 0x00B Recibo de una palabra del código ilegal del V.42bis. Especifica el recibo de una palabra del código, en cualquier momento, igual al c1 (entrada de diccionario vacía siguiente) y es válido para el V.42bis. (El recibo de una palabra del código = del c1 es ilegal en el V.42bis, pero legal en el V.44).
4,6 0x00C Acuse recibo de un testigo ilegal (demasiado grande) en el V.44 o el V.42bis. Esto significa que el V.42bis o el tamaño de la palabra del código recibido V.44 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 Recibo de un código de comando reservado V.44 o del V.42bis. Especifica el recibo de un código de comando reservado y es válido para el V.44 y el V.42bis.
4,6 0x00E El V.42bis o el V.44 recibió la palabra del código mayor que la entrada de diccionario vacía siguiente. Recepción de carácter STEPUP ilegal V.44. Esto indica el recibo de un código de control ELEVADOR que haría el valor de C5 (tamaño ordinal) exceder de ocho. Esto es válido para el V.44 solamente.
4,6 0x00F Diccionario del rx V.44 por completo. Especifica el recibo de una palabra del código que no sea un reinicio de diccionario cuando el nodo-árbol del rx es lleno. Válido para el V.44 solamente.
4,6 0x010 Historial del rx V.44 por completo. Especifica el recibo de una palabra del código que no sea un reinicio de diccionario cuando el historial del rx es lleno. Válido para el V.44 solamente.
4,6 0x011 Tamaño de la cadena ilegal del rx V.44/V.42bis excedido. Especifica el recibo de una palabra del código que haga el tamaño de la cadena negociado máximo ser excedida. Es válido para V.44 y V.42bis.
4,6 0x012 Un error de negociación V.44 ha ocurrido especifica un error de negociación V.44 ha ocurrido. Para el V.44, este código es complementado por el índice de campo de información de links de diagnóstico 119. 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 Un error de compresión V.44 ha ocurrido especifica un error de compresión V.44 ha ocurrido. Para el V.44, este código es complementado por el índice de campo de información de links de diagnóstico 119. 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 DSP cesó de escuchar a la portadora MICA por un período mayor que el valor especificado en el registro S10 (retraso de desconexión después de la pérdida de la portadora). Esto puede significar que el trayecto de conversación desapareció o que el cliente detuvo la transmisión. Si un protocolo de la capa II (V.42 y/o V.42bis) está en efecto, sería anormal considerar 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 cuentas de fallas contra el 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 signal processor (SP) es en la fase de la detección del Answer Back Tone (ABT) en que ocurre la falla de llamada.
3 0X102 Falla de llamada durante el tren del módem encima de debido a la modulación incompatible o a la mala línea. Este motivo de desconexión ocurre durante la llamada setup(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. El límite del reentrenamiento se alcanza una vez (el límite del reentrenamiento se puede alterar usando el registro S40), MICA cae la llamada y señala este motivo de desconexión. En algunas circunstancias (T1/E1 canalizado) este tipo de desconexión puede ser considerado una desconexión de estado estacionario normal. alternativamente, éste podría simplemente ser el resultado de una desconexión defectuosa debido a los errores de la línea posibles de los cuales el MICA no puede recuperarse. Por lo tanto, este tipo de desconexión no cuenta hacia el CSR puesto que la llamada se establece ya. 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 que detecta el final de la respuesta de control Tone(ABT). Falla de negociación o ruido excesivo durante el entrenamiento V.34. Los módems del host contestan y envían al V.8bis y la respuesta modulada 2100Hz detrás entona (los ABT) con las inversiones de fase, pero el ruido excesivo del encuentro durante la secuencia de preparación. 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 (prueba de continuidad) completó este motivo de desconexión ocurre con éxito durante la configuración de la llamada (0x6105). La operación SS7/COT (prueba de continuidad) fue completamente exitosa.
3 0x106 La operación SS7/COT (prueba de continuidad) falló: Tono que espera del descanso T8/T24 para 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 La operación SS7/COT (prueba de continuidad) falló: Tono que espera del descanso T8/T24 para 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 medido el tiempo hacia fuera mientras que espera el tono 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.
  • Terminación a causa de a la llamada saliente.
  • Terminación debido a otro motivo.
4 0x109 Valor de agotamiento del tiempo del Modem On Hold (MOH) alcanzado.
El EC local condiciona (clase 2)
  0x2xx Condiciones locales EC
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. Este motivo 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. Algunas veces, cuando la llamada se conecta en un protocolo de compresión de error (EC) (Procedimiento de acceso al link para módems [LAPM] o Protocolo de red Microcom [MNP])., el MICA no puede transmitir una trama al modem del 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 las configuraciones del módem del 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, un paquete de la desconexión V.42 fue enviado del modem del 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 recibida DM. El par está desconectando posiblemente. 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. Este motivo 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 Tipo de trama desconocido o unimplemented PIAFS recibido. Esto incluye el FI (tipo de trama importante), y negocia, sincroniza o clase 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. Observe que las tramas continuas y del usuario son unimplemented, y que no hay tramas sabidas de la notificación.
3,4 0x233 La negociación de la comunicación PIAFS falló. Después de la sincronización inicial, se intercambian las tramas del req/Ack del parámetro de comunicación. Cualquier los parámetros eran inaceptables, o el iniciador detectó una respuesta NAK (Negative Acknowledgment).

Nota: MICA sólo puede funcionar como un cliente/iniciador para realizar pruebas

3,4 0x234 La negociación ARQ PIAFS fallado. Después de la resincronización, se intercambian las tramas de la petición ARQ (req) /Acknowledgment (Ack). Cualquier los parámetros eran inaceptables, o el iniciador detectó a respuesta Nak.

Nota: MICA sólo puede funcionar como un cliente/iniciador para realizar pruebas

3,4 0x235 Problemas del protocolo transfer del control PIAFS detectados. El iniciador recibió un Ack/Nak/Rsp cuya identificación, clase y secuencia no coincidió con el Req/Ntf original.

Nota: El MICA puede actuar solamente como un cliente o iniciador para comprobar

3,4 0x236 Esta razón de la desconexión indica no más el recibo de un bastidor de la petición 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 la comienza cuando se envía una trama de recepción síncrona, enarena para cuando una sincronización-recepción (caso de la colisión) o se detecta una trama de control. Este error ocurrirá solamente cuando el puerto MICA está actuando como servidor (modo contestar), que es el modo de operación 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 0x23A El temporizador PIAFS T101 caducó: temporizador de confirmación de espera de la trama 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 negociada es menos que el valor RTF (retardo de ida y vuelta). Este error ya no es publicado por Portware y nunca debería observarse.
3,4 0x23E PIAFS: el campo de la extensión 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: negociación del protocolo fallada. No hay protocolo (por ejemplo, velocidad fija del protocolo de la Transferencia de datos, tipo 1 de la velocidad variable DTP) aceptable por 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 administrador de evento. 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 la mica no vio la respuesta del cambio de velocidad en el plazo de 200 milisegundos.
3,4 0x245 El CP de la mica vio la información de control contraria en las estructuras de control compartido 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).
Mún comando protocol recibido MNP o LAPM 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. Un MNP LD o la trama del LAP-M Frame Reject (FRMR) se envía en la 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 de la razón está en los dos dígitos más recientes
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 los informes de peer tiene mún parámetro #1. El módem del host recibió una trama FRMR del módem del cliente. La trama recibida LD indica que el modem del cliente recibió una trama de petición de link del módem del host que contuvo un mún (es decir, inesperado) PARAM1. Para más información acerca de PARAM1, consulte la especificación V.42.
3 0x503 MNP: la trama LR de los 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 recibida LD indica que el modem del cliente recibió una trama LR del módem del host que es incompatible con el modem del cliente, configuración s.
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 los informes de peer expiró. El módem del host recibió una trama FRMR del módem del cliente. ¿La trama recibida LD indica que el modem del cliente? ¿hasn del host s (DTE)? t pasó los datos al modem del cliente dentro de un período de tiempo.
3 0x506 MNP: error de los 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 recibida LD indica una finalización normal de MNP, indicando que el DTR del modem del cliente cayó o que recibió un +++ o un comando ATH. Este motivo de desconexión ocurre en la configuración de la llamada y el modo de 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 la desconexión o el error 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, continuación de link de datos prohibida. 2 – Versión normal, continuación del link de datos. … Otras clases normales - clases no definidas peculiares a algunos dispositivos del 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 no posibles del uso de recurso - clases no definidas peculiares a algunos dispositivos del cliente.
3,4 0x63x Mantenga la clase no posible de la utilización para PIAFS DLR (malos parámetros). 9 - Pida la configuración de parámetro no posible. A - Pida la configuración de parámetro no posible actualmente. Clases no posibles de utilización en otro servicio - clases no definidas peculiares a los dispositivos de algunos clientes.
3,4 0x64x Mantenga la clase no todavía proporcionada para PIAFS DLR. 1- indicación de parámetro aún no proporcionada. … Clases no todavía proporcionadas del otro servicio - clases no definidas peculiares a algunos dispositivos del cliente.
3,4 0x65x Clase de contenido de la información no válido para PIAFS DLR. 8 - Atributo del terminal no coincidente. … El otro contenido de información no válida clasifica - las clases no definidas peculiares a algunos dispositivos del cliente.
3,4 0x66x Clase de error de secuencia para el DLR 0 PIAFS - Parámetros esenciales escasos. 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 expira. … Otras clases de error de secuencia - clases no definidas peculiares a algunos dispositivos del cliente.
3,4 0x67x Otra clase de peculiaridades para PIAFS DLR. 1 - Durante la llamada de voz. … Otras otras clases no definidas peculiares de las clases peculiares a algunos dispositivos del 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 caído. 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ó al comando ATH (desconexión).
3 0x1f05 Sin acceso a la red de la compañía telefónica. La desconexión ha ocurrido porque el host no podría acceder 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. También, si el cliente precipitadamente desenchufara la línea telefónica/apague el módem, después este motivo de desconexión sería considerado 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. La Desconexión indicada de red es tan, en este caso, probablemente indicativa de un modem del cliente infeliz, uno que decidía que podría sostener no más el portador 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. EL TERMINAR. El host envía este motivo de desconexión cuando recibe un mensaje de terminación no solicitado.

Motivo de desconexión: Tipos

Motivo de desconexión: tipos describe cuándo ocurrió de hecho 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 constante). 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. Datos del rx (línea a recibir) que 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), éste es el único tipo del modo de datos usado; no se hace ninguna indicación de la dirección que vacia de los datos.
5 0xA… En el modo de datos. Datos del rx (línea a recibir) que vacian NO OK. 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. Datos TX (host a alinear) que 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. Datos TX (host a alinear) que vacian NO 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. 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


Document ID: 5135