Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)リリース 9.0(1)
分散型導入
分散型導入
発行日;2012/11/27   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

分散型導入

 

分散型展開では、入力ゲートウェイは Unified CVP コール サーバとは地理的に分離しています。 この章では、これらのタイプの導入を設計する方法、およびコール存続可能性とコール アドミッション制御を処理する方法について説明します。

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

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

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

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

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

説明

この章には、SRND の 2012 年 7 月 6 日のバージョンに関する新規トピックはありません。

 

分散型ゲートウェイ

Unified CVP では、展開モデルに応じて、さまざまなタイプのゲートウェイを使用できます。 この項では、各タイプのゲートウェイについて説明し、分散型展開がそれらのゲートウェイにどのように影響するかを示します。

ブランチにおける入力または出力ゲートウェイ

この展開モデルでは、通常、拠点オフィスに展開した入力ゲートウェイを使用して、発信者にアクセスを提供します。アクセスには、中央番号や非地理的番号ではなく、市内電話番号を使用します。 この機能は、複数の国にまたがる国際展開で特に重要になります。 出力ゲートウェイは、集中型 PSTN ブレークアウト用、または分散型 TDM プラットフォームの Unified CVP スイッチング ソリューションへの統合用として、拠点に展開されます。 ゲートウェイを除く他の Unified CVP コンポーネントはすべて中央に展開され、WAN リンクによって各拠点から中央データセンターまでのデータ接続が実現されます。

ブランチにおける入力または VoiceXML ゲートウェイ

拠点で実行される他の音声サービスについて考慮する必要があります。 たとえば、拠点として通常使用されるのは、ACD エージェント電話と非エージェント電話の両方をサポートするリモート Cisco Unified Communications Manager(Unified CM)サイトです。 また、このモデルでは、必然的に、PSTN ゲートウェイが Unified CVP コールの入力用としてだけでなく、そのサイトの標準ユーザ コールの入力/出力用としても使用されます。 VoiceXML ゲートウェイ機能と音声ゲートウェイ機能が同じ拠点の異なるデバイスに存在する環境では、VRU レッグがローカルの VoiceXML リソースに送信されるように、ダイヤル プランに特別な注意を払う必要があります。Unified CVP コール サーバの settransferlabel メカニズムは、共存する VoiceXML ゲートウェイ コンフィギュレーションと音声ゲートウェイ コンフィギュレーションにのみ適用されるためです。

拠点の入力ゲートウェイと VoiceXML ゲートウェイが同じゲートウェイに存在しない場合は、コールが拠点内で処理され、WAN を介して別の VoiceXML ゲートウェイに送信されないようにします。それには、次の 2 つの方法があります。

  • Unified ICM に複数のユーザ(1 つの拠点当たり 1 人)を設定します。 このオプションでは、Unified ICM コンフィギュレーションを利用して、コールを着信番号に基づいて識別します。 着信番号は、ブランチ サイトを表すユーザに関連付けられます。 ネットワーク VRU が必要な場合は、Unified ICM のユーザに関連付けられているネットワーク VRU が選択され、発信者がそのネットワーク VRU に送信されます。 これにより、それぞれに一意のラベルを付けた複数のネットワーク VRU を使用できます。 この方法の欠点は、各ネットワーク VRU が Unified ICM でそれぞれ独自の VRU スクリプトを必要とすることです。 Unified ICM コンフィギュレーションでは、各ネットワーク VRU スクリプトに変更を加えると、かなりの量の作業になります。
  • Unified CVP で SigDigits 機能を使用するように設定します。 Unified CVP の SigDigits 機能を使用すると、SIP プロキシでダイヤル プランを使用して、コールを適切なサイトにルーティングできます。 コールが入力ゲートウェイに到達すると、ゲートウェイはコールを Unified CVP に送信する前にディジットを付加します。 ダイヤル プランでは、付加されるディジットはそのサイトに固有のものです。 コールが Unified CVP に到達すると、Unified CVP は付加されたディジットを削除してからメモリに格納します。結果として、元の DID でコールが到達したことになります。 その後、Unified CVP は、元の DID(Unified ICM の着信番号と一致)を使用して、コールの到達について Unified ICM に通知します。 Unified ICM が Unified CVP にラベルを返して、IVR 処理用に VoiceXML ゲートウェイにコールを転送したり、エージェントの電話にコールを転送したりすることが可能になると、Unified CVP はメモリ内に格納されたディジットを付加してから転送を開始します。 SIP プロキシのダイヤル プランにディジットの付加を設定する際には、特定のディジット文字列が付加されたコールが特定の VoiceXML ゲートウェイまたは出力ゲートウェイに送信されるようにする必要があります。 重要な点として、VoiceXML ゲートウェイがコールを受信すると、ディジットを再び削除するように CVP ブートストラップ サービスが設定され、コールの IVR レッグのセットアップ時に着信 VoiceXML 要求で元の DN が使用されるようになることに留意してください。 また、ディジットはトランスレーション ルート DN の先頭にも付加されることがある点、および出力または受信側コンポーネント(Unified CM など)で元の DN を確認するにはディジットの削除が必要になる場合がある点についても留意してください。 SigDigits という用語は、この機能を表すために使用されます。Unified CVP で機能を有効にして、削除する有効ディジット数を指定するためのコマンドは、SIP の Operations Console では Prepend Digits であるためです。 Unified ICM コンフィギュレーションのオーバーヘッドが最小限に抑えられるため、この方法が推奨されます。必要になるのは、単一のネットワーク VRU と単一セットの VRU スクリプト/Unified ICM ルーティング スクリプトだけです。 そのため、Unified ICM の観点では、すべての Unified CVP Server および VoiceXML ゲートウェイが単一のネットワークワイドの仮想 IVR として機能します。 また、SigDigits 機能を使用すると、マルチクラスタのコール アドミッション制御の問題を解決することもできます (詳細については、コール アドミッション制御の考慮事項を参照してください)。

共存 Unified CVP VXML Server およびゲートウェイ

すべてのゲートウェイとサーバを中央に展開するか、各サイトでそれぞれ独自のセットの Unified CVP VXML Server とゲートウェイを共存させます。

共存させる場合の利点:

  • WAN が停止しても、セルフサービス アプリケーションには影響しません。
  • WAN 帯域幅が不要です。

共存させる場合の欠点:

  • 拠点オフィスをレプリケートして使用する場合、追加の Unified CVP VXML Server が必要になります。
  • アプリケーションを複数の Unified CVP VXML Server に展開する場合、オーバーヘッドが増加します。

集中型 Unified CVP VXML を使用してブランチにゲートウェイを展開する場合

集中型 VoiceXML の利点:

  • 管理とレポート生成が一元化されます。
  • Unified CVP VXML Server の機能を拠点オフィス間で共有できます。

集中型 VoiceXML の欠点:

  • 拠点の存続可能性が制限されます。
  • VoiceXML over HTTP トラフィックを増やすには、WAN 帯域幅のサイズを調整する必要があります。

Cisco Unified Communications Manager

Unified CVP 環境では、Unified CM は入力または出力ゲートウェイとして使用できます。 一般的には、Unified CM は出力ゲートウェイとして使用されます。通常、発信者は PSTN からコールを行い、Unified CVP によってキューイングされた後、エージェントでの処理のために Unified CM にスイッチングされるためです。 発信者が PSTN からではなく、IP 電話からコールを行う場合、Unified CVP の観点では Unified CM は入力ゲートウェイになります。

出力ゲートウェイとしての Unified CM

Unified CVP とともに Unified CM を展開するには、入力 Unified CVP ゲートウェイとエージェント IP 電話間のコールに Unified CM コール アドミッション制御を使用する必要があります。 そのため、Unified CM は、コールの発信元をリモートの入力ゲートウェイではなく集中型 Unified CVP コール サーバであると見なします。

入力ゲートウェイとしての Unified CM

IP 電話が Unified CVP へのコールを開始すると、Unified CM は Unified CVP への入力ゲートウェイとして機能します。 Unified CVP にコールを送信するために SIP トランクが使用されます。 これらのタイプのコール フローの詳細については、Cisco Unified Communications Manager により発生したコールの章を参照してください。

マルチキャスト Music-on-Hold(MOH)

ユニキャスト MOH の代わりとして、Unified CM の補足サービスを利用してマルチキャスト Music-on-Hold を実現できます。 次の 2 つの方法でこの機能の使用を展開できます。

  • Unified CM を使用して、ローカル LAN でのパケットのマルチキャストを行います。
  • ブランチ ゲートウェイを使用して、ローカル LAN でのマルチキャストを行います

ゲートウェイに Survivable Remote Site Telephony(SRST)が設定されている場合は、後者の方法を使用します。 この方法を使用すると、展開で MOH をローカルに使用でき、WAN リンク上での MOH ストリーミングを避けることができます。


(注)  


マルチキャスト MOH の使用に関する参照資料

Call Manager Enterprise(CME)で MOH を設定する方法については、次の URL を参照してください。

http:/​/​www.cisco.com/​en/​US/​docs/​voice_ip_comm/​cucme/​admin/​configuration/​guide/​cmemoh.html#wpmkr1022205


設計上の考慮事項

マルチキャスト MOH を使用する場合は、次の点を考慮してください。

  • モデムをグローバルに設定したり、入力または出力ゲートウェイのダイヤル ピアに設定したりしないでください。
    passthrough nse codec g711ulaw
    このように設定すると、10 ~ 12 秒のタイムアウト期間後、Unified CM によって MOH が停止される可能性があります。
  • 入力ゲートウェイにメディア非アクティビティを設定しないでください。マルチキャスト MOH では RTP も RTCP も送信しないため、メディア非アクティビティのコンフィギュレーションが原因でコールが切断される可能性があります。 メディア非アクティビティ基準の設定では、マルチキャスト トラフィックはサポートされていません。
  • 5400 プラットフォームでは ccm-manager ベースの MOH サブシステムはサポートされていないため、5400 プラットフォームでは SIP ベースのマルチキャスト MOH はサポートされていません。 この制限には、Unified CM MOH サーバからブロードキャストされるマルチキャスト パケットを TDM 発信者が認識する機能も含まれます。

分散型導入でのコール存続可能性

分散型展開では、拠点で実行される他の音声サービスの設計を考慮する必要があります。 たとえば、拠点として通常使用されるのは、ACD エージェント電話と非エージェント電話の両方をサポートするリモート Unified CM サイトです。 また、この導入では、必然的に、PSTN ゲートウェイが Unified CVP コールの入力用としてだけでなく、標準の非 ACD 電話コールの入力または出力用としても使用されます。

WAN の信頼性は通常 LAN リンクより劣るため、拠点の信頼性が集中型 Unified CVP モデルの場合よりも多少問題になります。 したがって、拠点に固有のメカニズムを提供して、中央サイトへの WAN リンクが喪失した場合に影響を受けるコールを適切に処理する必要があります。

Unified コールと非 CVP コールのどちらの場合も、コール存続可能性を考慮する必要があります。 Unified CM エンドポイントの電話の場合、存続可能性は Survivable Remote Site Telephony(SRST)という Cisco IOS 機能を使用して実現されます。 SRST の詳細については、次の URL から入手可能な最新バージョンの『Cisco Unified Communications 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 コールの場合、存続可能性は TCL スクリプト(survivability.tcl)と SRST 機能のサービスの組み合わせによって処理されます。 存続可能性 TCL スクリプトは、リモート ゲートウェイからのすべての入力コールの SIP 接続をモニタするために使用されます。 シグナリング障害が発生した場合、TCL スクリプトはコールを制御し、設定可能な宛先にリダイレクトします。 TCL スクリプトの宛先の選択肢は、Cisco IOS ゲートウェイ コンフィギュレーションでパラメータとして設定します。

この転送の代替の宛先として、別の IP 宛先(リモート サイトの SRST コール エージェントを含む)、*8 TNT、またはフックフラッシュを指定できます。 リモート サイトの SRST コール エージェントに転送する場合、最も一般的なターゲットは SRST エイリアスまたは Basic ACD ハント グループです。 これらの SRST 機能の詳細については、『Cisco Unified Communications SRND based on Cisco Unified Communications Manager』を参照してください。

Voice Mail Server および Recording Server は Real-Time Control Protocol(RTCP)パケットを発信者(TDM 音声ゲートウェイ)に向かって逆方向に送信することはないため、存続可能性スクリプトのメディア非アクティビティ タイマーが間違ってトリガーされることがあります。 survivability.tcl スクリプトをダイヤルピアに慎重に適用することが重要です。これは、ボイスメールまたは録音要素に移動する場合、コールがドロップされる可能性があるためです。 1 つの方法は、ボイスメールまたは録音コールに別個のダイヤルピアを使用し、これらのダイヤルピアには Unified CVP 存続可能性スクリプトを関連付けないことです。 もう 1 つの方法は、ボイスメールまたは録音ダイヤルピアに関連付けられている存続可能性スクリプトでメディア非アクティビティを無効にすることです。

これらの転送方法のコンフィギュレーションおよび適用の詳細については、最新バージョンの『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 から入手できます。

SIP トランクでの CUBE 導入も参照してください。


(注)  


シグナリング障害が発生した場合に代替ルーティングを利用するには、Unified CVP を指し示すすべてのゲートウェイで存続可能性サービスを使用する必要があります。 このサービスの使用を妨げる特定の実装を利用しない限り、必ずこのサービスを使用してください。

Unified CVP 包括コール フローで SIP REFER を使用する場合、ルータ再クエリーはサポートされません。存続可能性サービスが Unified CVP からの REFER メッセージを処理します。 IOS が存続可能性サービスを使用せずに REFER を処理したり、Unified CM が REFER を処理したりする他のコール フローでは、REFER を使用したルータ再クエリーをサポートできます。 サードパーティ製の SIP トランクの場合、REFER を使用したルータ再クエリーのサポートは、SIP REFER 自体の実装とサポートによって異なります。


コール アドミッション制御の考慮事項

Unified CVP だけでなく、ソリューションの観点では、コール アドミッション制御についても考慮する必要があります。 これらの考慮事項は、Unified CM などの他の音声サービスが Unified CVP と同じゲートウェイを共有し、サイト間で帯域幅の量が制限されるような分散型ブランチ オフィス モデルでは最も明白です。 考慮すべき最も重要な項目は、同じコール アドミッション制御メカニズムが、そのサイトから WAN を通過するすべてのコールに使用されるように、どのコール アドミッション制御メカニズムがネットワークに配置されているかです。 2 つのコール アドミッション制御メカニズムがそれぞれ 4 つのコールを許可し、WAN リンクでは 4 つのコールしか処理できない場合、両方のコール アドミッション制御エンティティが WAN への 4 つのコールを同時に許可し、それにより音声品質に影響が生じます。 単一のコール アドミッション メカニズムを実装できない場合は、各コール アドミッション制御メカニズムに帯域幅を割り当てる必要があります。 このような状況は、非効率的な帯域幅のオーバープロビジョニングにつながるため、望ましくありません。

Unified CVP 環境では、2 つのコール アドミッション制御メカニズムを使用できます。それは、Unified CM ロケーションおよび Unified CM RSVP エージェントの 2 つです。 単一サイト展開では、コール アドミッション制御は不要です。

Unified CM では、デバイスを特定のロケーションに割り当てて、それらのロケーション間でアクティブなコールの数を追跡することによって、コール アドミッションを行います。 Unified CM ではアクティブなコールの数と各コールに使用されているコーデックを把握しているため、どれくらいの帯域幅が使用されているかを計算し、許容コール数を制限できます。

コール アドミッション制御メカニズムの概念を十分に理解することが重要です。 これらのメカニズムの詳細については、次の URL から入手可能な『Cisco Unified Communications SRND Based on Cisco Unified Communications Manager』を参照してください。

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

Unified CM コール アドミッション制御

Unified CM が Unified CVP との間でコールを送受信していて、Unified CVP ゲートウェイと IP 電話エージェントがリモート サイトに共存している場合、コール フローを理解して、コール アドミッション制御を正しく設計および制御できるようにすることが重要です。

SIP コール フロー

SIP ベースのコール フローを使用した場合、Cisco Unified CM Release 6.0(およびそれ以前のリリース)は Unified CVP からの着信 SIP INVITE のソース IP アドレスしか確認できません。 この制限によりコール アドミッション制御で問題が発生します。Unified CM は、コールの発信元 Unified CVP の背後にあるゲートウェイを識別できないためです。

コールの発信元デバイスを特定する際に、ソース IP アドレスの先を確認したり、SIP ヘッダー内の情報を検査するには、SIP トランク機能を使用できます。 この拡張機能によって、Unified CVP のリモート ポートではなく、元の送信元 IP アドレスによって SIP トランクを動的に選択できます。 SIP プロファイルおよび設定は、Unified CVP トランクとは異なる送信元トランクで使用できます。

さらに具体的に説明すると、SIP INVITE の Call-Info ヘッダーによって発信元デバイスが次の形式で指定されます。

<sip: IPAddress:port>;purpose=x-c isco-origIP

ここで、IPAddress:port は、発信元デバイスとその SIP シグナリング ポートを示します。

このソース IP SIP トランク選択機能は、コール アドミッション制御の帯域幅モニタリングには影響しません。 Unified CM では、Unified CVP および Unified CM のロケーション コンフィギュレーションを使用して、SIP で帯域幅モニタリングが実行されます。 Unified CM のロケーション サーバでは、コール アドミッション制御の帯域幅情報を操作するために、次のヘッダーが使用されます。

Call-Info: [urn:x-cisco-remotecc:callinfo];x-cisco-loc-id="PKID";x-cisco-loc-name="Loc-NAME"

RSVP

RSVP は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。 RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。 CAC の推奨ソリューションは、Unified CVP および Unified CM のロケーション コンフィギュレーションを採用することです。

RSVP の詳細については、次の URL から入手可能な最新バージョンの『Cisco Unified Communications SRND Based on Cisco Unified Communications Manager』を参照してください。

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