音声とユニファイド コミュニケーション : Cisco Unified Communications Manager Session Management Edition

Cisco Unified Communications Manager Session Management Edition 導入ガイド リリース 8.x

Cisco Unified Communications Manager Session Management Edition 導入ガイド リリース 8.x
発行日;2012/07/25 | 英語版ドキュメント(2011/09/28 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

Cisco Unified Communications Manager Session Management Edition 導入ガイド リリース 8.x

目的

対象読者

はじめに

このマニュアルの範囲

Unified CM Session Management Edition:要約の説明

Unified CM Session Management Edition を導入する状況

Unified CM Session Management Edition クラスタと標準の Unified CM クラスタの相違

Unified CM Session Management Edition のライセンス

Unified CM Session Management Edition クラスタのアーキテクチャの概要

Unified CM Session Management Edition Release 8.5 以降のリリースのトランク機能

単一トランクに対するルート ローカル ルール

ルート リストを使用した複数トランクに対するルート ローカル ルール

すべての Unified CM ノードで実行および複数のトランク宛先 IP アドレスの利点

リーフ Unified CM クラスタのソフトウェア リリースとそれらがクラスタ間トランク タイプに与える影響

SIP のディレイド オファーとアーリー オファー、H.323 の Slow Start と Fast Start

双方向メディア接続が SIP トランク上で確立される前の遅延を低減するための PRACK の使用

Unified CM Release 8.5 以降のリリースでのボイスコールおよびビデオ コールのアーリー オファー サポート(必要に応じて MTP を挿入)

システム全体のトランク設定の選択

システム全体のトランク設定のガイドライン

音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入):使用上のガイドライン

SIP トランク上のエンドツーエンド RSVP と SIP アーリー オファー/ディレイド オファー

H.323 ゲートウェイと H.323/H.225 ゲートキーパー制御トランク

MGCP ゲートウェイ

Unified CM Session Management Edition:コール ルーティング、コール再ルーティング、および原因コード

宛先 UC システムからのコール拒否と原因コード

トランク エンゲージメントとコール再ルーティングに関する注意

[Q.931 接続解除原因コード時のルーティングの中止(Stop Routing on Q.931 Disconnect Cause Code)] サービス パラメータ

Unified CM Session Management Edition クラスタのサイズの決定方法

Unified CM Session Management Edition 導入のコンポーネント

Unified CM Session Management Edition クラスタ

リーフ Unified CM クラスタ

IP ベースのサードパーティ製リーフ UC システム

TDM ベースのサードパーティ製リーフ UC システム

サービス プロバイダー ネットワークへの IP-PSTN および IP トランク

IP-PSTN 接続用のセッション ボーダー コントロール

集中型アプリケーション

Unified CM Session Management Edition がサポートするアプリケーション

リーフ クラスタへの接続が必要なアプリケーション

Unified CM Session Management Edition 導入モデル

単一の Unified CM Session Management Edition クラスタの導入

コール分配

着信コール分配

発信コール分配

単一の Unified CM Session Management Edition クラスタとクラスタオーバー WAN

クラスタオーバー WAN 設計に関する一般的な設計上の考慮事項

クラスタオーバー WAN を使用して導入された Unified CM Session Management Edition クラスタへのリーフ クラスタ トランク接続に関する設計ガイドライン

クラスタオーバー WAN の導入における Unified CM Session Management Edition クラスタ トランクからリーフ UC システムへのコールに関する設計ガイドライン

Unified CM Session Management Edition に対するクラスタオーバー WAN の帯域幅の計算

クラスタ内通信シグナリング帯域幅

データベース帯域幅の計算

Unified CM Session Management Edition クラスタオーバー WAN 帯域幅の計算

分散された複数の Unified CM Session Management Edition クラスタ

長距離接続でのシグナリングおよびメディア遅延

IP Phone が登録された Unified CM Session Management Edition クラスタ

クラスタ間トランクを介した Q.SIG パス置換

Unified CM Session Management Edition での Q.SIG の導入に関する注意事項

Unified CM Session Management Edition SAF CCD の導入

Unified CM Session Management Edition および SAF と集中型コール ルーティング

Unified CM Session Management Edition からまたはそれを通じた SAF CCD ルートのリーフ クラスタへのアドバタイジング

SAF CCD ルートのリーフ クラスタから Unified CM Session Management Edition へのアドバタイジング

Unified CM Session Management Edition および SAF CCD の導入と集中型コール ルーティングに関する運用上の考慮事項

リーフ クラスタによる自身の DN 範囲の Unified CM Session Management Edition からの学習

Unified CM Session Management Edition からリーフ クラスタへの IP ルートが使用できない場合の PSTN へのコールのルーティング

スタティック Unified CM Session Management Edition トランクを通じた非 SAF UC システムへのコール

非 SAF UC システムへのコールに対する PSTN フォールバック

Unified CM Session Management Edition および SAF と分散型コール ルーティング

Unified CM Session Management Edition の導入に推奨されるダイヤル プラン

グローバル番号計画

Unified CM および Unified CM Session Management Edition リーフ クラスタ内の番号操作方法

リーフ システムから Unified CM Session Management Edition へのコールの番号正規化

Unified CM Session Management Edition からリーフ システムへのコールの番号正規化

一般的な番号計画に関する推奨事項

Unified CM Session Management Edition/Unified CM トランク プロトコルおよび + 文字転送

転送されたコールおよび転送情報

転送情報の正規化に関する特別な考慮事項

転送情報および集中型ボイスメール:推奨事項のまとめ

非集中型 PSTN アクセスを持つ集中型テールエンド ホップオフ

Unified CM Session Management Edition の導入のコール アドミッション制御に関する推奨事項

CAC ドメインの Unified CM Session Management Edition Management とロケーション CAC

ロケーション CAC を使用する CAC ドメインを管理するリーフ クラスタ

クラスタ間トランク上のロケーション ベースのコール アドミッション制御

Q.SIG パス置換

RSVP 導入での Unified CM Session Management Edition

RSVP SIP プレコンディション サポートのないリーフ クラスタを使用した Unified CM Session Management Edition の設計

RSVP SIP プレコンディション サポートのあるリーフ クラスタを使用した Unified CM Session Management Edition の設計

混合リーフ クラスタを使用した Unified CM Session Management Edition の設計(RSVP SIP プレコンディション サポートのありとなし)

RSVP Agent のための複数クラスタによる単一プラットフォームの共有

Unified CM Session Management Edition のクラスタ導入におけるトランク セキュリティ

安全な SIP トランク

安全な H.323 トランク

シスコのモバイル ソリューションおよび Unified CM Session Management Edition の導入

標準のリーフ クラスタ モビリティ導入

Unified CM Session Management Edition ベースの PSTN アクセスによるリーフ クラスタ モビリティ導入

モビリティとサードパーティ PBX

Unified CM Session Management Edition を介した PSTN アクセスによる、サードパーティ PBX のモビリティ/シングル ナンバー リーチ サポート

接続されたサードパーティ PBX に対して Unified CM Session Management Edition が提供するモビリティ機能

Unified CM Session Management Edition 上のボイスメール アプリケーション

転送情報および集中型ボイスメール:推奨事項のまとめ

ボイスメールでの RDNIS 送信に関する注意事項

Cisco TelePresence(旧称 Tandberg)VCS の Unified CM Session Management Edition との統合

Cisco Unified Contact Center Enterprise を使用した Unified CM Session Management Edition の導入

Unified CM Session Management Edition におけるトランクツートランクの SIP ヘッダーの透過性

Unified CM Session Management Edition におけるトランクツートランクの SIP メッセージの透過性

サポートされる導入モデル

IPv6 ベースの Unified CM Session Management Edition の導入

IPv6 UC 設計ガイドラインの要約

Unified CM Session Management Edition を使用したクラスタ間のエクステンション モビリティの導入

Cisco Unified Communications Manager Session Management Edition 導入ガイド リリース 8.x

 

このマニュアルの構成は、次のとおりです。

目的

対象読者

はじめに

「このマニュアルの範囲」

「Unified CM Session Management Edition:要約の説明」

「Unified CM Session Management Edition を導入する状況」

「Unified CM Session Management Edition クラスタと標準の Unified CM クラスタの相違」

「Unified CM Session Management Edition のライセンス」

「Unified CM Session Management Edition クラスタのアーキテクチャの概要」

「Unified CM Session Management Edition Release 8.5 以降のリリースのトランク機能」

「単一トランクに対するルート ローカル ルール」

「ルート リストを使用した複数トランクに対するルート ローカル ルール」

「すべての Unified CM ノードで実行および複数のトランク宛先 IP アドレスの利点」

「リーフ Unified CM クラスタのソフトウェア リリースとそれらがクラスタ間トランク タイプに与える影響」

「SIP のディレイド オファーとアーリー オファー、H.323 の Slow Start と Fast Start」

「双方向メディア接続が SIP トランク上で確立される前の遅延を低減するための PRACK の使用」

「Unified CM Release 8.5 以降のリリースでのボイスコールおよびビデオ コールのアーリー オファー サポート(必要に応じて MTP を挿入)」

「システム全体のトランク設定の選択」

「システム全体のトランク設定のガイドライン」

「音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入):使用上のガイドライン」

「SIP トランク上のエンドツーエンド RSVP と SIP アーリー オファー/ディレイド オファー」

「H.323 ゲートウェイと H.323/H.225 ゲートキーパー制御トランク」

「MGCP ゲートウェイ」

「Unified CM Session Management Edition:コール ルーティング、コール再ルーティング、および原因コード」

「宛先 UC システムからのコール拒否と原因コード」

「トランク エンゲージメントとコール再ルーティングに関する注意」

「[Q.931 接続解除原因コード時のルーティングの中止(Stop Routing on Q.931 Disconnect Cause Code)] サービス パラメータ」

「Unified CM Session Management Edition クラスタのサイズの決定方法」

「Unified CM Session Management Edition 導入のコンポーネント」

「Unified CM Session Management Edition クラスタ」

「リーフ Unified CM クラスタ」

「IP ベースのサードパーティ製リーフ UC システム」

「TDM ベースのサードパーティ製リーフ UC システム」

「サービス プロバイダー ネットワークへの IP-PSTN および IP トランク」

「IP-PSTN 接続用のセッション ボーダー コントロール」

「集中型アプリケーション」

「Unified CM Session Management Edition 導入モデル」

「単一の Unified CM Session Management Edition クラスタの導入」

「コール分配」

「着信コール分配」

「発信コール分配」

「単一の Unified CM Session Management Edition クラスタとクラスタオーバー WAN」

「クラスタオーバー WAN 設計に関する一般的な設計上の考慮事項」

「クラスタオーバー WAN を使用して導入された Unified CM Session Management Edition クラスタへのリーフ クラスタ トランク接続に関する設計ガイドライン」

「クラスタオーバー WAN の導入における Unified CM Session Management Edition クラスタ トランクからリーフ UC システムへのコールに関する設計ガイドライン」

「Unified CM Session Management Edition に対するクラスタオーバー WAN の帯域幅の計算」

「クラスタ内通信シグナリング帯域幅」

「データベース帯域幅の計算」

「Unified CM Session Management Edition クラスタオーバー WAN 帯域幅の計算」

「分散された複数の Unified CM Session Management Edition クラスタ」

「長距離接続でのシグナリングおよびメディア遅延」

「IP Phone が登録された Unified CM Session Management Edition クラスタ」

「クラスタ間トランクを介した Q.SIG パス置換」

「Unified CM Session Management Edition での Q.SIG の導入に関する注意事項」

「Unified CM Session Management Edition SAF CCD の導入」

「Unified CM Session Management Edition および SAF と集中型コール ルーティング」

「Unified CM Session Management Edition からまたはそれを通じた SAF CCD ルートのリーフ クラスタへのアドバタイジング」

「SAF CCD ルートのリーフ クラスタから Unified CM Session Management Edition へのアドバタイジング」

「Unified CM Session Management Edition および SAF CCD の導入と集中型コール ルーティングに関する運用上の考慮事項」

「Unified CM Session Management Edition および SAF と分散型コール ルーティング」

「Unified CM Session Management Edition の導入に推奨されるダイヤル プラン」

グローバル番号計画

Unified CM および Unified CM Session Management Edition リーフ クラスタ内の番号操作方法

リーフ システムから Unified CM Session Management Edition へのコールの番号正規化

Unified CM Session Management Edition からリーフ システムへのコールの番号正規化

一般的な番号計画に関する推奨事項

Unified CM Session Management Edition/Unified CM トランク プロトコルおよび + 文字転送

転送されたコールおよび転送情報

非集中型 PSTN アクセスを持つ集中型テールエンド ホップオフ

「Unified CM Session Management Edition の導入のコール アドミッション制御に関する推奨事項」

CAC ドメインの Unified CM Session Management Edition Management とロケーション CAC

ロケーション CAC を使用する CAC ドメインを管理するリーフ クラスタ

RSVP 導入での Unified CM Session Management Edition

RSVP SIP プレコンディション サポートのないリーフ クラスタを使用した Unified CM Session Management Edition の設計

RSVP SIP プレコンディション サポートのあるリーフ クラスタを使用した Unified CM Session Management Edition の設計

混合リーフ クラスタを使用した Unified CM Session Management Edition の設計(RSVP SIP プレコンディション サポートのありとなし)

「Unified CM Session Management Edition のクラスタ導入におけるトランク セキュリティ」

「安全な SIP トランク」

「安全な H.323 トランク」

「シスコのモバイル ソリューションおよび Unified CM Session Management Edition の導入」

「標準のリーフ クラスタ モビリティ導入」

「Unified CM Session Management Edition ベースの PSTN アクセスによるリーフ クラスタ モビリティ導入」

モビリティとサードパーティ PBX

「Unified CM Session Management Edition を介した PSTN アクセスによる、サードパーティ PBX のモビリティ/シングル ナンバー リーチ サポート」

「接続されたサードパーティ PBX に対して Unified CM Session Management Edition が提供するモビリティ機能」

「Unified CM Session Management Edition 上のボイスメール アプリケーション」

転送情報および集中型ボイスメール:推奨事項のまとめ

「ボイスメールでの RDNIS 送信に関する注意事項」

「Cisco TelePresence(旧称 Tandberg)VCS の Unified CM Session Management Edition との統合」

「Cisco Unified Contact Center Enterprise を使用した Unified CM Session Management Edition の導入」

「Unified CM Session Management Edition におけるトランクツートランクの SIP ヘッダーの透過性」

Unified CM Session Management Edition におけるトランクツートランクの SIP メッセージの透過性

サポートされる導入モデル

IPv6 ベースの Unified CM Session Management Edition の導入

IPv6 UC 設計ガイドラインの要約

Unified CM Session Management Edition を使用したクラスタ間のエクステンション モビリティの導入

目的

このマニュアルでは、Cisco Unified Communications Manager Session Management Edition(Unified CM Session Management Edition)とそのコンポーネントの概要を説明します。また、Unified CM Session Management Edition を導入する際の設計上の考慮事項とガイドラインも説明します。

対象読者

このマニュアルは、Unified CM Session Management Edition システムの導入を担当するネットワーク管理者および設計者を対象としています。このマニュアルを使用するには、Unified Communications および IP ネットワーキング テクノロジーに関する知識が必要です。

はじめに

ユニファイド コミュニケーション(UC)ネットワークの規模が拡大し、ますます多くのコール制御システムが企業ネットワークに導入されるにつれ、UC マネージャの多くは、UC コール制御システム間の接続を簡素化するように UC インフラストラクチャを編成することが必要になっています。さらに、サービス プロバイダーが提供する集中型 IP-PSTN サービスの成長や、集中型 UC アプリケーションがもたらす管理上のメリットも、集中型 UC 集約プラットフォームの必要性を高めています。UC システムの集約には H.323 ゲートキーパーや SIP プロキシ サーバなどといった複数の単一プロトコルの集約プラットフォームを使用できますが、お客様の多くはマルチプロトコル UC 環境で運用します。さらに、何十万台もの UC エンドポイントをサポートする UC システムを集約する場合、使いやすく、大規模で複雑なダイヤル プランへの対応も容易な、高性能な番号操作ツールが不可欠です。Unified CM Session Management Edition は、何千ものエンド UC システムに対応可能なマルチプロトコルの UC 集約プラットフォームを提供します。また、Web ベースの GUI を使用して、広範かつ複雑なダイヤル プランと何千もの関連トランクを設定および管理します。

Unified CM Session Management Edition は、基本的には Cisco Unified Communications Manager(Unified CM)クラスタであり、クラスタに接続している大半のデバイスは、回線側の接続ではなく、トランク接続を使用します。Unified CM Release 8.5 では、Unified CM Session Management Edition の導入のために、コール ルーティングの簡素化、相互運用性、および可用性を実現する複数のトランキング機能が導入されました。

このマニュアルの範囲

Unified CM Session Management Edition は、Unified CM と同じソフトウェアを使用します。Unified CM Session Management Edition クラスタと Unified CM クラスタの本質的な違いは、その導入のされ方にあります。通常、Unified CM クラスタでは数千台の電話機がサポートされるのに対し、Unified CM Session Management Edition クラスタでは数千本のトランクがサポートされます。このマニュアルは、Unified CM Session Management Edition ベースで UC を導入する際の新しい設計上の考慮事項およびオプションについて説明する資料であり、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html にある『Cisco Unified Communications System Release 8.x SRND』を補足するマニュアルです。

『Cisco Unified Communications System Release 8.x SRND』には Unified CM Session Management Edition 設計と Unified CM 設計の両方に共通する重要な章および設計上の推奨事項が多く記載されているため、読者は『Cisco Unified Communications System Release 8.x SRND』の内容について熟知している必要があります。Unified CM Session Management Edition クラスタでは一般にエンドポイント(IP 電話)よりもはるかに多い数のトランク接続がサポートされるため、このマニュアルの読者は、少なくとも『Cisco Unified Communications System Release 8.x SRND』の「Unified CM Trunks」の章を一読している必要があります。

Unified CM Session Management Edition:要約の説明

Unified CM Session Management Edition を使用した UC の導入は、マルチサイト分散型コール処理導入モデル( http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1043850 にある『Cisco Unified Communications System Release 8.x SRND』の「Unified Communications Deployment Models」の章を参照)のバリエーションの 1 つです。通常、これらの導入は、1 つのフロントエンド システム(この場合は Unified CM Session Management Edition)を介して多数の UC システムを相互接続するために使用されます。

Unified CM Session Management Edition は、基本的にトランク インターフェイスのみを使用する Unified CM クラスタであり、通常は IP エンドポイントを使用しません。これにより、複数の UC システム(リーフ システムと呼ばれる)の集約が可能になります。

通常、Unified CM Session Management Edition は、複数の Unified CM クラスタ、サードパーティ製 UC システム(IP ベースおよび TDM ベースの PBX)、PSTN 接続、および集中型 UC アプリケーションを相互接続するために使用されます。(図 1 を参照)。

また、Unified CM Session Management Edition の導入は、複数の PBX の導入(およびそれらに付随する電話機)を、IP 電話があり、比較的少数のトランクを持つ Unified CM クラスタに移行する場合にも使用できます。つまり、Unified CM Session Management Edition クラスタは、多数のサードパーティ製 PBX を相互接続している多数のトランクから始め、そこから徐々に何千もの IP 電話を持つ Unified CM クラスタの導入に移行することができます。

Unified CM Session Management Edition では、次のトランク タイプとコール タイプがサポートされます。

H.323 Annex M1 クラスタ間トランク

SIP クラスタ間トランク

SIP トランク

H.323 トランク

MGCP トランク

ボイスコール

ビデオ コール

暗号化されたコール

FAX コール

図 1 Unified CM Session Management Edition を使用したマルチサイト導入

Unified CM Session Management Edition を導入する状況

次のいずれかを行う場合、Unified CM Session Management Edition を導入することを推奨します。

集中型ダイヤル プランの作成および管理

他のすべての UC システムと接続するように各 UC システムを個別のダイヤル プランとトランクで設定する代わりに、Unified CM Session Management Edition では、Unified CM Session Management Edition クラスタを指している簡素化されたダイヤル プランとトランクでリーフ UC システムを設定できます。Unified CM Session Management Edition は、他のすべての UC システムへの集中型ダイヤル プランとそれに対応したトランク ルーティング情報を保持します。

集中型 PSTN アクセスの提供

Unified CM Session Management Edition を使用すると、1 つ(または複数)の集中型 IP-PSTN トランクに PSTN アクセスを集約できます。集中型 PSTN アクセスには一般に、ブランチベースの PSTN 回線の削減または排除を伴います。

アプリケーションの集中化

Unified CM Session Management Edition を導入して、よく使用されるアプリケーション(ボイスメール、音声会議、ビデオ会議など)を Unified CM Session Management Edition クラスタに直接接続します。それにより、リーフ システムの複数のトランクを管理するオーバーヘッドが削減されます。

UC システムに移行するための PBX の集約

レガシー PBX から Unified CM システムへ移行する際に Unified CM Session Management Edition を複数 PBX の集約ポイントとして使用します。

Unified CM Session Management Edition クラスタと標準の Unified CM クラスタの相違

Unified CM Session Management Edition ソフトウェアは、Unified CM ソフトウェアとまったく同じものです。ただし、Cisco Unified CM Release 8.5 以降でなければ、この新しい導入モデルの要件を満たすソフトウェアの拡張が行われていません。Unified CM Session Management Edition クラスタは、多数のトランクツートランク接続をサポートするように設計されているため、次に示す設計上の考慮事項に従う必要があります。

キャパシティ

リーフ UC システム(Unified CM クラスタや PBX など)間で予想される集中型 PSTN 接続や集中型アプリケーションの最繁時呼数(BHCA)トラフィック負荷に基づいて Unified CM Session Management Edition クラスタのサイズを適切に決定することが重要です。使用している UC システムでのユーザの平均的な BHCA およびコール保持時間を判断し、その情報をシスコ アカウント システム エンジニア(SE)またはシスコ パートナーと共有して、Unified CM Session Management Edition クラスタのサイズを適切に決定してください。

トランク

可能な場合は、Unified CM トランク上での静的なメディア ターミネーション ポイント(MTP)の使用は回避します(つまり、リーフ Unified CM または Unified CM Session Management Edition クラスタの SIP または H.323 トランク上で [MTP が必要(MTP required)] を有効にしてはなりません)。[MTP が必要(MTP required)] を使用しないトランクの場合、コーデックの選択の幅が広がり、音声、ビデオ、および暗号化がサポートされ、トランク コールメディアは MTP リソースに固定されません。トランク上には MTP を動的に挿入できます(たとえば、インバンドからアウトオブバンドに DTMF を変換する場合など)。サードパーティ製 UC システムが SIP アーリー オファーを必要とする場合は、Unified CM SIP トランク上で [音声コールとビデオコールに対する早期オファーのサポート(必要な場合は MTP を挿入)(Early Offer support for voice and video calls (insert MTP if needed))] 機能を使用するか、Cisco Unified Border Element 上で [ディレイド オファーからアーリー オファー(Delayed Offer to Early Offer)] 機能を使用します。

Unified CM リリース

Unified CM Session Management Edition クラスタおよびリーフ クラスタには、Unified CM Release 8.6 以降のリリースを推奨します。それよりも前のリリースの Unified CM を Unified CM Session Management Edition クラスタとリーフ Unified CM クラスタの両方に導入することもできますが、クラスタを Unified CM Release 7.1(2) 以降のリリースにアップグレードしないと解決できない問題が発生する可能性があります。

相互運用性

ほとんどのベンダーが標準に準拠していますが、各ベンダーによるプロトコルの実装には相違があります。標準の Unified CM クラスタの場合と同様に、実稼動環境にシステムを導入する前に、未検証のサードパーティ製 UC システムとのエンドツーエンドのシステム相互運用性テストを実施することを強く推奨します。相互運用性テストでは、Unified CM Session Management Edition クラスタを介したシスコおよびサードパーティのリーフ システムからのコール フローと機能を検証します。シスコの相互運用性チームによってテスト済みのサードパーティ製 UC システムの詳細については、www.cisco.com/go/interoperability にアクセスし、[Cisco Unified Communications Manager - Session Management Edition] のリンクを選択してください。

着信コールと発信コールのロード バランシング

Unified CM Session Management Edition クラスタ内のコール処理サブスクライバ間で着信コールと発信コールが均等に分散されるように、Unified CM Session Management Edition システム上とリーフ UC システム上のトランクを設定します。

Unified CM Session Management Edition のライセンス

Unified CM Session Management Edition のライセンスはセッションベースであり、Unified CM Session Management Edition の導入に際して購入する必要があります。Unified CM Session Management Edition の導入に必要なセッション ライセンス数を判断するには、シスコのアカウント チームと協力して、Unified CM Session Management Edition クラスタの適切なサイズを決定します。セッション数は、Unified CM Session Management Edition システムによってサポートされる同時発生コール数になります。

Unified CM Session Management Edition のセッション ライセンスは、ハードウェアとソフトウェアの購入プロセスの一環として、あるいは UC システム アップグレードの一環として購入できます。Unified CM Session Management Edition の初期インストール後は、いつでも追加のセッション ライセンスを購入してインストールできます。

Unified CM Session Management Edition ライセンスの発注方法については、http://www.cisco.com/web/partners/downloads/partner/WWChannels/technology/ipc/downloads/uc_sol_og_ucl_final.pdf にある『Cisco Unified Communications Solutions Ordering Guide』の第 8 章を参照してください。

Unified CM Session Management Edition クラスタのアーキテクチャの概要

エンドポイントがほとんどまたはまったく存在しなければ、Unified CM Session Management Edition は、高度なコールルーティング番号操作機能を備えたマルチプロトコル トランク集約プラットフォームを実質的に提供して、大規模な集中型ダイヤル プランを管理します。Unified CM Session Management Edition クラスタ設計におけるいくつかの重要な側面を以下に示します。

Unified CM Session Management Edition クラスタ内のトランクとサーバの可用性

Unified CM Session Management Edition クラスタ内のノードから発信される発信トランク コールのロード シェアリング

トランク宛先アドレスへのトランク上の発信コールのロード シェアリング

Unified CM Session Management Edition クラスタ内のコール処理ノードに対する着信トランク コールの均等分配

これらの各種トランク機能を設定する方法および設定する状況については、リーフ Unified CM クラスタと Unified CM Session Management Edition クラスタで実行する Unified CM ソフトウェアのリリースに大きく左右されます。図 2 に、リリース 8.5 以降のソフトウェアを実行している Unified CM と Unified CM Session Management Edition、それに Cisco Unified Border Element も経由する、着信コールおよび発信コールのための一般的なトランク設定を示します。次の項では、UC ソフトウェアのリリースに基づいたロード バランシング、トランク プロトコル、および機能について説明します。

図 2 UC ソフトウェア リリース 8.5 を使用した一般的なトランクの導入

Unified CM Session Management Edition Release 8.5 以降のリリースのトランク機能

Unified CM Session Management Edition の導入のほとんどは新規のクラスタ インストールであるため、最新のリリースの Unified CM を使用することを推奨します。Unified CM Release 8.5 では、ロード バランシングとコール分配を改善する複数のトランク機能が導入されました。

SIP トランク、SIP クラスタ間トランク、および H.323 非ゲートキーパー制御クラスタ間トランクの場合、[すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能および最大 16 個の宛先アドレスのサポートにより、ロード バランシングとコール分配が改善されます。また、[すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能では、ルート グループと複数トランクで使用されるルート リストに対してもロード バランシングとコール分配が改善されます。

トランク(および該当する場合はルート リスト)に対する [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能では、ルート ローカル ルールと連携することにより、Unified CM クラスタと Unified CM Session Management Edition クラスタから発信されるコールに対して確定的なノード選択を利用できます。これらの機能およびその動作の詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/trunks.html にある『Cisco Unified Communications System Release 8.x SRND』の「Unified CM Trunks」の章を参照してください。

SIP トランク、SIP クラスタ間トランク、および H.323 非ゲートキーパー制御クラスタ間トランクでは、複数のクラスタ間トランクを用意しなくてもすむように最大 16 個の宛先アドレスを使用することができ、設定された宛先アドレスに対するコール分配も可能です。


) H.323 クラスタ間トランク(ICT)では、ラウンドロビン方式でコールが宛先 IP アドレスに分配されます。SIP トランクと SIP ICT では、コールがランダムに宛先 IP アドレスに分配されます。


図 3 Unified CM Release 8.5 以降:単一トランク(ルート リストなし)を使用し、すべての Unified CM ノードで実行および複数の宛先 IP アドレスが併用された場合のルート ローカル ルール

単一トランクに対するルート ローカル ルール

ルート ローカル ルールは、トランクに対して有効にされた [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能と連携して動作し、着信コールが到着するのと同じノードから発信トランク コールが発信されるようにします。

図 4 Unified CM Release 8.5 以降:複数のトランクとルート リストを使用し、すべての Unified CM ノードで実行および複数の宛先 IP アドレスが併用された場合のルート ローカル ルール

ルート リストを使用した複数トランクに対するルート ローカル ルール

ルート ローカル ルールは、ルート リストとトランクに対して有効にされた [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能と連携して動作し、着信コールが到着するのと同じノードから発信トランク コールが発信されるようにします。

すべての Unified CM ノードで実行および複数のトランク宛先 IP アドレスの利点

[すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能、トランクごとに複数の宛先 IP アドレス、およびルート ローカル ルールを併用することにより、Unified CM クラスタ、Unified CM Session Management Edition クラスタ、およびその他の UC システムとの間のコール分配が大幅に簡素化されます。これらの機能を使用する Unified CM クラスタまたは Unified CM Session Management Edition クラスタの場合、着信コールが到着するノードを使用して、発信トランク コールが確立されます。クラスタ間トランクに複数の宛先アドレスを使用すると(または IOS で複数のダイヤル ピアを使用することにより)、コールをクラスタ内のすべてのノードに均等に分配することが可能になり、必要なクラスタ間トランクの本数が削減されます。

リーフ Unified CM クラスタのソフトウェア リリースとそれらがクラスタ間トランク タイプに与える影響

Unified CM Release 8.5 以降のリリースを使用した場合、SIP トランクは、H.323 Annex M1 クラスタ間トランク(ICT)と同等の機能を備えるとともに、さまざまな追加のトランク機能も提供します。SIP と H.323 の ICT 機能の詳細な比較については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/trunks.html にある『Cisco Unified Communications System Release 8.x SRND』の「Unified CM Trunks」の章の始めを参照してください。

Unified CM Release 8.5 以降のリリースに含まれる主要な SIP トランク機能の一部を以下に示します。

すべての Unified CM ノード上で実行可能な SIP トランク*

トランクごとに最大 16 個の宛先 IP アドレスをサポート*

SIP OPTIONS ping キープアライブ

ボイスコールとビデオ コールに対する SIP アーリー オファー サポート(必要に応じて MTP を挿入)

SIP 上での Q.SIG**

SIP トランクの正規化および透過性

すべての Unified CM ノード上で実行可能なルート リスト*

*Unified CM Release 8.5 以降の H.323 非ゲートキーパー制御 ICT でもサポートされています。

**H.323 非ゲートキーパー制御 ICT でも Annex M1 を使用して Q.SIG がサポートされます。

リーフ Unified CM クラスタと Unified CM Session Management Edition クラスタの両方で Unified CM Release 8.5 以降のリリースがサポートされる導入では、追加機能をサポートするために、SIP トランクの使用を推奨します。(特に SIP OPTIONS ping をサポートするために推奨されます。この機能により、H.323 トランクで使用されるコール単位のタイムアウト トランク宛先障害検出メカニズムの制限が克服されます。SIP OPTIONS ping は、アウトオブダイアログ SIP OPTIONS ping 要求をすべてのトランク宛先 IP アドレスに送信して、トランク宛先の到達可能性を動的に追跡します)。

リーフ Unified CM クラスタまたは Unified CM Session Management Edition クラスタで Release 8.5 よりも前の Unified CM リリースがサポートされる導入では、H.323 ICT が SIP ICT よりも豊富な機能をサポートしているため、H.323 Annex M1 トランクの使用を推奨します。(詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/trunks.html にある『Cisco Unified Communications Solution Reference Network Design (SRND) Based on Cisco Unified Communications Manager Release 7.x』の「Unified CM Trunks」の章を参照してください)。

Release 8.5 よりも前の Unified CM リリースでは、H.323 ベースの ICT によって提供される重要な利点として、H.323 Annex M1 を使用したパス置換やコール バックなどの Q.SIG 機能のサポートがあります。SIP トランクでは単一の宛先 IP アドレスしかサポートされないのに対し、H.323 ICT ではトランクごとに最大 3 個の宛先 IP アドレスがサポートされるので、トランクの分配が改善され、必要なトランクの本数が削減されます。

SIP のディレイド オファーとアーリー オファー、H.323 の Slow Start と Fast Start

Unified CM Session Management Edition の導入で SIP トランクまたは H.323 トランクを使用する場合、それぞれのトランク プロトコル タイプで 2 つのオプションのうち 1 つを選択する必要があります。

SIP ディレイド オファーまたは SIP アーリー オファー

H.323 Slow Start または H.323 Fast Start

SIP ディレイド オファー トランク設定と H.323 Slow Start トランク設定は、静的な MTP を使用しませんが、双方向メディアが確立される前に追加のメッセージ交換が必要になる場合があります。

H.323 Fast Start トランク、およびアーリー オファーに [MTP が必要(MTP Required)] を使用する SIP トランクは、すべての発信コールに対して MTP を使用します。これらの静的な MTP により、単一コーデックの制限がトランク コールに課せられ、トランク上のコールは単一のコーデック タイプ(G711 や G729 など)を使用したボイスコールのみに制限されます。通常、H.323 Slow Start トランクや SIP ディレイド オファー トランクと比べ、H.323 Fast Start トランクや SIP アーリー オファー トランクでは双方向メディアの確立前に交換されるメッセージの数は少なくなります。

これらのトランク特性は、UC 導入のメディア要件に基づいたトランク設定の選択に影響します。一般的なガイドラインは次のとおりです。

クラスタ間でボイスコール、ビデオ コール、または暗号化されたコールを必要とする場合は、すべての発信コールに対する静的な MTP の使用を回避するために、SIP ディレイド オファー トランクまたは H.323 Slow Start トランクの使用を推奨します。

通常は問題になりませんが、エンドポイント間の長時間のシグナリング遅延が原因でコールの開始時にメディア クリッピングが発生する場合は、SIP アーリー オファーまたは H.323 Fast Start を使用することで、双方向メディアが確立される前の遅延を低減できます。ただし、H.323 Fast Start トランク、またはアーリー オファーに [MTP が必要(MTP Required)] を使用する SIP トランクを使用すると、これらのトランク タイプが使用する MTP に関連した単一コーデックの制限により、コールが音声のみに制限されることに注意してください。

一部の UC アプリケーション(IVR など)は、コール セットアップ時にできるだけ早く一方向のメディア接続を確立しようとします。この IVR から発信者へのメディア接続は、メディア特性(IP アドレス、UDP ポート、サポートされるコーデックなど)が IVR に送信されるとすぐに確立されます。SIP アーリー オファー コールの場合、発信者のメディア特性は、初期の SIP INVITE とともに送信されます。それにより、IVR はメディア接続をすぐに確立することができます。SIP ディレイド オファーでは、IVR から発信者へのメディア接続をセットアップできるようになるまでに、一般に 5 つの SIP メッセージの交換が必要です。H.323 の場合も同様になります。H.323 Fast Start では、最初のメッセージが送信されてからほぼすぐ後にメディアを確立できるようになります。それに対して H.323 Slow Start では、メディア接続を確立できるようになるまでに、さらに多くのメッセージの交換を必要とします。発信者と IVR の間で長時間のシグナリング遅延が発生する場合は、SIP アーリー オファーや H.323 Fast Start を使用することで、IVR からの一方向メディア接続がより迅速に確立されます。

図 5 SIP アーリー オファー コール

双方向メディア接続が SIP トランク上で確立される前の遅延を低減するための PRACK の使用

SIP では、最終応答と暫定応答の 2 種類の応答が規定されています。最終応答は、処理された要求の結果を伝達するとともに、信頼性のある方法で送信されます(確認応答される)。暫定応答は、要求の進行に関する情報を伝えますが、信頼性のある方法では送信されません。つまり、暫定応答の送信者は、その応答が受信されたかどうかはわかりません。SIP コール セットアップ時のメディア ネゴシエーション用のオファーおよびアンサーの交換は、信頼性のある方法で送信される必要があります。SIP 1XX 応答は暫定応答であり(信頼性がない)、標準 SIP コール用です。したがって、コール セットアップ時にこれらの応答でオファーまたはアンサーのセッション記述プロトコル(SDP)本文を送信することはできません。図 6 からわかるように、100 Trying メッセージまたは 180 Ringing メッセージで SIP オファーまたはアンサーを送信できれば、双方向メディアが確立される前に交換しなければならない SIP メッセージの数を削減できます。

図 6 PRACK なしの SIP ディレイド オファー コール

暫定 1XX 応答でオファーまたはアンサーを送信するには、これらの応答が信頼性のある方法で送信される必要があります。暫定確認(PRACK)を使用して、信頼性のある 1XX 応答を実現します。

図 7 PRACK を使用して SIP オファーを 183 応答で送信する SIP ディレイド オファー コール

PRACK(アーリー メディアとも呼ばれる)の使用は、SIP アーリー オファーとディレイド オファーの両方の Unified CM トランクで有効にできます。アーリー メディアのカットスルーをサポートする SIP トランクの場合、トランクに関連付けられている SIP プロファイルの [SIP Rel1XX オプション(SIP Rel1XX Options)] 機能で、PRACK を有効にする必要があります。


) 一部の UC システムでは PRACK はサポートされていません。


図 8 PRACK を使用して SIP アンサーを 183 応答で送信する SIP アーリー オファー コール

Unified CM Release 8.5 以降のリリースでのボイスコールおよびビデオ コールのアーリー オファー サポート(必要に応じて MTP を挿入)

リーフ Unified CM クラスタのソフトウェア リリースとそれらがクラスタ間トランク タイプに与える影響で説明したように、Unified CM Release 8.5(およびそれ以降のリリース)を使用する場合は、H.323 Annex M1 クラスタ間トランクと同等の機能を備え、さまざまな追加のトランク機能も提供する SIP トランクの使用が推奨されます。

Unified CM Release 8.5 で導入される SIP トランク機能に、[音声コールとビデオコールに対する早期オファーのサポート(必要な場合は MTP を挿入)(Early Offer support for voice and video calls (insert MTP if needed))] があります。この機能は、MTP の使用を削減するとともに、MTP がコール フローに挿入される場合には、MTP が必要なアーリー オファーの単一音声コーデックの制限を克服するように設計されています。

Unified CM は、次のいずれかの手段で着信コールを受信する場合は、SIP トランク上で発信アーリー オファー コールを作成するために MTP を挿入する必要はありません。

アーリー オファーを使用する SIP トランク上

Fast Start を使用する H.323 トランク上

MGCP トランク上

Unified CM に登録されている SIP ベースの IP 電話から

Unified CM に登録されている新しい SCCP ベースの Cisco Unified IP Phone モデルから(詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/endpnts.html#wp1045087 にある『Cisco Unified Communications System Release 8.x SRND』の「Unified Communications Endpoints」の章内の「Endpoint Features Summary」を参照してください)。

上記のデバイスの場合、Unified CM はエンドポイントのメディア機能を使用して、発信デバイスと発信 SIP トランクのリージョンペアに基づいてコーデック フィルタリング ルールを適用し、発信 SIP トランクのオファー SDP を作成します。ほとんどの場合、オファー SDP には、コールを開始したエンドポイントの IP アドレスとポート番号が含まれます。前の説明では、前提として、発信デバイスと SIP トランクのリージョン間に共通のコーデックがない場合でも、DTMF の不一致、TRP 要件、トランスコーダ要件などの他の理由から Unified CM が MTP を挿入することが必要になることはないとしています。

トランクの SIP プロファイルに [音声コールとビデオコールに対する早期オファーのサポート(必要な場合は MTP を挿入)(Early Offer support for voice and video calls (insert MTP if needed))] を設定した場合、古い SCCP ベースの電話機、SIP ディレイド オファー トランク、および H.323 Slow Start トランクからのコールは、すでに別の理由で MTP またはトランスコーダが割り当てられていなければ、Unified CM によって MTP が割り当てられます。この MTP を使用して、有効なメディア ポート番号と IP アドレスを含むオファー SDP が生成されます。この MTP は、発信 SIP トランクのメディア リソースからではなく、発信デバイスに関連付けられているメディア リソースから割り当てられます。(したがって、メディア パスは、発信 SIP トランクの MTP に固定されません)。MTP を発信デバイスのメディア リソース グループ リスト(MRGL)から割り当てできない場合は、MTP の割り当てを SIP トランクの MRGL から試みます。

Unified CM に登録された古い SCCP ベースの電話機からのコールの場合、発信デバイスの一部のメディア機能(サポートされる音声コーデック、ビデオ コーデック、暗号キー(サポートされている場合)など)を SDP によるメディア交換に使用できます。(これらの電話機のリストについては、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html にある『Cisco Unified Communications System Release 8.x SRND』の「Unified Communications Endpoints」の章内の「Endpoint Features Summary」を参照してください)。Unified CM は、エンドポイントと MTP コーデックの機能のスーパーセットを作成し、該当するリージョンペアの設定に基づいてコーデック フィルタリングを適用します。発信オファー SDP は、MTP の IP アドレスとポート番号を使用します。また、音声メディア、ビデオ メディア、および暗号化されたメディアをサポートできます。パススルー コーデックをサポートするには、IOS MTP を設定する必要があります。

Unified CM が H.323 Slow Start または SIP ディレイド オファー トランクで着信コールを受信する場合、コールの開始時に発信デバイスのメディア機能を使用できません。この場合、Unified CM は、MTP を挿入し、その IP アドレスと UDP ポート番号を使用して、(リージョンペアのフィルタリング後の)サポートされるすべてのオーディオ コーデックを、発信 SIP トランク上で送信される初期 INVITE のオファー SDP でアドバタイズする必要があります。アンサー SDP が SIP トランク上で受信される場合、その SDP に発信エンドポイントでサポートされるコーデックが含まれていれば、追加のオファー/アンサー トランザクションは不要です。コーデックが一致しない場合、Unified CM は、トランスコーダを挿入してその不一致に対処するか、Re-INVITE または UPDATE を送信してメディア ネゴシエーションをトリガーできます。H.323 Slow Start トランクまたは SIP ディレイド オファー トランクからのコールは、初期コール セットアップ時に音声のみをサポートしますが、コール メディアが再ネゴシエートされれば(保留/再開後など)、ビデオと SRTP をサポートするようにコール中にアップグレードされる可能性があります。

システム全体のトランク設定の選択

大規模な Unified CM Session Management Edition の導入には、リーフ Unified CM システムに接続されたトランク、IP PBX、TDM ベースの PBX に接続された IOS ゲートウェイへの IP トランク、PSTN 接続、および UC アプリケーションが数百から数千規模で使用されます。

多くの場合、Unified CM Session Management Edition に接続する UC システムでは、Unified CM Session Management Edition(Unified CM Release 8.5 以降のリリース)へのトランク上で使用されるプロトコルの選択は事前に決定されます。次に例を示します。

現在の IP-PSTN サービスは SIP ベースにする傾向があります。

Unified CM Release 8.5 以降のリリースを実行するリーフ Unified CM クラスタの場合、SIP トランクの使用を推奨します。

Release 8.5 よりも前の Unified CM リリースを実行するリーフ Unified CM クラスタの場合、H.323 非ゲートキーパー制御クラスタ間トランクの使用を推奨します。

現在の IP PBX は SIP トランクを使用する傾向があります。

IOS ゲートウェイは、H.323、MGCP、または SIP をトランク プロトコルとして使用できます。Unified CM Release 8.5 以降のリリースを使用する Unified CM Session Management Edition クラスタでは、SIP トランクの使用を推奨します。

リーフ UC システムから Unified CM Session Management Edition へのトランク プロトコルが決定した後、SIP トランクと H.323 トランクに対して、追加の設定を選択する必要があります。具体的には、次の選択を行います。

H.323 Slow Start または H.323 Fast Start

SIP ディレイド オファーまたは SIP アーリー オファー

これらの設定オプションのそれぞれの利点および欠点については、 SIP のディレイド オファーとアーリー オファー、H.323 の Slow Start と Fast Startで説明しました。

この Unified CM/Unified CM Session Management Edition のトランク設定は、発信コールにのみ影響します。着信コールの場合、Unified CM/Unified CM Session Management Edition は、SIP アーリー オファーとディレイド オファー(または H.323 Slow Start と Fast Start)のコールを同じトランク上で受け入れ可能です。したがって、SIP アーリー オファーまたは H.323 Fast Start を設定する必要があるかどうかは、Unified CM Session Management Edition の接続先となる UC システムによって決定されます。


) MTP が必要なトランク コールの場合、MTP の割り当てに失敗すると(MTP リソースが不足している場合など)、クラスタ全体のデフォルトの動作で MTP なしのコールが進行します。つまり、SIP アーリー オファー トランクの場合、MTP の割り当てに失敗すると、ディレイド オファーが送信されます。この動作を設定するには、Unified CM サービス パラメータ [MTP の割り当てに失敗したらコールを失敗(Fail Call if MTP Allocation Fails)] を使用します。デフォルト値は [いいえ(False)] です。


システム全体のトランク設定のガイドライン

Unified CM Session Management Edition を使用して複数の UC システムを相互接続する場合、SIP ディレイド オファー トランクまたは H.323 Slow Start トランクの使用を推奨します。SIP ディレイド オファー トランクと H.323 Slow Start トランクでは、クラスタ間のボイスコール、ビデオ コール、および暗号化されたコールがサポートされます。これらのトランク タイプでは、すべての発信コール対する静的な MTP の使用は行われません(静的な MTP ではコールが(単一コーデックの)ボイスコールのみに制限されます)。

H.323 Fast Start の受信が必要な H.323 ベースのリーフ UC システムは(単一コーデックの)ボイスコールのみに制限され、Unified CM Session Management Edition はすべての発信コールに MTP を使用します。

SIP アーリー オファーの受信が必要な SIP ベースのリーフ UC システムの場合、Unified CM Release 8.5 以降のリリースでは、次の 2 つのオプションを使用できます。

[MTP が必要(MTP Required)] を有効にした SIP アーリー オファー

音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))

[MTP が必要(MTP Required)] を有効にした SIP アーリー オファー トランクには、H.323 Fast Start リーフ UC システムと同じ制限があります。つまり、コールは(単一コーデックの)ボイスコールのみに制限され、Unified CM Session Management Edition はすべての発信コールに MTP を使用します。

音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入):使用上のガイドライン

[音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))] を使用すると、MTP の使用を削減できるとともに、ボイスコール、ビデオ コール、および暗号化されたコールを実行できるようになります。ただし、このトランク タイプ上での発信コールの機能は、着信コールの特性によって決定されることに注意してください。(Unified CM クラスタの場合、着信コールは一般に電話機から発信されます。Unified CM Session Management Edition クラスタの場合、着信コールはトランク上で受信されます)。

[音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))] 機能を使用する SIP トランクを単一の Unified CM クラスタで導入した場合、このアーリー オファー トランク タイプに対する登録された電話機からのコールで、音声、ビデオ、および暗号化がサポートされます。ただし、古い SCCP ベースの電話機では、この SIP トランク上でコールを行う際に MTP が常に使用されます。

Unified CM Session Management Edition 設計の場合、アーリー オファーが必要ならば、[MTP が必要(MTP Required)] を有効にしたアーリー オファーではなく、[音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))] を使用することを推奨します。それにより、MTP の使用を削減できます。ただし、Unified CM Session Management Edition 上の SIP ディレイド オファー トランクまたは H.323 Slow Start トランクを、[音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))] を使用する SIP アーリー オファー トランクと組み合わせると、MTP 使用の削減メリットが得られるかどうかわからない状況になる可能性があることに注意してください。つまり、H.323 Slow Start トランクまたは SIP ディレイド オファー トランクから SIP アーリー オファー トランクへのコールは、初期コール セットアップの状態では MTP を使用し、音声のみをサポートしますが、コール メディアが再ネゴシエートされれば(保留/再開後など)、ビデオと SRTP をサポートするようにコール中にアップグレードされる可能性があります。

そのような状況の例として、Unified CM Release 8.5 よりも前の UC リリースを実行するリーフ Unified CM クラスタが 1 つ以上含まれる Unified CM Session Management Edition 設計があります。この状況でクラスタ間のボイスコール、ビデオ コール、および暗号化されたコールが必要な場合は、Unified CM クラスタと Unified CM Session Management Edition の間に H.323 Slow Start トランクを使用します。Unified CM Session Management Edition クラスタに、SIP アーリー オファーの受信が必要な IP-PSTN サービスへの SIP トランクも存在する場合は、IP-PSTN に向かう SIP トランク上で [音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))] を使用できます。この場合、H.323 Slow Start トランクから SIP IP-PSTN へのすべてのコールに MTP が使用されます。

他にも好ましい方法として、Cisco Unified Border Element セッション ボーダー コントローラ(SBC)が企業/サービス プロバイダーの境界ポイントとして導入される場合は、IP-PSTN への Unified CM Session Management Edition トランク上で [SIP ディレイド オファー(SIP Delayed Offer)] を設定でき、Cisco Unified Border Element の [ディレイド オファーからアーリー オファー(Delayed Offer to Early Offer)] 機能を使用して、Unified CM Session Management Edition からのディレイド オファーを IP-PSTN へのアーリー オファーに変換できます。

Cisco Unified Border Element の [ディレイド オファーからアーリー オファー(Delayed Offer to Early Offer)] 機能は、多数(数千)の同時 IP-PSTN コールをサポートする導入において特に役立つ可能性があります。たとえば、アグリゲーション サービス ルータ(ASR)シリーズなどの Cisco Unified Border Element プラットフォームは、最大で 15,000 の同時発生コールをサポートできます。大量の同時発生コールをサポートする必要がある場合、すべての発信コールに MTP を使用する必要性がなくなれば、大幅にコストを節約できます。

図 9 Unified CM Session Management Edition 設計:クラスタが Unified CM Release 8.5 より前およびそれ以降のリリースを使用する場合のトランク設定

図 10 Unified CM Session Management Edition 設計:すべてのクラスタが Unified CM Release 8.5 以降を使用する場合のトランク設定

SIP トランク上のエンドツーエンド RSVP と SIP アーリー オファー/ディレイド オファー

[SIP トランク上のエンドツーエンド RSVP(End-to-End RSVP over SIP Trunks)] がトランクの SIP プロファイル内で有効にされると、Unified CM は、すべての発信コールに SIP アーリー オファーを送信します。エンドツーエンド RSVP、[MTP が必要(MTP Required)]、および [音声とビデオに対する SIP アーリー オファー(必要に応じて MTP を挿入)(SIP Early Offer for voice and video (insert MTP if needed))] は、相互に排他的な設定です。これらの設定オプションのうちの 1 つのみを SIP トランク上で有効にできます。

H.323 ゲートウェイと H.323/H.225 ゲートキーパー制御トランク

H.323 非ゲートキーパー制御クラスタ間トランクを除いた Unified CM 上のすべての H.323 トランクと H.323 ゲートウェイは、Unified CM Release 8.5 で導入された [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能をサポートしません。これらのトランクとゲートウェイでは Unified CM グループが引き続き使用され、トランクごとにクラスタ内の最大 3 台のノードからしかコールを発信できません。発信コールを 4 台以上のノードに分配する必要がある場合は、ルート リストとルート グループ内で複数のトランクを使用します。さらに、ルート ローカル ルールがルート リストとルート グループ内のこれらのトランクおよびゲートウェイに適用されることにも注意してください。Release 8.5 以降のリリースを使用する Unified CM クラスタの場合、すべてのルート リストに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を使用します。Release 8.5 よりも前のリリースを使用する Unified CM クラスタの場合は(ルート リストは自身の Unified CM グループ内のプライマリ ノード上でのみアクティブになる)、ルート リストの Unified CM グループ内のノードのうち、そのルート リストに関連付けられているトランクからも使用されるノードを選択してはなりません(ルート ローカル ルールにより、すべてのコールが、トランクとルート リストによって共有されるノードからしか発信されなくなるため)。

Unified CM Session Management Edition 設計に多数の H.323 ゲートウェイと H.323/H.225 ゲートキーパー制御トランクが必要な場合、または比較的少数のそれらのトランク上で大量のコールが予測される場合は、クラスタ内のノードに発信コールと着信コールを均等に分配するようにします。

MGCP ゲートウェイ

MGCP は、一般に IOS ゲートウェイと Unified CM クラスタを相互接続するために使用されます。MGCP ゲートウェイがよく使用される主な理由に、IOS ゲートウェイで必要な設定がわずかであるという点があります。(つまり、Q.931 シグナリング チャネルが Unified CM にバックホールされるため、ダイヤル ピアを設定する必要がありません)。Unified CM Release 8.5(およびそれ以降のリリース)では、SIP ベースのゲートウェイにより、Unified CM/Unified CM Session Management Edition に接続する際に SIP を優先プロトコルにする一連の機能強化が提供されています。MGCP を使用する場合は、コール シグナリングがクラスタ内の単一ノード(Q.931 シグナリング チャネルを終端するプライマリ Unified CM グループ ノード)上で発信および終端されることに注意してください。Unified CM Session Management Edition 設計で多数の MGCP ゲートウェイを導入する場合は、クラスタ内のすべてのノードにゲートウェイとコール シグナリングを均等に分配するようにします。

図 11 プロトコルごとの IOS ゲートウェイ機能

Unified CM Session Management Edition:コール ルーティング、コール再ルーティング、および原因コード

Unified CM Session Management Edition は、着信コールを受信すると、自身に設定されているダイヤル プランを使用して、そのコールを発信トランク経由でルーティングしようとします。Unified CM Session Management Edition がそのコールをダイヤルされた宛先にルーティングできない場合、Unified CM Session Management Edition または発信元の UC システムはそのコールを再ルーティングできます。

Unified CM Session Management Edition と Unified CM は、ルート リストとルート グループ内の複数のトランクを使用して、代替メディア パス経由でコールを再ルーティングします。

コールがルート リストとルート グループ内の代替トランクに再ルーティングされる原因となるイベントは複数存在します。次の例を参考にしてください。

トランクがアウト オブ サービスとしてマークされている(OPTIONS ping を使用する SIP トランク)。

試行されたコールに対してトランク接続(TCP/TLS)を確立できない。

複数回のコール試行後にトランク接続がタイムアウトする。

コールがこのトランクに進むことができないことを示す SIP 応答、H.323 メッセージ、または Q.931 原因コードの受信。

コール アドミッション制御の帯域幅の不足。

宛先 UC システムからのコール拒否と原因コード

宛先 UC システムへのコールを進行できない場合、通常、コール先のシステムからコール拒否の原因を示す応答が相手の UC システムに返されます。コールの失敗原因を示すために使用される方法は、プロトコルによって異なります。Unified CM は、SIP、H.323、および MGCP の各トランク上で受信するこの種のコール プログレス メッセージをそれらに対応する PSTN Q.931/Q.850 原因コードに変換し、コールを進行する方法を決定します。

各種原因コードの受信時の Unified CM/Unified CM Session Management Edition のデフォルトの動作は次のとおりです。

発信トランクがルート リストまたはルート グループに含まれていない場合、着信コールがトランクに到着すると、受信された原因コードは発信元の UC システムに着信トランク経由で返されます(トランク プロトコル Q.850 原因コードの同等なメッセージを使用)。

図 12 Unified CM Session Management Edition 上にルート リストまたはルート グループがない場合のコール再ルーティング

図 13 Unified CM Session Management Edition 上にルート リストまたはルート グループがない場合のコール再ルーティング

発信トランクがルート リストまたはルート グループに含まれている場合は、次のとおりです。

番号未割り当てまたはユーザ ビジーを示す原因コードがコール先のシステムから受信されると、Unified CM/Unified CM Session Management Edition は、ルーティングを中止し、ルート リスト内の別のトランク経由でコールを再ルーティングしようとはしません。

選択されたメディア パス上でコールの進行に使用できる帯域幅が不足していると、Unified CM/Unified CM Session Management Edition は、ルーティングを中止しないで、ルート リスト内の別のトランク経由でコールを再ルーティングしようとします。

その他の原因コードがコール先のシステムから受信されると、Unified CM/Unified CM Session Management Edition は、ルーティングを中止しないで、ルート リスト内の別のトランク経由でコールを再ルーティングしようとします。

Unified CM/Unified CM Session Management Edition のエンタープライズ パラメータである [クラスタ全体のパラメータ(ルート プラン)(Clusterwide Parameters (Route Plan))] を使用して、上記の動作を設定できます。特に、Unified CM/Unified CM Session Management Edition は、特定の範囲の原因コードを受信したときにルーティングを中止するように設定できます。

Q.850 原因コードの説明と SIP メッセージへのそれらのマッピングについては、次の URL にあるマニュアルを参照してください。

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftmap.html

および

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftbibble.html


) Unified CM は、IOS と同じ SIP スタックを使用します。したがって、前述のマニュアルに記載されている SIP メッセージへの Q.850 原因コードのマッピングは、Unified CM SIP トランクにも一般に当てはまります。


図 14 Unified CM Session Management Edition 上にルート リストとルート グループが存在する場合のコール再ルーティング

図 15 Unified CM Session Management Edition 上にルート リストとルート グループが存在する場合のコール再ルーティング

トランク エンゲージメントとコール再ルーティングに関する注意

システムがルート リストのメンバーにコールを最初に提示したとき、Unified CM は、ユーザ ビジーと番号未割り当て以外のすべての原因コードについて再ルーティングを行います。

Cisco Unified CM サービスの関連するサービス パラメータの値によって、それらの原因コードに対する再ルーティングの判断が決定されます。[クラスタ全体のパラメータ(ルート プラン)(Clusterwide Parameters (Route Plan))] グループには、[帯域幅不足時のルーティングの中止フラグ(Stop Routing on Out of Bandwidth flag)]、[ユーザ ビジー時のルーティングの中止フラグ(Stop Routing on User Busy flag)]、および [番号未割り当て時のルーティングの中止フラグ(Stop Routing on Unallocated Number flag)] サービス パラメータが含まれています。各サービス パラメータは [はい(True)] または [いいえ(False)] に設定できます。

デフォルトの設定を図 16 に示します。(Unified CM は、ユーザ ビジーと番号未割り当て以外のすべての原因コードについて再ルーティングを行います)。

図 16 ルート プラン:クラスタ全体の設定パラメータ:ルーティングの中止

ルート リストがトランク上に固定され、メディア ネゴシエーションが開始された後、再ルーティングは行われません。ルート リストが次のルート グループのハンティングを止めるタイミングは、エンドポイントのメディア接続時間とルーティングの中止のサービス パラメータに従って決定されます。メディア ネゴシエーションが開始されるとき、Unified CM は、遠端デバイス/ユーザに到達していると判断します。この時点でルーティングは完了し、ルート リストは再ルーティングできません。

[Q.931 接続解除原因コード時のルーティングの中止(Stop Routing on Q.931 Disconnect Cause Code)] サービス パラメータ

ルート リストによってリモート サイトにルーティングされるコールが解放され、Q.931 原因コードが Unified CM に送信されると、Unified CM は、このサービス パラメータを使用してルーティング動作を決定します。メッセージ内の原因コードがこのパラメータで指定された原因コードと一致すると、ローカル Unified CM はそのコールのルーティングを中止します。(コールは、ルート リスト内の次のデバイスに送信されません)。

Unified CM Session Management Edition クラスタのサイズの決定方法

Unified CM Session Management Edition クラスタのサイズを正しく決定するには、Unified CM Session Management Edition クラスタ経由で行われる同時発生コールの数とコールの頻度を調べる必要があります。これらの数字が算出された後は、選択した Unified CM Session Management Edition サーバ プラットフォームのパフォーマンスに基づいて、Unified CM Session Management Edition のコール処理サーバ ペアの数を決定できます。

Unified CM Session Management Edition クラスタのサイズを決定するには、お客様から次の情報を入手する必要があります。

UC システム内のユーザの合計数

ユーザあたりの平均の最繁時呼数(BHCA)

ユーザあたりの平均のコール保持時間(CHT)

シスコ パートナーと従業員は、Unified CM Session Management Edition サイジング ツール(http://tools.cisco.com/cucst/faces/login.jsp > [新規ソリューション(New Solutions)] > [個別製品のサイジング(Individual Product Sizing)])を利用できます。Unified CM Session Management Edition サイジング ツールでは、次の項目を定義できます。

Unified CM Session Management Edition への接続に使用するトランク プロトコルごとのリーフ クラスタ/UC システム

リーフ クラスタ タイプごとのユーザ分割率

オフネット コールの比率

オンネット コールの比率

クラスタ内に留まるコールの比率

予測される成長率

Unified CM Session Management Edition サイジング ツールの出力からは、Unified CM Session Management Edition クラスタに必要なコール処理サーバ ペアの数、サーバあたりの平均のコール数/秒、サーバあたりの平均の同時発生コール数、および必要なセッション マネージャ ライセンスの数について詳細が得られます。


) このサイジング ツールの出力には、専用パブリッシャ サーバは含まれていません。専用パブリッシャ サーバは、すべての Unified CM Session Management Edition クラスタの導入に含める必要があります。


Unified CM Session Management Edition 導入のコンポーネント

ここでは、Unified CM Session Management Edition 導入のコンポーネントについて説明します。

Unified CM Session Management Edition クラスタ

Unified CM Session Management Edition クラスタ サーバは、次のプラットフォーム上に導入できます。

Cisco Unified Computing System B200 M1/M2:B シリーズ ブレード サーバ

Cisco Unified Computing System C210 M1/M2:2U ラックマウント サーバ

Cisco Media Convergence Server(MCS)7845-I3 および HP DL380G6 サーバ

各サーバは、最大 9,000 の同時発生コールをサポートできます。サーバのコール数/秒のパフォーマンスは、使用されているプラットフォーム タイプとトランク プロトコルに左右されます。たとえば、MCS 7845 I3 サーバ上での SIP トランクから SIP トランクへのコールは、一般に 48 コール/秒の能力があります。


) Unified CM Session Management Edition サイジング ツールでは、ユーザあたりの平均コール数と平均コール保持時間を使用して Unified CM Session Management Edition クラスタのサイズが決定され、コールのピークを考慮してクラスタのサイズが縮小されます。同様に、1 秒あたりのトランクツートランク コール パフォーマンスは、使用されるトランク プロトコルによって異なります。Unified CM Session Management Edition サイジング ツールでは、このようなパフォーマンスの差を計算に入れて、Unified CM Session Management Edition のクラスタ サイズが決定されます。


Unified CM Release 8.5 以降のリリースではトランク固有の拡張機能が多数サポートされているため、通常、Unified CM Session Management Edition クラスタにはこれらのリリースを導入することが推奨されます。それ以前の Unified CM リリースを導入する場合は、Unified CM Release 7.1(2) 以降が推奨されます。リリース 7.1(2) よりも前の Unified CM リリースも導入できますが、クラスタを Unified CM Release 7.1(2) 以降にアップグレードしなければ解決できない問題に遭遇する可能性があります。

リーフ Unified CM クラスタ

リーフ Unified CM クラスタは、Unified CM Release 7.1(2) 以降のリリースに導入する必要があります。(Unified CM Release 8.5 以降が推奨されます)。7.1(2) よりも前の Unified CM リリースも導入できますが、クラスタを Unified CM Release 7.1(2) 以降にアップグレードしなければ、解決できない問題に遭遇する可能性があります。

IP ベースのサードパーティ製リーフ UC システム

ほとんどの場合、サードパーティ製の UC システム機能(つまり、SIP または H.323 のサポート)によって、Unified CM Session Management Edition に接続するために使用するトランキング プロトコルが決定されます。アプリケーションが SIP プロトコルと H.323 プロトコルの両方をサポートしている場合は、Unified CM Release 8.5 以降の Unified CM Session Management Edition クラスタに SIP トランクを使用することが推奨されます。8.5 よりも前のリリースを実行する Unified CM Session Management Edition クラスタには、SIP トランクか H.323 ベース ゲートウェイ/トランクのいずれかを使用できます。

TDM ベースのサードパーティ製リーフ UC システム

TDM ベースのサードパーティ製リーフ UC システムは通常、PBX またはキー システムです。これらのサードパーティ製 UC システムは IOS 音声ゲートウェイを使用して、Unified CM Session Management Edition に接続します。IOS ゲートウェイは、Q.931 および Q.SIG ベースの TDM インターフェイス(および必要に応じてアナログ インターフェイス)をサポートします。IOS ゲートウェイから Unified CM Session Management Edition への IP 接続には、SIP、H.323、または MGCP コール制御プロトコルを使用できます。Unified CM Release 8.5 の多くの新機能から利点を得られるため、Unified CM Session Management Edition には SIP または Q.SIG-over-SIP トランク接続が推奨されます。H.323 および MGCP も使用できますが、これらのプロトコルでは SIP トランクと同じフィーチャ セットの利点を得られません。Unified CM Session Management Edition での H.323 および MGCP ベース トランクの使用については、 H.323 ゲートウェイと H.323/H.225 ゲートキーパー制御トランクおよび MGCP ゲートウェイをに説明があります。

サービス プロバイダー ネットワークへの IP-PSTN および IP トランク

サービス プロバイダーは、企業の顧客に対して非 TDM PSTN 接続のサービスを増やしています。非 TDM インターフェイスを導入した場合に得られるコスト削減という重要なメリットのほか、これらの IP ベース PSTN 接続では、従来の PSTN インターフェイスと比較して料金の低下と音声機能の追加を実現できます。

Unified CM Session Management Edition を使用して、1 つ(または複数)の集中型 IP-PSTN トランクを介した PSTN アクセスを集約できます。集中型 PSTN アクセスには一般に、ブランチベースの PSTN 回線の削減または排除を伴います。

図 17 集中型 PTSN

Unified CM Session Management Edition クラスタからの 1 つまたは複数のトランクは、Cisco Unified Border Element などのセッション ボーダー コントローラ(SBC)を介してサービス プロバイダー(SP)IP-PSTN サービスに接続できます。通常、会社へのすべての PSTN コール、および会社からのすべての PSTN コールでこのトランクのセットが使用されます。

現在、いくつかの H.323 ベース IP-PSTN サービスが存在していますが、サービス プロバイダーが提供する大半の IP-PSTN トランクでは、会社と SP 間のコール制御プロトコルとして SIP が使用されています。

IP-PSTN 接続用のセッション ボーダー コントロール

Cisco Unified Border Element は、企業 UC ネットワーク内の重要コンポーネントであり、サービス プロバイダーへの IP-PSTN 接続のために企業ネットワークのエッジに導入されます。ここで、制御された境界ポイントとセキュアなネットワーク間インターフェイスが提供されます。Cisco Unified Border Element は、次のプラットフォームで使用できるライセンスされた Cisco IOS アプリケーションです。

Cisco Integrated Service Routers Generation 2(29xx、39xx などの ISR-G2)

Cisco 1000 シリーズ Aggregation Services Router(ASR)

Cisco Integrated Service Router(28xx、38xx などの ISR)

Cisco AS5000XM メディア ゲートウェイ

Cisco Unified Border Element は、ハードウェア プラットフォームに応じて、4 ~ 16,000 本の同時ボイスコールが可能なセッション拡張性を提供できます。Cisco Unified Border Element は、次のプラットフォームで拡張性と冗長性を提供します。

ISR-G2 プラットフォーム。安定したアクティブ コールのために、メディア保護によるボックスツーボックス冗長性を提供できます(Cisco IOS Release 15.1.2T 以降の Cisco Unified Border Element Release 8.5)

ASR プラットフォーム。安定したアクティブ コールのために、メディアおよびシグナリングの保護(ステートフル フェールオーバー)によるボックスツーボックス冗長性またはインボックス冗長性を提供できます(リリース 3.2)。

集中型アプリケーション

Unified CM Session Management Edition の導入により、ボイスメール、音声会議、またはビデオ会議など、一般に使用されるアプリケーションは Unified CM Session Management Edition クラスタへの直接接続が可能になります。これにより、リーフ システムへの複数のトランクの管理に要するオーバーヘッドが軽減されます。

図 18 集中型アプリケーション

Unified CM Session Management Edition がサポートするアプリケーション

Unified CM Session Management Edition は、次のアプリケーションをサポートします。

Cisco Unity および Cisco Unity Connection

Cisco Unified MeetingPlace および Cisco Unified MeetingPlace Express

SIP および H.323 ベースのビデオ会議システム

サードパーティ製ボイスメール システム

ファクス サーバ

Cisco Unified Mobility

リーフ クラスタへの接続が必要なアプリケーション

次のアプリケーションは、リーフ クラスタに接続する必要があります。

Cisco Unified Contact Center および Cisco Unified Contact Center Express

Cisco Unified Presence Server

Cisco Unified Communications Manager Attendant Console

Cisco Emergency Responder(CER)

一般的なガイドラインとして、コールを確立するために番号に基づいたコール ルーティングのみに依存するアプリケーションは、Unified CM Session Management Edition に接続できます。デバイス状態を追跡するために追加のインターフェイスを必要するアプリケーション(CTI など)は、リーフ クラスタに接続する必要があります。

Unified CM Session Management Edition クラスタに電話機を導入する場合は、標準の UC アプリケーションを導入してそれらの電話機にサービスを提供できます。

Unified CM Session Management Edition 導入モデル

複数のリーフ Unified CM クラスタおよびサードパーティ製の UC システムと組み合わせた Unified CM Session Management Edition クラスタの導入は、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html にある『Cisco Unified Communications System Release 8.x SRND』で説明しているマルチサイトの分散型コール処理の導入モデルにおけるバリエーションです。企業 UC ネットワークの規模に応じて、UC 設計には 1 つまたは複数の Unified CM Session Management Edition クラスタを含めることができます。たとえば、大規模な欧州の組織では、複数の国に Unified CM クラスタとサードパーティ製の UC システムを装備し、Unified CM Session Management Edition クラスタを使用してそれらのシステムを相互接続することができます。一方、大規模なグローバル組織では、地域別に編成された多数の Unified CM Session Management Edition クラスタを配置できます(欧州、アジア太平洋、北米など)。この場合、各 Unified CM Session Management Edition クラスタは、地域内のリーフ UC システムにサービスを提供し、他の Unified CM Session Management Edition クラスタと直接接続します。


) 次の説明では、Unified CM Session Management Edition クラスタがトランクのみをサポートすることを前提としています。


単一の Unified CM Session Management Edition クラスタの導入

単一の Unified CM Session Management Edition クラスタは、最大 8 つのコール処理サブスクライバ(または、Unified CM Session Management Edition メガクラスタの導入においては最大 16 のコール処理サブスクライバ)で構成されます。標準の Unified CM Session Management Edition クラスタでは、サーバ冗長性により、最大 36,000 本の同時コールをサポートできます。Unified CM Session Management Edition クラスタには専用のパブリッシャ サーバが必要であり、導入環境によっては次のコンポーネントも必要になります。

MGCP ベース ゲートウェイおよび IP Phone(使用する場合)にファイルを提供するための TFTP サービス

SIP アーリー オファー用、または DTMF 転送の不一致に対処するためのメディア ターミネーション ポイント

トランスコーダ

RSVP エージェント


) 保留しているデバイスが保留音を起動するため、電話機のない Unified CM Session Management Edition クラスタに保留音は必要ありません。


コール分配

Unified CM Session Management Edition のいずれの設計でも、クラスタ内のすべてのコール処理ノードに対する均等なコール分配が望まれます。ルート ローカル ルール(前述)と、ルート リストおよびルート グループ内の単一トランクおよび複数トランクでのロールに留意してください。可能な場合は、トランクおよびルート リストで [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を有効にします。この機能を有効にできない場合は、クラスタ内のすべてのノードにトランク インスタンスが均等に分配されるようにします。また、ルート リストの Unified CM グループにあるプライマリ ノードが、このルート リストに関連付けられているトランクが使用するノードと一致しないようにしてください。

着信コール分配

Unified CM Session Management Edition クラスタ内のノードへの着信コールの分配は、以下の項で説明するとおり、コールを Unified CM Session Management Edition にルーティングするデバイス/UC システムの機能によって決定されます。

Unified CM Release 8.5 以降のリリースを実行するリーフ Unified CM クラスタ

複数の宛先アドレスが指定された SIP クラスタ間トランク(ICT)を使用するリーフ クラスタは、すべての宛先に対してランダムにコールを分配します。

複数の宛先アドレスが指定された H.323 ICT を使用するリーフ クラスタは、すべての宛先に対してラウンドロビン(交換)方式でコールを分配します。

リリース 8.5 よりも前の Unified CM リリースを実行するリーフ Unified CM クラスタ

H.323 非ゲートキーパー クラスタ間トランクを使用するリーフ クラスタは、1 つまたは複数のトランクを使用して、リーフ クラスタからコールを発信できます。トランクごとに、最大 3 つの宛先アドレスをサポートできます。

SIP クラスタ間トランクを使用するリーフ クラスタは、1 つまたは複数のトランクを使用して、リーフ クラスタからコールを発信できます。各トランクがサポートできる宛先アドレスは 1 つです。

Unified CM Session Management Edition へのトランク プロトコルとして SIP または H.323 を使用する IOS ゲートウェイの場合、Unified CM Session Management Edition クラスタへの着信コールがすべてのコール処理サーバに対して均等に分配されるように、複数のダイヤル ピアを設定できます。

Unified CM Session Management Edition へのトランク プロトコルとして MGCP を使用する IOS ゲートウェイの場合、Q.931/Q.SIG コール シグナリングは Unified CM Session Management Edition クラスタ内の単一のコール処理サーバにバックホールされます。複数の MGCP ゲートウェイを使用する場合は、Unified CM Session Management Edition クラスタ内のすべてのコール処理サーバに対して各ゲートウェイからバックホールされたコールシグナリング接続が均等に分配されるようにします。

発信コール分配

Unified CM Session Management Edition クラスタ内のノードからの発信コールの分配は、使用される発信トランク タイプとルート ローカル ルールによって決定されます。単一の Unified CM Session Management Edition クラスタ設計に望まれる設計目標は、着信コールの到達先と同じノードから発信コールを開始することです。ほとんどの場合、Unified CM Release 8.5 以降のリリースを使用することが推奨されます。

SIP クラスタ間トランク(ICT)を使用する Unified CM Session Management Edition クラスタでは、トランクに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を有効にして、1 つまたは複数の宛先アドレスを設定します。ルート リストおよびルート グループ内の複数の SIP トランクを使用する場合、ルート リストに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を有効にします。この構成では、(ルート ローカル ルールが作用し、)着信コールの到達先と同じノードから発信コールが開始されます。発信コールは、すべての宛先に対してランダムに分配されます。Unified CM Session Management Edition から IOS ゲートウェイ(またはサードパーティ製の UC システム)に SIP トランク接続を設定するには、同じアプローチを使用してください。

H.323 ICT を使用する Unified CM Session Management Edition クラスタでは、トランクに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を有効にして、1 つまたは複数の宛先アドレスを設定します。ルート リストおよびルート グループ内の複数の H.323 トランクを使用する場合、ルート リストに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を有効にします。この構成では、ルート ローカル ルールが作用し、着信コールの到達先と同じノードから発信コールが開始されます。発信コールは、すべての宛先に対してラウンドロビン(交換)方式で分配されます。

Unified CM Session Management Edition から IOS ゲートウェイまたはサードパーティ製の UC システムへの H.323 ゲートウェイ接続では、[すべての Unified CM ノードで実行(Run on All Unifed CM Nodes)] 機能はサポートされず、単一の宛先アドレスだけがサポートされます。複数のゲートウェイ/サードパーティ製 UC システムへの複数の H.323 接続を必要とする場合、H.323 ゲートウェイの Unified CM グループで Unified CM Session Management Edition クラスタ内のノードが均等に使用されるようにしてください。ルート リストおよびルート グループ内の複数のトランクについては、ルート リストに対して [すべての Unified CM ノードで実行(Run on All Unifed CM Nodes)] 機能を有効にします。H.323 ゲートウェイ トランクは [すべての Unified CM ノードで実行(Run on All Unifed CM Nodes)] 機能をサポートしないため、これらのトランク経由の発信コールには、必ずしもルート ローカル ルールが適用されないことに注意してください。したがって、着信コールが到達する Unified CM Session Management Edition クラスタ内のノードを、発信 H.323 コールに使用するノードと同一にすることはできません。図 19 を参照してください。

図 19 ルート ローカルと H.323 ゲートウェイ トランク経由の発信コール

Unified CM Session Management Edition から IOS ゲートウェイへの MGCP 接続は、[すべての Unified CM ノードで実行(Run on All Unifed CM Nodes)] 機能をサポートせず、単一の宛先アドレスのみサポートします。コールシグナリング チャネルは、Unified CM Session Management Edition クラスタ内の 1 つのノードにバックホールされるので、MGCP ゲートウェイの Unified CM グループで同時にアクティブになるノードは 1 つだけです(通常は、プライマリ ノード)。複数の MGCP ゲートウェイを使用する場合は、Unified CM Session Management Edition クラスタ内のすべてのコール処理サーバに対して各ゲートウェイからバックホールされたコールシグナリング接続が均等に分配されるようにします。

ルート リストおよびルート グループ内の複数の MGCP ゲートウェイについては、ルート リストに対して [すべての Unified CM ノードで実行(Run on All Unifed CM Nodes)] 機能を有効にします。ゲートウェイ MGCP 接続は、Unified CM Session Management Edition クラスタ機能内の 1 つのノードでのみアクティブになるので、MGCP ゲートウェイを介した発信コールには、必ずしもルート ローカル ルールが適用されないことに注意してください。したがって、着信コールが到達する Unified CM Session Management Edition クラスタ内のノードを、発信 MGCDP コールに使用するノードと同一にすることはできません。

単一の Unified CM Session Management Edition クラスタとクラスタオーバー WAN

Unified CM クラスタと同様に、QoS 機能が有効な IP WAN によって接続された複数のサイト間に単一の Unified CM Session Management Edition クラスタを導入できます。一般に、サイト間の遅延(最大ラウンド トリップ タイム(RTT)= 80 ミリ秒)、帯域幅、およびネットワークの QoS 要件においては、標準の Unified CM クラスタに適用されるルールが Unified CM Session Management Edition クラスタにも適用されます。クラスタオーバー WAN に関する一般的なガイダンスについては、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1043996 にある『Cisco Unified Communications System Release 8.x SRND』を参照してください。クラスタオーバー WAN の導入に関する Unified CM Session Management Edition 固有のガイダンスについては、次の項を参照してください。

複数のサイト間に分散された Unified CM Session Management Edition クラスタを介してコールをルーティングする場合、クラスタオーバー WAN サイト内の Unified CM Session Management Edition ノードに到達するコールは、別のクラスタオーバー WAN サイトにある Unified CM Session Management Edition ノード間で内部ルーティングするよりも、同じノードから宛先に発信するのが理想的です(つまり、ルート ローカル ルールが着信コールと発信コールに対して正常に作用することが必要です)。ルート ローカル ルールを使用したコールのルーティングの利点は、クラスタ内のノード間トラフィックが減少することと、Unified CM Session Management Edition クラスタへの着信コールの分配によって Unified CM Session Management Edition ノード間のコール分配が決定されることです。

Unified CM Session Management Edition クラスタを介してコールをルーティングするこの効率的な方法を最も簡単に実現するには、Unified CM Release 8.5 以降のリリースと、SIP トランク、SIP ICT、H.323 非ゲートキーパー制御 ICT、ルート リスト、およびローカル ルート グループを組み合わせて使用します。ローカル ルート グループでは、単一のクラスタ全体のルート パターンに、コールが到達する着信トランクに対してローカルな(同じクラスタオーバー WAN サイト内の)発信トランクを選択できます。複数の宛先アドレス、標準の Unified CM グループ、または [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能をサポートする、SIP トランク、SIP ICT、および H.323 非ゲートキーパー制御 ICT では、ルート ローカル ルールをすべてのコールに適用できます。

クラスタオーバー WAN 設計に関する一般的な設計上の考慮事項

リーフ UC システムおよび Unified CM Session Management Edition クラスタを検討する際、OPTIONS ping や正規化および透過性のスクリプトなどの SIP トランク機能を必要に応じて適宜使用できます。[すべての Unified CM ノードで実行(Run on all Unified CM Nodes)] や複数の宛先アドレスなどの SIP および H.323 トランク機能は本来、トランクが着信コールを識別し、受け入れるために使用するメカニズムであるため、よく考えて使用する必要があります。(着信の送信元 IP アドレスが、宛先 IP アドレスとして定義されているアドレスのいずれかに一致すると、トランクはコールを受け入れます)。

クラスタオーバー WAN を使用して導入された Unified CM Session Management Edition クラスタへのリーフ クラスタ トランク接続に関する設計ガイドライン

各リーフ クラスタで、各データセンター内の各 Unified CM Session Management Edition ノード グループにコールを分配するための複数のクラスタ間トランクをルート リストに作成し、優先順位を付けます。Unified CM Release 8.5 以降のリリースを使用している場合は、クラスタ間トランクおよびルート リストに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] を有効にして、地理的なコール分配用にトランクごとに宛先 IP アドレスを定義します。

図 20 リーフ クラスタから Unified CM Session Management Edition へのコール

クラスタオーバー WAN の導入における Unified CM Session Management Edition クラスタ トランクからリーフ UC システムへのコールに関する設計ガイドライン

Unified CM Session Management Edition クラスタで、ルート リスト内に複数のトランクを作成して優先順位を付け、各データセンター内の各 Unified CM Session Management Edition ノード グループから接続先のリーフ クラスタへコールをルーティングできるようにします。Unified CM Release 8.5 以降のリリースを使用する場合、トランクごとに標準の Unified CM グループを使用し、1リーフ クラスタ内のすべてのコール処理ノードに宛先 IP アドレスとポート番号を定義し、すべてのルート リストに対して [すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] を有効にします。

着信トランク コールの場合、ローカル ルート グループを使用して、同じデータセンターのトランク上で発信コールをルーティングします。

図 21 Unified CM Session Management Edition からリーフ クラスタへのコール

それぞれの環境で使用するトランク タイプと Unified CM リリースによって、トランクの設計は上記のガイダンスと異なる場合があります。たとえば、Unified CM Session Management Edition クラスタで MGCP トランクを使用する場合、MGCP トランクは Unified CM Session Management Edition ノードでだけアクティブになるため、ルート ローカル ルールはたまにしか作用せず、多くの場合、着信コールは Unified CM Session Management Edition クラスタ内の他のノードにルーティングされてから、それぞれの宛先にルーティングされます。

一般に、Unified CM Session Management Edition クラスタまたはリーフ Unified CM クラスタに Unified CM Release 8.5 以降のリリースを導入する場合は、MGCP トランク、H.323 トランク、および H.323 ゲートウェイよりも多くのフィーチャ セットが提供されることから(OPTIONS ping や SIP Normalization など)、SIP トランクおよび SIP ICT が推奨されます。

Unified CM Session Management Edition に対するクラスタオーバー WAN の帯域幅の計算

次の説明では、Unified CM Session Management Edition クラスタに電話機が登録されていないか、登録数が少ない(150 台未満)ことを前提としています。Unified CM Session Management Edition クラスタに 150 台を超える電話機を登録している場合は、クラスタオーバー WAN の帯域幅を決定する方法について、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1043616 にある『Cisco Unified Communications System Release 8.x SRND』のガイドラインを使用してください。

『Unified Communications System Release 8.x SRND』では、同一のクラスタオーバー WAN サイトにデバイスのバックアップ ノードが存在するローカル フェールオーバーと、リモートのクラスタオーバー WAN サイト内にデバイスのバックアップ ノードが存在するリモート フェールオーバーの 2 タイプの導入に関するクラスタオーバー WAN のサポートについて説明しています。

[すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能を使用するトランクの場合、1 つのノードに障害が発生したことで、別のノードでトランク プロセスが再登録されることはありません(すべてのノードにすでにプロセスが存在するため)。クラスタ内の 1 つまたは複数のノードに障害が発生した場合、クラスタ内の残りのアクティブ ノードが後続のコールを処理します。標準の Unified CM グループを使用するトランクの場合、1 つの Unified CM Session Management Edition クラスタオーバー WAN サイトでトランクの Unified CM グループ内にノードをローカライズすることも、2 つまたは 3 つのサイトにノードを分散させて地理的な冗長性を確保することもできます。Unified CM グループを使用するトランクを導入する場合、たいていは、ルート リストに複数のトランクを設定し、Unified CM Session Management Edition クラスタを経由するプライマリ パスが同じ Unified CM Session Management Edition のクラスタオーバー WAN サイト内のノードを使用するよう、ローカル ルート グループを使用することで、バックアップと冗長性を実現できます。

何千台もの電話機が登録された標準の Unified CM クラスタに比べると、Unified CM Session Management Edition クラスタ内のアクティブ デバイスはほんの少数です。Unified CM Session Management Edition クラスタは、最大 2100 個のトランクをサポートできますが、一般的な Unified CM Session Management Edition クラスタのトランク数は 100 未満になることがほとんどです。トランク数が 300 ~ 400 に達するのは、大規模な Unified CM Session Management Edition 導入のごく一部です。

『Unified Communications System Release 8.x SRND』のクラスタオーバー WAN の項にある WAN に関する考慮事項、クラスタ内通信2、主要サービスの複製などの関連するガイドラインに従ってください。

Unified CM Session Management Edition のクラスタオーバー WAN サイト間の WAN 帯域幅を求めるには、次の公式を使用します。

サイト間で必要な合計帯域幅 = 合計クラスタ内通信シグナリング(ICCS)帯域幅 + 合計データベース帯域幅

クラスタ内通信シグナリング帯域幅

クラスタオーバー WAN サイト間で 10,000 回の Busy Hour Call Attempt(BHCA)を実現するためのクラスタ内通信シグナリング(ICCS)には、最低でも 1.544 Mb/秒(T1)の帯域幅が必要です。このコール制御トラフィックは、優先トラフィックに分類されます。優先 ICCS トラフィックには、IP Precedence 3(DSCP 24 または PHB CS3)が付けられます。

コールを転送するルート ローカル ルールが作用するように大部分の Unified CM Session Management Edition トランクを導入すると、コールは他のクラスタ ノードおよびサイトにルーティングされません。この場合、サイト間の ICCS トラフィック用に最低でも 1.544 Mb/秒(T1)の帯域幅をプロビジョニングできます。

1 つの Unified CM Session Management Edition ノードでアクティブになる MGCP トランクを導入する場合、コールはクラスタ内のノード間でルーティングされる可能性があります。別の Unified CM Session Management Edition クラスタオーバー WAN サイトにあるノード間でルーティングされるかどうかは、トランク、Unified CM グループ、ルート リスト、およびルート グループの設定によります。通常の条件またはバックアップ条件下でサイト間にルーティングされるコールの BHCA が 10,000 回を超える場合、次の公式を使用してサイト間の帯域幅を計算します。

合計 ICCS 帯域幅(Mb/秒)=(サイト間 BHCA/10,000)*(1 + 0.006 * 遅延):ここで「遅延」はミリ秒単位のラウンド トリップ タイム(RTT)遅延です。


) どのような場合にも、ICCS トラフィックには最低 1.544 Mb/秒の帯域幅が必要です。


1 つの Unified CM Session Management Edition ノードあたりの BHCA を判断するには、Unified CM Session Management Edition クラスタの合計 BHCA 値を Unified CM Session Management Edition クラスタ内のコール処理ノード数で割ります。


) クラスタ内のすべてのコール処理ノードに均等にコールを分配していることが前提となります。


ノードごとの BHCA を計算した後、サイト間に予想される BHCA を判断し、この値が 10,000 を超える場合には、前述の公式にその値を使用します。

データベース帯域幅の計算

クラスタ内通信シグナリング(ICCS)トラフィックに必要な帯域幅に加え、リモートからパブリッシャとなるあらゆるサブスクライバ サーバに対するデータベースおよびその他のサーバ間トラフィック用に、最低でも 1.544 Mb/秒(T1)の帯域幅が必要になります。

合計データベース帯域幅 =(リモートからパブリッシャとなるサーバの数)* 1.544 Mb/秒

Unified CM Session Management Edition クラスタオーバー WAN 帯域幅の計算

サイト間に必要な帯域幅を計算するには、次の公式を使用します。

サイト間に必要な合計帯域幅 = 合計 ICCS 帯域幅 + 合計データベース帯域幅

図 22 SIP および H.323 ベース トランクに対するルート ローカルによるクラスタ内コール ルーティング

Unified CM Session Management Edition クラスタへのすべてのコールが、コールの到達先と同じノード上のクラスタを離れるように(ルート ローカル ルールの動作)、SIP および H.323 ICT またはトランクを使用して Unified CM Session Management Edition クラスタを設計できます。SIP および H.323 トランクを使用する Unified CM Session Management Edition クラスタを導入し、ルート ローカル ルールが作用するようにトランク、ルート リスト、およびローカル ルート グループを設定すると、クラスタ内 ICCS トラフィックが大幅に減少します(異なるサイト内のノード間では、コールはクラスタ内でルーティングされないため)。

図 23 MGCP トランクを使用した接続先 UC システムへのクラスタ内コール ルーティング

MGCP トランクを使用する場合、各トランクはクラスタ内の 1 つのノードでのみアクティブになり、同様に、ゲートウェイからの各 MGCP トランク接続は 1 つの Unified CM ノードにのみ接続できます(複数の Unified CM ノードに接続でき、Unified CM ルート リストおよびルート グループに組み込むこともできる、SIP または H.323 トランクを介したゲートウェイからの接続とは異なります)。したがって、コールは Unified CM Session Management Edition クラスタから MGCP ゲートウェイにルーティングされると、異なる Unified CM Session Management Edition クラスタオーバー WAN サイトのノード間でルーティングされる可能性が高くなり、ICCS トラフィックが増加します。多数の MGCP ゲートウェイを使用する場合、その導入のクラスタオーバー WAN 帯域幅要件を計算するときには、この ICCS トラフィックの追加分を計算に入れてください。

分散された複数の Unified CM Session Management Edition クラスタ

多数の地域別リーフ UC システムおよびエンドポイントを伴うグローバルな UC 導入の場合、相互に接続した複数の Unified CM Session Management Edition クラスタを導入して、各地域のリーフ UC システムのトランクとダイヤル プランを集約することができます。

図 24 地域的に分散された Unified CM Session Management Edition クラスタ

長距離接続でのシグナリングおよびメディア遅延

大幅な時間遅延や、可能性のある多数のコールシグナリング レッグで分割されるデバイス間のコールでは(たとえば、図 24 のアジア太平洋地域の電話機から欧州の電話機へのコールについて考えます)、2 台のデバイス間のメディア パスで発生する一方向の遅延が、コールの参加者のコール品質感に影響を及ぼす場合があります。ITU-T 勧告 G.114 では、このメディア移行パスの遅延を 150 ミリ秒未満に保ち、400 ミリ秒を上限とすることを推奨しています。この上限を超えると、多くのユーザがコールの品質に不満を持ちます。

コール シグナリングについては、コールがいったんセットアップされると、発信側と着信側のデバイス間のシグナリング パス(複数のコール エージェントを通過する可能性がある)で発生した遅延はコールの品質に影響しませんが、コールの始まりに発信側と着信側のユーザ エクスペリエンスに影響する可能性があります。

図 25 に、遅延の長いシグナリング パスにコールがセットアップされている場合に、発信者と着信者が経験する可能性のある一部の遅延を示します。


図 25 は、非常に基本的な SIP アーリー オファー コールを示すという意味で単純に描かれています。実際の環境では、複数のコール エージェントとプロトコルを使用することが考えられます(SCCP、SIP、H323、MGCP など)。プロトコルのバージョンまたは設定によっては、各ステージで交換する必要のあるメッセージの数が増加します(たとえば、H.323 Slow Start と H.323 Fast Start で比較した場合)。また、ベンダーによって実装されるプロトコル スタックも異なります。たとえば、図 25 では、ACK の受信後に双方向メディアが確立されていますが、一部のベンダーは SDP 応答を含む 200 OK を受信した後に双方向メディアを確立します。


図 25 コールシグナリング遅延の影響

双方向メディア パスの確立に必要な時間は、最終的に、交換する必要のあるシグナリング パケットの数と、それらのパケットがネットワークを通過するときの遅延の積となります。これには、各エンドポイントとコール処理エージェント間で交換されるすべてのコール セットアップ シグナリングパケットのほか、異種のコール処理エージェント間で交換されるシグナリング パケットが存在する場合はそれらのパケットが含まれます(たとえば、複数のコール処理エージェントを使用する分散コール処理環境など)。

IP Phone が登録された Unified CM Session Management Edition クラスタ

一般に、ほとんどの Unified CM Session Management Edition 導入は、トランクのみで構成されます。これらの Unified CM Session Management Edition クラスタを使用して、多数のリーフ UC システムを集約し、集中化された大規模なダイヤル プラン管理を実現します。また、Unified CM Session Management Edition クラスタは IP Phone の登録をサポートしており、Unified CM Session Management Edition クラスタの導入では、数千の電話機と多数のトランクをサポートできます。図 26 に示すとおり、Unified CM クラスタへのレガシー UC システムの移行時に Unified CM Session Management Edition クラスタを使用することもできます。

図 26 単一の Unified CM クラスタへの段階を追ったレガシー UC システムの移行

クラスタ間トランクを介した Q.SIG パス置換

リーフ Unified CM クラスタにある電話機間のコール バック(通話中/無応答時)などの機能のほか、Q.SIG はパス置換機能も提供します。パス置換機能は、コールが元のクラスタに戻される場合などに、クラスタ間のコール シグナリングを最適化します。このシグナリングの最適化により、場所に基づいたクラスタのコール アドミッション制御帯域幅に未使用の帯域幅を戻すことができます。


) Q.SIG が有効なトランクは、ジオロケーションおよび関連する論理パーティショニング機能をサポートしません。


図 27 クラスタ間の Q.SIG パス置換:最初のコール

図 28 クラスタ間の Q.SIG パス置換:転送されたコール

 

図 29 クラスタ間の Q.SIG パス置換:シグナリング パスの最適化

Unified CM Session Management Edition での Q.SIG の導入に関する注意事項

Q.SIG アプリケーション プロトコル データ ユニット(APDU)で送信される発信者番号、着信者番号、および転送番号は、トランスレーション パターンおよび変換パターンによって変更されません。Q.SIG が有効なトランクを使用する Unified CM Session Management Edition の導入では、Q.SIG APDU で送信される番号(特にダイヤルされた番号。ユーザのダイヤリング動作がクラスタ間で異なる可能性があるため)が Q.SIG ベースの機能の提供に影響する場合があります。コール バックやパス置換などの Q.SIG 機能で所定のコールの着信者番号と発信者番号を使用して、それらの機能を呼び出すことができるかどうか、またそのタイミングを判断することができます。Q.SIG 機能の呼び出しに関して着信者番号と発信者番号の依存関係を回避するには、次に示す Q.SIG 機能の Unified CM サービス パラメータ設定値を使用します。

クラスタ全体のパラメータ(機能:パス置換)

Q.SIG プロトコルは番号変換を適用せずに内線番号または電話番号を渡すので、定型ダイヤル プランを使用する UC ネットワークではパス置換などの Q.SIG 機能を使用してください。UC ネットワークのダイヤル プランに一意でない電話番号(または、変動するユーザのダイヤリング手順)を使用する場合、PINX ID を使用してコールを再ルーティングする必要があります。PINX ID は、UC ネットワーク内のすべての PINX(つまり、Q.SIG 対応の UC システム)に対する一意の電話番号です。パス置換機能は、PINX ID が設定されている場合に、着信者番号または発信者番号の代わりにこの ID を使用して、パス置換を呼び出す必要があるかどうかを判断します。PINX ID を設定するには、Cisco Unified Communications Manager の管理ページで次のタスクを実行します。

パス置換機能の PINX ID サービス パラメータを設定します。(パス置換機能では、Cisco CallManager サービスが使用されます)。

PINX ID だけを含めるコール ピックアップ グループを作成します。

Unified CM には [パス置換コーリング サーチ スペース(Path Replacement Calling Search Space)] サービス パラメータがあります。このサービス パラメータでは、連携している PINX が発信 SETUP メッセージを要求側の PINX に送信するために使用するコーリング サーチ スペースを設定します。[パス置換コーリング サーチ スペース(Path Replacement Calling Search Space)] サービス パラメータの値を指定しないと、要求側の PINX は、そのコールに関係しているエンド ユーザのコーリング サーチ スペースを使用します。

Q.SIG トランクを介したパス置換機能の詳細については、次の Web ページを参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a08procl.html#wpmkr1174602

クラスタ全体のパラメータ(機能:コール バック)

次のコール バック(コール完了とも呼ばれる)サービスは、Q.SIG が有効なトランクを介した次の Cisco Call Back 機能を提供します。

Completion of Calls to Busy Subscribers(CCBS):発信者は、ビジー音を受信した場合、ビジー状態の相手側が電話を切り、応答できるようになったときにコールを完了するように要求できます。

Completion of Calls on No Reply(CCNR):発信者は、宛先の応答を得られない場合、着信側の電話機でアクティビティが生じた後にコールを完了するように要求できます。

Unified CM Session Management Edition の導入では、[接続提案タイプ(Connection Proposal Type)](デフォルト パラメータは [接続保持(Connection Retention)])および [接続応答タイプ(Connection Response Type)](デフォルト パラメータは [接続保持にデフォルト設定(Default to Connection Retention)])に対してコール バックのクラスタ全体サービス パラメータのデフォルト設定を使用します。これらのデフォルト値により、所定のコール試行の着信者番号および発信者番号を使用せずに、Q.SIG のコール バック機能を呼び出すことできます。

Q.SIG のコール バック機能の詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a08procl.html#wp1164947 を参照してください。

図 30 クラスタ全体の Q.SIG:パス置換機能とコール バック機能

コール転送

Unified CM は、再ルーティングによるコール転送と転送スイッチングによるコール転送をサポートします。再ルーティングによるコール転送が発生すると、発信側の PINX はコールの受信者から、コールを別のユーザに転送するための要求を受信します。[クラスタ全体のパラメータ(機能:転送)(Clusterwide Parameters (Feature--Forward))] のデフォルト設定では、[転送スイッチングによるコール転送(Call Forward by Forward Switching)] を使用します([再ルーティングによる転送(Forward By Reroute)] は無効になります)。Unified CM Session Management Edition の導入に対する一般的な推奨事項として、また、UC ネットワークに定型ダイヤル プランを使用しない場合には、転送スイッチングによるコール転送とパス置換を使用して、開始側と終端側のユーザ間のパスを最適化してください。

Q.SIG のコール転送の詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a08procl.html#wp1156053 を参照してください。

Q.SIG トランク上での + 文字の処理

Q.SIG トランクは、Q.SIG APDU で + 文字を転送しません。+ 文字転送をサポートしていないことが、コール完了、パス置換、および転送スイッチングによるコール転送の各 Q.SIG 機能の動作に影響することはありません。Q.SIG APDU での + 文字転送をサポートしてないことが、集中型ボイスメール システムへのコール転送に影響する可能性はあります。通常、この + 文字の問題に対処するには、ボイスメール システムのユーザ ボイスメールボックスに対してプライマリ番号と代替番号を定義します。これらの Q.SIG 関連のボイスメール問題の詳細については、 Unified CM Session Management Edition 上のボイスメール アプリケーションで説明します。

Unified CM Session Management Edition SAF CCD の導入

Unified CM Session Management Edition の導入により、内部ダイヤル プランを集約できます。Cisco Service Advertisement Framework(SAF)コール制御ディスカバリ(CCD)の導入では、内部ダイヤル プランと対応する外部の to-PSTN ダイヤル プランの両方が、参加している SAF CCD UC システムに分散されます。

Unified CM Session Management Edition と SAF のさまざまな組み合わせにより、UC の導入に運用上およびダイヤル プラン管理上の利点をもたらすことができます。次の項では、以下の 2 つの SAF および Unified CM Session Management Edition の導入モデルについて説明します。

集中型 Unified CM Session Management Edition コール ルーティング

集中型 Unified CM Session Management Edition コール ルーティングを使用すると、IP WAN を介したリーフ クラスタ間のすべてのコールが Unified CM Session Management Edition クラスタを経由します。IP WAN のパスにエラーが発生した場合、コールはローカルの PSTN ゲートウェイにルーティングされます。この導入モデルでは、Unified CM Session Management Edition クラスタでシステム ダイヤル プランを集中的に管理し、to-PSTN ダイヤル プラン情報をすべてのクラスタに分散させることができます。

分散型コール ルーティング

分散型コール ルーティングを使用する場合、リーフ クラスタは SAF を使用して IP WAN 上で互いに直接コールをルーティングします。コールは、Unified CM Session Management Edition を経由しません。Unified CM Session Management Edition クラスタは、SAF を使用してリーフ クラスタからダイヤル プラン情報を学習します。また、サードパーティ製の UC システムの代わりに、PSTN ルートや電話番号パターンをアドバタイズすることもできます。

Unified CM Session Management Edition および SAF と集中型コール ルーティング

Unified CM Session Management Edition と SAF CCD を組み合せることにより、Unified CM Session Management Edition をすべてのリーフ UC システムに対する中央のセッション マネージャとして機能させ、同時に SAF CCD を使用して内部ダイヤル プランと外部の to-PSTN ダイヤル プランの両方を SAF CCD に参加しているすべてのリーフ Unified CM クラスタに分散させることが可能になります。

Unified CM Session Management Edition と SAF のハイブリッド導入では、リーフ クラスタ間のすべてのコールが Unified CM Session Management Edition クラスタ経由でのみルーティングされるようにするために、SAF CCD の特定の設定を使用します。この SAF 設定は、次の 2 つの部分から成ります。

Unified CM Session Management Edition からまたはそれを通じた SAF CCD ルートのリーフ クラスタへのアドバタイジング

SAF CCD ルートのリーフ クラスタから Unified CM Session Management Edition へのアドバタイジング


) ここの説明では、Unified CM 上ですでに Cisco IOS SAF フォワーダと基本的な SAF CCD 設定(アドバタイジング サービス、要求サービス、SAF 対応トランクなど)が設定されていることを前提としています。この設計は、単一の SAF 自律システム(AS)を使用します。


Unified CM Session Management Edition からまたはそれを通じた SAF CCD ルートのリーフ クラスタへのアドバタイジング

Unified CM Session Management Edition クラスタ上で、各 SAF 対応リーフ クラスタでホストされる内部の番号範囲および外部の to-PSTN 番号のための電話番号(DN)パターン、DN グループ、および対応する to-DID ルールを作成します。これらの DN パターンを 1 つまたは複数の SAF 対応トランクおよびアドバタイジング サービスに関連付けることにより、SAF AS にパブリッシュします。これらの DN パターンと、Unified CM Session Management Edition への対応するルートが、すべての SAF 対応リーフ クラスタによって学習されます。Unified CM Session Management Edition が IP WAN 経由で到達可能である場合、すべてのクラスタ間コールは Unified CM Session Management Edition を通じてルーティングされます。Unified CM Session Management Edition が到達不可能であると、クラスタ間コールは、学習された DN パターンの to-DID ルールを使用して着信者番号が変更された後で、リーフ クラスタのローカル PSTN ゲートウェイを通じてルーティングされます。

SAF CCD ルートのリーフ クラスタから Unified CM Session Management Edition へのアドバタイジング

各リーフ クラスタのホストされる DN 範囲を SAF AS にアドバタイズする目的は、Unified CM Session Management Edition クラスタがこれらの DN 範囲とリーフ クラスタの到達可能性を学習できるようにすることです。これらの番号範囲は、その他のすべてのリーフ クラスタにも学習されます。(図 31 を参照)。リーフ間の直接ルートが使用されるのを避けるために、各リーフ クラスタ内で、他のすべてのリーフ クラスタから学習されたルートをブロックします。ルートのブロックは、それがリーフ クラスタ内の SAF ノードの IP アドレスか、または(可能であれば)各リーフ クラスタの Remote Call Control Entity Name に一致するかどうかに基づいて行うことができます。(これは、Unified CM の [エンタープライズ パラメータ] メニューにある Unified CM のクラスタ ID です)。

図 31 Unified CM Session Management Edition 導入での SAF CCD ルートのアドバタイジング

Unified CM Session Management Edition および SAF CCD の導入と集中型コール ルーティングに関する運用上の考慮事項

SAF CCD を使用した Unified CM Session Management Edition の導入には、次の運用上の考慮事項が適用されます。

リーフ クラスタによる自身の DN 範囲の Unified CM Session Management Edition からの学習

図 31 の SAF CCD ルーティング テーブルからわかるように、リーフ クラスタは、自身の DN 範囲の到達可能性について Unified CM Session Management Edition から学習します。これらの DN 範囲は、クラスタ間の DN 範囲およびルートをブロックするのと同じ方法でブロックできます。これらの Unified CM Session Management Edition SAF CCD ルートがブロックされていない場合、発信デバイスのコーリング サーチ スペースが内部 DN のパーティションの上に順序付けられた、SAF CCD で学習されたルート パーティションを持っていれば、これらはクラスタ内コールにだけ選択されます。ほとんどの場合、内部 DN パーティションが SAF CCD パーティションの上に順序付けられるため、クラスタ内コールは Session Management Edition を通じてはルーティングされません。

Unified CM Session Management Edition からリーフ クラスタへの IP ルートが使用できない場合の PSTN へのコールのルーティング

コールを PSTN に再ルーティングする場合に、次の 2 つの設定オプションを使用できます。

Unified CM Session Management Edition に関連付けられている PSTN ゲートウェイを通じた PSTN へのコールの再ルーティング

Unified CM Session Management Edition クラスタが PSTN アクセスを持っており、IP パスを通じて Unified CM Session Management Edition から接続先リーフ クラスタに到達できないコールを再ルーティングする場合は、アドバタイズされる各 DN 範囲またはグループに対する to-DID ルールが各リーフ クラスタから Unified CM Session Management Edition にアドバタイズされるようにしてください。Unified CM Session Management Edition は、この to-DID ルールを使用して着信者番号を変更し、着信トランクの自動代替ルーティング(AAR)コーリング サーチ スペース(CSS)を介してコールをルーティングします。

発信側リーフ クラスタから PSTN へのコールの再ルーティング

Unified CM Session Management Edition クラスタが PSTN アクセスを持っておらず、発信側リーフ クラスタでの PSTN を通じて Unified CM Session Management Edition から接続先リーフ クラスタに到達できないコールを再ルーティングする場合には、アドバタイズされる各 DN 範囲またはグループに対する to-DID ルールが各リーフ クラスタから Unified CM Session Management Edition にアドバタイズされないようにしてください。この場合、Unified CM Session Management Edition から接続先リーフ クラスタへのシグナリング パスを確立できないと、Unified CM Session Management Edition は発信側リーフ クラスタにコールの失敗を通知します。発信側リーフ クラスタは次に、その to-DID ルール(Unified CM Session Management Edition から学習)を使用して着信者番号を変更し、発信側デバイスの自動代替ルーティング(AAR)コーリング サーチ スペース(CSS)を介してコールをルーティングします。

スタティック Unified CM Session Management Edition トランクを通じた非 SAF UC システムへのコール

Unified CM Session Management Edition は、SAF CCD を使用して、非 SAF UC システムの DN 範囲をすべての SAF 対応リーフ クラスタにアドバタイズできます。Unified CM Session Management Edition クラスタを通じたリーフ クラスタから非 SAF UC システムへのコールは、SAF トランクを使用して Unified CM Session Management Edition に到達します。Unified CM Session Management Edition は、設定されているルート パターンと対応するスタティック(標準)トランクを使用して、非 SAF UC システムに到達します。

非 SAF UC システムへのコールに対する PSTN フォールバック

非 SAF UC システムが Unified CM Session Management Edition からスタティック トランクを通じて到達できない場合の PSTN フォールバックには、次の 2 つのオプションがあります。

発信側リーフ クラスタから PSTN へのコールの再ルーティング

このオプションでは、Unified CM Session Management Edition から接続先 UC システムへの単一のトランクが設定されます。Unified CM Session Management Edition から接続先 UC システムへのシグナリング パスを確立できない場合、Unified CM Session Management Edition は発信側リーフ クラスタにコールの失敗を通知します。発信側リーフ クラスタは次に、その to-DID ルール(Unified CM Session Management Edition から学習)を使用して着信者番号を変更し、発信側デバイスの自動代替ルーティング(AAR)コーリング サーチ スペース(CSS)を介してコールをルーティングします。

Unified CM Session Management Edition から PSTN へのコールの再ルーティング

このオプションでは、ルート リストとルート グループの一部として 2 つのトランクが作成されます。Unified CM Session Management Edition から接続先 UC システムへの最初のトランクを設定します。Unified CM Session Management Edition からローカル PSTN ゲートウェイへの 2 番目のトランクを選択します。Unified CM Session Management Edition から接続先 UC システムへのシグナリング パスを確立できない場合、Unified CM Session Management Edition は PSTN への 2 番目のトランクを選択します。PSTN トランクを含むルート グループを使用して、内部着信者番号をその PSTN で相当する番号に変更できます。

Unified CM Session Management Edition および SAF と分散型コール ルーティング

この導入モデルでは、リーフ クラスタは SAF を使用して IP WAN 上で互いに直接コールをルーティングします。コールは、Unified CM Session Management Edition を経由しません。Unified CM Session Management Edition クラスタは、SAF を使用してリーフ クラスタからダイヤル プラン情報を学習します。また、サードパーティ製の UC システムの代わりに、PSTN ルートや電話番号パターンをアドバタイズすることもできます。この導入モデルは、リーフ システム間の SAF ルートのブロックを必要としないため、集中型コール ルーティング モデルよりも単純になります。

図 32 Unified CM Session Management Edition および SAF と分散型コール処理

Unified CM Session Management Edition の導入に推奨されるダイヤル プラン

Unified CM Session Management Edition クラスタのダイヤル プランの設計は、さまざまな要因(リーフ UC システムのダイヤル プランおよび番号操作機能、ユーザのダイヤリング手順、番号グローバル化/正規化の要件など)に基づき UC ネットワークごとに異なります。すべてのダイヤル プランの種類について説明することは不可能であるため、次の項では、グローバルで一意な番号(+E.164、E.164、8XXXYYY 番号、またはこれらの番号形式の組み合わせ)を持つデジタルプランの設計について説明します。着信者番号および発信者番号の正規化は、リーフ UC システムまたは Unified CM Session Management Edition クラスタ内で実行できます。ただし、リーフ UC システムが高度な番号操作メカニズムをサポートせず、すべての着信者番号および発信者番号の正規化が Unified CM Session Management Edition クラスタで行われることがあります。次の項では、これらの Unified CM Session Management Edition および UC システム ダイヤル プランの設計の一部について説明します。ただし、一般的なダイヤル プランの推奨事項については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html にある『Cisco Unified Communications System Release 8.x SRND』の「Dial Plan」の章を参照してください。

これまでに述べたように、Unified CM Session Management Edition のソフトウェア コード ベースは Unified CM とまったく同じです。したがって、企業全体のダイヤル プランを実装するツールも同じです。コール ルーティングは、コーリング サーチ スペース(CSS)、パーティション、およびこれらのパーティションに割り当てられたパターンに基づいて実装されます。効果的な CSS が回線 CSS とデバイス CSS を連結したものである通常の電話機からのコールとは対照的に、トランクからのコールの場合、着信コールに対するサービスのクラスを定義する CSS は、ゲートウェイまたはトランクの着信コール セクションで定義された CSS です。

グローバル番号計画

Unified CM Session Management Edition により管理された集中型ダイヤル プランは、グローバルで一意な番号を使用する番号計画に基づく必要があります。Unified CM Session Management Edition のコール ルーティングは、このグローバルで一意な番号計画に基づいて定義されます。Unified CM Session Management Edition に接続されたリーフ システムは、異なる番号計画を使用することがあります(特に、複数の既存のコール制御に対してコール ルーティングを集中化するために、Unified CM Session Management Edition が既存の導入に追加される場合)。

図 33 に、電話番号、ダイヤリング手順、および Unified CM Session Management Edition ダイヤル プランに +E.164 の番号指定が使用される UC ネットワークを示します。この番号計画とダイヤル プランにより UC ネットワーク内で必要とされる番号正規化の要件は大幅に減少しますが、UC ネットワーク内のユーザはすでに特定のダイヤリング手順(8XXXYYYY など)を使用していたり、ユーザの要件を満たすために番号計画とダイヤル プランを変更することが必要になる場合がある非 E.164 電話番号を使用していたりすることがあります。この項では、可能なダイヤル プランの設計を表す図が他にも複数示されています。(図 34図 35、および図 36 を参照してください)。

図 33 + E.164 の番号指定およびダイヤリング

Unified CM および Unified CM Session Management Edition リーフ クラスタ内の番号操作方法

Unified CM Session Management Edition クラスタのグローバル化された番号計画とは異なる番号計画がリーフ システムで使用される場合は、リーフ システムの番号計画と Unified CM Session Management Edition のコール ルーティングに使用されるグローバル番号計画のマッピングを実装する必要があります。

Unified CM および Unified CM Session Management Edition を使用する場合は、発信側および着信側の情報の正規化を行うために、次のメカニズムを使用できます。

トランクまたはデバイスプール レベルの変換 CSS

ルート パターンの変換

トランスレーション パターンの変換

ルート リストの変換

これらのいずれかのメカニズムを使用して、Unified CM および Unified CM Session Management Edition クラスタを通過する着信者番号および発信者番号を正規化できます。以下では、変換 CSS とトランスレーション パターンをトランク レベルで使用して、着信および発信の着信者番号および発信者番号の正規化を行うことについて集中的に説明します。必要に応じて、上記のリストで示されたメカニズムのいずれかを使用できます。

リーフ システムから Unified CM Session Management Edition へのコールの番号正規化

発信側の正規化

可能な場合は、リーフ システムで発信側情報を正規化します。コール確立中にリーフ システムから Unified CM Session Management Edition に送信された発信側情報は、Unified CM Session Management Edition がコール ルーティングに使用できるようリーフ システムのローカル形式からユニバーサルなグローバル形式に変換する必要があります。

着信側の正規化

リーフ システムから Unified CM Session Management Edition へのコールの着信側情報も、できる限りリーフ システムで正規化する必要があります。全体の E.164 ベースのダイヤル プランが何らかの形式のオンネットの内線番号ダイヤリング(たとえば、アクセス コード、サイト コード、および DN に基づく)もサポートする場合、このオンネットの内線番号ダイヤリング手順の正規化はリーフ システムで実行できません。これは、Unified CM Session Management Edition のみに、すべてのサイト コードとその個々の同等の E.164 番号とのグローバル マッピングが存在するためです。

発信のリーフ Unified CM トランクでこの正規化を実行するには、次のものを使用します。

発信の着信側変換 CSS

発信の発信側変換 CSS

デバイスまたは電話番号レベルでの発信番号変換

リーフ レベルでの正規化が不可能な場合、Unified CM Session Management Edition は次のものを使用して着信トランクまたはゲートウェイで発信者番号および着信者番号情報のリーフ システム固有の正規化を実行できます。

着信する発信側変換 CSS、および

着信する着信側変換 CSS(H.323 のみ)、または

トランクの着信 CSS に関連付けられたトランスレーション パターン


) 着信の着信側変換 CSS は、SIP トランクおよび MGCP ゲートウェイで利用できません。SIP トランクおよび MGCP ゲートウェイで着信の着信者番号を正規化する場合は、トランクの着信 CSS に関連付けられたトランスレーション パターンを使用します。


Unified CM Session Management Edition からリーフ システムへのコールの番号正規化

着信側および発信側の正規化

リーフ システムのダイヤル プランが、Unified CM Session Management Edition での中心的なルーティングのために定義されたグローバル番号計画をサポートしない場合、リーフ システムに送信された発信側および着信側の情報は、リーフ システムでサポートされる番号形式に正規化する必要があります。

この正規化は、次のものを使用して発信の Unified CM Session Management Edition トランクで実行できます。

発信の着信側変換 CSS

発信の発信側変換 CSS

また、この正規化は、次のものを使用して着信リーフクラスタ トランクで実行することもできます。

着信する発信側変換 CSS、および

着信する着信側変換 CSS(H.323 のみ)、または

トランクの着信 CSS に関連付けられたトランスレーション パターン


) 着信の着信側変換 CSS は、SIP トランクおよび MGCP ゲートウェイで利用できません。SIP トランクおよび MGCP ゲートウェイで着信の着信者番号を正規化する場合は、トランクの着信 CSS に関連付けられたトランスレーション パターンを使用します。


図 34 リーフ Unified CM および Unified CM Session Management Edition クラスタでの番号正規化を示す UC の設計

図 35 Unified CM Session Management Edition クラスタのみでの番号正規化を示す UC の設計

一般的な番号計画に関する推奨事項

複雑なシステムに発信側および着信側の情報の複数の変換が加わるため、E.164 番号に基づいて単一のグローバル番号計画を定義し、+E.164 番号に基づいて Unified CM Session Management Edition とリーフ システムでもダイヤル プランを作成することが推奨されます。これにより、Unified CM Session Management Edition からのリーフ間コールに対する複数の発信側および着信側番号変換の必要がなくなります。一部の状況では、リーフ システム ダイヤル プランとユーザのダイヤリング手順が Unified CM Session Management Edition ダイヤル プランで使用された番号形式と異なることがあります。

図 36 +E.164 の番号指定および E.164 ダイヤリング

Unified CM Session Management Edition/Unified CM トランク プロトコルおよび + 文字転送

Unified CM Session Management Edition クラスタを通過する着信者番号と発信者番号には +E.164 形式を使用することが推奨されます。着信者番号および発信者番号で + 文字を転送する Unified CM Session Management Edition トランクの機能はプロトコル固有です。+ 文字をサポートしないプロトコルの場合、番号の受信後に + 文字を再挿入するには簡単な回避策がいくつかあります。

プロトコル タイプごとの + 文字のサポートの概要は次のとおりです。

SIP トランクは + 文字をサポートします。

H.323 トランクは + 文字をサポートしません(+ 文字は H.323 の仕様でサポートされません)。

MGCP Q.931 トランクは + 文字をサポートしません(+ 文字は MGCP Q.931 の仕様でサポートされません)。

SIP トランクおよび + 文字

SIP プロトコルは +E.164 番号を発信側番号および着信側番号としてサポートしません。+E.164 発信側番号および着信側番号は、テクノロジーごとの変換なしで SIP トランク全体に送信できます。

+ 文字は、SIP トランクを介して Q.SIG で送信された発信側および着信側の情報のトンネル情報要素の一部としても送信されます。

図 37 SIP トランクでの番号操作

H.323 トランクおよび + 文字

H.323 は +E.164 番号を転送できません。+ 文字は H.323 トランクを介して送信されるときに削除されます。ただし、H.323 は番号計画と番号ごとのタイプの概念をサポートします。これに基づき、H.323 トランクを介した番号転送を定義する次の 2 つのオプションを使用できます。

共通の番号タイプ(ISDN International など)を使用してすべての番号を +E.164 として送信します。デバイス プールまたはサービス パラメータで、H.323 トランクの、着信する着信側および発信側の設定において、選択番号タイプのプレフィクスとして「+」を設定することにより、+ 文字は送信時に削除され、受信側でプレフィクスとして付加されます。この方法は、トランクを介して送信されるすべての番号が +E.164 に正規化される場合のみ使用できます。トランクを介して他の番号タイプも使用する必要がある場合は、次の方法を使用します。

送信側で適切な発信側および着信側変換 CSS を使用すると、トランクで送信された発信側および着信側の情報には、適切な番号計画およびタイプの設定が適用されます。一般的に、すべての完全な E.164 を計画 ISDN とタイプ international として送信し、他のすべての番号を計画 unknown とタイプ unknown として送信します。受信側では、デバイス プールまたはサービス パラメータで、トランクの、着信する着信側および発信側の設定において、+ 文字を国際番号のプレフィクスとして設定する必要があります。番号タイプ unknown の場合、トランクまたはデバイス プール レベルの、着信する着信側および発信側変換 CSS を使用して適切な番号変換を適用できます。

+ 文字は、H.323 トランクを介して Q.SIG で送信された発信側および着信側の情報のトンネル情報要素の一部として送信されません。

図 38 H.323 トランクおよびゲートウェイでの番号操作

MGCP Q.931 トランクおよび + 文字

MGCP は +E.164 番号を転送できません。+ 文字は MGCP トランクを介して送信されるときに削除されます。H.323 トランクのように、MGCP トランクは、着信と発信の発信者番号に対して番号計画およびタイプ マッピングの概念と変換 CSS をサポートします。

また発信の着信者番号は、番号計画、タイプ マッピング、および変換 CSS をサポートします。ただし、着信の着信者番号は、番号計画、タイプ マッピング、および変換 CSS をサポートしません。着信の着信者番号にプレフィクスとして + 文字を付加する場合は、MGCP トランクの着信 CSS に関連付けられた MGCP トランクまたはトランスレーション パターンで prefix-DN 機能を使用します。

+ 文字は、MGCP トランクを介して Q.SIG で送信された発信側および着信側の情報のトンネル情報要素の一部として送信されません。

図 39 MGCP ゲートウェイでの番号操作

転送されたコールおよび転送情報

一般的に、UC システム内でルーティングされる着信者番号と発信者番号には、番号形式の考慮と正規化が必要です。このコンテキストでは転送情報も考慮する必要があります。転送情報については、次の項で説明します。

通常、UC システムは次の 2 つの状況で転送情報を送信します。

[全てのコールの転送(Call Forward All)] を使用してコールが別の番号に転送される場合。たとえば、着信側の携帯電話番号や別の内線番号などがあります。

一般的に [無応答時転送(Call Forward No Answer)] または [話中転送(Call Forward On Busy)] を使用してコールがボイスメール システムに転送される場合。

トランクおよびゲートウェイを介して転送されたコールの転送情報を送受信するには、次の手順に従います。

MGCP ゲートウェイ、H.323 ゲートウェイ、および H.323 トランクで着信および発信の [番号 IE 配信のリダイレクト(Redirecting Number IE Delivery)] を有効にします。

SIP トランクで着信および発信の [Diversion ヘッダー配信のリダイレクト(Redirecting Diversion Header Delivery)] を有効にします。

転送情報の正規化に関する特別な考慮事項

H.323 トランクおよびゲートウェイ

H.323 リダイレクト番号情報要素(IE)で送信された転送情報は、リダイレクト元の DN に割り当てられたボイスメール プロファイルのボイスメールボックス マスクで定義された発信側変換のみを取得します。ルート パターン、ルート リスト、または発信の発信側変換 CSS で定義された発信側変換は、転送情報に適用されません。

ボイスメールボックス マスクが +E.164 マスクとして定義された場合、H.323 リダイレクト番号 IE 内の転送情報は、+ 文字を転送します。H.323 発信側および着信側 IE は + 文字を転送しないことに注意してください。

SIP トランク

SIP Diversion ヘッダーで送信された転送情報は、リダイレクト元の DN に割り当てられたボイスメール プロファイルのボイスメールボックス マスクで定義された発信側変換のみを取得します。ルート パターン、ルート リスト、または発信の発信側変換 CSS で定義された発信側変換は、転送情報に適用されません。

ボイスメールボックス マスクが +E.164 マスクとして定義された場合、SIP Diversion ヘッダー内の転送情報は、+ 文字を転送します。SIP トランクも + 文字発信側番号および着信側番号を転送できます。

MGCP トランク

MGCP リダイレクト番号 IE で送信された転送情報は、リダイレクト元の DN に割り当てられたボイスメール プロファイルのボイスメールボックス マスクで定義された発信側変換のみを取得します。ルート パターン、ルート リスト、または発信の発信側変換 CSS で定義された発信側変換は、転送情報に適用されません。

ボイスメールボックス マスクが +E.164 マスクとして定義された場合、MGCP トランク リダイレクト番号 IE 内の転送情報は、+ 文字を転送します。MGCP トランク発信側および着信側 IE は + 文字を転送しないことに注意してください。

Q.SIG 対応トランク

Q.SIG 対応トランク(MGCP、H.323、または SIP トランク)を介して Q.SIG APDU で送信された転送情報は、発信側の変更をまったく取得せず、ボイスメールボックスマスクの設定を反映しません。Unified CM により送信された Q.SIG 転送情報は、変換の適用なしでリダイレクト元の DN に常に送信されます。

リダイレクト元の DN を +E.164 として設定すると、先頭の + 文字は削除され、Q.SIG 転送情報は + 文字なしで E.164 番号のみを転送します。

すべての Q.SIG トランク タイプに関する考慮事項

Q.SIG トンネリングが有効な H.323、MGCP、および SIP トランクでは、発信、着信、およびリダイレクト番号情報を含むすべての番号情報は、外側 H.323 メッセージまたは SIP ヘッダーからではなくカプセル化された Q.SIG メッセージから常に取得されます。この Q.SIG トランク操作を行うには、Unified CM Session Management Edition と、サービスを提供する複数のリーフ システムに集中化されたボイスメール システムに対して特別な設計を考慮しなければならないことがあります。これについては、 転送情報および集中型ボイスメール:推奨事項のまとめで説明します。

転送情報および集中型ボイスメール:推奨事項のまとめ

一般的な推奨事項として、グローバルで一意な一律のダイヤル プランをすべての UC システムで実装し、円滑なエンドツーエンド Q.SIG 実装を有効にします。

グローバルで一意なダイヤル プランをすべての UC システムで実装する場合であっても、番号形式はすべてのリーフ UC システムで同じでないことがあります。この例としては、あるリーフ UC システムが E.164 の番号指定を使用し、他のリーフ UC システムが 8XXXYYYY の番号指定を使用する実装があります。

Q.SIG をリーフ システムと Unified CM Session Management Edition クラスタ間のすべてのトランクで使用する場合、これらのリダイレクト元の E.164 および 8XXXYYY ベースの番号は、集中型ボイスメール システムに送信する前に正規化できません。この制限により、各リーフ UC システムのユーザ用の集中型ボイスメールボックス番号は、各リーフ システムで使用される電話番号の番号形式に対応している必要があります。

次の例を参考にしてください。

8XXXYYYY 形式の電話番号を持つユーザは、同じ 8XXXYYYY 形式を使用するボイスメールボックス番号を持つ必要があります。

E.164 形式の電話番号を持つユーザは、同じ E.164 形式を使用するボイスメールボックス番号を持つ必要があります。

+E.164 形式の電話番号を持つユーザは、同じ +E.164 形式を使用するボイスメールボックス番号を持つ必要があります。

注:Cisco Unity などの一部のボイスメール システムでは、ユーザのボイスメールボックスに複数の番号を関連付けることができます。次の例を参考にしてください。

プライマリ VM ボックス番号:E.164

代替 VM ボックス番号:+E.164

プライマリ VM ボックス番号:8XXXYYYY

代替 VM ボックス番号:+E.164

非集中型 PSTN アクセスを持つ集中型テールエンド ホップオフ

Unified CM Session Management Edition を使用して集中型テールエンド ホップオフ(TEHO)ポリシーを実装できます。基本的に、これは、リーフ システムが、各リーフ システムに対してローカルの宛先に送信されないすべてのコールを Unified CM Session Management Edition に送信する必要があることを意味します。これには、リーフがゲートウェイを持つ PSTN への国内コールも含まれることがあります。

Unified CM Session Management Edition のダイヤル プランは、リーフに対してローカルと認識されたプレフィクスだけでなく、特定のリーフ システムで発信すべき PSTN 宛先も保持するよう拡張する必要があります。最後に、Unified CM Session Management Edition からトランクのリーフ クラスタに着信するコールを PSTN に発信できるようにする必要があります。これを実現するには、ローカルの PSTN 発信ポイント(トランクまたはゲートウェイ)を示すルート パターンが、Unified CM Session Management Edition からリーフ クラスタへのトランクで着信コールのコーリング サーチ スペースにより指定できる必要があります。

リーフ システムまたはサイトごとに異なるTEHO ポリシーが必要な場合、Unified CM Session Management Edition ダイヤル プランの TEHO 部分をリーフ システム固有にする必要があります。そのためには、該当するリーフからのトランクで適切な着信コーリング サーチ スペースを使用するか、発信側情報に基づいてルーティングする Unified CM Session Management Edition の機能(『Cisco Communications Manager Features and Services Guide』を参照)とダイヤル プランの上記の TEHO 部分を組み合わせる必要があります。詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmfeat/fshotline.html#wp1422478 にある『Cisco Communications Manager Features and Services Guide』の「Hotline」の章の「Configuring Call Screening With Calling Party Number Routing」の項を参照してください。

図 40 送信元固有 TEHO ポリシー

TEHO ダイヤル プランで明示的に定義されない宛先へのコールが送信元クラスタに戻るよう次の 2 つの異なる方法を実装できます。

トランク固有ヘアピニング

ローカル ルート グループ(LRG)を使用するヘアピニング

トランク固有ヘアピニング

トランク固有ヘアピニングを実装するには、トランク固有の着信 CSS と、特定のトランクを直接示し返す適切な catchall ルート パターン(「!」など)を保持するトランク固有パーティションが必要です。この方法では、Unified CM Session Management Edition で着信トランクごとに 1 つの CSS、1 つのパーティション、および 1 つのルート パターンが必要です。

ローカル ルート グループ(LRG)を使用するヘアピニング

ヘアピニングを単純化するために、次のことを行います。

リーフ トランクごとに専用デバイス プールを作成し、トランクを各デバイス プールに配置します。

トランクごとにルート グループを作成し、トランク固有デバイス プールでトランク固有ルート グループを LRG として設定します。

LRG を示す単一の catchall ルート パターン(「!」など)を作成します。

この方法により、catchall ルート パターンが選択されるたびに、コールが、同じトランクを示し返す送信元トランクの LRG にルーティングされます。ダイヤル プランの観点から、この方法では、必要となる設定要素がトランク固有ヘアピニング設定よりも少なくなります。

Unified CM Session Management Edition がリーフ クラスタにコールをルーティングし返す可能性があるため、非集中型 PSTN アクセスを持つ集中型 TEHO ポリシーを実装する場合は、リーフ クラスタにループの回避を実装することが重要です。ルーティング ループを回避するには、リーフ クラスタの Unified CM Session Management Edition からのトランク上にある着信コーリング サーチ スペースがリーフ クラスタに対してローカルな宛先と PSTN ルート パターンのみを指定できるようにする必要があります。

Unified CM Session Management Edition の導入のコール アドミッション制御に関する推奨事項

トランクツートランクの音声およびビデオ コーリングを許可するために、Unified CM Session Management Edition では 2 つの主要な形式のコール アドミッション制御(CAC)を利用できます。1 つはロケーション CAC であり、もう 1 つはリソース予約プロトコル(RSVP)です。この項では、Unified CM Session Management Edition の導入に固有の設計ガイドラインとベスト プラクティスについて説明します。ロケーション CAC、ロケーションベースの RSVP、または RSVP SIP プレコンディションの基本的な機能については説明しません。以下の設計ガイドラインの前提条件として、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html にある『Cisco Unified Communications System Release 8.x SRND』の「Call Admission Control」の章を参照することを強く推奨します。

この項では、「CAC ドメイン」という用語は、ロケーション CAC や RSVP などの単一 CAC メカニズムにより管理されるネットワークの領域を表すために使用されます。ロケーション CAC に関連する場合、CAC ドメインという用語はロケーション CAC が単一クラスタ(リーフ クラスタまたは Unified CM Session Management Edition クラスタのどちらであっても)により管理されることも意味します。これは、ロケーション CAC は単一クラスタ認識であり、ロケーション情報がクラスタ間で通信されないためです。クラスタがクラスタ間でロケーション情報を通信することを可能にする、クラスタ間トランクを介したロケーションベースのコール アドミッション制御と呼ばれるメカニズムがありますが、使用範囲が限定されるため、適用される場合に特別に記述します。

CAC ドメインの Unified CM Session Management Edition Management とロケーション CAC

Unified CM Session Management Edition では、ロケーション CAC を使用してリーフ クラスタ、サードパーティ IP PBX、および TDM ゲートウェイの代わりに帯域幅を限定された方法で管理できます。ロケーション CACは、異なるロケーションにあるデバイス間で発信された音声およびビデオ コール用の帯域幅を 1 つのクラスタ内で追跡する、基本のスタティック CAC メカニズムです。ロケーションは、単一の WAN アップリンクが存在する物理的なサイトと同等です。ロケーション CAC では、クラスタをまたいだ通信は行われません。つまり指定されたクラスタ内にだけ適用されます。したがって、ロケーション CAC を使用したマルチクラスタ分散型 Unified CM 導入のサポートには多くの制限があります。ただし、Unified CM Session Management Edition は、メディアが、キャンパスに配置されているリーフ クラスタ デバイスから発信されるか、そこで終端するトランクまたはトランクのセットにロケーションを関連付けることでロケーション CAC を活用できます。

図 41 に、2 つのキャンパス サイトに対する Unified CM Session Management Edition の CAC ドメイン管理の例を示します。左のキャンパス サイトで同じ場所にある 2 つのリーフ クラスタは、同じ物理キャンパスのエンドポイントとデバイスを管理します。別のリーフ クラスタは、別のキャンパス導入にあります。任意のサイト間およびクラスタ間のコールは、処理のため Unified CM Session Management Edition に送信されます。この場合、Unified CM Session Management Edition クラスタでは、次の 2 つのロケーションが設定されています。リーフ クラスタ 1 と 2 の両方のトランクに関連付けられたロケーション 1 およびリーフ クラスタ 3 のトランクに関連付けられたロケーション 2 です。

この設計では、Unified CM Session Management Edition は、ロケーションをそれぞれのキャンパスでリーフ クラスタを指すトランクに関連付けることで、キャンパス サイト WAN エッジ アップリンク用の CAC を管理します。

図 41 Unified CM Session Management Edition による 2 つのキャンパス サイト用の CAC 管理

リーフ 1 からリーフ 2 への任意のコールは、コール アドミッション制御されません。これは、リーフ 1 とリーフ 2 のトランクが両方とも Unified CM Session Management Edition 構成で同じロケーションにあるためです。リーフ 3 とリーフ 1 や 2 の間のコールは、それぞれのロケーションの音声プールまたはビデオ プールから差し引かれます。

ロケーション CAC を使用する CAC ドメインを管理するリーフ クラスタ

Unified CM Session Management Edition の設計では、リーフ クラスタはロケーション CAC を使用してそれぞれの CAC ドメインの維持および管理もできます。この場合、Unified CM Session Management Edition はリーフ クラスタのアドミッション制御管理に対して透過的です。次の重要なガイドラインに従い、ロケーション CAC がそれぞれのクラスタで正しく機能することを確認します。

シスコは、1 つのクラスタだけで単一の WAN エッジの帯域幅を保護することを推奨します。これは、異なるクラスタに登録されているが、同じ物理的なサイトにあり、サイト間のコールに対して同じ WAN エッジ アップリンクを使用するエンドポイントがある設計で発生する場合があります。これらの場合にロケーション CAC を使用すると、それぞれのクラスタに管理される帯域幅では、クラスタ間で通信が行われません。このシナリオを効果的に管理する唯一の方法は、クラスタ間の WAN エッジ帯域幅を分割して、各クラスタが WAN エッジ帯域幅のそれぞれの部分を管理することです。ただしこれは、メディアが WAN エッジを通過せず、サイトの LAN にとどまる場合、クラスタ間コールで帯域幅の差し引きにつながることがあります。これは、WAN エッジをオーバーサブスクライブさせませんが、WAN エッジ帯域幅の使用が非効率的なため、推奨されません。

クラスタ間コールでは、コール転送または転送の場合に帯域幅の二重カウントを避けることが重要です。コールが転送されるか、発信元リーフ クラスタおよび発信元ロケーションに戻される場合がこれに該当します。このようなコール シナリオでは、転送する、または自動転送するリーフ クラスタでシグナリングがヘアピンされます。図 42 および図 43 でこのシナリオを説明します。

図 42 では、ロケーション B(ブランチ 1、クラスタ 1)のデバイスおよびロケーション F(ブランチ 2、クラスタ 2)の間でコールが確立されます。クラスタ 1 は、80 k の帯域幅をロケーション B から差し引き、クラスタ 2 は、80 k の帯域幅をロケーション F から差し引きます(クラスタ間の G.711 音声コール)。Unified CM Session Management Edition へのクラスタ間トランク(ICT)および Unified CM Session Management Edition からリーフ クラスタへのクラスタ間トランク(ICT)は、ロケーション帯域幅が無制限(デフォルト:設定不可)に設定されている Hub_none ロケーションに配置されていることに注意してください。シグナリングとは異なり、メディア接続は 2 ブランチ間で直通であるため、ロケーション CAC を使用したそれぞれのブランチの WAN エッジを保護することが重要です。

図 42 ロケーション CAC の設計

図 43 では、ロケーション F のエンドポイントは、ロケーション B(ブランチ 1、クラスタ 1)の別のエンドポイントにコールを転送します。この時点で、クラスタ 2 は、そのエンドポイントがコールシグナリング処理中ではないため、ロケーション F から帯域幅の差し引きを削除します。ただし、クラスタ 2 からクラスタ 1 への発信は、クラスタ 2 のトランクをまたいで Unified CM Session Management Edition にヘアピンされ、Unified CM Session Management Edition と次にクラスタ 1 の両方による発信として処理されます。したがって、この場合クラスタ 1 は、ロケーション B のエンドポイントへの発信用にさらに 80 k の帯域幅を差し引きます。つまりロケーション B の 2 つのデバイス間コールに対して、ロケーション B から合計 160 k の帯域幅が差し引かれることになります。このような非効率的なコール シグナリング パスは、クラスタ 1 がロケーション B のエンドポイントと Unified CM Session Management Edition への ICT 間に確立された 2 つの別々のコール用に、CAC 帯域幅を予約する状況を作り出します。ロケーション B の 2 つのエンドポイントには互いに確立したメディアがあるため、実際にはメディアは WAN エッジを通過しません。偶然、これはクラスタ 2 でヘアピンされるコール シグナリングによるものであったということです。

図 43 ロケーション CAC の設計

ロケーション CAC がリーフ クラスタで管理される場合、この帯域幅の二重カウントのシナリオを回避するには、次の 2 つの方法があります。

クラスタ間トランク上のロケーション ベースのコール アドミッション制御(Phantom ロケーションとも呼ばれます)

Q.SIG パス置換

クラスタ間トランク上のロケーション ベースのコール アドミッション制御

以前は、コールが ICT を介したクラスタをまたいで発信されて、同じロケーションまたは同じクラスタのサイトにヘアピンされる場合、メディアは同じサイトまたはロケーションの 2 つのエンドポイント間で交換されましたが、Unified CM ロケーション CAC はロケーション帯域幅を 2 回、発信コール用に 1 回と着信コール用にもう 1 回差し引いていました。その結果は帯域幅使用量を正しく反映しておらず、十分な帯域幅がまだ存在していた場合に、最終的にサイトまたはロケーションへの、あるいはサイトまたはロケーションからの発信拒否の原因となっていました。

帯域幅計算の問題を解決するために、クラスタ間トランク上のロケーション ベースのコール アドミッション制御機能によって、Unified CM は、ICT を介した発信側および着信側の間で H.323 または SIP プロトコルによって、ロケーション情報(ロケーション データおよびロケーション名のプライマリ キー ID(PKID))を独自の情報要素(IE)として渡せるようになります。このため、それぞれのクラスタに ICT のロケーション情報ではなく、相手またはエンドポイントの正確なロケーション情報が通知されます(例として 図 44 および 図 45 を参照)。

Phantom ロケーションとして指定された Unified CM ロケーションが、この種のアプリケーション用の ICT に対して作成されます。ロケーション サーバは、Phantom ロケーションに割り当てられたデバイス用の帯域幅を差し引きません。Phantom ロケーションに割り当てられた ICT などのデバイスは、クラスタをまたいで接続されたデバイスの正確なロケーションを使用します。

図 44 に、ロケーション B(ブランチ 1、クラスタ 1)のデバイスおよびロケーション F(ブランチ 2、クラスタ 2)の間で確立されたコールに対するシナリオを示します。クラスタ 1 は、80 k の帯域幅をロケーション B から差し引き、クラスタ 2 は、80 k の帯域幅をロケーション F から差し引きます(クラスタ間の G.711 音声コール)。コール シグナリングがクラスタ 1 から Unified CM Session Management Edition に送信される際、ロケーション B の情報は IE(図 44、ステップ 1)に送信され、次にこの同じ情報が再び Unified CM Session Management Edition からクラスタ 2(図 44、ステップ 2)に送信されます。ロケーション F のデバイスに関する情報は、同じ方法で Unified CM Session Management Edition を介して、クラスタ 2 からクラスタ 1 へも送信されます。この例ではロケーション B の情報だけが示されていますが、このようなロケーション情報交換は両方向で行われます。

Unified CM Session Management Edition への ICT および Unified CM Session Management Edition からリーフ クラスタへの ICT が、Phantom ロケーションに存在することに注意してください。Phantom ロケーションでは、ロケーション帯域幅は無制限(CAC に対して実質的に追跡されない)に設定され、ロケーション B の発信側に関するロケーション情報は ICT をまたいで送信されます。

この時点で、クラスタ 2 は Unified CM Session Management Edition から受信したコールがロケーション B に関連付けられることを認識します。クラスタ 2 はこの情報しか使用せずに、ICT 上のその特定コールをそのロケーション IDに関連付けて、ロケーション B に対して一切帯域幅の差し引きを処理しません

図 44 ロケーション CAC の設計

図 45 ロケーション CAC の設計

図 45 で、転送後、クラスタ 2 は ICT 上のコールをヘアピンして、クラスタ 1 にロケーション B の情報を送信します(Unified CM Session Management Edition 経由。ステップ 3 および 4)。ロケーション B の情報は元々クラスタ 1 から受信したものです(Unified CM Session Management Edition 経由。ステップ 1 および 2)。このように、クラスタ 1 に、クラスタ 2 から受信した着信コールが、クラスタ 1 のロケーション B の発信元デバイスに対してのものであったことが通知されます。これにより、クラスタ 1 は、同じロケーションの 2 つのエンドポイントに対する 2 つのコールのために差し引かれた帯域幅を戻せるようになります。

詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmsys/a02cac.html#wp1113777 にある『Cisco Unified Communications Manager System Guide』の「Call Admission Control」の章の「Location-Based Call Admission Control Over Intercluster Trunk」の項を参照してください。

Q.SIG パス置換

Q.SIG パス置換機能は、Q.SIG ICT が設定されているリーフ クラスタ間のコール シグナリング パスを最適化します。コール シグナリング パスを最適化する場合、ロケーション帯域幅はコール シグナリングが解放されるロケーションに戻されます。Q.SIG パス置換機能が動作する方法の詳細については、 クラスタ間トランクを介した Q.SIG パス置換の項を参照してください。

RSVP 導入での Unified CM Session Management Edition

Unified CM Session Management Edition を、クラスタ間で SIP プレコンディションのサポートあり、またはサポートなしの複数の RSVP 導入に配置できます。UC の設計における RSVP の概要については、また次の内容への前提条件として、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html にある『Cisco Unified Communications System Release 8.x SRND』の「Call Admission Control」の章の「Unified Communications Architectures Using Resource Reservation Protocol (RSVP)」の項を参照してください。その項には、「Unified CM RSVP-Enabled Locations」および「RSVP SIP Preconditions」の詳細なサブセクションが含まれます。

RSVP SIP プレコンディション サポートのないリーフ クラスタを使用した Unified CM Session Management Edition の設計

リーフ クラスタ内でローカルに独自の CAC サポートを維持するリーフ クラスタを使用した Unified CM Session Management Edition を導入できます。リモート サイトの独自のデバイスに対してリーフ クラスタが独自の CAC メカニズムを管理する導入であるか、またはそれらのリーフ クラスタがキャンパス導入内にあり、クラスタ内コール(リーフ クラスタ内にとどまっているコール)に CAC を必要としない導入である場合、Unified CM Session Management Edition を活用して、RSVP を使用したそれらのリーフ クラスタ間の音声およびビデオ コール(クラスタ間コール)用の CAC を管理できます。これらの場合、Unified CM Session Management Edition は、RSVP Agent を活用してリーフ クラスタ間のリンクをまたがった CAC を処理しますが、クラスタ内コールに対してリーフ クラスタが管理するリンク用の CAC を管理しません。

このような導入の要件は次のとおりです。

リーフ クラスタの CAC は、クラスタ内コールを管理します。

Unified CM Session Management Edition の RSVP 対応ロケーションの CAC は、クラスタ間コールを管理します。

Unified CM Session Management Edition により管理されたクラスタ間コールの WAN 帯域幅を、リーフ クラスタにより管理されたクラスタ内コールの WAN 帯域幅と共有しないことを強く推奨します。同じ WAN リンクからの帯域幅が 2 つの別々の CAC メカニズムによって管理される場合、2 つの別々の CAC メカニズムは実質的にお互いを認識しないため、帯域幅の二重カウントの可能性があります。

図 46 に、異なるリージョン サイトに導入され、クラスタ間接続に Unified CM Session Management Edition を使用する 2 つのリーフ クラスタを示します。リーフ クラスタ 1 は、ロケーション CAC を使用して CAC ドメインにあるリモート サイトを管理しますが、リーフ クラスタ 2 は、RSVP を使用して CAC ドメインにあるリモート サイトを管理します。この場合、Unified CM Session Management Edition は、リモート RSVP Agent を使用することにより、RSVP 対応ロケーションを活用して、リーフ クラスタ間の CAC ドメインを管理します。リモート RSVP Agent は、Unified CM Session Management Edition に登録され、メディア リソース グループおよびリスト(MRGL)機能を介してリーフ クラスタ トランクに関連付けられた標準の RSVP Agent です。ただし、リモート RSVP Agent は、物理的にキャンパス サイトに配置されるか、リーフ クラスタと同じ場所に配置されるため、Unified CM Session Management Edition クラスタから「リモート」となります。これらの RSVP Agent は、リーフ クラスタを相互接続し、RSVP のサポートが有効化されたヘッドエンド ネットワーク WAN にある必要があります。

図 46 SIP プレコンディション サポートのないリーフ クラスタを使用した Unified CM Session Management Edition の設計

図 47 で、リーフ 1 およびリーフ 2 の間のコール設定のためのコール フローは次のように動作します。

1. リーフ 1 は、H.323 または SIP クラスタ間トランク上の Unified CM Session Management Edition へのコールを設定します。Q.SIG パス置換サポートが優先されるため、Unified CM のリリース 8.5 よりも前のリリースには H.323 を使用し、Unified CM Release 8.5 およびそれ以降のリリースとともに SIP を使用するようにします。

2. Unified CM Session Management Edition は、リーフ 1 からコールを受信し、2 つの RSVP Agent を割り当てます(RSVP Agent は、メディア リソース グループおよびリスト(MRGL)機能によってトランクに関連付けられます。図 46 を参照)。それらが割り当てられたあと、RSVP Agent は、その間のパス上の帯域幅を予約します。

3. 帯域幅の要求が成功した場合、コールは Unified CM Session Management Edition から、SIP または H.323 クラスタ間トランク上のリーフ 2 まで拡張されます。予約が失敗した場合、コールはリーフ 2 まで拡張されず、Unified CM Session Management Edition のコール処理の設定に応じて、コールが別の場所に拡張されるか、リーフ 1 から切断されます。

図 47 SIP プレコンディション サポートのないリーフ クラスタを使用した Unified CM Session Management Edition の設計


) ステップ 3 でコールがリーフ 2 に拡張される場合、リーフ 2 はロケーション CAC または RSVP を、そのコール レッグに対するアドミッション制御として使用できます。RSVP が 図 47 のように使用されている場合、リーフ 2 は RSVP Agent を、Unified CM Session Management Edition を指す SIP トランクに関連付けます。また RSVP Agent は着信側エンドポイントと関連付けられます。



) リーフ クラスタが RSVP をローカルに実行し、SIP プレコンディションがない場合、Unified CM Session Management Edition のリモート RSVP Agent およびトランクに関連付けられた Unified CM Session Management Edition へのリーフ クラスタの RSVP Agent は同じルーティング プラットフォームの同じ場所に設置できます。詳細については、 RSVP Agent のための複数クラスタによる単一プラットフォームの共有を参照してください。


RSVP SIP プレコンディション サポートのあるリーフ クラスタを使用した Unified CM Session Management Edition の設計

RSVP を使用して CAC ドメインを管理し、RSVP SIP プレコンディションをサポートするリーフ クラスタを使用した Unified CM Session Management Edition を導入できます。詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html#wp1191628 を参照してください。

この場合、Unified CM Session Management Edition は、RSVP SIP プレコンディションを使用したクラスタ間トランクをイネーブルにします。また、SIP プレコンディションをリーフ クラスタからリーフ クラスタへ渡し、エンドツーエンドの RSVP Agent 導入を可能にします。

このような導入の要件は次のとおりです。

クラスタは、リリース 8.0 以降のリリース(可能であればリリース 8.6.1)を導入します。

リーフ クラスタは、Unified CM RSVP 対応ロケーションを使用してクラスタ内コールを管理します。詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html#wp1190645 を参照してください。

Unified CM Session Management Edition は、RSVP SIP プレコンディションをリーフ クラスタからリーフ クラスタへ渡すように設定された SIP ICT を使用したクラスタ間コールを管理します。

パス置換のある Q.SIG を、すべての SIP ICT 上でコールの転送および自動転送用にコール シグナリングを最適化できるようにする必要があります。(これには Unified CM Release 8.5 以降のリリースが必要です)。

図 48 に、リーフ クラスタにクラスタ内コール用の Unified CM RSVP 対応ロケーション、および両方のリーフ クラスタで設定された SIP ICTがあり、RSVP SIP プレコンディションを使用して Unified CM Session Management Edition をイネーブルにする、説明済みのソリューションを示します。Unified CM Session Management Edition は、SIP プレコンディションをリーフの Unified CM からリーフの Unified CM へ渡し、結果的にそれらのプレコンディションをブランチの RSVP Agent まで伝えます。これにより、複数のクラスタ境界をまたいでブランチからブランチまで直接エンドツーエンドの RSVP 予約ができます。

図 48 SIP プレコンディション サポートのあるリーフ クラスタを使用した Unified CM Session Management Edition の設計

混合リーフ クラスタを使用した Unified CM Session Management Edition の設計(RSVP SIP プレコンディション サポートのありとなし)

Unified CM Session Management Edition は、次のような混合環境をサポートできます。(i)1 つのトランクで、リーフ クラスタへのトランクの RSVP SIP プレコンディションをサポートします。このリーフ クラスタは RSVP(ローカル)および RSVP SIP プレコンディションをサポートしています(例については、図 49 のリーフ 2 を参照)。(ii)別のトランクで、Unified CM Session Management Edition が、RSVP Agent を関連付け、クラスタへのトランクに対して RSVP をローカルに実行します。このクラスタは、RSVP SIP プレコンディションをサポートしていません(例については、図 49 のリーフ 1 を参照)。

図 49 混合リーフ クラスタを使用した Unified CM Session Management Edition の設計(SIP プレコンディション サポートのありとなし)

RSVP Agent のための複数クラスタによる単一プラットフォームの共有

場合によっては、複数の Unified CM クラスタをまたいで RSVP Agent をサポートする単一のルータ プラットフォームを共有する必要がある可能性があります。そのために、Cisco サービス統合型ルータ(ISR)のように、RSVP Agent をサポートする単一のルータ プラットフォームを、複数の RSVP Agent で、また専用ソフトウェア セッションとともに別々の Unified CM クラスタに登録されたそれぞれのエージェントで設定できます。プラットフォームごとにサポートされる RSVP Agent のセッション数については、RSVP Agent データシートを参照してください。

図 50 Unified CM Session Management Edition とリーフ クラスタ:RSVP Agent のための複数クラスタによる単一プラットフォームの共有

Unified CM Session Management Edition のクラスタ導入におけるトランク セキュリティ

Unified CM Session Management Edition の導入でトランク シグナリングと関連メディアの両方を暗号化できます。シグナリングを暗号化せずに、SIP および H.323 トランク経由のコールに対するメディア暗号化をイネーブルにできます。ただし、この場合キーと他のセキュリティ関連情報はトランク接続を介して暗号化されていない状態で送信されます。SIP トランクおよび H.323 トランクは、シグナリングの暗号化に異なるメカニズムを使用します。これらのメソッドを次に説明します。

安全な SIP トランク

安全な SIP トランクには次の 2 つのプロセスが必要です。

メディアを暗号化するようにトランクを設定する

シグナリングを暗号化するようにトランクを設定する

SIP トランクのメディア暗号化

メディア暗号化を SIP トランクで設定するには、トランクの [SRTP を許可(SRTP Allowed)] チェックボックスをオンにします。[SRTP を許可(SRTP Allowed)] をオンにすると、コールのメディアは暗号化されますが、トランクのシグナリングは暗号化されない点に注意してください。結果として、安全なメディア ストリームの確立に使用されるセッション キーは暗号化されていない状態で送信されます。そのため、Unified CM と宛先 SIP トランク デバイス間のシグナリングも暗号化し、キーや他のセキュリティ関連情報がコールのネゴシエーション中に漏洩しないようにすることが重要です。

SIP トランクのシグナリング暗号化

SIP トランクはシグナリング暗号化に TLS を使用します。SIP トランクに関連付けられた SIP セキュリティ プロファイルで TLS を設定します。TLS は、X.509 証明書の交換を使用してトランク デバイスを認証し、シグナリング暗号化をイネーブルにしています。

証明書は、次のいずれかの処理が実行されます。

各 Unified CM ノードの SIP トランク デーモンに対して TLS 接続の確立が必要な各デバイスから、そのノードに対してインポートします。

認証局(CA)から署名されます。この場合、リモート デバイスの証明書をインポートする必要はありません。CA 証明書だけインポートする必要があります。

Unified CM には、証明書の一括インポートおよびエクスポート機能があります。ただし、[すべての Unified CM ノードで実行(Run on All Unified CM Nodes)] 機能と最大 16 の宛先アドレスを使用する SIP トランクの場合、CA の使用によって、管理上の負荷の少ない集中管理的な方法で SIP トランクにシグナリング暗号化を設定できます。

図 51 TLS を使用する SIP クラスタ間トランク

安全な H.323 トランク

安全な H.323 トランクには次の 2 つのプロセスが必要です。

メディアを暗号化するようにトランクを設定する

シグナリングを暗号化するようにトランクを設定する

H.323 トランクのメディア暗号化

メディア暗号化を H.323 トランクで設定するには、トランクの [SRTP を許可(SRTP Allowed)] チェックボックスをオンにします。[SRTP を許可(SRTP Allowed)] チェックボックスをチェックすると、コールのメディアは暗号化されますが、トランクのシグナリングは暗号化されない点に注意してください。結果として、安全なメディア ストリームの確立に使用されるセッション キーは暗号化されていない状態で送信されます。そのため、Unified CM と宛先 H.323 トランク デバイス間のシグナリングも暗号化し、キーや他のセキュリティ関連情報がコールのネゴシエーション中に漏洩しないようにすることが重要です。

H.323 トランクのシグナリング暗号化

H.323 トランクはシグナリング暗号化に IPSec を使用します。IPSec はネットワーク インフラストラクチャで設定するか、Unified CM とリモート ゲートウェイまたはトランク間で設定できます。IPSec を設定するために 1 つのメソッドを実装する場合、他のメソッドを実装する必要はありません。Unified CM サーバで IPSec を使用すると、サーバのパフォーマンスに大きな影響を及ぼす可能性があるため、シスコは Unified CM 自体ではなく、ネットワーク インフラストラクチャに IPSec をプロビジョニングすることを推奨します。

図 52 ルータベースの IPSec トンネルを使用する H.323 クラスタ間トランク

シスコのモバイル ソリューションおよび Unified CM Session Management Edition の導入

Cisco Unified Mobility は、Unified CM に組み込まれたネイティブなモビリティ機能を意味し、次の機能が含まれます。

モバイル コネクト(SNR とも呼ばれます)

モバイル ボイス アクセス(MVA)

エンタープライズ機能アクセス(EFA)

デスクトップ フォンおよびリモート接続先ピックアップ

コール中付加サービス(DTMF 機能アクセス コードを使用)

また Unified CM および Cisco Unified Mobility 機能を活用する多数のモバイル クライアント ソリューションがあります。

Cisco Unified Mobile Communicator

デュアルモード電話およびクライアント(クライアントの例には、iPhone 対応 Cisco Mobile 8.x および Android 対応 Cisco Jabber 8.6 が含まれます)

ダイレクト コネクト モバイル クライアント(クライアントの例には、Nokia 対応 Cisco Mobile 8.5 および今後発表されるすべての Cisco Jabber モバイル クライアント)

BlackBerry MVS

これらの機能、ソリューション、および操作の詳細については、『Cisco Unified Communications System Release 8.x SRND』の「Mobile Unified Communications」の章で説明します。(詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/mobilapp.html#wp1244934 を参照してください)。

Unified CM Session Management Edition ベースの UC 設計では、Cisco Unified Mobility およびモビリティ クライアント ソリューションを次のように導入できます。

リーフ クラスタですべてのモビリティ機能と PSTN アクセスが提供される、標準のリーフ Unified CM クラスタ モビリティ導入

Unified CM Session Management Edition ベースの PSTN アクセスによるリーフ クラスタ モビリティ

Unified CM Session Management Edition を介した PSTN アクセスによる、サードパーティ PBX のモビリティ/シングル ナンバー リーチ サポート

接続されたサードパーティ PBX に対して Unified CM Session Management Edition が提供するモビリティ機能

図 53 Unified CM Session Management Edition とモビリティ導入

Unified CM Session Management Edition ベースの PSTN アクセスによるリーフ クラスタ モビリティ導入

Unified CM Session Management Edition ベースの PSTN アクセスによるリーフ クラスタ モビリティ導入では、次の機能およびソリューションがサポートされます。

モバイル コネクト(SNR とも呼ばれます)

モバイル ボイス アクセス(MVA)

モバイル デバイスでの切断によるデスクトップ フォンのピックアップおよびデスクトップフォンでの復帰

携帯電話へのコールの送信を使用したリモート接続先のピックアップ

Cisco Unified Mobile Communicator

デュアルモードの電話機とクライアント

ダイレクト コネクト モバイル クライアント

BlackBerry MVS


) TDM または IP ベースの PSTN アクセスが可能です。


Unified CM Session Management Edition ベースの PSTN アクセスによるリーフ クラスタ モビリティ導入では、機能の呼び出しのために DTMF トーンを使用する次のモビリティ機能はサポートされません。

エンタープライズ機能アクセス(EFA)

デスクトップ フォンおよびリモート接続先ピックアップ

DTMF 機能アクセス コードによるコール中の補足サービス

モビリティとサードパーティ PBX

図 54 に、サードパーティ PBX を使用した Unified CM Session Management Edition と Unified Mobility の導入を示します。サードパーティ PBX は、モビリティ機能をサポートする場合としない場合があります。次の項では、両方のケースのモビリティ導入について説明します。

図 54 Unified CM Session Management Edition と Unified Mobility の導入:サードパーティ PBX

Unified CM Session Management Edition を介した PSTN アクセスによる、サードパーティ PBX のモビリティ/シングル ナンバー リーチ サポート

Unified CM Session Management Edition クラスタは PSTN との間で PBX コールをルーティングするトランジット スイッチとして機能し、ネイティブのモビリティ機能を提供しないため、これらの導入がサポートされます。


) サードパーティ PBX のモビリティ機能について、シスコは機能の保証やサポートの提供を行うことはできません。実稼動環境に導入する前に、サードパーティ PBX の機能を個別にテストする必要があります。


接続されたサードパーティ PBX に対して Unified CM Session Management Edition が提供するモビリティ機能

このタイプの導入では、サードパーティ PBX はモビリティ機能をネイティブにはサポートしませんが、Unified CM Session Management Edition クラスタをプロキシとして使用し、そのモビリティ機能を利用するために、リモート接続先プロファイルとユーザあたり 2 つ以上のリモート接続先番号/ID を作成します。ユーザの会社の電話番号を使用して、回線レベルでリモート接続先プロファイルを設定します。少なくとも 2 つのリモート接続先番号を設定し、それらの番号をリモート接続先プロファイルに関連付けます。1 つのリモート接続先番号はユーザのサードパーティ PBX 電話機の電話番号で、1 つの追加のリモート接続先番号はユーザの携帯電話番号です。PBX 内線のシングル ナンバー リーチ機能を提供するには、Unified CM Session Management Edition クラスタに各 PBX ユーザの会社の電話番号を設定する必要があります(リモート接続先プロファイルの回線レベルで)。また、Unified CM Session Management Edition を介して PBX 間のすべての着信および発信コールをルーティングする必要があります。さらに、サードパーティ PBX から発信されるコールとシングル ナンバー リーチ対応の PBX 内線を宛先とするコールすべてが、最初に Unified CM Session Management Edition クラスタを介してルーティングされる必要があります。これには通常、シングル ナンバー リーチと接続先 PBX 内線および携帯電話へのリング バックを実行するために、シングル ナンバー リーチ対応の PBX 内線へのコールが最初に Unified CM Session Management Edition クラスタにルーティングされるように、モビリティ対応 PBX ユーザに対する PBX 内線番号の再割り当て、または PBX ダイヤル プランの変換が必要となります。Unified CM Session Management Edition クラスタは、最大 15,000 のリモート接続先をサポートし、最大 7500 のモビリティ対応のサードパーティ PBX ユーザにサポートを提供できます(各ユーザのリモート接続先が、PBX 内線用と携帯電話用の 2 つだけであると仮定した場合)。

上記のタイプの導入では、次のモビリティ機能がサポートされます。

モバイル コネクト(SNR とも呼ばれます)

モバイル ボイス アクセス(MVA)


) TDM または IP ベースの PSTN アクセスが可能です。


上記のタイプの Unified CM Session Management Edition 導入では、機能の呼び出しのために DTMF トーンを使用する次のモビリティ機能はサポートされません。

エンタープライズ機能アクセス(EFA)

デスクトップ フォンおよびリモート接続先ピックアップ

DTMF 機能アクセス コードによるコール中の補足サービス

詳細については、http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns832/962994.pdf を参照してください。

Unified CM Session Management Edition 上のボイスメール アプリケーション

Cisco Unity Voice Mail などのボイスメール アプリケーションは、Unified CM Session Management Edition クラスタに接続し、すべてのリーフ UC システム上のユーザにボイスメール サービスを提供できます。

図 55 Unified CM Session Management Edition と集中型ボイスメール

リーフ クラスタと Unified CM Session Management Edition 間のクラスタ間トランク、およびボイスメール アプリケーションとのトランク接続では、ボイスメールにルーティングされるコールとともに、元の着信側/リダイレクト元番号が送信されることを確認してください。

Q.SIG 非対応トランクの場合:元の着信側/リダイレクト元番号の転送は、次の方法によって有効にできます。

MGCP ゲートウェイ、H.323 ゲートウェイ、および H.323 トランクで着信および発信の [番号 IE 配信のリダイレクト(Redirecting Number IE Delivery)] を有効にします

SIP トランクで着信および発信の [Diversion ヘッダー配信のリダイレクト(Redirecting Diversion Header Delivery)] を有効にします

Q.SIG 対応 SIP、MGCP および H.323 トランクの場合:元の着信側番号は、Q.SIG 転送元レッグ情報 APDU で送信されます。

Q.SIG 対応トランク

Q.SIG 対応トランク(MGCP、H.323、または SIP トランク)を介して Q.SIG APDU で送信される転送情報は、発信側の変更をピックアップせず、ボイスメールボックスのマスク設定にも対応しません。Unified CM によって送信される Q.SIG 転送情報は、変換を適用せずに常にリダイレクト元 DN に設定されます。

リダイレクト元 DN が +E.164 として設定されている場合は、Q.SIG 転送情報に + 文字を含まない E.164 番号だけが保持されるように、先頭の + 文字が削除されます。

すべての Q.SIG トランク タイプに関する考慮事項

Q.SIG トンネリングが有効になっている H.323、MGCP、および SIP トランクでは、発信側、着信側、およびリダイレクト元の番号情報を含むすべての番号情報が、外部の H.323 メッセージや SIP ヘッダーからではなく、常にカプセル化された Q.SIG メッセージから取得されます。この Q.SIG トランクの動作には、Unified CM Session Management Edition に集中化され、複数のリーフ システムにサービス提供するボイスメール システムに特別な設計上の考慮が必要となる場合があります。これについては、 転送情報および集中型ボイスメール:推奨事項のまとめで説明します。

転送情報および集中型ボイスメール:推奨事項のまとめ

一般的な推奨事項として、円滑なエンドツーエンドの Q.SIG 実装を可能にするためには、すべての UC システムにわたって統一された、グローバルに一意なダイヤル プランが実装される必要があります。

すべての UC システムでグローバルに一意なダイヤル プランが実装されていても、番号形式がすべての UC システムで統一されていない場合があります。この例として、一部のリーフ UC システムで E.164 の番号指定が使用され、その他で 8XXXYYYY の番号指定が使用されている実装が挙げられます。

リーフ システムと Unified CM Session Management Edition クラスタ間のすべてのトランクで Q.SIG が使用されている場合、集中型ボイスメール システムに送信される前に、これらの E.164 および 8XXXYYYY ベースのリダイレクト元番号を正規化することはできません。この制限により、各リーフ UC システムのユーザ用の集中型ボイスメールボックス番号は、各リーフ システムで使用される電話番号の番号形式に対応している必要があります。

次の例を参考にしてください。

8XXXYYYY 形式の電話番号を持つユーザ:同じ 8XXXYYYY 形式を使用した、対応するボイスメールボックス番号を設定する必要があります。

E.164 形式の電話番号を持つユーザ:同じ E.164 形式を使用した、対応するボイスメールボックス番号を設定する必要があります。

+E.164 形式の電話番号を持つユーザ:同じ +E.164 形式を使用した、対応するボイスメールボックス番号を設定する必要があります。

注意:Cisco Unity Voicemail では、ユーザのボイスメールボックスに複数の番号を関連付けることができます。次の例を参考にしてください。

プライマリ VM ボックス番号:E.164

代替 VM ボックス番号:+E.164

プライマリ VM ボックス番号:8XXXYYYY

代替 VM ボックス番号:+E.164

ボイスメールでの RDNIS 送信に関する注意事項

Redirected Dialed Number Information Service(RDNIS)は、コールのセットアップ時にコールをリダイレクトした側の番号を提供します。ボイスメールシステムでは、このサービスによって提供される情報を使用して、コールをリダイレクトしたユーザを識別します。この情報がボイスメール システムに送信されることで、コールをリダイレクトした側のメールボックスにメッセージを残すことができるようになります。PRI バリアントでは、この RDNIS 情報は、リダイレクト元番号の情報要素(IE)または(一部のプロトコル実装で)元の着信者番号(OCN)IE の SETUP メッセージで送信されます。Q.SIG プロトコルではこれらの IE が定義されていないため、Unified CM の Q.SIG 実装では、RDNIS サービスはサポートされません。RDNIS を使用する代わりに、Unified CM SIP または H.323 トランクで Q.SIG が有効になっている場合、ボイスメール情報は originalcalledPartyNumber として DivertingLegInformation2 APDU で渡されます。

Cisco Unified Contact Center Enterprise を使用した Unified CM Session Management Edition の導入

Unified CM Session Management Edition は、1 つ以上のリーフ クラスタがコンタクト センター対応である場合、Cisco Unified Contact Center Enterprise(Unified CCE)の設計に導入できます。このようなシナリオで使用されるアーキテクチャには、特定の要件があることに注意してください。Unified CM Session Management Edition と Unified CCE を使用した UC 設計に関する最も重要な導入上の考慮事項は、この項で説明されているとおりです。

SIP プロトコル

Unified CCE は、ソリューション コンポーネントを相互接続するプロトコルとして SIP の使用のみが保証されています。つまり、相互の通信時には、Unified CVP、Unified CM Session Management Edition およびクラスタのすべてが SIP を使用する必要があります。H.323 およびその他の形式のクラスタ間トランクは、コンタクト センターのコール フローではサポートされませんが、ソリューションの他の部分で使用される場合があります。外部(サービス プロバイダー)のトランクは SIP または TDM を使用でき、電話機は、従来の Unified CCE 設計でサポートされる任意のプロトコルを使用できます。

DTMF 転送

RFC2833(インバンド DTMF)は、Unified CVP でのセルフサービス アプリケーションでサポートされている唯一の方式であるため、Unified CCE で推奨される DTMF 転送です。Unified CM Session Management Edition で複雑な MTP プロビジョニングを行う必要をなくすために、クラスタ トランクに DTMF シグナリング方式:RFC2833 を設定する必要があります(Unified CM Session Management Edition トランク自体に特別な設定は必要ありません)。この手順を実行しないと、通常は(Unified CM Session Management Edition を介して)リーフ クラスタから Unified CVP に発信されたコールに対して Unified CM Session Management Edition で MTP が要求されます。従来の Unified CCE 設計の場合のように、リーフ クラスタでの MTP プロビジョニングを実行する必要があることに注意してください。

Unified CM Session Management Edition におけるトランクツートランクの SIP ヘッダーの透過性

Unified CCE および Unified CVP では、多くの場合、SIP ヘッダーを使用してシステム間での情報の受け渡しを行います。Unified CM Session Management Edition は、デフォルトでは、これらの SIP ヘッダーやペイロードの一部を 1 つのトランクから別のトランクに透過的に中継することはありません。ただし、必要であれば、透過性スクリプトを Unified CM Session Management Edition トランクに適用できます。これらのヘッダーの例は、次のとおりです(このリストはすべてを網羅したものではありません)。

Call-Info。システムがコール アドミッション制御(CAC)とリージョン間コーデックの規則を適用できるように、コールの発信元(つまり、発信元ゲートウェイの IP アドレス)を提供するために使用します。これはリーフ クラスタが入力ゲートウェイ ロケーションの情報を必要としている場合にのみ関係します。Unified CM Session Management Edition が CAC を実施している場合や、すべてのゲートウェイが集中化されている場合のものではありません。

GTD(Generic Transparency Descriptor)。SIP メッセージに対する多目的インターネット メール拡張(MIME)ペイロードで、Cisco TDM ゲートウェイが ISDN 情報要素(適切に設定されている場合)を受け渡しするために使用できます。技術的には、GTD は SIP ヘッダーではありませんが、すべて揃えるためにここに記載します。GTD の最も一般的な用途は、Unified CVP との ISDN ユーザ間データの受け渡しと、入力および出力ゲートウェイ間での ISDN 情報の移動です。Unified CM は GTD を使用しないため、GTD に対する Unified CM Session Management Edition の透過性は一般に必要ありません。

カスタム ヘッダー。Unified CCE および Unified CVP 管理者が、お客様の個別のニーズを満たすために作成する場合があります。

Unified CM Session Management Edition は、デフォルトで Cisco-Guid ヘッダーを透過的に中継します。このヘッダーには、ユニバーサル コール ID が含まれます。これにより、トラブルシューティング、レポーティング、および録音のためのエンドツーエンドのトラッキングが可能になります。

Unified CM Session Management Edition におけるトランクツートランクの SIP メッセージの透過性

ヘッダーに加えて、Unified CVP では、Unified CM Session Management Edition がデフォルトで処理するようには設定されていない、異なる SIP メッセージを使用することもあります。これらのメッセージの例は、次のとおりです。

REFER ベースの転送:Unified CVP は、SIP REFER を使用してコールを転送するように設定できます。デフォルトでは、Unified CM は着信 SIP REFER メッセージをダイジェストし、代わりに Re-INVITE メッセージを送信してコールを転送します。REFER メッセージの代わりに Re-INVITE を送信することにより、コールが継続している間、Unified CM クラスタによってコール シグナリングが維持されます。コンタクト センターのお客様によっては、このような to-PSTN コール転送シナリオにおいて、コール メディアとシグナリングの両方をリリースしたい場合があります。これを実現するためには、Lua 透過性スクリプトを作成して、着信 SIP トランクから発信 SIP トランクに REFER メッセージが透過的に送信されるようにします。この場合は、REFER 要求が Re-INVITE メッセージの代わりに発信 SIP トランク経由で転送されます。

302 リダイレクト ベースの転送:コールが完全に応答(SIP 200 OK)される前に転送が起動された場合、Unified CVP は、SIP REFER の代わりに 302 リダイレクト メッセージを送信します。Unified CM Session Management Edition の動作は、REFER ベースの転送に類似しています。

SIP INFO:Unified CVP は、SIP INFO メッセージを送信して DTMF トーンをアウトオブバンドで再生します。これは Transfer Connect のシナリオで使用されます。Unified CM Session Management Edition の動作は、REFER ベースの転送に類似しています。デフォルトでは、INFO メッセージはローカルで処理されるため、Unified CM Session Management Edition がシグナリング パスにある場合は、それらを入力ゲートウェイに中継するために Lua 透過性スクリプトが必要になります。

サポートされる導入モデル

ソリューションの復元性と相互運用性を高めるために、サポートされる Unified CM Session Management Edition の導入モデルでは、次のことに従う必要があります。

外部コール(PSTN)は、Unified CVP に到達する前に Unified CM Session Management Edition を経由しないようにする必要があります。コールは Cisco TDM ゲートウェイまたは Cisco Unified Border Element に到達したあと、直接 Unified CVP に送られる必要があります。または、Cisco ユニファイド SIP プロキシ(ユニファイド SIP プロキシ)を Unified CVP サーバの手前に使用することもできます。

Unified CVP と IOS Voice XML ブラウザ間の SIP シグナリングは、Unified CM Session Management Edition を経由しないようにする必要があります。これらはユニファイド SIP プロキシを経由することができます。

Unified CM Session Management Edition は、コールが Unified CVP から出て行く際に使用できるので、エージェントが存在する Unified CM クラスタにコールをルーティングするのに Unified CM Session Management Edition が使用されます。

図 56 に、このコール フローを示します。

図 56 サポートされる Unified CM Session Management Edition および Unified CCE の導入

この導入モデルでは、通常、透過性スクリプトは必要ありません。ユニファイド SIP プロキシは、コールがゲートウェイから Unified CVP に入ってくる際にヘッダーとメッセージを透過的に中継できます。通常は、Unified CVP が出力レッグの Unified CM にヘッダーを渡す必要はありません。

この導入では、バックオフィス(コンタクト センター以外)のユーザへのコールは Unified CM Session Management Edition 経由でルーティングされることに注意してください。

図 57 の導入は、サポートされない Unified CM Session Management Edition と Unified CCE の設計を示します。キューイングされるコンタクト センターへのコールに対してハイ アベイラビリティが要求される導入の場合は、図 56 に示すように、これらのコールが Unified CM Session Management Edition 経由ではなくユニファイド SIP プロキシ経由でルーティングされる必要があります。

図 57 Unified CM Session Management Edition と Unified CCE の導入(ハイ アベイラビリティが要求される場合はサポートされない)

IPv6 ベースの Unified CM Session Management Edition の導入

シスコは、次の UC 製品で IPv4 と IPv6 をサポートしています。

Unified CM/Unified CM Session Management Edition の SIP トランク

新しい SCCP ベースの電話機

SIP ベースの IOS ゲートウェイ

Cisco Unified Communications Manager Express

Cisco Unified Border Element

SCCP ベースの VG224 アナログ ゲートウェイおよびルータの FXS ポート

IOS MTP

Unity Connection への SIP トランク

IPv6 UC 設計ガイドラインの要約

シスコは、デュアル スタック(IPv4 および IPv6)構成を推奨します。

SIP トランクではデュアル スタックの Alternative Network Address Types(ANAT)を推奨します。

IPv6 UC 設計に関する詳細なガイドラインについては、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd.html を参照してください。

図 58 IPv6 ベースの Unified CM Session Management Edition の導入

Unified CM Session Management Edition を使用したクラスタ間のエクステンション モビリティの導入

クラスタ間のエクステンション モビリティ(EMCC)は、Unified CM Session Management Edition ベースの UC ネットワークにおいてリーフ クラスタ間のオーバーレイとして導入できます。リーフ クラスタの EMCC トランクは、Unified CM Session Management Edition クラスタをポイントしていません。各リーフ クラスタでは、各 EMCC トランクが他のすべての EMCC 対応リーフ クラスタに直接到達できるように、EMCC トランクと対応するリモート クラスタの宛先情報が定義されます。一般に、これらの EMCC トランクは Visiting クラスタ内の電話機からの緊急コールに対してのみ使用されます。他のすべてのコールは、通常は Unified CM Session Management Edition クラスタを通過します。

図 59 Unified CM Session Management Edition を使用したリーフ クラスタの EMCC


 

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks . Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)


1. 着信の送信元 IP アドレスが、宛先 IP アドレスとして定義されているアドレスのいずれかに一致すると、トランクはコールを受け入れます。
2. 注:Unified CM Session Management Edition クラスタに制御対象またはモニタ対象のサードパーティ製デバイス、または CTI デバイスがない場合、CTI マネージャ リアルタイム トラフィックは生成されません。