Resumen
- RFC 3545 repetía valores de contexto modificados en N+1 paquetes para que el descompresor pudiera resincronizarse si la ráfaga de pérdidas se mantenía dentro del límite supuesto para el enlace.
- Su HDRCKSUM opcional ayudaba a comprobar cabeceras reconstruidas cuando la suma UDP de IPv4 era cero, pero no cubría la Identificación IPv4; después de más de N pérdidas, era más seguro invalidar el contexto y pedir su estado.
La comprobación tenía un punto ciego. RFC 3545 permitió al compresor sustituir una suma UDP IPv4 nula por una suma de cabecera de 16 bits. Así, el descompresor podía comprobar una cabecera reconstruida. Pero la Identificación IPv4 no estaba entre los campos validados por esa suma. En un enlace sin pérdidas relevantes, la omisión podía permanecer oculta dentro de un mecanismo de recuperación más amplio. Después de demasiadas pérdidas consecutivas, cambiaba el alcance de una «recuperación» fiable.
CRTP, definido en RFC 2508, comprime las cabeceras IP, UDP y RTP manteniendo contexto compartido en ambos extremos. Una cabecera completa establece ese estado; los paquetes siguientes pueden transportar cambios o diferenciales. Si se pierde un paquete que contenía una actualización, el compresor avanza y el descompresor no. La discrepancia quizá no se note hasta que llega otro paquete comprimido. En un enlace con mucho retardo, solicitar reparación cuesta un viaje de ida y vuelta; durante ese tiempo el descompresor puede descartar más paquetes.
RFC 3545 responde con repetición y un límite explícito. Define N según el comportamiento de pérdidas del enlace: la probabilidad de perder más de N paquetes consecutivos debería ser pequeña. Si una actualización aparece en N+1 paquetes seguidos, debería llegar al menos una copia mientras la ráfaga no supere N. El descompresor puede aplicar el algoritmo «twice» para reconstruir un hueco acotado y comprobar el resultado con la suma UDP o, cuando corresponda, HDRCKSUM. El protocolo tolera más pérdidas; no garantiza que cualquier ráfaga cumpla el modelo.
El número de secuencia del enlace solo tiene cuatro bits y vuelve a empezar cada 16 paquetes. Por tanto, la diferencia observada no siempre permite distinguir entre muchas pérdidas y un reordenamiento en el que primero llega un paquete posterior. Si una interpretación plausible implica menos de N+1 pérdidas, el descompresor puede intentar la reconstrucción correspondiente y verificarla. Si la interpretación razonable supera N, IPv4 impone una regla más clara: no seguir adivinando con «twice», invalidar el contexto y enviar CONTEXT_STATE para que el compresor restaure el estado compartido.
Ahí importa la cobertura de la suma. HDRCKSUM está disponible cuando la suma UDP IPv4 original es cero; se inserta para comprobar la reconstrucción y luego el descompresor lo retira. No se usa en IPv6, donde no se permite una suma UDP nula. Aun así, la suma de cabecera no valida la Identificación IPv4. Tras más de N pérdidas, superar la comprobación no cierra ese hueco: RFC 3545 indica que se descarte el contexto incierto. IPv6 carece del campo de identificación IPv4 y puede aplicar una regla de recuperación distinta.
La ráfaga de actualizaciones también tiene una salvaguarda propia. Si cambia un campo constante del contexto mientras se envían N+1 paquetes FULL_HEADER, el compresor empieza otra ráfaga y cambia el número de generación. De otro modo, el descompresor podría confundir dos ráfagas superpuestas con una tolerancia mayor a pérdidas y no detectar una desincronización. Las respuestas CONTEXT_STATE también deberían repetirse. Estos son mecanismos del protocolo, no pruebas de que un equipo concreto los activara o de que una aplicación RTP reprodujera el contenido.
La distinción histórica es pequeña, pero importa en operación: una suma solo prueba los campos que cubre, una reconstrucción acotada no equivale a entrega y la reparación de contexto no confirma la recepción de medios. Una comprobación local válida puede coexistir con una Identificación IPv4 no verificada. Cuando el patrón de pérdidas supera el límite previsto, invalidar el contexto no es renunciar a recuperarlo; es negarse a convertir una secuencia ambigua en una certeza falsa.
Fuentes
- RFC 3545 — Enhanced Compressed RTP
- RFC 3545 — ficha del RFC Editor y acceso a erratas
- RFC 3545 — historial de Datatracker
- RFC 2508 — compresión de cabeceras IP/UDP/RTP
- RFC 3544 — compresión de cabeceras IP sobre PPP
- RFC 3095 — Robust Header Compression
- RFC 3550 — RTP: protocolo de transporte para aplicaciones en tiempo real
- RFC 3711 — Secure Real-time Transport Protocol
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
