Résumé

  • RFC 3388 donnait une identité locale aux lignes média de SDP et permettait de leur attacher une relation exécutable, mais refusait tout groupement dès que l’espace des identités devenait incomplet.
  • Ce refus préservait les descriptions média ordinaires tout en empêchant une supposition partielle de synchroniser, sélectionner ou recopier le mauvais flux.

Un appel propose quatre lignes m=. Trois portent une valeur mid; la quatrième décrit pourtant une adresse, un port et un format parfaitement utilisables. Le groupe ne cite que deux lignes nommées. Il serait tentant d’exécuter cette relation et d’ignorer l’élément sans nom.

RFC 3388 interdisait ce raccourci. Dès qu’une description employait group, toutes ses lignes média devaient avoir un mid, même celles qui n’appartenaient à aucun groupe. Une seule omission imposait de ne réaliser aucun groupement. Le document de base restait exploitable ; seule la couche relationnelle perdait son autorité.

Publié en décembre 2002 sur la Standards Track, RFC 3388 répondait à une limite du Session Description Protocol. SDP savait énumérer plusieurs médias, mais ne disait pas comment ils se rapportaient. Une application pouvait recevoir de l’audio, de la vidéo et un second audio sans savoir lesquels devaient être joués ensemble ni quelles destinations formaient une seule instance logique.

L’extension ajoutait une clé et une relation. L’attribut média a=mid attribuait un jeton unique à chaque ligne. L’attribut de session a=group réunissait ces jetons sous une sémantique enregistrée. Le texte initial définissait LS, pour la synchronisation labiale, et FID, pour l’identification d’un flux.

Ces relations déclenchaient des actes. Avec LS, l’application devait reconstituer le rapport temporel et synchroniser la lecture. RTP pouvait s’appuyer sur RTCP pour rapprocher plusieurs horloges ; d’autres transports devaient disposer d’un autre mécanisme. L’étiquette décrivait l’obligation, pas la précision obtenue devant l’utilisateur.

FID allait plus loin dans l’espace des destinations. Plusieurs lignes et sessions RTP pouvaient constituer un même flux média. Un terminal cellulaire pouvait exposer des ports distincts pour différents codecs, ou envoyer les tonalités DTMF vers un serveur différent de celui qui recevait la voix. Si plusieurs membres acceptaient le codec courant, l’émetteur devait produire plusieurs copies.

Une association incorrecte n’était donc pas seulement une erreur de classement. Elle pouvait déplacer ou dupliquer le média. La section sécurité prévenait qu’un intervenant capable de modifier la description et la relation FID pouvait forcer l’envoi d’une copie vers une destination arbitraire. L’intégrité du signalement protégeait l’autorité du groupement déclaré.

Le RFC imposait alors des contrôles simples. Chaque mid devait être unique. Une ligne de groupe qui citait un nom absent était entièrement ignorée. Une ligne média pouvait appartenir à plusieurs groupes de sémantiques différentes, mais la version de 2002 interdisait plusieurs groupes de même sémantique. RFC 5888 a ensuite levé cette dernière restriction après retour d’implémentation, sans abandonner la nécessité de noms cohérents.

L’offre et la réponse SIP révélaient un second piège. RFC 3264 associait toujours la première ligne média de l’offre à la première de la réponse, puis les suivantes par leur position. mid ne remplaçait pas cette règle. Si la réponse échangeait les noms de deux positions, l’application devait ignorer toutes les lignes mid et group.

Le texte ne tentait pas de sauver les correspondances « évidentes ». Une relation bien formée posée sur une identité contradictoire restait dangereuse. Le nom enrichissait la ligne négociée ; il ne pouvait pas réécrire silencieusement son identité ordinale.

L’acceptation produisait un autre reçu. Le répondant qui comprenait la sémantique renvoyait les mêmes membres ou un sous-ensemble. Une ligne refusée par un port zéro devait disparaître du groupe. Le groupe effectif était celui de la réponse, pas l’intention initiale de l’offrant.

Le répondant ne pouvait pas inventer un nouveau groupement dans sa réponse. Avec seulement deux messages SDP, il ne recevrait aucune confirmation de l’offrant. Il devait devenir offrant lors d’un échange ultérieur. La règle attribuait l’initiative au message qui pouvait obtenir un assentiment, non à l’acteur réputé le plus fiable.

La compatibilité ancienne conservait une incertitude honnête. Aucun en-tête SIP Require n’était défini. Un pair ignorant les attributs les omettait ou les ignorait. Il pouvait traiter les lignes FID comme des flux séparés, agir comme mélangeur, refuser la session ou provoquer une nouvelle tentative plus simple. Un échange SIP réussi ne prouvait donc pas l’exécution du groupe.

La primauté du code en fonctionnement de Lu Heng rend cette prudence générale. La règle commune doit pouvoir être vérifiée localement : toutes les lignes ont un nom unique, les noms restent stables à travers les positions négociées, la réponse sélectionne positivement les membres. Lorsque ces prédicats échouent, la relation perd son mandat. L’implémentation n’a pas à détruire les données de base ; elle doit cesser de prétendre connaître les associations.

RFC 5888 a remplacé RFC 3388 et corrigé certaines limites. L’idée historique demeure : une liste de descriptions valides ne suffit pas pour exécuter une relation supposée. Il manquait une étiquette ; les médias pouvaient rester, mais le groupement devait attendre.

Sources