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

Introdução

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

Pré-requisitos

Requisitos

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 pressupõe que o Balanceamento de carga já esteja configurado para suas Callbridges (CB) em cluster e esteja trabalhando para chamadas diretas para esses servidores CMS (chamando diretamente para um espaço CMS existente). Isso significa que esses requisitos já estão configurados:

• Todos os servidores CMS que devem ser usados para conferência ad hoc são adicionados ao CUCM > Recursos de Mídia > Ponte de Conferência e sã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 no MRGL
• Uma lista de rotas contendo 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

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.

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

Observação: há três métodos principais de adicionar um participante a uma conferência CMS existente: adicionar um participante via API, adicionar um participante via Controle Ativo e adicionar um participante sem Controle Ativo.

1. Adicionar um participante via API

Para usar esse método, LoadbalanceOutgoingCalls no grupo Callbridge precisa ser habilitado.

Para adicionar o participante usando esse método, uma solicitação API POST deve ser feita para /calls/<ative-call-id>/participant/. 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 POST .

Esta solicitação de 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 de Controle Ativo, o Controle Ativo 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 que está configurado no Tronco SIP conectando o CUCM com o CMS, para fazer isso habilitar o parâmetro Permitir mídia de aplicativo IX e observar que o Perfil SIP padrão para conferência de telepresença o habilita por padrão. Além disso, LoadbalanceOutgoingCalls no grupo Callbridge precisa ser habilitado.

Quando um participante é adicionado através do Controle Ativo a uma conferência CMS existente, o CMS1 é instruído pelo usuário (através da mensagem de controle ativo) a fazer uma chamada de saída para o novo participante. Se o valor de limite de carga configurado no CMS1 for atingido e o usuário tentar adicionar um novo participante com controle ativo, o CMS1 exibirá esta mensagem de erro (até o 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 Controle Ativo

Quando um participante é adicionado sem usar o controle ativo (portanto, Permitir mídia do aplicativo IX não está 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 o novo participante na 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 número de chamada de exemplo):

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

Essa mensagem de erro é normal e deve ser impressa por um servidor CMS quando ele recebe uma chamada e depois de atingir seu limite máximo de carga. Cabe então 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 maneira de adicionar um participante à 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 está hospedando-a

2. Depois que a conferência ad hoc for estabelecida, gradualmente o CMS1 atingirá 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

Observação: 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 ele pode ser usado até que o defeito de controle ativo seja corrigido. O Controle ativo fica desativado nessa conferência ad-hoc. 

Etapa 1. Criar 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 Name como Trunk1 non secure receiving on 5040
• Defina o modo de segurança do dispositivo como Não seguro
• Defina a porta de entrada como 5040
• Selecione Salvar

Perfil de segurança SIP do Tronco 1

Etapa 2. Criar 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 Name como Trunk2 non secure receiving on 5041
• Defina o modo de segurança do dispositivo como 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é Device > Device settings > Scripts de normalização SIP
  
• Selecione Adicionar novo
• Defina o Nome como remove_conference_from_call_info_header
• Em Content, 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. Criar um novo Perfil SIP

• Navegue até Dispositivo > Configurações do dispositivo > Perfil SIP
  
• Selecione o perfil SIP padrão para conferência de telepresença e copie.
  
• Defina o Nome como Sem conferência de telepresença de controle ativo
• 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 chamadas > Classe de controle > Partição
  
• Selecione Adicionar novo
• Defina Name como cms_adhoc_numbers
• Selecione Salvar

Etapa 6. Criar um novo CSS (Calling Search Space):

• Navegue até 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

Etapa 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 esses valores e salve

Nome de dispositivo	Insira um nome para o Tronco SIP, Tronco1
Executar em todos os nós ativos do Unified CM	Marcado
Endereço de destino	Insira o IP do próprio servidor CUCM, por exemplo 10.48.36.50
Porta de Destino	Insira a porta na qual o Tronco2 escuta, 5041
Perfil de Segurança de Tronco de SIP	Selecione o perfil criado na etapa 1, Tronco1 recepção não segura 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 SIP do Tronco 1

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 esses valores e salve

Nome de dispositivo	Insira um nome para o Tronco SIP, Tronco2
Executar em todos os nós ativos do Unified CM	Marcado
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	Insira a porta na qual o Tronco1 escuta, 5040
Perfil de Segurança de Tronco de SIP	Selecione o perfil criado na etapa 2, Tronco2 recepção não segura 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 de Tronco2

Etapa 9. Crie um novo Padrão de Rota

• Navegue até Roteamento de chamadas > Rota/busca > Padrão de Rota
  
• Selecione Adicionar novo
• Defina o Padrão de Rota para!
  
• Defina Route Partition 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 a lista de rotas/gateways como a lista de rotas do CMS que já está configurada (como mencionado na seção Requisitos anteriormente)
• Selecione Salvar

Padrão de rota

Lista de rotas de balanceamento de carga CMS

grupo de rota de balanceamento de carga CMS

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

• Navegue até Recursos de mídia > Ponte 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 destino do tronco SIP como endereço HTTPS
  
• No campo Hostname/IP Address, defina o FQDN do Webadmin do CMS 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 Trunk1 para ser usado em todos eles, no entanto, altere o campo Nome do host/Endereço IP para o FQDN do CMS específico

CMS1

CMS2

CMS3

Etapa 11. Redefinir troncos SIP Tronco1 e Tronco2

• Navegue até Dispositivo > Tronco
• Selecione Trunk1 e Trunk2
• Selecione Redefinir selecionado
• Aguarde até que os dois estejam mostrando o serviço completo

Etapa 12. Redefinir servidores CMS adhoc

• Navegue até Recursos de mídia > Conference Bridge
• Selecionar todos os servidores CMS
• Selecione Redefinir selecionado
• Aguarde até que todos os servidores apareçam como Registrados

Verificar

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

• Crie uma conferência Adhoc e verifique qual servidor CMS está hospedando a conferência

CMS1 hospedando 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 que seja 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 servidor distribuído é criado entre o CMS1 e outro servidor CMS, pois o CMS1 atingiu seu limite

Chamada distribuída

Troubleshooting

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

Você pode usar a ferramenta Collaboration Solutions Analyzer 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