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

Einleitung

Dieses Dokument beschreibt ein Problem bei der Verwendung des umfassenden CVP-Anrufflusses mit der Transferverbindungsfunktion von AT&T ( DTMF *8).

Voraussetzungen

Anforderungen

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

• CVP-Version 8.5
• Intelligenter Kontakt-Manager (ICM)
• AT&T Verbindungs-Services übertragen

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• ICM 8.5
• CVP 8,5
• CUBE-Version 151-3.T4
• AT&T Verbindung übertragen

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Symptome

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

Bitte warten

Ihr Anruf kann leider nicht beendet werden. Versuchen Sie es erneut.

Ursache/Problembeschreibung

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

Schritt 1: Der Anrufer tätigt einen Anruf vom öffentlichen Telefonnetz (PSTN).

Schritt 2: Das Eingangs-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 über einen SIP-Proxyserver an CVP.

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

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

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

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

Schritt 8: CVP sendet eine Request Instruction an das ICM.

Schritt 9: 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 Impulse für die DTMF an das AT&T-Netzwerk.

Schritt 12: Das AT&T-Netzwerk sendet DTMF **7 Das Netzwerk hat die gewählte Nummer nicht empfangen oder kann sie nicht erkennen. In bestimmten Szenarien sendet CVP DTMF **6, und die Kundenanhörungen werden nach Bitte warten gehalten.

Überprüfung

Schritt 1: CVP-Konfiguration.

In der Datei sip.properties im Konfigurationsordner muss die Funktion SIP.ExternalTransferWait hinzugefügt und auf 1000 (1 Sekunde) festgelegt werden. Starten Sie anschließend den CVP-Anrufserver neu.

Schritt 2: CVP-Anrufserver-Protokolle.

Sammeln Sie CVP-Ablaufverfolgungen, indem Sie Select com.dynamicsoft.DsLibs.DsUALibs auf die Debug-Ebene setzen.

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: Erfassen der Eingangs-Gateway-Protokolle (CUBE)

debug ccsip-Meldung

debug voip rtp session name event

Das auf der PSTN-Strecke (AT&T) ausgehandelte DTMF-Relay ist RTP-NTE mit dem Payload-Typ 100.
Das auf der CVP-Strecke ausgehandelte DTMF-Relay lautet sip-info und rtp-net und verwendet die Nutzlast vom Typ 101.

Aus den Protokollen geht hervor, dass das Eingangs-Gateway (CUBE) alle Ziffern des CVP mithilfe einer SIP-Info-Nachricht empfängt und 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: Sammeln Sie die Paketerfassung am Gateway, und bestätigen Sie die AT&T-Anforderungen.

Anforderungen:

Zeitüberschreitung zwischen zwei Stellen = 3 Sekunden

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

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

Paketerfassungsanalyse

Bei guten Anrufen sendet CUBE nach dem Senden der letzten Ziffer an AT&T die DTMF "* 6" um die 500 MS.

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

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

Dauer der Veranstaltung - Ziffernlänge = 100 MS

Ungültiger 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 von DTMF *8 wird gesendet und die erste Ziffer = 400 MS

Dauer der Veranstaltung - Ziffernlänge = 100 MS

Bei der Paketerfassung besteht kein Unterschied zwischen guten und schlechten Anrufen.

Auflösung

Da die DTMFs, die an AT&T für die guten und schlechten Anrufe gesendet werden, dieselben Eigenschaften und Timer haben, aber in einigen Szenarien die DTMF nicht erkannt werden, werden Tests durchgeführt, bei denen Pausen vor einer bestimmten Gruppe von Ziffern hinzugefügt werden. Die Kombination, die das Problem löst, ist: DTMF*8,,,,,1,,8YY,,,,NXX,,XXXX,,,,,,". Dies wird im ICM-Skript geändert.