この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、ハイアベイラビリティ Unified CVP システムの設計に関するガイドラインおよびベスト プラクティスについて説明します。
次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
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』に記載されている、すべての設計ガイドラインおよび推奨事項に従ってください。
Unified CVP ソリューションの計画および設計に関する支援については、シスコまたは認定パートナーの Systems Engineer(SE; システム エンジニア)に相談してください。
Unified CVP コール サーバ コンポーネントに関する注意
このマニュアルの他の章では、Unified CVP コール サーバを単一のコンポーネントとして扱います。これは、これらの章では、Unified CVP コール サーバについてそれ以上の詳細を説明する必要がないためです。 ただし、Unified CVP のハイアベイラビリティについて説明する場合、このコンポーネントは実際にはいくつかの部分で構成されていることを理解しておく必要があります。
データセンター ネットワーク設計の詳細については、次の 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)』を参照してください。
また、Unified CVP ソリューションでハイアベイラビリティを実現するゲートウェイを設計する場合、次の問題も考慮してください。
voice service voip sip bind control source-interface Loopback0 bind media source-interface Loopback0このコンフィギュレーションでは、物理インターフェイスに依存せずにコール シグナリングが動作します。 この方法では、一方のインターフェイスに障害が発生しても、他方のインターフェイスでトラフィックを処理できます。 各ゲートウェイ インターフェイスを異なる物理スイッチに接続し、一方のスイッチまたはインターフェイスに障害が発生した場合に冗長性を実現する必要があります。 ゲートウェイ上の各インターフェイスは、異なるサブネット上の IP アドレスを使用して設定されます。 ネットワークの IP ルータは、スタティック ルートまたはルーティング プロトコルによるループバック アドレスへの冗長ルートとして設定されます。 ルーティング プロトコルを使用して、ゲートウェイと交換するルート数を確認する場合、ゲートウェイがループバック アドレスだけをアドバタイジングし、ルートを受信しないようにルーティング アップデートを制限するフィルタの使用を考慮してください。
SIP プロキシ サーバは、SIP エンドポイントの代わりにダイヤル プランの解決法を提供し、ダイヤル プラン情報を各 SIP デバイスにスタティックに設定するのではなく、集中的に設定します。 SIP プロキシ サーバは、Unified CVP ソリューションでは必要ありませんが、集中的に設定およびメンテナンスできるという利点のため、ほとんどのソリューションで使用されます。 複数の SIP プロキシ サーバをネットワークに導入し、ロード バランシング、冗長性、および地域の SIP コール ルーティング サービスを実現できます。 Unified CVP ソリューションでは、SIP コール ルーティングの選択肢は次のとおりです。
(注) |
DNS サーバによる SRV の使用またはサーバ グループの使用によるスタティック ルートの選択により、プライマリの宛先が停止中またはネットワークに接続されていないときに、Unified CVP コール サーバ上での UDP 転送によるフェールオーバーまたはロード バランシング中に予期しない長時間の遅延が引き起こされる可能性があります。 UDP で、ホスト名にサーバ グループ(srv.xml)内で異なるプライオリティを持つ複数の要素がある場合、Unified CVP は、要素ごとに 2 回、各試行間を 500 ミリ秒で試行します。 最初の要素が応答しない場合、次の要素を 1 秒後に試行しようとします。 この遅延は、ロードバランシングに応じて、また T1 タイマーに関する RFC 3261 の第 17.1.1.1 項に準拠して、障害が発生している間、すべてのコールに発生します。 サーバ グループのハートビートがオンになっている場合、要素のステータスに応じて、遅延は 1 回だけ発生するか、まったく発生しない可能性があります。 これは、TCP にも適用されます。 |
Unified CVP ソリューションの各デバイスは、上記の方法を使用して、コールの送信先を決定できます。 SIP ネットワークへの Unified CVP コール サーバ インターフェイスは、Unified CVP SIP サービスを使用します。このサービスについては、Unified CVP SIP サービスの項で説明します。
Unified CVP Release 9.0(1) は、Cisco Unified SIP プロキシ サーバ(CUSP Server)バージョン 1.1.4 で検証されています。 つまり、Unified CVP は、CUSP プロキシ サーバだけをサポートするようになりました。
CVP ソリューションの CUSP プロキシでは、2 つの導入オプションがサポートされています。
この例では、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)
この例では、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)
CVP キューイングとの協議が発生すると、セッションでさらに 4 つの SIP トランザクションが発生し、実質的にコール数が 2 倍になります。
プロキシ サーバにおいて、レコード ルート設定を常にオフにしてシングル ポイント障害を回避し、耐障害性ルーティングを可能にし、プロキシ サーバのパフォーマンスを向上します。 プロキシ サーバでレコード ルート設定を使用すると、CUSP ベースライン マトリクスに示すようにパフォーマンスへの影響が 2 倍になります。また、プロキシが停止した場合、これがコールに対してシングル ポイント障害になるため、ハイアベイラビリティ モデルではなくなります。
CUSP では、レコード ルートはデフォルトでオフです。
(注) |
SIP ハートビートを使用したアップストリーム要素ルーティング CUSP プロキシでは、INVITE または OPTIONS への応答はすべて適切な応答であるため、CUSP は、応答を受信すれば要素ダウンのマークを付けません。 応答が、サーバ グループのフェールオーバー応答コード リストで設定されている場合、CUSP は、グループ内の次の要素にフェールオーバーします。そうでない場合、CUSP は、応答を最終応答としてダウンストリームに送信します。 |
次の各項では、SIP プロキシ サーバと、SIP を使用する Cisco IOS ゲートウェイのコンフィギュレーションについて説明します。 ここでは、コンフィギュレーション オプションの完全なリストを示しているわけではなく、特定のコンフィギュレーション概念にだけ焦点を当てています。
SIP プロキシ サーバは、適切なデバイス(Unified CVP コール サーバ、VoiceXML ゲートウェイ、Cisco Unified Communications Manager クラスタなど)を指すスタティック ルートを使用して設定する必要があります。 SIP プロキシ サーバ コンフィギュレーションでは、ルートのプライオリティを指定できます。 1 つの宛先へのルートが複数ある場合、同じプライオリティを持つ宛先間でロード バランシングするように SIP プロキシを設定するか、または異なるプライオリティを使用して優先順位を付けてコールを送信するように SIP プロキシを設定できます。
プロキシ サーバの障害の影響を軽減するには、RecordRoute ヘッダーに SIP プロキシ サーバからデータ入力されないようにすることを推奨します こうすることにより、着信コールが SIP プロキシを通過するようになりますが、コールが Unified CVP コール サーバ(コール サーバ)に到達すると、シグナリングが発信元デバイスとコール サーバの間で直接交換され、SIP プロキシの障害は、進行中のコールには影響しなくなります。
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 メッセージングおよび SIP ルーティングを処理します。 コール サーバは、発信ダイヤル プランの解決法に SIP プロキシ サーバを使用するように設定できます。または、IP アドレスまたは DNS SRV に基づいてスタティック ルートを使用するように設定できます。 コール サーバは、スタティック ルートに関するコンフィギュレーション情報を共有しません。したがって、スタティック ルートを変更する必要がある場合、各コール サーバの SIP サービスで変更を行う必要があります。 コンフィギュレーション オーバーヘッドを最小限にするために、1 つの SIP プロキシ サーバを使用することを推奨します。
単一の SIP プロキシ サーバだけがコール サーバからの発信コール ルーティングに必要な場合、SIP サービスを設定するときに SIP プロキシ コンフィギュレーションを選択します。 Unified CVP Operations Console Server で、次のように設定します。
[Call Server SIP Service] 設定で、次のように設定します。
コール サーバからの発信冗長性のために複数の SIP プロキシ サーバを使用する場合、DNS 名を使用して SIP プロキシを設定し、SIP プロキシ サーバに到達するために DNS SRV レコードを設定します。 DNS SRV レコードは、外部 DNS サーバ上に存在できます。または、このレコードは、各 CVP Server 上のローカル DNS SRV レコードで設定できます。 OAMP Console で、次のように設定します。
各サーバ上でローカル DNS SRV レコードを設定するには、[SIP service] 設定で、[Resolve SRV records locally] のチェックをオンにします。
進行中のコールがあるコール サーバに障害が発生した場合、特定のゲートウェイ コンフィギュレーション手順を実行済みの場合は、すべてのコールを保持できます。 コール サーバは、次のいずれかが発生した場合に障害が発生する可能性があります。
この項で説明するコンフィギュレーションにより、これらの状況すべてに対して保護されます。 ただし、次の 2 つのシナリオのうちいずれかが発生した場合、リカバリは不可能です。
コール存続可能性を実現するには、次の URL から入手可能な最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』の説明に従って、発信元ゲートウェイを設定します。
survivability.tcl スクリプトには、一部の指示および有用な情報も含まれています。
ほとんどのダウンストリーム障害(コール サーバの障害を含む)の場合、コールは、発信元ゲートウェイによってデフォルトのルートにルーティングされます。 存続可能性は、Unified CVP スタンドアロンおよび NIC ルーティング モデルには適用されないことに注意してください。その理由は、これらのモデルには、Unified CVP SIP サービスがないためです。
Unified CVP が認識せずにクリアされたコールを検出するメカニズムもあります。
CVP SIP サービスは、発信元ゲートウェイなどのエンドポイントが自身でセッション更新を実行できるように、Session Expires ヘッダーをコールに追加できます。 SIP コールでの Session Expires の使用法の詳細については、RFC 4028(『Session Timers in the Session Initiation Protocol』)を参照してください。
次のシナリオの場合、コールは示されているように処理されます。
サーバグループは、SIP INVITE の送信を試行する前に宛先アドレスのステータスを発信元エンドポイントが認識できるようにする、ダイナミック ルーティング機能です。 宛先がネットワークを介して到達不能、またはアプリケーション層でアウトオブサービスの場合、発信元 SIP ユーザ エージェントは、ハートビート メカニズムを介してステータスを認識できます。
サーバ グループ機能は、SIP のエンドポイントとともにハートビート メカニズムを追加します。 この機能を使用すると、障害のあるエンドポイントが原因の遅延をなくすことによって、呼制御のフェールオーバーを高速化できます。
Unified CVP SIP サブシステムは、Release 9.0(1) で使用可能なローカル SRV コンフィギュレーション XML に基づいて作成されています。
サーバ グループは、1 つ以上の宛先アドレス(エンドポイント)で構成され、サーバ グループ ドメイン名で識別されます。 このドメイン名は、SRV クラスタ ドメイン名、または FQDN とも呼ばれます。 SRV メカニズムが使用されますが、レコードの DNS サーバ解決は実行されません。 サーバ グループは、ローカル SRV 実装(srv.xml)と同じままですが、サーバ グループ機能には、その機能に加えてハートビート メカニズムがオプションとして追加されます。
以前のリリースでは、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 間隔もこれに応じて変化することがあるため、事後対応モードでは未確定性が増します。
デフォルトでは、サーバ グループのハートビートは、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 アドレスで検証が渡されます。
サーバ グループを実装する場合、次の設計上の考慮事項を確認してください。
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 の指示を参照してください。
ハイアベイラビリティは、アプリケーション サーバの 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)』を参照してください。
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://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 ゲートウェイは、Unified CVP コール サーバと同じデータセンターにあります。
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 レコードが、ロード バランシングおよび冗長性を提供します。
この設定では、PSTN からの着信コールを処理するゲートウェイは、WAN などの低帯域幅の接続で Unified CVP サーバから分離されます。 VoiceXML ゲートウェイは、入力ゲートウェイと同じです。 この設定は、WAN でメディア ストリームが帯域幅を消費しないようにします。
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」を参照してください。 |
この設定では、PSTN からの着信コールを処理するゲートウェイは、WAN などの低帯域幅の接続で Unified CVP サーバから分離されます。 VoiceXML ゲートウェイは、入力ゲートウェイと異なりますが、同じサイトに置かれます。 設定によって、WAN で帯域幅を消費せずに同じサイトでメディア ストリームが維持され、入力ゲートウェイと VoiceXML ゲートウェイを分離することが適切な場合に、VoiceXML ゲートウェイのサイジングが最適化します。 この場合、コールの IVR レッグを入力ゲートウェイに戻さないため、setTransferLabel および Send to Originator は使用できません。 また、各リモート サイトの ICM で別のネットワーク VRU、ネットワーク VRU ラベル、およびお客様を設定する必要があるため、SIP プロキシを使用してコール ルーティングを制御することもできません。 代わりに、SetSigDigits 機能を使用します。
この方法では、コール サーバが、着信 DNIS 番号から先頭の最上位の数字を除去します。 除去した値は保存され、このコールを後続するときに先頭に付加されます。
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] ウィンドウにあります。
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 を設定します。
先頭に付加された数字を使用して、適切な VoiceXML ゲートウェイに送信されるように SIP プロキシのスタティック ルートを定義します。 Unified CM クラスタのエージェントへの転送では先頭に数字が付加されるため、エージェント電話のスタティック ルートにも付加された数字が含まれている必要があります。
個々のハードウェア コンポーネントには、次のハイアベイラビリティ オプションがあります。
例 1:別個の PSTN ゲートウェイおよび VoiceXML ゲートウェイ
PSTN ゲートウェイおよび別個の VoiceXML ゲートウェイによって、PSTN と VoiceXML が結合されたゲートウェイよりも高いアベイラビリティが実現されます。
地理的な冗長性およびハイアベイラビリティは、サイド A とサイド B で同じハードウェアを購入することにより実現できます。
音声ファイルは、VoiceXML ゲートウェイまたは HTTP/TFTP ファイル サーバ上のフラッシュ メモリにローカルに保存されます。 音声ファイルをローカルに保存する方法は可用性が非常に高くなります。 ただし、HTTP/TFTP ファイル サーバには、音声ファイルの集中管理という利点があります。
(注) |
Unified CVP 9.0 以降は、別のメディア サーバをインストールできません。 メディア サーバは、コール サーバおよび Unified CVP VXML Server と同じ場所に設置する必要があります。 |
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 を使用する場合、バックアップ サーバを設定できます。
メディア サーバに障害が発生した場合、次の状態がコール処理に適用されます。
Cisco Unified Call Studio でスクリプティングしている場合は、ICM スクリプティングとは異なり、メディア ファイルのバック機能はありません。 スクリプトの作成者は、アプリケーションで を選択して、単一のメディア サーバまたはメディア ファームのファームの ACE VIP アドレスを選択することができます。
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 デバイスなしでも実現できます。
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 に障害が発生すると、次の状態がコール処理に適用されます。
(注) |
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)』を参照してください。
VoiceXML ゲートウェイは、ACE デバイスを使用している場合と使用していない場合の両方で、ゲートウェイ コンフィギュレーション パラメータを使用して、ASR/TTS サーバを検索します。 バックアップ サーバは、プライマリ サーバにアクセスできない場合だけ呼び出されます。これは、ロード バランシング メカニズムではありません。 新しい各コールは、プライマリ サーバに接続しようとします。 フェールオーバーが発生すると、バックアップ サーバがコールの間使用されます。次の新しいコールは、プライマリ サーバに接続しようとします。
ホスト名(asr-en-us など)は固定され、変更できません。 変更できるのは、ロケールだけです。 次の例では、プライマリとバックアップの英語の ASR/TTS サーバのセットおよびスペイン語のサーバのセットがあります。 次の URL から入手可能な最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』の指示に従って、ACE(使用する場合)を設定します。
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 サーバに障害が発生すると、次の状態がコール処理に適用されます。
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 プロセスに障害が発生した場合、次の状態がコール処理に適用されます。
Cisco Intelligent Contact Management(ICM)ソフトウェアは、地理的に分散したコンタクトセンター間でマルチチャネル コンタクト(電話による着信および発信コール、Web 共同要求、電子メール メッセージ、およびチャット要求)を企業全体に分散させます。 ICM ソフトウェアは、ルーティング、キューイング、モニタリング、耐障害性等の機能を持つオープン標準ベースのソリューションです。
ハイアベイラビリティを実現するための ICM の設定に関する最新情報については、次の URL から入手可能な最新バージョンの『Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND)』を参照してください。
Cisco ICM には多くのコンポーネントがあり、コール処理は障害が発生したコンポーネントによって異なります。 いくつかの例外はありますが、次の状態がコール処理に適用されます。