Introduction
Ce document décrit un problème rencontré en utilisant CVP l'écoulement que complet d'appel avec le transfert connectent la caractéristique d'AT&T (DTMF *8).
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Version 8.5 CVP
- Gestionnaire de contacts intelligent (missile aux performances améliorées)
- AT&T transfèrent connectent des services
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Missile aux performances améliorées 8.5
- CVP 8.5
- Version 151-3.T4 de CUBE
- AT&T transfèrent se connectent
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Symptômes
Vous placez un appel et l'appel est conduit au Cisco Unified Contact Center Enterprise (UCCE) par l'intermédiaire de CVP, l'appel est transféré de nouveau à un nombre externe sur le réseau d'AT&T (le transfert connecte le service). Quand le problème se produit vous entendez ces demandes d'AT&T :
Attendez s'il vous plaît
Nous sommes désolés que votre appel ne puisse pas être terminé. Veuillez essayer votre appel de nouveau
Cause/description du problème
Dans un écoulement complet d'appel CVP, un appel est reçu sur CVP, CVP reçoit l'étiquette DTM *8 suivie de 500 millisecondes (MS) a fait une pause et 1800 nombres. CVP envoie le DTMF au Logiciel Cisco Unified Border Element (CUBE) et la passerelle palpitent les chiffres au réseau d'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 essayer votre appel de nouveau.
Étape 1. L'appelant place un appel du téléphone commuté par public Networ (PSTN).
Étape 2. La passerelle d'entrée (IGW) reçoit l'appel du PSTN, CUBENT dans ce cas est la passerelle d'entrée.
Étape 3. L'IGW envoie un message de SIP INVITE à CVP par l'intermédiaire d'un serveur proxy SIP.
Étape 4. CVP envoie une nouvelle demande d'appel au missile aux performances améliorées.
Étape 5. Le missile aux performances améliorées exécute le script de routage et envoie une étiquette de l'unité de réponse vocale (VRU) à CVP.
Étape 6. CVP envoie un message de SIP INVITE par l'intermédiaire du serveur proxy SIP à la passerelle de la Voix XML (VXML gw).
Étape 7. Le VXML gw exécute le script de bootstrap et envoie une demande de HTTP à CVP.
Étape 8. CVP envoie une instruction de demande au missile aux performances améliorées.
Étape 9. Le missile aux performances améliorées annule le tronçon VRU et envoie l'étiquette DTMF à CVP. CVP termine le tronçon VRU avec le VXML gw.
Étape 10. CVP envoie le DTMF à IGW (CUBE).
Étape 11. IGW (CUBE) palpite le DTMF au réseau d'AT&T.
Étape 12. Le réseau d'AT&T envoie le réseau DTMF **7 n'a pas reçu ou ne peut pas identifier le numéro composé. Pour de bons scénarios de cas CVP envoie DTMF **6 et client entend s'il vous plaît pour se tenir après qu'attendiez s'il vous plaît.
Vérifiez
Étape 1. Configuration CVP.
Sur le fichier sip.properties sous le répertoire de configuration la caractéristique SIP.ExternalTransferWait doit être ajoutée et placée à 1000 (1 seconde). Après cette reprise le serveur d'appel CVP.
Étape 2. Journaux du serveur d'appel CVP.
Collectez les suivis CVP avec le positionnement choisi com.dynamicsoft.DsLibs.DsUALibs pour débugger de niveau.
De CVP les logs confirment que CVP envoie des messages de l'information de SIP à la passerelle d'entrée (CUBE) pour chaque DTMF :
Par exemple « * » la tonalité a envoyé à IGW (CUBE) de 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. Collectez les logs de passerelle d'entrée (CUBE).
mettez au point le message de ccsip
événement de nom de session de debug voip rtp
Le relais de DTMF négocié sur le tronçon PSTN (AT&T) est RTP-NTE utilisant le type 100 de charge utile.
Le relais de DTMF négocié sur le tronçon CVP est sip-information et rtp-nte utilisant le type 101 de charge utile.
Des logs, il peut voir que la passerelle d'entrée (CUBE) reçoit tous les chiffres du CVP utilisant le message de l'information de SIP et l'envoie au PSTN (AT&T)
Par exemple CUBEZ envoyer le chiffre 7 au réseau 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
Étape 4. Collectez la capture de paquet sur la passerelle et confirmez les conditions requises d'AT&T.
Conditions requises :
temps d'Inter-chiffre = 3 secondes
Pour DTMF signalant au réseau, le VRU de l'interlocuteur de réorientation (CVP dans ce cas et CUBE) doit envoyer des tonalités DTMF avec au moins 80ms de la durée de chiffre et 80ms de silence d'inter-chiffre.
Une pause au moins de 350ms doit être appliquée entre le *T et le nombre de redirection ou le code écart-type. (Les limites inférieures et supérieures sont 300ms - 11sec.)
Analyse de capture de paquet
Dans les bons appels, après que le CUBE envoie le dernier chiffre à AT&T, AT&T envoie au DTMF « * 6" environ 500 MS
Le temps entre les chiffres a envoyé à AT&T = 200 MS
Le temps de DTMF *8 est envoyé et le premier chiffre = 400 MS
Durée d'événement – Longueur de chiffre = 100 MS
Mauvais appel :
AT&T envoie le DTMF **7, 6 secondes plus tard ensuite ayant reçu le dernier chiffre
Le temps entre les chiffres a envoyé à AT&T = 200 MS
Le temps de DTMF *8 est envoyé et le premier chiffre = 400 MS
Durée d'événement – Longueur de chiffre = 100 MS
Il n'y a aucune différence entre appels les bons et du mauvais dans la capture de paquet.
Résolution
Puisque le DTMFs envoyé à AT&T pour les bons et mauvais appels ont les mêmes propriétés et temporisateurs, mais dans quelques scénarios les DTMF ne sont pas identifiés, des tests sont faits ajoutant des pauses avant que le groupe spécifique des chiffres et de la combinaison qui résout le problème soit : . Ceci est changé dans le script ICM.