Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

CSCvt73723 - Sessões vazadas do servidor WebRTC após uma grande quantidade de sessões colocadas no servidor

Como você identifica este bug?

Como você pode evitar esse problema?

Quando está prevista a sua fixação?

Informações Relacionadas

Introduction

Este documento descreve a detecção e solução no bug da Cisco ID CSCvt73723 em sessões vazadas de servidor WebRTC após uma grande quantidade de sessões colocadas no servidor. Isso pode eventualmente fazer com que os usuários não consigam fazer logon ou ingressar como convidado no WebBridge.

Prerequisites

Requirements

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

- Cisco Meeting Server (CMS) (componente CallBridge e WebBridge)

Componentes Utilizados

As informações neste documento são baseadas no Cisco Meeting Server e, em particular, no componente WebRTC do WebBridge 2 / CMA. Este documento não se aplica ao novo componente Web do WebBridge 3 / CMS que foi introduzido na versão 2.9.

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.

CSCvt73723 - Sessões de vazamento do servidor WebRTC após grande quantidade de sessões colocadas no servidor

Como você identifica este bug?

O sintoma do ponto de vista do usuário final é que depois que ele atinge o limite máximo e nenhum outro usuário pode ingressar em uma reunião. Nos registros, apontar as estatísticas da webbridge (conforme esta FAQ) estão atingindo 149 NÃO implica necessariamente que estas são sessões vazadas. Isso significa apenas que a ponte Web atingiu seu limite máximo e nenhuma nova conexão é permitida.

"webbridge": INFORMAÇÕES: [DEBUGING] Estatísticas 149, c:3477, d:3170

Calcular quantos deles são sessões vazadas é um pouco mais complicado e pode ser feito se você NÃO estiver usando o cliente de desktop CMA ou o cliente iOS. Da versão 2.8, o Call Bridge relata a cada 5 minutos o número de sessões CMA (cliente CMA WebRTC + cliente de desktop CMA + cliente CMA iOS). Observe que isso é relatado como "CMA": "X/Y" onde X é o número atual de sessões CMA ativas e Y é o pico nos últimos 5 minutos.

INFORMAÇÕES: STATS: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}

Só porque uma Call Bridge está relatando 14 sessões atuais não significa que a Web Bridge co-localizada também está relatando 14 sessões. Esse mapeamento é 1:1 em um único servidor combinado, mas em uma implantação em cluster uma sessão da Web Bridge pode instanciar uma chamada em uma Call Bridge diferente (especialmente quando o balanceamento de carga está ativado - o que, por padrão, é para a CMA).

Portanto, para calcular o número total de sessões vazadas em uma implantação, você precisa das sessões ativas combinadas de TODAS as estatísticas da Web Bridge e compare isso com as estatísticas combinadas da CMA Call Bridge reportadas.

Como você pode evitar esse problema?

Dependendo da frequência com que sua implantação atinge essa situação (uma vez a cada dois dias ou uma vez a cada duas semanas), você deve ser aconselhado a reiniciar os Web Bridge(s), o que elimina todas as sessões vazadas e redefine a contagem de sessões ativas para 0. Compreensivelmente, isso pode ser entediante se se tornar uma tarefa diária, portanto, por que essa tarefa pode ser facilitada com um script disponível de acordo com o bloco de código.

################################################################

#### Cisco Meeting Server ####

#### Webbridge restart ####

#### Workaround for CSCvt73723  ####

#### feedback: willwoo@cisco.com ####

################################################################

#--------------------------------------------------------------

# ---------- DISCLAIMER ----------

#--------------------------------------------------------------

# Please note this script is NOT maintained or supported by Cisco.

# This is to be run at entirely your own risk.

# This script is not intended for redistribution

# Tested with python 3.7.4

#--------------------------------------------------------------

#--------------------------------------------------------------

# ---------- Libraries to import ----------

#--------------------------------------------------------------

import paramiko

import time

import datetime

#--------------------------------------------------------------

#--------------------------------------------------------------

# ---------- Deployment parameters to change ----------

#--------------------------------------------------------------

# WB Inventory - just extend or modify the below to match your deployment requirements.

# Enter the MMP IP of the server (can differ from interface webbridge service is running)

webbridges ={1:"127.0.0.1",2:"127.0.0.1",3:"127.0.0.1",4:"127.0.0.1"}

mmp_username = "admin" # MMP username

mmp_password = "password" # MMP password

#--------------------------------------------------------------

def mmp_webbridge_restart(mmp_address,uname,pword):

conn = paramiko.SSHClient()

conn.set_missing_host_key_policy(paramiko.AutoAddPolicy())

try:

conn.connect(mmp_address, 22, uname, pword)

stdin, stdout, stderr = conn.exec_command('webbridge restart')

time.sleep(1)

conn.close()

print_log_message('Webbridge on server: ' + mmp_address + ' restarted successfully')

except Exception as error:

print_log_message('Failed to restart webbridge on server ' + mmp_address + '. Error:')

print_log_message(str(error))

pass

def print_log_message(message):

time_stamp = datetime.datetime.now(datetime.timezone.utc)

time_stamp = str(time_stamp)

file = open('webbridge_restart_logs.txt', 'a')

file.write(time_stamp + " " + message + "\n")

file.close()

if __name__ == '__main__':

for wb in webbridges:

mmp_webbridge_restart(webbridges[wb], mmp_username, mmp_password)

################################################################

O script requer algumas pequenas edições (as credenciais na linha 29-30 e os endereços IP das Web Bridges na implantação na linha 27) e SOMENTE devem ser executadas quando não houver carga esperada ou durante uma janela de manutenção. O script não verifica as sessões ativas e simplesmente executa o comando 'webbridge restart' em todos os servidores listados que encerram qualquer sessão WebRTC ativa.

Para automatizar esse script, ele pode ser feito configurando um trabalho cron ou em um PC Windows 10 com Agendador de Tarefas. Supondo que o PC Win 10 tenha o Python 3.4+ instalado, eles podem seguir estas etapas:

1. Abrir Agendador de Tarefas

2. Selecione 'Criar tarefa básica..'

2.1 Insira um nome/descrição para esta tarefa

2.2 Selecione a frequência e as horas que você deseja executar esta tarefa (recomendável apenas para ser executada fora dos horários de pico, mostrada aqui para cada sábado às 2h)

2.3 Ação a executar, selecione: 'Iniciar um programa'

2.4 Ação:

* Programa/Script:  C:\<caminho para python.exe>

(se você não souber o caminho para python.exe, ele pode ser encontrado acessando cmd e digitando: python -c "import sys; print(sys.executable)"

* Adicionar argumentos (opcional): webbridge_restart.py (ou nome do script python)

* Iniciar em (opcional): C:\<caminho para webbridge_restart.py>

Observe que o computador que está executando o trabalho cron deve ser capaz de acessar o MMP dos servidores CMS configurados. Depois que o script é executado, ele cria um arquivo webbridge_restart_logs.txt que contém detalhes sobre as reinicializações de diferentes WebBridges, bem como quaisquer possíveis falhas. Um exemplo é mostrado com uma conexão bem-sucedida com 10.48.79.194 e uma falha com 127.0.0.1 (como sendo, na verdade, o endereço de loopback do PC).

2020-06-08 14:53:18.149915+00:00 Webbridge on server: 10.48.79.194 restarted successfully 2020-06-08 14:53:19.165543+00:00 Failed to restart webbridge on server 127.0.0.1. Error: 2020-06-08 14:53:19.165543+00:00 [Errno None] Unable to connect to port 22 on 127.0.0.1

Como testar se o script funciona bem?

Se o Python instalou o PC do qual você pretende executar o script, você pode executá-lo manualmente primeiro com as próximas etapas:

1. Abra o cmd e navegue até o local do script com o comando 'cd'

2. Execute o arquivo python com o comando 'python webbridge_restart.py'

3. Caso veja um erro indicando que o módulo 'paramiko' não está instalado, você precisa instalar uma biblioteca extra com o comando 'pip install paramiko'

4. Depois de concluído, você pode executar o script novamente com 'python webbridge_restart.py' (OBSERVAÇÃO: isso reinicia a webbridge e faz com que as conexões atuais do WebRTC sejam desconectadas)

Se ele tiver sido executado com êxito, você poderá verificar o resultado no arquivo webbridge_restart_logs.txt.

Quando está prevista a sua fixação?

Este não é um bug novo e não há plano para consertá-lo no Web Bridge 2 / CMA WebRTC. O novo aplicativo Web Bridge 3 / CMS (disponível a partir de 2.9) não é afetado por esse bug porque ele foi completamente reprojetado. Os clientes que sofrem um impacto pesado com isso devem considerar a mudança para o novo aplicativo da Web CMS (embora isso ainda não seja paridade de recursos com o Web Bridge 2 na versão 2.9. Verifique as notas de versão do aplicativo Web CMS 2.9 e cms para obter detalhes completos sobre isso.)

Informações Relacionadas

- Notas de defeito: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt73723

- Notas de versão: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-release-notes-list.html

- FAQ

- https://meeting-infohub.cisco.com/faq/content/43/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html