Resumen

  • La RFC 3322 sumó 4.131 ms para una secuencia SIP/SDP usando 9,6 kbit/s y 140 ms de RTT, pero dejó fuera retransmisiones y reconoció que la aproximación era burda.
  • El cálculo justificó requisitos futuros para SigComp; no fue una medición de usuario, una promesa de servicio ni prueba de mejora en un despliegue real.

El reloj que faltaba

La ecuación parecía completa: tamaño del mensaje en bits dividido por velocidad del enlace, más la mitad del tiempo de ida y vuelta. Con un enlace de 9.600 bit/s y RTT de 140 ms, cada INVITE, respuesta provisional, PRACK y ACK recibía un coste. La suma de la secuencia mostrada llegaba a 4.131 ms. Otros trabajos de reserva y gestión de sesión añadían valores aproximados antes y durante el intercambio.

Pero la propia RFC 3322 avisaba de lo que no medía. Un canal de radio introduce errores; FEC, entrelazado y ARQ cambian pérdida por demora. La aproximación no incorporaba posibles retransmisiones. Suponía un solo salto celular y simplificaba la red IP intermedia. Los tamaños eran representativos. Por eso la precisión aritmética no convertía el resultado en una observación del mundo.

El tercer reloj —el de la recuperación frente a errores— podía permanecer quieto en la fórmula y correr en una red real. El documento lo sabía. Esa declaración permite usar el número como comparación bajo condiciones fijas, pero prohíbe presentarlo como latencia universal de SIP, de UMTS o de SigComp.

Un documento de necesidades, no un certificado

RFC 3322 apareció en enero de 2003 como Informational. Su tarea era describir motivación, supuestos y requisitos para un esquema de compresión de señalización. SIP, SDP y RTSP compartían mensajes de texto relativamente grandes y fases con varias esperas. En radio de capacidad limitada, la serialización podía agravar el tiempo de establecimiento y consumir recursos que servían a otros usuarios.

El texto examinó aumentar el bit rate, reducir RTT, cambiar la secuencia de protocolos, quitar campos y comprimir. Más tasa por usuario tenía coste de capacidad. Reducir RTT exigía cambios de sistema. Alterar la secuencia modificaba protocolos. Quitar campos perdía transparencia y lesionaba el principio extremo a extremo. La compresión conservaba el mensaje y por eso resultaba atractiva.

Ese razonamiento seleccionó una dirección de ingeniería. No demostró que la dirección estuviera desplegada. Un requisito escrito en futuro no prueba que una implementación lo cumpla, del mismo modo que una línea de código disponible no prueba que dos extremos la negociaron en una llamada.

La transparencia era una limitación deliberada

El mensaje recuperado debía ser idéntico bit a bit al original. SigComp podía reducir la representación, no convertirse en autoridad sobre el significado de SIP o SDP. Debía coexistir con ROHC, permitir compatibilidad con extremos sin compresión, aceptar flujos arbitrarios y funcionar sobre UDP y TCP.

También debía operar en rutas unidireccionales, aunque con menor rendimiento por falta de retorno. La decisión de usar compresión quedaba fuera del esquema: correspondía al protocolo productor. Así se conservaba una frontera de control. Un compresor no podía declararse obligatorio por sí mismo.

Los requisitos de rendimiento reforzaban esa disciplina. La solución debía adaptarse a distinta memoria y CPU. No podía ganar ratio poniendo mensajes en cola y añadiendo el mismo retraso que pretendía reducir. Los errores residuales debían tener poca probabilidad de producir salidas incorrectas. La pérdida o desorden moderado no debía impedir recuperar mensajes posteriores.

La arquitectura de RFC 3320, el diccionario de RFC 3485, el uso con SIP de RFC 3486 y las guías posteriores de RFC 4077 y RFC 5049 muestran cómo continuó la especificación. No dicen cuántos dispositivos la activaron ni cuánto tiempo ahorraron. Para eso harían falta trazas de negociación, versiones, condiciones de radio y comparaciones observadas.

La historia importante no es que 4.131 ms fuese un número equivocado. Era un número correctamente limitado. El error llega cuando desaparecen sus supuestos y queda la cifra sola, disponible para justificar decisiones que el modelo nunca evaluó.

Sources