Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Problem

Lösung

Einführung

Dieses Dokument beschreibt ein häufig auftretendes Verzögerungsszenario beim Abrufen einer ersten Eingabeaufforderung, die im Allgemeinen eine willkommene WAV-Datei in einem umfassenden cvp-Anruffluss ist.

Voraussetzungen

Anforderungen

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

- Cisco Unified Contact Center Enterprise (UCCE)

- Cisco Unified Customer Voice Portal (CVP)

- Cisco IOS- und VXML-Gateways

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

- Cisco Unified Customer Voice Portal (CVP) Version 11.X

- Cisco IOS Gateway mit Cisco IOS Software Train 15.4(x)M als Eingangs-Gateway

- VXML-Gateway, das auf demselben Eingangs-Gateway ausgeführt wird

Problem

Wenn der Kunde anruft, ertönt eine Stille von 2 Sekunden, nach der die IVR-Eingabeaufforderung abgespielt wird. Die hier erläuterten CVP- und VXML-Gateway-Protokolle zeigen, dass die Verzögerung darin besteht, dass CVP mehr als zwei Sekunden benötigt, um auf die vom VXML-Gateway generierte HTTP-Ping- und HTTP-NEW_CALL-Anforderung zu reagieren.

Das VXML-Gateway erstellt HTTP-PING-Nachrichten, die für den CVP-Anrufserver unter der Adresse "16:11:31.292" bestimmt sind.

16:11:31.292: //199995//HTTPC:/httpc_write_stream: Client write buffer fd(0):

GET /cvp/VBServlet?MSG_TYPE=PING&CALL_DNIS=77777777771319&CALL_ANI=sip:xxx-xxx-xxxx@X.X.X.X:5060&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=C350CF8000010000000003BD9663630E&CALL_LEGID=C350CF8000010000000003BD9663630E-1448554499804567@X.X.X.X&CALL_UUI=&VERSION=CVP_10_5_1_0_0_0_189 HTTP/1.1

CVP antwortet mit "16:11:32.452" zurück zum PING, wobei der Zeitunterschied mehr als eine Sekunde beträgt.

16:11:32.452: processing server rsp msg: msg(212BBA48)URL: http://X.X.X.X:8000/cvp/VBServlet?MSG_TYPE=PING&CALL_DNIS=77777777771319&CALL_ANI=sip:4692551000@X.X.X.X:5060

Diese Antwort veranlasst das VXML-Gateway, jetzt eine HTTP NEW CALL-Anfrage zu erstellen, die sich bei "16:11:33.064" befindet.

16:11:33.064: //199995//HTTPC:/httpc_write_stream: Client write buffer fd(0):

GET /cvp/VBServlet?MSG_TYPE=CALL_NEW&CALL_DNIS=77777777771319&CALL_UUI=&CALL_ANI=sip:xxx-xxx-xxxx@X.X.X.X:5060&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=C350CF8000010000000003BD9663630E&ERROR_CODE=0 HTTP/1.1

CVP antwortet auf diese Anfrage um "16:11:34.112", wobei die Zeitdifferenz erneut 1 Sekunde oder mehr beträgt.

16:11:34.112: processing server rsp msg: msg(212BBC48)URL: http://X.X.X.X:8000/cvp/VBServlet?MSG_TYPE=CALL_NEW&CALL_DNIS=77777777771319&CALL_UUI=&CALL_ANI=sip:xxx-xxx-xxxx@X.X.X.X:5060&RECOVERY_VXML=flash:recovery.vxml

Dieser Austausch von HTTP-Ping , HTTP NEW Call Request und Antwort vom CVP dauert mehr als zwei Sekunden, was der Anrufer als Stille erlebt.

Lösung

Der Grund, warum der CVP-Server eine Verzögerung bei der Reaktion hat, ist der Tomcat-Prozess, bei dem es einige Zeit dauert, bis er eine TCP-Verbindung aufbaut und Pakete auf jeweils 590 Byte segmentiert. Um diese Bedingung auf dem VXML-Gateway zu beheben, konfigurieren Sie den Befehl "ip tcp mss 1500".

Hinweis: TDieses Problem wird unter dem Fehler "CSCuq07550 - CVP 10.0 tomcat delay when VxML gateway in a different subnet" (CSCuq07550 - CVP 10.0 tomcat verzögert, wenn sich das VxML-Gateway in einem anderen Subnetz befindet) nachverfolgt.