Comportement attendu lors de l'utilisation du paramètre maxPeerVideoStreams dans les clusters CMS

Introduction

Ce document décrit le comportement attendu du paramètre maxPeerVideoStreams lorsqu'il est utilisé dans un cluster Cisco Meeting Server (CMS). 

Ce paramètre est mentionné dans le Guide de référence rapide de l'administrateur. 

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Composant Cisco Meeting Server Call Bridge (et mise en grappe de celui-ci)
• Configuration de l'API de Cisco Meeting Server

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• CMS 2.9.x

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Quel est le paramètre maxPeerVideoStreams et quand est-ce qu'il entre en vigueur ?

Le paramètre maxPeerVideoStreams a été introduit pour la première fois dans CMS version 2.3. Ce paramètre détermine le nombre de flux vidéo de participants qu'un serveur CMS peut envoyer via un appel distribué à un autre serveur CMS. Il doit être défini séparément sur chaque serveur CMS. Le paramètre maxPeerVideoStreams est effectif pour une conférence distribuée de grande taille lorsqu'il y a plus de 4 participants sur chaque pont d'appel.

Remarque: Le maxPeerVideoStreams n'est pertinent que dans un cluster CMS de deux serveurs ou plus, il n'est pas pertinent avec un seul serveur CMS. 

Si maxPeerVideoStreams n'est pas défini, le comportement par défaut de CMS est d'envoyer un maximum de 4 flux vidéo sur un appel distribué à l'autre serveur CMS, c'est le comportement antérieur à CMS 2.3. Avec CMS 2.3 et versions ultérieures, il est désormais possible de modifier ce comportement et de configurer CMS pour envoyer un maximum de 9 flux vidéo sur l'appel distribué au lieu de seulement 4.

Cette importance de ce paramètre devient plus claire avec les grandes conférences, qui accueillent un grand nombre de participants, et en utilisant une disposition AllEqual, qui permet d'afficher un maximum de 25 volets sur l'écran d'un seul participant. Dans ce cas, si une conférence est distribuée sur deux serveurs CMS (par exemple CMS1 et CMS2) et que plus de 4 participants sont hébergés sur chaque serveur CMS pour cette conférence (5 ou plus), les participants hébergés sur CMS1 ne peuvent voir la vidéo que depuis un maximum de 4 participants à distance hébergés sur CMS2, en plus de la vidéo de tous les autres participants locaux hébergés sur leur CMS1 local hôte serveur, même si CMS2 compte actuellement 8 participants actifs. Il en va de même pour les participants hébergés sur CMS2. Ils ne peuvent voir la vidéo que depuis un maximum de 4 participants des participants distants hébergés sur CMS1 et la vidéo des autres participants hébergés sur le même CMS2, même si CMS1 compte 10 participants actifs.

Remarque: Le maxPeerVideoStreams est toujours une fonctionnalité bêta (preview). 

Exemple de déploiement et de scénarios

Les informations de ce document sont basées sur cet exemple de déploiement :

• Cluster CMS de deux serveurs, CMS1 et CMS2
• La limite de charge configurée sur ces serveurs autorise 17 appels, après le démarrage de la distribution des appels
• Le groupe de routage CUCM pour les serveurs CMS est configuré avec une distribution circulaire
• La disposition AllEqual est utilisée, ou 5x5, pour permettre le maximum de volets participants possibles, soit 25
• 30 participants rejoignent space1, qui a une priorité (pour l'équilibrage de charge) sur CMS1

1. maxPeerVideoStreams défini sur 4 avec loadBalancing activé

• Puisque l'équilibrage de charge est activé et que la priorité de space1 est sur CMS1, les 17 premiers participants se joignent à CMS1, jusqu'à ce qu'il atteigne sa pleine capacité. Le prochain participant 18 se joint à CMS2 et un appel distribué est créé

maxPeerVideoStreams défini sur 4 avec équilibrage de charge activé

• Il y a 17 participants sur CMS1 (1 à 17) et 13 participants sur CMS2 (18 à 30)  
• Les participants 1 à 17 voient les 16 autres participants locaux de CMS1, en plus de seulement 4 participants de CMS2, un total de 20 participants sont affichés sur les écrans des participants 1 à 17
• Les participants 18 à 30 voient les 12 autres participants locaux de CMS2, en plus de seulement 4 participants de CMS1, un total de 16 participants sont affichés sur les écrans des participants 18 à 30
• En résumé : Les participants hébergés par CMS1 voient 20 participants, les participants hébergés par CMS2 voient 16 participants sur leur écran

2. maxPeerVideoStreams défini sur 4 avec loadBalancing désactivé

• Comme l'équilibrage de charge n'est pas activé, les participants rejoignent la conférence sur les deux serveurs CMS à partir du deuxième appel. Ceci est dû au fait que le groupe de routage CUCM est défini sur circulaire, ce qui signifie que les appels sont envoyés aux deux serveurs CMS de manière séquentielle. L'appel 1 est envoyé à CMS1, l'appel 2 est envoyé à CMS2, l'appel 3 est envoyé à CMS1, l'appel 4 est envoyé à CMS2
• Cela signifie qu'il est prévu de trouver 15 participants hébergés sur chaque CallBridge : 15 participants sur CMS1 et 15 participants sur CMS2

maxPeerVideoStreams défini sur 4 avec équilibrage de charge désactivé

• Les participants de CMS1 voient les 14 autres participants locaux de CMS1, en plus de 4 participants de CMS2, un total de 18 participants sont affichés sur les écrans des participants de CMS1
• Les participants de CMS2 voient les 14 autres participants locaux de CMS2, en plus de 4 participants de CMS1, un total de 18 participants sont affichés sur les écrans des participants de CMS2
• En résumé : Les participants CMS1 et CMS2 voient 18 participants sur leur écran

3. maxPeerVideoStreams défini sur 9 avec loadBalancing activé

• Comme l'équilibrage de charge est activé et que la priorité de space1 est sur CMS1, les participants se joignent à CMS1 jusqu'à ce qu'il atteigne sa pleine capacité. Le prochain participant 18 se joint à CMS2 et un appel distribué est créé

maxPeerVideoStreams défini sur 9 avec loadBalancing activé

• Il y a 17 participants sur CMS1 (1 à 17) et 13 participants sur CMS2 (18 à 30)  
• Les participants 1 à 17 voient les 16 autres participants locaux de CMS1, en plus des 9 participants de CMS2, un total de 25 participants sont affichés sur les écrans des participants 1 à 17
• Les participants 18 à 30 voient les 12 autres participants locaux de CMS2, en plus de 9 participants de CMS1, un total de 21 participants sont affichés sur les écrans des participants 18 à 30
• En résumé : Les participants CMS1 voient 25 participants, les participants CMS2 21 participants sur leurs écrans

4. maxPeerVideoStreams défini sur 9 avec loadBalancing désactivé

• Comme l'équilibrage de charge n'est pas activé, les participants rejoignent la conférence sur les deux serveurs CMS à partir du deuxième appel. Ceci est dû au fait que le groupe de routage CUCM est défini sur circulaire, ce qui signifie que les appels sont envoyés aux deux serveurs CMS de manière séquentielle. L'appel 1 est envoyé à CMS1, l'appel 2 à CMS2, l'appel 3 à CMS1 et l'appel 4 à CMS2
• Cela signifie qu'il est prévu de trouver 15 participants hébergés sur chaque CallBridge - 15 participants sont sur CMS1 et 15 participants sur CMS2

maxPeerVideoStreams défini sur 9 avec équilibrage de charge désactivé

• Les participants de CMS1 voient les 14 autres participants locaux de CMS1, en plus des 9 participants de CMS2, un total de 23 participants sont affichés sur les écrans des participants de CMS1
• Les participants de CMS2 voient les 14 autres participants locaux de CMS2, en plus des 9 participants de CMS1, un total de 23 participants sont affichés sur les écrans des participants de CMS2
• En résumé : Les participants CMS1 et CMS2 voient 23 participants sur leur écran

Dépannage

Aucune information de dépannage spécifique n'est actuellement disponible pour cette configuration.

Vous pouvez utiliser l'outil Collaboration Solutions Analyzer pour analyser les journaux.

Informations connexes

• Logique d'équilibrage de charge sur Cisco Meeting Server
• Documentation de configuration CMS
• API CMS et guides de programmation MMP