Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

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

Configurar

Verificar

Troubleshoot

Informações Relacionadas

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