Mis videollamadas a reuniones habilitadas para dispositivos de vídeo se eliminarán después de 15 minutos (o después de cualquier hora específica)

Mis videollamadas a reuniones habilitadas para dispositivos de vídeo se caen después de 15 minutos (o después de cualquier hora específica).

Las conexiones de videollamadas Cisco Webex reuniones habilitadas para dispositivos de vídeo se desconectan después de 15 minutos.

Las llamadas de SIP se caen después de un intervalo de tiempo definido.

Las conexiones a reuniones habilitadas para dispositivos de vídeo se desconectan después de 15 minutos.

Las videollamadas se caen después de 15 minutos.

 

Causa: Cuando las videollamadas se desconectan exactamente a 15 minutos, el problema común es el tiempo de espera de TCP configurado en la red (firewall/enrutadores) es menor que el temporizador de vencimiento de la sesión SIP. De manera predeterminada, en CallManager, el temporizador de caducidad de la sesión de SIP se establece en 1800 segundos.

Solución:

Para verificar esto:

  1. Abra Cisco Unified Communications Manager de red (CM).
  1. Haga clic en Sistema y > de servicio.
  2. En Seleccionar servidor y servicio, en el cuadro de diálogo lista desplegable servicio, seleccione Cisco Call Manager (activo):
Imagen agregada por el usuario
  1. Busque el temporizador para caducar de la sesión deSIP:
Imagen agregada por el usuario

Todos los dispositivos registrados en CUCM utilizan este temporizador. Cuando el dispositivo está en una llamada con otro dispositivo remoto, una de las partes tiene que actualizar la sesión y enviar una nueva INVITACIÓN o ACTUALIZACIÓN. Esta actualización debe enviarse antes de la mitad del temporizador de vencimiento de la sesión ( 1800/2 = 900 segundos = 15 minutos). Si no se recibe ningún mensaje de actualización, la llamada se desconecta.

Compruebe el temporizador de la sesión en la INVITACIÓN inicial. Se debe recibir una actualización (INVITE/UPDATE) antes de que caduque este tiempo:
Imagen agregada por el usuario

Según la negociación inicial del cliente del agente del usuario/del servidor del agente del usuario (UAC/UAS), uno de los dispositivos actualiza la sesión cuando envía un re-INVITACIÓN. Si el actualizador es UAC, el iniciador de la llamada tiene la responsabilidad de actualizar la sesión. Si el programa de actualización es UAS, el servidor tiene que actualizar la sesión. Recopile los registros de depuración de SIP desde ambos extremos y compruebe estos puntos:

Ejemplo: Llamada realizada de la parte A a cucm a la parte B. Si el actualizador es UAC en la parte A y UAS en la parte B:

1.     La parte A tiene que enviar la invitación/la actualización de nuevo al CUCM.
2.     CUCM debe enviar una nueva INVITACIÓN/ACTUALIZACIÓN a la parte B.
3.     La parte B recibe la invitación de nuevo y responde a ese mensaje con un 200 ok.
4.     CUCM debe enviar el 200 Aceptar a la parte A.

Si un dispositivo envía el mensaje de invitación re-invitar al CUCM, CUCM envía un re-INVITAR a la otra parte. Sin embargo, si no se recibe por el lado remoto, esto podría deberse a algunos dispositivos de red entre. Es muy posible que la re-invitación/respuesta no llegue a uno de los lados debido a una inspección SIP o a la configuración de la red.
Si los dispositivos no inician la invitación re-invitado, podría ser un problema con el dispositivo. Involucre al Centro de asistencia técnica (TAC) de Cisco para investigar más.
 
En la lista de cosas que debe probar [si todavía no lo ha hecho] en el área de configuración avanzada de la zona, vaya a Webex:
Active el modo de filtro SIP UDP/IXen [no el predeterminado]:
Imagen agregada por el usuarioY también verifique los temporizadores de sesión SIP en VCS-e.

 
El valor predeterminado es de 1800s [15 mins], que es estándar y querrá asegurarse que el temporizador de TCP de su firewall también coincida aquí, pero usted podría subir esto un poco para ver si tiene un efecto así como en su VCS.

Esto se encuentra en Configuración > Protocolos > SIP:
Imagen agregada por el usuarioNota el intervalo de actualización de la sesión (segundos) se establece en el valor predeterminado.

Puede intentar con 3600. Pero la raíz real del problema aquí es cuando el FW piensa que una sesión ya no está en uso [caso 1], cuando VCS realmente piensa que está bien y que la sesión aún está activa, pero no recibe un FIN/cierre en esa sesión/puerto e intenta volver a usarla y la llamada falle. [caso 2] es el FW cierra correctamente la conexión y envía un fin/cerrado y VCS registra una caída/borrado de llamada normal y la llamada también falle. Modificar el temporizador de la sesión aquí solo controla cuándo VCS se deserrá en una sesión después de que no haya podido recibir ningún ACK por ningún intento de comunicación con respecto al estado de la llamada.
 
Sin embargo, puede ayudarnos a encontrar el problema un poco mejor. También es posible que necesitemos bajar este valor según la configuración de fw para este temporizador.

¿Ha encontrado este artículo útil?