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

Options de téléchargement

  • PDF     (336.6 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (208.5 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (143.9 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:28 octobre 2020
ID du document:215666

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    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

    Historique de révision

    Révision Date de publication Commentaires
    1.0
    22-Jun-2020
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Nart Omat
      Ingénieur TAC Cisco
    • Edité par Lidiya Bogdanova
      Ingénieur TAC Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits