Resumen

  • RFC 3952 no transmitía el número de tramas iLBC: el receptor dividía la carga RTP entre 38 o 50 octetos según el modo negociado mediante SDP.
  • Una errata presentada en 2026, aún con estado Reported, propone corregir 32/50 a 38/50; la longitud compatible no prueba por sí sola negociación, autenticidad, decodificación ni reproducción.

Una economía que necesitaba memoria

El formato tenía dos piezas regulares: 38 octetos para una trama de 20 milisegundos y 50 para una de 30. RFC 3952 permitió concatenar una o más y omitió el contador. Si el receptor conocía el modo, la división bastaba.

Pero el conocimiento decisivo no viajaba en esa carga. Setenta y seis octetos significaban dos tramas bajo mode 20; cien significaban dos bajo mode 30. Sin el estado de sesión, una captura conservaba la longitud pero no la regla con la que el equipo la interpretó.

El documento prohibía partir una trama entre paquetes o mezclar ambos modos dentro de uno. También limitaba la agregación práctica al MTU. Empaquetar poco reducía espera y aumentaba sobrecarga; empaquetar más ahorraba encabezados a costa de retraso y de perder más audio con un único datagrama. La aritmética era parte de una política operativa, no solo del diseño binario.

El divisor se acordaba fuera del flujo

SDP anunciaba iLBC/8000 y llevaba mode en a=fmtp. La ausencia del parámetro seleccionaba 30 ms. El valor era bidireccional: los dos extremos debían usar el mismo resultado.

La oferta expresaba una preferencia y la respuesta podía proponer la alternativa. La regla elegía el modo de menor ancho de banda. Aunque 30 parezca mayor, 50 octetos cada 30 ms consumen menos carga por segundo que 38 cada 20; por eso los dos ejemplos discrepantes de la RFC terminan en mode 30.

RFC 2327 definía SDP y RFC 3264 el intercambio de oferta y respuesta. RFC 3550 aportaba secuencia y tiempo a RTP. Ninguna de esas piezas sustituía a las demás: una negociación aceptada no demuestra cumplimiento, y un paquete ordenado no declara su divisor.

El documento se contradijo en el punto más sensible

Las secciones 2 y 3.1 dicen 38 octetos para 20 ms. RFC 3951, que especifica el códec, coincide. Sin embargo, la sección 3.2 imprime 32/50 al describir el cálculo del número de tramas.

La página de erratas registra como ID 8866 una propuesta del 3 de abril de 2026 para cambiarlo a 38/50. Su estado sigue siendo Reported. La lectura de 38 tiene fuerte apoyo interno, pero no debe presentarse como una errata ya verificada.

Tampoco corresponde inventar un incidente. Las fuentes no prueban una caída, una vulnerabilidad explotada ni una tasa de llamadas fallidas. Sí prueban que una herramienta que copie una frase aislada puede adquirir 32, mientras una implementación que lea el contrato completo encuentra 38. Los bytes de red serían correctos y la base documental del intérprete, no.

Un cociente exacto no era audio escuchado

Con mode 20, 114 dividido por 38 da tres sin resto. Esa comprobación detecta coherencia de longitud. No valida el contenido de cada trama, la identidad del emisor, la protección SRTP, la admisión por el búfer, la salida del decodificador ni el resultado acústico.

RFC 3711 separa la seguridad de SRTP del encuadre del códec. Un paquete autenticado puede ser inutilizable con el modo equivocado; uno divisible sin protección no autentica a nadie. Un resto sugiere estado obsoleto, tipo dinámico equivocado, daño o captura incompleta, pero todavía exige investigación.

El registro del RFC Editor fecha el documento en diciembre de 2004 y lo clasifica Experimental. Su enseñanza perdurable es sobria: eliminar metadatos redundantes desplaza la dependencia hacia otro sistema. Si ese sistema no deja recibo, la eficiencia del formato se convierte en ambigüedad histórica.

Fuentes