Resumen

  • RFC 5285, obsoleta por RFC 8285, usa números locales para ahorrar espacio y delega en extmap la asociación con la URI que define cada extensión.
  • El análisis fiable necesita conservar paquetes y negociación como evidencias separadas. El formato válido no prueba la semántica, y la semántica correcta tampoco prueba que una acción posterior funcionó.

La grabación mostraba el ID 5 en miles de paquetes. Después de una migración, el panel siguió dibujando la misma métrica. Nadie había falsificado los datos ni perdido tráfico. El error era más sencillo: el analizador había heredado la tabla de la llamada anterior. En la nueva negociación, 5 apuntaba a otra URI.

El número se repitió; el significado no.

RFC 5285 resolvió un problema de eficiencia. RTP disponía de un área de extensión, pero no de un método general para empacar varios elementos pequeños y evitar colisiones entre muchas extensiones posibles. La solución separó nombre y código corto. Una URI absoluta identifica el formato y el significado. Un número local aparece en cada paquete. SDP los relaciona mediante a=extmap.

RFC 8285 sustituyó a RFC 5285 y permitió, bajo condiciones, alternar formas de cabecera de uno y dos bytes en un flujo. Conservó la idea crucial: no hay una asignación estática y mundial de los identificadores locales. Por eso una captura aislada puede demostrar que llegó el ID 5 sin demostrar qué extensión era.

El registro central termina donde empieza la sesión

IANA mantiene un registro de URI para extensiones compactas RTP. Allí aparecen funciones muy distintas: desfase de transmisión, marcas de sincronización, nivel de audio, MID, RID o marcado de tramas. El registro permite referirse a una definición estable. No reserva el número 1, 3 o 5 para esa función en todos los flujos.

La forma de un byte dispone de catorce identificadores útiles. La de dos bytes amplía el espacio. La escasez es intencionada: el número se envía en cada paquete y debe ser barato. El precio es que su autoridad acaba en el ámbito donde fue negociado.

El ámbito puede ser toda la sesión o una sección de medios. RFC 8285 no permite mezclar ambos estilos de declaración. La dirección también cuenta. Una extensión puede ser sendonly, recvonly, sendrecv o inactive. Guardar una pareja simple ID → nombre elimina dimensiones que pueden cambiar la interpretación o la legitimidad de lo observado.

La evidencia completa debería enlazar cada paquete con una instantánea concreta de oferta y respuesta, su sección de medios, grupo BUNDLE, dirección, URI y atributos. Si falta ese enlace, el analista puede seguir calculando pérdida, orden y temporización. Lo que no puede hacer con rigor es bautizar el contenido de la extensión por semejanza con otro despliegue.

Analizar la envoltura no equivale a interpretar el dato

Cada elemento lleva identificador y longitud. El perfil RTP indica si el paquete usa el formato de uno o dos bytes. Un parser puede confirmar que la longitud encaja, separar el valor y conservarlo sin error. Ese es un recibo sintáctico.

El recibo semántico empieza después. El ID debe localizar una URI en la configuración válida; el decodificador de esa URI debe aceptar el valor. Un sistema que salta directamente de «pude recorrer los bytes» a «sé que es nivel de audio» mezcla dos autoridades.

El modo mixto refuerza esta separación. RFC 5285 obligaba a mantener una sola forma en el flujo. RFC 8285 introduce extmap-allow-mixed para que un flujo pueda alternarlas cuando todos los receptores lo han aceptado por oferta/respuesta o conocimiento externo. No autoriza mezclar elementos de ambas formas dentro del mismo paquete.

Por tanto, ver una forma de dos bytes prueba lo que envió el transmisor, no que el receptor tuviera capacidad negociada. Ver el atributo en una oferta prueba una propuesta, no su aceptación. Una operación madura conserva ambos documentos y no disfraza una mitad como confirmación de la otra.

La estabilidad del mapa protege al código en ejecución

Los IDs válidos no pueden duplicarse dentro del ámbito aplicable. Una actualización de sesión puede añadir o quitar extensiones y cambiar calificadores de dirección, pero no puede reasignar un ID válido a una URI distinta. Si pudiera hacerlo, los paquetes en tránsito quedarían sujetos a dos diccionarios simultáneos.

Esta regla convierte el historial en parte de la prueba. El último SDP no basta para explicar todos los paquetes anteriores. Cada cambio crea una época. El archivo debe saber cuándo empezó a aplicarse y qué mensajes de señalización la justifican.

Las cifras 4096–4351 sirven para ofrecer alternativas mutuamente excluyentes o candidatos que no caben aún en el rango válido. El respondedor puede seleccionar uno y asignarlo a un número utilizable. Esas cifras grandes son instrumentos de negociación, no valores de cable. Un inventario que las marque como extensiones activas confunde posibilidad con ejecución.

También es legítimo anunciar una extensión como inactiva para reservar la posibilidad de usarla en una oferta futura. «Está en SDP» no significa «apareció en RTP». La prueba de presencia sigue siendo el paquete; la prueba de significado y permiso sigue siendo el contexto negociado.

BUNDLE obliga a conservar la geometría de la negociación

Cuando varias descripciones de medios comparten un transporte BUNDLE, ya no basta con asociar el flujo a una dirección y un puerto. MID permite vincular RTP con la sección m= correcta. RFC 9143 exige habilitar esa extensión en los medios RTP agrupados.

RFC 8285 considera que las secciones de un mismo grupo BUNDLE comparten el espacio de IDs locales. La misma URI y configuración debe llevar el mismo número en todas las secciones donde aparezca. Sin embargo, cada sección puede usar conjuntos distintos. La tabla correcta es una estructura con grupos, miembros y configuraciones, no un diccionario plano por servidor.

RID añade otra capa. RFC 8852 acota RtpStreamId por fuente y sesión; con BUNDLE, también por MID. El ID compacto localiza la clase de extensión. La carga RID identifica después un flujo dentro de su propio ámbito. Usar la palabra «ID» para ambos no los convierte en una única identidad global.

Un SFU, grabador o sonda que reenvía, reescribe o analiza esas capas debe declarar qué transformó. El paquete entrante, el mapa recibido, el paquete saliente y el mapa entregado al siguiente tramo son recibos distintos. Sin ellos, una gráfica agregada puede parecer coherente mientras atribuye metadatos a la sección de medios equivocada.

La confidencialidad puede retirar visibilidad sin retirar el dato

Las extensiones contienen metadatos que a veces son sensibles. RFC 6904 permitió cifrar valores seleccionados. RFC 9335 señaló además que identificadores y longitudes visibles podían servir para identificar una aplicación o terminal, y amplió la protección mediante Cryptex.

Cuando se cifra la zona, una sonda de red puede dejar de leer ID y valor. Ese cambio no significa que la aplicación haya dejado de producir el metadato. Significa que la sonda perdió autoridad para observarlo. Un endpoint que sí descifra todavía necesita el extmap correcto; criptografía y semántica resuelven problemas distintos.

La cadena honesta separa recepción, parseo, asociación, decodificación, uso y resultado. Por ejemplo, una aplicación puede decodificar correctamente un nivel de audio, elegir un hablante activo y aun así entregar una mala experiencia por latencia en otro tramo. El resultado no se hereda de la validez del metadato.

La lección operacional es conservar la realidad por capas. Paquete original, señalización, interpretación y consecuencia deben poder examinarse sin que una reemplace a la anterior. Así se puede corregir un decodificador sin reescribir la evidencia y retirar una automatización sin perder visibilidad.