Diretrizes de uma atualização simples do Cisco Meeting Server 2.9 para a versão 3.0 (e em diante)

Introdução

Este documento descreve os desafios de atualizar uma implantação do Cisco Meeting Server executando a versão 2.9 (ou anterior) para a versão 3.0 (ou posterior) e como lidar com eles para um processo de atualização tranquilo.

Recursos removidos: XMPP foi removido (o que afeta o WebRTC), troncos/balanceadores de carga, webbridge

Recursos alterados: gravadores e galhardetes agora são SIP e webbridge é substituído por webbridge3

Este documento abrange apenas os tópicos que você precisa considerar antes de atualizar. Ele não cobre todos os novos recursos disponíveis no 3.X.

Pré-requisitos

Requisitos

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

• administração de CMS
• Atualizações do CMS
• Criação e assinatura de certificado

Tudo o que aqui se refere está descrito em vários documentos.  É sempre aconselhável ler as notas de versão do produto e consultar nossos guias de programação e guias de implantação se precisar de mais esclarecimentos sobre os recursos: Guias de instalação e configuração do CMS e Notas de versão do produto do CMS .

Componentes Utilizados

As informações neste documento são baseadas no Cisco Meeting Server.

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.

Informações de Apoio

Este documento tem como objetivo orientar caso você já tenha uma implantação do CMS 2.9.x (ou anterior), independentemente de ser única, combinada ou resiliente, e quando planeja atualizar para o CMS 3.0.  As informações neste documento pertencem a todos os modelos de CMS.  

Observação: o X-series não pode ser atualizado para CMS 3.0. Você precisa planejar a substituição de seus servidores X-series o mais rápido possível.

Informações importantes sobre atualizações

O único método com suporte para atualizar o CMS é uma atualização em etapas.  No momento em que este documento foi escrito, o CMS 3.5 foi lançado.  Se você estiver no CMS 2.9, deverá fazer o upgrade em etapas (2.9 —> 3.0 —> 3.1 —> 3.2 —> 3.3 —> 3.4 —> 3.5 (Observe que o processo de upgrade tem alterações a partir do CMS 3.5, portanto, leia as notas de versão com atenção!!)

Se você não executar uma atualização em etapas e estiver tendo um comportamento incomum, o TAC poderá solicitar que você faça o downgrade e comece novamente.

Além disso, a partir do CMS 3.4, o CMS DEVE usar o Smart Licensing.  Você não pode atualizar para o CMS 3.4 ou mais recente e ainda usar licenças tradicionais.  Não atualize para o CMS 3.4 ou posterior, a menos que você tenha configurado o Smart Licensing.

Resumo dos itens a serem considerados

Use essas perguntas para navegar para as seções que pertencem à sua própria situação.  Cada consideração se refere a um hiperlink para uma descrição mais detalhada apresentada neste documento.

Licenças

Você tem licenças suficientes de Personal MultiParty (PMP) / Shared MultiParty (SMP) em seus servidores antes da atualização?

Na versão 3.0, as licenças PMP são alocadas, mesmo que o usuário não esteja conectado. Por exemplo, se você importou usuários 10000 por meio do LDAP, mas tem apenas 100 licenças PMP, isso o coloca fora de conformidade assim que você faz o upgrade para a versão 3.0.  Para este caso de uso, verifique se há locatários que tenham userProfile definido e/ou sistema/perfis para ver se um userProfile com hasLicense com um valor de true está definido.

Como verificar o userProfile na API e ver se você tem o conjunto de licenças=verdadeiro (significando usuários com licença PMP), é abordado em mais detalhes nesta seção. 

Você tem licenças PMP/SMP em seu arquivo cms.lic atual?

Devido a uma mudança no comportamento da licença no 3.0 em diante, você deve confirmar se tem licenças PMP/SMP suficientes antes de executar a atualização. Isso é descrito em mais detalhes nesta seção.

Você tem o Cisco Meeting Manager (CMM) implantado?

O CMS 3.0 requer o CMM 3.0 devido a alterações na forma como as licenças são tratadas. É recomendável implantar o CMM 2.9 antes de executar uma atualização do seu ambiente para a versão 3.0, pois você pode verificar o consumo de licença do seu relatório de 90 dias nos últimos 90 dias. Isso é descrito em mais detalhes nesta seção.

Você tem Smart Licensing?

O CMS 3.0 requer o CMM 3.0 devido a alterações na forma como as licenças são tratadas. Portanto, se você já estiver usando o Smart Licensing através do CMM, certifique-se de ter licenças PMP e SMP associadas ao seu cluster.

Webbridge (cliente WebRTC e CMA)

Você usa WebRTC no CMS 2.9?

O Webbridge mudou significativamente no CMS 3.0.  Para obter orientação sobre a migração de webbridge2 para webbridge3 e o uso do aplicativo Web, as informações são encontradas nesta seção.

Seus usuários usam o thick client do CMA?

Como esses clientes são baseados em XMPP, eles não poderão mais ser usados após a atualização, pois o servidor XMPP foi removido. Se isso se aplicar ao seu caso de uso, você poderá encontrar mais informações nesta seção.

Você usa Bate-papo em WebRTC?

A funcionalidade de bate-papo é removida do aplicativo Web no 3.0. No CMS 3.2, o chat é reintroduzido, mas não é persistente.  Você pode encontrar mais informações sobre este recurso nesta seção.

Seus usuários realizam chamadas Point to Point do WebRTC para dispositivos?

No CMS 3.0, um usuário do aplicativo Web não pode mais discar diretamente para outro dispositivo. Agora você deve ingressar em um espaço de reunião e ter permissão para adicionar participantes à reunião para executar a mesma ação.  Você pode encontrar mais informações sobre esta parte nesta seção.

Seus usuários criam seus próprios coSpaces a partir do WebRTC?

No 3.0, para que os usuários do aplicativo Web possam criar seus próprios espaços a partir do cliente, um coSpaceTemplate precisa ser criado na API e atribuído ao usuário. Pode ser manual ou automático durante a importação LDAP.  CanCreateCoSpaces é removido de UserProfile.  Você pode encontrar mais informações sobre este recurso nesta seção.

Alterações na GUI da Web

Você tem as configurações do WebBridge definidas na GUI do administrador da Web?

As configurações do webBridge são removidas da GUI no 3.0, portanto, você deve configurar as webbridges na API e observar quais são suas configurações atuais na GUI para que você possa configurar os webBridgeProfiles na API de acordo.  Você pode encontrar mais informações sobre essa alteração nesta seção.

Você tem configurações externas configuradas na GUI do administrador da Web?

As configurações externas foram removidas da GUI no CMS 3.1.  Se você tiver o URL do Webbridge ou o IVR configurado em sua GUI do administrador da Web do CMS 3.0 ou mais antiga (Configuração —> Geral —> Configurações Externas), eles foram removidos da página da Web e agora precisam ser configurados na API. As configurações anteriores à atualização para 3.1 NÃO são adicionadas à API e devem ser feitas manualmente.  Você pode encontrar mais informações sobre essa alteração nesta seção.

Gravadores/Streamers

Você usa algum gravador CMS e/ou dinamizador?

O gravador CMS e o componente de stream agora são baseados em SIP em vez de em XMPP. Portanto, como o XMPP está sendo removido, eles precisam ser ajustados após a atualização. Você pode encontrar mais informações sobre essa alteração nesta seção.

Considerações sobre o Cisco Expressway

Qual é a sua versão atual do Cisco Expressway se você estiver usando Expressway para proxy WebRTC? 

O CMS 3.0 requer o Expressway 12.6 ou mais recente.  Você pode encontrar mais informações sobre este recurso de proxy WebRTC nesta seção.

CMS Edge

Você tem atualmente uma borda CMS em seu ambiente?

O CMS Edge é reintroduzido no CMS 3.1 com maior escalabilidade para conexões externas.  Você pode encontrar mais informações sobre esta parte nesta seção.

CMS (Acano) X-Series

Atualmente, você tem servidores x-series em seu ambiente? 

Esses servidores não podem ser atualizados para o CMS 3.0 e você deve estar pensando em substituí-los em breve (mude para uma máquina virtual ou dispositivo CMS antes de atualizar para a versão 3.0). Você pode encontrar o aviso de fim da vida útil sobre esses servidores neste link.

Borda SIP

Você usa atualmente o SIP Edge em seu ambiente?

O Sip Edge foi totalmente substituído a partir do CMS 3.0.  Você precisa usar o Cisco Expressway para trazer as chamadas SIP para o seu CMS. Entre em contato com o seu representante de conta da Cisco para saber como obter o Expressway para a sua organização.

Mais informações

Licenciamento - Verificar licenças antes da atualização

O status de licença fora de conformidade é o problema mais impactante quando você atualiza para a versão 3.0 ou superior a partir de uma versão 2.x. Esta seção descreve como determinar a quantidade de licenças PMP/SMP necessárias para uma atualização tranquila.

Antes de atualizar sua implantação para a versão 3.0, implante o CMM 2.9 e verifique o relatório de 90 dias na guia Licenças para ver se o uso da licença permaneceu sob a quantidade de licença alocada atual nos nós do CMS:

Se você usa o licenciamento tradicional (o arquivo cms.lic é instalado localmente nos nós do CMS), verifique o arquivo de licença do CMS para as quantidades de licenças pessoais e compartilhadas (100 / 100 conforme a imagem aqui) em cada um dos nós do CMS (baixe através do WinSCP de cada nó callBridge).

Se você já usa o Smart Licensing, verifique quantas licenças PMP/SMP estão atribuídas no Cisco Software Smart Portal para os servidores CMS.

Abra o relatório de 90 dias (o arquivo Zip é chamado license-data.zip) e abra o arquivo daily-peaks.csv.

No Excel, classifique a coluna PMP por Z a A para obter os valores mais altos para o topo e, em seguida, execute o mesmo para a coluna SMP.  Os valores exibidos nesse arquivo são inferiores às licenças disponíveis no arquivo de licença do CMS? Em caso afirmativo, você está bem e totalmente em conformidade. Caso contrário, isso criará avisos e/ou erros, conforme indicado na Figura 6 na seção 1.7.3 do guia de implantação do CMS, para o qual você pode encontrar mais informações também na seção 1.7.4.

De acordo com a imagem, por exemplo, foram usadas 2.1667 licenças de SMP e nenhuma licença de PMP durante o pico dos últimos 90 dias. O arquivo cms.lic indicou 100 unidades de cada tipo de licença, portanto, esta configuração é totalmente compatível. Portanto, não há problemas com o licenciamento quando essa configuração é atualizada para o CMS 3.0. No entanto, ainda pode haver um problema quando, na configuração, 10.000 usuários por meio do LDAP teriam sido importados. Como então você tem apenas 100 licenças PMP, mas você aloca 10000 (com userProfile com hasLicense definido como True) para que nesse caso você esteja fora de conformidade assim que você atualizar para a versão 3.0. Saiba mais sobre isso na próxima seção.

Determine a quantos usuários é atribuída uma licença PMP após a atualização

Todos os usuários importados e que usam um userProfile com hasLicense=true recebem automaticamente uma licença PMP no CMS 3.0. 

Na API, verifique quantos userProfiles você tem e se algum deles tem "hasLicense=true" definido.  Em caso afirmativo, é necessário verificar onde esses userProfiles estão atribuídos. 

Os perfis de usuário podem ser atribuídos em qualquer um destes níveis:

1. FontesLDAP
2. Locatários
3. Sistema/perfis

Verifique todos os 3 locais para userProfiles atribuídos que tenham hasLicense=true.

1. Fontes Ldap/Locatários

Para cada ldapSource que esteja usando um espaço ou um userProfile, os usuários importados com esse ldapSource receberão uma licença PMP quando o parâmetro hasLicense estiver definido como True.  Se houver um espaço, você precisará clicar na ID do espaço para ver se ele tem um userProfile atribuído e, em seguida, verificar se esse userProfile está configurado com 'hasLicense=true'.  Se não houver nenhum espaço, mas houver um userProfile definido, clique nele para ver se ele tem 'hasLicense=true'.  Se ambas as maneiras tiverem 'hasLicense=true', você poderá verificar quantos usuários foram importados executando um GET para 'api/v1/users' e filtrando para o domínio usado para jidMapping no ldapmapping associado ao ldapSource, por exemplo.

Observação: isso pode ser mais complexo em outras situações em que você precisa verificar isso com os mapeamentos e filtros do Ative Diretory criados.

Etapa 1. Localize a ID de mapeamento no ldapSource.

Etapa 2. Pesquise ldapMappings para localizar jidMapping.

Etapa 3. Procure em api/v1/users pelo domínio usado em jidMapping.

Etapa 4. Adicione os usuários encontrados em cada ldapSource.  Esse é o número de usuários LDAP importados que precisam de licenças PMP. 

2. Sistema/Perfis

Se um userProfile for definido no nível do sistema/perfis e esse userProfile tiver "hasLicense=true", qualquer usuário importado para o CMS receberá uma licença PMP quando o servidor for atualizado.  Se você importou 10.000 usuários, mas só tem 100 PMPs, isso resulta em falta de conformidade quando você faz o upgrade para o CMS 3.0, e pode fazer com que uma mensagem na tela de 30 segundos seja exibida e o prompt de áudio no início das chamadas.  

Se userProfile no nível do sistema indicar que os usuários devem obter um PMP, vá para api/v1/users para ver quantos usuários há no total:

Se você já importou todos os usuários do ldap, mas agora percebeu que precisa apenas de um determinado subconjunto dessa lista, crie um filtro melhor no ldapSource para que ele importe apenas os usuários aos quais você deseja receber licenças PMP. Revise seu filtro em ldapSource e execute uma nova sincronização LDAP em api/v1/ldapsync.  Isso faz com que apenas os usuários desejados sejam importados e todos os outros usuários dessa importação anterior removidos. 

Observação: se você fizer isso corretamente e a nova importação remover apenas usuários indesejados, os CallIDs e os segredos do coSpace dos usuários restantes não serão alterados, mas se você cometer um erro, isso poderá resultar na alteração de todos os callIds e segredos.  Faça um backup dos nós do banco de dados antes de tentar isso, se estiver preocupado com isso!

Você tem licenças SMP suficientes?

Ao observar os picos diários do Relatório de 90 dias do CMM, você já tem licenças SMP suficientes para cobrir o pico?  As licenças SMP são usadas quando o proprietário da reunião não recebeu uma licença PMP (seja como proprietário do coSpace / reunião ad-hoc / reunião agendada do TMS).  Se você estiver usando intencionalmente o SMP e tiver o suficiente para cobrir seus horários de pico, tudo estará OK. Se você verificar o horário de pico de 90 dias para o SMP e não estiver claro por que eles são consumidos, veja algumas coisas a serem verificadas.

1. As chamadas ad hoc (conforme escaladas do CUCM) usam uma licença SMP se o dispositivo usado para mesclar não estiver associado a um usuário que recebeu uma licença PMP no CMS através do perfil do usuário.  O CUCM fornece o GUID do usuário que está escalando a reunião.  Se essa GUID corresponder a um usuário LDAP importado do servidor da reunião com uma licença PMP atribuída, a licença desse usuário será usada.

2. Se um proprietário do coSpace não tiver recebido uma licença PMP, as chamadas para esses coSpaces específicos usarão uma licença SMP.

3. Se a reunião tiver sido agendada no TMS versão 15.6 ou mais recente, o proprietário da reunião será enviado ao CMS e, se esse usuário não tiver recebido uma licença PMP, essa reunião usará uma licença SMP.

Configurar CMM

A partir do CMS 3.0, o CMM 3.0 é necessário para que o CMS funcione corretamente.  O CMM é responsável pelo licenciamento do CMS, portanto, se você planeja atualizar o CMS para 3.0, deverá ter um servidor CMM.  É recomendável implantar o CMM 2.9 enquanto você estiver no CMS 2.9 para que possa verificar o consumo de licença antes da atualização.

O CMM verifica todas as callBridges adicionadas para licenças SMP e PMP e para a licença callBridge.  Ele usa o número mais alto entre os vários dispositivos dentro do cluster. 

Por exemplo, se o CMS1 tiver 20 licenças PMP e 10 licenças SMP e o CMS2 tiver 40 licenças PMP e 5 licenças SMP no licenciamento tradicional, o CMM informará que você tem 40 licenças PMP e 10 licenças SMP para usar.

Se você tiver mais licenças de PMP do que usuários importados, não terá problemas relacionados às licenças de PMP (ou SMP), mas se verificar o pico de 90 dias e descobrir que usou mais do que o disponível, você ainda poderá atualizar para o CMS 3.0 e usar a Licença de avaliação de 90 dias no CMM para resolver as questões com seu licenciamento ou agir antes da atualização.

Configurar Webbridge (WebRTC e cliente CMA)

O CMS 3.0 remove o componente de servidor XMPP e, com isso, remove o webBridge e a capacidade de usar o cliente thick CMA.  O WebBridge3 é o que é usado agora para conectar usuários de aplicativos Web (antes chamados de usuários WebRTC) a reuniões usando o navegador.  Ao atualizar para a versão 3.0, você precisa configurar o webbridge3. 

Observação: o cliente thick CMA não funciona após a atualização para o CMS 3.0!

Este vídeo o orienta durante o processo de criação dos certificados webbridge 3.

https://video.cisco.com/detail/video/6232772471001?autoStart=true&q=cms

Antes da atualização para a versão 3.0, os clientes devem planejar como configurar o Webbridge3. As etapas mais importantes são destacadas aqui.

1. Você precisa de uma cadeia de chaves e certificados para o webbridge3.  O certificado webbridge antigo pode ser usado se o certificado contiver todos os FQDNs do servidor CMS ou endereços IP como Nome Alternativo do Assunto (SAN)/Nome Comum (CN) que estejam executando o webbridge3 e se qualquer um destes for atendido:

a. O certificado não tem uso avançado de chave (o que significa que pode ser usado como cliente ou servidor).

b. O certificado tem autenticação de cliente e de servidor.  O certificado HTTP só precisa realmente de Autenticação de Servidor, enquanto o certificado C2W requer servidor e cliente).

2. Se você quiser criar um novo certificado para o certificado "webbridge3 https", é recomendável que ele seja assinado publicamente (para evitar avisos de certificado no cliente ao usar o aplicativo Web).  Esse mesmo certificado pode ser usado para o "certificado webbridge3 c2w", e o certificado deve ter o FQDN dos servidores webbridge em SAN/CN.

3. As CallBridges precisam se comunicar com a nova webbridge3 usando uma porta configurada no comando webbridge3 c2w listen. Pode ser qualquer porta disponível, como 449. Os usuários precisam ter certeza de que as callbridges podem se comunicar com a webbridge3 nessa porta e ter todas as alterações de firewall feitas antecipadamente, se necessário.  Não pode ser a mesma porta usada por "webbridge https" para escutar.

Antes da atualização do CMS para a versão 3.0, é recomendável fazer um backup usando 'backup snapshot <servername_date>' e depois fazer login na página webadmin em seus nós callbridge para remover todas as Configurações XMPP e Configurações Webbridge.  Em seguida, conecte-se ao MMP em seus servidores e execute estas etapas em todos os servidores centrais que possuem xmpp e webbridge em uma conexão SSH:

1. xmpp disable
2. xmpp reset
3. xmpp certs none
4. xmpp domain none
5. desabilitar webbridge
6. webbridge listen none
7. webbridge certs none
8. webbridge trust none

Depois de atualizar para a versão 3.0, comece configurando o webbridge3 em todos os servidores que executavam o webbridge anteriormente.  Você deve fazer isso porque já existem registros DNS lá fora que apontam para esses servidores, portanto, dessa forma, você garante que, se um usuário for enviado para um webbridge3, ele estará preparado para lidar com a solicitação.

Configuração Webbridge3 (toda a conexão SSH)

Etapa 1. Configure a porta de escuta http webbridge3.

Webbridge3 https ouça a:443

Etapa 2. Configure certificados para webbridge3 para conexões do navegador.  Este é o certificado enviado aos navegadores e precisa ser assinado por uma CA (Autoridade de Certificação) pública e que contém o FQDN usado no navegador para que o navegador confie na conexão.

Webbridge3 https certs wb3.key wb3trust.cer (Isso precisa ser uma cadeia de confiança: torne um certificado de confiança que tenha uma entidade final no topo, seguido por CAs Intermediárias em ordem, terminando com RootCA).

Etapa 3. Configure a porta a ser usada para escutar conexões callBridge para webbridge (c2w).  Como 443 é usado para a porta de escuta https webbridge3, essa configuração deve ser uma porta disponível diferente, como por exemplo 449.

Webbridge3 c2w ouvir a:449

4. Configure os certificados que o webbridge envia ao callbridge para a confiança do c2w

WebBridge3 c2w certs wb3.key wb3trust.cer

5. Configure o armazenamento confiável que o WB3 usa para confiar no certificado callBridge.  Isso precisa ser o mesmo que o certificado usado no pacote de CA callbridge (e deve ser um pacote de certificados intermediários no topo e CA raiz no final, seguido por um único retorno de carro).

Webbridge3 c2w trust rootca.cer

6. Habilitar webbridge3

Webbridge3 enable

Alterações de configuração do CallBridge (toda a conexão SSH)

Etapa 1. Configure a confiança do callBridge com o certificado/pacote de CA que assinou o certificado c2w webbridge3.

Callbridge trust c2w rootca.cer

Etapa 2. Reinicie o callBridge para que a nova relação de confiança entre em vigor.  Isso descarta todas as chamadas nesse callBridge específico, portanto use-o com cuidado.

reinicialização de Callbridge

Configuração de API para callBridges para conexão com webBridge3

1. Crie um novo objeto do webBridge usando o POST na API e forneça a ele um valor de URL usando o FQDN e a porta configurada na lista branca da interface c2w do webbridge (etapa 3 na configuração do webbridge3)

c2w://webbridge.darmckin.local:449

Neste ponto, o Webbridge3 funciona novamente e você pode ingressar em espaços como convidado ou, se tiver importado usuários anteriormente, eles devem ser capazes de entrar.

Permissões de criação de espaço do usuário do aplicativo Web

Seus usuários estão acostumados a criar seus próprios espaços no WebRTC?  A partir do CMS 3.0, os usuários do aplicativo Web não podem criar seus próprios coSpaces, a menos que tenham um modelo de cospace atribuído a eles permitindo isso.

Mesmo com um coSpaceTemplate atribuído, isso não cria um espaço para que outras pessoas possam discar (sem URI, sem ID de chamada ou senha), mas se o coSpace tiver um callLegProfile com ‘addParticipantAllowed’, elas poderão discar do espaço.

Para ter cadeias de caracteres de discagem que possam ser usadas para chamar o novo espaço, coSpaceTemplate deve ter uma configuração de accessMethodTemplate (consulte as notas de versão 2.9 - https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-2-9/Cisco-Meeting-Server-Release-Notes-2-9-6.pdf).

Na API, crie coSpaceTemplate(s) e, em seguida, crie um accessMethodTemplate(s) e atribua o coSpaceTemplate ao ldapUserCoSpaceTemplateSources ou você pode atribuir manualmente um coSpaceTemplate a um usuário em api/v1/users.

Você pode criar e atribuir vários CoSpaceTemplates e accessMethodsTemplates.  Consulte o guia da API do CMS para obter mais informações (https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-programming-reference-guides-list.html)

CoSpaceTemplate (configuração da API)

Nome: Qualquer nome que você queira dar ao coSpaceTemplate.

Descrição: Breve descrição, se desejado.

callProfile: CallProfile branco você deseja que qualquer espaço criado com este modelo use? Se não for fornecido, ele usa o que está definido no nível do sistema/perfil.

calllegProfile: Qual calllegProfile você deseja que qualquer espaço criado com este modelo use?  Se não for fornecido, ele usa o que está definido no nível do sistema/perfil.

dialInSecurityProfile: Qual dialInSecurityProfile você deseja que os espaços criados com este modelo usem? Se não for fornecido, ele usa o que está definido no nível do sistema/perfil.

AccessMethodTemplate (configuração da API)

Nome: Qualquer nome que você queira dar ao coSpaceTemplate.

uriGenerator: A expressão a ser usada para gerar valores URI para este modelo de método de acesso; o conjunto de caracteres permitido é 'a' a 'z', 'A' a 'Z', '0' a '9', '.', '-', '_' e '$'; se não estiver vazio, deverá conter exatamente um caractere '$'.  Exemplo disso é $.space que usa o nome fornecido pelo usuário ao criar o espaço e anexar ".space" a ele. "Reunião de Equipe" cria a URL 'Team.Meeting.space@domain'.

callLegProfile: Que calllegProfile você deseja que qualquer accessMethods criado com este modelo use?  Se não for fornecido, ele usará o que está definido no nível CoSpaceTemplate e, se não houver nenhum, usará o que está no nível do sistema/perfil.

generateUniqueCallId: se gerar uma ID numérica exclusiva para este método de acesso que substitui a global para o espaço conjunto.

dialInSecurityProfile: Qual dialInSecurityProfile você deseja que qualquer método de acesso criado com este modelo use? Se não for fornecido, ele usará o que está definido no nível CoSpaceTemplate e, se não houver nenhum, usará o que está no nível do sistema/perfil.

Função de bate-papo

O CMS 3.0 removeu a função de bate-papo persistente, mas no CMS 3.2 o bate-papo não persistente dentro dos espaços retornou.  O bate-papo está disponível para usuários de aplicativos Web e não é armazenado em nenhum lugar.  Depois que o CMS 3.2 é instalado, os usuários do aplicativo Web são, por padrão, capazes de enviar mensagens uns aos outros durante as reuniões.  Essas mensagens estão disponíveis apenas durante a reunião e apenas as mensagens trocadas após o ingresso são vistas. Você não pode ingressar atrasado e rolar de volta para ver as mensagens anteriores.

Chamadas ponto a ponto WebRTC

No CMS 2.9.x, os participantes do WebRTC puderam discar de seus clientes diretamente para outros contatos.  A partir do CMS 3.0, isso não é mais possível. Agora os usuários devem entrar e ingressar em um espaço. A partir daí, se eles tiverem permissão no callLegProfile (parâmetro addParticipants definido como True), eles poderão adicionar outros contatos.  Isso faz com que o CMS disque para o participante e eles se reúnem em um espaço no CMS.

Alterações notáveis nas configurações do webBridge

O CMS 3.0 e 3.1 removeu ou realocou algumas das configurações de webbridge da GUI e elas precisam ser configuradas na API para manter a experiência consistente para os usuários.  No 3.x, use api/v1/webBridges e api/v1/webBridgeProfiles. 

Verifique o que você configurou atualmente para que, ao atualizar para a versão 3.0, você possa configurar os Perfis webbridge e webbridge na API de acordo.

No 3.0, as configurações de Web bridge foram removidas na GUI e, no CMS 3.1, os campos Acesso externo também foram removidos.

Configurações de Web Bridge na GUI

• URI do cliente da conta de convidado - usado pelo callBridge para localizar o webBridge.  Se você tiver várias webBridges em sua implantação para WebRTC, esse campo já deverá estar em branco e você deverá ter URLs exclusivos em api/v1/webbridges para cada webBridge ao qual a callBridge precisa se conectar.  Exclua qualquer coisa nesse campo e verifique se você tem as webBridges configuradas na API.

• Domínio Jid da Conta de Convidado - não é mais usado no CMS 3.0 e você pode excluí-lo.
• Acesso de convidado via ID e senha - removido e não substituído no CMS 3.0.
• Acesso de convidado através de hiperlinks - agora configurável em webBridgeProfiles na API na configuração "AllowSecrets".

Observe que no CMS 3.0, vários campos foram removidos de api/v1/webBridges.

• resourceArchive - agora em webbridgeProfiles.
• idEntryMode - agora preterido.
• allowWeblinkAccess - agora em webBridgeProfiles como allowSecrets.
• showSign - agora em webBridgeProfiles como userPortalEnabled.
• resolveCoSpaceCallIds- agora em webbridgeProfiles.
• resolveLyncConferenceIDs - agora em webbridgeProfiles.

WebBridgeProfile

• resourceArchive - se você usar planos de fundo personalizados e seu arquivo de recursos estiver armazenado em um servidor da Web, digite o URL aqui.
• allowPasscodes - se for falso, os usuários não terão uma opção para ingressar em reuniões como convidados.  Eles só podem entrar ou usar uma URL que contenha as informações e o segredo do espaço
• allowSecrets - Se for definido como false, os usuários não poderão ingressar em espaços usando uma URL como https://meet.company.com/meeting/040478?secret=gPDnucF8is4W1cS87_l.zw. Os usuários precisam usar https://meet.company.com e digitar a ID da chamada/ID da reunião/URI e PIN/Senha, se houver um configurado.
• userPortalEnabled - se estiver definido como false, a página inicial do portal do aplicativo Web não mostrará a opção de entrada. Ele exibe apenas os campos para inserir a ID da chamada/ID da reunião/URI e PIN/Senha, se houver um configurado.
• allowUnauthenticatedGuest - se definido como False, os convidados não poderão ingressar em nenhuma reunião - mesmo com a URL completa que contém a ID e o segredo da reunião.  Quando Falso, somente os usuários que podem entrar podem ingressar em uma reunião.  Exemplo.  O Usuário2 está tentando usar a URL para a reunião do Usuário1.  Após digitar a URL, o Usuário2 deve entrar para continuar na reunião do Usuário1.
• resolveCoSpaceCallIds - se definido como False, os convidados só poderão ingressar em reuniões inserindo o URI e o PIN/Senha, se usados.  ID de chamada/ID de reunião/ID numérica não são aceitos.
• resolveCoSpaceUris - 3 configurações possíveis: off, domainSuggestionDisabled e domainSuggestionEnabled. Se este webBridge aceita ou não URIs SIP coSpace e coSpace accessMethod com a finalidade de permitir que os visitantes participem de reuniões do cospace.

- Quando definido como 'off', a associação por URI é desabilitada.

- Quando definido como 'domainSuggestionDisabled', a associação por URI é habilitada, mas o domínio do URI não é preenchido automaticamente ou verificado em webBridges usando esse webBridgeProfile.

- Quando definido como 'domainSuggestionEnabled', a associação por URI é habilitada e o domínio do URI pode ser preenchido automaticamente e verificado em webBridges usando esse webBridgeProfile.

Seção Acesso Externo removida da GUI Web

No CMS 3.1, a seção Acesso Externo foi removida da GUI da Web. Se você tiver configurado essas opções antes da atualização, será necessário reconfigurá-las na API em webbridgeProfiles.

Primeiro, você precisa criar um webbridgeProfile como descrito na seção anterior. Depois de criar um webbridgeProfile, você pode criar um Número IVR e/ou um URI de Web Bridge através dos links disponíveis na API sob o webBridgeProfile recém-criado.

Você pode criar até 32 números IVR ou 32 endereços webbridge por perfil de webBridge

Gravação ou transmissão

O gravador e o componente de streaming no CMS 2.9.x e anterior eram clientes XMPP, e a partir do CMS 3.0, eles são baseados em SIP.  Isso agora permite que os layouts para gravações e streaming sejam alterados usando o layout padrão na API. Além disso, agora os rótulos de nome são mostrados na sessão de gravação/streaming.  Consulte as notas de versão do CMS 3.0 para obter mais informações sobre os recursos de gravação/streaming - https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-3-0/Cisco-Meeting-Server-Release-Notes-3-0.pdf.

Se você tiver o gravador ou o streaming configurado no 2.9.x, será necessário redefinir as configurações no MMP e na API para que elas continuem a funcionar após a atualização.

Antes da atualização do CMS para 3.0, é recomendável fazer um backup usando 'backup snapshot <servername_date>' e depois fazer login na página webadmin em seus nós callbridge para remover todas as configurações XMPP.  Em seguida, conecte-se ao MMP em seus servidores e execute estas etapas em todos os servidores centrais que possuem xmpp em uma conexão SSH:

1. xmpp disable
2. xmpp reset
3. xmpp certs none
4. xmpp domain none

Gravador

MMP

As figuras mostram um exemplo das configurações vistas no CMS 2.9.1 quando o gravador foi configurado e como ele se parece imediatamente após a atualização para o 3.0.

Após a atualização, você deverá reconfigurar o gravador:

Etapa 1. Configure a interface de escuta SIP.

gravador sip escutar um 5060 5061 (A interface e as portas que o gravador SIP está configurado para escutar para TCP e TLS, respectivamente. Se não quiser usar TLS, você pode usar 'recorder sip listen a 5060 none')

Etapa 2. Configure os certificados que o gravador usará se você estiver usando uma conexão TLS.

recorder sip certs <key-file> <crt-file> [crt-bundle] (Sem esses certificados, o serviço tls não inicia no gravador. O gravador usa o pacote crt para verificar o certificado callBridge.)

Etapa 3. Configure o limite de chamadas.

limite do gravador <0-500|nenhum> (Define o limite para o número de gravações simultâneas que o servidor pode servir. Esta tabela está em nossa documentação e o limite do gravador deve estar alinhado com os recursos no servidor.)

API

Em api/v1/callProfiles, você precisa configurar o sipRecorderUri. Este é o URI que o callBridge disca quando precisa iniciar uma gravação. O domínio deste URI precisa ser adicionado à sua tabela de regras de saída e apontar para o gravador (ou controle de chamadas) como o Proxy SIP a ser Usado.

Esta figura mostra uma discagem direta para o componente gravador nas regras de saída encontradas em Configuração > Chamadas de Saída.

Esta figura mostra uma chamada para o componente gravador através de um controle de chamada (como por exemplo, Cisco Unified Communications Manager (CUCM) ou Expressway).

Observação: se você configurou o gravador para usar SIP TLS e se as chamadas estiverem falhando, verifique o nó callBridge no MMP para ver se a verificação SIP TLS está habilitada.  O comando MMP é 'tls sip'.   As chamadas podem falhar porque o certificado do gravador não é confiável para callBridge.  Você pode testar isso desabilitando isso no callBridge usando 'tls sip verify disable'.

Vários gravadores?

Configure cada um como explicado e ajuste suas regras de saída de acordo.  Se você usar um método direto para o gravador, altere a regra de saída para o gravador existente para o comportamento "Continuar" e adicione uma nova regra de saída abaixo da anterior com prioridade um a menos que a primeira.  Quando o primeiro gravador tiver atingido seu limite de chamada, ele enviará um 488 Unaccept aqui para callBridge, e o callBridge passa para a próxima regra.

Se quiser fazer o balanceamento de carga dos gravadores, use um controle de chamadas e ajuste o roteamento do controle de chamadas para que ele possa fazer chamadas para vários gravadores.

Streamer

MMP

Após a atualização de 2.9.x para 3.0, você precisa reconfigurar o streamer.

Etapa 1. Configure a interface de escuta SIP.

streamer sip listen a 6000 6001 (A interface e as portas que o streamer SIP está configurado para ouvir TCP e TLS, respectivamente.  Se não quiser usar TLS, você pode usar 'streamer sip listen a 6000 none')

Etapa 2. Configure os certificados que o otimizador usará se você estiver usando uma conexão TLS.

streamer sip certs <key-file> <crt-file> [crt-bundle] (Sem esses certificados, o serviço tls não inicia no streamer. O otimizador usa o pacote crt para verificar o certificado callBridge.)

Etapa 3. Configurar o limite de chamadas

limite do otimizador <0-500|nenhum> (Define o limite para o número de fluxos simultâneos que o servidor pode servir. Esta tabela está em nossa documentação e o limite do otimizador deve estar alinhado com os recursos no servidor.)

API

Em api/v1/callProfiles, você precisa configurar o sipStreamUri. Este é o URI que o callBridge disca quando precisa iniciar o streaming. O domínio deste URI precisa ser adicionado à sua tabela de regras de saída e apontar para o dinamizador (ou controle de chamadas) como o Proxy SIP a ser Usado.

Esta figura mostra uma discagem direta para o componente de streaming nas regras de saída encontradas em Configuração > Chamadas de Saída.

Esta figura mostra uma chamada para o componente gravador através de um controle de chamada (como por exemplo, Cisco Unified Communications Manager (CUCM) ou Expressway).

Observação: se você configurou o otimizador para usar SIP TLS e se as chamadas estiverem falhando, verifique o nó callBridge no MMP para ver se a verificação SIP TLS está habilitada.  O comando MMP é 'tls sip'.   As chamadas podem falhar porque o certificado do transmissor não é confiável para callBridge.  Você pode testar isso desabilitando isso no callBridge usando 'tls sip verify disable'.

Vários Streamers?

Configure cada um como explicado e ajuste suas regras de saída de acordo.  Se você usar um método de fluxo direto para fluxo, altere a regra de saída para gravador existente para o comportamento "Continuar" e adicione uma nova regra de saída abaixo da anterior com a prioridade um a menos do que a primeira.  Quando o primeiro streamer atinge seu limite de chamada, ele envia um 488 Inaceitável aqui de volta para callBridge, e o callBridge passa para a próxima regra.

Se quiser fazer o balanceamento de carga dos fluxos, use um controle de chamadas e ajuste o roteamento do controle de chamadas para que ele possa fazer chamadas para vários fluxos.

Consideração do Expressway

Se você usa o Cisco Expressway para Web Proxy, deve garantir que seu Expressway está executando pelo menos X12.6 antes da atualização do CMS. Isso é exigido pelo CMS 3.0 para que o proxy da Web funcione e seja suportado.

A capacidade dos participantes do aplicativo Web aumentou em relação ao Expressways quando usado com o CMS 3.0.  Para um OVA Expressway grande, a capacidade esperada é de 150 chamadas Full HD (1080p30) ou 200 chamadas de outro tipo (por exemplo, 720p30). Você pode aumentar essa capacidade agrupando Expressways, até 6 nós (onde 4 é usado para dimensionamento e 2 para redundância, para um máximo de 600 chamadas Full HD ou 800 chamadas de outro tipo).

CMS Edge

O CMS Edge é reintroduzido no CMS 3.1, pois oferece capacidades maiores do que o Expressway para sessões de aplicativos Web externos. Há duas configurações recomendadas.

Especificações de borda pequena

4 GB de RAM, 4 vCPUs, interface de rede de 1 Gbps

Essa especificação VM Edge tem potência suficiente para cobrir uma única capacidade de carga de áudio e vídeo do CMS1000, que é de 48 x 1080p, 96 x 720p, 192 x 480p e 1000 chamadas de áudio.

Para a implantação, é recomendável ter 1 servidor de borda pequeno por CMS1000 ou 4 servidores de borda pequeno por CMS2000.

Especificações de borda grande

8 GB de RAM, 16 vCPUs, interface de rede de 10 Gbps

Essa especificação VM Edge tem potência suficiente para cobrir uma única capacidade de áudio e vídeo do CMS2000, que é de 350 x 1080p, 700 x 720p, 1000 x 480p e 3000 x chamadas de áudio.

Para a implantação, é recomendável ter 1 servidor de borda grande por CMS2000 ou por 4 CMS1000.