Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)Cisco Unified Customer Voice Portal(CVP)Release 8.5(x)
Cisco Unified Communications Manager により発生したコール
Cisco Unified Communications Manager により発生したコール
発行日;2012/03/14 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

Cisco Unified Communications Manager により発生したコール

この章の新規情報

Cisco Unified Communications Manager により発生したコールの相違点

顧客コール フロー

IVR への転送を伴う Unified ICM 発信コール

内部ヘルプ デスク コール

ウォーム コンサルタティブ転送と会議

プロトコル コール フロー

モデル #1:スタンドアロン セルフサービス

モデル #2:コール ディレクタ

モデル #3a:ICM Micro-Apps を使用する包括モデル

モデル #3b:UnifiedCVP VXML Server を使用する包括モデル

展開の意味

Unified ICM のコンフィギュレーション

ホスト型実装

Cisco Unified Communications Manager の設定

ゲートキーパーまたは SIP プロキシのダイヤル プランのコンフィギュレーション

サイジング

ゲートウェイ

KPML のサポート

UCM トランク上の MTP の使用

設計上の考慮事項

Cisco Unified Communications Manager により発生したコール

この章では、主に次のトピックについて取り上げます。

「この章の新規情報」

「顧客コール フロー」

「プロトコル コール フロー」

「展開の意味」

「KPML のサポート」

この章の新規情報

表 6-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 6-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明

「KPML のサポート」

KPML は、RTP ストリームではなく SIP シグナリングによってキー押下情報を渡すアウトオブバンド dtmf 方式です。

Cisco Unified Communications Manager により発生したコールの相違点

Unified ICM への JTAPI インターフェイスに関連付けられた Unified CM ルート ポイントをユーザがダイヤルすると、Cisco Unified Communications Manager(Unified CM)により発生したコールは、最初に Unified ICM システムに入ります。そのようなコールによって、発信者をキューまたはセルフサービス アプリケーションに展開するために使用できる Unified ICM ルーティング スクリプトが開始されるか、使用可能なエージェントが選択されるか、またはアプリケーション ゲートウェイが起動されます。Unified ICM への JTAPI インターフェイスを介して起動されたコールは、通常のポストルート要求です。着信番号、ANI、変数などが提示され、ラベルが返されます。次に、Unified CM は、返されたラベルによって指定された宛先にコールを配信します。他の ACD ポストルート要求と同様に、交換はそこで終了します。Unified CM が別のポストルート要求を発行しない限り、Unified ICM は後続のラベルをその Unified CM に送信できません。

この制限が、Unified CM により発生したコールと、Unified CVP 入力ゲートウェイにより発生したコールの最初の相違点です。Unified CVP は、コールのルーティングおよび再ルーティングを必要な回数だけ継続できます。このため、コールが Unified CM から発生した場合、ルーティング クライアントの責任が Unified CVP にできるだけ早くハンドオフされる必要があります。

2 番めの相違点は、VRU へのコールの転送方法に関係します。Unified CM などの ACD ルーティング クライアントは、TranslationRouteToVRU ラベルを使用することによってのみ転送可能です。Unified CVP は、ルーティング クライアントである場合、SendToVRU ノードによって生成されたトランスレーション ルート ラベルおよび相関 ID ラベルを処理できます。

ロケーションベースのコール アドミッション制御は、IP から発生したコール(エージェントがウォーム転送または会議を実行するコールを含む)に対してサポートされていません。

次の項では、これらの相違点についてさらに詳細に説明します。

顧客コール フロー

次のタイプのコールが Unified CM により発生し、Unified CVP により発生したコールとは異なる処理が必要です。

「IVR への転送を伴う Unified ICM 発信コール」

「内部ヘルプ デスク コール」

「ウォーム コンサルタティブ転送と会議」

IVR への転送を伴う Unified ICM 発信コール

Cisco Unified CCE Outbound Dialer は、Skinny Client Control Protocol(SCCP)電話機を偽装し、Unified CM に発信コールを行うよう要求することによって、発信コールを導入します。ユーザが応答したことを検出すると、コールを Unified CCE 宛先に転送してループを抜けます。顧客の要件が Unified CVP メッセージまたはセルフサービス アプリケーションを着信側に提供することである場合、コールは Unified CM ルート ポイントを使用して Unified CVP に転送されます。このプロセスは、Unified CM により発生したコールの定義に合致しています。

内部ヘルプ デスク コール

従業員のデスクに IP 電話を設置している企業は、セルフサービス アプリケーションにコールする機能を従業員に提供する場合があります。たとえば、従業員が医療保障に加入できるようにするアプリケーションがあります。あるいは、従業員が IT ヘルプ デスクなどのエージェントに到達しようとして、キューで待機することになる場合もあります。これらのシナリオは、どちらも Unified CM から Unified CVP に対して発生するコールになります。

内線発信者が、モデル #1 スタンドアロン セルフサービスを使用して展開されている Unified CVP VXML Server でホストされているセルフサービス アプリケーションにダイヤルインできる場合もあります。ICM はこのシナリオには関係しませんが、Unified CM により発生したコールとして適しています。

ウォーム コンサルタティブ転送と会議

通常のコンタクトセンター コール フローでは、ほとんどの企業は、発信者を別のエージェント(現在使用可能な場合も使用不可の場合もある)に転送する機能をエージェントに提供することを希望しています。この転送を実現するには、ブラインド転送とウォーム コンサルタティブ転送(または会議)という 2 つの方法があります。

ブラインド転送では、最初のエージェントは番号をダイヤルして切断します。発信者は 2 番めのエージェントに接続されるか、必要に応じてキューに格納されます。このタイプの転送は Unified CM により発生したコールとは関係しておらず、ネットワーク転送と呼ばれます。ネットワーク転送については、「ICM 管理転送」の項も参照してください。

ウォーム転送または会議では、発信者が保留状態の間にエージェントは番号をダイヤルして 2 番めのエージェントに接続されます。2 人のエージェントは会話が可能となり、発信者と会議を開くことができ、その後最初のエージェントは離脱できます。2 番めのエージェントが使用不可の場合、キューに格納されるのは(発信者ではなく)最初のエージェントです。最初のエージェントをキューに格納する必要がなければ、この処理はすべて Unified CVP なしで行うことができます。最初のエージェントをキューに格納する必要がある場合は、最初のエージェントのコールを Unified CVP に転送し、Unified CM により発生したコールを作成する必要があります。

プロトコル コール フロー

この項では、次に示す関連する展開モデルそれぞれで、Unified CM により発生したコールの Protocol-Level コール フローについて説明します。

「モデル #1:スタンドアロン セルフサービス」

「モデル #2:コール ディレクタ」

「モデル #3a:ICM Micro-Apps を使用する包括モデル」

「モデル #3b:Unified CVP VXML Server を使用する包括モデル」


) Unified CM により発生したコールに関係する NIC はないため、モデル #4(NIC 制御ルーティングのみを使用する VRU)についてはここでは説明しません。


モデル #1:スタンドアロン セルフサービス

モデル #1 には Unified ICM は関係しません。このモデルは、Unified CM ユーザが Unified CVP VoiceXML ゲートウェイに接続する電話番号をダイヤルし、Unified CVP VXML Server アプリケーションを起動したときに発生します。VoiceXML ゲートウェイは、Unified CM で H.323 ゲートウェイまたは SIP トランクとして設定されます。このモデルのコール フローは、次のとおりです。

1. 発信者がルート パターンをダイヤルします。

2. Unified CM がコールを VoiceXML ゲートウェイに送信します。

3. VoiceXML ゲートウェイは、設定済みの Unified CVP セルフサービス アプリケーションに基づいて音声ブラウザ セッションを起動します。

4. Unified CVP セルフサービス アプリケーションが、Unified CVP VXML Server に対して HTTP 要求を行います。

5. Unified CVP VXML Server は、セルフサービス アプリケーションを開始します。

6. Unified CVP VXML Server と VoiceXML ゲートウェイは、HTTP 要求と VoiceXML 応答を交換します。

7. 発信者が切断します。


) スクリプトは、TDM 宛先に対してでない限り、Transfer ノードを実行できません。IP 宛先への転送は IP-to-IP コール(サポート対象)になりますが、別の VoIP 宛先への転送操作が成功するように、ip-ip-gw コマンド(CUBE コマンド)をゲートウェイ コンフィギュレーションに追加する必要があります。


モデル #2:コール ディレクタ

モデル #2 には VRU レッグはなく、すべてスイッチングです。したがって、Unified CM により発生したコールは、常にターゲットに直接配信されるか、拒否されます。キューイングまたはセルフサービスは関係しません。

このモデルでは、コールが Unified CM から発生することを想定しています。このモデルでは、もともとは Unified CVP 入力ゲートウェイを介して着信し、Unified CM に転送されて、現在は再度転送されているコールは除外されます。通常は Unified CM 自体がこれらの転送を処理できるため、このような状況はまれです。ただし、ターゲットが Unified CM 以外の ACD である場合などの例外がありますが、そのような状況はここでは説明しません。

このモデルでは、次の項目を設定する必要があります。

Unified ICM スクリプトを起動する Unified CM ルート ポイント

タイプ 2 ネットワーク VRU として設定された Unified CVP

Unified CVP への VRU トランスレーション ルート

Unified CVP コール サーバで設定されたトランスレーション ルート Dialed Number Identification Service(DNIS; 着信番号識別サービス)番号

H.323 トランクまたは SIP トランクを使用して設定された Unified CM。

トランスレーション ルート DNIS の Unified CM ルート パターン

このモデルのコール フローは、次のとおりです。

1. 発信者がルート ポイントをダイヤルします。

2. Unified ICM がルーティング スクリプトを起動します。

3. ルーティング スクリプトは、TranslationRouteToVRU ノードを検出し、コールを Unified CVP に転送します(Unified CVP はタイプ 2 ネットワーク VRU として設定されています)。

4. Unified ICM は、トランスレーション ルート ラベルを Unified CM に返します。

5. Unified CM は、ゲートキーパー、DNS SRV、または SIP プロキシに問い合わせて、Unified CVP コール サーバを見つけます。

6. Unified CM は、コールを Unified CVP コール サーバに接続します。

7. Unified CM は、一時的に発信者と Unified CVP H.323 サービスの間の G.711 メディア接続を確立します(H.323 の場合のみ)。

8. ルーティング スクリプトは Select または Label ノードを検出し、ターゲット ラベルを選択します。

9. Unified ICM は、ターゲット ラベルを(ルート要求を発行したデバイスではなく)Unified CVP コール サーバに返します。

10. Unified CVP コール サーバは、ゲートキーパー、DNS SRV、または SIP プロキシに問い合わせて、宛先デバイスを見つけます。

11. Unified CVP コール サーバは、H.323 または SIP を介してターゲット デバイスと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

ここで、ターゲット デバイスが別のルート要求を Unified ICM に発行した場合に何が起こるかについて考えます。コール フローのこの部分は、ステップ 3. で説明した初期の TranslationRouteToVRU がない場合は実行できません。

12. Unified ICM が新しいルーティング スクリプトを起動します。

13. ルーティング スクリプトは Select または Label ノードを検出し、ターゲット ラベルを選択します。

14. Unified ICM は、ターゲット ラベルを(ルート要求を発行したデバイスではなく)Unified CVP コール サーバに返します。

15. Unified CVP コール サーバは、ゲートキーパー、DNS SRV、または SIP プロキシに問い合わせて、宛先デバイスを見つけます。

16. Unified CVP コール サーバは、H.323 または SIP を介してターゲット デバイスと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

モデル #3a:ICM Micro-Apps を使用する包括モデル

モデル #3a には、コール スイッチングと VRU アクティビティの両方が関係します。したがって、コールは Unified CVP スイッチ レッグに転送された後に Unified CVP VoiceXML ゲートウェイに転送される必要があるという点で、モデル #2 とは異なります。このモデルではキューイングが可能であり、基本的なプロンプト/コレクト アクティビティも可能です。

このモデルでは、次の項目を設定する必要があります。

Unified ICM スクリプトを起動する Unified CM CTI ルート ポイント。

タイプ 10 ネットワーク VRU として設定された Unified CVP。

Unified ICM でタイプ 10 ネットワーク VRU によって DN として設定された CTI ルート ポイント。

ネットワーク VRU には、Unified CVP スイッチ レッグ ルーティング クライアント用のラベルが必要です。

ネットワーク VRU ラベルは、ゲートキーパーまたは SIP プロキシで VoiceXML ゲートウェイを指すように設定されている必要があります。

H.323 トランクまたは SIP トランクを使用して設定された Unified CM。

このモデルのコール フローは、次のとおりです。

1. 発信者がルート ポイントをダイヤルします。

2. Unified ICM がルーティング スクリプトを起動します。

3. ルーティング スクリプトは、SendToVRU ノードを検出し、コールを Unified CVP に転送します(Unified CVP はタイプ 10 ネットワーク VRU として設定されています)。

4. Unified ICM は、相関 ID を持つ VRU ラベルを Unified CM に返します。

5. Unified CM は、ゲートキーパー、DNS SRV、または SIP プロキシに問い合わせて、Unified CVP コール サーバを見つけます。

6. コールは Unified CVP コール サーバに接続されます。

7. Unified CM は、一時的に発信者と Unified CVP H.323 サービスの間の G.711 メディア接続を確立します(H.323 の場合のみ)。

8. Unified ICM は、相関 ID を持つ VRU 転送ラベルを Unified CVP コール サーバに送信します。

9. Unified CVP コール サーバは、ゲートキーパー、DNS SRV、または SIP プロキシに問い合わせて、VoiceXML ゲートウェイを見つけます。

10. Unified CVP コール サーバは、H.323 または SIP を介して VoiceXML ゲートウェイと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

11. ルーティング スクリプトは、RunExternalScript ノード経由で 1 つ以上の Unified CVP マイクロアプリケーションを実行し、メディア ファイルを再生し、DTMF 入力を要求し、その他の処理を行います。

12. Unified CVP マイクロアプリケーションが実行中ですが、ターゲット エージェントは使用可能になり、コールを取得します。

13. Unified ICM は、ターゲット エージェントのラベルを判別します。

14. Unified ICM は、ターゲット ラベルを Unified CVP コール サーバに返します。

15. Unified CVP コール サーバは、ゲートキーパー、DNS SRV、または SIP プロキシに問い合わせて、宛先デバイスを見つけます。

16. Unified CVP コール サーバは、H.323 または SIP を介してターゲット デバイスと通信し、VoiceXML ゲートウェイのメディア ストリームを削除して、そのデバイスへのメディア ストリームを確立するように Unified CM に命令します。

ターゲット デバイスが後で別のルート要求を Unified ICM に発行した場合、コール フローは再度、前述したとおりになります。コールは再度、VRU レッグを作成するために、相関 ID とともに SendToVRU を介して Unified CVP コール サーバおよび VoiceXML ゲートウェイに転送される必要があります。マイクロアプリケーションが実行される場合があり、最終的に新しいターゲット ラベルが Unified CVP スイッチ レッグに配信され、スイッチ レッグはコールをそのターゲットに転送します。

モデル #3b:Unified CVP VXML Server を使用する包括モデル

呼制御およびシグナリングに関する限り、モデル #3b はモデル #3a と大きく変わりません。唯一の相違点は、モデル #3b で実行される Unified CVP マイクロアプリケーションに、Unified CVP VXML サーバへのサブダイアログ要求も含まれる場合があることです。コールがキューに格納されている間はセルフサービス アプリケーションは起動されないと考えられます。したがって、Unified ICM ルーティング スクリプト内のエージェント選択ノードまたはキュー ノードは、セルフサービス アプリケーションが完了し、制御が Unified ICM ルーティング スクリプトに戻るまで、延期されると考えられます。

展開の意味

この項では、Unified CM により発生したコールを展開に組み込む際の次の側面について、ガイドラインを示します。

「Unified ICM のコンフィギュレーション」

「ホスト型実装」

「Cisco Unified Communications Manager の設定」

「サイジング」

Unified ICM のコンフィギュレーション

Cisco Unified ICM 7.0 では、Unified CVP で後続の呼制御を実行できるようにする場合、コールを次の宛先に配信する前に、必ずタイプ 2 ネットワーク VRU として設定されている Unified CVP にコールをトランスレーション ルーティングします。これを実行するとハンドオフが作成され、Unified CM はその後のラベルを受信できないため、Unified CVP がコールの後続の転送を管理するようになります。

キューイング処理、プロンプトとコレクト、またはセルフサービス アプリケーションを実行する場合は、常に前述のトランスレーション ルートと SendToVRU ノードに従います。SendToVRU は Queue ノードまたは RunExternalScript ノードによって暗黙的に起動できますが、この方法に頼らないことをお勧めします。実際の SendToVRU ノードを常に含めるようにします。

Cisco Unified ICM 7.1 では、Unified CVP で後続の呼制御を実行できるようにする場合、タイプ 10 ネットワーク VRU を使用するときはトランスレーション ルートは必要ありません。タイプ 10 VRU は、相関 ID メカニズムを使用し、SendToVRU ノードを使用して Unified CM から Unified CVP への転送を実行します。タイプ 10 VRU で SendToVRU ノードが使用されると、Unified CVP への最初の転送によって呼制御は Unified CVP にハンドオフされ、VRU レッグへの 2 番めの転送が自動的に実行されて、コールは IVR 処理のために VoiceXML ゲートウェイに配信されます。


) このコール フローおよびこのマニュアルのその他のすべてのコール フローは、Cisco Unified ICM 7.0(0) 以降を想定しています。


その他のコンフィギュレーション要件については、「プロトコル コール フロー」を参照してください。

ホスト型実装

1 つの ICM ルータから送信されたトランスレーション ルートは、同じ ICM ルータに接続されたペリフェラルによって受信される必要があります。したがって、Unified CVP も CICM レベルで展開されている場合にのみ、Unified CM からのコールを CICM レベルで Unified CVP にトランスレーション ルーティングできます。つまり、ホスト型環境では、すでに他の Unified CVP コール サーバ(コール サーバ)が NAM レベルで存在する場合でも、コール サーバを CICM レベルでプロビジョニングする必要があります。VoiceXML ゲートウェイおよびゲートキーパーは共有できます。

この項目の詳細については、「Cisco Unified ICM との対話」の章を参照してください。

Cisco Unified Communications Manager の設定

Unified CM のコンフィギュレーションには、次のガイドラインが適用されます。

ゲートキーパーによって制御される H.323 トランクまたは SIP トランクを設定します。Unified CVP 4.1 以降のリリースでは、H.323 トランクに MTP は必要なくなりました。ゲートキーパーを設定して、このトランクを使用する Unified CM にコールを送信します。

トランスレーション ルート DNIS または相関 ID が付加された VRU ラベル用の適切なルート パターンを設定します。タイプ 10 VRU では相関 ID 方式が使用され、追加の桁を付加(たとえば、ルート パターンの終わりに ! を追加)できるように Unified CM のルート パターンを設定する必要があります。

エージェント ラベルを設定するときは、どのデバイスがルーティング クライアントかを考慮します。ラベルが Unified CM に直接返される場合、Unified CM がルーティング クライアントである必要があります。ラベルが Unified CVP に送信される場合は、個々の Unified CVP スイッチ レッグ コール サーバにラベルを関連付ける必要があります。

ゲートキーパーまたは SIP プロキシのダイヤル プランのコンフィギュレーション

ゲートキーパーまたは SIP プロキシを使用している場合、Unified CM ルーティング クライアントに関連付けられている VRU ラベルは、Unified CVP ルーティング クライアントに関連付けられている VRU ラベルとは異なるものである必要があります。これは、Unified CM により発生したコールの VRU ラベルの目的は、最初に呼制御をハンドオフするためにコールを Unified CVP コール サーバに送信することであるのに対し、Unified CVP がすでにルーティング クライアントであるコールの VRU ラベルの目的は、処理のために VXML ゲートウェイに送信されることであるためです。呼制御をハンドオフするためにコールが Unified CVP に送信されると、Unified CVP は Unified CVP ルーティング クライアントに関連付けられている VRU ラベルへの後続の転送を実行し、処理するためにコールを VXML ゲートウェイに配信します。

ゲートキーパーまたは SIP プロキシのダイヤル プランは、次のように構成する必要があります。

(Unified CM ルーティング クライアントの VRU ラベル + 相関 ID):CVP Server を指す

(CVP ルーティング クライアントの VRU ラベル + 相関 ID):VXML ゲートウェイを指す

Cisco ゲートキーパーおよび Cisco SIP プロキシ サーバについては、「Cisco ゲートキーパー」および「SIP プロキシ サーバ」を参照してください。

サイジング

ほとんどの顧客実装は、Unified CM により発生したコールを優先して設計されているわけではありません。主要な対象は一般に顧客からの着信コールですが、Unified CM により発生したコールが構成要素である場合が多くあります(特にウォーム転送の場合)。装置のサイジングでは、それらのコールを考慮してください。

ゲートウェイ

Unified CM により発生したコールでは、入力ゲートウェイは使用されません。コールは Unified CM から Unified CVP コール サーバに直接配信されます。ただし、VRU レッグが使用される場合は、VoiceXML ゲートウェイが使用されます。したがって、VoiceXML ゲートウェイのサイジングでは、キュー内にある、またはセルフサービス アクティビティを実行している個々の Unified CM コールを考慮してください。

KPML のサポート

KPML は、RTP ストリームではなく SIP シグナリングによってキー押下情報を渡すアウトオブバンド dtmf 方式です。

通常の Unified CVP の包括コール フローでは、インバンド RFC2833 DTMF コンフィギュレーションがエンドポイントで使用されます。ただし、インバンド RFC2833(7985 ビデオ電話など)および UCCE モバイル エージェント展開で使用される CTI ポートをサポートしないエンドポイントがいくつかあります。

これらのエンドポイントについては、SIP トランクの背後の宛先が RFC2833 によって設定されている場合、回線側およびトランク側ではインバンド パケットから DTMF のアウトオブバンド シグナリング メッセージへの変換が必要であるため、Cisco Unified CM は MTP リソースを割り当てます。

MTP 割り当てを回避するには、SIP KPML DTMF 方式(つまり、初期設定なしという設定)を使用して SIP トランクの宛先を設定する必要があります。また、VXML ブートストラップ ダイヤル ピアには SIP および KPML 設定が必要です。

Unified CVP SIP サブシステムは、KPML DTMF 番号(アウトオブバンド DTMF)に関連する Subscribe および Notify イベントをパススルーできます。

UCM トランク上の MTP の使用

Unity Voice Mail や Mobile Agent などの特定の固有のコール フローで UCM SIP トランクを使用する場合は、MTP リソースの使用に要件がある場合があります。

エンドポイントのネゴシエートされたメディア機能(たとえば、DTMF インバンドとアウトオブバンド機能)が合致しない場合に、この要件が発生します。この場合、DTMF メディア機能が合致しないため、UCM は MTP を動的に割り当てることがあります。

サードパーティ製のデバイスと同時に使用する場合は、MTP も必要になる場合があります。

設計上の考慮事項

KPLM 機能を使用する場合、次の制限が適用されます。

1. ダイヤルピアで SIP に対して KPML を設定した場合、同じダイヤルピアを H.323 に対して使用できません。別のブートストラップ DP を同じパターンで設定でき、それを優先して H.323 コールを処理できます。

2. KPML では ASR/TTS はサポートされていません

ゲートウェイに KPML が設定されている場合は、DTMF の初期設定なしという設定に対して、SIP トランクを設定する必要があります。SIP トランクが Cisco Unified Presence Server(CUP Server)または Unified CVP を直接指している場合でも、DTMF 設定を初期設定なしに設定する必要があり(Unified CVP B2BUA がコールの途中であるため)、SDP 属性は VXML ゲートウェイから直接発信されたかのようにパススルーされます。