IVR ベースのアウトバウンド ダイヤラのトラブルシューティング
目次
概要
このドキュメントでは、IVR ベースのアウトバウンド ダイヤラについて説明し、SIP ゲートウェイのサンプル設定、SIP ゲートウェイと Cisco Unified Contact Center Express（UCCX）エンジンのログの分析、および IVR ベースのアウトバウンド ダイヤラの制限が含まれています。
UCCX 8.5 では、新しいタイプのアウトバウンド ダイヤラが導入されました。 自動音声応答（IVR）ベースのアウトバウンド ダイヤラ。 古いプレビューアウトバウンド ダイヤラとは異なり、発信コールにエージェントは使用されません。 UCCX は、顧客企業の Session Initiation Protocol（SIP）ゲートウェイに直接接続してアウトバウンド連絡先にダイヤルします。 ゲートウェイが実稼働中の音声または留守番電話を検出すると、コールは、発信コールのコントロール グループに向かう UCCX トリガーにリダイレクトされます。 アウトバウンドのコンピュータ テレフォニー インテグレーション（CTI）のポートで終端されると、トリガーに関連付けられたアプリケーションが通常どおりに実行されます。
機能情報
8.5 よりも前のバージョンの UCCX には、プレビュー アウトバウンド ダイヤラのみが存在します。 このダイヤラでは、Java Telephony Application Programming Interface（JTAPI）/CTI を介してサードパーティ コール制御を使用することにより、エージェントの電話機にコールを発信するように指示しました。 コールは、エージェントがアウトバウンド予約を受け入れてから発信されました。 アウトバウンド予約のクライアント、サーバ間の相互対話は、CTI を介して実行されました。
特定の使用例（アポイントメント リマインダ、セルフサービス IVR アプリケーションなど）では、プレビュー アウトバウンド ダイヤラが適していませんでした。 DialingList の番号に発信するために、コールが発信される間にエージェントが結合されました。 つまり、公衆電話交換網（PSTN）番号が無効、ビジー、または留守番電話による応答に至った場合でも、エージェントが各発信コール用に占有されました。 この高レベルのエージェント使用率は、これらの使用例におけるプレビュー アウトバウンド ダイヤラの主な欠点です。
IVR ベースの発信コールのフロー
IVR ベースのアウトバウンド ダイヤラの同じ使用例では（アポイントメント リマインダ、セルフサービス IVR アプリケーション）、エージェントがコール フローに関与することはありません。 これは、IVR ベースのアウトバウンド ダイヤラのコール フローです。
- アウトバウンド IVR ダイヤラによってダイヤルする連絡先の数が決まり（アルゴリズムの定義による）、SIP を使用してボイス ゲートウェイを介してコールが発信されます。
- 音声ゲートウェイは Call Progress Analysis（CPA）機能を使用して実稼働していない連絡先を検出し、実稼働していない連絡先の状態をダイヤラに送信します。 ダイヤラでは、コンフィギュレーション データベースにある連絡先の状態情報を更新します。
- 音声ゲートウェイは、CPA 機能を使用して実稼働している連絡先を検出し、実稼働している連絡先の状態をダイヤラに送信します。 ダイヤラでは、コンフィギュレーション データベースにある連絡先の状態情報を更新し、さらに SIP Refer メッセージを SIP ゲートウェイに送信します。ゲートウェイでは、次に、Cisco Unified Communications Manager（CUCM）上の設定された CTI ルート ポイントにコールを転送します。
- CUCM は Cisco UCCX サーバ上の IVR ポートにコールを転送します。
- IVR サブシステムは、キャンペーンに関連付けられた IVR アプリケーションにコールを関連付けます。 エンジンはアプリケーションの実行を開始し、UCCX のキャンペーン用の IVR アプリケーションと、カスタマー コンタクトの間で IVR セッションが開始されます。
IVR ベースのダイヤラのタイプ
IVR ベースのアウトバウンド ダイヤラには、プレディクティブとプログレッシブの 2 種類があります。 UCCX では生音声（または設定可能な留守番電話）が検出された場合に限り、スクリプトを実行するために IVR ポートにコールを転送するため、ポートを必要としないアウトバウンド連絡先があることを仮定することは適切です。 CTI ポートを必要とするケースと、Ring No Answer（RNA）、ビジー状態、および無効な番号のある状況の確率のバランスを取るために、プレディクティブ ダイヤラとプログレッシブ ダイヤラでは、設定されているアウトバウンド CTI ポートの数を基準に、一度に発信されるコールの数を変更します。
プレディクティブ IVR ベース アウトバウンド ダイヤラには、次の特徴があります。
- 各ポートの回線数は放棄呼率に基づいて調整できます。
- 手動操作は必要ではありません。
- 目標は、IVR ポートをビジーにしておくように十分な回線にダイヤルする一方で、設定された最大放棄呼率を超過しないようにすることです。
プログレッシブ IVR ベース アウトバウンド ダイヤラには、次の特徴があります。
- 使用できるアウトバウンド IVR ポートごとに、常にダイヤルされる固定された数の回線を指定できます。
- 回線数は後日更新できます。
- 各ポートの回線が 3 本あり、アウトバウンド専用のポートが 3 個の場合は、9 コール（3x3）がダイヤルされます。
- 放棄呼は、顧客が電話に応答する一方で、この顧客にプロンプトするために使用できるポートがない場合に発生します。
- デフォルト設定を定義できます。
UCCX とダイヤラ コンポーネント
この新しい IVR ベースのアウトバウンド ダイヤラに対応するために、すべての機能と内部サブシステムが抽出されています。 エンジン、DialingList テーブルなどの新しいダイヤラのシステム コンポーネントは、プレビュー アウトバウンド ダイヤラと同じであり、拡張が行われています（callStatus と callResult の値の増大など）。
ゲートウェイ機能情報
生音声、留守番電話、および特殊情報トーン（SIT）の検出をサポートするために、ゲートウェイでは CPA 機能をサポートする必要があります。 SIP ダイヤラおよび CPA をサポートするゲートウェイの Cisco IOS® のバージョンを判別するには Cisco Feature Navigator を使用します。 [Search by Feature] 検索を使用して「Serviceability support for SIP dialer and Call Progress Analysis」を検索してください。
CPA はどのような仕組みですか。
CPA には 3 つの主要機能があります。
- 留守番電話の検出（AMD）
- ファクス/モデム検出
- 留守番電話終了トーン検出
これらを区別するために複雑なアルゴリズムが実装されていますが、機能の観点からは次のことが言えます。
- 生身の通話者の応答は最初の言葉が短く、その後に無音の時間があると想定されています。
例： 「はい」+ 無音
例： 「はい、ジョンソンです」+ 無音 - 留守番電話は最初の言葉が長く、その後に無音がないと想定されています。
例： 「はい、ミラーです。ビープ音の後にメッセージを残してください」 - 留守番電話終了トーンの検出は、留守番電話、無音、終結のトーンの検出になると予期されます。
- ファクスの検出は、FAX 音を認識することです。
これらを区別する機能は難易度が高いことがあるため、設定を最適化するためにタイミング パラメータを調整する必要がある場合があります。
さらに、携帯電話プロバイダーは、コールのプレゼンテーション、セルのロケーション、およびセル自体へのコールのプレゼンテーション間にさまざまな程度の遅延を設けていることがあるという要因も考慮する必要があります。
次に関係する計算の例を示します。
- UCCX はゲートウェイ（T1）に SIP INVITE を送信
- ゲートウェイは ISDN のコール セットアップをサービス プロバイダーとセルのプロバイダー（T2）に送信
- 携帯電話が鳴り、無応答タイマー（T3）を開始
- セルの RNA タイマーの期限が切れ、ボイスメール（T4）に転送
セルの RNA タイマーが 15 秒である場合、セルへのコールがボイスメールに転送される実際の時間は（T1 + T2 + T3 + 15）です。 T1 + T2 + T3 は固定電話またはその他の非セルのデバイスにコールを示すために要する時間よりも著しく長い可能性があります。
したがって、キャンペーンの無応答リング制限を定義するときは、携帯電話のボイス メール システムに到達するように、この時間間隔を十分に長くする必要があります。 これは、メッセージを残すことを意図するキャンペーンなどにとって望ましい動作です。
IOS ゲートウェイ コードの選択は、このドキュメントの範囲外です。 IVR ベースのアウトバウンド ダイヤラを使用するには、ゲートウェイ コードで CPA および SIP ダイヤラをサポートする必要があります。 Cisco Feature Navigator は機能要件を満たす IOS リリースを確認するために役立ちます。 ご使用の IOS リリースがこのゲートウェイと対話するすべてのコンポーネントと互換性があることを常に確認してください。
トラブルシューティング
アウトバウンド IVR をトラブルシュートするには、ゲートウェイ、CUCM、または UCCX で障害が発生しているかどうかを判別します。 特定のコンポーネントに問題を特定すると、トラブルシューティングが簡単になります。 システム コンポーネントからこの情報を収集すると有用です
ゲートウェイの場合は、次のコマンドを実行します。
- show tech
- debug ccsip messages
- debug voip ccapi inout
- debug isdn q931（または PSTN 側のシグナリングをキャプチャする同様のデバッグ）
- debug voip hpi all（CPA のトラブルシュート用）
- debug voip vtsp all（CPA のトラブルシュート用）
UCCX の場合は、ログ ファイルと設定を確認します。
- SS_OB デバッグおよび XDebug1 ～ XDebug3 が有効化された MIVR ログ ファイル
- JTAPI ログ ファイル（REFERed コール障害をトラブルシュートするため）
- UCCX AppAdmin からの SIP ゲートウェイの設定
CUCM の場合、設定を確認します。
- 詳細 CallManager
- 詳細 CTIManager
- アウトバウンド IVR に使用されるゲートウェイを指している SIP トランク設定
データ分析
SIP ゲートウェイは、UCCX から PSTN へのコール要求をルーティングするためだけでなく、アウトバンド用に指定された UCCX トリガーに対するこれらのコールの転送を処理するために必要な設定も含む必要があります。 この SIP ゲートウェイ設定には、次のものが必要です。
- UCCX からの着信 SIP 要求に一致する着信ダイヤルピア。
- コールを PSTN にルーティングするアウトバウンド ダイヤルピア（VoIP または単純な旧式の電話サービス（POTS））。
- リダイレクト（REFERed）されたコールを、UCCX と統合されている CUCM クラスタにルーティングするアウトバウンド ダイヤルピア（VoIP）。
CUCM サーバは SIP ゲートウェイからのインバウンド SIP コール要求（REFERed コール）を受信して、UCCX のトリガーと UCCX のコール制御グループの CTI ポートに適宜ルーティングするように設定する必要があります。
サンプル SIP ゲートウェイ設定
次に、注釈付きの SIP ゲートウェイ設定の例を示します。 次の例の PSTN 接続方法は ISDN 一次群速度インターフェイス（PRI）です。
RyanIVRRouter#show run
Building configuration...
ISDN PRI 用に設定された T1 コントローラ
!
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24
!
ISDN PRI に設定されたシリアル インターフェイス
!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
発信コールを PSTN にルーティングするための音声ポート
!
voice-port 0/0/0:23
!
着信 VoIP ダイヤルピア
このダイヤルピアは UCCX からの着信 SIP コール要求と一致します。 着信 VoIP ダイヤルピアが設定されていない場合は、デフォルトのダイヤルピア（ダイヤルピア 0）と一致します。 着信 VoIP ダイヤルピアを定義して一致させることがベスト プラクティスです。 このダイヤルピアは、UCCX からの着信 SIP レッグで使用されるコーデック、プロトコル、およびデュアルトーン多重周波数（DTMF）リレーをゲートウェイに通知します。
このダイヤルピアは、717 から始まる長さが 10 桁のすべて Digital Number Identification Service（DNIS）を持つ着信 SIP INVITE と一致します。 この例では、UCCX によってダイヤルされるすべての連絡先は 717 エリア コードにあり、電話番号が 10 桁です。
!
dial-peer voice 100 voip
description -- Outbound Calls From UCCX --
session protocol sipv2
incoming called-number 717.......
dtmf-relay rtp-nte
codec g711ulaw
!
POTS ダイヤルピア
このダイヤルピアは以前に設定された PRI を介して PSTN にコールをルーティングします。 これは、UCCX からのコール要求用の発信ダイヤルピアであり、上記の VoIP ダイヤルピア 100 用のアウトバウンド ダイヤルピアです。 このダイヤルピアは、テストのために PSTN から到達するコール用のインバウンド ダイヤルピアとしても動作します。 UCCX のアウトバウンド ダイヤラのコール フローでは、このダイヤルピアはインバウンド ダイヤルピアとして一致しません。
!
dial-peer voice 10 pots
description -- POTS Dial Peer To/From PSTN Simulator --
destination-pattern 717.......
incoming called-number .
direct-inward-dial
port 0/0/0:23
forward-digits all
!
発信 VoIP ダイヤルピア
このダイヤルピアは、UCCX トリガーに向かう CUCM クラスタにコールをルーティングするために SIP ゲートウェイで必要なアウトバウンド ダイヤルピアとして動作します。 このダイヤルピアは、生音声（または設定が存在する場合は留守番電話）を検出したときに、UCCX が送信した REFER をルーティングするためにゲートウェイで使用されます。 このダイヤルピアは、リダイレクトされたコールを SIP ゲートウェイでルーティングする必要がある CUCM ノードのプロトコル、DTMF リレー、コーデック、および IP アドレスを定義します。 冗長性とロード バランシングのために、このタイプのダイヤルピアが複数存在することがあります。 これらは、クラスタ内の複数の CUCM ノードに要求をルーティングするために分割したり、特定のトリガーのリダイレクトをさまざまな CUCM ノードにルーティングするためにプロビジョニングしたりできます。
この例では、IVR ベースのアウトバウンド キャンペーンの UCCX トリガーは 2001 および 2002 です。
!
dial-peer voice 102 voip
description -- Redirect Calls to UCCX 90 --
destination-pattern 200[1-2]
session protocol sipv2
session target ipv4:14.10.166.15
incoming called-number 200[1-2]
dtmf-relay rtp-nte
codec g711ulaw
!
IVR ベース発信コールのトレース分析の例
これは、SIP ゲートウェイ、UCCX、および PSTN 間のメッセージ ログに対する詳細な分析の例です。
UCCX からの最初の INVITE で PSTN 番号にコールを行うようゲートウェイに指示します。 INVITE には、このコールに関連付けられたすべてのメッセージを追跡するために使用できるコール ID と、Session Description Protocol（SDP）（メディア パラメータ）が含まれています。
さらに重要なのは、INVITE には、CPA を実行するためにゲートウェイで使用する必要があるパラメータが含まれていることです。 これらのパラメータは UCCX の AppAdmin ページで設定されますが、UCCX では使用されません。 正確に言えば、INVITE に含めてゲートウェイに送信され、このコールの CPA のデジタル シグナル プロセッサ（DSP）を設定するためにゲートウェイによって使用されます。 したがって、これらのパラメータはコールごとにゲートウェイに送信され、AppAdmin からいつでも変更できます。
UCCX では、コールごとに次の CPA 設定属性をゲートウェイに送信します。
| パラメータ名（Parameter Name） | パラメータ値 | 推奨値（Suggested Value） |
| Minimum Silence Period（100 ～ 1000）* | ミリ秒 | 375 |
| Analysis Period（1000 ～ 10000）* | ミリ秒 | 2500 |
| Maximum Time Analysis（1000 - 10000）* | ミリ秒 | 3000 |
| Minimum Valid Speech Time（50 ～ 500）* | ミリ秒 | 112 |
| Maximum Term Tone Analysis（1000 - 60000）* | ミリ秒 | 15000 |
設定可能な値は AppAdmin の [SIP Gateway Configuration] ページに表示されます。
Received:
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary
--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--
ゲートウェイのダイヤルピアを介してコールを処理中に、UCCX に「100 Trying」メッセージが送信されます。
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
発信コールがアウトバウンド ダイヤルピアと一致すると、設定された TDM プロトコルを使用して PSTN に送信されます。 この場合は、PRI が使用されます。
Aug 3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008D
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x2180, '9195551212'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '7175551212'
Plan:ISDN, Type:National
コール プログレスとシグナリングが、PSTN とゲートウェイの間で交換されます。 PSTN 電話が鳴っていることが ALERTING メッセージによってゲートウェイに通知されます。
Aug 3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808D
Channel ID i = 0xA98397
Exclusive, Channel 23
Aug 3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808D
Progress Ind i = 0x8188 - In-band info or appropriate now available
ゲートウェイは、PSTN 電話が鳴っていることを UCCX に通知するために 183 Session Progress を UCCX に返信します。 これにはリングバックトーンのメディア ネゴシエーション用の SDP が含まれます。
Sent:
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
event=enabled
--uniqueBoundary--
PSTN 電話機がコールに応答したため、コールは、TDM レッグで接続されます。 ゲートウェイは CONNECT_ACK で確認を送信します。
Aug 3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x808D
Aug 3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x008D
ゲートウェイはコールが 200 OK で接続されていることを UCCX に通知します。 UCCX では、SIP RFC の要件に応じてこれを ACK します。 200 OK には、メディア ネゴシエーション用の SDP も含んでいますが、UCCX によって使用されることはありません。
Sent:
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271
v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
Received:
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
ゲートウェイでは、CPA でのコール プログレスを検出し、一連の UPDATE メッセージを通じてコール プログレスを UCCX に通知します。 UCCS では、SIP RFC の要件に応じてこれを ACK します。
この SIP アップデートの例では、イベントは「Detected」で、状態は「CpaS」です。
- CpaS は、CPA が開始したことを示します。
- 留守番電話が検出された場合、状態は「Asm」です。
- 留守番電話のトーンが適格である場合、状態は「AsmT」です。
次の表は、SIP アップデート メッセージで使用される x-cisco-cpa ステータス コードを示します。
| 名前 | 定義 |
FT |
ファクス/モデム トーン。 |
Asm |
留守番電話。 |
AsmT |
留守番電話終了トーン。 |
LS |
生身の人間の会話。 |
SitIC |
SIT トーン IC：代行受信：空き番号、AIS など |
SitNC |
SIT トーン NC：回線なし、緊急、またはトランクのブロック |
SitVC |
SIT トーン VC：空のコード |
SitRO |
SIT トーン RO：アナウンスのリオーダー |
SitMT |
その他の SIT トーン |
CpaS |
CPA の開始 |
LV |
少量または無音のコール |
Sent:
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26
event=detected
status=CpaS
Received:
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...
UCCX は、このアウトバウンド キャンペーンに割り当てられたトリガーにコールをリダイレクトするために、ゲートウェイに通知を送信します。 ゲートウェイは、これを ACK します。
Received:
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...
Sent:
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...
ゲートウェイでは、ゲートウェイのダイヤルピア経由で、通常の呼処理同様に、新しい宛先にこのコールをルーティングする必要があります。
Aug 3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=FALSE, Mode=0,
Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)
コールは、REFER に含まれている宛先に一致するアウトバウンド ダイヤルピアの設定に基づいてゲートウェイによってルーティングされます。
Sent:
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
MIVR ログの分析の例
MIVR のログからこれらのフラグメントは、UCCX の観点によるコールの概要を示します。 正しい情報をキャプチャするには、次のデバッグ レベルを有効にします。
- SS OB：Debug、XD1、XD2、XD3
- SS RM：Debug、XDebug1
- CFG MGR：Debug、XDebug1（リスト レコードのダイヤルに関する問題の場合）
135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, ,
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239
135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2
B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0
135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber:
callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber:
dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber:
phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber:
intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9
longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber():
domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber():
long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber:
dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId -
phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset:
DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId -
phoneNum=9785551212
//Based on the Campaign config, the phone number is modified accordingly. In a failed call
scenario, you might want to verify what the number is after the formatting is done. Look
for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.
135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor:
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212.
これは、フォーマット設定された phoneNumber とフォーマット設定されていない phoneNumber を示します。
135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() -
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )
SIP シグナリングが開始されます。
SIP-9919785551212 INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0
SIP-9919785551212 SIP/2.0 100 Trying
SIP-9919785551212 SIP/2.0 183 Session Progress
SIP-9919785551212 SIP/2.0 200 OK
これまでに説明したゲートウェイのメッセージングを参照して、ゲートウェイにおけるこれらのメッセージの処理を確認します。
135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68,
State=CONTACTING, fromDN=8005553434, toDN=9919785551212,
callId=134551289542668@10.10.10.5 sending
SIP-9919785551212 ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0
135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5
notify
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed
135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway
135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg:
OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5,
status=OK135534725: Aug 20 21:34:58.810 EDT
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg:
OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER,
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212,
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR
Dialer processes
135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData:
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1
ゲートウェイは、CPA メッセージとともに SIP UPDATE メッセージを送信します。 CPA ソフトウェアは、ゲートウェイで実行され、着信側からの Real-Time Transport Protocol（RTP）を分析します。 これは、着信側の端が音声であるのか留守番電話であるのかを区別するために役立ちます。 CPA SIP UPDATE メッセージは Content-Type が「application/x-cisco-cpa」であることによって識別できます。
SIP-9919785551212 UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212 Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212 Max-Forwards: 69
SIP-9919785551212 To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212 From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212 Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212 CSeq: 102 UPDATE
SIP-9919785551212 Content-Length: 26
SIP-9919785551212 Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212 User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212 Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212 Timestamp: 1345512899
SIP-9919785551212 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
SIP-9919785551212 Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212 Min-SE: 1800
SIP-9919785551212 Content-Type: application/x-cisco-cpa
SIP-9919785551212 Content-Disposition: signal;handling=optional
SIP-9919785551212
SIP-9919785551212 event=detected
SIP-9919785551212 status=CpaS
SIP-9919785551212 UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212 Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212 Max-Forwards: 69
SIP-9919785551212 To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212 From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212 Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212 CSeq: 103 UPDATE
SIP-9919785551212 Content-Length: 163
SIP-9919785551212 Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212 User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212 Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212 Timestamp: 1345512902
SIP-9919785551212 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
SIP-9919785551212 Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212 Min-SE: 1800
SIP-9919785551212 Content-Type: application/x-cisco-cpa
SIP-9919785551212 Content-Disposition: signal;handling=optional
SIP-9919785551212
SIP-9919785551212 event=detected
SIP-9919785551212 status=LV
SIP-9919785551212 pickupT=320
SIP-9919785551212 maxActGlitchT=0
SIP-9919785551212 numActGlitch=0
SIP-9919785551212 valSpeechT=20
SIP-9919785551212 maxPSSGlitchT=0
SIP-9919785551212 numPSSGlitch=0
SIP-9919785551212 silenceP=0
SIP-9919785551212 termToneDetT=0
SIP-9919785551212 noiseTH=1000
SIP-9919785551212 actTh=32000
//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low
Volume as Voice,' this call is handled accordingly
135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus
post OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg:
OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239,
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5,
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239
一般的な問題
CPA がゲートウェイから UCCX に送信されない
コールが PSTN の発信者と接続された後で、CPA が完了したことやコールが帰着したこと（生音声、話中、留守番電話など）を示すメッセージは、ゲートウェイによって UCCX に返信されません。 ゲートウェイ上の IOS バージョンで CPA をサポートしていることを確認します。 ゲートウェイを調べて、CPA が正常に動作していることを確認します。
生音声の検出後にコールが UCCX にリダイレクトされない
キャンペーンに割り当てられた UCCX トリガーの着信番号（DN）と一致するダイヤルピアがゲートウェイに設定されていることを確認します。 ゲートウェイからのコールが CUCM のこの CTI ルート ポイント/トリガーにルーティングできることを確認します。
再試行がダイヤルされない
プレビュー アウトバウンド ダイヤラのコールバック同様、RNA またはビジーを受信するコールが再試行されない場合は、DialingList テーブルでこれらのレコードが Retry として正しくマーキングされていることを確認します。 指定したコールバックまたは再試行時間にコールが試みられていることを MIVR のログで確認します。
IVR のスクリプトに接続している場合に DTMF が機能しない
DTMF が CUCM とゲートウェイの間で正しくネゴシエートされていることおよび名前付きダイヤルピアが一致していること（ダイヤルピア 0 は DTMF リレー設定を含まない）を確認します。 UCCX では JTAPI を介したアウトオブバンド DTMF のみをサポートしているため、DTMF インターワーキングを完了するためには、一部のゲートウェイ タイプとコール フローでは、メディア ターミネーション ポイント（MTP）を起動しなければならない可能性があります。 ゲートウェイを調べて、ゲートウェイと CUCM が DTMF の要求とネゴシエーションを正しく処理していることを確認します。
フィードバック