AT&T Transfer Connect Customer Voice Portal(CVP)和Intelligent Contact Management(ICM)
簡介
本文描述在使用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指令碼中對此進行了更改。
意見