CUCMクラスタ間での位置情報の実装

概要

このドキュメントでは、ロケーション伝達を使用してマルチクラスタ展開にわたって位置情報を拡張する方法について説明します。最小限の設定で規制されているクラスタと規制されていないクラスタ間でクローズドユーザグループ(CUG)を動作させる方法に関するこの新しい情報を使用します。また、規制ルールの遵守も保証します。

位置情報に関連する用語

地理位置情報

GeoLocationは、定義上、現在何かが存在する物理的な地理的エリアの説明です。CUCMでは、位置情報は、IP電話、SIPトランク、Inter CLuster trunk(ICT)ゲートウェイなどのデバイスにロケーションの詳細を割り当てます。これは、企業間、クラスタおよびサイト間で意味を持ちます。

RFC 4119では、17個のCivic Location要素を指定し、UCM論理パーティション機能では、これらの17個のフィールド/要素を管理設定から手動で設定しています。17フィールドすべてに入力することをお勧めします。フィールドには、logicalおよびshortという名前を付ける必要があります。

地理位置情報フィルタ

位置情報フィルタは、論理パーティション機能のポリシーの照合に使用できる位置情報ストリングを構築するために、位置情報の特定のフィールドを選択するルールです。たとえば、  ポリシーを設定する必要がある位置情報フィールドのセットが提供されます

位置情報ID

位置情報、フィルタ、およびデバイスタイプの組み合わせから構成される識別子です。この識別子はLPと比較するために使用され、コールは許可または拒否されます

デバイスの位置情報∩位置情報フィルタ+デバイスタイプ=位置情報ID

つまり、CUCMのSIPトランクは、次のように論理的に表すことができます

Border:Country:IN:A1:KAR:A2:BAN 

位置情報ポリシーレコード(GLP)

Geolocationsには通常17個のフィールドがすべて設定されており、クラスタ内の各UCMデバイスに固有である可能性があるため、ポリシーはGeolocations間で直接設定されません。そのため、Geolocation間のポリシー設定は、特定の数のGeolocationに対する管理者のオーバーヘッドが大きくなる可能性があります。 

ポリシーを作成するために、管理者は位置情報のフィールドに必要なデータを持つレコードを作成する必要があります。このため、設定では、位置情報フィールドを示すドロップダウンからデータを選択するプロビジョニングが提供されます。

これらのレコードは、GeolocationPolicy(GLP)レコードと呼ばれます。

注：GeolocationPolicyレコードは、そのデータがフィルタで選択されたフィールドと一致するように作成する必要があります。フィールドの階層は重要であり、フィールドの最初または中間の位置は失わないはずですが、最後の位置は失われる可能性があります。

フィルタに固有のフィールドがポリシーに含まれていない場合、検索アルゴリズムはフィールドを末尾から削除し、ポリシーで一致する可能性があるかどうかを探します。  

例：1つのLPにフィールドC、A1、A2、A6を選択し、別のLPにC、A1、A6のみを選択した場合、この2つのLP間のCUCMは、両方のCUCMにA6が存在していても、C、A1のみをとします。

ロケーション伝達

• SIPを使用して、あるSIPユーザエージェントから別のエンティティへのGeoLocationの伝達をロケーション伝達と呼びます。
  
  
• LP要件をサポートするために、UCMの実装ではPIDF-LOのデバイスタイプ情報を追加して伝達します。これは、SIP拡張のdraft-ietf-simple-prescaps-ext-08の仕様に従って、[User Agent Capability Presence Status]に基づいています。 
  
  
• UCMのSIPトランクは、次の仕様に従ってロケーション伝達をサポートします。
  
  
• ICTをSIPトランクと互換性のある機能にし、同じ機能を使用できるようにするため、ICT/H225トランクは、PIDF-LOを使用したクラスタ間のロケーション伝達もサポートします。 
  
  
• UCMは、コール確立時のロケーション情報の伝達と、コール中の参加における接続側の変更によるロケーション変更の両方をサポートします。  

CUCMクラスタ間での位置情報の実装

前提条件:位置情報とその必要性に関する基本的な知識がある。 

このドキュメントでは、2つのCUCMクラスタを使用しています。1つのクラスタは米国に常駐し、他のクラスタはインドに常駐すると想定されます。デモンストレーション用にCUCMバージョン11.5および10.5を使用しています。クラスタ間にSIPトランクがあります。ダイヤルプランは、CSSとパーティションを使用して両方のクラスタからこのICT/SIPトランクで内部コールだけが許可されるように設定されます。VOIPからPSTNへのコールがローカルゲートウェイを使用してCSSとパーティションを使用してPSTNコールを発信するように、ダイヤルプランが設定されています。

Indiaクラスタは、論理パーティション対応/対応クラスタです。USAクラスタは、論理パーティションが無効/非対応のクラスタです。位置情報および位置情報フィルタが設定され、両方のクラスタのすべてのデバイスに適用されます。現時点では、インドのクラスタでのみ論理パーティションを設定し、後で制限が発生します。これは、どの位置情報が有効になっているかによる問題で、米国のクラスタでも論理パーティションを設定するためです。  

India VOIP内線番号：7XXX(7001、7002)

USA VOIP内線番号：  5XXX(5005)

PSTN内線：1XXX(1005)

これは、位置情報IDを持つイメージです。

背景説明

インド側では、TRAI規制が適用されます。簡単な用語では、非ローカルVOIPコールとローカルPSTNコールを混在させないでください。クローズドユーザグループ(CUG)コールが許可されます。つまり、同じエンタープライズネットワーク内のVOIPコールが許可されます。

地理的に異なる場所に複数のCUCMクラスタがあり、そのうちの1つが規制されている場合は、次の目的を達成します

1. TRAIまたは規制ルールに従う
2. CUGを使用している 

理論

CUGを動作させるには、ロケーション伝達を使用して論理パーティションポリシーの適用を拡張します。つまり、地理位置情報は両方のクラスタのICTおよびSIPトランクでSend Geolocation Dataがオンに設定されていると、他のクラスタに送信されます。これにより、デバイスの位置情報の送受信が可能になり、それに加えて、デバイスが内部または境界であるかどうかを確認できます。

コールの初期設定には、IP Phone AとICT間の通信が許可されるようにポリシーが必要です。SIP INVITEが他のクラスタに送信されると、宛先デバイスBが検出され、このデバイスが呼び出し中またはコールに応答すると、デバイスBの位置情報がSIP INVITE/UPDATEメッセージを介して発信側クラスタに送信されます。発信側クラスタがINVITE/UPDATEメッセージで有効な位置情報を受信すると、ローカルSIPトランクの位置情報の設定が上書きされ、これを受信した位置情報に置き換えます。

この新しい位置情報を使用すると、VOIPからVOIPへのコールを許可し、別のクラスタのボーダーデバイスに到達するクラスタからのVOIPコールを拒否するように論理パーティションポリシーを設定できます。

注：このシナリオでは、すべてのクラスタに位置情報および位置情報フィルタを設定し、すべてのデバイスプールに適用する必要があります。クラスタ間コールには、位置情報データが含まれ、その参加者が内部と境界のどちらであるかが含まれます。クラスタ間コールで位置情報データが受信されない場合は、トランク設定の位置情報フィルタまたはトランクのデバイスプールから継承された位置情報フィルタが代わりに使用されます。

設計

位置情報および論理パーティションを設計するには、

• コールを発信するデバイスと、コールを受信するデバイスの物理的な場所を一意に識別する方法
• コール制限を設定する必要がある位置情報/物理的な場所に関する情報を収集します。
• 17個のフィールド（選択した場合）のうち、コールを許可するか拒否するかを決定できます。 

位置情報フィールドには17個のフィールドがあり、A1から郵便番号までA6に移動します。A1から塗り潰すには、マップを拡大表示します。詳細を入力すると、デバイスの場所を正確に特定でき、その位置情報が割り当てられます。考慮すべき点は、地理位置情報のすべてのフィールドのうち、有効な論理パーティションの決定が可能なデバイスのペアがCUCMに存在する必要があるということです。

論理パーティションポリシーが設定されている場合は、位置情報フィールドのセットを選択し、デバイスがコールを発信したときにCUCMに位置情報IDのセットを提示し、宛先デバイスがCUCMに位置情報IDのセットを提示するコールを受信するように選択します。これらのフィールドが定義済みの論理パーティションポリシーに一致する場合、コールに制限を適用できます。

例：デバイスAに位置情報A1=IN,A2=BAN,NAM=BGL14があり、デバイスBに位置情報A1=IN,A2=MUM,NAM=BAN1がある場合、位置情報ポリシー1を作成します=BGL14。ポリシー2 A=IN,A2=MUM,NAM=BAN1を作成します。ポリシー1と2に一致するデバイス間で許可または拒否を行う必要があります。

コールが発信され、発信元デバイスの位置情報がA1=IN、A2=BAN、NAM=BGL14の場合、CUCMはポリシー1が選択できることを認識します。宛先デバイスにも位置情報A1=IN、A2=MUM、NAM=BAN1がある場合、CUCMはポリシー1と2の論理パーティション関係に最適であることを認識します。

注：位置情報フィルタフィールドと論理パーティションポリシーフィールドの選択で同じフィールドを選択して一致させるか、論理パーティションポリシーフィールドを位置情報フィルタフィールドのサブセットにすることをお勧めします。コールが行われている場合は、完全な一致を試してください。

CUCMの設定

インドのクラスタ構成は、次の部分に分けることができます。

位置情報の設定

この場合、3つの位置情報が作成されます。

• インドのデバイス：India_GL
• ICTでのSIPトランクの場合：India_ICT_GL
• 米国のデバイス：US_GL

注：インドのクラスタでは、Empty_GLが設定され、これはデフォルトの位置情報として指定されます。これは、デバイスプールを介して任意のデバイスに位置情報を追加することを忘れた場合に、この位置情報を使用して任意の境界デバイスへのコールが拒否されるようにするためです。

次の図は、India_GLの設定を示しています。

次の図に、India_ICT_GLの設定を示します。

次の図に、US_GLの設定を示します。

図に示すように、位置情報フィルタには、[Country]、[A1]、[A2]、[NAM]フィールドが使用されます。

位置情報の有効化

エンタープライズパラメータで論理パーティションを有効にし、デフォルトポリシーを[Deny]に設定し、デフォルトの位置情報をEmpty_GLとして適用します。

デバイスへの位置情報の割り当て

• IP PhoneのCUCMデバイスプールでIndia_GLを割り当てます。

• ICT SIPトランクでIndia_ICT_GLを割り当て、地理位置情報を送信するようにチェックします。

これが完了したら、UCクラスタに移動します。米国の位置情報ポリシーを作成し、これを米国クラスタ内のデバイスに関連付ける必要があります。  米国とインドのクラスタ間のSIPトランクまたはICTで[Send Geolocation Information]チェックボックスがオンになっていることを確認します。 

米国クラスタの設定が完了したら、インドのクラスタに戻ります。

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

3つの論理ポリシーが作成されます。

• ICTポリシー：Country=IN,A1=KAR,A2=BAN,NAM=ICT
• インド政策：Country=IN,A1=KAR,A2=BAN,NAM=BGL14
• USポリシー：国=US、A1=TEX、A2=SAN、NAM=BGL1

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

論理パーティションを設定したら、2つのポリシー間の関係を設定します。

ICT論理ポリシー

デバイスタイプ、ポリシー、およびその他のポリシーテーブルとの関係。

デバイス タイプ	ポリシー	デバイスタイプ	ポリシー	結果
ボーダー	Country=IN,A1=KAR,A2=BAN,NAM=ICT（ICTポリシー）	ボーダー	Country=IN,A1=KAR,A2=BAN,NAM=ICT（ICTポリシー）	プライベート ネットワーク間で
ボーダー	Country=IN,A1=KAR,A2=BAN,NAM=ICT（ICTポリシー）	内部	Country=IN,A1=KAR,A2=BAN,NAM=BGL14（インド政策）	プライベート ネットワーク間で

• 米国側からデバイスのアップデートを取得する前にICTに到達するには、内部IP電話が必要です。Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT（ICT SIPトランク）からInterior:Country=IN,A1=KAR,A2=BAN NAM=BGL14（インドのIP Phone）は[Allow]です。
  
  
• 米国へのコールバックをヘアピンする必要がある場合は、ICTからICTへのコールを許可されている必要があります。これにより、Border:Country=IN,A1=KAR,A2=BAN,NAM=ICTからBorder:Country=IN,A1=KAR,BAN,BAN ICTを許可します。
  
  

インドの論理政策

デバイスタイプ、ポリシー、およびその他のポリシーテーブルとの関係。

この設定では、論理パーティションがインドのクラスタでのみ設定され、米国とインドのクラスタ間でロケーション伝達が行われます。米国とインドのクラスタ間のコールがPSTNと混在するのをブロックし、CUGを動作させることができなければなりません。いくつかのコールを行って、この設定をテストします。

シナリオ

• インドのIP Phoneが米国のIP Phoneにコールします。
• インドのIP Phoneが米国のIP Phoneにコールし、インドのIP PhoneがPSTNユーザにコールを転送します。
• インドのIP Phoneが米国、インドのIP Phone会議のPSTNユーザに電話をかけます。
• インドのIP Phoneが米国のIP Phoneにコールすると、US ExtはこれをPSTNユーザに転送します。
• インドのIP Phoneが米国のIP Phone、米国の内線会議のPSTNユーザにコールします。

シナリオ 1：インドのIP Phoneが米国のIP Phoneにコールする

予想される動作:コールの許可

観察された動作：コールが許可される

インドのIP Phone Ext 7001はUs Ext 5005と呼んでいます。

SIPトランクラダー図を次に示します

コールを2つに分割できます。

• USクラスタから位置情報を取得する前。
• 米国クラスタから位置情報を取得した後。

最初のSIP INVITEに対して最初の200 OKとACKがあることに気付いた場合。USクラスタから得た200 OKの詳細を見ると、RTPポートがダミーポート(4000)であることがわかります

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.106.97.137:5060;branch=z9hG4bK68935124bc7a
From: <sip:7001@10.106.97.137>;tag=26724~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365227
To: <sip:5005@10.106.97.135>;tag=16120~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364848
Date: Sat, 16 Mar 2019 19:52:55 GMT
Call-ID: 15e0cb00-c8d15417-6828-89616a0a@10.106.97.137
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uas
Require:  timer
P-Asserted-Identity: <sip:5005@10.106.97.135>
Remote-Party-ID: <sip:5005@10.106.97.135>;party=called;screen=yes;privacy=off
Remote-Party-ID: <sip:5005@10.106.97.135;user=phone>;party=x-cisco-original-called;privacy=off
Contact: <sip:5005@10.106.97.135:5060>
Content-Type: application/sdp
Content-Length: 340
v=0
o=CiscoSystemsCCM-SIP 16120 1 IN IP4 10.106.97.135
s=SIP Call
c=IN IP4 10.65.43.112
b=TIAS:64000
b=AS:64
t=0 0
m=audio 4000 RTP/AVP 9 0 8 116 3 18
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 iLBC/8000
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=sendonly

RTPはまだフローを開始していません。ACKの後に、もう1つのSIP INVITEが表示され、その中に位置情報が自分自身に送信されています。

INVITE sip:7001@10.106.97.137:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.97.135:5060;branch=z9hG4bK11f6de9436
From: <sip:5005@10.106.97.135>;tag=16120~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364848
To: <sip:7001@10.106.97.137>;tag=26724~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365227
Date: Sat, 16 Mar 2019 19:53:00 GMT
Call-ID: 15e0cb00-c8d15417-6828-89616a0a@10.106.97.137
Supported: timer,resource-priority,replaces
Cisco-Guid: 0367053568-0000065536-0000000033-2304862730
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
Min-SE:  1800
Geolocation: 
     
     
       ;inserted-by="10.106.97.135" 
     
P-Asserted-Identity: <sip:5005@10.106.97.135>
Remote-Party-ID: <sip:5005@10.106.97.135>;party=calling;screen=yes;privacy=off
Contact: <sip:5005@10.106.97.135:5060>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 1219
--uniqueBoundary
Content-Type: application/sdp
v=0
o=CiscoSystemsCCM-SIP 16120 2 IN IP4 10.106.97.135
s=SIP Call
c=IN IP4 10.65.43.112
b=TIAS:64000
b=AS:64
t=0 0
m=audio 25344 RTP/AVP 9
a=ptime:30
a=rtpmap:9 G722/8000
--uniqueBoundary
Content-Type: application/pidf+xml
Content-ID: <5005@10.106.97.135>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:cisco="http://www.cisco.com"
entity="pres:geotarget@example.com">
<dm:device id="sg89ae">
<caps:devcaps>

     
     
       false 
     
</caps:devcaps>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>

     
     
       US 
     

     
     
       TEX 
     

     
     
       SAN 
     

     
     
       BGL1 
     
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2019-03-17T19:53:00Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
<timestamp>2019-03-16T19:53:00Z</timestamp>
</dm:device>
</presence>

--uniqueBoundary--

このInviteには、US IP Phoneが使用するRTPポート番号が表示されます。IP電話の位置情報と、ゲートウェイであるかどうかについての情報がインドのクラスタに送信されます。この新しい位置情報を使用すると、インドのクラスタで論理パーティションが再度照合され、コールが許可されるか拒否されるかを確認できます。これらは内部から内部へのコールであるため、論理パーティションは適用されず、コールは許可されます

シナリオ 2：インドのIP Phoneが米国のIP Phoneにコールし、インドのIP PhoneがPSTNユーザにコールを転送

予想される動作:コールを拒否する

観察された動作：コールが拒否される

インドのIP Phone Ext 7001はUs Ext 5005にコールし、最初に転送ソフトキーにヒットし、PSTN番号1005にダイヤルし、転送キーを押しますが、何も起こりません。

CUCMトレースに、が表示されます。

01192372.012 |01:51:49.984 |AppInfo  |LPPolicyManager -getLogicalPartitionPolicy, devtypeA[Border], devtypeB[Interior]
01192372.013 |01:51:49.984 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Border], devTypeB[Interior]
01192372.014 |01:51:49.984 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,
01192372.015 |01:51:49.984 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

01192372.074 |01:51:49.984 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]
01192372.075 |01:51:49.984 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]
01192372.076 |01:51:49.984 |AppInfo  |Transferring - LPPolicy Result [9]
01192372.077 |01:51:49.984 |AppInfo  |LPPolicyManager -incLogicalPPerfmon, perfMon[0]
01192372.078 |01:51:49.984 |AppInfo  |Transferring - handleTransferErrorPreStart, ERROR fid=[4], Retaining Calls, xferring[1, 18365238], xferred[1, 18365239]. infoCause=53, clearCause=63

01192668.001 |01:51:56.765 |AppInfo  |StationD:    (0000019) DisplayNotify timeOutValue=10 notify='a' content='External Transfer Restricted' ver=8560000c.

インドのクラスタパーティでは、AはPSTNデバイス（ボーダーエレメント）に接続されます。インドの境界と米国内部の間で許可を設定していないため、デフォルトのポリシーセットを使用して拒否し、コールをブロックします。

シナリオ 3：インドのIP Phoneが米国、インドのIP Phone会議PSTNユーザに電話をかけます

予想される動作:コールを拒否する

観察された動作：コールが拒否される

インドのIPフォン内線7001が米国内線5005にコールし、インドのIPフォン内線7001が最初に[Confrn]ソフトキーをクリックし、PSTN番号1005にダイヤルし、図に示示示すように[Confrn]ソフトキーををします。ただし、[Conference is unavailable]と表示されます。

CUCMログには、次のように表示されます。

01213687.146 |02:00:35.806 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Border], devTypeB[Interior]
01213687.147 |02:00:35.806 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,
01213687.148 |02:00:35.806 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

01213687.207 |02:00:35.806 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]
01213687.208 |02:00:35.806 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]
01213687.209 |02:00:35.806 |AppInfo  |Conference: processGeoLocationResultListForConfRequest:ci=18365306,status=9

インドのクラスタパーティでは、AはPSTNデバイス（ボーダーエレメント）に接続されます。インドの境界と米国内部の間で許可を設定していないため、拒否に設定され、コールがブロックされるデフォルトポリシーを使用します。

シナリオ 4：インドのIP Phoneが米国のIP Phoneにコールし、米国の内線はこれをPSTNユーザに転送

予想される動作:コールを拒否する

観察された動作：コールが拒否される

インドのIPフォン内線7001はUS IPフォン内線5005にコールし、US IPフォン内線5005は最初に転送ソフトキーをクリックし、PSTN番号100005に5をダイヤル、転送キーを再クリックします。

US内線番号がコールをPSTNに転送すると、USクラスタから更新が送信されます。

UPDATE sip:7001@10.106.97.137:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.97.135:5060;branch=z9hG4bKbe39bb25ad
From: <sip:5005@10.106.97.135>;tag=6376~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364784
To: <sip:7001@10.106.97.137>;tag=9968~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365199
Date: Wed, 13 Mar 2019 10:57:03 GMT
Call-ID: b6619180-c881e1f8-26cd-89616a0a@10.106.97.137
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 UPDATE
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=MIXED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
Min-SE:  1800
Geolocation: 
     
     
       ;inserted-by="10.106.97.135" 
     
P-Asserted-Identity: <sip:1005@10.106.97.135>
Remote-Party-ID: 
     
     ;party=calling;screen=yes;privacy=off
Contact: <sip:1005@10.106.97.135:5060>
Content-Type: application/pidf+xml
Content-ID: 1005@10.106.97.135
Content-Length: 872
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:cisco="http://www.cisco.com"
entity="pres:geotarget@example.com">
<dm:device id="sg89ae">
<caps:devcaps>

     
     
       true 
     
</caps:devcaps>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>

     
     
       US 
     

     
     
       TEX 
     

     
     
       SAN 
     

     
     
       BGL1 
     
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2019-03-14T10:57:14Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
<timestamp>2019-03-13T10:57:14Z</timestamp>
</dm:device>
</presence>

更新では、対話するデバイスが境界要素であることがわかります。この情報を使用すると、インド側のCUCMは再びこのコールに論理パーティションを適用し、結果としてコールを拒否します。

CUCMログには、次のように表示されます。

00443670.032 |16:27:14.830 |AppInfo  |LPPolicyManager -getLogicalPartitionPolicy, devtypeA[Interior], devtypeB[Border]
00443670.033 |16:27:14.830 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Interior], devTypeB[Border]
00443670.034 |16:27:14.830 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,
00443670.035 |16:27:14.830 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

00443670.064 |16:27:14.830 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]
00443670.065 |16:27:14.830 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]

ユーザB（米国のデバイス）が内部からボーダーエレメントに更新されました。デフォルトポリシーが一致し、インドのクラスタのデフォルトポリシーが[Deny]になります。

シナリオ5：インドのIP Phoneが米国のIP Phone、米国の内線会議PSTNユーザにコールする

予想される動作:コールを拒否する

観察された動作：コールが許可される

この最後のシナリオでは、ロケーション伝達だけでコールが機能しますが、インドのクラスタで設定された論理パーティションによって米国で開始された会議コールをブロックすることはできません。これは、この設定の制限です。この制限を克服するには、UCクラスタにも論理パーティションを設定する必要があります。

configの次のセクションは、US CLuster側で行う必要があります。

USクラスタの設定

USクラスタの設定は、次の部分に分けることができます。

• 位置情報の設定
• 位置情報の有効化
• デバイスへの位置情報の割り当て
• 論理パーティションポリシーの設定
• 論理パーティションポリシー間の関係の設定

位置情報の設定

この場合、3つの位置情報が作成されます。

• インドのデバイス：India_GL
• ICTでのSIPトランクの場合：US_ICT_GL
• 米国のデバイス：US_GL

次の図に、US_GLの設定を示します。

次の図に、US_ICT_GLの設定を示します。

次の図に、India_GLの設定を示します。

図に示すように、フィルタには[Country A1]、[A2]、[NAM]フィールドが使用されます。

位置情報の有効化

エンタープライズパラメータの[Logical Partition]を有効にし、[Default policy]を[Allow]に設定します。

デバイスへの位置情報の割り当て

注：これで、位置情報US_GLを使用してUS IP Phoneのデバイスプールがすでに設定されているはずです。

US_ICT_GLをUSクラスタのICT SIPトランクに割り当てます。 

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

USクラスタには2つの論理ポリシーが作成されます。

• インド政策：  Country=IN,A1=KAR,A2=BAN,NAM=BGL14
• USポリシー：国=US、A1=TEX、A2=SAN、NAM=BGL1

米国論理ポリシー

デバイスタイプ、ポリシー、およびその他のポリシーテーブルとの関係。

インドのIP Phoneが米国のIP Phoneにコールする場合、この設定に代わって、米国のIP Phone Conferences PSTNユーザがブロックされるようになりました。

インドのIP Phoneと米国のPSTNユーザを会議しようとすると、US IP Phoneでこのエラーメッセージが表示されます。

米国クラスタで位置情報を設定すると、シナリオ2と4の動作は同じになります。米国側で論理パーティションが有効になるため、インドのクラスタは米国のクラスタ自体でコールの拒否が発生するため、米国のクラスタからのSIP UPDATE/INVITEを待つ必要はありません。 

これにより、インドと米国のクラスタ間でCUGを動作させ、クラスタ間のVOIPコールと別のクラスタのPSTNコールを混在させないようにする必要があります。

将来の拡張 

エンタープライズネットワークへの新しいクラスタの追加

新しいクラスタをスケールアップして収容するには、追加する2つの新しいクラスタがあると仮定します。英国クラスタとフランスのクラスタ。

既存の設定に関しては、次の項目を追加します

インド側で

• インドのクラスタに英国の位置情報とフランスの位置情報を追加するだけです。
• 英国およびフランスに向かうSIPトランクにICT位置情報を割り当てます。
• SIPトランクまたはICTで[Send Geolocation Information]チェックボックスがオンになっていることを確認します。

英国クラスタ

• 英国、ICT、およびインドの位置情報を、他のクラスタと同じフィルタで作成します（米国のクラスタ設定と同様）。
• デフォルトポリシーはallowのままにします。
• SIPトランクまたはICTで[Send Geolocation Information]チェックボックスがオンになっていることを確認します。
• SIPトランク/ICTにICTとして位置情報および位置情報フィルタを割り当てます。
• 2つの論理ポリシーUKポリシーとインドのポリシーを作成します。
• 英国のポリシーでは、英国の境界とインドの内部の間の論理パーティション関係をdenyとして設定します。

フランスのクラスタ

• 他のクラスタと同じフィルタを使用して、フランス、ICT、およびインドの位置情報を作成します（米国のクラスタ設定と同様）。
• デフォルトポリシーはallowのままにします。
• SIPトランクまたはICTで[Send Geolocation Information]チェックボックスがオンになっていることを確認します。
• SIPトランク/ICTにICTとして位置情報および位置情報フィルタを割り当てます。
• 2つの論理政策、フランス政策、インド政策を作成します。
• フランスでは、ポリシーにより、フランスの境界とインドの内部の間の論理パーティション関係がdenyとして設定されます。

別の郡から新しいクラスタを追加するには、上記の手順を実行します。これにより、設定が最小限に抑えられ、クラスタを追加すると拡張できます

SMEを使用している場合の対処方法

SMEは、SMEクラスタ上の論理パーティションに参加することなく、位置情報のキャリアとして機能します。

• SIPトランクまたはICTで[Send Geolocation Information]チェックボックスをオンにします。
• SMEで位置情報を設定する必要はありません。

.

すべての位置情報の設定と論理パーティションは、リーフノードでのみ実行されます。リーフノードの設定は、ICT上の2つのクラスタ間の位置情報の設定に似ています。SMEは、1つのトランクで受信した位置情報を、プロキシとして機能する別のトランクに渡すだけです。  

注：このリストは完全なものではありません。管理者は、コールパークとコールピックアップ（ローカルおよびリモート）、SNR、EM、EMCC、Huntpilot、CTI関連の転送と会議、アドホック、ミートミー会議をクラスタ上でテストし、テストする必要があります。 

制限

会議チェーン：例：MeetMeおよびアドホックチェーン会議には、LPが拒否された参加者を含めることができますが、通信に参加することは禁止できます。

推奨事項：サービスパラメータから会議チェーンを無効にします。 

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

関連情報

• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/11_5_1_SU1/cucm_b_system-configuration-guide-1151su1/cucm_b_system-configuration-guide-1151su1_chapter_01010001.html
  
  
• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/11_5_1_SU1/cucm_b_system-configuration-guide-1151su1/cucm_b_system-configuration-guide-1151su1_chapter_01010000.html
  
  
• https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116038-logical-partition-geolocation-00.html
  
  
• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100_chapter_011100.html
  
  
• https://tools.ietf.org/html/rfc6442

• テクニカル サポートとドキュメント – Cisco Systems