Resumen

  • La RFC 3323 definió la privacidad según la información que se oculta a cada parte, no como una promesa de que una petición SIP careciera de identidad.
  • El servicio podía ocultar cabeceras y, a la vez, guardar y restaurar el estado de enrutamiento del diálogo: la confianza cambiaba de lugar, no desaparecía.

El anonimato depende de quién observa

En 2002, la privacidad en SIP no era un interruptor entre “identificado” y “anónimo”. La RFC 3323 la planteó como la retención de información frente a una o varias partes de un diálogo. Un llamante podía ocultar su nombre real al destinatario y permitir que un servicio de confianza conociera su identidad. Otra configuración podía intentar ocultar detalles de red. La pregunta decisiva era: ¿anónimo ante quién?

Por eso, un campo From anónimo no significaba que la petición no incluyera direcciones útiles. La RFC recomendó anonymous.invalid para un URI SIP anónimo, pero las solicitudes posteriores del diálogo aún debían encontrar el extremo correcto. Podía ocultarse una identidad personal y conservar Contact, Via, Record-Route u otros datos de sesión necesarios para enrutar. La privacidad ofrecía una vista controlada del estado del protocolo; no lo borraba.

El servicio debía recordar lo que ocultaba

La RFC distinguió la privacidad solicitada por el usuario de la que aporta la red. El campo Privacy contempla user, header y session; none prohíbe que el servicio aplique acciones de privacidad, mientras que critical exige rechazar la petición si no se puede prestar el nivel solicitado. Son expresiones de intención, no autenticación, autorización, cifrado de medios ni prueba de que todos los intermediarios las respeten.

La privacidad de cabeceras mostraba el coste operativo. Un servicio podía actuar como B2BUA, retirar o modificar cabeceras identificativas, sustituir Contact por su propia dirección y guardar localmente las rutas originales. Cuando llegaban mensajes posteriores, debía restaurar lo necesario para continuar el diálogo. El destinatario veía menos; el servicio retenía más estado privilegiado. El usuario no era anónimo para ese servicio.

La privacidad de sesión exigía todavía más: un B2BUA y un intermediario de medios o anonimizador de tráfico. Como el servicio pasaba a formar parte de la comunicación, la RFC desaconsejó esa modalidad sin protección de medios de extremo a extremo, como SRTP. Es una advertencia arquitectónica, no una medición de despliegue.

Ocultar identidad crea un punto de control

La tensión histórica es clara: cuanto menos ve el destinatario, mayor puede ser la dependencia del componente que ejecuta el ocultamiento. El servicio decide qué elimina, retiene, modifica y restaura; además, debe ser confiable para preservar la continuidad del diálogo.

La RFC 3261 aporta el contexto de diálogos y rutas SIP. La RFC 3325 aborda después la identidad afirmada dentro de redes de confianza y aclara que no define un modelo general entre dominios de confianza. Son límites adyacentes, no una solución universal. La RFC 3323 no prueba adopción ni interoperabilidad. Documenta una decisión: reducir lo que aprende una parte, conservar suficiente estado para que continúe la llamada y nombrar al intermediario responsable de ese equilibrio.

Fuentes