Resumen

  • RFC 5577 sustituyó la especificación anterior de carga RTP para admitir el audio de 14 kHz de G.722.1 Anexo C, un reloj de muestreo de 32 kHz y una modalidad de 48 kbit/s.
  • No impuso una ruptura total: recomendó ofrecer también el perfil anterior de 16 kHz para mantener la interoperabilidad, y exigió declarar en SDP cada combinación de frecuencia de reloj y tasa de bits que se pretendiera usar.

Una RFC sustituida no hizo desaparecer a quienes usaban la anterior

Cuando se publicó en julio de 2009, RFC 5577 llevaba la indicación «Obsoletes: 3047». Puede sonar a un cambio instantáneo: sale una especificación y entra otra. Sin embargo, su apartado de interoperabilidad cuenta una transición más práctica. RFC 3047 describía G.722.1 con un reloj de muestreo de 16 kHz. La revisión añadió soporte para el audio de banda superancha del Anexo C de la recomendación revisada de UIT-T: la banda de audio llegó a 14 kHz, apareció una configuración con reloj de 32 kHz y se incorporó la tasa de 48 kbit/s.

Esas cifras no miden lo mismo. Los 14 kHz describen el ancho de banda del audio codificado; 16 o 32 kHz es el reloj de muestreo que emplea RTP para sus marcas de tiempo; 24, 32 o 48 kbit/s es la tasa del códec. RFC 5577 no las convirtió en un único ajuste de «calidad». La señalización de sesión permite describir una combinación utilizable.

El flujo del códec no incluía una notificación en banda cuando cambiaba la tasa de bits. Por eso RFC 5577 exigía un método de señalización externo y mantenía constante la tasa para cada valor de tipo de carga RTP. Una aplicación podía cambiar de perfil entre paquetes, pero tenía que asignar valores distintos de tipo de carga. En SDP, a=rtpmap identifica la codificación y la frecuencia de reloj; a=fmtp aporta la tasa de bits. Juntos describen la configuración que se solicita al receptor.

El modelo de Oferta/Respuesta daba consecuencias a esa declaración. RFC 5577 indica que la oferta debe enumerar todas las configuraciones que se pretendan utilizar. Luego identifica directamente la brecha de compatibilidad: RFC 3047 solo admitía el reloj de 16 kHz, así que un sistema que buscara interoperabilidad debía ofrecer también un tipo de carga a 16 kHz. El ejemplo presenta el perfil de 16 kHz/24 kbit/s y el de 32 kHz/48 kbit/s como tipos de carga distintos.

Esto no demuestra que todo terminal antiguo pudiera negociar con éxito ni que el perfil nuevo retrocediera automáticamente al anterior. Una oferta anuncia opciones compatibles; no prueba qué contestó el otro extremo ni que el sonido llegara a quien escuchaba. El terminal receptor debe elegir una configuración que admita y la sesión debe transportar el perfil acordado. RFC 5577 preservó una vía, pero no certificó quién la recorrió.

La estructura de los paquetes mantuvo otra frontera. Las tramas seguían durando 20 milisegundos. En las tasas estándar, cada una ocupaba 60, 80 o 120 octetos. Un paquete podía agregar tramas consecutivas, siempre que compartieran tasa y reloj; ninguna trama podía dividirse entre paquetes. El receptor deducía cuántas había contando los octetos y dividiendo por el tamaño esperado, sin un campo adicional en la carga útil. La RFC recomendó menos tramas por paquete cuando importaba el retardo y permitió más para streaming o mensajería menos sensibles a él. No fijó una cifra universal de latencia.

Vista como una regla de migración, RFC 5577 no cuenta que un «códec nuevo sustituyera al viejo», sino cómo mantener visibles las opciones. La línea «Obsoletes» sustituyó el texto normativo. La oferta de 16 kHz mantuvo disponible la frontera de compatibilidad anterior. Ninguna de las dos cosas revela cuántos terminales implementaron cada perfil.

Fuentes