Résumé

  • La ligne o= de SDP réunit un tuple d’identité et un sess-version séparé : une nouvelle description peut continuer la même session.
  • SDP exige que la version augmente si la description change ; Offer/Answer impose, pour une offre modifiée, le même origin sauf une progression de un, et exige des octets identiques si la version est répétée.
  • Une révision plus récente aide à écarter un état périmé. Elle n’authentifie pas l’émetteur, n’accepte pas l’offre et ne prouve ni consentement ni circulation des médias.

Une continuité, deux questions

Les premières annonces multimédias devaient survivre à leurs propres modifications. Une conférence pouvait changer d’horaire ; un appel pouvait ajouter une vidéo ou déplacer son adresse de réception. Le destinataire devait reconnaître à la fois la session qui continuait et la description qui venait de changer.

Confondre les deux aurait produit deux erreurs opposées. Une identité renouvelée à chaque édition aurait cassé la lignée. Une identité immobile sans numéro de révision aurait permis à une vieille annonce de revenir comme si elle était actuelle.

SDP inscrivit les deux réponses dans une seule ligne :

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Le tuple formé par le nom d’utilisateur, l’identifiant de session, les types de réseau et d’adresse et l’adresse d’origine désigne la lignée. sess-version situe une description dans cette lignée. Il faut donc vérifier l’identité complète avant de comparer les révisions.

« Origin » ne voulait pas dire identité certifiée

Le vocabulaire est trompeur. username peut être le login de l’auteur, mais aussi un simple tiret. La norme actuelle autorise même un nom arbitraire et une adresse privée lorsque la confidentialité l’exige, à condition de préserver l’unicité du tuple.

La ligne d’origine est ainsi un espace de noms, pas une authentification. Son adresse n’est pas nécessairement la destination du média. Son nom n’est pas un justificatif. Deux descriptions qui réutilisent le même sess-id avec d’autres coordonnées d’origine ne deviennent pas automatiquement une seule session.

L’outil créateur choisit localement le numéro. Les spécifications recommandent une valeur inspirée d’un timestamp NTP pour réduire le risque de collision. Cette forme numérique ne certifie ni l’exactitude de l’horloge, ni l’instant de création, ni la propriété de l’adresse affichée.

La révision n’avait besoin d’aucun registre central

sess-version doit augmenter quand la description est modifiée. Un proxy ou un participant peut donc conserver le tuple, la version et l’empreinte du texte accepté, puis refuser qu’une copie plus ancienne remplace un état plus récent.

Cette décision reste locale. Aucun service mondial n’attribue les révisions et aucun serveur ne proclame une vérité universelle. Le destinataire possède juste assez d’éléments pour comparer les descriptions d’une même lignée.

La règle générale de SDP demande une augmentation, pas forcément un ajout de un. La recommandation d’utiliser un timestamp ne transforme pas le champ en heure civile. Et deux versions placées sous des tuples différents ne forment pas une séquence commune.

Offer/Answer resserra la règle

SDP décrivait d’abord des sessions. Le modèle Offer/Answer ajouta la procédure par laquelle deux agents construisent une vue commune. Il dépend d’un protocole supérieur, comme SIP, pour transporter les offres, maintenir le contexte, ordonner les messages et résoudre les offres simultanées.

Lorsqu’un agent modifie sa session, la nouvelle ligne o= doit reprendre exactement l’ancienne, sauf la version qui progresse de un. Les coordonnées stables disent que l’offre appartient à la même lignée ; le pas unique annonce la révision suivante de cet agent.

La règle inverse est tout aussi importante. Si la version ne change pas, le SDP doit être identique à celui déjà associé à cette version. Une offre inchangée peut être répétée et reçoit tout de même une réponse valide. Mais une version ancienne ne peut pas transporter honnêtement un nouveau corps.

Pour l’audit, une même paire (origin, version) accompagnée de deux corps différents constitue un conflit, non deux variantes équivalentes. L’ordre d’arrivée ne résout pas ce conflit.

Offer/Answer exige aussi que l’identifiant et la version tiennent dans un entier signé de 64 bits et que la version initiale reste sous 2^62 - 1, afin d’éviter le bouclage. Cette borne appartient à cette utilisation précise ; ce n’est pas une arithmétique circulaire commune à toutes les applications SDP.

La nouvelle révision restait une proposition

Un numéro plus élevé décrit l’état proposé par son auteur. Il ne force pas l’autre agent à l’adopter. La réponse peut retenir les flux compatibles, en refuser certains, ou le protocole porteur peut rejeter toute l’offre. En cas de rejet, l’état antérieur redevient la référence de la session.

La concurrence est également gérée ailleurs. Un agent ne doit pas lancer une autre offre tant qu’il attend une réponse ou doit répondre à son pair. Deux offres croisées créent un glare que le protocole supérieur doit résoudre. sess-version n’est ni un verrou distribué ni une élection où le plus grand entier gagne.

Une réponse valide ne prouve toujours pas que les paquets sont passés, que le codec fonctionne, que le pare-feu a ouvert le chemin, qu’une personne a consenti ou qu’un service commercial a été rendu. Elle atteste un accord descriptif, rien de plus.

La fraîcheur ne fabriquait pas la confiance

Un attaquant sait choisir un grand entier. Offer/Answer exige donc que le protocole de signalisation fournisse l’authentification de bout en bout et l’intégrité des offres et réponses. Le logiciel destinataire conserve en plus son pouvoir d’admission et de consentement.

Chaque preuve répond à une question différente : l’authentification nomme la source reconnue ; l’intégrité protège le transport ; le tuple déclare une lignée ; la version déclare une révision ; l’état Offer/Answer indique une proposition, une acceptation ou un rejet ; l’observation du média mesure l’effet réel.

L’apport durable de SDP n’est donc pas d’avoir inventé un nombre souverain. Il est d’avoir séparé la continuité du changement, afin que chaque acteur puisse juger localement sans attribuer au numéro un mandat qu’il ne possède pas.

Sources et limites de preuve

Le dossier normatif est formé par RFC 2327, RFC 4566, RFC 8866 et RFC 3264. Ces textes établissent la grammaire et la procédure Offer/Answer ; ils ne mesurent pas les implémentations actuelles, n’identifient pas un expéditeur réel et ne prouvent pas la livraison du média.