Comportamiento esperado al utilizar el parámetro maxPeerVideoStreams en clústeres CMS
Contenido
Introducción
Este documento describe el comportamiento esperado del parámetro maxPeerVideoStreams cuando se utiliza en un clúster de Cisco Meeting Server (CMS).
Este parámetro se menciona en la Guía de referencia rápida para administradores.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- componente Call Bridge de Cisco Meeting Server (y agrupación en clúster del mismo)
- Configuración de la API de Cisco Meeting Server
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- CMS 2.9.x
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
¿Qué es el parámetro maxPeerVideoStreams y cuándo entra en vigor?
El parámetro maxPeerVideoStreams se introdujo por primera vez en la versión 2.3 de CMS. Este parámetro determina el número de transmisiones de vídeo de participantes que un servidor CMS puede enviar a través de una llamada distribuida a otro servidor CMS. Debe configurarse en cada servidor CMS por separado. El parámetro maxPeerVideoStreams es efectivo para una conferencia grande y distribuida cuando hay más de 4 participantes en cada CallBridge.
Si no se establece maxPeerVideoStreams, el comportamiento predeterminado de CMS es enviar un máximo de 4 transmisiones de vídeo a través de una llamada distribuida al otro servidor CMS; este era el comportamiento anterior a CMS 2.3. Con CMS 2.3 y superior, ahora es posible cambiar ese comportamiento y configurar CMS para enviar un máximo de 9 transmisiones de vídeo a través de la llamada distribuida en lugar de solo 4.
Esta importancia de este parámetro se hace más evidente con las grandes conferencias, que alojan a un gran número de participantes, y con el uso de un diseño AllEqual, que permite mostrar un máximo de 25 paneles en la pantalla de un solo participante. En este caso, si una conferencia se distribuye a través de dos servidores CMS (por ejemplo, CMS1 y CMS2) y hay más de 4 participantes alojados en cada servidor CMS para esta conferencia (5 o más), los participantes alojados en CMS1 solo podrán ver el vídeo de un máximo de 4 participantes de los participantes remotos alojados en CMS2, además del vídeo de todos los demás participantes locales alojados en su host de servidor CMS local (CMS1), incluso si CMS2 tiene 8 participantes activos actualmente. Lo mismo se aplica a los participantes alojados en CMS2: solo pueden ver el vídeo de un máximo de 4 participantes de los participantes remotos alojados en CMS1 y el vídeo de los otros participantes alojados en el mismo CMS2, incluso si CMS1 tiene 10 participantes activos.
Ejemplo de implementación y escenarios
La información de este documento se basa en este ejemplo de implementación:
- Clúster CMS de dos servidores, CMS1 y CMS2
- El límite de carga configurado en esos servidores permite 17 llamadas, después de que se inicie la distribución de llamadas
- El grupo de rutas de CUCM para los servidores CMS se configura con distribución circular
- Se utiliza el diseño AllEqual, o 5x5, para permitir el máximo de paneles de participantes posibles, que es 25
- 30 participantes se están uniendo a space1, que tiene una prioridad (para el equilibrio de carga) en CMS1
1. maxPeerVideoStreams establecido en 4 con loadBalancing habilitado
- Dado que se habilita el balanceo de carga y la prioridad de space1 está en CMS1, los primeros 17 participantes se unen en CMS1, hasta que alcanza su capacidad total. El próximo participante 18 se conectará a CMS2 y se creará una llamada distribuida
maxPeerVideoStreams establecido en 4 con el equilibrio de carga habilitado
- Hay 17 participantes en CMS1 (1 - 17) y 13 participantes en CMS2 (18 - 30)
- Participantes 1 - 17 ver los otros 16 participantes locales de CMS1, además de solo 4 participantes de CMS2, un total de 20 participantes se muestran en las pantallas de los participantes 1 - 17
- Participantes 18 - 30 ver los otros 12 participantes locales de CMS2, además de solo 4 participantes de CMS1, un total de 16 participantes se muestran en las pantallas de los participantes 18 - 30
- En resumen: los participantes alojados en CMS1 pueden ver 20 participantes, mientras que los alojados en CMS2 pueden ver 16 participantes en sus pantallas
2. maxPeerVideoStreams establecido en 4 con loadBalancing deshabilitado
- Dado que loadbalancing no está habilitado, los participantes se unen a la conferencia en ambos servidores CMS a partir de la segunda llamada. Esto se debe a que el grupo de ruta de CUCM está configurado en circular, lo que significa que las llamadas se envían a ambos servidores CMS secuencialmente. La llamada 1 se envía a CMS1, la llamada 2 se envía a CMS2, la llamada 3 se envía a CMS1, la llamada 4 se envía a CMS2
- Esto significa que se espera encontrar 15 participantes alojados en cada CallBridge: hay 15 participantes en CMS1 y 15 participantes en CMS2
maxPeerVideoStreams establecido en 4 con balanceo de carga deshabilitado
- Los participantes de CMS1 ven a los otros 14 participantes locales de CMS1, además de los 4 participantes de CMS2, se muestra un total de 18 participantes en las pantallas de los participantes de CMS1
- Los participantes de CMS2 ven a los otros 14 participantes locales de CMS2, además de los 4 participantes de CMS1, un total de 18 participantes se muestran en las pantallas de los participantes de CMS2
- En resumen: los participantes de CMS1 y CMS2 ven a 18 participantes en sus pantallas
3. maxPeerVideoStreams establecido en 9 con loadBalancing habilitado
- Dado que el balanceo de carga está habilitado y la prioridad de space1 está en CMS1, los participantes se unen en CMS1 hasta que alcanza su capacidad total. El próximo participante 18 se conectará a CMS2 y se creará una llamada distribuida
maxPeerVideoStreams establecido en 9 con loadBalancing habilitado
- Hay 17 participantes en CMS1 (1 - 17) y 13 participantes en CMS2 (18 - 30)
- Participantes 1 - 17 ver los otros 16 participantes locales de CMS1, además de 9 participantes de CMS2, un total de 25 participantes se muestran en las pantallas de los participantes 1 - 17
- Participantes 18 - 30 ver los otros 12 participantes locales de CMS2, además de 9 participantes de CMS1, un total de 21 participantes se muestran en las pantallas de los participantes 18 - 30
- En resumen: los participantes de CMS1 ven a 25 participantes, los de CMS2 ven a 21 en sus pantallas
4. maxPeerVideoStreams establecido en 9 con loadBalancing deshabilitado
- Dado que loadbalancing no está habilitado, los participantes se unen a la conferencia en ambos servidores CMS a partir de la segunda llamada. Esto se debe a que el grupo de ruta de CUCM está configurado en circular, lo que significa que las llamadas se envían a ambos servidores CMS secuencialmente. La llamada 1 se envía a CMS1, la llamada 2 se envía a CMS2, la llamada 3 se envía a CMS1, la llamada 4 se envía a CMS2
- Esto significa que se espera encontrar 15 participantes alojados en cada CallBridge: 15 participantes están en CMS1 y 15 participantes están en CMS2
maxPeerVideoStreams establecido en 9 con balanceo de carga deshabilitado
- Los participantes de CMS1 ven a los otros 14 participantes locales de CMS1, además de los 9 participantes de CMS2, un total de 23 participantes se muestran en las pantallas de los participantes de CMS1
- Los participantes de CMS2 ven a los otros 14 participantes locales de CMS2, además de los 9 participantes de CMS1, un total de 23 participantes se muestran en las pantallas de los participantes de CMS2
- En resumen: los participantes de CMS1 y CMS2 ven a 23 participantes en sus pantallas
Troubleshoot
Actualmente no hay información de solución de problemas específica disponible para esta configuración.
Puede utilizar la herramienta Analizador de soluciones de colaboración para el análisis de registros.
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
22-Jun-2020 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)