Resumen

  • El proxy debe generar periódicamente nuevas referencias PURR aunque no cambien los parámetros del servicio de notificación. También debe mantener los valores anteriores mientras sigan en curso los diálogos asociados.
  • PURR es una referencia única dentro del contexto del proxy: no es una identidad mundial del dispositivo ni una autorización general para despertarlo.
  • La frontera combina decisión por diálogo, continuidad de la ruta y conservación local de dependencias, sin convertir el cambio de referencia en una supuesta extinción de obligaciones.

El mantenimiento tiene dos clientes

Cuando se renueva una referencia, el sistema sirve a dos grupos distintos. Los interlocutores futuros deberían recibir un valor reciente, menos útil para relacionar actividad a lo largo del tiempo. Los interlocutores de conversaciones ya establecidas pueden necesitar todavía el anterior. Una mejora para los primeros no demuestra que los segundos hayan dejado de existir.

Esta diferencia permite plantear un ejemplo sencillo. Un agente de usuario abre un diálogo con una referencia a la que llamaremos P1. Más tarde recibe P2 durante otro registro. Un nuevo diálogo puede anunciar P2, mientras una petición intermedia del diálogo anterior todavía utiliza P1. Son etiquetas explicativas y una situación hipotética, no datos de una instalación inspeccionada.

Si el proxy ha eliminado P1, la actualización puede parecer impecable: P2 se reconoce, el registro reciente funciona y las conversaciones nuevas progresan. Sin embargo, falta la asociación que la conversación antigua sigue utilizando. Ninguna de esas pruebas recientes acredita que su dependencia haya terminado.

RFC8599, publicado en mayo2019, contiene las dos obligaciones necesarias para evitar esa falsa conclusión. En el apartado6.2.1 exige producir una nueva Proxy Unique Registration Reference, PURR, de manera periódica, incluso cuando los parámetros de notificación no cambian. Exige asimismo conservar los valores antiguos mientras continúen los diálogos asociados a ellos.

No se trata de una recomendación genérica de guardar más información. Es una separación entre renovación de lo que se revela y continuidad de lo que aún debe resolverse. El estándar no pide sacrificar la privacidad para mantener el servicio, ni autoriza a abandonar el servicio en nombre de la privacidad.

Despertar no equivale a entregar la petición

SIP puede conservar un vínculo de registro útil aunque la aplicación móvil esté suspendida y no pueda recibir señalización continuamente. El mecanismo de notificación permite que el proxy solicite al servicio correspondiente, PNS, que despierte al agente. Al volver a estar disponible, este actualiza su registro y puede recibir señalización mediante las condiciones renovadas.

La notificación no sustituye a la petición SIP. Su aceptación por el proveedor no prueba que el mensaje del diálogo haya llegado, que el agente haya completado el registro o que la transacción siga dentro de su plazo. Es una intervención en la disponibilidad de la aplicación, no una entrega automática de todo lo pendiente.

El agente obtiene del PNS un identificador PRID con formato propio del proveedor. En el registro SIP comunica los datos necesarios al proxy: proveedor, PRID y, si el servicio lo necesita, un parámetro adicional. La búsqueda del PNS, el alta en él y el mantenimiento de esa relación quedan fuera del mecanismo que RFC8599 define.

Así aparecen varias vidas útiles. El recurso del proveedor puede dejar de ser válido; un vínculo SIP puede expirar; una conexión puede fallar; un diálogo puede continuar; una petición concreta puede agotar su tiempo. Interpretarlo todo como una sola sesión «activa» borra los límites que explican quién puede hacer qué.

Las reglas de registro se aplican a vínculos individuales. Un agente puede mantener más de uno, y el despertar desencadena su actualización según el procedimiento. No hay que inventar un registro global único para el dispositivo con el fin de simplificar un razonamiento que precisamente depende de distinguir asociaciones.

Lo que recibe el interlocutor es deliberadamente menos

Un interlocutor de una conversación no necesita conocer las coordenadas privadas con las que el proxy solicita notificaciones. RFC8599 prohíbe que el agente incluya los parámetros de notificación pertinentes en peticiones distintas de REGISTER, salvo pn-purr. La excepción permite comunicar una referencia sin distribuir pn-provider, pn-prid y pn-param a la otra parte.

PURR ofrece una búsqueda indirecta. El proxy crea un valor único en su propio contexto y lo relaciona con los datos almacenados para solicitar la notificación. La palabra «único» no significa que exista un registro mundial de valores ni que la referencia identifique a un teléfono ante cualquier operador.

El valor debe ser imposible de falsificar, anónimo y no vinculable para entidades ajenas al proxy. Este último sí tiene que poder establecer la asociación; de otro modo no serviría para resolver la petición. Un espacio suficientemente amplio de valores aleatorios seguros es una posibilidad técnica, no un algoritmo obligatorio para todas las organizaciones.

La protección se refiere a las propiedades de la referencia. No asegura que todos los encabezados SIP sean anónimos, que los registros de actividad carezcan de información identificable o que una aplicación no divulgue otros datos. Usar una cadena opaca no convierte mágicamente el conjunto de la comunicación en un entorno sin metadatos.

Tampoco debe confundirse PURR con una GRUU. RFC5627 define una URI globalmente encaminable hacia una instancia concreta del agente de usuario. La búsqueda local de información de registro para pedir una notificación desempeña otra función. Compartir el objetivo amplio de facilitar la comunicación no vuelve equivalentes los instrumentos.

La ventaja del cambio periódico es que una misma referencia pública no permanezca como punto estable de correlación. Pero la asociación interna que presta servicio a un diálogo no tiene por qué desaparecer al mismo ritmo. El proxy responsable puede conservar una dependencia limitada sin ofrecerla como información reutilizable a terceros.

La participación se decide conversación por conversación

La capacidad del proxy no obliga a todas las aplicaciones a usarla en todos los diálogos. RFC8599 deja al agente la decisión según su política local. Puede considerar las características del diálogo o de sus medios. La elección de una conversación no se convierte en una autorización permanente para cualquier actividad posterior del terminal.

Cuando decide participar, el agente incluye pn-purr en el Contact inicial pertinente, empleando la última referencia recibida mediante sip.pnspurr. Si no ha recibido ese indicador, no debe inventar el parámetro. La otra parte recibe una capacidad ofrecida realmente por el proxy, no una afirmación unilateral de la aplicación.

Feature-Caps, cuyo marco define RFC6809, permite anunciar funciones de entidades que no están representadas por la URI Contact. El registro IANA describe sip.pnspurr en términos de asociación entre mensajes intermedios y datos de registro. Eso no concede al interlocutor control general del proveedor de notificación.

Por tanto, disponer de una referencia no basta para describir una autorización completa. Hay que considerar la elección del agente, la ruta del diálogo, la asociación local, el registro que corresponde y las reglas de admisión del PNS. Son condiciones diferentes, con responsables y evidencias diferentes.

Esta separación permite que una aplicación adopte una política apropiada para su actividad sin solicitar una clasificación central de cada conversación. También limita el poder del operador: una respuesta favorable del proveedor no prueba que se haya respetado la elección del diálogo ni convierte en válido un vínculo que ya terminó.

La renovación no es un certificado de cierre

El valor nuevo informa sobre una emisión reciente. No informa, por sí solo, sobre todas las dependencias anteriores. Un registro posterior puede proporcionar P2 sin demostrar que todos los diálogos hayan sustituido la información de contacto aprendida al empezar. Si una conversación aún usa P1, la asociación vieja sigue teniendo una función.

Esta observación modifica el criterio de limpieza. El estándar vincula la conservación a diálogos asociados que siguen en curso. No fija un intervalo universal de rotación ni un plazo global tras el cual todas las referencias antiguas puedan borrarse. Un calendario de mantenimiento puede ser práctico, pero no es evidencia de que una conversación haya concluido.

Conservar lo necesario tampoco significa preservar cada referencia para siempre. La dependencia tiene una frontera, aunque su duración concreta sea propia de la instalación. Presentar el asunto como una elección entre borrado inmediato y almacenamiento infinito evita la pregunta real: qué diálogo sigue requiriendo qué asociación, y cuándo deja de hacerlo.

Para dimensionar la memoria, contar únicamente los registros actuales puede resultar insuficiente. La cadencia con que se emiten referencias, la duración de las conversaciones y el cierre de dependencias pueden influir. Es una inferencia operativa de este análisis, no una cifra medida ni una estructura de datos prescrita por RFC8599.

La misma lógica vale para una sustitución de nodos. Que el sucesor conozca el registro más reciente no acredita que pueda resolver referencias antiguas utilizadas por conversaciones existentes. El estándar no establece un procedimiento universal de replicación, migración de proxys o reparto de asociaciones entre particiones.

Por eso el coste de adoptar la función no se agota al mostrar una referencia nueva. Incluye mantener localmente la responsabilidad anunciada. Esa carga puede exigir trabajo de ingeniería, pero su existencia no demuestra la necesidad de un directorio global que reúna todas las asociaciones.

Una asociación guardada necesita una ruta que la encuentre

La información correcta en el nodo equivocado no sirve a la petición que nunca lo visita. El proxy participante se incluye mediante Record-Route en el establecimiento aplicable del diálogo, para seguir en la ruta de los mensajes posteriores. El conjunto de rutas y el destino remoto del diálogo forman parte del marco de RFC3261.

Path resuelve una cuestión cercana, pero distinta. RFC3327 permite registrar intermediarios necesarios para llegar a un agente inscrito. Record-Route conserva el recorrido pertinente de una conversación establecida. Un registro bien formado no prueba automáticamente que su diálogo posterior atraviese el proxy que puede resolver PURR.

RFC5626 aborda conexiones iniciadas por el agente, mantenimiento de flujos y varias conexiones ante NAT o cortafuegos. Eso tampoco elimina la posibilidad de que la aplicación esté suspendida. Tener una ruta, tener un vínculo y tener una aplicación disponible no son nombres diferentes de un único hecho comprobado.

En el tratamiento intermedio correspondiente, pn-purr puede aparecer en la URI de la petición o en una URI Route, según cómo se construya el conjunto de rutas. Si el proxy recupera la información necesaria, coloca el mensaje en espera y pide una notificación. Al recibir la respuesta2xx de la transacción REGISTER asociada, transmite la petición del diálogo que corresponde.

Aquí no aplica la comparación de URI del apartado5.3 utilizada en otros tratamientos. La petición intermedia no lleva las coordenadas privadas pn-prid, pn-provider y pn-param. La asociación se realiza con PURR y la respuesta de registro pertinente. Ocultar las coordenadas cambia efectivamente la lógica de resolución, no solo la apariencia del mensaje.

Esta descripción se limita al apartado6.2.3. Las peticiones iniciales tienen condiciones propias, incluidas diferencias de secuencia según el transporte. No sería correcto afirmar que cualquier petición SIP, en cualquier caso, espera siempre una respuesta REGISTER2xx.

Continuar una responsabilidad no prolonga cualquier permiso

El vínculo de registro conserva su propia frontera. Si el proxy es informado de que ha expirado o se ha eliminado, RFC8599 le exige no pedir más notificaciones con el PRID correspondiente. Que una referencia antigua figure todavía en un diálogo no resucita ese vínculo ni restablece un recurso del proveedor inválido.

La petición pendiente también tiene un plazo. El emisor puede dar por fallida su transacción mientras el proxy espera la notificación y el registro. El texto advierte expresamente de esa posibilidad y recomienda que el error afecte a la transacción pertinente, en vez de perjudicar innecesariamente al diálogo entero.

Conservar una asociación es, por tanto, una obligación de continuidad acotada. No promete disponibilidad permanente, entrega inevitable ni una suspensión infinita de los límites del solicitante. Un resultado tardío puede no tener ya el efecto que se pretendía, aunque todos los componentes hayan vuelto a responder.

Las reglas de autenticación y autorización específicas del PNS siguen perteneciendo a ese servicio. RFC8599 exige señalización SIP debidamente protegida y que los parámetros privados no se divulguen a usuarios o entidades no fiables. Los avisos de eventos de registro son otro posible camino de exposición que debe tratarse con cuidado.

RFC8030 explica la seguridad de HTTP Web Push, pero no sustituye la elección de política de la aplicación SIP. Una notificación aceptada por el proveedor, una referencia encontrada por el proxy y un diálogo establecido son tres hechos distintos. Reunirlos en un único «permiso» dificulta atribuir correctamente el coste de despertares innecesarios.

La evidencia de implementación tiene un alcance preciso

La documentación fijada del módulo registrar de OpenSIPS3.6 describe pn_enable_purr, pn_process_purr y el tiempo configurable pn_refresh_timeout. Muestra que anunciar la función, resolver la referencia y mantener una petición en espera requieren piezas concretas. No es una inspección de una red actualmente desplegada.

Las dos publicaciones de OpenSIPS de2020 explican históricamente el registro y las solicitudes durante el diálogo. No prueban que una instalación concreta conserve todos los valores exigidos o que una réplica los transfiera sin pérdidas. En esta investigación no se ha enviado señalización a ningún operador ni comprobado una implementación en funcionamiento.

Los errata también deben mantener su estatus. El8136 es editorial y está verificado: corrige sip.pnsreq por sip.pnsreg en el apartado4.1.4. El7136 es técnico y está reportado, sobre ejemplos de URI de REGISTER; no es una revisión normativa aceptada. La claridad del argumento no necesita fingir una prueba de paquetes ni convertir un informe pendiente en regla nueva.

La lección es más exigente que «rote sus identificadores». Hay que renovar lo que conviene no exponer de forma estable y conservar, de manera local y limitada, lo que las conversaciones aún utilizan. El punto de control no es una autoridad que autorice cada llamada, sino la frontera que impide confundir novedad con desaparición de obligaciones.

Fuentes