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

Introduction

Ce document décrit un problème rencontré lors de l'utilisation du flux d'appels complet CVP avec la fonctionnalité de connexion de transfert d'AT&T ( DTMF *8).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• CVP version 8.5
• Gestionnaire de contacts intelligent (ICM)
• Services de connexion de transfert AT&T

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• ICM 8.5
• CVP 8.5
• CUBE version 151-3.T4
• Connexion de transfert AT&T

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. If your network is live, make sure that you understand the potential impact of any command.

Symptômes

Si vous passez un appel et que celui-ci est acheminé vers Cisco Unified Contact Center Enterprise (UCCE) via CVP, l'appel est renvoyé vers un numéro externe sur le réseau AT&T (service de transfert de connexion). Lorsque le problème se produit, vous entendez ces invites d'AT&T :

Veuillez patienter

Nous sommes désolés que votre appel n'ait pas pu aboutir. Veuillez réessayer d'appeler

Description de la cause/du problème

Dans un flux d'appels CVP complet, un appel est reçu sur CVP, CVP reçoit l'étiquette DTM *8 suivie de 500 millisecondes (MS) en pause et du numéro 1800. CVP envoie le DTMF au CUBE (Cisco Unified Border Element) et la passerelle transmet les chiffres au réseau AT&T. Cependant, l'appel n'est pas transféré et le client entend Nous sommes désolés que votre appel ne puisse pas être terminé. Veuillez réessayer d'appeler.

Étape 1. L’appelant passe un appel à partir du réseau téléphonique public commuté (RTPC).

Étape 2. La passerelle d'entrée (IGW) reçoit l'appel du RTPC, dans ce cas CUBE est la passerelle d'entrée.

Étape 3. L’IGW envoie un message SIP INVITE à CVP via un serveur proxy SIP.

Étape 4. CVP envoie une demande de nouvel appel à ICM.

Étape 5. ICM exécute le script de routage et envoie une étiquette VRU (Voice Response Unit) au CVP.

Étape 6. CVP envoie un message SIP INVITE via le serveur proxy SIP à la passerelle VXML (VXML GW).

Étape 7. La passerelle VXML exécute le script de démarrage et envoie une requête HTTP à CVP.

Étape 8. CVP envoie une instruction de requête à ICM.

Étape 9. ICM annule la branche VRU et envoie l’étiquette DTMF au CVP. CVP termine la branche VRU avec la passerelle VXML.

Étape 10. CVP envoie la DTMF à IGW (CUBE).

Étape 11. La sortie IGW (CUBE) envoie une impulsion DTMF au réseau AT&T.

Étape 12. Le réseau AT&T envoie le message DTMF **7 Le réseau n’a pas reçu le numéro composé ou ne peut pas le reconnaître. Pour les scénarios de bon cas CVP envoie DTMF **6 et le client entend s'il vous plaît attendre après S'il vous plaît attendre.

Vérifier

Étape 1 : configuration du protocole CVP

Dans le fichier sip.properties sous le dossier de configuration, la fonctionnalité SIP.ExternalTransferWait doit être ajoutée et définie sur 1000 (1 seconde). Ensuite, redémarrez le serveur d'appels CVP.

Étape 2. Journaux du serveur d’appels CVP

Collectez les traces CVP avec Select com.dynamicsoft.DsLibs.DsUALibs défini au niveau Debug.

À partir des journaux CVP, vérifiez que CVP envoie des messages d'informations SIP à la passerelle d'entrée (CUBE) pour chaque DTMF :

Par exemple, la tonalité « * » envoyée à IGW (CUBE) par 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

Étape 3 : collecte des journaux de passerelle d'entrée (CUBE)

debug ccsip message

debug voip rtp session name event

Le relais DTMF négocié sur la branche RTPC (AT&T) est RTP-NTE avec une charge utile de type 100.
Le relais DTMF négocié sur la branche CVP est sip-info et rtp-net en utilisant le type de données utiles 101.

Les journaux indiquent que la passerelle d'entrée (CUBE) reçoit tous les chiffres du CVP à l'aide du message d'information SIP et l'envoie au RTPC (AT&T)

Par exemple, CUBE envoie le chiffre 7 au réseau RTPC / 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

Étape 4 : collecte de la capture de paquets sur la passerelle et confirmation des exigences AT&T

Exigences:

Délai inter-chiffres = 3 secondes

Pour la signalisation DTMF vers le réseau, le VRU de la partie de redirection (CVP dans ce cas et CUBE) doit envoyer des tonalités DTMF avec au moins 80 ms de durée de chiffre et 80 ms de silence inter-chiffres.

Une pause d'au moins 350 ms doit être appliquée entre le *T et le numéro de redirection ou le code SD. (Les limites inférieure et supérieure sont comprises entre 300 ms et 11 sec.)

Analyse de capture de paquets

Dans les bons appels, après que CUBE ait envoyé le dernier chiffre à AT&T, AT&T envoie le DTMF "* 6" autour de 500 MS

Intervalle entre les chiffres envoyés à AT&T = 200 MS

Heure à partir de DTMF *8 est envoyé et le premier chiffre = 400 MS

Durée de l'événement - Longueur du chiffre = 100 MS

Appel incorrect :

AT&T envoie la DTMF **7, 6 secondes plus tard après avoir reçu le dernier chiffre

Intervalle entre les chiffres envoyés à AT&T = 200 MS

Heure à partir de DTMF *8 est envoyé et le premier chiffre = 400 MS

Durée de l'événement - Longueur du chiffre = 100 MS

Il n'y a aucune différence entre les appels bons et les appels mauvais dans la capture de paquets.

Résolution

Puisque les DTMF envoyés à AT&T pour les appels bons et mauvais ont les mêmes propriétés et minuteurs, mais dans certains scénarios les DTMF ne sont pas reconnus, des tests sont effectués en ajoutant des pauses avant un groupe spécifique de chiffres et la combinaison qui résout le problème est : DTMF*8,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. Ceci est modifié dans le script ICM.