Leitfaden für ein reibungsloses Upgrade von Cisco Meeting Server 2.9 auf 3.0 (und höher)

Einleitung

In diesem Dokument werden die Herausforderungen bei der Aktualisierung einer Cisco Meeting Server-Bereitstellung mit Version 2.9 (oder früher) auf 3.0 (oder höher) beschrieben. Außerdem wird erläutert, wie diese Herausforderungen im Hinblick auf einen reibungslosen Upgrade-Prozess bewältigt werden können.

Funktionen entfernt: XMPP wurde entfernt (wirkt sich auf WebRTC aus), Trunks/Load Balancer, Webbridge

Neue Funktionen: Rekorder und Streamer sind jetzt SIP, und webbridge wird durch webbridge3 ersetzt

In diesem Dokument werden nur Themen behandelt, die Sie vor dem Upgrade berücksichtigen müssen. Sie deckt nicht alle neuen Funktionen ab, die in 3.x verfügbar sind.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• CMS Administration
• CMS-Upgrades
• Erstellung und Signierung von Zertifikaten

Alles, was hier erwähnt wird, ist in verschiedenen Dokumenten beschrieben.  Es ist immer ratsam, die Produktveröffentlichungshinweise zu lesen und sich in unseren Programmierhandbüchern und Bereitstellungsleitfäden zu informieren, wenn Sie weitere Informationen zu den Funktionen benötigen: CMS Installations- und Konfigurationsleitfäden und CMS Produktveröffentlichungshinweise .

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco Meeting Server.

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.

Hintergrundinformationen

Dieses Dokument dient als Leitfaden für den Fall, dass Sie bereits über eine CMS 2.9.x-Bereitstellung (oder eine frühere Version) verfügen, unabhängig davon, ob es sich um eine kombinierte oder ausfallsichere Bereitstellung handelt und Sie ein Upgrade auf CMS 3.0 planen.  Die Informationen in diesem Dokument beziehen sich auf alle CMS-Modelle.  

Hinweis: Für die X-Serie ist kein Upgrade auf CMS 3.0 möglich. Sie müssen so schnell wie möglich Ihre Server der X-Serie austauschen.

Wichtige Informationen zu Upgrades

Das Upgrade von CMS kann nur schrittweise erfolgen.  Zum Zeitpunkt der Erstellung dieses Dokuments wurde CMS 3.5 veröffentlicht.  Wenn Sie auf CMS 2.9 sind, müssen Sie ein schrittweises Upgrade durchführen (2.9 —> 3.0 —> 3.1 —> 3.2 —> 3.3 —> 3.4 —> 3.5 (Der Aktualisierungsprozess für Notizen hat Änderungen gegenüber CMS 3.5, lesen Sie daher die Versionshinweise sorgfältig durch!!)

Wenn Sie kein schrittweises Upgrade durchführen und ungewöhnliches Verhalten feststellen, kann das TAC ein Downgrade und einen Neustart von Ihnen verlangen.

Ab CMS 3.4 MUSS CMS außerdem Smart Licensing verwenden.  Sie können kein Upgrade auf CMS 3.4 oder höher durchführen und weiterhin herkömmliche Lizenzen verwenden.  Führen Sie kein Upgrade auf CMS 3.4 oder höher durch, es sei denn, Sie haben Smart Licensing eingerichtet.

Zusammenfassung der zu berücksichtigenden Aspekte

Navigieren Sie mithilfe dieser Fragen zu den Abschnitten, die sich auf Ihre eigene Situation beziehen.  Jede Überlegung bezieht sich auf einen Hyperlink zu einer detaillierteren Beschreibung in diesem Dokument.

Lizenzen

Verfügen Sie vor dem Upgrade über ausreichend Personal MultiParty (PMP)-/Shared MultiParty (SMP)-Lizenzen auf Ihren Servern?

In Version 3.0 werden die PMP-Lizenzen zugewiesen, auch wenn der Benutzer nicht angemeldet ist. Wenn Sie beispielsweise 10000 Benutzer über LDAP importiert haben, aber nur über 100 PMP-Lizenzen verfügen, wird die Compliance dadurch beeinträchtigt, sobald Sie ein Upgrade auf 3.0 durchführen.  Überprüfen Sie in diesem Anwendungsfall auf jeden Fall, ob Tenants mit userProfile und/oder System/Profilen festlegt, ob userProfile mit hasLicense mit dem Wert true festgelegt ist.

In diesem Abschnitt wird detaillierter beschrieben, wie Sie das Benutzerprofil auf der API überprüfen und feststellen, ob hasLicense=true set (d. h. lizenzierte PMP-Benutzer) vorhanden ist. 

Verfügen Sie über PMP/SMP-Lizenzen in Ihrer aktuellen Datei "cms.lic"?

Aufgrund eines geänderten Lizenzverhaltens ab Version 3.0 müssen Sie vor der Durchführung des Upgrades bestätigen, ob Sie über genügend PMP/SMP-Lizenzen verfügen. Dies wird in diesem Abschnitt ausführlicher beschrieben.

Ist Cisco Meeting Manager (CMM) bei Ihnen im Einsatz?

CMS 3.0 erfordert CMM 3.0 aufgrund von Änderungen im Umgang mit Lizenzen. Es wird empfohlen, CMM 2.9 bereitzustellen, bevor Sie ein Upgrade Ihrer Umgebung auf 3.0 durchführen, da Sie Ihren 90-Tage-Bericht zur Lizenznutzung für die letzten 90 Tage überprüfen können. Dies wird in diesem Abschnitt ausführlicher beschrieben.

Nutzen Sie Smart Licensing?

CMS 3.0 erfordert CMM 3.0 aufgrund von Änderungen im Umgang mit Lizenzen. Wenn Sie Smart Licensing bereits über CMM verwenden, stellen Sie sicher, dass Ihrem Cluster PMP- und SMP-Lizenzen zugeordnet sind.

Webbridge (WebRTC und CMA-Client)

Verwenden Sie WebRTC in CMS 2.9?

Webbridge hat sich in CMS 3.0 deutlich verändert.  Für Hinweise zur Migration von webbridge2 zu webbridge3 und zur Verwendung der Web-App finden Sie die Informationen in diesem Abschnitt.

Verwenden Ihre Benutzer den CMA-Thick-Client?

Da diese Clients auf XMPP basieren, können diese Clients nach dem Upgrade nicht mehr verwendet werden, da der XMPP-Server entfernt wurde. Wenn dies auf Ihren Anwendungsfall zutrifft, finden Sie weitere Informationen in diesem Abschnitt.

Verwenden Sie Chat in WebRTC?

Die Chat-Funktion wurde in Version 3.0 aus der Web-App entfernt. In CMS 3.2 wird der Chat wieder eingeführt, er ist jedoch nicht persistent.  Weitere Informationen zu dieser Funktion finden Sie in diesem Abschnitt.

Führen Ihre Benutzer Point-to-Point-Anrufe von WebRTC an Geräte durch?

In CMS 3.0 kann ein Web-App-Benutzer nicht mehr direkt ein anderes Gerät anwählen. Jetzt müssen Sie einem Meeting-Bereich beitreten und die Berechtigung haben, dem Meeting Teilnehmer hinzuzufügen, die die gleiche Aktion ausführen.  Weitere Informationen zu diesem Teil finden Sie in diesem Abschnitt.

Erstellen Ihre Benutzer ihre eigenen CoSpaces über WebRTC?

In Version 3.0 muss eine coSpaceTemplate in API erstellt und dem Benutzer zugewiesen werden, damit Web-App-Benutzer ihre eigenen Bereiche vom Client erstellen können. Dies kann manuell oder automatisch während des LDAP-Imports erfolgen.  CanCreateCoSpaces wird aus UserProfile entfernt.  Weitere Informationen zu dieser Funktion finden Sie in diesem Abschnitt.

Änderungen an der Web-Benutzeroberfläche

Sind die WebBridge-Einstellungen in der Web-Admin-GUI konfiguriert?

Die WebBridge-Einstellungen werden in 3.0 aus der GUI entfernt. Sie müssen daher die WebBridges in der API konfigurieren und sich die aktuellen Einstellungen in der GUI notieren, damit Sie die WebBridgeProfiles in der API entsprechend konfigurieren können.  Weitere Informationen zu dieser Änderung finden Sie in diesem Abschnitt.

Haben Sie in der grafischen Benutzeroberfläche für den Webadministrator externe Einstellungen konfiguriert?

Die externen Einstellungen wurden in CMS 3.1 aus der GUI entfernt.  Wenn Sie entweder Webbridge URL oder IVR in Ihrem CMS 3.0 oder einer älteren Web-Admin-GUI (Konfiguration —> Allgemein —> Externe Einstellungen) konfiguriert haben, wurden diese von der Webseite entfernt und müssen nun in der API konfiguriert werden. Die vorherigen Einstellungen vor dem Upgrade auf 3.1 werden NICHT zur API hinzugefügt und müssen manuell vorgenommen werden.  Weitere Informationen zu dieser Änderung finden Sie in diesem Abschnitt.

Rekorder/Streamer

Verwenden Sie derzeit einen oder mehrere CMS-Recorder und/oder Streamer?

Die CMS Recorder- und Streamer-Komponente ist jetzt SIP- statt XMPP-basiert. Wenn XMPP entfernt wird, müssen diese daher nach dem Upgrade angepasst werden. Weitere Informationen zu dieser Änderung finden Sie in diesem Abschnitt.

Überlegungen zu Cisco Expressway

Welche ist Ihre aktuelle Cisco Expressway-Version, wenn Sie Expressway als Proxy für WebRTC verwenden? 

CMS 3.0 erfordert Expressway 12.6 oder neuer.  Weitere Informationen zu dieser WebRTC-Proxy-Funktion finden Sie in diesem Abschnitt.

CMS-Edge

Verfügen Sie derzeit über einen CMS Edge in Ihrer Umgebung?

CMS Edge wird in CMS 3.1 wieder eingeführt und bietet eine höhere Skalierbarkeit für externe Verbindungen.  Weitere Informationen zu diesem Teil finden Sie in diesem Abschnitt.

CMS X-Serie (Acano)

Verfügen Sie derzeit über Server der x-Serie in Ihrer Umgebung? 

Diese Server können nicht auf CMS 3.0 aufgerüstet werden, und Sie müssen diese bald ersetzen (vor dem Upgrade auf 3.0 auf eine virtuelle Maschine oder eine CMS-Appliance umstellen). Den End-of-Life-Hinweis zu diesen Servern finden Sie unter diesem Link.

SIP-Edge

Verwenden Sie derzeit SIP Edge in Ihrer Umgebung?

Sip Edge ist seit CMS 3.0 vollständig veraltet.  Sie müssen Cisco Expressway verwenden, um SIP-Anrufe in Ihr CMS zu integrieren. Wenden Sie sich an Ihren Cisco Kundenbetreuer, um mehr über die Nutzung von Expressways für Ihre Organisation zu erfahren.

Weitere Informationen

Lizenzierung - Lizenzen vor dem Upgrade überprüfen

Der Status einer nicht konformen Lizenz ist das schwerwiegendste Problem, wenn Sie von einer Version 2.x auf Version 3.0 oder höher aktualisieren. In diesem Abschnitt wird beschrieben, wie Sie die Anzahl der PMP/SMP-Lizenzen bestimmen, die Sie für ein reibungsloses Upgrade benötigen.

Bevor Sie Ihre Bereitstellung auf 3.0 aktualisieren, stellen Sie CMM 2.9 bereit, und überprüfen Sie den 90-Tage-Bericht unter der Registerkarte "Lizenzen", um festzustellen, ob die Lizenznutzung unter dem aktuell zugewiesenen Lizenzbetrag auf den CMS-Knoten geblieben ist:

Wenn Sie die herkömmliche Lizenzierung verwenden (die Datei cms.lic wird lokal auf Ihren CMS-Knoten installiert), überprüfen Sie in der CMS-Lizenzdatei die Anzahl der persönlichen und gemeinsam genutzten Lizenzen (100/100 wie hier abgebildet) auf jedem der CMS-Knoten (über WinSCP von jedem callBridge-Knoten herunterladen).

Wenn Sie bereits Smart Licensing verwenden, überprüfen Sie, wie viele PMP/SMP-Lizenzen den CMS-Servern im Cisco Software Smart Portal zugewiesen sind.

Öffnen Sie den 90-Tage-Bericht (Zip-Datei heißt license-data.zip) und die Datei daily-peaks.csv.

Sortieren Sie in Excel die PMP-Spalte nach Z bis A, um die höheren Werte nach oben zu erhalten, und führen Sie dann die gleichen Werte für die SMP-Spalte aus.  Sind die in dieser Datei angezeigten Werte niedriger als die in der CMS-Lizenzdatei verfügbaren Lizenzen? Wenn ja, dann sind Sie in Ordnung und vollständig in Übereinstimmung. Wenn dies nicht der Fall ist, werden Warnungen und/oder Fehler generiert, wie in Abbildung 6 in Abschnitt 1.7.3 des CMS-Bereitstellungsleitfadens angegeben, zu denen Sie weitere Informationen finden können, wie auch in Abschnitt 1.7.4 beschrieben.

Wie im Beispiel-Image gezeigt, wurden in den letzten 90 Tagen 2,1667 SMP-Lizenzen verwendet, während PMP-Lizenzen nicht zu Spitzenzeiten vergeben wurden. In der Datei "cms.lic" wurden 100 Einheiten jedes Lizenztyps angegeben, sodass diese Konfiguration vollständig konform ist. Daher gibt es keine Lizenzprobleme, wenn dieses Setup auf CMS 3.0 aktualisiert wird. Es kann jedoch weiterhin ein Problem auftreten, wenn bei der Einrichtung 10.000 Benutzer über LDAP importiert wurden. Wie damals haben Sie nur 100 PMP-Lizenzen, aber Sie weisen 10000 zu (wobei "userProfile" mit "hasLicense" auf "True" gesetzt ist). In diesem Fall sind Sie nicht konform, sobald Sie ein Upgrade auf 3.0 durchführen. Weitere Informationen hierzu finden Sie im nächsten Abschnitt.

Bestimmen Sie, wie vielen Benutzern nach dem Upgrade eine PMP-Lizenz zugewiesen wird.

Allen Benutzern, die importiert werden und ein userProfile mit hasLicense=true verwenden, wird in CMS 3.0 automatisch eine PMP-Lizenz zugewiesen. 

Überprüfen Sie in der API, wie viele Benutzerprofile vorhanden sind, und prüfen Sie, ob einer dieser Profile den Satz "hasLicense=true" aufweist.  Wenn dies der Fall ist, müssen Sie überprüfen, wo diese userProfiles zugewiesen sind. 

Die Benutzerprofile können auf einer der folgenden Ebenen zugewiesen werden:

1. LDAP-Quellen
2. Tenants
3. System/Profile

Überprüfen Sie alle 3 Speicherorte auf zugewiesene Benutzerprofile, die über License=true verfügen.

1. LDAP-Quellen/Tenants

Für jede ldapSource, die einen Tenant oder ein userProfile verwendet, wird Benutzern, die mit dieser ldapSource importiert werden, eine PMP-Lizenz zugewiesen, wenn der Parameter hasLicense auf True festgelegt ist.  Wenn ein Tenant vorhanden ist, müssen Sie auf die Tenant-ID klicken, um festzustellen, ob ihm ein userProfile zugewiesen ist, und dann überprüfen, ob dieses userProfile mit 'hasLicense=true' konfiguriert ist.  Wenn es keinen Tenant gibt, aber ein userProfile-Satz vorhanden ist, klicken Sie darauf, um zu sehen, ob es 'hasLicense=true' enthält.  Wenn eine der beiden Methoden 'hasLicense=true' hat, können Sie überprüfen, wie viele Benutzer importiert wurden, indem Sie eine GET-Funktion für 'api/v1/users' und eine Filterung für die Domäne ausführen, die für die jidMapping-Funktion auf der ldapmapping verwendet wird, die der ldapSource zugeordnet ist.

Hinweis: Dies kann in anderen Situationen komplexer sein. In diesem Fall müssen Sie dies mit den von Ihnen erstellten Active Directory-Zuordnungen und -Filtern überprüfen.

Schritt 1: Suchen Sie die Zuordnungs-ID aus der ldapSource.

Schritt 2: Suchen Sie ldapMappings um jidMapping zu finden.

Schritt 3: Suchen Sie in api/v1/users nach der Domain, die in der jidMapping verwendet wird.

Schritt 4: Addieren Sie die Benutzer, die von jeder ldapSource gefunden wurden.  Dies ist die Anzahl der LDAP-importierten Benutzer, die PMP-Lizenzen benötigen. 

2. System/Profile

Wenn ein userProfile auf System-/Profilebene festgelegt ist und userProfile den Wert "hasLicense=true" aufweist, wird jedem in CMS importierten Benutzer beim Upgrade des Servers eine PMP-Lizenz zugewiesen.  Wenn Sie 10.000 Benutzer importiert haben, aber nur 100 PMPs haben, führt dies dazu, dass Sie bei einem Upgrade auf CMS 3.0 die Compliance nicht mehr erfüllen und eine 30-Sekunden-Bildschirmmeldung und Audio-Eingabeaufforderung zu Beginn der Anrufe angezeigt werden.  

Wenn das Benutzerprofil auf Systemebene angibt, dass Benutzer einen PMP erhalten sollen, rufen Sie api/v1/users auf, um zu sehen, wie viele Benutzer es insgesamt gibt:

Wenn Sie zuvor alle Benutzer aus Ihrem LDAP importiert haben, aber jetzt feststellen, dass Sie nur eine bestimmte Teilmenge aus dieser Liste benötigen, erstellen Sie einen besseren Filter in Ihrem LDAP-Quellcode, sodass nur die Benutzer importiert werden, denen Sie PMP-Lizenzen zuweisen möchten. Überprüfen Sie Ihren Filter auf ldapSource und führen Sie dann eine neue LDAP-Synchronisierung in api/v1/ldapsync durch.  Dies führt dazu, dass nur die gewünschten Benutzer importiert und alle anderen aus diesem vorherigen Import entfernt werden. 

Hinweis: Wenn Sie dies richtig machen und der neue Import nur unerwünschte Benutzer entfernt, verbleibende Benutzer coSpace CallIDs und Geheimnisse nicht ändern, aber wenn Sie einen Fehler machen, kann dies dazu führen, dass alle callIDs und Geheimnisse ändern.  Erstellen Sie eine Sicherung Ihrer Datenbankknoten, bevor Sie dies versuchen, wenn Sie sich darum sorgen!

Verfügen Sie über ausreichend SMP-Lizenzen?

Wenn Sie Ihre täglichen Spitzenwerte aus dem CMM 90 Day Report betrachtet haben, haben Sie bereits genug SMP-Lizenzen, um Ihre Spitzenwerte abzudecken?  SMP-Lizenzen werden verwendet, wenn dem Meeting-Veranstalter keine PMP-Lizenz zugewiesen wurde (entweder als CoSpace-Veranstalter/Ad-hoc-Meeting/TMS-geplantes Meeting).  Wenn Sie absichtlich SMP verwenden und genug haben, um Ihre Spitzenzeiten abzudecken, dann ist das alles in Ordnung. Wenn Sie den 90-Tage-Gipfel für SMP überprüfen und es unklar ist, warum diese verbraucht werden, sind hier einige Dinge zu überprüfen.

1. Ad-hoc-Anrufe (von CUCM eskaliert) verwenden eine SMP-Lizenz, wenn das zum Zusammenführen verwendete Gerät nicht einem Benutzer zugeordnet ist, dem in CMS über das Benutzerprofil eine PMP-Lizenz zugewiesen wurde.  CUCM stellt die GUID des Benutzers bereit, der das Meeting eskaliert.  Wenn diese GUID einem von Meeting Server importierten LDAP-Benutzer mit zugewiesener PMP-Lizenz entspricht, wird die Lizenz dieses Benutzers verwendet.

2. Wenn einem CoSpace-Besitzer keine PMP-Lizenz zugewiesen wurde, verwenden Anrufe an diese CoSpaces eine SMP-Lizenz.

3. Wenn das Meeting in TMS-Version 15.6 oder höher geplant wurde, wird der Meeting-Veranstalter an das CMS gesendet. Wenn diesem Benutzer keine PMP-Lizenz zugewiesen wurde, verwendet dieses Meeting eine SMP-Lizenz.

Konfigurieren von CMM

Ab CMS 3.0 wird CMM 3.0 benötigt, damit CMS ordnungsgemäß funktioniert.  CMM ist für die Lizenzierung von CMS verantwortlich. Wenn Sie also ein Upgrade von CMS auf 3.0 planen, benötigen Sie einen CMM-Server.  Es wird empfohlen, CMM 2.9 in CMS 2.9 bereitzustellen, damit Sie vor dem Upgrade Ihre Lizenznutzung überprüfen können.

CMM überprüft alle hinzugefügten CallBridges auf SMP- und PMP-Lizenzen sowie auf die CallBridge-Lizenz.  Dabei wird die Nummer verwendet, die auf den verschiedenen Geräten im Cluster am höchsten ist. 

Wenn z. B. CMS1 über 20 PMP- und 10 SMP-Lizenzen verfügt und CMS2 über 40 PMP- und 5 SMP-Lizenzen in herkömmlicher Lizenzierung verfügt, meldet das CMM, dass Sie 40 PMP- und 10 SMP-Lizenzen verwenden müssen.

Wenn Sie mehr PMP-Lizenzen als importierte Benutzer besitzen, haben Sie keine Probleme im Zusammenhang mit PMP- (oder SMP-) Lizenzen. Wenn Sie jedoch diesen 90-Tage-Peak überprüfen und feststellen, dass Sie mehr als verfügbar verwendet haben, können Sie dennoch auf CMS 3.0 aktualisieren und die 90-Tage-Testlizenz auf CMM verwenden, um die Dinge mit Ihrer Lizenz zu regeln, oder vor dem Upgrade Maßnahmen ergreifen.

Konfigurieren von Webbridge (WebRTC und CMA-Client)

CMS 3.0 entfernt die XMPP-Serverkomponente und damit WebBridge und die Möglichkeit, den CMA-Thick-Client zu verwenden.  WebBridge3 wird heute verwendet, um Web-App-Benutzer (ehemals WebRTC-Benutzer) über den Browser mit Meetings zu verbinden.  Wenn Sie ein Upgrade auf 3.0 durchführen, müssen Sie webbridge3 konfigurieren. 

Hinweis: CMA-Thick-Client funktioniert nach dem Upgrade auf CMS 3.0 nicht!

In diesem Video erfahren Sie, wie Sie die webbridge 3-Zertifikate erstellen.

https://video.cisco.com/detail/video/6232772471001?autoStart=true&q=cms

Vor dem Upgrade auf Version 3.0 müssen Kunden die Konfiguration von Webbridge3 genau planen. Die wichtigsten Schritte sind hier hervorgehoben.

1. Sie benötigen einen Schlüssel und eine Zertifikatskette für webbridge3.  Das alte Webbridge-Zertifikat kann verwendet werden, wenn das Zertifikat alle FQDNs oder IP-Adressen des CMS-Servers als Subject Alternative Name (SAN)/Common Name (CN) enthält, auf denen webbridge3 ausgeführt wird, und wenn eine der folgenden Bedingungen erfüllt ist:

a. Das Zertifikat weist keine erweiterte Schlüsselverwendung auf (d. h. es kann entweder als Client oder Server verwendet werden).

b. Das Zertifikat weist sowohl Client- als auch Serverauthentifizierung auf.  Das HTTP-Zertifikat benötigt nur die Serverauthentifizierung, während das C2W-Zertifikat sowohl den Server als auch den Client erfordert.)

2. Wenn Sie ein neues Zertifikat für das "webbridge3 https"-Zertifikat erstellen möchten, wird empfohlen, es öffentlich zu signieren (um Zertifikatswarnungen auf dem Client bei Verwendung der Web-App zu vermeiden).  Das gleiche Zertifikat kann für das "webbridge3 c2w-Zertifikat" verwendet werden, und das Zertifikat muss über den FQDN der Webbridge-Server im SAN/CN verfügen.

3. CallBridges müssen mit der neuen webbridge3 über einen Port kommunizieren, der im Befehl webbridge3 c2w listen konfiguriert ist. Dies kann ein beliebiger verfügbarer Port sein, z. B. 449. Benutzer müssen sicherstellen, dass die Callbridges mit webbridge3 an diesem Port kommunizieren können und dass bei Bedarf Änderungen an der Firewall im Voraus vorgenommen werden.  Es kann sich nicht um denselben Port handeln, den "webbridge https" zum Abhören verwendet.

Vor dem CMS-Upgrade auf Version 3.0 wird empfohlen, ein Backup mit 'backup snapshot <servername_date>' durchzuführen und sich dann bei der webadmin-Seite auf Ihren callbridge-Knoten anzumelden, um alle XMPP-Einstellungen und Webbridge-Einstellungen zu entfernen.  Stellen Sie dann eine Verbindung mit dem MMP auf Ihren Servern her, und führen Sie diese Schritte auf allen Core-Servern aus, die über xmpp und webbridge über eine SSH-Verbindung verfügen:

1. xmpp deaktivieren
2. xmpp zurücksetzen
3. xmpp certs none
4. XMPP-Domäne keine
5. Webbridge deaktivieren
6. Webbridge, keine Überwachung
7. Webbridge-Zertifikate keine
8. Webbridge-Vertrauenswürdigkeit keine

Sobald Sie ein Upgrade auf 3.0 durchgeführt haben, beginnen Sie mit der Konfiguration von webbridge3 auf allen Servern, auf denen zuvor webbridge ausgeführt wurde.  Sie müssen dies tun, da es bereits DNS-Einträge gibt, die auf diese Server verweisen. Auf diese Weise stellen Sie sicher, dass ein Benutzer, der an eine webbridge3 gesendet wird, bereit ist, die Anfrage zu bearbeiten.

Webbridge3-Konfiguration (über alle SSH-Verbindungen)

Schritt 1: Konfigurieren Sie den HTTP-Überwachungsport webbridge3.

Webbridge3 HTTPS-Übertragung:443

Schritt 2: Konfigurieren Sie Zertifikate für webbridge3 für Browser-Verbindungen.  Dieses Zertifikat wird an Browser gesendet und muss von einer öffentlichen Zertifizierungsstelle signiert werden. Es enthält den FQDN, der im Browser verwendet wird, damit der Browser der Verbindung vertrauen kann.

Webbridge3 https certs wb3.key wb3trust.cer (Hierbei muss es sich um eine Vertrauenskette handeln: Erstellen Sie ein Vertrauenszertifikat, das die End-Entity im Vordergrund hat, gefolgt von den zwischengeschalteten CAs in der Reihenfolge, und schließen Sie mit RootCA ab).

Schritt 3: Konfigurieren Sie den Port so, dass er auf CallBridge-to-Webbridge (c2w)-Verbindungen wartet.  Da 443 für den Webbridge3 HTTPS-Listen-Port verwendet wird, muss diese Konfiguration ein anderer, verfügbarer Port sein, z. B. 449.

Webbridge3 c2w abhören:449

4. Konfigurieren Sie Zertifikate, die Webbridge an callbridge für die c2w-Vertrauensstellung sendet.

Webbridge3 c2w-Zertifikate wb3.key wb3trust.cer

5. Konfigurieren Sie den Vertrauensspeicher, den WB3 verwendet, um dem callBridge-Zertifikat zu vertrauen.  Dies muss mit dem Zertifikat übereinstimmen, das für das Callbridge-CA-Paket verwendet wird (und muss ein Paket von Zwischenzertifikaten darüber und eine Root-CA am Ende gefolgt von einem einzelnen Wagenrücklauf sein).

Webbridge3 c2w - Vertrauen auf rootca.cer

6. Aktivieren Sie webbridge3

WebBridge3 aktivieren

CallBridge-Konfigurationsänderungen (über alle SSH-Verbindungen)

Schritt 1: Konfigurieren Sie die callBridge-Vertrauensstellung mit dem Zertifizierungsstellenzertifikat/Bündel, das das webbridge3 c2w-Zertifikat signiert hat.

Callbridge trust c2w rootca.cer

Schritt 2: Starten Sie callBridge neu, um die neue Vertrauensstellung zu aktivieren.  Dadurch werden alle Anrufe für diese spezielle callBridge-Klasse fallen gelassen. Verwenden Sie diese daher mit Vorsicht.

Callbridge-Neustart

API-Konfiguration für CallBridges zur Verbindung mit WebBridge3

1. Erstellen Sie ein neues WebBridge-Objekt mithilfe von POST in der API, und geben Sie ihm einen URL-Wert mithilfe von FQDN und einem auf der Webbridge c2w-Schnittstelle konfigurierten Port (Whitelist) (Schritt 3 in der Webbridge3-Konfiguration).

c2w://webbridge.darmckin.local:449

An diesem Punkt funktioniert Webbridge3 wieder, und Sie können Leerzeichen als Gast beitreten, oder wenn Sie zuvor Benutzer importiert haben, müssen diese sich anmelden können.

Berechtigungen zur Erstellung von Speicherplatz für Web-Anwendungen

Sind Ihre Benutzer es gewohnt, eigene Spaces in WebRTC erstellen zu können?  Ab CMS 3.0 können Web-App-Benutzer keine eigenen CoSpaces erstellen, es sei denn, ihnen wurde eine CoSpace-Vorlage zugewiesen, die dies ermöglicht.

Selbst wenn eine coSpaceTemplate zugewiesen ist, wird dadurch kein Raum geschaffen, in den sich andere einwählen können (kein URI, keine Anruf-ID oder kein Passcode). Wenn der coSpace jedoch ein callLegProfile mit "addParticipantAllowed" hat, können sie sich aus dem Raum heraus einwählen.

Damit Wählzeichenfolgen zum Aufrufen in den neuen Space verwendet werden können, muss coSpaceTemplate über eine accessMethodTemplate-Konfiguration verfügen (siehe 2.9 Release Notes - https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-2-9/Cisco-Meeting-Server-Release-Notes-2-9-6.pdf).

Erstellen Sie in der API coSpaceTemplate(s), und erstellen Sie dann accessMethodTemplate(s), und weisen Sie die coSpaceTemplate den ldapUserCoSpaceTemplateSources zu. Alternativ können Sie einem Benutzer in api/v1/users manuell eine coSpaceTemplate zuweisen.

Sie können mehrere CoSpace-Vorlagen und accessMethodsTemplates erstellen und zuweisen.  Weitere Informationen finden Sie im CMS API-Leitfaden (https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-programming-reference-guides-list.html)

CoSpaceTemplate (API-Konfiguration)

Name: Ein beliebiger Name, den Sie der CoSpaceTemplate zuweisen möchten.

Beschreibung: Kurzbeschreibung (falls gewünscht)

callProfile: White callProfile Möchten Sie mit dieser Vorlage erstellte Leerzeichen verwenden? Wird diese Angabe nicht gemacht, wird die auf System-/Profilebene eingestellte Konfiguration verwendet.

calllegProfile: Welches calllegProfile soll mit dieser Vorlage erstellte Leerzeichen verwenden?  Wird diese Angabe nicht gemacht, wird die auf System-/Profilebene eingestellte Konfiguration verwendet.

dialInSecurityProfile: Welches dialInSecurityProfile soll mit dieser Vorlage erstellte Leerzeichen verwenden? Wird diese Angabe nicht gemacht, wird die auf System-/Profilebene eingestellte Konfiguration verwendet.

AccessMethodTemplate (API-Konfiguration)

Name: Ein beliebiger Name, den Sie der CoSpaceTemplate zuweisen möchten.

uriGenerator: Der Ausdruck, der zum Generieren von URI-Werten für diese Zugriffsmethodenvorlage verwendet werden soll. Die zulässigen Zeichen sind 'a' bis 'z', 'A' bis 'Z', '0' bis '9', '.', '-', '_' und '$'. Wenn kein leeres Zeichen vorhanden ist, muss es genau ein '$'-Zeichen enthalten.  Ein Beispiel hierfür ist $.space, das den vom Benutzer beim Erstellen des Leerzeichens angegebenen Namen verwendet und ".space" daran anhängt. "Team Meeting" erstellt die URL "Team.Meeting.space@domain".

callLegProfile: Welches calllegProfile soll verwendet werden, und welche accessMethods sollen mit dieser Vorlage erstellt werden?  Wenn dies nicht angegeben ist, wird die CoSpaceTemplate-Ebene verwendet. Wenn keine CoSpaceTemplate-Ebene angegeben ist, wird die Ebene des Systems bzw. Profils verwendet.

generateUniqueCallId: Gibt an, ob eine eindeutige numerische ID für diese Zugriffsmethode generiert werden soll, die die globale ID für den Cospace überschreibt.

dialInSecurityProfile: Welches dialInSecurityProfile soll von den mit dieser Vorlage erstellten Zugriffsmethoden verwendet werden? Wenn dies nicht angegeben ist, wird die CoSpaceTemplate-Ebene verwendet. Wenn keine CoSpaceTemplate-Ebene angegeben ist, wird die Ebene des Systems bzw. Profils verwendet.

Chat-Funktion

In CMS 3.0 wurde die persistente Chat-Funktion entfernt, in CMS 3.2 wurde jedoch der nicht persistente Chat innerhalb von Leerzeichen zurückgegeben.  Der Chat steht Benutzern von Web-Apps zur Verfügung und wird nirgendwo gespeichert.  Nach der Installation von CMS 3.2 können sich Web-App-Benutzer während Meetings standardmäßig gegenseitig Nachrichten senden.  Diese Nachrichten sind nur während des Meetings verfügbar, und es werden nur Nachrichten angezeigt, die nach dem Beitritt ausgetauscht werden. Sie können nicht zu spät teilnehmen und einen Bildlauf zurück durchführen, um vorherige Nachrichten zu sehen.

WebRTC Point-to-Point-Anrufe

In CMS 2.9.x konnten WebRTC-Teilnehmer direkt von ihrem Client aus andere Kontakte anrufen.  Ab CMS 3.0 ist dies nicht mehr möglich. Jetzt müssen sich Benutzer anmelden und einem Space beitreten. Von dort aus können sie, wenn sie über die Berechtigung im callLegProfile (addParticipants-Parameter auf True festgelegt) verfügen, weitere Kontakte hinzufügen.  Dadurch wählt sich das CMS beim Teilnehmer aus und trifft sich auf einem Platz im CMS.

Bemerkenswerte Änderungen an den WebBridge-Einstellungen

CMS 3.0 und 3.1 haben einige der Webbridge-Einstellungen aus der GUI entfernt oder verschoben und müssen in der API konfiguriert werden, um eine konsistente Benutzererfahrung zu gewährleisten.  Verwenden Sie unter 3.x api/v1/webBridges und api/v1/webBridgeProfiles. 

Prüfen Sie, was Sie derzeit konfiguriert haben, sodass Sie beim Upgrade auf 3.0 die Webbridge- und Webbridge-Profile in der API entsprechend konfigurieren können.

In 3.0 wurden Web-Bridge-Einstellungen über die GUI entfernt, in CMS 3.1 wurden auch die External Access-Felder entfernt.

Web-Bridge-Einstellungen in der GUI

• Guest Account Client URI - Diese wurde von callBridge verwendet, um die webBridge zu finden.  Wenn Sie mehrere WebBridges in Ihrer Bereitstellung für WebRTC installiert haben, muss dieses Feld bereits leer sein. Außerdem müssen Sie für jede WebBridge, mit der CallBridge eine Verbindung herstellen muss, eindeutige URLs in api/v1/webbridges angeben.  Löschen Sie alle Angaben in diesem Feld, und stellen Sie sicher, dass die webBridges in der API konfiguriert sind.

• Gastkonto Jid Domain - wird in CMS 3.0 nicht mehr verwendet und kann gelöscht werden.
• Gastzugriff über ID und Passcode - entfernt und nicht in CMS 3.0 ersetzt.
• Gastzugriff über Hyper Links - jetzt konfigurierbar unter webBridgeProfiles in API in der Einstellung "AllowSecrets".

Beachten Sie, dass in CMS 3.0 mehrere Felder aus api/v1/webBridges entfernt wurden.

• resourceArchive - jetzt in webbridgeProfiles.
• idEntryMode - jetzt veraltet.
• allowWeblinkAccess - jetzt in webBridgeProfiles als allowSecrets.
• showSignin - jetzt in webBridgeProfiles als userPortalEnabled.
• resolutCoSpaceCallIds- jetzt in webbridgeProfiles.
• ResolveLyncConferenceIDs - jetzt in webbridgeProfiles.

WebBridge-Profil

• resourceArchive - Wenn Sie benutzerdefinierte Hintergründe verwenden und Ihr Ressourcenarchiv auf einem Webserver gespeichert ist, geben Sie die URL hier ein.
• allowPasscodes: Bei "false" können Benutzer nicht als Gäste an Meetings teilnehmen.  Sie können sich nur anmelden oder eine URL verwenden, die die Space-Informationen und den geheimen Schlüssel enthält
• allowSecrets - Wenn dieser Wert auf false festgelegt ist, können Benutzer Leerzeichen nicht über eine URL wie https://meet.company.com/meeting/040478?secret=gPDnucF8is4W1cS87_l.zw beitreten. Die Benutzer müssen "https://meet.company.com" verwenden und, falls konfiguriert, die Anruf-ID/Meeting-ID/URI und die PIN/den Passcode eingeben.
• userPortalEnabled - Wenn dieser Wert auf false festgelegt ist, wird die Option zum Anmelden nicht auf der Landing Page des Web-App-Portals angezeigt. Es werden nur die Felder zur Eingabe von Anruf-ID/Meeting-ID/URI und PIN/Passcode angezeigt, wenn diese konfiguriert wurden.
• allowUnAuthenticatedGuests - Bei der Einstellung False können Gäste keinem Meeting beitreten - auch nicht mit der vollständigen URL, die die Meeting-ID und den geheimen Schlüssel enthält.  Bei False können nur Benutzer, die sich anmelden können, an einem Meeting teilnehmen.  Beispiel.  User2 versucht, die URL für das Meeting von User1 zu verwenden.  Nach Eingabe der URL muss sich User2 anmelden, um mit dem Meeting von User1 fortzufahren.
• resolutCoSpaceCallIds - Wenn diese Eigenschaft auf False festgelegt ist, können Gäste nur an Meetings teilnehmen, indem sie den URI und die PIN/den Passcode eingeben, wenn sie verwendet werden.  Anruf-ID/Meeting-ID/numerische ID werden nicht akzeptiert.
• resolutCoSpaceUris - 3 mögliche Einstellungen: off, domainSuggestionDisabled und domainSuggestionEnabled. Legt fest, ob diese webBridge CoSpace- und CoSpace-Zugriffs-Method SIP-URIs akzeptiert, um Besuchern die Teilnahme an Cospace-Meetings zu ermöglichen.

- Wenn 'off' gesetzt ist, wird der Join durch URI deaktiviert.

- Wenn 'domainSuggestionDisabled' als Wert festgelegt ist, ist der Join über URI aktiviert, aber die Domäne des URI wird auf webBridges mit diesem webBridgeProfile nicht automatisch vervollständigt oder verifiziert.

- Wenn 'domainSuggestionEnabled' als Join durch URI festgelegt ist, ist der URI aktiviert, und die Domäne des URI kann mithilfe dieses webBridgeProfile automatisch vervollständigt und auf webBridges überprüft werden.

Abschnitt für externen Zugriff von Web-GUI entfernt

In CMS 3.1 wurde der Abschnitt Externer Zugriff aus der Web-GUI entfernt. Wenn diese vor dem Upgrade konfiguriert wurden, müssen Sie sie in der API unter "webbbridgeProfiles" neu konfigurieren.

Zunächst müssen Sie ein webbridgeProfile erstellen, wie im vorherigen Abschnitt beschrieben. Nachdem Sie ein webbridgeProfile erstellt haben, können Sie eine IVR-Nummer und/oder einen Web Bridge URI über die in der API unter dem neu erstellten webBridgeProfile verfügbaren Links erstellen.

Sie können bis zu 32 IVR-Nummern oder 32 Webbridge-Adressen pro WebBridge-Profil erstellen.

Aufzeichnung oder Streaming

Die Recorder- und Streamer-Komponente in CMS 2.9.x und früheren Versionen waren XMPP-Clients, und von CMS 3.0 sind sie SIP-basiert.  Dadurch können jetzt die Layouts für Aufzeichnungen und Streaming mit dem Standardlayout in API geändert werden. Außerdem werden jetzt Namensbezeichnungen in der Aufnahme-/Streaming-Sitzung angezeigt.  Weitere Informationen zu den Recorder-/Streaming-Funktionen finden Sie in den Versionshinweisen zu CMS 3.0 unter https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-3-0/Cisco-Meeting-Server-Release-Notes-3-0.pdf.

Wenn Sie Rekorder oder Streamer in 2.9.x konfiguriert haben, müssen Sie die Einstellungen in MMP und API neu konfigurieren, damit diese nach dem Upgrade weiterhin funktionieren.

Vor dem CMS-Upgrade auf Version 3.0 wird empfohlen, ein Backup mit 'backup snapshot <servername_date>' durchzuführen und sich dann bei der webadmin-Seite auf Ihren callbridge-Knoten anzumelden, um alle XMPP-Einstellungen zu entfernen.  Stellen Sie dann eine Verbindung mit dem MMP auf Ihren Servern her, und führen Sie die folgenden Schritte auf allen Core-Servern aus, die über eine SSH-Verbindung mit xmpp verbunden sind:

1. xmpp deaktivieren
2. xmpp zurücksetzen
3. xmpp certs none
4. XMPP-Domäne keine

Rekorder

MMP

Die Abbildungen zeigen ein Beispiel der Konfigurationen, die in CMS 2.9.1 bei der Konfiguration des Recorders beobachtet wurden, und wie es unmittelbar nach dem Upgrade auf 3.0 aussieht.

Nach dem Upgrade müssen Sie den Rekorder neu konfigurieren:

Schritt 1: Konfigurieren Sie die SIP-Überwachungs-Schnittstelle.

recorder sip listen a 5060 5061 (Die Schnittstelle und die Ports, auf denen der SIP-Recorder eingerichtet ist, um TCP und TLS zu überwachen. Wenn Sie TLS nicht verwenden möchten, können Sie "recorder sip listen a 5060 none" verwenden)

Schritt 2: Konfigurieren Sie die Zertifikate, die der Rekorder verwendet, wenn Sie eine TLS-Verbindung verwenden.

recorder sip certs <key-file> <crt-file> [crt-bundle] (Ohne diese Zertifikate startet der tls-Dienst nicht auf dem Recorder. Der Recorder verwendet das crt-Bundle, um das callBridge-Zertifikat zu verifizieren.)

Schritt 3: Konfigurieren Sie das Anruflimit.

recorder limit <0-500|none> (Legt die Grenze für die Anzahl gleichzeitiger Aufzeichnungen fest, die der Server bereitstellen kann. Diese Tabelle finden Sie in unserer Dokumentation. Die Rekorder-Grenze muss mit den Ressourcen auf dem Server übereinstimmen.)

API

Bei api/v1/callProfiles müssen Sie den sipRecorderUri konfigurieren. Dies ist der URI, den CallBridge wählt, wenn eine Aufzeichnung gestartet werden muss. Die Domäne dieses URIs muss zur Tabelle der ausgehenden Regeln hinzugefügt werden und auf den Rekorder (oder die Anrufsteuerung) als zu verwendenden SIP-Proxy verweisen.

Diese Abbildung zeigt eine Direktdurchwahl zur Rekorder-Komponente in den Regeln für ausgehende Anrufe unter Konfiguration > Ausgehende Anrufe.

Diese Abbildung zeigt einen Anruf an die Recorderkomponente über eine Anrufsteuerung (wie z.B. Cisco Unified Communications Manager (CUCM) oder Expressway).

Hinweis: Wenn Sie den Rekorder für die Verwendung von SIP TLS konfiguriert haben und wenn Anrufe fehlschlagen, überprüfen Sie Ihren callBridge-Knoten in MMP, um festzustellen, ob die TLS SIP-Verifizierung aktiviert ist.  Der MMP-Befehl lautet 'tls sip'.   Anrufe können fehlschlagen, weil das Rekordzertifikat von callBridge nicht vertrauenswürdig ist.  Sie können dies testen, indem Sie dies auf der callBridge mit 'tls sip verify disable' deaktivieren.

Mehrere Rekorder?

Konfigurieren Sie die einzelnen Regeln wie beschrieben, und passen Sie die Regeln für ausgehende Anrufe entsprechend an.  Wenn Sie eine Direct To Recorder-Methode verwenden, ändern Sie die vorhandene Regel für ausgehende Anrufe in Recorder in das Verhalten "Continue" (Weiter), und fügen Sie eine neue Regel für ausgehende Anrufe unterhalb der vorherigen hinzu, deren Priorität um eins kleiner als die der ersten ist.  Wenn der erste Recorder sein Anruflimit erreicht hat, sendet er eine 488 Unaccept (Unannehmbar) zurück an callBridge, und callBridge geht zur nächsten Regel über.

Wenn Sie den Lastenausgleich für die Rekorder vornehmen möchten, verwenden Sie eine Anrufsteuerung, und passen Sie die Anrufsteuerungsweiterleitung an, sodass mehrere Rekorder angerufen werden können.

Streamer

MMP

Nach dem Upgrade von 2.9.x auf 3.0 müssen Sie Streamer neu konfigurieren.

Schritt 1: Konfigurieren Sie die SIP-Überwachungs-Schnittstelle.

streamer sip listen a 6000 6001 (Die Schnittstelle und die Ports, auf denen der SIP-Streamer eingerichtet ist, um TCP und TLS zu überwachen.  Wenn Sie TLS nicht verwenden möchten, können Sie "streamer sip listen a 6000 none" verwenden.

Schritt 2: Konfigurieren Sie die Zertifikate, die der Streamer verwendet, wenn Sie eine TLS-Verbindung verwenden.

streamer sip certs <key-file> <crt-file> [crt-bundle] (Ohne diese Zertifikate startet der tls-Dienst nicht auf dem streamer. Der Streamer verwendet das crt-Paket, um das callBridge-Zertifikat zu verifizieren.)

Schritt 3: Konfigurieren des Anruflimits

streamer limit <0-500|none> (Legt den Grenzwert für die Anzahl gleichzeitiger Streams fest, die der Server bedienen kann. Diese Tabelle finden Sie in unserer Dokumentation, und die Streamer-Grenze muss mit den Ressourcen auf dem Server übereinstimmen.)

API

Bei api/v1/callProfiles müssen Sie den sipStreamUri konfigurieren. Dies ist der URI, den callBridge wählt, wenn das Streaming gestartet werden muss. Die Domäne dieses URIs muss zur Tabelle der ausgehenden Regeln hinzugefügt werden und auf den Streamer (oder die Anrufsteuerung) als zu verwendender SIP-Proxy verweisen.

Diese Abbildung zeigt eine Direktdurchwahl zur Streamer-Komponente in den Regeln für ausgehende Anrufe unter Konfiguration > Ausgehende Anrufe.

Diese Abbildung zeigt einen Anruf an die Recorderkomponente über eine Anrufsteuerung (wie z.B. Cisco Unified Communications Manager (CUCM) oder Expressway).

Hinweis: Wenn Sie den Streamer für die Verwendung von SIP TLS konfiguriert haben und wenn Anrufe fehlschlagen, überprüfen Sie Ihren callBridge-Knoten in MMP, um festzustellen, ob die TLS SIP-Verifizierung aktiviert ist.  Der MMP-Befehl lautet 'tls sip'.   Anrufe können fehlschlagen, weil das Streamer-Zertifikat von callBridge nicht als vertrauenswürdig eingestuft wird.  Sie können dies testen, indem Sie dies auf der callBridge mit 'tls sip verify disable' deaktivieren.

Mehrere Streamer?

Konfigurieren Sie die einzelnen Regeln wie beschrieben, und passen Sie die Regeln für ausgehende Anrufe entsprechend an.  Wenn Sie eine Methode für das direkte Aufzeichnen verwenden, ändern Sie die vorhandene Regel für das ausgehende Aufzeichnen in das Verhalten "Continue" (Fortfahren), und fügen Sie eine neue Regel für das ausgehende Aufzeichnen unterhalb der vorherigen hinzu, deren Priorität um eins kleiner als die erste ist.  Wenn der erste Streamer sein Anruflimit erreicht hat, sendet er eine 488 Unaccept (Unannehmbar) an callBridge zurück, und callBridge geht zur nächsten Regel über.

Wenn Sie den Lastenausgleich für Ihre Streamer vornehmen möchten, verwenden Sie eine Anrufsteuerung, und passen Sie die Anrufsteuerungsweiterleitung so an, dass Anrufe an mehrere Streamer weitergeleitet werden können.

Überlegungen zum Expressway

Wenn Sie Cisco Expressway für Webproxy verwenden, müssen Sie sicherstellen, dass Ihr Expressway mindestens X12.6 vor dem CMS-Upgrade ausgeführt wird. Dies ist in CMS 3.0 erforderlich, damit der Web-Proxy funktioniert und unterstützt wird.

Die Kapazität für Web-App-Teilnehmer hat sich gegenüber Expressways bei Verwendung mit CMS 3.0 erhöht.  Für einen großen OVA-Expressway beträgt die erwartete Kapazität 150 Full HD-Anrufe (1080p30) oder 200 Anrufe anderer Art (z. B. 720p30). Sie können diese Kapazität durch Clustering von Expressways erhöhen, bis zu 6 Knoten (wobei 4 für Skalierung und 2 für Redundanz verwendet wird, sodass bis zu 60 0 Full-HD-Anrufe oder 800 Anrufe anderer Art).

CMS-Edge

CMS Edge wird in CMS 3.1 wieder eingeführt, da es höhere Kapazitäten als der Expressway für externe Web-App-Sitzungen bietet. Es gibt zwei empfohlene Konfigurationen.

Small Edge-Spezifikationen

4 GB RAM, 4 vCPUs, 1 Gbit/s Netzwerkschnittstelle

Diese VM Edge-Spezifikation verfügt über eine ausreichende Leistung, um eine einzelne CMS1000-Audio- und Video-Lastkapazität von 48 x 1080p, 96 x 720p, 192 x 480p und 1000 Audio-Anrufen abzudecken.

Für die Bereitstellung wird ein Small Edge-Server pro CMS1000 oder vier Small Edge-Server pro CMS2000 empfohlen.

Spezifikationen für große Ränder

8 GB RAM, 16 vCPUs, 10 Gbit/s Netzwerkschnittstelle

Diese VM-Edge-Spezifikation verfügt über eine ausreichende Leistung, um eine einzelne CMS2000-Audio- und Videokapazität von 350 x 1080p, 700 x 720p, 1000 x 480p und 3000 x Audioanrufe abzudecken.

Für die Bereitstellung wird ein großer Edge-Server pro CMS2000 oder pro 4 CMS1000 empfohlen.