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

目次

コール転送オプション

この章の新規情報

解放トランク転送

Takeback-and-Transfer(TNT)

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

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

設計上の考慮事項

Two B Channel Transfer(TBCT)

ICM 管理転送

ネットワーク転送

SIP Refer 転送

H.323 Refer 転送

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

VoiceXML 転送

コール転送オプション

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

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

「解放トランク転送」

「ICM 管理転送」

「ネットワーク転送」

「SIP Refer 転送」

「H.323 Refer 転送」

「インテリジェント ネットワーク(IN)解放トランク転送」

「VoiceXML 転送」

この章の新規情報

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

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

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

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

SIP では、フックフラッシュ信号を使用した転送がサポートされています。

解放トランク転送

この項では、入力トランクを解放し、呼制御ループからゲートウェイと 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 つのシグナリング メカニズムを使用して、解放トランク転送をトリガーできます。

「Takeback-and-Transfer(TNT)」

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

「Two B Channel Transfer(TBCT)」

Takeback-and-Transfer(TNT)

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

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、この動作が必要になることがあります。その後必要であれば、エージェントを TDM ACD から Cisco 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 5 x 00 シリーズ ゲートウェイは、T1/CAS および e&m-fgb dtmf dnis コマンドを使用してテストされました。E&M は、PBX に対する「トランク側フックフラッシュ」と見なされます。すべてのスイッチでトランク側フックフラッシュがサポートされているわけではありません(Avaya Definity G3 ではサポートされていません)。また、Cisco 5 x 00 シリーズ ゲートウェイでのフックフラッシュ期間は 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)

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 ルーティング スクリプトの最初のノードとして使用してください。

H.323 ベースの展開では、Cisco Unified Communications Manager の 2 つのタイマーを Unified CVP RONA タイマーより大きい値に設定する必要があります。これらのタイマーを使用して、エージェント 2 の電話が呼び出されている間に、コンサルテーション完了の状況に対応します。タイマーは次のとおりです。

[Clusterwide Parameters (Service)] -> [Media Exchange Timer]

[Clusterwide Parameters (Service)] -> [Media Resource Allocation Timer]

H.323 ベースの展開では、Cisco Unified CM 6.1.3 またはそれ以前のリリースを使用している場合、UCCE PG ルーティング クライアント ラベルが設定されている Unified CM トランクで [Wait for Far End H.245 Terminal Capability Set] フラグのチェックを解除する必要があります。

コンサルテーション、ブラインド転送、または会議の間は、予備ポートが使用されます。これらのポートは、発信側のコンサルテーションが終了した場合にのみ解放されます。

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 に rf XXXX という形式(rf5551000 など)のルーティング ラベルを送信します。

アプリケーション制御の代替方法として、Unified ICM スクリプトの ECC 変数(user.sip.referertransfer)を値 y に設定し、その変数を Unified CVP に送信します。

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

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

H.323 Refer 転送

Unified CVP 4.0(2) には、SIP Refer と同じように動作する新しい H.323 コール用転送メカニズムが導入されています。この機能では、Unified CVP がそれ自体をコールから削除して、呼制御ポートを解放できます。この機能を使用して、VoiceXML ゲートウェイでコールをキューに格納し、Cisco Unified Communications Manager または他の H.323 エンドポイント(ACD など)上のエージェントに送信できます。

このタイプの転送が実行された後、Unified CVP はその後の呼制御操作を実行できなくなります。ただし、このシナリオでも、失敗時の回復用に Unified CVP 存続可能性サービスを引き続き使用できます。この機能は、包括コール フロー モデルとコール ディレクタ コール フロー モデルのどちらにも使用できます。対象となるのは、Unified CVP 存続可能性サービスが実行されている Cisco IOS ゲートウェイを介して PSTN から発信されたコールのみです。

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

Unified ICM が Unified CVP に RF88# xxxx # という形式(RF88#5551000# など)のルーティング ラベルを送信します。

アプリケーション制御の代替方法として、Unified ICM スクリプトの ECC 変数(user.h323.rftransfer)を値 y に設定し、その変数を Unified CVP に送信します。CVP H.323 サービスは、受信したラベルを自動的に変更して、上記の形式に準拠するようにします。

H323 Refer 転送を実行するには、次のパラメータを使用して Unified CVP 存続可能性サービスを有効にする必要があります。

param icm-rf 1

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

展開モデル #4(NIC 制御ルーティングのみを使用する VRU)を使用しているユーザは、Unified CVP が関係しないコール スイッチング方式に依存しています。こういった状況では、すべてのスイッチング命令が Unified ICM Network Interface Controller(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 転送、TBCT 転送、フックフラッシュ/ウィンク転送、および 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 ポート ライセンスは引き続き使用された状態のままになることに注意してください。