TCL IVR API Version 2.0 プログラミング ガイド
概要
概要
発行日;2012/01/11 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

概要

IVR と TCL

TCL IVR API Version 2.0

前提条件

利点

サポートされる機能

Developer Support

拡張された複数言語のサポート

VoiceXML および IVR アプリケーション

TCL での呼の受け渡し

VoiceXML での呼の受け渡し

TCL/VoiceXML ハイブリッド アプリケーション

ハイブリッド アプリケーションでの VoiceXML と TCL IVR 2.0 間の通信

ハイブリッド モードと VoiceXML 呼制御タグ

SendEvent オブジェクト

TCL IVR コール転送の概要

コール転送の用語

サポートされる TCL IVR コール転送スクリプト

Cisco IOS デフォルト セッション アプリケーションでのコール転送サポート

カスタム TCL IVR コール転送スクリプト

コール転送シナリオ

1 つのゲートウェイとアナログ転送元のシナリオ

1 つのゲートウェイと Cisco CME IP 電話の転送元のシナリオ

2 つのゲートウェイとアナログ転送元のシナリオ

2 つのゲートウェイと Cisco CME IP 電話の転送元のシナリオ

3 つのゲートウェイとアナログ転送元のシナリオ

3 つのゲートウェイと Cisco CME IP 電話の転送元のシナリオ

コール転送プロトコルのサポート

アナログ フックフラッシュと T1 CAS Release Link Trunk(RLT)転送

ISDN コール転送

SIP コール転送

H.450 コール転送

Cisco CallManager Express コール転送

SIP 登録および通知

SIP ヘッダー

アプリケーション インスタンス

セッション対話

セッションの開始と停止

メッセージの送信

メッセージの受信

呼の受け渡し

受け渡しの戻り

サービス レジストリ

概要

この章では、Interface Voice Response(IVR)、Tool Command Language(TCL)、および TCL IVR Application Programming Interface(API)Version 2.0 の概要について説明します。次の項で構成されます。

「IVR と TCL」

「TCL IVR API Version 2.0」

「前提条件」

「利点」

「サポートされる機能」

「Developer Support」

「拡張された複数言語のサポート」

「VoiceXML および IVR アプリケーション」

「TCL IVR コール転送の概要」

「SIP 登録および通知」

「SIP ヘッダー」

「アプリケーション インスタンス」

「セッション対話」

「サービス レジストリ」

IVR と TCL

IVR は、電話回線を使用し、記録されたメッセージに応答したユーザ入力を収集するために使用されるシステムを表す用語です。ユーザ入力の形式には、話し言葉やより一般的なデュアル トーン マルチ周波数(DTMF)シグナリングがあります。

たとえば、ユーザがデビット カードを使用して電話をかけると、PIN などの特定の種類の情報を入力するように発信者に案内するために IVR アプリケーションが使用されます。音声プロンプトの再生後、IVR アプリケーションは、タッチ トーンの指定済みの番号を収集し(ディジット収集)、収集したディジットをサーバに転送して保存および検索してから、宛先の電話またはシステムに電話をかけます。呼は記録をとることが可能なため、多彩なアカウンティング機能を実行できます。

IVR アプリケーション(またはスクリプト)は、音声機能および特性を備えたルータである「音声ゲートウェイ」で呼処理を行うために設計された音声アプリケーションです。

IVR スクリプトで使用するプロンプトは、静的または動的のいずれでも使用できます。

「スタティック プロンプト」は、静的な URL によって参照される音声ファイルです。音声ファイルの名前と格納場所は、TCL スクリプトで指定されます。

「ダイナミック プロンプト」は、基盤となるシステムによって生成され、比較的小さい音声プロンプトを組み立てて順番に再生します。どのプロンプトを再生するかをシステムに命令するために、表記法に基づいた API コマンド(「media play」を参照)がスクリプトで使用されます。基盤となるシステムは、選択された言語や構成された音声ファイルの格納場所に基づいて一連の URL を組み立て、順番に再生します。これによって、簡単な TTS(Text-to-Speech)操作が提供されます。

たとえば、ダイナミック プロンプトは、次のように、デビット カードのアカウントに通話時間がどれだけ残っているかを発信者に知らせる場合に使用します。

"You have 15 minutes and 32 seconds of call time left in your account."


) 上記のプロンプトを生成するために、8 つの個別のプロンプト ファイルが使用されています。ファイルの内訳は、youhave.au、15.au、minutes.au、and.au、30.au、2.au、seconds.au、leftinyouraccount.au です。これらの音声ファイルは、基盤となるシステムによって動的に組み立てられ、選択された言語やプロンプト ファイルの格納場所に基づいて 1 つのプロンプトとして再生されます。


Cisco IOS リリース 12.0(6)T 以降で利用可能な Cisco Interactive Voice Response(IVR)機能では、TCL 1.0 スクリプトの使用によって IVR 機能が提供されます。このスクリプトではシグニチャがロックされているため、Cisco によってのみ変更が可能です。IVR 機能によって、呼処理中に IVR スクリプトを使用することが可能になり、Cisco IOS ソフトウェアで呼関連の関数を多数実行することが可能になります。Cisco IOS リリース 12.1(3) 以降は、TCL スクリプトがロックされていないため、カスタマーは TCL スクリプトを自分で作成および変更することができます。

TCL は、インタプリタ型のスクリプト言語です。このため、TCL で記述されたスクリプトは、実行する前にコンパイルする必要がありません。TCL には基本的なコマンド セットが用意されているため、フロー制御(if、then、else)などの標準関数や変数管理に対応できます。拡張機能を言語に追加すれば、このコマンド セットを拡張して特定の操作を行うこともできます。

TCL IVR コマンドと呼ばれる拡張機能のセットが作成されたため、ユーザは、TCL を使用して IVR スクリプトを作成することが可能になります。シェルから実行される別の TCL スクリプトと異なり、TCL IVR スクリプトは、ゲートウェイに呼が着信すると実行されます。

このマニュアルでは、これ以降、TCL や、TCL によるスクリプトの作成について理解していることを前提としています。まだよく理解していない場合は、『TCL and the TK Toolkit』(John Ousterhout 氏著、Addison Wesley Longman, Inc 発行)をお読みください。

TCL IVR API Version 2.0

ここでは、TCL IVR API における前提条件、制約事項、利点、機能、開発者サポート プログラムについて説明します。

前提条件

使用する場合は次のプラットフォームが必要です。

Cisco AS5300、Cisco AS5400、または Cisco AS5800

Cisco IOS リリース 12.1(3)T 以降

TCL Version 7.1 以降

呼がゲートウェイに着信するには、アナログ回線、ISDN 回線、VoIP リンク、Voice over Frame Relay(VoFR)リンクのいずれかが使用されます。TCL IVR スクリプトは、アナログ回線や ISDN 回線で受信した呼に対しては完全な機能を提供することができます。

一方、VoIP リンクや VoFR リンクで受信した呼に対しては、使用する Cisco IOS ソフトウェアのリリースに基づいて機能が提供されます。たとえば、Cisco IOS リリース 12.0 を使用する場合、プロンプトまたはトーンの再生やトーンの収集を行うことはできません。


) TCL IVR API Version 2.0 は、TCL IVR API Version 1.0 とは別個の製品です。


利点

TCL IVR API Version 2.0 には、次の利点があります。

スクリプトはイベント方式で、呼のフローは、TCL スクリプトで定義される有限状態マシン(FSM)によって制御されます。

VoIP のコール レッグに対してプロンプトを再生できます。

VoIP のコール レッグに対してディジットを収集できます。

Real-Time Streaming Protocol(RTSP)ベースのプロンプトは、(一部の Cisco IOS ソフトウェアのリリースおよびプラットフォームで)サポートされています。

スクリプトで複数のレッグを同時に制御することができます。

スクリプト間でコール レッグを受け渡すことができます。

動詞はすべてノンブロッキングです。これは、スクリプトの待ち時間を発生させずに実行できることを意味し、スクリプトが複数のタスクを一度に行うことを可能にします。次のコード例を参照してください。

leg collect digits 1 callInfo
leg collect digits 2 callInfo
leg setup 295786 setupInfo $callID5
puts "\n This will be executed immediately i.e. before the collect digits or call setup is actually complete"
 

上記のスクリプト例では、レッグ 1 とレッグ 2 でディジット収集が開始され、callID5 を着信レッグとして呼の確立プロセスが開始されます。スクリプトは、各コマンドを発行した後で、それぞれの終了に関するイベントを受け取ります。コマンドはいずれも、別のコマンドの処理が終了するまで待つ必要がありません。

サポートされる機能

TCL IVR API Version 2.0 のコマンドを使用して、次のファシリティや機能を利用することができます。

呼処理(確立、会議通信、切断など)

メディアの再生と制御(メモリ ベースおよび RTSP ベースの両プロンプト)

AAA 認証および許可

OSP 決済

コール タイマーとレッグ タイマー

再生トーン

呼の受け渡しと戻り

ディジット収集

詳細については、 第3章「TCL IVR コマンド」 を参照してください。

Developer Support

Cisco Developer Support Program についてご紹介します。この新しいプログラムは、開発プロジェクトにおいて Cisco のインターフェイスを利用する間、信頼性の高いサポートを一貫したレベルで提供します。

このプログラムへ加入するには、Developer Support Agreement の承認が必要です。詳細について、またサポート契約については、http://www.cisco.com/warp/public/779/servpro/programs/ecosystem/devsup にアクセスするか、developer-support@cisco.com まで電子メールでお問い合せください。

拡張された複数言語のサポート

Cisco IOS リリース 12.2(2)T から、Cisco IOS ゲートウェイのコア IVR インフラストラクチャに新しい言語と TTS(Text-to-Speech)表記を追加するためのサポートを提供する新機能が TCL IVR Version 2.0 に導入されました。

従来、IVR アプリケーションで TTS を実行する場合、英語、スペイン語、中国語に制限され、TTS 表記セットも変更できませんでした。IVR アプリケーションでサポートされる言語を追加するには、独自に翻訳を行い、翻訳を必要とする TCL IVR アプリケーションすべてに言語翻訳プロシージャを追加する必要がありました。

この新機能により、あらゆる言語と TTS 表記セットについて新しい TCL 言語モジュールを作成できます。モジュールとそれに付属する音声ファイルを言語パッケージとしてテストして配布し、配布する言語とサポートする TTS 表記を文書化できます。ゲートウェイにこのモジュールを設定すると、そのゲートウェイで実行される IVR アプリケーションとその TTS 表記を使用するアプリケーションは、その言語で動作し、発声します。

詳細については、『 Enhanced Multi-Language Support for Cisco IOS Interactive Voice Response 』マニュアルを参照してください。


) TCL 言語モジュールは TCL IVR スクリプトではありません。TCL 言語モジュールは特定の TCL Language Module Interface(TLMI)を実装するピュアな TCL スクリプトであるため、IVR スクリプトの記述に使用できる TCL IVR API 拡張の使用は許可されていません。


VoiceXML および IVR アプリケーション

VoiceXML は Web ベースの開発とコンテンツという利点を IVR アプリケーションにもたらしました。IVR アプリケーションでの VoiceXML の使用に関する詳細については、『Cisco IOS Tcl and VoiceXML Application Guide 』および『Cisco VoiceXML Programmer's Guide』を参照してください。

TCL での呼の受け渡し

呼の受け渡しについて理解するには、まずアプリケーション インスタンスの概念を理解する必要があります。Cisco IOS IVR インフラストラクチャでは、アプリケーション インスタンスは、アプリケーション コードを実行し、1 つ以上のコール レッグを受信、作成、管理して呼を生成したり、ユーザにサービスを提供したりするエンティティです。アプリケーション インスタンスは、これらのコール レッグを所有および制御し、コール レッグに関連付けられたイベントをすべて受け取ります。例外もありますが、通常、アプリケーションは 1 つのアプリケーション インスタンスを使用し、1 つの呼によるサービスを提供します。TCL IVR アプリケーションは、実行中 1 つ以上のアプリケーション インスタンスとして動作します。

呼の受け渡しは、あるアプリケーション インスタンスから別のアプリケーション インスタンスにコール レッグの制御全体を転送する操作を表す用語です。呼が受け渡されると、そのコール レッグに関連付けられたそれ以降のイベントはすべて、転送先のアプリケーション インスタンスによって受け取られ、処理されます。

受け渡しは、コール レッグが受け渡し操作の元のアプリケーション インスタンスに戻る必要があるかどうかに応じて、いくつかの異なる方法で行うことができます。通常の受け渡しアプリケーション操作は、goto イベントに似ていますが、戻りアドレスが自動的に記憶されることはありません。転送先は、元のインスタンスにレッグを戻すことができません。

call app 操作は、関数呼び出しに似ています。call app 操作を実行するアプリケーション インスタンスはスタックに保存されるので、転送先アプリケーション インスタンスが受け渡しの戻し操作を実行して、スタックの一番上にあるアプリケーション インスタンスにコール レッグを戻すことができます。

コール レッグの受け渡しを実行すると、そのコール レッグと会議通信しているレッグがあれば、明示的に指定されなくても一緒に受け渡されます。受け渡し操作または受け渡しの戻し操作を実行するとき、アプリケーション インスタンスでパラメータを引数文字列として渡すことができます。呼の受け渡しは、VoiceXML と TCL IVR 2.0 のアプリケーションの任意の組み合わせの間で実行できます。

呼の受け渡し機能を使用すると、開発者はさまざまな目的のために互いに対話するアプリケーションを記述できます。これには、既存アプリケーションの機能を利用する場合や、大きなアプリケーションを小さいアプリケーション セグメントにモジュール化し、受け渡しメカニズムを使用してモジュール間の調整と通信を行う場合などがあります。場合によっては、アプリケーション開発者が、開発するアプリケーションで VoiceXML と TCL IVR 2.0 の両方の機能を利用する必要が生じることがあります。これもまた、受け渡し操作のアプリケーションになる可能性があります。

受け渡し操作には、モジュール化やアプリケーション間の対話の実現という点では、ある程度の柔軟性がありますが、コール レッグの制御に関しては制限があります。コール レッグを全体的に制御し、イベントを受け取るアプリケーション インスタンスは 1 つだけであることが、シナリオによっては制限となる可能性があります。したがって、TCL IVR 2.0 と VoiceXML の両方に関わるアプリケーションの実装メカニズムの選択を検討する際には、開発者は選択肢としてハイブリッド スクリプトも検討することをお勧めします。

ハイブリッド アプリケーションは、呼の受け渡し操作とは異なります。ハイブリッド アプリケーションは、TCL IVR スクリプトと、その中に組み込まれているか、またはそこから起動される VoiceXML ダイアログを使用して記述されます。TCL IVR スクリプトは呼制御に使用され、VoiceXML スクリプトはダイアログ管理に使用されます。これらはすべて 1 つのアプリケーション インスタンスの一部として実行され、コール レッグの共有制御をある程度可能にします。ハイブリッド スクリプトの詳細については、この後で説明します。

TCL/VoiceXML ハイブリッド アプリケーション

TCL IVR 2.0 および VoiceXML API には、それぞれ独自の長所と短所があります。TCL IVR 2.0 は呼制御という面ではきわめて柔軟であり、複数のコール レッグと、その制御方法やインターワーキング方法を記述できます。ただし、ユーザ インターフェイス プリミティブが leg collectdigits および media play コマンドに制限されるという短所があります。

一方、VoiceXML は音声ユーザ インターフェイスの設計ではよく知られており、使いやすいのですが、呼制御機能については大幅な制限があります。たとえば、VoiceXML ダイアログはユーザ入力の収集やプロンプトの再生などの IVR アクティビティには適しています。

そのため、TCL IVR 2.0 は、コール レッグと、コール レッグ間の呼のフローや呼制御の記述への使用には適しており、一方、VoiceXML は、制御する 1 つ以上のレッグで動作するユーザ インターフェイス ダイアログの記述に適しています。

限定的に、受け渡しメカニズムを使用して TCL IVR 2.0 で別個のアプリケーション インスタンスを動作させたり、VoiceXML をアプリケーションの呼制御やダイアログ部分の処理に使用したりすることが可能な場合もありますが、呼制御とダイアログのアクティビティを明確に分離することが次第に困難になります。これには、呼制御スクリプトと、コール レッグに対するダイアログ実行共有制御が必要になりますが、これを受け渡しアプローチで実現するのは困難です。

Cisco IOS リリース 12.2(11)T には、開発者が TCL および VoiceXML スクリプトを使用してハイブリッド アプリケーションを開発するための機能が導入されました。TCL IVR 2.0 拡張によって、TCL アプリケーションが、TCL IVR スクリプト内から VoiceXML を呼び出しおよび管理することで、ASR と TTS のサポートを活用できるようになります。ハイブリッド アプリケーションは、呼制御に TCL IVR を、ダイアログ管理に VoiceXML を使用して開発できます。アプリケーションは TCL IVR 2.0 と VoiceXML の API の両方を使用しながら 1 つのアプリケーション インスタンスとして動作することができます。

ハイブリッド スクリプトでは、制御の共有と優先規則を設定する必要があります。ハイブリッド アプリケーションでは、TCL IVR 2.0 スクリプトによって呼とそのすべてのコール レッグが制御されます。ハイブリッド スクリプトは、着信コール レッグについて ev_setup_indication を受け取ります。また、leg alert の発行や、leg connect コマンドを使用したコール レッグの受信のためのプリミティブを備えています。さらに、発信コール レッグの作成、1 つ以上のコール レッグのブリッジ、またはその他の類似操作のためのプリミティブとイベントのサポートもあります。

TCL IVR スクリプトが、いずれかのコール レッグのユーザと通信する必要がある場合、2 つの方法があります。ネイティブの TCL IVR 2.0 で既存の leg collectdigits および media play コマンドを使用して個々の音声プロンプトを再生してディジットを収集するか、leg vxmldialog コマンドを使用してレッグでの VoiceXML ダイアログ操作を開始できます。leg vxmldialog コマンドは、TCL IVR 2.0 スクリプトの直接制御の下で、コール レッグでの VoiceXML インタプリタ セッションを起動します。セッションで起動される最初の VoiceXML ドキュメントは、起動元の TCL IVR 2.0 スクリプトに組み込まれているか、または単に Web サーバにある VoiceXML ドキュメントが参照されます。

レッグで起動されたこの VoiceXML セッションは、ほぼ標準的な VoiceXML セッションですが、次の例外があります。

VoiceXML ダイアログ セッションと TCL IVR 2.0 呼制御スクリプトの間で情報交換ができるように、同期のためのプリミティブとメカニズムが追加されている。

VoiceXML では、<transfer> や <disconnect> タグなどの呼制御コマンドがサポートされているが、このモードでは、TCL IVR 2.0 スクリプトがすべての呼制御アクティビティを完了しなければならないため動作が異なる。

ハイブリッド アプリケーションでの VoiceXML と TCL IVR 2.0 間の通信

TCL IVR 2.0 スクリプトがコール レッグで VoiceXML ダイアログを開始するとき、leg vxmldialog コマンドにパラメータの配列を渡すことができます。これらのパラメータは、com.cisco.params.xxxxxx 変数を使用して VoiceXML セッションからアクセスできるようになります。VoiceXML セッションでは、com.cisco.params オブジェクトに TCL IVR 配列からの情報が入力されます(xxxxx は TCL 配列の指数)。

VoiceXML ダイアログは、終了するときに <exit/> タグの namelist 属性を使用して TCL IVR スクリプトに情報を戻すことができます。VoiceXML ダイアログが実行を終了すると、TCL スクリプトは exit タグで戻される情報が付属する ev_vxmldialog_done イベントを受け取ります。このイベントには、evt_status 情報タグを使用してアクセス可能なステータス コードも付属しています。

VoiceXML ダイアログの開始や終了とは別に、TCL スクリプトは leg vxmlsend コマンドを使用して実行中のダイアログに中間メッセージを送信できます。コマンドで指定されたイベントは、VoiceXML インタプリタ内にスローされ、イベントを検索する <catch> ハンドラによってキャッチできます。このコマンドには TCL パラメータ配列を使用することもできます。配列の情報には、前述した com.cisco.params.xxxx に似た、適用範囲を設定した _message.params.xxxxxx 変数を使用して VoiceXML catch ハンドラ内でアクセスできます。

同様に、VoiceXML インタプリタ環境または実行中のドキュメントから、さまざまなタイミングで TCL スクリプトにイベントを送信できます。このようなイベントは、ev_vxmldialog_event イベントとして TCL スクリプトに着信します。実行中の VoiceXML ドキュメントは、<object> 拡張に classid="builtin://com.cisco.ivrscript.sendevent" と指定することで、明示的なメッセージを関連するパラメータ情報と共に親 TCL スクリプトに送信できます。VoiceXML ドキュメントがハイブリッド モードで <disconnect> や <transfer> のような特定のタグを実行すると、TCL スクリプトは ev_vxmldialog_event イベントを暗黙的に受け取ります。

ev_vxmldialog_done イベントまたは ev_vxmldialog_event イベントには、次の 2 つの情報が付属することがあります。

VoiceXML 固有のイベント名。ev_vxmldialog_done または ev_vxmldialog_event イベントのさまざまな理由を識別するために使用し、evt_vxmlevent 情報タグを使用してアクセスできます。このイベント名は、vxml.* の形式の文字列です。これは、イベント名の発生元が VoiceXML インタプリタ環境(vxml.session.*)か、VoiceXML インタプリタで実行されているダイアログ(vxml.dialog.*)の可能性があることを示しています。環境レベルのメッセージの例としては、vxml.session.complete(ダイアログの正常な終了を示す)、または vxml.session.transfer(ドキュメントがこのモードの操作ではサポートされていない <transfer> タグの実行を試みたことを示す)があります。キャッチされない error.badfetch メッセージをドキュメントがスローし、それが原因でダイアログが終了する場合、またはドキュメントが <object> 送信タグを使用して TCL に明示的なメッセージを送信する場合、evt_vxmlevent には、vxml.dailog.* 文字列が含まれます。

evt_vxmlevent_params 情報タグを使用してアクセス可能な情報のパラメータ配列。

ハイブリッド モードと VoiceXML 呼制御タグ

ハイブリッド モードでは、VoiceXML の <disconnect> タグがコール レッグを切断することはありません。代わりに、vxml.session.disconnect イベントが TCL IVR スクリプトに送信されます。VoiceXML の実行という観点では、<disconnect> がエミュレートされ、disconnect イベントをスローしてから実行を継続します。ダイアログでは、これ以降、プロンプトの再生や入力の収集は行われません。

ユーザが電話を切ると、上記と同じように <disconnect> が再びエミュレートされます。ただし、レッグはまだ切断されていません。TCL スクリプトは制御イベントの一部として ev_disconnected イベントを受け取ってから、ダイアログを終了するかダイアログが終了するまで待機し、レッグを切断します。

ドキュメントが <transfer> タグを実行すると、次の結果になります。

vxml.session.transfer イベントが VoiceXML 環境から TCL スクリプトに送信される。

VoiceXML 環境から VoiceXML セッションにキャッチ可能な error.unsupported.transfer イベントがスローされる。キャッチされない場合は、デフォルトのハンドラがダイアログを終了し、最終的な ev_vxmldialog_done イベントを TCL スクリプトに送信します。

SendEvent オブジェクト

記録されたオブジェクトは、VoiceXML/JAVA スクリプトでは音声オブジェクト変数として表されます。TCL ではすべてがテキスト ベースであるため、オブジェクトは ram://XXXXX URI として表されます。ram://XXX の値を持つ TCL 配列要素は、VoiceXML では音声変数または音声オブジェクトとして使用できます。同様の逆変換が、VoiceXML から TCL スクリプトに情報が渡されるときに行われます。

TCL IVR コール転送の概要

TCL IVR スクリプトを使用して、さまざまなコール転送プロトコルでブラインド転送および打診転送をサポートできます。ここでは、TCL IVR アプリケーションに関するコール転送の用語と使用方法のシナリオについての背景を説明します。また、サポートされる各プロトコルのコール転送機能について、転送に関与する終端点が異なるシグナリング プロトコルを使用する場合にサポートされるプロトコルでどのようなインターワーキングが可能かについて説明します。

コール転送の用語

転送参加者

通常、コール転送には次の 3 つの参加者が含まれます。

転送元(XOR):転送を開始する終端点。

転送中継先(XEE):別の宛先に転送される終端点。

転送先(XTO):転送中継先が転送先となる終端点。

転送のトリガー

コール転送のトリガーとは、転送元終端点がコール転送プロシージャの開始に使用するメカニズムです。これは通常、アナログ電話用のフックフラッシュ イベント、または Cisco CallTw55tieManager Express(CME)モードで動作する Cisco IOS 音声ゲートウェイに登録された IP 電話のボタンまたはソフトキーです。

転送のコミット

転送のコミットは、転送中継先と転送先の終端点を接続する必要がある場合に転送元終端点が実行する操作であり、多くの場合は転送先終端点に打診した後に行われます。アナログ電話と Cisco CME IP 電話については、転送のコミットは通常、電話を切ることによって実行されます。TCL IVR スクリプトは通常、転送がコミットされたことを示す結果を受信すると、転送要求を転送中継先コール レッグに送信します。

サポートされる TCL IVR コール転送スクリプト

Cisco では、この後に説明する H.450 コール転送シナリオをサポートする TCL IVR スクリプトを公式に提供しています。 http://www.cisco.com/cgi-bin/tablebuild.pl/ip-key で参照できる Cisco CallManager Express(CME)zip ファイルに含まれています。スクリプトの現行バージョンは、
app_h450_transfer.2.0.0.3.tcl という名前です。詳細については、スクリプトに付属している README ファイルを参照してください。

Cisco IOS デフォルト セッション アプリケーションでのコール転送サポート

コール転送サポートが 12.2(15)ZJ Cisco IOS リリースのデフォルト音声セッション アプリケーションに追加されました。デフォルト アプリケーションでは、H.450 および SIP の転送中継先および転送先機能がブラインド転送と打診転送について提供されるようになりました。また、Cisco IOS ゲートウェイに接続している IP 電話で Cisco CallManager Express(CME)モードで動作したまま、H.450 および SIP のブラインド転送と打診転送がサポートされます。


) 拡張されたデフォルト セッション アプリケーションでは、Cisco IOS ゲートウェイに接続するアナログ電話を使用した転送開始はサポートされません。この機能は、前述した app_h450_transfer.2.0.0.3.tcl スクリプトで実現するか、またはカスタム TCL IVR アプリケーションに実装できます。


カスタム TCL IVR コール転送スクリプト

すでに説明した Cisco IOS デフォルト セッション アプリケーションと app_h450_transfer.tcl スクリプトを使用して、多くの典型的なコール転送シナリオをサポートできます。この機能のバリエーションが必要な場合は、カスタム TCL IVR スクリプトを記述できます。 Developer Support Central ページにある call-transfer-sample.zip ファイルには、TCL IVR スクリプト例と関連するマニュアルが含まれており、カスタム スクリプトを記述する際のガイドとして使用できます。

TCL IVR スクリプトを記述する上でより詳細なサポートが必要な場合は、Cisco Developer Support プログラムにご参加ください。このプログラムでは、あらゆる開発ニーズに対応する一元化されたリソースをご利用いただけます。プログラムのメンバーは、提供されている製品とマニュアルのダウンロード、バグ レポート、スクリプト例、よくある質問のすべてにアクセスして、開発作業を円滑に進めることができます。

Developer Support のエンジニアはそれぞれ、Cisco のインターフェイスとプロトコルの各分野の専門家です。このチームは、お客様および Cisco AVVID Partner Program やその他のエコシステムのメンバーに、開発プロジェクトで Cisco API を使用するためのサポートを専門にしています。プログラムでは、Cisco.com を利用して特典にアクセスできるだけでなく、簡単なプロセスで問題を開始、更新、およびトラッキングすることができます。サポート契約、料金、利用可能なオプションを定義した Developer Support Agreement は、Cisco Developer Support Web サイト
(http://www.cisco.com/warp/public/570/)から入手できます。

コール転送シナリオ

TCL IVR スクリプトを記述するときには、多くのコール転送シナリオを検討する必要があります。ここでは、1 ~ 3 つの Cisco IOS 音声ゲートウェイを含むシナリオをいくつか説明します。コール転送シナリオをわかりやすくするために、この後の各説明には次のダイアグラムが含まれています。

最初のダイアグラムには、転送前の 2 者間呼が示されます。

2 つめのダイアグラムには、進行中のブラインド転送が示されます。

3 つめのダイアグラムには、進行中の打診転送が示されます。

4 つめのダイアグラムには、ブラインド転送または打診転送が正常に終了した後の最終呼が示されます。

具体的な要件に応じて、スクリプトを記述し、この後に説明するシナリオの 1 つ以上をサポートすることができます。図1-7 の打診転送シナリオなど、場合によっては、スクリプトの 2 つの独立したインスタンスが同じゲートウェイで使用されることもあります。

その後に続く図で、XOR、XEE、XTO の各ラベルはコール転送で各コール レッグが果たす役割を示します。IN ラベルと OUT ラベルが、2 者間呼の間の着信コール レッグと発信コール レッグをトラッキングします。そのため、スクリプトはコール レッグ トポロジをトラッキングすることができ、イベントを受け取ったときに取るべきアクションを判断できます。

ここで説明するシナリオのすべてで、電話 A と電話 B の間の元の 2 者間呼はすでに確立されています。電話 A は転送元終端点(XOR)、電話 B は転送中継先終端点(XEE)、電話 C は転送先終端点(XTO)です。転送元の電話 A は、アナログ FXS 電話か、または Cisco CallManager Express(CME)モードで動作する Cisco IOS 音声ゲートウェイに登録された IP 電話です。

1 つのゲートウェイとアナログ転送元のシナリオ

最初のコール転送シナリオでは、図1-1 のように電話 A、電話 B、電話 C が同じゲートウェイに接続されています。この場合、すべての転送元、転送中継先、転送先の機能は、TCL IVR スクリプトの 1 つのインスタンスによって提供されます。

図1-1 1 つのゲートウェイ:転送前のアナログ XOR

 

ブラインド転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先を入力してから電話を切ります。次にスクリプトが転送先に通常の電話をかけ、転送中継先コール レッグと転送先コール レッグを接続してから、転送元コール レッグを切断します。図1-2 を参照してください。

図1-2 1 つのゲートウェイ:アナログ XOR のブラインド転送

 

打診転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先の番号を入力します。次にスクリプトが転送先に電話をかけ、電話 A が電話 C に打診できるようにします。ユーザが(電話を切って)転送をコミットすると、スクリプトは転送先(電話 C)に打診 ID を要求します。電話 C はローカルのアナログ電話であるため、ゲートウェイはローカルの打診 ID を生成してこのスクリプト インスタンスに登録します。スクリプトは、この打診 ID を含む転送呼を電話 C 宛てに発信します。打診 ID はこのスクリプト インスタンスに登録されているので、転送中継先コール レッグが同じスクリプトに受け渡されます。図1-3 を参照してください。

図1-3 1 つのゲートウェイ:アナログ XOR の打診転送

 

スクリプトは、受け渡しイベントを受け取ると、転送中継先レッグと転送先レッグをブリッジし、転送元を解放します。図1-4 を参照してください。


) ゲートウェイが 1 つのこのシナリオでは、呼のフローを簡略化して、スクリプトが転送中継先コール レッグをスクリプト自身に受け渡さないようにすることもできます。ただし、受け渡しメカニズムは、この後で説明する複数ゲートウェイのシナリオでも有効なため、使用することをお勧めします。


図1-4 1 つのゲートウェイ:転送後のアナログ XOR

 

1 つのゲートウェイと Cisco CME IP 電話の転送元のシナリオ

この転送シナリオでは、電話 A、B、C のすべてが同じゲートウェイに接続されています。図1-5 を参照してください。この場合、転送元、転送中継先、転送先の機能は、TCL IVR スクリプトの 1 つまたは 2 つのインスタンスによって提供されます。

図1-5 1 つのゲートウェイ:転送前の Cisco CME IP 電話 XOR

 

ブラインド転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先を入力します。スクリプトが転送要求イベントを電話から受け取り、転送先に通常の電話をかけ、転送中継先コール レッグと転送先コール レッグを接続します。次に、転送元コール レッグを切断します。図1-6 を参照してください。

図1-6 1 つのゲートウェイ:Cisco CME IP 電話 XOR のブラインド転送

 

打診転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先の番号を入力します。IP 電話は、別の回線を使用して転送先に電話をかけます。この呼は、ゲートウェイで実行されている TCL IVR スクリプトの 2 つめのインスタンスによって独立して処理されます。スクリプト インスタンスでは、この呼を打診呼として認識することなく、通常の 2 者間呼として扱います。

転送先への打診後、ユーザは電話を切って転送をコミットし、2 つめのスクリプト インスタンスが打診要求を IP 電話 A から受信します。電話 C はローカルのアナログ電話であるため、ゲートウェイはローカルの打診 ID を生成してこのスクリプト インスタンスに登録します。スクリプトは、この打診 ID を含む打診応答を IP 電話 A に送信します。続いて、最初のスクリプト インスタンスが IP 電話 A から転送要求を受信します。この転送要求には 2 つめのスクリプト インスタンスから受信された打診 ID が含まれています。図1-7 を参照してください。

図1-7 1 つのゲートウェイ:Cisco CME IP 電話 XOR の打診転送

 

このスクリプト インスタンスは、打診 ID を含む転送呼を電話 C 宛てに発信します。打診 ID は 2 つめのスクリプト インスタンスに登録されているので、転送中継先コール レッグが 2 つめのスクリプト インスタンスに受け渡されます。2 つめのスクリプト インスタンスは受け渡しイベントを受け取り、転送中継先レッグと転送先レッグをブリッジします。最初のスクリプト インスタンスが転送元コール レッグを解放します。図1-8 を参照してください。

図1-8 1 つのゲートウェイ:転送後の Cisco CME IP 電話 XOR

 

2 つのゲートウェイとアナログ転送元のシナリオ

2 つの Cisco IOS ゲートウェイとアナログ転送が含まれるコール転送シナリオは複数あります。そのうちのいくつかを次に説明します。

ゲートウェイ 1 に XOR と XTO があり、ゲートウェイ 2 に XEE がある場合

最初のシナリオでは、転送元(電話 A)と転送先(電話 C)の終端点がゲートウェイ 1 に接続されています。転送中継先の終端点(電話 B)はゲートウェイ 2 に接続されています。図1-9 を参照してください。

図1-9 2 つのゲートウェイ(XOR/XTO と XEE):転送前のアナログ XOR

 

ブラインド転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先を入力してから電話を切ります。ゲートウェイ 1 のスクリプトが SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプトが受信します。このスクリプトは、電話 C に電話をかけ、呼が正常に確立すると転送元コール レッグを切断します。図1-10 を参照してください。

電話 C もゲートウェイ 1 に接続されていますが、電話 B から電話 C への着呼は TCL IVR スクリプトの別のインスタンスによって処理されます。このスクリプトは、コール転送の一部であることを認識することなく、電話 C に通常の電話をかけるだけです。

図1-10 2 つのゲートウェイ(XOR/XTO と XEE):アナログ XOR のブラインド転送

 

打診転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先の番号を入力します。次にスクリプトが転送先に電話をかけ、電話 A が電話 C に打診できるようにします。ユーザが(電話を切って)転送をコミットすると、スクリプトは転送先(電話 C)に打診 ID を要求します。電話 C はローカルのアナログ電話であるため、ゲートウェイはローカルの打診 ID を生成してこのスクリプト インスタンスに登録します。次に、スクリプトが打診 ID を含む SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の呼を処理するスクリプトが受信します。このスクリプトは、電話 C に電話をかけ、呼が正常に確立すると転送元コール レッグを切断します。図1-11 を参照してください。

図1-11 2 つのゲートウェイ(XOR/XTO と XEE):アナログ XOR の打診転送

 

確立要求には、転送要求で受信した打診 ID が含まれます。前述のブラインド転送の場合と異なり、電話 C に着信する確立要求は、電話 A と電話 B 間の元の呼、および電話 A と電話 C 間の打診呼を処理するものと同じスクリプトのインスタンスによって処理されます。このスクリプトは、着呼を電話 C に接続し、電話 A を切断します。図1-12 を参照してください。

図1-12 2 つのゲートウェイ(XOR/XTO と XEE):転送後のアナログ XOR

 

ゲートウェイ 1 に XOR と XEE があり、ゲートウェイ 2 に XTO がある場合

このシナリオでは、転送元(電話 A)と転送中継先(電話 B)がゲートウェイ 1 に接続されています。転送先(電話 C)はゲートウェイ 2 に接続されています。図1-13 を参照してください。

図1-13 2 つのゲートウェイ(XOR/XEE と XTO):転送前のアナログ XOR

 

ブラインド転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先を入力してから電話を切ります。スクリプトは、SIP または H.323 確立要求をゲートウェイ 2 に送信して電話 C に電話をかけます。ゲートウェイ 2 でこの確立要求を処理するスクリプトは、この呼がコール転送の一部であることを認識することなく、電話 C に通常の電話をかけます。呼が正常に確立したら、ゲートウェイ 1 のスクリプトが電話 B と電話 C をブリッジし、電話 A からの呼を解放します。図1-14 を参照してください。

図1-14 2 つのゲートウェイ(XOR/XEE と XTO):アナログ XOR のブラインド転送

 

打診転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先の番号を入力します。次に、スクリプトが転送先に電話をかけ、電話 A が電話 C に打診できるようにします。ユーザが(電話を切って)転送をコミットすると、スクリプトは転送先(電話 C)に打診 ID を要求します。

H.450 転送の場合、ゲートウェイ 1 は H.450 打診要求メッセージを電話 C に送信します。この要求は、ゲートウェイ 2 の電話 A と電話 C 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、打診 ID を含む打診応答を送信します。図1-15 を参照してください。

SIP の場合、打診要求は電話 C には送信されません。代わりに、打診 ID がゲートウェイ 1 によってローカルに生成されます。どちらの場合も、ゲートウェイ 1 のスクリプトは打診応答を受信すると、この打診 ID を含む SIP または H.450 確立要求をゲートウェイ 2 に送信します。確立要求は、ゲートウェイ 2 に到着後、電話 A と電話 C 間の打診呼を処理するものと同じスクリプト インスタンスに配信されます。

図1-15 2 つのゲートウェイ(XOR/XEE と XTO):アナログ XOR の打診転送

 

このスクリプトは、着呼を電話 C に接続し、電話 A からの打診呼を切断します。図1-16 を参照してください。

図1-16 2 つのゲートウェイ(XOR/XEE と XTO):転送後のアナログ XOR

 

ゲートウェイ 1 に XOR があり、ゲートウェイ 2 に XEE と XTO がある場合

この 3 つめのコール転送シナリオには、図1-17 のように 2 つのゲートウェイが含まれます。転送元(電話 A)はゲートウェイ 1 に接続し、転送中継先(電話 B)と転送先(電話 C)はゲートウェイ 2 に接続しています。

図1-17 2 つのゲートウェイ(XOR と XEE/XTO):転送前のアナログ XOR

 

ブラインド転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先を入力してから電話を切ります。ゲートウェイ 1 のスクリプトが SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプトが受信します。このスクリプトは、電話 C に電話をかけます。呼が正常に確立すると、このスクリプトは電話 B を電話 C に接続し、電話 A からの呼を切断します。図1-18 を参照してください。

図1-18 2 つのゲートウェイ(XOR と XEE;/XTO):アナログ XOR のブラインド転送

 

打診転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先の番号を入力します。次に、スクリプトが転送先に電話をかけ、電話 A が電話 C に打診できるようにします。電話 A からの着呼は、ゲートウェイ 2 の、電話 A と電話 B 間の呼を処理するスクリプト インスタンスとは別のスクリプト インスタンスによって処理されます。図1-19 を参照してください。

ユーザが(電話を切って)転送をコミットすると、ゲートウェイ 1 のスクリプトは転送先(電話 C)に打診 ID を要求します。H.450 転送の場合、ゲートウェイ 1 は H.450 打診要求メッセージを電話 C に送信します。要求は、ゲートウェイ 2 の電話 A と電話 C 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、打診 ID を含む打診応答を送信します。

SIP の場合、打診要求は電話 C には送信されません。代わりに、打診 ID がゲートウェイ 1 によってローカルに生成されます。どちらの場合も、ゲートウェイ 1 のスクリプトは、打診応答を受信すると、この打診 ID を含む SIP または H.450 転送要求をゲートウェイ 2 に送信します。

図1-19 2 つのゲートウェイ(XOR と XEE/XTO):アナログ XOR の打診転送

 

転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、電話 C に電話をかけます。確立要求には、転送要求で受信した打診 ID が含まれます。確立要求に含まれる打診 ID は、打診応答でゲートウェイ 1 に送信された打診 ID と一致するため、呼の確立は、着呼を 2 つめのスクリプト インスタンスに受け渡すことで完了します。受け渡し後、電話 A から電話 B への元の呼は、ゲートウェイ 2 の最初のスクリプト インスタンスによって切断され、電話 A からの打診呼は、2 つめのスクリプト インスタンスによって切断されます。図1-20 を参照してください。

図1-20 2 つのゲートウェイ(XOR と XEE/XTO):転送後のアナログ XOR

 

2 つのゲートウェイと Cisco CME IP 電話の転送元のシナリオ

2 つの Cisco IOS ゲートウェイと Cisco CallManager Express(CME)IP 電話の転送元が含まれるコール転送シナリオは複数あります。そのうちのいくつかを次に説明します。

ゲートウェイ 1 に XOR と XTO があり、ゲートウェイ 2 に XEE がある場合

最初のシナリオを、図1-21 に示します。ここでは、転送元(電話 A)と転送先(電話 C)の終端点がゲートウェイ 1 に接続されています。転送中継先の終端点(電話 B)はゲートウェイ 2 に接続されています。

図1-21 2 つのゲートウェイ(XOR/XTO と XEE):転送前の Cisco CME IP 電話 XOR

 

ブラインド転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先を入力します。スクリプトが電話から転送要求イベントを受け取り、SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプトが受信します。このスクリプトは、電話 C に電話をかけ、呼が正常に確立すると転送元コール レッグを切断します。電話 C もゲートウェイ 1 に接続されていますが、電話 B から電話 C への着呼は TCL IVR スクリプトの別のインスタンスによって処理されます。このスクリプトは、コール転送の一部であることを認識することなく、電話 C に通常の電話をかけるだけです。図1-22 を参照してください。

図1-22 2 つのゲートウェイ(XOR/XTO と XEE):Cisco CME IP 電話 XOR のブラインド転送

 

打診転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先の番号を入力します。IP 電話は、別の回線を使用して転送先に電話をかけます。この呼は、ゲートウェイ 1 で実行されている TCL IVR スクリプトの 2 つめのインスタンスによって独立して処理されます。スクリプト インスタンスでは、この呼は打診呼として認識されることなく、通常の 2 者間呼として扱われます。図1-23 を参照してください。

転送先への打診後、ユーザは電話を切って転送をコミットし、2 つめのスクリプト インスタンスが打診要求を IP 電話 A から受信します。電話 C はローカルのアナログ電話であるため、ゲートウェイはローカルの打診 ID を生成してこのスクリプト インスタンスに登録します。スクリプトは、この打診 ID を含む打診応答を IP 電話 A に送信します。

続いて、最初のスクリプト インスタンスが IP 電話 A から転送要求を受信します。この転送要求には 2 つめのスクリプトから受信した打診 ID が含まれます。このスクリプトは打診 ID を含む SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプトが受信します。このスクリプトは、電話 C に電話をかけ、呼が正常に確立すると転送元コール レッグを切断します。確立要求には、転送要求で受信した打診 ID が含まれます。

図1-23 2 つのゲートウェイ(XOR/XTO と XEE):Cisco CME IP 電話 XOR の打診転送

 

着信した確立要求は、電話 A と電話 C 間の打診呼を処理するゲートウェイ 1 のスクリプト インスタンスに配信されます。このスクリプトは着呼を電話 C に接続し、電話 A からの呼を解放します。図1-24 を参照してください。

図1-24 2 つのゲートウェイ(XOR/XTO と XEE):転送後の Cisco CME IP 電話 XOR

 

ゲートウェイ 1 に XOR と XEE があり、ゲートウェイ 2 に XTO がある場合

2 つめのシナリオには、2 つのゲートウェイと IP 電話の転送元が含まれます。転送元(電話 A)と転送中継先(電話 B)はゲートウェイ 1 に接続されています。転送先(電話 C)はゲートウェイ 2 に接続されています。図1-25 を参照してください。

図1-25 2 つのゲートウェイ(XOR/XEE と XTO):転送前の Cisco CME IP 電話 XOR

 

ブラインド転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先を入力します。スクリプトは、電話 A からの転送要求を受信し、SIP または H.323 確立要求をゲートウェイ 2 に送信して電話 C に電話をかけます。ゲートウェイ 2 でこの確立要求を処理するスクリプトは、この呼がコール転送の一部であることを認識することなく、電話 C に通常の電話をかけます。呼が正常に確立したら、ゲートウェイ 1 のスクリプトが電話 B と電話 C をブリッジし、電話 A からの呼を解放します。図1-26 を参照してください。

図1-26 2 つのゲートウェイ(XOR/XEE と XTO):Cisco CME IP 電話 XOR のブラインド転送

 

打診転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先の番号を入力します。IP 電話は、別の回線を使用して転送先に電話をかけます。この呼は、ゲートウェイ 1 で実行されている TCL IVR スクリプトの 2 つめのインスタンスによって独立して処理されます。スクリプト インスタンスでは、この呼は通常の 2 者間呼として扱われ、打診呼として認識されることはありません。

転送先への打診後、ユーザは電話を切って転送をコミットし、2 つめのスクリプト インスタンスが打診要求を IP 電話 A から受信します。H.450 転送の場合、ゲートウェイ 1 は、H.450 打診要求メッセージを電話 C に送信して、この打診要求を電話 C にリレーします。要求は、ゲートウェイ 2 の電話 A と電話 C 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、打診 ID を含む打診応答を送信します。図1-27 を参照してください。

SIP の場合、打診要求は電話 C にリレーされません。代わりに、打診 ID がゲートウェイ 1 によってローカルに生成されます。どちらの場合も、ゲートウェイ 1 のスクリプトは打診応答を受信すると、それを IP 電話 A にリレーします。さらに、Cisco IOS アプリケーション フレームワークの内部打診 ID 管理体系により、ゲートウェイ 2 から受信した打診 ID は、このスクリプト インスタンス(2 つめのインスタンス)に登録されます。


) ゲートウェイ 2 のスクリプト インスタンスは、打診応答をゲートウェイ 1 に送信したので、転送中継先から着呼が来るものと期待します。転送は、受け渡しによりゲートウェイ 1 でローカルに処理されたため、ゲートウェイ 2 がこの着呼を受信することはありません。最終的には Cisco IOS のガード タイマーが時間切れになり、スクリプトは引き続き電話 A と電話 C 間の呼を通常の 2 者間呼として処理します。


続いて、最初のスクリプト インスタンスが IP 電話 A から転送要求を受信します。この転送要求には 2 つめのスクリプトから受信した打診 ID が含まれています。このスクリプト インスタンスは、電話 C に打診 ID を含む発呼を行います。

図1-27 2 つのゲートウェイ(XOR/XEE と XTO):Cisco CME IP 電話 XOR の打診転送

 

打診 ID が 2 つめのスクリプト インスタンスに登録されているので、転送中継先コール レッグが 2 つめのスクリプト インスタンスに受け渡されます。このスクリプト インスタンスは受け渡しイベントを受け取り、転送中継先レッグと転送先レッグをブリッジします。最初のスクリプト インスタンスが転送元コール レッグを解放します。図1-28 を参照してください。

図1-28 2 つのゲートウェイ(XOR/XEE と XTO):転送後の Cisco CME IP 電話 XOR

 

ゲートウェイ 1 に XOR があり、ゲートウェイ 2 に XEE と XTO がある場合

3 つめのコール転送シナリオには、図1-29 のように 2 つのゲートウェイと IP 電話の転送元が含まれます。転送元(電話 A)はゲートウェイ 1 に接続し、転送中継先(電話 B)と転送先(電話 C)はゲートウェイ 2 に接続しています。

図1-29 2 つのゲートウェイ(XOR と XEE/XTO):転送前の Cisco CME IP 電話 XOR

 

ブラインド転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先を入力します。スクリプトが電話から転送要求イベントを受け取り、SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプトが受信します。このスクリプトは、電話 C に電話をかけます。呼が正常に確立すると、ゲートウェイ 2 のスクリプトが電話 B と電話 C をブリッジし、電話 A からの呼を解放します。図1-30 を参照してください。

図1-30 2 つのゲートウェイ(XOR & XEE/XTO):Cisco CME IP 電話 XOR のブラインド転送

 

打診転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先の番号を入力します。IP 電話は、別の回線を使用して転送先に電話をかけます。呼は、ゲートウェイ 1 で実行されている TCL IVR スクリプトの 2 つめのインスタンスによって独立して処理されます。このスクリプト インスタンスでは、この呼は通常の 2 者間呼として扱われ、打診呼として認識されることはありません。

転送先への打診後、ユーザは電話を切って転送をコミットし、2 つめのスクリプト インスタンスが打診要求を IP 電話 A から受信します。H.450 転送の場合、ゲートウェイ 1 は、H.450 打診要求メッセージを電話 C に送信して、この打診要求を電話 C にリレーします。要求は、ゲートウェイ 2 の電話 A と電話 C 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、打診 ID を含む打診応答を送信します。SIP の場合、打診要求は電話 C にリレーされません。代わりに、打診 ID がゲートウェイ 1 によってローカルに生成されます。どちらの場合も、ゲートウェイ 1 のスクリプトは打診応答を受信すると、それを IP 電話 A にリレーします。さらに、Cisco IOS アプリケーション フレームワークの内部打診 ID 管理体系により、ゲートウェイ 2 から受信した打診 ID は、このスクリプト インスタンス(2 つめのインスタンス)に登録されます。

続いて、ゲートウェイ 1 の最初のスクリプト インスタンスが IP 電話 A から転送要求を受信します。この転送要求にはゲートウェイ 1 の 2 つめのスクリプト インスタンスから受信した打診 ID が含まれています。次に、スクリプト インスタンスが打診 ID を含む SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは電話 C に電話をかけます。確立要求に含まれる打診 ID は、打診応答でゲートウェイ 1 に送信された打診 ID と一致するため、呼の確立は、着呼を 2 つめのスクリプト インスタンスに受け渡すことで完了します。図1-31 を参照してください。

図1-31 2 つのゲートウェイ(XOR と XEE/XTO):Cisco CME IP 電話 XOR の打診転送

 

受け渡し後、電話 A から電話 B への元の呼は、ゲートウェイ 2 の最初のスクリプト インスタンスによって切断され、電話 A からの打診呼は、2 つめのスクリプト インスタンスによって切断されます。図1-32 を参照してください。

図1-32 2 つのゲートウェイ(XOR & XEE/XTO):転送後の Cisco CME IP 電話 XOR

 

3 つのゲートウェイとアナログ転送元のシナリオ

図1-33 は、コール転送に 3 つのゲートウェイが含まれるシナリオを示しています。コール転送の各参加者は、別々の Cisco IOS ゲートウェイに接続しています。

図1-33 3 つのゲートウェイ:転送前のアナログ XOR

 

ブラインド転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先を入力してから電話を切ります。ゲートウェイ 1 のスクリプトが SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の呼を処理するスクリプトが受信します。このスクリプトは、通常の電話を電話 C にかけます。ゲートウェイ 3 で着呼の確立を受信したスクリプトは、この呼を通常の 2 者間呼として扱います。確立が完了したら、ゲートウェイ 2 のスクリプトは転送応答を電話 A に送信します。ゲートウェイ 1 のスクリプトは転送応答を受信し、電話 A からの呼を解放します。図1-34 を参照してください。

図1-34 3 つのゲートウェイ:アナログ XOR のブラインド転送

 

打診転送を開始するには、アナログ電話のユーザはフックフラッシュを押し、転送の宛先の番号を入力します。次にスクリプトが転送先に電話をかけ、電話 A が電話 C に打診できるようにします。ユーザが(電話を切って)転送をコミットすると、スクリプトは転送先(電話 C)に打診 ID を要求します。H.450 コール転送の場合、打診要求プロトコル メッセージが電話 C に送信されます。この要求は、ゲートウェイ 3 の電話 A と電話 C 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、打診 ID を含む打診応答を送信します。図1-35 を参照してください。

SIP の場合、打診要求は電話 C には送信されません。代わりに、打診 ID がゲートウェイ 1 によってローカルに生成されます。どちらの場合も、ゲートウェイ 1 のスクリプトは、打診応答を受信すると、打診 ID を含む SIP または H.450 転送要求を電話 B に送信します。

この転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプトが受信します。このスクリプトは電話 C に電話をかけます。確立要求には、電話 A からの転送要求で受信した打診 ID が含まれています。電話 B からの着信確立要求がゲートウェイ 2 に到着すると、電話 A と電話 C 間の呼を処理するスクリプト インスタンスに配信されます。

図1-35 3 つのゲートウェイ:アナログ XOR の打診転送

 

このスクリプトは、着呼を電話 C に接続し、電話 A からの呼を切断します。図1-36 を参照してください。

図1-36 3 つのゲートウェイ:転送後のアナログ XOR

 

3 つのゲートウェイと Cisco CME IP 電話の転送元のシナリオ

図1-37 は、コール転送に 3 つのゲートウェイが含まれるシナリオを示しています。コール転送の各参加者は、別々の Cisco IOS ゲートウェイに接続しています。

図1-37 3 つのゲートウェイ:転送前の Cisco CME IP 電話 XOR

 

ブラインド転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先を入力します。スクリプトが電話から転送要求イベントを受け取り、SIP または H.450 転送要求を電話 B に送信します。転送要求は、ゲートウェイ 2 の呼を処理するスクリプトが受信します。このスクリプトは、通常の電話を電話 C にかけます。ゲートウェイ 3 で着呼の確立を受信したスクリプトは、この呼を通常の 2 者間呼として扱います。確立が完了したら、ゲートウェイ 2 のスクリプトは転送応答を電話 A に送信します。ゲートウェイ 1 のスクリプトは転送応答を受信し、電話 A からの呼を解放します。図1-38 を参照してください。

図1-38 3 つのゲートウェイ:Cisco CME IP 電話 XOR のブラインド転送

 

打診転送を開始するには、IP 電話のユーザは電話の転送ボタンを押して、転送の宛先の番号を入力します。IP 電話は、別の回線を使用して転送先に電話をかけます。この呼は、ゲートウェイ 1 で実行されている TCL IVR スクリプトの 2 つめのインスタンスによって独立して処理されます。スクリプト インスタンスでは、この呼は通常の 2 者間呼として扱われ、打診呼として認識されることはありません。図1-39 を参照してください。

転送先への打診後、ユーザは電話を切って転送をコミットし、2 つめのスクリプト インスタンスが打診要求を IP 電話 A から受信します。H.450 転送の場合、ゲートウェイ 1 は、H.450 打診要求メッセージを電話 C に送信して、この打診要求を電話 C にリレーします。要求は、ゲートウェイ 3 の電話 A と電話 C 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは、打診 ID を含む打診応答を送信します。

SIP の場合、打診要求は電話 C にリレーされません。代わりに、打診 ID がゲートウェイ 1 によってローカルに生成されます。どちらの場合も、ゲートウェイ 1 のスクリプトは打診応答を受信すると、それを IP 電話 A にリレーします。さらに、Cisco IOS アプリケーション フレームワークの内部打診 ID 管理体系により、ゲートウェイ 2 から受信した打診 ID は、このスクリプト インスタンス(2 つめのインスタンス)に登録されます。

続いて、ゲートウェイ 1 の最初のスクリプト インスタンスが IP 電話 A から転送要求を受信します。この転送要求には 2 つめのスクリプトから受信した打診 ID が含まれています。このスクリプト インスタンスは、この打診 ID を含む SIP または H.450 転送要求を電話 B に送信します。

この転送要求は、ゲートウェイ 2 の電話 A と電話 B 間の呼を処理するスクリプト インスタンスが受信します。このスクリプトは電話 C に電話をかけます。確立要求には、電話 A からの転送要求で受信した打診 ID が含まれます。電話 B からの着信確立要求がゲートウェイ 3 に到着すると、電話 A と電話 C 間の呼を処理するスクリプト インスタンスに配信されます。

図1-39 3 つのゲートウェイ:Cisco CME IP 電話 XOR の打診転送

 

このスクリプトは、着呼を電話 C に接続し、電話 A からの呼を切断します。図1-40 を参照してください。

図1-40 3 つのゲートウェイ:転送後の Cisco CME IP 電話 XOR

 

コール転送プロトコルのサポート

ここでは、Cisco IOS 音声ゲートウェイで TCL IVR スクリプトを使用する場合にサポートされるコール転送プロトコルの概要について説明します。このようなプロトコルを使用するさまざまなシナリオについては、該当するセクションを参照してください。

アナログ フックフラッシュと T1 CAS Release Link Trunk(RLT)転送

転送元サポート

スクリプトから T1 CAS またはアナログ FXO の終端点に向けてフックフラッシュ転送を開始することはできません。代わりに、スクリプトは転送先宛てに電話をかけ、呼が確立したら、転送中継先コール レッグと転送先コール レッグを接続します。

転送中継先サポート

TCL IVR スクリプトは、ゲートウェイに接続している T1 CAS またはアナログ FXS の終端点からフックフラッシュ転送要求を受信できます。加入者は、フックフラッシュまたは DTMF ディジットを使用して、ブラインド転送または打診呼転送を開始できます。

スクリプトは、フックフラッシュ転送トリガーを受信すると、ダイヤル トーンを発し、DTMF によって転送の宛先を収集できます。

スクリプトは、転送コミット要求を受信すると、次のいずれかを実行できます。

転送要求を転送中継先コール レッグに伝達してインターワーキングする。これは、転送中継先コール レッグがこのマニュアルで説明する転送プロトコルのいずれかをサポートしている場合に実行できます。

転送先宛てに電話をかけ、呼が確立したら転送中継先と転送先を接続する。

転送先サポート

TCL IVR スクリプトは、アナログ終端点から打診 ID を含む打診要求または確立結果を受信できません。

ISDN コール転送

転送元サポート

TCL IVR スクリプトは、転送中継先と転送先の両方が、ゲートウェイに接続する PBX の同じ TBCT グループに属している場合、ISDN Two B-Channel Transfer(TBCT)要求を転送中継先コール レッグに送信できます。

スクリプトが TBCT 要求を開始すると、Cisco IOS ソフトウェアは転送先に電話をかけます。転送先が応答すると、転送中継先と転送先が PBX に設定された同じ TBCT グループに属する場合は、Cisco IOS ソフトウェアが TBCT を開始します。転送中継先と転送先が同じ TBCT グループに属していない場合は、転送中継先コール レッグと転送先コール レッグはスクリプトによってブリッジされます。呼が PBX に正常に転送された場合、転送中継先コール レッグと転送先コール レッグは解放され、スクリプトは呼を終了できます。転送しようとして失敗した場合、スクリプトは転送元コール レッグと転送中継先コール レッグに再接続することもできます。

スクリプトは、打診転送を開始するために次のことを実行できます。

転送先デバイスに打診呼を送り、呼が確立したら転送元コール レッグと転送先コール レッグを接続する。

転送中継先と転送先が同じ TBCT グループに属する場合、転送がコミットされるとスクリプトは次のことを実行できます。

ローカルの TBCT 打診 ID を要求する。

TBCT 要求を転送中継先コール レッグに送信する。転送要求には打診 ID が含まれます。

呼が PBX に正常に転送された場合、転送中継先コール レッグと転送先コール レッグは解放され、スクリプトは呼を終了できます。

転送しようとして失敗した場合、スクリプトは転送元コール レッグと転送中継先コール レッグに再接続することもできます。

転送中継先と転送先が同じ TBCT グループに属していない場合は、転送がコミットされると、スクリプトによって転送中継先コール レッグと転送先コール レッグをブリッジできます。

転送中継先サポート

TCL IVR スクリプトは、ネットワーク側の ISDN コール転送プロトコルはサポートしていないため、ISDN デバイスからコール転送要求を受信することはできません。


) ISDN 加入者が転送をトリガーする DTMF 入力を使用してブラインド転送を開始できるようにすることは可能です。このメカニズムは、前述したアナログ FXS および T1 CAS の転送メカニズムに似ていますが、このマニュアルでは詳細な説明を省きます。


転送先サポート

TCL IVR スクリプトは、ISDN 終端点から打診 ID を含む打診要求または確立結果を受信できません。

SIP コール転送

転送元サポート

TCL IVR スクリプトは、REFER 転送要求をリモートの転送中継先コール レッグに送信できます。また、スクリプトは、打診転送を実行するときに打診呼を開始することもできます。

スクリプトは、REFER メッセージをリモートの転送中継先に送信してブラインド転送を開始できます。転送が成功すると、転送中継先は転送先に電話をかけます。呼はこのスクリプトの関与なしに確立し、スクリプトは呼を終了できます。転送しようとして失敗した場合、スクリプトは転送元コール レッグと転送中継先コール レッグに再接続することもできます。

スクリプトは、打診転送を開始するために次のことを実行できます。

転送先デバイスに打診呼を送り、呼が確立したら転送元コール レッグおよび転送先コール レッグを接続する。

転送がコミットされたら、打診 ID を要求する。


) H.450 転送とは異なり、転送元と転送先間の打診呼を処理するスクリプトが、転送元から打診要求を受信することはありません。代わりに、打診 ID は転送元と転送中継先間の元の呼を処理するスクリプトによってローカルに生成されます。


転送中継先コール レッグに REFER を送信する。これには打診 ID が含まれます。転送中継先デバイスは、転送先に送信する INVITE メッセージに打診 ID を含めます。

転送が成功すると、転送中継先が転送先に電話をかけます。呼はこのスクリプトの関与なしに確立し、スクリプトは呼を終了できます。

転送しようとして失敗した場合、スクリプトは転送元コール レッグと転送中継先コール レッグに再接続することもできます。

転送中継先サポート

TCL IVR スクリプトはリモートの SIP 転送元から SIP REFER または BYE/ALSO 転送要求を受信できます。転送要求を受信すると、スクリプトは次のいずれかを実行できます。

転送要求を転送中継先コール レッグに伝達してインターワーキングする。これは、転送中継先コール レッグがこのマニュアルで説明する転送プロトコルのいずれかをサポートしている場合に実行できます。


) 現在、SIP 転送要求と H.450 転送要求のインターワーキングはできません。


転送先宛てに電話をかけ、呼が確立したら転送中継先と転送先を接続する。

転送先サポート

ゲートウェイがリモートの転送中継先から打診 ID を含む INVITE 要求を受信すると、その要求は転送先への打診呼を処理するスクリプト インスタンスに配信されます。この後、このスクリプトは転送中継先コール レッグと転送先コール レッグを接続し、転送元コール レッグを切断できます。


) H.450 転送とは異なり、転送元と転送先間の打診呼を処理するスクリプトが、転送元から打診要求を受信することはありません。代わりに、打診 ID は転送元と転送中継先間の元の呼を処理するスクリプトによってローカルに生成されます。


H.450 コール転送

転送元サポート

TCL IVR スクリプトは、H450.2 転送要求を転送中継先コール レッグに送信できます。また、スクリプトは、打診転送を実行するときに打診呼を開始することもできます。

スクリプトは、H450.2 転送要求をリモートの転送中継先に送信してブラインド転送を開始できます。転送が成功すると、転送中継先が転送先に電話をかけます。呼はこのスクリプトの関与なしに確立し、スクリプトは呼を終了できます。転送しようとして失敗した場合、スクリプトは転送元コール レッグと転送中継先コール レッグに再接続することもできます。

スクリプトは、打診転送を開始するために次のことを実行できます。

転送先デバイスに打診呼を送り、呼が確立したら転送元コール レッグおよび転送先コール レッグを接続する。

転送がコミットされたら、転送先からの打診 ID を要求する。

H450.2 転送要求を転送中継先コール レッグに送信する。これには、転送先デバイスからの打診応答で受信した打診 ID が含まれます。転送中継先は、転送先に送信する SETUP 要求にこの打診 ID を含めます。

転送が成功すると、転送中継先が転送先に電話をかけ、このスクリプトが関与することなく呼が確立します。スクリプトは呼を終了できます。

転送しようとして失敗した場合、スクリプトは転送元コール レッグと転送中継先コール レッグに再接続することもできます。

転送中継先サポート

TCL IVR スクリプトは、H450.2 転送要求をリモートの H.323 転送元から受信できます。転送要求を受信すると、スクリプトは次のいずれかを実行できます。

転送要求を転送中継先コール レッグに伝達してインターワーキングする。これは、転送中継先コール レッグがこのマニュアルで説明する転送プロトコルのいずれかをサポートしている場合に実行できます。


) SIP 転送要求と H.450 転送要求のインターワーキングはできません。


転送先宛てに電話をかけ、呼が確立したら転送中継先と転送先を接続する。

転送先サポート

TCL IVR スクリプトは、リモートの H450 転送元から打診要求を受信し、打診 ID と転送の宛先を含む打診応答を送信できます。この転送の宛先は、転送中継先が転送先に電話をかけるときに使用する必要がある番号です。

ゲートウェイがリモートの転送中継先から H450.2 打診 ID を含む SETUP 要求を受信すると、その要求は転送先への打診呼を処理するスクリプト インスタンスに配信されます。この後、このスクリプトは転送中継先コール レッグと転送先コール レッグを接続し、転送元コール レッグを切断できます。

Cisco CallManager Express コール転送

転送元サポート

TCL IVR スクリプトは、コール転送要求を Cisco CallManager Express(CME)モードで動作する Cisco IOS ゲートウェイに登録されたローカルの IP 電話に送信することはできません。代わりに、スクリプトは転送先宛てに電話をかけ、呼が確立したら、転送中継先コール レッグと転送先コール レッグを接続します。

転送中継先サポート

TCL IVR スクリプトは、コール転送要求を Cisco CME モードで動作する Cisco IOS ゲートウェイに登録されたローカルの IP 電話から受信できます。転送要求を受信すると、スクリプトは次のいずれかを実行できます。

転送要求を転送中継先コール レッグに伝達してインターワーキングする。これは、転送中継先コール レッグがこのマニュアルで説明する転送プロトコルのいずれかをサポートしている場合に実行できます。

転送先宛てに電話をかけ、呼が確立したら転送中継先と転送先を接続する。

転送先サポート

TCL IVR スクリプトは、ローカルの Cisco CME IP 電話から打診要求を受信し、次のいずれかを実行できます。

打診要求を別のコール レッグにリレーすることでインターワーキングする。これは、転送中継先コール レッグがこのマニュアルで説明する転送プロトコルのいずれかをサポートしている場合に実行できます。

ローカルに生成された打診 ID と転送の宛先を含む打診要求を IP 電話に送信する。この転送の宛先は、転送中継先が転送先に電話をかけるときに使用する必要がある番号です。

ゲートウェイがリモートの転送中継先から打診 ID を含む SETUP 要求を受信すると、その要求は転送先への打診呼を処理するスクリプトに配信されます。この後、このスクリプトは転送中継先コール レッグと転送先コール レッグを接続し、転送元コール レッグを切断できます。

SIP 登録および通知

TCL IVR 2.0 スクリプトは、SIP 登録サーバに登録し、通知イベントを受け取る機能を備えています。通知を受信したときにアプリケーションを起動できるため、登録されたイベントの完了までに時間がかかりそうな場合(数分や数時間など)に便利です。この場合、アプリケーションでは、インスタンスを解放し、通知を受信したときにシステムが別のインスタンスを作成して通知を処理するように指定することもできます。

通知を処理するアプリケーションは、登録を実行したアプリケーションと同じである必要はありません。そのため、登録と通知を別々のアプリケーションで柔軟に処理することができます。

登録を実行したアプリケーションは、次のタスクを実行できます。

実行を継続して、サーバからの通知を処理する。

インスタンスを解放し、通知を受信した時点で同じアプリケーションの別のインスタンスを生成させる。

インスタンスを解放し、通知を受信した時点で別のアプリケーションを生成させる。

別のモジュールに通知を処理させる。

SIP ヘッダー

TCL IVR 2.0 スクリプトは、SIP INVITE または H.323 SETUP メッセージで送信するヘッダーを指定できます。スクリプトを記述する場合、ヘッダー値のペアを宛先 URI の「?」の後に付加できます。次の例を参考にしてください。

set destination “sip:joe@big.com?Subject=Hotel Reservation&Priority=urgent&
X-ReferenceNumber=1234567890"
leg setup destination callInfo leg_incoming
 

宛先の文字列が URI ではなく E.164 番号の場合、ヘッダーを宛先 URI に付加できないため、set コマンドを使用してヘッダーを設定できます。次の例を参考にしてください。

set setupSignal(Subject) “Hotel Reservation”
set setupSignal(Priority) “urgent”
set setupSignal(X-ReferenceNumber) “1234567890”
set callInfo(protoHeaders) setupSignal
set destination “4085550100”
leg setup destination callInfo leg_incoming
 

発呼については、アプリケーション固有のヘッダーを SPI に渡すデータ パッシング メカニズムが提供されます。TCL スクリプトは、 evt_proto_headers または leg_proto_headers 情報タグを使用してヘッダーを取得できます。Cisco IOS リリース 12.3(4)T では、ヘッダーへのアクセスは SIP INVITE、SUBSCRIBE、NOTIFY メッセージ、および H.323 SETUP メッセージに制限されています。ただし、次に挙げたヘッダーは上書きできません。

call-ID

Supported

Require

Min-SE

Session-Expires

Max-Forwards

CSeq


) ヘッダーを渡すときに各コール レッグに割り当てられるメモリは最大 20 K に制限されています。各ヘッダーの AV ペアは 256 文字に制限されています。TCL スクリプトが 256 文字を超えるヘッダー AV ペアを渡そうとした場合や、20 K のメモリを使い切った場合には、アプリケーションがエラーをスローします。


呼が発信アプリケーションに受け渡される場合、その発信アプリケーションにより、前のアプリケーションから受け渡されたすべてのヘッダーに加え、SPI で設定された着信コール レッグからのヘッダーも evt_handoff proto_headers 情報タグを使用して取得できます。

アプリケーション インスタンス

Cisco 音声ゲートウェイに設定された TCL IVR 2.0 アプリケーションは、通常、着呼によりトリガーされます。その後、アプリケーションを使用して発信者に IVR サービスを提供し、1 つ以上のコール レッグを作成して制御できます。音声コールによってアプリケーションが起動されると、そのアプリケーションのインスタンスまたはセッションがアプリケーションによって開始されます。アプリケーション インスタンスは、アプリケーション スクリプトを実行し、別のアプリケーションに電話をかけたり、呼を転送したりすることができます。呼は、システムの呼処理の設定に応じて、1 つまたは複数のアプリケーション インスタンスを開始できます。1 つのアプリケーション セッションで複数の音声コールを管理できます。

Cisco IOS リリース 12.3(x) では、TCL IVR 2.0 アプリケーションのインスタンスをゲートウェイでコール レッグなしに手動で開始できます。そのため、着呼を必要とすることなくゲートウェイでアプリケーション セッションを起動できます。たとえば、キープアライブ サービスを提供するために、サーバ グループのステータスを監視するアプリケーションを作成するとします。このアプリケーションのインスタンスは、ステータス情報を、着呼を処理する別のアプリケーションに渡すことができます。この種類のサービス アプリケーションは、呼によってトリガーされることなくゲートウェイで実行できます。

TCL IVR 2.0 アプリケーションのインスタンスは、call application session start CLI コマンドを使用してゲートウェイで開始できます。アプリケーション インスタンスは、同じゲートウェイにある別のセッションと通信が可能であり、呼は異なるセッション間でブリッジできます。

mod_all_handles 情報タグを使用して、ゲートウェイで現在実行中の全インスタンスのリストを取得できます。


) TCL IVR 2.0 では、ハンドラあたりの登録数が 18 に制限されています。スクリプト インスタンスはそれぞれがハンドラであるため、アプリケーション インスタンスが同時に処理できる登録数は最大 18 です。


セッション対話

セッションは TCL アプリケーションの 1 つのインスタンスであり、直接データを共有しないという点では、別のセッションから独立しています。たとえば、あるセッションのグローバル TCL 変数を別のセッションで使用することはできません。ただし、アプリケーション セッションは、メッセージの送受信やセッション間での呼の受け渡しを行うために、ゲートウェイの別のセッションと通信できます。

TCL セッションは、複数の発信コール レッグを開始し、そこに着信コール レッグや発信コール レッグを受け渡すことができます。TCL セッションは、sendmsg または通知から CLI で開始された場合、または処理するレッグを切断した場合は、コール レッグなしに実行できます。

セッションの開始と停止

最も一般的にセッションが開始されるのは、TCL アプリケーションが着信音声コールを処理する場合ですが、セッションは、sendmsg または通知から CLI で開始される場合、または処理していたコール レッグを切断する場合は、コール レッグなしでも実行できます。

TCL インスタンスが開始すると、開始方法に応じて次のいずれかのイベントを受け取ります。

ev_msg_indication

ev_notify

ev_session_indication

ev_call_indication

ユーザが TCL セッションを call app session stop CLI コマンドを使用して停止すると、TCL スクリプトは ev_session_terminate イベントを受け取ります。その TCL スクリプトは終了するものと期待されます。TCL スクリプトが 10 秒以内に終了しなければ、セッションは強制的に遮断され、コール レッグは切断されます。そのため、TCL スクリプトは時間を取って適切に終了できます。

イベントの処理後にセッションが戻り、実行中のタイマー、レッグ、登録されたサービス、または登録がない場合、セッションは終了されます。

メッセージの送信

メッセージは、 sendmsg コマンドを使用して別のアプリケーション インスタンスに送信されます。sendmsg コマンドは非同期コマンドで、宛先がイベントに反応して動作するのを待つ必要がありません。アプリケーション名が指定されると、そのアプリケーションの新しいインスタンスが生成されます。

メッセージの受信

アプリケーションには、ev_msg_indication イベントによって別のアプリケーションからの着信メッセージが通知されます。メッセージと一緒に渡されるパラメータは、 evt_msg 情報タグによってアプリケーションで使用できるようになります。送信側アプリケーションのハンドルは、 evt_msg_source 情報タグによって使用できます。

呼の受け渡し

handoff コマンドは、アプリケーション名を渡すだけでなく、ハンドルを渡すこともできます。たとえば、TCL スクリプトが発信者の課金番号を収集し、呼が別のインスタンスによって処理中であるという通知を受信したとします。スクリプトは、handoff コマンドを使用して着信コール レッグを別のアプリケーション インスタンスに渡し、引数の文字列で情報を提供します。別のアプリケーション インスタンスがコール レッグを戻すと、このアプリケーションは ev_returned イベントを受け取ります。

受け渡しの戻り

受け渡しの戻りでさまざまなセッションから別々のコール レッグを受信する場合、コール レッグごとに handoff return コマンドを実行する必要があります。「handoff return leg_all」コマンドは、この場合には定義されていません。最初のユーザ定義レッグについて、レッグ全体のセットが戻り先に戻される必要があります。

会議レッグ セットの受け渡しの戻りでは、両方のレッグを同じセッションに戻す必要があります。たとえば、セッションに session1 から leg1、session2 から leg2 が受け渡され、2 つのレッグで会議通信を行ったとします。この場合、handoff return $leg2 コマンドは、会議通信を行った両方のレッグをセッション 2 に戻します。

サービス レジストリ

サービス レジストリは、サービスとして登録している TCL IVR 2.0 アプリケーション インスタンスのすべてをトラッキングするデータベースです。このため、別の TCL アプリケーションは、登録されたアプリケーションであれば、検索して通信することができます。

TCL セッションは、Cisco IOS ソフトウェアを使用してサービスとして登録されることはありません。TCL IVR 2.0 アプリケーションの実行中のインスタンスが、TCL の service コマンドを使用し、自分自身をサービスとして登録します。登録されているサービスのハンドルは、 mod_handle_service 情報タグを使用して取得できます。