Résumé

  • L’entrelacement de RFC 3558 répartit les trames EVRC ou SMV voisines entre plusieurs paquets RTP. La perte d’un paquet produit alors des effacements séparés, souvent moins destructeurs qu’une longue lacune continue.
  • maxinterleave est un plafond déclaré par le récepteur. Seules des traces d’allocation, d’occupation, de délai par trame et d’ingestion par le décodeur prouvent que la capacité annoncée a existé au bon moment.

La valeur cinq est séduisante parce qu’elle paraît concrète. RFC 3558, publié en juillet 2003 comme Proposed Standard, donne cette valeur par défaut lorsque maxinterleave est absent. Un émetteur d’une session point à point ne doit pas dépasser le plafond communiqué. On pourrait donc croire la ressource connue.

Ce qui est connu, pourtant, est une frontière protocolaire. La mémoire physique, la profondeur de la file, la politique de gigue et l’échéance de lecture demeurent locales. La norme permet au récepteur de calculer un maximum prévisible ; elle ne lui remet pas un certificat attestant que ce maximum a été alloué ou qu’aucune autre charge ne l’a consommé.

Un groupe tisse deux chronologies

EVRC et SMV produisent une trame toutes les 20 millisecondes. Le format Interleaved/Bundled place dans son premier octet LLL, longueur d’entrelacement sur trois bits, et NNN, indice du paquet dans le groupe sur trois bits. Le second octet contient une demande de mode et un compteur de trames sur cinq bits. Ce compteur code le nombre moins un : un paquet peut donc déclarer de une à 32 trames.

Lorsque LLL vaut zéro, les trames sont simplement groupées. Lorsqu’il est positif, NNN doit lui être inférieur ou égal et les trames successives dans le temps sont distribuées entre LLL plus un paquets. Avec B trames par paquet et une longueur L, le groupe couvre B multiplié par L plus un positions temporelles.

Les paquets partent par NNN croissant afin de réduire l’attente. Les trames qu’ils contiennent ne sont toutefois pas contiguës dans la parole reconstruite. Le récepteur observe donc l’ordre d’arrivée du réseau et doit fabriquer l’ordre temporel du décodeur. Une seule ligne de journal ne suffit pas à représenter les deux.

Il faut conserver l’identité du groupe, la séquence RTP, NNN, chaque position de trame, son heure d’arrivée et son échéance. Sans cette jointure, une occupation mémoire élevée ressemble à de la simple gigue, tandis qu’un effacement tardif paraît être une perte réseau qui n’a peut-être jamais eu lieu.

La perte est dispersée, pas annulée

Un paquet manquant dans un groupe entrelacé peut laisser plusieurs trous non consécutifs. La parole reçue entre ces trous donne au décodeur davantage de contexte qu’une disparition continue de même durée. C’est la raison fonctionnelle de l’entrelacement.

La norme prévoit une trame d’effacement de zéro bit pour remplacer une trame perdue ou endommagée. Elle fait avancer l’état du décodeur d’un intervalle de 20 millisecondes. Elle ne recrée aucun phonème et ne prouve aucune intelligibilité. Une trame nulle, également de zéro bit, exprime une autre condition et n’est normalement pas transmise ; confondre les deux efface la cause de l’absence.

Le compte rendu prudent dit quelles positions ont été reçues, lesquelles sont devenues des effacements et lesquelles ont été utilisées après une arrivée tardive. « Décodage continu » ne signifie pas « parole intacte ». Pour un numéro, un nom propre ou un ordre bref, un trou isolé peut rester décisif.

Un plafond négocié a une heure d’effet

Le récepteur peut diminuer maxinterleave au cours d’une session. Cette possibilité crée une question que la valeur seule ne résout pas : à quel groupe la nouvelle limite s’applique-t-elle ? Un émetteur conforme à l’ancienne offre et un récepteur déjà passé à la nouvelle peuvent chacun posséder une trace localement cohérente et néanmoins diverger.

Le reçu minimal associe la proposition, la réponse, l’instant d’effet, la version de configuration de l’émetteur, le premier groupe conforme et le dernier groupe accepté sous l’ancienne valeur. Le plafond observé dans SDP n’est pas l’état effectif du flux.

maxptime, dont la valeur par défaut est 200 millisecondes dans ce format, borne de son côté la durée média mise dans un paquet. Il agit sur le regroupement ; maxinterleave agit sur l’étalement. Aucun ne décrit seul la quantité de mémoire ou le délai de bout en bout. B, L, la gigue, le réordonnancement et l’ordonnanceur du décodeur complètent le calcul.

Le paquet tardif oblige à choisir

Un paquet peut manquer l’échéance de sa première trame et arriver à temps pour une position plus tardive du même groupe. Le jeter intégralement sacrifie de la parole encore utile. Attendre toutes ses positions retarde la conversation. En extraire seulement les trames encore valides exige des échéances par position et une interface de décodeur capable de les recevoir.

Cette décision n’est pas contenue dans le bit LLL. Elle appartient à la politique locale. L’équipe qui règle la gigue doit partager le résultat avec celle qui mesure l’expérience vocale, faute de quoi l’une peut annoncer un excellent taux de réception tandis que l’autre subit davantage d’effacements.

Une preuve exploitable précise : arrivée du paquet à T, première position expirée et remplacée, positions suivantes admises, occupation avant et après, version de politique, délai de lecture obtenu. La simple présence du paquet dans une capture est insuffisante.

Header-Free nomme un autre budget

Le format Header-Free transporte une seule trame sans table des matières ni en-tête d’entrelacement. Il renonce à la dispersion et au regroupement, en échange d’une faible attente de paquetisation et d’un traitement plus direct. Davantage d’en-têtes RTP, UDP et IP sont alors payés par seconde de parole.

Pour une conversation interactive, le délai peut être la ressource rare. RFC 3558 recommande LLL égal à zéro ou Header-Free lorsque l’interactivité prime ; des valeurs quatre ou cinq peuvent convenir lorsque la résistance à la perte compte davantage. Ce ne sont pas deux niveaux de qualité. Ce sont deux allocations différentes entre bande passante, mémoire, délai et concentration des pertes.

RFC 2508 et RFC 3095 rappellent que la compression d’en-têtes peut modifier ce calcul. Une capacité de compression annoncée n’atteste toutefois ni un contexte synchronisé ni les réparations qu’il a fallu effectuer sur le chemin réel.

La demande de mode ne ferme aucune boucle

Le champ Mode Request demande un mode d’encodage dans le sens inverse. En point à point, le correspondant est invité à l’honorer ; en multipoint, il devrait l’ignorer. La demande est répétée afin qu’une perte isolée ne la fasse pas disparaître.

Répéter n’est pas acquitter. Le journal doit séparer l’intention envoyée, les répétitions, la réception éventuelle, la décision de l’encodeur et la première trame produite sous le nouveau mode. Sinon, le tableau de bord transforme une demande tolérante aux pertes en preuve fictive de changement.

La même discipline vaut pour l’entrelacement : capacité, sélection et observation du flux sont trois faits distincts.

Les invalidités ne sont pas toutes des pertes réseau

La table des matières donne le type et la taille des trames. Une combinaison incohérente de LLL, NNN, compteur ou octets peut conduire le récepteur à rejeter le paquet et à fournir des effacements au décodeur. Pour celui-ci, le résultat ressemble à une perte. Pour la responsabilité opérationnelle, la différence est essentielle.

Séparer paquet jamais reçu, paquet tardif, charge invalide, type non pris en charge et éviction locale du tampon. Chacun appelle un propriétaire et un remède différent. Une métrique unique « paquets perdus » dissimule précisément la surface de contrôle.

RFC 4788 a ensuite étendu la famille avec EVRC-B, un format compact groupé, la transmission discontinue et des précisions d’enregistrement et d’offre-réponse. Cette mise à jour est un contexte ultérieur ; elle ne doit pas être attribuée sans preuve à une mise en œuvre de RFC 3558.

Limite des preuves

Cet Article ne désigne aucun opérateur, équipement, appel, utilisateur, incident, taux de perte, réservation mémoire ou résultat d’écoute. Les exemples expliquent un mécanisme normalisé, non un déploiement observé.

RFC 3550 et RFC 3551 encadrent RTP. RFC 3264 encadre l’offre-réponse ; RFC 2327 était le contexte SDP à la publication et RFC 8866 en constitue un contexte plus récent. RFC 2508 et RFC 3095 décrivent des solutions de compression. RFC 8174 précise le langage normatif. RFC 4788 est une mise à jour, pas un reçu d’exécution.

Les essais Running-Code Primacy et Minimum Initial Specification de Heng Lu sont des prismes éditoriaux déclarés. Ils motivent la séparation entre capacité déclarée et comportement exécuté, ainsi qu’une frontière commune limitée laissant les décisions futures aux acteurs locaux. Ils ne prouvent ni l’intention des auteurs de la RFC ni un résultat réseau.

La conclusion bornée est la suivante : l’entrelacement peut rendre les effacements non consécutifs, mais exige mémoire, reconstruction et arbitrage de délai. maxinterleave fixe ce que l’émetteur ne doit pas dépasser. Il ne prouve pas que le récepteur a payé la ressource nécessaire.

Sources