Implementierung von GeoLocation in CUCM-Clustern

Einführung

In diesem Dokument wird erläutert, wie die Standortbestimmung durch Standortüberwachung über mehrere Cluster hinweg erweitert werden kann. Mit diesen neuen Informationen wird beschrieben, wie die Closed User Group (CUG) zwischen einem Cluster funktioniert, der reguliert ist und nicht für Cluster mit minimaler Konfiguration konfiguriert ist. Außerdem wird sichergestellt, dass die Vorschriften eingehalten werden.

Begriffe im Zusammenhang mit Standortbestimmung

GeoLocation

Der GeoLocation ist per Definition eine Beschreibung des physischen geografischen Gebiets, in dem derzeit etwas existiert. In CUCM weist die Standortdetails Geräten wie IP-Telefon, SIP-Trunk, Inter Cluster Trunk (ICT) Gateway usw. zu, was in einem Unternehmen über Cluster und Standorte hinweg Sinn machen könnte.

RFC 4119 legt 17 Elemente für den zivilen Standort fest, und die Funktion für die logische Partitionierung von UCM implementierte die manuelle Konfiguration dieser 17 Felder/Elemente aus Verwaltungskonfigurationen. Es wird empfohlen, alle 17 Felder auszufüllen. Die Felder sollten logische und kurze Bezeichnungen tragen.

Standortfilter

Der Standortfilter ist eine Regel zur Auswahl bestimmter Geolokationsfelder, um Geolokationszeichenfolgen zu erstellen. Diese können verwendet werden, um Richtlinien für die Funktion zur logischen Partitionierung zuzuordnen. d. h.  Es gibt Gruppen von Geolokationsfeldern, für die Richtlinien konfiguriert werden müssen.

Geolocation-Kennung

Eine Kennung, die aus einer Kombination aus Geolokation, Filter und Gerätetyp erstellt wird. Diese ID wird für den Vergleich mit LP verwendet, und Anrufe können zugelassen oder abgelehnt werden.

Geolokation für Geolokation und Standortfilter für Geräte = Geolokations-ID

D. h. ein SIP-Trunk in CUCM kann logisch dargestellt werden als

Grenze:Land:IN:A1:KAR:A2:BAN 

Geolocation Policy Record (GLP)

Die Richtlinien werden nicht direkt zwischen Standorten konfiguriert, da Geolocations in der Regel alle 17 Felder konfiguriert haben und möglicherweise für jedes UCM-Gerät in einem Cluster eindeutig sind. Die Konfiguration von Richtlinien zwischen geografischen Standorten kann für einen Administrator mit einer bestimmten Anzahl von geografischen Standorten einen hohen Overhead bedeuten. 

Damit Richtlinien erstellt werden können, muss der Administrator Datensätze erstellen, die die erforderlichen Daten für die Geolokationsfelder enthalten. Zu diesem Zweck bietet die Konfiguration die Möglichkeit, Daten aus Dropdown-Menüs auszuwählen, die Geolokationsfelder anzeigen.

Diese Datensätze werden als GLP-Datensätze (GeolocationPolicy) bezeichnet.

Hinweis: Die GeolocationPolicy-Datensätze sollten so erstellt werden, dass die zugehörigen Daten mit den in Filtern ausgewählten Feldern übereinstimmen. Die Hierarchie der Felder ist wichtig, und die Felder sollten nicht am Anfang oder in der Mitte verpasst werden, sondern am Ende auch verpasst werden.

Wenn die für den Filter spezifischen Felder nicht in Richtlinien festgelegt sind, entfernt der Suchalgorithmus das Feld am Ende und sucht nach einer möglichen Übereinstimmung in den Richtlinien.  

Beispiel: Wenn ich für ein LP das Feld C, A1, A2, A6 ausgewählt habe und für ein anderes LP nur das Feld C, A1, A6, dann nimmt der CUCM zwischen diesen beiden LP nur C und A1, obwohl A6 in beiden CUCM vorhanden ist, es nicht.

Standortbereitstellung

• Die Übertragung von GeoLocation von einem SIP-Benutzer-Agent an eine andere Einheit mithilfe von SIP wird als "Location Conveyance" (Standortüberwachung) bezeichnet.
  
  
• Zur Unterstützung der LP-Anforderungen übermittelt die UCM-Implementierung zusätzlich in PIDF-LO Gerätetypinformationen. Dies basiert auf dem User Agent Capability Presence Status, gemäß Spezifikation in der SIP-Erweiterung Draft-ietf-simple-prescaps-ext-08. 
  
  
• Der SIP-Trunk des UCM unterstützt die Standortübertragung gemäß diesen Spezifikationen.
  
  
• Damit ICT-Verbindungen mit SIP-Trunks kompatibel sein und dieselben Funktionen ermöglichen, unterstützt der ICT/H225-Trunk auch die Standortübertragung im Cluster mithilfe von PIDF-LO. 
  
  
• Das UCM unterstützt die Weiterleitung von Standortinformationen sowohl bei der Anrufeinrichtung als auch bei Standortänderungen aufgrund von Änderungen bei der Beteiligung verbundener Teilnehmer an Mid Call-Joins und Umleitungen.  

Standortübergreifende Implementierung im CUCM-Cluster

Annahme: Sie müssen wissen, warum Geolokation notwendig ist. 

Für dieses Dokument wurden 2 CUCM-Cluster verwendet. Es wird angenommen, dass ein Cluster in den USA und ein anderer in Indien ansässiger Cluster ansässig ist. Zur Demonstration werden die CUCM-Versionen 11.5 und 10.5 verwendet. Wir haben einen SIP-Trunk zwischen den Clustern. Der Wählplan ist so eingerichtet, dass auf diesem ICT/SIP-Trunk von beiden Clustern, die CSS und Partitionen verwenden, nur interne Anrufe zugelassen sind. Der Wählplan wurde so eingerichtet, dass VoIP-Anrufe an das PSTN das lokale Gateway verwenden, um PSTN-Anrufe über CSS und Partition zu tätigen.

Der indische Cluster ist ein Cluster, der auf logische Partitionen zugreifen kann. Der US-Cluster ist ein logisches, deaktiviertes/nicht erkanntes Cluster. Geolokations- und Standortfilter werden für alle Geräte in beiden Clustern konfiguriert und angewendet. Derzeit wird die logische Partition nur in Indien-Clustern konfiguriert. Später wird jedoch eine Einschränkung festgestellt, aufgrund derer die Geolokation aktiviert ist, und die logische Partition wird auch auf US-Clustern konfiguriert.  

Indien VOIP-Erweiterung: 7. XXX (7001, 7002)

VOIP-Durchwahl USA: 5XXX (5005)

PSTN-Erweiterung: 1 XXX (1005)

Dies ist das Bild mit Geolocation Identifiers.

Hintergrundinformationen

Auf indischer Seite gelten die TRAI-Bestimmungen. Einfach ausgedrückt kombinieren Sie keine Nicht-Lokal-VoIP-Anrufe mit einem lokalen PSTN-Anruf. CUG-Anrufe (Closed User Group) sind zulässig, d. h. VoIP-Anrufe innerhalb desselben Enterprise-Netzwerks sind zulässig.

Wenn Sie mehrere CUCM-Cluster an unterschiedlichen geografischen Standorten haben und einer davon geregelt ist, ist das Ziel

1. Einhaltung von TRAI oder gesetzlichen Bestimmungen
2. CUG-Funktion 

Theorie

Um das CUG zu aktivieren, wird die Standortübertragung verwendet, um die Richtliniendurchsetzung für die logische Partitionierung zu erweitern, d. h., Geolokationsinformationen werden an andere Cluster gesendet, da die Send Geolocation Data auf ICT und SIP-Trunk auf beiden Clustern überprüft werden. So können Sie Geolocation-Informationen von Geräten senden und empfangen. Außerdem können Sie feststellen, ob es sich bei dem Gerät um ein Gerät im Inneren oder an einer Grenze handelt.

Für die Ersteinrichtung des Anrufs benötigen Sie eine Richtlinie, die die Kommunikation zwischen IP-Telefon A und ICT ermöglicht. Sobald die SIP-INVITE an andere Cluster gesendet wurde, wird das Zielgerät B erkannt und sobald dieses Gerät klingelt oder/und den Anruf entgegennimmt, werden die Standortinformationen von Gerät B über eine SIP-INVITE-/UPDATE-Nachricht an das ursprüngliche Cluster gesendet. Sobald der ursprüngliche Cluster gültige Geolokationsinformationen in der INVITE/UPDATE-Nachricht empfängt, die die lokale Konfiguration der SIP-Trunk-Standortbestimmung überschreibt und diese durch die empfangene Geolokation ersetzt.

Mit diesen neuen Geolokationsinformationen können Sie eine logische Partitionsrichtlinie konfigurieren, die VoIP-Anrufe zulässt und VoIP-Anrufe vom Cluster, der sich an das Grenzgerät eines anderen Clusters ausrichtet, verweigert.

Hinweis: In diesem Szenario müssen alle Cluster über Geolocations- und Standortfilter verfügen, die konfiguriert und auf alle Gerätepools angewendet werden. Clusterübergreifende Anrufe beinhalten Standortdaten und die Frage, ob dieser Teilnehmer als Innen- oder Grenzteilnehmer angesehen wird. Wenn bei einem clusterübergreifenden Anruf keine Standortdaten empfangen werden, wird stattdessen der Geolocation and Geolocation Filter in der Trunk-Konfiguration oder der aus dem Gerätepool des Trunks geerbte Filter verwendet.

Design

Wenn Sie Geolocation und logische Partitionen entwerfen möchten, sollten Sie

• Wie kann der physische Standort des Geräts, das den Anruf entgegennimmt, und das Gerät, das den Anruf entgegennimmt, eindeutig identifiziert werden?
• Sammeln Sie Informationen darüber, zwischen welchen Orten/Orten ich Anrufbeschränkungen unterwerfen muss.
• In den 17 Feldern, die bei Auswahl ausgewählt werden, können Sie entscheiden, ob Sie den Anruf zulassen oder ablehnen möchten. 

In den Geolocation-Feldern gibt es 17 Felder, die von A1 bis A6 bis zu Postleitzahl reichen. Um aus A1 zu füllen, ist es wie in eine Karte zu zoomen. Je mehr Details Sie eingeben, desto genauer kann der Standort des Geräts bestimmt werden, dem dieser Standort zugewiesen ist. Es muss berücksichtigt werden, welche Felder von allen Feldern in der Geolokation ein Gerätepaar für CUCM enthalten sollten, mit denen Sie eine effektive logische Partitionsentscheidung treffen können.

Wenn die Richtlinie für logische Partitionen konfiguriert ist, haben Sie die Möglichkeit, eine Reihe von Geolokationsfeldern auszuwählen. Wählen Sie diese Geolokationsfelder aus. Wenn ein Gerät einen Anruf tätigt, werden dem CUCM eine Reihe von Geolokations-IDs angezeigt, und das Zielgerät erhält einen Anruf, der dem CUCM eine Reihe von Geolokations-IDs anzeigt. Wenn diese Felder mit einer vordefinierten Logical Partition Policy übereinstimmen, können für Aufrufe Einschränkungen angewendet werden.

Beispiel. Wenn Gerät A eine Geolokations-Info A1=IN, A2=BAN, NAM=BGL14 und Gerät B eine Geolokation A1=IN,A2=MUM,NAM=BAN1 hat. Erstellen Sie eine Geolokationsrichtlinie 1, die Folgendes vorsieht: A=IN,A2=BAN,NAM=BGL14. Erstellen Sie Policy 2 A=IN, A2=MUM, NAM=BAN1. Sie müssen zulassen oder ablehnen, wenn Geräte die Richtlinien 1 und 2 erfüllen.

Wenn ein Anruf getätigt wird und das Ursprungsgerät über die Standortinformationen A1=IN,A2=BAN,NAM=BGL14 verfügt, weiß CUCM, dass die Richtlinie 1 ausgewählt werden kann. Wenn das Zielgerät außerdem über die Geolocation-Info A1=IN,A2=MUM,NAM=BAN1 verfügt, weiß CUCM, dass es sich um eine perfekte Übereinstimmung für die logische Partitionsbeziehung zwischen Richtlinie 1 und 2 handelt.

Hinweis: Es wird empfohlen, dass die Felder für den Standortfilter und die Richtlinienauswahl für die logische Partition dieselben Felder enthalten, die ausgewählt und zugeordnet sind, oder dass es sich bei dem Richtlinienfeld für die logische Partition um eine Teilmenge der Felder für den Standortfilter handelt, sodass Sie bei einem Aufruf die Richtlinie für die logische Partition in der ersten Iteration zugeordnet haben. Sie sollten versuchen, bei Telefongesprächen die richtige Wahl zu finden.

Konfiguration auf dem CUCM

Die Konfiguration des indischen Clusters kann in folgende Teile unterteilt werden:

Geolokation konfigurieren

In diesem Fall werden drei Standorte erstellt.

• Für Geräte in Indien: Indien_GL
• Für SIP-Trunk in ICT: Indien_ICT_GL
• Für Geräte in den USA: USA_GL

Hinweis: Im indischen Cluster wird eine Empty_GL konfiguriert, die als Standardgeolokation angegeben wird. Wenn Sie jedoch vergessen, einem Gerät über einen Gerätepool Geolocation hinzuzufügen, wird dieser Standort verwendet, um Anrufe an ein Grenzgerät abzulehnen.

Dieses Bild zeigt die Konfiguration für Indien_GL.

Dieses Bild zeigt die Konfiguration India_ICT_GL.

Dieses Bild zeigt die US_GL-Konfiguration.

Wie im Bild gezeigt, werden für Geolokationsfilter die Felder Country, A1, A2, NAM verwendet.

Geolokation aktivieren

Aktivieren Sie die logische Partitionierung im Enterprise-Parameter, legen Sie eine Standardrichtlinie auf Verweigern fest, wenden Sie die Standardzugriffsberechtigung auf Empty_GL an.

Zuweisung von Standorten zu Geräten

• Weisen Sie im CUCM-Gerätepool für IP-Telefon India_GL zu.

• Weisen Sie auf dem ICT SIP-Trunk India_ICT_GL zu, und überprüfen Sie, ob Geolokationsinformationen gesendet werden sollen.

Fahren Sie anschließend zum UC-Cluster fort. Sie müssen eine US-Geolokationsrichtlinie erstellen und diese mit Geräten im US-Cluster verknüpfen.  Vergewissern Sie sich, dass das Kontrollkästchen Standortinformationen senden auf SIP-Trunk oder ICT zwischen US- und indischem Cluster aktiviert ist. 

Wenn die Konfiguration im US-Cluster abgeschlossen ist, kehren Sie zum Indien-Cluster zurück.

Konfigurieren von Richtlinien für logische Partitionen

Es werden drei logische Richtlinien erstellt.

• IKT-Politik: Country=IN, A1=KAR, A2=BAN, NAM=ICT
• Indien-Richtlinie: Land=IN,A1=KAR,A2=BAN,NAM=BGL14
• US-Politik: Country=US,A1=TEX,A2=SAN,NAM=BGL1

Konfigurieren von Beziehungen zwischen Richtlinien der logischen Partition

Nach der Konfiguration der logischen Partition füllen Sie die Beziehungen zwischen den beiden Richtlinien auf.

ICT Logical Policy

Gerätetyp, Richtlinie und deren Beziehung zu anderen Richtlinientabellen.

Gerätetyp	Richtlinie	Gerätetyp	Richtlinie	Ergebnis
Grenze	Country=IN, A1=KAR, A2=BAN, NAM=ICT(ICT-Richtlinie)	Grenze	Country=IN, A1=KAR, A2=BAN, NAM=ICT(ICT-Richtlinie)	Zulassen
Grenze	Country=IN, A1=KAR, A2=BAN, NAM=ICT(ICT-Richtlinie)	Innenbereich	Country=IN,A1=KAR,A2=BAN,NAM=BGL14(indische Richtlinie)	Zulassen

• Internes IP-Telefon wird benötigt, um auf ICT zuzugreifen, bevor Sie das Update des Geräts von US-Seite erhalten. Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT (ICT SIP-Trunk) to Interior:Country=IN,A1=KAR,A2=BAN,NAM=BGL14 (IP-Telefone in Indien) als Zulassen.
  
  
• Falls Sie den Anruf an die USA zurückschicken müssen, dann benötigen Sie ICT-to-ICT-Anrufe, wie erlaubt, sodass Sie die Beziehung Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT to Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT als Zulassen haben.
  
  

Logische Richtlinien für Indien

Gerätetyp, Richtlinie und deren Beziehung zu anderen Richtlinientabellen.

Bei dieser Konfiguration ist die logische Partition nur auf Indien-Clustern konfiguriert, und die Standortübertragung zwischen US-amerikanischen und indischen Clustern erfolgt. Sie sollten in der Lage sein, Anrufe zwischen Clustern in den USA und Indien so zu blockieren, dass sie sich mit dem PSTN mischen und CUG zum Laufen bringen. Testen Sie diese Konfiguration, indem Sie einige Anrufe tätigen.

Szenarien

• Das IP-Telefon in Indien ruft das IP-Telefon in den USA an.
• IP-Telefon in Indien ruft IP-Telefon in den USA an, IP-Telefon in Indien leitet Anrufe an PSTN-Benutzer weiter.
• IP-Telefon in Indien ruft IP-Telefon in den USA an, IP-Telefonkonferenzen für PSTN-Benutzer in Indien.
• Das IP-Telefon in Indien ruft das IP-Telefon in den USA an, das wird von US Ext an den PSTN-Benutzer übertragen.
• Das IP-Telefon in Indien ruft das IP-Telefon in den USA an, ein Benutzer des US Ext Conferences PSTN.

Szenario 1: IP-Telefon in Indien ruft IP-Telefon in den USA an

Erwartetes Verhalten: Anruf zulassen

Beobachtetes Verhalten: Anruf ist zulässig

Das indische IP-Telefon Ext 7001 ruft uns über die Durchwahl 5005 an.

Das folgende Diagramm zeigt die SIP-Trunk-Leiter.

Sie können den Anruf in zwei Teile unterteilen.

• Bevor Sie die Geolokationsinformationen von US Cluster erhalten haben.
• Nachdem Sie die Geolokationsinformationen von US Cluster erhalten haben.

Wenn Sie bemerken, dass es die ersten 200 OK und ACK für die erste SIP-Einladung. Wenn Sie sich die 200 OK näher ansehen, die Sie aus dem US-Cluster erhalten haben, wird festgestellt, dass der RTP-Port ein Dummy-Port ist, d. h. 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 hat noch nicht begonnen zu fließen. Nach dem ACK sehen Sie eine weitere SIP-INVITE und in dieser haben Sie Geolocation-Informationen an sich.

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--

In dieser Einladung wird die RTP-Portnummer angezeigt, die das US-IP-Telefon verwendet. Die Standortinformationen des IP-Telefons und Informationen darüber, ob es sich um ein Gateway handelt oder nicht, werden an Indien-Cluster gesendet. Mit diesen neuen Standortinformationen werden erneut logische Partitionen im indischen Cluster abgeglichen, um zu prüfen, ob der Anruf zugelassen oder abgelehnt werden soll. Da es sich um interne Anrufe handelt, wird die logische Partition nicht angewendet, und der Anruf ist zulässig.

Szenario 2: IP-Telefon in Indien ruft IP-Telefon in den USA an, IP-Telefon in Indien leitet Anruf an PSTN-Benutzer weiter

Erwartetes Verhalten: Anruf ablehnen

Beobachtetes Verhalten: Anruf wird abgelehnt

Das IP-Telefon Ext 7001 in Indien ruft uns Ext 5005 an, trifft den Softkey Transfer erstmalig, wählt die PSTN-Nummer 1005, drückt die Übertragungstaste, aber es passiert nichts.

In der CUCM-Spur sehen Sie.

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.

Auf der indischen Cluster-Partei wird A an ein PSTN-Gerät, d. h. ein Grenzelement, geleitet. Sie haben keine Zulässigkeit zwischen der indischen Grenze und dem US-amerikanischen Innern festgelegt. Daher verwenden Sie die Standardrichtlinie, um den Anruf abzulehnen und zu blockieren.

Szenario 3: IP-Telefon in Indien ruft IP-Telefon in den USA, Indien IP-Telefonkonferenzen PSTN-Benutzer an

Erwartetes Verhalten: Anruf ablehnen

Beobachtetes Verhalten: Anruf wird abgelehnt

Das indische IP-Telefon Ext 7001 ruft uns Ext 5005 an, das indische IP-Telefon Ext 7001 klickt auf den Softkey Confrn, wählt die PSTN-Nummer 1005, klickt auf den Softkey Confrn, wie im Bild gezeigt. Sie sehen jedoch, dass die Konferenz nicht verfügbar ist.

In den CUCM-Protokollen wird Folgendes angezeigt:

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

Auf der indischen Cluster-Partei wird A an ein PSTN-Gerät, d. h. ein Grenzelement, geleitet. Sie haben keine Zulässigkeit zwischen der indischen Grenze und dem Inneren der USA festgelegt. Daher verwenden Sie die Standardrichtlinie, die auf "Ablehnen" und "Anruf wird blockiert" festgelegt ist.

Szenario 4: Das IP-Telefon in Indien ruft das IP-Telefon in den USA an, das wird von US Ext an den PSTN-Benutzer übertragen.

Erwartetes Verhalten: Anruf ablehnen

Beobachtetes Verhalten: Anruf wird abgelehnt

Das IP-Telefon Ext 7001 in Indien ruft das US-IP-Telefon Ext 5005 an, das US-IP-Telefon Ext 5005 klickt auf den Softkey Transfer (Weiterleiten), wählt die PSTN-Nummer 1005 und klickt erneut auf.

Wenn die US-Durchwahl den Anruf an das PSTN weiterleitet, erhalten Sie ein Update vom US-Cluster.

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>

In der Aktualisierung sehen Sie, dass das Gerät, mit dem es interagiert, ein Randelement ist. Mit diesen Informationen wendet CUCM auf indischer Seite jetzt wieder eine logische Partition auf diesen Anruf an, und das Ergebnis ist, dass der Anruf abgelehnt wird.

In den CUCM-Protokollen wird Folgendes angezeigt:

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]

Partei B, d. h. das Gerät aus den USA wird jetzt vom internen in das grenzübergreifende Element aktualisiert. Die Standardrichtlinie wird zugeordnet, und die Standardrichtlinie im indischen Cluster lautet Deny.

Szenario 5: IP-Telefon in Indien ruft IP-Telefon in den USA an, PSTN-Benutzer für US-Ext-Konferenzen

Erwartetes Verhalten: Anruf ablehnen

Beobachtetes Verhalten: Anruf ist zulässig

In diesem letzen Szenario funktioniert der Anruf. Bei der Weiterleitung an den Standort können wir den Konferenzanruf, der in den USA von den in Indien konfigurierten logischen Partitionen initiiert wird, nicht blockieren. Dies ist eine Einschränkung dieser Konfiguration. Um diese Einschränkung zu überwinden, müssen Sie dann auch die logische Partition auf dem UC-Cluster konfigurieren.

Der nächste Abschnitt der Konfiguration muss auf der Seite "US Cluster" erfolgen.

US-Cluster-Konfiguration

Die Konfiguration des US-Clusters kann in diese Teile unterteilt werden.

• Konfiguration der Standortbestimmung
• Geolokation ermöglichen
• Zuweisung von Standorten zu Geräten
• Konfigurieren von Richtlinien für logische Partitionen
• Konfigurieren der Beziehung zwischen Richtlinien für logische Partitionen

Geolokation konfigurieren

In diesem Fall werden drei Standorte erstellt.

• Für Geräte in Indien: Indien_GL
• Für SIP-Trunk in ICT: US_ICT_GL
• Für Geräte in den USA: USA_GL

Dieses Bild zeigt die US_GL-Konfiguration.

Dieses Bild zeigt die Konfiguration US_ICT_GL.

Dieses Bild zeigt die Konfiguration India_GL.

Für den Filter werden die Felder "Land A1", "A2" und "NAM" verwendet, wie im Bild gezeigt.

Geolokation aktivieren

Aktivieren Sie die logische Partition auf dem Unternehmensparameter, die Standardrichtlinie lautet Zulassen.

Zuweisung von Standorten zu Geräten

Hinweis: Sie hätten jetzt bereits den Gerätepool des US-IP-Telefons mit der Ortsbestimmung US_GL konfiguriert.

Weisen Sie US_ICT_GL dem ICT SIP-Trunk im US-Cluster zu. 

Konfigurieren von Richtlinien für logische Partitionen

Im US-Cluster werden zwei logische Richtlinien erstellt.

• Indien-Richtlinie: Country=IN,A1=KAR,A2=BAN,NAM=BGL14
• US-Politik: Country=US,A1=TEX,A2=SAN,NAM=BGL1

Logische US-Richtlinie

Gerätetyp, Richtlinie und deren Beziehung zu anderen Richtlinientabellen.

Diese Konfiguration, die für IP-Telefone in Indien verwendet wird, ruft IP-Telefon in den USA an. Der PSTN-Benutzer für die Konferenzen in den USA ist jetzt gesperrt.

Sie sehen diese Fehlermeldung auf dem US-IP-Telefon, wenn wir versuchen, einen Benutzer des US-PSTN mit einem indischen IP-Telefon zu konferenzen.

Sobald die Standortbestimmung im US-Cluster konfiguriert wurde, ist das Verhalten für Szenario 2 und 4 identisch. Das indische Cluster muss nicht auf ein SIP-UPDATE/INVITE von US-Cluster warten, da die Ablehnung von Anrufen im US-Cluster selbst erfolgt, da die logische Partition auf US-Seite in Kraft tritt. 

Damit sollte CUG zwischen dem Cluster Indien und den USA funktionieren und sicherstellen, dass Sie VoIP-Anrufe von einem Cluster nicht mit PSTN-Anrufen eines anderen Clusters kombinieren.

Zukünftige Skalierung 

Hinzufügen eines neuen Clusters zum Unternehmensnetzwerk

Wenn Sie neue Cluster skalieren und aufnehmen möchten, gehen Sie davon aus, dass Sie zwei neue Cluster hinzufügen müssen. Cluster Vereinigtes Königreich und Frankreich

Im Hinblick auf die Konfiguration mit der vorhandenen Konfiguration fügen Sie diese hinzu

Auf der indischen Seite

• Sie müssen lediglich eine britische Region und eine französische Region im indischen Cluster hinzufügen.
• Weisen Sie dem SIP-Trunk nach Großbritannien und Frankreich eine ICT-Standortbestimmung zu.
• Vergewissern Sie sich, dass das Kontrollkästchen Send Geolocation Information (Standortinformationen senden) auf SIP-Trunk oder ICT aktiviert ist.

UK-Cluster

• Erstellen Sie eine Standortbestimmung für Großbritannien, ICT und Indien mit demselben Filter wie andere Cluster (ähnlich der Cluster-Konfiguration in den USA).
• Behalten Sie die Standardrichtlinie so weit wie möglich bei.
• Vergewissern Sie sich, dass das Kontrollkästchen Send Geolocation Information (Standortinformationen senden) auf SIP-Trunk oder ICT aktiviert ist.
• Weisen Sie dem SIP-Trunk/ICT einen Standortfilter und einen Standortfilter zu.
• Erstellen Sie zwei logische Richtlinien für UK und Indien.
• In der Richtlinie des Vereinigten Königreichs wird die logische Trennungsbeziehung zwischen der britischen Grenze und Indien als "deny" konfiguriert.

Frankreich Cluster

• Erstellen Sie die Standortbestimmung für Frankreich, ICT und Indien mit dem gleichen Filter wie andere Cluster (ähnlich der Cluster-Konfiguration in den USA).
• Behalten Sie die Standardrichtlinie so weit wie möglich bei.
• Vergewissern Sie sich, dass das Kontrollkästchen Send Geolocation Information (Standortinformationen senden) auf SIP-Trunk oder ICT aktiviert ist.
• Weisen Sie dem SIP-Trunk/ICT einen Standortfilter und einen Standortfilter zu.
• Erstellen Sie zwei logische Richtlinien, eine Richtlinie für Frankreich und eine Richtlinie für Indien.
• In Frankreich konfiguriert die Richtlinie die logische Trennungsbeziehung zwischen der französischen Grenze und Indien als "deny".

Das Hinzufügen eines neuen Clusters aus einem anderen Land würde wie oben beschrieben erfolgen. Dadurch wird die Konfiguration auf ein Minimum reduziert, und die Skalierung ist möglich, wenn Sie weitere Cluster hinzufügen.

Was ist zu tun, wenn Sie einen Experten haben?

KMU fungiert als Träger von Geolokationsinformationen, ohne an einer logischen Partitionierung auf dem KMU-Cluster teilzunehmen.

• Aktivieren Sie das Kontrollkästchen Geolokationsinformationen senden auf SIP-Trunk oder ICT.
• Keine Geolokationskonfiguration für KMU erforderlich.

.

Alle Standortkonfigurationen und die logische Partitionierung erfolgen nur auf dem Leaf-Knoten. Die Konfiguration auf dem Leaf-Knoten ähnelt einer Geolokationskonfiguration zwischen zwei Clustern über ICT. Der Experte gibt einfach die Geolokationsinformationen weiter, die er von einem Trunk an einen anderen Trunk erhält, da er als Proxy fungiert.  

Hinweis: Die Liste ist keinesfalls erschöpfend. Als Administrator müssen Sie das Parken von Anrufen und die Anrufübernahme (lokal und remote) testen, SNR, EM, EMCC, Huntpilot, CTI-bezogene Weiterleitung und Konferenz, Adhoc- und Meet-Me-Konferenz sowohl im Cluster als auch testen. 

Einschränkung

Konferenzverkettung - z. B. MeetMe- und Adhoc-verkettete Konferenzen können Teilnehmer haben, die LP ablehnen, jedoch nicht daran gehindert werden können, in der Kommunikation zu bleiben.

Empfehlung: Deaktivieren Sie die Konferenzverkettung anhand des Service-Parameters. 

Corner Case of CBarge/Barge - Wenn der verbundene Teilnehmer aufgrund einer aktiven Funktion wie Konferenz oder MeetMe eine Konferenzbrücke ist und ein aktives Gerät mit gemeinsam genutzter Leitung Geolokation übernimmt, die für alle Geräte in der Konferenz zulässig ist, zeigt das Remote-Gerät mit gemeinsam genutzten Leitungen Informationen zur Anrufinstanz an. In diesem Fall kann das Remote-Telefon immer die Funktion "cBarge/Barge" ausführen, selbst wenn ein nicht autorisierter Teilnehmer an der Konferenz teilnimmt. Für die Teilnehmer von cBarge/Barge gibt es keine Überprüfung der Richtlinien für logische Partitionierung, und Szenarien, die eine logische Partitionierung abgelehnt haben, können nicht verhindert werden.  

Zugehörige Informationen

• 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

• Technischer Support und Dokumentation - Cisco Systems