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

このマニュアルの範囲

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 クラスタ サーバは、次のプラットフォーム上に導入できます。

• 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 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 コールに使用するノードと同一にすることはできません。

クラスタオーバー 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 が推奨されます。

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

クラスタオーバー 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 トラフィックの追加分を計算に入れてください。

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

大幅な時間遅延や、可能性のある多数のコールシグナリング レッグで分割されるデバイス間のコールでは（たとえば、図 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 コールシグナリング遅延の影響

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

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 クラスタ上で、各 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 により管理された集中型ダイヤル プランは、グローバルで一意な番号を使用する番号計画に基づく必要があります。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 ルート パターンのみを指定できるようにする必要があります。

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 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 のための複数クラスタによる単一プラットフォームの共有

安全な 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 クラスタ間トランク

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

標準のリーフ クラスタ モビリティ導入のサポートについては、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/mobilapp.html にある『Cisco Unified Communications System Release 8.x SRND』で説明されています。

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 を参照してください。

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

一般的な推奨事項として、円滑なエンドツーエンドの 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 で渡されます。

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 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 の導入

このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアル内の例、コマンド出力、ネットワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際のアドレスおよび電話番号が使用されていたとしても、それは意図的なものではなく、偶然の一致によるものです。

Copyright © 2011 Cisco Systems, Inc.
All rights reserved.

Copyright © 2011, シスコシステムズ合同会社.
All rights reserved.