Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Qu'est-ce que le paramètre maxPeerVideoStreams et quand entre-t-il en vigueur ?

Exemples de déploiement et de scénarios

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

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

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

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

Dépannage

Informations connexes

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

Exigences

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 Cisco Meeting Server

Composants utilisés

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

- 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 votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Qu'est-ce que le paramètre maxPeerVideoStreams et quand entre-t-il en vigueur ?

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

Remarque : maxPeerVideoStreams est uniquement pertinent 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'était 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.

L'importance de ce paramètre devient plus évidente avec les grandes conférences, qui accueillent un grand nombre de participants et qui utilisent 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 des participants distants qui sont hébergés sur CMS2, en plus de la vidéo de tous les autres participants locaux hébergés sur leur hôte de serveur CMS local (CMS1), même si CMS2 a 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 d'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 a 10 participants actifs.

Remarque : maxPeerVideoStreams est toujours une fonctionnalité bêta (prévisualisation).

Exemples de déploiement et de scénarios

Les informations contenues dans 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 permet 17 appels, après le démarrage de cette distribution d'appels

- Le groupe de routage CUCM pour les serveurs CMS est configuré avec une distribution circulaire

- La disposition AllEqual est utilisée, ou 5x5, afin de 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é

- Comme l'équilibrage de charge est activé et que la priorité d'space1 est sur CMS1, les 17 premiers participants se joignent sur CMS1, jusqu'à ce qu'il atteigne sa pleine capacité. Le participant 18 à venir 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 des 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 la SMC2, en plus des 4 participants seulement de la SMC1, 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 leurs écrans

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

- L'équilibrage de charge n'étant pas activé, les participants rejoignent la conférence sur les deux serveurs CMS à partir du deuxième appel. En effet, le groupe de routage CUCM est défini sur circulaire, ce qui signifie que les appels sont envoyés aux deux serveurs CMS séquentiellement. 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 - il y a 15 participants sur CMS1 et 15 participants sur CMS2

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

- Les participants sur CMS1 voient les 14 autres participants locaux de CMS1, en plus des 4 participants de CMS2, un total de 18 participants sont affichés sur les écrans des participants de CMS1

- Les participants sur CMS2 voient les 14 autres participants locaux de CMS2, en plus des 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 les participants CMS2 voient tous deux 18 participants sur leurs écrans

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

- Comme l'équilibrage de charge est activé et que la priorité d'space1 est sur CMS1, les participants rejoignent CMS1 jusqu'à ce qu'il atteigne sa capacité maximale. Le participant 18 à venir 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 des 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 voient 21 participants sur leurs écrans

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

- L'équilibrage de charge n'étant pas activé, les participants rejoignent la conférence sur les deux serveurs CMS à partir du deuxième appel. En effet, le groupe de routage CUCM est défini sur circulaire, ce qui signifie que les appels sont envoyés aux deux serveurs CMS séquentiellement. 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 sont sur CMS1 et 15 participants sont sur CMS2

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

- Les participants sur 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 sur 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 les participants CMS2 voient tous deux 23 participants sur leurs écrans

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 l'analyse des journaux.

Informations connexes

- Logique d'équilibrage de charge sur Cisco Meeting Server

- Documentation de configuration CMS

- Guide de programmation CMS API et MMP