AT&T Transfer Connect Customer Voice Portal(CVP)およびIntelligent Contact Management(ICM)

はじめに

このドキュメントでは、AT&Tの転送接続機能(DTMF *8)でCVPの包括的なコールフローを使用する場合に発生する問題について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• CVP バージョン 8.5
• Intelligent Contact Manager（ICM）
• AT&T Transfer Connectサービス

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• ICM 8.5
• CVP 8.5
• CUBEバージョン151-3.T4
• AT&T転送接続

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

症状

コールを発信すると、そのコールはCVPを経由してCisco Unified Contact Center Enterprise(UCCE)にルーティングされ、AT&Tネットワーク上の外部番号（転送接続サービス）に転送されて戻されます。 問題が発生すると、AT&Tから次のプロンプトが聞こえます。

Please wait

申し訳ありませんが、通話を完了できません。通話を再試行してください

原因/問題の説明

CVPの包括的なコールフローでは、コールはCVPで受信され、CVPはDTM *8ラベルに続いて500ミリ秒(MS)一時停止、1800番号を受信します。CVPがDTMFをCisco Unified Border Element(CUBE)に送信し、ゲートウェイがディジットをAT&Tネットワークにパルス送信します。ただし、コールが転送されず、お客様には「We're sorry your call cannot be completed.コールを再試行してください。

ステップ 1：発信者が公衆電話交換網(PSTN)からコールを発信します。

ステップ 2：入力ゲートウェイ(IGW)がPSTNからコールを受信します。この場合、CUBEは入力ゲートウェイです。

ステップ 3：IGWは、SIPプロキシサーバ経由でCVPにSIP INVITEメッセージを送信します。

ステップ 4：CVP が ICM に発信要求を送信します。

ステップ 5：ICM がルーティング スクリプトを実行して、CVP に Voice Response Unit（VRU）ラベルを送信します。

手順 6：CVP が SIP プロキシ サーバ経由で Voice XML Gateway（VXML GW）に SIP の INVITE メッセージを送信します。

手順 7：VXML GW がブートストラップ スクリプトを実行して、CVP に HTTP 要求を送信します。

ステップ 8：CVP が ICM に Request Instruction を送信します。

ステップ 9：ICMはVRUレグをキャンセルし、DTMFラベルをCVPに送信します。CVP が VXML GW で VRU レグを終了します。

ステップ 10：CVPがDTMFをIGW(CUBE)に送信します。

ステップ 11IGW(CUBE)アウトパルスは、AT&TネットワークにDTMFを発信します。

ステップ 12AT&Tネットワークが、DTMF **7ネットワークが受信しなかったか、またはダイヤル番号を認識できなかったことを送信します。適切な事例では、CVPがDTMF **6を送信すると、Please holdというメッセージがPlease waitの後に顧客に再生されます。

確認

ステップ 1：CVPの設定

設定フォルダの下にあるsip.propertiesファイルにSIP.ExternalTransferWait機能を追加し、1000（1秒）に設定する必要があります。 この後、CVPコールサーバを再起動します。

ステップ 2：CVPコールサーバログ

Select com.dynamicsoft.DsLibs.DsUALibsをDebugレベルに設定して、CVPトレースを収集します。

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イベント

PSTN(AT&T)レグでネゴシエートされるDTMFリレーは、ペイロードタイプ100を使用するRTP-NTEです。
CVPレグでネゴシエートされるDTMFリレーは、ペイロードタイプ101を使用するsip-infoおよびrtp-nteです。

ログから、入力ゲートウェイ(CUBE)がSIP情報メッセージを使用してCVPからすべてのディジットを受信し、それをPSTN(AT&T)に送信していることがわかります

たとえば、CUBEがPSTN/AT&Tネットワークにディジット7を送信するとします

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）が、少なくとも80ミリ秒のディジット継続時間と80ミリ秒のディジット間無音を含むDTMFトーンを送信する必要があります。

*Tとリダイレクション番号またはSDコードの間に、350ミリ秒以上のポーズを適用する必要があります。（下限と上限は300ミリ秒～ 11秒です）。

パケットキャプチャ分析

正常なコールでは、CUBEが最後の数字をAT&Tに送信した後、AT&TはDTMF「* 6」を500 MS前後で送信します

AT&Tに送信されるディジット間の時間= 200ミリ秒

DTMF *8からの時間が送信され、最初のディジット= 400 MS

イベント期間 – ディジット長= 100ミリ秒

不正なコール：

AT&Tは、最後のディジットを受信してから6秒後にDTMF **7を送信します

AT&Tに送信されるディジット間の時間= 200ミリ秒

DTMF *8からの時間が送信され、最初のディジット= 400 MS

イベント期間 – ディジット長= 100ミリ秒

パケットキャプチャのコールの状態は良好でも不良でも変わりません。

解決方法

正常コールと不良コールに対してAT&Tに送信されるDTMFのプロパティとタイマーは同じですが、一部のシナリオではDTMFが認識されないため、特定のディジットのグループの前に一時停止を追加してテストを行い、問題を解決する組み合わせは：DTMF*8,,,,,,1,,8YY,,,,,,NXX,,XXXX,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, これは、ICMスクリプトで変更されます。