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

Introduction

This document describes a problem encountered when using CVP comprehensive call flow with transfer connect feature of AT&T ( DTMF *8).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• CVP Version 8.5
• Intelligent Contact Manager (ICM)
• AT&T Transfer connect services

Components Used

The information in this document is based on these software and hardware versions:

• ICM 8.5
• CVP 8.5
• CUBE version 151-3.T4
• AT&T Transfer connect

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.

Symptoms

You place a call and the call is routed to Cisco Unified Contact Center Enterprise (UCCE) via CVP, the call is transferred back to an external number on AT&T network (Transfer connects service). When the problem happens you hear these prompts from AT&T:

Please wait

We're sorry your call cannot be completed. Please try your call again

Cause / Problem Description

In a CVP comprehensive call flow, a call is received on CVP, CVP receives the DTM *8 label followed by 500 millisecond (MS) paused and 1800 number. CVP sends the DTMF to the Cisco Unified Border Element (CUBE) and the gateway out pulse the digits to the AT&T network. However, the call is not transferred and the customer hears  We're sorry your call cannot be completed. Please try your call again.

Step 1. The caller places a call from the Public Switched Telephone Networ (PSTN).

Step 2. The Ingress Gateway (IGW) receives the call from the PSTN, in this case CUBE is the Ingress gateway.

Step 3. The IGW sends an SIP INVITE message to CVP via a SIP proxy server.

Step 4. CVP sends a New Call request to the ICM.

Step 5. The ICM executes the routing script and sends a Voice Response Unit (VRU) label to CVP.

Step 6. CVP sends an SIP INVITE message via SIP proxy server to the Voice XML Gateway (VXML GW).

Step 7. The VXML GW executes the bootstrap script and sends an HTTP request to CVP.

Step 8. CVP sends a Request Instruction to the ICM.

Step 9. The ICM cancels the VRU leg and sends the DTMF label to CVP. CVP terminates the VRU leg with the VXML GW.

Step 10. CVP sends the DTMF to IGW (CUBE).

Step 11. IGW (CUBE) out pulses the DTMF to the AT&T Network.

Step 12. AT&T network sends DTMF **7 Network did not receive or cannot recognize dialed number. For good case scenarios CVP sends  DTMF **6 and customer hears please hold after Please wait.

Verify

Step 1. CVP configuration.

On the sip.properties file under the configuration folder the SIP.ExternalTransferWait feature needs to be added and set to 1000 (1 second). After this restart the CVP call server.

Step 2. CVP Call server logs.

Collect CVP traces with Select com.dynamicsoft.DsLibs.DsUALibs set to Debug level.

From the CVP logs confirm that CVP sends SIP info messages to Ingress gateway (CUBE) for each DTMF:

For example the “*” tone sent to IGW (CUBE) from 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

Step 3. Collect Ingress gateway logs (CUBE).

debug ccsip message

debug voip rtp session name event

The DTMF relay negotiated on the PSTN (AT&T) leg is RTP-NTE using payload type 100.
The DTMF relay negotiated on the CVP leg is sip-info and rtp-nte using payload type 101.

From the logs, it can be seen that Ingress gateway (CUBE) receives all the digits from the CVP using SIP info message and send it to the PSTN (AT&T)

For example CUBE sending digit 7 to the PSTN / AT&T network

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

Step 4. Collect Packet capture on the gateway and confirm the AT&T requirements.

Requirements:

Inter-digit time out = 3 seconds

For DTMF signaling to the Network, the Redirecting Party’s VRU (CVP in this case and CUBE) must send DTMF tones with at least 80ms of digit duration and 80ms of inter-digit silence.

A pause of at least 350ms must be applied between the *T and the redirection number or SD code. (The lower and upper bounds are 300ms - 11sec.)

Packet Capture Analysis

In the good calls, after CUBE sends the last digit to AT&T, AT&T sends the DTMF "* 6" around 500 MS

Time between digits sent to AT&T = 200 MS

Time from DTMF *8 is sent and the first digit =  400 MS

Event duration – Digit length = 100 MS

Bad call:

AT&T sends the DTMF **7,  6 seconds later after having received the last digit

Time between digits sent to AT&T = 200 MS

Time from DTMF *8 is sent and the first digit =  400 MS

Event duration – Digit length = 100 MS

There is no difference between the good and bad calls in the packet capture.

Resolution

Since the DTMFs sent to AT&T for the good and bad calls have the same properties and timers, but in some scenarios the DTMF are not recognized, tests are done adding pauses before specific group of digits and the combination which solves the problem is :DTMF*8,,,,,1,,,8YY,,,NXX,,,XXXX,,,". This is changed in the ICM script.