Estados do modem MICA e razões de desconexão

Introduction

Esse documento descreve como interpretar os códigos da razão da desconexão do atendimento relatados pelos modems MICA (agregação de canal de modem ISDN) da Cisco.

Observação: este documento contém muitos termos definidos nos padrões ITU, como V.90, V.44, V.42bis e V.34. Para obter mais informações sobre esses termos, consulte o padrão ITU-T apropriado. Os termos especificados nos padrões ITU-T não são explicados neste documento.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes do seguinte:

Sempre que uma chamada que usa partes específicas do domínio MICA (DSPs) for removida ou desconectada, o MICA registrará o motivo da desconexão. É possível usar essa razão para determinar se a desconexão foi normal. Se não, você poderá usá-lo para rastrear as possíveis origens da falha. Os modems podem ser desconectados devido a vários fatores, como desconexões do cliente, erros da empresa de telecomunicações e quedas de chamadas no servidor de acesso à rede (NAS). Um motivo típico de desconexão é que o DTE (modem cliente ou NAS) em uma extremidade deseja desligá-lo. Essas desconexões "normais" indicam que a desconexão não foi um resultado dos erros do modem ou do nível de transmissão. Para obter mais informações sobre como determinar se uma razão de desconexão é normal, consulte Visão geral de modem geral e qualidade de linha NAS.

Componentes Utilizados

Os modems MICA são utilizados nos servidores de acesso a seguir:

• Cisco 3600 Series Routers

• AS5200

• AS5300

• AS5800

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

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

Determinando o estado do modem

Use o comando show modem log slot/port para encontrar o estado atual de um modem MICA. Nesta saída de log, as entradas mais recentes estão no final do log. Os estado do modem MICA atual são exibidos no último evento de estado do modem (change). No exemplo de saída abaixo, o estado do modem está ocioso, indicado pelo evento Modem State com carimbo de 00:00:28. Consulte a tabela Estados do modem MICA para obter mais informações sobre os possíveis estados do modem MICA.

maui-nas-02#show modem log 1/0
Modem 1/0 Events Log:
  00:03:33:Startup event:MICA Hex modem (Managed)
           Modem firmware = 2.7.3.0
  
!--- This modem is using portware 2.7.3.0

  00:03:33:RS232 event:  noRTS, noDTR, CTS, noDCD
  ...
  ...
  
!--- This output was removed for brevity.

  ...
  00:00:28:Modem State event:
           State: Terminate
  00:00:28:RS232 event:  noRTS, DTR, CTS, noDCD
  00:00:28:RS232 event:  RTS, DTR, CTS, noDCD
  00:00:28:Modem State event:
           State: Idle
  
!--- The last modem state event !--- This indicates that the modem is in state Idle

Determinando a razão de desconexão

Sempre que uma conexão de modem é encerrada, o NAS relata dois motivos de desconexão: os motivos DTE (IOS) e DCE (MICA). Esses motivos de desconexão podem ser reportados por meio de três métodos principais:

1. Registros de Chamada de Modem: Eles relatam os motivos de desconexão do IOS® Software e do modem MICA.

2. Registros de contabilização de AAA: Eles relatam somente a razão da desconexão do software IOS.

3. Comandos IOS: Comandos como show modem operational-status e show modem log relatam somente o motivo da desconexão do modem MICA.

Registros de chamada de modem

O motivo de desconexão do IOS e do modem para uma conexão específica é exibido no registro de chamada do modem (MCR). O MCR é enviado ao servidor syslog pelo NAS durante o término de cada chamada. Os registros de chamada de modem foram introduzidos nas versões 11.3AA e 12.0T do Software Cisco IOS e são ativados (no NAS) com o comando modem call-record terse. Para obter mais informações sobre como implementar registros de chamada de modem, consulte o documento Using Syslog, NTP, and Modem Call Records to Isolate and Troubleshoot Faults.

No exemplo de registro de chamada de modem mostrado abaixo, o motivo de desconexão do IOS indicado por disk(radius) é Lost Carrier/Lost Carrier, enquanto o motivo de desconexão do modem indicado por disk(modem) é:

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

Consulte a tabela Motivos de Desconexão do Modem Mica para obter mais informações sobre como interpretar o motivo da desconexão do modem.

*May 31 18:11:09.558: %CALLRECORD-3-MICA_TERSE_CALL_REC: DS0 slot/contr/chan=2/0/18, 
slot/port=1/29, call_id=378, userid=cisco, ip=0.0.0.0, calling=5205554099, 
called=4085553932, std=V.90, prot=LAP-M, comp=V.42bis both, init-rx/tx b-rate=26400/41333, 
finl-rx/TX brate=28800/41333, rbs=0, d-pad=6.0   dB, retr=1, sq=4, snr=29, rx/TX chars=93501/94046,
bad=5, rx/TX ec=1612/732, bad=0, time=337, finl-state=Steady, 
disc(radius)=Lost Carrier/Lost Carrier, disc(modem)=A220 Rx (line to host) 
data flushing - not OK/EC condition - locally detected/received
DISC frame -- normal LAPM termination

Registros de relatório de AAA

Os logs de contabilidade AAA também podem ser usados para determinar a razão da desconexão do IOS. No exemplo de consulta de AAA sql abaixo, podemos ver a causa da desconexão do raio:

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

O código de desconexão (disk-cause=4), no exemplo acima, indica que a desconexão foi causada pela expiração do Tempo de inatividade.

Observação: os registros de contabilidade AAA não exibem o motivo de desconexão MICA, portanto, a tabela fornecida neste documento não pode ser usada para interpretar o motivo de desconexão Radius.

Para obter mais informações sobre como implementar relatório AAA, consulte o documento sobre como implementar relatório AAA baseado em servidor.

Os comandos show modem operational-status e show modem log

Os comandos show modem operational-status slot/port e show modem log slot/port do IOS podem ser usados para determinar o motivo da desconexão de MICA.

A saída desse comando mostra por que a conexão foi perdida ou por que as conexões atuais não são o que você esperava. Consulte os motivos de desconexão abaixo para obter explicações sobre os diferentes tipos de desconexão.

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.

O slot/porta show modem log também exibe o motivo da desconexão

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 da razão de desconexão

Um motivo de desconexão consiste em quatro dígitos hexadecimais. Os três dígitos hexadecimais de ordem baixa podem ser usados para identificar a razão da desconexão. O dígito hexadecimal de alta ordem geralmente indica o tipo de motivo de desconexão ou o momento em que o motivo de desconexão ocorreu. Estas opções são descritas na seção Razão de desconexão: Tipos. Por exemplo, se o motivo da desconexão for 0xWXYZ, 0xXYZ poderá identificar esse motivo enquanto 0xW indica quando ele ocorreu.

Nos exemplos acima, 0xF03 e 0x220 identificam o motivo da desconexão enquanto 0xD e 0x8 indicam quando o motivo da desconexão ocorreu. As definições para as razões de desconexão do MICA são fornecidas na seção MICA Modem Disconnect Reasons (Razões para desconexão do modem MICA).

Para obter mais informações sobre operações de modem MICA, consulte a documentação Verifying Modem Performance and Modem Management Operations no Cisco AS5x00 Case Study for Basic IP Modem Services.

Estados de modem MICA

Estado	Descrição
OCIOSO (#0)	Nesse estado, a sessão do modem está inativa no momento. O estado IDLE (LIVRE) foi inserido no estado TERMINATING (TERMINAÇÃO) durante a verificação de recepção no DSP em que todas as operações foram interrompidas.
CALL_SETUP (#5)	Nesse estado, o processador de sinais do modem fica preparado para receber e gerar sinais T1, de freqüência múltipla (MF), de tom dual de freqüência múltipla (DTMF), R1, R2 e de progresso de chamadas. O modem permanece no estado CALL_SETUP até receber uma mensagem LINK_TERMINATE, SOFTWARE_RESET ou INITIATE_LINK do host.
CONECTAR (#10)	O estado CONNECT é inserido do estado CALL_SETUP(#5) somente ao receber o comando host para Iniciar. No modo de resposta, a sessão do modem iniciou a atividade, mas ainda não começou a produzir um Tom de resposta. No modo de origem, a sessão do modem iniciou a atividade, mas ainda não detectou um Tom de resposta.
LINK (15)	O estado LINK é introduzido a partir do estado CONNECT somente ao detectar um Tom de replicação (origem) ou o Tom de replicação (resposta). No modo Answer, a sessão do modem transmite um Answerback Tone para a linha. No modo de Originação, a sessão do modem detectou a quantidade mínima (configurável) exigida de tom de replicação. Isso indica que há um peer remoto.
QC (nº 16)	Pode-se entrar no Quick Connect (QC) através do LINK ou estado Exchange do V.8 bis se o QC estiver ativado, e com o recebimento de uma seqüência QCA (modo Originate) ou envio de uma seqüência QCA (modo Answer).
TREINAMENTO (Nº 20)	Nesse estado, a sessão do modem negocia o padrão de modulação física (conforme configurado) usado durante o link. O estado TRAINUP é inserido do estado LINK somente quando: Detecção do final de um Tom de Replicação (originar). Concluindo a transmissão de um Tom de replicação (resposta).
EC_NEGOCIATION (#25)	Nesse estado, a sessão do modem negocia a correção do erro e o protocolo de compactação de dados a ser usado durante o link. Quando as configurações são agradáveis a ambos os modems (a interseção dos dois modems, capacidades e configuração), uma negociação bem-sucedida é alcançada. Se a interseção for nula, o modem será desconectado ou iniciará uma sessão conectada sem erros. O estado EC_NEGOTIATING é inserido do estado TRAINUP após a conclusão bem-sucedida da sincronização da modulação física.
STEADY_STATE (#30)	Nesse estado, a sessão do modem pode transmitir dados no link. O estado STEADY_STATE é inserido pelo estado EC_NEGOTIATING: Após a negociação bem-sucedida do protocolo (conforme configurado). A partir dos estados STEADY_STATE_RETRAINING e STEADY_STATE_SHIFTINGSPEED, visto que o enlace físico é renegociado com êxito. Em modo de fax; esse estado significa que o mecanismo T30 está em execução. Durante uma chamada de fax, há uma alternância entre STEADY_STATE para STEADY_STATE_ESCAPE. Isso representa a chamada de fax passando por suas diferentes fases de uma sessão de fax (T30).
STEADY_STATE_RETRAINING (#35)	Nesse estado, a sessão de modem está sendo reciclada. O estado STEADY_STATE_RETRAINING é inserido dos estados STEADY_STATE ou STEADY_STATE_SHIFTINGSPEED: Comando Upon Host Link_Control - [Retrain]. Retirando um limiar interno (configurável).
STEADY_STATE_SHIFTINGSPEED (#40)	Neste estado, a sessão do modem está transferindo a velocidade atualmente. O estado STEADY_STATE_SHIFTINGSPEED é inserido do estado STEADY_STATE : Em Host_Link_Control - [Fallback, Fall-Forward]. Retirando um limiar interno (configurável).
STEADY_STATE_ESCAPE (#45)	Nesse estado, o modem ainda está conectado ao peer remoto, mas a interface do host está no modo de comando AT. Entra-se neste estado somente com o recebimento de uma seqüência de escape Hayes válida. No modo Fax, esse estado significa que o mecanismo T30 está aceitando comandos AT do host. Consulte o estado STEADY_STATE (#30) para obter informações sobre uma chamada de fax.
TERMINANDO (#50)	Nesse estado, a sessão do modem tenta limpar os dados do usuário e limpar o DSP (digital signal processor, processador de sinal digital). Em um Software_reset , não há fluxo ordenado e o DSP é RESET. O estado TERMINATE é inserido a partir de qualquer estado: Após LINK_TERMINATE ou Software_reset do host. Na perda do portador do DSP. Na recepção de um comando ATH do DTE. Ao receber um quadro de correção de erros DISK/LD (desconectar) da linha. Pela remoção de vários limiares internos (configuráveis).
EM ESPERA ( Nº 55 )	A sessão do modem é mantida e os dados não passam no enlace. O estado Em Espera é inserido a partir do estado estável após a recepção de uma mensagem de solicitação (MHReq) de Modem em Espera (MoH). Se o modem em espera estiver ativado (Registro S62), o modem deve transmitir a sequência de Reconhecimento de Modem em Espera (MHack) para conceder a solicitação e transmitir o SNA (Answer Tone) quando o silêncio ou RT for detectado. Se um sinal Call Menu (CM) (para V.8) ou uma seqüência Quick Connect Acknowledge-QCA (QC - Registro S63) for detectado em um estado de espera, o modem deverá sair do estado de espera e responder à seqüência inicial de acordo com as recomendações do V.8 ou do QC (Registro S63), respectivamente. Se nenhuma seqüência inicial for detectada depois que o valor de timeout on hold for definido, o modem deixará o estado On Hold e será desconectado. Se o modem em espera estiver desativado, o modem transmitirá MHnack. Se MHcda for detectado após a transmissão de MHnack, o modem será desconectado. Se o MHfrr for detectado após o MHnack ser transmitido, o modem deverá transmitir o tom de resposta e preparar-se para detectar as seqüências CM (V.8) ou o QCA (QC - registro S63) do modem remoto. Para obter mais informações sobre Modem em espera, consulte as especificações ITU-T V.92. Observação: o estado MICA #55 era anteriormente o estado VOICE, que agora foi removido das versões 2.9.1.0 e superiores do portware.
TROCA V.8bis (Nº 71)	Esse estado é inserido do estado CONNECT somente quando se detecta CRe (modo de origem) ou quando se inicia o CRe (modo de resposta). Modo de resposta: A sessão de modem está transmitindo um CRe para a linha. Modo de origem: A sessão do modem detectou a resposta automática de solicitação de recurso (CRe). Isso indica que há um peer remoto.
INTERVALO(#72)	RANGING é inserido a partir do estado LINK ou QC (Registro S63) ao iniciar a estimativa RTDEd. Esse estado só se aplica aos padrões V.32 e posteriores.
INTERVALO CURTO(#73)	RANGING SHORT é inserido a partir do QC (Registro S63) ao iniciar o Roteamento Trip Delay Estimate-Digital Modem (RTDEd)
TREM DE ALTA DEFINIÇÃO (Nº 74)	HD TRAIN (trainup semi-duplex) é introduzido de RANGING ou RANGING SHORT até o início do treinamento do filtro de adaptação. Isso se aplica ao V.22bis e superiores.
STEADY_STATE_PIAFS_RESYNC(#80)	Inserir STEADY_STATE_PIAFS_RESYNC indica que uma chamada PIAFS (Personal Handyphone Internet Access Forum Standard) perdeu a sincronização e está executando uma ressincronização.
STEADY_STATE_PIAFS_SPEEDSHIFT(#85)	A entrada de STEADY_STATE_PIAFS_SPEEDSHIFT indica que uma chamada PIAFS está negociando uma troca de transparência de velocidade. Esse é um estado momentâneo, transitório. O MICA jamais permanecerá nesse estado. Se a ressincronização resultar em uma mudança de velocidade, então o MICA passa para esse estado a partir de STEADY_STATE_PIAFS_RESYNC e, em seguida, vai para STEADY_STATE. Se a resincronização NÃO resultar em uma mudança de velocidade, então STEADY_STATE_PIAFS_RESYNC passará diretamente para STEADY_STATE quando estiver completa.

Razões para desconexão do modem MICA

Um motivo de desconexão do modem MICA consiste em quatro dígitos hexadecimais. Os três dígitos hexadecimais de ordem inferior identificam exclusivamente o motivo da desconexão. O dígito hexadecimal de ordem alta indica o tipo do motivo da desconexão ou o horário no qual o motivo da desconexão ocorreu. No exemplo acima, onde o código de desconexão é hexadecimal 0xDF03, 0xF03 identifica o motivo da desconexão enquanto 0xD indica quando o motivo da desconexão ocorreu (Motivo da desconexão: Tipos).

As razões de desconexão descritas abaixo não incluem o tipo de desconexão. Portanto, pelo motivo da desconexão, retire o dígito hexadecimal mais à esquerda e compare os dígitos restantes com as opções abaixo. A partir do exemplo acima, procure o 0xF03 na seção abaixo.

Observação: neste documento, o modem do host é o modem MICA no Cisco Access Server, enquanto o modem do cliente é o modem do dispositivo remoto (por exemplo, um modem do PC cliente).

Tipo de desconexão	Código de razão da desconexão	Descrição
-	0	Ainda não ocorreu desconexão. Você vê esse código se o motivo da desconexão é colocado na fila imediatamente após o carregamento do Portware ou durante uma chamada, antes do estado constante.
Razões gerais de desconexão (Classe 0)
2	0x001	O Cisco IOS encerrou abruptamente a chamada por algum motivo - por exemplo, porque a camada 1 caiu no intervalo físico que contém a chamada.
2	0x002	Terminação da camada de Correção de Erro (EC).
2	0x003	A tarefa de descompressão do Microcom Network Protocol 5 (MNP5) recebeu um token ilegal no fluxo de dados. Esse motivo de desconexão ocorre durante o modo de dados (0x3003). Existe a possibilidade de um erro lógico na implementação de modem ou de parceiro da compactação/descompactação ou correção de erro. (Também existe a possibilidade de um acerto de linha ocasional ou de um erro de memória RAM.)
2,4,6	0x004	A tarefa de descompressão V.42bis ou V.44 recebeu um token ilegal no fluxo de dados. Esse motivo de desconexão pode ocorrer durante o modo de dados (0x4004). Existe a possibilidade de um erro lógico na implementação de modem ou de parceiro da compactação/descompactação ou correção de erro. (Também existe a possibilidade de um acerto de linha ocasional ou de um erro de memória RAM.) Para o V.44, esse código é complementado pelo campo de informações de enlace de diagnóstico índice 119 (um campo de informações de oito bytes usado como uma ferramenta de depuração).
2	0x005	Erro de software MICA. O código de erro para esse motivo de desconexão é 0x4005. Um erro de software MICA ocorre e indica uma variável de estado de co-processador incorreta.
6	0x006	O comando ATH foi detectado pelo modem local. Esse motivo de desconexão ocorre durante o modo de dados (0xC006 e 0xE006). O comando ATH (Hangup) foi detectado pelo modem local (MICA). Por exemplo, durante um dialout de IOS, depois que a chamada for conectada, a interface DTE do IOS apagou a chamada transmitindo o comando ATH na banda.
3	0x007	O comando AT dial foi cancelado . O comando AT dial foi abortado pelo comando any key abort. Por exemplo, o modem do host origina uma chamada. Durante o estabelecimento da conexão, antes do ESTADO ESTACIONADO, pressionar qualquer tecla fará com que o comando de discagem AT seja cancelado.
3	0x008	A conexão de chamada demorou muito para ser concluída. Observe que o temporizador S7 (aguarde pela portadora após discagem) expirou para essa desconexão. Este motivo de desconexão ocorre durante o estabelecimento da chamada (0x6008). O modem host demorou tempo demais para estabelecer uma conexão devido à reciclagem. As causas são: dificuldade na escolha (negociação) de um padrão de Camada I (por exemplo, abortar a chamada antes de retornar com a razão de desconexão 0x6102) ou a demora no estabelecimento de uma combinação da Camada I e da Camada II. Por exemplo, a negociação de correção de erros leva um tempo estendido no topo de um novo treinamento ou devido a erros de bits introduzidos quando o modem cliente tenta se conectar a uma taxa agressiva (o receptor do modem cliente tenta se conectar a uma taxa que não pode manter). Esse tipo de desconexão é considerada contra CSR. Essa desconexão também pode ocorrer se o modem de resposta não ouvir nenhum tom do canal (Por exemplo, o originador não foi um modem).
2	0x009	O DSP foi redefinido (comando, interno ou espontâneo). O código de erro para esse motivo de desconexão é 0x4009. O DSP dentro do modem do host foi reinicializado pelo Processador de controle (PC) ou pelo Processador de sinal (PS). O CP redefinirá o DSP se as mensagens de correio do CP para o SP não estiverem sendo confirmadas. O SP será redefinido se receber um erro de inconsistência interna.
4,6	0x00A	Recebimento de uma palavra de código STEPUP ilegal. Especifica o recebimento de uma palavra de código STEPUP quando isso faria com que o valor de C2 (tamanho de palavra de código atual) excedesse N1 (tamanho máximo de palavra de código: negociado) e é válido somente para V.44 e V.42bis.
4,6	0x00B	Recepção de uma palavra de código V.42bis ilegal. Especifica o recebimento de uma palavra de código, a qualquer momento, igual a C1 (próxima entrada de dicionário vazia) e é válido para V.42bis. (Recebimento de uma palavra de código = C1 é ilegal em V.42bis, mas legal em V.44).
4,6	0x00C	Recepção de um token ilegal (demasiado grande) em V.44 ou V.42bis. Isso significa que o tamanho da palavra do código V.42bis ou V.44 recebido excedeu o máximo negociado. Especifica o recebimento de uma palavra de código, a qualquer momento, maior que C1 (próxima entrada de dicionário vazia) e é válido para V.44 e V.42bis.
4,6	0x00D	Recebimento de um código de comando reservado V.44 ou V.42bis. Especifica o recebimento de um código de comando reservado e é válido para V.44 e V.42bis.
4,6	0x00E	V.42bis ou V.44 recebeu uma palavra de código maior que a próxima entrada de dicionário vazia. Recebimento de um caractere V.44 Illegal STEPUP. Indica o recebimento de um código de controle STEPUP que faria com que o valor de C5 (tamanho normal) excedesse oito. Isso é válido apenas para V.44.
4,6	0x00F	Dicionário Rx V.44 Cheio. Especifica o recebimento de uma palavra de código que não é uma redefinição de dicionário quando a árvore de nó Rx está cheia. Válido apenas para V.44.
4,6	0x010	Histórico De Rx V.44 Completo. Especifica o recebimento de uma palavra de código que não é uma redefinição de dicionário quando o histórico Rx está cheio. Válido apenas para V.44.
4,6	0x011	Tamanho De String Rx Ilegal V.44/V.42bis Excedido. Especifica o recebimento de uma palavra de código que faz com que o tamanho máximo negociado da string seja excedido. É válido para V.44 e V.42bis.
4,6	0x012	Ocorreu um erro de negociação do V.44 Especifica que ocorreu um erro de negociação do V.44. Para V.44, este código é complementado pelo campo de informações de link de diagnóstico índice 119. O índice do campo de informações de enlaces de diagnósticos é um campo informativo de oito bytes usado como uma ferramenta de depuração.
4,6	0x013	Ocorreu um erro de compactação V.44 Especifica que ocorreu um erro de compactação V.44. Para V.44, este código é complementado pelo campo de informações de link de diagnóstico índice 119. O índice do campo de informações de enlaces de diagnósticos é um campo informativo de oito bytes usado como uma ferramenta de depuração.
Condições informadas pelo DSP (classe 1)
	0x1xx	Condições DSP relatadas pelo SPE
3,4,5	0x100	O DSP perdeu o sinal da Portadora. Isto é, o MICA detectou um descarte de portador de modem de cliente. Essa causa de desconexão ocorre durante a configuração de chamada e o modo de dados (ou seja, 0x6100, 0x8100 e 0xA100). O MICA DSP parou de ouvir a transportadora por um período superior ao valor especificado no Registro S10 (atraso de desligamento após perda da transportadora). Isso pode indicar que o caminho de conversa desapareceu ou que o cliente parou de transmitir. Se um protocolo da camada II (V.42 e/ou V.42bis) estiver em vigor, seria anormal ver tal desconexão. Esse motivo de desconexão ocorre às vezes durante a negociação EC (antes do modo de dados). Ou seja, a Camada I foi negociada com êxito (resultando em uma detecção de sinal de portadora) e a desconexão ocorre ao se tentar estabelecer o protocolo da Camada II (V.42 e/ou V.42bis). Causas comuns são usuários que abortam a chamada antes que a conexão seja efetuada. A discagem incidental, inicializações abortadas e intervalo de aplicativos do cliente devido à demora na conexão (por exemplo, diversas recliclagens durante a negociação de camada I). Esse tipo de falha conta com o CSR. A condição de perda da portadora também pode ocorrer durante o modo normal de dados, quando o cliente perde a portadora repentinamente. A causa comum é uma desconexão não-negociada ou suja por parte do modem cliente (ou seja, o modem cliente apenas descarta o sinal da portadora). Isso poderá ocorrer se o link for abruptamente descartado (ou seja, erro de rede), a energia do modem do cliente é desligada para desconectar a chamada. Isso também pode ocorrer com modems clientes mais baratos que não implementam os protocolos clear-down de Camada I e/ou Camada II em uma queda DTR. Em um grande número de modems de cliente, essa desconexão é considerada normal. Quando o modem cliente realiza uma desconexão suja, ocorre uma condição de disparo entre 0xA103, 0xA100 e 0xDF06. Se o DSP com o modem host detectar uma perda de portadora, o 0xA100 ganhará e será indicado como motivo da desconexão. Se o DSP não detectar uma perda de portadora e fizer uma reciclagem até que chegue ao limite de registro S40, então o 0xA103 vence. Se a rede detectar que a chamada foi desconectada e sinalizar para que o roteador desconecte, o 0xDF06 ganhará. Essa razão de desconexão não será levada em conta em relação ao CSR quando o modem do host estiver em modo de dados.
3	0x101	Isso ocorre quando a controladora de armazenamento está na fase de detecção ABT (Answer Back Tone, Tom de retorno de resposta) quando ocorre uma falha de chamada.
3	0x102	Falha de chamada durante o treinamento do modem devido a modulação incompatível ou linha incorreta. Esse motivo de desconexão ocorre durante a configuração da chamada (0x6102). Isso pode indicar tentativas para negociar uma modulação não suportada, como uma modulação proprietária da Rockwell herdada (K56Plus, V.FC, etc.). Outras causas possíveis são falhas de DSP para treinamento devido a danos graves na linha, ruídos de impulsos, interrupção de treinamento, parâmetros de modulação incompatíveis e, talvez, a incapacidade de selecionar adequadamente um padrão de Camada I. Esse tipo de desconexão é considerada contra CSR.
4,5	0x103	Muitas reciclagens consecutivas ou transferências de velocidade. O limite de reciclagem é especificado com Register S40. Este motivo de desconexão ocorre durante a configuração de chamada e o modo de dados (0x6103, 0x8103 e 0xA103). Durante o andamento de uma chamada, ocorreram muitas reciclagens que processaram a chamada sem efeito uma vez que a taxa de dados seria tão baixa quanto inútil. Condições possíveis são quando o modem cliente não conclui o protocolo de clear-down (por exemplo, a telco cortou a chamada no meio da conexão) e o MICA tenta recuperar a chamada emitindo reciclagens. Quando o limite de reciclagem é atingido (o limite de reciclagem pode ser alterado usando o registro S40), o MICA descarta a chamada e informa esse motivo de desconexão. Em algumas circunstâncias (T1/E1 canalizado), esse tipo de desconexão pode ser considerado uma desconexão de estado STEADY normal. como alternativa, isso pode ser simplesmente o resultado de uma desconexão suja devido a possíveis erros de linha dos quais o MICA não pode se recuperar. Portanto, esse tipo de desconexão não conta para o CSR, pois a chamada já está estabelecida. Esse motivo de desconexão também pode ocorrer durante a negociação do EC, quando o modem cliente está extremamente agressivo em relação à taxa inicial de conexão e não pode manter a chamada (como pode ser observado nos antigos modems clientes da USRobotics). Esse tipo de desconexão não é considerada contra o CSR. Quando o modem cliente realiza uma desconexão suja, ocorre uma condição de disparo entre 0xA103, 0xA100 e 0xDF06. Se o DSP (Digital Signal Processor) do modem do host detectar uma perda de portadora, 0xA100 ganha e é indicado como o motivo da desconexão. Se o DSP não detectar uma perda de portadora e fizer uma reciclagem até que chegue ao limite de registro S40, então o 0xA103 vence. Se a rede detectar que a chamada foi desconectada e sinalizar para que o roteador desconecte, o 0xDF06 ganhará. Essa razão de desconexão não será levada em conta em relação ao CSR quando o modem do host estiver em modo de dados.
3	0x104	Problema ao detectar o fim do tom de resposta (ABT). Falha na negociação ou ruído excessivo durante o treinamento V.34. Os modems de host respondem e enviam tons de resposta (ABTs) V.8bis e modulados de 2100Hz com reversões de fase, mas encontram ruído excessivo durante a sequência de treinamento. Procure por erros do caminho do modem chamador ao modem de resposta em uma ou ambas as direções. Ocorre comportamento semelhante onde houver latência no Public Switched Telephone Network (PSTN) para a discagem que exceder um segundo e deixar os modems indisponíveis para treinamento de canceladores de eco. Outras possíveis causas são: Os níveis de potência de TX reais estão incorretos e, portanto, os tons não são processados pelo lado remoto. Há muito ruído excessivo nas Fases III e IV durante o treinamento V.34. Há um erro de operador. Há uma interferência na rede durante o treinamento V.34 (alguém seleciona a extensão). Esse tipo de desconexão é considerada contra CSR.
3	0x105	Operação SS7/COT (Continuity Test) concluída com êxito. Esse motivo de desconexão ocorre durante a configuração da chamada (0x6105). A operação SS7/COT (Teste de continuidade) foi concluída com êxito.
3	0x106	Falha na operação SS7/COT (Teste de Continuidade): T8/T24 timeout esperando o tom ligado. Este motivo de desconexão ocorre durante a configuração de chamada (isto é, 0x6106). A operação SS7/COT (Teste de Continuidade) falhou porque o temporizador T8/T24 parou enquanto aguardava por um tom.
3	0x107	Falha na operação SS7/COT (Teste de Continuidade): T8/T24 timeout esperando o tom desligado. Esse motivo de desconexão ocorre durante a configuração da chamada (0x6107). A operação SS7/COT falhou porque o temporizador T8/T24 expirou enquanto aguardava o tom desligado.
4	0x108	Modem On Hold (MOH) cleardown pelo MICA. A solicitação Modem On Hold Cleardown (Liberação de Modem Retido) foi recebida no modem cliente. V.92 especifica que o motivo da exclusão pode ser: Exclusão devido à chamada recebida. Apagado devido à chamada efetuada. Liberação devido a outro motivo.
4	0x109	O valor de tempo limite do Modem On Hold (MOH) foi atingido.
Condições EC locais (classe 2)
	0x2xx	Condições locais CE
3	0x201	Nunca recebeu uma estrutura de LR (solicitação de enlace) durante a negociação. Este motivo de desconexão ocorre durante a configuração da chamada (ou seja, 0x6201). Isso significa que o modem do host nunca recebeu o quadro LR durante a negociação de correção de erros. O modem de peer pode não suportar MNP dentro de V.42.
3	0x202	Foi recebido um quadro LR com um parâmetro inválido (PARAM1). O quadro Link Request (LR) MNP recebido tinha PARAM1 inválido ou inesperado. Para obter mais informações sobre PARAM1, consulte a especificação V.42.
3	0x203	Recebido um quadro LR (Solicitação de Link) incompatível. Esta causa da desconexão ocorre durante a configuração da chamada (0x6203). A estrutura LR MNP recebida é incompatível com as configurações do modem de host para EC.
4,5	0x204	Muitas retransmissões consecutivas. Esse motivo de desconexão ocorre durante a configuração da chamada e o modo de dados (0x8204, 0xA204 e 0x6204). Essa razão de desconexão pode ser causada por ruído na linha. Por exemplo, o modem do host transmite dados para o modem do cliente, mas o ruído na linha faz com que os dados sejam recebidos incorretamente (ou nem sejam recebidos) pelo cliente. Assim, o ruído excessivo pode levar a retransmissões em excesso. O modem de cliente também pode ter sido desconectado sem que o modem de MICA percebesse. Por isso, o modem host retransmite continuamente, sem saber que o modem cliente não está mais presente. Às vezes, quando a chamada se conecta a um protocolo de compressão de erros (EC) (Link Access Procedure for Modems (LAPM) ou Microcom Networking Protocol (MNP)), o MICA não consegue transmitir um quadro ao modem do cliente. O modem cliente não reconhece a transmissão inicial da MICA e por isso não responde às chamadas seletivas (o padrão é 12) S19 (Limite de retransmissão de correção de erro), fazendo com que a MICA desconecte a chamada. Uma causa pode ser que a portadora do caminho de transmissão tenha sido substancialmente degradada enquanto o downshift do cliente falhava. Outra causa poderia ser um problema com o mecanismo EC do cliente (como aconteceria em um sistema Winmodem se o Windows parasse de responder).
6,7	0x205	Limite de tempo de inatividade esgotado, Desconexão de Enlace (LD) de MNP enviado. Esse motivo de desconexão ocorre no modo de dados (0xC205 e 0xE205). O modem do host envia ao modem do cliente um quadro LD indicando que ocorreu um intervalo de inatividade.
4,5	0x206	Erro do protocolo EC. Este motivo de desconexão ocorre durante o modo de dados (0x8206 e 0xA206). Esse é um erro genérico do protocolo de captação geral Indica que ocorreu um erro de protocolo LAPM ou MNP EC.
3	0x210	Não há um protocolo de recuo EC disponível. Essa desconexão ocorre durante o estabelecimento da chamada (0x6210). A negociação de correção de erro não foi bem-sucedida. A chamada é terminada porque não há protocolo de recuo de correção de erros disponível. O S-register S25 (fallback de protocolo de ligação) determina o protocolo de fallback disponível. As opções são enquadramento assíncrono, enquadramento síncrono ou desconectar (desligado).
3	0x211	Nunca recebeu um quadro de identificação de intercâmbio (XID) durante a negociação. Este motivo de desconexão ocorre durante a configuração de chamada (0x6211). Isso significa que o modem do host nunca recebeu o quadro XID durante negociação de correção de erros. O modem do cliente pode não suportar LAPM dentro de V.42.
3	0x212	A estrutura XID recebida é incompatível com as configurações locais. Esse motivo de desconexão ocorre na configuração da chamada (0x6212). O quadro XID recebido é incompatível com as configurações do modem do host. Por exemplo, o modem do cliente pode indicar MNP5, enquanto o modem do host indica apenas V.42 e V.42bis.
3,4,5	0x220	Estrutura DISC (Disconnect) recebida. Essa a desconexão normal de LAP-M. Esta razão de desconexão ocorre durante a configuração da chamada e o modo de dados (0x 6220, 0x8220 e 0xA220). A chamada terminou normalmente com uma liberação adequada por parte do cliente. (isto é, um pacote de desconexão V.42 foi enviado do modem do cliente para o modem NAS.) O modem do cliente descartou o DTR e negociou de forma inteligente um protocolo simples.
3,4,5	0x221	Quadro DM recebido. O par está possivelmente a desligar. Esse motivo de desconexão ocorre na configuração de chamada e no modo de dados (0x6221, 0x8221 e 0xA221). O modem cliente indica que ele está desconectando. Durante a configuração da chamada, esta razão indica que o modem cliente está desistindo da negociação da correção de erro.
4,5	0x222	Recebeu um número de seqüência incorreto. Esse motivo de desconexão ocorre no modo de dados (0x8222 e 0xA222). O modem host recebeu um quadro de correção LAPM ou MNP com um número de seqüência ou de reconhecimento incorreto. Um quadro de LD ou rejeição de estrutura (FRMR) é enviado ao modem do cliente indicando que o modem do host está sendo desconectado.
4,5	0x223	Frame SABME recebido no estado fixo. Esse motivo de desconexão ocorre no modo de dados (0x8223 e 0xA223). Isso é interpretado como um erro de protocolo de correção de erro LAPM em estado fixo. Significa que o modem do cliente pode ser reiniciado devido ao recebimento de uma rejeição de estrutura (FRMR).
4,5	0x224	Estrutura XID de MNP recebida em estado STEADY_STATE. Essa razão de desconexão acontece no modo de dados (0x8224 e 0xA224). Isso é interpretado como um erro de protocolo de correção de erro LAPM em estado fixo. Significa que o modem do cliente pode ser reiniciado devido ao recebimento de uma rejeição de estrutura (FRMR).
4,5	0x225	Quadro LR MNP recebido durante o estado constante. Esse motivo de desconexão ocorre no modo de dados (0x8225 e 0xA225). Isso é interpretado como um erro de protocolo de correção de erro MNP em estado fixo. Significa que o modem cliente foi reinicializado.
Condições Específicas do Protocolo PIAFS (Classe 2, continuação)
3,4	0x230	Uma mensagem recebida é menor que o tamanho mínimo definido para esse tipo de mensagem.
3,4	0x231	Tipo de quadro PIAFS desconhecido ou não implementado recebido. Isso inclui a FI (tipo de quadro principal) e negocia, sincroniza ou controla class (subtipo).
3,4	0x232	Identificador de Quadro de Controle (CFI) do PIAFS desconhecido. Um quadro de controle foi recebido com uma identificação desconhecida ou não implementada para esta classe. Observe que quadros contínuos e de usuário não são implementados e que não há quadros de notificação conhecidos.
3,4	0x233	A negociação de comunicação PIAFS falhou. Após a sincronização inicial, os quadros Req/Ack do parâmetro de comunicação são trocados. Os parâmetros eram inaceitáveis ou o iniciador detectou uma resposta NAK (Negative Acknowledgment). Observação: o MICA só pode operar como cliente/iniciador para fins de teste
3,4	0x234	Falha na negociação do ARQ do PIAFS. Após a ressincronização, os quadros de Solicitação ARQ (Req)/Confirmação (Ack) são trocados. Os parâmetros eram inaceitáveis ou o iniciador detectou uma resposta Nak. Observação: o MICA só pode operar como cliente/iniciador para fins de teste
3,4	0x235	Detectados problemas no PIAFS Control Transfer Protocol . O iniciador recebeu um Acn/Nak/Rsp cujo ID, Classe e Seqüência não correspondem ao Req/Ntf original. Observação: o MICA só pode operar como cliente ou iniciador para fins de teste
3,4	0x236	Este motivo de desconexão não indica mais o recebimento de um quadro de solicitação de DataLinkRelease. Agora, indica uma desconexão sem a geração de um motivo de desconexão anterior. Isso significa que o MICA está desconectando uma chamada, mas descobre que nenhuma razão foi publicada.
3,4	0x237	O temporizador de espera por recepção síncrona do PIAFS (T001) expirou. Esse cronômetro começa quando um quadro de requisição de sincronismo é enviado, parando quando esse quadro é detectado. Esse erro ocorrerá somente quando a porta MICA estiver operando como um cliente ou iniciador, o que acontece apenas durante o período de teste. O valor padrão é de 15 segundos.
3,4	0x238	O cronômetro T002 de transmissão de recepção pós-sincronização PIAFS expirou. Esse temporizador começa quando um quadro de recepção de sincronização é enviado e pára quando uma recepção de sincronização (caso de colisão) ou um quadro de controle é detectado. Esse erro ocorrerá somente quando a porta MICA estiver operando como um servidor (modo de resposta), que é o modo operacional normal. O valor padrão é de 15 segundos.
3,4	0x239	O temporizador de espera de requisição de sincronização de PIAFS T003 expirou. O temporizador é ativado quando são detectados erros de FCS contínuos e pára quando um quadro de requisição de sincronia é detectado. Esse erro ocorrerá apenas se a porta MICA estiver operando como servidor (modo de resposta), que é o modo operacional normal. O valor padrão é de 15 segundos.
3,4	0x23A	O temporizador PIAFS T101 expirou: temporizador de espera de confirmação de quadro de controle. Começa quando a requisição ou a notificação de quadro de controle é enviada e pára quando o quadro é confirmado. Esse erro ocorrerá somente quando a porta MICA estiver operando como cliente ou iniciador, o que só ocorre durante testes (dez segundos).
3,4	0x23B	PIAFS: FBI recebido (# seqüência ACK) a partir do intervalo negociado ou FBI=0 recebido com um quadro de dados não vazio.
3,4	0x23C	PIAFS: FFI recebido (nº de seqüência de MSG) fora do intervalo negociado, ou FFI=0.
3,4	0x23D	PIAFS: a janela de dados negociados é menor que o valor RTF (round trip delay). Esse erro não é mais publicado pela Portware e não será mais visto.
3,4	0x23E	PIAFS: o campo de comprimento de dados da mensagem é muito grande. Deve ser de 0 a 73.
3,4	0x23F	Erro interno de PIAFS: Chamada SREJ retornou um código de erro.
3,4	0x240	Erro geral de protocolo PIAFS. Esse é um receptáculo para erros que não têm um motivo de desconexão associado.
3,4	0x241	PIAFS: falha na negociação do protocolo. Nenhum protocolo (por exemplo, Velocidade Fixa do Protocolo de Transferência de Dados, Tipo1 de Velocidade Variável DTP) era aceitável para ambas as estações. Protocolos inaceitáveis seriam DTP de velocidade variável tipo 3 ou Protocolo de tempo real (RTP).
3,4	0x242	PIAFS: o valor de RTF medido (Retardo de round trip) não estava no intervalo definido (aceitável).
3,4	0x243	Erro interno de PIAFS: evento desconhecido no manipulador de eventos. Uma instrução de Switch não funcionou no caso padrão.
3,4	0x244	Ocorreu um intervalo de parada durante a resposta do SP (Processador de Sinal), no decorrer da transferência de velocidade de um PIAFS 2.1. O CP da América não viu a resposta de alteração de velocidade em 200 ms.
3,4	0x245	O CP de Mica viu informações de controle inconsistentes nas estruturas de controle compartilhado CP/SP. Em particular, o buffer de dados tinha um deslocamento inicial ou final que ultrapassava os limites do buffer de dados (0-63).
Recebido o comando MNP ou LAPM Protocol Incorreto do parceiro (Classe 3)
4.5	0x3xx	O EC detectou um código de comando incorreto. O comando received unknown está nos últimos dois dígitos. Um quadro MNP LD ou LAP-M Frame Reject (FRMR) é enviado em resposta.
O Parceiro LAPM Indica Erro de Protocolo MICA (Classe 4)
4,5	0x4xx	Condições de EC indicadas pelo cliente no quadro LAP-M FRMR. A razão do bit mapeado está nos dois últimos dígitos.
4,5	0x401	LAPM: correspondente relata comando incorreto. O modem do host recebeu um quadro FRMR do modem do cliente. O quadro de FRMR recebido indica que o modem cliente recebeu um quadro de correção de erro do modem do host, contendo um comando incorreto.
4,5	0x403	LAPM: o peer relata que o campo de dados não é permitido ou tem tamanho incorreto (quadros U). O modem do host recebeu um quadro FRMR do modem do cliente. O quadro FRMR recebido indica que o modem cliente recebeu um quadro de correção de erro do modem host que continha um campo de dados não permitido ou que continha um campo de dados com comprimento incorreto (quadro U).
4,5	0x404	LAPM: a extensão do campo de dados dos relatórios de peer é maior do que N401 (o campo de informações de extensão máxima especificado em V.42), mas tem boa FCS (seqüência de verificação de estrutura). O modem NextPort recebeu uma estrutura FRMR do modem cliente. O quadro FRMR recebido indica que o modem de cliente recebeu um quadro de correção de erro de NextPort que continha uma extensão de campo de dados que é maior que o número máximo de octetos que pode ser transportado no campo de informações (N401) de um quadro I, um quadro SREJ, um quadro XID, um quadro UI ou um quadro TEST. A seqüência de verificação da estrutura é boa.
4,5	0x408	LAPM: peer relata número de seqüência de recepção ou N(R) inválido. O modem do host recebeu um quadro FRMR do modem do cliente. O quadro FRMR recebido indica que o modem cliente recebeu um quadro de correção de erro do modem do host que continha um número de seqüência de recebimento inválido.
O parceiro MNP indica desconexão ou o erro do protocolo MICA (Classe 5)
4,5	0x5xx	Condições EC indicadas pelo cliente no quadro LD MNP. O campo Razão está nos dois últimos dígitos
3	0x501	MNP: o peer nunca recebeu o quadro LR. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro LD recebido indica que o modem cliente nunca recebeu uma solicitação de enlace do modem do host.
3	0x502	MNP: o quadro LR de relatórios de pares tem o parâmetro #1 incorreto. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro LD recebido indica que o modem cliente recebeu um quadro de solicitação de link do modem host que continha um PARAM1 ruim (ou seja, inesperado). Para obter mais informações sobre PARAM1, consulte a especificação V.42.
3	0x503	MNP: o quadro LR de relatórios de pares é incompatível com sua configuração. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro LD recebido indica que o modem cliente recebeu um quadro LR do modem do host incompatível com a configuração do modem do cliente.
4,5	0x504	MNP: o correspondente relata excessivas retransmissões de EC consecutivas. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro de LD recebido indica que o modem cliente recebeu excessivas retransmissões consecutivas.
4,5	0x505	MNP: o temporizador de inatividade de relatórios de peer expirou. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro LD recebido indica que o host do modem cliente (DTE) não passou dados ao modem cliente em um período de tempo.
3	0x506	MNP: erro de relatório de peer. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro LD recebido indica que o modem cliente recebeu um erro de protocolo MNP.
3	0x5FF	Desconexão de MNP normal. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro LD recebido indica uma terminação MNP normal, indicando que o DTR do modem do cliente foi descartado ou que recebeu um comando ++ ou ATH. Esse motivo de desconexão ocorre no modo de configuração de chamada e de dados (0x65FF, 0x85FF e 0xA5FF). O modem do host recebeu um LD, que indica uma terminação normal. A chamada encerrada normalmente com um clear down adequado no lado do cliente (por exemplo, um pacote de desconexão foi enviado do modem do cliente para o modem host): O modem do cliente descartou o DTR e negociou de forma inteligente um protocolo simples.
Parceiro PIAFS indica erro de desconexão ou protocolo MICA (Classe 6)
3,4	0x6xx	O MICA recebeu um PIAFS DataLinkRelease (PDLR) com o motivo xx (ver valores detalhados abaixo).
3,4	0x61x	Classe normal para DataLinkRelease (PDLR) de PIAFS: 0 - Versão normal. 1 - Versão normal, continuação de enlace de dados proibida. 2 – Versão normal, continuação do enlace de dados. ... Outras classes normais - classes indefinidas peculiares a alguns dispositivos clientes.
3,4	0x62x	O uso do recurso não é possível para a classe DLR PIAFS (condições de ocupado): 8 – DTE ocupado. 9 – Obstrução temporária. ... Outras classes de uso de recursos não possíveis - classes indefinidas peculiares a alguns dispositivos clientes.
3,4	0x63x	Classe de utilização de serviço não possível para PIAFS DLR (parâmetros incorretos). 9 - A configuração do parâmetro Request não é possível. A - A configuração do parâmetro Request não é possível no momento. .. Outras classes muito difíceis para utilização de serviço - classes indefinidas peculiares a alguns dispositivos de cliente.
3,4	0x64x	O serviço ainda não forneceu classe para PIAFS DLR. 1 – Indicação de parâmetro ainda não fornecida. ... Outros serviços ainda não fornecem classes - classes indefinidas peculiares a alguns dispositivos clientes.
3,4	0x65x	Classe de conteúdo de informações inválidas para PIAFS DLR. 8 - Atributo terminal não correspondido. ... Outras classes de conteúdo de informações inválidas - classes indefinidas peculiares a alguns dispositivos clientes.
3,4	0x66x	Classe de erro de sequência para PIAFS DLR 0 - Parâmetros essenciais insuficientes. 1 – Conteúdo de informações indefinido ou ainda não fornecido. 5 – A condição e o sinal ARQ não são correspondentes. 6 - O temporizador expira. ... Outras classes de erro de sequência - classes indefinidas peculiares a alguns dispositivos clientes.
3,4	0x67x	Outra classe de pecualiaridades de PIAFS DLR. 1 - Durante a chamada de voz. ... Outras classes peculiares - classes indefinidas peculiares a alguns dispositivos clientes.
Desconexão solicitada de host/IOS (classe 31)
6,7	0x1fxx	O host iniciou a desconexão. Valor é a soma de 0x1F00 e valor SessionStopCommand. Essa é a outra razão do encerramento do host. A razão do host é indicada na nos bytes xx de ordem baixa.
3,6,7	0x1f00	Host não específico iniciou desconexão. Valor é a soma de 0x1F00 e valor SessionStopCommand. Esse é o motivo genérico da desconexão iniciada de IOS. É usado em todas as desconexões não padrão. Por exemplo, poderia ser o resultado do software de gerenciamento de modem decidindo terminar a chamada. Uma explicação possível é uma falha de autenticação de nível superior RADIUS, TACACS ou outro aplicativo emitindo uma queda DTR para o modem do host. Este tipo de desconexão não contará para CSR quando o modem de host estiver no modo de dados.
3	0x1f01	O número discado estava ocupado. A desconexão ocorreu porque o host está indicando que o número discado está ocupado.
3	0x1f02	O número discado não respondeu. A desconexão ocorreu porque o host está indicando que o número discado não atendeu.
3,6,7	0x1f03	DTR virtual descartado. Esse status é reflexo do redirecionador de porta de E/S que está usando o modem atualmente. A desconexão ocorreu porque o host descartou a linha DTR virtual. Essa causa genérica de desconexão é iniciada pelo Software IOS da Cisco. As causas possíveis são timeout ocioso, TERMREQ de LCP PPP recebido, falha de autenticação, desligamento do Telnet, etc. Para determinar a razão da desconexão, examine a razão de desconexão de Radius, usando o comando modem call-record terse ou o AAA.
6,7	0x1f04	O comando ATH (desligamento) foi detectado pelo host local.
3	0x1f05	Sem acesso à rede Telco. Ocorreu uma desconexão porque o host não pôde acessar a rede (ISDN).
3,4,5 ,	0x1f06	Desconexão de rede indicada. Isso pode acontecer antes ou durante o modo de dados. Uma desconexão 0x1f06 significa que o IOS recebeu um sinal de desligamento de circuito da rede de circuito (ou seja, uma desconexão Q.931 ou um sinal no gancho CAS) e o IOS então comunicou isso ao MICA quando instruiu o MICA a se desconectar. Se o MICA alcançar o modo de dados e o protocolo EC (LAPM ou MNP4) não foi negociado, então deve se tratar de uma desconexão normal. Essa razão também pode ser gerada quando os usuários do DUN (Dial Up Networking) do Windows 95 ou 98 apertam cancelar durante o treinamento e antes da chamada atingir o estado fixo. Além disso, se o cliente fosse desconectar abruptamente a linha telefônica/desligar o modem, esse motivo de desconexão seria considerado normal. No entanto, se a conexão tiver negociado EC (LAPM ou MNP4) e então em modo de dados, esse motivo de desconexão pode ter sido gerado por uma desconexão suja (isto é, uma desconexão que não seja um encerramento de chamada delicado). Isso ocorre porque, se o cliente DTE (no modo dados) desconectar a chamada em um modo ordenado (com DTR drop ou +++/ATH), o modem do cliente nos enviará um DISC LAPM (ou LD MNP) antes de ele ir para o gancho, gerando, assim, uma razão de desconexão preferencialmente 0x220 e não 0x1f06. Portanto, a desconexão indicada pela rede é, neste caso, provavelmente indicativa de um modem cliente infeliz, que decidiu que não poderia mais sustentar a portadora por algum motivo.
3	0x1f07	NAS encerrou a operação do SS7/COT. A desconexão ocorreu porque o NAS terminou a operação SS7/COT (teste de continuidade).
3	0x1f08	A operação SS7/COT foi terminada pelo roteador devido a um intervalo T8/T24.
-	0x1fff	Não solicitado. TERMINANDO. O host envia essa razão de desconexão quando recebe uma mensagem de terminação não solicitada.

Razão de desconexão: Tipos

O motivo da desconexão:tipos descreve quando a desconexão de chamada realmente ocorreu. Eles podem ser categorizados em dois tipos principais: durante a configuração da chamada e durante o modo de dados (estado estacionário). A tabela a seguir especifica os tipos de motivos de desconexão mais comuns e seus valores, conforme indicado no motivo de desconexão.

Tipo de desconexão	Tipo de desconexão (Hex)	Descrição
0	0x0...	(não utilizado)
1	0x2..	(não utilizado)
2	0x4..	Outras situações.
3	0x6..	A condição ocorreu durante a configuração da chamada.
4	0x8...	No modo de dados. Descarregamento de dados Rx (linha para host) OK. A condição desconectada ocorreu no modo de dados. O MICA tenta fornecer qualquer dado recebido ao host (IOS). Para algumas desconexões (por exemplo, PIAFS), este é o único tipo de modo de dados usado; não há indicação de direção de fluxo de dados.
5	0xA...	No modo de dados. Descarregamento de dados Rx (linha para host) não OK. A condição desconectada ocorreu no modo de dados. O MICA tenta fornecer qualquer dado recebido ao host (IOS). Em código MICA herdado, este tipo é equivalente ao tipo 4 acima. Apesar de o IOS exibir tais desconexões como não OK, nenhum problema ocorreu realmente.
6	0xC...	No modo de dados. Transfira dados de TX (host para linha) OK. A condição desconectada ocorreu no modo de dados. O MICA tenta transmitir dados do host armazenados no buffer (IOS) para o modem de sócio.
7	0xE...	No modo de dados. Transmissão de dados de TX (host para linha) não OK. A condição desconectada ocorreu no modo de dados. O MICA tenta transmitir dados do host armazenados no buffer (IOS) para o modem de sócio. No código MICA herdado, esse tipo é equivalente ao tipo 6 acima. Apesar de o IOS exibir tais desconexões como não OK, nenhum problema ocorreu realmente.

Informações Relacionadas

• Conjunto de comandos MICA AT
• Conjunto de comandos MICA AT com PIAFS
• Notas da versão do software MICA
• Referências de comandos NextPort AT e registros S
• Suporte Técnico - Cisco Systems