Contenu

Introduction

Conditions préalables

Conditions requises

Composants utilisés

Symptômes

Cause/description du problème

Vérifier

Résolution

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

Composants utilisés

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.