Análise detalhada de chamada de volta para todos os protocolos VoIP e analógicos

Introduction

O objetivo deste documento é fornecer uma explicação detalhada dos tons de áudio rinback comumente referidos como tons de progresso de chamada ou tons de progresso de chamada para abreviação.

Este documento tentará discutir e fornecer uma análise de como o ringback funciona em qualquer protocolo de Voz sobre IP (VoIP) e de Sinalização Analógica.

Prerequisites

Requirements

Embora não haja um pré-requisito formal necessário para ler este documento; foi escrito na expectativa de que o leitor já tenha algum conhecimento funcional dos protocolos subjacentes de sinalização de voz usados para estabelecer e conectar chamadas telefônicas. Esses protocolos são referenciados várias vezes neste documento.

Protocolos de sinalização: Session Initiation Protocol (SIP), H323 (h225 / h245), Media Gateway Control Protocol (MGCP), Skinny Client Control Protocol (SCCP), ISDN Q931, E1 R2.

Protocolos de mídia: RTP (Real Time Protocol, protocolo em tempo real), codecs de voz, codecs de vídeo.

Tecnologias analógicas: Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS), Foreign Exchange Office (FXO) e E1 R2.

Componentes Utilizados

As informações neste documento são baseadas nestes softwares e hardwares:

Gateways Cisco IOS e IOS-XE (2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / ASR100X) executando qualquer versão do IOS/IOS-XE.

Cisco Unified Communications Manager (CUCM) versões 9.X e superiores

Cisco Unity Connection (CUC) versões 9.x e superiores

Customer Voice Portal (CVP) versão 9.x e superior

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. Se a sua rede estiver ativa, certifique-se de que você entende o impacto potencial de qualquer comando ou configuração.

Informações de Apoio

O Rinback não é um protocolo VoIP ou analógico, mas está presente em todas as chamadas telefônicas feitas por telefones celulares, linhas terrestres, telefones fixos e clientes de software. Assim, entender como ele funciona, de onde vem e como solucionar problemas de chamada de volta é uma parte importante de uma ferramenta de Engenheiros de Colaboração.

O toque de retorno é uma sequência de tons tocados para a pessoa que está fazendo uma chamada telefônica que permite ao chamador saber que a parte chamada está realmente tocando. A ausência de toque deve ser considerada um sinal ruim, pois o chamador presumiria que a parte chamada não está tocando. Toques de chamada / tons variam de país para país. Se uma pessoa chamasse um número dos Estados Unidos, ela seria tocada com um toque diferente do que se essa mesma pessoa chamasse um número do Reino Unido.

Na maioria dos cenários, o toque de retorno é reproduzido pelo chamador remoto para o chamador. Para que isso ocorra, o áudio deve ser cortado na direção inversa (chamada para chamada).

Protocolos

Este documento examina os diferentes protocolos e como eles negociam o ringback, bem como como como manipular o ringback ao usar esse protocolo.

ISDN Q.931 (T1 / E1 / BRI)

O Q.931 da ISDN utilizou o conceito de Indicadores de Progresso (PIs) que pode ser visualizado na sinalização Q.931. Isso pode ser visto nos Cisco Voice Gateways executando debug isdn q931. Os indicadores de progresso podem ser enviados em mensagens de alerta, progresso, continuação de chamada, confirmação de configuração e desconexão. Um valor de Indicador de progresso de 1 ou 8 cortará o áudio inverso para mensagens de toque e de erro. Os valores do Indicador de progresso de 0, 2 e 3 não vão cortar a mídia de trás para frente. Um DSP atribuído ao canal ISDN pode reproduzir a chamada de volta para a linha ISDN se o autor da chamada remoto não puder fazer isso.

Advertências conhecidas com chamada de volta ISDN

• As chamadas de SIP para ISDN exigem Oferta Antecipada para que quando o Gateway recebe ISDN com um PI válido para abrir mídia invertida, ele tenha o IP do Telefone CUCM/IP para o qual enviar mídia.

Indicadores de progresso Q931

Valor	Definição	Mensagem Q.931
Indicador de progresso = 0	out-of-band	Instalação
Indicador de progresso = 1	A chamada não é ISDN de ponta. Mais informações sobre o progresso da chamada podem estar disponíveis in-band	Alerta, conexão, progresso, configuração
Indicador de progresso = 2	O endereço de destino não é ISDN.	Alerta, conexão, progresso
Indicador de progresso = 3	O endereço de destino não é ISDN.	Instalação
Indicador de progresso = 8	Agora, estão disponíveis informações na banda ou um padrão apropriado.	Alerta, conexão, progresso, desconexão

Exemplos de indicadores de progresso na 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 

  

Configuração

O ringback de ISDN funciona de forma confiável por padrão, portanto, nenhuma configuração adicional é necessária. No entanto, existem comandos para alterar o comportamento no caso de um requisito de interoperabilidade.

Alterando manualmente o valor progress_ind.

Notas Importantes:

• Por padrão, isso é desativado
• Isso só pode ser aplicado a correspondentes de discagem de saída
• Isso PODE ser aplicado aos peers de discagem VOIP e POTS.

Sintaxe completa do comando: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
!

Exigir que um Gateway de Voz sempre envie mensagens de alerta

Se um administrador precisar de um gateway de voz, envie sempre uma mensagem de alerta antes de um Connect, o comando isdn send-alerting pode ser configurado em uma interface Serial. Por padrão, isso é desativado

Sintaxe completa do comando: 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
!

Debugs

debug isdn q931
debug voip ccapi inout

H.323

O H.323 e, mais especificamente, o protocolo de sinalização H.225 VOIP foi criado com base no protocolo Q.931 da ISDN. Como resultado, eles compartilham muitos elementos comuns. Muitos dos comandos presentes e as ideias por trás do toque Q.931 estão presentes no H.323/H.225. Isso inclui os valores do indicador de progresso, os tipos de mensagem e os comandos.

Exemplo de mensagem H.225 para retorno

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

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

Configuração

O H.323 e o H.225 não exigem configuração para o retorno de chamada. No entanto, os comandos especificados na seção Q.931 da ISDN também são aplicáveis ao H.323 Ringback. Além disso, há comandos disponíveis para sinalização H.323.

Comando	Definição
voice call send-alert	Configurado na configuração global. Esse comando é desativado por padrão. Este comando permite que o gateway de destino envie uma mensagem de alerta em vez de uma mensagem de progresso depois de receber uma configuração de chamada. Esse comando pode ser usado quando "Voice Call Send Alert=FALSE" está nas depurações do CCAPI para tornar o valor TRUE. Além disso, isso pode ser usado para ISDN para SIP, onde 183 w/SDP foram recebidos, mas o dispositivo da extremidade oposta não estava realmente reproduzindo o toque de retorno. Ele altera o progresso do TX para alerta do TX com as mesmas informações do PI. A PSTN reproduziu o rinback.
voice rtp send-recv	Abre o canal de áudio RTP em ambas as direções.
! dial-peer voice 1 voip tone ringback alert-no-pi ! dial-peer voice 2 pots tone ringback alert-no-pi !	Esse comando faz com que o gateway gere uma chamada de volta para a parte chamadora se um alerta for recebido no trecho de chamada IP sem PI presente. É diferente do comando progress_ind setup porque a mensagem de configuração H.225 de saída não contém um PI de 3 com o comando tone ringback. É possível que alguns dispositivos não aceitem mensagens de configuração quando um PI estiver incluído.

Configurações do CUCM

Existem algumas configurações H.323 específicas para chamada de volta no CUCM>

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

Valor	Definição
Usar ANN para toque de retorno	Usar o Cisco SCCP Annunciator para reproduzir o tom de chamada de volta (disponível no Cisco CallManager versão 4.0 e posterior)
Informações do usuário para o tom de progresso da chamada	Enviar mensagem de informação do usuário H.225 para o gateway do IOS para reproduzir tom de chamada de volta ou tom em espera (este é o padrão).
H225 Info for Call Progress Tone (Informações sobre o tom de progresso da chamada)	Enviar mensagem de informação H.225 para o gateway do IOS para reproduzir tom de chamada de volta ou tom em espera

Debugs

debug voip ccapi inout
debug h225 asn1

Este também é um excelente documento sobre Troubleshooting H.323 Ringback

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

SIP

O toque de retorno SIP geralmente envolve uma de duas mensagens. 180 e 183. O RFC 3261 afirma que 0, 1 ou mais dessas mensagens 1XX podem ser recebidas após um CONVITE, portanto, não é contra o RFC não receber uma dessas mensagens. Se nenhum for recebido, não haverá chamada de volta. Portanto, se um chamador está esperando um toque de retorno de alguma forma, é necessário um 180 ou 183.

Tanto um 180 quanto o 183 podem conter o Session Description Protocol (SDP) que o CUBE tratará como mídia inicial. Quando o SDP está presente em uma mensagem 18X, o CUBE e o CUCM esperam que o dispositivo da extremidade oposta enviando o 18X com o SDP reproduza a chamada de volta do IP especificado no SDP. Não há configuração para alterar esse comportamento no CUCM ou no CUBE. Alguns dispositivos exigem uma troca PRACK (rel1xx) na mensagem 18X antes do envio do retorno.

O RFC3960 mergulha em mais detalhes sobre a Sinalização de Toque de Retorno com SIP.

É importante observar que para o SIP para ISDN e SIP para H.323 chama um 18X com mapas SDP para um Indicador de progresso de dentro da banda, enquanto um 18X sem SDP mapeia para um alerta.

Exemplo 183 com 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

Exemplo 180 sem 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

Configuração

Comando	Definição
! sip-ua disable-arly-media 180 !	Usado para especificar qual tratamento de chamada, mídia inicial ou chamada de volta local, é fornecido para 180 respostas com 180 respostas com Session Description Protocol (SDP)
! voice service voip  sip   bloco {180 | 181 | 183} sdp {presente | ausente} !	Bloqueia mensagens específicas referentes ao toque de retorno

Perfil SIP para alterar uma sessão 183 em andamento para um toque 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
!

Habilitando PRACK (rel1xx) no CUCM.

• O PRACK está desabilitado por padrão nos perfis SIP do CUCM

Caminho do menu do sistema: Dispositivo > Configurações do dispositivo > Perfil Sip > Escolha um perfil SIP > SIP Rel1XX

Opções 

• Desativado (padrão)
• Enviar PRACK se 1xx contiver SDP
• Enviar PRACK para todas as mensagens 1xx

Ativação do PRACK (rel1xx) em gateways

• Por padrão, rel1xx está ativado em gateways de voz. Se um CUBE receber um requisito: cabeçalho 100rel ele irá PRACK

Debugs

debug voip ccapi inout
debug ccsip messages

  

MGCP

MGCP é o lado VOIP que controla as portas FXS e ISDN T1 / E1. Você pode verificar se o CUCM está enviando a sinalização de chamada de volta apropriada para a porta específica, mas não há muita configuração que possa ser feita.

Exemplo de mensagem de chamada de volta MGCP do CUCM para uma porta 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 sinalizados e g/rt = Pacote genérico / Tom de chamada de volta

Configuração do CUCM

Caminho do menu do sistema: Sistema > Parâmetros de serviço > Pub > CallManager > Desativar indicador de progresso de alerta

• Esse parâmetro determina se o indicador de progresso de alerta para Informações de Inband é relatado para gateways PRI digitais.
• Os valores válidos especificam Verdadeiro (desative o indicador de progresso de alerta) ou Falso (envie o indicador de progresso de alerta).
• Para receber o toque de volta em determinadas configurações, talvez seja necessário definir esse campo como Falso para forçar o cut-through de mídia.

Configuração de gateway

• Nenhum

Debugs

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

SCCP

Para telefones IP SCCP registrados no CUCM ou CME, há uma "StartToneMessage" enviada para o telefone IP que diz ao telefone local para reproduzir o toque de retorno para a pessoa que está fazendo a chamada.

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

Depurações de chamada de volta para todas as portas de voz analógicas:

debug voip ccapi inout
debug vpm signal
debug voip vtsp session

  

portas de voz

• O DSP local será responsável por fornecer o retorno de chamada para a porta de voz.
• Um CPtone personalizado é configurável na porta de voz escolhida.

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

Saída de debug ccapi inout, debug vpm signal e debug voip vtsp session para chamada E1 R2 mostrando o toque de retorno.

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='#'

Detalhes específicos do toque de retorno da Cisco

Transferências internas (troncos SIP e CUC)

• Durante uma transferência interna através de um tronco sip ou para/do anunciador CUC CUCM será o responsável pela chamada de volta.

• Verifique se uma MRGL e um Annunciator estão atribuídos ao tronco e se o serviço IPVMS foi iniciado.

Agentes móveis do Contact Center

• Para que um agente ouça os tons de progresso de chamada para chamadas iniciadas pelo agente, é necessária uma configuração adicional se o MTP obrigatório não estiver ativado. Se, em vez disso, você tiver alocação dinâmica de MTP forçando configurações de DTMF incompatíveis, o Unified CM deverá ser configurado para ativar a Oferta antecipada.
• Tons de andamento de chamada e de chamada não são gerados pelo Cisco Annunciator, como é o caso de telefones e softphones regulares. Em vez disso, o Agente Móvel depende que esses tons sejam gerados pela parte chamada (e a configuração de oferta antecipada aciona esses tons para serem enviados ao agente).

Documentação:
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) e VXML

O CVP sinalizará o gateway VXML para reproduzir o toque enviando um CONVITE com um número específico.
Exemplo: 9191
O SDP deste CONVITE será onde queremos que o gateway VXML envie o toque de volta.

Isso corresponderá a um peer de discagem configurado com um serviço de chamada de volta configurado.

Troubleshoot

Atraso no toque

O atraso no corte de chamada é geralmente causado por um atraso na sinalização subjacente. As depurações e os registros do dispositivo específico e dos protocolos que estão sendo usados precisarão ser consultados para descobrir por que há um atraso na sinalização.

Para a falha de sinalização do gateway de voz em peers de discagem e a re-busca de peer de discagem pode causar um atraso considerável, à medida que o dispositivo tenta encontrar um próximo salto para a chamada. 

debug voip ccapi inout Analysis

Como você pode ver por todo o documento, a coleta de depurações ccapi é muito importante para QUALQUER problema de retorno de chamada.

a API de controle de chamadas (CCAPI) é responsável por ligar dois lados de uma chamada em um gateway de voz e, como resultado, também agrupar o toque de retorno de uma perna de chamada para outra.

Exemplos de saída de depuração do CCAPI para chamada de volta

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

Sinalização é OK, mas não há sinal de volta?

Dependendo da sua sinalização, tudo pode parecer bem. No entanto, pode não haver chamada de volta. Se o sinal indicar que uma parte específica está enviando um toque de volta ao seu dispositivo, vale a pena capturar um pacote ou uma captura PCM da porta de voz para verificar se o toque de retorno é realmente reproduzido ou não.

Também é importante verificar o roteamento da camada 3 a partir da origem e do destino. se eles não puderem enviar pacotes RTP para o dispositivo, você não ouvirá áudio. Além disso, se você não puder enviar pacotes para um dispositivo específico, eles não ouvirão seu toque de volta.

Comandos úteis de roteamento de Camada 3

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

Documentação de captura PCM:

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