Resumen

  • RFC 3557 agrupa dos vectores de 10 ms en un Frame Pair de 20 ms, protegido por un CRC de cuatro bits y empaquetable junto a otros FP en RTP.
  • Más agregación reduce cabeceras, pero espera más antes de enviar y expone más tiempo consecutivo a una pérdida. maxptime, Null FP y CRC no son recibos de reconocimiento.

RFC 3557 fue publicado en julio de 2003 como Proposed Standard para transportar rasgos de reconocimiento distribuido. No mide un servicio real; muestra dónde cambian las unidades de fallo.

Del vector al datagrama

Cada 10 ms, el frontal produce 44 bits. Dos tramas forman un FP de 20 ms. Cuatro bits de CRC y cuatro de relleno completan 96 bits. Varios FP se concatenan en una carga RTP.

El receptor puede comprobar los FP presentes. No puede aplicar el CRC a uno ausente. El timestamp marca el instante inicial y avanza según la frecuencia de muestreo; junto con la secuencia permite cuantificar el hueco.

Por eso el registro debe mapear FP a paquete. “Un paquete perdido” no informa si faltaron 20, 40 u 80 ms. “CRC correcto” no informa sobre lo que nunca llegó.

La eficiencia cambia el dominio de fallo

Un FP por paquete repite cabeceras y limita la pérdida semántica. Varios FP amortizan cabeceras, aumentan el tiempo de espera y convierten una pérdida en una racha más larga. El RFC advierte que los reconocedores suelen tolerar mal muchas FP consecutivas ausentes.

La recomendación es minimizar la agregación dentro de la exigencia de eficiencia y considerar compresión. No existe una cifra universal: pérdida, congestión, potencia, latencia y tolerancia del motor cambian la decisión.

La gobernanza debe unir dos paneles. El de red cuenta bytes ahorrados; el de producto ve confianza, repetición y abandono. Sin versión común, una mejora puede aparecer como dos hechos sin relación.

El valor declarado debe contrastarse con los paquetes

maxptime expresa la duración máxima en un paquete y debería ser múltiplo de 20 ms. Si falta, RFC 3557 supone 80 ms. Ante pérdida alta se puede elegir menos.

La declaración no demuestra cumplimiento. Mida la duración representada por secuencia y timestamp, y registre cualquier paquete que exceda la política. Relacione el valor con compresión efectiva y presupuesto de latencia.

RFC 2508 y RFC 3095 ofrecen vías para reducir cabeceras sin ampliar necesariamente el intervalo agregado. Pero una capacidad configurada no prueba que el contexto funcione. RFC 2198, por otra parte, describe redundancia vecina; este payload no duplica automáticamente los FP.

Null FP no rellena el segmento

Con DTX, el frontal envía cuando detecta habla. Tras suficiente no-habla —1,5 segundos aparece como valor típico, no obligatorio— considera terminado el segmento y debería emitir uno o más Null FP.

El Null FP lleva contenido nulo, CRC y relleno. Declara el cierre en el emisor. Puede llegar después de que el paquete anterior se pierda. Si el motor interpreta cierre como completitud, la señal limpia oculta el hueco.

Guarde decisión de voz, umbral, último FP real, intentos Null, secuencias recibidas y cierre del motor. El fin temporal no puede borrar incertidumbre anterior.

El motor y la aplicación siguen tomando decisiones

Después de RTP vienen ordenación, validación, ocultación o rechazo, ingestión, hipótesis, confianza y acción. Cada etapa tiene otro actor y otro posible fallo.

Un paquete recibido no prueba ingestión. Un segmento cerrado no prueba hipótesis. Una hipótesis no prueba corrección ni autorización de una acción. La cadena debe terminar en resultado observado, no en el último campo fácil de consultar.

La compresión cambia la alternativa disponible

RFC 3557 remite a técnicas de compresión de cabeceras IP, UDP y RTP descritas en RFC 2508 y RFC 3095. Ese detalle evita una falsa dicotomía. La organización no siempre tiene que elegir entre desperdiciar cabeceras y concentrar más tiempo de habla en un datagrama.

Si el contexto de compresión está activo y estable, puede conservarse un intervalo corto por paquete con menor coste de cabecera. Si el contexto no existe, está obsoleto o exige reparaciones frecuentes, la opción puede no rendir como promete. La decisión debe registrar capacidad observada, no una casilla teórica de compatibilidad.

RFC 2198 aporta un contexto vecino sobre redundancia de audio, pero esa redundancia no aparece por el mero hecho de agregar pares primarios. Cuatro FP en un paquete siguen compartiendo un único destino. Perder el datagrama puede retirar los cuatro.

El hueco necesita su propia cronología

Un registro defendible une, sin fusionarlos, el intervalo capturado, los FP producidos, el paquete que debía transportarlos, el salto de secuencia, el salto de timestamp, el veredicto CRC de lo recibido, la decisión de concealment o rechazo del motor y la hipótesis final. Cada capa informa solo de su tramo.

Esa separación permite evaluar cambios de política. Antes de aumentar la agregación se fijan la distribución de pérdidas, la latencia, la salud de la compresión y la tolerancia del motor. Después se comparan los mismos indicadores bajo una versión identificable de la política. Sin esa versión, una subida de reintentos no puede atribuirse y un ahorro de red no puede valorarse contra el resultado del servicio.

El cuadro de mando debe mostrar en paralelo bytes de cabecera evitados y milisegundos consecutivos expuestos. Contar solo paquetes hace parecer equivalentes una pérdida de 20 ms y otra de 80 ms. Contar solo errores de reconocimiento tampoco explica si la red entregó una secuencia incompleta o si el modelo tomó una mala decisión sobre datos completos.

La comparación debe conservar también el momento efectivo de cada cambio. Un promedio mensual que mezcla dos políticas de agregación puede ocultar justo la transición que se intenta evaluar. Ventanas alineadas con la versión y el camino observado permiten comprobar el efecto sin atribuir a la RFC un resultado que pertenece a una implementación concreta.

Límite de evidencia

No se nombra usuario, voz, idioma, terminal, motor, modelo, operador, servicio o incidente. No se afirma pérdida, calidad, adopción ni valor óptimo. Los 80 ms son el valor por defecto especificado.

Las especificaciones RTP, SDP, compresión y redundancia son contexto, no evidencia de despliegue. Los textos de Heng Lu se declaran como lentes para separar estándar, código y resultado, no como intención de los autores.

La conclusión: maxptime delimita una exposición; solo la observación de paquetes, ingestión, reconocimiento y acción puede decir qué ocurrió.

Sources