Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Was ist der maxPeerVideoStreams-Parameter, und wann wird er in Kraft treten?

Beispielbereitstellung und Szenarien

1. maxPeerVideoStreams bei aktiviertem LoadBalancing auf 4 eingestellt

2. maxPeerVideoStreams auf 4 festgelegt, bei deaktiviertem LoadBalancing

3. maxPeerVideoStreams bei aktiviertem LoadBalancing auf 9 eingestellt

4. maxPeerVideoStreams bei deaktiviertem LoadBalancing auf 9 eingestellt

Fehlerbehebung

Zugehörige Informationen

Einführung

Dieses Dokument beschreibt das erwartete Verhalten des Parameters maxPeerVideoStreams, wenn er in einem Cisco Meeting Server (CMS)-Cluster verwendet wird.

Dieser Parameter wird in der Kurzreferenz für Administratoren erwähnt.

Voraussetzungen

Anforderungen

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

- Cisco Meeting Server Call Bridge-Komponente (und Clustering der Komponente)

- Konfiguration der Cisco Meeting Server-API

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

- CMS 2.9.x

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.

Was ist der maxPeerVideoStreams-Parameter, und wann wird er in Kraft treten?

Der maxPeerVideoStreams-Parameter wurde erstmals in CMS Version 2.3 eingeführt. Dieser Parameter legt fest, 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 eine große, verteilte Konferenz wirksam, wenn es auf jeder CallBridge mehr als 4 Teilnehmer gibt.

Hinweis: Der maxPeerVideoStreams ist nur in einem CMS-Cluster mit zwei oder mehr Servern relevant, er ist nicht für einen einzelnen CMS-Server relevant.

Wenn maxPeerVideoStreams nicht festgelegt ist, werden standardmäßig maximal vier Video-Streams über einen verteilten Anruf an den anderen CMS-Server gesendet. 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 das CMS so zu konfigurieren, dass statt nur 4 maximal 9 Video-Streams über den verteilten Anruf gesendet werden.

Diese Bedeutung dieses Parameters wird bei großen Konferenzen, bei denen eine große Anzahl von Teilnehmern gehostet wird, und bei Verwendung eines AllEqual-Layouts, bei dem maximal 25 Bereiche auf dem Bildschirm eines Teilnehmers angezeigt werden können, deutlicher. 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 (5 oder mehr) gehostet werden, können die Teilnehmer, die auf CMS1 gehostet werden, das Video nur von maximal 4 Teilnehmern aus den Remote-Teilnehmern sehen, die auf CMS2 gehostet werden, zusätzlich zum Video aller anderen lokalen Teilnehmer, die auf ihrem lokalen CMS gehostet werden CMS1) Server-Host, auch wenn CMS2 derzeit 8 aktive Teilnehmer hat. Das Gleiche gilt für Teilnehmer, die auf CMS2 gehostet werden. Sie können das Video von maximal 4 Teilnehmern aus den auf CMS1 gehosteten Remote-Teilnehmern und das Video der anderen Teilnehmer sehen, die auf demselben CMS2 gehostet sind, selbst wenn CMS1 zehn aktive Teilnehmer hat.

Hinweis: Die maxPeerVideoStreams ist noch eine Beta-Funktion (Preview).

Beispielbereitstellung und Szenarien

Die Informationen in diesem Dokument basieren auf dieser Beispielbereitstellung:

- CMS-Cluster mit zwei Servern, CMS1 und CMS2

- Die auf diesen Servern konfigurierte Lastenbegrenzung ermöglicht 17 Anrufe, nachdem die Anrufverteilung begonnen hat.

- Die CUCM-Routengruppe für die CMS-Server wird mit einer zirkulären Verteilung konfiguriert.

- AllEqual Layout wird verwendet, oder 5x5, um die maximal möglichen Teilnehmerbereiche zu ermöglichen, d. h. 25.

- 30 Teilnehmer schließen sich Space1 an, das eine Priorität (für Lastenausgleich) auf CMS1 hat.

1. maxPeerVideoStreams bei aktiviertem LoadBalancing auf 4 eingestellt

- Da Load Balancing aktiviert ist und space1 auf CMS1 Priorität hat, treten die ersten 17 Teilnehmer auf CMS1 bei, bis die Kapazität voll ausgeschöpft ist. Der anstehende Teilnehmer 18 nimmt am CMS2 teil, und ein verteilter Anruf wird erstellt.

maxPeerVideoStreams bei aktiviertem Lastenausgleich auf 4 eingestellt

- Es gibt 17 Teilnehmer am CMS1 (1 - 17) und 13 Teilnehmer am CMS2 (18 - 30)

- Die Teilnehmer 1-17 sehen die anderen 16 lokalen Teilnehmer aus CMS1, zusätzlich zu nur 4 Teilnehmern aus CMS2, werden insgesamt 20 Teilnehmer auf den Bildschirmen der Teilnehmer 1-17 angezeigt

- Die Teilnehmer 18-30 sehen die anderen 12 lokalen Teilnehmer aus CMS2, zusätzlich zu nur 4 Teilnehmern aus CMS1 werden insgesamt 16 Teilnehmer auf den Bildschirmen der Teilnehmer 18-30 angezeigt

- Zusammenfassung: Von CMS1 gehostete Teilnehmer sehen 20 Teilnehmer, von CMS2 gehostete Teilnehmer sehen 16 Teilnehmer auf ihrem Bildschirm.

2. maxPeerVideoStreams auf 4 festgelegt, bei deaktiviertem LoadBalancing

- Da der Lastenausgleich nicht aktiviert ist, treten die Teilnehmer der Konferenz ab dem zweiten Anruf auf beiden CMS-Servern bei. Dies liegt daran, dass die CUCM-Routengruppe auf kreisförmig festgelegt ist, d. h. Anrufe werden sequenziell an beide CMS-Server gesendet. Anruf 1 wird an CMS1 gesendet, Anruf 2 wird an CMS2 gesendet, Anruf 3 wird an CMS1 gesendet, Anruf 4 wird an CMS2 gesendet.

- Das bedeutet, dass voraussichtlich 15 Teilnehmer auf jeder CallBridge gehostet werden - es gibt 15 Teilnehmer auf CMS1 und 15 Teilnehmer auf CMS2.

maxPeerVideoStreams auf 4 festgelegt, Lastenausgleich deaktiviert

- Teilnehmer am CMS1 sehen die anderen 14 lokalen Teilnehmer aus CMS1. Zusätzlich zu 4 Teilnehmern aus CMS2 werden insgesamt 18 Teilnehmer auf den Bildschirmen der CMS1-Teilnehmer angezeigt.

- Teilnehmer am CMS2 sehen die anderen 14 lokalen Teilnehmer aus CMS2, zusätzlich zu 4 Teilnehmern aus CMS1 werden insgesamt 18 Teilnehmer auf den Bildschirmen der CMS2-Teilnehmer angezeigt.

- Zusammenfassung: CMS1-Teilnehmer und CMS2-Teilnehmer sehen auf ihrem Bildschirm jeweils 18 Teilnehmer.

3. maxPeerVideoStreams bei aktiviertem LoadBalancing auf 9 eingestellt

- Da Load Balancing aktiviert ist und Leerzeichen1 auf CMS1 Priorität hat, treten Teilnehmer auf CMS1 bei, bis sie ihre volle Kapazität erreicht haben. Der anstehende Teilnehmer 18 nimmt am CMS2 teil, und ein verteilter Anruf wird erstellt.

maxPeerVideoStreams bei aktiviertem LoadBalancing auf 9 eingestellt

- Es gibt 17 Teilnehmer am CMS1 (1 - 17) und 13 Teilnehmer am 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 bis 30 sehen die anderen 12 lokalen Teilnehmer aus CMS2, zusätzlich zu den 9 Teilnehmern aus CMS1 werden insgesamt 21 Teilnehmer auf den Bildschirmen der Teilnehmer 18 bis 30 angezeigt

- Zusammenfassung: Die CMS1-Teilnehmer sehen 25 Teilnehmer, die CMS2-Teilnehmer 21 Teilnehmer auf ihren Bildschirmen.

4. maxPeerVideoStreams bei deaktiviertem LoadBalancing auf 9 eingestellt

- Da der Lastenausgleich nicht aktiviert ist, treten die Teilnehmer der Konferenz ab dem zweiten Anruf auf beiden CMS-Servern bei. Dies liegt daran, dass die CUCM-Routengruppe auf kreisförmig festgelegt ist, d. h. Anrufe werden sequenziell an beide CMS-Server gesendet. Anruf 1 wird an CMS1 gesendet, Anruf 2 wird an CMS2 gesendet, Anruf 3 wird an CMS1 gesendet, Anruf 4 an CMS2.

- Das bedeutet, dass voraussichtlich 15 Teilnehmer auf jeder CallBridge gehostet werden - 15 Teilnehmer befinden sich auf CMS1 und 15 Teilnehmer sind auf CMS2.

maxPeerVideoStreams auf 9 eingestellt, ohne Lastenausgleich

- Teilnehmer am CMS1 sehen die anderen 14 lokalen Teilnehmer aus CMS1. Zusätzlich zu den 9 Teilnehmern aus CMS2 werden auf den Bildschirmen der CMS1-Teilnehmer insgesamt 23 Teilnehmer angezeigt.

- Teilnehmer am CMS2 sehen die anderen 14 lokalen Teilnehmer aus CMS2, zusätzlich zu den 9 Teilnehmern aus CMS1 werden insgesamt 23 Teilnehmer auf den Bildschirmen der CMS2-Teilnehmer angezeigt.

- Zusammenfassung: CMS1-Teilnehmer und CMS2-Teilnehmer sehen auf ihrem Bildschirm jeweils 23 Teilnehmer.

Fehlerbehebung

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Sie können das Collaboration Solutions Analyser-Tool für Protokollanalysen verwenden.

Zugehörige Informationen

- Load Balancing-Logik auf Cisco Meeting Server

- CMS-Konfigurationsdokumentation

- Programmieranleitungen für CMS API und MMP