Résumé

  • RFC 3545 répète les valeurs modifiées du contexte dans N+1 paquets afin que le décompresseur puisse se resynchroniser si la rafale de pertes reste dans la limite supposée pour le lien.
  • Son HDRCKSUM facultatif aide à vérifier un en-tête reconstruit lorsque la somme UDP IPv4 est nulle, mais il ne couvre pas l’identification IPv4 ; au-delà de N pertes, mieux vaut invalider le contexte et en redemander l’état.

Le contrôle avait un angle mort. RFC 3545 permet à l’émetteur de remplacer une somme UDP IPv4 nulle par une somme de contrôle d’en-tête de 16 bits. Le décompresseur peut ainsi vérifier une reconstruction. Mais l’identification IPv4 ne figure pas parmi les champs couverts. Dans un lien sans perte notable, cette omission peut rester discrète au sein d’un dispositif plus large. Après trop de pertes consécutives, elle change le sens d’une « récupération » fiable.

CRTP, défini dans RFC 2508, compresse les en-têtes IP, UDP et RTP en conservant un contexte partagé aux deux extrémités. Un en-tête complet établit cet état ; les paquets suivants peuvent transporter des modifications ou des différentiels. Si un paquet qui porte une mise à jour disparaît, le compresseur avance tandis que le décompresseur reste en arrière. Le décalage peut n’apparaître qu’à l’arrivée du paquet compressé suivant. Sur un lien à long délai, demander une réparation coûte un aller-retour, pendant lequel plusieurs paquets peuvent être écartés.

RFC 3545 répond par la répétition, avec une limite explicite. Il définit N selon le comportement de pertes du lien : la probabilité de perdre plus de N paquets consécutifs doit être faible. Répéter une mise à jour dans N+1 paquets consécutifs devrait en laisser parvenir au moins une si la rafale ne dépasse pas N. Le décompresseur peut appliquer l’algorithme « twice » pour tenir compte d’un intervalle borné, puis vérifier le résultat avec la somme UDP ou, le cas échéant, HDRCKSUM. Le protocole rend la récupération plus tolérante ; il ne promet pas que toute rafale respecte le modèle.

Le numéro de séquence de liaison ne fait que quatre bits et boucle tous les 16 paquets. Un écart observé ne permet donc pas toujours de distinguer de nombreuses pertes d’un réordonnancement où un paquet récent arrive avant un paquet antérieur. Si une interprétation plausible correspond à moins de N+1 pertes, le décompresseur peut tenter la reconstruction correspondante et la vérifier. Si la lecture plausible dépasse N, IPv4 impose une limite plus nette : ne pas continuer à deviner avec « twice », invalider le contexte et envoyer CONTEXT_STATE pour que le compresseur restaure l’état partagé.

C’est là que la couverture de la somme compte. HDRCKSUM est disponible lorsque la somme UDP IPv4 d’origine est nulle ; il est inséré pour le contrôle puis retiré par le décompresseur. Cette option ne sert pas en IPv6, où une somme UDP nulle est interdite. Mais le contrôle d’en-tête ne valide toujours pas l’identification IPv4. Après plus de N pertes, un contrôle réussi ne comble pas ce manque : RFC 3545 demande plutôt d’abandonner le contexte incertain. IPv6, qui ne possède pas ce champ d’identification, suit une règle différente.

La rafale de mises à jour a aussi son propre garde-fou. Si un champ de contexte constant change pendant l’envoi des N+1 paquets FULL_HEADER, le compresseur lance une nouvelle rafale et change le numéro de génération. Sans cela, le décompresseur pourrait confondre deux rafales qui se chevauchent avec une tolérance à davantage de pertes et manquer une désynchronisation. Les réponses CONTEXT_STATE devraient également être répétées. Ce sont des mécanismes du protocole, pas la preuve qu’un appareil précis les a activés ou qu’une application RTP a lu le contenu.

La distinction historique est modeste mais opérationnellement importante : une somme ne prouve que les champs qu’elle couvre, une reconstruction bornée n’est pas une livraison, et une réparation de contexte n’est pas un accusé de réception du média. Un contrôle local valide peut coexister avec une identification IPv4 non vérifiée. Lorsque les pertes dépassent la limite indiquée, invalider n’est pas renoncer à récupérer ; c’est refuser de transformer une séquence ambiguë en certitude artificielle.

Sources