Analisi approfondita del Ringback per tutti i protocolli VoIP e analogici

Introduzione

Lo scopo di questo documento è fornire una spiegazione dettagliata dei toni di ritorno audio comunemente indicati come toni di avanzamento chiamata o toni CP per breve.

Questo documento tenterà di discutere e fornire un'analisi di come il ringback funziona all'interno di tutti i protocolli VoIP (Voice over IP) e di segnalazione analogica.

Prerequisiti

Requisiti

Sebbene non vi sia alcun prerequisito formale necessario per leggere questo documento; è stato scritto con la speranza che il lettore abbia già una certa conoscenza operativa dei protocolli di segnalazione vocale sottostanti utilizzati per stabilire e connettere le chiamate telefoniche. In questo documento viene fatto riferimento più volte a questi protocolli.

Protocolli di segnalazione:Session Initiation Protocol (SIP), H323 (h225 / h245), Media Gateway Control Protocol (MGCP), Skinny Client Control Protocol (SCCP), ISDN Q931, E1 R2.

Protocolli multimediali:Real Time Protocol (RTP), codec voce, codec video.

Tecnologie analogiche: Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS), Foreign Exchange Office (FXO) e E1 R2.

Componenti usati

Le informazioni fornite in questo documento si basano sui seguenti prodotti software e hardware:

Cisco IOS e gateway IOS-XE (2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / ASR100X) con qualsiasi versione di IOS/IOS-XE.

Cisco Unified Communications Manager (CUCM) versione 9.X e successive

Cisco Unity Connection (CUC) versioni 9.x e successive

Customer Voice Portal (CVP) versione 9.x e successive

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi o delle configurazioni.

Premesse

Rinback non è un protocollo VoIP o analogico, ma è presente in ogni chiamata telefonica fatta da telefoni cellulari, linee fisse, telefoni da scrivania e soft client. La comprensione del funzionamento, dell'origine e della modalità di risoluzione dei problemi di richiamata è quindi una parte importante di un toolbet dei tecnici di collaborazione.

Il richiamo è una sequenza di toni riprodotti alla persona che fa una telefonata che fa sapere al chiamante che la parte chiamata sta effettivamente suonando. L'assenza della suoneria è da considerarsi un segno negativo in quanto chi chiama suppone che il destinatario non stia effettivamente suonando. Ringback / CPtones variano paese per paese. Se una persona chiamasse un numero degli Stati Uniti, verrebbe riprodotta con un set di riproduzioni diverso rispetto a se la stessa persona chiamasse un numero del Regno Unito.

Nella maggior parte degli scenari la richiamata viene eseguita dal destinatario della chiamata remoto al destinatario della chiamata. A questo scopo, l'audio deve essere tagliato nella direzione indietro (Chiamata a chiamata).

Protocolli

In questo documento vengono esaminati i diversi protocolli e le relative modalità di negoziazione del ringback, nonché le modalità di modifica del ringback quando si utilizza tale protocollo.

ISDN Q.931 (T1 / E1 / BRI)

L'ISDN Q.931 utilizzava il concetto di Indicatori di avanzamento (PI, Progress Indicators) che possono essere visualizzati nella segnalazione Q.931. A tal fine, è possibile eseguire il comando debug isdn q931 sui Cisco Voice Gateway. Gli indicatori di stato possono essere inviati nei messaggi Alert, Progress, Call Proceeding, Setup Ack e Disconnect. Un valore indicatore di stato pari a 1 o 8 interrompe l'audio all'indietro per il ritorno all'indietro e i messaggi di errore. I valori 0, 2 e 3 degli indicatori di avanzamento non consentono di scorrere i supporti all'indietro. Un DSP assegnato al canale ISDN può riprodurre il segnale alla linea ISDN se il destinatario della chiamata non è in grado di farlo.

Avvertenze note con richiamata ISDN

• Le chiamate da SIP a ISDN richiedono un'offerta anticipata, in modo che quando il gateway riceve un'ISDN con una PI valida per aprire i supporti in senso inverso, abbia l'IP del telefono CUCM/IP a cui inviare i supporti.

Indicatori di avanzamento Q931

Valore	Definizione	Messaggio Q.931
Indicatore di stato = 0	fuori banda	Configurazione
Indicatore di stato = 1	La chiamata non è un'ISDN end-end. Ulteriori informazioni sull'avanzamento delle chiamate sono disponibili in banda	Avviso, Connessione, Avanzamento, Configurazione
Indicatore di stato = 2	L'indirizzo di destinazione non è ISDN.	Avviso, connessione, avanzamento
Indicatore di stato = 3	L'indirizzo di destinazione non è ISDN.	Configurazione
Indicatore di stato = 8	Sono ora disponibili informazioni in banda o un modello appropriato.	Avviso, Connessione, Avanzamento, Disconnessione

Esempi di indicatori di avanzamento in 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 

  

Configurazione

Il servizio di richiamata ISDN è affidabile per impostazione predefinita, quindi non è necessaria alcuna configurazione aggiuntiva. Tuttavia, esistono dei comandi per modificare il comportamento in caso di un requisito di interoperabilità.

Modifica manuale del valore progress_ind.

Note importanti:

• Questa opzione è disattivata per impostazione predefinita
• Applicabile solo ai dial-peer in uscita
• Questa condizione PUÒ essere applicata sia ai dial-peer VOIP che POTS.

Sintassi completa dei comandi: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
!

Richiedere che un gateway vocale invii sempre messaggi di avviso

Se l'amministratore deve richiedere che il gateway vocale invii sempre un messaggio di avviso prima di eseguire Connect, è possibile configurare il comando isdn send-alerting tramite un'interfaccia seriale. Questa opzione è disattivata per impostazione predefinita

Sintassi completa dei comandi: 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
!

Debug

debug isdn q931
debug voip ccapi inout

H.323

H.323, e più specificamente il protocollo di segnalazione VOIP H.225, è stato sviluppato sul protocollo Q.931 di ISDN. Di conseguenza condividono molti elementi comuni. Molti dei comandi presenti e delle idee alla base di Q.931 sono presenti in H.323/H.225. Ciò include i valori degli indicatori di avanzamento, i tipi di messaggio e i comandi.

Esempio di messaggio H.225 per il rinvio

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

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

Configurazione

H.323 e H.225 non richiedono alcuna configurazione per la richiamata automatica dalla scatola. Tuttavia, i comandi specificati nella sezione ISDN Q.931 sono validi anche per H.323 Ringback. Inoltre, sono disponibili alcuni comandi per la segnalazione H.323.

Comando	Definizione
send-alert chiamata vocale	Configurato nella configurazione globale. Questo comando è disabilitato per impostazione predefinita. Questo comando consente al gateway di chiusura di inviare un messaggio di avviso anziché un messaggio di stato dopo la ricezione della configurazione di una chiamata. Questo comando può essere utilizzato quando "Voice Call Send Alert=FALSE" è nei debug CCAPI per rendere il valore TRUE. Questa funzione può essere usata anche per le connessioni ISDN-SIP dove è stata ricevuta una connessione 183 con SDP, ma il dispositivo più lontano non stava riproducendo la riproduzione del ringback. Cambia l'avanzamento TX in avviso TX con le stesse informazioni PI. PSTN ha quindi riprodotto la riproduzione.
voice rtp send-recv	Apre il canale audio RTP in entrambe le direzioni.
! dial-peer voice 1 voip avviso di richiamata tono-no-pi ! dial-peer voice 2 porte avviso di richiamata tono-no-pi !	Con questo comando il gateway genera un ringback verso il chiamante se viene ricevuto un avviso sulla gamba della chiamata IP senza la presenza di una PI. Differisce dal comando progress_ind setup in quanto il messaggio di installazione H.225 in uscita non contiene una PI di 3 con il comando tone ringback. È possibile che alcuni dispositivi non accettino i messaggi di impostazione quando è inclusa una PI.

Configurazioni CUCM

Esistono alcune configurazioni H.323 specifiche per il ringback all'interno di CUCM>

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

Valore	Definizione
Usa ANN per richiamare	Utilizzare Cisco SCCP Annunciator per riprodurre la suoneria (disponibile in Cisco CallManager versione 4.0 e successive)
Informazioni utente per segnale di avanzamento chiamata	Inviare il messaggio di informazioni per l'utente H.225 al gateway IOS per riprodurre la suoneria o la suoneria in attesa (impostazione predefinita).
Segnale di avanzamento informazioni H225 per chiamata	Invia messaggio informativo H.225 al gateway IOS per riprodurre la suoneria o la suoneria in attesa

Debug

debug voip ccapi inout
debug h225 asn1

Questo è anche un ottimo documento sulla risoluzione dei problemi H.323 Ringback

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

SIP

Il sip ringback in genere comporta uno di due messaggi. 180 e 183. In base alla RFC 3261, 0, 1 o più di questi messaggi 1XX possono essere ricevuti dopo un INVITE, pertanto non è consigliabile che la RFC non riceva uno di questi messaggi. Se non ne viene ricevuto nessuno, non verrà eseguito il ringback. Quindi, se il chiamante si aspetta una richiamata in qualche forma, è necessario un 180 o 183.

Sia il 180 che il 183 possono contenere il Session Description Protocol (SDP) che CUBE considererà come supporti iniziali. Quando SDP è presente in un messaggio 18X CUBE e CUCM si aspetta che il dispositivo più lontano che invia il 18X con SDP riproduca la richiamata dall'IP specificato in SDP. Non è disponibile alcuna configurazione per modificare questo comportamento in CUCM o CUBE. Per alcuni dispositivi è necessario uno scambio PRACK (rel1xx) sul messaggio 18X prima dell'invio della richiamata.

RFC3960 esamina ulteriori dettagli sulla segnalazione di richiamata con SIP.

È importante notare che per SIP to ISDN e SIP to H.323, il segnale 18X con SDP viene mappato a un indicatore di avanzamento in banda, mentre il segnale 18X senza SDP viene mappato a un avviso.

Esempio 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

Esempio 180 senza 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

Configurazione

Comando	Definizione
! sip-ua disable-early-media 180 !	Utilizzato per specificare il trattamento delle chiamate, il supporto iniziale o il richiamata locale, fornito per 180 risposte con 180 risposte con SDP (Session Description Protocol)
! voice service voip  sorso   blocco {180 | 181 | 183} sdp {presente | assente} !	Blocca i messaggi specifici relativi alla richiamata

SIP Profile per modificare una sessione 183 in corso in un ring 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
!

Attivazione di PRACK (rel1xx) in CUCM.

• PRACK è disabilitato per impostazione predefinita nei profili SIP CUCM

Percorso menu di sistema: Dispositivo > Impostazioni dispositivo > Profilo SIP > Scegliere un profilo SIP > SIP Rel1XX

Opzioni 

• Disabilitato (predefinito)
• Invia PRACK se 1xx contiene SDP
• Invia PRACK per tutti i messaggi 1xx

Abilitazione di PRACK (rel1xx) su gateway

• Per impostazione predefinita, rel1xx è abilitato sui gateway voce. Se un CUBE riceve un'istruzione: Intestazione 100rel su cui verrà eseguito PRACK

Debug

debug voip ccapi inout
debug ccsip messages

  

MGCP

MGCP è il lato VOIP che controlla le porte FXS e ISDN T1 / E1. È possibile verificare se CUCM sta inviando il segnale di riavvio corretto alla porta specifica, ma non è possibile eseguire molte operazioni di configurazione.

Messaggio di esempio di richiamata MGCP da CUCM a una porta VG224 FXS

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: = Eventi segnalati e g/rt = Pacchetto generico / Suono di richiamata

Configurazione CUCM

Percorso menu di sistema: Sistema > Parametri servizio > Pub > CallManager > Disabilita indicatore di stato avvisi

• Questo parametro determina se l'indicatore di avanzamento degli avvisi per Informazioni in banda viene segnalato ai gateway PRI digitali.
• I valori validi specificano True (disattiva l'indicatore di stato degli avvisi) o False (invia l'indicatore di stato degli avvisi).
• Per ricevere il segnale acustico in determinate configurazioni, potrebbe essere necessario impostare questo campo su False per forzare il taglio dei supporti.

Configurazione gateway

• Nessuna

Debug

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

SCCP

Per i telefoni IP SCCP registrati su CUCM o CME viene inviato un messaggio "StartToneMessage" all'IP Phone che indica al telefono locale di riprodurre la chiamata alla persona che effettua la chiamata.

Analogico (FXS / FXO / E&M / E1 R2)

Debug della richiamata per tutte le porte voce analogiche:

debug voip ccapi inout
debug vpm signal
debug voip vtsp session

  

Porte voce

• Il DSP locale sarà responsabile della richiamata per la porta vocale.
• Un CPtone personalizzato è configurabile sotto la porta voce scelta.

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

Output dei capi in uscita di debug, segnale vpm di debug e sessione vtsp di debug voip per la chiamata E1 R2 con riavvio.

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

Dettagli richiamata specifici di Cisco

Trasferimenti interni (SIP Trunk e CUC)

• Durante un trasferimento interno attraverso un sip trunk o verso/da CUC CUCM annunciator sarà quello che fornisce la richiamata.

• Accertarsi che MRGL e Annunciatore siano assegnati al trunk e che il servizio IPVMS sia avviato.

Agenti mobili per Contact Center

• Affinché un agente possa ascoltare i toni di avanzamento delle chiamate avviate dall'agente, è necessaria una configurazione aggiuntiva se MTP Required non è abilitato. Se invece si dispone di un'allocazione MTP dinamica forzando impostazioni DTMF non corrispondenti, è necessario configurare il CM unificato per abilitare l'offerta anticipata.
• Il richiamo e altri toni di avanzamento delle chiamate non vengono generati da Cisco Annunciator, come nel caso dei telefoni normali e dei softphone. Al contrario, Mobile Agent si basa su questi toni generati dal destinatario della chiamata (e l'impostazione dell'offerta anticipata attiva questi toni da inviare all'agente).

Documentazione:
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

Il CVP segnalerà al gateway VXML di riprodurre il riavvio inviando un INVITE con un numero specifico.
Esempio: 9191
Il SDP di questo INVITE sarà il punto in cui il gateway VXML invierà il riavvio.

Corrisponde a un dial-peer configurato con un servizio di richiamata configurato.

Risoluzione dei problemi

Ritardo nella richiamata

Il ritardo nel taglio della richiamata è in genere causato da un ritardo nella segnalazione sottostante. I debug e i log per il dispositivo e i protocolli specifici usati dovranno essere consultati per capire perché si è verificato un ritardo nella segnalazione.

In caso di errore di segnalazione del gateway vocale sui peer di connessione e di re-ricerca del peer di connessione, il dispositivo potrebbe causare un ritardo considerevole quando tenta di trovare un hop successivo per la chiamata. 

debug voip capi inout Analysis

Come si può vedere in tutto il documento la raccolta di ccapi debug è molto importante per QUALSIASI problema di ringback.

l'API di controllo delle chiamate (CCAPI) è responsabile del bridging di due lati di una chiamata su un gateway vocale e, di conseguenza, anche del collegamento del ringback da un call-leg all'altro.

Esempi di output di debug da CCAPI per il ringback

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 segnalazione è OK, ma non c'è la richiamata?

A seconda della tua segnalazione, tutto potrebbe sembrare a posto. Tuttavia, potrebbe ancora non essere disponibile il ritorno. Se il segnale indica che una parte specifica sta inviando il riavvio al dispositivo, vale la pena acquisire un pacchetto o un'acquisizione PCM dalla porta voce per verificare se il riavvio è effettivamente eseguito.

È inoltre importante controllare il routing di layer 3 dall'origine e dalla destinazione. se non possono inviare pacchetti RTP al dispositivo, l'audio non verrà riprodotto. Inoltre, se non è possibile inviare i pacchetti a un dispositivo specifico, il sistema non ascolterà la richiamata.

Comandi di routing utili sul layer 3

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

Documentazione sull'acquisizione PCM:

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