Résumé

  • RFC 3524 a ajouté la sémantique SRF à SDP afin que plusieurs lignes média demandent un unique flux de réservation.
  • Le groupe exprimait le plan. L’admission, l’autorisation, l’installation des classificateurs, la survie de l’état et le rendu des médias restaient des preuves distinctes.

La ligne a=group:SRF 1 2 paraît presque accomplir l’opération. Les valeurs mid nomment deux descriptions, par exemple l’audio et la vidéo, puis SRF annonce qu’elles devraient partager un Single Reservation Flow. Le destinataire n’a plus à deviner le découpage souhaité.

Mais RFC 3524 commence justement par séparer les médias des flux auxquels les ressources sont attribuées. Une session peut réunir tous ses médias dans une réservation, en créer une par média, ou mélanger les deux modèles. SRF choisit une relation. Il ne fournit ni débit, ni route, ni ordonnanceur.

Le texte normatif dit que les lignes du groupe SHOULD être associées au même flux et que les lignes extérieures SHOULD NOT y être introduites. Même une seule ligne peut former un groupe. Il s’agit donc d’une consigne adressée à l’implémentation qui préparera la réservation, pas d’un constat sur l’état du réseau.

Le cadre de groupement rend les références vérifiables : chaque mid doit être unique dans la description, et un identifiant absent ne devient pas réel parce qu’il figure dans group. RFC 5888 a ensuite conservé cette architecture. SDP demeure extensible ; un récepteur qui ne comprend pas un attribut l’ignore. Une syntaxe valide peut ainsi rester sans effet.

La sémantique était surtout utile lorsque le correspondant distant devait participer. Si l’auteur du SDP pouvait attribuer lui-même les deux directions, il pouvait choisir le découpage sans SRF. Sans la ligne de groupe, le destinataire de l’exemple restait libre d’établir deux sessions RSVP au lieu d’une.

SIP transportait le SDP et RSVP réalisait la réservation dans l’exemple, mais le RFC autorisait d’autres mécanismes. La couche descriptive ne possédait donc pas l’outil d’exécution. Elle lui transmettait une intention portable.

RSVP montre le travail manquant. Un Resv porte un flowspec décrivant la QoS désirée et un filter spec qui désigne les paquets. Chaque nœud vérifie ensuite les ressources par l’admission et les droits par le contrôle de politique. Si l’un échoue, l’état demandé n’est pas installé. En cas de succès, le classificateur et l’ordonnanceur peuvent enfin être configurés.

Cet état reste souple : Path et Resv doivent le rafraîchir. Un changement de route crée un nouvel état tandis que l’ancien expire. Le groupe SDP peut rester intact pendant que la réalité réservée disparaît.

RFC 2205 va plus loin : recevoir ResvConf ne donne aucune garantie. Une confirmation peut précéder une erreur lorsque d’autres demandes ou les règles de fusion modifient le résultat. Une déclaration SDP antérieure ne peut donc pas servir de reçu de service.

RFC 3312 distingue d’ailleurs le statut QoS courant du statut désiré. Cette dualité existe précisément parce qu’énoncer la cible ne la rend pas présente. SRF répondait à « quels médias partageront la demande ? », pas à « la réservation existe-t-elle dans chaque sens ? ».

La sécurité révèle l’enjeu. Un attaquant ajoutant des lignes SRF pouvait provoquer trop ou trop peu de flux de réservation, consommer les ressources du terminal ou dégrader la QoS. L’intégrité du SDP était fortement recommandée, avec S/MIME dans SIP.

Cette intégrité authentifie l’instruction. Elle ne crée pas de capacité, n’impose pas une décision de politique, ne maintient pas l’état RSVP et ne prouve aucun son entendu. Le registre IANA accomplit une tâche aussi précise : stabiliser le jeton commun, pas observer son adoption.

La leçon historique est une discipline de preuves. Il faut conserver séparément le SDP valide, les mid résolus, l’intention authentifiée, le découpage choisi, la requête de réservation, l’admission de chaque nœud, l’état installé, son rafraîchissement, le traitement des paquets et le média rendu. SRF coordonnait le premier tiers de cette chaîne ; il n’a jamais prétendu posséder les ressources des autres.

Sources