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

Options de téléchargement

  • PDF     (183.3 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (179.1 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (144.3 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

    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

    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.

    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.

    Note: 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.

    Note: 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

    TAC Authored

    Contribution d’experts de Cisco

    • Nart Omat
      Cisco TAC Engineer
    • Edited by Lidiya Bogdanova
      Cisco TAC Engineer

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits