Resumen

  • RFC 3555 convirtió un nombre de tipo de medio en una unión verificable entre el número local de carga RTP, el formato, el reloj y los parámetros de sesión.
  • El registro coordinaba el vocabulario; no demostraba que un extremo entendiera el formato, que los paquetes respetaran lo anunciado ni que el audio pudiera usarse.

El 97 de a=rtpmap:97 L16/48000/2 parece compacto, pero no conserva por sí solo ninguna identidad. RTP reserva números dinámicos para que una sesión los asigne. Por eso 97 solo adquiere sentido al lado de L16, 48000 y dos canales, dentro de la descripción que también enumera 97 en la línea de medios.

Esa fue una de las aportaciones históricas de RFC 3555. El documento hizo posible usar los nombres de los formatos de carga RTP como subtipos de medio en expresiones de texto y protocolos de control. Pero no confundió el nombre transportable con el número efímero. El primero remitía a una especificación; el segundo era una clave de la sesión.

Desmontar la cadena antes de volver a montarla

El ejemplo de RFC 3555 comienza con audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15. La conversión a SDP reparte sus piezas. audio aparece en m=; L16, el reloj y el número de canales forman rtpmap; emphasis pasa a fmtp; y el tiempo de paquete recomendado queda en un atributo ptime independiente.

Cada destino responde a una pregunta distinta. ¿Qué clase de medio ofrece la sesión? ¿Qué formato representa el número dinámico? ¿Con qué reloj avanza el sello temporal? ¿Cuántos canales codifica? ¿Qué parámetros debe recibir la herramienta que conoce ese formato? ¿Qué duración de paquete recomienda el emisor?

Si un intermediario conserva el nombre pero pierde una de esas respuestas, no ha preservado el contrato. Dos descripciones pueden mostrar L16 y aun así diferir en reloj, canales o parámetros. También pueden ser sintácticamente válidas y resultar incompatibles con el receptor.

RFC 3555 cerró además una vía de expansión informal. Los parámetros específicos que se colocan en fmtp deben estar permitidos por el RFC del formato de carga. El registro del subtipo puede describir el mapa, pero no agregar semántica nueva sin revisar la especificación del formato. IANA mantiene la entrada; no gobierna el decodificador ni inventa el protocolo.

El catálogo no es una tabla de capacidades

Una consulta al registro actual puede encontrar audio/L16, audio/PCMA o audio/PCMU. La instantánea XML congelada para este artículo, actualizada el 6 de octubre de 2026, contiene 165 entradas de audio y 97 de vídeo; veinte citan directamente RFC 4856. Eso prueba que existen entradas en el catálogo y qué documento las controla. No prueba que un teléfono, navegador, pasarela o archivo concreto las implemente.

La prueba operativa exige más escalones. Primero, el subtipo debe estar registrado para el modo de transporte usado. Después, los parámetros deben mapearse a los campos correctos. Luego, la sesión debe enlazar el número de carga con esa combinación exacta. Ambos extremos deben implementar el mismo formato y aceptar sus parámetros. Por último, los paquetes deben llegar, ajustarse al formato y producir una decodificación utilizable.

Un anuncio no es una aceptación. Una aceptación no es un paquete. Un paquete no es audio útil.

La sustitución de 2007 no borró el mecanismo

RFC 4855 y RFC 4856 dejaron obsoleto RFC 3555. El primero actualizó el procedimiento de registro y mantuvo el mapa hacia SDP. También aclaró que un mismo subtipo no debía compartirse entre RTP y un formato de archivo si los datos o los parámetros obligatorios no eran equivalentes. El segundo separó los registros concretos del perfil RTP y declaró que esa extracción no introducía cambios técnicos.

La separación reveló tres ritmos de mantenimiento: la regla general de registro, la lista de subtipos y la especificación de cada carga. RFC 6838 siguió revisando las reglas generales de tipos de medio. RFC 8866 modernizó SDP y conservó rtpmap y fmtp. Ningún cambio autorizó a tratar el número dinámico como identidad mundial.

La lección no es que el mismo nombre deba aparecer en todas partes. Es que, cuando atraviesa contextos, deben quedar visibles tanto el mapa como sus límites. RFC 3555 consiguió portabilidad porque no permitió que la comodidad del nombre ocultara la localidad del número ni la autoridad del formato.

Fuentes