Adicionar participantes à conferência ou espaço existente na implantação do cluster CMS com balanceamento de carga habilitado

Introduction

Este documento descreve como adicionar participantes a uma conferência CMS existente na implantação de CMS em cluster com balanceamento de carga ativado.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Balanceamento de carga do CMS (Cisco Meeting Server)
• Conferência ad-hoc do CUCM (Cisco Unified Communications Manager)

Este documento supõe que o Balanceamento de carga já está configurado para suas Callbridges (CB) em cluster e funcionando para chamadas diretas para esses servidores CMS (ligando diretamente para um espaço CMS existente). Isso significa que esses requisitos já estão configurados:

• Todos os servidores CMS a serem usados para conferências ad hoc são adicionados ao CUCM > Recursos de mídia > recurso de conferência e estão registrados
• Uma Lista de grupos de recursos de mídia (MRGL) que contém um grupo de recursos de mídia (MRG) é criada e tem apenas os servidores CMS e é o primeiro grupo na MRGL
• Uma Lista de Rotas que contém um grupo de Rotas é criada e tem os servidores CMS, e o algoritmo de distribuição selecionado é Circular

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• CMS 2.9.1
• CUCM 12.5.1

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Métodos para adicionar participantes à conferência CMS existente

Note: Há três métodos principais de adicionar um participante a uma conferência CMS existente: adicione um participante via API, adicione um participante via Ative Control e adicione um participante sem Ative Control.

1. Adicionar um participante via API

Para usar esse método, LoadbalanceOutgoingCalls no Grupo Callbridge deve ser ativado.

Para adicionar o participante usando este método, uma solicitação POST de API deve ser feita para /calls/<ative-call-id>/participantes/. A solicitação POST precisa incluir o ID do participante do participante que está sendo adicionado à conferência como valor do parâmetro remoteParty, que faz parte dessa solicitação.

Esta solicitação POST instrui o CMS a fazer uma chamada de saída para o participante que está sendo adicionado. Se LoadbalanceOutgoingCalls no Grupo Callbridge estiver habilitado e se o CMS tiver atingido seu limite de carga, ele encontrará um servidor CMS livre no cluster para fazer uma chamada de saída para o participante que está sendo adicionado, e uma chamada distribuída será criada entre os dois servidores. Este é o mesmo método usado pelo CMM para adicionar participantes a uma conferência do CMS.

2. Adicionar um participante via Controle ativo

Para usar a adição de participante do Ative Control, o Ative Control deve ser negociado primeiro entre o servidor do CMS e o usuário que está adicionando o participante.

Você precisa habilitar o Controle Ativo no Perfil de Tronco SIP configurado no Tronco SIP conectando o CUCM ao CMS, para habilitar o parâmetro Permitir mídia de aplicativo IX, e observe que o Perfil SIP Padrão para TelePresence Conferencing tem esse recurso ativado por padrão. Além disso, LoadbalanceOutgoingCalls no grupo Callbridge deve ser ativado.

Quando um participante é adicionado via Controle Ativo a uma conferência CMS existente, o CMS1 é instruído pelo usuário (por meio de mensagem de controle ativo) a fazer uma chamada de saída para o novo participante. Se o valor limite de carga configurado no CMS1 for alcançado e o usuário tentar adicionar um novo participante com controle ativo, o CMS1 exibirá esta mensagem de erro (até CMS versão 2.9.1):

add participant "<participant-uri>" request failed: call bridge unavailable

Isso se aplica a ambos os casos de uso - quando o participante é adicionado a uma conferência ad hoc e quando é adicionado a um espaço CMS existente por meio do controle ativo. 

Este é um comportamento defeituoso e está sendo rastreado sob o defeito:  CSCvu72374

3. Adicionar um participante sem o Ative Control

Quando um participante é adicionado sem usar controle ativo (portanto, Permitir mídia de aplicativo IX não habilitado no Perfil SIP), o CUCM faz uma chamada entre o usuário que está iniciando a ação e o novo participante. Em seguida, quando o usuário estiver pronto para ingressar no novo participante da conferência, o CUCM fará uma chamada de saída para a conferência ad hoc em execução no CMS1. Se o limite de carga for atingido no CMS1, o participante não poderá ser adicionado e o CMS1 exibirá esta mensagem de erro (55 é um exemplo de número de chamada):

call 55: ending; local teardown, system participant limit reached - not connected after 0:00

Essa mensagem de erro é uma mensagem de erro normal a ser impressa por um servidor CMS quando ele recebe uma chamada e depois de atingir seu limite máximo de carga. Em seguida, cabe ao servidor de controle de chamadas (CUCM ou VCS) continuar roteando a chamada para outros membros no cluster. No entanto, no caso de uma conferência ad hoc, isso não funciona e não é possível, pois o CUCM não tem uma lista de rotas para conferências ad hoc.

Configurar

Este documento fornece as etapas de configuração necessárias para usar a terceira forma de adicionar participantes à conferência existente (Adicionar um participante sem Controle Ativo).

O comportamento abordado com as etapas de configuração neste documento é:

1. O usuário cria uma conferência ad hoc, o servidor CMS1 a hospeda

2. Depois que a conferência ad hoc é estabelecida, gradualmente o CMS1 alcança seu limite de carga configurado (configurado sobre API em /system/configuration/cluster)

3. O usuário tenta adicionar um novo participante à conferência ad hoc em andamento, mas o novo usuário não se conecta à conferência

Note: Este procedimento de configuração permite que um usuário adicione participantes a uma conferência adhoc CMS existente, mesmo que o servidor CMS que hospeda a conferência adhoc tenha atingido seu limite de carga e possa ser usado até que o defeito de controle ativo seja corrigido. O Controle Ativo torna-se desativado nessa conferência ad-hoc. 

Etapa 1.  Crie um novo Perfil de Segurança de Tronco SIP para Tronco1

• Navegue até Sistema > Segurança > Perfil de Segurança de Tronco de SIP
  
• Selecione Adicionar novo
• Defina o nome como Tronco1 não seguro recebendo no 5040
• Defina o modo de segurança do dispositivo para Não seguro
• Defina a porta de entrada como 5040
• Selecione Salvar

Perfil de segurança SIP do Tronco1

Etapa 2.  Crie um novo Perfil de Segurança de Tronco SIP para Tronco2

• Navegue até Sistema > Segurança > Perfil de Segurança de Tronco de SIP
  
• Selecione Adicionar novo
• Defina o nome como Tronco2 não seguro para recebimento no 5041
• Defina o modo de segurança do dispositivo para Não seguro
• Defina a porta de entrada como 5041
• Selecione Salvar

Perfil de segurança SIP do Tronco2

Etapa 3.  Crie um novo Script de Normalização SIP 

• Navegue até Dispositivo > Configurações do dispositivo > Scripts de normalização SIP
  
• Selecione Adicionar novo
• Defina o nome para ser remove_conference_from_call_info_header
• No Conteúdo, use este script

M = {}
function M.outbound_INVITE(msg)
    msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>")
end
return M

• Selecione Salvar

Etapa 4.  Crie um novo perfil SIP

• Navegue até Dispositivo > Configurações do dispositivo > Perfil SIP
  
• Selecione o perfil SIP padrão para conferência de TelePresence e copie -o
  
• Defina o nome para Nenhuma conferência de telepresença de controle ativa
• Desmarque a caixa de seleção Allow iX Application Media na parte inferior da página
• Selecione Salvar

Etapa 5.  Criar uma nova partição

• Navegue até Roteamento de chamada > Classe de controle > Partição
  
• Selecione Adicionar novo
• Defina o Nome como cms_adhoc_numbers
• Selecione Salvar

Etapa 6.  Criar um novo CSS (Calling Search Space, Espaço de pesquisa de chamada):

• Navegar para Roteamento de chamada > Classe de controle > Espaço de pesquisa de chamada
  
• Selecione Adicionar novo
• Defina o nome como CMS_adhoc_numbers
• Adicione a partição criada na etapa 5 cms_adhoc_numbers
• Selecione Salvar

Configuração do Espaço de Pesquisa de Chamada

Passo 7.  Crie um novo tronco SIP, Tronco1:

• Navegue até Dispositivo > Tronco
• Selecione Adicionar novo
• Selecione Tronco SIP para Tipo de tronco
• Selecione Próximo
• Insira estes valores e Salvar

Nome de dispositivo	Insira um nome para o Tronco SIP, Tronco1
Executar em todos os nós Ative Unified CM	Verificado
Endereço de destino	Insira o IP do próprio servidor CUCM, por exemplo 10.48.36.50
Porta de Destino	Digite a porta na qual o Tronco2 escuta, 5041
Perfil de Segurança de Tronco de SIP	Selecione o perfil criado na etapa 1, Tronco1 não seguro recebido no 5040
Perfil SIP	Selecione o perfil criado na etapa 4, Sem conferência de telepresença de controle ativo
Método de sinalização DTMF	Selecione RFC 2833
Script de normalização SIP	Selecione o script criado na etapa 3, remove_conference_from_call_info_header

Configurações do SIP do Tronco1

Etapa 8.  Crie um novo tronco SIP, Tronco2:

• Navegue até Dispositivo > Tronco
• Selecione Adicionar novo
• Selecione Tronco SIP para Tipo de tronco
• Selecione Próximo
• Insira estes valores e Salvar

Nome de dispositivo	Insira um nome para o Tronco SIP, Tronco2
Executar em todos os nós Ative Unified CM	Verificado
Espaço de pesquisa de chamada	Selecione o CSS criado na etapa 6, CMS_adhoc_numbers
Endereço de destino	Insira o endereço IP ou FQDN do próprio servidor CUCM, por exemplo 10.48.36.50
Porta de Destino	Digite a porta na qual Tronco1 escuta, 5040
Perfil de Segurança de Tronco de SIP	Selecione o perfil criado na etapa 2, Tronco2 não seguro recebido no 5041
Perfil SIP	Selecione o perfil criado na etapa 4, Sem conferência de telepresença de controle ativo
Método de sinalização DTMF	Selecione RFC 2833
Script de normalização SIP	Selecione o script de normalização existente cisco-meeting-server-interop

Configurações SIP do Tronco2

Etapa 9.  Crie um novo padrão de rota

• Navegue até Roteamento de chamada > Rota/busca > Padrão de rota
  
• Selecione Adicionar novo
• Defina o Padrão de rota para!
  
• Defina a Partição de Rota para a partição criada na Etapa 5, cms_adhoc_numbers
• Ativar a caixa de seleção Prioridade urgente
• Alterar classificação de chamada para OnNet
• Defina Gateway/Route List como a CMS Route List que já está configurada (conforme mencionado na seção Requirments anteriormente)
• Selecione Salvar

Padrão de rota

lista de Rotas de Balanceamento de CMS

grupo de rota de balanceamento de carga do CMS

Etapa 10.  Modificar a configuração do CMS adhoc Conference Bridge

• Navegue até Recursos de mídia > Bridge de conferência
  
• Selecione o primeiro servidor CMS
• Alterar o Tronco SIP para Tronco1, o tronco SIP criado na etapa 7
• Ativar a caixa de seleção Substituir o destino do tronco SIP como endereço HTTPS
  
• No campo Nome do host/Endereço IP, defina o FQDN do CMS Webadmin para esse servidor CMS específico que também deve existir no certificado Webadmin desse servidor
• Selecione Salvar
• Faça o mesmo para todos os outros servidores CMS, defina Tronco1 para ser usado em todos eles, no entanto, altere o campo Nome do host/Endereço IP para o FQDN CMS específico

CMS1

CMS2

CMS3

Etapa 11.  Redefinir troncos SIP Tronco1 e Tronco2

• Navegue até Dispositivo > Tronco
• Selecione Tronco1 e Tronco2
• Selecione Redefinir selecionado
• Aguarde até que ambos estejam mostrando o serviço completo

Etapa 12.  Redefinir servidores ad hoc CMS

• Navegue até Recursos de mídia > Conference Bridge
• Selecionar todos os servidores CMS
• Selecione Redefinir selecionado
• Aguarde até que todos os servidores estejam mostrando Registrados

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

• Crie uma conferência Ad-hoc e verifique qual servidor CMS está hospedando a conferência

CMS1 que hospeda a conferência ad hoc

• Verifique a carga de processamento de mídia atual nesse servidor CMS, use um API GET para /sistema/carga

Carga de mídia atual

• Defina o limite de carga no servidor para um valor inferior à carga de processamento de mídia enviando um POST para /system/configuration/cluster com o parâmetro loadlimit, por exemplo, 1000

Alterando o limite de carga

• Adicione um novo participante à reunião. O participante é adicionado e um distribuído é criado entre o CMS1 e outro servidor CMS, já que o CMS1 atingiu seu limite

Chamada distribuída

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Você pode usar a ferramenta Collaboration Solutions Analyser para análise de log.

Informações Relacionadas

• Lógica de balanceamento de carga no Cisco Meeting Server
• documentação de configuração do CMS
• Guias de programação CMS API e MMP
• documentação de configuração do CUCM