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

Einführung

In diesem Dokument wird ein Problem beschrieben, das bei der Verwendung des umfassenden CVP-Anrufflusses mit der Übertragungs-Connect-Funktion von AT&T ( DTMF *8) auftritt.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• CVP Version 8.5
• Intelligent Contact Manager (ICM)
• AT&T Transfer Connect-Services

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• ICM 8.5
• CVP 8,5
• CUBE Version 151-3.T4
• AT&T Transfer Connect

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Symptome

Sie tätigen einen Anruf und der Anruf wird über CVP an Cisco Unified Contact Center Enterprise (UCCE) weitergeleitet. Der Anruf wird an eine externe Nummer im AT&T-Netzwerk (Transfer Connect-Service) zurückgeleitet. Wenn das Problem auftritt, hören Sie folgende Aufforderungen von AT&T:

Bitte warten

Es tut uns leid, dass Ihr Anruf nicht abgeschlossen werden kann. Versuchen Sie es erneut.

Ursache/Problembeschreibung

In einem umfassenden CVP-Anruffluss wird ein Anruf auf dem CVP empfangen, das CVP erhält das DTM *8-Label, gefolgt von einer Pause von 500 Millisekunden (MS) und einer 1800-Nummer. CVP sendet das DTMF an das Cisco Unified Border Element (CUBE) und das Gateway sendet die Ziffern an das AT&T-Netzwerk. Der Anruf wird jedoch nicht weitergeleitet, und der Kunde hört, dass Ihr Anruf leider nicht abgeschlossen werden kann. Versuchen Sie es erneut.

Schritt 1: Der Anrufer ruft über das öffentliche Telefonnetz (Public Switched Telefone Network, PSTN) an.

Schritt 2: Das Ingress Gateway (IGW) empfängt den Anruf vom PSTN, in diesem Fall ist CUBE das Eingangs-Gateway.

Schritt 3: Das IGW sendet eine SIP-INVITE-Nachricht an CVP über einen SIP-Proxyserver.

Schritt 4: CVP sendet eine Anforderung für einen neuen Anruf an den ICM.

Schritt 5: Das ICM führt das Routing-Skript aus und sendet ein VRU-Label an CVP.

Schritt 6: CVP sendet eine SIP-INVITE-Nachricht über den SIP-Proxyserver an das Voice XML Gateway (VXML GW).

Schritt 7: Der VXML-GW führt das Bootstrap-Skript aus und sendet eine HTTP-Anfrage an CVP.

Schritt 8: CVP sendet eine Anforderungsanweisung an den ICM.

Schritt 9: Der ICM bricht den VRU-Abschnitt ab und sendet das DTMF-Label an CVP. CVP terminiert den VRU-Abschnitt mit dem VXML GW.

Schritt 10: CVP sendet DTMF an IGW (CUBE).

Schritt 11: Das IGW (CUBE) sendet die DTMF an das AT&T-Netzwerk.

Schritt 12: Das AT&T-Netzwerk sendet DTMF **7 Netzwerk hat die gewählte Nummer nicht empfangen oder kann sie nicht erkennen. Für den Fall, dass CVP DTMF **6 sendet und der Kunde hört, warten Sie bitte, nachdem Sie gewartet haben.

Überprüfen

Schritt 1: CVP-Konfiguration.

In der Datei sip.properties unter dem Konfigurationsordner muss die SIP.ExternalTransferWait-Funktion hinzugefügt und auf 1000 (1 Sekunde) festgelegt werden. Nach diesem Neustart wird der CVP-Anrufserver gestartet.

Schritt 2: CVP-Anrufserverprotokolle.

Erfassen Sie CVP-Ablaufverfolgungen mit Select com.dynamicsoft.DsLibs.DsUALibs, der auf die Debug-Ebene festgelegt ist.

Aus den CVP-Protokollen wird bestätigt, dass CVP für jede DTMF SIP-Informationsmeldungen an das Eingangs-Gateway (CUBE) sendet:

Beispiel: Der "*"-Ton wird vom CVP an IGW (CUBE) gesendet.

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

Schritt 3: Erfassung von Eingangs-Gateway-Protokollen (CUBE).

debuggen ccsip meldung

debuggen voip rtp session name event

Das DTMF-Relay, das auf der PSTN-Strecke (AT&T) ausgehandelt wird, ist RTP-NTE unter Verwendung des Payload-Typs 100.
Das auf dem CVP-Bein ausgehandelte DTMF-Relay ist sip-info und rtp-nte mit Payload vom Typ 101.

Aus den Protokollen kann erkennbar werden, dass das Eingangs-Gateway (CUBE) mithilfe der SIP-Informationsmeldung alle Ziffern vom CVP empfängt und sie an das PSTN (AT&T) sendet.

Beispiel: CUBE sendet Ziffer 7 an das PSTN/AT&T-Netzwerk.

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

Schritt 4: Erfassen Sie die Paketerfassung auf dem Gateway, und bestätigen Sie die AT&T-Anforderungen.

Anforderungen:

Timeout zwischen Ziffern = 3 Sekunden

Für die DTMF-Signalisierung an das Netzwerk muss das VRU (in diesem Fall CVP und CUBE) des Weiterleitungsunternehmens DTMF-Töne mit mindestens 80 ms Zifferndauer und 80 ms Zwischenstufe senden.

Zwischen der *T und der Umleitungsnummer bzw. dem SD-Code muss eine Pause von mindestens 350 ms angewendet werden. (Die untere und obere Grenze beträgt 300 ms - 11 Sek.)

Paketerfassungsanalyse

Nachdem CUBE die letzte Ziffer an AT&T gesendet hat, sendet AT&T bei guten Anrufen die DTMF "* 6" um 500 MS.

Zeit zwischen den an AT&T gesendeten Ziffern = 200 MS

Zeit aus DTMF *8 wird gesendet und die erste Ziffer = 400 MS

Veranstaltungsdauer - Ziffernlänge = 100 MS

Schlechter Anruf:

AT&T sendet die DTMF **7, 6 Sekunden später, nachdem die letzte Ziffer empfangen wurde

Zeit zwischen den an AT&T gesendeten Ziffern = 200 MS

Zeit aus DTMF *8 wird gesendet und die erste Ziffer = 400 MS

Veranstaltungsdauer - Ziffernlänge = 100 MS

Es besteht kein Unterschied zwischen guten und schlechten Anrufen bei der Paketerfassung.

Auflösung

Da die DTMFs, die für die guten und schlechten Anrufe an AT&T gesendet werden, die gleichen Eigenschaften und Timer haben, aber in einigen Fällen die DTMF-Funktion nicht erkannt wird, werden Tests durchgeführt, um Pausen vor bestimmten Zifferngruppen hinzuzufügen. Die Kombination, die das Problem löst, ist :DTMF*8,,,, 1, 8YY, NXX, XXXX, XXXX,". Dies wird im ICM-Skript geändert.