Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）リリース 9.0(1)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月27日
章のタイトル： 分散型導入
目次
- 分散型導入
- 新規または変更された章の情報
- 分散型ゲートウェイ
- ブランチにおける入力または出力ゲートウェイ
- ブランチにおける入力または VoiceXML ゲートウェイ
- 共存 Unified CVP VXML Server およびゲートウェイ
- 集中型 Unified CVP VXML を使用してブランチにゲートウェイを展開する場合
- Cisco Unified Communications Manager
- 出力ゲートウェイとしての Unified CM
- 入力ゲートウェイとしての Unified CM
- マルチキャスト Music-on-Hold（MOH）
- 設計上の考慮事項
- 分散型導入でのコール存続可能性
- コール アドミッション制御の考慮事項
- Unified CM コール アドミッション制御
- SIP コール フロー
- RSVP
分散型展開では、入力ゲートウェイは Unified CVP コール サーバとは地理的に分離しています。 この章では、これらのタイプの導入を設計する方法、およびコール存続可能性とコール アドミッション制御を処理する方法について説明します。
新規または変更された章の情報
次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
分散型ゲートウェイ
Unified CVP では、展開モデルに応じて、さまざまなタイプのゲートウェイを使用できます。 この項では、各タイプのゲートウェイについて説明し、分散型展開がそれらのゲートウェイにどのように影響するかを示します。
- ブランチにおける入力または出力ゲートウェイ
- ブランチにおける入力または VoiceXML ゲートウェイ
- 共存 Unified CVP VXML Server およびゲートウェイ
- 集中型 Unified CVP VXML を使用してブランチにゲートウェイを展開する場合
- Cisco Unified Communications Manager
- マルチキャスト Music-on-Hold（MOH）
ブランチにおける入力または出力ゲートウェイ
この展開モデルでは、通常、拠点オフィスに展開した入力ゲートウェイを使用して、発信者にアクセスを提供します。アクセスには、中央番号や非地理的番号ではなく、市内電話番号を使用します。 この機能は、複数の国にまたがる国際展開で特に重要になります。 出力ゲートウェイは、集中型 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 とゲートウェイを共存させます。
集中型 Unified CVP VXML を使用してブランチにゲートウェイを展開する場合
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 つの方法でこの機能の使用を展開できます。
ゲートウェイに Survivable Remote Site Telephony（SRST）が設定されている場合は、後者の方法を使用します。 この方法を使用すると、展開で MOH をローカルに使用でき、WAN リンク上での MOH ストリーミングを避けることができます。
 （注） |
マルチキャスト MOH の使用に関する参照資料 Call Manager Enterprise（CME）で MOH を設定する方法については、次の URL を参照してください。 |
設計上の考慮事項
マルチキャスト 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』を参照してください。
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』を参照してください。
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』を参照してください。