Résumé

  • La RFC 3322 obtenait 4 131 ms pour une séquence SIP/SDP en supposant un lien à 9,6 kbit/s et un aller-retour de 140 ms, tout en signalant les limites de cette approximation.
  • Le calcul motivait des exigences de transparence, de généralité et de robustesse ; il ne mesurait ni un déploiement SigComp ni un gain réellement fourni aux utilisateurs.

L’honnêteté contenue dans un adjectif

Une valeur à la milliseconde près inspire facilement une confiance excessive. La RFC 3322 additionne pourtant des résultats produits par une formule, non par un chronomètre. Pour chaque message, elle divise la taille en bits par 9 600 bits par seconde, puis ajoute 70 ms, soit la moitié d’un RTT fixé à 140 ms. L’échange SIP/SDP illustré aboutit ainsi à 4 131 ms. Des opérations RSVP, de gestion de session et d’établissement du support radio ajouteraient encore des délais approximatifs.

Le texte prévient que l’approximation WCDMA est « rather crude ». Les retransmissions éventuellement provoquées par les erreurs ne sont pas comptées. Un seul lien cellulaire est supposé. Le réseau IP intermédiaire est réduit à une composante simplifiée. Les tailles de messages sont typiques, pas garanties. Même la comparaison voisine entre environ 3,6 secondes pour un appel GSM et 7,9 secondes pour un cas SIP reste une donnée de motivation issue d’un contexte déterminé.

Le document ne s’affaiblit pas en reconnaissant ces limites. Il rend au contraire son raisonnement vérifiable. On peut discuter le débit, le RTT ou la séquence, remplacer une hypothèse et recalculer. Ce que l’on ne peut pas faire honnêtement, c’est transformer le total en temps observé chez tous les utilisateurs de 2003.

Le problème venait avant le mécanisme

Publié en janvier 2003 dans la catégorie Informational, le texte expose les besoins auxquels un schéma de compression devait répondre. Les messages SIP, SDP et RTSP étaient généreux en texte. Sur une interface radio où la capacité par utilisateur restait limitée, chaque octet pouvait prolonger une succession de requêtes et de réponses. La correction d’erreurs, l’entrelacement et les retransmissions réduisaient les pertes au prix d’un délai supplémentaire.

Plusieurs solutions sont examinées. Augmenter le débit pouvait diminuer le nombre d’utilisateurs servis par cellule. Réduire le RTT demandait des changements profonds. Modifier l’enchaînement requête-réponse touchait les protocoles applicatifs. Supprimer des champs économisait des octets en détruisant la transparence et en portant atteinte au principe de bout en bout. La compression paraissait préférable parce qu’elle pouvait modifier la représentation sans modifier le message.

Cette conclusion restait un choix de conception. Elle ne prouvait pas que SigComp était négocié, installé ou performant. La publication d’un besoin ne remplace ni le code en fonctionnement ni l’observation d’un service.

L’identité bit à bit comme frontière de pouvoir

La première exigence générale impose qu’après compression et décompression, le résultat soit identique bit à bit à l’original. Le mécanisme commun reçoit donc une fonction étroite : transporter plus efficacement, sans réécrire le sens de SIP ou de SDP. Il doit coexister avec ROHC, accepter des terminaux aux capacités différentes, fonctionner sur TCP comme sur UDP et ne pas dépendre d’un motif fixe de conversation.

Il doit aussi fonctionner sur une route unidirectionnelle, même si l’absence de retour peut dégrader l’efficacité. La négociation de l’usage de la compression est laissée hors du schéma et confiée au protocole qui produit les messages. Cette séparation est essentielle pour l’interprétation des preuves : la présence d’une bibliothèque compatible SigComp ne démontre pas qu’une session l’a utilisée.

Les exigences de performance restent elles aussi prospectives. La compression ne doit pas ajouter un délai perceptible ; mettre plusieurs messages en attente pour obtenir un meilleur ratio contredirait l’objectif. Les erreurs résiduelles doivent rarement produire une décompression incorrecte. Une perte ne doit pas condamner tous les messages suivants. Un désordre modéré doit rester récupérable.

RFC 3320, le dictionnaire SIP/SDP de RFC 3485, l’usage SIP de RFC 3486, puis les guides RFC 4077 et RFC 5049 constituent une filiation technique. Cette filiation indique que les ingénieurs ont poursuivi le travail. Elle ne fournit pas, à elle seule, un taux d’adoption, un résultat d’interopérabilité ou une réduction de délai.

L’enseignement historique de la RFC 3322 est donc une discipline de provenance. Une hypothèse peut produire une comparaison utile. Une exigence peut exclure une mauvaise conception. Ni l’une ni l’autre ne devient une mesure du monde sans une nouvelle chaîne de preuves.

Sources