Resumen

  • La IESG aprobó el 10 de septiembre los mensajes RTCP de petición y notificación de resolución temporal-espacial como Proposed Standard. Al cierre seguían siendo un Internet-Draft sin número RFC final y con trabajo de IANA pendiente.
  • TSRR permite pedir velocidad de cuadros, anchura y altura; TSRN informa los valores que el emisor prevé usar. La respuesta puede apartarse de lo solicitado y no garantiza lo que finalmente recibió el terminal.
  • Para afirmar un ahorro no basta con una señal válida: hacen falta observación del flujo, una línea base energética, condiciones del dispositivo, efectos de calidad y un registro de corrección.

El mensaje nuevo resuelve una falta de coordinación

La acción de protocolo del 10 de septiembre aprobó RTP Control Protocol Messages for Temporal-Spatial Resolution como Proposed Standard. La ficha vigente del Datatracker mostraba la revisión 17, el anuncio de aprobación enviado y el trámite de IANA en curso. La decisión es real; un número RFC definitivo y unas asignaciones terminadas todavía no lo eran en la fecha de corte.

El expediente de aprobación deja otra separación útil. La primera última llamada del grupo de trabajo, en 2024, no recibió respuestas suficientes para declarar consenso. Tras nuevas revisiones, una segunda ronda permitió concluir que existía buen consenso. Contar esa secuencia no debilita el estándar; ubica la autoridad en actos verificables.

La necesidad técnica es sencilla. Un decodificador puede encontrarse limitado por batería o capacidad de proceso, mientras el codificador remoto controla el flujo. Hasta ahora faltaba una forma RTCP específica de pedir una combinación de velocidad de cuadros y dimensiones y recibir una respuesta explícita. El nuevo formato llena esa carencia dentro del modelo de realimentación de RFC 4585 y de los mensajes de control de códec de RFC 5104.

TSRR expresa una preferencia acotada

La revisión 17 denomina TSRR a la petición de resolución temporal-espacial. Incluye la fuente multimedia destinataria, un número de secuencia, cuadros por segundo, anchura y altura. Los valores deben permanecer dentro de lo negociado por SDP y no pueden ser cero.

El receptor sugiere; el emisor conserva la decisión. Si puede adaptar el codificador, puede tener en cuenta la petición para las imágenes futuras. Después debe enviar TSRN, la notificación correspondiente, con la combinación que utilizará como resultado de esa petición. El lenguaje evita convertir la necesidad de un extremo en una orden universal.

Hay razones normales para no copiar los valores solicitados. Un vídeo pregrabado puede no admitir el cambio. El codificador puede carecer de esa configuración. Un mezclador puede estar atendiendo a varias personas con necesidades opuestas. Las reglas del servicio pueden fijar un mínimo de calidad, y el control de congestión puede reducir lo que realmente se entrega. Una petición superior a lo negociado se ignora.

La capacidad tampoco se presume. En oferta/respuesta SDP, tsrr solo queda disponible si aparece en la intersección que aceptan ambos extremos. La sección operativa afirma que implementarlo únicamente en un lado no cambia el servicio RTP. Por eso conviene separar soporte declarado, negociación completada, petición emitida y adaptación efectiva.

La respuesta cierra un bucle, no todos

TSRN tiene semántica concreta. Acusa recibo de TSRR, conserva su número de secuencia e informa a cada solicitante de los valores elegidos. Si llegan repeticiones, el emisor debe responder de acuerdo con las reglas de secuencia. En una topología con traductor o mezclador, la respuesta puede demorarse mientras la petición se reenvía.

Esa notificación es evidencia de control. No es una captura del vídeo recibido. Tampoco contiene vatios, julios, duración de batería, carga del procesador o una medida de carbono. Incluso cuando el emisor cumple su intención, dos terminales con el mismo vídeo pueden tener consumos distintos por el códec, el silicio, la aceleración, el brillo de pantalla o las tareas simultáneas.

La referencia de energía es ISO/IEC 23001-11:2023, sobre consumo multimedia eficiente. El borrador IETF transporta una parte del feedback previsto en ese contexto; no se presenta como metodología integral de medición. El nombre histórico green-metadata no amplía lo que los campos pueden demostrar.

La cadena lógica correcta mantiene cinco estados:

petición → selección anunciada → flujo observado → energía medida → balance de calidad.

Saltar de la segunda casilla a la cuarta crea una afirmación que el protocolo no respalda.

La calidad es un coste de decisión

El propio texto advierte que aceptar sugerencias inadecuadas puede empeorar la experiencia y provocar quejas. Recomienda calibrar rangos aceptables e incorporar el riesgo al cumplimiento y aseguramiento de acuerdos de nivel de servicio. Un menor número de píxeles puede ser razonable para preservar una llamada; también puede volver ilegible una pizarra, perjudicar una interpretación visual o desplazar el coste al usuario.

En una conferencia, además, quien pide el cambio y quien soporta sus efectos pueden ser personas distintas. El mezclador debe considerar necesidades conjuntas. Una notificación con tres números no revela qué política resolvió el conflicto, quién la administraba ni si existía un mecanismo de excepción.

Aquí aparece la gobernanza real. La IETF ofrece vocabulario interoperable. El operador decide el rango, el orden de prioridad, la protección, la reparación y la promesa comercial. El estándar no debería recibir crédito o culpa por decisiones que dejó correctamente en el ámbito local.

Proteger la ruta no demuestra la finalidad

Mensajes falsificados podrían bajar drásticamente los cuadros o las dimensiones, intentar aumentos fuera de los límites o saturar al receptor con solicitudes frecuentes. El documento exige tener en cuenta autenticación e integridad y remite al perfil seguro de RFC 5124. También pide un comportamiento conservador ante patrones anómalos.

La criptografía acredita que un mensaje procede del contexto protegido y no fue modificado. No acredita que la estimación de batería fuese correcta, que el solicitante tuviera permiso para afectar a otros, ni que la respuesta produjera ahorro. Una señal auténtica puede estar mal calibrada; una señal legítima puede generar una experiencia inaceptable.

También existe una superficie de derechos que los adoptantes deben revisar. La declaración Qualcomm 5764 se relaciona con el borrador predecesor y expresa una licencia razonable y no discriminatoria con posible canon o tarifa. La declaración InterDigital 6159 se refiere a versiones iniciales del documento del grupo y ofrece negociar, bajo sus condiciones, en términos razonables, recíprocos y no discriminatorios. Ninguna publicación es una decisión de la IETF sobre validez, esencialidad, infracción, precio o licencia efectivamente necesaria.

Un recibo que llegue hasta el efecto

Si una empresa presenta esta función como ahorro energético, debería respaldarla con una cadena de evidencia de cambio de resolución. Primero registra versiones de software, negociación tsrr, contexto de seguridad, función del solicitante, fuente destinataria, secuencia, hora y valores pedidos.

Después identifica quién decidió: emisor o mezclador, versión de la política, rango admisible, prioridades y forma de agregar solicitudes. TSRN se conserva como la configuración anunciada. Otra observación, separada, mide cuadros, dimensiones y bitrate entregados durante una ventana determinada.

La afirmación energética añade dispositivo, decodificador, ruta de hardware, pantalla, carga paralela, línea base, unidad, intervalo e incertidumbre. Al lado figuran congelaciones, latencia, legibilidad, accesibilidad, quejas, excepciones y retorno al estado anterior. La vista pública elimina identificadores de participantes, secretos y umbrales que facilitarían abuso, mientras la prueba protegida queda para operación y controversias.

Esta cadena es una propuesta editorial, no un campo exigido por la IETF, ISO, IANA o los titulares declarantes. Aplica la regla de autoridad de The Policy Mirror de Heng Lu: cada estado debe mostrar quién puede decidir y qué lo prueba. Minimum Initial Specification explica por qué una señal común mínima puede convivir con adopción voluntaria y decisiones locales. Why BTW Media Exists obliga a no convertir la intención institucional en operación observada.

La aprobación mejora la coordinación entre extremos. La prueba de energía empieza exactamente donde termina esa coordinación.

Sources

  1. Anuncio de la acción IETF
  2. Registro del Datatracker
  3. Internet-Draft, revisión 17
  4. Expediente de aprobación
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. Declaración IPR 5764
  9. Declaración IPR 6159
  10. ISO/IEC 23001-11:2023
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists