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.
In diesem Dokument wird beschrieben, wie Sie einer vorhandenen CMS-Konferenz Teilnehmer für die Bereitstellung eines geclusterten CMS mit aktiviertem Lastenausgleich hinzufügen.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
In diesem Dokument wird davon ausgegangen, dass der Lastenausgleich bereits für Ihre geclusterten Callbridges (CB) konfiguriert ist und für direkte Anrufe an diese CMS-Server (direkte Anrufe an einen bestehenden CMS-Space) funktioniert. Dies bedeutet, dass diese Anforderungen bereits konfiguriert sind:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hinweis: Es gibt drei Hauptmethoden, um einer bestehenden CMS-Konferenz einen Teilnehmer hinzuzufügen: Fügen Sie einen Teilnehmer über API hinzu, fügen Sie einen Teilnehmer über Active Control hinzu, und fügen Sie einen Teilnehmer ohne Active Control hinzu.
1. Teilnehmer über API hinzufügen
Um diese Methode zu verwenden, muss LoadbalanceOutgoingCalls für die Callbridge-Gruppe aktiviert sein.
Um den Teilnehmer mithilfe dieser Methode hinzuzufügen, muss eine API-POST-Anforderung an /calls/<active-call-id>/participants/ gesendet werden. Die POST-Anforderung muss die Teilnehmer-ID des Teilnehmers, der der Konferenz hinzugefügt wird, als Wert des remoteParty-Parameters enthalten, der Teil dieser POST-Anforderung ist.
Diese POST-Anforderung weist das CMS an, einen ausgehenden Anruf beim hinzuzufügenden Teilnehmer zu tätigen. Wenn LoadbalanceOutgoingCalls für die Callbridge-Gruppe aktiviert ist und CMS den Lastgrenzwert erreicht hat, findet es einen freien CMS-Server im Cluster, um einen ausgehenden Anruf an den hinzugefügten Teilnehmer zu tätigen, und es wird ein verteilter Anruf zwischen den beiden Servern erstellt. Dies ist die gleiche Methode, mit der CMM Teilnehmer zu einer CMS-Konferenz hinzufügt.
2. Teilnehmer über Active Control hinzufügen
Um Active Control Teilnehmer hinzufügen zu können, muss Active Control zuerst zwischen dem CMS-Server und dem Benutzer, der den Teilnehmer hinzufügt, ausgehandelt werden.
Sie müssen Active Control auf dem SIP-Trunk-Profil aktivieren, das auf dem SIP-Trunk konfiguriert ist, der den CUCM mit dem CMS verbindet, um dies zu ermöglichen. Aktivieren Sie dazu den Parameter Allow IX-Anwendungsmedien, und beachten Sie, dass das Standard-SIP-Profil für TelePresence-Konferenzen standardmäßig aktiviert ist. Darüber hinaus muss LoadbalanceOutgoingCalls für die Callbridge-Gruppe aktiviert werden.
Wenn ein Teilnehmer über Active Control zu einer bestehenden CMS-Konferenz hinzugefügt wird, wird CMS1 vom Benutzer (über Active Control Message) angewiesen, einen ausgehenden Anruf an den neuen Teilnehmer zu tätigen. Wenn der für CMS1 konfigurierte Lastgrenzwert erreicht ist und der Benutzer versucht, einen neuen Teilnehmer mit aktiver Steuerung hinzuzufügen, zeigt CMS1 die folgende Fehlermeldung an (bis CMS-Version 2.9.1):
add participant "<participant-uri>" request failed: call bridge unavailable
Dies gilt für beide Anwendungsfälle - wenn der Teilnehmer zu einer Ad-hoc-Konferenz hinzugefügt wird und wenn er einem vorhandenen CMS-Raum über eine aktive Steuerung hinzugefügt wird.
Dies ist ein fehlerhaftes Verhalten und es wird unter dem Defekt verfolgt: CSCvu72374
3. Fügen Sie einen Teilnehmer ohne aktive Kontrolle hinzu.
Wenn ein Teilnehmer hinzugefügt wird, ohne eine aktive Steuerung zu verwenden (daher IX-Anwendungsmedien im SIP-Profil nicht aktiviert zulassen), führt CUCM einen Anruf zwischen dem Benutzer, der die Aktion initiiert, und dem neuen Teilnehmer aus. Wenn der Benutzer bereit ist, dem neuen Teilnehmer der Konferenz beizutreten, führt der CUCM einen ausgehenden Anruf an die Ad-hoc-Konferenz aus, die auf CMS1 ausgeführt wird. Wenn der Lastgrenzwert für CMS1 erreicht ist, kann der Teilnehmer nicht hinzugefügt werden, und CMS1 zeigt diese Fehlermeldung an (Beispiel: 55):
call 55: ending; local teardown, system participant limit reached - not connected after 0:00
Diese Fehlermeldung ist eine normale Fehlermeldung, die von einem CMS-Server ausgegeben wird, wenn ein eingehender Anruf eingeht und die maximale Last erreicht ist. Anschließend kann der Anrufsteuerungsserver (CUCM oder VCS) den Anruf an andere Mitglieder im Cluster weiterleiten. Im Fall einer Ad-hoc-Konferenz funktioniert dies jedoch nicht, und es ist auch nicht möglich, da der CUCM keine Routenliste für Ad-hoc-Konferenzen besitzt.
Dieses Dokument enthält die erforderlichen Konfigurationsschritte für die dritte Methode zum Hinzufügen von Teilnehmern zu einer vorhandenen Konferenz (Hinzufügen von Teilnehmern ohne Active Control).
Bei den Konfigurationsschritten in diesem Dokument wird folgendes Verhalten behandelt:
1. Der Benutzer erstellt eine Ad-hoc-Konferenz, diese wird vom CMS1-Server gehostet.
2. Nach Einrichtung der Ad-hoc-Konferenz erreicht CMS1 allmählich den konfigurierten Lastgrenzwert (konfiguriert über API bei/System/Konfiguration/Cluster)
3. Der Benutzer versucht, der aktuellen Ad-hoc-Konferenz einen neuen Teilnehmer hinzuzufügen. Der neue Benutzer wird jedoch nicht mit der Konferenz verbunden.
Hinweis: Mit diesem Konfigurationsverfahren kann ein Benutzer einer vorhandenen CMS-Adhoc-Konferenz Teilnehmer hinzufügen, auch wenn der CMS-Server, auf dem die Adhoc-Konferenz stattfindet, seine Belastungsgrenze erreicht hat. Er kann verwendet werden, bis der Fehler der aktiven Steuerung behoben ist. Active Control wird in dieser Ad-hoc-Konferenz deaktiviert.
Schritt 1: Erstellen eines neuen SIP-Trunk-Sicherheitsprofils für Trunk1
Schritt 2: Erstellen eines neuen SIP-Trunk-Sicherheitsprofils für Trunk2
Schritt 3: Erstellen eines neuen SIP-Normalisierungsskripts
M = {} function M.outbound_INVITE(msg) msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>") end return M
Schritt 4: Erstellen eines neuen SIP-Profils
Schritt 5: Erstellen einer neuen Partition
Schritt 6: Erstellen eines neuen Calling Search Space (CSS):
Schritt 7: Erstellen Sie einen neuen SIP-Trunk, Trunk1:
Device Name (Gerätename) | Geben Sie einen Namen für den SIP-Trunk Trunk1 ein. |
Auf allen aktiven Unified CM-Knoten ausführen | Aktiviert |
Zieladresse | Geben Sie die IP-Adresse des CUCM-Servers ein, z. B. 10.48.36.50 |
Zielport | Geben Sie den Port ein, auf dem Trunk2 zuhört, 5041 |
SIP-Trunk-Sicherheitsprofil | Wählen Sie das in Schritt 1 erstellte Profil aus: Trunk1 nicht sicher empfängt auf 5040 |
SIP Profile (SIP-Profil) | Wählen Sie das Profil aus, das in Schritt 4 erstellt wurde: No active control telepresence conferencing (Keine aktive Telepresence-Konferenz). |
DTMF-Signalisierungsverfahren | RFC 2833 auswählen |
SIP-Normalisierungsskript |
Wählen Sie das in Schritt 3 erstellte Skript remove_conference_from_call_info_header aus. |
Schritt 8: Erstellen Sie einen neuen SIP-Trunk, Trunk2:
Device Name (Gerätename) | Geben Sie einen Namen für den SIP-Trunk ein: Trunk2 |
Auf allen aktiven Unified CM-Knoten ausführen | Aktiviert |
Calling Search Space | Wählen Sie den in Schritt 6 erstellten CSS aus: CMS_adhoc_numbers |
Zieladresse | Geben Sie die IP-Adresse oder den FQDN des CUCM-Servers ein, z. B. 10.48.36.50 |
Zielport | Geben Sie den Port ein, auf dem Trunk1 zuhört, 5040 |
SIP-Trunk-Sicherheitsprofil | Wählen Sie das in Schritt 2 erstellte Profil aus: Trunk2 (nicht sicher) empfängt auf 5041 |
SIP Profile (SIP-Profil) | Wählen Sie das Profil aus, das in Schritt 4 erstellt wurde: No active control telepresence conferencing (Keine aktive Telepresence-Konferenz). |
DTMF-Signalisierungsverfahren | RFC 2833 auswählen |
SIP-Normalisierungsskript |
Vorhandenes Normalisierungsskript auswählen cisco-meeting-server-interop |
Schritt 9: Erstellen eines neuen Routenmusters
Schritt 10: Ändern der CMS-Ad-hoc-Konferenzbrücken-Konfiguration
Schritt 11: Zurücksetzen der SIP-Trunks Trunk1 und Trunk2
Schritt 12: CMS-Adhoc-Server zurücksetzen
Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.
Sie können das Analysetool für Collaboration-Lösungen zur Protokollanalyse verwenden.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
17-Jun-2020 |
Erstveröffentlichung |