Resumen

  • comp=sigcomp actuaba sobre el próximo salto: en una URI gobernaba la solicitud, en Via la respuesta y en Contact o Record-Route parte del tráfico posterior.
  • La marca comunicaba soporte y disposición actual para recibir compresión. No demostraba que el mensaje viajara comprimido, fuera analizado, llegara, estuviera autenticado ni estableciera una sesión.

La historia de RFC 3486 puede leerse como una secuencia de sobres. En el sobre de una solicitud había una URI de próximo salto. En el de la respuesta, la entrada Via superior. Para el tráfico futuro aparecían Contact y Record-Route. La decisión de comprimir no pertenecía a una llamada abstracta: pertenecía al sobre que señalaba al receptor inmediato.

El motivo inicial era práctico. SIP ya usaba NAPTR y SRV para localizar servicios sobre UDP, TCP o SCTP. Si el DNS tuviera que enumerar además cada combinación de TLS y SigComp, el número de registros crecería con cada capa. RFC 3486 trasladó la elección al nivel de la aplicación. Un mismo puerto podía aceptar SIP ordinario y mensajes SigComp, distinguidos por los bits iniciales de la cookie.

La sintaxis era mínima: comp=sigcomp. En una URI SIP o SIPS indicaba que la solicitud debía comprimirse hacia ese próximo salto. En la entrada Via superior indicaba que la respuesta debía volver comprimida. La coincidencia textual no borraba la diferencia de dirección ni de autoridad.

El parámetro reunía dos afirmaciones: la entidad soportaba SigComp y estaba dispuesta a recibir mensajes comprimidos en ese momento. La segunda era decisiva. Tener una función implementada no equivalía a activarla para todo tráfico. El receptor conservaba la capacidad de influir en el uso de compresión mediante el material de encaminamiento que publicaba.

Por eso la norma prohibía comprimir una solicitud cuando el cliente desconocía el soporte del servidor. Sin embargo, el cliente podía enviar la solicitud sin compresión y colocar el parámetro en su propio Via superior. Así expresaba que aceptaría una respuesta comprimida si el servidor podía producirla. La ida y la vuelta mantenían pruebas independientes.

Antes de establecer el diálogo surgía una dificultad: todavía no existía un juego de rutas del cual aprender. La configuración manual podía resolverla. También una solicitud OPTIONS sin comprimir dirigida al proxy de salida. El proxy podía responder con una URI alternativa en Contact que incluyera el parámetro. Aquello autorizaba una ruta para intentos posteriores; no probaba que el siguiente mensaje adoptara esa ruta ni esa codificación.

Cuando comenzó el diálogo, Contact y Record-Route propagaron preferencias. Un agente insertaba el parámetro en Contact para recibir solicitudes futuras comprimidas. Un proxy que permanecía en el trayecto podía usar Record-Route. Al procesar la respuesta, ese proxy inspeccionaba el próximo salto ascendente y añadía o quitaba el parámetro de su propia entrada. La ruta futura era una construcción, no un reflejo automático del primer INVITE.

El flujo ilustrado por RFC 3486 deja una huella desigual. Participan cuatro elementos y varios admiten SigComp, pero solo los mensajes 1, 6 y 7 están comprimidos. El primer proxy recibe un INVITE comprimido y envía otro ordinario. Una respuesta cruza un tramo sin compresión y el siguiente comprimida. El ACK vuelve a cambiar. Decir «el diálogo estaba comprimido» eliminaría precisamente la información que el estándar organizaba.

Ni siquiera el doble Record-Routing unificaba el camino. Un proxy situado entre dos redes podía insertar una entrada por interfaz y evitar reescrituras, pero seguir recibiendo mensajes comprimidos por un lado y ordinarios por el otro. También podía abstenerse de comprimir si el próximo salto era él mismo y el mensaje no salía a la red.

El caso de error muestra por qué un silencio no es una conclusión. Un servidor sin SigComp podía no entender suficiente contenido como para hallar Via y devolver un error SIP. Tras vencer la transacción, el cliente debía repetir la misma solicitud sin compresión. Ese tiempo de espera autorizaba una acción de recuperación, pero no identificaba por sí solo la causa.

Con TCP había que cerrar la conexión anterior y abrir otra. Si se reutilizaba el flujo que comenzaba con datos comprimidos, el servidor podía no encontrar el inicio de la nueva solicitud ordinaria. La identidad de la conexión se convertía así en parte de la evidencia de recuperación.

La marca tampoco traía autenticidad incorporada. Un atacante que insertara comp=sigcomp podía hacer que una entidad enviara datos comprimidos a otra que no los entendía; la integridad del mensaje era necesaria. Además, descomprimir exigía algo más de procesamiento y aumentaba levemente la presión de denegación de servicio.

El registro de IANA dio un nombre estable a comp y a sigcomp, no una garantía operativa. RFC 3320 definió SigComp; RFC 3485 fijó el diccionario SIP/SDP; RFC 5049 actualizó la aplicación a SIP con mínimos de recursos y compartimentos. RFC 4077, RFC 4896, RFC 5112 y RFC 5626 ampliaron otros aspectos. El hecho de que una pieza encajara en ese linaje no demuestra que una red concreta la desplegara.

Para reconstruir un episodio hay que conservar la URI del próximo salto, Via, Contact, Route y Record-Route, dirección, integridad, bytes en el cable, transporte y conexión. OPTIONS y uso posterior deben ser eventos distintos. También el tiempo de espera, el reintento sin compresión y la conexión TCP nueva. Después pueden unirse la descompresión, el análisis SIP, la autenticación y el resultado de la llamada.

RFC 3486 resolvió la explosión de combinaciones sin inventar una verdad global. Su marca era deliberadamente local. Viajaba con la ruta, cambiaba con el sentido y podía desaparecer en el siguiente proxy. Esa modestia fue la condición de su precisión.

Fuentes