Summary

  • Les huit bits de séquence FIR appartiennent au couple formé par le SSRC qui commande et le SSRC visé. Ils identifient une génération de commande, pas l’état du décodeur.
  • La RFC 5104 arrête les répétitions après réception d’un rafraîchissement complet ou après détection d’une tentative endommagée. « La répétition a cessé » ne veut donc pas dire « l’image est revenue ».

Un ticket d’exploitation est clos avec une preuve apparemment nette : la commande FIR a été envoyée, le numéro de séquence a changé et les retransmissions ont cessé. Le contrôleur a effectivement accompli son travail. Pourtant, aucune de ces trois observations ne dit encore ce que le décodeur a pu reconstruire.

La RFC 5104 étend le profil RTP audiovisuel avec retour, AVPF. Elle définit six messages adaptés aux contraintes temporelles des médias : FIR, TSTR, TSTN, VBCM, TMMBR et TMMBN. Leur proximité avec le flux RTP ne leur confère pas une autorité générale sur la session. Le texte précise au contraire qu’ils portent sur un codec ou un flux RTP déterminé et non sur les propriétés des liens d’accès.

FIR, Full Intra Request, est une commande ciblée. Son champ SSRC désigne la source média qui doit produire un point de rafraîchissement du décodeur. Son numéro de séquence sur huit bits est propre au couple SSRC source de la commande / SSRC cible. Une nouvelle commande augmente ce nombre d’une unité modulo 256. Une répétition conserve la même valeur.

Ce nombre résout un problème de contrôle : le destinataire peut reconnaître une copie d’une commande déjà traitée et éviter de générer inutilement plusieurs grosses images intra. Il ne constitue pas un compteur universel de récupération. Sans l’identité de la session, les deux SSRC, l’époque et le contexte de sécurité, une valeur identique après bouclage peut même appartenir à une autre histoire.

Le point de rafraîchissement possède une définition plus exigeante que la commande. Il s’agit d’un ensemble de bits transporté dans un ou plusieurs paquets RTP qui replace complètement le décodeur dans un état connu. Selon le codec, ce peut être une image intra, une image IDR ou un rafraîchissement graduel. Les informations en bande nécessaires au-dessus de la couche image font également partie du point.

La réception de FIR oblige l’encodeur à envoyer ce point dès que possible. La formule laisse subsister une contrainte concrète : le contrôle de congestion. Un point de rafraîchissement est souvent plusieurs fois plus volumineux qu’une image prédite. Lorsque le débit disponible est faible, son émission peut durer bien plus longtemps qu’un intervalle d’image ordinaire. Le journal d’émission peut donc être exact alors que l’application a déjà changé de source ou dépassé son délai.

Le modèle de fiabilité refuse précisément de confondre la commande et le résultat. L’émetteur de FIR peut répéter la même commande jusqu’à ce qu’il reçoive le contenu souhaité. Il doit aussi arrêter les répétitions lorsqu’il détecte une tentative de point de rafraîchissement abîmée par une perte de paquets. Dans ce second cas, l’arrêt atteste une tentative identifiable, pas un contenu exploitable.

Si un nouveau FIR devient nécessaire, son numéro augmente. Une seule commande distincte peut rester en attente par source média. Si l’encodeur reçoit encore des répétitions plus de deux temps aller-retour après avoir envoyé un point, il doit en émettre un autre. Ces règles améliorent la probabilité de livraison et limitent les doublons. Elles ne produisent pas un accusé de décodage.

La RFC ne définit d’ailleurs aucun message de notification FIR. Ce choix n’est pas un oubli. Le point de rafraîchissement est reconnaissable dans le flux binaire ; le demandeur peut donc observer l’action sur le chemin média. Le reçu pertinent n’est pas « le contrôleur a répondu », mais « le contenu demandé a été observé, complet ou endommagé ».

Même ce reçu ne couvre pas toute la chaîne. Un analyseur peut identifier un ensemble complet de paquets sans démontrer que la pile RTP l’a livré à temps. La pile peut livrer les octets sans prouver que le codec disposait de tous les paramètres. Le décodeur peut annoncer sa remise à zéro sans prouver que le moteur graphique a présenté l’image. Le rendu peut réussir sans établir ce que l’utilisateur a vu ou compris.

Les topologies multipoints ajoutent une rupture de garde. Un mélangeur RTP ou un MCU de commutation qui reçoit FIR doit faire parvenir un point de rafraîchissement au demandeur. Il peut générer une autre commande vers la source sélectionnée. La RFC traite les deux branches — demandeur vers MCU, puis MCU vers origine — comme des domaines de fiabilité indépendants.

Une ligne unique intitulée « FIR traité » efface cette distinction. Le MCU peut recevoir la première commande tandis que la seconde se perd. La source peut produire le point au moment où le MCU change sa sélection. Le MCU peut recevoir le rafraîchissement et n’en transmettre qu’une partie au destinataire initial. Les SSRC, horloges, numéros de séquence, contextes de protection et plages de paquets doivent rester rattachés à leur branche.

FIR n’est pas non plus le remède normal à chaque perte d’image. La RFC recommande le Picture Loss Indication de la RFC 4585 pour ce cas. FIR vise les situations où l’absence de rafraîchissement rendrait la vidéo inutilisable, par exemple l’arrivée d’un participant sans intervalle de rafraîchissement régulier ou la sélection d’une nouvelle source par un MCU.

Cette limitation protège le réseau autant que le sens des preuves. Des rafraîchissements répétés peuvent réduire la fréquence d’image et rendre la vidéo saccadée. Une automatisation qui transforme chaque alerte de perte en FIR peut créer elle-même le symptôme qu’elle prétend corriger. La mesure de perte, la politique de commande et l’effet observé doivent pouvoir être examinés séparément.

Les autres messages montrent pourquoi « acquitté » n’a pas une signification commune. TSTR demande un compromis entre résolution temporelle et spatiale. TSTN indique le compromis effectivement choisi, qui peut différer de la demande lorsque l’encodeur agrège plusieurs préférences ou applique ses propres critères.

TMMBR et TMMBN décrivent encore une autre relation. Un récepteur annonce une contrainte de débit total et de surcharge par paquet. L’émetteur calcule une région faisable et un ensemble de tuples limitants, puis publie cet ensemble et ses propriétaires. Il doit envoyer TMMBN même lorsque le nouveau tuple demandé n’entre pas dans l’ensemble. La notification ne signifie donc ni acceptation de la demande particulière, ni qualité mesurée.

La limite de débit dépend du point d’observation et de la couche comptée. La RFC indique que l’émetteur et le récepteur peuvent observer des débits totaux différents à cause des surcharges. TMMBR exprime généralement une limite connue localement et ne garantit rien sur le chemin complet. Une hausse reste soumise au contrôle de congestion et à un délai laissant aux autres récepteurs le temps d’annoncer une contrainte plus stricte.

La sécurité rend la commande attribuable, pas auto-réalisatrice. La RFC 5104 avertit qu’un faux TMMBR peut écraser le débit, qu’un faux TSTR peut imposer un compromis indésirable et que des FIR malveillants répétés peuvent dégrader la vidéo. Elle exige authentification et intégrité pour la signalisation de mise en place et les retours. SRTP et SAVPF apportent ce cadre contre les menaces externes.

Un FIR authentifié est une meilleure preuve qu’un paquet anonyme. Il établit des octets, un principal de session et un contexte de protection. Il ne prouve toujours pas l’obéissance de l’encodeur, la traversée des paquets, la remise à zéro du décodeur ou la présentation. L’authenticité répond à « qui a parlé » ; elle ne répond pas à « que s’est-il produit à chaque couche suivante ».

Le statut du document doit lui aussi rester dans sa couche. RFC 5104 demeure Proposed Standard et a été mise à jour par la RFC 7728 sur pause/reprise et la RFC 8082 sur les codecs en couches. La publication ne prouve ni implémentation, ni négociation correcte de ces extensions, ni résultat de session.

Un registre d’incident défendable relie donc des reçus distincts : identité de session et contexte de sécurité ; SSRC source et cible ; numéro de commande ; premier envoi et répétitions ; branche de mélangeur ou de traducteur ; réception par l’encodeur ; génération du point avec identité codec ; plage RTP et pertes ; observation complète ou endommagée par le demandeur ; résultat du décodeur ; image présentée ; signal de récupération applicative. L’incertitude des horloges et les changements de topologie doivent être conservés sans enregistrer le contenu média.

Cette chaîne applique la discipline des couches de réalité de Heng Lu. Un registre devient fiable lorsqu’il refuse de prétendre au-delà de son observation. Le contrôleur peut prouver la commande. Le flux peut prouver la tentative. Le décodeur peut prouver sa transition. Le rendu peut prouver une présentation. La direction peut définir la règle qui les joint ; elle ne doit pas laisser un seul voyant emprunter l’autorité des autres.

Sources