AT&T Transfer Connect Customer Voice Portal (CVP) e Intelligent Contact Management (ICM)

Introduzione

Questo documento descrive un problema incontrato quando si usa il flusso di chiamata completo CVP con la funzione di connessione trasferimento di AT&T ( DTMF *8).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• CVP versione 8,5
• Intelligent Contact Manager (ICM)
• Servizi di connessione trasferimento AT&T

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• ICM 8.5
• CVP 8,5
• CUBE versione 151-3.T4
• Connessione trasferimento AT&T

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.

Sintomi

Si effettua una chiamata e la chiamata viene instradata a Cisco Unified Contact Center Enterprise (UCCE) tramite CVP, la chiamata viene ritrasferita a un numero esterno sulla rete AT&T (servizio di connessione trasferimento). Quando si verifica il problema, AT&T chiede all'utente:

Attendere

Siamo spiacenti che la tua chiamata non possa essere completata. Riprovare

Descrizione causa/problema

In un flusso di chiamata completo CVP, viene ricevuta una chiamata su CVP, CVP riceve l'etichetta DTM *8 seguita da 500 millisecondi (MS) in pausa e da 1800 numeri. Il CVP invia il DTMF al CUBO (Cisco Unified Border Element) e il gateway esce tirando le cifre verso la rete AT&T. Tuttavia, la chiamata non viene trasferita e il cliente viene informato che non è possibile completare la chiamata. Riprovare.

Passaggio 1. Il chiamante effettua una chiamata dalla PSTN (Public Switched Telephone Network).

Passaggio 2. Il gateway in ingresso (IGW) riceve la chiamata dalla PSTN, in questo caso CUBE è il gateway in ingresso.

Passaggio 3. L'IGW invia un messaggio SIP INVITE al CVP tramite un server proxy SIP.

Passaggio 4. Il CVP invia una nuova richiesta di chiamata all'ICM.

Passaggio 5. L'ICM esegue lo script di routing e invia un'etichetta VRU (Voice Response Unit) al CVP.

Passaggio 6. CVP invia un messaggio SIP INVITE tramite server proxy SIP a Voice XML Gateway (VXML GW).

Passaggio 7. Il GW VXML esegue lo script bootstrap e invia una richiesta HTTP a CVP.

Passaggio 8. Il CVP invia una richiesta di istruzione all'ICM.

Passaggio 9. L'ICM annulla il segmento VRU e invia l'etichetta DTMF al CVP. Il CVP termina il segmento VRU con il VXML GW.

Passaggio 10. Il CVP invia il DTMF a IGW (CUBE).

Passaggio 11. L'uscita IGW (CUBE) allunga il DTMF alla rete AT&T.

Passaggio 12. La rete AT&T invia un segnale DTMF **7. La rete non ha ricevuto o non è in grado di riconoscere il numero composto. Per scenari ottimali, il CVP invia DTMF **6 e il cliente può ascoltare attendere dopo. Attendere.

Verifica

Passaggio 1. Configurazione CVP.

Sul file sip.properties nella cartella configuration è necessario aggiungere la funzionalità SIP.ExternalTransferWait e impostarla su 1000 (1 secondo). Dopo questo riavvio, il server di chiamata CVP.

Passaggio 2. Registri del server di chiamata CVP.

Raccogliere le tracce CVP con Select com.dynamicsoft.DsLibs.DsUALibs impostato sul livello Debug.

Dai log CVP, confermare che il CVP invia messaggi informativi SIP al gateway in ingresso (CUBE) per ciascun DTMF:

Ad esempio, il tono "*" inviato a IGW (CUBE) da CVP.

264788: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %CVP_8_5_SIP-7-CALL:  {Thrd=pool-1-thread-197-SIP-61173} 409D1D04-4D6B11E3-8E94E199-7280FCFD: Starting an external transfer with label: DTMF*8,,,,,18YYNXXXXXX
2059160: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection:  Sending Message (NB): INFO sip:5123809981@10.1.2.2:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.1.1:5060;branch=z9hG4bKa74MS0n9A4oRWinVIAjXSA~~47394
Max-Forwards: 70
To: <sip:5123809981@10.1.2.2>;tag=658DC428-11DA
From: <sip:5008007435000@10.1.1.11>;tag=dsefb53fdb
Call-ID: 409D1D04-4D6B11E3-8E94E199-7280FCFD@10.1.2.2
CSeq: 1 INFO
Content-Length: 26
Contact: <sip:10.1.1.1:5060;transport=udp>
Content-Type: application/dtmf-relay
Signal=*    
Duration=100

Passaggio 3. Raccolta dei log del gateway in ingresso (CUBE).

messaggio debug ccsip

evento debug voip rtp session name

Il relay DTMF negoziato sul segmento PSTN (AT&T) è RTP-NTE con payload di tipo 100.
Il relay DTMF negoziato sulla gamba CVP è sip-info e rtp-net con payload di tipo 101.

Dai log, si può notare che il gateway in ingresso (CUBE) riceve tutte le cifre dal CVP utilizzando il messaggio info SIP e lo invia alla PSTN (AT&T)

Ad esempio, CIFRA DI INVIO CUBE 7 alla rete PSTN / AT&T

289591: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD4 timestamp 0x2B700
289592: Nov 15 22:20:52.244:          Pt:100    Evt:7       Pkt:0A 00 00  <Snd>>>
289593: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD5 timestamp 0x2B700
289594: Nov 15 22:20:52.244:          Pt:100    Evt:7       Pkt:0A 00 00  <Snd>>>
289595: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD6 timestamp 0x2B700

Passaggio 4. Raccogliere l'acquisizione del pacchetto sul gateway e confermare i requisiti AT&T.

Requisiti:

Timeout tra cifre = 3 secondi

Per la segnalazione DTMF alla rete, la VRU (in questo caso CVP e CUBE) della parte che reindirizza deve inviare toni DTMF con una durata di almeno 80 ms e 80 ms di silenzio tra cifre.

Si deve applicare una pausa di almeno 350 ms tra *T e il numero di reindirizzamento o il codice SD. (I limiti inferiore e superiore sono 300 ms - 11 sec.)

Analisi acquisizione pacchetti

Nelle chiamate corrette, dopo che CUBE invia l'ultima cifra ad AT&T, AT&T invia il DTMF "* 6" a circa 500 MS

Tempo tra le cifre inviate a AT&T = 200 MS

Tempo di invio da DTMF *8 e prima cifra = 400 MS

Durata evento - Lunghezza cifra = 100 MS

Chiamata non valida:

AT&T invia il segnale DTMF **7, 6 secondi dopo aver ricevuto l'ultima cifra

Tempo tra le cifre inviate a AT&T = 200 MS

Tempo di invio da DTMF *8 e prima cifra = 400 MS

Durata evento - Lunghezza cifra = 100 MS

Non c'è differenza tra le chiamate buone e quelle cattive nell'acquisizione dei pacchetti.

Risoluzione

Poiché i DTMF inviati ad AT&T per le chiamate buone e cattive hanno le stesse proprietà e timer, ma in alcuni scenari i DTMF non vengono riconosciuti, i test vengono eseguiti aggiungendo pause prima di un gruppo specifico di cifre e la combinazione che risolve il problema è :DTMF*8,,,,1,,8YY,,,NXX,,XXXX,,,". Questa condizione viene modificata nello script ICM.