Cisco Unified Communications Manager 機能およびサービス ガイド リリース 8.5(1)

インド通信規制の適用

Telecom Regulatory Authority of India（TRAI）の規制では、エンタープライズ データ ネットワークおよび公衆電話交換網（PSTN）経由の音声トラフィックを厳密に区別し、トール バイパス目的でこの 2 つのネットワーク間のコールを混在させてはならないと規定されています。

次に、制限される（つまり、許可されない）基本シナリオを示します。

• PSTN ゲートウェイをパススルーするコールが、WAN を使用して、地理的に異なる場所にある VoIP 電話機または VoIP PSTN ゲートウェイに直接接続されます。

– インドに PSTN ゲートウェイが存在する場合でも、このシナリオは厳しく制限されます。PSTN はインド以外の国、VoIP 電話機はインドにあって、接続した結果インドの通信サービス プロバイダーの収益が低下する場合、この接続は制限の対象となります。

次に、許可される基本シナリオを示します。

• 地理的に異なる場所にある 2 つの VoIP 電話機を直接結ぶコール

• 地理的に同じ場所にある VoIP 電話機から PSTN ゲートウェイへのコール

PSTN ゲートウェイをパススルーするコールが、IP テレフォニーを使用して、異なるサイトまたは地理的場所（位置情報）にある VoIP 電話機または VoIP PSTN ゲートウェイに直接接続しないようにする必要があります。

配置要件

TRAI 規制を順守し、トール バイパスを回避しつつ、推奨される設定ガイドラインに従って、1 回線電話機が VoIP（Closed User Group [CUG; 非公開ユーザ グループ]）または PSTN ネットワークの外部に達することができるようにする必要があります。

（注） トール バイパスを回避するには、論理パーティションを有効にします。

利用可能な Cisco Unified Communications Manager サポート

Cisco Unified Communications Manager では、論理パーティション機能の実装に先立って、次のサポートが提供されます。

• 複数の電話機が、同じ回線を使用して、VoIP ネットワークまたは PSTN ネットワークに達することができます。

• 既存の Calling Search Space（CSS; コーリング サーチ スペース）およびパーティションのメカニズムにより、基本コール専用にネットワークをパーティション化できます。

1 回線の制限

論理パーティション機能の設定なしで（または設定前に）1 回線を使用するときには、次の制限があります。

• コール中の参加：転送などの補足機能の呼び出し時に、WAN 上の VoIP ネットワークに接続するコールと PSTN ネットワークに確立される別のコールがともに参加することがあります。

• リダイレクト：自動転送などの補足機能の呼び出し時に、WAN 上の VoIP ネットワークを流れるコールが PSTN ネットワークにリダイレクトされることがあります。

論理パーティション機能が有効になっていないと、制限の対象となるシナリオを呼び出さないように補足機能を設定することができません。

論理パーティションを使用する前の既存の配置

インドなどの国では、電話機の分割回線を使用して、VoIP（CUG）ネットワークと PSTN ネットワークを分けています。この実装はこれまで、低コストのアナログ電話機と 1 回線の VoIP 電話機を使用できないようになっていました。

2 回線の電話機を使用する配置の場合、Join Across Lines（JAL; 回線をまたいで参加）や Direct Transfer Across Line（DTAL; 回線をまたいで直接転送）などの補足機能を呼び出すと、TRAI 規制で制限されるシナリオとなることがあります。このような配置を TRAI 規制に準拠させるには、論理パーティション機能が必要です。

追加情報

「関連項目」を参照してください。

これまでの経緯

従来、インドの規制では、VoIP システムを PSTN 相互接続システムとは物理的に分けるよう規定されていました。ユーザは、局間電話コール専用に VoIP システムで電話を使用していましたが、PSTN と相互に通信する必要があるコールは PSTN システムを使用して確立する必要がありました。2008 年時点の TRAI 規制では、単一のシステムで両タイプのコールをサポートすることが許可されています。ただし、禁止されているコールは完了しないようにシステムを設定できる場合だけです。Cisco Unified Communications Manager システムでは、 論理パーティション という用語がこの機能を指しています。

リリース 7.1(x) よりも前の Cisco Unified Communications Manager リリースを使用してインドでエンタープライズ VoIP を実装する場合は、VoIP 接続と PSTN 接続のいずれにも同じ Cisco Unified IP Phone を使用します。 Cisco Unified Communications Manager では、参加者が VoIP ドメインまたは PSTN ドメインに存在する 1 回線から補足機能を呼び出すときには、VoIP トラフィックと PSTN トラフィックの混在を制御するための特定の設定はサポートされていません。規制に準拠するために、これまでインドに VoIP を実装する場合は、PSTN コールおよび VoIP コールに VoIP 電話機の分割回線を使用していました。

Cisco Unified Communications Manager では、各回線の設定にパーティションおよびコーリング サーチ スペース（CSS）という概念を導入しています。このため、VoIP ドメインと PSTN ドメインの制御が別々になっており、1 回線の電話機では転送などの機能を実行できません。このような機能を呼び出すと、PSTN ネットワークで VoIP の参加が可能になるためです。

この制限があるため、インドではシスコシステムズの装置を使用してエンタープライズ VoIP を配置しても、少なくとも 2 回線を備えた電話機を使用するという制限が引き続き存在し、ほとんどのカスタマーにとっては経済的なソリューションとなりません。また、この制限のため、仕様により 1 回線となっている低コストのアナログ電話機を使用するソリューションも、VG224/VG248 ゲートウェイを使用するソリューションも実現できません。

これらの制限に対処するために、Cisco Unified Communications Manager ソリューションでは管理者ポリシーによって Cisco Unified IP Phone で 1 回線の論理パーティションを設定できるようになっています。ただし、参加者の属性タグまたは位置情報に基づいて、コール参加またはコールの転送を制御する必要があることに注意してください。

追加情報

「関連項目」を参照してください。

論理パーティションでの位置情報および位置情報フィルタの使用

Cisco Unified Communications Manager 管理者は、次の項目を定義する必要があります。

• 論理パーティションを使用するデバイスごとの 位置情報 。詳細については、「位置情報の特徴」を参照してください。

• 論理パーティションを使用するデバイスごとの 位置情報フィルタ 。詳細については、「位置情報フィルタについて」を参照してください。

Cisco Unified Communications Manager 管理者は続いて、位置情報および位置情報フィルタをデバイスに割り当てます。

Cisco Unified Communications Manager クラスタ 内の次のエンティティに位置情報と位置情報フィルタの値を割り当てることができます。

• デバイス プール

• CTI ルート ポイント

• 電話機（オプション）

• CTI ポート

（注） 電話機の場合、電話機に位置情報フィルタを関連付けるためのドロップダウン リスト ボックスは指定しません。

• SIP トランク

• クラスタ間トランク（ICT）

• H.323 ゲートウェイ

• T1、E1、PRI、FXO タイプの MGCP ポート

Media Termination Point（MTP; メディア ターミネーション ポイント）、Conference Bridge（CFB; 会議ブリッジ）、アナンシエータ、Music On Hold（MOH; 保留音）サーバなどのメディア デバイスは、位置情報および位置情報フィルタに関連付ける必要はありません。

Cisco Unified Communications Manager のデバイス層には、コール処理で使用される位置情報の値が内部的に関連付けられます。次に、一連の処理を示します。

1. デバイスがデバイス レベルまたはデバイス プール レベルでの設定用に GeolocationPkid および GeolocationFilterPkid を読み取ります。

2. デバイスは、コール シグナリング時に CC（たとえば、CcRegisterPartyA）および PolicyAndRSVPRegisterReq メッセージでこの Pkid と deviceType の情報を伝達します。

3. コール処理およびコール機能層が、この情報を使用して、論理パーティション ポリシーをチェックします。

位置情報の標準レコードは 未指定 です。位置情報をデバイスに関連付ける必要がない場合は、この値を使用します。デバイスの場合、位置情報を 未指定 にするか、または位置情報フィルタに [なし(None)] を指定すると、識別子が作成されず、そのデバイスは論理パーティション ポリシー チェックに参加しません。

[エンタープライズパラメータ設定(Enterprise Parameters Configuration)] ウィンドウのドロップダウン リスト ボックスから、Default Geolocation エンタープライズ パラメータおよび Logical Partitioning Default Filter エンタープライズ パラメータを設定できることに留意してください。

位置情報および位置情報フィルタの例

位置情報の例については、 「位置情報およびロケーション伝達」 の章の 表 24-4 を参照してください。

位置情報フィルタの例については、 「位置情報およびロケーション伝達」 の章の 表 24-6 を参照してください。

追加情報

「関連項目」を参照してください。

シェアドラインおよびルート リストでの論理パーティション位置情報の使用

着信側がグループ デバイスの場合、グループ内のデバイスごとに別個の位置情報を適用できます。早期在席シナリオの場合、実際に接続されるデバイスはデバイスが応答するまでわかりません。そのため、デバイスが応答するまで、位置情報は集約されます。

• コール制御および機能の層は、デバイスが応答するまで、一時位置情報（「MixedDevice」）を受信します。

• デバイスが応答し、デバイスの実際の位置情報が使用可能になるまで、機能層または LPSession プロセスの論理パーティション ポリシー チェックは無視されます。

• この動作は、応答時まで論理パーティション ポリシー チェックを遅らせることによって、早期在席転送機能および早期在席会議機能に影響を及ぼします。

追加情報

「関連項目」を参照してください。

論理パーティションでの位置情報識別子の使用

位置情報識別子は、位置情報、位置情報フィルタ、および Cisco Unified Communications Manager デバイスのデバイス タイプで構成されます。

詳細については、 「位置情報およびロケーション伝達」 の「位置情報識別子」を参照してください。

追加情報

「関連項目」を参照してください。

論理パーティション ポリシー

次のエンティティ間に必須の相互接続動作には、論理パーティション ポリシーを設定します。

• PSTN ゲートウェイと VoIP 電話機

• PSTN ゲートウェイと PSTN ゲートウェイ

• クラスタ間トランク（ICT）と VoIP 電話機

• ICT と VoIP ゲートウェイ

System Default Policy エンタープライズ パラメータ（デフォルト値 = DENY）は、設定済みのポリシーが見つからない場合のデフォルトのポリシーです。

許可ポリシーと拒否ポリシーを設定します。設定の詳細については、「許可ポリシーおよび拒否ポリシー」を参照してください。

[論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] ウィンドウ（Cisco Unified Communications Manager の管理ページの [コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] メニュー オプション）で、管理者は位置情報に設定されているフィールドのサブセットから位置情報ポリシー レコードを作成する必要があります。Cisco Unified Communications Manager の管理ページを使用して論理パーティション ポリシー レコードを作成する方法の詳細については、「論理パーティションポリシーの設定」を参照してください。

論理パーティション ポリシーは、位置情報ポリシー レコードとデバイス タイプのペア間に設定します。

論理パーティション ポリシーの例

({geolocpolicy1, devType1}, {geolocpolicy2, devType2}, Allow)

次の表に、位置情報、デバイス タイプ、およびポリシー タイプ間の論理パーティション ポリシーの構造を示します。

まず、次の位置情報ポリシー レコードがあるとします。

これらのレコードから、次のサンプルの論理パーティション ポリシーを設定できます。システム デフォルト ポリシーは DENY です。

最初の論理パーティション ポリシーは次のようになっています。

BLRBLD1GeolocPolicy に一致するゲートウェイと BLRBLD1GeolocPolicy に一致する VoIP 電話機の間のすべてのトラフィックを許可しています。

さらに詳細なポリシーが必要である場合は、位置情報 NAM フィールドを使用すると、建物内のデバイスの名前を指定できます。

例

• バンガロールの BLD1 にある固定電話機とゲートウェイ 1 の間

Interior:（country=IN、A1=KA、A3=Bangalore、LOC=BLD1、NAM=deskphone）

Border:（country=IN、A1=KA、A3=Bangalore、LOC=BLD1、NAM=gateway1）= 許可

• バンガロールの BLD1 にある Cisco IP SoftPhone と ICT1 の間

Interior:（country=IN、A1=KA、A3=Bangalore、LOC=BLD1、NAM=softphone）

Border:（country=IN、A1=KA、A3=Bangalore、LOC=BLD1、NAM=ICT1）= 許可

位置情報フィールドが上記のポリシーに一致するデバイスは、ポリシーに従って互いに通信できます。

Cisco Unified Communications Manager の管理ページを使用して論理パーティション ポリシーを設定する方法の詳細については、「論理パーティションポリシーの設定」を参照してください。

追加情報

「関連項目」を参照してください。

LPPolicyManager およびポリシー ツリー

LPPolicyManager は、データベースとのインターフェイスとなって、コール処理のポリシーを論理パーティション ポリシー ツリー形式で保持する単一プロセスです。Cisco Unified Communications Manager サービスの起動中、LPPolicyManager はデータベース テーブルからポリシーを読み取り、論理パーティション ポリシー ツリーを構築します。

データベースでポリシーの追加/削除/更新を行うと、LPPolicyManager に変更内容が通知され、その変更が論理パーティション ポリシー ツリーに反映されます。

コール処理は、LPPolicyManager とのインターフェイスとなって、デバイスの位置情報ポリシー レコードに対応する論理パーティション ポリシーを読み取ります。

LPPolicyManager は、次の検索タイプのユーティリティ機能を備えています。

• デバイス ペアの位置情報

• 既存のデバイスと新規参加者の位置情報

• 既存のデバイスの位置情報と新規参加者のリスト

ポリシー ツリーの例

ここでは、ポリシー ツリーの例を示します。

図 32-1 に、論理パーティション ポリシーのポリシー ツリーの例を示します。バンガロールにあるゲートウェイ（BLD1、BLD2）とバンガロールにある VoIP 電話機（BLD1、BLD2）の位置情報ポリシー レコード間に存在するインド クラスタのポリシーです。

（注） 通常、特定のソース位置情報ポリシー レコードと特定のターゲット位置情報ポリシー レコード間にポリシー ペアが 1 つだけ設定されます。

ポリシー ツリーは、ペア化されたポリシーがツリーのソース部分とターゲット部分となるように構築されます。

たとえば、データがソース = Border:IN:KA:Bangalore:BLD1 およびターゲット = Interior:IN:KA:Bangalore:BLD1 で、 許可 ポリシーが設定されたポリシー レコードが、次のノードに関連付けられています。

• ソース部分の Border、IN、KA、Bangalore、BLD1

• ターゲット部分の Interior、IN、KA、Bangalore、BLD1

この例の場合、許可ポリシーがターゲット部分のリーフノードに設定されます。

この図は、ツリーのターゲット部分ではレベルごとにポリシーが設定可能であることを示しています。つまり、各ノード（Interior、IN、KA、Bangalore、および BLD1）にポリシーを設定できます。

図 32-1 インド クラスタに適用される論理パーティション ポリシーのポリシー ツリーの例

ポリシー ツリー内を検索するための論理パーティション ポリシー検索アルゴリズムについては、「論理パーティション ポリシー検索アルゴリズム」を参照してください。 表 32-3 に、このポリシー ツリーでポリシーが見つかった場合の置換をすべて記載したリストを示します。

ポリシー ツリーの構築

ポリシー ツリーの構築は、決められたアルゴリズムに従います。ポリシー ツリーにはソース部分とターゲット部分が含まれています。

1. [GLP_X Border GLP_Y Interior] ポリシーが追加されます。構築には GLP_X Border のソース部分と GLP_Y Interior のターゲット部分が必要です。

2. [GLP_Y Interior GLP_X Border] ポリシーが追加されます。構築には GLP_X Border のソース部分と GLP_Y Interior のターゲット部分が必要です。

したがって、Border-to-Interior ポリシーは、Border 部分が必ずツリーのソース部分から始まります。リーフノードにポリシーが追加されます。

3. [GLP_X Border GLP_Y Border] ポリシーが追加されます。

最初に、ソース部分の GLP_X を追加するか、またはソース部分の GLP_Y を追加するかどうかが決定されます。

既存のポリシーが（他の GLP ポリシーにより）GLP_X または GLP_Y のいずれのトークンにも一致しない場合、ツリーの構築には GLP_X Border のソース部分と GLP_Y Border のターゲット部分が必要です。

既存のポリシーがソース部分の一部のトークンに一致する場合、ソース部分はその GLP から取得されます。

例 1： GLP_Y Border GLP_X Interior は常に設定されます。

GLP_Y はソース部分ですでに使用されているので、[GLP_X Border GLP_Y Border] ポリシーを追加するために GLP_Y がソース部分に追加されます。

例 2： 2 つのポリシー [GLP_X Border GLP_Y Interior] と [GLP_Y Border GLP_X Interior] が存在する場合は、Border で始まる 2 つのソース ブランチが存在します。

GLP_B は（GLP_Y と比較して）GLP_X と重複するトークンが多いこと、および GLP_A は Border ブランチとは一致しないことを前提としています。

[GLP_A Border GLP_B Border] ポリシーを追加するため、GLP_A または GLP_B が既存のソース ブランチに一致するかどうかについて、ポリシーが検索されます。

GLP_B が GLP_X のトークンに一致すると、ツリーの一部が GLP_X と共有されます。

Border:IN:KA:BLR:BLD1 と Border:IN:MH:MUM:BLD1 が存在することを前提としています。

Border:IN:MH:Pune:BLD1 を Border:IN:KA:BLR:BLD2 ポリシーに追加する場合は、Border:IN:KA:BLR のソース部分が使用されます。このとき、ソース ツリーのリーフには BLD2 が追加され、Border:IN:MH:Pune:BLD1 のターゲット部分が追加されます。

したがって、Border-to-Border ポリシーの場合、ポリシー ツリーは既存のソース ブランチおよびターゲット ブランチに最も一致するように構築されます。できるだけ多くのノードを共有するように考慮してください。

追加情報

「関連項目」を参照してください。

論理パーティション ポリシー検索アルゴリズム

ここでは、論理パーティション ポリシー検索アルゴリズムについて説明します。

論理パーティション ポリシー検索アルゴリズムは、次のように機能します。

• コール制御時または機能のインタラクション時にポリシーが検索されます。

• 実行時にツリー走査を使用して設定済みのポリシーを検索する場合には、設定済みのポリシー ツリーが使用されます。

• ソース（A）デバイスおよびターゲット（B）デバイスの位置情報（つまり、位置情報、位置情報フィルタ、およびデバイス タイプ）を使用して、デバイス ペア間でポリシーが検索されます。

基本操作

位置情報および位置情報フィルタ情報から名前/値のペア（つまり、pairList1 および pairList2）を構築します。

例： pairList ="Country=IN:A1=KA:A3=Bangalore:LOC=BLD1"

検索の入力は {pairList1, devType1} および {pairList2, devType2} です。

ポリシーの検索では、次の手順が実行されます。

ステップ 1 devType1=Border および devType2=Interior の場合は、{devTypeA=devType1, pairListA= pairList1} および {devTypeB=devType2, pairListB= pairList2} を設定します。

ステップ 2 devType1=Interior および devType2=Border の場合は、{devTypeA=devType2, pairListA= pairList2} および {devTypeB=devType1, pairListB= pairList1} を設定します。

ステップ 3 ポリシー ツリーのノードを検索して、完全一致ペアを照合します。{devTypeA, pairListA} の値を使用し、ツリーのソース ブランチを探します。

ステップ 4 {devTypeB, pairListB} の値を使用し、ツリーの（ペア化された）ターゲット ブランチを探します。

ステップ 5 ツリーで完全一致が見つかり、ポリシーが設定されている場合は、リーフノードに設定されているポリシー データを使用し、ポリシー値を返します。

ステップ 6 完全一致が見つからない場合は、pairListB 入力からカラムを 1 つ除去して一致を検索します（つまり、ポリシー ツリーの（ペア化された）ターゲット ブランチで 1 つ上のレベルに進み、対応するノードにポリシー データが設定されているかどうかを確認します）。

ステップ 7 一致が見つかった場合、ポリシー値を返します。見つからない場合、引き続きポリシー ツリーのペア化されたブランチを上に進み、ポリシー データが設定されているかどうかを確認します。

ステップ 8 ポリシーが見つからない場合、pairListA に対応するソース ブランチで 1 つ上のレベル（ノード）に進みます。

ステップ 9 ポリシーが見つかるか、またはルート ノードに達するまで、ステップ 4 からステップ 8 を繰り返します。

ステップ 10 devType1=Border および devType2=Border の場合は、走査を行って完全一致を検索します。{devTypeA=devType1, pairListA= pairList1} および {devTypeB=devType2, pairListB= pairList2} を使用します。見つからない場合は、走査を行って {devTypeA=devType2, pairListA= pairList2} および {devTypeB=devType1, pairListB= pairList1} を使用します。

（注） ツリー レイアウトには、管理者がポリシーを追加した方法に基づいて任意の順序を指定できます。したがって、両方の組み合わせを使用してツリーを検索する必要があります。

ポリシーが次のデータで検索されるとします。

（devTypeA = "Border"、pairListA = "Country=IN:A1=KA:A3=Bangalore:LOC=BLD1"、devTypeB = "Interior"、pairListB = "Country=IN:A1=KA:A3=Bangalore:LOC=BLD1"）。

表 32-3 に、考えられるポリシーの置換をすべて示します。どの値も照合されます。検索アルゴリズムは、表に指定されている順に、設定済みのポリシーを探します。

最初に一致したエントリに対応する設定済みポリシーが使用されます。

位置情報識別子のペアを指定したものの、設定済みのポリシーが見つからない場合は、論理パーティション デフォルト システム ポリシーが使用されます。

追加情報

「関連項目」を参照してください。

ポリシー マッチング

次の場合にポリシー チェックが行われます。

• コールが PSTN ゲートウェイと VoIP 電話機を接続する場合。

• コールが、PSTN ゲートウェイと VoIP 電話機を接続する補足サービス（転送や会議など）を呼び出す場合。

• ポリシーに基づいて、制限されているすべてのコールおよび接続が拒否される場合。

追加情報

「関連項目」を参照してください。

ポリシー拒否の処理

論理パーティション ポリシーに従ってコールが拒否されると、次の処理が発生します。

• Cisco Unified Communications Manager が送信するリオーダー音とともに基本コールがクリアされます。

– 原因コード = 63 "Service or option not available." を使用して、Q.850 準拠のデバイス（SCCP、H323、MGCP）がクリアされます。

– SIP ステータス コード = 503 "Service unavailable." を使用して、SIP 回線または SIP トランクがクリアされます。

• 機能が、個々の機能に基づいて処理されます。

– コールのクリアが伴う場合、原因コード = 63 または SIP ステータス コード = 503 が使用されます。

– 機能ベースのメッセージが、VoIP 電話機に送信されて状況表示行に表示されます。

– 機能を呼び出すアナログ電話機の場合、転送の結果、両方のコールがクリアされます。会議は、セカンダリ コールをクリアして、アナログ電話機のリオーダー音を再生します。

追加情報

「関連項目」を参照してください。

LPSession インフラストラクチャおよびポリシー チェック

LPSession は、集中型ポリシー チェック インフラストラクチャを提供するように Cisco Unified Communications Manager Resource Reservation Protocol（RSVP）インフラストラクチャを拡張するインフラストラクチャです。

（注） RSVP インフラストラクチャの拡張は、ペア化された同じような論理パーティション ポリシー チェック動作を土台としています。論理パーティションが RSVP のポリシー チェックに影響を及ぼすことはありません。その逆も同じです。

次の操作では、ポリシー チェックに LPSession インフラストラクチャを使用しています。

• 基本コール

• リダイレクト（たとえば、自動転送、リダイレクト機能、およびパーク復帰）

• 分割/参加プリミティブ

よく使用される次の機能では、分割/参加または転送の前に、機能層で論理パーティション ポリシー チェックが実行されます。

• 転送

• アドホック会議

• ミートミー会議

• ピックアップ

• コール パークとダイレクト コール パーク

それ以外の分割/参加機能および類似機能は、分割/参加プリミティブ レベルのポリシー チェックを LPSession インフラストラクチャに依存しています（たとえば、Cisco Unified Mobilityの場合は MKI）。

追加情報

「関連項目」を参照してください。

基本コール用の論理パーティション処理

ここでは、基本コールの論理パーティション処理について説明します。

動作

発信側デバイスおよび着信側デバイスの位置情報ポリシー レコード間で、論理パーティション ポリシーがチェックされます。

設定

発信側デバイスおよび着信側デバイスのいずれにも、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• VoIP 電話機と PSTN ゲートウェイ、PSTN ゲートウェイと別の PSTN ゲートウェイ、ICT と PSTN ゲートウェイ、または ICT と別の ICT 間での基本コールの間。

• 番号分析の事後処理の間（コールをルーティングするために設定済みのコーリング サーチ スペースおよびパーティションが使用される）。

• Cisco Unified Communications Manager が、着信側および発信側の Cisco Unified Communications Manager デバイスに関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

• 設定済みの論理パーティション ポリシーが発信 Cisco Unified Communications Manager デバイス層に戻され、そのポリシーに従ってアクションが実行される場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 発信側と着信側の両方のデバイスが、VoIP 電話機（DevType = Interior）である場合。

• 位置情報と位置情報フィルタがどのデバイスにも関連付けられていない場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• コールが、リオーダー音とともに拒否されます。

• コールは、電話、ゲートウェイ、およびクラスタ間トランクに延長されません。

• Number of Basic Call Failures パフォーマンス モニタリング（perfmon）カウンタが増分されます。

追加情報

「関連項目」を参照してください。

論理パーティションと、SIP トランクおよびクラスタ間トランクをまたぐ位置情報伝達とのインタラクション

論理パーティションが複数クラスタ環境に適用される場合は、ロケーション伝達を設定します。

ロケーション伝達設定は単一クラスタ環境の論理パーティション設定と同じ設定を必要としますが、デバイスがリモート クラスタに属する場合には追加の設定が必要です。

ロケーション伝達を必要としないシステムの論理パーティションを設定する方法の詳細については、「論理パーティションの設定チェックリスト」を参照してください。

参加者がクラスタをまたぐ論理パーティション シナリオをサポートするには、SIP トランクおよびクラスタ間トランクから次のサポートが必要です。

• クラスタ間で位置情報およびデバイス タイプ情報が送信される。

• コール確立時にも、コール中の参加とリダイレクト時にも、この情報が送信される。

• トランクに位置情報フィルタが設定される。

– この設定では、位置情報識別子の作成が許可されます。これらの位置情報識別子に基づいて、論理パーティション ポリシー チェック用にポリシー レコードを設定できます。

SIP トランクまたはクラスタ間トランクの設定で [位置情報の送信(Send Geolocation Information)] チェックボックスがオンになっている場合には、位置情報がクラスタ間で送信されます。

• デバイスの位置情報が設定されている場合、SIP トランクまたはクラスタ間トランクのインタラクションでは、位置情報がトランクをまたいでコール シグナリングで送信されます。

（注） ロケーション伝達は、どの論理パーティション設定にも依存しません。

詳細については、「SIP トランクおよびクラスタ間トランクの間での位置情報の伝達」を参照してください。

「ロケーション伝達の設定チェックリスト」 に、ロケーション伝達の設定に関する詳細なチェックリストを示します。

追加情報

「関連項目」を参照してください。

取得した位置情報の論理パーティション処理

受信側クラスタが論理パーティションに対して有効になっている場合、受信側クラスタは取得した PIDF-LO 位置情報を使用して、Cisco Unified Communications Manager のデバイスの論理パーティション ポリシーをチェックします。

詳細については、「受信された位置情報の処理」を参照してください。

また、ポリシー チェックに位置情報を使用する機能のリストについては、「インタラクション」を参照してください。

追加情報

「関連項目」を参照してください。

論理パーティション機能とコール中位置情報変更とのインタラクション

論理パーティションが有効になっている場合、次の手順が実行されます。

• SIP トランクまたはクラスタ間トランクが、論理パーティション ポリシーをチェックし、設定済みポリシーに基づいてアクションを実行します。

• 会議やミートミーなどの機能層が、トランク デバイスの最新の位置情報に基づいて、論理パーティション ポリシーを再チェックします。

コール中位置情報の変更を伴う機能のインタラクションについては、「コール中に位置情報が変更された場合の機能インタラクション」を参照してください。

また、ポリシー チェックに位置情報を使用する機能のリストについては、「インタラクション」を参照してください。

追加情報

「関連項目」を参照してください。

ダイナミック SIP トランク

Cisco Intercompany Media Engine（IME）、Service Advisement Framework（SAF）、または Cisco クラスタ間のエクステンションモビリティ（EMCC）などのダイナミック SIP トランクの場合、ターゲット クラスタは指定された宛先によって異なります。これらのトランク上で設定できるデバイスレベルの位置情報および位置情報フィルタには、宛先に応じて設定を変更する柔軟性がない場合があります。このような SIP トランクは、これらのトランクからのトラフィックが許可または拒否されるように、適切に設定する必要があります。ロケーション伝達機能を使用することをお勧めします。この機能を使用すると、実際の位置情報をクラスタ間に適用でき、正確な論理パーティション ポリシーのチェックに役立ちます。

追加情報

「関連項目」を参照してください。

論理パーティションの SIP トランクまたはクラスタ間トランク設定要件

論理パーティションが有効になっているクラスタは、一般に次のように動作します。

1. VoIP 電話機と SIP トランク（またはクラスタ間トランク [ICT]）間のトラフィックが許可されます。

2. SIP トランク（または ICT）と PSTN ゲートウェイ間のトラフィックがブロックされます。

3. SIP トランク（または ICT）と SIP トランク（または ICT）間の VoIP 専用トラフィックが許可されます。

これらの動作を実現するには、論理パーティション ポリシーを設定する必要があります。

非ロケーション伝達クラスタとのインタラクション

動作 1 および 3 を実現するには、その動作ごとにポリシーを 1 つ設定する必要があります。デフォルト ポリシーが DENY である場合は、動作 2 のポリシーは必要ありません。

動作 1 および 3 については、ロケーション伝達が存在しないため、論理パーティション クラスタはトラフィックが VoIP 専用であるのか、リモート クラスタのゲートウェイから発信されているのかを特定できません。つまり、一般に SIP トランク（または ICT）から VoIP 電話機または他の SIP トランク（または ICT）に発信されるすべてのトラフィックを許可する必要があります。

ロケーション伝達クラスタとのインタラクション

動作 1 の場合、SIP トランク（または ICT）をコールする VoIP 電話機には、そのトランクでのコールの延長を許可するポリシーが必要です。これは、リモート クラスタからロケーション伝達情報を受信する前に発生します。

SIP トランク（または ICT）からの着信 VoIP コールの場合、発信側 VoIP 電話機のポリシーは必要ありません。SIP トランク（または ICT）からのトラフィックを他の ICT または PSTN ゲートウェイに許可する必要がある場合は、対応するポリシーが必要です。

例

バンガロールから RCDN クラスタを指す SIP トランクは次のように設定します。

位置情報 = "IN:KA:Bangalore:ICTToRCDN"

位置情報フィルタ = "UseCountry, UseA1, UseA3, UseNam"

この設定では、SIP トランクの位置情報識別子を次のように指定します。

{"IN:KA:Bangalore:ICTToRCDN", devType=Border}

論理パーティション ポリシーを次のように設定します。

"Border:IN:KA:Bangalore:ICTToRCDN" to Interior = 許可
結果： バンガロール クラスタのすべての VoIP 電話機が Richardson と通信できます。

"Border:IN:KA:Bangalore:ICTToRCDN" to "Border:IN:KA:Bangalore:ICTToRCDN"= 許可 結果： ICT が通信できます。

これらのポリシーは、動作 1 および 3 の要件を満たしています。

ロケーション伝達シナリオの場合、クラスタをまたぐデバイスの位置情報設定およびデバイス タイプに基づいて、ポリシーを設定します。

追加情報

「関連項目」を参照してください。

インタラクション

次の項では、論理パーティションおよび補足機能と、次に挙げるコール処理 エンティティとのインタラクションについて説明します。

（注） Logical Partitioning Default Policy エンタープライズ パラメータを設定し、[コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] メニュー オプションを使用して対応する論理パーティション ポリシーを設定します。

• 「自動転送」

• 「コール転送」

• 「アドホック会議、参加、回線をまたいで参加（JAL）」

• 「ミートミー会議」

• 「コール ピックアップ」

• 「コール パークとダイレクト コール パーク」

• 「Cisco エクステンション モビリティ」

• 「Cisco Unified Mobility」

• 「シェアドライン」

• 「割り込み、C 割り込み、およびリモート再開」

• 「ルート リストおよびハント パイロット」

• 「CTI 処理」

また、論理パーティションは次の Cisco Unified Communications Manager コンポーネントと通信します。

• 一括管理ツール：一括管理ツール（BAT）による論理パーティションのサポートの詳細については、『 Cisco Unified Communications Manager Bulk Administration ガイド 』を参照してください。

• 呼詳細レコード：論理パーティションで障害が発生した場合、既存のコール終了原因コードおよび新しいシスコ固有のコール終了原因コードが使用されます。CDR の詳細については、『 Cisco Unified Communications Manager Call Detail Records Administration Guide 』を参照してください。

• Real-Time Monitoring Tool：Real-Time Monitoring Toolには Cisco Call Restriction オブジェクト用に一連のパフォーマンス モニタリング（perfmon）カウンタがあり、論理パーティションで障害が発生した場合に増分されます。また、Real-Time Monitoring Toolは [Call Activity] ウィンドウで Logical Partitioning Failures Total カウンタをトラッキングします。Real-Time Monitoring Tool の詳細については、『 Cisco Unified Real Time Monitoring Tool Administration Guide 』を参照してください。

• Cisco Unified Reporting：Cisco Unified Reporting論理パーティション ポリシーに関するレポートを生成します。Cisco Unified Reportingが生成するレポートの詳細については、『 Cisco Unified Reporting Administration Guide 』を参照してください。

追加情報

「関連項目」を参照してください。

自動転送

ここでは、論理パーティションと自動転送機能とのインタラクションについて説明します。

動作

コールの発信側デバイスおよびコールの自動転送先デバイスの位置情報識別子間で、論理パーティション ポリシー チェックが実行されます。

設定

発信側デバイスおよび転送元デバイスには、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• コールを別のデバイスに転送するデバイスの着信コールを受信すると、自動転送機能が呼び出される場合。

• デバイスの 1 つに、PSTN 参加者が指定されている場合。

• Cisco Unified Communications Manager が、着信側および転送元の Cisco Unified Communications Manager デバイスに関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

• 設定済みの論理パーティション ポリシーが転送元 Cisco Unified Communications Manager デバイスに戻され、そのポリシーに従ってアクションが実行される場合。

• この処理は、Call Forward All（CFwdAll; 不在転送）、Call Forward No Answer（CFNA; 無応答時転送）、Call Forward Busy（CFB; 話中転送）など、あらゆる種類の自動転送に適用される。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 発信側と転送元の両方のデバイスが VoIP 電話機（DevType = Interior）である場合。

• 位置情報と位置情報フィルタがどのデバイスにも関連付けられていない場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• 発信側デバイスは、Cisco Unified Communications Manager からリオーダー音を受信します。

– 原因コード = 63 "Service or option not available." を使用して、Q.850 準拠のデバイス（SCCP、H323、または MGCP デバイスが実行されている電話機）がクリアされます。

– SIP ステータス コード = 503 "Service unavailable." を使用して、SIP 回線または SIP トランクがクリアされます。

追加情報

「関連項目」を参照してください。

コール転送

ここでは、論理パーティションとコール転送機能とのインタラクションについて説明します。

動作

転送元として機能するデバイスの位置情報識別子と、転送先として機能するデバイスの位置情報識別子との間で、論理パーティション ポリシー チェックが実行されます。

設定

転送元デバイスおよび転送先デバイスには、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• 電話機が [転送] ソフトキーを使用してコールを転送するとき、[転送] キーをもう一度押すと転送機能が呼び出されて処理される場合。

• 同様に、転送機能の呼び出しを伴う他のメカニズム（たとえば、直接転送、オンフック転送、フック フラッシュ転送、CTI アプリケーション開始転送）が含まれている場合。

• 転送元および転送先、またはそのいずれかが PSTN 参加者である場合。

• Cisco Unified Communications Manager が、転送元および転送先の Cisco Unified Communications Manager デバイスに関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

• この処理は通常、参加に先立ってプライマリ コールおよびセカンダリ コールを分割する前に実行される。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 転送元と転送元の両方のデバイスが VoIP 電話機（DevType = Interior）である場合。

• 位置情報と位置情報フィルタがどのデバイスにも関連付けられていない場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• 「外線転送を制限中」というメッセージを VoIP 電話機に送信します。

• 通常の転送：SCCP が実行されている電話機の場合、プライマリ コールが保留状態となり、打診コールがアクティブなままとなります。SIP が実行されている電話機の場合、プライマリ コールと打診コールの両方が保留状態となり、障害後に手動で再開する必要があります。

• オンフック、フックフラッシュ、およびアナログ電話機開始転送：Cisco Unified Communications Manager からのリオーダー音とともに、原因コード = 63 "Service or option not available." を使用して、プライマリ コールとセカンダリ コールの両方がクリアされます。

• Number of Transfer Failures perfmon カウンタが増分されます。

Block OffNet to OffNet Transfer サービス パラメータとのインタラクション

Block OffNet to OffNet Transfer サービス パラメータを使用すると、転送元と転送先の両方がオフネット コールの場合に、転送機能で転送操作をブロックできます。

このサービス パラメータの詳細については、このガイドの 「External Call Transfer Restrictions 機能」 の章の「Block OffNet to OffNet Transfer サービス パラメータの設定」を参照してください。

論理パーティションが無効になっている Cisco Unified Communications Manager クラスタでは、このサービス パラメータによって指定される所定の動作が保持されます。

論理パーティションが有効なクラスタ

論理パーティションが有効な Cisco Unified Communications Manager クラスタでは、次のようなポリシーを設定して、補足機能の位置情報ポリシー GLPolicyX を使用する複数の音声ゲートウェイ（PSTN）参加者を許可するようにシステムを設定できます。

GLPolicyX Border GLPolicyX Border Allow

このようなポリシーを Cisco Unified Communications Manager で設定すると、（自動転送、任意転送、アドホック会議などの）すべての機能が、位置情報ポリシー GLPolicyX Border を使用する参加者間で有効になります。たとえば、GLPolicyX Border を使用する側からのコールを GLPolicyX Border を使用する相手側に自動転送できます。

Cisco Unified Communications Manager の導入には、これらの参加者に対して転送機能を除くすべての補足機能が機能することが必要であるとします。このような場合は、論理パーティション ポリシーが許可されている場合でも、Block OffNet to OffNet Transfer サービス パラメータによって、オフネット デバイス間の転送をブロックできます。

このサービス パラメータはオフネット間の転送のブロックだけを制御し、その他の補足機能には影響しません。したがって、音声ゲートウェイ間の転送に関係するシナリオについては、次の詳細で詳しく説明します。

詳細

1. ボーダー間論理パーティション ポリシーに拒否を指定

この位置情報ポリシーを使用する通話者間の転送操作の場合は、Cisco Unified Communications Manager によって転送が拒否されます。「外線転送を制限中」というメッセージが転送側に表示されます。

Block OffNet to OffNet Transfer サービス パラメータ用の Cisco Unified Communications Manager の設定（[True] または [False]）は、転送操作には影響を及ぼしません。

論理パーティションの拒否ポリシーが優先され、Cisco Unified Communications Manager は厳密にこのポリシーに従います。

2. ボーダー間論理パーティション ポリシーに許可を指定

この位置情報ポリシーを使用する通話者間の転送操作の場合は、許可ポリシーと Block OffNet to OffNet Transfer サービス パラメータの設定が、Cisco Unified Communications Manager によってチェックされます。したがって、このサービス パラメータは、オフネット参加者間の転送に影響を及ぼします。

a. Block OffNet to OffNet Transfer サービス パラメータに [True] を指定：Cisco Unified Communications Manager は両方の通話者（転送元と転送先）がオフネットかどうかをチェックします。いずれもオフネットである場合、この通話の転送は拒否されます。また、「外線転送を制限中」というメッセージが転送側に表示されます。

サービス パラメータによって転送がブロックされるため、Serviceability の Logical Partitioning Transfer Failures perfmon カウンタは増分されません。

b. Block OffNet to OffNet Transfer サービス パラメータに [False] を指定：転送に成功します。

デバイスのオフネット/オンネット動作

発信コールの場合は、[ルートパターンの設定(Route Pattern Configuration)] ウィンドウの [コールの分類(Call Classification)] 設定によって、オフネットまたはオンネットの値が決定されます。[ルートパターンの設定(Route Pattern Configuration)] ウィンドウの [コールの分類(Call Classification)] の値は、デバイスレベルの設定または Call Classification サービス パラメータの対応する値よりも優先されます。

着信コールの場合は、デバイスレベルの設定または対応する Call Classification サービス パラメータ値によって、オフネットまたはオンネットの値が決定されます。

追加情報

「関連項目」を参照してください。

アドホック会議、参加、回線をまたいで参加（JAL）

ここでは、論理パーティションと、アドホック会議、参加、および JAL 機能とのインタラクションについて説明します。

動作

確立中の会議：アドホック会議に招待されるデバイスの位置情報識別子間で、論理パーティション ポリシーがチェックされます。

確立済みの会議：会議にすでに参加しているデバイスと、会議に招待されるデバイスの位置情報識別子間で、論理パーティション ポリシーがチェックされます。

設定

参加デバイスには、位置情報および位置情報フィルタが関連付けられます。

会議ブリッジには、位置情報も位置情報フィルタも関連付ける必要がありません。参加者だけに関連付けます。ポリシー チェックは参加者に対して実行されます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• 電話機が、[会議] ソフトキーを使用して、アドホック会議または CTI アプリケーション開始アドホック会議を確立または延長する場合。

• [会議] キーをもう一度押すと、会議機能が呼び出されて処理される場合。

• Cisco Unified Communications Manager が、参加者位置識別子情報を使用して、ポリシー チェックを実行する場合。

• 確立済みの会議で、コール中の更新のために変更された参加者位置識別子情報に基づいて、再度ポリシー チェックが実行される場合。たとえば、応答へのアラート、保留/リモート再開、転送、コール パーク取得、リダイレクトなど、コール状態の変更時に、ポリシー チェックが実行されます。

• PSTN が参加している場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• すべての参加者が VoIP 電話機（DevType = Interior）である場合。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないと、そのデバイスに対してポリシー チェックが実行されない場合。

拒否処理

論理パーティションは、次のように会議の拒否を処理します。

• 確立中の会議の場合、CFB は割り当てられません。

• SCCP が実行されている電話機または SIP が実行されている電話機の場合、プライマリ コール レッグが保留になり、打診コールがアクティブなままとなります。プライマリ コール レッグを再開する必要がある場合、再開は手動で行う必要があります。

• 「会議は使用できません」というメッセージが、会議を開始した VoIP 電話機に送信されます。

• アナログ電話機が会議を開始すると、Cisco Unified Communications Manager からのリオーダー音とともに、原因コード = 63 "Service or option not available." を使用して、セカンダリ コールがクリアされます。

• Number of Adhoc Conference Failures perfmon カウンタが増分されます。

追加情報

「関連項目」を参照してください。

ミートミー会議

ここでは、論理パーティションとミートミー会議機能とのインタラクションについて説明します。

動作

ミートミー会議にすでに参加しているデバイスと、その会議に参加しようとしているデバイスの位置情報識別子間で、論理パーティション ポリシーがチェックされます。

設定

参加デバイスには、位置情報および位置情報フィルタが関連付けられます。

会議ブリッジには、位置情報も位置情報フィルタも関連付ける必要がないことに注意してください。参加者だけに関連付けます。ポリシー チェックは参加者に対して実行されます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• PSTN の参加には要件がある場合。

• 会議参加時のポリシー チェックがサポートされる場合。参加者がミートミー番号をダイヤルしてミートミー会議に参加するとき、その新規参加者にミートミー会議への参加を許可する前に、参加者位置情報を使用してポリシー チェックが実行されます。

• 確立済みのミートミー会議で、コール中の更新（保留/再開、転送、割り込み、C 割り込み、コール パーク取得など）時に、参加者の更新済みポリシーを使用してポリシー チェックが実行される場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• すべての参加者が VoIP 電話機（DevType = Interior）であるときに、処理が発生しない場合。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないと、そのデバイスに対してポリシー チェックが実行されない場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• 「ミートミーは使用できません」というメッセージが VoIP 電話機に送信されます。

• 既存の会議は影響を受けません。

• Cisco Unified Communications Manager からのリオーダー音とともにコールがクリアされます。

– 原因コード = 63 "Service or option not available." を使用して、Q.850 準拠のデバイス（SCCP、H323、または MGCP デバイスが実行されている電話機）がクリアされます。

– SIP ステータス コード = 503 "Service unavailable." を使用して、SIP 回線または SIP トランクがクリアされます。

• Number of Meet-Me Conference Failures perfmon カウンタが増分されます。

追加情報

「関連項目」を参照してください。

コール ピックアップ

ここでは、論理パーティションとコール ピックアップ機能とのインタラクションについて説明します。

動作

発信側デバイスの位置情報識別子と、コールをピックアップするデバイスの位置情報識別子との間で、論理パーティション ポリシーがチェックされます。

設定

ピックアップを試みる発信側デバイスおよび着信側デバイスのいずれにも、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• PSTN デバイスが VoIP 電話機（A）をコールし、別の VoIP 電話機（B）にその電話機に対するピックアップ グループ関係がある場合（いずれの電話機も、同じピックアップ グループに属しているなど）。

• 電話機 B が [ピック]、[他Grp]、[グループ ピックアップ]、[BLF ピックアップ] のいずれかのボタンを押してピックアップを試みると、ピックアップ機能が呼び出される場合。

• Cisco Unified Communications Manager が発信側デバイスの位置識別子情報とコールをピックアップするデバイスの位置識別子情報を使用して、ポリシー チェックを実行する場合。

• アラート コールが 1 つだけ発生すると、対応する論理パーティション ポリシーが最後のポリシーとして処理される場合。

• 複数のアラート コールが発生すると、アラート コールごとに論理パーティション ポリシーがチェックされる場合。チェックは最も長いアラート コールから始まり、論理パーティション ポリシーが許可されてコールがピックアップされるまで続きます。最後に処理されたアラート コールに論理パーティション拒否ポリシーがあり、これ以上アラート コールが発生しない場合は、拒否処理アクションが実行されます。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 発信者が VoIP 電話機（DevType = Interior）で構成されているときに、処理が発生しない場合。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないときに、ポリシー チェックが実行されない場合。

拒否処理

論理パーティションは、次のようにピックアップの拒否を処理します。

• 「ピックアップは使用できません」というメッセージが、ピックアップを試みた VoIP 電話機に送信されます。

• アラート コールは影響を受けません。

• アラート コールが複数存在する場合（許可ポリシーと拒否ポリシーが混在する場合）、拒否ポリシーがあるコールが最初のピックアップに失敗すると、Cisco Unified Communications Manager は次のアラート コールをピックアップして処理を続行します。

• Cisco Unified Communications Manager は、ピックアップを試みた電話機にリオーダー音を送信します。

– 原因コード = 63 "Service or option not available." を使用して、Q.850 準拠のデバイス（SCCP が実行されている電話機）がクリアされます。

– SIP ステータス コード = 503 "Service unavailable." を使用して、SIP 電話機がクリアされます。

• Number of Pickup Failures perfmon カウンタが増分されます。

追加情報

「関連項目」を参照してください。

コール パークとダイレクト コール パーク

ここでは、論理パーティションと、コール パーク機能およびダイレクト コール パーク機能とのインタラクションについて説明します。

動作

コールを取得する側のデバイスの位置情報識別子と、パークされる側の位置情報識別子との間で、論理パーティション ポリシーがチェックされます。

設定

取得の場合：パークされる側およびパーク取得を試みる側のデバイスには、位置情報および位置情報フィルタが関連付けられます。

復帰の場合：パークされる側および復帰が発生する側のデバイスには、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• パークされたコールが存在し、デバイスがパーク取得を試みると、パーク取得機能が呼び出される場合。

• パークされたコールが存在し、復帰タイマーの期限が切れると、パーク復帰機能が呼び出される場合。

• 参加者の 1 つが PSTN である必要がある場合。

• パーク取得では、Cisco Unified Communications Manager がパークされる側のデバイスの位置識別子情報と、パーク取得を実行する側のデバイスの位置識別子情報を使用して、ポリシー チェックを実行する場合。

• パーク復帰では、Cisco Unified Communications Manager がパークされる側のデバイスの位置識別子情報と、コールがリダイレクトされる側のデバイスの位置識別子情報を使用して、ポリシー チェックを実行する場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 参加しているデバイスが VoIP 電話機（DevType = Interior）であるときに、処理が発生しない場合。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないときに、ポリシー チェックが実行されない場合。

拒否処理

論理パーティションは、次のように取得/復帰の拒否を処理します。

• 取得の場合、「パークされているコールを取得できません」というメッセージが VoIP 電話機に送信されます。

• Cisco Unified Communications Manager は、取得を試みている電話機にリオーダー音を送信します。

– 原因コード = 63 "Service or option not available." を使用して、Q.850 準拠のデバイス（SCCP、H323、または MGCP デバイスが実行されている電話機）がクリアされます。

– SIP ステータス コード = 503 "Service unavailable." を使用して、SIP が実行されている電話機または SIP トランクがクリアされます。

• 復帰の場合、リオーダー音とともに、パークされたコールがクリアされます。

• Number of Park Retrieval Failures perfmon カウンタが増分されます（コール パークとダイレクト コール パークのいずれの取得も拒否される場合）。

追加情報

「関連項目」を参照してください。

Cisco エクステンション モビリティ

ここでは、論理パーティションと Cisco エクステンション モビリティ機能とのインタラクションについて説明します。

動作

ユーザは、同じ Cisco Unified Communications Manager クラスタ内で Cisco エクステンション モビリティを使用して、VoIP 電話機にログインします。電話機からの着信コールまたは発信コールに対して、論理パーティション ポリシーがチェックされます。

設定

Cisco エクステンション モビリティにログインする VoIP 電話機および PSTN アクセス デバイスのいずれにも、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• ユーザが、Cisco エクステンション モビリティを使用してデバイス プロファイルとは異なる位置情報のデバイスにログインし、ユーザ ホーム サイトのゲートウェイを使用して PSTN コールを発信するか、または着信 PSTN コールを取得する場合。

• Cisco Unified Communications Manager が、Cisco エクステンション モビリティにログインしたデバイスと PSTN ゲートウェイ デバイスの位置識別子情報を使用してポリシー チェックを実行する場合。

• 設定済みの論理パーティション ポリシーが発信 Cisco Unified Communications Manager デバイス層に戻され、そのポリシーに従ってアクションが実行される場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 位置情報または位置情報フィルタが、Cisco エクステンション モビリティにログインする VoIP 電話機にも、発信側と着信側のデバイスにも関連付けられない場合。

• Cisco エクステンション モビリティにログインする VoIP 電話機がコールするか、または VoIP 電話機（DevType = Interior）からのコールを取得する場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• Cisco エクステンション モビリティにログインしている VoIP 電話機が、論理パーティション単位で拒否する必要がある PSTN コールを発信した場合、そのコールはリオーダー音とともに拒否されます。

• Cisco エクステンション モビリティにログインしている VoIP 電話機が、論理パーティション単位で拒否する必要がある PSTN コールを取得した場合、そのコールはリオーダー音とともに拒否されます。

追加情報

「関連項目」を参照してください。

Cisco Unified Mobility

ここでは、論理パーティションと Cisco Unified Mobility機能とのインタラクションについて説明します。これらのインタラクションは、モバイル コネクトまたはモバイル ボイス アクセスを必要とするコールに適用されます。

動作

論理パーティションは、次のように Cisco Unified Mobility と通信します。

• Single-Number-Reach（SNR; シングル ナンバー リーチ）コール：発信側デバイスと、そのモバイル デバイスに接続する PSTN ゲートウェイとの間で、SNR コールに対して論理パーティション ポリシーがチェックされます。

• セル ピックアップ：固定電話からのセル ピックアップ操作は、リモート宛先のモバイル デバイスを接続している PSTN ゲートウェイに、接続済みのコールを参加させようとします。コールに参加する前に、参加するデバイスの位置情報識別子を使用して、論理パーティション ポリシーがチェックされます。

• モバイル ボイス アクセス：着信ゲートウェイの位置情報識別子と着信側デバイスの位置情報識別子との間で、論理パーティション ポリシーがチェックされます。

設定

参加するデバイスおよび PSTN アクセス ゲートウェイには、位置情報および位置情報フィルタが関連付けられる必要があります。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• シングル ナンバー リーチ（SNR）コール

Cisco Unified Mobility がエンタープライズ拡張用に設定され、VoIP 電話機または別の PSTN ゲートウェイから SNR に対するコールが取得される場合。

Cisco Unified Communications Manager が、着信側および発信側の Cisco Unified Communications Manager デバイスに関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

設定済みの論理パーティション ポリシーが着信側 Cisco Unified Communications Manager デバイス層に戻され、そのポリシーに従ってアクションが実行される場合。

• セル ピックアップ

Cisco Unified Mobility がエンタープライズ拡張用に設定され、VoIP 電話機（SNR）と別の VoIP 電話機または PSTN ゲートウェイ（接続される側）との間でコールがアクティブである場合。

VoIP 電話機（SNR）が、モバイルへのセル ピックアップを実行して、携帯電話への到達に使用される PSTN ゲートウェイに、接続される側を参加させようとしている場合。

Cisco Unified Communications Manager が、PSTN ゲートウェイおよび接続される側に関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

設定済みの論理パーティション ポリシーによって、セル ピックアップの操作が成功するか失敗するかが決定される場合。

• モバイル ボイス アクセス

Cisco Unified Mobility がエンタープライズ拡張用に設定され、携帯電話が PSTN ゲートウェイからエンタープライズ VoIP 電話機にコールする場合。

Cisco Unified Communications Manager が、発信側 PSTN ゲートウェイおよび着信側 VoIP 電話機に関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

設定済みの論理パーティション ポリシーが着信側 Cisco Unified Communications Manager デバイス層に戻され、そのポリシーに従ってアクションが実行される場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 位置情報または位置情報フィルタが、参加するデバイスに関連付けられていない場合。

• デュアル モード フォンが使用されるときには、論理パーティションがサポートされない場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• SNR および モバイル ボイス アクセスの場合、リオーダー音とともにコールがクリアまたは拒否されます。

• セル ピックアップの場合、接続される側と VoIP 電話機（SNR）間の元のコールが復元され、「携帯電話へコールを送信できません」というメッセージが VoIP 電話機に表示されます。

追加情報

「関連項目」を参照してください。

シェアドライン

ここでは、論理パーティションとシェアドライン機能とのインタラクションについて説明します。

動作

シェアドラインへのコールまたはシェアドラインからのコールでは、論理パーティション チェックに基本コールと同じ処理が使用されます。

Cisco Unified Communications Manager 上のシェアドライン デバイスは、Remote-In-Use（RIU; リモートで使用中）情報を表示するために、論理パーティション ポリシー チェックを実行します。接続される側の位置情報識別子と、RIU 情報を表示するシェアドライン デバイスとの間で、ポリシーがチェックされます。

設定

シェアドライン デバイスおよび PSTN アクセス デバイス（VoIP ゲートウェイ）には、位置情報および位置情報フィルタが関連付けられます。

処理される状況

基本コールで次の状況が発生した場合、論理パーティションの処理が行われます。

• 異なる位置情報をまたぐ VoIP 電話機のシェアドラインが存在し、いずれかの VoIP 電話機がローカル PSTN ゲートウェイを介して PSTN コールを発信または取得する場合。

• シェアドラインから PSTN ゲートウェイへのコールを完了するために、Cisco Unified Communications Manager が発信側シェアドライン電話機および着信側 PSTN ゲートウェイに関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

• PSTN ゲートウェイからシェアドラインへのコールを完了するために、Cisco Unified Communications Manager が発信側 PSTN ゲートウェイおよび各着信側シェアドライン電話機に関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

• 設定済みの論理パーティション ポリシーが着信側 Cisco Unified Communications Manager デバイス層に戻され、そのポリシーに従ってアクションが実行される場合。

• リモートで使用中（RIU）情報を表示するかどうかを決定するために、Cisco Unified Communications Manager がシェアドラインに関連付けられている各デバイスの位置識別子情報と、接続される側（発信側または着信側）の位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 発信側と着信側の両方のデバイスが VoIP 電話機（DevType = Interior）であるときに、処理が発生しない場合。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないときに、処理が発生しない場合。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• Cisco Unified Communications Manager は、発信側デバイスで許可されていない位置情報にある着信側シェアドライン デバイスへのコールをドロップします（またはコールを延長しません）。

• リモートで使用中状態のシェアドライン デバイスには、コール インスタンス情報が表示されません。

追加情報

「関連項目」を参照してください。

割り込み、C 割り込み、およびリモート再開

ここでは、論理パーティションと、割り込み、C 割り込み、およびリモート再開機能とのインタラクションについて説明します。

動作

シェアドラインでの割り込み、C 割り込み、またはリモート再開操作は、リモートで使用中（RIU）状態でコール インスタンス情報が入手できるかどうかに依存します。

シェアドライン インタラクションに適用される同じ論理パーティション ポリシー チェックによって、RIU 情報が入手できるかどうかが決定されます。

論理パーティション拒否の場合、制限されているシェアドラインでは RIU コール インスタンスが取り消されます。

設定

シェアドライン デバイスおよび PSTN アクセス デバイスには、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• 異なる位置情報をまたぐ VoIP 電話機のシェアドラインが存在し、いずれかの VoIP 電話機がローカル PSTN ゲートウェイを介して PSTN コールを発信または取得する場合。

• リモートで使用中（RIU）情報の表示がシェアドライン コール シナリオの場合と同じように処理される場合。

• アクティブ コールがシェアドライン デバイスによって保留されている間、リモートの [解除] ボタンが使用できない場合。

• [割り込み] ボタンおよび [C割込] ボタンが使用できないため、これらのシナリオが実行できない場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 発信側と着信側の両方のデバイスが VoIP 電話機（DevType = Interior）であるときに、論理パーティション ポリシー チェックが無視される場合。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないときに、処理が発生しない場合。

• 会議やミートミーなどのアクティブな機能のために、接続される側が会議ブリッジとなり、会議に参加するすべてのデバイスに許可される位置情報がアクティブなシェアドライン デバイスに関連付けられるときに、リモートで使用中のシェアドライン デバイスにコール インスタンス情報が表示される場合。この場合、リモートで使用中の電話機では、許可されない参加者が会議に参加している場合も含め、常に C 割り込み/割り込み機能を実行できます。C 割り込み/割り込みの参加者の場合、論理パーティション ポリシー チェックが存在せず、論理パーティション拒否シナリオを防止できません。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• コール インスタンス情報は表示されません。

追加情報

「関連項目」を参照してください。

ルート リストおよびハント パイロット

ここでは、論理パーティションと、ルート リストおよびハント パイロットとのインタラクションについて説明します。

動作

ルート リストの場合、デバイスから、ルート リストおよびルート グループに属しているゲートウェイまたは MGCP ポートへのコールが、参加する発信側デバイスおよび着信側デバイスの位置情報識別子に基づいて、論理パーティション ポリシーに照らしてチェックされます。

ハント パイロットの場合、PSTN デバイスから、ハント リストまたはハント グループに属している回線デバイスへのコールが、参加する発信側デバイスおよび着信側デバイスの位置情報識別子に基づいて、論理パーティション ポリシーに照らしてチェックされます。

設定

発信側デバイスおよび着信側デバイスには、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• VoIP 電話機または PSTN ゲートウェイからルート リストを経由して PSTN ゲートウェイに至る基本コールが実行される場合。

• PSTN ゲートウェイからハント リストを経由して一連の VoIP 電話機に至る基本コールが実行される場合。

• Cisco Unified Communications Manager が、着信側および発信側の Cisco Unified Communications Manager デバイスに関連付けられている位置識別子情報を使用して、論理パーティション ポリシー チェックを実行する場合。

• 設定済みの論理パーティション ポリシーが発信 Cisco Unified Communications Manager デバイス層に戻され、そのポリシーに従ってアクションが実行される場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 発信側と着信側の両方のデバイスが VoIP 電話機（DevType = Interior）であるときに、処理が発生しない場合。

• すべてのデバイスに位置情報と位置情報フィルタの両方を関連付ける必要がある場合。デバイスに位置情報も位置情報フィルタも関連付けられていない場合、処理は発生しません。

拒否処理

論理パーティションは、次のようにコールの拒否を処理します。

• Cisco Unified Communications Manager からのリオーダー音とともにコールがクリアまたは拒否されます。

追加情報

「関連項目」を参照してください。

CTI 処理

ここでは、論理パーティションと、参加またはリダイレクトを実行するすべての機能との CTI インタラクションについて説明します。

動作

PSTN ゲートウェイへのコール、参加、またはリダイレクトを伴うすべての操作に対して、論理パーティション ポリシーがチェックされ、次の状況で論理パーティションに障害が発生した場合は CTI エラーが生成されます。

• 基本コール

• 転送

• 会議

• パーク取得および類似した機能

設定

参加するデバイスには、位置情報および位置情報フィルタが関連付けられます。

処理される状況

次の状況では、論理パーティションの処理が行われます。

• デバイスの 1 つに、PSTN 参加者が指定されている場合。

• 操作のコンテキストで論理パーティション ポリシーがチェックされる場合。

処理されない状況

次の状況では、論理パーティションの処理は行われません。

• 位置情報または位置情報フィルタがデバイスに関連付けられていないときに、処理が発生しない場合。

• 参加しているすべてのデバイスが VoIP 電話機（DevType = Interior）であるときに、処理が発生しない場合。

拒否処理

論理パーティションは、次のように操作ベースの CTI 原因コードを生成して、コールの拒否を処理します。

• 基本コール：CTICCMSIP503SERVICENOTAVAILABL

• リダイレクト：CTIERR_REDIRECT_CALL_PARTITIONING_POLICY

• 参加、転送、会議、およびその他：CTIERR_FEATURE_NOT_AVAILABLE

追加情報

「関連項目」を参照してください。

制限

論理パーティションには、次の制限事項があります。

• UPDATE での SIP トランク User Agent Server（UAS; ユーザ エージェント サーバ）ロケーション伝達

UAS は、UPDATE 要求を使用して、着信側の位置情報を User Agent Client（UAC; ユーザ エージェント クライアント）に通知します。これは通常、180 Ringing の後に発生します。

この位置情報を受信する論理パーティション対応クラスタで実行される論理パーティション ポリシー チェックでは、ポリシーが拒否されると、コールがキャンセルされることがあります。使いやすいエンド ユーザ エクスペリエンスが実現されない可能性があります。

• 会議チェーンで会議をまたぐ参加者に対しては、論理パーティション チェックがサポートされません。

たとえば、ミートミーおよびアドホックの会議チェーンには、論理パーティション拒否の参加者が参加できます。

• QSIG クラスタ間トランク（ICT）に関する制限

Q.SIG プロトコルが設定された ICT では、発信側デバイスまたは着信側デバイスの位置情報を通知できないことに注意してください。Q.SIG トンネル化プロトコルが選択されたときには、[位置情報の送信(Send Geolocation Information)] の ICT 設定が無効になります。

• シェアドライン アクティブ コール情報

論理パーティションが制限されるシナリオでは、ある機能によってシェアドライン コールが許可カテゴリに移動される場合でも、シェアドラインはコール期間中にアクティブ コール情報をドロップします。

• C 割り込み/割り込み

割り込み/C 割り込みは発生しません。接続される側の論理パーティション拒否ポリシーに基づいて、シェアドラインではこれらの機能を試行できないようにしているためです（コール インスタンスはドロップされます）。

ただし、会議やミートミーなどのアクティブな機能のために、接続される側が会議ブリッジとなり、会議に参加するすべてのデバイスに許可される位置情報がアクティブなシェアドライン デバイスに関連付けられるときは、リモートで使用中のシェアドライン デバイスにコール インスタンス情報が表示されます。この場合、リモートで使用中の電話機では、許可されない参加者が会議に参加している場合も含め、常に C 割り込み/割り込み機能を実行できます。C 割り込み/割り込みの参加者の場合、論理パーティション ポリシー チェックが存在せず、論理パーティション拒否シナリオを防止できません。

• Cisco Unified Communications Manager は、位置情報を H.323 ゲートウェイまたは MGCP ゲートウェイに通知しません。

SIP トランクのチェックボックスに基づいて、SIP ゲートウェイへの通知を無効にすることができます。

• Cisco Unified Communications Manager は、H.225 ゲートキーパー制御によるトランクでは位置情報を通知しません。

シナリオ：Cisco Unified Communications Manager 1 は論理パーティションが有効なままですが、Cisco Unified Communications Manager 2 は論理パーティションが無効なままとなります。

CCM1 の電話機 A が、（ICT トランクまたは SIP トランクを使用して）CCM2 の電話機 B をコールします。

電話機 B が会議を要請し、PSTN を会議に招待します。

制限：会議が確立されます。

電話機 B がオンフックになると、電話機 A と Cisco Unified Communications Manager 2 の PSTN 間のコールがリオーダー音とともにクリアされます。

• モビリティ セル ピックアップ：携帯電話でコールに応答すると、論理パーティション拒否処理が実行されます。

コールが携帯電話に発信される前に、論理パーティション ポリシー チェックは発生しません（基本 SNR コールの場合には発生します）。現在の仕様により、論理パーティション ポリシーがチェックされるのは、携帯電話がコールに応答すると実行される SsJoinReq 処理の後だけです。

• Cisco エクステンション モビリティ は、位置情報が異なる電話機にログインします。

ローカルルート グループの設定時に、発信 PSTN コールが発生することがあります。

着信 PSTN コールは電話機に対して発信されませんが、リオーダー音を受信します。

• 論理パーティション ポリシーでは、BLF SD または BLF ピックアップ プレゼンス通知はチェックされません。

現在、通知用には論理パーティション インフラストラクチャが追加されません。

自動転送で障害が発生しても、RTMT Number of Forwarding Failures perfmon カウンタは増分されません。その代わり、Number of Basic Call Failures perfmon カウンタが増分されます。

• IOS H.323 ゲートウェイおよび SIP ゲートウェイでは、コールの接続がリリースされても、補足機能実行時の論理パーティション ポリシーにより、リオーダー音が発生しません。

例

IOS SIP ゲートウェイまたは H.323 ゲートウェイの背後にある Remote Destination（RD; リモート接続先）の電話機が、VoIP 電話機 A をコールします。

認証の完了後、RD 電話機が電話機 C にコールを発信しますが、論理パーティション制限ポリシーにより、コールが拒否されます。

原因コード = 63 "Service or option not available." で RD 電話機へのコールがクリアされますが、その RD 電話機へのリオーダー音は再生されません。

（注） この原因コードは、すべての論理パーティション障害に共通のコードです。

この動作は、CONNECT 状態後はリオーダー音を再生しないという IOS ゲートウェイ側の仕様制限により発生します。CONNECT 状態後に再生される唯一の音は、17（話し中）または 44（使用可能な回線なし）です。

同じような制限が、フックフラッシュやオンフック転送などの補足機能に適用されます。

• 論理パーティションで障害が発生した場合にコールをボイスメールに自動転送するための設定は存在しません。

• 論理パーティション拒否で障害が発生しても、アナウンスは発生しません。

• Cisco Unified Communications Manager は、Cisco Unified MeetingPlace または Cisco Unified MeetingPlace Express に関連するコールの論理パーティション機能をサポートしていません。

追加情報

「関連項目」を参照してください。

位置情報の設定

位置情報を設定するには、Cisco Unified Communications Manager の管理ページの [システム(System)] > [位置情報の設定(Geolocation Configuration)] メニュー オプションを使用します。

位置情報の設定の詳細については、「位置情報の設定」を参照してください。

追加情報

「関連項目」を参照してください。

位置情報フィルタの設定

位置情報フィルタを設定するには、Cisco Unified Communications Manager の管理ページの [システム(System)] > [位置情報フィルタ(Geolocation Filter)] メニュー オプションを使用します。

位置情報フィルタの設定の詳細については、「位置情報フィルタの設定」を参照してください。

追加情報

「関連項目」を参照してください。

論理パーティションポリシーの設定

論理パーティション ポリシーを設定するには、Cisco Unified Communications Manager の管理ページの [コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] メニュー オプションを使用します。

論理パーティション ポリシーの設定については、次の項を参照してください。

• 「論理パーティション ポリシーの検索」

• 「論理パーティション ポリシーの設定」

• 「論理パーティション ポリシー レコードの削除」

• 「論理パーティション ポリシー ペア設定の削除」

• 「論理パーティション ポリシー ペア設定の更新」

• 「[論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] の設定」

追加情報

「関連項目」を参照してください。

論理パーティション ポリシーの検索

ネットワークに複数の論理パーティション ポリシーが存在することがあるため、Cisco Unified Communications Manager では指定した条件に基づいて論理パーティション ポリシーを検索できます。Cisco Unified Communications Manager データベースで特定の論理パーティション ポリシーを検索するには、次の手順に従います。

（注） ブラウザ セッションでの作業中は、Cisco Unified Communications Manager の管理ページで論理パーティション ポリシーの検索プリファレンスが保持されます。他のメニュー項目に移動してこのメニュー項目に戻った場合でも、検索を変更するかブラウザを閉じない限り、論理パーティション ポリシーの検索プリファレンスは Cisco Unified Communications Manager の管理ページで保持されています。

手順

ステップ 1 [コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] を選択します。

[ポリシーの検索と一覧表示(Find and List Policies)] ウィンドウが表示されます。ウィンドウには、アクティブな（前の）クエリーのレコードが表示される場合もあります。

ステップ 2 データベース内のすべてのレコードを検索するには、ダイアログボックスが空になっていることを確認し、ステップ 3 に進みます。

特定のレコードをフィルタリングまたは検索するには、次の操作を実行します。

• 最初のドロップダウン リスト ボックスで、検索パラメータを選択します。

• 2 番目のドロップダウン リスト ボックスで、検索パターンを選択します。

• 必要に応じて、適切な検索文字を入力します。

（注） 別の検索条件を追加するには、[+] ボタンをクリックします。条件を追加した場合は、指定したすべての条件に一致するレコードが検索されます。条件を削除するには、[-] ボタンをクリックして、最後に追加された条件を削除するか、または [フィルタのクリア(Clear Filter)] ボタンをクリックして、追加されたすべての検索条件を削除します。

ステップ 3 [検索(Find)] をクリックします。

条件に一致するレコードがすべて表示されます。[ページあたりの行数(Rows per Page)] ドロップダウン リスト ボックスで別の値を選択すると、表示される項目数を変更できます。

（注） 適切なレコードの横にあるチェックボックスをオンにして、[選択項目の削除(Delete Selected)] をクリックすると、データベースから複数のレコードを削除できます。[すべてを選択(Select All)] をクリックして [選択項目の削除(Delete Selected)] をクリックすると、この選択対象として設定可能なすべてのレコードを削除できます。

ステップ 4 表示されたレコード リストから、目的のレコードのリンクをクリックします。

（注） ソート順を逆にするには、リストのヘッダーにある上矢印または下矢印をクリックします（使用可能な場合）。

選択した項目がウィンドウに表示されます。

追加情報

「関連項目」を参照してください。

論理パーティション ポリシーの設定

論理パーティション ポリシーを追加または更新するには、次の手順を実行します。

手順

ステップ 1 [コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] を選択します。

[ポリシーの検索と一覧表示(Find and List Policies)] ウィンドウが表示されます。

ステップ 2 次のいずれかの手順を実行します。

• 新しい論理パーティション ポリシーを追加するには、[新規追加(Add New)] をクリックします。

[論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] ウィンドウが表示されます。

• 論理パーティション ポリシーを更新するには、「論理パーティション ポリシーの検索」の説明に従って特定の論理パーティション ポリシーを検索します。

ステップ 3 適切な設定値を入力します（ 表 32-4 を参照）。

ステップ 4 [保存(Save)] をクリックします。

論理パーティション ポリシーを追加した場合は、ウィンドウの一番下にあるリスト ボックスに新しい論理パーティション ポリシーが含まれています。

追加情報

「関連項目」を参照してください。

論理パーティション ポリシー レコードの削除

既存の論理パーティション ポリシー レコードを削除するには、次の手順を実行します。

手順

ステップ 1 [コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] を選択します。

[ポリシーの検索と一覧表示(Find and List Policies)] ウィンドウが表示されます。

ステップ 2 特定の論理パーティション ポリシーを検索するには、検索条件を入力し、[検索(Find)] をクリックします。

検索条件に一致した位置情報フィルタ論理パーティション ポリシーが表示されます。

ステップ 3 次のいずれかの操作を実行します。

• 削除する論理パーティション ポリシーの横のチェックボックスをオンにし、[選択項目の削除(Delete Selected)] をクリックします。

• [すべてを選択(Select All)] をクリックし、[選択項目の削除(Delete Selected)] をクリックして、ウィンドウ内のすべての論理パーティション ポリシーを削除します。

• 削除する論理パーティション ポリシー名をリストから選択し、[削除(Delete)] をクリックします。

確認のダイアログボックスが表示されます。

ステップ 4 [OK] をクリックします。

このレコードに指定した論理パーティション ポリシーおよびすべてのペア ポリシーが削除されます。

追加情報

「関連項目」を参照してください。

論理パーティション ポリシー ペア設定の削除

この場合、論理パーティション ポリシー レコードを選択し、そのレコードの設定ウィンドウを表示します。

ポリシーは現在ペアで設定されています。例を示します。

GLP-1 Border GLP-2 Interior Allow

GLP-1 Border GLP-3 Interior Allow

2 つ目のポリシーを削除する必要がある場合は、2 つ目のポリシーを選択し、[デフォルトポリシーの使用(Use Default Policy)] 設定を選択します。

保存すると、ポリシーの対応するペアがポリシーのマトリクスから削除されます。

GLP-1 レコードには変更が加えられないことに注意してください。

追加情報

「関連項目」を参照してください。

論理パーティション ポリシー ペア設定の更新

この場合、論理パーティション ポリシー レコードを選択し、そのレコードの設定ウィンドウを表示します。

ポリシーは現在ペアで設定されています。例を示します。

GLP-1 Border GLP-2 Interior Allow

GLP-1 Border GLP-3 Interior Allow

2 つ目のポリシーを更新する必要がある場合は、2 つ目のポリシーを選択し、[ポリシー(Policy)] 設定で [許可(Allow)] または [拒否(Deny)] を指定します。

保存すると、ポリシーの対応するペアがポリシーのマトリクスから更新されます。

追加情報

「関連項目」を参照してください。

[論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] の設定

次のエンティティ間に必須の相互接続動作には、論理パーティション ポリシーを設定します。

• PSTN ゲートウェイと VoIP 電話機

• PSTN ゲートウェイと PSTN ゲートウェイ

• クラスタ間トランク（ICT）と VoIP 電話機

• ICT と VoIP ゲートウェイ

System Default Policy エンタープライズ パラメータ（デフォルト値 = DENY）は、設定済みのポリシーが見つからない場合のデフォルトのポリシーです。

[論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] ウィンドウ（Cisco Unified Communications Manager の管理ページの [コールルーティング(Call Routing)] > [論理パーティションポリシーの設定(Logical Partitioning Policy Configuration)] メニュー オプション）で、管理者は位置情報に設定されているフィールドのサブセットから位置情報ポリシー レコードを作成する必要があります。

論理パーティション ポリシーは、位置情報ポリシー レコードとデバイス タイプのペア間に設定します。

許可ポリシーと拒否ポリシーを設定します。設定の詳細については、「許可ポリシーおよび拒否ポリシー」を参照してください。

例を含め論理パーティション ポリシーの詳細については、「論理パーティション ポリシー」を参照してください。

表 32-4 に、論理パーティション ポリシーの設定に使用する設定項目を示します。

追加情報

「関連項目」を参照してください。