Risoluzione dei problemi di Dialer in uscita basato su IVR

Introduzione

Questo documento descrive IVR-Based Outbound Dialer e include un esempio di configurazione del gateway SIP, un'analisi dei log sia dal gateway SIP che dal motore Cisco Unified Contact Center Express (UCCX) e le limitazioni di IVR-Based Outbound Dialer.

In UCCX 8.5 è stato introdotto un nuovo tipo di dialer in uscita: Interactive Voice Response (IVR)-Based Outbound Dialer. A differenza della versione precedente di Preview Outbound Dialer, per la chiamata in uscita non viene utilizzato alcun agente. UCCX si connette direttamente a un gateway SIP (Session Initiation Protocol) nell'azienda del cliente per comporre i contatti in uscita. Quando il gateway rileva una voce o una segreteria telefonica attiva, la chiamata viene reindirizzata a un trigger UCCX associato a un gruppo di controllo delle chiamate in uscita. Una volta terminato sulla porta CTI (Computer Telephony Integration) in uscita, l'applicazione associata al trigger viene eseguita normalmente.

Informazioni sulle funzionalità

Nelle versioni UCCX precedenti alla 8.5, esisteva solo l'Anteprima dialer in uscita. Questo dialer ha utilizzato il controllo delle chiamate di terze parti tramite JTAPI (Java Telephony Application Programming Interface)/CTI per indicare al telefono dell'agente di effettuare la chiamata. La chiamata è stata effettuata dopo che un agente ha accettato una prenotazione in uscita. L'interazione tra client e server per le prenotazioni in uscita è stata eseguita tramite CTI.

In alcuni casi di utilizzo (ad esempio, promemoria di appuntamenti e applicazioni IVR self-service), l'opzione Anteprima dialer in uscita non è appropriata. Per effettuare una chiamata a un numero nell'elenco di composizione, un agente è stato bloccato durante l'esecuzione della chiamata. Ciò significa che l'agente è occupato per ogni chiamata in uscita, anche se il numero PSTN (Public Switched Telephony Network) non è valido, è occupato o ha restituito una segreteria telefonica. Questo elevato livello di utilizzo degli agenti ha rappresentato un notevole inconveniente dell'opzione Anteprima dialer in uscita per questi casi di utilizzo.

Flusso delle chiamate in uscita basate su IVR

Negli stessi casi di utilizzo (promemoria di appuntamenti e applicazioni IVR self-service) in IVR-Based Outbound Dialer, un agente potrebbe non essere mai coinvolto nel flusso di chiamata. Flusso di chiamata per Dialer in uscita basato su IVR:

1. Il dialer IVR in uscita determina il numero di contatti da comporre (come definito nell'algoritmo) e utilizza il SIP per effettuare le chiamate in uscita attraverso il gateway vocale.
2. Il gateway vocale rileva un contatto non attivo con le funzionalità CPA (Call Progress Analysis) e invia lo stato del contatto non attivo al dialer. La connessione telefonica aggiorna le informazioni sullo stato dei contatti nel database di configurazione.
3. Il gateway vocale rileva il contatto attivo con le funzionalità CPA e invia lo stato del contatto al dialer. Il dialer aggiorna le informazioni sullo stato dei contatti nel database di configurazione e invia un messaggio di riferimento SIP al gateway SIP, che a sua volta trasferisce la chiamata al punto di routing CTI configurato sul Cisco Unified Communications Manager (CUCM).
4. CUCM trasferisce la chiamata a una porta IVR sul server Cisco UCCX.
5. Il sottosistema IVR associa la chiamata all'applicazione IVR associata alla campagna. Il motore avvia l'esecuzione dell'applicazione e viene eseguita una sessione IVR tra l'applicazione IVR per la campagna su UCCX e il contatto del cliente.

Tipi di dialer basati su IVR

Esistono due tipi di dialer IVR basati su IVR in uscita, predittivi e progressivi. Poiché UCCX trasferisce una chiamata a una porta IVR per eseguire uno script quando viene rilevata una voce in diretta (o una segreteria telefonica configurabile), è ragionevole supporre che non tutti i contatti in uscita richiedano una porta. Per bilanciare la possibilità che sia necessaria una porta CTI con la probabilità che esistano situazioni con numeri occupati e non validi, i dialer predittivi e progressivi modificano il numero di chiamate in uscita che vengono effettuate alla volta rispetto al numero di porte CTI in uscita configurate.

Un dialer in uscita basato su IVR predittivo dispone delle seguenti funzionalità:

• Il numero di linee per ciascuna porta può essere sintonizzato in base alla frequenza delle chiamate di abbandono.
• Non è necessario alcun intervento manuale.
• L'obiettivo è comporre un numero di linee sufficiente per mantenere occupate le porte IVR ma non superare la velocità massima configurata per le chiamate in uscita.

Un dialer in uscita basato su IVR progressivo ha le seguenti caratteristiche:

• È possibile specificare un numero fisso di righe da comporre sempre per ogni porta IVR in uscita disponibile.
• Il numero di righe può essere aggiornato in un secondo momento.
• Se vi sono tre linee per ciascuna porta e il numero di porte dedicate per la connessione in uscita è tre, vengono composte nove chiamate (3x3).
• Una chiamata interrotta si verifica quando un cliente risponde al telefono, ma non è disponibile alcuna porta per la richiesta al cliente.
• È possibile definire le impostazioni predefinite.

Componenti dialer con UCCX

Tutte le funzionalità e i sottosistemi interni sono astratti per tenere conto di questo nuovo dialer in uscita basato su IVR. I componenti di sistema nella nuova finestra di dialogo, come la tabella Engine e la tabella DialingList, sono gli stessi della finestra di dialogo Anteprima chiamata in uscita, con le estensioni aggiunte (ad esempio altri valori callStatus e callResult).

Informazioni sulle funzionalità del gateway

Per supportare il rilevamento della voce in diretta, della segreteria telefonica e delle informazioni speciali (SIT), il gateway deve supportare la funzione CPA. Usare Cisco Feature Navigator per determinare le versioni del gateway Cisco IOS^® che supportano la connessione dialer SIP e CPA; utilizzare la ricerca 'Search by Feature' per 'Supporto facilità di manutenzione per dialer SIP e analisi dell'avanzamento delle chiamate'.

Come funziona il CPA?

La CPA ha tre funzioni principali:

• Rilevamento segreteria telefonica (AMD)
• Rilevamento fax/modem
• Segreteria telefonica terminazione rilevamento tono

Esistono complessi algoritmi implementati per fare queste distinzioni, ma da un punto di vista funzionale:

• Una risposta dal vivo dovrebbe essere un breve saluto, poi un periodo di silenzio.
  Esempio: "Ciao" + silenzio
  Esempio: "Ciao, Johnson residence" + silenzio
• Ci si aspetta che una segreteria telefonica sia una formula di saluto più lunga e che non ci sia silenzio.
  Esempio: "Hai raggiunto la residenza di Miller, per favore lascia un messaggio dopo il bip"
• Una segreteria telefonica che rileva il tono di risposta dovrebbe essere il rilevamento della segreteria telefonica, poi il silenzio, poi il tono di chiusura.
• Il rilevamento fax è il riconoscimento del segnale fax.

La capacità di effettuare queste distinzioni potrebbe essere difficile, quindi potrebbe essere necessario regolare i parametri di temporizzazione per ottimizzare la configurazione.

Un altro fattore da considerare è che i fornitori di telefoni cellulari potrebbero avere vari gradi di ritardo tra la presentazione di una chiamata a loro, la posizione della cella e la presentazione della chiamata alla cella stessa.

Questo è un esempio del calcolo previsto:

1. UCCX invia un invito SIP al gateway (T1)
2. Il gateway invia una configurazione di chiamata ISDN al provider di servizi e al provider di celle (T2)
3. Il cellulare squilla e avvia il timer di risposta (T3)
4. Il timer Cell RNA scade e viene inoltrato alla segreteria telefonica (T4)

Se si presume che il timer RNA per la cella sia di 15 secondi, il tempo effettivo necessario per una chiamata a una cella da inoltrare alla segreteria telefonica è (T1 + T2 + T3 + 15). T1 + T2 + T3 potrebbe essere significativamente più alto del tempo necessario per presentare una chiamata a una linea fissa o a un altro dispositivo non cellulare.

Pertanto, quando si definisce il limite di chiamata senza risposta per una campagna, il periodo deve essere sufficientemente lungo da raggiungere il sistema di segreteria telefonica per i telefoni cellulari; questo sarebbe il comportamento desiderato, ad esempio, per una campagna destinata a lasciare un messaggio.

Nota: CPA è una funzionalità dello sportello; a differenza di Cisco Unified Contact Center Enterprise (UCCE), CPA non può essere attivato o disattivato su UCCX. Mentre CPA può essere disattivato sul gateway, Cisco sconsiglia questa operazione. Per ulteriori informazioni, vedere Cenni preliminari sull'analisi dell'avanzamento delle chiamate.

La selezione dei codici del gateway IOS esula dall'ambito di questo documento. Per utilizzare IVR-Based Outbound Dialer, il codice del gateway deve supportare CPA e SIP dialer. Cisco Feature Navigator consente di individuare le versioni IOS che soddisfano i requisiti delle funzionalità. Accertarsi sempre che la versione IOS in uso sia compatibile con tutti i componenti che interagiscono con questo gateway.

Risoluzione dei problemi

Nota: per ulteriori informazioni sui comandi menzionati in questa sezione, usare lo strumento di ricerca dei comandi (solo utenti registrati).

Per risolvere i problemi relativi a un IVR in uscita, determinare se il gateway, CUCM o UCCX è in errore. La risoluzione dei problemi è più semplice se il problema viene isolato per un componente specifico. È utile raccogliere queste informazioni dai componenti di sistema

Per il gateway, eseguire i seguenti comandi:

1. show tech
2. messaggi debug ccsip
3. debug voip ccapi inout
4. debug isdn q931 (o debug simile per acquisire la segnalazione laterale PSTN)
5. debug voip hpi all (per risolvere i problemi relativi a CPA)
6. debug voip vtsp all (per risolvere i problemi relativi a CPA)

Per UCCX, esaminare i file di log e la configurazione:

1. File di log MIVR con debug SS_OB e XDebug1 - XDebug3 abilitato
2. File di registro JTAPI (per risolvere i problemi relativi all'errore della chiamata di REFERENCE)
3. Configurazione gateway SIP da UCCX AppAdmin

Per il CUCM, rivedere le configurazioni:

1. CallManager dettagliato
2. CTIManager dettagliato
3. Configurazione trunk SIP che punta al gateway utilizzato per IVR in uscita

Analisi dei dati

Il gateway SIP deve contenere la configurazione necessaria non solo per instradare le richieste di chiamata da UCCX alla PSTN, ma anche per gestire il trasferimento di tali chiamate al trigger UCCX designato per l'uscita. La configurazione del gateway SIP deve avere:

1. Dial-peer in entrata per soddisfare le richieste SIP in entrata da UCCX.
2. Dial-peer in uscita (VoIP o POTS (Plain Old Telephone Service)) per indirizzare le chiamate alla PSTN.
3. VoIP (Dial-Peer) in uscita per instradare la chiamata reindirizzata (REFERENCE) al cluster CUCM integrato con UCCX.

Il server CUCM deve essere configurato in modo da ricevere le richieste di chiamata SIP in entrata dal gateway SIP (chiamate REFERENCE) e da indirizzare le richieste di conseguenza alle porte CTI del trigger UCCX e del gruppo di controllo delle chiamate UCCX.

Esempio di configurazione del gateway SIP

Questo è un esempio di configurazione di un gateway SIP con notazioni. La connettività PSTN in questo esempio è ISDN Primary Rate Interface (PRI).

Nota: Sono supportati altri tipi di connettività PSTN TDM (Time Division Multiplexing), ma Cisco Unified Border Element (CUBE) non è supportato. Per ulteriori informazioni sul supporto CUBE, vedere gli ID bug Cisco CSCui62525 e CSCuf4826. Sono supportate più connessioni alla PSTN TDM per instradare classi diverse di chiamate (locali, interurbane, internazionali) a trunk o provider diversi.

RyanIVRRouter#show run
Building configuration...

Controller T1 configurato per PRI ISDN

!
controller T1 0/0/0
 cablelength long 0db
 pri-group timeslots 1-24
!

Interfaccia seriale configurata per PRI ISDN

!
interface Serial0/0/0:23
 no ip address
 encapsulation hdlc
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!

Porta voce per il routing delle chiamate in uscita verso PSTN

!
voice-port 0/0/0:23
!

VoIP Dial-Peer in entrata

Questo dial-peer corrisponde alle richieste di chiamata SIP in arrivo da UCCX. Se non è configurato alcun dial-peer VoIP in ingresso, viene trovata una corrispondenza con il dial-peer predefinito (dial-peer 0). È buona norma definire e associare un dial-peer VoIP in entrata. Questo dial-peer notifica al gateway il codec, il protocollo e il relay DTMF (Dual-Tone Multifrequency) da utilizzare sulla gamba SIP in entrata da UCCX.

Questo dial-peer corrisponde a tutti gli INVITE SIP in entrata con un DNIS (Digital Number Identification Service) che iniziano con 717 e sono lunghi 10 cifre. In questo esempio, tutti i contatti composti da UCCX sono inclusi nell'indicativo località 717 e hanno numeri di telefono di 10 cifre.

!
dial-peer voice 100 voip
 description -- Outbound Calls From UCCX -- 
 session protocol sipv2
 incoming called-number 717.......
 dtmf-relay rtp-nte
 codec g711ulaw
!

POTS Dial-Peer

Questo dial-peer instrada le chiamate alla PSTN tramite il PRI configurato in precedenza. Si tratta del dial-peer in uscita per le richieste di chiamata provenienti da UCCX e del dial-peer in uscita per VoIP dial-peer 100 di cui sopra. Questo dial-peer funge anche da dial-peer in entrata per le chiamate provenienti dalla PSTN a scopo di test. Nel flusso di chiamate in ingresso UCCX in uscita, questo dial-peer non corrisponde come dial-peer in ingresso.

!
dial-peer voice 10 pots
 description -- POTS Dial Peer To/From PSTN Simulator --
 destination-pattern 717.......
 incoming called-number .
 direct-inward-dial
 port 0/0/0:23
 forward-digits all
!

VoIP Dial-Peer in uscita

Questo dial-peer funge da dial-peer in uscita necessario al gateway SIP per instradare le chiamate al cluster CUCM destinato al trigger UCCX. Questo dial-peer viene utilizzato dal gateway per indirizzare il REFERENCE inviato da UCCX quando viene rilevata la voce in diretta (o la segreteria telefonica se la configurazione esiste). Questo dial-peer definisce il protocollo, il relay DTMF, il codec e l'indirizzo IP del nodo CUCM in cui il gateway SIP deve instradare la chiamata reindirizzata. Ai fini della ridondanza e del bilanciamento del carico, è possibile che esistano più peer di questo tipo. Possono essere partizionati per instradare le richieste a più nodi CUCM nel cluster o essere attivati per instradare i reindirizzamenti per determinati trigger a nodi CUCM diversi.

In questo esempio, i trigger UCCX per le campagne in uscita basate su IVR sono 2001 e 2002.

!
dial-peer voice 102 voip
 description -- Redirect Calls to UCCX 90 --
 destination-pattern 200[1-2]
 session protocol sipv2
 session target ipv4:14.10.166.15
 incoming called-number 200[1-2]
 dtmf-relay rtp-nte
 codec g711ulaw
!

Analisi traccia chiamate in uscita basata su IVR di esempio

Questa è un'analisi dettagliata di un log di messaggistica di esempio tra il gateway SIP, UCCX e PSTN.

L'istruzione INVITE iniziale da UCCX indica al gateway di effettuare una chiamata al numero PSTN. INVITE contiene l'ID chiamata, che può essere utilizzato per tenere traccia di tutti i messaggi associati a questa chiamata, e il protocollo SDP (Session Description Protocol) (parametri multimediali).

Ancora più importante, INVITE include i parametri che il gateway deve utilizzare per completare CPA. Questi parametri sono configurati nelle pagine UCCX AppAdmin, ma non vengono utilizzati da UCCX. ma vengono inviati tramite INVITE al gateway e utilizzati dal gateway per configurare i DSP (Digital Signal Processor) per CPA per questa chiamata. Di conseguenza, questi parametri vengono inviati al gateway per ogni chiamata e possono essere modificati in qualsiasi momento da AppAdmin.

UCCX invia i seguenti attributi di configurazione CPA al gateway per ciascuna chiamata:

Nome parametro	Valore parametro	Valore consigliato
Periodo di silenzio minimo (100 - 1000)*	Millisecondi	375
Periodo di analisi (1000 - 10000)*	Millisecondi	2500
Analisi del tempo massimo (1000 - 10000)*	Millisecondi	3000
Tempo minimo di riconoscimento vocale valido (50 - 500)*	Millisecondi	112
Durata massima dell'analisi delle tonalità (1000 - 60000)*	Millisecondi	15000

I valori configurabili sono presentati in AppAdmin nella pagina Configurazione gateway SIP.

Received: 
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary

--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--

Mentre la chiamata viene elaborata attraverso i dial-peer del gateway, UCCX riceve un messaggio '100 Trying'.

Sent: 
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

Quando la chiamata in uscita corrisponde a un dial-peer in uscita, viene inviata alla PSTN utilizzando il protocollo TDM configurato. In questo caso, viene utilizzato un PRI:

Aug  3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x008D 
	Bearer Capability i = 0x8090A2 
		Standard = CCITT 
		Transfer Capability = Speech  
		Transfer Mode = Circuit 
		Transfer Rate = 64 kbit/s 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23 
	Calling Party Number i = 0x2180, '9195551212' 
		Plan:ISDN, Type:National
 	Called Party Number i = 0xA1, '7175551212' 
		Plan:ISDN, Type:National

La chiamata procede e la segnalazione viene scambiata tra la PSTN e il gateway. Il gateway riceve una notifica che il telefono PSTN sta riempiendo il messaggio ALERTING.

Aug  3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x808D 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23

Aug  3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x808D 
    Progress Ind i = 0x8188 - In-band info or appropriate now available

Il gateway invia un messaggio di stato della sessione 183 a UCCX per notificare a UCCX che il telefono PSTN sta squillando. Questo include SDP per la negoziazione dei media dei toni di riavvolgimento.

Sent: 
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

event=enabled
--uniqueBoundary--

La chiamata è collegata al segmento TDM quando il telefono PSTN ha risposto alla chiamata. Il gateway invia una conferma in CONNECT_ACK.

Aug  3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x808D

Aug  3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x008D

Il gateway notifica a UCCX che la chiamata è connessa con un OK 200. UCCX esegue questa operazione, come richiesto dall'RFC SIP. La 200 OK contiene anche SDP per la negoziazione dei supporti, ma non viene utilizzata da UCCX.

Sent: 
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Received: 
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...

Il gateway rileva l'avanzamento della chiamata con CPA e notifica a UCCX l'avanzamento della chiamata tramite una serie di messaggi UPDATE. UCS ACK, come richiesto dall'RFC SIP.

Nell'esempio di aggiornamento SIP, l'evento è 'Detected' (Rilevato) e lo stato è 'CpaS'.

• CpaS indica che il CPA è iniziato.
• Quando viene rilevata una segreteria telefonica, lo stato è 'Asm'.
• Quando il tono della segreteria telefonica è qualificato, lo stato è 'AsmT'.

In questa tabella vengono elencati i codici di stato x-cisco-cpa utilizzati nei messaggi di aggiornamento SIP:

Nome	Definizione
FT	Tono fax/modem.
Asm	Answer Machine
AsmT	Segnale di terminazione del computer di risposta.
LS	Voce umana in diretta.
SitIC	Tono SIT IC - Intercept - Numero vuoto o AIS o così via.
SitNC	Tono SIT NC - Nessun circuito, blocco di emergenza o blocco trunk
SitVC	SIT tone VC - Codice libero
SitRO	Tono SIT RO - Annuncio di riordino
SitMT	Segnale SIT
CpaS	Inizio CPA
LV	Volume basso o inattività

Sent: 
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26

event=detected
status=CpaS

Received: 
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...

UCCX invia una notifica al gateway per reindirizzare la chiamata al trigger assegnato a questa campagna in uscita. L'ACK del gateway corrisponde a questo.

Received: 
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...

Sent: 
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...

Il gateway deve indirizzare questa chiamata alla nuova destinazione come qualsiasi normale elaborazione delle chiamate tramite i dial-peer sul gateway.

Aug  3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=FALSE, Mode=0,
   Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)

La chiamata viene instradata dal gateway in base alla configurazione nel dial-peer in uscita corrispondente per la destinazione contenuta nel FAR RIFERIMENTO.

Sent: 
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270

v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Esempio di analisi del log MIVR

Questi frammenti di un registro MIVR forniscono una panoramica della chiamata dal punto di vista di UCCX. Abilitare questi livelli di debug per acquisire le informazioni corrette:

• SS_OB - Debug,XD1,XD2,XD3
• SS_RM - Debug,XDebug1
• CFG_MGR - Debug,XDebug1 (se il problema riguarda i record della lista di composizione)
  

135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, , 
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239


135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2

Nota: Poiché potrebbero essere presenti più campagne contemporaneamente, è importante prestare attenzione all'ID campagna e all'ID record.

B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0

135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber: 
   callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9 
   longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset: 
   DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212

//Based on the Campaign config, the phone number is modified accordingly. In a failed call 
scenario, you might want to verify what the number is after the formatting is done. Look 
for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.

135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor: 
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239 
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240 
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212. 

Ecco i numeri di telefono formattati e non formattati:

135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() - 
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212 
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )

La segnalazione SIP ha inizio:

SIP-9919785551212  INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0

SIP-9919785551212  SIP/2.0 100 Trying

SIP-9919785551212  SIP/2.0 183 Session Progress

SIP-9919785551212  SIP/2.0 200 OK

Verificare la gestione di questi messaggi sul gateway con i messaggi del gateway descritti in precedenza.

135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68, 
State=CONTACTING, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5 sending
 
SIP-9919785551212  ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0

135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify 
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed

135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway

135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=OK135534725: Aug 20 21:34:58.810 EDT 
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, 
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR 
Dialer processes
135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData:
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

Il gateway invia un messaggio SIP UPDATE insieme al messaggio CPA. Il software CPA viene eseguito sul gateway e analizza il protocollo RTP (Real-Time Transport Protocol) della parte chiamata. Ciò consente di distinguere tra la voce e la segreteria telefonica al termine della chiamata. È possibile identificare un messaggio CPA SIP UPDATE dal relativo Content-Type 'application/x-cisco-cpa'.

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 102 UPDATE
SIP-9919785551212  Content-Length: 26
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512899
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=CpaS

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 103 UPDATE
SIP-9919785551212  Content-Length: 163
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512902
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=LV
SIP-9919785551212  pickupT=320
SIP-9919785551212  maxActGlitchT=0
SIP-9919785551212  numActGlitch=0
SIP-9919785551212  valSpeechT=20
SIP-9919785551212  maxPSSGlitchT=0
SIP-9919785551212  numPSSGlitch=0
SIP-9919785551212  silenceP=0
SIP-9919785551212  termToneDetT=0
SIP-9919785551212  noiseTH=1000
SIP-9919785551212  actTh=32000

//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low 
Volume as Voice,' this call is handled accordingly

135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus 
post OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, 
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with 
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239

Problemi comuni

Nessun CPA inviato dal gateway a UCCX

Dopo la connessione della chiamata al chiamante PSTN, il gateway non invia alcun messaggio a UCCX per indicare che la chiamata è stata completata e che ne è risultato uno (voce in diretta, occupato, segreteria telefonica e così via). Verificare che la versione IOS sul gateway supporti CPA. Esaminare il gateway per verificare che CPA funzioni correttamente.

La chiamata non viene reindirizzata a UCCX dopo il rilevamento della voce in tempo reale

Verificare che il gateway disponga di un dial-peer corrispondente al numero di chiamata del trigger (DN) UCCX assegnato alla campagna. Verificare che una chiamata dal gateway possa indirizzare a tale punto/trigger di routing CTI in CUCM.

Tentativi non composti

Analogamente ai callback in Anteprima chiamata in uscita, se le chiamate che ricevono RNA o sono occupate non vengono ripetute, verificare che i record siano contrassegnati correttamente come Riprova nella tabella Elenco di composizione. Verificare dai registri MIVR che il tentativo di chiamata venga eseguito al callback specificato o all'ora specificata per i nuovi tentativi.

Il protocollo DTMF non funziona se collegato allo script IVR

Verificare che il protocollo DTMF sia negoziato correttamente tra CUCM e il gateway e che i dial-peer denominati corrispondano (il dial-peer 0 non contiene la configurazione del relay DTMF). UCCX supporta solo DTMF fuori banda tramite JTAPI, quindi alcuni tipi di gateway e flussi di chiamate potrebbero richiedere un Media Termination Point (MTP) da richiamare per completare l'interoperabilità DTMF. Esaminare il gateway per verificare che il gateway e CUCM elaborino correttamente le richieste e la negoziazione DTMF.

Informazioni correlate

• Documentazione e supporto tecnico – Cisco Systems