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 den Modus Operandi, mit dem Cisco Unified Communications Manager entscheidet, welche CUCM-Knoten zum Senden von Anrufen über SIP- (Session Initiation Protocol) oder H.323-basierte Trunks verwendet werden.
Cisco empfiehlt, dass Sie zuvor über folgende Themen informiert sind:
Die Informationen in diesem Dokument basieren auf Cisco Unified Communications Manager (CUCM) 8.x und höher.
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.
SIP-Trunks und H.323-Gateways sind nicht beim CUCM registriert (im Gegensatz zu MGCP-Gateways). Stattdessen bestimmt die CUCM-Gruppe, die dem mit dem Trunk oder Gateway verbundenen Gerätepool zugeordnet ist, wo diese aktiv sind. Wenn sie z. B. auf 2 oder 3 Knoten aktiv sind, über welchen Mechanismus entscheidet der CUCM, auf welchen Server der Anruf gesendet werden soll.
In diesem Dokument wird erläutert, wie Anrufweiterleitungsentscheidungen getroffen werden und wie der Lastenausgleich für ausgehende Anrufe über SIP-Trunks oder H.323 erreicht werden kann.
Allgemeine Logik: Wenn der CUCM eine Ziffernanalyse durchlaufen hat, wird der Anruf bei einem ausgehenden Anruf auf die RouteList oder das Endgerät weitergeleitet. (RouteList wird für einen bestimmten Knoten registriert, der von der CUCM-Gruppe abhängt.)
Das RouteList-Steuerelement identifiziert die Liste der Geräte und fragt den Gerätemanager ab.
Der Gerätemanager gibt die Geräte-Prozess-ID (PID) an (Beispiel: (2.100,25,45), in diesem Beispiel ist das Gerät auf Knoten 2 aktiv.)
Die RouteList-Steuerung überprüft den Status des Geräts (ist das Zielgerät aktiv, inaktiv oder besetzt) und leitet den Anruf auf den Trunk oder das Gateway weiter.
Da SIP-Trunks/H.323-Gateways auf mehreren Knoten aktiv sein können, stellt sich jetzt die Frage, welcher Knoten vom Gerätemanager als aktive PID ausgewählt wird.
Diese Anwendungsfälle beleuchten Folgendes:
In diesem SIP-Trunk ist auf Knoten 1 und 4 aktiv.
In diesem Fall ist der SIP-Trunk auf Knoten 1 aktiv, auf dem das Telefon registriert ist, sodass CUCM den Anruf von Knoten 1 (jedes Mal) erweitert. Hier wird keine zufällige Logik angewendet, und es gibt keinen Lastenausgleich, da der Anruf in jedem Fall von Knoten 1 aus weitergeleitet wird.
In diesem SIP-Trunk ist auf Knoten 2 und 4 aktiv.
Da die RouteList für Knoten 2 registriert ist und der SIP-Trunk auf demselben Knoten aktiv ist, werden alle Anrufe unabhängig vom Standort des Telefons von Knoten 2 übernommen. Auch hier wird keine zufällige Logik angewendet.
In diesem H323-Gateway ist auf Knoten 1 und 4 aktiv.
Sie wendet die zufällige Logik an und gibt dem RouteList-Steuerelement eine aktive PID zufällig zu. Da sie zufällig zwischen Knoten 1 und 4 gesendet wird, wird der Lastausgleich für Anrufe im CUCM vorgenommen.
CUCM überprüft, ob der SIP-Trunk/das H.323-Gateway auf demselben Knoten wie das anrufende Gerät aktiv ist. In diesem Fall wird der Anruf immer über den lokalen Knoten gesendet.
Wenn das SIP-Trunk-/H.323-Gateway nicht auf demselben Knoten wie das anrufende Gerät aktiv ist, wird es willkürlich von den Knoten geleitet, auf denen der Trunk/das Gerät aktiv ist.
Hinweis: Beim anrufenden Gerät kann es sich entweder um ein Telefon oder um eine RouteList handeln. Wenn das Routenmuster mit einer RouteList übereinstimmt, ist der anrufende Teilnehmer die RouteList. Wenn das Weiterleitungsmuster direkt mit dem SIP/H.323-Gerät verknüpft ist, ist der Anrufer das Telefon.
Wenn eine Lastverteilung erreicht werden soll, ist es nicht ratsam, die RouteList oder das Telefon mit den CUCM-Knoten zu verbinden, denen die SIP/H.323-Gateways zugeordnet sind, d. h. wenn beide auf demselben Knoten aktiv sind, werden Anrufe vom lokalen Knoten (immer) gesendet.
Anders ausgedrückt: Das SIP-Trunk-/H.323-Gateway muss so konfiguriert werden, dass es nicht an den Knoten aktiv ist, an denen die RouteList oder Telefone registriert sind.
Ab CUCM Version 8.6 hat CUCM auf allen aktiven Unified CM-Knoten eine neue Funktion namens Ausführen für RouteList-/SIP-Trunks eingeführt.
Dies ist eine weitere Möglichkeit, die ausgehenden Anrufe effizient auszugleichen und die Anzahl der im Cluster ausgetauschten Signale zu reduzieren.
In CUCM 8.5 und höher hat Cisco eine neue Funktion für SIP-Trunks und die Routenliste Run auf allen aktiven Unified CM-Knoten eingeführt. Dadurch wurde die Abhängigkeit des SIP-Trunks und der Routenliste der ihnen zugewiesenen CUCM-Gruppe entfernt. Dies bedeutet, dass Sie über mehr als drei CUCM-Server verfügen können, die Anrufe von und zu einem SIP-Trunk auslösen und beenden.
Wenn die Option Ausführen auf allen aktiven Unified CM-Knoten auf einem SIP-Trunk aktiviert ist, erstellt Unified CM eine Instanz des SIP-Trunk-Daemons auf jedem Subscriber zur Anrufverarbeitung innerhalb des Clusters, sodass ein SIP-Trunk-Anruf auf jedem Subscriber zur Anrufverarbeitung getätigt oder empfangen werden kann. (Vor dieser Funktion können mithilfe von Unified CM-Gruppen bis zu drei Knoten pro Trunk ausgewählt werden.)
Bei aktiviertem Ausführen aller aktiven Unified CM-Knoten gehen ausgehende SIP-Trunk-Anrufe von demselben Knoten aus, auf dem der eingehende Anruf (z. B. von einem Telefon oder Trunk) empfangen wird (basierend auf der Route Local (Route Local)-Regel). Die Funktion Ausführen auf allen aktiven Unified CM-Knoten überschreibt die Unified CM-Gruppenkonfiguration des Trunks.
Für SIP-Trunks wird die Route Local-Regel wie folgt ausgeführt:
Bei ausgehenden SIP-Trunk-Anrufen, wenn ein Anruf von einem registrierten Telefon oder einem eingehenden Trunk an einem Unified CM-Knoten eingeht, prüft Unified CM, ob eine Instanz des ausgewählten ausgehenden Trunks auf demselben Knoten vorhanden ist, auf dem der eingehende Anruf eingeht. In diesem Fall verwendet Unified CM diesen Knoten, um den ausgehenden Trunk-Anruf einzurichten.
Um Run auf allen aktiven Unified CM-Knoten auf SIP-Trunks zu aktivieren, wird dringend empfohlen, da diese Funktion es ermöglicht, dass ausgehende Anrufe von einem beliebigen Anrufverarbeitungsknoten im Cluster stammen und dort empfangen werden. Bei Ausführung auf allen aktiven Unified CM-Knoten können Anrufe auch nicht zwischen Anrufverarbeitungsknoten innerhalb desselben Clusters eingerichtet werden, bevor sie über den ausgehenden SIP-Trunk eingerichtet werden.
Wie bei allen Unified CM-SIP-Trunks nehmen die dem Trunk zugeordneten SIP-Daemons eingehende Anrufe nur von Endsystemen mit IP-Adressen an, die in den Adressfeldern des Trunks definiert sind.
Wenn mehrere SIP-Trunks zu denselben Zielen dieselben Anrufverarbeitungsknoten verwenden, muss für jeden Trunk eine eindeutige Eingangs- und Zielportnummer definiert werden, damit jeder Trunk eindeutig identifiziert werden kann.
Auch wenn es sich nicht um eine spezielle SIP-Trunk-Funktion handelt, bietet die Ausführung von Routenlisten auf allen Knoten Vorteile für Trunks in Routenlisten und Routengruppen. Das Ausführen von Weiterleitungslisten auf allen Knoten verbessert die Verteilung ausgehender Anrufe, indem die Route Local-Regel verwendet wird, um unnötigen clusterinternen Anrufeinrichtungsverkehr zu vermeiden.
Für Routenlisten wird die Route Local-Regel wie folgt ausgeführt:
Bei ausgehenden Anrufen, die Routenlisten (und zugeordnete Routengruppen und Trunks) verwenden, überprüft Unified CM bei einem Anruf von einem registrierten Telefon oder einem eingehenden Trunk am Knoten mit der Routenlisteninstanz, ob eine Instanz des ausgewählten ausgehenden Trunks auf demselben Knoten wie die Routenliste vorhanden ist. In diesem Fall verwendet Unified CM diesen Knoten, um den ausgehenden Trunk-Anruf einzurichten.
Cisco empfiehlt nachdrücklich, Run auf allen aktiven Unified CM-Knoten auf allen Routenlisten und SIP-Trunks zu aktivieren.