Voz : CAS Digital

Resposta e supervisão de desconexão nos troncos digitais T1

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


Índice


Introdução

Há frequentemente alguma confusão sobre os termos “supervisão de resposta” e “supervisão de desconexão” em sistemas de telefonia. Este documento descreve o que esses termos significam e como eles se aplicam aos roteadores com interfaces de voz.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

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

Fundamentos de supervisão de resposta e desconexão

Conceitos básicos de sinalização CAS E&M

Para os troncos digitais da sinalização associada a canal (CAS) T1 que executam o ear and mouth (sinalização E&M), há geralmente somente dois estados em que um canal de voz pode estar. Quando há nenhum chamar um canal, o canal está na quietude, ou no estado no gancho. Quando há uma chamada ativa em um canal, a seguir o canal está na apreendida, ou no estado fora do gancho. Esta tabela mostra os padrões de bit padrão da sinalização ABCD da transmissão/recepção para a quietude e os estados apreendidos:

Direção Estado A B C D
Transmit Idle/On-Hook 0 0 0 0
Transmit Apreendido/gancho 1 1 1 1
Recepção Idle/On-Hook 0 0 0 0
Recepção Apreendido/gancho 1 1 1 1

Após a captura inicial de um canal, cada dispositivo deve indicar o andamento de uma chamada. Os indicadores de progresso indicam se uma chamada está sendo atendida ou continua sem atendimento e, quando a chamada é atendida, qual parte é desconectada primeiro. Esses estados de andamento da chamada são importantes, pois os sistemas de telefonia precisam saber quando a chamada foi tentada, atendida e concluída; daí o termo Supervisão de atendimento e desconexão.

Por que a supervisão de resposta e desconexão é necessária

A razão a mais óbvia para a resposta e supervisão de desconexão é faturando — o intercâmbio telefônico e a necessidade de cliente uma indicação precisa dos atendimentos através de uma rede. É um padrão das empresas de telefone não cobrar por chamadas não respondidas ou sem êxito. Todos os registos dos destalhes da chamada (CDR) produzidos devem indicar que um atendimento era não respondido ou mal sucedido, e, não incorra consequentemente nenhuma carga do sistema de faturamento.

Em segundo lugar, alguns sistemas não podem cortar completamente o caminho de áudio até que haja uma indicação positiva que o número chamado respondeu ao atendimento — não pode haver uma conexão de áudio até que o sinal de resposta esteja enviado.

Ultimamente, o canal deve tornar-se livre tomar atendimentos novos quando o atendimento precedente cancela. Se não havia nenhuma indicação da disconexão do atendimento, todos os canais no tronco t1 seriam obstruídos eventualmente.

Exemplo de supervisão de resposta e desconexão

Este exemplo ilustra como a resposta e supervisão de desconexão trabalha e como os IO debugam podem ser usados para ganhar a visibilidade neste processo.

Sinalização de permissão de início

Este exemplo mostra a sinalização de permissão de início do E&M. Este diagrama ilustra as várias condições do andamento da chamada.

ansdscnt-sprvsn-1.gif

A permissão de início é usada para notificar o lado remoto de que ele pode enviar o Serviço de Identificação de Número Discado (DNIS), também referido como Número Chamado.

Para uma chamada recebida (rede ao roteador), isto ocorre:

  1. A rede vai fora-gancho. Bits ABCD = 1111.

  2. O roteador envia a permissão de início. Os bits ABCD passam de 0000 para 1111 para 200 ms e depois novamente para 0000.

  3. A rede vê a permissão e então continua a enviar informações DNIS (Numero Chamado). Isto está feito quando os tons multifrequency inband multifrequency/tom dual (MF/DTMF) são enviados, que estão descodificados pelos DSP.

  4. O roteador passa para o estado fora do gancho quando a chamada é atendida. Bits ABCD = 1111.

  5. O caminho do áudio é aberto, as partes podem conversar e o sistema de faturamento faz um registro de início de chamada.

Em uma chamada feita (roteador para rede), ocorre o mesmo procedimento, mas a rede e o roteador comutam os papéis. A razão é que a sinalização é simétrica.

Estes ocorrem quando uma disconexão da rede ao roteador acontece:

  1. A rede fica suspensa. ABCD bits = 0000.

  2. O roteador vê que a rede para ir em-gancho e o roteador vai em-gancho. ABCD bits = 0000.

  3. O caminho de áudio está fechado, e o sistema de faturamento registra uma interrupção de chamada.

Para uma disconexão do roteador à rede, estas etapas são invertidas.

É possível observar a resposta e supervisão de desconexão se você executa debug de sinalização apropriados em Roteador de Gateway de Voz.

Depuração de sinalização de permissão de início

Estes traços são de um Cisco AS5300 que mostra atendimentos da rede ao roteador e ao roteador à rede. O roteador AS5300 executou o comando debug cas fornecer rastreamentos em tempo reais do estado do bit de sinalização de CAS.

debug cas – Chamadas da rede para o roteador
multi-5-17#show debug
CAS: Channel Associated Signaling debugging is on


!--- Router receives initial seizure from network:
 
May 15 15:35:59.455: from Trunk(0):(0/2): Rx LOOP_CLOSURE (ABCD=1111)


!--- Router sends a 200 msec wink towards network:
 
May 15 15:35:59.679: from Trunk(0):(0/2): Tx LOOP_CLOSURE (ABCD=1111)
May 15 15:35:59.883: from Trunk(0):(0/2): Tx LOOP_OPEN (ABCD=0000)
		

!--- Router sends an answer signal to indicate that the called 
!--- party has answered the call: 

May 15 15:36:09.943: from Trunk(0):(0/2): Tx LOOP_CLOSURE (ABCD=1111)


!--- Router receives a disconnect from network requesting 
!--- to clear the call:
 
May 15 15:36:32.975: from Trunk(0):(0/2): Rx LOOP_OPEN (ABCD=0000)


!--- Router responds with a disconnect, call is cleared: 

May 15 15:36:33.295: from Trunk(0):(0/2): Tx LOOP_OPEN (ABCD=0000)

O próximo rastreio mostra uma chamada a partir do roteador para a rede.

debug cas - Chamadas do roteador para a rede
multi-5-17#show debug
CAS: Channel Associated Signaling debugging is on


!--- Router sends initial seizure to network: 

May 15 15:40:26.471: from Trunk(0):(0/5): Tx LOOP_CLOSURE (ABCD=1111)


!--- Router receives a 200 msec wink from network: 

May 15 15:40:26.679: from Trunk(0):(0/5): Rx LOOP_CLOSURE (ABCD=1111)
May 15 15:40:26.883: from Trunk(0):(0/5): Rx LOOP_OPEN (ABCD=0000)


!--- Router receives an answer signal indicating that a telephone 
!--- handset on the network has answered the call: 

May 15 15:40:36.495: from Trunk(0):(0/5): Rx LOOP_CLOSURE (ABCD=1111)


!--- Router sends a disconnect to clear the call:
 
May 15 15:40:57.631: from Trunk(0):(0/5): Tx LOOP_OPEN (ABCD=0000)


!--- Router receives disconnect response from network, 
!--- call is cleared:
 
May 15 15:40:58.163: from Trunk(0):(0/5): Rx LOOP_OPEN (ABCD=0000)

Como você pode ver nos rastros de depuração, é possível determinar a direção da chamada e se a chamada foi atendida. Estes debugam a ajuda que você resolve desacordos sobre a fonte e a razão para disconexões do atendimento, assim como registros de faturamento disputados.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 23683