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

設定

発信元ゲートウェイおよび T1/E1 回線に冗長性および信頼性をもたらす方法に関する最新情報については、次の URL から入手可能な最新バージョンの『 Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html

また、Unified CVP ソリューションでハイアベイラビリティを実現するゲートウェイを設計する場合、次の問題も考慮してください。

• ICM 統合モデルで使用する場合、発信元ゲートウェイは、H.323 または SIP を使用して Unified CVP と通信します。MGCP とは異なり、SIP および H.323 では、冗長性機能はプロトコルに組み込まれていません。代わりに、SIP および H.323 は、ゲートウェイおよびコール処理コンポーネントを使用して、冗長性を実現します。

• ゲートウェイを設定する場合、次の設定例に示すように、H.323 または SIP シグナリングを仮想ループバック インターフェイスにバインドすることを推奨します。

H.323：

SIP：

このコンフィギュレーションでは、物理インターフェイスに依存せずにコール シグナリングが動作します。この方法では、一方のインターフェイスに障害が発生しても、他方のインターフェイスでトラフィックを処理できます。各ゲートウェイ インターフェイスを異なる物理スイッチに接続し、一方のスイッチまたはインターフェイスに障害が発生した場合に冗長性を実現する必要があります。ゲートウェイ上の各インターフェイスは、異なるサブネット上の IP アドレスを使用して設定されます。次に、ネットワークの IP ルータは、スタティック ルートまたはルーティング プロトコルを使用して、ループバック アドレスへの冗長ルートを持つように設定されます。ルーティング プロトコルを使用する場合、ゲートウェイと交換するルート数に注意してください。また、ゲートウェイがループバック アドレスだけをアドバタイジングし、ルートを受信しないようにルーティング アップデートを制限するフィルタの使用を考慮してください。

コール処理

発信元ゲートウェイに障害が発生した場合、次の状態がコール処理に適用されます。

• 進行中のコールはドロップされます。このゲートウェイ上のすべての T1/E1 トランクへの D チャネルを PSTN スイッチが失うため、これらのコールを保持する方法はありません。

• 新しいコールは、代替ゲートウェイで PSTN キャリアによって T1/E1 に転送されます（PSTN スイッチにトランクがあり、ダイヤル プランがこのように設定されている場合）。

Cisco Unified SIP プロキシ（CUSP）のサポート

Unified CVP Release 8.0(1) は、Cisco Unified SIP Proxy Server（CUSP Server; Cisco Unified SIP プロキシ サーバ）バージョン 1.1.4 で検証されています。つまり、Unified CVP は、CUP プロキシ サーバと CUSP プロキシ サーバの両方をサポートするようになりました。

次に、2 つの実装の相違点を示します。

• CUSP は専用 SIP プロキシ サーバであり、CUP プロキシは、プロキシ エンジンを備えたプレゼンス サーバです。

• これらは異なるハードウェア上で実行されます。CUSP Server はゲートウェイで実行され、CUP Server は MCS マシンで実行されます。

• また、CUP にはさまざまなデフォルト設定があります。たとえば、CUP プロキシでは、MS OCS フェデレーションに必要となるためレコード ルートはデフォルトでオンです。CUSP プロキシでは、レコード ルートはデフォルトでオフです。

• 詳細については、ソリューション サイジング ツール（ http://tools.cisco.com/cucst/faces/login.jsp ）を参照してください。

CUSP の展開方法

CVP ソリューションの CUSP プロキシでは、2 つの展開オプションがサポートされています。これらの方法は、次の 2 つのトピックに記載されています。

展開オプション A - 冗長 SIP プロキシ サーバ

この方法は、次のとおりです。

• 冗長性のために、地理的に離れた 2 つのゲートウェイから構成されます。それぞれに 1 つのプロキシ モジュールがあります。プロキシの冗長性のために SRV プライオリティが使用されます。HSRP はありません。

• ISR は、プロキシ ブレード機能専用です。これは、CUSP に関するプラットフォームの認証制約のため、VXML ゲートウェイまたは TDM ゲートウェイと同じ場所には展開されません。

• TDM ゲートウェイは、SRV またはダイヤル ピア設定で設定され、プライマリ CUSP プロキシまたはセカンダリ CUSP プロキシを使用します。

• CUSP は、サーバ グループを使用して設定され、プライマリおよびバックアップの Unified CVP、Unified CM および VXML ゲートウェイを検索します。

• Unified CVP は、サーバ グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

• Cisco Unified CM は、複数の SIP トランクを持つルート グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

オプション A の例

この例では、ISR1 が東海岸にあり、ISR2 が西海岸にあります。TDM ゲートウェイは、最も近い ISR を使用し、セカンダリ プライオリティ ブレードにフェールオーバーする必要がある場合だけ WAN を超えます。

SRV レコードは、次のようになります。

展開オプション B - 冗長 SIP プロキシ サーバ（二重容量）

この方法は、次のとおりです。

• 冗長性のために、2 つのゲートウェイから構成されます。各シャーシに 2 つのプロキシ モジュールがあります。4 つのプロキシ サーバすべてがアクティブ モードで、コールはこれらの間でバランシングされます。

• SRV を使用して、プライオリティによりプロキシ間でロード バランシングを行います。

• ISR は、プロキシ ブレード機能専用です。これは、CUSP に関するプラットフォームの認証制約のため、VXML ゲートウェイまたは TDM ゲートウェイと同じ場所には展開されません。

• TDM ゲートウェイは、SRV またはダイヤル ピア設定で設定され、プライマリ CUSP プロキシまたはセカンダリ CUSP プロキシを使用します。

• CUSP は、サーバ グループを使用して設定され、プライマリおよびバックアップの Unified CVP、Unified CM および VXML ゲートウェイを検索します。

• Unified CVP は、サーバ グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

• Cisco Unified CM は、複数の SIP トランクを持つルート グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

オプション B の例

この例では、ISR1 が東海岸にあり、ISR2 が西海岸にあります。TDM ゲートウェイは、最も近い ISR を使用し、セカンダリ プライオリティ ブレードにフェールオーバーする必要がある場合だけ WAN を超えます。SRV レコードは、次のようになります。

CUSP 展開のパフォーマンス マトリックス

CUSP 公開データ シート 「Performance Measured in the Number of New Call Attempts per Second」の表 2 に、CUSP Server のパフォーマンス データを示します。

CUSP ベースライン テストは、プロキシ上で隔離して行われ、キャパシティの数値（毎秒 450 TCP、500 UDP トランザクション）が最高クラスのベンチマークとして使用され、許容される最も負荷がかかる条件で実行されました。

プロキシ サーバの観点では、CVP コールは、平均すると次の 4 つの異なる SIP コールになります。

• 発信者の着信レッグ

• VXML 発信レッグ

• 着信音の発信レッグ

• エージェントの発信レッグ

CVP キューイングとの協議が発生すると、セッションでさらに 4 つの SIP トランザクションが発生し、実質的にコール数が 2 倍になります。

CUSP 設計上の考慮事項

プロキシ サーバにおいて、レコード ルート設定を常にオフにしてシングル ポイント障害を回避し、耐障害性ルーティングを可能にし、プロキシ サーバのパフォーマンスを向上します。プロキシ サーバでレコード ルート設定を使用すると、CUSP ベースライン マトリックスに示すようにパフォーマンスへの影響が 2 倍になります。また、プロキシが停止した場合、これがコールに対してシングル ポイント障害になるため、ハイアベイラビリティ モデルではなくなります。

CUSP では、レコード ルートはデフォルトでオフです。

（注） SIP ハートビートを使用したアップストリーム要素ルーティング
CUSP プロキシでは、INVITE または OPTIONS への応答はすべて適切な応答であるため、CUSP は、応答を受信すれば要素ダウンのマークを付けません。応答が、サーバ グループのフェールオーバー応答コード リストで設定されている場合、CUSP は、グループ内の次の要素にフェールオーバーします。そうでない場合、CUSP は、応答を最終応答としてダウンストリームに送信します。

CUP プロキシ バージョン 7.0(5) では、CUSP への実装方法はさまざまですが、OPTIONS ping および INVITE 要求を使用するアップストリーム ルート宛先ステータスをサポートしています。CUP がルートの ping を開始するのは、コール試行または OPTIONS ping が 5XX 応答で失敗した後だけです。宛先には、INVITE または OPTIONS メッセージへの 5XX 応答を使用してアウトオブサービスのマークが付けられます。

設定

次の各項では、SIP プロキシ サーバと、SIP を使用する Cisco IOS ゲートウェイのコンフィギュレーションについて説明します。ここでは、コンフィギュレーション オプションの完全なリストを示しているわけではなく、特定のコンフィギュレーション概念にだけ焦点を当てています。

SIP プロキシ サーバ コンフィギュレーション

SIP プロキシ サーバは、適切なデバイス（Unified CVP コール サーバ、VoiceXML ゲートウェイ、Cisco Unified Communications Manager クラスタなど）を指すスタティック ルートを使用して設定する必要があります。SIP プロキシ サーバ コンフィギュレーションでは、ルートのプライオリティを指定できます。1 つの宛先へのルートが複数ある場合、同じプライオリティを持つ宛先間でロード バランシングするように SIP プロキシを設定するか、または異なるプライオリティを使用して優先順位を付けてコールを送信するように SIP プロキシを設定できます。

Cisco Unified Presence Server SIP プロキシは、発信コールに DNS SRV を使用できません。ロード バランシングまたはフェールオーバーを行うために、複数のスタティック ルートを使用して設定する必要があります（Cisco Unified Presence Server は、DNS SRV 機能をサポートしていませんが、Unified CVP 展開ではテストされていません）。スタティック ルートは、IP アドレスまたは通常の DNS A ホスト レコードを指すことができます。

プロキシ サーバの障害の影響を軽減するには、RecordRoute ヘッダーに SIP プロキシ サーバからデータ入力されないようにすることを推奨します（これは、Cisco Unified Presence Server プロキシでは、デフォルトでオンになっています）。こうすることにより、着信コールが SIP プロキシを通過するようになりますが、コールが Unified CVP コール サーバ（コール サーバ）に到達すると、シグナリングが発信元デバイスとコール サーバの間で直接交換され、SIP プロキシの障害は、進行中のコールには影響しなくなります。

Cisco IOS ゲートウェイ コンフィギュレーション

Cisco IOS ゲートウェイでは、ダイヤルピアを使用して、電話番号を照合し、宛先を SIP プロキシ サーバ、DNS SRV、または IP アドレスにできます。次の例に、SIP プロキシの IP アドレスを使用して、コールを SIP プロキシ サーバに送信する Cisco IOS ゲートウェイ コンフィギュレーションを示します。

ダイヤルピアでの sip-server コマンドは、Cisco IOS ゲートウェイに対して、 sip-ua で設定されたグローバル定義の sip-server を使用するよう指示します。冗長性のために複数の SIP プロキシを設定するためには、次の例に示すように、IP アドレスを DNS SRV レコードに変更できます。DNS SRV レコードでは、単一の DNS 名を複数のサーバにマップできます。

代わりに、次の例に示すように、複数の SIP プロキシ サーバを直接指すように複数のダイヤルピアを設定できます。このコンフィギュレーションでは、DNS を使用する代わりに IP アドレスを指定できます。

前の例では、ダイヤル プランの解決およびコール ルーティングのためにコールが SIP プロキシ サーバに送信されます。複数の Unified CVP コール サーバがある場合、SIP プロキシ サーバは、ロード バランシングおよび冗長性のために複数のルートを使用して設定されます。Cisco IOS ゲートウェイでは、SIP プロキシ サーバを使用せずに、ロード バランシングおよび冗長性を実現できます。次の例では、3 つの Unified CVP コール サーバ間でコールをロード バランシングするように、複数のダイヤルピアを使用した Cisco IOS ゲートウェイ コンフィギュレーションを示します。

DNS SRV レコードによって、管理者は、DNS ラウンドロビン冗長性およびロード バランシングを使用した場合よりも詳細に冗長性およびロード バランシングを設定できます。DNS SRV レコードを使用すると、特定のサービス（この場合のサービスは SIP）に対して使用する必要があるホストを定義できます。また、これらのホスト間でのロード バランシングの特性を定義できます。次の例では、上記のように設定された 3 つのダイヤルピアで実現される冗長性が DNS SRV レコードを使用して単一のダイヤルピアに置き換えられます。DNS ルックアップを行うためには、DNS サーバが必要であることに注意してください。

Cisco IOS ゲートウェイでは、スタティック ホスト レコードと同様に DNS SRV レコードをスタティックに定義できます。この機能を使用すると、DNS SRV ロード バランシングおよび冗長性を実現しながらダイヤルピア コンフィギュレーションを簡素化できます。この方法には、SRV レコードの変更が必要な場合、集中型 DNS サーバではなく各ゲートウェイで設定を変更する必要があるという欠点があります。次の例は、cvp.cisco.com で処理された SIP サービスのスタティック SRV レコードのコンフィギュレーションを示します。cvp.cisco.com の SIP SRV レコードは、3 台のサーバ間でロード バランシングするように設定されます。

（SIP/TCP の SRV レコード）

（SIP/UDP の SRV レコード）

コール処理

次の障害シナリオの場合、コールは示されているように処理されます。

• プライマリ SIP プロキシ サーバの障害

アクティブ コールは保持されます。後続のコール転送は正常に行われます。ただしこれは、バックアップの SIP プロキシを使用でき、RecordRoute ヘッダーが SIP プロキシによってデータ入力されていない場合です。RecordRoute ヘッダーにデータが入力されている場合、ゲートウェイへのシグナリングは実行できず、後続の転送は失敗します。

• すべての SIP プロキシ サーバに障害が発生または到達不能

ゲートウェイで存続可能性が設定されている場合、ゲートウェイに到着する新しいコールは、デフォルトのルートにルーティングされます。

設定

単一の SIP プロキシ サーバだけがコール サーバからの発信コール ルーティングに必要な場合、SIP サービスを設定するときに SIP プロキシ コンフィギュレーションを選択します。Unified CVP Operations Console Server（Operations Console）で、次のように設定します。

• SIP プロキシ サーバを追加し、このサーバの IP アドレスを指定します。

[Call Server SIP Service] 設定で、次のように設定します。

• [Enable Outbound Proxy] = [True]

• [Use DNS SRV type query] = [False]

• [Outbound Proxy Host] = 上記で設定した SIP プロキシ サーバ

コール サーバからの発信冗長性のために複数の SIP プロキシ サーバを使用する場合、DNS 名を使用して SIP プロキシを設定し、SIP プロキシ サーバに到達するために DNS SRV レコードを設定します。DNS SRV レコードは、外部 DNS サーバ上に存在できます。または、このレコードは、各 CVP Server 上のローカル DNS SRV レコードで設定できます。OAMP Console で、次のように設定します。

• SIP プロキシ サーバを追加し、このサーバの DNS 名を指定します。

[SIP Service] 設定で、次のように設定します。

• [Enable Outbound Proxy] = [True]

• [Use DNS SRV type query] = [True]

• SIP プロキシ サーバのリストを使用して、DNS SRV レコードを設定します。

各サーバ上でローカル DNS SRV レコードを設定するには、[SIP Service] 設定で、[Resolve SRV records locally] のチェックをオンにします。

冗長プロキシ サーバにサーバ グループを使用するには、次の手順を実行します。

1. [resolve SRV records locally] を選択し、発信プロキシ ドメイン名にサーバ グループの名前を入力します。

2. [System] > [Server Groups] で、プライオリティ 1 と 2 の 2 台のプロキシ サーバを含む新しいサーバ グループを作成します。

3. サーバ グループ コンフィギュレーションをコール サーバに展開します。

進行中のコールのハイアベイラビリティの設定

進行中のコールがあるコール サーバに障害が発生した場合、特定のゲートウェイ コンフィギュレーション手順を実行済みの場合は、すべてのコールを保持できます。コール サーバの障害では、次のいずれかが生じる可能性があります。

• サーバのクラッシュ。

• プロセスのクラッシュ。

• プロセスのハング。

• ネットワークの停止。

この項で説明するコンフィギュレーションにより、これらの状況すべてに対して保護されます。ただし、次の 2 つの状況からは保護できません。

• 進行中のコールを含むプロセスが停止された場合。この状況は、システム管理者が、プロセスを停止する前にまずコール サーバをアウトオブサービスにしてから進行中のコールを終了することを忘れた場合に発生します。

• コール サーバが推奨コール レートを超えた場合。コール サーバで許可されるコールの絶対数に対するスロットルはありますが、コール レートに対するスロットルはありません。一般的に、推奨の Calls Per Second（cps; 1 秒当たりのコール）を長時間超えると、いずれかのコンポーネントが正しくサイジングされていない場合、またはコール ロードが各コール処理コンポーネントの加重およびサイジングに応じて分散されていない場合、CVP ソリューションの特定のコンポーネントで不安定で予測できないコール動作が引き起こされる可能性があります（コール サーバのコール レートの詳細については、「サイジング」を参照してください）。

コール存続可能性を実現するには、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』の説明に従って、発信元ゲートウェイを設定します。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

survivability.tcl スクリプト自体には、一部の指示および有用な情報も含まれています。

ほとんどのダウンストリーム障害（コール サーバの障害を含む）の場合、コールは、発信元ゲートウェイによってデフォルトのルートにルーティングされます。存続可能性は、Unified CVP スタンドアロンおよび NIC ルーティング モデルには当てはまりません。これらのモデルには、関連する Unified CVP H.323 または SIP サービスがないためです。

Unified CVP が認識せずにクリアされたコールを検出するメカニズムもあります。

• Unified CVP は、設定時間（デフォルトでは 120 分）を超える長さの着信コールを 2 分ごとにチェックします。

• これらのコールについて、Unified CVP は UPDATE メッセージを送信します。メッセージが拒否または送信不能を受信すると、コールがクリアされ、ライセンスがリリースされます。

CVP SIP サービスは、発信元ゲートウェイなどのエンドポイントが自身でセッション更新を実行できるように、Session Expires ヘッダーをコールに追加できます。SIP コールでの Session Expires の使用法の詳細については、RFC 4028（『 Session Timers in the Session Initiation Protocol 』）を参照してください。

コール処理

次のシナリオの場合、コールは示されているように処理されます。

• コールが進行中

発信者が転送（IP 電話、VoiceXML ゲートウェイ、他の外部へのゲートウェイへの転送など）された後に、Unified CVP SIP サービスに障害が発生した場合、Unified CVP SIP サービスからの後続の転送動作（ある場合）が必要になるまで、コールは通常どおりに継続します。発信者が電話を切らずに追加の動作を待っている場合、9 ～ 18 秒の無音の後、発信者は存続可能性によって代替場所のデフォルトのルートにルーティングされます。

コールが転送されていない場合、発信者は 9 ～ 18 秒の無音の後、存続可能性によって代替場所のデフォルトのルートにルーティングされます（存続可能性は、NIC ルーティング モデルでは適用されません）。

• 新しいコール

新しいコールは、SIP プロキシによって、代替 Unified CVP コール サーバに転送されます。使用可能なコール サーバがない場合、コールは、存続可能性によって代替場所のデフォルトのルートにルーティングされます（存続可能性は、NIC ルーティング モデルでは適用されません）。

サーバ グループのハートビート設定

サーバ グループのハートビートのデフォルト設定では、2 回の ping の間の ping up/down 間隔が設定されます。これは、同じエンドポイントへの ping の間の設定ではありません。サーバ グループは、特定の間隔で動作してすべての要素を ping することはありません。これは、この方法が、CPU 使用率に対してシーソー効果をもたらすためです。また、システムが多くのエンドポイントを ping する必要がある場合、より多くのリソースを使用します。たとえば、すべてのグループ間で合計 3 つの要素がある場合、30 秒間隔で各要素を事前に ping するには、ping 間隔を 10 秒に設定する必要があります。

現在停止している要素が変化し、ping 間隔もこれに応じて変化することがあるため、事後対応モードでは未確定性が増します。

（注） • サーバ グループのハートビート動作設定。要素が稼動中のときに ping をオフにするには、[Up Endpoint Heartbeat Interval] をゼロに設定します（事後対応型 ping）。要素が停止しているときに ping をオフにするには、[Down Endpoint Heartbeat Interval] をゼロに設定します（事前対応型 ping）。要素が稼動中または停止中のいずれかのときに ping するには、ハートビート間隔をゼロより大きくします（適応型 ping）。

• ハートビート応答処理。CVP がコールをルーティングする先のエンドポイントは、OPTIONS に対して応答（200 OK または他の応答）で応答する必要があります。ハートビートに対して応答がある場合は、もう一方の側が動作していて到達可能であることを示します。通常 200 OK が返されますが、Cisco Unified Presence Server（CUP Server）や Cisco Unified SIP Proxy Server（CUSP Server）のようなプロキシ サーバは、OPTIONS メッセージで max-forwards ヘッダーがゼロに設定されているため、483 Too Many Hops 応答を返す場合があります。エンドポイントで OPTIONS または ping が許可されず、405 Method Not Allowed を返す場合もあります（これも問題ありません）。

デフォルトでは、サーバ グループのハートビートは、UDP ソケット接続を使用して実行されます。[Operations Console Server Groups] ウィンドウで、トランスポート タイプを [TCP] に変更できます。

要素が到達不能または過負荷のステータスの場合は、必ずその要素は、完全停止のマークを付けられます（つまり、UDP トランスポートと TCP トランスポートの両方に対して）。要素が再び稼動中になると、UDP と TCP の両方でルーティング可能になります。

（注） TLS トランスポートはサポートされていません。

複製サーバ グループ要素は、ハートビートがその要素に対して確立済みのため、ハートビートから除外されます。

（注） サーバ グループ機能の一般的なコンフィギュレーションについては、『Configuration and Administration Guide for Cisco Unified Customer Voice Portal』を参照してください。マニュアルは、http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html から入手可能です。

スタティック ルートの認証

スタティック ルートのホスト名および IP アドレスは、DNS ルックアップ解決を使用して、起動時およびコンフィギュレーション展開時に検証されます。ホスト名が A レコードまたは SRV レコードに解決されない場合、ルートがディセーブルになり、Unified CVP エラー ログに通知が書き込まれます。この状態では、このルートへのコールのルーティングは不可能になります。ホストがローカル SRV サーバ グループ コンフィギュレーション内に SRV 名として含まれる場合、ホストはローカル SRV 名に解決されるためこのチェックは実行されません。IP アドレスは、常にこの検証をパスします。

設計上の考慮事項

サーバ グループを実装する場合、次の設計上の考慮事項を確認してください。

• ローカル SRV コンフィギュレーションを使用している場合、このコンフィギュレーションは、DNS SRV コンフィギュレーションと連携しません。ただし、要素は IP アドレスではなく A レコード ホスト名として宣言され、DNS サーバ ルックアップまたは OS などのホスト ファイルを使用して解決される場合があります。

• CUP プロキシを使用している場合、一般的に SRV クラスタ名（proxy-servers.cisco.com など）は、プロキシ コンフィギュレーションのサービス パラメータ セクションで定義する必要があります。それ以外の場合、404 not found 拒否になります。CUSP プロキシの場合、CLI でも同様のコンフィギュレーションを行うことができます。

診断

CVP ログ ファイルには、エンドポイント ステータス イベントを示すトレースがあります。 http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html から入手可能な「 Configuration and Administration Guide for Cisco Unified Customer Voice Portal 」の Unified CVP System CLI の指示を参照してください。

HSRP を使用するゲートキーパー冗長性

HSRP は、シスコ所有のルータ冗長性プロトコルで、2 つ以上のゲートキーパーが同じ IP アドレスをアクティブ/スタンバイとして共有できます。HSRP を使用すると、2 台のゲートキーパーが連携し、LAN 上の単一の仮想 IP アドレスのようになります。

これらのゲートキーパーは、同じ IP アドレスおよび MAC アドレスを共有します。したがって、ゲートキーパーのいずれかに障害が発生しても、LAN 上のホストは、パケットを同じ IP アドレスおよび MAC アドレスに転送し続けることができます。一方のデバイスから他方のデバイスにルーティング機能を移すプロセスは、ユーザには分からないように実行されます。H.323 エンドポイント（Unified CVP H.323 サービス、Cisco Unified Communications Manager、ゲートウェイなど）は、HSRP ゲートキーパーのペアを表す仮想 IP アドレスに登録されます。

一方のゲートキーパーに障害が発生しても、他方のゲートキーパーがプライマリ制御を引き継ぎます。ただし HSRP には、HSRP フェールオーバー ペアの両方のゲートキーパーが同じ IP サブネットまたは VLAN に存在している必要があるため、通常これらは地理的に分離できないという欠点があります。また、冗長性のために HSRP を使用するゲートキーパーは、状態の情報を共有しません。したがって、フェールオーバーが発生した場合は、スクラッチから、すべてのデバイスをゲートキーパーに再登録する必要があります。

Unified CVP 3.1 SR1 以降、HSRP は推奨されていません。ゲートキーパー冗長性を実現するためには、代わりに、ゲートキーパー クラスタリングおよび Unified CVP での代替ゲートキーパー コンフィギュレーションが推奨されます。

代替ゲートキーパーを使用したゲートキーパー冗長性

Unified CVP H.323 サービスは、代替ゲートキーパー（必要な数だけ、制限なし）のリストを使用して設定できます。開始された H.323 サービスは、リストの最初のゲートキーパーに登録しようとします。登録に成功しない場合、登録に成功するまで、リストの残りのゲートキーパーに順次登録しようとします。

H.323 サービスは、次のいずれかのイベントが発生するまで、そのゲートキーパーに登録されたままになります。

• あるタイプの障害がゲートキーパーに発生した場合。H.323 サービスは、次のいずれかの方法でゲートキーパーの障害を認識します。

– ゲートキーパーへの定期的な RAS Registration Request（RRQ; RAS 登録要求）がタイム アウトまたは拒否される。

– 転送に対する Admission Request（ARQ; アドミッション要求）がタイム アウトになる。

– ゲートキーパーが H.323 サービスに登録解除を事前に通知する（管理者がゲートキーパー コンフィギュレーションを停止する場合など）。

• ユーザが VBAdmin から別の setGK を実行した場合。これにより、H.323 サービスはリストに最初のゲートキーパー（このゲートキーパーが使用可能な場合）を登録します。そのゲートキーパーが使用不可の場合は、再び登録を順次試行します。

Unified CVP の代替ゲートキーパーを使用するためには、ゲートキーパー クラスタリングは必要ありません。2 台のゲートキーパーを同じコンフィギュレーションにできます。また、代替ゲートキーパーを使用して Unified CVP を設定し、冗長性を実現できます。

Unified CVP H.323 サービスは、ゲートキーパー クラスタリング メッセージをサポートしていませんが、ゲートキーパーを GUP クラスタの一部にできない理由はありません。この方法で、元々クラスタリングをサポートする他の H.323 エンドポイント（Cisco Unified Communications Manager や Cisco IOS ゲートウェイなど）は、ゲートキーパー クラスタリングの利点を利用できます。Unified CVP は、クラスタリング メッセージ（クラスタ内のゲートキーパーのいずれかが過負荷になった場合や Unified CVP がゲートキーパーに登録した場合など）を単に無視します。

Unified CVP は、ゲートキーパーに登録するときに、ゲートキーパー クラスタの他のメンバーを自動的に学習しないため、Unified CVP でゲートキーパー クラスタのメンバーをスタティックに定義する必要があります。Unified CVP は、クラスタ内で 1 つ以上のゲートキーパーをリスト内の代替ゲートキーパーとして使用し、この項で説明済みのルールに従って障害を検出します。

設定

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

• 「HSRP のコンフィギュレーション」

• 「代替ゲートキーパー」

HSRP のコンフィギュレーション

プライマリ ゲートキーパーで、次のコマンドを入力します。

バックアップ ゲートキーパーで、次のコマンドを入力します。

両方のゲートキーパーで、同じゲートキーパー コンフィギュレーションを入力します。例：

詳細については、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

代替ゲートキーパー

次の例に示すように、Unified CVP VBAdmin を使用して、代替ゲートキーパーを設定します。

この例では、H.323 サービスが登録できる 3 台のゲートキーパーを設定します。いずれの場合にも、H.323 サービスは、このゲートキーパーで設定される最初のローカル ゾーンに登録されます。このサービスは、デフォルトの RAS ポート 1719 も使用します。

この例では、H.323 サービスは、まずローカル ゾーン zone1 を使用して、ポート 1718 のゲートキーパー 10.0.1.100 に登録しようとします。このゲートキーパーに障害がある場合、H.323 サービスは、このゲートキーパーで定義された最初のローカル ゾーンを使用して、ポート 1719 の 10.0.2.100 に順次登録しようとします。

コール処理

この項に記載されているコール処理は、HSRP と代替ゲートキーパーの両方に適用されます。

ゲートキーパーの障害は、次のいずれかの場合に発生します。

• プライマリ ゲートキーパーに障害が発生する。

– 進行中のコールの一部は、エンドポイントがバックアップ ゲートキーパーへの再登録を行っている間は転送されない場合があります。転送に失敗した後、ICM にエラーが返されます。ICM スクリプトがエラーを返すようにコーティングされていて（END ノードがこれを実行します）、 同時に ゲートウェイで存続可能性が設定されている場合、コールはデフォルトのルートにルーティングされます。

– 着信ゲートウェイおよび Unified CVP に到着する新しいコールは、正しく処理されます。ただし、コールの一部は、エンドポイントがバックアップ ゲートキーパーに再登録している間に存続可能性を呼び出す可能性があります。

• すべてのゲートキーパーに障害が発生する。

– Unified CVP H.323 サービスは、アウトオブサービスになります。

– 進行中のコールは転送されません。転送に失敗した後、ICM にエラーが返されます。ICM スクリプトがエラーを返すようにコーティングされていて（END ノードがこれを実行します）、 同時に ゲートウェイで存続可能性が設定されている場合、コールはデフォルトのルートにルーティングされます。

– ゲートウェイで存続可能性が設定されている場合、ゲートウェイに到着する新しいコールは、デフォルトのルートにルーティングされます。

• プライマリ ゲートキーパーが降格するが障害は発生しない。

– この動作は、通常、メモリ リークによるメモリ低下またはデバッグ レベル超過による CPU の過負荷の 2 つの条件により発生します。

– この状況では、バックアップ ゲートキーパーに正常にフェールオーバーされない場合があるため、コール処理動作が予測不能になります。ゲートウェイで存続可能性が設定されている場合、コールはデフォルトのルートにルーティングされます。

設定

ハイアベイラビリティのための Unified CVP H.323 コンフィギュレーションは、主に入力ゲートウェイで行われますが、H.323 サービスを設定して、ゲートキーパーに登録する必要もあります。

新しいコールのためのハイアベイラビリティの設定

ゲートキーパーは、コール サーバがインサービスかアウトオブサービスかを認識します。したがって、ゲートキーパーにより着信コールがコール サーバにルーティングされるようにすることが重要です。デフォルトでは、Unified CVP H.323 サービスは、Technology Prefix（tech-prefix; テクノロジー プレフィクス）の 2# を付けてゲートキーパーに登録します。Unified CVP H.323 サービスは、tech-prefix を付けて登録する必要があります。tech-prefix がないと、H.323 サービスを設定できません。

テクノロジー プレフィクスは、ゲートキーパーが登録エンドポイントを機能ごとに分類する方法です。通常、ゲートキーパーで着信コールに対して追加のコンフィギュレーションを行う必要はありません。H.323 サービスは、2# を付けてゲートキーパーに登録し、発信元ゲートウェイは、Dialed Number Identification Service（DNIS; 着信番号識別サービス）の番号の先頭に 2# を付加します。ゲートキーパーは、ゲートウェイの要求を使用可能なコール サーバと照合する方法を自動的に認識します。ゲートキーパーで、コマンド show gatekeeper gw-type-prefix を使用すると、ゲートキーパーがコールのルーティングに使用するルート プランが表示されます。

発信元ゲートウェイで、次のようにコール サーバのダイヤルピアを定義します。

コマンド session target ras を使用すると、ゲートウェイは、コールを該当のゲートキーパーに送信します。コマンド tech-prefix 2# を使用すると、ゲートウェイは、コールをゲートキーパーに送信するときに、DNIS 番号の先頭に 2# を付加します。

進行中のコールのハイアベイラビリティの設定

進行中のコールがあるコール サーバに障害が発生した場合、特定のゲートウェイ コンフィギュレーション手順を実行済みの場合は、すべてのコールを保持できます。コール サーバは、次のいずれかの場合に障害が発生する可能性があります。

• サーバのクラッシュ。

• プロセスのクラッシュ。

• プロセスのハング。

• ネットワークの停止。

この項で説明するコンフィギュレーションにより、これらの状況すべてに対して保護されます。ただし、次の 2 つの状況からは保護できません。

• 進行中のコールを含むプロセスが停止された場合。この状況は、システム管理者が、プロセスを停止する前にまずコール サーバをアウトオブサービスにしてから進行中のコールを終了することを忘れた場合に発生します。

• コール サーバが推奨コール レートを超えた場合。コール サーバで許可されるコールの絶対数に対するスロットルはありますが、コール レートに対するスロットルはありません。通常、5 Calls Per Second（cps; 1 秒当たりのコール）を長時間超えると、コール サーバの動作が不安定で予測できなくなります。この状況は、Unified CVP システムを正しくサイジングすることによって防止できます。

コール存続可能性を実現するには、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』の説明に従って、発信元ゲートウェイを設定します。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

survivability.tcl スクリプト自体には、一部の指示および有用な情報も含まれています。

ほとんどのダウンストリーム障害（コール サーバの障害を含む）の場合、コールは、発信元ゲートウェイによってデフォルトのルートにルーティングされます。存続可能性は、Unified CVP スタンドアロンおよび NIC ルーティング モデルには適用されません。その理由は、これらのモデルには、関連する Unified CVP コール サーバがないためです。

追加の Cisco IOS ゲートウェイ コンフィギュレーション

次の例のコマンドを使用すると、ゲートウェイ上で H.225 シグナリングの TCP タイムアウトがディセーブルになります。

この操作では、ゲートウェイがコール サーバまたは Cisco Unified Communications Manager との接続を失いますが、引き続きアクティブ コールを保持します。このコマンドを使用しないと、このコマンドを使用している場合に障害の影響を受けない、引き続きアクティブなコール（つまり、RTP ストリームがエンドポイント間で引き続きストリーミングしている）は、TCP セッションがタイムアウトになると、接続解除されます。

次のコマンドは、RTP メディア タイムアウトを指定します。

RTCP メッセージが指定の間隔で受信されなかったことをゲートウェイが検出すると、コールは接続解除されます。

コール処理

Unified CVP H.323 サービスに障害が発生すると、次の状態が適用されます。

• コールが進行中

発信者が転送（IP 電話、VoiceXML ゲートウェイ、他の外部へのゲートウェイへの転送）された後に、Unified CVP H.323 サービスに障害が発生した場合、Unified CVP H.323 サービスからの後続の転送動作（ある場合）が必要になるまで、コールは通常どおりに継続します。発信者が電話を切らずに追加の動作を待っている場合、9 ～ 18 秒の無音の後、発信者は存続可能性によって代替場所のデフォルトのルートにルーティングされます。

コールが転送されていない場合、発信者は 9 ～ 18 秒の無音の後、存続可能性によって代替場所のデフォルトのルートにルーティングされます（存続可能性は、NIC ルーティング モデルでは適用されません）。

• 新しいコール

新しいコールは、ゲートキーパーによって、代替 Unified CVP コール サーバに転送されます。使用可能なコール サーバがない場合、コールは、存続可能性によって代替場所のデフォルトのルートにルーティングされます（存続可能性は、Unified CVP スタンドアロンおよび NIC ルーティング モデルでは適用されません）。

設定

使用する IVR サービスを H.323 または SIP サービスに通知するために、追加のコンフィギュレーションを行う必要はありません。デフォルトでは、H.323 および SIP サービスは、同じサーバ上にある IVR サービスを使用します。また、コール サーバの IVR サービスの IP アドレスを使用して VoiceXML ゲートウェイを設定する必要もなくなります。SIP を使用する場合、SIP サービスは、コールが VoiceXML ゲートウェイに送信されるときに、コール サーバの IVR サービスの URL を SIP INVITE メッセージのヘッダーに挿入します。VoiceXML ゲートウェイは、使用するコール サーバを決定するときに SIP INVITE からこの情報を抽出し、使用します。H.323 を使用する場合、VoiceXML ゲートウェイは、コール サーバからの着信コールのソース IP アドレスを検査します。次に、この IP アドレスは、コール サーバの IVR サービスのアドレスとして使用されます。

次の例は、コールを受信したときに呼び出される VoiceXML ブートストラップ サービスを示しています。

Unified CVP 3.1 以前のリリースと異なり、Unified CVP 4.0 以降のリリースでは、コール サーバの IP アドレスを設定する必要はありません。bootstrap.tcl は、ソース コール サーバの IP アドレスを学習し、これをこのコール サーバとして使用します。コール サーバからコールを受信するということは、サーバが起動していて、動作中であることを示しているため、CSS またはバックアップ コール サーバ コンフィギュレーションは必要ありません。

ゲートウェイのフラッシュ メモリには、handoff.tcl、survivability.tcl、recovery.vxml、いくつかの .wav ファイルなど、ハイアベイラビリティと関係のあるファイルがあります。Trivial File Transfer Protocol（TFTP; 簡易ファイル転送プロトコル）を使用して、適切なファイルをフラッシュにロードします。各ファイルのコンフィギュレーション情報は、ファイル内にあります。詳細については、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

コール処理

Unified CVP IVR サービスに障害が発生すると、次の状態がコール処理に適用されます。

• 進行中のコールは、発信元ゲートウェイの存続可能性によって代替の場所のデフォルトのルートにルーティングされます。（存続可能性は、NIC ルーティング モデルでは適用されません）。

• 新しいコールは、インサービスの Unified CVP IVR サービスに転送されます。

設定

VoiceXML ゲートウェイのハイアベイラビリティ コンフィギュレーションは、H.323 のゲートキーパー、SIP の SIP プロキシ、または Unified CVP コール サーバ（コール サーバ）、あるいはこれらすべてによって制御されます。VoiceXML ゲートウェイが分散型か集中型かによっても、ハイアベイラビリティの達成度は影響されます。

コール サーバが VoiceXML ゲートウェイに接続できない場合、ICM スクリプトにエラーが返されます。ICM スクリプトでは、VoiceXML ゲートウェイ接続エラーを取得するために、Send to VRU ノードを最初の Run External スクリプト ノードから分離します。END スクリプト ノードが、Send to VRU ノードの X-path から分離されて使用される場合、コールは、発信元ゲートウェイの存続可能性によって、デフォルトのルートにルーティングされます（存続可能性は、VRU のみのモデルでは適用されません）。Queue to Skill グループ ノードも使用できますが、この方法が効果的なのは、エージェントがある場合だけです。それ以外の場合は、ICM は発信者をキューに入れようとして、失敗します（コール サーバが再び VoiceXML ゲートウェイに接続できなくなるため）。次に、END ノードも Queue to Skill Group ノードの X-path から分離して使用され、コールをデフォルトのルートにルーティングできます。

（注） VXML Server には、ロード バランシングを支援する次の 2 つの機能があります。

• ロード バランサの関与の制限

• ロード バランサ用の拡張 HTTP プローブ

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_user_guide_list.html から入手可能な『User Guide for Unified CVP VXML Server and Cisco Unified Call Studio』のコンフィギュレーション オプション ip_redirect および license_depletion_probe_error を参照してください。

集中型 VoiceXML ゲートウェイ

このコンフィギュレーションでは、VoiceXML ゲートウェイは、Unified CVP コール サーバと同じデータセンターにあります。

H.323 VoiceXML ゲートウェイ

ゲートキーパーで、データセンターのすべての VoiceXML ゲートウェイの H.323 ID を含むゾーン プレフィクス リストを設定します。たとえば、データセンターに H.323 ID が VoiceXMLgw1、VoiceXMLgw2、および VoiceXMLgw3 である 3 つの VoiceXML ゲートウェイがあり、ネットワーク VRU の ICM ラベルが 5551000 であるとします。この例では、ゲートキーパーは、実質的にはラウンドロビン スキームでのコールを 3 つの VoiceXML ゲートウェイ間で分散させます（3 つのゲートウェイがすべてインサービスの場合）。

SIP VoiceXML ゲートウェイ

Cisco Unified Presence Server を使用している場合、SIP プロキシ サーバで、各ゲートウェイのネットワーク VRU ラベルのスタティック ルートを設定します。VRU ラベルが 5551000 の場合、スタティック ルート パターンは、correlation-id が付加され、VoiceXML ゲートウェイにルーティングされるように、5551000* になります。

Unified CVP コール サーバで SIP スタティック ルートを使用している場合、コール サーバの SIP サービス コンフィギュレーションで、各ネットワーク VRU ラベルおよびゲートウェイにスタティック ルートを設定します。VRU ラベルが 5551000 の場合、スタティック ルート パターンは、5551000> になります。> は、1 つ以上の数字を表すワイルドカードで、DNIS 番号に付加される correlation-id を VoiceXML ゲートウェイに正しく渡すために必要です。

（注） 他のワイルドカード文字も使用できます。全ワイルドカードの形式および優先情報については、Operations Console オンライン ヘルプのトピック「Valid Formats for Dialed Numbers」を参照してください。

SIP プロキシと Unified CVP スタティック ルートの両方の場合、ルートのネクストホップ アドレスは、ゲートウェイの IP アドレスまたは DNS SRV レコードにできます。IP アドレスを使用している場合、複数のスタティック ルートを作成する必要があります（各 VoiceXML ゲートウェイに 1 つ）。DNS SRV の場合、必要なルートは、ネットワーク VRU ラベルごとに 1 つだけです。SRV レコードが、ロード バランシングおよび冗長性を提供します。

分散型 VoiceXML ゲートウェイ（共存入力ゲートウェイおよび VoiceXML）

このコンフィギュレーションでは、PSTN からの着信コールを処理するゲートウェイは、低帯域幅の接続（WAN など）によって Unified CVP Server から分離され、使用される VoiceXML ゲートウェイは、入力ゲートウェイと同じです。このコンフィギュレーションの目的は、WAN 上の帯域幅の使用を回避するために、メディア ストリームをエッジで保持することです。

H.323 VoiceXML ゲートウェイ

VBAdmin で SetTransferLabel を使用し（ゲートキーパー ゾーン プレフィクスは使用しない）VoiceXML ゲートウェイの選択を制御します。SetTransferLabel コマンドは、ネットワーク VRU ラベルごとに指定されます。Unified CVP コール サーバが SetTransferLabel で設定されたラベルと一致するラベルを ICM から受信すると、コール サーバは、ゲートキーパー ルックアップを実行しますが、ゲートキーパーから返される宛先ゲートウェイを無視し、コールの発信元のゲートウェイにコールを戻します。H.323 サービスは、H.323 シグナリングのソース IP アドレスを検索して、発信元ゲートウェイを判別します。

SIP VoiceXML ゲートウェイ

SIP では、SetTransferLabel コマンドと同等のものが、SIP サービスの Send to Originator コンフィギュレーションです。ネットワーク VRU ラベルが 5551000 の場合、Send to Originator パターンは、5551000> になります。> は、1 つ以上の数字を表すワイルドカード パターンです。SIP サービスは、SIP INVITE メッセージの Remote-Party-ID ヘッダーを検索して、発信元ゲートウェイを判別します。

（注） 他のワイルドカード文字も使用できます。全ワイルドカードの形式および優先情報については、Operations Console オンライン ヘルプのトピック「Valid Formats for Dialed Numbers」を参照してください。

分散型 VoiceXML ゲートウェイ（分離入力ゲートウェイおよび VoiceXML）

このコンフィギュレーションでは、PSTN からの着信コールを処理するゲートウェイは、低帯域幅の接続（WAN など）によって Unified CVP Server から分離され、使用される VoiceXML ゲートウェイは、入力ゲートウェイとは異なりますが、入力ゲートウェイと同じサイトにあります。このコンフィギュレーションの目的は、入力ゲートウェイと VoiceXML ゲートウェイを分離することが適切な場合に、メディア ストリームを同じサイトに保持し、WAN 上の帯域幅の使用を回避し、VoiceXML ゲートウェイのサイズを最適化することです。この場合、コールの IVR レッグを入力ゲートウェイに戻さないため、setTransferLabel および Send to Originator は使用できません。また、各リモート サイトの ICM で別のネットワーク VRU、ネットワーク VRU ラベル、およびお客様を設定する必要があるため、ゲートキーパーまたは SIP プロキシを使用してコール ルーティングを制御することもできません。代わりに、SetSigDigits 機能を使用します。

この方法では、コール サーバが、着信 DNIS 番号から先頭の最上位の数字を除去します。除去した値は保存され、このコールを後続するときに先頭に付加されます。

H.323 VoiceXML ゲートウェイ

H.323 を使用する場合、最上位の数字の先頭に # 記号が付加され、ゲートキーパーがこれをテクノロジー プレフィクスとして処理します。リモート サイトの VoiceXML ゲートウェイは、DNIS 番号から除去された先頭の最上位の数字と同じテクノロジー プレフィクスを使用して、ゲートキーパーに登録する必要があります。ゲートキーパーは、コールの IVR レッグを正しい VoiceXML ゲートウェイにルーティングします。Cisco Unified Communications Manager（Unified CM）を使用している場合、Unified CVP は、すべての転送（Unified CM への転送を含む）に sigdigits 値を無差別に付加することを忘れないでください。したがって、このシナリオで Unified CM を使用している場合、次の例に示すように、VoiceXML ゲートウェイのテクノロジー プレフィクスそれぞれにゲートキーパー制御のトランクを定義し、ゾーン プレフィクス コンフィギュレーションを Unified CM エージェントのゲートキーパーに追加する必要があります。

入力ゲートウェイのコンフィギュレーション

着信 DNIS 番号の先頭に値 3 を付加する変換ルールを適用します。

DNIS 番号が 8002324444 の場合、Unified CVP にルーティングされる最終 DNIS ストリングは、2#38002324444 です。

VB Admin のコンフィギュレーション

2# のテクノロジー プレフィクスを除去した後、DNIS 番号から 1 つの数字を除去します。

VoiceXML ゲートウェイのコンフィギュレーション

テクノロジー プレフィクス 3# を使用してゲートキーパーに登録します。

Cisco Unified CM コンフィギュレーション（使用する場合）

VXML ゲートキーパーが使用するテクノロジー プレフィクスそれぞれに対応する、別個のゲートキーパー制御のトランクを作成します。

ゲートキーパー コンフィギュレーション

ゾーン プレフィクスを定義して、コールを Unified CM エージェントに適切にルーティングします（Cisco Unified CM を使用している場合のみ）。

コール ルーティングのまとめ

1. コールは、Unified CVP に DNIS ストリング 2#38002324444 で到着します。

2. Unified CVP は、まずテクノロジー プレフィクス（2#）を除去し、38002324444 になります。

3. 次に Unified CVP は、DNIS ストリングの先頭から 1 つの数字（3）を除去し、8002324444 になります。

4. 8002324444 がコール ルーティング用に ICM に渡されます。

5. 転送時、ICM はラベル 5551000102 を返すとします。Unified CVP は、3# を先頭に付加し、3#5551000102 になります。この値がアドレス解決のためにゲートキーパーに渡されます。

6. ゲートキーパーは、テクノロジー プレフィクス 3# を付けて登録した VoiceXML ゲートウェイに対してこのラベルを解決します。

7. VoiceXML ゲートウェイは、3# を除去し、宛先アドレスは 5551000102 になります。

SIP VoiceXML ゲートウェイ

SIP を使用する場合、DNIS 番号の先頭に最上位の数字が付加され、この付加された数字に基づいてルーティングするように SIP プロキシを設定できます。VoiceXML ゲートウェイの SIP プロキシにあるスタティック ルートは、先頭に数字を付加する必要があります。この付加された数字は、元々入力ゲートウェイによって入力されたため、SIP プロキシは、これを使用して、着信ゲートウェイに基づいて使用する VoiceXML ゲートウェイを判別できます。この方法で、特定のサイトに到着するコールは、VoiceXML の処理のために常にこのサイトに戻すことができ、音声 RTP ストリームを転送するために WAN 帯域幅は使用されません。Unified CVP は、すべての転送（Unified CM への転送を含む）に sigdigits 値を無差別に付加することを忘れないでください。したがって、このシナリオで Unified CM を使用している場合、次の例に示すように、コールが到着したときに、先頭に付加された数字を除去し、Unified CM が電話の実際の DNIS 番号を使用して、このコールをルーティングする必要があります。

入力ゲートウェイのコンフィギュレーション

着信 DNIS の先頭に値 3333 を付加する変換ルールを適用します。

DNIS 番号が 8002324444 の場合、Unified CVP にルーティングされる最終 DNIS ストリングは、33338002324444 です。

Unified CVP SIP サービスのコンフィギュレーション

SIP サービスを設定するには、Operations Console で、[Call Server] > [SIP] タブを選択します。多くの設定が [Advanced Configuration] ウィンドウにあります。

VoiceXML ゲートウェイのコンフィギュレーション

DNIS ストリング（先頭に付加された数字を含む）に一致するように VXML ゲートウェイを設定します。

sigdigits パラメータを使用して、Unified CVP の bootstrap.tcl アプリケーションを設定し、着信 DNIS ストリングから数字をいくつ除去するかを指示します。

Cisco Unified CM コンフィギュレーション（使用する場合）

[SIP Trunk configuration] ページの Significant Digits コンフィギュレーションまたは変換パターンを使用して、先頭に付加された数字を除去するように Unified CM を設定します。

SIP プロキシ コンフィギュレーション

先頭に付加された数字を使用して、適切な VoiceXML ゲートウェイに送信されるように SIP プロキシのスタティック ルートを定義します。Unified CM クラスタのエージェントへの転送にも先頭に数字が付加されるため、エージェント電話のスタティック ルートにも付加された数字が含まれている必要があります。

コール ルーティングのまとめ

1. コールは、Unified CVP に DNIS 番号 33338002324444 で到着します。

2. 次に Unified CVP は、DNIS ストリングの先頭から 4 つの数字（3333）を除去し、8002324444 になります。

3. 8002324444 がコール ルーティング用に ICM に渡されます。

4. 転送時、ICM はラベル 5551000102 を返すとします。Unified CVP は、3333 を先頭に付加し、33335551000102 になります。

5. SIP サービスは、SIP プロキシまたはローカル スタティック ルートを使用してこのアドレスを解決し、このコールを VoiceXML ゲートウェイに送信します。

6. VoiceXML ゲートウェイの bootstrap.tcl は、3333 を除去し、宛先アドレスは 5551000102 になります。

H.323 代替エンドポイント

集中型展開または分散型展開のすべての場合において、VoiceXML ゲートウェイが着信要求を拒絶した場合（エラーや過負荷が原因）に備えて、VoiceXML ゲートウェイそれぞれに対して代替エンドポイントを設定します。

コール処理

VoiceXML ゲートウェイに障害が発生した場合、次の状態がコール処理に適用されます。

• 進行中のコールは、入力ゲートウェイの存続可能性によって代替の場所のデフォルトのルートにルーティングされます（存続可能性は、NIC ルーティング モデルでは適用されません）。

• 新しいコールは、代替 VoiceXML ゲートウェイを見つけます。

音声ゲートウェイでのハイアベイラビリティのためのハードウェア設定

個々のハードウェア コンポーネントには、次のハイアベイラビリティ オプションがあります。

• 冗長電源および手元のスペア

• ハイアベイラビリティのための別個のコンポーネント

• 相互作用の問題が少ない専用コンポーネント

例 1： 別個の PSTN ゲートウェイおよび VoiceXML ゲートウェイ

PSTN ゲートウェイおよび別個の VoiceXML ゲートウェイによって、PSTN と VoiceXML が結合されたゲートウェイよりも高いアベイラビリティが実現されます。

例 2： ハイアベイラビリティのためのコンポーネントの複製

• 8-T1 PSTN ゲートウェイが 2 つあると、16-T1 PSTN ゲートウェイ 1 つよりも高いアベイラビリティが実現されます。

• 96 ポート Unified CVP VXML Server が 2 つあると、192 ポート Unified CVP VXML Server 1 つよりも高いアベイラビリティが実現されます。

• 大規模な設計では、ハイアベイラビリティのために N+1 のスペアを使用できます。

例 3： ハイアベイラビリティのための地理的な冗長性

地理的な冗長性およびハイアベイラビリティは、サイド A とサイド B で同じハードウェアを購入することにより実現できます。

設定

次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』の説明に従って、Virtual IP（VIP; 仮想 IP）冗長性の方法を使用して CSS のハイアベイラビリティを設定できます。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

次の URL から入手可能な最新バージョンの『 CSS Redundancy Configuration Guide 』も参照してください。

http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_installation_and_configuration_guides_list.html

本質的に、CSS のマスターとバックアップのペアは、HSRP ゲートキーパーのペアとほぼ同じように機能します。このペアは、同じ VLAN にあり、HSRP と非常によく似たプロトコルである Virtual Router Redundancy Protocol（VRRP; 仮想ルータ冗長プロトコル）を使用して、ハートビートを交換します。プライマリ CSS に障害が発生した場合、バックアップ CSS は、3 秒以内に障害を認識し、設定された仮想 IP アドレスへのクライアント要求の処理を開始します。マスター CSS とバックアップ CSS のコンフィギュレーションは、常に同期が取られている必要があります。

コール処理

マスター CSS に障害が発生した場合、次の状態がコール処理に適用されます。

• 進行中のコールには、VoiceXML ゲートウェイ クライアントが要求したサービスのタイプに応じて、さまざまな動作が発生します。

– メディア サーバ要求には、影響ありません。

VoiceXML ゲートウェイの、音声ファイルの CSS を使用した相互作用は非常に短いです。ゲートウェイからメディア サーバ要求を受信するとき、CSS は、VoiceXML ゲートウェイに HTTP リダイレクト IP アドレスを与えるだけです。この時点で、ゲートウェイは、メディア サーバから音声ファイルを直接フェッチし、CSS とのさらなる相互作用をバイパスします。また、VoiceXML ゲートウェイは、以前に取得したメディア ファイルをキャッシュするため、CSS へのメディア ファイル要求の頻度は非常に低いです。

– Unified CVP IVR サービス要求には、影響ありません。

Unified CVP IVR サービスへの最初の VoiceXML ドキュメント要求だけが CSS を使用します。CSS は、要求を実行するために、まず Unified CVP IVR サービスを選択します。最初のドキュメントは、VoiceXML ゲートウェイに戻るときに CSS を通過します。ただし、後続の VoiceXML 要求は、VoiceXML ゲートウェイ クライアントから Unified CVP IVR サービスに直接行われます。最初の VoiceXML ドキュメントが戻される、非常に短い時間に CSS に障害が発生した場合、VoiceXML ゲートウェイは、単に要求を再試行します。バックアップ（現在のプライマリ）CSS が前回と同じ Unified CVP IVR サービスを選択した場合、重複コール インスタンスのためにエラーになります。この場合、発信者は、発信元ゲートウェイの存続可能性によってデフォルトのルートにルーティングされます。

– ASR/TTS 要求は、通常障害を発生しますが、回復できる場合があります。

VoiceXML ゲートウェイが CSS に対して ASR/TTS 要求を初めて行うとき、TCP 接続が VoiceXML ゲートウェイから Media Resource Control Protocol（MRCP）サーバに開かれます。この TCP 接続は、CSS に到達し、発信者が接続解除するか、エージェントに転送されるまで維持されます。プライマリ CSS に障害が発生すると、TCP 接続は切断されます。VoiceXML ゲートウェイによってエラー コードが返されます。これに回避するためのスクリプトを書き込めます。最悪のシナリオは、発信者が発信元のゲートウェイの存続可能性によって、代替場所のデフォルトのルートにルーティングされることです。

– Unified CVP VXML Server 要求は、障害が発生する場合があります。

VoiceXML ゲートウェイは、VoiceXML セッションの間、特定の Unified CVP VXML Server に対して「スティッキ」になります。このゲートウェイは、CSS クッキーを使用して、このスティッキ性を実現します。

アクティブとバックアップの VIP 冗長および仮想インターフェイス冗長環境で CSS ピアに対して Adaptive Session Redundancy（ASR）を設定すると、ほとんどの既存のコールのステートフル フェールオーバーが実現します。ASR は、マスター CSS に障害が発生した場合、バックアップ CSS が、マスターの役割を引き継ぐときに中断せずに、ほとんどのアクティブ コールを継続するために必要なフローステート情報を持つことを保証します。

既存のコールを継続できない、まれな場合には、VoiceXML ゲートウェイによってエラー コードが返されます。これに回避するためのスクリプトを書き込めます。最悪のシナリオは、発信者が発信元のゲートウェイの存続可能性によって、代替場所のデフォルトのルートにルーティングされることです。

CSS の Adaptive Session Redundancy（ASR）機能を使用すると、ポート ライセンスが VXML Server で一時的に不必要に使用できなくなることはありません。VXML Server はステートフルで、ASR 機能は、CSS フェールオーバー中に VXML Server ライセンス ポート使用率を最小化します。

新しいコールは、ユーザには意識されずにバックアップ CSS の VIP に転送され、サービスには影響ありません。

Unified CVP マイクロアプリケーション使用時のコンフィギュレーション

VoiceXML ゲートウェイは、HTTP 要求を HTTP メディア サーバに送信し、音声ファイルを取得します。このゲートウェイは、CSS を使用しない場合、次の VoiceXML ゲートウェイ コンフィギュレーション パラメータを使用して、サーバを検索します。

バックアップ サーバは、プライマリ サーバにアクセスできない場合だけ呼び出されます。これは、ロード バランシング メカニズムではありません。新しい各コールは、プライマリ サーバに接続しようとします。フェールオーバーが発生すると、バックアップ サーバがコールの間使用されます。次の新しいコールは、プライマリ サーバに接続しようとします。

mediaserver は固定された名前ではなく、ICM スクリプトで media_server ECC 変数に割り当てられた名前と一致する必要があります。

VoiceXML ゲートウェイも、CSS を使用するときに、次の VoiceXML ゲートウェイ コンフィギュレーション パラメータを使用して、サーバを検索します。

CSS は、最初の要求に関して、ほとんどの場合メディア サーバを検索するため、バックアップ サーバが呼び出されることはほとんどありません。ただし、複数のデータセンターそれぞれに CSS がある場合の展開に CSS を使用する場合、バックアップ サーバを設定すると便利です。

Unified CVP マイクロアプリケーション使用時のコール処理

メディア サーバに障害が発生した場合、次の状態がコール処理に適用されます。

• 進行中のコールは、自動的に回復されます。上記で説明したハイアベイラビリティ コンフィギュレーション技術により、障害が発信者には分からないようにする必要があります。メディア要求に障害が発生した場合、スクリプティング技術を使用してエラーを回避します（要求の再試行、エージェントまたはラベルへの転送、TTS の使用など）。

• 新しいコールは、ユーザには意識されずにバックアップ メディア サーバに転送され、サービスには影響ありません。

• メディア サーバが VoiceXML ゲートウェイから WAN を超えて展開されていて、WAN 接続に障害が発生した場合、ゲートウェイは、要求されたプロンプトが期限切れになるまで、ゲートウェイ キャッシュからのプロンプトの使用を継続します。要求されたプロンプトが期限切れになると、ゲートウェイは、メディアの再フェッチを試行し、存続可能性がイネーブルになっていない場合、コールは失敗します。存続可能性がイネーブルになっている場合、コールはデフォルトのルートにルーティングされます。

Cisco Unified Call Studio スクリプティング使用時のコンフィギュレーション

Cisco Unified Call Studio でスクリプティングしている場合は、ICM スクリプティングとは異なり、メディア ファイルの「 バックアップ 」の概念はありません。スクリプトを書き込んでいるユーザができる最良の方法は、アプリケーションで、[Properties] -> [AudioSettings] -> [Default Audio Path URI] を単一のメディア サーバまたはメディア サーバのファームの CSS VIP アドレスにすることです。

設定

Unified CVP VXML Server のハイアベイラビリティ コンフィギュレーションおよび動作は、次の各項で説明するように、スタンドアロン展開と ICM と統合展開で異なります。

スタンドアロン セルフサービス展開

プライマリとバックアップの Unified CVP VXML Server の設定方法については、 http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html から入手可能な最新バージョンの『 Cisco Unified CVP Configuration and Administration Guide 』を参照してください。

特に、Unified CVP VXML Server のハイアベイラビリティ特性を制御するのは、CVPPrimaryVXMLServer ゲートウェイ パラメータおよび CVPBackupVXMLServer ゲートウェイ パラメータです。Unified CVP VXML Server のロード バランシング機能およびさらの強固なフェールオーバー機能が必要な場合、CSS または ACE デバイスを使用できます（設定の詳細については、最新バージョンの『 Cisco Unified CVP Configuration and Administration Guide 』を参照してください）。ロード バランシングは、CSS または ACE デバイス使用しなくても、複数のゲートウェイでプライマリおよびバックアップの Unified CVP VXML Server コンフィギュレーションを変えることにより実現できます。

ICM を使用した展開

Unified CVP VXML Server を ICM とともに使用する場合、ICM スクリプトは、VoiceXML アプリケーションを呼び出すために、VoiceXML ゲートウェイに URL を渡します。Unified CVP VXML Server A への接続を初めて試行するように ICM スクリプトを設定できます。アプリケーションが Unified CVP VXML Server の ICM スクリプト ノードの X-path で障害を発生すると、Unified CVP VXML Server B への接続が試行されます。URL の IP アドレスは、CSS の Unified CVP VXML Server VIP を表すこともできます。

コール処理

Unified CVP VXML Server に障害が発生すると、次の状態がコール処理に適用されます。

• スタンドアロン展開の進行中のコールは、接続解除されます。ICM 統合展開の進行中のコールは、上記のスクリプトで示したようにスクリプティング技術を使用して回復し、エラーを回避できます（要求の再試行、エージェントまたはラベルへの転送、END スクリプト ノードを使用して強制的にエラーにし、発信元ゲートウェイの存続可能性を呼び出すなど）。

• 新しいコールは、ユーザには意識されずに代替 Unified CVP VXML Server に転送されます。

（注） CSS または ACE デバイスがない場合、発信者は、コールの最初で遅延が発生し、プライマリ Unified CVP VXML Server への接続を試行しながら、システムがタイムアウトになるのを待つ必要がある場合があります。

設定

ASR/TTS ハイアベイラビリティのコンフィギュレーションおよび動作は、次の各項で説明するように、スタンドアロン展開と ICM 統合展開で異なります。

スタンドアロン セルフサービス展開

スタンドアロン展開で、ASR/TTS に対してフェールオーバー機能を提供するには、CSS または ACE デバイスが必要です。ASR/TTS に対して CSS または ACE デバイスを設定する方法およびスタンドアロン展開で ASR/TTS サーバを設定する方法については、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

ICM を使用した展開

VoiceXML ゲートウェイは、CSS または ACE デバイスを使用している場合と使用していない場合の両方で、ゲートウェイ コンフィギュレーション パラメータを使用して、ASR/TTS サーバを検索します。バックアップ サーバは、プライマリ サーバにアクセスできない場合だけ呼び出されます。これは、ロード バランシング メカニズムではありません。新しい各コールは、プライマリ サーバに接続しようとします。フェールオーバーが発生すると、バックアップ サーバがコールの間使用されます。次の新しいコールは、プライマリ サーバに接続しようとします。

ホスト名（ asr-en-us など）は固定され、変更できません。変更できるのは、ロケールだけです。次の例では、プライマリとバックアップの英語の ASR/TTS サーバのセットおよびスペイン語のサーバのセットがあります。次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』の指示に従って、CSS（使用する場合）を設定します。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

CSS を使用している場合、次の例で説明する IP アドレスは、CSS 上での ASR/TTS サービスの仮想 IP アドレスです。

CVP 展開での混在コーデックの使用に関する説明については、「G.729 および G.711 コーデックの混在サポート」を参照してください。各コーデックの利点および欠点の説明については、「音声トラフィック」を参照してください。

（注） ASR スピーチ ライセンスは、発信者がエージェントに転送されるまでリリースされません。

コール処理

ASR/TTS MRCP サーバに障害が発生すると、次の状態がコール処理に適用されます。

• スタンドアロン展開の進行中のコールは、接続解除されます。ICM 統合展開の進行中のコールは、スクリプティング技術を使用して回復し、エラーを回避できます（要求の再試行、エージェントまたはラベルへの転送、残りのコールの事前に記録されたプロンプトおよび DTMF のみの入力への切り替え、END スクリプト ノードを使用して強制的にエラーにし、発信元ゲートウェイの存続可能性を呼び出すなど）。

• CSS を使用している場合、スタンドアロン展開または ICM 統合展開の新しいコールは、ユーザには意識されずに代替 ASR/TTS サーバに転送されます。「-backup」というゲートウェイ ホスト名を使用していた場合、ICM 統合展開の新しいコールは、ユーザには意識されずに代替 ASR/TTS サーバに転送されます。

設定

Unified CM でのハイアベイラビリティの実現に関する最新情報については、 http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html から入手可能な最新バージョンの『 Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND) 』を参照してください。

コール処理

コールをホストしているまたは電話をホストしているサーバで Unified CM プロセスに障害が発生した場合、次の状態がコール処理に適用されます。

• 進行中のコールは保持されます。Skinny Client Control Protocol（SCCP）電話には、Unified CM を失ったことを検出したときでも、コールを保持する機能があります。発信者とエージェントの会話は、発信者またはエージェントのいずれかが電話を切るまで継続されます。Unified CVP コール サーバは、Unified CM に障害が発生したことを認識し、コールを保持する必要があると推測し、発信元ゲートウェイへのシグナリング チャネルを維持します。こうすることにより、発信元ゲートウェイは、Unified CM に障害が発生したことを認識しません。コールで追加操作（保留、転送、会議など）は、できないことに注意してください。いったん電話が切られると、この電話は別の Unified CM サーバに接続されるようになります。エージェントが電話を切ると、Real-Time Control Protocol（RTCP）パケットが発信元ゲートウェイへの送信を停止します。この結果、ゲートウェイは、エージェントが電話を切った 9 ～ 18 秒後に接続解除されます。ゲートウェイで存続可能性が設定されていて、発信者が追加の操作を待っている場合（エージェントは、発信者が別の宛先にブラインド転送されていると考える場合があります）、発信者は別の場所のデフォルトのルートにルーティングされます。

• 新しいコールは、クラスタ内の代替 Unified CM サーバに転送されます。

設定

ハイアベイラビリティを実現するための ICM の設定に関する最新情報については、次の URL から入手可能な最新バージョンの『 Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html

コール処理

Cisco ICM には多くのコンポーネントがあり、コール処理は障害が発生したコンポーネントによって異なります。いくつかの例外はありますが、次の状態がコール処理に適用されます。

• Voice Response Unit（VRU; 音声応答装置）Peripheral Gateway（PG; ペリフェラル ゲートウェイ）または VRU PG 上のコンポーネントに障害が発生した場合、進行中のコールは、発信元ゲートウェイの存続可能性によってデフォルトのルートにルーティングされます。

• Logger に障害が発生した場合、進行中のコールには影響ありません。

• プライマリ ルータに障害が発生した場合、進行中のコールには影響ありません。サイド A とサイド B のルータ両方に障害が発生した場合、進行中のコールは、発信元ゲートウェイの存続可能性によってデフォルトのルートにルーティングされます。

• 新しいコールは、バックアップの ICM コンポーネントに転送されます。