PROBLEMA
Al entrar a una reunión de Webex con un dispositivo de vídeo registrado por CUCM, la llamada se desconecta exactamente a los 15 minutos.

SOLUCIÓN
Revise los pasos a continuación:

1. Abra la administración de Cisco Unified Communications Manager (CM).
2. Haga clic en Sistema > Parámetros de servicio.
3. En Seleccionar servidor y servicio, en el cuadro de lista desplegable Servicio, seleccione Administrador de llamadas de Cisco (activo):

4. Busque el Temporizador de caducidad de sesión SIP:

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 que caduque la mitad del temporizador 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 sesión en la invitación inicial. Debe recibirse una actualización (INVITE/UPDATE) antes de que caduque este tiempo:


En función de la negociación inicial del cliente del agente de usuario/servidor del agente de usuario (UAC/UAS), uno de los dispositivos actualiza la sesión cuando envía una nueva invitación. Si la actualización es UAC, el iniciador de la llamada tiene la responsabilidad de actualizar la sesión. Si la actualización es UAS, el servidor tiene que actualizar la sesión. Recopile los registros de depuración de SIP de ambos extremos y compruebe estos elementos:

Ejemplo: Llamada realizada desde la parte A a CUCM a la parte B. Si la actualización es UAC en la parte A y UAS en la parte B:

1.     La parte A tiene que enviar la nueva INVITACIÓN/ACTUALIZACIÓN al CUCM.
2.     CUCM debe enviar una nueva INVITACIÓN/ACTUALIZACIÓN a la Parte B.
3.     La parte B recibe la nueva invitación y responde a ese mensaje con 200 OK.
4.     CUCM tiene que enviar 200 OK a la parte A.

Si un dispositivo envía el mensaje de re-INVITE al CUCM, el CUCM envía una re-INVITE a la otra parte. Sin embargo, si el lado remoto no lo recibe, podría deberse a algunos dispositivos de red intermedios. Es muy posible que la re-INVITE/respuesta no llegue a uno de los lados debido a la inspección SIP o a la configuración de red.
Si los dispositivos no inician la re-INVITE, podría ser un problema con el dispositivo. Involucre al Centro de asistencia técnica (TAC) de Cisco para investigar más a fondo.
 
En la lista de cosas para probar [si aún no lo ha hecho], en el área de configuración avanzada de la zona que va a Webex:
Gire el modo de filtro UDP/IX SIP a activado [no el predeterminado]:

Y compruebe los temporizadores de sesión SIP también en VCS-e.
 
Nuestro valor predeterminado es 1800 [30 minutos], que es estándar, y debe asegurarse de que el temporizador TCP de su firewall coincida también aquí, pero podría superarlo un poco para ver si tiene un efecto también en su VCS.

Esto se encuentra en Configuración > Protocolos > SIP:


Tenga en cuenta que el intervalo de actualización de la sesión (segundos) está configurado en el valor predeterminado. Puedes probar el 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 todavía está en funcionamiento pero no recibe una FIN/cierre en esa sesión/puerto e intenta volver a utilizarla y la llamada se muere. [caso 2] es que el FW cierra correctamente la conexión y envía una FIN/cierre y VCS registra una caída/eliminación de llamada normal y la llamada también se muere. La modificación del temporizador de sesión aquí solo controla cuándo VCS abandonará una sesión después de que no haya recibido ninguna ACK para cualquier intento de comunicación con respecto al estado de la llamada.
 
Sin embargo, nos puede ayudar a identificar el problema un poco mejor. También es posible que tengamos que reducir este valor según la configuración de firewall para este temporizador.

CAUSA
Cuando las videollamadas se desconectan a los 15 minutos exactos, el problema común es que el tiempo de espera de TCP configurado en la red (firewall/enrutadores) es menor que el temporizador de caducidad 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.