Discar e acessar : Conexões assíncronas

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

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

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.

Nota:  Este documento contém muitos termos que são definidos nos padrões de ITU tais como o V.90, o V.44, o V.42bis, e o V.34. Para obter mais informações sobre destes termos satisfaça referem o padrão apropriadoleavingcisco.com do ITU-T. Os termos especificados nos padrões do ITU-T não são explicados neste documento.

Pré-requisitos

Requisitos

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 de desconexão típico é que o DTE (modem do cliente ou NAS) em uma extremidade quer a fechar para baixo. 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. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

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). Nas saídas de exemplo abaixo, o estado do modem é quietude, indicada pelo estado do modem que o evento carimbou 00:00:28. Refira a tabela dos estados de modem de MICA para mais informações sobre dos estados de modem de MICA possíveis.

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 é terminada, o NAS relata dois motivos de desconexão: as razões DTE (IO) e as razões DCE (MICA). Esses motivos de desconexão podem ser reportados por meio de três métodos principais:

  1. Registros de Chamada de Modem: Estes relatam o software e razões de desconexão de modem de MICA do ½ do ¿  IOSïÂ.

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

  3. Comandos IOS: Os comandos tais como o modem operational-status da mostra e o log de modem da mostra relatam somente a razão de desconexão de modem de MICA.

Registros de chamada de modem

Os IO e a razão da disconexão do modem para uma conexão particular são indicados no registro de chamada de 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 registro de chamada de modem da amostra mostrado abaixo, o motivo de desconexão IOS indicado pelo disc(radius) é portador perdido/portador perdido, quando a razão da disconexão do modem indicada pelo disc(modem) for:

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

Refira as razões da disconexão do modem de mica da tabela para obter mais informações sobre de interpretar a razão da disconexã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. Na pergunta da amostra AAA sql abaixo, nós podemos ver a causa da desconexão 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

O código da disconexão (disc-cause=4), no exemplo acima, indica que a disconexão esteve causada pela expiração do intervalo inativo.

Nota: Os registros de contabilização AAA não exibem a razão de desconexão do MICA, por isso a tabela fornecida neste documento não pode ser utilizada para interpretar a razão de desconexão do 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. Veja os motivos de desconexão abaixo para explicações nos tipos diferentes 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.

A /porta do Slot do Log do modem da mostra igualmente indica o motivo de 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 alto ordem indica geralmente o tipo de motivo de desconexão ou do tempo 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 de desconexão quando 0xD e 0x8 indicarem quando o motivo de 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 mais informações sobre das operações do modem MICA, veja a documentação de verificação do desempenho do modem e das operações de gerenciamento do modem nos Casos Práticos do Cisco AS5x00 para serviços de modem básicos IP.

Estados de modem MICA

Estado Descrição
QUIETUDE (#0) Neste estado, a sessão de modem é atualmente inativa. 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.
CONECTE (#10) O estado da CONEXÃO é incorporado CALL_SETUP(#5) do estado somente em cima de receber o comando host iniciar. No modo de resposta, a sessão de modem iniciou a atividade, mas não começou ainda a produzir um tom de replicação. Em origine o modo, a sessão de modem iniciou a atividade, mas não detectou ainda um tom de replicação.
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 (#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).
TRAINUP (#20) Neste estado, a sessão de modem negocia o padrão de modulação física (como configurado) usado durante o link. O estado do trainup é entrado do estado do LINK somente em cima:
  • Detecção do final de um Tom de Replicação (originar).
  • Concluindo a transmissão de um Tom de replicação (resposta).
EC_NEGOTIATING (#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 os ajustes forem agradávens a ambo o Modems (a interseção das duas potencialidades de modems e configurações), uma negociação bem-sucedida está alcançada. Se a interseção for nula, o modem será desconectado ou iniciará uma sessão conectada sem erros. O estado EC_NEGOTIATING é incorporado do estado do trainup em cima com sucesso de terminar a sincronização física da modulação.
STEADY_STATE (#30) Neste estado, a sessão de modem pode passar 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.
  • No fax - modo; este estado significa que o motor T30 está sendo executado. Durante uma chamada de fax, há um pino de madeira entre o STEADY_STATE a STEADY_STATE_ESCAPE. Isto representa a chamada de fax que atravessa suas fases diferentes de uma sessão do fax (T30).
STEADY_STATE_RETRAINING (#35) Nesse estado, a sessão de modem está sendo reciclada. O estado STEADY_STATE_RETRAINING é incorporado 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) Neste estado, o modem é conectado ainda com o peer remoto, mas a relação do host está dentro no modo de comando. 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. Veja o estado STEADY_STATE (#30) para obter informações sobre de uma chamada de fax.
TERMINAR (#50) Neste estado, a sessão de modem tenta nivelar dados do usuário e claro-para baixo o processador do sinal digital (DSP). Em um Software_reset , não há fluxo ordenado e o DSP é RESET. O estado TERMINATE é inserido a partir de qualquer estado:
  • Em cima do LINK_TERMINATE ou do Software_reset do host.
  • Na perda do portador do DSP.
  • Na recepção de um comando ATH do DTE.
  • No recibo de um frame de correção de erros DISC/LD (disconexão) da linha.
  • Pela remoção de vários limiares internos (configuráveis).
NA POSSE (#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 On Hold está permitido (registro S62), o modem transmitirá a sequência do reconhecimento do Modem On Hold (MHack) para conceder o pedido e para transmitir o Answer Back Tone (ANSam) quando o silêncio ou o RT são detectados. 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 On Hold é desabilitado, o modem transmitirá o 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 do Modem On Hold, refira as especificações do ITU-T V.92leavingcisco.com .

Nota: MICA estado #55 anteriormente era o estado VOICE, que foi removido das versões do software de porta 2.9.1.0 e superiores.

V.8bis EXCHANGE(#71) Este estado é incorporado de CONECTA o estado somente em cima de detectar CRe (origine o modo) ou a iniciação de 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 de modem detectou a capacidade Pedido-para autoanswer (CRe). Isto indica que há um peer remoto.
RANGING(#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.
SHORT(#73) DE AGRUPAMENTO VARIAR CURTO é incorporado de QC (registro S63) em cima de ligar o modem Avaliação-digital do retardo de round trip (RTDEd)
HD TRAIN(#74) HD TRAIN (trainup semi-duplex) é introduzido de RANGING ou RANGING SHORT até o início do treinamento do filtro de adaptação. Isto aplica-se a V.22bis e levanta-se.
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 da disconexão é o hexadecimal 0xDF03, o 0xF03 identifica o motivo de desconexão quando 0xD indicar quando o motivo de desconexão ocorreu (motivo de desconexão: Tipos).

As razões de desconexão descritas abaixo não incluem o tipo de desconexão. Daqui, do motivo de desconexão você tem, descasca fora o leftmost encanta o dígito e compara os dígitos remanescente com as opções abaixo. A partir do exemplo acima, procure o 0xF03 na seção abaixo.

Nota: Neste documento, o modem de host é o modem MICA no servidor de acesso Cisco, enquanto o modem de cliente é o modem de dispositivo remoto (por exemplo, um modem PC de cliente).

Tipo de desconexão Código de motivo de 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 terminou abruptamente o atendimento por qualquer motivo - por exemplo, porque a camada 1 foi para baixo no período físico que contém o atendimento.
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. Este 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. Este 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, este código é suplementado pelo campo índice de informação de link de diagnóstico 119 (um campo de informação com XX bytes oito usado como uma ferramenta para debugar).
2 0x005 Erro de software mica. O código de erro por este motivo 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. Este 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 abortado. O comando AT dial foi abortado pelo comando any key abort. Por exemplo, o modem do host origina um atendimento. Durante o estabelecimento de conexão, antes do ESTADO STEADY, pressionar toda a chave causará o comando AT dial ser abortado.
3 0x008 A conexão de chamada demorou muito para ser concluída. Note que o temporizador S7 (espera para o portador após o seletor) expirado para esta disconexã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 erro toma uma quantidade estendida de tempo sobre um retreinamento ou devido aos erros de bit introduziu-a quando o modem do cliente tenta conectar em uma taxa agressiva (o receptor do modem do cliente tenta conectar em uma taxa que não pode sustentar). 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 restaurado (comando, interno ou espontâneo). O código de erro por este motivo 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 restaurará o DSP se as mensagens do correio do CP ao SP não estão sendo reconhecidas. O SP restaurar-se-á se obtém um erro de inconsistência interna.
4,6 0x00A Recibo de umas palavras código do progresso ilegal. Especifica o recibo de umas palavras código de subida quando faria com que o valor do C2 (tamanho da palavra de código atual) excedesse o N1 (tamanho da palavra de código máximo: é negociado) e válido para o V.44 e o V.42bis somente.
4,6 0x00B Recibo de umas palavras código ilegais de V.42bis. Especifica o recibo de umas palavras código, a qualquer hora, igual ao C1 (entrada de dicionário vazio seguinte) e é válido para V.42bis. (O recibo de umas palavras código = do C1 é ilegal em V.42bis, mas legal no V.44).
4,6 0x00C Passe recibo de um token ilegal (demasiado grande) no V.44 ou no V.42bis. Isto significa que V.42bis ou o tamanho da palavra de código V.44 recebido excederam 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 Recibo de um código de comando reservado V.44 ou de V.42bis. Especifica o recibo de um código de comando reservado e é válido para o V.44 e o V.42bis.
4,6 0x00E V.42bis ou o V.44 receberam as palavras código maiores do que a entrada de dicionário vazio seguinte. Recebimento de um caractere V.44 Illegal STEPUP. Isto indica o recibo de um código de controle ELEVADOR que faça com que o valor do C5 (tamanho ordinal) excedesse oito. Isto é válido para o V.44 somente.
4,6 0x00F Dicionário V.44 RX completamente. Especifica o recibo de umas palavras código que não sejam uma reinicialização de dicionário quando a nó-árvore RX está completa. Válido para o V.44 somente.
4,6 0x010 História V.44 RX completamente. Especifica o recibo de umas palavras código que não sejam uma reinicialização de dicionário quando a história RX está completa. Válido para o V.44 somente.
4,6 0x011 Tamanho de série ilegal V.44/V.42bis RX excedido. Especifica o recibo de umas palavras código que façam com que o tamanho de série negociado máximo seja excedido. É válido para V.44 e V.42bis.
4,6 0x012 Um erro de negociação V.44 ocorreu especifica um erro de negociação V.44 ocorreu. Para o V.44, este código é suplementado pelo campo índice de informação de link de diagnóstico 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 Um erro de compactação V.44 ocorreu especifica um erro de compactação V.44 ocorreu. Para o V.44, este código é suplementado pelo campo índice de informação de link de diagnóstico 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 DSP parou de ouvir a portadora MICA por um período maior do que o valor especificado no registro S10 (retardo de resposta após a perda de portadora). 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) é de fato, seria anormal considerar tal disconexã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). Este tipo de contagens de falha contra 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 Isto ocorre quando o signal processor (SP) se realiza na fase da detecção do Answer Back Tone (ABT) em que a falha de chamada ocorre.
3 0x102 Falha de chamada durante o trem do modem acima de devido à linha da modulação incompatível ou do mau. Este motivo de desconexão ocorre durante o atendimento setup(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. O limite do retreinamento é alcançado uma vez (o limite do retreinamento pode ser alterado usando o registro S40), MICA deixa cair o atendimento e relata este motivo de desconexão. Sob algumas circunstâncias (T1/E1 separado) este tipo de disconexão pode ser considerado uma disconexão de estado estacionário normal. alternativamente, este poderia simplesmente ser o resultado de uma desconexão suja devido aos erros de linha possíveis de que o MICA não pode recuperar. Daqui, este tipo de desconexão não conta para o CSR desde que o atendimento é estabelecido já. 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 que detecta o fim da resposta Tone(ABT). Falha de negociação ou ruído excessivo durante o treinamento V.34. O Modems do host responde e manda a V.8bis e a resposta 2100Hz modulada para trás tonifica (ABT) com reversões de fase, mas ruído excessivo do encontro durante a sequência de trainup. 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 A operação SS7/COT (teste de continuidade) terminou com sucesso este motivo de desconexão ocorre durante a configuração de chamada (0x6105). A operação SS7/COT (Teste de continuidade) foi concluída com êxito.
3 0x106 A operação SS7/COT (teste de continuidade) falhou: Tom de espera do intervalo T8/T24 sobre. 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 A operação SS7/COT (teste de continuidade) falhou: Tom de espera do intervalo T8/T24 fora. Esse motivo de desconexão ocorre durante a configuração da chamada (0x6107). A operação SS7/COT falhou porque o temporizador T8/T24 cronometrou para fora ao esperar o tom fora.
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.
  • Cleardown devido a à chamada feita.
  • Liberação devido a outro motivo.
4 0x109 Valor de timeout do Modem On Hold (MOH) alcançado.
O EC local condiciona (classe 2)
  0x2xx Condições locais EC
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. Este motivo de desconexão ocorre durante a configuração de 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 EC (compressão de erro) ou LAPM (Procedimento de Acesso de Link para Modens) ou MNP (protocolo de rede Microcom)), o MICA é incapaz de 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 xid frame recebido é incompatível com os ajustes 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 da disconexão V.42 foi enviado do modem do cliente ao modem de NAS.). O modem do cliente descartou o DTR e negociou de forma inteligente um protocolo simples.
3,4,5 0x221 Quadro recebido DM. O par está desligando possivelmente. 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. Este 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 frame desconhecido ou unimplemented PIAFS recebido. Isto inclui o FI (tipo de frame principal), e classe negocia-o, do sincronização ou do controle (secundário-tipo).
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. Note que os quadros contínuos e do usuário são unimplemented, e que não há nenhum quadro conhecido da notificação.
3,4 0x233 A negociação de comunicação PIAFS falhou. Após a sincronização inicial, os quadros do req do parâmetro de comunicação/Ack são trocados. Um ou outro os parâmetros eram inaceitáveis, ou o iniciador detectou uma resposta NAK (Negative Acknowledgment).

Nota: MICA pode apenas operar como um cliente/iniciador para fins de teste

3,4 0x234 Negociação de ARQ de PIAFS falhada. Após o resynchronization, os quadros do pedido ARQ (req) /Acknowledgment (Ack) são trocados. Um ou outro os parâmetros eram inaceitáveis, ou o iniciador detectou uma resposta Nak.

Nota: MICA pode apenas operar como um cliente/iniciador para fins de teste

3,4 0x235 Problemas do protocolo transfer do controle de PIAFS detectados. O iniciador recebeu um Acn/Nak/Rsp cujo ID, Classe e Seqüência não correspondem ao Req/Ntf original.

Nota: O MICA pode somente operar-se como um cliente ou um iniciador para propósitos testando

3,4 0x236 Esta razão da desconexão já não indica o recibo de um quadro do pedido 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. Este temporizador começa-o quando um frame de recepção síncrona é enviado, lixa- para quando uma sincronização-recepção (caso da colisão) ou um frame de controle é detectado. Este erro ocorrerá somente quando a porta de MICA se está operando como um server (modo de resposta), que seja 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 da espera da confirmação do frame 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: o indicador negociado dos dados é menos do que o valor RTF (retardo de round trip). Esse erro não é mais publicado pela Portware e não será mais visto.
3,4 0x23E PIAFS: o campo do comprimento de dados da mensagem é demasiado 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: negociação de protocolo falhada. Nenhum protocolo (por exemplo, velocidade fixa do protocolo de transferência de dados, de velocidade variável DTP Type1) era aceitável a 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 alimentador de evento. 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 mica não viu a resposta da mudança da velocidade dentro de 200 milissegundos.
3,4 0x245 O CP da mica viu a informação de controle incompatível 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).
Comando protocol ruim recebido MNP ou LAPM do sócio (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 MNP LD ou o quadro do LAP-M Frame Reject (FRMR) são enviados na 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 da razão está nos últimos dois 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 frame LR dos relatórios de peer tem o parâmetro ruim #1. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro recebido LD indica que o modem do cliente recebeu um frame de solicitação de link do modem do host que conteve (isto é, inesperado) um PARAM1 ruim. Para obter mais informações sobre PARAM1, consulte a especificação V.42.
3 0x503 MNP: o frame LR dos relatórios de peer é incompatível com sua configuração. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro recebido LD indica que o modem do cliente recebeu um frame LR do modem do host que é incompatível com o modem do cliente, configuração s.
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 dos relatórios de peer expirou. O modem do host recebeu uma estrutura de LD do modem do cliente. O quadro recebido LD indica que o modem do cliente? hasn do host s (DTE)? t passou dados ao modem do cliente dentro de um período de tempo.
3 0x506 MNP: erro dos relatórios 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 recebido LD indica uma terminação de MNP normal, indicando que o DTR do modem do cliente deixou cair ou que recebeu um +++ ou um comando ATH. Este motivo de desconexão ocorre na configuração de chamada e no modo 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.
O sócio PIAFS indica a disconexão ou o erro de protocolo de 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 - Liberação normal. 1 - Liberação normal, continuação do link de dados proibida. 2 – Versão normal, continuação do enlace de dados. … Outras classes do Normal - classes indefinidas peculiares a alguns dispositivos do cliente.
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 não possíveis do uso de recurso - classes indefinidas peculiares a alguns dispositivos do cliente.
3,4 0x63x Preste serviços de manutenção à classe não possível da utilização para PIAFS DLR (parâmetros ruins). 9 - Peça a configuração de parâmetro não possível. A - Peça a configuração de parâmetro não possível presentemente. Outras classes muito difíceis para utilização de serviço - classes indefinidas peculiares a alguns dispositivos de cliente.
3,4 0x64x Preste serviços de manutenção à classe não ainda fornecida para PIAFS DLR. 1 – Indicação de parâmetro ainda não fornecida. … Classes não ainda fornecidas do outro serviço - classes indefinidas peculiares a alguns dispositivos do cliente.
3,4 0x65x Classe de conteúdo de informações inválidas para PIAFS DLR. 8 - Atributo terminal não correspondido. … O outro índice de informação inválida classifica - as classes indefinidas peculiares a alguns dispositivos do cliente.
3,4 0x66x Classe de erro de sequência para o DLR 0 PIAFS - 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 do cliente.
3,4 0x67x Outra classe de pecualiaridades de PIAFS DLR. 1 - Durante a chamada de voz. … Outras outras classes indefinidas peculiares das classes peculiares a alguns dispositivos do cliente.
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 deixado cair. 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 (HANGUP) foi detectado pelo host local.
3 0x1f05 Sem acesso à rede Telco. A desconexão ocorreu porque o host não poderia alcançar 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. Também, se o cliente devia abruptamente desconectar a linha telefônica/desliga o modem, a seguir este 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. Assim a desconexão indicada de rede é, neste caso, provavelmente indicativa de um modem do cliente infeliz, um que decidiu que poderia já não sustentar o portador por qualquer 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 Espontâneo. TERMINAÇÃO. 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 de desconexão: tipos descreve quando realmente ocorreu a desconexão da chamada. Podem ser categorizados em dois tipos principais: durante a configuração de chamada e durante o modo de dados (estado steady). 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. Dados RX (linha a hospedar) que nivelam ESTÁ BEM. A condição desconectada ocorreu no modo de dados. O MICA tenta fornecer qualquer dado recebido ao host (IOS). Para algumas disconexões (por exemplo, PIAFS), este é o único tipo do modo de dados usado; nenhuma indicação é feita do sentido de nivelamento dos dados.
5 0xA… No modo de dados. Dados RX (linha a hospedar) que nivelam NÃO ESTÁ BEM. 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. Dados TX (host a alinhar) que nivelam ESTÁ BEM. 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. Dados TX (host a alinhar) que nivelam NÃO ESTÁ BEM. 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


Document ID: 5135