Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)リリース 9.0(1)
ハイアベイラビリティのための Unified CVP 設計
ハイアベイラビリティのための Unified CVP 設計
発行日;2012/11/27   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

目次

ハイアベイラビリティのための Unified CVP 設計

 

この章では、ハイアベイラビリティ Unified CVP システムの設計に関するガイドラインおよびベスト プラクティスについて説明します。

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

新規または変更された章の情報

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

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

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

説明

Application Control Engine に関する更新済みの内容

 

Content Services Switch に関する削除済みのコンテンツ

 

概要

ハイアベイラビリティ設計では、トップレベルの障害保護が実現されます。 ソリューションは、次のようなビジネス上の必要性によって異なります。

  • コール障害に対する耐性
  • 予算
  • トポロジ上の考慮事項

Unified CVP は、多くのハードウェアおよびソフトウェア コンポーネントを使用する、多くの構成に展開できます。 各ソリューションは、コール センターで障害の影響を受けるリソースを最小限に抑えるような設計になっている必要があります。 影響を受けるリソースのタイプおよび数は、ビジネス要件の厳しさや、さまざまな Unified CVP コンポーネントに対して選択する設計特性によって異なります。 適切な Unified CVP 設計はほとんどの障害に耐えますが、一部の障害を発信者に分からないようにできないことがあります。

Unified CVP は、ミッションクリティカルなコール センターのために設計された高度なソリューションです。 Unified CVP 展開を成功させるには、データと音声のインターネット作業、システム管理、および Unified CVP アプリケーションのコンフィギュレーションに関する経験を持つチームが必要です。

Unified CVP を実装する前に、後で導入サイクルにおいて高コストなアップグレードやメンテナンスを行わずに済むように、入念な計画を使用してください。 常に、最悪の障害シナリオを考慮して設計し、将来のスケーラビリティをすべての Unified CVP サイトについて考慮してください。

つまり、事前に計画を立て、このマニュアルおよび次の URL から入手可能な最新バージョンの『Cisco Unified Communications Solution Reference Network Design (SRND) Based on Cisco Unified Communications Manager』に記載されている、すべての設計ガイドラインおよび推奨事項に従ってください。

http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​products_​implementation_​design_​guides_​list.html

Unified CVP ソリューションの計画および設計に関する支援については、シスコまたは認定パートナーの Systems Engineer(SE; システム エンジニア)に相談してください。

Unified CVP コール サーバ コンポーネントに関する注意

このマニュアルの他の章では、Unified CVP コール サーバを単一のコンポーネントとして扱います。これは、これらの章では、Unified CVP コール サーバについてそれ以上の詳細を説明する必要がないためです。 ただし、Unified CVP のハイアベイラビリティについて説明する場合、このコンポーネントは実際にはいくつかの部分で構成されていることを理解しておく必要があります。

  • SIP サービス:SIP を使用して、着信コールおよび発信コールの処理を行います。
  • ICM サービス:ICM へのインターフェイスです。 ICM サービスは、GED-125 を使用して VRU PG と通信し、ICM で IVR 制御が可能になります。 ICM サービスは、以前のリリースの Unified CVP ではアプリケーション サーバの一部でしたが、現在は別のコンポーネントになっています。
  • IVR サービス:Unified CVP マイクロアプリケーションから VoiceXML ページへ、およびその逆の変換を行います。 IVR サービスは、以前のバージョンの Unified CVP では、アプリケーション サーバと呼ばれていました。

レイヤ 2 スイッチ

図 1. 冗長性のある Unified CVP システム. 次の図に、耐障害性の Unified CVP システムの概要レイアウトを示します。 Unified CVP サイトの各コンポーネントは、冗長性を実現するために複製されています。 これらのコンポーネントそれぞれの数は、特定の展開に対して予想される Busy Hour Call Attempt(BHCA; 最繁時呼数)に応じて異なります。



この図では、2 台のスイッチによって、Unified CVP Server にトップ レベルのネットワーク冗長性がもたらされます。
  • 一方のスイッチに障害が発生しても、アクセスできなくなるのは、コンポーネントの 1 つのサブセットだけです。 もう一方のスイッチに接続されているコンポーネントには、コール処理のために引き続きアクセス可能です。
  • ACE を使用している場合、ホットスタンバイ ルータ プロトコル(HSRP)に似たプロトコルである仮想ルータ冗長プロトコル(VRRP)を介して相互に keep-alive メッセージを送信するためには、冗長パートナーが同じ VLAN 上に展開されている必要があります。 一方のスイッチに障害が発生しても、他方の ACE は引き続き動作します。

データセンター ネットワーク設計の詳細については、次の URL から入手可能なデータセンターに関するマニュアルを参照してください。

http:/​/​www.cisco.com/​go/​designzone


(注)  


NIC のチーム機能は、Unified CVP ソリューションでは現在サポートされていません。

NIC カードおよびイーサネット スイッチは、10/100 リンクの 100 MB 全二重に設定するか、ギガビット リンクの自動ネゴシエーションに設定することを推奨します。


発信元ゲートウェイ

Unified CVP ソリューションでの発信元ゲートウェイの機能は、PSTN からのコールを受け入れ、コール ルーティングおよび IVR 処理のためにこれを Unified CVP に転送することです。

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

設定

発信元ゲートウェイおよび 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 統合モデルで使用すると、発信側ゲートウェイは、SIP を使用して Unified CVP と通信します。 MGCP とは異なり、SIP では、冗長性機能はプロトコルに組み込まれていません。 代わりに、SIP は、冗長性のためにゲートウェイとコール処理コンポーネントに依存します。
  • ゲートウェイを設定する場合、次の設定例に示すように、SIP シグナリングを仮想ループバック インターフェイスにバインドすることを推奨します。 SIP
    voice service voip sip
      bind control source-interface Loopback0
      bind media source-interface Loopback0
    このコンフィギュレーションでは、物理インターフェイスに依存せずにコール シグナリングが動作します。 この方法では、一方のインターフェイスに障害が発生しても、他方のインターフェイスでトラフィックを処理できます。 各ゲートウェイ インターフェイスを異なる物理スイッチに接続し、一方のスイッチまたはインターフェイスに障害が発生した場合に冗長性を実現する必要があります。 ゲートウェイ上の各インターフェイスは、異なるサブネット上の IP アドレスを使用して設定されます。 ネットワークの IP ルータは、スタティック ルートまたはルーティング プロトコルによるループバック アドレスへの冗長ルートとして設定されます。 ルーティング プロトコルを使用して、ゲートウェイと交換するルート数を確認する場合、ゲートウェイがループバック アドレスだけをアドバタイジングし、ルートを受信しないようにルーティング アップデートを制限するフィルタの使用を考慮してください。

コール処理

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

  • 進行中のコールはドロップされます。 このゲートウェイ上のすべての T1/E1 トランクへの D チャネルを PSTN スイッチが失うため、これらのコールを保持する方法はありません。
  • 新しいコールは、代替ゲートウェイで PSTN キャリアによって T1/E1 に転送されます(PSTN スイッチにトランクがあり、ダイヤル プランがこのように設定されている場合)。

SIP プロキシ

SIP プロキシ サーバは、SIP エンドポイントの代わりにダイヤル プランの解決法を提供し、ダイヤル プラン情報を各 SIP デバイスにスタティックに設定するのではなく、集中的に設定します。 SIP プロキシ サーバは、Unified CVP ソリューションでは必要ありませんが、集中的に設定およびメンテナンスできるという利点のため、ほとんどのソリューションで使用されます。 複数の SIP プロキシ サーバをネットワークに導入し、ロード バランシング、冗長性、および地域の SIP コール ルーティング サービスを実現できます。 Unified CVP ソリューションでは、SIP コール ルーティングの選択肢は次のとおりです。

  • SIP プロキシ サーバ
    • 利点: 加重ロード バランシングおよび冗長性。 集中型ダイヤル プラン コンフィギュレーション。 SIP プロキシは、ダイヤル プランの解決法またはクラスタ間コール ルーティングのために、すでに存在しているかまたはその他のアプリケーションに使用されている場合があります。
    • 欠点: 追加のサーバまたはハードウェアが SIP プロキシに必要(導入済みでない場合)。
  • DNS サーバ上でサーバ グループ(DNS SRV レコード)を使用するスタティック ルート
    • 利点: 加重ロード バランシングおよび冗長性。
    • 欠点: DNS サーバの場所によっては、既存のサーバを使用できません。 DNS サーバ管理権限を共有または委任する機能が、一部の組織では制限される場合があります。 ダイヤル プラン コンフィギュレーションを各デバイス(Unified CM、Unified CVP、およびゲートウェイ)に対して個別に設定する必要があります。 DNS SRV ルックアップが Unified CVP によってすべてのコールそれぞれに対して実行されます。 DNS サーバの応答が遅い場合、使用できない場合、または WAN 経由である場合、パフォーマンスに影響を及ぼします。
  • ローカル DNS SRV レコードを使用するスタティック ルート
    • 利点: 加重ロード バランシングおよび冗長性。 外部 DNS サーバに依存しないため、ポイント障害、遅延、および DNS サーバのパフォーマンスの問題が発生しません。
    • 欠点: ダイヤル プランを各デバイス(Unified CM、Unified CVP、およびゲートウェイ)に対して個別に設定する必要があります。

(注)  


DNS サーバによる SRV の使用またはサーバ グループの使用によるスタティック ルートの選択により、プライマリの宛先が停止中またはネットワークに接続されていないときに、Unified CVP コール サーバ上での UDP 転送によるフェールオーバーまたはロード バランシング中に予期しない長時間の遅延が引き起こされる可能性があります。 UDP で、ホスト名にサーバ グループ(srv.xml)内で異なるプライオリティを持つ複数の要素がある場合、Unified CVP は、要素ごとに 2 回、各試行間を 500 ミリ秒で試行します。 最初の要素が応答しない場合、次の要素を 1 秒後に試行しようとします。 この遅延は、ロードバランシングに応じて、また T1 タイマーに関する RFC 3261 の第 17.1.1.1 項に準拠して、障害が発生している間、すべてのコールに発生します。 サーバ グループのハートビートがオンになっている場合、要素のステータスに応じて、遅延は 1 回だけ発生するか、まったく発生しない可能性があります。 これは、TCP にも適用されます。
  • IP アドレスを使用したスタティック ルート
    • 利点: 宛先にコールを配信する際に他のデバイス(DNS またはプロキシ)に依存しません。
    • 欠点: Unified CVP からの SIP コールに対して冗長性を持たせることができません。 ダイヤル プランを各デバイス個別に設定する必要があります。 このオプションは、冗長性がない(単一のサーバ)環境または実験での導入の環境で使用されます。

Unified CVP ソリューションの各デバイスは、上記の方法を使用して、コールの送信先を決定できます。 SIP ネットワークへの Unified CVP コール サーバ インターフェイスは、Unified CVP SIP サービスを使用します。このサービスについては、Unified CVP SIP サービスの項で説明します。

Cisco Unified SIP プロキシ(CUSP)のサポート

Unified CVP Release 9.0(1) は、Cisco Unified SIP プロキシ サーバ(CUSP Server)バージョン 1.1.4 で検証されています。 つまり、Unified CVP は、CUSP プロキシ サーバだけをサポートするようになりました。

CUSP の導入方法

CVP ソリューションの CUSP プロキシでは、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 レコードは、次のようになります。

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
導入オプション 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 レコードは、次のようになります。

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.30 priority 2 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.30 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR1 on east coast)

CUSP 導入のパフォーマンス マトリクス

CUSP ベースライン テストは、プロキシ上で隔離して行われ、キャパシティの数値(毎秒 450 TCP、500 UDP トランザクション)が最高クラスのベンチマークとして使用され、許容される最も負荷がかかる条件で実行されました。
プロキシ サーバの観点では、CVP コールは、平均すると次の 4 つの異なる SIP コールになります。
  • 発信者の着信レッグ
  • VXML 発信レッグ
  • 着信音の発信レッグ
  • エージェントの発信レッグ

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

CUSP 設計上の考慮事項

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

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


(注)  


SIP ハートビートを使用したアップストリーム要素ルーティング

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


設定

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

SIP プロキシ サーバの設定

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

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

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

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

sip-ua sip-server ipv4:10.4.1.100:5060 

dial-peer voice 1000 voip
 session target sip-server
 ...

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

sip-ua sip-server dns:cvp.cisco.com

dial-peer voice 1000 voip
 session target sip-server
 ...

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

dial-peer voice 1000 voip session target ipv4:10.4.1.100
 preference 1
 ...
dial-peer voice 1000 voip
 session target ipv4:10.4.1.101
 preference 1
 ...

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

dial-peer voice 1001 voip session target ipv4:10.4.33.131
 preference 1
 ...
dial-peer voice 1002 voip
 session target ipv4:10.4.33.132
 preference 1
 ...
dial-peer voice 1003 voip
 session target ipv4:10.4.33.133
 preference 1
 ...

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

ip name-server 10.4.33.200 
dial-peer voice 1000 voip
 session target dns:cvp.cisco.com

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

ip host cvp4cc2.cisco.com 10.4.33.132ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131

(SIP/TCP の SRV レコード)

ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.comip 
host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com

(SIP/UDP の SRV レコード)

ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.comip 
host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com

Unified CVP SIP サービス

Unified CVP SIP サービスは、Unified CVP コール サーバ上のサービスで、すべての着信および発信の SIP メッセージングおよび SIP ルーティングを処理します。 コール サーバは、発信ダイヤル プランの解決法に SIP プロキシ サーバを使用するように設定できます。または、IP アドレスまたは DNS SRV に基づいてスタティック ルートを使用するように設定できます。 コール サーバは、スタティック ルートに関するコンフィギュレーション情報を共有しません。したがって、スタティック ルートを変更する必要がある場合、各コール サーバの SIP サービスで変更を行う必要があります。 コンフィギュレーション オーバーヘッドを最小限にするために、1 つの SIP プロキシ サーバを使用することを推奨します。

設定

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

  • 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 つのシナリオのうちいずれかが発生した場合、リカバリは不可能です。

  • 進行中のコールを含むプロセスが停止された場合。 この状況は、システム管理者がコール サーバのグレースフル シャットダウンを忘れた場合に発生します。 この場合、CVP コール サーバはライセンスを解除するために、すべてのアクティブ コールを終了します。
  • コール サーバが推奨コール レートを超えた場合。 コール サーバで許可されるコールの絶対数に対する制限はありますが、コール レートに対する制限はありません。 一般に、推奨されるコール数/秒(cps)を長時間超えると、特定のコンポーネントでコールの動作が不安定で予測できなくなります。 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 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 ルーティング モデルでは適用されません)。
  • 新しいコール 新しいコールは、Unified SIP プロキシによって、代替 Unified CVP コール サーバに転送されます。 使用可能なコール サーバがない場合、コールは、存続可能性によって代替場所のデフォルトのルートにルーティングされます (存続可能性は、NIC ルーティング モデルでは適用されません)。

サーバ グループ

サーバグループは、SIP INVITE の送信を試行する前に宛先アドレスのステータスを発信元エンドポイントが認識できるようにする、ダイナミック ルーティング機能です。 宛先がネットワークを介して到達不能、またはアプリケーション層でアウトオブサービスの場合、発信元 SIP ユーザ エージェントは、ハートビート メカニズムを介してステータスを認識できます。

サーバ グループ機能は、SIP のエンドポイントとともにハートビート メカニズムを追加します。 この機能を使用すると、障害のあるエンドポイントが原因の遅延をなくすことによって、呼制御のフェールオーバーを高速化できます。


(注)  


  • サーバ グループは、自動的には作成されません。 サーバ グループは、リリース 9.0(1) へのアップグレードによって自動的に作成されるわけではありません。 この機能を利用するには、導入用にサーバ グループを明示的に設定し、アップグレード後にこの機能をオンにする必要があります。
  • すでにローカル SRV を使用しているユーザの場合のアップグレード。 すでに srv.xml ファイルをローカル SRV で設定しているユーザは、コンフィギュレーションを Unified CVP Operations Console Server データベースにインポートするために、下記の import コマンドを実行する必要があります。 この作業は、以前のコンフィギュレーションの上書きを回避するために、新しいサーバ グループを保存し、展開する前に行ってください。

Unified CVP SIP サブシステムは、Release 9.0(1) で使用可能なローカル SRV コンフィギュレーション XML に基づいて作成されています。

サーバ グループは、1 つ以上の宛先アドレス(エンドポイント)で構成され、サーバ グループ ドメイン名で識別されます。 このドメイン名は、SRV クラスタ ドメイン名、または FQDN とも呼ばれます。 SRV メカニズムが使用されますが、レコードの DNS サーバ解決は実行されません。 サーバ グループは、ローカル SRV 実装(srv.xml)と同じままですが、サーバ グループ機能には、その機能に加えてハートビート メカニズムがオプションとして追加されます。


(注)  


  • Unified CVP および SIP プロキシ サーバのサーバ グループは、同じように機能します。
  • ハートビートが送信されるようにできるのは、サーバ グループで定義されたエンドポイントだけです。
  • プロキシでレコード ルートをオフに設定すると、REFER や REINVITES などの mid-dialog SIP メッセージは、サーバ グループで定義された要素をバイパスします。 これらのメッセージは、ダイアログ内の他のエンドポイントに直接配信されます。

以前のリリースでは、DNS SRV クエリーのオーバーヘッドを回避するために、SRV レコードをローカルに設定するための srv.xml コンフィギュレーション ファイルを使用しました。 ただし、コンフィギュレーションの方法は手動で、Unified CVP Operations Console Server(Operations Console)からプッシュできませんでした。 また、フィールドの最小値および最大値の検証はありませんでした。

リリース 9.0(1) では、サーバ グループの概念を使用して、このコンフィギュレーションが Operations Console SIP サブシステムに追加されます。 サーバ グループの条件は、ローカル SRV コンフィギュレーションの参照のみを行います。 [Server groups with Heartbeat] をオンにすると、Unified CVP でエンドポイントのステータスを事前にモニタできるダイナミック ルーティング機能を取得できます。 この機能が対象としているのは、Unified CVP からの発信コールだけです。 Unified CVP への着信コールを対象に含めるために、SIP プロキシ サーバは、類似のハートビートを Unified CVP に送信できます。Unified CVP は、ステータス応答で応答できます。

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

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

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


(注)  


  • サーバ グループのハートビート動作設定。 要素が稼働中のときに ping をオフにするには、[Up Endpoint Heartbeat Interval] をゼロに設定します(事後対応型 ping)。 要素が停止しているときに ping をオフにするには、[Down Endpoint Heartbeat Interval] をゼロに設定します(事前対応型 ping)。 要素が稼働中または停止中のいずれかのときに ping するには、ハートビート間隔をゼロより大きくします(適応型 ping)。
  • ハートビート応答処理。 CVP がコールをルーティングする先のエンドポイントは、OPTIONS に対して応答(200 OK または他の応答)で応答する必要があります。 ハートビートに対して応答がある場合は、もう一方の側が動作していて到達可能であることを示します。 通常 200 OK が返されますが、OPTIONS メッセージで max-forwards ヘッダーがゼロに設定されているため、CUSP Server は 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 サーバ ルックアップまたはオペレーティング システムなどのホスト ファイルを使用して解決される場合があります。
  • CUSP プロキシ CLI では、プロキシ コンフィギュレーションのサービス パラメータ セクションの SRV クラスタ名(proxy-servers.cisco.com など)を定義します。 それ以外の場合、404 not found 拒否になります。

診断

Unified 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 の指示を参照してください。

Unified CVP IVR サービス

ハイアベイラビリティは、アプリケーション サーバの IP アドレスのリストまたは ACE を使用するか、あるいはこれら両方を使用して、Unified CVP Voice Browser および VoiceXML ゲートウェイを設定することにより、実現されていました。 Unified CVP 4.0 以降のリリースでは、IVR サービスは、SIP サービスと厳密に結合されています。 IVR サービスがアウトオブサービスになると、SIP サービスもアウトオブサービスになり、Unified CVP コール サーバでコールを受け付けなくなります。

設定

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

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

service bootstrap flash:bootstrap.tcl  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en

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

ゲートウェイのフラッシュ メモリには、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 ゲートウェイ

VoiceXML ゲートウェイは、次のソースから取得した VoiceXML ドキュメントを解析し、レンダリングします。Unified CVP コール サーバ(この IVR サービスから)、Unified CVP VXML Server、または他の外部 VoiceXML ソースの一部。 VoiceXML ドキュメントのレンダリングは、事前に録音されたオーディオ ファイルの取得および再生、ユーザ入力の収集および処理、または音声認識およびダイナミックな音声合成変換のための ASR/TTS サーバへの接続から構成されます。

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

設定

VoiceXML ゲートウェイのハイアベイラビリティ コンフィギュレーションは、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 コール サーバと同じデータセンターにあります。

SIP VoiceXML ゲートウェイ

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 ゲートウェイ

この設定では、PSTN からの着信コールを処理するゲートウェイは、WAN などの低帯域幅の接続で Unified CVP サーバから分離されます。 VoiceXML ゲートウェイは、入力ゲートウェイと同じです。 この設定は、WAN でメディア ストリームが帯域幅を消費しないようにします。

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 ゲートウェイ

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

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

SIP VoiceXML ゲートウェイ

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

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

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

translation-rule 99 
 rule 1 8002324444 33338002324444

dial-peer voice 1000 voip
 translate-outgoing called 99

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

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

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

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

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

dial-peer voice 3000 voip 
 incoming-called number 33335551000T
 service bootstrap
 ...

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

application 
 service bootstrap flash:bootstrap.tcl
 param sigdigits 4
 ...

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 になります。

コール処理

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 で同じハードウェアを購入することにより実現できます。

メディア サーバ

音声ファイルは、VoiceXML ゲートウェイまたは HTTP/TFTP ファイル サーバ上のフラッシュ メモリにローカルに保存されます。 音声ファイルをローカルに保存する方法は可用性が非常に高くなります。 ただし、HTTP/TFTP ファイル サーバには、音声ファイルの集中管理という利点があります。


(注)  


Unified CVP 9.0 以降は、別のメディア サーバをインストールできません。 メディア サーバは、コール サーバおよび Unified CVP VXML Server と同じ場所に設置する必要があります。


Unified CVP マイクロアプリケーションの設定

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

ip host mediaserver <ip-address-of-primary-media-server>
ip host mediaserver-backup <ip-address-of-secondary-media-server>

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

メディア サーバは固定された名前ではなく、ICM スクリプトで media_server ECC 変数に割り当てられた名前と一致する必要があることに注意してください。

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

ip host mediaserver <ip-address-of-ACE-VIP-for-media-server>
ip host mediaserver-backup <ip-address-of-ACE-VIP-for-media-server>

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

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

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

  • 進行中のコールは、自動的に回復されます。 上記で説明したハイアベイラビリティ コンフィギュレーション技術により、障害が発信者には分からないようになります。 メディア要求に障害が発生した場合、スクリプティング技術を使用してエラーを回避します(要求の再試行、エージェントまたはラベルへの転送、TTS の使用など)。
  • 新しいコールは、ユーザには意識されずにバックアップ メディア サーバに転送され、サービスには影響ありません。
  • メディア サーバが VoiceXML ゲートウェイから WAN を超えて展開されていて、WAN 接続に障害が発生した場合、ゲートウェイは、要求されたプロンプトが期限切れになるまで、ゲートウェイ キャッシュからのプロンプトの使用を継続します。要求されたプロンプトが期限切れになると、ゲートウェイは、メディアの再取得を試行し、存続可能性がイネーブルになっていない場合、コールは失敗します。 存続可能性がイネーブルになっている場合、コールはデフォルトのルートにルーティングされます。

Cisco Unified Call Studio スクリプティング設定

Cisco Unified Call Studio でスクリプティングしている場合は、ICM スクリプティングとは異なり、メディア ファイルのバック機能はありません。 スクリプトの作成者は、アプリケーションで [Properties] > [AudioSettings]> > [Default Audio Path URI] を選択して、単一のメディア サーバまたはメディア ファームのファームの ACE VIP アドレスを選択することができます。

Unified CVP VXML Server

VoiceXML ゲートウェイは、Unified CVP VXML Server に対する HTTP 要求を作成し、VoiceXML ドキュメントを取得します。


(注)  


リリース 9.0 から、Unified CVP VXML Server は Unified CVP コール サーバおよびメディア サーバと一緒にインストールします。 これらは、以前のリリースのように別個にはインストールできません


設定

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 のロード バランシング機能およびさらの強固なフェールオーバー機能が必要な場合、ACE デバイスを使用できます。 設定の詳細については、最新バージョンの『Cisco Unified CVP Configuration and Administration Guide』を参照してください。 また、ロード バランシングは、複数のゲートウェイを介してプライマリおよびバックアップの Unified CVP VXML Server の設定を変えることで、ACE デバイスなしでも実現できます。

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 アドレスは、ACE の Unified CVP VXML Server VIP を表すこともできます。

コール処理

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

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

    (注)  


    ACE デバイスがない場合、発信者は、コールの最初で遅延が発生し、プライマリ Unified CVP VXML Server への接続を試行しながらシステムを待機しなければならないことがあります。


自動音声認識および音声合成サーバ

VoiceXML ゲートウェイは、VoiceXML ドキュメントで定義されている音声認識および音声合成の指示を実行するために、MRCP 要求を ASR/TTS サーバに送信します。

設定

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

スタンドアロン セルフサービス導入

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

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

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html

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

ip host asr-en-us <ip-address-of-primary-English-ASR-server>
ip host asr-en-us-backup <ip-address-of-secondary-English-ASR-server>
ip host tts-en-us <ip-address-of-primary-English-TTS-server>
ip host tts-en-us-backup <ip-address-of-secondary-English-TTS-server>
ip host asr-es-es <ip-address-of-primary-Spanish-ASR-server>
ip host asr-es-es-backup <ip-address-of-secondary-Spanish-ASR-server>
ip host tts-es-es <ip-address-of-primary-Spanish-TTS-server>
ip host tts-es-es-backup <ip-address-of-secondary-Spanish-TTS-server>

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


(注)  


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


コール処理

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

  • スタンドアロン展開の進行中のコールは、接続解除されます。 ICM 統合導入の進行中のコールは、スクリプティング技術を使用して回復し、エラーを回避できます。 たとえば、要求の再試行、エージェントまたはラベルへの転送、残りのコールの事前に記録されたプロンプトおよび DTMF のみの入力への切り替え、END スクリプト ノードを使用してエラーにし、発信元ゲートウェイの存続可能性を呼び出すなどです。
  • ACE を使用している場合、スタンドアロン導入または ICM 統合導入の新しいコールは、ユーザには意識されずに代替 ASR/TTS サーバに転送されます。 バックアップ ゲートウェイを使用する場合、ICM 統合導入の新しいコールは、ユーザには意識されずに代替 ASR/TTS サーバに転送されます。

Cisco Unified Communications Manager

Unified CVP は、SIP を使用する Unified CCE エージェント電話またはデスクトップに発信者を転送します。 Unified CVP コール サーバは、ICM からエージェント ラベルを受信し、SIP プロキシを使用してコールをルーティングします。 コールは、クラスタ内の適切な Cisco Unified Communications Manager(Unified CM)に送信され、発信者をエージェントに接続します。 コール サーバがコール シグナリングの代わりになり、転送完了後、コール シグナリング パスに留まります。 ただし、RTP ストリームは、発信元ゲートウェイから電話に直接流れます。 このことは、ハイアベイラビリティの説明において非常に重要です。

Unified CVP バージョン 9.0(1) は、Analysis Manager もサポートします。 Analysis Managerを参照してください。

設定

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 サーバに転送されます。

Intelligent Contact Management

Cisco Intelligent Contact Management(ICM)ソフトウェアは、地理的に分散したコンタクトセンター間でマルチチャネル コンタクト(電話による着信および発信コール、Web 共同要求、電子メール メッセージ、およびチャット要求)を企業全体に分散させます。 ICM ソフトウェアは、ルーティング、キューイング、モニタリング、耐障害性等の機能を持つオープン標準ベースのソリューションです。

設定

ハイアベイラビリティを実現するための 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 コンポーネントに転送されます。