Resumen

  • Seleccionar un subtipo EVRC-WB establece cómo interpretar el payload RTP; no certifica el modo usado por el codificador en cada trama ni la frecuencia acústica del dispositivo.
  • mode-set-recv y recvmode son preferencias del receptor que el emisor remoto puede ignorar. sendmode anuncia el estado del emisor, pero puede llegar después de los medios que pretende describir.

El inventario de la sesión decía EVRCWB0/16000. El cuadro de mando tradujo esa pareja a “voz wideband entregada”. No había captura del codificador, no había asociación entre modo y trama y nadie había comprobado la configuración del transductor.

La conclusión sonaba razonable porque cada palabra provenía de un estándar. También era más amplia que la evidencia.

El nombre del formato no es el resultado del codificador

RFC 5188 define tres subtipos principales. audio/EVRCWB corresponde al formato interleaved/bundled; audio/EVRCWB0, al formato header-free; y audio/EVRCWB1, al compacto bundled. El rtpmap vincula un payload type dinámico con una de esas reglas de interpretación.

Ese acuerdo permite analizar los bytes. No decide por sí solo si el codificador opera en modo 0, 4 o 7. Los modos 4 y 7 de EVRC-WB son interoperables con EVRC-B, precisamente porque la familia admite una transición controlada entre operación wideband y narrowband.

Un observador que guarda solo el payload type puede probar el contrato de decodificación. No puede atribuir el modo a un intervalo concreto sin la declaración y, cuando sea importante, sin evidencia de la configuración real del codificador y de las tramas.

La cifra 16000 tampoco es un recibo acústico

EVRC-WB debe usar siempre un reloj RTP de 16 kHz. El timestamp avanza 320 unidades por cada trama de 20 ms. Esa regla permanece aunque la entrada del codificador o la salida del decodificador se configure a 8 kHz.

Por tanto, EVRCWB0/16000 prueba la escala temporal que debe usar RTP. No prueba la frecuencia de muestreo del micrófono, la ruta de audio, el convertidor, la salida física ni la experiencia del oyente.

La distinción importa para capacidad, calidad y cumplimiento. Una métrica de “sesiones wideband” calculada a partir del clock rate puede aumentar mientras la ruta acústica sigue siendo narrowband. La sintaxis conserva interoperabilidad; no inspecciona el hardware.

La preferencia del receptor no controla al emisor

Con mode-set-recv, un receptor EVRC-WB expresa el conjunto de modos que prefiere que use el codificador remoto. Con recvmode, un receptor EVRC-B expresa un modo preferido. Ambos parámetros pertenecen a la dirección de recepción.

RFC 5188 permite que el emisor remoto ignore la solicitud. El receptor debe seguir decodificando correctamente aunque el modo elegido no pertenezca a su preferencia. El propio ejemplo normativo muestra a un receptor dispuesto a aceptar el modo 0 mientras el otro extremo decide enviar en modo 4.

Eso no convierte el parámetro en adorno. Puede orientar una política de ancho de banda o compatibilidad. Pero obliga a registrar la respuesta con precisión: preferencia recibida, decisión del emisor, motivo local, modo anunciado, modo aplicado y periodo de vigencia.

Marcar “negociación fallida” cuando el emisor elige otro modo confunde una preferencia con una obligación. Marcar “preferencia cumplida” por el simple hecho de verla en la respuesta comete el error inverso.

Cada parámetro tiene dirección y autor

mode-set-recv y recvmode son receive-only. sendmode es send-only. Una preferencia de recepción en un stream sendonly no aporta una decisión útil; un sendmode en un stream recvonly tampoco.

Los adaptadores que copian automáticamente todos los parámetros de una oferta a una respuesta pueden producir un documento simétrico y semánticamente vacío. La presencia de la misma cadena en ambos lados no demuestra que ambos extremos le den el mismo significado.

Los parámetros desconocidos de una oferta deben ignorarse y no aparecer en la respuesta. Esa omisión evita simular un acuerdo sobre una extensión que el receptor no entiende. Una prueba que exige eco literal premiaría el comportamiento equivocado.

El estado de control puede llegar tarde

sendmode anuncia el modo actual del codificador. Sin embargo, RFC 5188 advierte que RTP puede llegar bastante antes que la SDP inicial o actualizada que contiene ese parámetro.

Si el codificador cambia a modo 4, el nuevo medio puede atravesar la red antes de que el colector reciba el nuevo sendmode. Durante ese hueco, el último documento conocido está desactualizado. Cuando llega la actualización, tampoco fecha retroactivamente cada paquete anterior.

La reconstrucción exige una línea temporal: versión de oferta/respuesta, momento de activación del codificador, envío y llegada RTP, interpretación de la trama e ingreso al decodificador. La correlación puede concluir que la declaración llegó tarde, que la captura está incompleta o que existió una divergencia real. Sin esos relojes, solo hay una conjetura decorada con SDP.

La compatibilidad antigua conserva incertidumbre

RFC 5188 añade recvmode y sendmode a registros EVRC-B de RFC 4788. Una implementación antigua no envía esos parámetros y los ignora si los recibe. Así se mantiene la interoperabilidad.

La ausencia no identifica automáticamente la versión ni el modo. Puede significar peer legacy, declaración opcional omitida, intermediario que normalizó la SDP o captura parcial. El registro debe decir “desconocido” hasta que otra evidencia cierre la hipótesis.

El oferente EVRC-WB debería anunciar también EVRC-B, dando preferencia a EVRC-WB, para que un peer solo compatible con EVRC-B pueda responder. Que la respuesta elija el fallback prueba la selección de codec, no una degradación accidental ni el modo exacto de cada trama.

EVRCWB1 necesita continuidad de sesión

EVRCWB1 fija tasa y modo durante toda la sesión. Un cambio a mitad de la misma identidad constituye una cuestión distinta de la libertad normal de otros formatos.

No basta con mostrar una renegociación posterior. Hay que probar dónde terminó la configuración anterior, si comenzó otra sesión o binding de payload y qué paquetes pertenecen a cada tramo. Sin identidad continua, dos periodos válidos pueden parecer una sesión inválida; sin un corte verificable, una violación real puede ocultarse bajo la última SDP.

Un recibo que no confunda capas

El expediente empieza con ID de sesión y cambio, roles, dirección, versiones de oferta y respuesta, payloads, subtipos, clock rate y líneas crudas rtpmap, fmtp, ptime y maxptime.

Después conserva la preferencia y su propietario; la decisión del emisor de respetarla o ignorarla; cada sendmode y su hora; las transiciones del codificador; y secuencia, timestamp, llegada y modo observado o inferido de las tramas relevantes. La capacidad legacy y el tratamiento de extensiones desconocidas deben quedar explícitos.

Por último se registran aceptación del decodificador, salida y resultado de aplicación. Decodificar no demuestra la preferencia, y cumplir la preferencia no demuestra calidad percibida. Cada capa informa solo de su propio hecho.

Decisión para liderazgo

Una organización debe decidir si gobierna texto o ejecución. Si su SLO promete modo, ancho de banda o calidad, no puede cerrarlo con payload y clock rate. Necesita el tramo que une la intención del receptor, la autonomía del emisor y el medio observado.

La disciplina consiste en no degradar la interoperabilidad a desobediencia y no elevar la señalización a resultado. Conservar esos límites hace posible una operación flexible sin perder responsabilidad.

Fuentes

  1. RFC 5188 HTML
  2. RFC 5188 texto
  3. Información RFC 5188
  4. Datatracker RFC 5188
  5. Historial RFC 5188
  6. Referencias RFC 5188
  7. Errata RFC 5188
  8. RFC 4788
  9. Información RFC 4788
  10. RFC 3558
  11. Información RFC 3558
  12. RFC 3264 oferta-respuesta
  13. Información RFC 3264
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. Tipo IANA audio/EVRCWB
  17. Parámetros RTP IANA
  18. Heng Lu — capas de realidad
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — prioridad del código en ejecución