Comportement prévu quand l'utilisation du paramter de maxPeerVideoStreams dans le CMS groupe

Introduction

Ce document décrit le comportement prévu des maxPeerVideoStreams de parmater quand il est utilisé à Cisco rencontrant la batterie du serveur (CMS). 

Ce paramètre est mentionné du guide de référence rapide d'administrateur. 

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco rencontrant le serveur appellent le composant de passerelle (et le groupement de lui)
• Cisco rencontrant la configuration du serveur API

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Quel est le paramètre de maxPeerVideoStreams et quand fait il entré dans effectue ?

Le paramètre de maxPeerVideoStreams a été introduit la première fois dans la version 2.3 CMS. Ce paramètre régit combien de flux vidéos de participant mettent en boîte un serveur CMS envoient au-dessus d'un appel distribué à un autre serveur CMS. Il doit être placé sur chaque serveur CMS séparément. Le paramètre de maxPeerVideoStreams est efficace pour un grand, distribué, conférence quand il y a plus de 4 participants sur chaque CallBridge.

Remarque: Les maxPeerVideoStreams est seulement approprié dans une batterie CMS de deux serveurs ou plus, il n'est pas approprié avec un serveur simple CMS. 

Si des maxPeerVideoStreams n'est pas placés, le comportement par défaut du CMS est d'envoyer un maximum de 4 flux vidéos au-dessus d'un appel distribué à l'autre serveur CMS, ceci était le comportement avant CMS 2.3. Avec CMS 2.3 et plus élevé, il est maintenant possible de changer ce comportement et de configurer le CMS pour envoyer un maximum de 9 flux vidéos au-dessus de l'appel distribué au lieu seulement de 4.

Cette importance de ce paramètre devient plus claire avec de grandes conférences, accueillant un grand nombre de participants, et utilisant un affichage d'AllEqual, qui tient compte d'un maximum de 25 volets à afficher sur l'écran d'un participant simple. Dans ce cas, si une conférence est répartie sur deux serveurs CMS (par exemple CMS1 et CMS2), et 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 peuvent seulement voir le vidéo d'un maximum de 4 participants des participants distants qui sont hébergés sur CMS2, comme ajout au vidéo de tous autres participants locaux hébergés sur leur hôte de serveur CMS de gens du pays (CMS1), même si CMS2 a 8 participants actifs actuellement. Le même s'applique pour des participants hébergés sur CMS2 - elles peuvent seulement voir le vidéo d'un maximum de 4 participants des participants distants hébergés sur CMS1 et le vidéo des autres participants hébergés sur le même CMS2, même si CMS1 a 10 participants actifs.

Remarque: Les maxPeerVideoStreams est toujours une bêta caractéristique (d'aperçu). 

Déploiement et scénarios d'exemple

Les informations dans ce document sont basées sur ce déploiement d'exemple :

• Batterie CMS de deux serveurs, CMS1 et CMS2
• Le Loadlimit configuré sur ces serveurs tient compte de 17 appels, ensuite des débuts de cette distribution d'appel
• Le groupe d'artère CUCM pour les serveurs CMS est configuré avec la distribution circulaire
• L'affichage d'AllEqual est utilisé, ou 5x5, ceci est de permettre aux participants possibles maximum des volets, qui est 25
• 30 participants joignent space1, qui a une priorité (pour loadbalancing) sur CMS1

1. maxPeerVideoStreams réglés à 4 avec loadBalancing activés

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

maxPeerVideoStreams réglés à 4 avec loadbalancing activés

• Il y a 17 participants sur CMS1 (1 – 17), et 13 participants sur CMS2 (18 – 30)  
• Participants 1 – 17 voyez 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
• Participants 18 – 30 voyez 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 CMS1-hosted voient 20 participants, des participants CMS2-hosted voient 16 participants sur leurs écrans

2. maxPeerVideoStreams réglés à 4 avec loadBalancing désactivés

• Puisque loadbalancing n'est pas activé, les participants joignent la conférence sur les deux serveurs CMS à partir du deuxième appel. C'est parce que le groupe d'artère CUCM est placé à la circulaire, ainsi il signifie que des 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
• Ceci signifie qu'on s'attend à ce qu'il trouve 15 participants hébergés sur chaque CallBridge - il y a 15 participants sur CMS1 et 15 participants sur CMS2

maxPeerVideoStreams réglés à 4 avec loadbalancing désactivés

• Les participants sur 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 CMS1
• Les participants sur 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 CMS2
• En résumé : Les participants CMS1 et CMS2 les participants chacun des deux voient 18 participants sur leurs écrans

3. maxPeerVideoStreams réglés à 9 avec loadBalancing activés

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

maxPeerVideoStreams réglés à 9 avec loadBalancing activés

• Il y a 17 participants sur CMS1 (1 – 17), et 13 participants sur CMS2 (18 – 30)  
• Participants 1 – 17 voyez les 16 autres participants locaux de CMS1, en plus de 9 participants de CMS2, un total de 25 participants sont affichés sur les écrans des participants 1 – 17
• Participants 18 – 30 voyez 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 voient 21 participants sur leurs écrans

4. maxPeerVideoStreams réglés à 9 avec loadBalancing désactivés

• Puisque loadbalancing n'est pas activé, les participants joignent la conférence sur les deux serveurs CMS à partir du deuxième appel. C'est parce que le groupe d'artère CUCM est placé à la circulaire, ainsi il signifie que des 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 envoyé à CMS2
• Ceci signifie qu'on s'attend à ce qu'il trouve 15 participants hébergés sur chaque CallBridge - 15 participants sont sur CMS1 et 15 participants sont sur CMS2

maxPeerVideoStreams réglés à 9 avec loadbalancing désactivés

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

Dépanner

Il n'y a actuellement aucun specifictroubleshootinginformation disponible pour cette configuration.

Vous pouvez utiliser l'outil d'analyseur de solutions de Collaboration pour l'analyse de log.

Informations connexes

• Logique d'Équilibrage de charge sur Cisco rencontrant le serveur
• Documentation basée sur la configuration CMS
• Guides de programmation CMS API et MMP