目次

はじめに

機能情報

IVR ベースの発信コールのフロー

IVR ベースのダイヤラのタイプ

UCCX とダイヤラ コンポーネント

ゲートウェイ機能情報

トラブルシューティング

データ分析

サンプル SIP ゲートウェイ設定

IVR ベース発信コールのトレース分析の例

MIVR ログの分析の例

一般的な問題

CPA がゲートウェイから UCCX に送信されない

生音声の検出後にコールが UCCX にリダイレクトされない

再試行がダイヤルされない

IVR のスクリプトに接続している場合に DTMF が機能しない

関連情報

概要

このドキュメントでは、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 ベースのアウトバウンド ダイヤラのコール フローです。

1. アウトバウンド IVR ダイヤラによってダイヤルする連絡先の数が決まり（アルゴリズムの定義による）、SIP を使用してボイス ゲートウェイを介してコールが発信されます。

2. 音声ゲートウェイは Call Progress Analysis（CPA）機能を使用して実稼働していない連絡先を検出し、実稼働していない連絡先の状態をダイヤラに送信します。 ダイヤラでは、コンフィギュレーション データベースにある連絡先の状態情報を更新します。

3. 音声ゲートウェイは、CPA 機能を使用して実稼働している連絡先を検出し、実稼働している連絡先の状態をダイヤラに送信します。 ダイヤラでは、コンフィギュレーション データベースにある連絡先の状態情報を更新し、さらに SIP Refer メッセージを SIP ゲートウェイに送信します。ゲートウェイでは、次に、Cisco Unified Communications Manager（CUCM）上の設定された CTI ルート ポイントにコールを転送します。

4. CUCM は Cisco UCCX サーバ上の IVR ポートにコールを転送します。

5. 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 音を認識することです。

これらを区別する機能は難易度が高いことがあるため、設定を最適化するためにタイミング パラメータを調整する必要がある場合があります。

さらに、携帯電話プロバイダーは、コールのプレゼンテーション、セルのロケーション、およびセル自体へのコールのプレゼンテーション間にさまざまな程度の遅延を設けていることがあるという要因も考慮する必要があります。

次に関係する計算の例を示します。

1. UCCX はゲートウェイ（T1）に SIP INVITE を送信

2. ゲートウェイは ISDN のコール セットアップをサービス プロバイダーとセルのプロバイダー（T2）に送信

3. 携帯電話が鳴り、無応答タイマー（T3）を開始

4. セルの RNA タイマーの期限が切れ、ボイスメール（T4）に転送

セルの RNA タイマーが 15 秒である場合、セルへのコールがボイスメールに転送される実際の時間は（T1 + T2 + T3 + 15）です。 T1 + T2 + T3 は固定電話またはその他の非セルのデバイスにコールを示すために要する時間よりも著しく長い可能性があります。

したがって、キャンペーンの無応答リング制限を定義するときは、携帯電話のボイス メール システムに到達するように、この時間間隔を十分に長くする必要があります。 これは、メッセージを残すことを意図するキャンペーンなどにとって望ましい動作です。

注: CPA はゲートウェイの機能です。 Cisco Unified Contact Center Enterprise（UCCE）とは異なり、CPA は UCCX でオンまたはオフにできません。 CPA はゲートウェイでオフにできますが、シスコではこれを推奨していません。 詳細については、『Call Progress Analyis の概要』を参照してください。

IOS ゲートウェイ コードの選択は、このドキュメントの範囲外です。 IVR ベースのアウトバウンド ダイヤラを使用するには、ゲートウェイ コードで CPA および SIP ダイヤラをサポートする必要があります。 Cisco Feature Navigator は機能要件を満たす IOS リリースを確認するために役立ちます。 ご使用の IOS リリースがこのゲートウェイと対話するすべてのコンポーネントと互換性があることを常に確認してください。

トラブルシューティング

注: このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool（登録ユーザ専用）を使用してください。

アウトバウンド IVR をトラブルシュートするには、ゲートウェイ、CUCM、または UCCX で障害が発生しているかどうかを判別します。 特定のコンポーネントに問題を特定すると、トラブルシューティングが簡単になります。 システム コンポーネントからこの情報を収集すると有用です

ゲートウェイの場合は、次のコマンドを実行します。

1. show tech

2. debug ccsip messages

3. debug voip ccapi inout

4. debug isdn q931（または PSTN 側のシグナリングをキャプチャする同様のデバッグ）

5. debug voip hpi all（CPA のトラブルシュート用）

6. debug voip vtsp all（CPA のトラブルシュート用）

UCCX の場合は、ログ ファイルと設定を確認します。

1. SS_OB デバッグおよび XDebug1 ～ XDebug3 が有効化された MIVR ログ ファイル

2. JTAPI ログ ファイル（REFERed コール障害をトラブルシュートするため）

3. UCCX AppAdmin からの SIP ゲートウェイの設定

CUCM の場合、設定を確認します。

1. 詳細 CallManager

2. 詳細 CTIManager

3. アウトバウンド IVR に使用されるゲートウェイを指している SIP トランク設定

データ分析

SIP ゲートウェイは、UCCX から PSTN へのコール要求をルーティングするためだけでなく、アウトバンド用に指定された UCCX トリガーに対するこれらのコールの転送を処理するために必要な設定も含む必要があります。 この SIP ゲートウェイ設定には、次のものが必要です。

1. UCCX からの着信 SIP 要求に一致する着信ダイヤルピア。

2. コールを PSTN にルーティングするアウトバウンド ダイヤルピア（VoIP または単純な旧式の電話サービス（POTS））。

3. リダイレクト（REFERed）されたコールを、UCCX と統合されている CUCM クラスタにルーティングするアウトバウンド ダイヤルピア（VoIP）。

CUCM サーバは SIP ゲートウェイからのインバウンド SIP コール要求（REFERed コール）を受信して、UCCX のトリガーと UCCX のコール制御グループの CTI ポートに適宜ルーティングするように設定する必要があります。

サンプル SIP ゲートウェイ設定

次に、注釈付きの SIP ゲートウェイ設定の例を示します。 次の例の PSTN 接続方法は ISDN 一次群速度インターフェイス（PRI）です。

注: 他のタイプの時分割多重（TDM）PSTN 接続方法はサポートされていますが、Cisco Unified Border Element（CUBE）はサポートされていません。 CUBE サポートの詳細については、Cisco Bug ID CSCui62525 と CSCuf44826 を参照してください。 TDM PSTN への複数接続は、さまざまなクラスのコール（ローカル、長距離電話、国際）をトランクまたはプロバイダーにルーティングするためにサポートされています。

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

注: 同時に複数のキャンペーンがあることがあるため、campaignID と recordID に留意することが重要です。

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&colon;

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 の要求とネゴシエーションを正しく処理していることを確認します。

関連情報

- テクニカル サポートとドキュメント – Cisco Systems