Explicación y solución alternativa en CSCvt73723 - El servidor WebRTC pierde sesiones después de una gran cantidad de sesiones colocadas en el servidor

Introducción

Este documento describe la detección y la solución alternativa en el Id. de bug Cisco CSCvt73723 en torno a las sesiones de fuga del servidor WebRTC después de una gran cantidad de sesiones colocadas en el servidor. Esto puede provocar que los usuarios no puedan iniciar sesión o unirse como invitados en WebBridge.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco Meeting Server (CMS) (componente CallBridge y WebBridge)

Componentes Utilizados

La información de este documento se basa en Cisco Meeting Server y, en particular, en torno al componente WebBridge 2 / CMA WebRTC. Este documento no se aplica al nuevo componente WebBridge 3 / CMS Web App que se ha introducido en la versión 2.9.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

CSCvt73723 - El servidor WebRTC pierde sesiones después de una gran cantidad de sesiones colocadas en el servidor

¿Cómo se identifica este error?

El síntoma desde la perspectiva del usuario final es que una vez que han alcanzado el límite máximo, ningún otro usuario puede unirse a una reunión. En los registros, detectar las estadísticas de webbridge (según esta FAQ) está llegando a 149 NO implica necesariamente que todas sean sesiones filtradas. Esto solo significa que el puente web ha alcanzado su límite máximo y no se permiten nuevas conexiones.

"webbridge": INFORMACIÓN: [DEPURACIÓN] Estadísticas 149, c:3477, d:3170

El cálculo de cuántas de estas sesiones se filtran es un poco más complicado y se puede hacer si NO utiliza el cliente de escritorio de CMA o el cliente de iOS. Desde la versión 2.8, Call Bridge informa cada 5 minutos del número de sesiones de CMA (CMA WebRTC + CMA desktop client + CMA iOS client). Tenga en cuenta que se informa como "CMA": "X/Y", donde X es el número actual de sesiones de CMA activas e Y es el pico de los últimos 5 minutos.

INFO: ESTADÍSTICAS: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}}

El hecho de que un Call Bridge informe de 14 sesiones actuales no significa que el Web Bridge ubicado conjuntamente informe también de 14 sesiones. Esta asignación es 1:1 en un único servidor combinado, pero en una implementación agrupada una sesión de Web Bridge puede instanciar una llamada en un Call Bridge diferente (especialmente cuando está habilitado el equilibrio de carga, que es de forma predeterminada para CMA).

Por lo tanto, para calcular el número total de sesiones filtradas en una implementación, necesita las sesiones activas combinadas de TODAS las estadísticas del puente web y compárelas con las estadísticas combinadas del puente de llamadas de CMA de las que se informa.

¿Cómo puede evitar este problema?

Dependiendo de la frecuencia con la que su implementación llegue a esta situación (una vez cada dos días o una vez cada dos semanas), se le debe aconsejar que reinicie sus puentes web, que eliminan las sesiones filtradas y restablecen el recuento de sesiones activas a 0. Comprensiblemente, esto puede ser tedioso si esto se convierte en una tarea diaria, por lo tanto, por qué esta tarea se puede facilitar con un script disponible según el bloque 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)
################################################################

La secuencia de comandos requiere algunas pequeñas modificaciones (las credenciales en la línea 29-30 y las direcciones IP de los puentes web en la implementación en la línea 27) y SOLO se debe ejecutar cuando no haya carga esperada o durante una ventana de mantenimiento. La secuencia de comandos no verifica las sesiones activas y simplemente ejecuta el comando 'webbridge restart' en todos los servidores enumerados, lo que no termina ninguna sesión WebRTC activa.

Para automatizar este script, se puede hacer configurando un trabajo cron o en un PC con Windows 10 con el Programador de tareas. Suponiendo que el PC Win 10 tenga Python 3.4+ instalado, pueden seguir estos pasos:

    1. Abrir el Programador de tareas

    2. Seleccione 'Crear tarea básica...'

    2.1 Introduzca un nombre/descripción para esta tarea

    2.2 Seleccione la frecuencia y las horas en las que desea ejecutar esta tarea (se recomienda que sea solo durante las horas de menor actividad, aquí se muestra para todos los sábados a las 2 AM)

    2.3 Acción a realizar, seleccione: 'Iniciar un programa'

    2.4 Acción:

    * Programa / Guión:  C:\<ruta de acceso a python.exe>

    (si no conoce la ruta de acceso a python.exe, puede encontrarla yendo a cmd y escribiendo: python -c "import sys; print(sys.ejecutable)")

    * Agregar argumentos (opcional): webbridge_restart.py (o nombre de la secuencia de comandos de python)

    * Comience en (opcional): C:\<path to webbridge_restart.py>

Tenga en cuenta que la computadora que ejecuta el trabajo cron debe poder acceder al MMP de los servidores CMS configurados. Una vez ejecutada la secuencia de comandos, crea un archivo webbridge_restart_logs.txt que contiene detalles sobre los reinicios de los diferentes WebBridges, así como sobre cualquier posible fallo. Se muestra un ejemplo con una conexión exitosa a 10.48.79.194 y una conexión fallida a 127.0.0.1 (como si fuera la dirección de loopback del PC en realidad).

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

¿Cómo probar que el guión funciona bien?

Si tiene Python instalado el equipo desde el que pretende ejecutar el script, puede ejecutarlo manualmente primero con los siguientes pasos:

1. Abra cmd y busque la ubicación del script con el comando 'cd'
   
   
   
   
2. Ejecute el archivo python con el comando 'python webbridge_restart.py'
   
   
   
   
3. En caso de que vea un error que indica que el módulo 'paramiko' no está instalado, debe instalar alguna biblioteca adicional con el comando 'pip install paramiko'
   
   
   
   
4. Una vez completado, puede ejecutar el script de nuevo con 'python webbridge_restart.py' (NOTA: esto reinicia webbridge y hace que se desconecten las conexiones actuales de WebRTC)
   
   Si se ha ejecutado correctamente, puede comprobar el resultado en el archivo webbridge_restart_logs.txt.

¿Cuándo está previsto solucionar este problema?

No se trata de un error nuevo y no hay ningún plan para corregirlo en Web Bridge 2 / CMA WebRTC. La nueva aplicación Web Bridge 3 / CMS (disponible a partir de 2.9) no se ven afectados por este error, ya que se ha rediseñado por completo. Los clientes que se vean muy afectados por esto deben plantearse cambiar a la nueva aplicación web de CMS (aunque tenga en cuenta que esta aún no es una paridad de funciones con Web Bridge 2 en la versión 2.9). Consulte las notas de la versión de la aplicación web CMS 2.9 y CMS para obtener más información).

Información Relacionada

• Notas de defectos: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt73723
• Notas de la versión: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-release-notes-list.html
• Preguntas frecuentes
  • https://meeting-infohub.cisco.com/faq/content/43/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html