In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt die Konfiguration der logischen Partitionierung und Standortbestimmung in Cisco Unified Communications Manager (CUCM).
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Die Funktion zur logischen Partitionierung stellt sicher, dass beide Anruftypen über ein einzelnes System unterstützt werden können, solange Anrufe, die über ein Public Switched Telefone Network (PSTN)-Gateway weitergeleitet werden, nicht direkt mit einem VoIP-Telefon oder einem VoIP-PSTN-Gateway an einem anderen geografischen Standort (Geolokation) verbunden sind, selbst wenn eine Funktion für einen Anruf aktiviert wird.
In einigen Ländern wie Indien gibt es Telekom-Vorschriften, die auf Unternehmensebene eingehalten werden müssen. Aus diesem Grund sind die Unternehmen verpflichtet, eine Sprachinfrastruktur einzurichten. Sie sind so konfiguriert, dass das lokale PSTN ausschließlich für die Verbindung von Anrufen außerhalb des Unternehmens verwendet wird. Laut der Telecom Regulatory Authority (TRAI) darf das PSTN-Telefonienetzwerk in Indien für die Zwecke der Gebührenfolge niemals mit dem VoIP-Telefoniennetz verbunden werden.
Dazu muss das Sprachsystem logisch in zwei Systeme partitioniert werden: ein VoIP innerhalb des Unternehmens und ein zweites für den Zugriff auf das lokale PSTN.
Es war recht schwierig, diese Art von Sprachsystem mit der Calling Search Space (CSS)- und Partition-Funktion in CUCM zu verwalten. CSS und Partition können die grundlegenden Anrufe einschränken, aber Funktionen wie Umleitung und Beitritt während eines Anrufs können nicht eingeschränkt werden.
CUCM erfordert die Bereitstellung von IDs für die Zuweisung an Geräte wie Telefone, Gateways, Trunks usw. Die Standortbestimmung ist ein Standard, der als Identifizierer bei der logischen Partitionierung verwendet werden kann.
Der physische Standort wird anhand von bis zu 17 Parametern angegeben: Land-2-Buchstaben Abkürzung, Bundesland (A1), Bezirk (A2), Stadt (A3), Bezirk (A4), Nachbarschaft (A5), Straße (A6), Richtung (PRD), Straße-Suffix (POD), Hausnummer (HNO) und Hausnummer-Suffix (HNS).
Eine typische Richtlinienkonfiguration für logische Partitionen verwendet nur eine Teilmenge von Feldern im Datensatz für Geolokationsrichtlinien. Diese Auswahl wird durch den Standortfilter eingeschränkt. Die im Standortfilter ausgewählten Felder werden von der Funktion Logische Partitionierung verwendet.
In CUCM ist die logische Partitionierung als Anrufsteuerungsfunktion definiert, mit der die Kommunikation zwischen diesen VoIP-Einheiten mithilfe von Logical Partitioning-Richtlinien eingeschränkt werden kann.
Die Geräte in der logischen Partition sind als Innen- und Rahmen kategorisiert. Dies sind Geräte, die als Innenräume eingestuft sind:
Diese Geräte werden als Rahmen kategorisiert:
Schritt 1: Die Standard-Standortbestimmung gilt für Geräte, auf denen keine Standortbestimmung konfiguriert ist und die nicht an der logischen Partitionierung teilnehmen. Um die Standardrichtlinie für die Standortbestimmung festzulegen, spielt eine wichtige Rolle. Wenn die Richtlinie auf diese Funktion gesetzt ist, müssen Richtlinien für logische Partitionen mit deny-Funktionen und umgekehrt festgelegt werden.
Schritt 2: Gehen Sie zu System-> Geolocation Configuration, und fügen Sie die Informationen zum Standort hinzu. Dies dient als Kennung für die Geräte, die dieser speziellen Standortbestimmung zugeordnet sind.
Schritt 3: Gehen Sie zu System-> Geolocation Filter, und überprüfen Sie die Felder in der Konfiguration des Geolocation-Filters, basierend auf den Anforderungen der logischen Richtlinie für das Filtern.
Schritt 4: Konfigurieren Sie die Richtlinie für logische Partitionen. Dies ist der wichtigste Teil der Konfiguration, da alle Entscheidungen zum Zulassen oder Ablehnen der Anrufe von der Konfiguration abhängen.
Schritt 5: Rufen Sie die Seite für die Gerätekonfiguration des Telefons auf, und wenden Sie die Standortbestimmung an, je nachdem, wo sich das Telefon befindet.
Gehen Sie auf ähnliche Weise zum Gerätepool, und fügen Sie die Standortkonfiguration hinzu.
Schritt 6: Gehen Sie anschließend zur Konfigurationsseite für den Gateway-/Trunk-/MGCP-Port, der als Schnittstelle zum PSTN fungiert, und wenden Sie die Standortkonfiguration und den Standortfilter an.
Schritt 1: Aktivieren Sie in den Enterprise-Parametern die Option Logische Partitionierung aktivieren, und wählen Sie True aus.
Schritt 2: Stellen Sie sicher, dass die Geräte an einem gültigen Standort auf Geräte- oder Gerätepoolebene angeordnet sind.
Schritt 3: Überprüfen Sie auf der Konfigurationsseite, ob das Gerät einem gültigen Geolokationsfilter zugeordnet ist und ob einige Geolokationsfelder auf Geräte- oder Gerätepoolebene ausgewählt wurden.
Schritt 4: Achten Sie darauf, dass die Groß- und Kleinschreibung für Felder der LP GeolocationPolicy-Datensätze korrekt ist und mit der Konfiguration der Geolocation Records übereinstimmt.
Schritt 5: Die Standortkonfiguration, die Filter und die Richtlinien können mithilfe dieser SQL-Befehle auch über die CLI überprüft werden.
run sql select * from geolocationfilter run sql select * from geolocationpolicy run sql select * from geolocationpolicymatrix run sql select * from typelogicalpartitionpolicy
Schritt 6: Überprüfen Sie nach dem Überprüfen der Basiskonfiguration den Beziehungssatz zwischen Geolokationsrichtlinien. Wenn die Standardrichtlinie für die logische Partitionierung des Enterprise-Parameters auf Verweigern gesetzt ist, überprüfen Sie, ob Richtlinien für logische Partitionen zwischen Geolokationsrichtlinien eines Gateways und einer VoIP-Site konfiguriert sind. Im Gegenteil: Wenn die Standardrichtlinie Allow lautet, überprüfen Sie, ob Richtlinien für logische Partitionen verweigern konfiguriert wurden.
Schritt 7: Stellen Sie sicher, dass keine sich überschneidenden oder widersprüchlichen Richtlinien konfiguriert sind.
Beispiel.
LP-India->Interior LP-Pudong->Border Allow
LP-Pudong->Border LP-India->Interior Deny
In diesem Bereich gibt es einen Konflikt zwischen den verschiedenen Politikbereichen. Wenn eine logische Richtlinie für das Inland von LP-India zu Border LP-Pudong konfiguriert ist, impliziert dies, dass diese Beziehung für Border-LP Pudong zu LP-India gilt. Diese Richtlinien sind bidirektional.
In diesem Beispiel dürfen interne IP-Telefone an Pudong-Standorten gemäß der ersten Richtlinie über PRI-India anrufen. Gleichzeitig sind PSTN-Anrufe vom PRI-India zu den IP-Telefonen in Pudong Geolocation zulässig.
Nach der zweiten Richtlinie werden jedoch die Anrufe von der Indien-PRI an IP-Telefone am Standort Pudong und umgekehrt abgelehnt, aber dies steht im Widerspruch zur ersten Richtlinie.
Denken Sie in solchen Fällen daran, dass die Richtlinie, die zuletzt hinzugefügt wurde, Vorrang hat.
Schritt 8: Verfolgen Sie die sich überschneidenden Richtlinien mit der Unified Reporting-Funktion, um die Logical Partition Policy-Matrix abzurufen. Die Fehlerbehebung ist sehr hilfreich, da Sie alle in CUCM konfigurierten Richtlinien für logische Partitionen von einem Bildschirm aus kennen lernen können. Die Unified CM Geolocation Policy with Filter Report enthält eine vollständige Liste der Datensätze aus der Matrix für die logische Partitionierung (Geolocation Logical Partitioning Policy) für ausgewählte Geolocation-Richtlinien. Der Unified CM Geolocation Policy Report enthält eine vollständige Liste aller logischen Partitionierungsrichtlinien.
Schritt 9: Führen Sie einige Testanrufe durch, und prüfen Sie, ob diese funktionieren. Das Real Time Monitoring Tool (RTMT) wurde verbessert, um die Anzahl der Fehler zu verfolgen, die aufgrund von Einschränkungen der Richtlinien für die logische Partitionierung in neuen Perfmon-Zählern auftreten. Perfmon-Zähler verfügen über eine neue Gruppe mit dem Namen Cisco Call Restriction. Von dort aus können wir eine Reihe von Anrufausfällen in verschiedenen Szenarien verfolgen: Übertragungsfehler, Adhoc-Konferenzfehler, MeetMe-Konferenzfehler, Weiterleitungsfehler, grundlegende Anrufausfälle, Mid-Call Failures, Total Call Restriction Failures usw.
Schritt 10: Sammeln Sie die CUCM-Traces von RTMT für die Dauer des Anrufs. In der Spur des Signalisierungs-Distribution-Layers (SDL) werden die Richtlinie angezeigt, die ausgewählt wird, und die Richtlinien, die zwischen dem Geolocation Policy-Paar konfiguriert werden.
Kommunikation von Geolocation Info in CC Signalen.
| 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=
Übermittlung von Standortinformationen in PolicyAndRSVP-Signalen.
| 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}
Richtlinienüberprüfung für die logische Partitionierung.
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]
Der devType =4 (UserDevice) ist für diese Geräte vorgesehen.
Der devType =3 (AccessDevice), wenn für diese Geräte.
Das devType =8 (SIPAccessDevice) für dieses Gerät.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsz91044
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo85770
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsq79192
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsr91423
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsy73509
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtb33479
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtb05434
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsv65724
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
23-May-2017 |
Erstveröffentlichung |