Résumé

  • La RFC 3485 permettait au premier message SigComp de référencer des fragments SIP/SDP connus parce que tous les équipements possédaient le même état statique, immuable et défini octet par octet.
  • Les listes lisibles des annexes expliquaient l’origine des chaînes, mais l’interopérabilité dépendait de la valeur binaire normative, de son identifiant, de sa longueur et des tranches exactes demandées.

Le premier message n’a aucune mémoire de conversation. Il ne peut pas désigner un en-tête déjà reçu, puisque rien n’a encore traversé le lien. La RFC 3485 résolut cette difficulté en fabriquant une mémoire antérieure à l’échange : un dictionnaire SIP/SDP déjà présent chez le compresseur et le décompresseur.

Cette mémoire commune exigeait une immobilité radicale. Toute implémentation SigComp destinée à SIP/SDP devait posséder le dictionnaire unique. Celui-ci ne suivrait pas les évolutions futures de SIP ou de SDP. Il était défini une fois pour toujours, afin d’éviter mise à jour, migration et découverte de version avant le premier envoi.

L’accord portait sur un état SigComp précis, non sur un nom d’édition. La section 3 fixait l’identifiant complet, la longueur 0x12E4, la longueur minimale d’accès de six octets et la totalité de la valeur. Les exemples pouvaient employer un identifiant partiel de six octets dans STATE-ACCESS grâce aux règles de résolution de SigComp. Le raccourci désignait néanmoins le même objet complet.

La hiérarchie documentaire devient alors une frontière de preuve. Les annexes A et B présentent les chaînes sources SIP et SDP, leurs priorités et les références qui justifiaient leur présence. Elles sont informatives. La représentation binaire de la section 3 est normative. Deux logiciels qui reproduisent les mêmes mots mais déplacent un seul octet ne partagent plus le même état.

La valeur concaténait deux régions. Le sous-ensemble de chaînes contenait toutes les expressions contributrices comme sous-chaînes. Le sous-ensemble de table associait à chaque entrée une longueur sur un octet et un décalage sur deux octets, augmenté de 1024 pour adresser directement un état chargé à l’adresse UDVM 1024. Certains algorithmes utilisaient les chaînes, les familles proches de LZ78 pouvaient aussi initialiser leurs jetons avec la table.

La composition mutualisait les fragments. Un préfixe commun pouvait n’occuper qu’une région, tandis que plusieurs entrées de table pointaient vers des suites distinctes. Les codes de réponse existaient seuls et avec leur phrase suggérée, car le code était normatif mais la phrase ne l’était pas. Une table logique de mots devenait ainsi un réseau d’adresses sur des octets partagés.

La forme exacte du message comptait. Les chaînes étaient sensibles à la casse. Les champs d’en-tête incluaient souvent le CRLF précédent, le deux-points et l’espace attendu. Un message SIP conforme pouvait employer un autre espacement légal et profiter moins du dictionnaire. Trouver le même concept ne suffisait pas ; il fallait retrouver la même séquence binaire.

Les priorités de un à cinq représentaient une estimation de fréquence. Un petit numéro signifiait une occurrence attendue plus fréquente et plaçait le matériau dans une zone avantageuse pour certains algorithmes. Ce classement n’était pas une mesure du trafic réel, encore moins une statistique durable sur les réseaux ultérieurs.

Ces rangs offraient aussi des coupes pour la mémoire limitée. La RFC donnait les décalages et longueurs permettant de charger seulement la priorité un, puis un à deux, un à trois ou un à quatre. Choisir une coupe ne créait pas une version allégée négociée ; l’implémentation accédait à une région du même état immuable.

Un audit doit donc conserver davantage que la mention « dictionnaire statique ». Il lui faut l’identifiant partiel, les opérandes de décalage et longueur, la région chaîne ou table et la coupe de priorité. Même ces éléments prouvent seulement un accès. Ils ne prouvent ni la réussite de la décompression ni la validité du message obtenu.

Les RFC voisines occupent d’autres étapes. La RFC 3320 confiait à l’application l’autorité de permettre la création d’un état persistant après décompression. La RFC 3321 traitait l’acquittement puis la disponibilité des états dynamiques. La RFC 3322 séparait un modèle de délai simplifié d’une observation de terrain. La RFC 3485 se situait avant tout cela : elle donnait au premier paquet une référence commune.

Les textes ultérieurs confirment cette filiation. La RFC 3486 indiquait comment SIP annonçait SigComp. Les RFC 4464 et 4465 expliquaient et testaient l’accès au dictionnaire. La RFC 4896 rappelait son découpage. La RFC 5049 imposait son support aux implémentations SIP/SigComp. La RFC 5112 créa un autre dictionnaire statique pour la présence au lieu de modifier silencieusement celui-ci.

La courte section de sécurité renvoyait à la RFC 3320 et n’identifiait pas de risque supplémentaire connu. Elle ne transformait pas la compression en authentification. Connaître l’identifiant ne prouvait ni l’identité de l’émetteur, ni l’autorisation, ni l’intégrité, ni la livraison, ni le succès d’une session.

Le document n’apportait pas non plus un taux de compression observé. Il expliquait pourquoi un état préalable devait améliorer le premier message, particulièrement sur des liens étroits, mais ne nommait aucun déploiement. Format, contenu, algorithme, coupe choisie et conditions de liaison restaient nécessaires à toute mesure.

La méthode des couches de réalité de Heng Lu impose un ordre. On vérifie d’abord le hachage et les paramètres de l’état complet. On conserve ensuite l’identifiant partiel et les opérandes STATE-ACCESS. On résout les octets visés, puis on les compare à la trace du décompresseur. Seulement après viennent analyse SIP/SDP, authentification, transport et résultat de session.

Le compromis historique de la RFC 3485 tient dans cette chronologie. Elle donna au premier message un passé qu’il n’avait jamais vécu. Ce passé ne resta commun que parce qu’il n’était pas un dictionnaire éditable : c’était un objet binaire scellé dont aucune deuxième édition ne pouvait surprendre l’autre extrémité.

Sources