Análisis detallado del tono de llamada para todos los protocolos VoIP y analógicos

Introducción

El propósito de este documento es proporcionar una explicación detallada de los tonos de repliegue de audio a los que normalmente se hace referencia como tonos de progreso de llamada o tonos de CP para abreviar.

Este documento intentará discutir y proporcionar un análisis de cómo funciona la recepción de llamada dentro de todos los protocolos de señalización analógica y voz sobre IP (VoIP).

Prerequisites

Requirements

Si bien no es necesario un requisito formal para leer este documento; se escribió con la esperanza de que el lector ya tenga algún conocimiento práctico de los protocolos de señalización de voz subyacentes que se utilizan para establecer y conectar llamadas telefónicas. A lo largo de este documento se hace referencia a estos protocolos muchas veces.

Protocolos de señalización: Protocolo de inicio de sesión (SIP), H323 (h225 / h245), Protocolo de control de gateway de medios (MGCP), Protocolo de control de cliente ligero (SCCP), ISDN Q931, E1 R2.

Protocolos de medios: protocolo en tiempo real (RTP), códecs de voz y códecs de vídeo.

Tecnologías analógicas: Oreja y Boca (E&M), Suscriptor de Intercambio Externo (FXS), Oficina de Intercambio Externo (FXO) y E1 R2.

Componentes Utilizados

La información de este documento se basa en estos programas y hardware:

Gateways Cisco IOS y IOS-XE (2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / ASR100X) que ejecutan cualquier versión de IOS/IOS-XE.

Cisco Unified Communications Manager (CUCM) versiones 9.X y posteriores

Cisco Unity Connection (CUC) versiones 9.x y posteriores

Customer Voice Portal (CVP) versión 9.x y posterior

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si su red está activa, asegúrese de comprender el impacto potencial de cualquier comando o configuración.

Antecedentes

Rinback no es un protocolo VoIP o analógico, pero está presente en todas las llamadas telefónicas realizadas por teléfonos móviles, líneas fijas, teléfonos de escritorio y clientes de software. Por lo tanto, entender cómo funciona, de dónde procede y cómo resolver problemas de recepción de llamada es una parte importante de una estrategia de herramientas de Ingenieros de colaboración.

El tono de llamada es una secuencia de tonos que se reproduce en la persona que realiza una llamada telefónica y que permite al autor de la llamada saber que la persona a la que se llama está sonando. La ausencia de tono de llamada se debe considerar un signo negativo, ya que el autor de la llamada supondría que la persona a la que se llama no está sonando. Los tonos de recepción de llamada/CP varían según el país. Si una persona a la que llamar a un número de Estados Unidos, se reproduciría un conjunto diferente de timbre que si esa misma persona llamara a un número del Reino Unido.

En la mayoría de los escenarios, la parte llamada remota de la parte que llama reproducirá la llamada. Para que esto ocurra, se debe cortar el audio en la dirección hacia atrás (Llamado a llamada).

Protocolos

Este documento examina los diferentes protocolos y cómo negocian la recepción de llamada, así como cómo manipular la devolución de llamada cuando se usa ese protocolo.

ISDN Q.931 (T1 / E1 / BRI)

ISDN Q.931 utilizó el concepto de indicadores de progreso (PI) que se puede ver en la señalización Q.931. Esto se puede ver en los gateways de voz de Cisco ejecutando debug isdn q931. Los indicadores de progreso se pueden enviar en los mensajes Alerta, Progreso, Procedimientos de llamada, Configuración Ack y Desconexión. Un valor del indicador de progreso de 1 u 8 recortará el audio hacia atrás para la recepción de llamada y los mensajes de error. Los valores de los indicadores de progreso 0, 2 y 3 no recortarán los medios hacia atrás. Un DSP asignado al canal ISDN puede reproducir el tono de llamada a la línea ISDN si la parte llamada remota no puede hacerlo.

Advertencias conocidas con ISDN Ringback

• Las llamadas de SIP a ISDN requieren oferta anticipada de modo que cuando la puerta de enlace recibe ISDN con una PI válida para abrir medios hacia atrás, tenga la IP del teléfono CUCM/IP hacia la que enviar medios.

Indicadores de progreso Q931

Valor	Definición	Mensaje Q.931
Indicador de progreso = 0	fuera de banda	Configuración
Indicador de progreso = 1	La llamada no es ISDN de extremo a extremo. Puede haber más información de progreso de llamada dentro de banda	Alerta, conexión, progreso, configuración
Indicador de progreso = 2	La dirección de destino no es ISDN.	Alerta, conexión, progreso
Indicador de progreso = 3	La dirección de destino no es ISDN.	Configuración
Indicador de progreso = 8	Ya está disponible información en banda o un patrón apropiado.	Alerta, conexión, progreso, desconexión

Ejemplos de Indicadores de Progreso en Banda ISDN Q.931

Jun 22 15:16:36.790: ISDN Se0/2/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x80A3
        Progress Ind i = 0x8188 - In-band info or appropriate now available

Nov 28 21:25:41.754: ISDN Se0/1/1:15 Q931: TX -> PROGRESS pd = 8  callref = 0x805C 
	Progress Ind i = 0x8188 - In-band info or appropriate now available 

  

Configuración

La recepción de llamada ISDN funciona de forma fiable de forma predeterminada, por lo que no se requiere ninguna configuración adicional. Sin embargo, existen comandos para cambiar el comportamiento en caso de un requisito de interoperabilidad.

Cambio manual del valor progress_ind.

Notas Importantes:

• Esta opción está desactivada de forma predeterminada
• Esto sólo se puede aplicar a los pares de marcado salientes
• Esto PUEDE aplicarse a los pares de marcado VOIP y POTS.

Sintaxis de comando completo:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-p2.html#wp1001337490

!
progress_ind { alert | callproc } { enable pi-number | disable | strip [strip-pi-number] }
progress_ind { connect | disconnect | progress | setup } { enable pi-number | disable }

!
dial-peer voice 1 pots
 destination-pattern 8675309$
 progress_ind alert enable 8
 progress_ind callproc enable 8
 progress_ind connect enable 8
 progress_ind disconnect enable 8
 progress_ind progress enable 8
 progress_ind progress setup 1
!
dial-peer voice 2 pots
 destination-pattern 8675309$
 progress_ind alert strip 8
 progress_ind callproc strip 8
!
dial-peer voice 3 pots
 destination-pattern 8675309$
 progress_ind alert disable
 progress_ind callproc disable
 progress_ind connect disable
 progress_ind disconnect disable
 progress_ind progress disable
 progress_ind progress disable
!

Requerir que una puerta de enlace de voz siempre envíe mensajes de alerta

Si un administrador necesita que un gateway de voz envíe siempre un mensaje de alerta antes de conectar, el comando isdn send-alerting se puede configurar en una interfaz serial. Esta opción está desactivada de forma predeterminada

Sintaxis de comando completo: http://www.cisco.com/c/en/us/td/docs/ios/dial/command/reference/dia-cr-book/dia_i2.html

!
interface Serial0/0/0:23
 isdn send-alerting
!

Depuraciones

debug isdn q931
debug voip ccapi inout

H.323

H.323 y más específicamente el protocolo de señalización H.225 VOIP se construyó sobre el protocolo Q.931 de ISDN. Como resultado, comparten muchos elementos comunes. Muchos de los comandos presentes y las ideas detrás de Q.931 ringback están presentes en H.323/H.225. Esto incluye los valores del indicador de progreso, los tipos de mensaje y los comandos.

Ejemplo de mensaje H.225 para recepción

*Jun 22 11:32:52.080: H225.0 INCOMING PDU ::=

value H323_UserInformation ::= 
    {
      h323-uu-pdu 
      {
        h323-message-body alerting : 

Configuración

H.323 y H.225 no requieren configuración para la devolución de llamada fuera de la caja. Sin embargo, los comandos especificados en la sección ISDN Q.931 también son aplicables al Retorno H.323. Además, hay comandos disponibles para la señalización H.323.

Comando	Definición
voice call send-alert	Configurado en la configuración global. Este comando está inhabilitado de forma predeterminada. Este comando habilita el gateway de terminación para enviar un mensaje de alerta en lugar de un mensaje de progreso después de que reciba una configuración de llamada. Este comando puede emplearlo cuando "Voice Call Send Alert=FALSE" está en las depuraciones de CCAPI para hacer el valor TRUE. Además, esto se puede utilizar para ISDN a SIP donde se recibió 183 w/SDP pero el dispositivo de extremo lejano no estaba reproduciendo el retorno de llamada. Cambia el TX Progress a TX Alerting con la misma información de PI. PSTN luego reprodujo el retroceso.
voice rtp send-recv	Abre el canal de audio RTP en ambas direcciones.
! dial-peer voice 1 voip tone ringback alert-no-pi ! dial-peer voice 2 pots tone ringback alert-no-pi !	Este comando hace que el gateway genere una señal de llamada hacia la parte que llama si se recibe una alerta en el tramo de llamada IP sin presencia de PI. Se diferencia del comando progress_ind setup en que el mensaje de configuración H.225 saliente no contiene un valor de PI igual a 3 con el comando tone ringback. Es posible que algunos dispositivos no acepten mensajes de configuración si incluyen un valor de PI.

Configuraciones de CUCM

Existen algunas configuraciones específicas de H.323 para la recepción de llamada dentro de CUCM>

Navigation Path: CUCM > System > Service Parameters > Pub > CallManager > Send H225 User Info Message > Use ANN For Ringback

Valor	Definición
Utilizar ANN para devolución de llamada	Utilice Cisco SCCP Annunciator para reproducir el tono de recepción de llamada (disponible en Cisco CallManager versión 4.0 y posteriores)
Información de usuario para el tono de progreso de llamada	Enviar el mensaje de información del usuario H.225 al gateway IOS para reproducir el tono de recepción de llamada o el tono en espera (este es el valor predeterminado).
H225 Info for Call Progress Tone (Información de H225 para el tono de progreso de la llamada)	Enviar el mensaje de información H.225 al gateway IOS para reproducir el tono de recepción de llamada o el tono en espera

Depuraciones

debug voip ccapi inout
debug h225 asn1

Este también es un documento excelente sobre la resolución de problemas del retorno de llamada H.323

http://www.cisco.com/c/en/us/support/docs/voice/h323/22983-ringback.html

SIP

La recepción de llamada SIP normalmente implica uno de dos mensajes. 180 y 183. RFC 3261 establece que 0, 1 o más de estos mensajes 1XX pueden ser recibidos después de una INVITE, por lo tanto no es contrario a RFC no recibir uno de estos mensajes. Si no se recibe ninguna, no habrá recepción de llamada. Por lo tanto, si una persona que llama espera una devolución de llamada de alguna forma, se requiere un 180 o 183.

Tanto un 180 como un 183 pueden contener el protocolo de descripción de sesión (SDP) que CUBE tratará como medios iniciales. Cuando SDP está presente en un mensaje 18X CUBE y CUCM esperará que el dispositivo de extremo lejano que envía el 18X con SDP reproduzca el timbre desde la IP especificada en el SDP. No hay ninguna configuración para cambiar este comportamiento en CUCM o CUBE. Algunos dispositivos requieren un intercambio PRACK (rel1xx) en el mensaje 18X antes de enviar el timbre.

RFC3960 profundiza en detalles adicionales sobre la señalización de recepción de llamada con SIP.

Es importante tener en cuenta que para SIP a ISDN y SIP a H.323 llama a un 18X con mapas SDP a un Indicador de progreso en banda mientras que un 18X sin SDP mapea a una Alerta.

Ejemplo 183 con SDP

SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK6350828126b1a
From: <sip:8675309@10.10.10.10>;tag=85512413~796a13c3-49d2-74ec-19db-f4258d9eef64-40934478
To: <sip:123456789@10.10.10.1>;tag=BA0FA04C-97B
Date: Wed, 22 Jun 2016 11:32:51 GMT
Call-ID: 575b0c00-76a177e1-57ea4-2009000a
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:8675309@10.10.10.10>;party=called;screen=no;privacy=off
Contact: <sip:8675309@10.10.10.10:5060;transport=tcp>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M2
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 9474 3602 IN IP4 172.16.37.129
s=SIP Call
c=IN IP4 10.10.10.10
t=0 0
m=audio 17606 RTP/AVP 8 101
c=IN IP4 10.10.10.10
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Muestra 180 sin SDP

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bKd34f2a2080
From: <sip:2002@10.10.10.10>;tag=17170~21823a7a-6ec3-4a2f-9307-df98bca4b011-23314477
To: <sip:3001@10.10.10.1> ;tag=1ADFB1AC-3CB
Date: Tue, 26 Jan 2016 22:05:06 GMT
Call-ID: d859d700-6a71ed8f-26-a21030e
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: < sip:3001@10.10.10.10> ;party=called;screen=yes;privacy=off
Contact: < sip:3001@10.10.10.10:5060;transport=tcp>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

Configuración

Comando	Definición
! sip-ua disable-Early-Media 180 !	Se utiliza para especificar el tratamiento de llamadas, los medios iniciales o el retorno de llamada local, que se proporciona para 180 respuestas con 180 respuestas con protocolo de descripción de sesión (SDP)
! voice service voip  sip   bloque {180 | 181 | 183} sdp {presente | ausente} !	Bloquea mensajes específicos pertenecientes a la devolución de llamada

Perfil SIP para cambiar una sesión 183 en curso a un timbre 180.

!
voice service voip
 sip
  sip-profiles inbound
!
voice class sip-profiles 777
 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" "SIP/2.0 180 Ringing"
!
dial-peer voice 777 voip
 voice-class sip profile 777 inbound
!

Habilitación de PRACK (rel1xx) en CUCM.

• PRACK está desactivado de forma predeterminada en los perfiles SIP de CUCM

Ruta del menú del sistema: Device > Device Settings > Sip Profile > Choose a SIP profile > SIP Rel1XX

Opciones 

• Desactivado (predeterminado)
• Enviar PRACK si 1xx contiene SDP
• Enviar PRACK para todos los mensajes 1xx

Habilitación de PRACK (rel1xx) en Gateawys

• De forma predeterminada, rel1xx está habilitado en los gateways de voz. Si un CUBE recibe un requisito: Encabezado de 100 barriles que PRACK

Depuraciones

debug voip ccapi inout
debug ccsip messages

  

MGCP (Protocolo de control de gateway de medios)

MGCP es el lado VOIP que controla los puertos FXS e ISDN T1 / E1. Puede verificar si CUCM está enviando la señalización de recepción de llamada adecuada al puerto específico pero no hay mucha configuración que se pueda hacer.

Ejemplo de mensaje MGCP Ringback de CUCM a un puerto FXS VG224

Apr 29 01:01:38.264: MGCP Packet received from 14.50.244.2:2427--->
RQNT 37 AALN/S2/1@vg224 MGCP 0.1
X: 1b
R: L/hu
S: G/rt
Q: process,loop
<---

S: = Eventos señalizados y g/rt = Paquete genérico / Tono de recepción de llamada

Configuración de CUCM

Ruta del menú del sistema: System > Service Parameters > Pub > CallManager > Disable Alerting Progress Indicator

• Este parámetro determina si el indicador de progreso de la alerta a la información dentro de banda se informa a los gateways PRI digitales.
• Los valores válidos especifican True (desactivar el indicador de progreso de las alertas) o False (enviar el indicador de progreso de las alertas).
• Para recibir el timbre en ciertas configuraciones, es posible que tenga que establecer este campo en False para forzar el corte de medios.

Configuración de gateway

• Ninguno

Depuraciones

debug mgcp packet
debug voip ccapi nout
debug vpm signal 
debug voip vtsp session

SCCP

En el caso de los teléfonos IP SCCP registrados en CUCM o CME, se envía un "mensaje de tono de inicio" al teléfono IP que indica al teléfono local que reproduzca el timbre a la persona que realiza la llamada.

Analógico (FXS / FXO / E&M / E1 R2)

Depuraciones de recepción de llamada para todos los puertos de voz analógicos:

debug voip ccapi inout
debug vpm signal
debug voip vtsp session

  

Puertos de voz

• El DSP local se encargará de proporcionar la devolución de llamada para el puerto de voz.
• Un CPtone personalizado se puede configurar en el puerto de voz elegido.

GATEWAY(config)#voice-port 0/2/0
GATEWAY(config-voiceport)#cptone ?
  locale   2 letter ISO-3166 country code

AR Argentina            IN India                PA Panama
AU Australia            ID Indonesia            PE Peru
AT Austria              IE Ireland              PH Philippines
BE Belgium              IL Israel               PL Poland
BR Brazil               IT Italy                PT Portugal
CA Canada               JP Japan                RU Russian Federation
CL Chile                JO Jordan               SA Saudi Arabia
CN China                KE Kenya                SG Singapore
CO Colombia             KR Korea Republic       SK Slovakia
C1 Custom1              KW Kuwait               SI Slovenia
C2 Custom2              LB Lebanon              ZA South Africa
CY Cyprus               LU Luxembourg           ES Spain
CZ Czech Republic       MY Malaysia             SE Sweden
DK Denmark              MT Malta                CH Switzerland
EG Egypt                MX Mexico               TW Taiwan
FI Finland              NP Nepal                TH Thailand
FR France               NL Netherlands          TR Turkey
DE Germany              NZ New Zealand          AE United Arab Emirates
GH Ghana                NG Nigeria              GB United Kingdom
GR Greece               NO Norway               US United States
HK Hong Kong            OM Oman                 VE Venezuela
HU Hungary              PK Pakistan             ZW Zimbabwe
IS Iceland

E1 R2

Salida de debug ccapi inout, debug vpm signal y debug voip vtsp session para llamadas E1 R2 que muestran el tono de llamada.

042446: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert:
   Interface=0x3ECE2770, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
042447: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)
042448: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert:
   Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
042449: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert:
   Call Entry(Responsed=TRUE, Alert Sent=TRUE)htsp_alert_notify
042450: May 12 14:51:15.816 GMT: r2_reg_event_proc(0/0/1:1(1)) ALERTING RECEIVED
042451: May 12 14:51:15.816 GMT: R2 Incoming Voice(0/1): DSX (E1 0/0/1:0): STATE: R2_IN_WAIT_REMOTE_ALERT R2 Got Event R2_ALERTING
042452: May 12 14:51:15.816 GMT: rx R2_ALERTING in r2_comp_wait_remote_alert
042453: May 12 14:51:15.816 GMT: r2_reg_generate_digits(0/0/1:1(1)): Tx digit '1'
042454: May 12 14:51:16.672 GMT: //2475487/47922BA59254/VTSP:(0/0/1:1):0:1:1/vtsp_report_cas_digit:
   End Digit=2, Mode=CC_TONE_R2_MF_BACKWARD_MODE
042455: May 12 14:51:16.672 GMT: htsp_digit_ready(0/0/1:1(1)): Rx digit='#'

Detalles específicos de la devolución de llamada de Cisco

Transferencias internas (líneas troncales SIP y CUC)

• Durante una transferencia interna a través de un tronco SIP o hacia/desde el anunciante CUCM de CUC será el que proporcione la recepción de llamada.

• Asegúrese de que se asigna un MRGL y un Anunciador al tronco y que se inicie el servicio IPVMS.

Agentes móviles de Contact Center

• Para que un agente escuche los tonos de progreso de la llamada para las llamadas iniciadas por el agente, se requiere una configuración adicional si MTP Required no está habilitado. Si, en su lugar, dispone de asignación dinámica de MTP al forzar una configuración DTMF no coincidente, Unified CM debe configurarse para activar la oferta anticipada.
• Cisco Annunciator no genera tonos de recepción de llamada ni de progreso de llamada, como ocurre con los teléfonos y softphones habituales. En su lugar, el agente móvil se basa en los tonos que genera el destinatario de la llamada (y la configuración de la oferta anticipada hace que estos tonos se envíen al agente).

Documentación:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_9_0_1/user/guide/UCCE_BK_UFAEED16_00_ucce-mobile-agent-guide/UCCE_BK_UFAEED16_00_ucce-mobile-agent-guide_chapter_010.html#UCCE_RF_E40E25C8_00

Contact Center Enterprise (UCCE) y VXML

CVP indicará al gateway VXML que reproduzca la recepción de llamada enviando una INVITE con un número específico.
Ejemplo: 9191
El SDP de esta INVITE estará donde queremos que el gateway VXML envíe la señal de llamada.

Esto coincidirá con un par de marcado configurado con un servicio de recepción de llamada configurado.

Troubleshoot

Retraso en recepción de llamada

El retraso en el corte de recepción de llamada suele deberse a un retraso en la señalización subyacente. Los debugs y los logs del dispositivo específico y los protocolos que se utilizan deberán ser consultados para averiguar por qué hay un retraso en la señalización.

Para la falla de señalización de la gateway de voz en los pares de marcado y la re-búsqueda del par de marcado puede causar un retraso considerable a medida que el dispositivo intenta encontrar un salto siguiente para la llamada. 

debug voip ccapi inout Analysis

Como puede ver en todo el documento, la recopilación de depuraciones ccapi es muy importante para CUALQUIER problema de recepción de llamada.

la función Api de control de llamadas (CCAPI) se encarga de conectar en puente dos lados de una llamada en una gateway de voz y, como resultado, de unir también el timbre de un tramo de llamada a otro.

Ejemplos de salida de depuración de CCAPI para recepción de llamada

Feb  2 21:27:18.884: //22/9285F23E801B/CCAPI/cc_api_call_alert:
   Interface=0x3AB79E8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)

Jun 23 13:32:34 EDT: //1204/77232A800001/CCAPI/cc_api_call_cut_progress:
   Interface=0x7FD5FD1CEE10, Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2),
   Cause Value=0

Jun 23 13:32:34 EDT: //1203/77232A800001/CCAPI/ccCallCutProgress:
   Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2), Cause Value=0
   Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)

Jun 22 11:32:52.096: //204706/575B0C000000/CCAPI/ccCallAlert:
   Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)

Nov 28 21:25:41.748: //43495/0C82F2F380B7/CCAPI/cc_api_call_cut_progress:
   Interface=0x7F8028B60F90, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1),
   Cause Value=0

Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccCallCutProgress:
   Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0
   Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)

Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccGenerateToneInfo:
   Stop Tone On Digit=FALSE, Tone=Null,
   Tone Direction=Network, Params=0x0, Call Id=43494

La señalización está bien, ¿pero no hay señal de llamada?

Dependiendo de su señalización, todo puede verse bien. Sin embargo, puede que todavía no haya recepción de llamada. Si la señal indica que una parte específica va a enviar una señal de llamada a su dispositivo, vale la pena capturar una captura de paquetes o una captura PCM del puerto de voz para verificar si la recepción de llamada se está reproduciendo o no.

También es importante verificar el ruteo de Capa 3 desde el origen y el destino. si no pueden enviar paquetes RTP a su dispositivo, no oirá audio. Además, si no puede enviar paquetes a un dispositivo específico, no oirán su recepción de llamada.

Comandos de ruteo útiles de capa 3

show ip route
show ip cef <remote_ip>
ping a.b.c.d source <interface>
traceroute a.b.c.d

Documentación de captura PCM:

http://www.cisco.com/c/en/us/support/docs/voice/h323/116078-technologies-technote-commandrefe.html