このドキュメントでは、発信者のハング アップではなく、HotEvent 要素を使用して一部の VoiceXML のエラー イベントを正常に処理できる方法について説明します。
このドキュメントの情報は、Cisco Unified Call Studio, Universal Editionに基づくものです。
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
症状:コールフロー設計者は、デフォルトエラー処理を可能にするのではなく、より一般的なVoiceXMLエラーイベントを考慮してコールフローで処理したいと考えています。
解決: HotEvent要素は、要素構成で指定されている特定のイベントをリッスンします。このイベントが発生すると、そのイベントの唯一の終了状態が追跡され、コールフローを続行できます。電話を切るなど、一部のイベントをキャッチするとCisco Unified Call Studio, Universal Editionの通常の機能に影響を与える可能性があるため、お勧めできません。ただし、コールフローで処理できるイベントがいくつかあり、エラーが発生した場合の発信者のエクスペリエンスを向上させることができます。コール中にブラウザが送出できるイベントのリストについては、使用している音声ブラウザのマニュアルを参照してください。
自動サーバ再起動(ASR)サーバがダウンした場合に、そのサーバを正常に処理する方法の例を次に示します。
この状況で音声ブラウザがスローするイベントをリッスンするようにHotEventを設定します。これは、resource.unavailable.asrのようなものにすることができます。
HotEventを終了して、発信者に対し、軽微なエラーが発生したがコールを続行できることを説明する要素であるCisco Unified Call Studio, Universal Editionを表示します。
Cisco Unified Call Studio, Universal Edition要素の終了状態をアプリケーション転送要素に接続します。
Application Transfer要素を使用して、発信者をdtmf専用バージョンのアプリケーションに送信します。
このアプローチでは、ASRサーバがダウンしても、発信者はコールを続行できます。発信者の入力が保存される方法によっては、発信者がデータを再入力するか、コールフローに戻る必要がある場合がありますが、少なくとも発信者は、後でコールバックする必要なしに、音声自動応答(IVR)の操作を続行できます。
この使用法の別の例は、メディアサーバがダウンした場合に発生する可能性があるerror.badfetchです。その場合、HotEventを使用してカスタムのAction要素にルーティングし、代わりにバックアップメディアサーバーを参照するように既定のパスを変更できます。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
16-May-2007 |
初版 |