Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

¿Cuál es el parámetro maxPeerVideoStreams y cuándo entra en vigor?

Implementación y escenarios de ejemplo

1. maxPeerVideoStreams establecido en 4 con loadBalancing habilitado

2. maxPeerVideoStreams establecido en 4 con loadBalancing desactivado

3. maxPeerVideoStreams establecido en 9 con loadBalancing habilitado

4. maxPeerVideoStreams establecido en 9 con loadBalancing desactivado

Troubleshoot

Información Relacionada

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 del Administrador.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- componente Call Bridge de Cisco Meeting Server (y agrupación en clúster)

- 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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

¿Cuál 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 rige el número de secuencias 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.

Nota: El maxPeerVideoStreams sólo es relevante en un clúster CMS de dos o más servidores, no es relevante con un único servidor CMS.

Si maxPeerVideoStreams no se establece, 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 fue el comportamiento anterior a CMS 2.3. Con CMS 2.3 y superiores, 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 sólo 4.

Esta importancia de este parámetro se hace más clara con las grandes conferencias, que albergan a un gran número de participantes y utilizan 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 en 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 sólo pueden ver el vídeo desde un máximo de 4 participantes de los participantes remotos alojados en CMS2, como complemento del vídeo de todos los demás participantes locales alojados en su CMS local (CMS1) servidor, 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 participantes remotos alojados en CMS1 y el vídeo de los demás participantes alojados en el mismo CMS2, aunque CMS1 tenga 10 participantes activos.

Nota: El maxPeerVideoStreams sigue siendo una función beta (vista previa).

Implementación y escenarios de ejemplo

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 la llamada

- El grupo de rutas CUCM para los servidores CMS se configura con distribución circular

- Se utiliza la disposición AllEqual, o 5x5, para permitir el máximo de paneles de participantes posibles, que es 25

- 30 participantes se están uniendo al espacio1, que tiene una prioridad (para el balanceo de carga) en el CMS1

1. maxPeerVideoStreams establecido en 4 con loadBalancing habilitado

- Dado que el balanceo de carga está habilitado y la prioridad del espacio1 está en CMS1, los primeros 17 participantes se unen a CMS1, hasta que alcance su plena capacidad. El participante 18 próximo se une a CMS2 y se crea una llamada distribuida

maxPeerVideoStreams establecido en 4 con el balanceo de carga habilitado

- Hay 17 participantes en CMS1 (1 a 17) y 13 participantes en CMS2 (18 a 30)

- Participantes 1 - 17 ver los otros 16 participantes locales de CMS1, además de sólo 4 participantes de CMS2, se muestra un total de 20 participantes en las pantallas de los participantes 1 - 17

- Participantes 18 - 30 ver los otros 12 participantes locales de CMS2, además de sólo 4 participantes de CMS1, se muestra un total de 16 participantes en las pantallas de los participantes 18 - 30

- En resumen: Los participantes alojados en CMS1 pueden ver a 20 participantes; los participantes alojados en CMS2 pueden ver a 16 participantes en sus pantallas

2. maxPeerVideoStreams establecido en 4 con loadBalancing desactivado

- Dado que el balanceo de carga 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 rutas 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 a CMS2, la llamada 3 a CMS1, la llamada 4 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 el balanceo de carga desactivado

- Los participantes en CMS1 verán los otros 14 participantes locales de CMS1, además de 4 participantes de CMS2, se muestra un total de 18 participantes en las pantallas de los participantes de CMS1

- Los participantes en CMS2 verán los otros 14 participantes locales de CMS2, además de 4 participantes de CMS1, se muestra un total de 18 participantes en las pantallas de los participantes de CMS2

- En resumen: Los participantes en CMS1 y los participantes en 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 espacio1 está en CMS1, los participantes se unen a CMS1 hasta que alcance su plena capacidad. El participante 18 próximo se une a CMS2 y se crea una llamada distribuida

maxPeerVideoStreams establecido en 9 con loadBalancing habilitado

- Hay 17 participantes en CMS1 (1 a 17) y 13 participantes en CMS2 (18 a 30)

- Participantes 1 - 17 ver los otros 16 participantes locales de CMS1, además de 9 participantes de CMS2, se muestra un total de 25 participantes 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, se muestra un total de 21 participantes en las pantallas de los participantes 18 - 30

- En resumen: Los participantes de CMS1 ven a 25 participantes, los participantes de CMS2 ven a 21 participantes en sus pantallas

4. maxPeerVideoStreams establecido en 9 con loadBalancing desactivado

- Dado que el balanceo de carga 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 rutas 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 a CMS2, la llamada 3 a CMS1, la llamada 4 a CMS2

- Esto significa que se espera encontrar 15 participantes alojados en cada CallBridge: 15 participantes están en CMS1 y 15 participantes en CMS2

maxPeerVideoStreams establecido en 9 con el balanceo de carga desactivado

- Los participantes en CMS1 verán los otros 14 participantes locales de CMS1, además de 9 participantes de CMS2, se muestra un total de 23 participantes en las pantallas de los participantes de CMS1

- Los participantes en CMS2 verán los otros 14 participantes locales de CMS2, además de 9 participantes de CMS1, se muestra un total de 23 participantes en las pantallas de los participantes de CMS2

- En resumen: Los participantes en CMS1 y los participantes en CMS2 ven 23 participantes en sus pantallas

Troubleshoot

Actualmente no hay información específica de resolución de problemas disponible para esta configuración.

Puede utilizar la herramienta Collaboration Solutions Analyser para el análisis de registros.

Información Relacionada

- Lógica de equilibrio de carga en Cisco Meeting Server

- documentación de configuración de CMS

- Guías de programación de MMP y API de CMS