AT&T Transfer Connect客户语音门户(CVP)和智能联系管理(ICM)

简介

本文描述使用AT&T(DTMF *8)的转接连接功能的CVP综合呼叫流时遇到的问题。

先决条件

要求

Cisco 建议您了解以下主题：

• CVP版本8.5
• 智能联系管理器(ICM)
• AT&T传输连接服务

使用的组件

本文档中的信息基于以下软件和硬件版本：

• ICM 8.5
• CVP 8.5
• CUBE版本151-3.T4
• AT&T转接连接

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

症状

您发出呼叫后，呼叫将通过CVP路由到Cisco Unified Contact Center Enterprise(UCCE)，呼叫将转回AT&T网络上的外部号码（转接连接服务）。 出现问题时，您会听到AT&T的以下提示：

请稍候

很抱歉您的通话无法完成。请再次尝试呼叫

原因/问题描述

在CVP综合呼叫流程中，在CVP上收到呼叫，CVP收到DTM *8标签，后跟500毫秒(MS)暂停和1800号码。CVP将DTMF发送到思科统一边界元素(CUBE)，网关将脉冲数字发送到AT&T网络。但是，呼叫未转接，客户听到“很抱歉，您的呼叫无法完成”。请再次尝试呼叫。

步骤1.呼叫方从公共交换电话网(PSTN)发出呼叫。

步骤2.入口网关(IGW)接收来自PSTN的呼叫，在这种情况下，CUBE是入口网关。

步骤3.IGW通过SIP代理服务器向CVP发送SIP INVITE消息。

步骤4. CVP向ICM发送新的呼叫请求。

步骤5. ICM执行路由脚本并向CVP发送语音响应单元(VRU)标签。

步骤6. CVP通过SIP代理服务器向语音XML网关(VXML GW)发送SIP INVITE消息。

步骤7. VXML GW执行bootstrap脚本并向CVP发送HTTP请求。

步骤8. CVP向ICM发送请求指令。

步骤9. ICM取消VRU分支并将DTMF标签发送到CVP。CVP使用VXML GW终止VRU分支。

步骤10. CVP将DTMF发送到IGW(CUBE)。

步骤11. IGW(CUBE)输出脉冲DTMF到AT&T网络。

步骤12. AT&T网络发送DTMF **7网络未收到或无法识别拨号号码。对于好的案例场景，CVP会发送DTMF **6，并且客户听到消息，请在Please wait(请稍候)后保持。

验证

步骤1. CVP配置。

在配置文件夹下的sip.properties文件中，需要添加SIP.ExternalTransferWait功能并将其设置为1000（1秒）。 在此之后，重新启动CVP呼叫服务器。

步骤2. CVP呼叫服务器日志。

收集CVP跟踪，其中Select com.dynamicsoft.DsLibs.DsUALibs设置为Debug级别。

从CVP日志中确认CVP向每个DTMF的入口网关(CUBE)发送SIP信息消息：

例如，从CVP发送到IGW(CUBE)的“*”音。

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

步骤3.收集入口网关日志(CUBE)。

debug ccsip message

debug voip rtp session name event

在PSTN(AT&T)支路上协商的DTMF中继是使用负载类型100的RTP-NTE。
在CVP支路上协商的DTMF中继是sip-info和rtp-nte，使用负载类型101。

从日志中可以看到，入口网关(CUBE)使用SIP信息消息从CVP接收所有数字并将其发送到PSTN(AT&T)

例如，CUBE将数字7发送到PSTN/AT&T网络

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

步骤4.收集网关上的数据包捕获并确认AT&T要求。

要求:

数字间超时= 3秒

对于到网络的DTMF信令，重定向方的VRU（本例中为CVP和CUBE）必须发送数字持续时间至少为80ms且数字间静默为80ms的DTMF音。

在*T和重定向号码或SD代码之间必须应用至少350毫秒的暂停。（下限和上限为300ms - 11sec。）

数据包捕获分析

在正常呼叫中，在CUBE将最后一个数字发送到AT&T后，AT&T会将DTMF“* 6”发送至500毫秒左右

发送到AT&T的数字之间的时间= 200 MS

发送来自DTMF *8的时间，第一个数字= 400 MS

事件持续时间 — 数字长度= 100毫秒

不良呼叫:

AT&T在收到最后**位后6秒后发送DTMF %7

发送到AT&T的数字之间的时间= 200 MS

发送来自DTMF *8的时间，第一个数字= 400 MS

事件持续时间 — 数字长度= 100毫秒

数据包捕获中的好呼叫和坏呼叫之间没有区别。

分辨率

由于发送至AT&T用于正常呼叫和错误呼叫的DTMF具有相同的属性和计时器，但在某些情况下无法识别DTMF，因此测试是在特定数字组之前添加停顿，而解决此问题的组合为：DTMF*8,,,,,,1,,,,8YY，,,,NXX，,,,XXXX，,,"。 这在ICM脚本中更改。