Résumé

  • SDP possède deux versions distinctes : v=0 désigne le format du protocole, tandis que sess-version, dans o=, progresse quand une description de session identifiée est modifiée.
  • Le numéro n’a de sens qu’avec le tuple d’origine. Le comparer entre deux origines ou lire sa forme d’horodatage comme une heure certifiée efface la preuve de filiation.

Le tri avait raison, la décision avait tort

Lors d’une bascule, un contrôleur de secours peut produire une description parfaitement valide avec un nombre supérieur à celui du contrôleur principal. Il peut aussi commencer plus bas. Rien d’anormal : chaque outil choisit sa méthode d’allocation dans sa propre lignée. Le nombre n’est pas un compteur mondial partagé par tous les émetteurs de SDP.

Une console qui ne conserve que session_id et max(version) transforme cette pluralité en chronologie fictive. Trois dates doivent rester distinctes : le moment déclaré par le créateur, l’heure de réception et la date d’autorisation d’une succession. Même lorsqu’elles coïncident, elles ne se prouvent pas mutuellement.

Le zéro de v= ne compte pas les révisions

RFC 8866 impose v=0 au début de la description. Ce champ indique la version du Session Description Protocol lui-même ; le texte précise qu’il n’existe pas de version mineure. Ajouter une caméra, remplacer un codec ou changer une adresse média ne crée donc pas v=1.

La ligne suivante, o=, contient six valeurs : nom d’utilisateur, identifiant de session, version de session, type de réseau, type d’adresse et adresse unicast. sess-version est le numéro de la description. L’outil créateur doit l’augmenter lorsqu’il modifie cette description ; l’emploi d’un horodatage est recommandé.

Confondre les deux champs produit des erreurs symétriques. Modifier v= annonce un format de protocole inexistant. Modifier les octets sans augmenter sess-version présente deux états comme une même révision. Un inventaire sérieux garde les deux champs, mais ne leur prête jamais la même portée.

L’identité tient dans cinq valeurs

Le RFC actuel définit l’identifiant mondialement unique de la session comme le tuple formé par le nom d’utilisateur, l’identifiant de session, le type de réseau, le type d’adresse et l’adresse unicast. L’identifiant numérique de session, pris seul, n’est donc pas une clé universelle. Un nom d’utilisateur familier n’authentifie pas une personne. Une nouvelle adresse n’hérite pas spontanément de l’ancienne.

Le premier RFC SDP rendait l’intention très concrète. En 1998, Handley et Van Jacobson expliquaient que la version permettait aux annonces mandataires de reconnaître la plus récente parmi plusieurs annonces de la même session. La restriction « de la même session » est essentielle. Les révisions ne deviennent comparables qu’après avoir établi qu’elles appartiennent à cette identité.

Lorsqu’une bascule change volontairement le tuple, l’exploitation doit créer un pont séparé : ancienne et nouvelle origine, autorité qui approuve, instant d’effet, état transmis et possibilité de retour. Choisir le plus grand entier ne documente aucune de ces décisions.

En offre-réponse, la même version exige le même texte

RFC 3264 ajoute une discipline précise. Une offre qui modifie une session garde la ligne o= précédente à l’identique, sauf la version qui augmente de un. Si cette version n’augmente pas, le SDP doit être identique à celui qui portait déjà ce numéro. Une offre répétée sans changement est un no-op, mais le destinataire doit tout de même produire une réponse valable.

Cette règle permet de repérer un conflit sans spéculation. Même origine, même version et contenus différents ne décrivent pas une simple retransmission. Il faut conserver les deux corps et leurs empreintes, déclarer la lignée incohérente et appliquer la politique d’erreur locale. Remplacer silencieusement l’ancien document par le dernier reçu détruirait précisément la preuve utile.

Une version accrue reste une déclaration du créateur. Elle ne démontre ni acceptation de l’offre, ni circulation RTP, ni qualité audible. La création, l’acceptation, la livraison des paquets et le résultat utilisateur ont chacun leur reçu.

Un nombre qui ressemble à une date n’est pas une horloge de confiance

RFC 8866 recommande un nombre de secondes depuis le 1er janvier 1900 UTC pour allouer l’identifiant de session, puis recommande aussi un horodatage pour la version. Ce choix aide un créateur à produire des nombres distinctifs et croissants. Il ne certifie pas la synchronisation de son horloge, l’heure d’arrivée ou son mandat.

La section sécurité du même RFC fixe une autre condition : une description ne peut être tenue pour fiable que si elle a été obtenue d’une source connue et digne de confiance par un transport authentifié et protégé en intégrité. L’origine déclarée appartient donc au contenu ; le principal authentifié et le résultat d’intégrité appartiennent au canal. Les deux doivent être joints avant décision.

SAP possède son propre signal de changement

RFC 2974 illustre la séparation des couches. SAP emploie une source d’origine et un hash d’identifiant de message. Modifier ce hash invite le récepteur à analyser un contenu d’annonce modifié. Le SDP transporté conserve néanmoins son propre champ d’origine et sa version de session. Le hash de distribution n’est pas la généalogie du document.

SDP est d’ailleurs défini comme un format de description, non comme un protocole de transport, et il n’est pas chargé à lui seul de négocier contenus ou encodages. SIP offre-réponse peut s’en servir pour une négociation limitée ; SAP, HTTP ou le courrier peuvent le transporter. Réception, identité, négociation et résultat média doivent pouvoir se rejoindre sans devenir un seul état.

Situer Mark Handley sans effacer le collectif

RFC 2327 est signé par Mark Handley et Van Jacobson. RFC 4566 réunit Handley, Jacobson et Colin Perkins. RFC 8866, aujourd’hui en vigueur, nomme Ali Begen, Paul Kyzivat, Perkins et Handley. SDP est une œuvre collective transmise entre générations de texte ; l’attribuer à un inventeur solitaire trahirait cette histoire.

La Royal Society présente Handley comme professeur de systèmes en réseau à UCL, auteur de nombreux standards de l’Internet et ancien membre de l’Internet Architecture Board. ACM SIGCOMM lui a décerné son prix 2019 pour ses contributions au multimédia Internet, au multicast, au contrôle de congestion, aux réseaux multipath et à la standardisation associée.

La portée exacte de la preuve

Avec le tuple complet, les octets exacts et une acquisition de confiance, sess-version permet d’affirmer qu’un créateur a marqué une description comme révision ultérieure de la même session. Dans le cadre de RFC 3264, il révèle aussi un contenu différent sous un numéro inchangé ou une modification dont la version n’a pas progressé.

Il ne prouve pas qu’une nouvelle origine est le successeur autorisé, que l’horloge est juste, que l’offre a été acceptée, que les paquets ont suivi l’adresse décrite ou que le service a réussi. Ces conclusions exigent respectivement un mandat de migration, une authentification de transport, un échange offre-réponse, des observations réseau et un test de résultat.

Sources