Erwartetes Verhalten bei Verwendung des maxPeerVideoStreams-Parameters in CMS-Clustern
Inhalt
Einleitung
In diesem Dokument wird das erwartete Verhalten des Parameters "maxPeerVideoStreams" bei Verwendung in einem CMS-Cluster (Cisco Meeting Server) beschrieben.
Dieser Parameter wird in der Kurzreferenz für Administratoren erwähnt.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Cisco Meeting Server Call Bridge-Komponente (und Clustering)
- API-Konfiguration für Cisco Meeting Server
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- CMS 2.9.x
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.
Was ist der Parameter maxPeerVideoStreams und wann tritt er in Kraft?
Der Parameter maxPeerVideoStreams wurde erstmals in CMS Version 2.3 eingeführt. Dieser Parameter bestimmt, wie viele Teilnehmer-Video-Streams ein CMS-Server über einen verteilten Anruf an einen anderen CMS-Server senden kann. Sie muss auf jedem CMS-Server separat eingerichtet werden. Der maxPeerVideoStreams-Parameter ist für große, verteilte Konferenzen wirksam, wenn mehr als 4 Teilnehmer pro CallBridge vorhanden sind.
Wenn maxPeerVideoStreams nicht festgelegt ist, sendet CMS standardmäßig maximal 4 Video-Streams über einen verteilten Anruf an den anderen CMS-Server. Dies war das Verhalten vor CMS 2.3. Mit CMS 2.3 und höher ist es jetzt möglich, dieses Verhalten zu ändern und CMS so zu konfigurieren, dass über den verteilten Anruf maximal 9 Video-Streams anstatt nur 4 gesendet werden.
Die Bedeutung dieses Parameters wird deutlicher, wenn große Konferenzen stattfinden, eine große Anzahl von Teilnehmern gehostet wird und ein AllEqual-Layout verwendet wird, das es ermöglicht, maximal 25 Bereiche auf dem Bildschirm eines Teilnehmers anzuzeigen. Wenn in diesem Fall eine Konferenz über zwei CMS-Server (z. B. CMS1 und CMS2) verteilt wird und mehr als 4 Teilnehmer auf jedem CMS-Server für diese Konferenz gehostet werden (5 oder mehr), können die auf CMS1 gehosteten Teilnehmer das Video nur von maximal 4 Teilnehmern der Remote-Teilnehmer sehen, die auf CMS2 gehostet werden, sowie das Video von allen anderen lokalen Teilnehmern, die auf ihrem lokalen CMS gehostet werden (CMS1) Serverhost, auch wenn CMS2 aktuell 8 aktive Teilnehmer hat. Dasselbe gilt für Teilnehmer, die auf CMS2 gehostet werden - sie können nur das Video von maximal vier Teilnehmern der auf CMS1 gehosteten Remote-Teilnehmer und das Video der anderen Teilnehmer sehen, die auf demselben CMS2 gehostet werden, selbst wenn CMS1 zehn aktive Teilnehmer umfasst.
Bereitstellungsbeispiele und Szenarien
Die Informationen in diesem Dokument basieren auf diesem Bereitstellungsbeispiel:
- CMS Cluster aus zwei Servern, CMS1 und CMS2
- Das auf diesen Servern konfigurierte Lastlimit ermöglicht 17 Anrufe, nachdem die Anrufverteilung gestartet wurde.
- Die CUCM-Routengruppe für die CMS-Server wird mit zirkulärer Verteilung konfiguriert
- AllEqual-Layout wird verwendet, oder 5x5, dies ist, um die maximal möglichen Teilnehmerbereiche, die 25 ist
- 30 Teilnehmer treten Space1 bei, das auf CMS1 eine Priorität (für den Lastenausgleich) hat.
1. maxPeerVideoStreams auf 4 festgelegt, LoadBalancing aktiviert
- Da Load Balancing aktiviert ist und die Priorität von space1 auf CMS1 festgelegt ist, treten die ersten 17 Teilnehmer auf CMS1 bei, bis die volle Kapazität erreicht ist. Der kommende Teilnehmer 18 nimmt am CMS2 teil, und es wird ein verteilter Anruf erstellt.
maxPeerVideoStreams auf 4 eingestellt, Lastenausgleich aktiviert
- 17 Teilnehmer in CMS1 (1 - 17) und 13 Teilnehmer in CMS2 (18 - 30)
- Teilnehmer 1 - 17 sehen die anderen 16 lokalen Teilnehmer aus CMS1, zusätzlich zu nur 4 Teilnehmern aus CMS2, insgesamt 20 Teilnehmer werden auf den Bildschirmen der Teilnehmer 1 - 17 angezeigt
- Teilnehmer 18 - 30 sehen die anderen 12 lokalen Teilnehmer aus CMS2, zusätzlich zu nur 4 Teilnehmern aus CMS1, insgesamt 16 Teilnehmer werden auf den Bildschirmen der Teilnehmer 18 - 30 angezeigt
- Zusammenfassung: Teilnehmer mit CMS1-Hosting sehen 20 Teilnehmer, Teilnehmer mit CMS2-Hosting sehen 16 Teilnehmer auf ihren Bildschirmen.
2. maxPeerVideoStreams auf 4 festgelegt, Lastenausgleich deaktiviert
- Da Load Balancing nicht aktiviert ist, nehmen die Teilnehmer ab dem zweiten Anruf an der Konferenz auf beiden CMS-Servern teil. Dies liegt daran, dass die CUCM-Routengruppe auf "Zirkular" festgelegt ist, d. h., dass Anrufe nacheinander an beide CMS-Server gesendet werden. Anruf 1 wird an CMS1 gesendet, Anruf 2 wird an CMS2 gesendet, Anruf 3 wird an CMS1 gesendet, Anruf 4 wird an CMS2 gesendet
- Es werden also 15 Teilnehmer auf jeder CallBridge erwartet - 15 Teilnehmer auf CMS1 und 15 Teilnehmer auf CMS2.
maxPeerVideoStreams auf 4 festgelegt, Lastenausgleich deaktiviert
- Die Teilnehmer auf CMS1 sehen die anderen 14 lokalen Teilnehmer von CMS1, zusätzlich zu 4 Teilnehmern von CMS2 werden insgesamt 18 Teilnehmer auf den Bildschirmen der CMS1-Teilnehmer angezeigt
- Teilnehmer auf CMS2 sehen die anderen 14 lokalen Teilnehmer von CMS2, zusätzlich zu 4 Teilnehmern von CMS1 werden insgesamt 18 Teilnehmer auf den Bildschirmen der CMS2-Teilnehmer angezeigt
- Zusammenfassung: CMS1- und CMS2-Teilnehmer sehen jeweils 18 Teilnehmer auf ihren Bildschirmen.
3. maxPeerVideoStreams auf 9 bei aktiviertem LoadBalancing eingestellt
- Da Load Balancing aktiviert ist und die Priorität von space1 auf CMS1 festgelegt ist, treten die Teilnehmer auf CMS1 bei, bis die volle Kapazität erreicht ist. Der kommende Teilnehmer 18 nimmt am CMS2 teil, und es wird ein verteilter Anruf erstellt.
maxPeerVideoStreams auf 9 festgelegt, LoadBalancing aktiviert
- 17 Teilnehmer in CMS1 (1 - 17) und 13 Teilnehmer in CMS2 (18 - 30)
- Teilnehmer 1 - 17 sehen die anderen 16 lokalen Teilnehmer aus CMS1, zusätzlich zu 9 Teilnehmern aus CMS2 werden insgesamt 25 Teilnehmer auf den Bildschirmen der Teilnehmer 1 - 17 angezeigt
- Die Teilnehmer 18 - 30 sehen die anderen 12 lokalen Teilnehmer aus CMS2, zusätzlich zu 9 Teilnehmern aus CMS1 werden insgesamt 21 Teilnehmer auf den Bildschirmen der Teilnehmer 18 - 30 angezeigt
- Zusammenfassung: CMS1-Teilnehmer sehen 25 Teilnehmer, CMS2-Teilnehmer sehen 21 Teilnehmer auf ihren Bildschirmen.
4. maxPeerVideoStreams auf 9 festgelegt, Lastenausgleich deaktiviert
- Da Load Balancing nicht aktiviert ist, nehmen die Teilnehmer ab dem zweiten Anruf an der Konferenz auf beiden CMS-Servern teil. Dies liegt daran, dass die CUCM-Routengruppe auf "Zirkular" festgelegt ist, d. h., dass Anrufe nacheinander an beide CMS-Server gesendet werden. Anruf 1 wird an CMS1 gesendet, Anruf 2 wird an CMS2 gesendet, Anruf 3 wird an CMS1 gesendet, Anruf 4 wird an CMS2 gesendet
- Es werden also 15 Teilnehmer auf jeder CallBridge gehostet - 15 Teilnehmer auf CMS1 und 15 Teilnehmer auf CMS2
maxPeerVideoStreams auf 9 festgelegt, Lastenausgleich deaktiviert
- Teilnehmer auf CMS1 sehen die anderen 14 lokalen Teilnehmer von CMS1, zusätzlich zu 9 Teilnehmern von CMS2 werden insgesamt 23 Teilnehmer auf den Bildschirmen der CMS1-Teilnehmer angezeigt
- Die Teilnehmer des CMS2 sehen die anderen 14 lokalen Teilnehmer des CMS2. Zusätzlich zu den 9 Teilnehmern des CMS1 werden auf den Bildschirmen der CMS2-Teilnehmer insgesamt 23 Teilnehmer angezeigt.
- Zusammenfassung: CMS1- und CMS2-Teilnehmer sehen jeweils 23 Teilnehmer auf ihren Bildschirmen.
Fehlerbehebung
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.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
22-Jun-2020 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)