Resumen

  • RFC 4028 extiende la expiración de una sesión SIP únicamente cuando un re-INVITE o UPDATE de refresco obtiene respuesta 2xx. Intentar, recibir 422 o ver tráfico no mueve el plazo.
  • Session-Expires, Min-SE y refresher reparten carga, frecuencia y obligación de refrescar; no certifican voz, presencia humana, calidad, consentimiento ni derecho de cobro.
  • Una decisión defendible conserva por separado transacción, diálogo, medios, aplicación y estado comercial, y explica sus discrepancias antes de llamar viva o terminada a la sesión.

Dos relojes para una misma llamada aparente

Un operador cursa la señalización SIP por proxies con estado y el audio RTP por una ruta distinta. El refrescador envía UPDATE sin SDP al llegar a la mitad del intervalo. La respuesta 200 OK vuelve a tiempo. El proxy amplía su vencimiento.

La ruta de audio, sin embargo, perdió conectividad unos segundos antes. No llega voz en una dirección y RTCP ya no informa recepción. El software del terminal sigue activo aunque la persona haya abandonado la interacción. Si el motor de cobro entiende “refrescada” como “consumida”, la factura crecerá sobre una inferencia.

RFC 4028 nació para limitar otro problema: los proxies que conservan estado no siempre ven un BYE, porque el agente no lo envía o la red lo pierde. Un refresco periódico permite que las partes renueven el estado SIP y que, sin éxito, llegue una limpieza acotada.

El propio RFC separa esta vitalidad de la que puede revelar RTCP en una sesión de audio. La extensión no pretende observar el habla; pretende que el estado de señalización no sobreviva sin límite.

Tres conceptos bajo la palabra «tiempo»

El intervalo de sesión es el máximo permitido entre refrescos exitosos y queda fijado por el Session-Expires del último 2xx aplicable.

El temporizador mínimo es la frecuencia máxima de trabajo que un elemento tolera. Min-SE evita que otro nodo le imponga peticiones continuas.

La expiración es un cálculo local. El UAS empieza desde el envío del 2xx; el UAC, desde su recepción; cada proxy usa lo que observó. El tránsito crea márgenes diferentes. No existe una hora mundial firmada por todos.

Para reconstruir una decisión hay que guardar el mensaje que instaló el intervalo, los tiempos en cada lado, la identidad del refrescador y el plazo calculado. El dato “1.800 segundos” por sí solo no dice quién lo eligió ni cuándo empezó a correr.

El camino también tiene voto técnico

El UAC puede anunciar timer y proponer una duración. Los proxies que necesitan conservar estado pueden solicitar el mecanismo, reducir Session-Expires o elevar Min-SE. No pueden exigir un intervalo por debajo del suelo acumulado. El UAS incluye la duración final y refresher en el 2xx; los proxies de retorno la observan sin volver a escribirla.

Una duración inferior al mínimo produce 422 Session Interval Too Small y un Min-SE. El UAC puede repetir en una transacción nueva con CSeq mayor y recordando el máximo pertinente.

Pero 422 no refresca. El plazo anterior sigue avanzando. Un 422 cerca del vencimiento puede exigir una duración mayor para el futuro y, al mismo tiempo, dejar escasos segundos para completar el nuevo intento. Contar solo el 200 posterior borra ese riesgo.

El mínimo también limita denegación de servicio. Una oleada de 422 puede señalar cambio de ruta, defensa de carga, configuración defectuosa o presión maliciosa. El código de respuesta no decide cuál.

El rol no es la identidad

refresher=uac o refresher=uas indica quién generará el siguiente refresco. UAC y UAS son roles de transacción. El receptor del INVITE inicial puede convertirse en UAC cuando envía UPDATE.

Por eso uac no significa necesariamente llamante, cliente pagador ni usuario autenticado. El registro debe resolver el rol a un endpoint concreto para ese diálogo, método, CSeq y sentido.

Un INVITE bifurcado agrava la cuestión. Puede crear varios diálogos con intervalos y responsables distintos. La rama que se refresca no mantiene a su hermana. Además, una negociación posterior puede cambiar el rol o recibir un 2xx sin Session-Expires, lo que desactiva el temporizador.

El umbral exacto: 2xx

Solo un 2xx mueve la expiración. El envío de la petición, una provisional, un 401/407, un 422, una escritura de socket o el paso por un proxy no tienen ese efecto.

Si la transacción expira o devuelve 408 o 481, el UA refrescador envía BYE. Otros errores pueden justificar reintento limitado. La parte no refrescadora, si no recibe nada a tiempo, debería enviar BYE un poco antes de su vencimiento. La anticipación recomendada es el menor valor entre 32 segundos y un tercio del intervalo, porque firewalls y ALG pueden cerrar el camino justo al expirar.

El proxy actúa de otra manera: puede borrar su propio estado y liberar recursos; no debe originar BYE. Limpiar memoria de intermediario no equivale a ordenar que los endpoints terminen.

Así nacen estados legítimamente divergentes. El proxy ya olvidó, el audio directo todavía circula. BYE salió, pero se perdió. Dos plazos locales no coinciden al milisegundo. Un sistema honesto conserva la divergencia en lugar de fabricar una única hora de fin.

El refresco puede traer cambios de sesión

Un re-INVITE o UPDATE de refresco sigue siendo una petición normal. RFC 3311 permite que UPDATE cambie información de sesión y objetivo remoto. RFC 3261 aplica a re-INVITE las reglas del diálogo, la secuencia y oferta/respuesta.

RFC 4028 recomienda UPDATE sin oferta para un refresco puro cuando el par lo soporta. re-INVITE suele llevar oferta aunque no cambie, y una petición nacida para otro cambio también refresca el temporizador.

Por tanto, el mismo 2xx puede acompañar Contact nuevo, SDP, hold, dirección distinta, codec o dirección IP nueva. RFC 6141 describe colisiones, 491 y restauración de estado porque re-INVITE no es un pulso vacío.

La observabilidad debe conservar si había SDP, su huella y versión, direcciones de flujo, Contact, desafío de autenticación y respuesta definitiva. “Refresco correcto” es un resumen demasiado pequeño si el mensaje también cambió el servicio.

Medios y presencia viven fuera del 2xx

RFC 3264 negocia flujos sendonly, recvonly, sendrecv, inactive o rechazados con puerto cero. Son acuerdos descriptivos, no recibos de paquetes.

RFC 3550 dice que RTP no garantiza entrega ni calidad. RTCP ofrece informes valiosos sobre recepción y participantes, pero tampoco prueba que una persona escuche, consienta o reciba valor.

Conviene separar cinco capas: transacción SIP; diálogo y timer; RTP/RTCP; aplicación y humano; contrato, cobro y cumplimiento. El 2xx es sólido para las dos primeras. Para las demás es, como máximo, contexto.

La señalización puede refrescar mientras el audio muere. El audio puede continuar durante una partición SIP. Un flujo inactive puede ser correcto. Un agente automático puede mantener el diálogo cuando ya no existe atención humana.

La doctrina de Heng Lu sobre capas de realidad encaja aquí: el registro no es falso, pero no adquiere autoridad por encima del sistema que ejecuta. La coordinación común debe permanecer estrecha y las decisiones futuras quedar en manos responsables y verificables.

Seguridad por saltos, no verdad universal

Los proxies modifican legítimamente estos campos. La protección de extremo a extremo con S/MIME no sirve para un valor que el camino debe tocar. RFC 4028 recomienda TLS salto a salto y SIPS.

Un camino protegido reduce la manipulación externa que podría imponer intervalos cortos. No convierte la duración en prueba de medios, persona o cobro. Y si falta protección en un salto, la fuerza de toda la cadena cambia.

El registro de erratas contiene correcciones verificadas y propuestas aún abiertas. Una reportada en mayo de 2026 discute cómo un proxy trata una preferencia explícita refresher=uas. Sigue con estado Reported. Debe alimentar pruebas y una nota de incertidumbre, no afirmaciones normativas.

Evidencia para explicar una decisión

Una traza defendible une Call-ID y tags con cada rol real. Guarda método, CSeq, branch, ruta, campos antes y después de los proxies, tiempos, vencimientos y el 2xx que los movió.

Registra SDP, oferta/respuesta, direcciones, Contact, desafíos y reintentos. Atribuye BYE a acción humana, fallo del refrescador, expiración del par o política. Mantiene RTP/RTCP, estado de aplicación y cobro fuera del registro SIP, pero correlacionables.

Los mensajes revelan identidad y topología. Se puede reservar el original para investigación y usar huellas con clave o proyecciones en métricas generales.

Las pruebas mínimas incluyen 422 tardío, 401 seguido de éxito, 408, 481, ausencia de refresh, limpieza de proxy sin BYE, medios muertos con SIP fresco, medios vivos tras pérdida SIP, forks con timers distintos, desactivación, UPDATE sin oferta, re-INVITE con SDP modificado, cambio de objetivo, failover y salto no protegido.

El producto final no es “activo/inactivo”. Es una explicación de qué capa continuó y qué autoridad tomó cada decisión.

Fuentes