論理パーティション分割と地理位置情報の設定とトラブルシューティング

ダウンロードオプション

PDF (1.6 MB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (1.5 MB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (1.3 MB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2021 年 7 月 19 日

Document ID:211280

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

前提条件

使用するコンポーネント

背景説明

論理パーティションの要素

地理位置情報

地理位置情報フィルタ

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

コンフィギュレーション

トラブルシュート

考慮するべきポイント

参考資料

既知のバグ

概要

このドキュメントでは、Cisco Unified Communications Manager（CUCM）で論理パーティションと地理位置情報を設定する方法について説明します。

前提条件

次の項目に関する知識があることが推奨されます。

Cisco Unified Communication Manager

使用するコンポーネント

Cisco Unified Communications Manager 8.6 以降

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

論理パーティション機能により、通話中の機能が起動しているときでも公衆電話交換網（PSTN）ゲートウェイを通過するコールが他の地理的位置（地理位置情報）の Voice over IP（VoIP）フォンや VoIP PSTN ゲートウェイと直接接続しない限り、両方のタイプのコールをサポートするのに単一のシステムを使用できます。

インドなど一部の国では、企業レベルで満たす必要がある通信の規制があります。このため、企業が音声インフラストラクチャを設定する必要があります。これらは、企業外のコールを接続する際にローカル PSTN のみが使用されるように設定されています。インド電気通信規制庁（TRAI）によると、インド国内の PSTN テレフォニーネットワークはトールバイパス目的で VoIP テレフォニーネットワークと接続することはできません。

このため、音声システムが 2 つのシステムに論理的に分割される必要があります。1 つの VoIP は企業内用、2 つ目はローカル PSTN にアクセスするためのものです。

コーリングサーチスペース（CSS）やパーティション機能を備えたこのような音声システムを CUCM で維持するのは非常に困難でした。CSS やパーティションで基本的なコールを制限できますが、リダイレクトや参加などの通話中機能では失敗します。

論理パーティションの要素

地理位置情報

CUCMでは、電話機、ゲートウェイ、トランクなどのデバイスに割り当てるために、IDのプロビジョニングが必要です。位置情報は、論理パーティションの識別子として使用できる標準です。

地理位置情報は、最大 17 の次のパラメータに基づいて物理的な場所を指定するのに使用されます。2 文字の国名コード、州（A1）、郡（A2）、都市（A3）、区（A4）、地域（A5）、番地（A6）、方角（PRD）、町名番地のサフィックス（POD）、住居番号（HNO）、住居番号のサフィックス（HNS）などがあります。

地理位置情報フィルタ

一般的な論理パーティションのポリシー設定には地理位置情報ポリシーレコード内のフィールドのサブセットのみが使用されます。この選択は地理位置情報のフィルタで絞り込まれます。地理位置情報フィルタで選択したフィールドは論理パーティション機能で使用されます。

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

CUCM では、論理パーティションは論理パーティションポリシーと連携してこれらの VoIP エンティティ間の通信を制限するのに使用できるコール制御機能として定義されています。

IP Phone とゲートウェイ間
ゲートウェイ間
IP Phone とトランク（ICT/SIP トランク）間
ゲートウェイとトランク（ICT/SIP トランク）間

論理パーティションのデバイスは内部および境界として分類されます。以下は内部として分類されるデバイスです。

電話機（SCCP、SIP、サードパーティ）
VG224 アナログ電話
MGCP ポート（FXS）
Cisco Unity ボイスメール（SCCP）
CTI ルートポイント、CTI ポート
QSIG ゲートウェイまたは ICT

以下は境界として分類されるデバイスです。

ゲートウェイ
クラスタ間トランク（ICT）
H.225 トランク
SIP トランク
MGCP ポート（E1、T1、PRI、BRI、FXO）

コンフィギュレーション

ステップ 1：デフォルトの地理位置情報は地理位置情報の設定がなく、論理パーティションに参加していないデバイスに適用されます。デフォルトの地理位置情報ポリシーの設定は大きな役割を持っています。許可するように設定されている場合、論理パーティションポリシーに拒否機能を充てる必要があり、逆も同様です。

ステップ 2：[System] > [Geolocation Configuration] に移動し、場所に関する情報を追加します。これは、この特定の地理位置情報に関連するデバイスの識別子として機能します。

ステップ 3：[System] > [Geolocation Filter] に移動し、[Geolocation Filter Configuration] のフィールドで論理ポリシーのフィルタ基準として使用する必要のある項目を確認します。

ステップ 4：論理パーティションポリシーを設定します。コールの許可や拒否のすべての判断はこの設定に基づいているため、これは設定の中で最も重要な部分です。

ステップ 5：電話機のデバイス設定ページに移動し、電話機がどこにあるかに応じて地理位置情報を適用します。

同様にデバイスプールに移動し、地理位置情報の設定を追加します。

ステップ6：次に、PSTNへのインターフェイスとして機能するゲートウェイ/トランク/MGCPポートの設定ページに移動し、位置情報の設定と位置情報フィルタを適用します。

トラブルシュート

ステップ 1：[Enable Logical Partitioning] のオプションが [True] に設定されているエンタープライズパラメータを確認します。

ステップ 2：デバイスが、デバイスまたはデバイスプールレベルで有効な地理位置情報に関連付けられていることを確認します。

ステップ3：設定ページで、デバイスが有効な位置情報フィルタに関連付けられていることを確認します。デバイスまたはデバイスプールレベルで、位置情報フィールドの一部を選択できます。

ステップ 4：LP 地理位置情報ポリシーレコードのフィールドの大文字と小文字の区別が正しく、地理位置情報レコードの設定と一致することを確認します。

ステップ5：位置情報の設定、フィルタ、およびポリシーは、次のSQLコマンドを使用してCLIから確認することもできます。

run sql select * from geolocationfilter
run sql select * from geolocationpolicy
run sql select * from geolocationpolicymatrix
run sql select * from typelogicalpartitionpolicy

ステップ6：基本設定を確認した後、位置情報ポリシー間の関係セットを確認します。エンタープライズパラメータの [Logical Partitioning Default Policy] が [Deny] に設定されている場合、ゲートウェイと VoIP サイトの地理位置情報ポリシー間の論理パーティションポリシーの [Allow] が設定されているかどうか確認します。反対に、デフォルトのポリシーが [Allow] に設定されている場合、論理パーティションポリシーの [Deny] が設定されているかどうか確認します。

ステップ 7：重複または競合するポリシーが設定されていないことを確認します。

例：

[LP-India] -> [Interior LP-Pudong] -> [Border Allow]

[LP-Pudong] -> [Border LP-India] -> [Interior Deny]

ここでは、ポリシー間の論理関係が競合しています。論理ポリシーの内部LP-IndiaからBorder LP-Pudongが設定されている場合、この関係はBorder-LP pudongからLP-Indiaに当たることを意味します。これらのポリシーは実際には双方向に機能します。

つまりこの例では、最初のポリシーにより浦東地区にある内部 IP フォンでは PRI インド経由の発信が許可されています。同時に、PRI インドから浦東の地理位置情報にある IP フォンへの PSTN コールが許可されています。

ただし、第 2 のポリシーに従った場合、インド PRI から浦東地区にある IP フォンへのコールやその逆が拒否され、これは第 1 のポリシーと競合します。

そのような場合、最後に追加されたポリシーが優先される点に注意してください。

ステップ 8：Unified Reporting 機能で重複するポリシーを追跡して論理パーティションポリシーマトリックスを取得します。1 つの画面から CUCM で設定されたすべての論理パーティションポリシーを把握できるためトラブルシューティングに非常に役立ちます。フィルタレポートを備えた Unified CM 地理位置情報ポリシーは、選択された地理位置情報パーティションについて地理位置情報論理パーティションポリシーからレコードの全一覧を提供しますが、Unified CM 地理位置情報ポリシーレポートはすべての論理パーティションポリシーのレコードの全一覧を提供します。

ステップ9：いくつかのテストコールを行い、動作するかどうかを確認します。Real Time Monitoring Tool（RTMT）は新しい Perfmon カウンタでの論理パーティションポリシーの制限による障害の数を追跡するよう強化されています。Perfmon カウンタにはシスコのコール制限機能と呼ばれる新しいグループがあります。そこから転送障害、アドホック会議障害、ミートミー会議障害、転送障害、基本コール障害、通話中障害、合計コールの制限障害など、さまざまなシナリオのコール障害の数を追跡できます。

ステップ 10：コール中の RTMT から CUCM トレースを収集します。Signaling Distribution Layer（SDL）トレースでは選択中のポリシーと地理位置情報ポリシーペア間で設定されているポリシーを確認できます。

CC 信号での地理位置情報の通信。

| SdlSig    | CcRegisterPartyA                      | restart0                      | LineControl(1,100,139,3)        | SIPCdpc(1,100,55,17)            | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 2, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=23624774 CI.branch=0  CSS= cssIns=0 aarCSS= aarDev=T doNotAppendLineCSS=F lrg= ccBearCap.itc=0 ccBearCap.l=3 ccBearCap.itr=1 protected=1 flushCapIns=0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4} locPkid= locName=

PolicyAndRSVP 信号での地理位置情報の通信。

| SdlSig    | PolicyAndRSVPRegisterReq              | wait                          | RSVPSessionMgr(1,100,76,1)      | SIPCdpc(1,100,55,17)            | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 23624774 Branch= 0  reg=Default cap=5 loc=0 MRGLPkid= PrecLev=5 VCall=F VCapa=F regiState=0 medReq=0 dataCapFl=2 ipAddrMode=0 status=0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4}
| SdlSig    | PolicyRegisterReq                     | await_init                    | LPSession(1,100,26,21)          | RSVPSessionMgr(1,100,76,1)      | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 23624774 Branch= 0  geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4}

考慮するべきポイント

メディアデバイス、つまり MTP（メディアターミネーションポイント）、CFB（会議ブリッジ）、アナンシエーター、MoH（保留音）は地理位置情報の値と関連付ける必要はありません。
VoIP から VoIP デバイスへのコールや VoIP の参加者のみの機能で LP ポリシーの確認はありません。つまり、内部から内部へのポリシーは常に許可されます。
LPPolicyManager は InMemDB とのインターフェイスとなって、コール処理のポリシーを LP ポリシーツリー形式で保持する単一プロセスです。CUCM サービスの起動中、LPPolicyManager は InMemDB テーブルからポリシーを読み取り、LP ポリシーツリーを構築します。データベースでポリシーの追加/削除/更新を行うと、LPPolicyManager に変更内容が通知され、その変更が LP ポリシーツリーに反映されます。

論理パーティションポリシーの確認。

001853112| 2008/09/26 11:50:39.687| 001| AppInfo   |                                       |                               |                                 |                                 |                                         | LPPolicyManager -getLogicalPartitionPolicy, GeolocInfoA[pkid=31396408-3d83-74a9-1655-d2f0a05dd0a4, filter=d5bdda76-6a86-56c5-b5fd-6dff82b37493, val=, devType=4]
001853113| 2008/09/26 11:50:39.687| 001| AppInfo   |                                       |                               |                                 |                                 |                                         | LPPolicyManager -getLogicalPartitionPolicy, GeolocInfoB[pkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filter=d5bdda76-6a86-56c5-b5fd-6dff82b37493, val=, devType=8]