Voz : CAS digital

Supervisión para responder y desconectar en los troncos digitales T1

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


Contenido


Introducción

Hay a menudo una cierta confusión sobre los términos “Supervisión de respuesta” y “Desconectar la supervisión” en los sistemas de telefonía. Este documento describe el significado de estos términos y cómo se aplican a los routers con interfaces de voz.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

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

Fundamentos de supervisión de respuestas y desconexiones

Técnicas básicas de señalización de E&M CAS

Para los trunks digitales del Señalización asociada al canal (CAS) T1 que ejecutan el ear and mouth (señalización E&M), hay generalmente solamente dos estados en los cuales un canal de voz puede estar. Cuando no hay llamada en un canal, el canal está en la marcha lenta, o el estado colgado. Cuando hay una llamada activa en un canal, después el canal está en haber agarrado, o el estado de descolgado. Esta tabla muestra los modelos estándar del bit de señalización ABCD de la transmisión/recepción para la marcha lenta y los estados agarrados:

Dirección: Estado A B C D
Transmitir Idle/On-Hook 0 0 0 0
Transmitir Agarrado/descolgado 1 1 1 1
‘Recibir’ Idle/On-Hook 0 0 0 0
‘Recibir’ Agarrado/descolgado 1 1 1 1

Luego de que se toma un canal inicialmente, cada dispositivo debe indicar el progreso de la llamada. Los indicadores de progreso incluyen si una llamada es respondida o si permanece sin responder, y cuando se responde, se determina qué parte se desconecta primero. Estos estados del progreso de la llamada son importantes debido a que los sistemas de telefonía necesitan saber cuándo se realizó, se contestó y se terminó la llamada. De ahí proviene el término Supervisión de desconexión y respuesta.

Por qué se requiere una respuesta y la supervisión de la desconexión

La razón más obvia de la supervisión para responder y desconectar está para cargar en cuenta — el intercambio telefónico y la cliente necesita una indicación precisa de las llamadas a través de una red. Es normal que las compañías de teléfonos no cobren llamadas sin respuesta o fallidas. Todos los registros de detalles de la llamada (CDR) presentados deben indicar que una llamada era por contestar o fracasada, y por lo tanto, no incurra en ninguna carga del sistema de facturación.

En segundo lugar, algunos sistemas pueden no cortar a través el trayecto de audio hasta que haya una indicación positiva que la Parte llamada contestó a la llamada — puede no haber una conexión de audio hasta que se envíe la señal de respuesta.

Pasado, el canal debe llegar a ser libre de tomar las nuevas llamadas cuando la llamada anterior borra. Si no hubiera indicación de la desconexión de la llamada, todos los canales en tronco de T1 serían bloqueados eventual.

Ejemplo de supervisión de desconexión y respuesta

Este ejemplo ilustra cómo la supervisión para responder y desconectar trabaja y cómo los debugs IOS se pueden utilizar para ganar la visibilidad en este proceso.

Señalización del inicio de Wink

Este ejemplo muestra la Señalización de inicialización de Wink E&M. Este diagrama ilustra las diversas condiciones del progreso de la llamada.

ansdscnt-sprvsn-1.gif

La inicialización de wink se usa para notificar al lado remoto que puede enviar el Dialed Number Identification Service (DNIS), también llamado como Called number.

Para una llamada entrante (red al router), esto ocurre:

  1. La red va descolgado. ABCD bits = 1111.

  2. El router envía un guiño. Transición de bits ABCD de 0000 a 1111 por 200 ms, y luego de nuevo a 0000.

  3. La red ve el parpadeo y luego procede a enviar la información DNIS (número llamado). Se hace esto cuando se envían los tonos de múltiples frecuencias de múltiples frecuencias/del tono dual inband (MF/DTMF), que son decodificados por el DSPs.

  4. El router pasa al estado descolgado cuando se responde la llamada. ABCD bits = 1111.

  5. El trayecto de audio está abierto, las partes pueden conversar, y el sistema de facturación registra un inicio de llamada.

En una llamada saliente (router a red) ocurre el mismo procedimiento, pero la red y el router cambian de roles. La razón es que la señalización es simétrica.

Éstos ocurren cuando sucede una desconexión de la red al router:

  1. La red se activa. ABCD bits = 0000.

  2. El router ve que va la red ir en-gancho y el router en-gancho. ABCD bits = 0000.

  3. El trayecto de audio está cerrado y el sistema de facturación registra una detención de llamada.

Para una desconexión del router a la red, se invierten estos pasos.

Es posible observar la supervisión para responder y desconectar si usted ejecuta los debugs de señalización apropiados en los routeres de gateway de voz.

Depuración de señalización de inicialización de Wink

Estas trazas son de un Cisco AS5300 que muestra las llamadas de la red al router y al router a la red. El router AS5300 funcionó con el comando debug cas de proporcionar los seguimientos en tiempo real del estatus del bit de señalización de CAS.

debug cas: Llamadas desde la red al router
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)

El siguiente seguimiento muestra una llamada del router a la red.

debug cas - Llamadas desde el router a la red
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 se puede ver en estos rastros de depuración, es posible determinar la dirección de la llamada y si la llamada fue respondida. Estos debugs ayudan le para resolver los desacuerdos sobre la fuente y la razón de las desconexiones de la llamada, así como a los registros de facturación disputados.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 23683