Resumen

  • RFC 3087 permitía que un cliente o proxy SIP comunicara el estado inicial de una aplicación escogiendo una Request-URI distinta: depositar, usar cierto saludo, recuperar mensajes o pedir un PIN.
  • La URI seleccionaba una conducta configurada localmente. No demostraba la identidad del llamante, su derecho sobre el buzón, la causa real del desvío ni que alguien hubiera guardado o escuchado el mensaje.

La llamada conservó un destinatario y cambió de servicio

Un buzón de voz tradicional podía mirar el número llamado, el número de origen y el motivo del desvío. Con esas pistas decidía si reproducir el saludo de ocupado, el de ausencia, abrir un buzón concreto o llevar a un abonado directo al menú de consulta. La comodidad dependía de que la red telefónica transmitiera señales cuyo significado local se diera por bueno.

SIP permitía una trayectoria menos lineal. Varios proxies podían redirigir una petición. El campo To podía seguir nombrando al destinatario lógico inicial aunque el servicio que debía atender el siguiente salto fuera otro. RFC 3087 lo muestra con una cadena sencilla: A llama a B, B desvía a C y C desvía a su propio buzón. Si la aplicación usa To: B para escoger el almacén, termina ante la persona equivocada.

El RFC, publicado como Informational en abril de 2001, no añadió métodos ni cabeceras. Aprovechó una propiedad ya definida por RFC 2543: el proxy podía reescribir la Request-URI, a diferencia de To. El destino operativo de la petición podía ser una identidad de servicio y esa identidad podía abrir el estado inicial adecuado.

El avance era conceptual antes que sintáctico. El contexto dejaba de ser una conjetura que el buzón reconstruía al final; pasaba a ser una decisión explícita tomada durante el encaminamiento.

Un solo buzón podía tener varias entradas

El documento imagina muchas identidades SIP provisionadas para un abonado. Una acepta depósitos con el saludo normal; otra usa el saludo de ocupado; una tercera ofrece un mensaje especial. Para consultar, una dirección puede esperar autenticación SIP y otra comenzar con la petición de un PIN por voz. Las entradas genéricas preguntan primero qué buzón se desea.

Un proxy de búsqueda podía seleccionar la entrada. Si agotaba los contactos sin respuesta, enviaba la llamada al depósito ordinario. Si recibía ocupado en todas partes, elegía el anuncio de ocupado. Un estado de no molestar podía terminar en otra identidad. El buzón no necesitaba recomponer la decisión leyendo To, From y señales heredadas; recibía como destino el comportamiento deseado.

Sin embargo, el texto visible de la URI no era un lenguaje normalizado. RFC 3087 aconsejaba que la aplicación no impusiera reglas semánticas a nombres mnemónicos. El operador podía usar una palabra, un número o un parámetro arbitrario, siempre que la URI SIP fuera válida y estuviera provisionada. La tabla que daba significado a cada identidad pertenecía al sistema.

Por eso una captura con busy no certifica una línea ocupada. Certifica que en un salto apareció esa cadena. Para saber qué significaba y por qué fue elegida hacen falta la versión de la configuración y el registro de la decisión del proxy.

Elegir la puerta no era tener la llave

Los casos de recuperación separan ruta y admisión. Una fuente de confianza podía delegar la autenticación mediante una relación segura con el buzón. Una petición con autenticación SIP válida podía seguir el flujo privilegiado. Si la autenticación fallaba o no existía, el servicio o su proxy protector podía redirigir a una URI que pidiera el PIN dentro de la llamada.

Una URI específica de recuperación elegía el proceso; no concedía acceso por sí misma. La relación de confianza, las credenciales SIP o el PIN resolvían el permiso. Incluso reconocer un número procedente de la PSTN era una suposición aceptada por el proveedor, no una prueba criptográfica de la persona que hablaba.

Los flujos detallados del RFC suponen un proxy protector y confianza entre este y el servicio de voz. La sección de seguridad no creó una nueva defensa, sino que remitió a las condiciones de SIP.

Un registro de red solo permite afirmaciones acotadas: llegó una INVITE; el proxy eligió una URI; la aplicación aceptó el destino; se ejecutó cierta rama de autenticación; se estableció RTP. Ninguno de esos hechos aislados prueba la titularidad humana, la verdad histórica del desvío, el almacenamiento duradero de una grabación o su escucha posterior.

La configuración local aún no era interoperabilidad

RFC 3261 sustituyó la primera especificación de SIP y conservó la distinción esencial: la Request-URI señala el usuario o servicio actual y el proxy la reemplaza al escoger un destino. Más tarde, History-Info permitió transportar el historial de redirecciones. Son capas útiles para interpretar el diseño, no pruebas de que una instalación concreta de RFC 3087 las usara.

En 2006, RFC 4458 definió los parámetros target y cause para buzones e IVR. Su motivación deja clara la frontera: cada proveedor podía hacer configurables sus propios mapas, pero eso no bastaba para que controles de llamada, pasarelas y mensajería unificada de fabricantes diferentes entendieran del mismo modo el buzón y la causa solicitados.

RFC 3087 enseñó a usar la URI como superficie de control dentro de una arquitectura. RFC 4458 añadió vocabulario compartido para cruzar límites de implementación. Que el segundo fuera necesario no demuestra fracaso, éxito comercial ni adopción del primero.

La lección que permanece es la cadena de evidencias: objetivo original, Request-URI actual, regla de reescritura, mapa local, autenticación, menú, sesión de medios y recibo de almacenamiento se relacionan sin ser la misma cosa. Llevar el contexto en la ruta reduce la adivinación. No convierte la ruta en identidad.

Fuentes

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html