Resumen
- Cada nivel de protección desigual de RFC 5109 declara su propio conjunto de paquetes y su propia longitud; resolver un nivel no resuelve los demás.
- Añadir FEC ante pérdidas puede empeorar una congestión, de modo que recuperación, tasa total y reproducción puntual deben medirse por separado.
La reacción que agravó la causa
Un contador de pérdidas no explica por qué faltan paquetes. Si el origen es congestión, aumentar sin más los paquetes FEC añade carga a la misma ruta que ya descarta tráfico. Puede mejorar la probabilidad matemática de alguna ecuación y, a la vez, empeorar el tiempo de llegada y el número total de pérdidas.
RFC 5109 hace explícita esa tensión. Más redundancia suele dar más protección, pero consume más ancho de banda. La especificación exige que las implementaciones no aumenten sustancialmente el caudal conjunto de medios y FEC cuando crecen las pérdidas. Para servicio best effort, además, hay que vigilar la pérdida y adaptar la tasa o abandonar la sesión cuando sea inaceptable.
Por eso un aumento del porcentaje «recuperado» no basta. La misma ventana debe mostrar tasa del medio, tasa FEC, retardo de cola, pérdida, nivel reconstruido, bytes recuperados y puntualidad de reproducción.
Una protección con niveles, no una cobertura uniforme
Uneven Level Protection divide el contenido protegido en secciones de importancia decreciente. El comienzo de un paquete puede recibir una protección más fuerte, normalmente mediante grupos menores, y el final una protección más débil. Una sola unidad FEC puede contener varias capas, pero cada una se calcula de forma independiente.
El encabezado de cada nivel incluye una longitud de protección de 16 bits y una máscara de 16 o 48 bits. Con una base de secuencia N, el bit i de la máscara incluye el paquete N+i en la ecuación de ese nivel. La máscara define participantes; la longitud define el tramo de bytes. Falta todavía saber qué participantes llegaron al receptor.
Un paquete protegido en el nivel p debe estar protegido también en p-1, y un paquete FEC que transporta p debe transportar el nivel anterior. Sin embargo, los conjuntos de paquetes pueden cambiar entre niveles, y los niveles de un mismo paquete multimedia pueden estar en unidades FEC distintas. La palabra «cubierto» carece de precisión si no va acompañada del nivel y del intervalo.
Resolver un prefijo
Imaginemos que falta un paquete. La ecuación del nivel 0 incluye ese desconocido y todos los demás operandos están presentes. El XOR reconstruye campos del encabezado RTP, la longitud total esperada y los primeros bytes protegidos. En el nivel 1, el grupo es mayor y falta otro paquete además del objetivo. Esa ecuación mantiene dos incógnitas y no se puede resolver.
El resultado es un paquete parcial. RFC 5109 ordena detectar esa situación comparando la longitud total recuperada desde el nivel 0 con la cantidad efectiva de carga reconstruida. El protocolo no concede que un encabezado válido convierta la ausencia del final en recuperación completa.
La recuperación también separa selección y reconstrucción. Primero, una estrategia propia de la implementación busca qué paquetes media/FEC combinar. Después, el procedimiento normativo reconstruye los bits. Una combinación útil puede existir pero no ser encontrada dentro del presupuesto de CPU o del plazo. También puede encontrarse para el nivel 0 y no para el superior.
En cada nivel, el receptor toma la longitud Ln, ubica los fragmentos a partir del desplazamiento acumulado, rellena con cero los operandos cortos, calcula el XOR y coloca los bytes en su posición. Al final, la comparación de longitud decide si el resultado cubre todo el paquete. Guardar solo el número de secuencia borra casi toda esta evidencia.
Un medio visible no demuestra FEC
Cuando la protección viaja en una sesión separada, los paquetes multimedia quedan intactos. Un receptor sin soporte FEC puede ignorar la redundancia y reproducir el medio. En oferta/respuesta, el destinatario puede rechazar la sesión FEC y aceptar la sesión principal. La continuidad visible es compatible con ausencia total de reparación.
La protección puede usar otra sesión RTP o aparecer como codificación redundante conforme a RFC 2198. En el primer modo, dirección, puerto, tipo dinámico y relación con el medio se anuncian fuera de banda. Medio y FEC pueden recorrer rutas distintas y perderse de forma distinta. Registrar únicamente la llegada del medio no revela si la defensa estaba negociada, disponible o usada.
La auditoría necesita oferta, respuesta, generación de asociación, recepción de ambos flujos y ecuación seleccionada. Una reproducción correcta puede deberse a que no hubo pérdida, a recuperación, a ocultación del decodificador o a que el segmento perdido era prescindible.
Los bytes reconstruidos pueden ser peligrosos
La paridad no autentica. Alterar un campo FEC puede producir una longitud absurda, cambiar los bytes reconstruidos o multiplicar el coste de búsqueda. RFC 5109 aconseja validar medios y FEC antes de reconstruir, y validar el resultado antes de usarlo.
Ese control incluye integridad, generación de claves, asociación entre sesiones, límites de longitud y política de consumo de CPU. Una ecuación puede ser algebraicamente resoluble y operacionalmente inaceptable. El resultado tampoco adquiere significado de aplicación hasta que el decodificador lo acepta.
ULP suele dejar una porción continua ausente al final, lo que algunos formatos pueden tolerar mejor que agujeros dispersos. La palabra decisiva es «algunos». Ni la especificación ni un evento XOR prueban que el códec concreto pueda usar el prefijo o que lo reciba antes de su fecha de reproducción.
Lo que RFC 5109 prueba
RFC 5109, Standards Track de diciembre de 2007, sustituyó RFC 2733 y RFC 3009, corrigió incoherencias del encabezado RTP y añadió protección desigual. El formato FEC no es compatible hacia atrás, aunque el medio no modificado pueda seguir siendo consumido. Eso prueba una propiedad del contrato, no adopción o eficacia de una instalación.
La máscara alcanza 48 posiciones y la operación es paridad XOR. La norma define transporte, señalización y recuperación, pero no aporta proveedor, operador, códec desplegado, porcentaje medido ni experiencia del usuario. Su contribución más útil es más estrecha: permite declarar con exactitud qué nivel intentó proteger qué bytes y cómo comprobar si la recuperación alcanzó la longitud completa.
Fuentes
- https://www.rfc-editor.org/rfc/rfc5109.html
- https://www.rfc-editor.org/rfc/rfc5109.txt
- https://www.rfc-editor.org/info/rfc5109
- https://www.rfc-editor.org/errata/rfc5109
- https://datatracker.ietf.org/doc/rfc5109/
- https://datatracker.ietf.org/doc/rfc5109/history/
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc2354.html
- https://www.rfc-editor.org/rfc/rfc2733.html
- https://www.rfc-editor.org/rfc/rfc3009.html
- https://www.rfc-editor.org/rfc/rfc2198.html
- https://www.rfc-editor.org/rfc/rfc4585.html
- https://www.rfc-editor.org/rfc/rfc6363.html
- https://www.rfc-editor.org/rfc/rfc6364.html
- https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
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
