Gracias por sus comentarios.

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

RESOLUCIÓN
Revise los pasos a continuación:

1. Abra la Cisco Unified Communications Manager de red (CM).
2. Haga clic en Sistema y > de servicio.
3. En Seleccionar servidor y servicio, en la casilla De lista desplegable servicio, seleccione Cisco Call Manager (Activo):

4. Busque el temporizador para caducar de la sesión de 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 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 sesión en la invitación inicial. Se debe recibir una actualización (INVITE/UPDATE) antes de que expire este tiempo:


En función de la negociación inicial del cliente del agente del usuario/servidor del agente del usuario (UAC/UAS), uno de los dispositivos actualiza la sesión cuando envía una nueva 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. Recoja los registros del Debug del SORBO de ambos puntos finales y marque estos elementos:

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

1.     La parte A tiene que enviar la reinvitación/ACTUALIZACIÓN al CUCM.
2.     CUCM tiene que enviar una nueva INVITACIÓN/ACTUALIZACIÓN a la Parte B.
3.     La parte B recibe la reinvitació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 reinvitación al CUCM, CUCM envía una reinvitación a la otra Parte. Sin embargo, si esto no es recibido por el lado remoto entonces esto podría ser debido a algunos dispositivos de red en el medio. Es altamente posible que la re-invitación/la respuesta no consiga a uno de los lados debido a la inspección del SORBO o a los ajustes de red.
Si los dispositivos no inician la reinvitación, 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 aún no lo ha hecho] en el área de configuración avanzada de la zona que va a Webex:
Active el modo de filtro SIP UDP/IX (no el predeterminado) :

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

Se encuentra en Configuración > Protocolos > SIP:


Tenga en cuenta que 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 identificar el problema un poco mejor. También es posible que necesitemos bajar este valor según la configuración de fw para este temporizador.

CAUSA
Cuando las videollamadas se desconectan exactamente a los 15 minutos, el problema común es que el tiempo de espera de TCP configurado en la red (firewall/routers) es menor que el temporizador de caducidad de la sesión SIP. Por abandono en el CallManager, el temporizador de la sesión del SORBO expira se fija a 1800 segundos.