Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）リリース 9.0(1)

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。

マニュアルのコンテンツ
このマニュアル内で検索
ご利用いただける言語
Download Options

Book Title

Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）リリース 9.0(1)

Chapter Title

コール転送オプション

検索結果

Updated:
2017年6月27日

章のタイトル： コール転送オプション

目次

 

コール転送のための設計は、Unified CVP 展開を設計するときに必要な主要ステップの 1 つです。 Unified CVP では、多数の転送オプションを使用できます。 この章は、各種オプションについて説明し、それぞれに関連する利点、欠点、および考慮事項を示すことを目的としています。

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

新規または変更された章の情報

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

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

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

説明

この章には、SRND の 2012 年 7 月 6 日のバージョンに関する新規トピックはありません。

解放トランク転送

この項では、入力トランクを解放し、呼制御ループからゲートウェイと Unified CVP を削除する転送のタイプを取り上げます。 このような場合、トロンボーニングはありません。 これらの転送の特徴は次のとおりです。

  • 解放トランク転送は、Unified CVP VXML Server（スタンドアロン モデル）によって呼び出すか、または Unified ICM を使用して呼び出すことができます。
  • Unified ICM ネットワーク転送で Unified CVP をルーティング クライアントとして使用した場合、Unified CVP で呼制御を実行できなくなり、転送は機能しません。
  • これらの転送はブラインドです。つまり、何らかの理由で転送に失敗した場合、Unified ICM は呼制御を回復しません。 ルータ再クエリーはサポートされていません。
  • Unified ICM レポートの観点から見ると、解放トランク転送によりスイッチ レッグが終了し、その結果として、発信者がエージェントと引き続き通話している可能性があっても、TCD レコードがコール用のデータベースに書き込まれます。 この動作は他のタイプの転送とは異なります。他のタイプの転送では、発信者が実際に電話を切るまで、TCD レコードはファイナライズされません。
  • 入力トランクは解放されるため、この方法で転送されたコールを対象に含めるようにゲートウェイのサイズを調整する必要はありません。 この動作は他のタイプの転送とは異なります。他のタイプの転送では、発信者が電話を切るまで、ゲートウェイ リソースは占有され続けます。
  • Unified CVP はコールをモニタしなくなるため、この方法で転送されたコールを対象に含めるように Unified CVP コール サーバのサイズを調整する必要はありません。 また、Unified CVP コール ディレクタ ポート ライセンスは不要です。

次の 3 つのシグナリング メカニズムを使用して、解放トランク転送をトリガーできます。

Take Back and Transfer

TNT（転送接続とも呼ばれる）は、一部の米国の PSTN サービス プロバイダーによって提供される転送メカニズムです。 この転送方法では、Unified CVP によって DTMF トーンが PSTN にアウトパルスされます。 これらのインバンド トーンは、PSTN に対するシグナリング メカニズムとして機能し、転送を完了するように要求します。 一般的な DTMF シーケンスは *8xxxx です。xxxx は、PSTN で認識できる新しいルーティング ラベルを表します。 TNT DTMF シーケンスを検出すると、PSTN は入力ゲートウェイ ポートへのコール レッグをドロップし、発信者を新しい PSTN ロケーション（TDM ACD ロケーションなど）に再ルーティングします。

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、この動作が必要になることがあります。 その後必要であれば、エージェントを TDM ACD から Unified CCE に移行し、Unified CVP を IVR、キューイング ポイント、および転送ピボット ポイントとして使用できます（これにより、TNT サービスが不要になります）。

Unified CVP 展開で ICM を使用した場合、別の Unified ICM ペリフェラル（TDM ACD など）へのコール データの引き渡しを可能にするために、DTMF ルーティング ラベルが Unified ICM トランスレーション ルーティング ラベルとしてアウトパルスされる可能性があります。 このシナリオでは、Unified CVP はコールを完了と見なし、Unified CVP 呼制御は終了します。 TNT を使用している場合、ターミネーション ポイントまでの転送に失敗すると、Unified CVP はコールの再ルーティング処理を何も行うことができません。 一部の TNT サービスはコールを再ルーティングして Unified CVP に戻すことができますが、Unified CVP はこのコールを新しいコールと見なします。

フックフラッシュとウィンク

フックフラッシュとウィンクは、通常 TDM PBX または ACD に関連するシグナリング メカニズムです。 フックフラッシュはアナログ トランクにのみ適用され、ウィンクはデジタル トランク（T1 または E1 チャネル）にのみ適用されますが、機能的にはほぼ同じです。 フックフラッシュとウィンクはどちらも、オンフック信号またはオフフック信号を PBX または ACD に送信し、PBX または ACD はダイヤル トーンで応答します（あるいは、PBX がデジタル トランクに対してウィンクを返します）。 このシグナリングでは、音声ゲートウェイがルーティング ディジットの文字列を PBX または ACD に送信します。 ルーティング ディジットを収集すると、PBX または ACD は発信者を新しいターミネーションに転送します。このターミネーションは、同じ PBX または ACD 上の ACD キューまたはサービスになることもあります。

IVR のない既存の ACD 環境で、Unified CVP を最初は IVR として使用し、その IVR を既存の PBX または ACD の回線側に論理的に設置する場合は、この動作が必要です。 その後必要であれば、エージェントを TDM ACD から Cisco Unified CCE に移行し、PBX または ACD の回線側の代わりに PSTN に音声ゲートウェイを接続できます。 Unified CVP 展開で Unified ICM を使用した場合、ルーティング ラベルは Unified ICM トランスレーション ルーティング ラベルになる可能性があります。 このラベルにより、ACD サービス（それに続けてエージェントの画面ポップ）へのコール データの引き渡しが可能になります。 フックフラッシュとウィンクを使用している場合、ターミネーション ポイントまでの転送に失敗すると、Unified CVP はコールの再ルーティング処理をも行うことができません。 一部の PBX または ACD モデルはコールを再ルーティングして Unified CVP に戻すことができますが、Unified CVP はこのコールを新しいコールと見なします。

この機能のサポートは PBX とゲートウェイによって制約されているため、フックフラッシュ転送はこれまで当てになりませんでした。 可能な限り、Unified ICM スイッチングに PBX を使用することは避け、すべての着信コールを PBX ではなく Unified CVP 入力ゲートウェイで終了してください。これにより、Unified CVP から PBX にコールをルーティングできるようになります（この逆ではありません）。

ただし、フックフラッシュ転送が必要な場合は、次のガイドラインと注意事項が適用されます。

  • Cisco 1700 シリーズ ゲートウェイでは、フックフラッシュ転送のテストが行われていません。
  • Cisco 2800 および 3800 シリーズ ゲートウェイでは、アナログ FXO またはデジタル FXO（T1/CAS）をサポートできます。 この機能は、PBX に対する回線側フックフラッシュと見なされ、Avaya Definity G3 でのテストでも適切に動作しました （ただし、現時点では E&M はサポートされていません）。voice-port で timing hookflash-out コマンドを使用して、フックフラッシュ期間を調整できます。 この機能は、フックフラッシュ期間の設定ができない PBX を使用している場合に役立ちます。また、この機能を使用すると、ゲートウェイ側でフラッシュバック期間を調整できます。
  • Cisco 5x00 シリーズ ゲートウェイは、T1/CAS および e&m-fgb dtmf dnis コマンドを使用してテストされました。 E&M は、PBX に対する「トランク側フックフラッシュ」と見なされます。すべてのスイッチでトランク側フックフラッシュがサポートされているわけではありません（Avaya Definity G3 ではサポートされていません）。 また、Cisco 5x00 シリーズ ゲートウェイでのフックフラッシュ期間は 200 ms であり、PBX の期間設定もこれと同じにする必要があります。 このオプションはスイッチ タイプによって異なり、スイッチ ベンダーとの間で概念実証を実施することを強く推奨します。
  • 展開モデル #1 のスタンドアロン セルフサービスでは、フックフラッシュの生成に TCL スクリプトが必要になります。 TCL スクリプトは Unified CVP に付属しています。
  • Digital FXO（T1 CAS）トランクの場合、Unified CVP に到達するコールでは Automatic Number Identification（ANI; 自動番号識別）は使用できません。 Unified CVP 展開モデルによっては、コールがプレルーティング済みであれば、ICM ですでに ANI が認識されていることがあります。
  • Digital FXO（T1 CAS）トランクの場合は、コールが到達する T1/E1 チャネルに基づいて、Dialed Number Identification Service（DNIS; 着信番号識別サービス）をゲートウェイに設定する必要があります。 PBX は、特定の T1 トランク上で特定の DNIS コールをルーティングするようにプログラムされています。 コールはそのトランクでゲートウェイに到達するため、その DNIS は断定的に設定できます。 このアプローチの欠点は、ゲートウェイ トランクの配分を事前に決定する必要がある点です。 何パーセントのコールがどの DNIS に到達するかを把握して、それに応じてゲートウェイのトランク グループを配分できるようにする必要があります。 一部の PBX では、「converse on ステップ」という代替の方法を使用できます。この方法を使用すると、DNIS および ANI を示す DTMF トーンが IVR に送信されます。 この方法では、単一のメイン Unified ICM ルーティング スクリプトを使用して、Get Data（GD）マイクロアプリケーションによって DNIS ディジットを入力し、収集した DNIS ディジットに基づいて正しいサブスクリプトを呼び出す必要があります。 この方法では、シスコ、PBX ベンダー、およびユーザとの間で緊密な連携が求められます。また、この方法はまだテストされていません。
  • Cisco 5x100 シリーズ ゲートウェイの FGB E&M トランクの場合は、デリミタとして「*」を使用すれば、ANI および DNIS を送信できます。 たとえば、*ANI*DNIS* のようにします。 設定の詳細については、http:/​/​www.cisco.com/​en/​US/​customer/​docs/​ios/​12_1t/​12_1t1/​feature/​guide/​anidnis.html からオンラインで入手可能な『ANI/DNIS Delimiter for CAS Calls on CT1』を参照してください。

SIP フックフラッシュのサポート

フックフラッシュは、通常 TDM PBX または ACD に関連するシグナリング メカニズムです。 エンドポイントはオンフック信号またはオフフック信号を PBX または ACD に送信し、PBX または ACD はダイヤル トーンで応答します。 このシグナリングでは、音声ゲートウェイがルーティング ディジットの文字列を PBX または ACD に送信します。 ルーティング ディジットを収集すると、PBX または ACD は発信者を新しいターミネーションに転送します。このターミネーションは、同じ PBX または ACD 上の ACD キューまたはサービスになることもあります。

SIP フックフラッシュ機能では、Unified CVP で hook flash、DTMF 宛先の順に指定して SIP コールを転送できます。 この機能を使用すると、PBX を Unified CVP 入力ゲートウェイのフロントエンドにするという展開が可能になります。また、PBX でエージェントへの非 VoIP 接続を提供できます。

一般的な使用例では、発信者がシステムにコールを行い、TDM ACD に関連付けられているエージェントに転送されます。 Unified CCE は、発信者が正しいエージェントにルーティングされるように、Unified CVP のラベルを返して PSTN に対するフックフラッシュ転送を実行します。 返されるラベルでは、フックフラッシュ ルーティング ディジットの前に HF が付加されます。 発信者がエージェントに転送され、Unified CVP は呼制御を実行しなくなります。

設計上の考慮事項

SIP フックフラッシュ機能を使用する場合、次の制限事項が適用されます。

  • この機能は、2X および 3X ゲートウェイでのみサポートされています。 5X ゲートウェイ（たとえば 5400XM）ではサポートされていません。
  • フックフラッシュは、TDM から発信されるコールにのみ適用されます。 フックフラッシュが Unified CVP によって呼び出されると、Unified CVP は呼制御を実行しなくなります。

Two B Channel Transfer

TBCT は、一部の PSTN サービス プロバイダーが提供している ISDN ベースの解放トランク シグナリング メカニズムです。 TBCT が呼び出されると、入力ゲートウェイは、別のコール レッグ（ISDN B チャネル）を使用してターミネーション ポイントに対するコールを行っている間、一時的に最初の着信コールを保留にします。 ターミネーション ポイントがコールに応答すると、ゲートウェイは ISDN シグナリングを PSTN スイッチに送信することで、転送を完了し、PSTN スイッチを介してコールをブリッジングして入力ゲートウェイから削除するように要求します。 TNT 転送では、ターミネーション ポイントは、PSTN に接続されている TDM PBX または ACD です。

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、この動作が必要になることがあります。 その後必要であれば、エージェントを TDM ACD から Cisco Unified CCE に移行し、Unified CVP を IVR、キューイング ポイント、および転送ピボット ポイントとして使用できます（これにより、TBCT サービスが不要になり、転送失敗時に Unified CVP を使用して再ルーティングを実行できるようになります）。

ICM 管理転送

ほとんどの Unified CVP ユーザは Unified ICM 管理転送を使用します。 Unified CVP は、この機能をほぼ必然的に実行し、Unified ICM および Unified CCE 設置環境にゲートウェイベースのスイッチングを提供します。

Unified CVP 展開で Unified ICM を使用した場合、Unified ICM はすべての呼制御を提供します。 Unified ICM を Unified CVP とともに展開した場合、Unified CVP VXML Server からの VoiceXML 呼制御はサポートされません。

Unified ICM 管理転送は、次のいずれかの新しいターミネーション ポイントにコールを転送します。

  • Cisco Unified Communications Manager 電話機
  • 入力ポートと同じゲートウェイ上の出力ポート
  • TDM によって TDM ACD または PBX に接続する遠隔出力ゲートウェイ（トール バイパス機能を利用）
  • キューイングまたはセルフサービス アクティビティ用の Unified CVP VoiceXML ゲートウェイ

音声ゲートウェイは、コールを終了するために、Unified ICM で指定された宛先に基づいて発信 POTS または VoIP ダイヤルピアを選択します。 Unified ICM VoIP 転送が行われても、入力音声ゲートウェイ ポートは解放されません。 ターミネーション ポイントが出力音声ゲートウェイの場合は、別の音声ゲートウェイ ポートが利用されます。 Unified CVP はコールを引き続きモニタし、Unified ICM も呼制御を維持し、Unified CVP に対してコールを新しい宛先に転送するように命令できます。

Unified CVP をコール処理プラットフォームおよび Unified CCE エージェントのキューイング ポイントとして使用する場合、このタイプの転送を使用します。 また、Unified CVP を使用して、Unified ICM によってサポートされている TDM ACD ロケーションへのフロントエンド コールにコール処理を提供することもできます。 このタイプの転送を使用すると、完全なコール コンテキストによって、Unified ICM でサポートされているペリフェラル間でコールを転送できます。音声パスを返す必要はありません。

この方法で転送されるコールには、次のような特徴があります。

  • Unified ICM ネットワーク転送で Unified CVP をルーティング クライアントとして使用した場合、Unified CVP は呼制御を続行するため、転送は正しく機能します。
  • これらの転送は監視されます。つまり、何らかの理由で転送に失敗した場合、Unified ICM ルーティング スクリプトはルータ再クエリー メカニズムを使用して制御を回復します。
  • Unified ICM レポートの観点から見ると、発信者が実際に電話を切るまで、スイッチ レッグは終了しません。 したがって、コールのスイッチ レッグに関して書き込まれる TCD レコードは、最初の入力から切断までの全コール期間を対象としています。
  • 入力トランクは解放されないため、この方法で転送されたコールを対象に含めるようにゲートウェイのサイズを調整する必要があります。
  • Unified CVP はコールを引き続き監視するため、この方法で転送されたコールを対象に含めるように Unified CVP コール サーバのサイズを調整する必要があります。 また、Cisco Unified Communications Manager エージェントに接続されるコールを除き、Unified CVP コール ディレクタ ポート ライセンスが必要になります。

ネットワーク転送

Unified CVP には、エージェントによる応答後に、別の宛先へコールを転送する機能が備わっています。 この機能はネットワーク転送と呼ばれます。

コールが Unified CVP からエージェントに転送され、そのエージェントがコールを別のエージェントに転送する必要がある場合、エージェントはエージェント IP 電話またはエージェント デスクトップのいずれかを使用してその転送処理を行うことができます。 IP 電話からの転送は、Unified ICME スクリプトを指し示す CTI ルート ポイントを使用して行われます。 エージェント デスクトップからの転送は、着信番号計画を使用して行われます。

Unified ICME でネットワーク転送を制御する場合、次の 2 つのフラグを使用します。

  • NetworkTransferEnabled：Unified ICME スクリプトのフラグです。 有効にすると、Unified ICM によって最初のルーティング クライアント（NewCall ルート要求を送信したルーティング クライアント）に関する情報が保存されます。
  • NetworkTransferPreferred：このフラグは Unified CVP PG コンフィギュレーションでチェックされます。 チェックされると、このルーティング クライアント（Unified ICME が最初のルーティング クライアントを認識しているもの）からルート要求があると、そのルート要求を送信したルーティング クライアントではなく、最初のルーティング クライアントにルート応答が送信されます。

ネットワーク転送を使用する場合、次の推奨事項が適用されます。

  • ネットワーク転送で上記の 2 つのフラグを使用する場合、Unified CVP を介してエージェント 1 からエージェント 2 までのブラインド転送のみを実行できます。 この場合、Unified CVP は、Unified ICME から命令を収集し、エージェント 1 からコールを戻し、それを VoiceXML ゲートウェイ（IVR 処理用）または別の宛先（エージェント 2 など）にルーティングします。
  • エージェント 1 がコンサルテーションまたは会議を行っている間、エージェント 1 へのコール レッグはアクティブである必要があるため、ネットワーク転送を使用して Unified CVP との間でウォーム転送または会議を行うことはできません。 ウォーム転送または会議の間、Unified CVP はエージェント 1 からコールを戻すことはできません。

発信者がブラインド転送、ウォーム転送、または会議とは関係なく同じ番号にダイヤルする場合は、次の推奨事項およびベスト プラクティスを使用できます。

  • Unified ICME スクリプトで NetworkTransferEnable フラグを有効にしないでください。
  • エージェントからの転送または会議要求では、同じ Unified CCE PG の CTI ルート ポイントをダイヤルして、転送中にコール コンテキストが維持されるようにする必要があります。 別の PG のルート パターンまたは CTI ルート ポイントをダイヤルすると、コール コンテキストが維持されません。
  • 常に SendToVru を Unified ICME ルーティング スクリプトの最初のノードとして使用してください。
  • 予備ポートがコンサルテーション、ブラインド転送、または会議中に使用されます。 これらのポートは、発信側のコンサルテーションが終了した場合にのみ解放されます。

SIP Refer 転送

シナリオによっては、Unified CVP でコールを SIP 宛先に転送し、Unified ICM と Unified CVP で今後の呼制御が維持されないようにすることが望ましい場合もあります。 Unified CVP では SIP Refer 転送を実行できます。この転送では、Unified CVP がそれ自体をコールから削除して、認可された Unified CVP ポートを解放できます。 入力音声ゲートウェイ ポートは、発信者または終端装置がコールを解放するまで、引き続き使用された状態のままです。 SIP Refer 転送は、包括展開とコール ディレクタ展開のどちらにも使用できます。

SIP Refer 転送は、次のいずれかの方法で呼び出すことができます。

  • Unified ICM が Unified CVP に rfXXXX という形式（rf5551000 など）のルーティング ラベルを送信します。
  • アプリケーション制御の代替方法として、Unified ICM スクリプトの ECC 変数（user.sip.refertransfer）を値 y に設定し、その変数を Unified CVP に送信します。

    （注）  

    Refer の前に Send To VRU ノードを使用する場合のみ、ラベルを使用した直接の Refer 転送が機能します。

Unified CVP キュー処理が発信者に提供されたら、SIP Refer 転送を呼び出すことができます。 SIP Refer 転送は、Cisco Unified Communications Manager または他の SIP エンドポイント（SIP 対応 ACD など）に対して実行できます。

SIP を Unified CVP とともに使用している場合、Refer 転送に失敗してもルータ再クエリーがサポートされます。ただし、対象となるのは、存続可能性サービスが SIP Refer 要求を処理しないコールのみです。

インテリジェント ネットワーク解放トランク転送

展開モデル #4（NIC 制御ルーティングのみを使用する VRU）を使用しているユーザは、Unified CVP が関係しないコール スイッチング方式に依存しています。 こういった状況では、すべてのスイッチング命令が Unified ICM ネットワーク インターフェイス コントローラ（NIC）と PSTN 間で直接交換されます。 このような NIC インターフェイスの例としては、Signaling System 7（SS7）や Call Routing Service Protocol（CRSP）などがあります。 PGW デバイスが関係する展開では、SS7 NIC は PGW に対するインターフェイスとしても使用されます。 そのため、PGW 展開では、このタイプの転送を実行します。

VoiceXML 転送

VoiceXML 呼制御は、Unified CVP VXML Server によって呼制御が提供されるスタンドアロン Unified CVP 展開（展開モデル #1）でのみサポートされています。 展開モデル #3b にも Unified CVP VXML Server が組み込まれていますが、このモデルでは VoiceXML 呼制御はサポートされていません。 これらの展開だけでなく、すべての Unified ICM 統合展開において、Unified ICM で呼制御のすべての決定を行う必要があります。

Unified CVP VXML Server では、3 つのタイプの転送（解放トランク転送、VoiceXML ブラインド転送、および VoiceXML ブリッジド転送）を呼び出すことができます。 解放トランク転送を使用すると、着信コールが入力音声ゲートウェイから解放されます。 VoiceXML ブラインド転送を使用すると、コールが出力音声ゲートウェイまたは VoIP エンドポイントにブリッジングされますが、Unified CVP VXML Server によって以降のすべての呼制御が解放されます。 VoiceXML ブリッジド転送を使用すると、コールが出力音声ゲートウェイまたは VoIP エンドポイントにブリッジングされますが、Unified CVP VXML Server で呼制御が維持され、発信者を IVR アプリケーションに戻したり、発信者を別のターミネーション ポイントに転送したりできます。

Unified CVP VXML Server からの解放トランク転送は、subdialog_return 要素を使用して呼び出されます。 Unified CVP VXML Server では、TNT 転送、Two B Channel Transfer、フックフラッシュ/ウィンク転送、および SIP Refer 転送を呼び出すことができます。 TDM 解放トランク転送（TNT、TBCT、およびフックフラッシュ/ウィンク）の場合、VoiceXML ゲートウェイと入力ゲートウェイを組み合わせて、解放トランク転送が機能するようにする必要があります。

VoiceXML ブラインド転送およびブリッジド転送は、Cisco Unified Call Studio で Transfer 要素を使用して呼び出されます。 VoiceXML 転送では、ゲートウェイに設定されているダイヤルピアにコールが転送されます。

VoiceXML ブラインド転送と VoiceXML ブリッジド転送の相違点は次のとおりです。

  • VoiceXML ブラインド転送ではコール進捗の監視はサポートされていません。ブリッジド転送ではサポートされています。 つまり、ブラインド転送に失敗した場合、Unified CVP VXML Server スクリプトは制御を回復せず、別の宛先を試すことも、是正措置を取ることもできません。
  • VoiceXML ブラインド転送を使用した場合、Unified CVP VXML Server スクリプトが終了します。 常にブラインド転送ノードの「done exit」分岐を subdialog_return ノードと hang-up ノードに接続してください。

ブリッジド転送では、スクリプトを終了しません。 Unified CVP VXML Server は、入力コールまたは宛先コールが終了するまで待機します。 スクリプトが終了するのは、入力コール レッグが切断された場合のみです。 宛先コール レッグが最初に切断されると、スクリプトは制御を回復し、追加のセルフサービス アクティビティを続行します。 スクリプトが実際に処理を実行していない場合でも、ブリッジド転送の期間中は、Unified CVP VXML Server ポート ライセンスは引き続き使用された状態のままになることに注意してください。

 

コール転送のための設計は、Unified CVP 展開を設計するときに必要な主要ステップの 1 つです。 Unified CVP では、多数の転送オプションを使用できます。 この章は、各種オプションについて説明し、それぞれに関連する利点、欠点、および考慮事項を示すことを目的としています。

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

新規または変更された章の情報

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

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

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

説明

この章には、SRND の 2012 年 7 月 6 日のバージョンに関する新規トピックはありません。

解放トランク転送

この項では、入力トランクを解放し、呼制御ループからゲートウェイと Unified CVP を削除する転送のタイプを取り上げます。 このような場合、トロンボーニングはありません。 これらの転送の特徴は次のとおりです。

  • 解放トランク転送は、Unified CVP VXML Server（スタンドアロン モデル）によって呼び出すか、または Unified ICM を使用して呼び出すことができます。
  • Unified ICM ネットワーク転送で Unified CVP をルーティング クライアントとして使用した場合、Unified CVP で呼制御を実行できなくなり、転送は機能しません。
  • これらの転送はブラインドです。つまり、何らかの理由で転送に失敗した場合、Unified ICM は呼制御を回復しません。 ルータ再クエリーはサポートされていません。
  • Unified ICM レポートの観点から見ると、解放トランク転送によりスイッチ レッグが終了し、その結果として、発信者がエージェントと引き続き通話している可能性があっても、TCD レコードがコール用のデータベースに書き込まれます。 この動作は他のタイプの転送とは異なります。他のタイプの転送では、発信者が実際に電話を切るまで、TCD レコードはファイナライズされません。
  • 入力トランクは解放されるため、この方法で転送されたコールを対象に含めるようにゲートウェイのサイズを調整する必要はありません。 この動作は他のタイプの転送とは異なります。他のタイプの転送では、発信者が電話を切るまで、ゲートウェイ リソースは占有され続けます。
  • Unified CVP はコールをモニタしなくなるため、この方法で転送されたコールを対象に含めるように Unified CVP コール サーバのサイズを調整する必要はありません。 また、Unified CVP コール ディレクタ ポート ライセンスは不要です。

次の 3 つのシグナリング メカニズムを使用して、解放トランク転送をトリガーできます。

Take Back and Transfer

TNT（転送接続とも呼ばれる）は、一部の米国の PSTN サービス プロバイダーによって提供される転送メカニズムです。 この転送方法では、Unified CVP によって DTMF トーンが PSTN にアウトパルスされます。 これらのインバンド トーンは、PSTN に対するシグナリング メカニズムとして機能し、転送を完了するように要求します。 一般的な DTMF シーケンスは *8xxxx です。xxxx は、PSTN で認識できる新しいルーティング ラベルを表します。 TNT DTMF シーケンスを検出すると、PSTN は入力ゲートウェイ ポートへのコール レッグをドロップし、発信者を新しい PSTN ロケーション（TDM ACD ロケーションなど）に再ルーティングします。

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、この動作が必要になることがあります。 その後必要であれば、エージェントを TDM ACD から Unified CCE に移行し、Unified CVP を IVR、キューイング ポイント、および転送ピボット ポイントとして使用できます（これにより、TNT サービスが不要になります）。

Unified CVP 展開で ICM を使用した場合、別の Unified ICM ペリフェラル（TDM ACD など）へのコール データの引き渡しを可能にするために、DTMF ルーティング ラベルが Unified ICM トランスレーション ルーティング ラベルとしてアウトパルスされる可能性があります。 このシナリオでは、Unified CVP はコールを完了と見なし、Unified CVP 呼制御は終了します。 TNT を使用している場合、ターミネーション ポイントまでの転送に失敗すると、Unified CVP はコールの再ルーティング処理を何も行うことができません。 一部の TNT サービスはコールを再ルーティングして Unified CVP に戻すことができますが、Unified CVP はこのコールを新しいコールと見なします。

フックフラッシュとウィンク

フックフラッシュとウィンクは、通常 TDM PBX または ACD に関連するシグナリング メカニズムです。 フックフラッシュはアナログ トランクにのみ適用され、ウィンクはデジタル トランク（T1 または E1 チャネル）にのみ適用されますが、機能的にはほぼ同じです。 フックフラッシュとウィンクはどちらも、オンフック信号またはオフフック信号を PBX または ACD に送信し、PBX または ACD はダイヤル トーンで応答します（あるいは、PBX がデジタル トランクに対してウィンクを返します）。 このシグナリングでは、音声ゲートウェイがルーティング ディジットの文字列を PBX または ACD に送信します。 ルーティング ディジットを収集すると、PBX または ACD は発信者を新しいターミネーションに転送します。このターミネーションは、同じ PBX または ACD 上の ACD キューまたはサービスになることもあります。

IVR のない既存の ACD 環境で、Unified CVP を最初は IVR として使用し、その IVR を既存の PBX または ACD の回線側に論理的に設置する場合は、この動作が必要です。 その後必要であれば、エージェントを TDM ACD から Cisco Unified CCE に移行し、PBX または ACD の回線側の代わりに PSTN に音声ゲートウェイを接続できます。 Unified CVP 展開で Unified ICM を使用した場合、ルーティング ラベルは Unified ICM トランスレーション ルーティング ラベルになる可能性があります。 このラベルにより、ACD サービス（それに続けてエージェントの画面ポップ）へのコール データの引き渡しが可能になります。 フックフラッシュとウィンクを使用している場合、ターミネーション ポイントまでの転送に失敗すると、Unified CVP はコールの再ルーティング処理をも行うことができません。 一部の PBX または ACD モデルはコールを再ルーティングして Unified CVP に戻すことができますが、Unified CVP はこのコールを新しいコールと見なします。

この機能のサポートは PBX とゲートウェイによって制約されているため、フックフラッシュ転送はこれまで当てになりませんでした。 可能な限り、Unified ICM スイッチングに PBX を使用することは避け、すべての着信コールを PBX ではなく Unified CVP 入力ゲートウェイで終了してください。これにより、Unified CVP から PBX にコールをルーティングできるようになります（この逆ではありません）。

ただし、フックフラッシュ転送が必要な場合は、次のガイドラインと注意事項が適用されます。

  • Cisco 1700 シリーズ ゲートウェイでは、フックフラッシュ転送のテストが行われていません。
  • Cisco 2800 および 3800 シリーズ ゲートウェイでは、アナログ FXO またはデジタル FXO（T1/CAS）をサポートできます。 この機能は、PBX に対する回線側フックフラッシュと見なされ、Avaya Definity G3 でのテストでも適切に動作しました （ただし、現時点では E&M はサポートされていません）。voice-port で timing hookflash-out コマンドを使用して、フックフラッシュ期間を調整できます。 この機能は、フックフラッシュ期間の設定ができない PBX を使用している場合に役立ちます。また、この機能を使用すると、ゲートウェイ側でフラッシュバック期間を調整できます。
  • Cisco 5x00 シリーズ ゲートウェイは、T1/CAS および e&m-fgb dtmf dnis コマンドを使用してテストされました。 E&M は、PBX に対する「トランク側フックフラッシュ」と見なされます。すべてのスイッチでトランク側フックフラッシュがサポートされているわけではありません（Avaya Definity G3 ではサポートされていません）。 また、Cisco 5x00 シリーズ ゲートウェイでのフックフラッシュ期間は 200 ms であり、PBX の期間設定もこれと同じにする必要があります。 このオプションはスイッチ タイプによって異なり、スイッチ ベンダーとの間で概念実証を実施することを強く推奨します。
  • 展開モデル #1 のスタンドアロン セルフサービスでは、フックフラッシュの生成に TCL スクリプトが必要になります。 TCL スクリプトは Unified CVP に付属しています。
  • Digital FXO（T1 CAS）トランクの場合、Unified CVP に到達するコールでは Automatic Number Identification（ANI; 自動番号識別）は使用できません。 Unified CVP 展開モデルによっては、コールがプレルーティング済みであれば、ICM ですでに ANI が認識されていることがあります。
  • Digital FXO（T1 CAS）トランクの場合は、コールが到達する T1/E1 チャネルに基づいて、Dialed Number Identification Service（DNIS; 着信番号識別サービス）をゲートウェイに設定する必要があります。 PBX は、特定の T1 トランク上で特定の DNIS コールをルーティングするようにプログラムされています。 コールはそのトランクでゲートウェイに到達するため、その DNIS は断定的に設定できます。 このアプローチの欠点は、ゲートウェイ トランクの配分を事前に決定する必要がある点です。 何パーセントのコールがどの DNIS に到達するかを把握して、それに応じてゲートウェイのトランク グループを配分できるようにする必要があります。 一部の PBX では、「converse on ステップ」という代替の方法を使用できます。この方法を使用すると、DNIS および ANI を示す DTMF トーンが IVR に送信されます。 この方法では、単一のメイン Unified ICM ルーティング スクリプトを使用して、Get Data（GD）マイクロアプリケーションによって DNIS ディジットを入力し、収集した DNIS ディジットに基づいて正しいサブスクリプトを呼び出す必要があります。 この方法では、シスコ、PBX ベンダー、およびユーザとの間で緊密な連携が求められます。また、この方法はまだテストされていません。
  • Cisco 5x100 シリーズ ゲートウェイの FGB E&M トランクの場合は、デリミタとして「*」を使用すれば、ANI および DNIS を送信できます。 たとえば、*ANI*DNIS* のようにします。 設定の詳細については、http:/​/​www.cisco.com/​en/​US/​customer/​docs/​ios/​12_1t/​12_1t1/​feature/​guide/​anidnis.html からオンラインで入手可能な『ANI/DNIS Delimiter for CAS Calls on CT1』を参照してください。

SIP フックフラッシュのサポート

フックフラッシュは、通常 TDM PBX または ACD に関連するシグナリング メカニズムです。 エンドポイントはオンフック信号またはオフフック信号を PBX または ACD に送信し、PBX または ACD はダイヤル トーンで応答します。 このシグナリングでは、音声ゲートウェイがルーティング ディジットの文字列を PBX または ACD に送信します。 ルーティング ディジットを収集すると、PBX または ACD は発信者を新しいターミネーションに転送します。このターミネーションは、同じ PBX または ACD 上の ACD キューまたはサービスになることもあります。

SIP フックフラッシュ機能では、Unified CVP で hook flash、DTMF 宛先の順に指定して SIP コールを転送できます。 この機能を使用すると、PBX を Unified CVP 入力ゲートウェイのフロントエンドにするという展開が可能になります。また、PBX でエージェントへの非 VoIP 接続を提供できます。

一般的な使用例では、発信者がシステムにコールを行い、TDM ACD に関連付けられているエージェントに転送されます。 Unified CCE は、発信者が正しいエージェントにルーティングされるように、Unified CVP のラベルを返して PSTN に対するフックフラッシュ転送を実行します。 返されるラベルでは、フックフラッシュ ルーティング ディジットの前に HF が付加されます。 発信者がエージェントに転送され、Unified CVP は呼制御を実行しなくなります。

設計上の考慮事項

SIP フックフラッシュ機能を使用する場合、次の制限事項が適用されます。

  • この機能は、2X および 3X ゲートウェイでのみサポートされています。 5X ゲートウェイ（たとえば 5400XM）ではサポートされていません。
  • フックフラッシュは、TDM から発信されるコールにのみ適用されます。 フックフラッシュが Unified CVP によって呼び出されると、Unified CVP は呼制御を実行しなくなります。

Two B Channel Transfer

TBCT は、一部の PSTN サービス プロバイダーが提供している ISDN ベースの解放トランク シグナリング メカニズムです。 TBCT が呼び出されると、入力ゲートウェイは、別のコール レッグ（ISDN B チャネル）を使用してターミネーション ポイントに対するコールを行っている間、一時的に最初の着信コールを保留にします。 ターミネーション ポイントがコールに応答すると、ゲートウェイは ISDN シグナリングを PSTN スイッチに送信することで、転送を完了し、PSTN スイッチを介してコールをブリッジングして入力ゲートウェイから削除するように要求します。 TNT 転送では、ターミネーション ポイントは、PSTN に接続されている TDM PBX または ACD です。

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、この動作が必要になることがあります。 その後必要であれば、エージェントを TDM ACD から Cisco Unified CCE に移行し、Unified CVP を IVR、キューイング ポイント、および転送ピボット ポイントとして使用できます（これにより、TBCT サービスが不要になり、転送失敗時に Unified CVP を使用して再ルーティングを実行できるようになります）。

ICM 管理転送

ほとんどの Unified CVP ユーザは Unified ICM 管理転送を使用します。 Unified CVP は、この機能をほぼ必然的に実行し、Unified ICM および Unified CCE 設置環境にゲートウェイベースのスイッチングを提供します。

Unified CVP 展開で Unified ICM を使用した場合、Unified ICM はすべての呼制御を提供します。 Unified ICM を Unified CVP とともに展開した場合、Unified CVP VXML Server からの VoiceXML 呼制御はサポートされません。

Unified ICM 管理転送は、次のいずれかの新しいターミネーション ポイントにコールを転送します。

  • Cisco Unified Communications Manager 電話機
  • 入力ポートと同じゲートウェイ上の出力ポート
  • TDM によって TDM ACD または PBX に接続する遠隔出力ゲートウェイ（トール バイパス機能を利用）
  • キューイングまたはセルフサービス アクティビティ用の Unified CVP VoiceXML ゲートウェイ

音声ゲートウェイは、コールを終了するために、Unified ICM で指定された宛先に基づいて発信 POTS または VoIP ダイヤルピアを選択します。 Unified ICM VoIP 転送が行われても、入力音声ゲートウェイ ポートは解放されません。 ターミネーション ポイントが出力音声ゲートウェイの場合は、別の音声ゲートウェイ ポートが利用されます。 Unified CVP はコールを引き続きモニタし、Unified ICM も呼制御を維持し、Unified CVP に対してコールを新しい宛先に転送するように命令できます。

Unified CVP をコール処理プラットフォームおよび Unified CCE エージェントのキューイング ポイントとして使用する場合、このタイプの転送を使用します。 また、Unified CVP を使用して、Unified ICM によってサポートされている TDM ACD ロケーションへのフロントエンド コールにコール処理を提供することもできます。 このタイプの転送を使用すると、完全なコール コンテキストによって、Unified ICM でサポートされているペリフェラル間でコールを転送できます。音声パスを返す必要はありません。

この方法で転送されるコールには、次のような特徴があります。

  • Unified ICM ネットワーク転送で Unified CVP をルーティング クライアントとして使用した場合、Unified CVP は呼制御を続行するため、転送は正しく機能します。
  • これらの転送は監視されます。つまり、何らかの理由で転送に失敗した場合、Unified ICM ルーティング スクリプトはルータ再クエリー メカニズムを使用して制御を回復します。
  • Unified ICM レポートの観点から見ると、発信者が実際に電話を切るまで、スイッチ レッグは終了しません。 したがって、コールのスイッチ レッグに関して書き込まれる TCD レコードは、最初の入力から切断までの全コール期間を対象としています。
  • 入力トランクは解放されないため、この方法で転送されたコールを対象に含めるようにゲートウェイのサイズを調整する必要があります。
  • Unified CVP はコールを引き続き監視するため、この方法で転送されたコールを対象に含めるように Unified CVP コール サーバのサイズを調整する必要があります。 また、Cisco Unified Communications Manager エージェントに接続されるコールを除き、Unified CVP コール ディレクタ ポート ライセンスが必要になります。

ネットワーク転送

Unified CVP には、エージェントによる応答後に、別の宛先へコールを転送する機能が備わっています。 この機能はネットワーク転送と呼ばれます。

コールが Unified CVP からエージェントに転送され、そのエージェントがコールを別のエージェントに転送する必要がある場合、エージェントはエージェント IP 電話またはエージェント デスクトップのいずれかを使用してその転送処理を行うことができます。 IP 電話からの転送は、Unified ICME スクリプトを指し示す CTI ルート ポイントを使用して行われます。 エージェント デスクトップからの転送は、着信番号計画を使用して行われます。

Unified ICME でネットワーク転送を制御する場合、次の 2 つのフラグを使用します。

  • NetworkTransferEnabled：Unified ICME スクリプトのフラグです。 有効にすると、Unified ICM によって最初のルーティング クライアント（NewCall ルート要求を送信したルーティング クライアント）に関する情報が保存されます。
  • NetworkTransferPreferred：このフラグは Unified CVP PG コンフィギュレーションでチェックされます。 チェックされると、このルーティング クライアント（Unified ICME が最初のルーティング クライアントを認識しているもの）からルート要求があると、そのルート要求を送信したルーティング クライアントではなく、最初のルーティング クライアントにルート応答が送信されます。

ネットワーク転送を使用する場合、次の推奨事項が適用されます。

  • ネットワーク転送で上記の 2 つのフラグを使用する場合、Unified CVP を介してエージェント 1 からエージェント 2 までのブラインド転送のみを実行できます。 この場合、Unified CVP は、Unified ICME から命令を収集し、エージェント 1 からコールを戻し、それを VoiceXML ゲートウェイ（IVR 処理用）または別の宛先（エージェント 2 など）にルーティングします。
  • エージェント 1 がコンサルテーションまたは会議を行っている間、エージェント 1 へのコール レッグはアクティブである必要があるため、ネットワーク転送を使用して Unified CVP との間でウォーム転送または会議を行うことはできません。 ウォーム転送または会議の間、Unified CVP はエージェント 1 からコールを戻すことはできません。

発信者がブラインド転送、ウォーム転送、または会議とは関係なく同じ番号にダイヤルする場合は、次の推奨事項およびベスト プラクティスを使用できます。

  • Unified ICME スクリプトで NetworkTransferEnable フラグを有効にしないでください。
  • エージェントからの転送または会議要求では、同じ Unified CCE PG の CTI ルート ポイントをダイヤルして、転送中にコール コンテキストが維持されるようにする必要があります。 別の PG のルート パターンまたは CTI ルート ポイントをダイヤルすると、コール コンテキストが維持されません。
  • 常に SendToVru を Unified ICME ルーティング スクリプトの最初のノードとして使用してください。
  • 予備ポートがコンサルテーション、ブラインド転送、または会議中に使用されます。 これらのポートは、発信側のコンサルテーションが終了した場合にのみ解放されます。

SIP Refer 転送

シナリオによっては、Unified CVP でコールを SIP 宛先に転送し、Unified ICM と Unified CVP で今後の呼制御が維持されないようにすることが望ましい場合もあります。 Unified CVP では SIP Refer 転送を実行できます。この転送では、Unified CVP がそれ自体をコールから削除して、認可された Unified CVP ポートを解放できます。 入力音声ゲートウェイ ポートは、発信者または終端装置がコールを解放するまで、引き続き使用された状態のままです。 SIP Refer 転送は、包括展開とコール ディレクタ展開のどちらにも使用できます。

SIP Refer 転送は、次のいずれかの方法で呼び出すことができます。

  • Unified ICM が Unified CVP に rfXXXX という形式（rf5551000 など）のルーティング ラベルを送信します。
  • アプリケーション制御の代替方法として、Unified ICM スクリプトの ECC 変数（user.sip.refertransfer）を値 y に設定し、その変数を Unified CVP に送信します。

    （注）  

    Refer の前に Send To VRU ノードを使用する場合のみ、ラベルを使用した直接の Refer 転送が機能します。

Unified CVP キュー処理が発信者に提供されたら、SIP Refer 転送を呼び出すことができます。 SIP Refer 転送は、Cisco Unified Communications Manager または他の SIP エンドポイント（SIP 対応 ACD など）に対して実行できます。

SIP を Unified CVP とともに使用している場合、Refer 転送に失敗してもルータ再クエリーがサポートされます。ただし、対象となるのは、存続可能性サービスが SIP Refer 要求を処理しないコールのみです。

インテリジェント ネットワーク解放トランク転送

展開モデル #4（NIC 制御ルーティングのみを使用する VRU）を使用しているユーザは、Unified CVP が関係しないコール スイッチング方式に依存しています。 こういった状況では、すべてのスイッチング命令が Unified ICM ネットワーク インターフェイス コントローラ（NIC）と PSTN 間で直接交換されます。 このような NIC インターフェイスの例としては、Signaling System 7（SS7）や Call Routing Service Protocol（CRSP）などがあります。 PGW デバイスが関係する展開では、SS7 NIC は PGW に対するインターフェイスとしても使用されます。 そのため、PGW 展開では、このタイプの転送を実行します。

VoiceXML 転送

VoiceXML 呼制御は、Unified CVP VXML Server によって呼制御が提供されるスタンドアロン Unified CVP 展開（展開モデル #1）でのみサポートされています。 展開モデル #3b にも Unified CVP VXML Server が組み込まれていますが、このモデルでは VoiceXML 呼制御はサポートされていません。 これらの展開だけでなく、すべての Unified ICM 統合展開において、Unified ICM で呼制御のすべての決定を行う必要があります。

Unified CVP VXML Server では、3 つのタイプの転送（解放トランク転送、VoiceXML ブラインド転送、および VoiceXML ブリッジド転送）を呼び出すことができます。 解放トランク転送を使用すると、着信コールが入力音声ゲートウェイから解放されます。 VoiceXML ブラインド転送を使用すると、コールが出力音声ゲートウェイまたは VoIP エンドポイントにブリッジングされますが、Unified CVP VXML Server によって以降のすべての呼制御が解放されます。 VoiceXML ブリッジド転送を使用すると、コールが出力音声ゲートウェイまたは VoIP エンドポイントにブリッジングされますが、Unified CVP VXML Server で呼制御が維持され、発信者を IVR アプリケーションに戻したり、発信者を別のターミネーション ポイントに転送したりできます。

Unified CVP VXML Server からの解放トランク転送は、subdialog_return 要素を使用して呼び出されます。 Unified CVP VXML Server では、TNT 転送、Two B Channel Transfer、フックフラッシュ/ウィンク転送、および SIP Refer 転送を呼び出すことができます。 TDM 解放トランク転送（TNT、TBCT、およびフックフラッシュ/ウィンク）の場合、VoiceXML ゲートウェイと入力ゲートウェイを組み合わせて、解放トランク転送が機能するようにする必要があります。

VoiceXML ブラインド転送およびブリッジド転送は、Cisco Unified Call Studio で Transfer 要素を使用して呼び出されます。 VoiceXML 転送では、ゲートウェイに設定されているダイヤルピアにコールが転送されます。

VoiceXML ブラインド転送と VoiceXML ブリッジド転送の相違点は次のとおりです。

  • VoiceXML ブラインド転送ではコール進捗の監視はサポートされていません。ブリッジド転送ではサポートされています。 つまり、ブラインド転送に失敗した場合、Unified CVP VXML Server スクリプトは制御を回復せず、別の宛先を試すことも、是正措置を取ることもできません。
  • VoiceXML ブラインド転送を使用した場合、Unified CVP VXML Server スクリプトが終了します。 常にブラインド転送ノードの「done exit」分岐を subdialog_return ノードと hang-up ノードに接続してください。

ブリッジド転送では、スクリプトを終了しません。 Unified CVP VXML Server は、入力コールまたは宛先コールが終了するまで待機します。 スクリプトが終了するのは、入力コール レッグが切断された場合のみです。 宛先コール レッグが最初に切断されると、スクリプトは制御を回復し、追加のセルフサービス アクティビティを続行します。 スクリプトが実際に処理を実行していない場合でも、ブリッジド転送の期間中は、Unified CVP VXML Server ポート ライセンスは引き続き使用された状態のままになることに注意してください。

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ