Résumé

  • Le 201 Created défini par RFC 9725 atteste l’acceptation d’une offre SDP et la création d’une ressource HTTP. Il n’atteste ni la sélection d’un couple ICE, ni l’achèvement de DTLS, ni l’arrivée d’un flux SRTP.
  • L’exploitation d’un direct doit conserver des reçus distincts pour l’admission, le chemin réseau, la sécurité, la continuité des paquets, le traitement, la distribution et l’expérience d’un lecteur.
  • La réponse à DELETE clôt une commande. La clôture opérationnelle exige encore de rattacher l’arrêt du média et la restitution de chaque capacité à la bonne session.

Sept états pour un seul voyant

Un technicien ferme un direct à 22 h 03. La requête DELETE reçoit un 200 OK. Pourtant, dix minutes plus tard, un emplacement de transcodage est toujours réservé et un manifeste continue d’être servi comme s’il était actuel. Ce n’est pas un paradoxe HTTP. C’est une erreur de comptabilité entre plusieurs systèmes.

La même erreur se produit au démarrage. RFC 9725 organise un échange volontairement bref : l’encodeur envoie une offre SDP par POST ; le point d’entrée répond 201 Created, fournit la réponse SDP et indique, dans Location, l’adresse de la nouvelle session WHIP. Le registre du RFC Editor et la fiche Datatracker situent ce Proposed Standard en mars 2025. La recherche d’errata ne renvoyait aucun résultat lors de cette étude ; elle ne certifie aucun logiciel.

Le point d’entrée peut donc prouver ce qu’il a fait : recevoir application/sdp, accepter la structure et la politique de l’offre, générer une réponse initiale et allouer une ressource. La sémantique HTTP borne ce constat. Elle ne rend pas le serveur témoin d’un paquet qui n’a pas encore traversé le réseau.

Sept états se cachent derrière le voyant « en direct » : ressource créée, chemin ICE sélectionné, association DTLS établie, média protégé reçu dans la durée, traitement productif, distribution observable, session entièrement libérée. La valeur de RFC 9725 est précisément de ne pas prétendre unifier ces états. L’erreur consiste à le faire dans l’exploitation.

Le contrat mince de WHIP

WHIP reprend les procédures d’offre et de réponse de JSEP, mais les réduit au cas d’une ingestion unidirectionnelle. Le client propose normalement sendonly, le serveur répond recvonly. La session contient un seul MediaStream, regroupe les médias et multiplexe RTP et RTCP. Les renégociations ultérieures qui changeraient les sections médias ne sont pas permises ; seuls les éléments ICE disposent d’un chemin de mise à jour.

Cette contrainte a une conséquence de gouvernance : le 201 fige une base non-ICE que les redémarrages ICE continueront de présumer. Si l’encodeur, le transcodeur ou le catalogue de codecs évolue après cette réponse, un PATCH ICE ne constitue pas une nouvelle approbation de ces choix.

Le RFC recommande aussi d’éviter les réponses partiellement réussies. Un point d’entrée devrait rejeter l’ensemble plutôt que conserver une section média et en refuser une autre, car une moitié de direct peut tromper l’utilisateur. Même ce rejet atomique ne transforme pas l’acceptation en qualité de service : il rend seulement la frontière de contrôle plus nette.

Une liste de candidats n’est pas un chemin

ICE construit des couples à partir des candidats locaux et distants, les vérifie avec STUN, en nomme un et finit par sélectionner le couple utilisé. Une adresse présente dans l’offre ou la réponse ne constitue donc qu’une possibilité. Le reçu utile est le couple sélectionné, son type direct ou relayé, son instant de nomination et sa persistance.

Trickle ICE rend cette différence visible. L’offre initiale peut partir avec quelques candidats locaux, voire sans candidat. Le client doit mettre en attente ceux qu’il découvre ensuite jusqu’à connaître la ressource Location — et, selon le cas, l’ETag — fournie par le 201. Il les envoie alors dans un PATCH défini par RFC 5789, au format application/trickle-ice-sdpfrag issu de RFC 8840.

La réponse 204 No Content ne promet pas que tous les candidats seront essayés. RFC 9725 autorise le serveur à écarter silencieusement un transport non pris en charge ou une adresse qu’il ne peut résoudre. Pour un centre d’exploitation, le nombre de PATCH réussis ne doit donc jamais remplacer le nombre de couples effectivement sélectionnés.

Les redémarrages ICE créent une autre génération. WHIP échange de nouveaux identifiants, mots de passe et candidats par PATCH tout en conservant les paramètres médias. Des ETags forts empêchent qu’une réponse retardée soit appliquée à la mauvaise génération. Les codes 428 et 412 rendent certains conflits visibles ; un 200 OK avec un nouvel ETag décrit toutefois un nouvel état ICE, pas la réussite future de ses vérifications.

Le chiffrement précède le programme

Lorsque le chemin est disponible, DTLS-SRTP utilise la poignée de main DTLS pour produire les clés de SRTP. Les exigences de transport WebRTC et de média RTP précisent l’environnement de transport sécurisé, de retours RTCP et de contrôle de congestion.

L’association cryptographique est indispensable et limitée. Elle montre que deux extrémités ont établi un contexte protégé sur le transport choisi. Elle ne montre pas qu’une caméra produit encore des images, que l’encodeur émet, que le codec est exploitable, que les séquences progressent, que le son accompagne la vidéo ou que les paquets atteignent le prochain système.

Le reçu média doit donc avoir une durée. Côté émetteur : paquets, octets, horodatages, SSRC et correspondance entre piste, MID ou RID. Côté entrée : premier et dernier paquets, progression de séquence, pertes, gigue, débit et retours RTCP dans une fenêtre déclarée. Les exigences de contrôle de congestion rappellent qu’un flux temps réel doit aussi réagir à la capacité partagée. Un débit instantané n’atteste pas une ingestion durable ; un premier paquet n’atteste pas un programme regardable.

Après l’entrée, les propriétaires changent

RFC 9725 parle d’ingérer dans un service de diffusion ou un CDN. Il ne normalise pas tout ce qui suit. L’entrée peut recevoir des paquets corrects alors qu’aucun décodeur n’avance, qu’un transcodeur est saturé, qu’un segment manque, qu’une origine refuse une version ou qu’un lecteur ne démarre jamais.

Le cadre CDNI distingue routage des requêtes, métadonnées, acquisition et distribution. L’interface de journalisation CDNI montre aussi qu’un journal de livraison passe par la génération, l’agrégation, le filtrage, la collecte et parfois la rectification. Une ligne de log n’est donc utile qu’avec son origine, sa période, sa couverture et ses transformations.

Une chaîne responsable change d’attestataire à chaque passage. L’équipe d’ingestion décrit le média observé à son récepteur. Le traitement décrit les entrées décodées et les rendus qui avancent. La distribution décrit les objets actuels, les décisions de routage et sa télémétrie bornée. Un lecteur de synthèse décrit le démarrage, les images ou le son rendus et les blocages depuis un point de vue précis. Aucun propriétaire ne doit promettre à la place du suivant.

La capacité commence avant le premier paquet

RFC 9725 exige la prise en charge de l’authentification HTTP et du jeton porteur. Il laisse à l’extérieur la forme, le sens et la distribution du jeton. Un jeton accepté donne donc un droit défini localement ; il ne prouve pas à lui seul le droit à un événement, une durée, une région, un débit ou un budget particuliers.

Ce droit peut consommer des ressources avant toute émission. Un client muni d’identifiants valides peut multiplier les POST sans établir ICE ou DTLS. Le RFC décrit ce risque d’épuisement et recommande limitation de débit et maîtrise des avalanches. Des PATCH répétés et des URL de session faciles à deviner élargissent encore la surface, notamment parce qu’un DELETE mal dirigé peut couper un direct.

La bonne jauge ne compte donc pas seulement les sessions. Elle mesure des cohortes et leur âge : créées sans ICE, connectées sans DTLS, sécurisées sans média, média instable, entrée prête sans distribution, distribution sans preuve lecteur, suppression acquittée sans baisse des ressources. L’écart indique l’endroit où se forme la dette de capacité.

Le point d’entrée peut rediriger le POST avec 307 pour conserver méthode et corps, ou répondre 503 avec Retry-After en surcharge. PATCH et DELETE ne sont pas tenus de suivre une redirection. Il faut donc conserver la chaîne de redirection, l’autorité finale de la session et l’identité du serveur média ; sinon le trafic change de propriétaire sans que la responsabilité le suive.

Ce que ferme vraiment DELETE

Le client envoie DELETE à l’URL reçue dans Location. Le RFC décrit alors la suppression de la ressource, la libération côté serveur média et la fin d’ICE et DTLS. La fraîcheur du consentement détecte séparément la disparition non gracieuse d’une extrémité sur un five-tuple. Ce consentement est technique : il n’exprime ni l’accord d’une personne ni la bonne réception d’une émission.

Un reçu de clôture doit relier la commande au bon identifiant opaque, à l’initiateur et à la règle d’autorisation ; confirmer l’arrêt des compteurs ; sceller la dernière période observable ; rendre les allocations TURN, le décodeur, le transcodeur, le paquetage et l’origine ; retirer les titres temporaires ; expliquer une expiration plutôt qu’un DELETE. Cette liste est une proposition d’exploitation, pas une extension normative de WHIP.

La doctrine de Running-Code Primacy de Lu Heng donne le bon ordre : la réalité décisive est le flux qui fonctionne pour l’utilisateur, pas l’apparence administrative d’une ressource. Son principe de spécification initiale minimale et de décisions futures localisées permet de garder WHIP mince sans rendre invisibles les responsabilités locales. Enfin, la réalité plutôt que le plaidoyer impose de conserver les contradictions : HTTP vert et média absent, entrée verte et lecteurs en échec, DELETE acquitté et capacité encore occupée.

WHIP standardise une frontière. Une production fiable commence lorsqu’elle refuse de faire passer cette frontière pour l’ensemble du direct.

Sources

Spécifications et registres : RFC 9725, notice RFC Editor, Datatracker, errata RFC 9725, RFC 8445, RFC 7675, RFC 5764, RFC 8834, RFC 8835, RFC 8836, RFC 8840, RFC 9429, RFC 9110, RFC 5789, RFC 8288, RFC 7336 et RFC 7937.

Cadre analytique attribué : Running-Code Primacy, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption et Why BTW.Media Exists — and Why Reality, Not Advocacy, Is the Product.