目錄

簡介

必要條件

需求

採用元件

症狀

原因/問題描述

驗證

解析

簡介

本文描述在使用AT&T(DTMF *8)的轉接連線功能的CVP綜合呼叫流程時遇到的問題。

必要條件

需求

思科建議您瞭解以下主題：

- 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執行路由指令碼並將語音響應單元(VRU)標籤傳送到CVP。

步驟6. CVP通過SIP代理伺服器向語音XML網關(VXML GW)傳送SIP INVITE消息。

步驟7. VXML GW執行引導指令碼並向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設定為調試級別。

從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代碼之間必須應用至少350ms的暫停。（下限和上限為300ms - 11sec。）

封包擷取分析

在正常呼叫中，在CUBE將最後一個數字傳送到AT&T後，AT&T會將DTMF「* 6」傳送到500毫秒左右

傳送到AT&T的位之間的時間= 200 MS

傳送來自DTMF *8的時間，第一個數字= 400 MS

事件持續時間 — 數字長度= 100 MS

錯誤呼叫：

AT&T在收到最後**位後6秒後傳送DTMF %7

傳送到AT&T的位之間的時間= 200 MS

傳送來自DTMF *8的時間，第一個數字= 400 MS

事件持續時間 — 數字長度= 100 MS

資料包捕獲中的好呼叫和壞呼叫之間沒有區別。

解析

由於傳送至AT&T用於正常呼叫和錯誤呼叫的DTMF具有相同的屬性和計時器，但在某些情況下無法識別DTMF，因此測試是在特定數字組之前新增暫停並組合來解決問題的：DTMF*8,,,,,,1,,,,8YY，,,,NXX，,,XXXX，,,"。 在ICM指令碼中對此進行了更改。