This document describes how to troubleshoot Cisco Customer Voice Portal (CVP) whisper announcement failing intermittently to the agent with delay until default timeout expires.
Contributed by Ricardo Mancera and Linda Mordosky, Cisco TAC Engineers.
Cisco recommends that you have knowledge of these topics:
Session Internet Protocol (SIP)
Cisco Unified Contact Center Enterprise (UCCE)
Cisco Unified Communications Manager (CUCM)
Skinny Client Control Protocol (SCCP)
The information in this document is based on these software versions:
Cisco CVP 9.0(1)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
You can find the 15 seconds timeout configuration in ringtone.tcl and UCCE fail-safe timeout (default 20 sec) modifiable in Peripheral Gateway (PG) Explorer for the Voice Respnse Unit (VRU) pim adding /WHSTMOUT <value in seconds> in the Configuration Parameters, please note the Unified CCE Whisper Announcement fail-safe timeout value should be equal to or (preferably) greater than the maximum Whisper Announcement play time setting in Unified CVP. Otherwise, Whisper Announcement play time in Unified CCE reports are under-reported.
This is what the CCM Service Parameter Port Received Timer after Call Connection [default value = 500ms ] for port Time-out says under CUCM:
This parameter determines the amount of time that CUCM waits to receive the audio/video/data port from the SCCP device or Media Termination Point (MTP) after the call is connected. If CUCM fails to receive the video port before the time specified in this parameter elapses, the call is initially established with two-way audio only. Two-way video may be established after another offer/answer transaction gets completed. If CUCM fails to receive the audio port before the time specified in this timer expires, CUCM attempts another offer/answer transaction to establish a two-way media path for both audio and video.
The CVP log for the Whisper invite shows dummy port 4000 in the App-Info. Agent cannot control the call during that time and Unified Contact Center Enterprise ( UCCE) cannot accurately calculate the whisper length thus skewing report data.
To avoid this problem Cisco recommendation is to increase Port Received Timer After Call Connection in CUCM Call Manager Service Parameters to a few seconds, i.e. 2000 ms. This would avoid CUCM sending TCP 4000 sendonly (a dummy port) in SDP.
It will not affect call in progress just calls that come inbound after the change, you can save it and apply it immediately.
If the offerer wishes to only send media on a stream to its peer, it MUST mark the stream as sendonly with the "a=sendonly" attribute. We refer to a stream as being marked with a certain direction if a direction attribute was present as either a media stream attribute or
// CVP set up the whisper call leg to VXML GW Ringtone.tcl 5121216: 10.1.1.24: Mar 19 2014 11:18:55.118 -0400: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: Sending Message (NB): INVITE sip:email@example.com:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.1.1.24:5060;branch=z9hG4bKiqLKy1OaNCMgZoZTxHa0lA~~20629403 Max-Forwards: 70 To: <sip:firstname.lastname@example.org:5060;transport=tcp> From: <sip:CVP@10.1.1.24:5060;transport=tcp>;tag=dsc96857bf Call-ID: DAEC7B8E100001447E771C460A010118email@example.com CSeq: 1 INVITE Content-Length: 416 Contact: <sip:CVP@10.1.1.24:5060;transport=tcp> Expires: 60 User-Agent: CVP 9.0 (1) Build-670 Content-Type: application/sdp Cisco-Guid: 2027159669-2930774499-2591376387-2814473344 Cisco-Gucid: 78D40075AEB011E39A754403A7C17480 App-Info: <10.1.1.24:8000:8443>;whisper=http://mediaserver:7000/CVP/en-us/../audio/whisper/Beep1.wav;port=4000
If a stream is offered with a unicast address, the answer for that stream MUST contain a unicast address. The media type of the stream in the answer MUST match that of the offer.
If a stream is offered as sendonly, the corresponding stream MUST be marked as recvonly or inactive in the answer. If a media stream is listed as recvonly in the offer, the answer MUST be marked as sendonly or inactive in the answer. If an offered media stream is listed as sendrecv (or if there is no direction attribute at the media or session level, in which case the stream is sendrecv by default), the corresponding stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive. If an offered media stream is listed as inactive, it MUST be marked as inactive in the answer.
Note: Useful parameters can be found by reading the ringtone.tcl file.