この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
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 により発生したコールとは異なる処理が必要です。
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 コール フローについて説明します。
(注) |
Unified CM により発生したコールに関係する NIC はないため、モデル #4(NIC 制御ルーティングのみを使用する VRU)についてはここでは説明しません。 |
モデル #1 には Unified ICM は関係しません。 このモデルは、Unified CM ユーザが Unified CVP VoiceXML ゲートウェイに接続する電話番号をダイヤルし、Unified CVP VXML Server アプリケーションを起動したときに発生します。 VoiceXML ゲートウェイは、Unified CM で SIP トランクとして設定されます。 このモデルのコール フローは、次のとおりです。
(注) |
スクリプトは、TDM 宛先に対してでない限り、Transfer ノードを実行できません。 IP 宛先への転送は IP-to-IP コール(サポート対象)になりますが、別の VoIP 宛先への転送操作が成功するように、ip-ip-gw コマンド(CUBE コマンド)をゲートウェイ コンフィギュレーションに追加する必要があります。 |
モデル #2 には VRU レッグはなく、すべてスイッチングです。 したがって、Unified CM により発生したコールは、常にターゲットに直接配信されるか、拒否されます。 キューイングまたはセルフサービスは関係しません。
このモデルでは、コールが Unified CM から発生することを想定しています。 このモデルでは、もともとは Unified CVP 入力ゲートウェイを介して着信し、Unified CM に転送されて、現在は再度転送されているコールは除外されます。 通常は Unified CM 自体がこれらの転送を処理できるため、このような状況はまれです。 ただし、ターゲットが Unified CM 以外の ACD である場合などの例外がありますが、そのような状況はここでは説明しません。
モデル #3a には、コール スイッチングと VRU アクティビティの両方が関係します。 したがって、コールは Unified CVP スイッチ レッグに転送された後に Unified CVP VoiceXML ゲートウェイに転送される必要があるという点で、モデル #2 とは異なります。 このモデルではキューイングが可能であり、基本的なプロンプト/コレクト アクティビティも可能です。
ターゲット デバイスが後で別のルート要求を Unified ICM に発行した場合、コール フローは再度、前述したとおりになります。 コールは再度、VRU レッグを作成するために、相関 ID とともに SendToVRU を介して Unified CVP コール サーバおよび VoiceXML ゲートウェイに転送される必要があります。 マイクロアプリケーションが実行される場合があり、最終的に新しいターゲット ラベルが Unified CVP スイッチ レッグに配信され、スイッチ レッグはコールをそのターゲットに転送します。
呼制御およびシグナリングに関する限り、モデル #3b はモデル #3a と大きく変わりません。 唯一の相違点は、モデル #3b で実行される Unified CVP マイクロアプリケーションに、Unified CVP VXML サーバへのサブダイアログ要求も含まれる場合があることです。 コールがキューに格納されている間はセルフサービス アプリケーションは起動されないと考えられます。 したがって、Unified ICM ルーティング スクリプト内のエージェント選択ノードまたはキュー ノードは、セルフサービス アプリケーションが完了し、制御が Unified ICM ルーティング スクリプトに戻るまで、延期されると考えられます。
(注) |
このコール フローおよびこのマニュアルのその他のすべてのコール フローは、Cisco Unified ICM 7.0(0) 以降を想定しています。 |
1 つの ICM ルータから送信されたトランスレーション ルートは、同じ ICM ルータに接続されたペリフェラルによって受信される必要があります。 したがって、Unified CVP も CICM レベルで展開されている場合にのみ、Unified CM からのコールを CICM レベルで Unified CVP にトランスレーション ルーティングできます。 つまり、ホスト型環境では、すでに他の Unified CVP コール サーバ(コール サーバ)が NAM レベルで存在する場合でも、コール サーバを CICM レベルでプロビジョニングする必要があります。
この項目の詳細については、Cisco Unified ICM の対話の章を参照してください。
Unified CM のコンフィギュレーションには、次のガイドラインが適用されます。
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 SIP プロキシ サーバについては、SIP プロキシ サーバを参照してください。
ほとんどの顧客実装は、Unified CM により発生したコールを優先して設計されているわけではありません。 主要な対象は一般に顧客からの着信コールですが、Unified CM により発生したコールが構成要素である場合が多くあります(特にウォーム転送の場合)。 装置のサイジングでは、それらのコールを考慮してください。
Unified CM により発生したコールでは、入力ゲートウェイは使用されません。 コールは Unified CM から Unified CVP コール サーバに直接配信されます。 ただし、VRU レッグが使用される場合は、VoiceXML ゲートウェイが使用されます。 したがって、VoiceXML ゲートウェイのサイジングでは、キュー内にある、またはセルフサービス アクティビティを実行している個々の Unified CM コールを考慮してください。
KPML は、RTP ストリームではなく SIP シグナリングによってキー押下情報を渡すアウトオブバンド DTMF 方式です。
通常の Unified CVP の包括コール フローでは、インバンド RFC2833 DTMF コンフィギュレーションがエンドポイントで使用されます。 ただし、インバンド RFC2833(7985 ビデオ電話など)および UCCE モバイル エージェント展開で使用される CTI ポートをサポートしないエンドポイントがいくつかあります。
これらのエンドポイントについては、SIP トランクの背後の宛先が RFC2833 によって設定されている場合、回線側およびトランク側ではインバンド パケットから DTMF のアウトオブバンド シグナリング メッセージへの変換が必要であるため、Cisco Unified CM は MTP リソースを割り当てます。
MTP 割り当てを回避するには、SIP KPML DTMF 方式(つまり、初期設定なしという設定)を使用して SIP トランクの宛先を設定する必要があります。 また、VoiceXML ブートストラップ ダイヤル ピアには SIP および KPML 設定が必要です。
Unified CVP SIP サブシステムは、KPML DTMF 番号(アウトオブバンド DTMF)に関連する Subscribe および Notify イベントをパススルーできます。
Unity Voice Mail や Mobile Agent などの特定の固有のコール フローで UCM SIP トランクを使用する場合は、MTP リソースの使用に要件がある場合があります。
エンドポイントのネゴシエートされたメディア機能(たとえば、DTMF インバンドとアウトオブバンド機能)が合致しない場合に、この要件が発生します。 この場合、DTMF メディア機能が合致しないため、UCM は MTP を動的に割り当てることがあります。
ゲートウェイに KPML が設定されている場合は、DTMF の初期設定なしという設定に対して、SIP トランクを設定する必要があります。 SIP トランクが Unified CVP を直接指している場合、DTMF 設定を初期設定なしに設定します(Unified CVP B2BUA がコール中であるため)。SDP 属性は VoiceXML ゲートウェイから直接発信されたかのようにパススルーされます。