Comportamento Esperado ao Usar o Parâmetro maxPeerVideoStreams em Clusters CMS
Contents
Introdução
Este documento descreve o comportamento esperado do parâmetro maxPeerVideoStreams quando ele é usado em um cluster do Cisco Meeting Server (CMS).
Esse parâmetro é mencionado no Guia de referência rápida do administrador.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Componente Call Bridge do Cisco Meeting Server (e sua organização por clusters)
- Configuração da API do Cisco Meeting Server
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- CMS 2.9.x
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
O que é o parâmetro maxPeerVideoStreams e quando ele entra em vigor?
O parâmetro maxPeerVideoStreams foi introduzido pela primeira vez na versão 2.3 do CMS. Esse parâmetro determina quantos fluxos de vídeo de participantes um servidor CMS pode enviar por uma chamada distribuída para outro servidor CMS. Ele precisa ser definido em cada servidor CMS separadamente. O parâmetro maxPeerVideoStreams é eficaz para uma conferência grande e distribuída quando há mais de 4 participantes em cada CallBridge.
Se maxPeerVideoStreams não estiver definido, o comportamento padrão do CMS é enviar um máximo de 4 fluxos de vídeo em uma chamada distribuída para o outro servidor CMS, esse foi o comportamento anterior ao CMS 2.3. Com o CMS 2.3 e posterior, agora é possível alterar esse comportamento e configurar o CMS para enviar um máximo de 9 fluxos de vídeo sobre a chamada distribuída em vez de apenas 4.
Essa importância desse parâmetro se torna mais clara com conferências grandes, hospedando um grande número de participantes e usando um layout AllEqual, que permite a exibição de um máximo de 25 painéis na tela de um único participante. Neste caso, se uma conferência for distribuída através de dois servidores CMS (por exemplo, CMS1 e CMS2) e mais de 4 participantes forem hospedados em cada servidor CMS para esta conferência (5 ou mais), os participantes hospedados no CMS1 só poderão ver o vídeo de um máximo de 4 participantes dos participantes remotos hospedados no CMS2, além do vídeo de todos os outros participantes locais hospedados em seu servidor CMS1 local, mesmo que o CMS2 tenha 8 participantes ativos atualmente. O mesmo se aplica aos participantes alojados no CMS2 - só podem ver o vídeo de um máximo de 4 participantes dos participantes remotos alojados no CMS1 e o vídeo dos outros participantes alojados no mesmo CMS2, mesmo que o CMS1 tenha 10 participantes ativos.
Exemplo de implantação e cenários
As informações neste documento são baseadas neste exemplo de implantação:
- Cluster de dois servidores CMS1 e CMS2
- O Loadlimit configurado nesses servidores permite 17 chamadas, após o início da distribuição da chamada
- O grupo de rota do CUCM para os servidores CMS está configurado com distribuição circular
- O layout AllEqual é usado, ou 5x5, para permitir o máximo possível de painéis de participantes, que é 25
- 30 participantes estão ingressando no space1, que tem uma prioridade (para balanceamento de carga) no CMS1
1. maxPeerVideoStreams definido como 4 com loadBalancing habilitado
- Como o balanceamento de carga está habilitado e a prioridade de space1 está no CMS1, os primeiros 17 participantes participam do CMS1, até que ele atinja sua capacidade total. O próximo participante 18 ingressa no CMS2 e uma chamada distribuída é criada
maxPeerVideoStreams definido como 4 com balanceamento de carga habilitado
- Há 17 participantes no CMS1 (1 - 17) e 13 participantes no CMS2 (18 - 30)
- Os participantes 1 - 17 veem os outros 16 participantes locais do CMS1, além de apenas 4 participantes do CMS2, um total de 20 participantes são exibidos nas telas dos participantes 1 - 17
- Os participantes 18 - 30 veem os outros 12 participantes locais do CMS2, além de apenas 4 participantes do CMS1, um total de 16 participantes são exibidos nas telas dos participantes 18 - 30
- Em resumo: os participantes hospedados no CMS1 veem 20 participantes, os participantes hospedados no CMS2 veem 16 participantes em suas telas
2. maxPeerVideoStreams definido como 4 com loadBalancing desabilitado
- Como o balanceamento de carga não está habilitado, os participantes ingressam na conferência em ambos os servidores CMS a partir da segunda chamada. Isso ocorre porque o grupo de rota do CUCM está definido como circular, o que significa que as chamadas são enviadas para ambos os servidores CMS sequencialmente. A chamada 1 é enviada ao CMS1, a chamada 2 é enviada ao CMS2, a chamada 3 é enviada ao CMS1, a chamada 4 é enviada ao CMS2
- Isso significa que se espera encontrar 15 participantes hospedados em cada CallBridge - há 15 participantes no CMS1 e 15 participantes no CMS2
maxPeerVideoStreams definido como 4 com balanceamento de carga desabilitado
- Os participantes no CMS1 veem os outros 14 participantes locais do CMS1, além de 4 participantes do CMS2, um total de 18 participantes são exibidos nas telas dos participantes do CMS1
- Os participantes no CMS2 veem os outros 14 participantes locais do CMS2, para além dos 4 participantes do CMS1, é apresentado um total de 18 participantes nas telas dos participantes do CMS2
- Resumindo: os participantes do CMS1 e do CMS2 veem 18 participantes em suas telas
3. maxPeerVideoStreams definido como 9 com loadBalancing habilitado
- Como o balanceamento de carga está habilitado e a prioridade de space1 está no CMS1, os participantes ingressam no CMS1 até que ele atinja sua capacidade total. O próximo participante 18 ingressa no CMS2 e uma chamada distribuída é criada
maxPeerVideoStreams definido como 9 com loadBalancing habilitado
- Há 17 participantes no CMS1 (1 - 17) e 13 participantes no CMS2 (18 - 30)
- Os participantes 1 - 17 veem os outros 16 participantes locais do CMS1, além de 9 participantes do CMS2, um total de 25 participantes são exibidos nas telas dos participantes 1 - 17
- Os participantes 18 - 30 veem os outros 12 participantes locais do CMS2, além de 9 participantes do CMS1, um total de 21 participantes são exibidos nas telas dos participantes 18 - 30
- Em resumo: os participantes do CMS1 veem 25 participantes, os participantes do CMS2 veem 21 participantes em suas telas
4. maxPeerVideoStreams definido como 9 com loadBalancing desabilitado
- Como o balanceamento de carga não está habilitado, os participantes ingressam na conferência em ambos os servidores CMS a partir da segunda chamada. Isso ocorre porque o grupo de rota do CUCM está definido como circular, o que significa que as chamadas são enviadas para ambos os servidores CMS sequencialmente. A chamada 1 é enviada ao CMS1, a chamada 2 é enviada ao CMS2, a chamada 3 é enviada ao CMS1, a chamada 4 é enviada ao CMS2
- Isso significa que se espera encontrar 15 participantes hospedados em cada CallBridge - 15 participantes estão no CMS1 e 15 participantes estão no CMS2
maxPeerVideoStreams definido como 9 com balanceamento de carga desabilitado
- Os participantes no CMS1 veem os outros 14 participantes locais do CMS1, além de 9 participantes do CMS2, um total de 23 participantes são exibidos nas telas dos participantes do CMS1
- Os participantes no CMS2 veem os outros 14 participantes locais do CMS2, para além de 9 participantes do CMS1, é apresentado um total de 23 participantes nas telas dos participantes do CMS2
- Resumindo: os participantes do CMS1 e do CMS2 veem 23 participantes em suas telas
Troubleshooting
No momento, não há informações específicas de solução de problemas disponíveis para esta configuração.
Você pode usar a ferramenta Collaboration Solutions Analyzer para análise de log.
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
22-Jun-2020 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)