Comportamento previsto durante l'utilizzo del parametro maxPeerVideoStreams nei cluster CMS
Sommario
Introduzione
In questo documento viene descritto il comportamento previsto del parametro maxPeerVideoStreams quando viene utilizzato in un cluster Cisco Meeting Server (CMS).
Questo parametro è indicato nella Guida di riferimento rapido per l'amministratore.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Componente Call Bridge di Cisco Meeting Server (e relativo clustering)
- Configurazione API Cisco Meeting Server
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- CMS 2.9.x
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Che cos'è il parametro maxPeerVideoStreams e quando entra in vigore?
Il parametro maxPeerVideoStreams è stato introdotto per la prima volta in CMS versione 2.3. Questo parametro determina il numero di flussi video che un server CMS può inviare a un altro server CMS tramite una chiamata distribuita. Deve essere impostato separatamente su ciascun server CMS. Il parametro maxPeerVideoStreams è valido per una conferenza distribuita di grandi dimensioni quando su ogni CallBridge sono presenti più di 4 partecipanti.
Se maxPeerVideoStreams non è impostato, il comportamento predefinito di CMS consiste nell'inviare un massimo di 4 flussi video durante una chiamata distribuita all'altro server CMS; si tratta del comportamento precedente a CMS 2.3. Con CMS 2.3 e versioni successive, è ora possibile modificare questo comportamento e configurare CMS per inviare un massimo di 9 flussi video tramite chiamata distribuita anziché solo 4.
L'importanza di questo parametro diventa più chiara con le grandi conferenze, che ospitano un gran numero di partecipanti e che utilizzano un layout AllEqual, che consente di visualizzare un massimo di 25 riquadri sullo schermo di un singolo partecipante. In questo caso, se una conferenza viene distribuita su due server CMS (ad esempio CMS1 e CMS2) e più di 4 partecipanti sono ospitati su ciascun server CMS per questa conferenza (5 o più), i partecipanti ospitati su CMS1 sono in grado di vedere il video solo da un massimo di 4 partecipanti provenienti dai partecipanti remoti ospitati su CMS2, oltre al video proveniente da tutti gli altri partecipanti locali ospitati sul loro host del server CMS (CMS1) locale, anche se CMS2 ha attualmente 8 partecipanti attivi. Lo stesso vale per i partecipanti ospitati su CMS2: essi sono in grado di vedere il video solo da un massimo di 4 partecipanti dei partecipanti remoti ospitati su CMS1 e il video degli altri partecipanti ospitati sullo stesso CMS2, anche se CMS1 ha 10 partecipanti attivi.
Esempi di distribuzione e scenari
Le informazioni di questo documento si basano sulla seguente distribuzione di esempio:
- Cluster CMS di due server, CMS1 e CMS2
- Il limite di carico configurato in questi server consente 17 chiamate, dopo l'avvio della distribuzione
- Il gruppo di route CUCM per i server CMS è configurato con la distribuzione circolare
- Viene utilizzato il layout AllEqual, ovvero 5x5, per consentire il numero massimo di riquadri partecipanti, ovvero 25
- 30 partecipanti stanno unendo space1, che ha una priorità (per il bilanciamento del carico) su CMS1
1. maxPeerVideoStreams impostato su 4 con loadBalancing abilitato
- Poiché il bilanciamento del carico è abilitato e la priorità di spazio1 è su CMS1, i primi 17 partecipanti si uniscono a CMS1, fino a raggiungere la sua piena capacità. Il prossimo partecipante 18 si unisce a CMS2 e viene creata una chiamata distribuita
maxPeerVideoStreams impostato su 4 con bilanciamento del carico abilitato
- Vi sono 17 partecipanti su CMS1 (1 - 17) e 13 partecipanti su CMS2 (18 - 30)
- Partecipanti 1 - 17 Cfr. gli altri 16 partecipanti locali del CMS1, oltre ai soli 4 partecipanti del CMS2, sugli schermi dei partecipanti 1 - 17 è visualizzato un totale di 20 partecipanti.
- Partecipanti 18 - 30 Cfr. gli altri 12 partecipanti locali del CMS2, oltre ai soli 4 partecipanti del CMS1, un totale di 16 partecipanti sono visualizzati sugli schermi dei partecipanti 18 - 30
- In sintesi: i partecipanti ospitati da CMS1 vedono 20 partecipanti, i partecipanti ospitati da CMS2 vedono 16 partecipanti sui loro schermi
2. maxPeerVideoStreams impostato su 4 con loadBalancing disabilitato
- Poiché il bilanciamento del carico non è abilitato, i partecipanti si uniscono alla conferenza su entrambi i server CMS a partire dalla seconda chiamata. Il motivo è che il gruppo di route CUCM è impostato su circolare, il che significa che le chiamate vengono inviate a entrambi i server CMS in sequenza. La chiamata 1 viene inviata a CMS1, la chiamata 2 a CMS2, la chiamata 3 a CMS1, la chiamata 4 a CMS2
- Ciò significa che ci si aspetta di trovare 15 partecipanti ospitati su ogni CallBridge - ci sono 15 partecipanti su CMS1 e 15 partecipanti su CMS2
maxPeerVideoStreams impostato su 4 con bilanciamento del carico disabilitato
- I partecipanti al CMS1 vedono gli altri 14 partecipanti locali del CMS1, oltre ai 4 partecipanti del CMS2, sugli schermi dei partecipanti al CMS1 sono visualizzati in totale 18 partecipanti
- I partecipanti al CMS2 vedono gli altri 14 partecipanti locali del CMS2, oltre ai 4 partecipanti del CMS1, un totale di 18 partecipanti sono visualizzati sugli schermi dei partecipanti del CMS2
- In sintesi: i partecipanti al CMS1 e i partecipanti al CMS2 vedono entrambi 18 partecipanti sui loro schermi
3. maxPeerVideoStreams impostato su 9 con loadBalancing abilitato
- Poiché il bilanciamento del carico è abilitato e la priorità dello spazio1 è su CMS1, i partecipanti si uniscono a CMS1 fino a raggiungere la sua piena capacità. Il prossimo partecipante 18 si unisce a CMS2 e viene creata una chiamata distribuita
maxPeerVideoStreams impostato su 9 con loadBalancing abilitato
- Vi sono 17 partecipanti su CMS1 (1 - 17) e 13 partecipanti su CMS2 (18 - 30)
- Partecipanti 1 - 17 Cfr. gli altri 16 partecipanti locali del CMS1, oltre ai 9 partecipanti del CMS2, sugli schermi dei partecipanti 1 - 17 sono visualizzati 25 partecipanti in totale
- Partecipanti 18 - 30 Cfr. gli altri 12 partecipanti locali del CMS2, oltre ai 9 partecipanti del CMS1, un totale di 21 partecipanti sono visualizzati sugli schermi dei partecipanti 18 - 30
- In sintesi: i partecipanti al CMS1 vedono 25 partecipanti, i partecipanti al CMS2 vedono 21 partecipanti sui loro schermi
4. maxPeerVideoStreams impostato su 9 con loadBalancing disabilitato
- Poiché il bilanciamento del carico non è abilitato, i partecipanti si uniscono alla conferenza su entrambi i server CMS a partire dalla seconda chiamata. Il motivo è che il gruppo di route CUCM è impostato su circolare, il che significa che le chiamate vengono inviate a entrambi i server CMS in sequenza. La chiamata 1 viene inviata a CMS1, la chiamata 2 a CMS2, la chiamata 3 a CMS1, la chiamata 4 a CMS2
- Ciò significa che si prevede di trovare 15 partecipanti ospitati su ogni CallBridge - 15 partecipanti sono su CMS1 e 15 partecipanti su CMS2
maxPeerVideoStreams impostato su 9 con bilanciamento del carico disabilitato
- I partecipanti al CMS1 vedono gli altri 14 partecipanti locali del CMS1, oltre ai 9 partecipanti del CMS2, sugli schermi dei partecipanti del CMS1 sono visualizzati in totale 23
- I partecipanti al CMS2 vedono gli altri 14 partecipanti locali del CMS2, oltre ai 9 partecipanti del CMS1, un totale di 23 partecipanti sono visualizzati sugli schermi dei partecipanti del CMS2
- In sintesi: i partecipanti al CMS1 e i partecipanti al CMS2 vedono entrambi 23 partecipanti sui loro schermi
Risoluzione dei problemi
Non sono attualmente disponibili informazioni specifiche sulla risoluzione dei problemi per questa configurazione.
È possibile utilizzare lo strumento Collaboration Solutions Analyzer per l'analisi dei log.
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
22-Jun-2020 |
Versione iniziale |
Feedback