Brevet FR3082386A1 — publié le 20191213

Adaptation de débit d'une session de communication en voix sur IP La présente invention se rapporte au domaine des télécommunications et plus particulièrement au domaine des réseaux de communication par paquets. Dans ce type de réseaux, il est possible d'acheminer des flux de données associées à des services temps réel. Le protocole Internet, appelé IP pour "Internet Protocol", développé par l'IETF, pour "Internet Engineering Task Force", est mis en oeuvre sur les réseaux de communication par paquets aussi bien pour supporter des services non temps-réel tels que des services de transfert de données, de consultation de pages web, de messagerie électronique, que des services temps réels ou conversationnels, tels que la téléphonie sur I P, la vidéo téléphonie sur IP ou encore la diffusion vidéo sur I P. L'invention se rapporte plus particulièrement à une adaptation de débit de codage/décodage de signaux temps réels comme les signaux de voix ou de vidéo lors d'une session de communication temps-réel entre deux terminaux de communication. Cette adaptation de débit et les mécanismes qui s'en rapportent sont adaptés pour la transmission de signaux numériques tels que des signaux audiofréquences (parole, musique ou autres), cependant ils s'appliquent à d'autres signaux temps réels comme la vidéo. Un exemple de système de communication voix sur IP existant est décrit en référence à la figure 1. Cette figure décrit un système de communication bidirectionnelle de voix sur IP (Vol P) avec deux terminaux de téléphonie (100 et 150) reliés par un réseau par paquets de type IP (125). Le "plan de signalisation" n'est pas représenté sur cette figure mais les solutions possibles pour établir et gérer des appels peuvent reposer sur différents protocoles connus comme par exemple: - SI P/SDP (pour « Session Initiation Protocol/Session Description Protocol » en anglais) selon les spécifications I ETF RFC 3261 et RFC 4566 - comme dans les services multimédia sur I MS (pour « IP Multimedia SubSystem » en anglais). Pour faciliter les échanges de signalisation sur les capacités média et les offres/réponses associées, il est également possible d'utiliser « SDPcapneg » selon la spécification I ETF RFC 5939. - JSEP (pour « JavaScript Session Establishment Protocol » en anglais) qui utilise la syntaxe de SDP pour définir des descriptions de session WebRTC (avec un échange par WebSocket ou un autre moyen). La figure 1 est une vue simplifiée du "plan média" et de la chaîne audio utilisée quand l'appel est établi entre 2 terminaux (100 et 150) reliés par un réseau IP (125). On se limite ici au cas d'un signal audio mono, le signal acoustique ambiant est par exemple capté par un microphone (101 et 151) de chaque côté de la communication. On remarquera que le cas d'un signal d'entrée / sortie mono peut facilement se généraliser à un cas multicanal où 2 plusieurs micros et/ou haut-parleurs sont utilisés. De même, les microphones et haut-parleurs pourront être remplacés par des caméras et écrans dans le cas de signaux vidéo. Le signal distant est restitué sur un haut-parleur (102 et 152). Les signaux audio captés et restitués subissent en général différents pré-/post-traitements en émission et en 5 réception (103 et 153) comme par exemple: - En émission : conversion analogique/numérique, contrôle de gain, réduction de bruit, annulation d'écho, etc. - En réception : conversion numérique/analogique, contrôle de gain, etc. Le signal audio prétraité en émission est codé par trames successives - avec 10 typiquement une longueur de trame de 20 ms - cette longueur est en général comprise entre 10 à 60 ms pour les applications conversationnelles. Les trames codées sont mises sous forme de paquets IP (104 et 154). Les paquets sont typiquement transportés par le protocole RTP (pour "Real Time Protocol" en anglais), décrit dans la spécification I ETF RFC 3550, ce protocole se situe au-dessus des protocoles de transport I P/UDP (pour "User Datagram 15 Protocol" en anglais). On notera que le protocole UDP peut être remplacé par un autre protocole de transport, par exemple par TCP (pour « Transmission Control Protocol » en anglais) pour notamment faciliter la traversée de réseaux avec traduction d'adresse réseau NAT (pour « Network Address Translation « en anglais), proxys ou pare-feux. En réception (105 et 155), les paquets sont reçus dans un buffer de gigue visant à 20 compenser les variations des temps de réception, et le signal est décodé (en compensant les pertes éventuelles de trames), enfin le signal reconstruit est post-traité (103 et 153) et restitué. La communication est ici supposée bidirectionnelle et le système de communication forme ainsi un système bouclé avec rétroaction ("feedback"). Le « feedback » peut être 25 transporté de deux façons: - "Hors bande" (c'est-à-dire contenu dans des paquets qui constituent un flux supplémentaire par rapport au flux média RTP). Typiquement, le protocole RTCP (pour Real-Time Control Protocol) est utilisé comme canal de « feedback ». RTCP permet des transmissions de paquets de contrôle dans des paquets séparés du 30 flux RTP. On rappelle que les paquets RTCP peuvent avoir une taille conséquente et donc résulter en un débit supplémentaire non négligeable; de plus, la perte possible de paquets peut être problématique, car si RTCP est utilisé à des fins d'adaptation, le feedback transporté peut être perdu. L'envoi des paquets par le protocole RTCP peut être discontinu et non répétitif, ce qui peut rendre 35 l'adaptation moins réactive et dépendante des conditions réseaux (retard de transmission, pertes de paquets, etc.). En général, l'application doit supporter et utiliser le profil RTPAVPF (pour « Audio Video Profile with Feedback » en anglais) pour que RTCP soit réellement utilisable pour l'adaptation média. De plus, les 3 applications de type voix sur IMS n'autorisent pour l'instant que le profil AVP (pour « Audio Video Profile » en anglais) qui restreint l'utilisation de RTCP; l'adaptation média dans les terminaux - si elle est utilisée - peut s'appuyer sur le "monitoring" des conditions réseaux, dont les informations contenues dans les 5 rapports RTCP RR (Receiver Report) sur la perte de paquets ou la gigue qui sont envoyés en moyenne tous les 5 secondes. - "Dans la bande" (c'est à dire dans le flux média RTP). Ce type de feedback peut être considéré comme plus robuste que RTCP car il est possible de répéter une 10 même requête dans plusieurs paquets successifs. A noter que dans certaines situations (appel en attente, écoute de messagerie, ...), il est possible que les paquets RTP soient envoyés dans un seul sens, cependant on suppose ici un envoi de paquets RTP bidirectionnel pour que la rétroaction fonctionne. Un exemple de signalisation dans la bande est l'utilisation d'un champ CMR (pour 15 « Codec Mode Request » en anglais) utilisé pour transmettre une requête d'adaptation de codage. En général, plusieurs types de dégradation peuvent potentiellement affecter la qualité de la voix sur I P: bande passante variable / congestion du réseau perte, dé-séquencement, répétition de paquets retard des paquets (de transmission, de mise en file d'attente, de traitement...), variation du retard (gigue) - dérive d'horloge entre les terminaux Ils existent différentes solutions pour pallier ces dégradations différentes, dont des 25 solutions d'adaptation dans les terminaux. On distingue deux types d'adaptation dans les terminaux Vol P: l'adaptation basée émetteur ("sender based" en anglais) et l'adaptation basée récepteur ("receiver based" en anglais). Il existe aussi des variantes où la décision d'adaptation est assistée ou prise par le réseau, mais ce cas n'est pas traité ici car il dépasse le cadre de l'invention. 30 Dans le cas d'une adaptation "basée émetteur", pour que l'émetteur puisse prendre une décision d'adaptation optimale de bout en bout, celui-ci doit recevoir un retour ou « feedback » du récepteur distant indiquant la qualité perçue en bout de chaîne, avec par exemple des indicateurs comme le taux de perte observé ou la bande passante disponible estimée par le récepteur distant. 35 Dans le cas d'une adaptation "basée récepteur", la décision d'adaptation est prise par le récepteur distant (155) et transmise par « feedback » vers l'émetteur local (104) (par exemple le choix du mode ou débit à utiliser) - ce feedback est transmis en passant par l'émetteur distant (154) puis le récepteur local (105). 20 - - - 4 La figure 1 indique ce feedback par des flèches en pointillées pour le sens allant du récepteur 155 à l'émetteur 104. Bien entendu, ce feedback peut se faire dans l'autre sens de la communication, avec un feedback du récepteur 105 vers l'émetteur 154 en passant par les blocs 104 et 155; ce sens inverse n'est pas représenté sur la figurel pour ne pas alourdir 5 cette figure. On s'intéresse ici plus particulièrement à une adaptation en débit pour remédier par exemple aux changements de bande passante et à la congestion de réseau. Dans un exemple de solutions d'adaptation, pour contrôler une variation de bande passante ou une congestion du réseau, on peut mettre en oeuvre les techniques décrites ci- 10 dessous. Lorsqu'un codec fonctionne à un débit fixe, une solution d'adaptation pour modifier le débit effectif sur le réseau consiste à varier le nombre de trames consécutives de signal dans un paquet ("frame bundling" en anglais) et ainsi varier le débit paquet ("packet rate" en anglais) et le débit relatif des entêtes protocolaires I P/UDP/RTP (et des couches inférieures). 15 Lorsqu'un codec est multi-débit, on peut également changer le débit du codec. Ce changement de débit peut se faire en fonction de la bande passante disponible estimée par le récepteur distant et reçue par « feedback » (décision "basée émetteur") ou en fonction d'une requête de changement de débit reçue par « feedback » (décision "basée récepteur"). La figure 2 décrit un exemple avancé de contrôle de débit d'un codec multi-débit 20 appelé iSAC (pour « internet Speech Audio Codec » en anglais). Le codec iSAC est un codec propriétaire développé par la société GI PS (Global I P Solutions). Depuis 2011 le code source d'iSAC est disponible dans le projet open source WebRTC de Google ChromiumTM Le codec fonctionne selon deux modes différents : - Le mode Wide Band (WB) code une bande audio de 0 à 8kHz avec une longueur de 25 trames de 30 ou 60 ms. - Le mode Super Wide Band (SWB) code une bande audio de 0 à 12kHz ou de 0 à 16kHz avec une longueur de trame de 30 ms. Le débit du codec iSAC est variable ; le débit moyen peut aller de 10 à 32kbit/s en mode Wide Band et de 10 à 56 kbit/s en SuperWideBand. Le codec iSAC peut fonctionner 30 selon deux modes de transmission sur le canal : - « Channel Adaptive » - « Channel I ndependent » Le mode « Channel Adaptive » prend en compte les estimations de bande passante faites en réception par le décodeur iSAC et permet d'adapter le débit de codage, tandis que le 35 mode « Channel I ndependent » se contente de suivre un débit cible (« target bitrate »). 5 Comparée à la figure 1, on a volontairement omis à la figure 2 les blocs de traitements audio (103 et 153) et le réseau (125) afin d'alléger la figure. On retrouve les éléments de captation et restitution audio (blocs 101, 102 et 151, 152). Le débit du codage (blocs 201, 251) est adapté dans le codec iSAC (blocs 202, 252) 5 à partir de l'indication de débit dans le sens descendant, estimé au récepteur (blocs 205, 255). En effet le récepteur (blocs 205, 255) estime la bande passante disponible dans le sens descendant (« downlink ») à chaque réception de paquets à partir des informations suivantes : - taille du paquet (charge utile) ; 10 - temps d'arrivée ; - numéro de séquence ; - temps d'émission RTP. Le débit estimé est ensuite mis à disposition de l'émetteur via une structure partagée (blocs 207 et 257). L'émetteur (blocs 204, 254) envoie un champ appelé BEI (pour 15 « Bandwidth Estimate Index » en anglais) dont les valeurs vont de 0 à 23 pour indiquer la bande passante disponible estimée par le récepteur; le champ BEI indique une valeur de bande passante disponible ("bottleneck") estimée parmi des valeurs définies entre les débits cibles minimum et maximum du codec iSAC (de 0 à 11 en mode WB et de 0 à 23 en mode SWB). Le champ BEI est décodé à l'autre bout de la chaîne (blocs 203, 253). 20 On notera également que l'estimation de bande passante dans le codec iSAC s'accompagne également d'une estimation de la gigue qui n'est pas décrite ici mais qui sert à l'estimation de la taille du bourrage décrite plus loin; la gigue estimée est représentée sur 1 bit pour indiquer une valeur faible ou élevée et elle transmise dans le champ BEI en mode WB (0 si le BEI est entre 0 et 11 et 1 s'il est entre 12 et 23) ou codée dans le train binaire 25 (charge utile de la trame courante) en mode SWB. Pour le sens de transmission de 200 à 250, l'adaptation de débit est mise en oeuvre côté émetteur. Le codage effectué en 201 a un débit mis à jour par le bloc 202 à partir d'un champ BEI décodé en 203. Ce champ décodé a été codé en 254 à partir d'une estimation de 30 bande passante disponible effectuée par le bloc 255 du récepteur 155. La transmission dans l'autre sens s'effectue de la même façon avec les blocs correspondants. Une méthode de bourrage ("padding" en anglais) de bits aléatoires, à la fin du paquet, est effectuée, pour tester s'il est possible d'augmenter le débit de codage ("bandwidth 35 probing" en anglais). Cette méthode simple permet en effet d'augmenter artificiellement la taille de certains paquets à l'émission (210 ou 260 respectivement) afin de pouvoir estimer en bout de chaîne en réception (205 ou 255 respectivement) si la bande passante disponible sur le canal de transmission permet d'utiliser un débit supérieur au débit actuel. On notera 6 cependant que cette méthode utilise des bits aléatoires sans autre utilité que le test de bande passante. La taille et la décision d'envoi du bourrage de bits sont déterminées à l'aide d'un modèle de débit ("rate model" en anglais). Au début de l'appel (typiquement les 10 premières 5 secondes), le débit est maintenu à un débit minimal. Ensuite trois paquets consécutifs comportant des bits de bourrage sont envoyés pour tester le canal, avec un intervalle maximal de typiquement 500 ms. La taille de ces paquets consécutifs est fixée pour que le débit instantané associé au paquet i soit donné par (1 + y,) R,, où R, est la bande passante disponible estimée au paquet i et le terme adaptatif y, (de valeur supérieure >0) est calculé 10 de façon "heuristique". Le principe est d'envoyer des pics de débit réguliers (« bursts ») sur le canal pour tester une augmentation de débit par rapport au débit actuel. Le modèle de débit (« rate model ») mis en oeuvre dans les blocs 210 et 260 repose sur un modèle de goulot d'étranglement (« bottleneck ») limitant la bande passante disponible dans le réseau. Ce modèle de débit s'appuie sur plusieurs états internes définis au 15 récepteur dont une détection binaire de dépassement ("overuse" en anglais) de la bande passante par le dernier paquet reçu avec une mesure du temps écoulé depuis le dernier dépassement détecté de bande passante (en ms), ainsi que des informations sur la file d'attente modélisant le "bottleneck" (nombre de paquets qui restent à transmettre, augmentation du retard). 20 L'estimation de débit effectuée au récepteur est en général efficace pour diminuer le débit de codage, c'est-à-dire détecter que la bande passante disponible est plus faible que le débit actuel et que le débit doit être abaissé. Par contre la méthode consistant à effectuer un bourrage de bits aléatoires pour vérifier que le débit actuel peut être augmenté n'est pas 25 optimale, en effet, elle introduit des bits aléatoires non utilisés et non contrôlés. D'autre part, le codec iSAC produit un débit moyen qui peut être ajusté assez finement entre un débit minimal et un débit maximal (ex: 10 à 32 kbit/s ou 10 à 56 kbit/s), alors qu'un codec multidébit fonctionnant selon un ensemble défini de débits discrets, comme un codec de type AMR, AMR-WB ou EVS, ne fonctionne pas sur une gamme continue de débits. 30 Par ailleurs, la méthode d'adaptation de débit du codec iSAC, utilisant une estimation de débit en réception et un test de canal par bourrage de bits, suppose l'utilisation d'un champ spécifique au codec iSAC (BEI). Ce champ spécifique n'existe pas pour d'autres types de codecs, notamment pour les codecs multi-débit de type AMR, AMR-WB et EVS. On notera que le champ CMR des codecs AMR, AMR-WB et EVS est différent du champ BEI du codec 35 iSAC, car l'un (BEI) représente une information sur la bande passante disponible estimée au récepteur et suppose une adaptation « basée émetteur », l'autre (CMR) permet de coder une requête d'adaptation indiquant un débit maximal et suppose une adaptation « basée récepteur ». 7 Une autre méthode plus avancée - reprenant les mêmes principes - d'estimation de bande passante disponible et d'adaptation de débit de codage est décrite dans l'article "Making Google Congestion Control robust over Wi-Fi networks using packet grouping" de G. 5 Carlucci, L. De Occo, S. Holmer, S. Mascolo, publié dans ACM, IRTF & ISOC, Applied Networking Research Workshop, 2016. Cet article décrit le fonctionnement de l'algorithme GCC (pour "Google Congestion Control" en anglais) pour le contrôle de congestion vidéo; l'algorithme d'adaptation GCC est divisé en deux parties: une partie émetteur et une partie récepteur. L'algorithme GCC suppose l'utilisation du profil RTP AVPF pour envoyer des 10 messages RTCP REMB (RTCP message for Receiver Estimated Maximum Bitrate) toutes les secondes ou dès que la bande passante estimée a baissé de 3%. La partie émetteur est basée sur le taux de perte (« loss based »). Elle transmet dans les entêtes des paquets RTP des temps d'émission absolus appelés "abs-send-time", qui servent à l'estimation de bande passante disponible dans la partie récepteur. Elle utilise les 15 rapports RTCP REMB indiquant le débit estimé Ar et la perte de trame observée fi par le récepteur distant pour adapter le débit de codage: le débit de codage cible As est respectivement augmenté, maintenu ou diminué quand le taux de perte est négligeable, faible ou élevé : {(1 - 0.5/1)As(i - 1) si fi > 0,1 As(i) = 1.05A, (i - 1) si fi 0, par exemple à 2, en cours de redondance, et elle vaut -1 quand la redondance 10 est désactivée), on verra plus loin que l'offset pourra aussi prendre une valeur qui sera fonction d'un paramètre de fréquence d'envoi de redondance; - temps écoulé (« timer ») depuis le dernier CMR reçu: TcmR réinitialisé à 0 à chaque réception de CMR (avec un débit donné, autre que NO_REQ); 15 - délai de déclenchement du test d'augmentation de débit par redondance : Tburst (défini en nombre de trames) fixé à 250 - facteur d'ajustement contrôlant le délai de déclenchement du test: f burst (sa valeur est adaptée mais ré-initialisée à 1.0) ; - paramètre d'adaptation du facteur f burst Ç0burst = 1.5. 20 Dans des variantes, d'autres valeurs pourront être affectées aux paramètres ci-dessus. Les figures 4a, 4b et 4c représentent un exemple d'implémentation d'un procédé d'adaptation de débit avec redondance selon l'invention sous la forme d'organigrammes, mis en oeuvre dans un système bidirectionnel. La figure 4a présente les étapes mises en oeuvre par le récepteur selon un premier 25 mode de réalisation de l'invention, à la réception d'un paquet. Dans ce mode de réalisation, la communication est bidirectionnelle et les étapes suivantes peuvent être appliquées dans les deux terminaux. A la réception d'un paquet (en 401), deux types d'information sont extraits : - des informations de transmission du paquet actuel permettant l'estimation de 30 la bande passante disponible (en 402) selon une des méthodes d'estimation précédemment décrites. L'extraction de ces informations est suivie par les étapes X décrites en référence à la figure 4b ; - des informations sur le type d'adaptation demandé à partir de la requête CMR envoyée par l'autre bout de la communication (en 403). Le CMR extrait est 35 indiqué dans la structure partagée "CMR req", en particulier pour signaler qu'un nouveau CMR a été reçu si celui-ci est présent et différent de NO_REQ. L'entrée "updated" de la structure CMR Req est mise à la valeur "vrai" quand un CMR (autre que NO REQ) a été extrait. 20 On rappelle que, pour le codec EVS, le champ CMR est codé sur un octet appelé "CMR byte" et qu'il est construit à partir de 3 champs: H ("header" à 1 bit), T ("type" sur 3 bits) et D ("data" sur 4 bits) selon les tableaux A.2 et A.3 de l'annexe A de la spécification 5 3GPP TS 26.445. On peut donc extraire le débit DaviR demandé et éventuellement d'autres paramètres de codage (comme la bande codée) en décodant le CMR (si celui-ci est reçu et autre que la valeur NO REQ correspondant à T=111 et D=1111 en binaire). On ne détaille pas ici les étapes connues de l'homme de l'art qui consistent à extraire les entêtes (champs CMR et ToC pour "Table of Content" si présents), à démultiplexer et 10 décoder les trames codées à partir de la charge utile du paquet reçu pour le codec EVS. En particulier, en cas de pertes de paquet, la redondance éventuelle sera utilisée par le récepteur pour corriger des pertes si la trame courante perdue a été dupliquée dans un autre paquet avec un offset donné. 15 La figure 4b détaille les étapes X mises en oeuvre au récepteur après extraction des informations sur le paquet actuel (402). Une estimation de la bande passante est faite selon l'une des méthodes précédemment décrite (en 411). Ensuite une correspondance (« mapping ») entre la bande passante estimée et les débits discrets EVS est réalisée (en 412) pour déterminer s'il y a besoin de changer le débit de réception actuel et s'il est possible de 20 passer d'un débit discret à un autre. Dans le mode de réalisation privilégié cette correspondance est mise en oeuvre selon le pseudo-code donné en Annexe 1 pour obtenir le débit D à partir de la bande passante disponible B. Dans des variantes, on pourra modifier cette correspondance en prenant par exemple 25 le débit discret du codec EVS supérieur ou inférieur le plus proche de la bande passante estimé. Si le débit estimé est équivalent au débit actuel (N en 413), aucune information de débit (bloc 414) n'est écrite dans la structure partagée "BW_info" et l'entrée "updated" de cette structure est mise à la valeur "faux". Si le débit estimé est différent du débit actuel (O 30 en 413), on écrit dans la structure partagée "BW_info" les informations nécessaires à l'étape 415 (la valeur de l'entrée "requested-bitrate") pour que l'émetteur puisse coder le CMR avec la prochaine trame à envoyer, en fixant aussi la valeur de l'entrée "updated" à "vrai". Une requête classique de changement de débit à un débit discret correspondant sera alors construite et codée comme dans le cas d'un codec EVS de l'état de l'art. 35 La figure 4c détaille les étapes mises en oeuvre à l'émetteur (incluant le codeur) d'un procédé d'adaptation de débit de codage selon un premier mode de réalisation de l'invention. 21 Lors de la réception d'une nouvelle trame de signal à coder (étape 420), l'émetteur vérifie si un CMR a été reçu dans la structure partagée "CMR Req" en 421 (en vérifiant si l'entrée "updated" est passée à "vrai"). Si c'est le cas, il réalise une adaptation des paramètres de codage et d'émission (en 424), si un CMR comportant une requête 5 d'adaptation existe, puis il met la valeur de l'entrée "updated" de la structure CMR Req à "faux". De plus, si un CMR a été reçu avec un débit demandé différent du débit de codage actuel, une indication de réception de CMR est mise en mémoire et le compteur de trame depuis le dernier CMR reçu est remis à 0 (TcmR= 0) à l'étape 424. En 425, on vérifie si un test d'augmentation de débit avec redondance est en cours, 10 en vérifiant si Nburst > 0. Si c'est le cas (O en 425), alors ce test est désactivé en 426. On réinitialise en 426 les paramètres de redondance avec Nburst = -1 (Nburst burst représentant le nombre de trames avec redondance qui reste à transmettre) et Kburst = -1. De plus, le délai de déclenchement du test d'augmentation de débit est adapté selon l'adaptation de débit demandée dans la requête CMR. 15 Ainsi; - Si le débit de codage actuel est supérieur au CMR reçu (Rs > RcmR) le récepteur demande de baisser le débit. Il est alors décidé d'augmenter la temporisation pour un déclenchement d'un test d'augmentation de débit. Pour cela, on augmente le facteur d'ajustement en fixant fburst = fburst + 20 (Pburst - La temporisation pour déclencher un test est comme expliqué ultérieurement, fonction du facteur fburst selon la formule suivante : TCMR = fburst-Tburst - Sinon le récepteur distant demande d'augmenter le débit (Rs 0) lors du codage de la trame courante, alors, on vérifie: 25 - Si on a atteint la fin de la redondance appliquée actuelle (Nburst = 0). Dans ce cas, on fixe Kburst = -1 et on réinitialise TcyiR= 0. - Sinon : on décrémente le compteur de trames avec redondance avec Nburst = Nburst - 1 30 En E427, l'émetteur vérifie si un CMR doit être transporté dans le paquet associé à la trame courante à coder. Si c'est le cas, les données du CMR dans la structure "BW Info" sont extraites pour codage ultérieur du CMR. L'émetteur crée ensuite l'entête du payload RTP courant, si les champs CMR et ToC sont à insérer dans le paquet courant. Pour le champ CMR, on renvoie le lecteur aux tableaux 35 A.2 et A.3 de l'annexe A de la spécification 3GPP TS 26.445 pour la construction et le codage du champ CMR pour le codec EVS à partir des informations sur la requête CMR (débit, bande codée...) à coder. Si un champ CMR doit être envoyé mais l'entrée "updated" de la structure "BW Info" a la valeur "faux", on utilisera le code NO REQ qui correspond à T=111 et 23 D=1111 (en binaire). De façon similaire, le codage du champ ToC est décrit dans la figure A.4 et les tableaux A.4 et A.5 de l'annexe A de TS 26.445. Selon l'invention, si la redondance 100% est utilisée dans le paquet courant, le champ ToC décrira à la fois le débit de la trame courante, le débit de la trame redondante et l'offset de redondance Kburst (en utilisant le 5 nombre adéquat de ToC associés à NO DATA). On rappelle que des exemples de structure de trames redondantes sont donnés au chapitre 10 de la spécification 3GPP TS 26.114 et la construction du champ ToC suit les principes donnés dans cette spécification pour les codecs AMR, AMR-WB et EVS. La trame courante est codée en 427 et ajoutée aux données du paquet. 10 Si la redondance est activée (O en 422), la trame codée redondante correspondant à l'offset Kburst (mémorisée dans une file ou une autre structure de données) est aussi ajoutée aux données du paquet courant pour être transmise en 428. Le paquet ainsi formée avec les entêtes (éventuelles) et données codées est transmis (428) en utilisant les informations relative à la taille de la charge utile RTP et le nombre de 15 trames codées depuis la réception du dernier CMR est incrémenté de 1 (7'cmR TcmR-F 1). La trame codée courante est mémorisée dans une file pour une éventuelle utilisation ultérieure comme trame redondante. On notera qu'il n'est pas toujours possible de doubler le débit de codage, si la session 20 SDP (avec le paramètre b=AS) ou les paramètres de qualité de service (GBR et MBR sur réseau mobile de type VoLTE) limitent le débit maximal utilisable par le codec. Dans des variantes de l'invention, on prendra par exemple en compte la définition d'un paramètre SDP de type b=AS limitant le débit maximal utilisable par le codec. Par exemple dans le cas du codec EVS SWB, on peut avoir un paramètre b=AS limitant le débit à 25 24.4 kbit/s (en transmission d'une trame unique de 20 ms). Dans ce cas, selon l'invention, on pourra limiter l'utilisation de la redondance de deux façons : - si le réseau ne rejette pas les paquets sur la base du débit instantané (par exemple un débit supérieur à 24.4 kbit/s) mais en utilisant une moyenne glissante du débit sur une fenêtre temporelle (par exemple d'une durée de 2 30 secondes comme indiqué à la section 7.5.5.1 de la spécification 3GPP TS 26.114), on pourra garder la réalisation d'une transmission alternée de paquets avec ou sans redondance, c'est-à-dire utiliser une transmission redondante intermittente pour le test d'augmentation de débit. La fréquence de transmission des paquets redondants est alors adaptée à cette contrainte 35 de débit maximum. On détaille plus loin une variante du premier mode de réalisation pour ce cas. - si aucun paquet ne peut dépasser une taille limite correspondant au débit maximal (par exemple une taille correspondante à 24.4 kbit/s), on pourra 24 tester par exemple 2x9.6 kbit/s mais pas 2x13.2 kbit/s et on pourra passer ainsi aux débits de 13.2 ou 16.4 kbit/s qui sont compris entre 9.6 et 2x9.6 kbit/s; par contre il sera difficile de tester le passage à 24.4 kbit/s, à moins d'alterner un codage à 9.6 et un codage à 13.2 et d'associer une trame codée 5 et une trame redondante pour un débit d'environ 9.6+13.2 kbit/s. Dans tous les cas, cette variante implique qu'avant d'appliquer la redondance, une diminution du débit à un débit discret inférieur doit être potentiellement effectuée (par exemple pour tester si l'on peut passer de 13.2 à 16.4 ou de 16.4 à 24.4 kbit/s). On utilisera un débit inférieur (par exemple 9.6 kbit/s) au 10 débit actuel (par exemple 13.2 ou 16.4 kbit/s). En effet il ne serait pas possible d'utiliser 2x13.2 kbit/s, car cela dépasserait le débit de 24.4 kbit/s et seuls les cas 2x9.6 kbit/s et 9.6+13.2 kbit/s seront autorisés. Dans des variantes de l'invention selon le premier mode de réalisation, l'activation de la redondance pourra n'être autorisée que lors des périodes de signal actif pour minimiser les 15 impacts de l'augmentation de débit. On a décrit précédemment un test d'augmentation de débit avec une redondance 100%, c'est-à-dire une redondance pour chaque paquet transmis pendant un nombre de trame déterminé (Lburst). Dans des variantes de réalisation, comme pour le deuxième mode 20 de réalisation décrit ultérieurement, la redondance ne sera activée que de façon intermittente. Par abus de langage, on appellera ici "fréquence" de redondance la période avec laquelle un paquet redondant est utilisé - ainsi une fréquence de x signifie qu'une trame redondante est insérée tous les x paquets. Plutôt que de doubler (approximativement) le débit de codage, la redondance est 25 utilisée par exemple tous les 2 ou 3 paquets ce qui permet d'obtenir en moyenne une augmentation relative de débit fractionnaire, afin de tester (en moyenne) le passage au débit discret immédiatement supérieur et non un débit doublé. Par exemple si le débit est de 9.6 kbit/s, l'activation de la redondance fait passer le débit pic instantanée à approximativement 2x9.6 kbit/s mais le débit moyen réel sur le canal sera de 30 (freq+1)/freq x 9.6, soit 2x9.6 (approx. 19.2) si freq= 1, 1.5x9.6 (approx. 14.4) si freq=2, 4/3x9.6 (approx. 12.8) si freq= 3. L'offset de redondance est fixé à la même valeur que le paramètre de fréquence (freq) pour que la redondance puisse être exploitée. Cet autre paramètre définissant la redondance, pourra être déterminé à l'étape 423 35 de la figure 4c en fonction d'information du débit actuel et du débit immédiatement supérieur. Par exemple, si la gamme de débit 9.6 à 24.4 kbit/s est utilisable dans une session avec le codec EVS en mode Super-Wideband, on pourra utiliser: 25 - à partir d'un débit de 9.6 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 9.6 kbit/s tous les 2 paquets (pour arriver à un débit moyen sur le canal de près de 14.4 kbit/s) ou tous les 3 paquets (approximativement 12.8 kbit/s) - à partir d'un débit de 13.2 kbit/s, le test d'augmentation de débit pourra se faire 5 avec une trame redondante codée à 13.2 kbit/s tous les 3 paquets (approx. 17.6 kbit/s) ou tous les 4 paquets (approx.16.5 kbit/s) - à partir d'un débit de 16.4 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 16.4 kbit/s tous les 2 paquets (approx. 24.6 kbit/s) La fréquence d'envoi de la redondance est donc adaptative, en fonction du débit 10 actuel. Elle est de 2 ou 3 à 9.6 kbit/s, 3 ou 4 à 13.2 kbit/s, 2 à 16.4 kbit/s. L'offset de redondance sera de façon privilégié défini comme étant égal à la fréquence d'envoi des paquets redondant pour compenser d'éventuelles pertes des paquets plus volumineux. Dans des variantes il sera possible d'utiliser un autre offset pour répéter par exemple la trame qui suit immédiatement le paquet avec redondance. 15 D'une manière plus générale, la fréquence pourra être choisie en fonction du débit discret courant DO et du débit discret D1 immédiatement supérieur pour un codec donné, comme la valeur entière la plus proche de 1/(D1/D0-1). A titre d'exemple, on considère les cas suivants (Tableau 1) qui seront utilisés de façon privilégiée dans cette variante du premier mode de réalisation: DO D1 1/(D1/D0-1) freq 9.6 13.2 2.66 3 13.2 16.4 4.125 4 16.4 24.4 2.05 2 20 Tableau 1 On présente ensuite un deuxième mode de réalisation où l'émetteur et le récepteur agissent encore de manière coordonnée mais où cette fois-ci le récepteur envoie une requête explicite d'activation de redondance 100% pour tester une augmentation de débit, par le biais 25 d'une requête CMR étendue. On suppose dans cette description un débit maximal de 24.4 kbit/s et une valeur de b=AS correspondante à ce débit maximal. Dans ce mode de réalisation, les codes CMR existants du codec EVS (comme définis dans le tableau A.3 de la spécification 3GPP TS 26.445) sont utilisés pour envoyer une requête vers un débit de codage donné, lorsqu'il s'agit de baisser ou d'augmenter le débit en 30 fonction de la bande passante disponible estimée. Cependant, un CMR non classique, dit CMR étendu est nécessaire pour envoyer une requête d'activation de redondance, car les codes CMR existants du codec EVS ne permettent qu'une adaptation en débit, bande audio et le contrôle d'un mode spécial de redondance partiel à 13.2 kbit/s (appelé « channel-aware mode »). On suppose que la session SDP inclut un paramètre supplémentaire appelé sans 26 perte de généralité "adapt" pour signaler et autoriser l'utilisation d'un tel CMR étendu, et que les deux terminaux sont compatibles avec le paramètre SDP "adapt". Pour indiquer l'activation d'une étape de test d'augmentation de débit par une transmission de paquets redondants, par exemple, une redondance 100%, dans le cas du codec EVS, on utilise selon 5 ce mode de réalisation, des codes CMR qui sont libres, laissés pour un usage futur ( "for future use") ou réservé ("reserved") et qui ne sont pour l'instant pas utilisés dans les spécifications du codec EVS. A titre d'exemple, on considère les codes suivants (Tableau 2): Code CMR (H T D) Requête EVS 1 111 0000 RED 2x9.6-SWB, f req. 1 , offset= 1 1 111 0001 RED 2x9.6-SWB, freq.2, offset= 2 1 111 0010 RED 2x9.6SWB, freq. 3, offset= 3 1 111 0011 RED 2x13.2-SWB, freq.1, offset= 1 1 111 0100 RED 2x13.2-SWB, freq.2, offset= 2 1 111 0101 RED 2x13.2-SWB, freq.3, offset= 3 1 111 0110 réservé 1 111 0111 réservé 1 111 1000 réservé 1 111 1001 réservé 1 111 1010 réservé 1 111 1011 réservé 1 111 1100 réservé 1 111 1101 réservé 1 111 1110 réservé Tableau 2 10 où la redondance 100% est activée par l'émetteur de façon intermittente tous les 1, 2, ou 3 paquets (selon la fréquence d'envoi) pour augmenter le débit. Par exemple si le débit est de 9.6 kbit/s, l'activation de la redondance fait passer le débit pic instantanée à approximativement 2x9.6 kbit/s mais le débit moyen réel sur le canal sera de (freq+1)/freq x 9.6, soit 2x9.6 (approx. 19.2) si freq= 1, 1.5x9.6 (approx. 14.4) si 15 freq=2, 4/3x9.6 (approx. 12.8) si freq=3. L'offset est fixé à la même valeur que la fréquence (freq) pour que la redondance puisse être exploitée. Dans des variantes, une autre convention pourra être définie pour fixer la valeur d'offset. On ne détaille pas ici les détails de construction ou d'extraction de CMR selon le 20 tableau 2. Cependant on suppose que la structure "CMR Req" contiennent un champ appelé "burst uplink" qui est mis à "1", "2" ou "3" lorsque des codes CMR étendus selon le tableau 2 27 sont utilisés, sinon sa valeur est mise à "-1". Ainsi en combinant l'entrée "requested bitrate" et cette entrée "burst uplink" il est possible de signaler complètement le type de requête à envoyer ou de requête reçue. 5 Une caractéristique importante de ce deuxième mode de réalisation par rapport à l'utilisation classique de redondance 100% est que la redondance est de façon privilégiée intermittente: plutôt que de doubler (approximativement) le débit de codage, la redondance est utilisée de façon adaptative par exemple tous les 1, 2 ou 3 paquets ce qui permet d'obtenir en moyenne une augmentation de débit fractionnaire, afin de tester (en moyenne) 10 le passage au débit discret immédiatement supérieur et non un débit doublé. D'une manière plus générale, la fréquence pourra être choisie en fonction du débit discret courant DO et du débit discret D1 immédiatement supérieur pour un codec donné, comme la valeur entière la plus proche de 1/(D1/D0-1). Dans le cas où le débit pic instantané ne peut pas dépasser le débit maximal autorisé 15 dans la session (par exemple 24.4 kbit/s), on n'utilisera que des requêtes associées à 9.6 kbit/s avec différentes valeurs de fréquences (freq= 1, 2 ou 3), sachant qu'il sera difficile dans ce cas de tester un débit proche de 24.4 kbit/s car la fréquence freq= 1 donne un débit autour de 19.2 kbit/s. Sinon on pourra également autoriser les requêtes associées au débit de 13.2 kbtit/s, ce qui permet de tester des débits d'approximativement (freq+1)/freq x 13.2, soit 20 2x13.2 (approx. 26.4) si freq= 1, 1.5x13.2 (approx. 19.8) si freq=2, 4/3x13.2 (approx. 17.6) si freq= 3. A partir de la bande passante estimée - en instantané ou sur un horizon de passé donné par l'historique - et en utilisant potentiellement des informations supplémentaires 25 comme le taux de pertes de paquets mesuré en réception (où la bande passante estimée sera multiplié par un facteur 10%), une requête d'adaptation de débit est déterminée et encodée en un code CMR (bloc 302 et 352 de la figure 3). Cette requête CMR est rajoutée par l'émetteur local dans le prochain paquet à transmettre. 30 On définit selon l'invention trois types de décisions de requête d'adaptation à envoyer pour l'adaptation de débit : - décision "SET RATE" : on envoie dans ce cas un CMR qui indique un débit de codage qui correspond à la bande passante estimée si le débit actuel n'est pas dans un intervalle autour de cette bande passante estimée ; 35 - décision "NO_REQ": on garde le débit actuel si le débit à utiliser reste inchangé - dans ce cas on peut envoyer un CMR indiquant le débit actuel ; - décision "USE_RED": on envoie un CMR indiquant qu'il faut activer la redondance 100% à l'émission - dans un mode de réalisation privilégié, la redondance est utilisée de 28 façon adaptative - avec un offset adaptatif lié au débit de codage - pour tester le passage au débit immédiatement supérieur au débit actuel (avec une fréquence d'envoi variable), dans des variantes on pourra envisager d'activer la redondance pour un usage en continu - avec freq= 1 et offset = 1 - jusqu'à ce qu'on détecte des problèmes de qualité. Cela 5 permet une remontée rapide du débit mais en général on préférera une remontée progressive par paliers pour tester les débits supérieurs un par un. Pour les codecs AMR et AMR-WB qui fonctionnent avec un feedback inband par CMR, la signification du CMR NO REQ est différente de celle d'EVS, NO_REQ indique le débit maximal autorisé. Dans des variantes utilisant ces codecs, on remplacera donc la décision 10 NO_REQ par une décision SET_RATE pour indiquer le débit courant. Dans des variantes de l'invention utilisant EVS on pourra de la même façon remplacer la décision NO REQ par une décision SET_RATE pour indiquer le débit courant. Selon ce deuxième mode de réalisation, des codes CMR réservés sont utilisés, ce qui 15 justifie la notation de CMR étendu (Ext. CMR) dans les blocs 307 et 357 de la figure 3. Les codes étendus de CMR servent à indiquer une requête d'adaptation pour augmenter le débit de codage, cette requête indique à l'émetteur distant de tester un débit supérieur à ce débit donné dans la requête - dans ce cas l'émetteur activera par transmission de paquets redondants, une transmission à ce débit donné avec redondance 100%. 20 Cette requête suppose une utilisation de redondance côté émetteur. Dans un mode de réalisation simplifié, l'émetteur pourra exécuter la requête issue du CMR comme dans le premier mode de réalisation de l'invention, en vérifiant que l'entrée "updated' est à "vrai" dans la structure "CMR Req" et en appliquant les paramètres d'adaptation contenus dans "CMR Req"; après récupération des paramètres, la valeur de "updated" est remise à "faux". 25 Dans un mode de réalisation privilégié, on laissera à l'émetteur suffisamment de flexibilité pour exécuter la requête d'activation de redondance en fonction du signal en cours de codage. Comme expliqué plus loin l'augmentation de débit peut résulter en une congestion, avec des pertes de paquets ou une augmentation de la gigue, il est donc important, quand la bande passante disponible n'est pas connue et testée en aveugle (pour estimer le "bottleneck" dans 30 le sens descendant) de ne pas dépasser outre mesure cette limite sur le canal; par ailleurs l'impact des pertes et de la gigue est différent selon les types de trames codées, pour les parties inactives ou les parties les moins sensibles de la parole active, on peut plus facilement tolérer ces dégradations. 35 Pour ce deuxième mode de réalisation, la figure 5a reprend du premier mode de réalisation les étapes d'extraction effectuées au récepteur. Ainsi, à la réception d'un paquet en 501, deux informations sont extraites au récepteur: 29 - des informations de transmission du paquet actuel permettant l'estimation de la bande passante disponible (en 502) selon une des méthodes d'estimation précédemment décrites. L'extraction de ces informations est suivie par les étapes X décrites en référence à la figure 5b ; 5 - des informations sur le type d'adaptation demandé à partir de la requête CMR envoyée par l'autre bout de la communication (en 503). La différence principale avec la figure 4a concerne le fait que la requête CMR peut correspondre à un CMR étendu alors qu'à la figure 4a on suppose une requête CMR "classique"; de plus les étapes X incluent également la possibilité de décider d'envoyer une 10 requête étendue pour activer la redondance en utilisant l'entrée "burst uplink". La figure 5b détaille les étapes X mises en oeuvre par le dispositif récepteur après extractions des informations sur le paquet actuel (502). De la même façon que pour le premier mode de réalisation, une estimation de la 15 bande passante est faite selon l'une des méthodes précédemment décrite (en 511). Ensuite une correspondance (« mapping ») entre la bande passante estimée et les débits discrets EVS est réalisée (en 512) comme décrite précédemment pour déterminer s'il faut changer le débit de réception actuel et s'il est possible de passer d'un débit discret à un autre. Si le débit déterminé selon la bande passante estimée dans le dernier paquet reçu est 20 différent du débit actuel (O en 513), on prend la décision « SET RATE », de changement de débit selon ce nouveau débit. Une requête classique de changement de débit à un débit discret correspondant est définie à l'étape 514 ; les données associées sont écrites dans la structure partagée "BW info", pour que l'émetteur puisse ensuite coder la requête correspondance avec la trame à envoyer. 25 Dans le cas où le nouveau débit est identique au débit actuel, alors une étape de vérification de conditions d'application de test est effectuée en 516. Cette étape de vérification 516 vérifie l'historique d'estimation de bande passante et mesure ainsi une tendance de variation de la bande passante estimée. Si cette tendance est positive (O à 516), c'est-à-dire si la bande passante estimée tend à augmenter, alors une 30 décision « USE RED » peut être prise et l'étape 517 est alors mise en oeuvre. Dans le cas contraire (N à 516), si la tendance est négative, alors il n'y a pas d'émission de requête, la décision « NO REQ » est prise et les données associées au CMR sont écrites dans la structure partagée "BW info". Pour mesurer la tendance de variation, on pourra par exemple utiliser une simple 35 régression linéaire sur la bande passante estimée en fonction du temps d'arrivée des paquets sur une période de 500 ms pour calculer une pente, comme décrit précédemment. Le temps depuis lequel cette décision « NO-REQ » reste sélectionnée peut être mesuré pour décider si un test d'augmentation de débit doit être activé ou non. Si ce temps 30 écoulé est inférieur à un seuil (par exemple 500 ms), alors une décision « NO_REQ » est prise (N à 516). Le mode « NO-REQ » n'a pas été suffisamment long. Dans ce cas, on enverra typiquement aucune requête (pas de CMR) ou un CMR indiquant NO_REQ en 519 - dans ce dernier les données associées au CMR NO REQ sont écrites dans la structure partagée 5 "BW info". Dans des variantes, on pourra réutiliser les critères de déclenchement (d'activation) du test d'augmentation de débit du premier mode de réalisation. Dans des variantes, la décision NO REQ sera remplacée par une décision SET RATE au débit actuel, de façon équivalente. On notera que pour les codecs AMR et AMR-WB le CMR 10 est systématiquement présent dans chaque paquet, et on pourra remplacer le cas NO REQ par le débit actuel. A l'inverse (O à 516), lorsque le temps écoulé est supérieur au seuil, la décision « USE RED » est prise pour demander un test d'augmentation du débit. Dans ce cas, à l'étape 517, une requête CMR étendue est préparée, en écrivant les données associées au CMR étendu dans la 15 structure partagée "BW info. La figure 5c décrit le fonctionnement de l'émetteur à la réception d'une requête CMR (normale ou étendue, autre que NO_REQ). On ne reprend pas ici les étapes restées identiques à l'émetteur en rapport à la figure 4c par souci de simplification. Deux cas possibles se présentent lors de l'étape de vérification si un champ CMR a 20 été reçu. Ainsi, si le champ CMR contient une requête d'adaptation du débit classique ou une requête CMR étendue, les paramètres de codage et d'émission sont fixés comme dans le premier mode de réalisation. Cependant, on pourra laisser l'émetteur décider du moment pour activer la redondance. En rapport avec la figure 5c, à l'étape 521, on vérifie si un CMR classique de 25 changement de débit a été reçu ("updated" à "vrai" et "burst uplink"= -1) et si une étape de test par transmission de paquets de redondance est en cours (Nburst 0). Dans la positive (O en 521), on arrête l'étape de test et on désactive la redondance en 522 comme décrit précédemment dans le premier mode de réalisation. S'il n'y a pas d'étape de test en cours (N en 521) - si Nburst 0" dans la structure "CMR Req"). Dans la positive (O en 523), l'émetteur met en oeuvre une étape de test d'augmentation de débit par la transmission de paquets redondants en 524 en fonction des informations contenues dans la structure "CMR Req". On 35 fixe également le débit pour coder la prochaine trame en fonction du CMR reçu (en 525). Dans des variantes l'algorithme ci-dessus peut être complété pour utiliser également le taux de perte de paquets. Cela rajoute des conditions supplémentaires pour en particulier baisser le débit en cas de pertes significatives (>= 10%) et/ou basculer sur un mode plus 31 robuste (comme le channel-aware mode) s'il est inférieur ou égal au débit actuel, ou éviter la décision USE RED en cas de pertes >= 10%. Dans des variantes, on pourra utiliser une redondance partielle comme expliqué ci- 5 dessus au lieu de la redondance 100% et on pourra également utiliser une redondance plus élevée, non limitée à 100% , par exemple une redondance à 200 ou 300%. Dans des variantes, on pourra aussi utiliser des codecs audio ou vidéo qui ne disposent pas du mécanisme de signalisation CMR « dans la bande » (« inband » en anglais) 10 tel que défini précédemment, dans ce cas on pourra utiliser des paquets RTCP pour indiquer des requêtes équivalentes au CMR utilisé dans les modes de réalisation de l'invention. La figure 6 illustre un exemple matériel d'un terminal de communication TA comportant un dispositif récepteur et un dispositif émetteur apte à mettre en oeuvre les 15 procédés d'adaptation de débit et de détermination d'une requête d'adaptation selon les différents modes de réalisation de l'invention. Le terminal TA comporte un espace de stockage 11, par exemple une mémoire MEM, une unité de traitement 10 comportant un processeur P, piloté par un programme informatique PG, stocké dans la mémoire 11 et mettant en oeuvre les étapes du procédé de 20 d'adaptation de débit et/ou du procédé de détermination d'une requête d'adaptation de débit au sens de l'invention, et notamment l'étape de test d'augmentation du débit de codage mis en oeuvre par un dispositif émetteur par la transmission d'au moins un paquet redondant selon des paramètres de transmission choisis , lorsque ces instructions sont exécutées par le processeur P. 25 Typiquement, la description des figures 4a à 4c et des figures 5a à 5c reprend les étapes des algorithmes de tels programmes informatiques. A l'initialisation, les instructions de code du programme PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur P de l'unité de traitement 10. Les instructions de programme peuvent être mémorisées sur un 30 support de stockage tel qu'une mémoire flash, un disque dur ou tout autre support de stockage non-transitoire. Le terminal TA comporte un module de communication 12 apte à recevoir les paquets voix d'un réseau I P et à transmettre des paquets voix vers le réseau I P avec une redondance pour tester une augmentation de débit selon l'invention. 35 Le terminal comprend un dispositif émetteur comportant une unité de transmission de paquets apte à mettre en oeuvre une étape de test d'augmentation du débit de codage par la transmission d'au moins un paquet redondant selon des paramètres de transmission choisis. 32 Le terminal comprend également un dispositif récepteur qui selon un mode de réalisation, comporte un module d'estimation apte à estimer une bande passante disponible et un module de construction et de transmission d'une requête d'adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en oeuvre d'une 5 étape de test d'augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis. Ces modules sont tels que décrits en référence à la figure 3. Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant 10 logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de 15 fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.) Le terminal est par exemple un téléphone, un téléphone intelligent, une tablette, un ordinateur, une passerelle résidentielle ou un objet connecté. 33 ANNEXE 1 : EVS D(0 à 8) = (9600, 13200, 16400, 24400, 32000, 48000, 64000, 96000, 12800) Pour i=0 à 8: 5 Si EVS D(i) > B-(EVS D(i+1)-EVS D(i))/2: Sortir de la boucle "Pour" Fin Si i = i+1 Fin Pour 10 S i == 9: D = EVS D(i-1) Sinon D = EVS D(i)