Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

CSCvt73723 - Sesiones de fuga del servidor WebRTC después de una gran cantidad de sesiones realizadas en el servidor

¿Cómo identifica este error?

¿Cómo puede evitar este problema?

¿Cuándo se planea arreglar esto?

Información Relacionada

Introducción

Este documento describe la detección y la solución temporal en Cisco bug id CSCvt73723 alrededor de las sesiones de filtración del servidor WebRTC después de una gran cantidad de sesiones colocadas en el servidor. Esto puede hacer 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 el componente WebBridge 2 / CMA WebRTC. Este documento no se aplica al nuevo componente de aplicación WebBridge 3 / CMS que se ha introducido en la versión 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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

CSCvt73723 - Sesiones de fuga del servidor WebRTC después de una gran cantidad de sesiones colocadas en el servidor

¿Cómo identifica este error?

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

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

Calcular cuántas de estas sesiones son filtradas es un poco más complicado y puede hacerse si NO está usando el cliente de escritorio CMA o el cliente iOS. Desde la versión 2.8, Call Bridge informa cada 5 minutos el número de sesiones CMA (CMA WebRTC + cliente de escritorio CMA + cliente CMA iOS). Tenga en cuenta que esto se denomina "CMA": "X/Y", donde X es el número actual de sesiones CMA activas e Y es el pico en los últimos 5 minutos.

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

El hecho de que Call Bridge esté informando de 14 sesiones en curso no significa que el Web Bridge ubicado de forma conjunta también esté informando 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 crear instancias de una llamada en un Call Bridge diferente (especialmente cuando el balanceo de carga está habilitado, lo que de forma predeterminada es 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 comparar esto con las estadísticas combinadas del puente de llamadas de CMA que se informan.

¿Cómo puede evitar este problema?

Dependiendo de la frecuencia con la que su implementación llegue a esta situación (una vez cada par de días o una vez cada par de semanas), se le debe aconsejar que reinicie sus puentes web, que eliminan todas las sesiones filtradas y restablecen el número de sesiones activas en 0. Comprensiblemente, esto puede ser tedioso si se convierte en una tarea diaria, por lo que 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 modificaciones pequeñas (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 SOLAMENTE se debe ejecutar cuando no hay carga esperada o durante una ventana de mantenimiento. El script no verifica las sesiones activas y simplemente realiza el comando 'webbridge restart' en todos los servidores enumerados que terminan cualquier sesión activa de WebRTC.

Para automatizar esta secuencia de comandos, se puede realizar configurando un trabajo cron o en un PC con Windows 10 con Task Scheduler. Suponiendo que el PC Win 10 tenga Python 3.4+ instalado, pueden seguir estos pasos:

1. Abrir 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 a las que desea ejecutar esta tarea (se recomienda que sólo se realice durante las horas fuera de las horas punta, aquí se muestra para cada sábado a las 2AM)

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

2.4 Acción:

* Programa / Guión:  C:\<path to 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)")

* Añadir argumentos (opcional): webbridge_restart.py (o nombre del script python)

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

Tenga en cuenta que el equipo que ejecuta el trabajo cron debe poder acceder al MMP de los servidores CMS configurados. Después de ejecutar el script, crea un archivo webbridge_restart_logs.txt que contiene detalles sobre los reinicios de los diferentes WebBridges así como cualquier posible falla. Se muestra un ejemplo con una conexión exitosa a 10.48.79.194 y una falla a 127.0.0.1 (como 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 script funciona bien?

Si ha instalado Python en el PC desde el que desea 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, necesita 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 el webbridge y hace que las conexiones WebRTC actuales se desconecten)

Si se ha ejecutado correctamente, puede comprobar el resultado en el archivo webbridge_restart_logs.txt.

¿Cuándo se planea arreglar esto?

Este no es un error nuevo y no hay plan para corregirlo en el Web Bridge 2 / CMA WebRTC. La nueva aplicación web de Web Bridge 3 / CMS (disponible a partir de 2.9) no se ve afectada por este error, ya que se ha rediseñado completamente. Los clientes que se ven gravemente afectados por esta situación deben considerar la posibilidad de migrar a la nueva aplicación web de CMS (aunque tenga en cuenta que aún no existe paridad de funciones con Web Bridge 2 en la versión 2.9. Revise las notas de la versión de la aplicación web CMS 2.9 y CMS para obtener más detalles sobre esto.)

Información Relacionada

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

- Release Notes: 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