Resumen

  • RFC 3680 modeló por separado el estado de registro de una dirección y el conjunto de contactos asociados. Aunque no hubiera ninguno, la dirección tenía el estado definido init.
  • Muchas notificaciones podían incluir solo los contactos modificados. El suscriptor debía aplicar las versiones en orden y solicitar una actualización completa si detectaba un salto; eso no demostraba presencia, actividad del dispositivo ni éxito de una llamada.

Una respuesta sin contactos seguía siendo una respuesta con estado. En RFC 3680, una dirección de registro (AoR) sin contactos vinculados permanecía en init. Esa máquina pertenecía a la dirección; cada contacto tenía otra distinta, que aparecía al registrarse y se eliminaba al desaparecer el contacto.

Publicado en marzo de 2004, RFC 3680 incorporó el paquete de eventos SIP reg. Un suscriptor autorizado enviaba SUBSCRIBE y recibía información en application/reginfo+xml. La notificación inicial podía contener el estado completo. Las posteriores normalmente mostraban solo los cambios. El documento indicaba full o partial y llevaba una versión: empezaba en cero y avanzaba de una en una dentro de esa suscripción.

El formato ahorraba datos, pero trasladaba trabajo al receptor. Un cambio parcial no enumera los contactos que siguen igual, así que el suscriptor debe mantener una tabla y combinar los mensajes en secuencia. Procesa la versión inmediatamente posterior; descarta una versión anterior. Si aparece un salto hacia delante, RFC 3680 recomienda refrescar para obtener una notificación completa. Sin esa recuperación, la tabla local puede parecer razonable y, aun así, omitir un cambio.

La máquina de la dirección aclara qué significa no tener contactos. El primer vínculo la mueve de init a active. Permanece activa mientras exista al menos un contacto. Cuando expira o se elimina el último, pasa a terminated y regresa enseguida a init; la transición final es invisible y no debe notificarse. El fin del contacto sí puede comunicarse como cambio de ese contacto. Así, desaparece el vínculo, no el estado de la dirección.

Active describe un registro, no a una persona. No prueba que alguien esté disponible, que el dispositivo funcione en ese momento ni que una INVITE llegue a buen puerto. RFC 3856 definió otro paquete SIP para presencia: los datos de registro pueden contribuir a ella, pero ambas semánticas no son intercambiables. Tampoco una especificación demuestra que una implementación siga sus reglas.

La aportación de RFC 3680 fue hacer observable el cambio sin perder de vista sus límites: mantener un estado para la lista vacía y dar al suscriptor una vía de resincronización tras perder una diferencia. La pregunta útil no es solo «¿hay un contacto?», sino «¿qué versión respalda esta vista, se perdió alguna actualización y qué permite concluir la evidencia de registro?»

Fuentes