Resumen

  • RFC 3320 asignó cada mensaje a una máquina virtual de descompresión con límites propios, también cuando el emisor aportaba el programa que se ejecutaría.
  • Que el mensaje se descomprimiera no autorizaba por sí solo memoria duradera: la aplicación debía autenticar el resultado y dar un identificador válido de compartimento antes de permitir estado nuevo o enviar retroalimentación.

La compresión también trasladaba un programa

RFC 3320, publicada en enero de 2003, definió SigComp —Signaling Compression— para protocolos de aplicación como SIP y RTSP. No partía de que todos los extremos tuvieran instalado de antemano el mismo compresor. El emisor podía elegir el algoritmo e incluir el bytecode que ejecutaría la Universal Decompressor Virtual Machine (UDVM) del receptor. La flexibilidad tenía un precio: el extremo que recibía debía ejecutar lógica influida por un tercero sin convertirla en control irrestricto del equipo.

Por eso la pregunta histórica no se reduce al porcentaje de bytes ahorrados. También importa qué cálculo puede provocar un mensaje y qué puede conseguir que el receptor recuerde. Los documentos no miden la adopción de SigComp ni sus ahorros reales en redes desplegadas. Establecen una frontera de protocolo: el emisor propone una computación restringida, pero el receptor conserva autoridad sobre los recursos y sobre la memoria que perdurará una vez procesado el mensaje actual.

Cada mensaje empezaba una ejecución nueva

Cada mensaje SigComp recibido inicia una instancia propia de UDVM. La memoria de descompresión tiene un límite y cada extremo debe ofrecer como mínimo 2.048 bytes para esa función. También hay un presupuesto de instrucciones dependiente del tamaño del mensaje y de cycles_per_bit: para n bytes, el máximo es (8*n + 1000) * cycles_per_bit, y el parámetro no puede ser menor que 16. Son límites por mensaje. Acotan una ejecución individual; no garantizan inmunidad ante cualquier denegación de servicio ni modelan por completo los recursos del servidor.

La instancia nueva crea una frontera de recuperación. Si un mensaje está dañado o agota su presupuesto, el siguiente mensaje válido no queda necesariamente atado a la misma máquina virtual. No es preciso imaginar un único decodificador de flujo cuyo estado crece para siempre. La especificación define un reinicio claro, aunque también permite que ciertos estados seleccionados se compartan entre mensajes.

Descomprimir y recordar requerían permisos distintos

SigComp separa la memoria temporal usada para descomprimir de la memoria de estado reservada para un compartimento. La aplicación define esos compartimentos según el contexto de comunicación y puede cerrarlos cuando termina ese contexto. Si un extremo no quiere retener estado, puede anunciar una capacidad de estado igual a cero. Guardar memoria para mensajes futuros no es requisito para poder descodificar el actual.

La regla más reveladora llega al terminar la descompresión. La aplicación recibe el mensaje reconstruido y puede autenticarlo de acuerdo con su protocolo y contexto. Solo si está dispuesta a asociarlo con un identificador válido de compartimento, la capa SigComp recibe autorización para crear estado nuevo y reenviar retroalimentación al compresor. Si la aplicación no tiene suficiente confianza, no ofrece un compartimento válido. La UDVM termina sin guardar el estado solicitado ni transmitir esa retroalimentación.

Así, la máquina virtual no decide sobre el significado. Puede probar que produjo bytes dentro de los límites definidos, pero no determinar que la señalización es auténtica, pertenece al diálogo esperado o debe influir en los mensajes que vendrán. La aplicación cuenta con el contexto adecuado y conserva la decisión final. RFC 4896 aclaró más tarde la relación entre autenticación y creación de estado; el resultado del decodificador no equivale a una decisión de confianza.

El acceso a estado previo tenía otra protección

Hay una dependencia de orden: quizá la aplicación necesite el mensaje descomprimido para autenticarlo, pero la descompresión puede aprovechar un estado existente. SigComp trata el acceso a ese estado antes de la autenticación posterior como un problema distinto. Los identificadores se derivan de un hash de los bytes del estado; el receptor comprueba el identificador antes de hacer que el UDVM lea el estado. Después del decodificado, la autorización de la aplicación sigue siendo necesaria para conservar estado nuevo.

No hay que confundir «este mensaje puede consultar un estado de compresión anterior» con «este mensaje ya autenticado puede modificar memoria duradera». Son decisiones en etapas diferentes y con evidencias distintas. La primera permite que el cálculo avance bajo control; la segunda espera la valoración semántica de la aplicación. Dejar claras ambas reglas evita presentar como contradicción lo que en realidad es una secuencia de controles.

Los documentos posteriores cubrieron las piezas cercanas

RFC 3321 añadió operaciones extendidas y mecanismos de confirmación; en transportes no fiables, el emisor necesita confirmar el estado antes de depender del receptor. RFC 4077 describió acuses negativos para informar de fallos de descompresión. RFC 5049 especificó requisitos para SIP, que no deben atribuirse en bloque a todas las aplicaciones SigComp. RFC 4464 ofreció una guía y RFC 4465 una colección de pruebas extremas. Explicación, señalización de errores y perfiles particulares completan la familia documental, pero no demuestran por sí solos adopción ni mejoras medidas.

La aportación duradera de RFC 3320 fue dividir la autoridad. El mensaje puede pedir un cálculo acotado; la aplicación decide si su contenido merece convertirse en memoria que afectará intercambios futuros. Esa separación hace visibles tanto el límite de recursos como el de confianza y evita que «se pudo descomprimir» se transforme silenciosamente en «ya lo guardamos».

Fuentes