このドキュメントでは、位置情報(Geolocation)、位置情報フィルタ(Geolocation Filter)、および論理パーティション(Logical Partitioning)を、インドなどオンネット コールからオフネット コールを分離する必要がある国でどのように使用できるかについて説明します。コーリング サーチ スペース(CSS)とパーティションで提供されるサービス クラスは、特定の法律や規制に準拠するために必要とされる細やかなレベルを提供しない場合があります。また、これらの同じ要素が Extension Mobility Cross Cluster(EMCC)設定で使用されていることに気づくこともあります。さらに特定の場所にフィルタリングする方法については、「Cisco Unified Communications Manager リリース 7.1(2) の機能とサービスのガイド」を参照してください。このドキュメントでは、地理的なコンポーネントについては詳しくは説明しません。このドキュメントは、どのようにすべてが論理的に連携して機能するかということを焦点にしています。
このドキュメントに特有の要件はありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
これらの主な要素は、次の Cisco Unified Communications Manager(CUCM)(CallManager)の [CCMAdmin] ページにあります。
[CCMAdmin] で、[Enterprise Parameters]> [Logical Partitioning Configuration] に移動します。位置情報(Geolocation)および論理パーティション(Logical Partitioning)に影響を与える可能性のあるパラメータは、4 つあります。次の点に注意してください。
設定を変更し、それが期待どおりに機能しない理由を特定できない場合は、電話などのエンドポイントに直接割り当てられた位置情報、およびSIPトランクなどのトランクとゲートウェイを調べます。電話機、トランク、ゲートウェイに直接割り当てられた位置情報フィルタを調べます。これらの両方が空白の場合、上記の [Enterprise Parameters] の中にリストされている [Default Policy]を調べます。
これで、電話機(Interior(内部)デバイス)と、トランクまたはゲートウェイ(Border(ボーダー)デバイス)に割り当てられている詳細が分かったので、論理パーティション ポリシー(Logical Partition Policy)を一致させることができます。[Call Routing] > [Logical Partition Policy Configuration] に移動します。ポリシーに関する知識と理解が課題になることがあります。このドキュメントの目的の 1 つは、広範囲にわたる役立つ例を提供することです。
Bangalore と Chennai という 2 つのポリシーを設定します。[Logical Partitioning Policy Configuration]ページを表示すると、選択した 2 つの [Device Type] の内の最初のデバイス タイプに常にリンクされる名前が先頭に表示されることを覚えておいてください。Bangalore の論理パーティション ポリシー(Logical Partitioning Policy)(位置情報ポリシー(Geolocation Policy))を設定する場合、許可(Allow)と拒否(Deny)の関係は常に Bangalore Interior または Bangalore Border で始まります。
これら 2 つのポリシーについて、Bangalore の [Policy] ページ上での可能な順列は次のとおりです。
また、これら 2 つのポリシーについて、Chennai の [Policy] ページ上での可能な順列も次の 8 つあります。
注:さまざまな理由から、このように多数のポリシーの関係を設定する必要はありません。関係ロジックは方向を調べません。したがって、Bangalore InteriorからChennai Borderは、Chennai BorderからBangalore Interiorと同じものです。 互いに矛盾する設定を行わないようにしてください。
Q: 矛盾や重複するポリシーがあるとどうなりますか。
A:ある特定のロジックで動作しますが、追跡が困難である可能性があります。このロジックは、追加された最後のポリシー(変更されたポリシーではなく、新しく追加されたポリシー)に関連します。
値の [Allow]が含まれていたポリシーの値が、後で [Deny] に変更された場合、そのポリシーは [Deny] のままになります。逆も同様です。前に [Deny]に設定されていて、後で [Allow] に変更されたポリシーは、[Allow] になります。[Cisco Unified Reporting]> [Geolocation Policy Report] は、重複するポリシーの特定に役立ちます。
Q:「Bangalore Interior から Chennai Border」が [Allow] に設定され、「Chennai Border から Bangalore Interior」が [Deny] に設定されるとどうなりますか。
A:Chennai Border から Bangalore Interior が追加された最後のポリシーの場合、そのポリシーが優先されます。
注:ポリシーが影響を与えるのは、Interior から Border、Border から Interior、および Border から Border の関係だけで、Interior から Interior の関係には影響を与えません。
この追加の情報を考慮すると、このドキュメント内のポリシーの例は、組み合わされた 16 個のエントリから 7 個のエントリに大幅に減らすことができます。Interior から Interior は影響を受けないことを覚えておいてください。Interior から Interior、および重複するポリシーを取り消し線で示しれ、今後、リストに示さないことにします。
Bangalore の [Policy] ページは、次のようになります。
Chennai の [Policy] ページは、次のようになります。
Chennai Policy に一致する Chennai Geolocation を持つ IP フォンは、Chennai の Interior デバイスです。Chennai Policy に一致する Chennai Geolocation を持つ SIP トランクは、Chennai の Border デバイスです。特に [Device-Type]を割り当てる必要はありません。CUCM では、トランク、ゲートウェイ、電話機を自動的に分類します。Chennai の Interior デバイス(電話機)から呼び出しが拒否される(たとえば、呼び出しでファースト ビジー信号を受信する)ことなく Chennai の Border デバイス(SIP トランク)を呼び出せるようにしたい場合、「Chennai Interior から Chennai Border」のポリシーを [Allow]に設定し、後でポリシーが重複して設定されないようにする必要があります。
注:[Device Pool] への変更は、その変更をコミットするために、[Device Pool] がリセットされる必要があります。このリセットは多数のデバイスに影響を与える可能性があるため、変更は業務時間外に設定してください。
注:CallManager SDI(ccm.txt)トレースで、番号分析(DA)が実行されずに、論理パーティション(LP)が原因でコール(呼び出し)が拒否されていることに気づくかもしれません。以下が一例です。SIP Invite, Trying, 503 Service Unavailable with no DA in between.
拒否メッセージ全体の例を次に示します。
09/18/2012 21:53:48.379 CCM|Cdcc::CcRejInd: ccRejInd.c.cv = -1493172161|
<CLID::KCMCS01-Cluster> <NID::10.50.1.11><CT::2,100,45,1.1290981><IP::10.50.15.127><DEV::>
<LVL::Detailed><MASK::0800>
...
CV=-1493172161 in CcRejInd refers to Logical Partitioning denial as per this
junked Defect CSCsz91044
...
09/18/2012 21:53:48.380 CCM|//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP
message to 10.50.15.127 on port 50380 index 90345
SIP/2.0 503 Service Unavailable
次の図では、位置情報および論理パーティションの例を示しています。
図 1:ネットワーク図
この図では、望ましいコール フローを示しています。このコール フローは、TEHO(テール エンド ホップ オフ)とトール バイパスを制限する政府の規制による結果である可能性が高いです。
ここでは、CUCM で位置情報(Geolocation)と論理パーティション(Logical Partition)をセットアップおよび設定するための手順を示します。
ステップ 1:[Enterprise Parameters Configuration] で次の設定を行います。[Logical Partitioning Default Policy]を [Deny] または [Allow] のいずれに設定するかに注意してください。これは重要です。この設定例の場合、[Deny]に設定されています。
図 2:CUCM の [Logical Partitioning Configuration](論理パーティションの設定)
ステップ 2:[Geolocation Filter Configuration]に移動し、この特定の設定に 1 つのフィルタを指定します。設定が非常に詳細になる場合は、さらにフィルタを指定できます。ここの場合は、[Country]とだけ照合することを指定します。
図 3:CUCM の [Geolocation Filter Configuration](位置情報フィルタの設定)
ステップ 3:[Geolocation Configuration]に移動し、優先してフィルタ処理する必要がある対象の特定の指定場所をセットアップします。この設定は非常に単純で、[Geolocation Filter] で設定したもの以外に設定する必要はありませんが、この例では追加の設定をいくつか示します。
図 4:CUCM の位置情報(Geolocation)のリスト
図 5:[Geolocation Configuration](位置情報の設定)
図 6:[Geolocation Configuration] ページ 2
ステップ 4:[Device Pool Configuration]に移動し、[Geolocation Configuration] のパラメータを探します。このパラメータは、電話機が物理的に存在する場所に設定します。
図 7:[Device Pool Configuration](デバイス プールの設定)
ステップ 5:電話機用のデバイス設定ページに移動し、電話が存在する場所を選択します。
図 8:電話機の設定
ステップ 6:PRI インターフェイス用のデバイス設定ページに移動し、それらのインターフェイスを個々の構成単位として、そしてあたかも同じものであるかのように設定します。
図 9:India(インド)用の PRI
図 10:US(米国)用の PRI
手順 7:このステップは、論理パーティション ポリシー(Logical Partition Policy)の設定でより難しい部分です。
注:2 つのポリシーが必要です。
図:11:[Logical Partitioning Policy](論理パーティション ポリシー)のリスト
図 12:India(インド)のポリシー
図 13:India(インド)のポリシー(続き)
図 14:US(米国)のポリシー
図 15:US(米国)のポリシー(続き)
ここでは、「ボーダー(Border)」と「内部(Interior)」の意味と、デバイスが「ボーダー」と「内部」のいずれであるかを判断する方法について説明します。
CUCM デバイスを分類するために使用される用語は、それらの機能に基づきます。
通常のボーダー デバイスには、次のものがあります。
通常の内部デバイスには、次のものがあります。
この「ボーダー」と「内部」のソースは CUCM デバイスに基づいて固定されており、CUCM リリース 7.1 では設定できません。
このドキュメントの設定例はすべて、[Enterprise Parameters] を [Deny] 状態にして実行されました。図 2 を参照してください。 状況によっては、この設定が設定されているため、これを実現するのは困難であるため拒否するすべてを割り当ててから、設定するには、この値を変更することができます。
このセットアップでは、設定する必要があるのは以下のものだけです。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
29-Apr-2013 |
初版 |