Summary

  • El número de secuencia FIR distingue una orden nueva de una repetición dentro de un par concreto de SSRC. No es un indicador del estado del decodificador.
  • En una topología con MCU, la petición hacia el MCU y la petición que este genera hacia la fuente son tramos de fiabilidad independientes; ninguno acredita por sí solo lo que recibió y mostró el destinatario.

Un MCU acaba de seleccionar a otro participante para la salida principal. Recibe una Full Intra Request, genera otra hacia la nueva fuente y registra ambos envíos. Antes de que llegue la imagen de refresco, cambia de nuevo la selección. El historial del control es correcto, pero ya no responde a la pregunta que interesa: ¿qué cadena de predicción pudo reconstruir el receptor original?

La RFC 5104 amplía AVPF con mensajes de control de codec que necesitan viajar cerca del medio. FIR pide un punto de refresco; TSTR y TSTN tratan la preferencia temporal-espacial; VBCM transporta retroalimentación H.271; TMMBR y TMMBN expresan límites temporales de tasa y el conjunto que los acota. Son contratos distintos, no variantes de un acuse universal.

FIR identifica al emisor multimedia mediante un SSRC objetivo. Además lleva una secuencia de ocho bits cuyo espacio pertenece a la pareja entre el SSRC que manda y el SSRC destinatario. Cada orden nueva incrementa uno módulo 256. La retransmisión de la misma orden conserva el valor.

Esa regla impide que una copia tardía parezca una instrucción nueva y evita trabajo duplicado en el codificador. Su alcance termina ahí. El ocho no codifica si la fuente aceptó la orden, cuándo pudo satisfacerla, qué paquetes se produjeron, qué tramo los perdió o qué imagen mostró el cliente.

El objeto solicitado tiene una semántica más fuerte. Un punto de refresco es una secuencia de bits, repartida en uno o varios paquetes RTP, que restablece por completo el decodificador a un estado conocido. Puede ser una imagen intra, una IDR o un proceso gradual, y debe incluir la información superior a la capa de imagen que sea necesaria en banda para decodificar lo que sigue.

Por eso un pico de tamaño o la presencia de un NAL concreto no bastan sin contexto de codec. Tampoco basta que el codificador anuncie que empezó una IDR. El receptor debe observar una unidad completa y pertinente a su flujo, con los parámetros de los que depende y dentro de la misma época de selección.

Al recibir FIR, el codificador debe emitir un punto de refresco tan pronto como sea posible. Pero la misma RFC obliga a respetar el control de congestión. Una imagen de refresco puede ser varias veces mayor que una imagen predicha y tardar mucho más que un intervalo de cuadro cuando la tasa disponible es baja. La obligación no convierte una cola ni un enlace en instantáneos.

La regla de repetición registra precisamente esa incertidumbre. El solicitante puede repetir FIR hasta recibir el contenido buscado. Debe dejar de repetir tanto cuando recibe el refresco completo como cuando detecta un intento de refresco dañado por pérdida. Es posible, por tanto, que la última repetición desaparezca del gráfico porque el intento falló de una manera reconocible.

Si hace falta una orden realmente nueva, la secuencia cambia. No puede haber más de una FIR distinta pendiente para una fuente. Si las repeticiones continúan más de dos RTT después de que el codificador enviara un punto, debe enviar otro. La máquina de estados mejora la fiabilidad; no produce una confirmación de renderizado.

La ausencia de una notificación FIR explícita es intencional. La RFC considera que el punto de refresco se puede identificar en el propio flujo. Para cerrar el bucle, el solicitante observa datos multimedia en vez de confiar en un mensaje que diga que la acción ocurrió. El dato ejecutado disciplina al control.

Esa observación sigue teniendo capas. Detectar un intento demuestra que algunos paquetes con sintaxis esperada llegaron al punto de observación. Demostrar integridad exige la totalidad pertinente. Demostrar reinicio exige el estado del decodificador. Demostrar presentación exige el renderer. Demostrar recuperación del servicio requiere además la regla de la aplicación y, si se formula una afirmación humana, una señal adecuada de experiencia.

El MCU divide la custodia. Según RFC 5104, un mixer o conmutador que recibe FIR es responsable de hacer llegar un punto al receptor solicitante. Puede necesitar emitir su propia FIR hacia la fuente. Los dos tramos se gestionan independientemente desde la perspectiva de fiabilidad.

Ese detalle impide sumar dos órdenes como si fueran un resultado. Para el primer tramo se necesitan los SSRC, la secuencia y el contexto de seguridad del receptor y el MCU. Para el segundo, los del MCU y la fuente. Entre ambos está el mapa de selección. Después vienen el paquete de refresco recibido por el MCU y la serie realmente reenviada. Una correlación sin estas identidades puede unir una orden a la fuente equivocada.

La topología también determina quién puede actuar localmente. Un traductor puede reenviar la petición; un mixer puede generar otra y responder hacia atrás. Un RTCP-terminating MCU no conserva necesariamente la misma visibilidad extremo a extremo. RFC 5117 ayuda a nombrar esas diferencias. Decir simplemente “el servidor de conferencia recibió FIR” oculta el contrato que falta.

FIR no debe sustituir a Picture Loss Indication. Para pérdida ordinaria, la RFC recomienda PLI de RFC 4585. FIR corresponde a situaciones en que no enviar un refresco dejaría la imagen inservible, como la incorporación de un participante sin refresco periódico o el cambio de fuente en un MCU.

La distinción reduce daños. Una imagen intra grande puede presionar una ruta ya congestionada. Ordenar FIR en cada señal de pérdida puede bajar la frecuencia de cuadros y producir saltos visibles. Un sistema de automatización necesita conservar la condición que disparó la orden y el efecto posterior; de lo contrario, atribuirá al enlace una degradación causada por su propia política.

TSTR/TSTN muestra otra clase de respuesta. TSTR solicita un punto de compromiso entre resolución temporal y espacial. TSTN devuelve el índice que el emisor decidió utilizar, no necesariamente el solicitado. Varios receptores pueden pedir valores incompatibles y la RFC deja margen al codificador, mixer o traductor para agregarlos.

TMMBR/TMMBN opera sobre una región factible. El receptor anuncia una pareja de tasa máxima total y overhead por paquete. El emisor calcula el conjunto limitante y notifica sus parejas y propietarios. Debe emitir TMMBN aunque el nuevo TMMBR no sea incorporado. Un monitor que traduce esa notificación como “petición aceptada” pierde el dato decisivo.

Además, la tasa total depende de la capa donde se mide. Emisor y receptor pueden contar diferente overhead. TMMBR expresa límites conocidos, a menudo locales, y no garantiza la capacidad de toda la ruta. Cuando se relaja una limitación, el emisor espera para que otros participantes puedan presentar una más estricta, y todo aumento continúa sujeto al control de congestión.

La protección criptográfica evita otra confusión pero no todas. La RFC advierte que feedback falsificado puede reducir severamente la tasa, atribuir el límite al participante equivocado, imponer una preferencia visual no deseada o provocar suficientes FIR para volver entrecortado el vídeo. Exige autenticidad e integridad en la señalización y el feedback. SRTP y SAVPF ofrecen el marco pertinente.

Un FIR autenticado demuestra mejor quién habló y qué bytes quedaron protegidos. No demuestra que el codificador obedeciera, que los paquetes cruzaran el siguiente tramo, que el refresco estuviera completo o que un usuario viera la imagen. Autenticidad, autorización, ejecución y resultado son comprobantes relacionados, no intercambiables.

La versión normativa también tiene época. RFC 5104 es Proposed Standard y fue actualizada por RFC 7728 para pausa/reanudación y por RFC 8082 para codecs escalables. Un analizador que conozca el formato original pero ignore el contexto de capas o pausa puede clasificar bien un paquete y mal la operación.

Una investigación debería retener una cadena mínima: sesión y contexto criptográfico; SSRC de origen y destino de FIR; secuencia, primer envío y repeticiones; mapeo y época del MCU; recepción por el codificador; identidad y hora del refresco generado; rango RTP y pérdidas por tramo; observación completa o dañada en el solicitante; transición del decodificador; presentación; y criterio de recuperación de la aplicación. No hace falta guardar el contenido de la llamada.

Esta separación aplica el enfoque de capas de realidad de Heng Lu. La orden es verdadera en el plano de control. El intento es verdadero en el plano multimedia. El reset pertenece al decodificador y la presentación al renderer. Un responsable puede unir esos datos con una política explícita; no debe dejar que el primer registro hable en nombre de todos.

Sources