このドキュメントでは、発信者のハング アップではなく、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,要素の終了状態をアプリケーション転送要素に接続します。
アプリケーション転送要素を使用して、発信者をdtmf専用バージョンのアプリケーションに送信します。
このアプローチでは、ASRサーバがダウンした場合、発信者はコールを続行できます。発信者の入力内容の保存方法に応じて、発信者はデータを再入力するか、コールフローに戻る必要がありますが、少なくとも発信者は後でコールバックすることなく、Interactive Voice Response(IVR;自動音声応答)エクスペリエンスを継続できます。
この使用例としては、error.badfetchがあります。これは、メディアサーバがダウンした場合に発生する可能性があります。その場合、HotEventを使用して、代わりにバックアップメディアサーバを参照するようにデフォルトパスを変更するカスタムAction要素にルーティングできます。