オンプレミス導入環境での Cisco Collaboration 12.0 エンタープライ ズ向け

存続可能リモートサイトテレフォニー（SRST）を使用した統一された CMの冗長性

Cisco IOS SRST は、Unified CM クラスタから離れたロケーションにあるエンドポイントに、可用性の高い呼処理サービスを提供します。Unified CM クラスタリングの冗長性方式は、LAN または MAN 環境内の呼処理などのアプリケーション サービスには高レベルの冗長性をもたらします。一方で、WAN などの低速リンクによって中央の Unified CM クラスタから分離されたリモート ロケーションの場合、冗長性方式として SRST を使用することにより、リモート サイトと中央サイトの間でネットワーク接続が失われたときに、基本的な呼処理サービスをこれらのリモート ロケーションに提供できます。呼処理サービスが重要であり、Unified CM クラスタへの接続が失われた場合にも呼処理サービスを維持する必要がある各リモート サイトには、SRST 対応の Cisco IOS ルータを配置することを推奨します。これらのリモート ロケーションのエンドポイントは、Unified CM 内の適切な SRST リファレンスとともに設定する必要があります。Unified CM サブスクライバへの接続を使用できない場合に、呼処理サービス用にどのアドレスを使用して SRST ルータに接続するかをエンドポイントが認識するようにするためです。

統一された CM と IM とプレゼンスサービスのクラスタリング

Unified CM はクラスタリングの概念をサポートしています。Unified CM アーキテクチャにより、サーバ ノード グループは単一の呼処理エンティティとして連携できるようになります。このサーバ ノード グループをクラスタと呼びます。

Cisco Unified CM にはパブリッシャとサブスクライバの 2 種類のノードがあります。

• Unified CM パブリッシャ

パブリッシャはすべてのクラスタの必須サーバ ノードです。各クラスタにパブリッシャは 1 つだけ存在できます。このサーバ ノードにはクラスタ設定が含まれており、クラスタ内の他のすべてのサブスクライバにデータベース サービスを提供します。この設計では Unified CM パブリッシャは専用ノードなので TFTP 要求やエンドポイントの登録、呼処理は扱いません。

• Unified CM サブスクライバ

サブスクライバ ノードは、パブリッシャにサブスクライブして、データベース情報のコピーを取得します。たとえば、サブスクライバ ノードには Unified CM TFTP ノードや Unified CM 呼処理サブスクライバ ノードなどがあります。

Cisco IM and Presence ノードには同じクラスタリングの概念があります。最初の IM and Presence ノードは IM and Presence パブリッシャです。その他の IM and Presence ノードは IM and Presence サブスクライバで、IM and Presence パブリッシャからデータベースのコピーを取得します。IM and Presence パブリッシャは Unified CM パブリッシャと通信を行い、大半の IM and Presence 設定は実際には Unified CM パブリッシャにより行われます（Unified CM ユーザ、プレゼンス ユーザが利用できる UC サービス、サービスのアクティブ化など）。このため、IM and Presence パブリッシャをはじめとするすべての IM and Presence ノードは、より大きな Unified CM and IM and Presence Service クラスタのサブスクライバであると見なされます。C：図 2-2 に Unified CM パブリッシャと 2 つのノードを持つ IM and Presence クラスタの関係を示します。

C：図 2-2 Unified CM と 2 つのノードを持つ IM and Presence クラスタとの関係

高適用性

Unified CM および IM and Presence ノードは高可用性インフラストラクチャで展開する必要があります。たとえば、二重化電源の使用と無停電電源（UPS）の使用を組み合わせると、電力の可用性が最大になります。ネットワーク面から見ると、プラットフォーム サーバは複数の上流側のスイッチに接続する必要があります。

また、Unified CM システムおよび IM and Presence システムは、アプリケーション レベルでも高可用性処理を行います。

この設計の Unified CM では、冗長化のために 2 つの TFTP サーバを配置する必要があります。呼処理ノードは一対一（1:1）の冗長性をもって配置する必要があります。つまり、それぞれのプライマリ呼処理サブスクライバについてバックアップ呼処理サブスクライバがあります。この 100%:0% 冗長化設計は 50%:50% 冗長化設計に比べ、Unified CM グループおよびデバイス プールが少なくてすむ、冗長化オプションが少ないのでデバイス設定と配布が簡素化されるなど、多くの利点があります。

Cisco IOS Survivable Remote Site Telephony（SRST）は Unified CM クラスタから離れたロケーションにあるエンドポイントに対して、WAN リンクがダウンしたときに高可用性のある呼処理を提供します。

個々の Cisco IM and Presence ノードはサブクラスタでグループ化されます。1 つのサブクラスタは 1 つないし 2 つのノードを持つことができます。サブクラスタで 2 番目のノードを追加すると、高可用性が提供されます。高可用性が推奨されるため、この設計では各サブクラスタが 2 つのノードで構成されています。2 つのノードを持つサブクラスタでは、サブクラスタの 1 つのサーバに関連付けられたユーザは、フェイルオーバー イベントが発生した場合に、そのサブクラスタのもう一方のサーバを自動的に使えるようになります。各ノード ペアで 2 つのノード間のユーザ割り当てのバランスをとることが推奨されます。IM and Presence パブリッシャは、他の IM and Presence サブスクライバとまったく同じように、プレゼンス クライアントからの IM and Presence 情報を処理し、IM and Presence サブクラスタの 2 つのノードの 1 つとして配置されます。

コンピュータ テレフォニー インテグレーション（CTI）

Cisco コンピュータ テレフォニー インテグレーション（CTI）を利用すると、Cisco Unified CM で使用可能な豊富なフィーチャ セットを、サードパーティ製のアプリケーションでも使用できるようになります。

CTIのアーキテクチャー

Cisco CTI は、次のコンポーネントで構成されます（C：図 2-3 を参照）。これらは互いに対話し、Cisco Unified CM で使用可能なテレフォニーフィーチャ セットを各アプリケーションで利用できるようにします。

• CTI アプリケーション：特定のテレフォニー機能を提供するために作成されたシスコまたはサードパーティのアプリケーション。このアプリケーションは JTAPI または TAPI インターフェイスを使用できます。CTI アプリケーションと Unified CM との間のプロトコルは Quick Buffer Encoding（QBE）です。
• 次のサービスを持つ Unified CM サブスクライバ：

–CCM：Cisco CallManager サービス。テレフォニー処理エンジンです。

–CTI Manager（CTIM）：プライマリまたはセカンダリ モードで動作する 1 つ以上の Unified CM サブスクライバで実行され、Cisco IP デバイスを制御およびモニタできるようにテレフォニー アプリケーションを認証および許可するサービス。

C：図 2-3 CTI のアーキテクチャ

高適用性

CTI Manager の高可用性は、プライマリ CTI Manager に障害が発生した場合にバックアップ CTI Manager Service に接続することができる、CTI アプリケーションに依存します。プライマリ Unified CM サブスクライバの CTI Manager と CCM サービスの両方に障害が発生した場合
（プライマリ Unified CM サブスクライバ全体に障害が発生した場合など）、バックアップ Unified CM サブスクライバで実行されている CCM と CTI Manager サービスの両方がアクティブ化され、CTI Manager サービスは同じバックアップ Unified CM サブスクライバ上にある CCM サービスに登録されている各デバイスを監視し、制御します。プライマリ CTI Manager Service に障害が発生したものの、プライマリ CCM Service はまだ実行中の場合（1:1 冗長化がプライマリ/バックアップ Unified CM サブスクライバの 100 %/0 % 分散で実現されている場合）、すべてのデバイスはそのままプライマリ Unified CM サブスクライバ上で実行されている CCM Service に登録されたままになり、バックアップ Unified CM サブスクライバで実行されている CTI Manager がアクティブ化されて、別のノード（この場合はプライマリ Unified CM サブスクライバ）で実行中の CCM サービスに登録されている CTI デバイスであってもそれらを監視し、制御します。

CTIのキャバシティー　プランニング

3 種類の CTI リソースについての次のキャパシティの上限を超えないようにしてください。

• 所定の CTI Manager インスタンス（CTI Manager サービスを実行している Unified CM ノード）に接続される CTI アプリケーションの最大数。CTI サーバベースのアプリケーションではこの数は通常少ないのですが、デスクフォン モードの Jabber クライアントなど、CTI クライアントベースのアプリケーション（この場合は各 Jabber クライアントが CTI アプリケーションと見なされます）では、多数の Jabber クライアントを展開する場合にこの上限を超えないようにすることが重要です。
• 所定の Unified CM 呼処理サブスクライバに登録される CTI 対応エンドポイントの最大数。
• 1 つの CTI Manager インスタンスによって監視され、制御される CTI 対応エンドポイントの最大数。Unified CM ノードで実行される CTI Manager サービスは、その Unified CM ノードに登録されたエンドポイントだけを監視するのが理想的です。しかし CTI Manager サービスが他の Unified CM ノードに登録されたエンドポイントを監視することも可能です。

CTI の上限は上記の 3 つの CTI リソースすべてで同じです。CTI のキャパシティの上限は OVA テンプレートの種類によって異なります。CTI の上限に達したら、CTI Manager サービスを実行する別の Unified CM 呼処理ノードのペアを配置します。

IMとプレゼンスのアーキテクチャー

Cisco Unified CM IM and Presence Service はオンプレミスのインスタント メッセージおよびプレゼンスを提供します。このソリューションの主要なプレゼンス コンポーネントは IM and Presence Service です。これには Extensible Communications Platform（XCP）が組み込まれ、ユーザの在籍ステータスとコミュニケーション手段に関する情報を収集する SIP/SIMPLE および Extensible Messaging and Presence Protocol（XMPP）をサポートしています。ユーザの在籍ステータスは、ユーザが電話機などの通信デバイスをアクティブに使用しているかどうかを示します。

アプリケーション（シスコ製またはサードパーティ製）にプレゼンスを統合することによって、エンド ユーザ エクスペリエンスと効率性を向上させるサービスを提供できます。さらに、Cisco Jabber はインスタント メッセージングとプレゼンス ステータスも統合した IM and Presence Service の対応クライアントです。

IM and Presence Service は Cisco Unified Computing System（UCS）プラットフォーム上の Unified CM で使用されるのと同じ基本アプライアンス モデルおよびハードウェアを使用します。

IM and Presence Service は IM and Presence クラスタとして展開されます。IM and Presence クラスタは最大 6 つのノードで構成されます。1 つのノードはパブリッシャとして指定され、最大 5 つのノードがサブスクライバ ノードになります。統一された CM と IM とプレゼンスサービスのクラスタリングおよび高適用性の項で説明されているように、IM and Presence ノードはサブクラスタでグループ化され、各サブクラスタは高可用性を得るために 2 つのノードで構成されます。サイジングの項で説明されているように、1 つのサブクラスタを展開すると、最大 15,000 人のユーザをサポートできます。IM and Presence パブリッシャは IM and Presence サブスクライバとまったく同じように IM and Presence 要求を処理するので、最初のサブクラスタは IM and Presence パブリッシャと 1 つの IM and Presence サブスクライバで構成されます。

統一された CM と IM とプレゼンスサービスのクラスタリングの項で説明されているように、IM and Presence ノードはより大きな Unified CM and IM and Presence Service クラスタの一部と見なされます。

統一された CM と IM とプレゼンスサービスラスターの展開

Cisco Unified CM and IM and Presence Service クラスタは次のノードで構成されます。

• 1x Cisco Unified CM パブリッシャ
• 2x（1 ペア）Cisco Unified CM TFTP サーバ サブスクライバ
• 2x（1 ペア）Cisco Unified CM 呼処理サブスクライバ（拡張のためにペアを追加）
• 2x（1 ペア）Cisco Unified IM and Presence ノード（拡張のためにペアまたはサブクラスタを追加）

拡張のために追加する Unified CM 呼処理および IM and Presence のペア数については、サイジングの章で説明します。

C：図 2-4 は、最大 10,000 台のデバイスおよび 10,000 人のユーザを持つ Unified CM and IM and Presence Service クラスタ展開の例です。サイジング情報の詳細については、サイジングの章を参照してください。

C：図 2-4 Unified CM and IM and Presence Service クラスタの展開

アップル　プッシュ　ノーティフィケーション　サービス（APN）との統合

Unified CM および Unified CM IM and Presence Service の展開を Apple Push Notification Service（APN）に統合すると、Apple のクラウドベースのプッシュ通知サービスを使用して、音声/ビデオ コールに関する通知とインスタント メッセージを、バックグラウンドで動作する Cisco Jabber for iPad and iPhone クライアントに配信することができます。Cisco Jabber クライアントは起動時に、社内ネットワーク上に存在する場合は Unified CM に直接登録し、社内ネットワークの外部から接続する場合はモバイルおよびリモート アクセス（MRA）を使って Cisco Expressway 経由で Unified CM に登録します。Cisco Jabber クライアントがフォアグラウンド モードで動作している限り、コールと IM 通知が Unified CM または Unified CM IM and Presence Service から直接受信されます。Cisco Jabber クライアントが中断モード (バックグラウンド) に移行するとすぐに、通知を直接受け取るこの方式から Apple Push Notification に移行します。バックグラウンドの Cisco Jabber クライアントは、Apple Push Notification が Apple iOS で受信されるとすぐにアクティブになります。その後、Cisco Jabber が Unified CM および Unified CM IM and Presence Service との直接通信を再度アクティブにします。このメカニズムでは、Cisco Jabber が着信 IM メッセージやコール イベントなどのイベントを常にポーリングする必要がありません。これより、バッテリの寿命が延び、ユーザ エクスペリエンスが向上します。

C：図 2-5 は、APN との統合の全体的なアーキテクチャを示しています。Apple iOS プラットフォーム上で動作する各アプリケーションは、APN 経由で通知を受け取るために APN に登録し、デバイスとアプリケーションに固有のデバイス トークンを受け取ります。APN 経由で通知を送信する通知プロバイダーは、APN に登録します。また、通知をデバイスに送信するときに、ターゲット デバイスとアプリケーションを一意に識別するデバイス トークンを提示する必要があります。

C：図 2-5 APN との統合のためのアーキテクチャ

C：図 2-5 に示すアーキテクチャでは、単一の APN プロバイダーがすべての統合に使用され、この APN プロバイダー（Push REST サービス）は Cisco Collaboration Cloud でホストされます。特定の Unified CM and IM and Presence Service クラスタの APN 統合を有効にするには、最初に、クラウドベースの Push REST サービスにクラスタをオンボードする必要があります。このオンボーディング プロセス中に、Cisco Collaboration Cloud 内の特定のクラスタ用のマシン アカウントが作成され、そのクラスタの OAuth 更新トークンが発行されます。この情報を使用すれば、クラスタのすべての IM and Presence ノードと呼処理ノードは Push REST サービスへの接続を構築して、特定の Jabber クライアントを対象とする通知要求を発行することができます
（ステップ 1）。これらの要求は、オンボーディング プロセス中に取得される OAuth 更新トークンを使って生成された OAuth アクセス トークンを使用して認証されます。

Jabber クライアントは、APN への登録中に APN からデバイス トークンを受け取ります。このデバイス トークンは元の Unified CM クラスタに報告された後、Push REST サービス宛てのアウトバウンド通知要求内で IM and Presence ノードと呼処理ノードによって使用されます。

Push REST サービスは、IM and Presence ノードと呼処理ノードから送られるすべての通知要求を APN に中継します（ステップ 2）。その後、通知は、Apple iOS デバイスと APN の間の永続的接続を介して個別のデバイスに転送されます（ステップ 3）。

Apple Push Notification を受信すると、Apple iOS はその通知をターゲット アプリケーションにディスパッチします。これにより、Cisco Jabber が起動してフォアグラウンド モードに移行し、Unified CM および Unified CM IM and Presence Service との間で通常のコールと IM のやり取りを再開します。

Apple iOS 上で動作する Jabber クライアントが APN との接続を作成して APN から通知を受け取るためには、社内からポート 443/TCP を介して Apple クラウド内の APN に接続できる必要があります。

エンドポイント

Jabber

Cisco Jabber クライアントは、音声、ビデオ、およびインスタント メッセージのためのコア コラボレーション機能をユーザに提供します。Cisco Jabber は Windows、Mac、およびスマートフォンやタブレットなどのモバイル デバイスを含む幅広いプラットフォームで利用できます。

Cisco Jabber は次の 2 つのモードのいずれかで展開できます。

• フル UC と Cisco Jabber for Everyone（IM のみ）モード

これはデフォルト モードです。ユーザのプライマリ認証は IM and Presence サーバに対して行われます。これは、このプリファード アーキテクチャ設計で使用されるモードであり、本マニュアルで取り上げられています。

• 電話モード

電話モードでは IM と Presence サービスは必要ありません。

C：図 2-6 は Cisco Unified Communications Manager IM and Presence が含まれたオンプレミス展開のアーキテクチャを示しています。

C：図 2-6 Cisco Unified Communications IM and Presence のアーキテクチャ

Cisco Jabber は、サービスに接続するために次の情報を必要とします。

• ユーザがクライアントにサインインできる認証のソース

フル UC および IM のみモードでは、認証のソースは IM and Presence サービスです。電話のみモードでは、Unified CM です。

• サービスのロケーション

サービスには IM and Presence、ディレクトリ、CTI、ボイスメール、会議が含まれます。

この情報をクライアントに提供するには、Manual Connection メソッドよりも Service Discovery メソッドの使用を推奨します。Service Discovery メソッドを使うと、クライアントが自動的に配置され、サービスに接続します。

この設計では、ユーザが最初に Jabber クライアントで電子メール アドレスを入力したときに取得される SRV レコード _cisco-uds を使って、クライアントが自動的にサービスと設定を検出します。

Jabber Contact Source として、Cisco Directory Integration（CDI）を伴う LDAP 連絡先ソースを使用できます。別の連絡先ソースとして Unified CM ユーザ データ サービス（UDS）を使用することもできますが、オンプレミス展開用の連絡先ソースとしては CDI が推奨されます。

マルチクラスターに関する考慮事項

マルチクラスタ展開では、SIP トランクを介して個々の Unified CM クラスタすべてを相互接続します。個々のクラスタ間のセッション トラバーサルを防ぐには、フルメッシュの SIP トランクを展開します。4 つ以上のクラスタでは、Cisco Unified CM Session Management Edition（SME）を展開してダイヤル プランとトランキングを一元化し、フルメッシュ SIP トランク トポロジの複雑さを回避します。Cisco Unified CM SME については、このマニュアルでは取り上げません。SME の詳細については、『 Cisco Collaboration SRND 』を参照してください。

マルチクラスタ展開では、グローバル ダイヤル プラン レプリケーション（GDPR）を使用して、クラスタ間でダイヤル プラン情報を複製します。GDPR はディレクトリ番号ごとに 1 つの +E.164 番号、1 つの Enterprise Significant Number（ESN）、そして最大 5 個の英数字 URI をアドバタイズできます。ESN はディレクトリ番号に相当する、サイト内の短縮ダイヤルです。GDPR を通じてアドバタイズされ、学習された情報により、次のようなダイヤル手順での決定論的なクラスタ内ルーティングが可能になります。

• アドバタイズされた +E.164 番号に基づく +E.164 ダイヤリング
• アドバタイズされた ESN に基づくエンタープライズのサイト内短縮ダイヤリング
• アドバタイズされた URI に基づく英数字 URI ダイヤリング

GDPR はトランスポート媒体としてクラスタ間検索サービス（ILS）を利用するので、マルチクラスタ展開の場合は、すべての Unified CM クラスタ間で ILS をセットアップする必要があります。GDPR に加えて、Jabber によって使われる UDS ベースのサービス検出でも ILS 交換を利用し、非ローカル ユーザの /cucm-uds/homeCluster 要求の転送先として可能なリモート クラスタ上の UDS ノードの存在を検出し、Jabber にログイン試行するユーザのホーム クラスタを特定します。

IM and Presence 機能は、単一クラスタ内での通信により制限されます。プレゼンスとインスタント メッセージングの能力と機能を拡張するには、これらのスタンドアロンのクラスタにピア関係を設定することで、同じドメイン内の複数のクラスタ間で通信できるようになります。この機能により、1 つのクラスタ内のユーザが、同じドメイン内の異なるクラスタにいるユーザと通信したり、プレゼンスをサブスクライブしたりできます。フルメッシュのプレゼンス トポロジを作成するには、それぞれの Cisco IM and Presence クラスタと、同じドメイン内の他のそれぞれの Cisco IM and Presence クラスタとの間に、個別のピア関係が設定されている必要があります。クラスタ間のピアはリモートの Unified CM cluster IM and Presence パブリッシャ ノードの IP アドレスとして設定されます。

トポロジーの例

このマニュアルでは、米国の 3 つのサイト（SJC、RCD、RTP）にサービスを提供する集中型の呼処理展開を想定しています。Unified CM および IM and Presence Service の各サーバは集中的に RCD に配置されます。中央の PSTN アクセスは RCD でも同様に行われます。SJC と RTP は、ローカルで Survivable Remote Site Telephony (SRST) を設定され、RCD サイトへの WAN 接続がダウンした場合のローカル PSTN アクセスを備えた小さなサイトであると想定します。
C：図 2-7 はこのトポロジの例を示しています。

C：図 2-7 トポロジの例

マルチクラスタに関する考慮事項のために、このマニュアルでは、2 つのクラスタ（C：図 2-7 で示されている米国のクラスタと、ヨーロッパ、中東、アフリカ（EMEA）を対象とした 2 つ目のクラスタ）による展開がトポロジの例として使用されます。

証明書に関する考慮事項

証明書に関する考慮事項（一般的な概念や展開に関する推奨事項など）については、
セキュリティーの章を参照してください。

DNS に関する考慮事項

前のセクションで説明したように、接続のセットアップ中に提出されるサーバ証明書のアイデンティティが検証されます。つまり、クライアントの接続先となるアイデンティティに対して、提出された証明書のサブジェクトが実際に検査されるようにするには、完全修飾ドメイン名（FQDN）に基づいてクライアントが接続を開始する必要があります。接続の開始で FQDN を使用するということは、DNS が基本要件であることを意味します。ネットワーク内のすべてのクライアントとサーバで名前解決を確実に利用できるように、エンタープライズ DNS がセットアップされる必要があります。信頼できる FQDN-IP アドレス解決（およびその逆の解決）を提供することに加えて、Jabber クライアントで使用される自動サービス検出プロセスにも DNS が必要とされます。

起動中に Jabber クライアントは、DNS を使用して _cisco-uds._tcp SRV を解決することにより、UDS ベースのサービス検出に必要な UDS サービスを特定します。最適な冗長性とロード バランシングを実現するには、Unified CM パブリッシャ ノードと TFTP ノードに等しい優先順位と重要度を使用して DNS SRV レコードをプロビジョニングすることをお勧めします。

エンドポイントのアドレッシング

DID アドレスを持つエンドポイント上のすべてのディレクトリ番号が +E.164 番号としてプロビジョニングされます。このアプローチのメリットは次のとおりです。

• +E.164 ディレクトリ番号は、一意として定義されます。
• +E.164 ディレクトリ番号は、それ以上のダイヤル プラン設定を必要とせず、直接的に 1
  つのダイヤル手順（+ E.164）を有効にします。
• +E.164 ディレクトリ番号は、ネット上の強制的なルーティングの実装を簡略化します。
• 自動代替ルーティング（AAR）の設定が大幅に簡略化されます。ターゲットのネット上宛先を代替 PSTN アドレス（+E.164 番号）として直接使用できるので、複数の AAR グループと AAR PSTN プレフィックスをプロビジョニングする必要がありません。
• すべてのコール フロー（直接、転送、ネット上、およびネット外）で、正しい発信者 ID が自動的に生成されます。

DID が関連付けられていないエンドポイント（ロビーの電話機など）およびエンタープライズ サービス（コール ピックアップやコール パークなど）にも、一意のアドレスが必要です。それらの +E.164 番号は存在しないため、代替のエンタープライズ固有番号計画（ESN）スキーマを使ってこれらを処理することをお勧めします。推奨される ESN スキーマ形式は、ESN ダイヤルと他のダイヤル手順が重複しないようにアクセス コードを選択した後、サイト コードとサイト内拡張番号を続けることです。サイト コードと拡張番号の長さでは、十分に大きな番号スペースを確保するか、それとも ESN ダイヤリングをできるだけ短くするかのトレードオフが存在します。

+E.164 ルーティングおよびダイヤリングの正規化

意図した通りのオンネットの強制的なルーティング（サポートされている数字でのダイヤル手順のどれを使って任意のオンネットの接続先にダイヤルしても、オンネットでルーティングされなければならない）を実現するために、推奨されるダイヤル プランの設計では 2 段階のルーティング方法が使用されます。第 1 段階で、ダイヤルされる数字列は可能であれば +E.164 で正規化されます（非 DID への発信は明らかに +E.164 で正規化されません）。次に第 2 段階で、正規化された +E.164 数字列が、電話番号およびルート パターンを含む +E.164 番号計画に対して照合されます。

ダイヤリングの正規化は、非 +E.164 ダイヤル列での照合を行うトランスレーション パターンをプロビジョニングし、その後に、そのトランスレーション パターンに基づいた発信側トランスフォーメーションにより、ダイヤルした番号が +E.164 に変換されることで実現されます。

C：図 2-8 に、SJC のサイト内短縮ダイヤルをダイヤル先の +E.164 フル番号に正規化するために使用できる、ダイヤリング正規化トランスレーション パターンの例を示します。サイト SJC のユーザ to ユーザーが 4001 にダイヤルすると、その数字列がトランスレーション パターン 4XXX; とそのトランスレーション パターン上で設定された着信側トランスフォメーション マスクによって照合され、4001 に適用されたときに、結果の数字列 +14085554001 が生成され、その後で、+E.164 ルーティング方式でルーティングできます。

C：図 2-8 ダイヤリング正規化トランスレーション パターンの例

トランスレーション パターンに基づいて定義された着信側トランスフォーメーションを適用した後に、Unified CM はそのトランスレーション パターンに基づいて定義されたコーリング サーチ スペース（CSS）を使用して数字列に対する 2 回目の検索を実行します。Unified CM は、この 2 回目の検索のために、発信元の CSS と使用するトランスレーション パターンの定義を有効にします。これにより、複数のコンテキストで再利用できるダイヤリング正規化トランスレーション パターンの定義が可能になります。ダイヤリング正規化を適用した後に、単一の固定された CSS に基づくのではなく、そのトランスレーション パターンが用意されたときに有効だった CSS に基づいて、正規化された数字列の 2 回目の検索が実行されるからです。

Tip 2 回目の検索で使用される CSS が最初の検索で使用される CSS と同一であるようにするために、ダイヤリング正規化トランスレーション パターンでオプション [発信側コーリングサーチスペースを使用 （Use Originator's Calling Search Space）] を設定します。

Tip （可変長ワイルドカードで終わらない）固定長のダイヤリング正規化トランスレーション パターンでは、[後続のホップで番号間タイムアウトを待機しない（Do Not Wait For Interdigit Timeout On Subsequent Hops）] オプションも設定します。これにより、2 次的な検索で可変長ルート パターンと一致した場合でも、番号間タイムアウトなしでコールが引き続きルーティングされます。

サービス クラスとコーリング サーチ スペース（CSS）

パーティションと CSS はサービス クラスを構築するために Unified CM で使用される基本的なコンポーネントです。ダイヤル可能なパターンは、同じクラスに属するパターンを同じパーティションに入れることにより、等価クラスにグループ化されます。このときの各 CSS は、その CSS を使用する発呼側エンティティがどのパーティションおよびパターンにアクセスできるかを定義するパーティションのリストです。CSS は、その CSS を使用するデバイスから到達可能な宛先を決定することにより、サービス クラスを効率的に適用します。

ダイヤル プランを複雑にする主な要因は定義されたサービス クラスの数であるため、必要なサービス クラスの数をできるだけ少なくする必要があります。適切に設計されたエンタープライズ ダイヤル プランでは、サービス クラス間でパターンとパーティションを再利用することにより、ダイヤル プラン展開が簡略化されます。

ローカル ルート グループを使用したアウトバウンド ゲートウェイ選択

ダイヤル プラン内の重複をできるだけ回避および排除するための根本原理に従って、イーグレス ゲートウェイの定義にローカル ルート グループ（LRG）の概念が使用されます。

ローカル ルート グループを使用したルート パターンには固有の特性があります。つまり、コールの発信元デバイスに基づいて出口ゲートウェイを動的に選択できます。それに対し、スタティック ルート グループを使用したルート パターンによってルーティングされるコールでは、コールの発信元デバイスに関係なく、コールが同じゲートウェイにルーティングされます。LRG を使用するルート リストを参照するよう設定されたルート パターンは、発信側のデバイス プールで LRG として設定された実際のルート グループに解決されます。

これにより、各サイトに固有ではないルート パターンの再利用が可能になります。各サイトのイングレス ゲートウェイに直接関連付けられたサイト固有のルート パターンをプロビジョニングする必要はありません。

アウトバウンド コール：着信者番号と発信者番号のローカリゼーション

このマニュアルで説明するダイヤル プランの設計では、ローカル ルート グループを使用して、発信側デバイスに基づく出力ゲートウェイを選択します。したがって、サービス プロバイダの要件に適応するために必要な発信側および着信側トランスフォーメーションは、ルート パターンまたはルート リストのレベルで行うことができません。その場合、これらのトランスフォーメーションは、すべてのゲートウェイ間で共有されることになります。代わりに、発信者情報と着信者情報をローカライズするためのこれらのサービス プロバイダ固有のトランスフォーメーションが、Cisco IOS Voice トランスレーション ルールを使用してゲートウェイに設定されるか、発信側または着信側トランスフォーメーション パターン（ゲートウェイまたはゲートウェイのデバイス プールに設定された発信側または着信側トランスフォーメーション CSS によって対処するパターン）を使用して Unified CM に設定されます。

インバウンド コール：着信者番号と発信者番号のグローバリゼーション

Unified CM 上のすべてのコール ルーティングは、Unified CM に到着するすべての着信コールの +E.164 番号に基づくため、プロバイダからリンク経由で受信された着信側情報の形式から +E.164 に確実にグローバル化する必要があります。これを実現するには、SIP ゲートウェイ上の Cisco IOS トランスレーション（SIP 経由で Unified CM に要求を送るときに ISDN ネットワークから受信される番号タイプの消失を防ぐために必要）、Unified CM 上で設定されたプレフィックス、および場合によっては着信番号変換と発信番号変換を組み合わせます。

LDAP 同期によるユーザー　プロビジョニング

Unified CM を社内 LDAP ディレクトリに同期すると、管理者は Unified CM データ フィールドをディレクトリ属性にマッピングすることにより、ユーザを容易にプロビジョニングできるようになります。LDAP ストアに保持されている重要なユーザ データは、スケジュール ベースで Unified CM データベース内の対応する適切なフィールドにコピーされます。社内 LDAP ディレクトリのステータスは、中央リポジトリのままとなります。Unified CM は、ユーザ データを保存するための統合データベースを備え、またユーザ アカウントおよびデータを作成して管理するための Web インターフェイスを、Unified CM Administration 内に備えています。LDAP 同期を有効にすると、ローカル Unified CM データベースを引き続き使用しながら、追加のローカル エンドユーザ アカウントを作成できます。その後、LDAP ディレクトリと Unified CM Administration のインターフェイスを通してエンドユーザ アカウントを管理できます。

LDAP によるユーザー認証

LDAP 認証機能により、Unified CM が LDAP で同期されたユーザを社内 LDAP ディレクトリに対して認証できます。ローカルに設定されたユーザは、常にローカル データベースに対して認証されます。また、すべてのエンドユーザの PIN も、常にローカル データベースで確認されます。

認証を有効にするには、クラスタ全体に単一の認証アグリーメントを定義します。

認証を有効にした場合の Unified CM の動作説明を、次に示します。

• LDAP からインポートされたユーザのエンド ユーザ パスワードは、シンプル バインド操作によって社内ディレクトリに対して認証される。
• ローカル ユーザのエンド ユーザ パスワードは、Unified CM データベースに対して認証される。
• アプリケーション ユーザ パスワードは、Unified CM データベースに対して認証される。
• エンド ユーザ PIN は、Unified CM データベースに対して認証される。

複数のドメイン コントローラを地理的に分散させた分散型 Active Directory トポロジを採用している環境では、認証速度が許容されない可能性があります。認証アグリーメント用のドメイン コントローラにユーザ アカウントが保持されていない場合、他のドメイン コントローラでそのユーザの検索が実行される必要があります。この設定が当てはまる展開においてログイン速度が過度に遅い場合は、グローバル カタログ サーバを使用するように認証設定を構成できます。

ただし、重要な制限があります。グローバル カタログは employeeNumber 属性をデフォルトで伝送しません。この場合は、認証（上記に示す制限に注意）用のドメイン コントローラを使用するか、employeeNumber 属性を含めるようにグローバル カタログを更新します。詳細については、Microsoft Active Directory のマニュアルを参照してください。

グローバル カタログに対する照会を有効にするには、グローバル カタログの役割が有効になっているドメイン コントローラの IP アドレスまたはホスト名を指すように [LDAP 認証（LDAP Authentication）] ページの [LDAP サーバ情報（LDAP Server Information）] を設定し、LDAP ポートを 3268 として設定します。

DNS 要件

ソリューションを展開する前に、展開するすべてのサーバで DNS 解決が使用できることを確認します。エンタープライズ DNS では、正引き（DNS 名から IP アドレス）と逆引き（IP アドレスから DNS 名）の両方のルックアップを設定する必要があります。

また、Unified CM IM and Presence Service ノードと Unified CM 呼処理ノードで設定された DNS リゾルバが、外部ルーティング可能なアドレスの解決を許可する必要があります。APN 経由のプッシュ通知では、これが必須です。

Jabber クライアント用の UDS ベースのサービス検出を有効にするのに加えて、すべての Unified CM パブリッシャ ノードおよび TFTP サブスクライバ ノードについて、DNS SRV レコードをプロビジョニングし、これらを_cisco-uds のサービス ロケーションとして定義します。C：例 2-1 は、いくつかの Unified CM ノードを _cisco-uds のサービス ロケーションとして定義した DNS SRV レコードの例です。

C：例 2-1 UDS ベースのサービス検出のための DNS SRV レコード

C：例 2-1 では、3 つの Unified CM ノード（1 つのパブリッシャ ノードと 2 つの TFTP サブスクライバ ノード）が UDS サービス検出のサービス ロケーションとして定義され、UDS サービス検出を利用する Jabber クライアントからの最初の UDS 要求の負荷が、アクティブなすべての Unified CM ノード間で均等に分散されます。

UDS サービス検出処理の一部として /cucm-uds/clusterUser リソースを使用してホーム クラスタを探した後に、Jabber クライアントは /cucm-uds/servers リソースを使用して、ユーザのホーム クラスタ内のすべての UDS ノードのリストを取得します。これにより、SRV レコードでパブリッシャだけをサービス ロケーションとして定義した場合でも、登録処理中の実際の UDS 要求は、すべての UDS ノード間でロード バランシングされます。

Cisco Unified CM と IMとプレゼンスサービスクラスタのプロビジョニング

Unified CM and IM and Presence Service クラスタを展開するには、次のタスクを実行します。

1。 対象となるユーザ数とデバイス数に基づいて、必要な呼処理サブスクライバのペア数を決定します。

2。 対象となるユーザ数に基づいて、必要な IM と Presence ノード数を決定します。

3。 必要なすべてのクラスタ メンバーのネットワーク パラメータ（DNS 名、IP アドレスなど）を決定します。TFTP サーバも同様に考慮します。

4。 Ciscoが提供する適切な OVA テンプレート ファイルを使用して、必要な数の仮想マシンを計算インフラストラクチャに展開します。これらの OVA ファイルの取得方法について詳しくは、次の場所にあるマニュアルを参照してください。

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/
collaboration-virtualization-sizing.html

5。 Cisco Prime Collaboration 展開で、すべてのメンバを含む Unified CM クラスタを定義し、
タスク 4 で作成した仮想マシンにノードをマップします。

6。 Cisco Prime Collaboration 展開を使用してすべてのノードを展開します。

Cisco Prime Collaboration Deployment を使用してクラスタをプロビジョニングする方法の詳細については、以下の場所にある『 Cisco Prime Collaboration Deployment Administration Guide 』の最新版を参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html

Cisco Unified CM と IM とプレゼンスサービスの証明書管理

セキュリティーの章の、サーバー証明書の生成と管理に関するセクションに記載されている手順に従います。エンドポイント上で暗号化を設定する予定がない場合でも、Cisco Unified CM and IM and Presence Service と Cisco Unity Connection の Tomcat 証明書の署名を外部 CA に依頼することをお勧めします。

CA により発行された証明書が、必要な鍵の用途と拡張鍵の用途を備えているかどうか、確認することが重要です。提供された CSR に基づいて証明書を発行する CA が、単にその CSR から鍵の用途と拡張鍵の用途をコピーして証明書を発行するのではなく、証明書を発行するために選択したテンプレートの設定に基づいて、発行される証明書の鍵の用途と拡張鍵の用途を設定することが、多くの場合に問題となります。たとえば、一般的な Web サーバ テンプレートに基づいて発行される証明書には、TLS Web クライアント認証の拡張鍵の用途が含まれていません。このために、TLS 接続を開始する側の Tomcat 証明書がクライアント証明書としても使用されるサーバ間通信（クラスタ間検索サービス（ILS）やユーザ データ ストア（UDS）など）において問題が生じ、鍵の用途が正しくないことが原因で TLS 接続のセットアップが失敗します（UDS 証明書要件の検討事項を参照）。

Cisco Unified CM の初期設定

Unified CM クラスタをインストールした後すぐに、次の基本的な設定タスクを実行します。

• ノード名設定
• エンタープライズ パラメーター設定
• サービスのアクティベーション
• サービス パラメーターの設定

ノード名設定

正しい証明書検証を許可し、Unified CM クラスタ メンバーへの参照が常に正しく解決できるようにするには、Unified CM 管理 GUI のシステム/サーバで、すべてのクラスタ メンバーに対してノード名に完全修飾ドメイン名（FQDN）を設定します。これを実現するには、Cisco Unified CM 管理 GUI でシステム/サーバに移動し、最初の列に表示されているすべてのサーバが FQDN であることを確認します。DNS ドメインが付いていない、ホスト名だけで表示されているサーバのエントリを FQDN に変更します。

エンタープライズ パラメーター設定

C：表 2-2 にリストされているエンタープライズ パラメータを確認し、更新します。

サービスのアクティベーション

C：表 2-3 に、Unified CM パブリッシャ ノード、専用の Unified CM TFTP サーバ サブスクライバ ノード、および Unified CM 呼処理サブスクライバ ノードでアクティブ化されるサービスをまとめます。

C：表 2-4 に、Cisco Unified CM IM and Presence パブリッシャおよびサブスクライバ ノードでアクティブ化すべきサービスをリストします。

サービス パラメーターの設定

Cisco CallManager サービスの一部のサービス パラメータはグローバルであり、Unified CM Administration で 1 度だけ設定する必要があります。Cisco CallManager サービスのグローバル サービス パラメータ設定は、 C：表 2-5 のリストに記載されています。

注 このマニュアルでは、デフォルト以外のサービス パラメータおよびその他の設定フィールドの値だけを示しています。フィールド設定値が示されていない場合は、デフォルト値が想定されます。

注 列挙したサービス パラメータの一部は、高度なサービス パラメータです。

Cisco CallManager サービスの他のサービス パラメータは、 C：表 2-6 に示すように、各 Unified CM 呼処理ノードについて明示的に設定する必要があります。

Apple Push Notification Service（APN）経由のプッシュ通知のオンボーディング

次で入手可能な Cisco Unified Communications Managerを使用した iPhone および iPad での Cisco Jabberのプッシュ通知の展開 の最新バージョンで説明されている プッシュ通知設定タスク フロー に従います。

https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html

要約すると、オンボーディングでは次の手順が必要です。

• スマート ライセンスの登録

–[ライセンス管理（license management）] ページで Unified CM クラスタを登録する

• バウチャーの生成

–[拡張機能（Advanced Features）] > [シスコ クラウド オンボーディング（Cisco Cloud Onboarding）] で、[バウチャーの生成（Generate Voucher）] をクリックする

• オンボーディング

–[拡張機能（Advanced Features）] > [シスコ クラウド オンボーディング（Cisco Cloud Onboarding）] で、

[プッシュ通知の有効化（Enable Push Notifications）] を選択します。

[シスコ クラウドにトラブルシューティング情報を送信する（Send Troubleshooting information to the Cisco Cloud）] を選択します。

[この信頼に必要なシスコ クラウド サービス CA 証明書をシスコが管理する（I want Cisco to manage the Cisco Cloud Service CA Certificates required for this trust）] を選択します。

C：表 2-7 の接続要件でフォワード プロキシを使用する必要がある場合は、[HTTP プロキシの有効化（Enable HTTP Proxy）] を選択して、プロキシの詳細を入力します。

[保存（Save）] をクリックします。

• Unified CM IM and Presence ノードで XCP ルータ サービス を再起動します。

–クラスタのオンボーディングが成功したら、クラスタ内のすべての Unified CM IM and Presence ノードで XCP ルータ サービスを再起動する必要があります。このサービスをメンテナンス期間に再起動することをお勧めします。

C：表 2-7 に、さまざまな Unified CM ノードの接続要件を示します。既存のネットワーキング ポリシーのために直接アクセスが不可能な場合は、フォワード プロキシ経由で、 C：表 2-7 の宛先へのアクセスを可能にする必要があります。

その他の IM とプレゼンス設定

これまでの項では、IM and Presence サービスのアクティブ化、証明書管理、および IM and Presence SIP トランク設定について説明しました。それらに加えて、IM and Presence サーバの次の設定を行います。

• [IM&P Cisco SIP Proxy] サービス パラメータでの Unified CM ドメインの設定。
• [Cisco Unified CM IM and Presence の管理（Cisco Unified CM IM and Presence Administration）] >
  [プレゼンス（Presence）] > [設定（Settings）] > [標準設定（Standard Configuration）]：

–クラスタ ID の値を設定します。

–可用性の共有を有効にします。これを有効にしない場合、ユーザは自分の可用性ステータスしか表示できません。

–[アドホックプレゼンスサブスクリプションを有効にする（Enable ad-hoc presence subscriptions）] チェックボックスを選択し、Cisco Jabber ユーザのアドホック プレゼンス サブスクリプションをオンにします。

• [Cisco Unified CM IM and Presence の管理（Cisco Unified CM IM and Presence Administration）] >
  [プレゼンス（Presence）] > [ルーティング（Routing）] > [設定（Settings）]：

–[プロキシサーバの設定（Proxy Server Settings）]：[ メソッド/イベントルーティングのステータス（Method/Event Routing Status）] を [有効（Enable）] に設定します

• [Cisco Unified CM IM and Presenceの管理（Cisco Unified CM IM and Presence Administration）] >
  [メッセージング（Messaging）] > [設定（Settings）]：　　

–インスタント メッセージを有効にします。

• OAuth 付与フロー認証を有効にします。

–エンタープライズ パラメータ [更新ログイン フローを使用した OAuth（OAuth with Refresh Login Flow）] を [有効（Enabled）] に設定します。

• マルチ デバイス メッセージングを有効にします。

–Cisco Unified CM IM and Presence Administration で、[システム（System）] > [サービス パラメータ（Service Parameters）] を選択します。

–[サーバ（Server）] ドロップダウン リストから、[IM and Presence サービス パブリッシャ（IM and Presence Service Publisher）] ノードを選択します。

–[サービス（Service）] ドロップダウン リストから、[Cisco XCP ルータ（アクティブ）（Cisco XCP Router (Active)）] を選択します。

–[マルチ デバイス メッセージングの有効化（Enable Multi-Device Messaging）] ドロップダウン リストから、[有効（Enable）] を選択します。

–[保存（Save）] をクリックします。

• プッシュ通知高可用性の有効化

–Cisco Unified CM IM and Presence Administration で、[システム（System）] > [サービス パラメータ（Service Parameters）] を選択します。

–[サーバ（Server）] ドロップダウン リストから、[IM and Presence サービス パブリッシャ（IM and Presence Service Publisher）] ノードを選択します。

–[サービス（Service）] ドロップダウン リストから、[Cisco XCP ルータ（アクティブ）（Cisco XCP Router (Active)）] を選択します。

–[プッシュ通知高可用性（Push Notifications High Availability）] ドロップダウン リストから、[有効（Enabled）] を選択します。

–[保存（Save）] をクリックします。

• XCP ルータ サービスを再起動します。

–マルチ デバイス メッセージングとプッシュ通知高可用性を有効にする 2 つのサービス パラメータを変更するには、メンテナンス期間中にすべての Unified CM IM and Presence ノードで Cisco XCP ルータ を再起動する必要があります。

さらに、Jabber プロビジョニング で説明されているように、Jabber クライアント用の UC サービスを設定します。

ダイヤル プラン設定

すべてのコール制御システムを思い通りに展開するために、構造化され、適切に設計されたダイヤル プランは必要不可欠です。エンタープライズ ダイヤル プランの設計では、次の主要な領域を対象とする必要があります。

• エンドポイントのアドレッシング
• 一般的な番号計画
• ダイヤル手順
• ルーティング
• サービス クラス

推奨されているダイヤル プランの設計は、最新版『 Cisco Collaboration System SRND 』の「 Dial Plan 」の章に記載されている設計アプローチに従っています。

トポロジーの例

このマニュアルでは、米国の 3 つのサイト（SJC、RCD、RTP）にサービスを提供する集中型の呼処理展開を想定しています。 C：表 2-8 に、これらのサイトの DID（ダイレクト イン ダイヤル）の範囲を示します。

エンドポイントのアドレッシング

DID アドレスを持つエンドポイントの場合、電話番号は +E.164 のフル番号でプロビジョニングされます。この場合、+E.164 は最初の「+」に続いてグローバルな E.164 フル電話番号を表します。Unified CM で +E.164 電話番号をプロビジョニングするには、最初の「+」をエスケープする必要があります。たとえば、SJC の内線 4001 は \+14085554001 としなければなりません。

プロバイダから十分な DID が入手できない、あるいは関連付けられたデバイスに PSTN から電話をかける必要がない（内線電話など）などの理由から、一部のエンドポイントは DID を持ちません。こうしたエンドポイントには DID（E.164 番号）が存在せず、そのためこれらのエンドポイントには +E.164 以外のアドレス形式が必要です。このアドレス形式については、
一般的な番号計画に関するセクションで説明します。

外部アクセス用エンタープライズ サービスのアドレッシング

一部のサービスには割り当てられた PSTN 番号があります。こうした例として、ユーザが PSTN からボイスメールに電話をかけられるように、外部から到達可能でなければならないボイスメールの代表番号が考えられます。こうしたサービスの PSTN の E.164 番号は、PSTN プロバイダによって割り当てられる DID の範囲から予約しておく必要があります。

一般的な番号計画

+E.164 アドレスが使用できる DID に関連付けられたエンドポイントに加えて、DID がない、以下のような接続先も数多く存在します。

• 内線電話
• プロバイダが DID を割り当てることができなかった正規のエンドポイント
• 各種サービス（コール ピックアップ番号、コールパーク番号、会議など）

このマニュアルではこれらのタイプの接続先のことを 非 DID と呼びます。

これら非 DID のアドレスは +E.164 アドレス同様、非 DID のサイト固有パーティションを回避するためにシステム全体で一意でなければなりません。推奨されるソリューションは、すべての非 DID に関してエンタープライズ固有の番号計画（ESN）を導入することです。この ESN 方式は一般的なサイト間短縮ダイヤルの構造に従います。

• アクセスコード

サイト間短縮ダイヤルの 1 桁のアクセスコード。設計段階において、ほかのどのエンタープライズ ダイヤル手順とも重複しないようにアクセスコードを選択します（下記参照）。

• サイトコード

ネットワーク内のサイトを一意に識別するための一連の番号。設計段階において、すべての既存のサイトを対象とするだけではなく、規模が拡大した場合も考慮したサイト コードの長さを選択します。

• 内線番号

サイト内で各エンティティを一意に識別するための一連の番号。

このマニュアルでは、サイト間短縮ダイヤルのアクセスコードに 8 を使います。しがたって、すべての ESN は 8 で始まります。また、サイト コードには 3 桁、内線番号には 4 桁を使用します。 C：表 2-9 では、本書の例にある各サイトの DID 番号および非 DID 番号の ESN 範囲を示しています。

このプランでは DID と非 DID について同じサイト コードを使用しますが、非 DID の内線番号の最初の数字は DID 内線番号の最初の数字とは異なります。これにより、非 DID 番号および DID 番号への 4 桁のサイト内短縮ダイヤルも可能になります。

C：表 2-9 の ESN 範囲ではサイト固有番号に対して ESN 計画に余地を残していますが、スケジュール済み会議などのサイト固有以外のサービスについても番号を割り当てる必要があります。 C：表 2-10 に、専用のサイト コード（この場合は 099）を予約しておくことにより、この要件に対処する方法の例を示します。

ダイヤル手順

ダイヤル手順では、エンド ユーザがさまざまな種類の接続先に電話をかけるためにどのようにダイヤルする必要があるかを記述します。ダイヤル手順はまず、数字でダイヤルするか（914085550123 など）、または英数字でダイヤルするか（ bob@ent-pa.com）などで分類されます。

この設計では、英文字の URI でダイヤルする方法に加えて C：表 2-11 に示すように数字でのダイヤル手順もサポートされています。

一般的に、サポートされるダイヤル手順が少ないほど設計は簡易になります。設計プロセスの開始時にすべてのダイヤル手順を考慮することで、番号間タイムアウトにつながる任意の 2 種類のダイヤル手順の重複を確実に見つけて、ダイヤル プランの展開前にそれを解決できます。PSTN アクセス コード（上記のように米国では 9 が標準）を使用する主な理由は、他の (通常はネット上の) ダイヤル手順との重複を避けることです。

パーティション

エンタープライズ ダイヤル プランを作成するためにプロビジョニングされるパーティションおよび CSS を定義するときの目標の 1 つは、できるだけ重複設定を防ぐことです。この原則に従い、 C：表 2-12 では、必要とされるグローバル パーティション（サイト別、国別ではない）を示します。

Directory URI 以外の C：表 2-12 にリストされたすべてのパーティションを作成する必要があります。これらのグローバル パーティションで表すパターン クラスに加えて、 C：表 2-13 に示すような複数のサイト、国、またはサービス クラス固有のパターン クラスが必要です。

緊急コールは国固有のダイヤル手順を使用して行われるため、緊急コールの米国のダイヤル手順を可能にするルート パターンを持つパーティション USEmergency も、国固有です。他のダイヤリング ドメイン（国）もサポートするには、それらの他のダイヤリング ドメインに相当するパーティション（DEEmergency：ドイツ、ITEmergency：イタリア、DEPhLocalize：ドイツ、ITPHLocalize：イタリアなど）を作成する必要があります。

ダイヤリング正規化トランスレーション パターン

C：表 2-14 は、前の項で説明したパーティションを使用してどのダイヤリング正規化トランスレーション パターンをプロビジョニングする必要があるかをまとめています。すべてのダイヤリング正規化トランスレーション パターンは、緊急パターンとしてプロビジョニングされ、[発信側コーリングサーチスペースを使用（Originator's Calling Search Space）] が設定されています（パーティション項を参照）。これにより、ダイヤリング正規化トランスレーション パターンで定義された着信側トランスフォーメーションを適用した後に、元の CSS を使用してダイヤル先の最終的な一致を検出できます。　　

米国以外のダイヤリング ドメインの場合、インストールでそうした国固有のダイヤル手順をサポートする必要があるなら、他の国固有のダイヤリング正規化トランスレーション パターンを定義しなければなりません。 C：表 2-15 に、例としてドイツ（DE）とイタリア（IT）に必要なダイヤリング正規化を示します。

C：表 2-15 の例は、イタリアとドイツではエンタープライズ内部からトランクにアクセスするのに ITU が推奨する 0 が使用され、次に国内および国際アクセスに 0 および 00 が使用されていることを示しています。1998 以降、イタリアの地域番号は 0 で始まり、1 から 9 の数字が国内番号の最初の数字として、番号のさまざまな種類を示します。したがって、2 個のゼロ（00）で始まるダイヤル番号は、ドイツとイタリアでは異なる処理をする必要があります。イタリアでは 2 番目のゼロは NSN の一部であると見なさなければならず、したがって +E.164 数字列に残しておく必要がありますが、ドイツでは地域番号がゼロで始まらないため、ドイツの 2 番目のゼロは削除する必要があります。

これら 2 つの国に必要なダイヤリング正規化の例は、提示する設計方法で国固有のダイヤル手順をどのようにモデル化できるかを示しています。

国際番号計画の詳細については、ITU-T の「 International Numbering Resources 」ページ
（ https://www.itu.int/en/ITU-T/inr/Pages/default.aspx ）を参照してください。このページには、E.164 国コードおよび国内番号計画を含むさまざまなリソースへのリンクがあります。さまざまな国で使用されているダイヤル手順の概要は、「 Operational Bulletin No.994 (15.XII.2011) and Annexed List: Dialling procedures (international prefix, national (trunk) prefix and national (significant) number) (in accordance with ITU-T Recommendation E.164 (11/2010)) (Position on 15 December 2011) 」（ https://www.itu.int/pub/T-SP-OB.994-2011 ）にあります。実際のダイヤル手順のリストはその文書の 25 ページから始まっています。また、
https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.164C-2011-PDF-E.pdf からもダウンロード可能です。

サービス クラスとコーリング サーチ スペース（CSS）

前述のように、CSS は、CSS を使用する発呼側エンティティがアクセスできるパーティションやパターンを定義するパーティションのリストです。このマニュアルでは、サービス クラスを定義する回線 CSS だけを使用するダイヤル プラン方法を使います。

C：表 2-16 に、この設計で検討するサービス クラスをリストします。この設計のために選択したサービス クラスは例にすぎません。さらにサービス クラスが必要な場合は、同じように定義できます。

Tip サービス クラスの数は、エンタープライズ ダイヤル プランの設計の複雑さを決める重要なパラメータの 1 つです。したがって、ダイヤル プランに定義するサービス クラスの数をできる限り少なくすることが肝要です。

推奨される設計では、サービス クラスを定義するために、回線にプロビジョニングされる CSS のみを利用し、デバイス CSS を使用しません。デバイス CSS は、誰にでも利用できることが必要な一般的なダイヤル手順を実装するために使用できます。この例として緊急コールがあります。デバイス CSS を使用して緊急コールを実装する場合の詳細については、多国間環境における緊急コールの考慮事項を参照してください。

International サービス クラスだけに business-to-business URI ダイヤリングを追加することは、business-to-business（B2B）コールが限られたエッジ リソースを消費するという前提に基づいた例です。また、International、InternationalB2B、National、NationalB2B、Internal、および InternalB2B のサービス クラスを導入することによって、サービス クラスの数の倍増を避けようとしています。

所定の発信者が利用できるサービス クラスとダイヤル手順セットの両方を定義するために回線 CSS だけを使用するため、サイトごと、サービス クラスごとに、CSS をプロビジョニングする必要があります。

C：表 2-17 に、以前に定義したパーティション セット（ C：表 2-12 および C：表 2-13 を参照）に基づいてサービス クラス International をサイト SJC のユーザに対して定義する方法を示します。

C：表 2-18 に示すように、残りのサービス クラスは B2B URI ダイヤリング、国際、および国内 PSTN 接続先へのアクセスを選択的に削除することにより、同じように作成できます。

他のサイトのユーザ用のサービス クラスの CSS は上述の CSS と同様に作成しますが、サイト固有のダイヤリング正規化パターンと共に使用するパーティションが異なる点だけが違います。 C：表 2-19 に、RTP サイトの National および Internal サービス クラスの例を示します。

これらの例は、選択したパーティション方式により、複数サイトのサービス クラスを実装する CSS を作成する際に、パターンとパーティションの理想的な再利用が可能になることをはっきり示しています。

他のダイヤリング ドメイン（国）の場合、上記に示すのと同じ CSS とパーティション方式を利用できますが、上記で使用される米国パーティションの代わりに、特定のダイヤリング ドメインのダイヤリング正規化パーティションおよび国内の PSTN 接続先への国固有のルートを使用する点のみが違います。たとえば、 C：表 2-20 はドイツ（DE）のサイト FRA のサービス クラス International の CSS を示しています。

特殊な CSS

ユーザ向けサービス クラスのほかに、コーリング サーチ スペース（CSS）は Cisco Unity Connection など、トランクを通じて接続されるアプリケーションのサービス クラスの定義にも使用されます。Unity Connection がネット上の接続先にのみアクセスでき、ESN および +E.164 ダイヤリング以外に Unity Connection からの米国ダイヤル手順もサポートされることを前提として、 C：表 2-21 は、このサービス クラスを実装する CSS を示しています。

Cisco Unity Connection が複数の国で提供される必要があるシナリオでは、上記の例のパーティション UStoE164 で定義された国固有のダイヤリング正規化の実装はオプションではありません。この場合にサポートできるダイヤル手順は、グローバルで有効なダイヤル手順である ESN と +E.164 だけです。

Unified CM プレゼンスを使用するには、プレゼンス ユーザのサブスクライブ先のすべてのプレゼンティティへのアクセスができるように、何よりもサブスクライブ CSS をプロビジョニングする必要があります。プレゼンス アクセスのさらなる差別化をせずに Unified CM プレゼンスのプロビジョニングを簡素化ができるようにするには、考えられるすべてのネット上の接続先へのアクセスが可能な単一の CSS をプロビジョニングする必要があります。 C：表 2-22 は、このデフォルトのサブスクライブ CSS の設定を示しています。

このサブスクライブ CSS は、すべてのタイプのネット上の接続先へのアクセスを保証します。

C：表 2-23 に、PSTN トランクでの着信 CSS として使用される（平易な）CSS「DN」を示します。ループを回避するため、PSTN トランクは +E.164 電話番号だけに接続できます。PSTN がサポートする番号方式は 1 つだけで、それが着信時に +E.164 に正規化されるため、PSTN トランクは ESN パターン、ダイヤリング正規化パターン、または URI にアクセスする必要がなくなります。

C：表 2-24 に、他の Unified CM クラスタへのトランクの着信 CSS として使用される CSS ICTInbound を示します。ループを回避するため、これらのクラスタ間トランクの着信 CSS は、リモートのネット上接続先（パーティション onNetRemote）へのアクセスを提供すべきではありませんが、トランク（着信 CSS）はネット上のすべての有効なアドレッシング モード（+E.164、ESN、 URI）をサポートする必要があります。ダイヤリング正規化は、この CSS の一部ではありません。コールが着信クラスタ間トランクに着信する前に、+E.164 および ESN 以外のダイヤル手順はリモートの Unified CM クラスタで +E.164 または ESN に正規化されているはずだからです。

コール タイプ固有の発信ゲートウェイを選択するためのローカル ルート グループ

発信側デバイスに基づいて柔軟な出口ゲートウェイ選択ができるように、ローカル ルート グループ（LRG）の使用が推奨されます。出口ゲートウェイの選択に LRG を使用すると、サイト固有のルート パターンが不要になります。

異なるコール タイプについて別々の LRG を選択できるようにするには、 C：表 2-25 に示すように複数の LRG 名を設定します。

これらの LRG 定義により、緊急コールと通常の PSTN コールに別々の PSTN リソース（ゲートウェイ）を使用できるように、「通常の」PSTN コールと緊急コールの両方についてそれぞれ専用のルート リストを作成できます。これは、一元化された PSTN リソースが通常の PSTN コールのためにプロビジョニングされているものの、適切な Public Safety Answering Point（PSAP）へローカルの緊急コールをルーティングできるように、緊急コールがローカル サイトの小さな専用ゲートウェイを依然として使用する必要があるような状況で役立ちます。

ビデオ LRG はビデオ対応の ISDN ゲートウェイ用にプロビジョニングされ、別のリソースとして扱われます。

ローカル ルート グループを使用するルート リスト

前の項で定義した LRG を使用して、 C：表 2-26 に示すようにルート リストを作成する必要があります。

各デバイス プールの上記の LRG およびルート リスト定義により、定義済みの LRG 対して最大 7 つのルート グループを選択でき、非常に限定した発信ゲートウェイ選択が可能になります。あるコール タイプに使用される実際の PSTN リソースは、デバイス プールのプロビジョニング中に定義されます。所定のデバイス セットについてコール タイプに基づく異なる発信 PSTN リソースの選択が不要で、すべてのコール タイプについて PSTN リソースが 1 つしか必要ではない場合、それぞれのデバイス プールに標準ローカル ルート グループの実際のルート グループだけを定義し、そのデバイス プール セットの他のすべての LRG は <None> に設定されたままにしておくだけで十分です。　すべてのルート リストで [標準ローカルルートグループ（Standard Local Route Group）] を最後のエントリにすることでできます。　

PSTN アクセスと緊急コールのルート パターン

PSTN アクセスは PSTN ルート パターンにより実現します。サービス クラスとコーリング サーチ スペース（CSS）で説明したように、PSTNInternational パーティションでは国際接続先へのルートをプロビジョニングする必要がある一方で、ダイヤリング ドメイン固有パーティション xxPSTNNational（xx は、USPSTNNational のように、ダイヤリング ドメインを表します）では国内 PSTN ルートがプロビジョニングされます。 C：表 2-27 に、設定済みの PSTN ルート パターンを示します。

C：表 2-27 に明示的に示したルート パターン設定以外のすべてのその他の設定は、
C：表 2-28 に示すデフォルト値のまま残します。これには特に、空白のまま残す発呼側、接続先、着信側のトランスフォーメーションが含まれます（前述の末尾番号の削除を除く）。PSTN 要件に合致することが必要な発呼側および着信側のトランスフォーメーションは、明示的な発呼側および着信側トランスフォーメーションとして設定されるからです。これは、アウトバウンド コール：ISDN ゲートウェイでの着信者番号と発信者番号のトランスフォーメーションおよびアウトバウンド コール：SIP トランクでの着信者番号および発信者番号のトランスフォーメーションで説明されています。

パーティション PSTNInternational の PSTN 国際ルート パターンはダイヤリング ドメイン（国）固有ではありませんが、パーティション USPSTNNational および USEmergency のルート パターンは国固有です。ダイヤル プランで他の国をサポートしなければならない場合は、 C：表 2-29 に示すように、それらの国のルート パターンを作成する必要があります。

C：表 2-29 に、固定長と可変長の番号計画の違いを示します。ドイツの国内番号計画は可変長なので、ドイツの国内接続先に一致させるルート パターンは可変長の数字列に一致する必要があります。また、ユーザが電話番号を明示的に # で終わらせることができるように、# で終わる代替ルート パターンをプロビジョニングして、国内接続先にダイヤルする際の番号間タイムアウトを回避する必要もあります。これとは対照的に、フランスの国内番号計画は固定長（米国と同じ）なので、1 つの固定長の緊急用ルート パターンでフランスの全国内番号をカバーできます。

ドイツとフランスは同じ緊急ダイヤル手順を使用するため、緊急用パーティション DEEmergency および FREmergency の両方を組み合わせて 1 つのパーティション 112Emergency とし、CSS 定義で代わりにそのパーティションを使用することにより、緊急用ルーティングを簡素化することができます。

多国間環境における緊急コールの考慮事項

個々のサービス クラスとは独立して、全エンドポイントから常時緊急番号へアクセスできることが必要です。前述のように、これは緊急コール ルート パターンを持つパーティションをすべての CSS に追加することで、簡単に実現します。この方法で問題が生じるのは、複数の国をサポートしなければならず、それらの国で異なる緊急ダイヤル手順が必要であり、エクステンション モビリティやデバイス モビリティなどのモビリティ機能が使用される場合です。

そのような場合、異なる緊急ダイヤル手順のある複数の国の間でユーザがローミングを行うと、このユーザが使用しているデバイスはアクセス中のユーザが使用する緊急ダイヤル手順を継承します。たとえば、ドイツのユーザがアメリカの電話にログインすると、ドイツ人ユーザのエクステンション モビリティ プロファイルで定義された回線 CSS が、アクセス先であるアメリカの電話に割り当てられ、この電話で緊急コールを発信するにはドイツの緊急電話番号 112 を使用しなければならず、米国の緊急コールのダイヤル手順 911 はサポートされなくなれます。

外国人ユーザが電話にログインするかどうかに関わらず、任意の国の電話が常にその国の国内緊急コールのダイヤル手順をサポートするように、緊急コール用に異なる方式を実装できます。USEmergency をすべての CSS に追加する代わりに、専用の USEmergency CSS を作成し、その CSS を米国のすべてのデバイスにデバイス CSS として割り当てます。こうすると、外国人ユーザが米国の電話にログインした場合に、回線 CSS により定義されたアクセス中のユーザの「ホーム」ダイヤル手順が、アクセス先の国の緊急ダイヤル手順と結びつきます。ドイツ人ユーザが米国の電話にログインする上記のケースでは、そのユーザのドイツ式 PSTN ダイヤル手順は、米国固有の緊急ダイヤル手順 911 と一緒にサポートされるようになります。異なる国間でのこうしたダイヤル手順の組み合わせにより、アクセス先の緊急ダイヤル手順とアクセス中のユーザの通常のダイヤル手順との間に重複が生じる可能性があることを念頭に置く必要があります。たとえば、ドイツのサイトが 9 で始まる 4 桁の内線番号を持つ場合（+E.164 範囲が +49 6100 773 9XXX など）、そのドイツのサイトのユーザが米国の電話にログインすると、9XXX ダイヤリング正規化トランスレーション パターンによりそのサイトに定義された 4 桁のサイト内短縮ダイヤルが、米国緊急ダイヤル 911 と重複してしまいます。緊急ダイヤル手順がより固有である限り、緊急パターンとして緊急コール ルート パターンを作成することにより、緊急コールをかけるときに遅滞が生じないことが保証されます。一方で、911 の米国緊急パターンは 911 で始まるすべての 4 桁のダイヤルを「ブロック」する可能性があり、これにより、例えば +49 6100 773 911X などの電話番号への 4 桁のサイト内のダイヤルに影響を与えることがあります。

緊急ダイヤルを回線 CSS からデバイス CSS に移動すると、アクセス中のユーザの緊急ダイヤル手順（ドイツ人ユーザの場合は 112）をアクセス先の国の緊急ダイヤル手順（米国の場合は911）に変換しなければならないという問題も回避できます。

ビデオ PSTN（ISDN）コールのルート パターン

コスト面から見て、通常のボイスコールに ISDN ビデオ ゲートウェイを使用することは実現不可能なため、ダイヤル プランの観点からビデオ用の ISDN ゲートウェイに特別の処理が必要です。この設計では、ビデオ ISDN ゲートウェイの選択を、特別なビデオ PSTN ダイヤル手順に明示的に結びつけます（ C：表 2-11 を参照）。 C：表 2-30 に、このダイヤル手順を有効にするために必要なルート パターンを記載します。

ビデオ ISDN ルート パターンをパーティション PSTNInternational に含めると、実質的に「国際」サービス クラスにビデオ ダイヤル機能が追加されます。

アウトバウンド コール：ISDN ゲートウェイでの着信者番号と発信者番号のトランスフォーメーション

ISDN トランクでは、発信側番号および着信側番号の情報が、発信側および着信側の情報要素で送受信されます。これらの情報要素は、番号計画、番号タイプ、および番号の 3 つで構成されます。これらのフィールドをどのように設定しなければならないかは、プロバイダのトランク サービス定義に依存します。一例として、ドイツ国内の同じ市外局番 6100 内のトランクにある E.164 着信番号 4961007739764 へのコールの場合、発信 ISDN SETUP メッセージに含まれる着信側番号は、（番号計画/タイプ/番号の形式で）「ISDN/national/61007739764」、「ISDN/subscriber/7739764」、または「unknown/unknown/061007739764」として送信される場合があります。

ISDN トランクの終端となるゲートウェイが SIP を使用して Unified CM に接続されている場合、SIP は番号タイプの概念を把握しないため、番号タイプを Unified CM からゲートウェイに送信することはできません。コールのタイプによって異なる ISDN 番号タイプをサポートする必要があるかどうかは、プロバイダの SIP トランク サービス定義によって決まります。ISDN トランクでは、一部のプロバイダは常に、着信先にかかわらず、同じ ISDN 計画およびタイプのインジケータを使用した着信側番号と発信側番号の送信を許可します。

C：表 2-31 に、米国の ISDN プロバイダが許容する可能性のある代替着信側番号形式の例を記載します。

ゲートウェイに送信される数字列の先頭には、ゲートウェイでのダイヤルピア定義を簡略化したプレフィックス「*」が付加されます。PSTN から受信する着信側番号が「*」で始まることは決してありません。したがって、ゲートウェイに送信する着信側番号にプレフィックス「*」を使用することで、インバウンド コールとアウトバウンド コールに関して、簡単で競合のない宛先パターンに基づいたアウトバウンド ダイヤルピアの選択がゲートウェイで可能です。コールを PSTN に送信する前に、Unified CM によって先頭に付加された「*」をゲートウェイで削除する必要があります。Unified CM からゲートウェイに送信されるすべての着信側番号で、先頭に「*」を使用すると、ゲートウェイで POTS ダイヤルピアに対して「宛先パターン *」を使用することが可能になります。この場合、先頭の「*」は、Cisco IOS のデフォルトでの桁削除動作により自動的に削除されます。

着呼側の +E.164 着信番号から PSTN に送信される数字列へのトランスフォーメーションは、Unified CM で行うことができます。ゲートウェイでは、C：例 2-2 に記載する Cisco IOS Voice トランスレーション ルールを使用して、簡単に ISDN 計画およびタイプを適用できます。

C：例 2-2 単一の ISDN 計画およびタイプを適用する Cisco IOS Voice トランスレーション

C：例 2-2 に記載されている、Cisco IOS 設定の抜粋には、特定の POTS ダイヤルピアから PSTN に送信される発信側と着信側の情報に単一の ISDN 計画およびタイプを適用する方法が示されています。voice-translation-rule 1 のルール 1 は、「*」で始まるすべての番号に一致し、この先頭の「*」を除去します。voice translation-rule 1 のルール 2 は、任意の計画およびタイプのすべての番号に一致し、計画とタイプの両方を「unknown」に強制する一方で、番号の実際の数字列は変更しません。ISDN を指す POTS ダイヤルピアに、この Cisco IOS Voice トランスレーション ルールを適用することで、計画とタイプが「unknown」に強制された上で、Unified CM からゲートウェイに送信されるすべての着信側番号と発信側番号が変更されずに PSTN に転送されます。

このトランスレーション ロジックをゲートウェイに設定した場合、Unified CM 側では、+E.164 着信側情報を C：表 2-31 に従った数字列に変換してから PSTN に送信するようにプロビジョニングする必要があります。表 24 に、ISDN ダイヤル用に +E.164 をローカライズするために必要な着信側トランスフォーメーション パターンを記載します。

C：表 2-32 に記載されている着信側トランスフォーメーション パターンで定義された着信側トランスフォーメーションをゲートウェイに適用するには、まず、USGWLocalizeCd パーティションだけを設定した CSS USGWLocalizeCd を定義します。そして、ゲートウェイのデバイス プールの [デバイスモビリティ関連情報（Device Mobility Related Information）] セクションで、その CSS を [着信側トランスフォーメーションCSS（Called Party Transformation CSS）] として設定します。これらのトランスフォーメーションをデバイス プールに設定すれば、同じ着信側トランスフォーメーション要件を共有する同じサイト内の複数のゲートウェイで、これらの同じ設定を共有することができます。それには、ゲートウェイ設定ページの [アウトバウンドコール（Outbound Calls）] セクションで、[デバイスプールの着信側トランスフォーメーションCSSを使用（Use Device Pool Called Party Transformation CSS）] オプションをオンにする必要があります。

また、必要なプロビジョニングとして、+E.164 からサービス プロバイダへ送信しなければならない形式への発信側番号のトランスフォーメーションを行います。ここで、非 DID から発信されるコール、または特定のゲートウェイに関連付けられた DID 範囲に含まれない DN から発信されるコールの発信側情報を処理する方法を検討する必要があります。最も一般的な選択肢は、発信者 ID をサイト固有の主要な内線番号に設定することです。このサイトでは特に、 C：表 2-33 に記載するサイト固有の発信側トランスフォオーメーションを作成する必要があります。

C：表 2-33 に記載されている発信側トランスフォーメーション パターンは、+E.164 形式の番号であるか、トランクの DN 範囲に一致しない企業固有の番号であるかにかかわらず、すべての発信側番号が主要な番号（19195551888）に強制されるようにするために必要なトランスフォーメーションを行います。

前述のアウトバウンド着信側トランスフォーメーションに適用する手法に相当する、これらのトランスフォーメーションを可能にするには、まず、パーティション RTPGWLocalizeCn だけを使用した CSS RTPGWLocalizeCn を作成します。そして、ゲートウェイ設定ページの [アウトバウンドコール（Outbound Calls）] セクションまたはゲートウェイのデバイス プールの [デバイスモビリティ関連情報（Device Mobility Related Information）] セクションで、その CSS を 発信側トランスフォーメーション CSS として適用します。

ゲートウェイごとに特定の着信側または発信側トランスフォーメーションが必要な場合、着信側トランスフォーメーションにデバイス プール レベルの設定を使用すると、複雑になりすぎます。その場合には、ゲートウェイ設定ページの [アウトバウンドコール（Outbound Calls）] セクションで、[デバイスプールの着信側/発信側トランスフォーメーションCSSを使用（Use Device Pool Called/Calling Party Transformation CSS）] オプションをオフにして、着信側または発信側トランスフォーメーション CSS を設定します。

アウトバウンド コール：SIP トランクでの着信者番号および発信者番号のトランスフォーメーション

前述のように、SIP には、番号の「タイプ」という概念がありません。通常、SIP トランクでは、着信先のタイプにかかわらず、すべての着信者番号と発信者番号を単一の形式で送信する必要があります。最も一般的な選択肢は、+E.164 または E.164 です。インバウンド コールおよびアウトバウンド コールの宛先パターンを重複させることなく、より簡単なダイヤルピア設定を行うには、SIP トランクの終端となる Cisco Unified Border Element に送信されるすべての E.164 着信側情報に、プレフィックス「*」を付加する必要があります。

（+ を含まない）E.164 を送信する必要がある場合は、着信側トランスフォーメーション パターンを使用した前述の手法を使用できます。 C：表 2-34 に記載されている着信側トランスフォーメーションを 1 回行えば、すべての +E.164 番号から先頭の + を除去できます。この場合も、パーティション GWNoPlus だけに対応する CSS（例えば、GWNoPlus）を作成してから、ゲートウェイまたはゲートウェイのデバイス プールのいずれかに対し、この着信側トランスフォーメーション パターンを [着信側トランスフォーメーションCSS（Called Party Transformation CSS）] として適用する必要があります。

送信される着信側情報の形式を SIP トランクで変換する必要がないとしても、有効な番号だけがプロバイダに送信されるようにするには、何らかのフィルタリングを着信側情報に適用する必要があります。アウトバウンド コール：ISDN ゲートウェイでの着信者番号と発信者番号のトランスフォーメーションの項で説明し、 C：表 2-33 に要約した発信側トランスフォーメーションと同じものを使用できます。さらに、Cisco Unified Border Element の Cisco IOS Voice トランスレーションにより、確実に、プロバイダの形式要件に従って発信側情報がプロバイダに送信されます。C：例 2-3 に、プロバイダを指す Cisco Unified Border Element（CUBE）上で VoIP ダイヤルピアに適用される Cisco IOS Voice トランスレーションを記載します。これらのトランスレーションにより、着信側情報が *E.164 から +E.164 に変換され、発信側情報が E.164 から +E.164 に変換されます。

C：例 2-3 CUBE で +E.164 発信側番号と着信側番号に強制される Cisco IOS Voice
トランスレーション

C：例 2-3 のルール 1 は先頭の「*」を「+」に置き換え、ルール 2 はすべての番号の先頭にプレフィックス「+」を付加します。

インバウンド コール：ISDN ゲートウェイでの着信者番号および発信者番号のトランスフォーメーション

Unified CM にルーティングされるコールはすべて、Unified CM に到着するすべての着信コールの +E.164 に基づくため、リンクで受信されたプロバイダからの着信側情報の形式が確実に +E.164 に変換されなければなりません。アウトバウンド コール：ISDN ゲートウェイでの着信者番号と発信者番号のトランスフォーメーションの項で説明したように、ISDN トランクで送受信する発信側情報と着信者情報は、番号計画、番号タイプ、および番号の 3 つで構成されています。SIP では番号タイプをサポートしていないため、実際の番号だけがゲートウェイから SIP トランク経由で Unified CM に転送されるとしたら、プロバイダから受信した番号タイプの意味が失われてしまいます。この状況を回避するためには、ゲートウェイに Cisco IOS Voice トランスレーションを導入し、受信した番号計画、番号タイプ、番号に基づく +E.164 数字列を作成して Unified CM に送信する必要があります。C：例 2-4 に、この目的を果たすための Cisco IOS Voice トランスレーションの設定を記載します。

C：例 2-4 ISDN を +E.164 にマッピングする Cisco IOS Voice トランスレーション

C：例 2-4 に記載されている Cisco IOS トランスレーションは、受信する着信側情報のタイプが「national」であること、したがって番号が 10 桁のみであることを前提とします。ルール 1 （/^\(.+\)$/）は、タイプが「international」に設定されたすべての番号にプレフィックス「+1」を付加し（/+\1/）、計画およびタイプを「unknown」に強制します。SIP トランクで Unified CM に転送する場合、計画とタイプは両方とも無関係であるためです。この同じトランスレーション ルールが、トランスレーション プロファイル ISDNtoE164 で発信側情報と着信側情報の両方に適用されます。したがって、タイプが「national」に設定された 10 桁の番号である発信側情報は、ルール 1 によって適切に +E.164 に変換されます。ルール 2 は、実際には着信側情報に適用されません。プロバイダは一般に、単一の形式だけを使用して着信側情報を送信するためです。したがって、ルール 2 が関係してくるのは、国外から受信したコールに限られます。この場合、受信する発信側情報は「international」タイプであり、番号は発信側の完全な E.164 番号に設定されていることになります。

プロバイダによって使用される番号形式は異なる場合があるため、ゲートウェイまたは Unified CM で異なる複数のトランスフォーメーションを使用する必要が生じてきます。音声トランスレーション ルールの詳細については、『 Number Translation using Voice Translation Profiles 』を参照してください。このドキュメントには、以下の URL でアクセスできます。

https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-
translation-profiles.html

何らかの理由で発信側情報と着信側情報の両方に同じ音声トランスレーション ルールを使用できない場合、発信側情報と着信側情報にそれぞれ個別の音声トランスレーション ルールをプロビジョニングして、1 つのトランスレーション プロファイルで発信側トランスレーションと着信側トランスレーションを関連付ける必要があります。

インバウンド Cisco IOS Voice トランスレーション ルールを使用する必要があるのは、プロバイダから複数の異なる番号タイプが送信される場合のみです。たとえば、発信側情報または着信側情報の番号タイプが常に不明である場合は、Unified CM で数字をグローバル化された +E.164 に変換するために、発信側情報と着信側情報にインバウンド プレフィックスを使用するか、発信側および着信側トランスフォーメーション CSS を使用することができます。プレフィックスと発信側および着信側トランスフォーメーションの両方を、トランク レベルまたはデバイス プール レベルで定義することもできます。ただし、SIP では異なる番号タイプをサポートしていないため、デバイス プール レベルで定義する場合は、インバウンド プレフィックスまたは発信側および着信側 CSS を番号タイプ unknown に設定する必要があります。

インバウンド コール：SIP トランクでの着信者番号と発信者番号のトランスフォーメーション

一般に、PSTN SIP トランクでのインバウンド コール番号情報の処理は、前述の ISDN の場合の番号処理よりも単純です。その主な理由は、SIP トランクでの番号情報にはタイプが設定されていないためです。したがって、トランスフォーメーションの複雑さは軽減され、考慮しなければならないのは受信した数字列だけとなります。通常、SIP トランクでの発信側情報と着信側情報はすでに +E.164 形式になっているため、トランスフォーメーションは不要です。

E.164 形式で受信した発信側情報と着信側情報を +E.164 形式に変換する最も簡単な方法は、Unified CM の SIP トランクまたはトランクのデバイス プールでプレフィックス「+」を付加するように設定することです。このプレフィックスは、トランクまたはトランクのデバイス プールの [着信の発呼側設定（Incoming Calling Party Settings）] または [着信の着呼側設定（Incoming Called Party Settings）] に設定できます。SIP トランクの場合、[不明な番号（Unknown Number）] の設定は、デバイス プール レベルに適用されることに注意してください。

電話上での発信側情報の表示

+E.164 電話番号から発信されるコールの場合、すべての電話番号は +E.164 番号としてプロビジョニングされるため、発信側情報は自動的に +E.164 形式になります。考えられるあらゆるコール フローでの発信側情報の表示を単純化して一貫性を持たせるために、PSTN などの外部ネットワークから受信するすべての発信側情報は、前述のように +E.164 に正規化されます。電話や外部ネットワークにコールを表示する際には、そのコールに関して表示される発信側情報を、外部ネットワークが必要とする形式（そのコールがゲートウェイに送信される場合）またはユーザが必要とする形式（電話に送信される場合）に変換しなければならないことがあります。

非 DID を使用した電話から発信されるコールには、特殊な考慮事項があります。この場合、使用可能な発信側情報は、ESN（Enterprise Specific Number）形式でプロビジョニングされた非 DID と同一です。 C：表 2-9 に、サンプル トポロジーで使用されている ESN 範囲を要約します。

電話の場合、優先される発信側の表示情報が +E.164 形式ではない場合もありますが、この情報を +E.164 として保持すると、展開が簡素化されるため、この方法が推奨されます。その場合の望ましい形式は、通常、発信側エンティティと着信側エンティティの両方に依存します。 C：表 2-35 に、サイト SJC の電話で、各種のソースからのコールで必要とされる発信側情報表示の例を記載します。

C：表 2-35 に記載されている表示形式を実現するには、発信側トランスフォーメーション パターンを適切なパーティションにプロビジョニングし、それらのパーティションに基づく発信側トランスレーション CSS を電話に設定して、トランスフォーメーションを有効にする必要があります。

表 28 に、 C：表 2-9 に記載された番号範囲に基づき、米国のすべてのサイトに関して、
C：表 2-35 に記載された短縮発信側番号を表示するためにプロビジョニングする必要がある、すべての発信側トランスフォーメーション パターンを記載します。

C：表 2-37 に、米国の全サイトの電話の発信側ローカリゼーションを有効にするための発信側トランスフォーメーション CSS を記載します。このスキーマを使用すると、ダイヤル発信ドメイン（国）に固有の発信側ローカリゼーション トランスフォーメーション パターンを、そのダイヤル発信ドメイン（国）内のすべてのサイトに再利用できます。国固有の発信側ローカリゼーション パターンは、基本的に、国番号と国際番号をその国に固有の国内および国際ダイヤル手順にマッピングします。

C：表 2-38 に、国固有の電話ローカリゼーション発信側トランスフォーメーション パターンの例を記載します。これは、イタリアおよびドイツに対してプロビジョニングする必要があるパターンの例です。

自動代替ルーティング

自動代替ルーティング（AAR）は、発信元のエンドポイント、ゲートウェイ、またはトランクと発信先のエンドポイント間で十分な帯域幅がない（コール アドミッション制御がコールを許可しない）場合に、PSTN 経由の代替ルートを介して登録済みエンドポイントへのコールを再ルーティングするメカニズムです。AAR は、エンドポイントへのコールにのみ適用されます。ゲートウェイやトランクなどの他の宛先へのコール用の帯域幅が不十分な場合は、AAR がトリガーされません。このような場合の代替ルーティング メカニズムは、ルート リストとルート グループに基づいています。AAR をアクティブにするには、次の手順が必要です。

• [自動代替ルーティングの有効化（Automated Alternate Routing Enable）] サービス パラメータを設定します（サービス パラメーターの設定の項を参照）。
• [ダイヤルプレフィックス（Dial Prefix）]（デフォルト）を設定せずに、Default という単一の AAR グループを設定します。
• +E.164 PSTN ルート パターンへのアクセスだけを設定した CSS PSTNReroute を設定します。この設計例に基づく CSS には、パーティション PSTNInternational だけを含める必要があります。
• AAR の対象となる可能性があるコールを開始するエンドポイント、トランク、およびその他のデバイスのすべてで、以下を設定します。

–[AARコーリングサーチスペース（AAR Calling Search Space）] を PSTNReroute に設定します。

–[AARグループ（AAR Group）] を Default に設定します。

• すべてのデバイス ポートで、[AARコーリングサーチスペース（AAR Calling Search Space）]を PSTNReroute に設定します。
• [AARグループ（AAR Group）] を Default に設定します。
• +E.164 電話番号に AAR マスクを設定し、その電話番号が +E.164 番号になるようにします。固定長の番号計画を使用する国では、すべての電話番号でマスクを同じ値に設定できます（たとえば米国では、+1XXXXXXXXXX など）。可変長の電話番号に対応する必要がある場合、単一のサイトをカバーする具体的なマスクをプロビジョニングします。あるいは最悪の場合、それぞれの電話番号と同じ完全修飾子を付けた +E.164 AAR マスクをプロビジョニングする必要があります。非 DID の場合、AAR マスクは空のままにします。これにより実質的に、非 DID が呼び出された場合は AAR が無効になります。非 DID には同等の E.164 アドレスがなく、PSTN を介してアクセスできないため、これは理にかなっています。

上記のリストでは、+E.164 電話番号を使用したダイヤル プランの利点の 1 つが示されています。この場合、他に変更を加えることなく、着信側 +E.164 アドレスを PSTN 経由の代替ダイヤルに直接再使用できるためです。

未登録エンドポイントの代替ルーティング

コール処理を一元化したマルチサイト展開環境で WAN に障害が発生した場合、その障害によって中央の Unified CM との接続を失ったエンドポイントは、代わりにローカル SRST ゲートウェイに登録します（Survivable Remote Site Telephony（SRST）展開の項を参照）。これにより、影響を受けた電話をそのまま配置して、受信したコールを同じサイト内の電話と PSTN との間で受け渡すことができます。ただし、中央の Unified CM の観点からは着信デバイスは登録されていないため、そのデバイスには到達できません。したがって、中央の Unified CM に登録された電話からのコールは失敗します。PSTN を介した未登録エンドポイントへのコールの自動再ルーティングを有効にするには、自動再ルーティングが必要な電話番号のそれぞれに対して、以下のタスクを実行します。

• 「未登録内線の不在転送」および 「未登録外線の不在転送」の宛先を、+E.164 電話番号と同じ値に設定します。
• [未登録内線の不在転送のCSS（Forward Unregistered Internal CSS）] および [未登録外線の不在転送のCSS（Forward Unregistered External CSS）] を、PSTNReroute に設定します。これは、自動代替ルーティングの項で定義したのと同じ CSS です。これにより、PSTN ルート パターンにアクセスできるようになります。
• サイトのゲートウェイがまだ統一された CMに接続中に電話機が登録解除された際（たとえば、接続されていない場合など）に発生する可能性があるルーティングループの影響を確実に制限するには、 DN への未登録ホップの最大転送数 サービスパラメータをゼロ以外の値に設定します。

未登録エンドポイントに対する PSTN を介した代替ルーティングが意味を持つのは、+E.164 電話番号のみです。DID を使用しないエンドポイント（電話番号として ESN を使用するエンドポイント）の場合、未登録エンドポイントに対して意味を持つ再ルーティングは、着信コールをボイスメールに転送するというルーティングだけです。未登録エンドポイントへのコールをボイスメールに転送するには、以下のタスクを実行します。

• [未登録内線の不在転送（Forward Unregistered Internal）] および [未登録外線の不在転送（Forward Unregistered External）] に [ボイスメールオプション（Voicemail options）] を選択します。
• [未登録内線の不在転送のCSS（Forward Unregistered Internal CSS）] および [未登録外線の不在転送のCSS（Forward Unregistered External CSS）] を、「国内」サービス クラスを実装する CSS（たとえば、SJCInternal）に設定します。実質的に、この CSS ではボイスメール パイロット番号にのみアクセスできます。

LDAP システムの設定

実際の同期アグリーメントを定義する前に、LDAP システムを有効にする必要があります。[LDAPシステムの設定（LDAP System Configuration）] メニューでは、次の操作を実行できます。

• [LDAPサーバからの同期を有効にする（Enable Synchronizing from LDAP Server）] オプシ
  ョンを選択する（チェックボックスをオンにする）。
• 展開環境に適切な [LDAPサーバタイプ（LDAP Server Type）] を選択します。
• 展開環境に適切な [ユーザIDのLDAP属性（LDAP Attribute for User ID）] を選択します。

Microsoft Active Directory からユーザが同期される環境では、 C：表 2-39 に記載する設定を使用します。

LDAP　カスタムフィルター

Unified CM ベースのディレクトリ検索が電話で使用されている場合は、社内 LDAP ディレクトリ全体を Unified CM に同期することが理にかなっています。その場合、実際にローカル クラスタの UC サービスを使用するユーザと、完全な社内 LDAP ディレクトリを Unified CM に反映するためだけに同期されるユーザとを区別可能にする必要があります。

この目標を達成するには、カスタム LDAP フィルタを使用して、ローカル ユーザ グループとリモート ユーザ グループの 2 つを定義できます。ここで言うリモート ユーザとは、ローカル Unified CM クラスタの UC サービスを一切使用しないユーザを意味します。 C：表 2-40 に、2 つのカスタム LDAP フィルタを記載します。ここでは、展開環境のユーザが米国と欧州に存在し、米国のユーザのみがローカル ユーザであることを前提としています。

読みやすくするために、 C：表 2-40 では、インデント レベルに LDAP フィルタ文字列の構造を反映して、LDAP フィルタ文字列を複数の行に分けて記載しています。これらの LDAP フィルタを Unified CM にプロビジョニングするには、特定のフィルタのすべての行を 1 行に連結する必要があります。

上記の LDAP フィルタは、どちらも Microsoft Active Directory のデフォルト LDAP フィルタを拡張したものです。他のディレクトリ タイプのデフォルト LDAP フィルタは、『 Cisco Collaboration System SRND 』最新版の「 Directory Integration and Identity Management 」に関する章と、LDAP ディレクトリの設定に関する Unified CM オンライン ヘルプに記載されています。

C：表 2-40 に記載されている LDAP フィルタでは、電話番号の開始部分を基準として、個々のユーザがローカル ユーザまたはリモート ユーザのどちらであるかを判別します。

複数の LDAP 同期アグリーメントを使用する場合は、それらの同期アグリメーメントで使用される LDAP フィルタを分離して、同じユーザが複数のフィルタに一致しないようにしてください。

機能グループ テンプレート

LDAP からユーザを同期する機能は、機能グループ グループ テンプレート（FGT）に定義されています。 C：表 2-41 に、Unified CM クラスタのアクティブ デバイスでのユーザの機能を定義する FGT の設定を要約します。

その他すべての設定には、デフォルト値をそのまま使用できます。

リモート ユーザも LDAP から同期されるため（LDAP　カスタムフィルターの項を参照）、リモート ユーザ用の FGT もプロビジョニングする必要があります。主な違いは、リモート ユーザ用の FGT では、[ホームクラスタ（Home Cluster）] および [Unified CM IM and Presenceのユーザを有効化（Enable User for Unified CM IM and Presence）] オプションをオンにしないことです。 C：表 2-42 に、これらの設定を要約します。

その他すべての設定には、デフォルト値をそのまま使用できます。

LDAP 同期アグリーメント

すべてのローカル ユーザを Unified CM に同期させるには、LDAP 同期アグリーメントを構成する必要があります。 C：表 2-43 に、[システム/LDAP/LDAP ディレクトリ（System/LDAP/LDAP Directory）] に構成する必要がある設定を記載します。

C：表 2-43 に記載されている LDAP 同期アグリーメントは、前に定義した FGT とカスタム LDAP フィルタを関連付けます。これにより、カスタム LDAP フィルタに一致する社内ディレクトリ内のすべてのユーザについて、Unified CM に、FGT に定義された機能が割り当てられたユーザが作成されます。

ローカル Unified CM クラスタで UC サービスを使用しないリモート ユーザを同期するための専用の LDAP 同期アグリーメントも必要です。 C：表 2-44 に、この LDAP 同期アグリーメントを要約します。

上記の LDAP 同期アグリーメントを使用すると、すべてのユーザを社内ディレクトリから識別できるようになり、LDAP 同期アグリーメントに関連付けられた FGT によって確実に、すべてのユーザに適切な機能が設定されます。

LDAP によるユーザ認証

C：表 2-45 に、LDAP 認証設定の例を記載します。

Cisco Unified CM グループ設定

Cisco Unified CM グループを使用して、クラスタ内に Unified CM インスタンスのグループを定義し、デバイスが Unified CM クラスタに登録するために使用する Unified CM インスタンスを指定することができます。単一の Unified CM コール処理ぺアだけが展開されている場合（詳細については、Cisco Unified CM と IMとプレゼンスサービスクラスタのプロビジョニングの項を参照）、Default という名前の単一の Unified CM グループも導入し、クラスタ内の単一の Unified CM コール処理サブスクライバ ぺアで実行する両方の Unified CM インスタンスを、
この単一の Unified CM グループのメンバにする必要があります。

複数の Unified CM コール処理サブスクライバ ペアが存在する場合、追加の Unified CM グループ（各 Unified CM コール処理サブスクライバ ペアごとに 1 つのグループ）をプロビジョニングして、各 Unified CM グループに、その特定のペアで実行する 2 つの Unified CM インスタンスを追加する必要があります。

最初のペアに ucm1a.ent-pa.com および ucm1b.ent-pa.com という名前の 2 つの Unified CM コール処理サブスクライバがあり、2 番目のペアに ucm2a.ent-pa.com および ucm2b.ent-pa.com という名前の 2 つの Unified CM コール処理サブスクライバがあり、それぞれのペアで ucm1a、ucm2a がプライマリ Unified CM コール処理サブスクライバとなっている Unified CM クラスタの場合、 C：表 2-46 にリストされているように Unified CM グループをプロビジョニングします。

Unified CM グループ間ですべての登録のバランスを取る必要があります。それには、デバイス プールの項で説明しているデバイス プール設定を使用して、デバイスを Unified CM グループに割り当てます。

電話用 NTP リファレンス

必要に応じて、SIP を実行している電話が NTP サーバから日時を取得するように、[Cisco Unified CMの管理（Cisco Unified Communications Manager Administration）] で電話用 Network Time Protocol（NTP）を設定することができます。すべての NTP サーバが応答しない場合、SIP を実行している電話は、REGISTER メッセージに対する 200 OK 応答の日付ヘッダーを日時に使用します。

電話用 NTP を Cisco Unified CM の管理に追加した後は、日付/時刻グループにその電話用 NTP を追加する必要があります。

電話用 NTP を定義するには、使用する予定の NTP サーバの IP アドレスを取得し、 C：表 2-47 に従って設定を行います。

冗長性をもたらすためには、複数の電話用 NTP をプロビジョニングする必要があります。

日付および時刻グループ

日付および時刻グループを使用して、Unified CM に登録する一連のデバイスに使用するタイムゾーンおよび日付と時刻の形式を定義できます。日付および時刻グループはデバイス プールに設定し、デバイス プールは電話ページで指定します。デバイス プールの詳細については、
デバイス プールのセクションを参照してください。

SIP 電話で NTP サーバから日付と時間を取得したい場合は、電話用 NTP の優先順位を設定し
ている日時グループで、電話を接続する最初のサーバを最も高い優先順位にします。

エンドポイントを展開するそれぞれのタイム ゾーンに対して、 C：表 2-48 に示すように 1 つの日時グループを作成します。

メディア リソース

メディア リソースとは、ソフトウェア ベースまたはハードウェア ベースのエンティティであり、接続中のデータ ストリームに対してメディア処理を行うものです。メディア処理機能には、複数のストリームを混合して 1 つの出力ストリームを作成する機能（会議）、ある接続から別の接続にストリームを渡す機能（メディア ターミネーション ポイント）、ある圧縮タイプから別の圧縮タイプにデータ ストリームを変換する機能（トランスコーディング）、保留中の発信者への音楽のストリーミング（保留音）、エコー キャンセレーション、シグナリング、TDM 回線からの音声インターフェイス（コーディング/デコーディング）、ストリームのパケット化、オーディオのストリーミング（Annunciator）などが含まれます。ソフトウェアベースのリソースは、Cisco Unified CM IP Voice Media Streaming アプリケーションによって提供されます。

メディア　リソース　マネージャー

Unified CM のソフトウェア コンポーネントであるメディア リソース マネージャ（MRM）は、メディア リソースの割り当ておよびメディア パスの挿入が必要であるかどうかを判別します。MRM は、メディア リソースのタイプを判別および特定すると、当該デバイスに関連付けられているメディア リソース グループ リスト（MRGL）およびメディア リソース グループ（MRG）の構成の設定値に応じて、使用可能なリソース全体を検索します。MRGL および MRG は、割り当ての目的のためにメディア リソースの関連グループをまとめて保持している構成体です。

メディア リソースの選択とデフォルト MRG の回避

メディア リソース グループ（MRG）とメディア リソース グループ リスト（MRGL）は、リソースの割り当て方法を制御する方式を提供するもので、リソースに対するアクセス権、リソースの場所、特定のアプリケーションのリソース タイプが含まれます。MRG の使用により、類似の特性を持つメディア リソースがまとめてグループ化されます。MRGL は、セッションのために必要なメディア リソースを選択するときに考慮される MRG のセットを定義します。メディア リソース マネージャが設定されている MRGL を検索しても必要なリソースが見つからない場合は、すべてのメディア リソースがリストの MRG のメンバーであると見なして、メディア リソース マネージャがデフォルトのメディア リソース グループでメディア リソースをチェックします。特定の MRG のメンバーであることが明示的に設定されている場合を除き、デフォルトではすべてのメディア リソースはこのデフォルトの MRG のメンバーです。

この設計では、メディア リソース選択のトラブルシューティングがより複雑になってしまうため、デフォルトの MRG は使用しません。デフォルトの MRG が確実に空になるようにするには、すべてのメディア リソースを少なくとも 1 つの MRG に割り当てる必要があります。

Cisco IP Voice Media Streaming Application

Cisco IP Voice Media Streaming Application は、ソフトウェアベースの次のメディア リソースを提供します。

• 会議ブリッジ
• 保留音（MoH）
• アナンシエータ
• メディア ターミネーション ポイント（MTP）

Unified CM クラスタのノードで IP Voice Media Streaming Application が アクティブになると、上記ースの 1 つが自動的に設定されます。サービスのアクティブ化についての推奨事項は、 C：表 2-3 を参照してください。

この設計では、ユニキャスト MoH のみが使用され、Unified CM クラスタのサブスクライバ ノード上で稼働している Cisco IP Voice Media Streaming Application からメディアが流されます。

アナンシエータは Cisco IP Voice Media Streaming Application のソフトウェア機能で、これを使用すると、音声メッセージや各種コール プログレス トーンをシステムからユーザに流すことができます。

Unified CM 上で実行されている Cisco IP Voice Media Streaming Application によって作成されたすべての MOH およびアナンシエータ メディア リソースは、以下のタスクを実行することにより 1 つの MRG に組み込まれます。

• Software という名前の MRG を作成する。
• Cisco IP Voice Media Streaming Application で作成したすべてのアナンシエータ リソースを MRG Software に割り当てる。
• Cisco IP Voice Media Streaming Application で作成したすべての MoH リソースを MRG Software に割り当てる。

Cisco IP Voice Media Streaming Application で作成されたソフトウェアベースの会議およびメディア ターミネーション ポイントは、この設計では使用されません。これらのものを無効にするには、次のタスクを実行します。

• Unused という名前の MRG を作成する。
• Cisco IP Voice Media Streaming Application で作成されたソフトウェアベースの会議ブリッジを MRG Unused に割り当てる。
• Cisco IP Voice Media Streaming Application で作成されたソフトウェアベースのメディア ターミネーション ポイントを MRG Unused に割り当てる。

このようにすると、これらのリソースはデフォルトの MRG に属さないため、メディア リソース マネージャのメディア リソース選択プロセスでは考慮されなくなります。

MRG および MRGL の定義

プロビジョニングされた MRGL の数を最小に保持しておくことは重要なポイントです。必要な MRGL の数に影響を与える要因には、次のものがあります。

• サイトの特異性

サイト固有のメディア リソースが存在する場合は、それらのリソースに対してサイト固有の MRG を設定する必要があります。また一般的には、サイト固有のメディア リソースの選択（通常はローカル）を可能にするには、サイト固有の MRGL も必要になります。

• 同じクラスにおける異なるタイプのメディア リソース

Unified CM は音声のみの会議リソースと、音声/ビデオの会議リソースを区別しません。音声のみと音声/ビデオの両方の会議メディア リソースがプロビジョニングされている場合、これらのリソースに対して異なるアクセス ポリシーを設定できるようにするには、メディア リソースのタイプごとに MRG（および MRGL）が必要になります。会議リソースの詳細については、会議 の章を参照してください。

サイト固有のメディア リソースがなく、メディア リソースのタイプを区別する必要がない場合は、Standard という名前の MRGL を少なくとも 1 つ設定する必要があります。

サイトの特異性およびメディア リソース タイプのプロビジョニングに基づいて必要なそれぞれの MRGL に対して、次のタスクを実行して MRGL を作成します。

• サイトの特異性、および MRGL のメディア リソース タイプを反映するように、MRGL に名前を付けます。
• MRGL に対して適切な MRG を選択します。MoH およびアナンシエータに対するアクセスが保証されるよう、Software MRG は必ず含めるようにします。

C：表 2-49 は、音声会議とビデオ会議について処理が異なる MRGL の定義例を示しています。MRGL Video ではビデオ会議リソースへアクセスすることができますが、MRGL Audio は、音声会議メディア リソースへのアクセスのみが必要なデバイスへ割り当てる必要があります。

デバイス プール

デバイス プールはデバイスの共通の特性セットを定義します。デバイス プールで定義されている特性には、 C：表 2-50 に示されている設定が含まれています。

デバイス プールのその他のレベルの設定はすべて、この設計では使用されません。

デバイスのグループに対して、 C：表 2-50 に記載されている設定オプションで同じ設定を適用する必要がある場合は、これらの設定を持つデバイス プールを作成し、このデバイス プールにすべてのデバイスを割り当てることを推奨しています。すべてのデバイスに対して 1 つの設定を変更する必要がある場合は、デバイス プールのレベル設定を使用して、すべてのデバイスに対してその部分だけを変更することができます。

デバイス プールの数を最小にするには、複数のデバイスで同じ特性を共有している場合のみデバイス プールを作成します。次に、同じサイト内の電話の例を示します。 C：表 2-51 は、RTP サイト内でビデオ会議機能を使用している電話に対するデバイス プールの設定例です。

C：表 2-51 は、実際のサイト固有の PSTN ゲートウェイがどのように LRG 名に割り当てられて、異なるサイトの電話に関して、サイト固有の出口ゲートウェイの選択を実現しているかを示しています。

C：図 2-9 は、サイト RTP および SJC の電話のデバイス プールで、同じ LRG 名（LRG_PSTN_1）に対して異なる LRG を選択することにより、サイト RTP および SJC で同じルート パターンおよびルート リストが使用されている場合でも、それぞれの電話からの PSTN コールを、異なるゲートウェイを介してどのように PSTN へストリームするかを示しています。

C：図 2-9 サイト固有の出力ゲートウェイの選択

C：表 2-51 の例と同じスキーマで考えると、1 つのサイトについて 2 つのデバイス プールをプロビジョニングして、ビデオ会議の機能を備えたデバイスと、備えていないデバイスを区別できるようにする必要があります。ビデオ会議機能が例外になっている場合は、デバイス設定で MRGL を Audio（音声）に設定して、1 つのサイトにつき 1 つのデバイス プールのみを使用し、ビデオ対応の少数のデバイスで MRGL を Video（ビデオ）に設定するように決定できます。

C：表 2-52 は、特定のサイトのゲートウェイで使用されるデバイス プールの設定についてまとめています。ここでは、例としてサイト RTP を使用します。

C：表 2-53 は、他の Unified CM クラスタおよびアプリケーション サーバへの、SIP トランクに関するデバイス プールの設定についてまとめています。他の Unified CM クラスタへの SIP トランクでは、発呼側および着呼側の情報について変換は必要ありません。着呼側の番号は、ダイヤル プランでプロビジョニングされているダイヤル正規化変換パターンによってすでに +E.164 にグローバル化されているため、およびプロビジョニングされているダイヤル プランに基づいた Unified CM 内部の発呼側の情報は +E.164 または ESN であり、どちらの形式もネット上のクラスタ間コールの状態で有効になるためです。

SIP トランク

コール制御、アプリケーション、会議リソースなどの他のエンティティへのすべての接続は SIP トランクを使用します。

SIP プロファイル

SIP プロファイルは、SIP トランクおよび SIP エンドポイントに関連付けられている一連の SIP 属性で構成されています。SIP プロファイルの数を最小に保持するには、次のルールに従います。

• 最初にデフォルトのプロファイルを考慮します。
• 次に、すでに定義されているデフォルト以外のプロファイルを考慮します。
• デフォルトのプロファイルが一致しなかった場合のみ、新しい SIP プロファイルを作成します。
• トランクごとにプロファイルを定義しないようにします。

C：表 2-54 は、他の Unified CM クラスタまたは SIP ゲートウェイへのすべての SIP IP 電話および SIP トランクで使用する SIP プロファイルについての設定を示しています。

SIP トランク セキュリティー　プロファイル

Cisco CallManager Administration は SIP トランク セキュリティ関係の設定（デバイス セキュリティ モード、ダイジェスト認証、着信/発信転送タイプの設定など）をグループ化して、[SIPトランクの設定（SIP Trunk Configuration）] ウィンドウでプロファイルを選択するときに、設定したすべての内容を 1 つの SIP トランクに適用することができます。

C：表 2-55 は、SIP トランクのセキュリティ プロファイルである非セキュア SIP トランク プロファイル（Non Secure SIP Trunk Profile）で生成された、システム上のデフォルト設定について示しています。この SIP トランク セキュリティ プロファイルは、ISDN PSTN ゲートウェイ向けの SIP トランクなどで使用されます。

C：表 2-56 は、IM and Presence ノード向けの SIP トランクで使用される SIP トランク セキュリティ プロファイル（SIP Trunk Security Profile）の設定について示しています。これは、
C：表 2-55 のデフォルトの設定とは異なります。

C：表 2-57 は、他の Unified CM クラスタへのクラスタ間トランクで使用する SIP トランク セキュリティ プロファイルの設定について示しています。これらのトランクでは、プレゼンスの SUBSCRIBE を許可して、クラスタ間のビジー ランプ フィールド（BLF）プレゼンスを有効にするとよいでしょう。

SIP トランク接続

SIP トランクは、Unified CM のクラスタ間、および Unified CM と（ゲートウェイ、アプリケーション、メディア リソースなどの）他のシステム間での接続を設定する場合に推奨される方法です。接続するシステムのタイプによって、各 SIP トランクで設定されるパラメータは少し異なります。 C：表 2-58 は、サイト RTP における、PSTN ゲートウェイ向けの SIP トランクについての設定をまとめて示しています。

ここでは、着信 CSS はローカルな +E.164 の通知先のみにアクセスを提供することがポイントです。これらの通信先には、ボイスメール パイロットや、PSTN から到達可能であることが必要な他のサービスが含まれますが、PSTN のルート パターン、ダイヤル正規化変換パターン、ESN、URI、およびクラスタ間の通知先へのアクセスは必要ありません。

他の Unified CM クラスタへの SIP トランクの設定は、ISDN ゲートウェイへの SIP トランクの設定とは少し異なります。 C：表 2-59 に、これらの設定を要約します。

PSTN ISDN ゲートウェイ向けの SIP トランクとは異なり、+E.164 番号だけでなく他の Unified CM クラスタからの着信コールも ESN と URI へのアクセスが必要です。ただし、ルーティングのループやトランジット ルーティングを回避するために、クラスタ間のトランクはクラスタ間の通知先（パーティション onNetRemote、 C：表 2-12 を参照）へのアクセス権を持っていません。

IM と Presence ノードへの SIP トランクについては、Unified CM と IM と Presence 間の SIP トランクを設定します。SIP トランクについては、IM と Presence のすべてのノードの通知先 IP アドレスを設定します。IM と Presence サービスに対して自身が設定した SIP トランク セキュリティ プロファイルを選択します。標準の SIP プロファイルも選択します。

ルート グループ

すべての SIP トランクはルート グループに割り当てられます。ルート グループは、トランクと、共通の特性を組み合わせます。 C：表 2-60 は、サイト RTP における PSTN ゲートウェイに対するルート グループの定義を示しています。

注 ルート グループは、SIP トランクが作成された後でのみ設定することが可能で、SIP トランクは、それぞれのデバイス プールが設定された後でのみ追加することが可能です。これは、PSTN ゲートウェイに対してデバイス プールを作成するときには、ルート グループはまだ存在していないことを意味しています。したがって、設定の順序は次のようになります。

1。 デバイス プールで LRG マッピングを定義せずに、PSTN ゲートウェイに対するデバイス プールを設定します。

2。 SIP トランクを設定します。

3。 ルート グループを作成します。

4。 デバイス プールに戻り、（必要に応じて）LRG マッピングを追加します。

他の Unified CM クラスタ向けのクラスタ間トランクでは、1 つのトランクにつき 1 つのルート グループを定義する必要があります。 C：表 2-61 は、リモート Unified CM クラスタ向けのクラスタ間トランクに対するルート グループの例を示しています。

Unified CM にプロビジョニングされているそれぞれの非 PSTN SIP トランクに対しては、簡単な類似のルート グループを作成する必要があります。

特定の非 LRG ルート リスト

ローカル ルート グループを使用するルート リストのセクションでは、ローカル ルート グループのみを使用した PSTN アクセスのルート リストについて概要を説明します。非 PSTN トランクでは、特定のルート リストは、これらの非 PSTN トランクを参照するルート グループを使用して作成する必要があります。1 つのメンバーのみを持つ簡単なルート グループと、メンバーとして 1 つの非 LRG ルート グループのみを持つ簡単なルート リストを定義する理由は、Unified CM のルート パターンはトランクを直接指定しないためです。具体的には、Unified CM でルート パターンが変更されるたびに、ルート パターンが指定しているデバイスがリセットされます。（トランクの代わりに）ルート リストに対してルート パターンを指定すると、ルート パターンの編集によってトランク自身はリセットされずに、ルート リストがリセットされます。このようなトランクの例として、他の Unified CM クラスタおよびアプリケーション向けのトランクが含まれます。

C：表 2-62 は、他の Unified CM クラスタ向けのクラスタ間トランクの簡単なルート リストを示しています。

Unified CM にプロビジョニングされているそれぞれの非 PSTN SIP トランクに対しては、簡単な類似のルート リストを作成する必要があります。

エンドポイントのプロビジョニング

新しいエンドポイントをプロビジョニングする場合には、次の最小限のタスクが必要です。

• デバイスの設定
• 回線の設定
• ユーザーが制御するデバイスへデバイスを追加する
• プレゼンスに対する回線の関連付けの設定

デバイスの設定

Unified CM に新しいエンドポイントを追加する場合は、このドキュメントで説明している設計では、 C：表 2-63 に要約されている設定が必要です。ここに記載されていない設定はデフォルトのままにしておくか、または、デバイス特有の要件に従って設定する必要があります。

回線の設定

各エンドポイントで、少なくとも最初の回線をプロビジョニングする必要があります。 C：表 2-64 は、このドキュメントに記載されている設計固有の回線設定について説明しています。

ユーザーが制御するデバイスへデバイスを追加する

ユーザに関連付けられているデバイスでは、Unified CM Administration の [デバイス情報（Device Information）] セクションにおいて各ユーザの [エンドユーザの設定（End User Configuration）] でデバイスをプロビジョニングした後で、デバイスがユーザに関連付けられていることを確認します。これを実行するための推奨される方法は、[デバイスの割り当て（Device Association）] を選択し、ユーザの電話番号と一致する電話番号を持つデバイスを検索することです。

プレゼンスに対する回線の関連付けの設定

ユーザのプレゼンス状態を決定するために、プレゼンスに明示的に関連付けられている（DN およびデバイスごとの）ライン アピアランスのみが考慮されます。ユーザの電話番号のすべてのライン アピアランスがプレゼンスに対して考慮されることを確認するには、Unified CM Administration の [デバイス情報（Device Information）] のセクションで各ユーザの [エンドユーザの設定（End User Configuration）] で、[プレゼンスのラインアピアランス関連付け（Line Appearance Association for Presence）] を選択し、すべてのライン アピアランスを関連付けます。

ユーザーのプライマリー内線の確認

LDAP から同期されているユーザのディレクトリ URI が電話番号へ反映されていることを確認するには、Unified CM Administration で各ユーザの [エンドユーザの設定（End User Configuration）] の [電話番号の割り当て（Directory Number Associations）] セクションにおいて、[プライマリ内線（Primary Extension）] を選択します。

Jabber プロビジョニング

Service Discovery により、Jabber が自動的に設定を確立することができます。Jabber クライアントは Unified CM User Discovery Service（UDS）を介して自身の設定を取得します。これは推奨される設定で、以前の手動による設定よりも優先されます。

サービスは UC サービスを介して設定されます。サービス プロファイルは、どの UC サービスを使用するかを指定します。各ユーザは、1 つのサービス プロファイルに関連付けられています。

C：表 2-65 は、Jabber クライアントで使用することができる UC サービスを示しています。これらのサービスは [ユーザ（User）] > [ユーザ設定（User Settings）] > [UCサービス（UC service）] で設定されます。

UC サービスをサービス プロファイルに関連付けます。次に、サービス プロファイルを各ユーザに関連付けます。複数の Unified CM 呼処理サブスクライバを備えている展開では、Unified CM のすべての呼処理サブスクライバに対して CTI の負荷を均等に分散させて、CTI の拡張性制限が、CTI Manager サービスを実行している単一の Unified CM の呼処理サブスクライバを超えないようにします。Jabber クライアントを、CTI Manager サービスを実行しているもう 1 つの Unified CM の呼処理に関連付けるには、関連する CTI UC サービスの設定を使用してもう 1 つのサービス プロファイルを設定します。