Resumen

  • RFC 3558 permite entrelazar tramas de voz de 20 milisegundos: una pérdida de red se reparte entre posiciones no consecutivas, pero el receptor necesita reconstruir el orden y respetar un plazo distinto para cada posición.
  • Marcar como perdido o recibido el paquete completo borra la decisión real. La evidencia útil identifica qué tramas se sustituyeron por borrados, cuáles llegaron a tiempo y cuáles se aprovecharon después de que la primera ya era inutilizable.

Los sistemas de voz suelen juzgar la red con una unidad demasiado grande. El datagrama es cómodo para el transporte, pero no siempre coincide con la unidad que todavía puede ayudar al decodificador.

RFC 3558, publicado en julio de 2003 como Proposed Standard, define cargas RTP para EVRC y SMV. Ambos códecs avanzan en tramas de 20 milisegundos. El formato Interleaved/Bundled puede repartir tramas vecinas entre varios paquetes, de modo que la desaparición de uno produzca huecos separados en la secuencia reconstruida.

La mejora no consiste en recuperar bits. Consiste en evitar que todos los huecos sean contiguos. Esa transformación crea una ventana durante la cual una llegada tardía puede ser inútil para el principio del paquete y valiosa para su final.

NNN ordena paquetes, no plazos de reproducción

El primer octeto contiene LLL, longitud de entrelazado, y NNN, índice dentro del grupo, ambos de tres bits. El segundo añade una solicitud de modo y un contador de cinco bits que representa el número de tramas menos uno. El rango resultante es de una a 32 tramas por paquete.

LLL igual a cero significa agrupación sin entrelazado. Si LLL es positivo, NNN no puede superarlo. Con B tramas por paquete y longitud L, el grupo abarca B por L más uno tramas y L más uno paquetes RTP. El paquete N contiene posiciones N, N más L más uno y las que sigan con ese salto.

Los paquetes se envían con NNN creciente para reducir la demora. Sin embargo, la primera trama de un paquete y la última no comparten la misma fecha límite. El reproductor las necesita en momentos distintos. Un registro que asigna un solo estado temporal al datagrama pierde esa diferencia.

El recibo mínimo debe unir secuencia RTP, grupo, NNN, posición temporal, instante de llegada, fecha límite y destino final. Solo así se puede explicar por qué un datagrama capturado acabó parcialmente descartado.

El caso límite revela la política

Supongamos que el paquete NNN=1 aparece después de que el decodificador tuvo que avanzar por su primera posición. El receptor inserta una trama de borrado para mantener el tiempo. Pero las demás posiciones del mismo paquete pertenecen a instantes posteriores. Si aún no vencieron, pueden entrar en el búfer y reducir daños futuros.

Descartar todo el paquete simplifica la implementación, pero amplía la pérdida efectiva. Esperar su llegada antes de reproducir la primera posición aumenta la latencia. Recuperar solo las posiciones todavía oportunas exige contabilidad por trama. Ninguna de estas políticas se desprende automáticamente de la conformidad con el formato.

Por eso «paquete recibido» no equivale a «contenido aprovechado». Tampoco «decodificador activo» equivale a «voz recuperada». Una trama de borrado de cero bits hace avanzar el estado durante 20 milisegundos; no reconstruye lo que dijo la persona.

Una trama nula representa otra condición y normalmente no se transmite. Mezclar nulos y borrados en una categoría genérica de silencio convierte un fallo verificable en una ausencia aparentemente normal.

La dispersión cambia el daño, no la verdad

Los decodificadores suelen soportar mejor borrados aislados que una racha continua. Al separar posiciones adyacentes entre paquetes distintos, el entrelazado puede conservar contexto entre huecos. La pérdida de un paquete deja de ser una herida única y pasa a ser una serie de cortes.

La palabra importante es «puede». El resultado depende del patrón de pérdidas, del tamaño del grupo, del algoritmo de ocultación y del contenido de la voz. Este Artículo no atribuye una mejora medida a ninguna llamada. RFC 3558 describe el mecanismo, no una garantía de calidad.

La cartografía de borrados debe acompañar cualquier nota de inteligibilidad, transcripción o acción posterior. Sin ella, un número mal entendido y una conversación perfecta pueden aparecer bajo la misma tasa de paquetes.

maxinterleave limita al emisor, no certifica al receptor

El receptor puede anunciar el mayor LLL que acepta mediante maxinterleave; si falta, el valor predeterminado es cinco. En una sesión uno a uno, el emisor no debe superarlo. La cifra permite prever el máximo estado de reconstrucción.

No prueba que la memoria estuviera reservada, que el proceso no sufriera presión, que todos los grupos se cerraran antes del playout ni que un cambio de oferta se aplicara de forma sincronizada. El receptor puede reducir la cifra en plena sesión. Toda reducción necesita una hora efectiva y una frontera de grupo observada.

maxptime, con 200 milisegundos como valor predeterminado en este registro, limita la duración de medios dentro de un paquete. maxptime y maxinterleave gobiernan dimensiones distintas. Para conocer el coste real hacen falta B, L, ritmo de envío, cola de jitter, profundidad de reordenamiento y agenda del decodificador.

Un tablero responsable muestra el techo negociado junto a bytes asignados, máximo de ocupación, esperas forzadas y tramas caducadas. Mostrar solo SDP convierte una promesa de capacidad en un hecho inventado.

Header-Free ofrece otra economía

El formato Header-Free lleva una sola trama sin tabla de contenidos ni cabecera de entrelazado. Genera más cabeceras de red por segundo que un grupo amplio, pero evita esperar a completar una agrupación y simplifica la entrega temporal.

RFC 3558 aconseja LLL igual a cero o Header-Free para usos interactivos, mientras que cuatro o cinco pueden ser razonables cuando la robustez pesa más que el retraso. No hay un modo superior en abstracto. La decisión depende de qué recurso es escaso: ancho de banda, tiempo conversacional, memoria o tolerancia a ráfagas.

RFC 2508 y RFC 3095 muestran alternativas de compresión de cabeceras. Que una alternativa esté implementada no demuestra que su contexto funcionara en el trayecto observado. Medirla es parte de la comparación.

Solicitar un modo no confirma el cambio

Mode Request pide al codificador del sentido inverso que use un modo. En una conversación uno a uno se recomienda atenderlo; en una sesión multiparte se recomienda ignorarlo. La repetición protege la solicitud contra una pérdida aislada.

Una solicitud repetida sigue sin ser un acuse. Hay que conservar cada envío, la recepción si existe, la decisión del codificador y la primera trama que demuestra el modo efectivo. Dar por cerrado el cambio al emitir el campo es confundir control deseado con estado ejecutado.

El mismo corte probatorio separa anuncio de maxinterleave, adopción por el emisor y paquetes realmente observados.

Un paquete inválido necesita otro propietario

La tabla de contenidos señala tipos y tamaños. Valores incoherentes de LLL, NNN, número de tramas o bytes pueden obligar a descartar una carga y producir borrados. Para el decodificador, el hueco puede parecer idéntico al causado por la red. Para corregirlo, no lo es.

Las métricas deben distinguir no recibido, recibido tarde, recibido inválido, tipo no compatible y expulsado por falta de búfer. Agruparlos bajo «pérdida» oculta si debe actuar el transporte, el empaquetador, el receptor o la planificación local.

RFC 4788 actualizó después esta familia con EVRC-B, formato compacto agrupado, transmisión discontinua y cambios de registro y oferta-respuesta. Es contexto posterior y no una característica que pueda suponerse en todo flujo RFC 3558.

Límite de la evidencia

Este Artículo no identifica operador, equipo, sesión, usuario, incidente, tasa medida, memoria disponible ni resultado auditivo. Los ejemplos son consecuencias del formato normalizado, no observaciones de producción.

RFC 3550 y RFC 3551 sitúan RTP; RFC 3264 define oferta-respuesta; RFC 2327 era el contexto SDP original y RFC 8866 es contexto posterior. RFC 2508 y RFC 3095 aportan compresión. RFC 8174 aclara lenguaje normativo. RFC 4788 es una actualización declarada.

Running-Code Primacy y Minimum Initial Specification, de Heng Lu, se usan como lentes editoriales transparentes. Orientan a separar la capacidad declarada del comportamiento comprobado y a dejar las decisiones locales fuera de la especificación común mínima. No prueban intención histórica ni resultado de red.

La conclusión acotada es precisa: el entrelazado puede repartir el daño de una pérdida, y una llegada tardía puede conservar tramas futuras aunque una anterior haya caducado. Solo un recibo por posición demuestra qué parte del paquete sirvió.

Sources