Brevet FR3153205A1 — publié le 20250321

Format optimisé de transport de données audio d’une session de communication en voix sur IP L’invention se rapporte à un procédé de de génération de format de transport de données audio lors d’une session de communication temps réel entre dispositifs de communication (A,B), dans lequel le format de transport de données pour un codec audio étendu (IVAS), étendant un codec audio mono (EVS), réutilise le format de transport de données dudit codec audio mono, et où au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. L’invention se rapporte également à un format de transport de données ainsi généré ainsi qu’à un terminal de communication mettant en œuvre le procédé de génération d’un tel format de transport. Figure de l’abrégé : Figure 2 Format optimisé de transport de données audio 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 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 œuvre 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 IP, la vidéo téléphonie sur IP ou encore la diffusion vidéo sur IP. L’invention se rapporte plus particulièrement à la génération et à la réception de charge utile (« payload » en anglais), encore appelé par la suite format de transport), pour le transport de données codées selon le protocole RTP (pour « Real-Time Transport Protocol » en anglais) lors d’une communication temps-réel entre deux dispositifs de communication, par exemple entre deux terminaux de communication ou entre un terminal de communication et un équipement réseau, pour traiter des signaux temps réels comme les signaux de voix ou de vidéo. On renvoie aux spécifications IETF RFC 3550 et RFC 4566 pour les bases connues de l’état de l’art sur le protocole RTP ainsi que le protocole SDP (Session Description Protocol). Le format de charge utile pour le transport de données par le protocole RTP, « RTP payload format » en anglais, encore appelé format de transport dans la suite du document, est défini pour le codec EVS dans la spécification 3GPP TS 26.445 Annexe A. On rappelle que le codec EVS (pour « Enhanced Voice Services » en anglais) a été normalisé à l’organisme 3GPP, fin 2014. Il est actuellement défini dans trois versions de codes sources : • Code source en virgule fixe (3GPP TS 26.442) • Code source en virgule flottante (3GPP TS 26.443) • Version alternative du code source en virgule flottante (3GPP TS 26.452) Il fonctionne avec des trames de 20 ms et à différentes fréquences d’échantillonnage (8, 16, 32, 48 kHz) pour des signaux monos. Les signaux stéréo ou multicanaux peuvent être codés en multi-mono uniquement, c’est-à-dire en codant séparément les canaux, sans métadonnées possibles. Le codec EVS définit 4 types de bandes audio : - bande étroite dite Narrowband (NB) - bande élargie dite Wideband (WB) - bande super-élargie dite Super-wideband (SWB) - pleine bande dite Fullband (FB) Il comprend deux modes d’opération : Mode « Primary » : dans ce cas il fonctionne à débit constant de 7.2 kbit/s à 128 kbit/s et comprend aussi un mode spécial appelé VBR avec un débit moyen de 5.9 kbit/s – ces débits sont désignés par « EVS primary modes » (ou « primary modes »). Mode rétrocompatible avec AMR-WB dit « AMR-WB IO » : dans ce cas il fonctionne aux débits AMR-WB, soit 6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85 kbit/s. Par ailleurs, le codec EVS permet le codage optimisé de silences par transmission discontinue ou « discontinuous transmission » (DTX) ce qui inclut une détection d’activité vocale ou « voice activity detection » (VAD) et une génération de bruit de confort ou « comfort noise generation » (CNG). Quand le DTX est activé, les trames inactives sont codées par des trames de type descripteur d’insertion de silence ou « Silence Insertion Descriptor » (SID) qui sont en général envoyées toutes les 160 ms. De plus, EVS inclut un mode spécial dit “channel-aware mode” (CAM) limité à 13.2 kbit/s en WB et SWB, et qui utilise une redondance partielle pour améliorer la robustesse aux pertes de trames. Le format de transport pour transporter sur protocole RTP des données codées par EVS est défini à l'annexe A de la spécification TS 26.445. Ce format est illustré aux figures 1a à 1i. Il existe deux modes différents pour former des paquets EVS : • Le mode par défaut : les paquets sont soit au format "Compact", soit au format "Header-full", pour éviter des conflits de taille entre ces deux modes, la priorité est donnée au mode Compact dont les tailles sont "protégées", tandis que les tailles du mode "Header-full" sont pénalisées en ajoutant un bourrage de zéros (zero padding) en cas de conflit avec une taille du mode "Compact". • Le mode "Header-full" qui consiste à ajouter des entêtes de payload (un octet de CMR pour « Codec Mode Request » selon le paramètre SDP « cmr », un ou plusieurs octet(s) ToC pour « Table of Content » pour décrire les trames multiplexées et pouvoir les extraire) avant les données codées qui correspondent à une ou plusieurs trames codées. Des exemples de charge utile RTP au format "Compact" sont données aux figures 1a et 1b pour les cas EVS Primary et EVS AMR-WB IO, respectivement; on observe en particulier que pour EVS Primary la charge utile se résume aux données codées SD (pour « Speech data » en anglais), sans aucune entête de transport et sans aucune possibilité de signaler une requête d'adaptation ( FIG. 1 ); pour EVS AMR-WB IO, les données codées en mode "Compact" sont réorganisées (certains bits sont permutés) et un champ de requête de changement de mode de codec CMR (pour « Codec Mode Request » en anglais) réduit à 3 bits est défini comme entête ( FIG. 1 ). Ce cas particulier de CMR sur 3 bits n'est pas détaillé ici. Des exemples de charge utile RTP au format "header-full" sont donnés aux figures 1c et 1d. Dans le premier cas ( FIG. 1 ), une seule trame est transportée et un octet (8 bits) d'entête ToC (pour "Table of Content" en anglais) est inséré. Dans le second cas ( FIG. 1 ), deux trames sont transportées dans le même paquet avec 2 entêtes ToC (2 octets) et un champ CMR (1 octet) est également utilisé. Une définition détaillée de ces champs est donnée dans la spécification TS 26.445, Annexe A. Par souci de concision on ne reprend pas ici tous les détails de cette spécification. Le choix du mode de payload (soit par défaut ou soit header-full) est contrôlé par le paramètre SDP (Session Description Protocol) du codec EVS appelé « hf-only ». On ne revoit pas ici la liste complète des paramètres SDP du codec EVS (voir 3GPP TS 26.445 Annexe A), mais on rappelle qu’il existe des paramètres globaux, des paramètres propres au mode EVS Primary (ex : « br » ou « bw ») et des paramètres propres à EVS AMR-WB IO (ex : « mode-set »). Il est possible d’adapter le codec EVS par des requêtes de changement de mode de codec « Codec Mode Request » en anglais, CMR, qui est une forme de signalisation dans la bande (ou « in band » en anglais), c’est-à-dire dans le flux RTP. Le CMR n’est pas possible en format « compact » sauf pour EVS AMR-WB IO (avec des restrictions). Pour EVS, en mode header-full, l’octet CMR (8 bits) est divisé en trois parties représentées à la FIG. 1 : • H (1 bit) : toujours à 1 (spécifiant une requête CMR) • T (3 bits): bits indiquant le type de requête pour distinguer les différents modes EVS Primary en NB, WB, SWB, FB (dont les modes VBR, CAM) et EVS AMR-WB IO. • D (4 bits): requête CMR Les valeurs possibles du champ CMR sont définies dans la spécification TS 26.445, Annexe A et précisent les différents modes que peut prendre le codec. Elles sont rappelées à la FIG. 1 . On peut observer que certaines valeurs sont indiquées comme non utilisées ‘Not Used’ ou réservées ‘Reserved’ et une valeur indiquée à ‘NO_REQ’ est une requête CMR vide. De façon similaire pour EVS l’octet ToC (8 bits) est divisé en 3 parties représentées à la FIG. 1 : • H (1 bit): toujours à 0 (pour distinguer l’octet comme étant un champ ToC et non CMR) • F (1 bit): Si F=1, une autre trame suit la trame courante, si F=0, il s'agit de la dernière trame du paquet. • FT (6 bits): bits indiquant le "Frame type" soit EVS Primary ou EVS AMR-WB IO (incluant le mode SID). Ce champ est lui-même divisé en 3 parties définies dans les tableaux représentés en figures 1h et 1i et telles que définies aux tables A.4 et A.5 de la spécification 3GPP TS 26.445: EVS mode (1 bit), Unused/Q bit (1 bit) selon le bit de mode EVS, et débit EVS (4 bits). A noter que pour EVS il est également possible d'ajouter un bourrage de bits (des octets de "padding") à la fin du payload. Dans ce cas le bit "P" '(pour "Padding") dans l'entête RTP peut être - de façon optionnelle - mis à 1 et les bits supplémentaires doivent être ajoutés; le dernier octet de ce "padding" contient le nombre d'octets ajoutés à la fin du payload (incluant ce dernier octet). Le codec IVAS (Pour « Immersive Voice and Audio Services » en anglais) est en cours de définition. Une description haut-niveau de l’état actuel du codec est donnée dans 3GPP TS 26.250 V1.0.0 datant du 15/09/2023. Le codec IVAS est une extension du codec EVS pour représenter les formats stéréo et immersifs. Il est identique à EVS pour le codage mono. Pour les formats stéréo et immersifs, le débit du codec IVAS va de 13,2 à 512 kbit/s (avec des restrictions selon le format exact). Les différents formats d’entrée de l’encodeur IVAS sont définis dans le tableau 1 ci-dessous : Type de format Nom du format d’entrée Description mono MONO Mono (EVS) 2 canaux STEREO Stereo BINAURAL Binaural ISM (Independent Stream with Metadata) ISM1 1 objet mono avec métadonnées ISM2 2 objet mono indépendants avec métadonnées ISM3 3 objet mono indépendants avec métadonnées ISM4 4 objet mono indépendants avec métadonnées SBA (scene-based audio) FOA Ambisonique à l’ordre 1 HOA2 Ambisonique à l’ordre 2 HOA3 Ambisonique à l’ordre 3 MC (multichannel) MC51 Multicanal 5.1 MC71 Multicanal 7.1 MC512 Multicanal 5.1+2 MC514 Multicanal 5.1+4 MC714 Multicanal 7.1+4 MASA (Metadata Assisted Spatial Audio) MASA1 Format MASA (metadata-assisted spatial audio) à 1 canal MASA2 Format MASA (metadata-assisted spatial audio) à 2 canaux OSBA (object-based audio with scene-based audio) OSBA Combinaison de FOA/HOA2/HOA3 et ISM OMASA (object-based audio with metadata-assisted spatial audio) OMASA Combinaison de MASA et ISM Il n’est pas exclu que d’autres modes de codage soient introduits plus tard dans le développement du codec, par exemple pour des applications de rendu immersif divisé entre un pré-rendu dans le réseau (edge ou cloud) et une diffusion d’un signal pré-rendu vers un terminal en utilisant au moins un autre format du codec IVAS qui n’est pas listé au tableau 1. Le débit du codec IVAS dépend en fait du format d’entrée (en bit/s) : Mono : identiques à EVS Stéréo : 13200, 16400, 24400, 32000, 48000, 64000, 80000, 96000, 128000, 160000, 192000, 256000 ISM : ISM1 : 13200, 16400, 24400, 32000, 48000, 64000, 80000, 96000, 128000 ISM2 : 16400, 24400, 32000, 48000, 64000, 80000, 96000, 128000, 160000, 192000, 256000 ISM3 : 24400, 32000, 48000, 64000, 80000, 96000, 128000, 160000, 192000, 256000, 384000 ISM4 : 24400, 32000, 48000, 64000, 80000, 96000, 128000, 160000, 192000, 256000, 384000 SBA, MASA, MC : 13200, 16400, 24400, 32000, 48000, 64000, 80000, 96000, 128000, 160000, 192000, 256000, 384000, 512000 Si des formats supplémentaires sont ajoutés au tableau 1, on peut supposer que le débit serait défini parmi ces débits allant de 13200 à 512000 bit/s. Les différents formats de sortie du décodeur/ « renderer » IVAS sont définis dans le tableau 2 ci-dessous : Type de format Nom du format d’entrée Description mono MONO Mono stéréo STEREO Stereo binaural BINAURAL Binaural (avec / ou sans réverbération) MC (Multichannel) 5_1 Multicanal 5.1 7_1 Multicanal 7.1 5_1_2 Multicanal 5.1+2 5_1_4 Multicanal 5.1+4 7_1_4 Multicanal 7.1+4 custom Configuration “custom” des hauts-parleurs SBA (Scene-Based Audio) FOA Ambisonique à l’ordre 1 HOA2 Ambisonique à l’ordre 2 HOA3 Ambisonique à l’ordre 3 External External Format “propriétaire” pour un renderer externe Il est important de noter que le retard algorithmique du codec IVAS dépend du format de codage/décodage, il est de 32 ms pour le format stéréo et il va de 32 à 38 ms pour les autres formats d’entrée que stéréo. Le format de charge utile pour transport de données par le protocole RTP, encore appelé format de transport (« payload format ») pour le codec IVAS n’est pas encore défini. Deux propositions ont été récemment publiées : Une première proposition est donnée dans le document du lien suivant, datée du « 7 septembre 2023 : https://forge.3gpp.org/rep/ivas-codec-pc/ivas-codec/-/wikis/uploads/5d3146bd2f9548a609c3f2d1ef431363/ivas-rtp-payload-format.pdf Cette première proposition suppose que le format de transport du codec IVAS est différent d’EVS. Dans cette proposition, aucun mode compact n’est proposé afin de ne garder qu’un mode de type « header-full » et ainsi éviter des complications et dépendances à un paramètre SDP. Pour pouvoir commuter dans un même appel entre un mode mono (EVS) et un mode immersif (IVAS), il faudrait selon cette proposition négocier les deux formats de transport en même temps, ce qui n’est pas possible dans les services multimédias sur IMS (pour « IP Multimedia SubSystem » en anglais). De plus, dans une communication asymétrique où le sens montant (uplink) envoie par exemple un signal mono codé et le sens descendant (downlink) reçoit un signal codé immersif, comme dans un scénario de pont de conférence spatialisée, la première proposition implique que deux codecs différents sont instanciés dans chaque sens (EVS et IVAS) d’un point de vue format de transport (« payload format »). Une deuxième proposition est donnée dans le document du lien suivant, datée du « 11 septembre 2023 : https://forge.3gpp.org/rep/ivas-codec-pc/ivas-codec/-/wikis/uploads/23f8cb74ba3631300f44804d2640f46f/Nokia-IVAS-RTP-Payload-draft-v1.pdf Cette deuxième proposition définit un mode compact pour IVAS ce qui implique une liste de tailles de paquet protégées. Cependant, si le mode compact était également conservé pour le format mono d’IVAS qui correspond à EVS, il y aurait un conflit entre les tailles de paquets EVS Primary (mono) et IVAS ; il faudrait rajouter des règles supplémentaires de bourrage de zéro soit sur EVS Primary soit sur IVAS, ce qui n’est pas attractif. Cette proposition ne définit aucun CMR pour IVAS, et s’appuie sur le protocole RTCP (pour « Real-Time Control Protocol » en anglais) pour véhiculer des requêtes d’adaptation, alors que la voix sur IMS s’appuie sur le profil RTP appelé AVP (pour « Audio Video Profile » en anglais) et non AVPF (pour « Audio Video Profile with Feedback » en anglais). Ainsi l’usage de RTCP (RTCP-APP ou RTCP-FB) n’est pas possible dans ce contexte de services multimédias sur IMS. Cette deuxième proposition change le format d’octet ToC (pour "Table of Content" en anglais) défini pour EVS (TS 26.445 Annexe A) pour inclure dans le cas d’IVAS des informations de signalisation supplémentaires et une indication de débit sur 4 bits. On notera que même si le format mono semble être pris en compte, les débits associés à EVS ne sont pas explicitement listés, ce qui implique que le format mono (EVS) n’est pas vraiment transporté en mode compact. Cette proposition ajoute également une idée nouvelle de transport de trames dites « processing information » pour véhiculer des informations non audios telles que l’orientation d’un terminal, l’importance d’un format. Ainsi, les propositions existantes de format de transport pour le codec IVAS, ne sont pas compatibles avec des applications de transport de voix ou de services multimédias sur IMS, ce qui peut être problématique pour un déploiement des codecs dans des services de communication. De plus, ces différentes propositions ne permettent pas de commuter facilement dans un même appel entre un mode mono utilisant un codec de type EVS et un mode immersif utilisant un seul codec de type IVAS, sans avoir à couper et relancer un appel. Elles ne permettent pas d’assurer une continuité de service entre le format mono (EVS) et les formats stéréo/immersifs (IVAS) L’invention vient améliorer l’état de la technique. A cet effet, l’invention vise un procédé de génération de format de transport de données audio lors d’une session de communication entre dispositifs de communication, dans lequel le format de transport de données pour un codec audio étendu, étendant un codec audio mono, réutilise le format de transport de données dudit codec audio mono, et où au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. De la même façon, l’invention vise un procédé de réception de format de transport de données audio lors d’une session de communication temps réel entre dispositifs de communication, dans lequel le format de transport de données pour un codec audio étendu étendant un codec audio mono, réutilise le format de transport de données dudit codec audio mono, et où au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. Ainsi, un seul format de données est spécifié à la fois pour le codec étendu IVAS et le codec EVS, ce qui permet d’une part de commuter facilement d’un codec à un autre lors d’un même appel, de façon compatible avec les services multimédias sur IMS qui ne peuvent sélectionner qu’un seul format de transport et de ne négocier qu’un seul format de transport. Selon un premier mode de réalisation, un champ non utilisé et existant du format de transport de données dudit codec audio mono est utilisé pour signaler le codec audio étendu et un autre champ est utilisé pour transmettre au moins des informations du débit du codec audio étendu. Cela permet de rester au maximum compatible avec le format mono existant en cas de commutation en gardant la signification de toutes les autres valeurs prédéfinies intactes, et ainsi maximiser la rétrocompatibilité avec le format mono existant. Dans un deuxième mode de réalisation, au moins un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono est utilisé pour transmettre au moins des informations du débit d’un codec étendu à utiliser. Dans un mode de réalisation particulier, chacun des débits possibles du codec étendu est indiqué dans un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec mono. Là encore, cela permet de rester au maximum compatible avec le format mono existant en cas de requête pour basculer d’un mode stéréo/immersif à un mode mono, en gardant la signification de toutes les autres valeurs CMR prédéfinies intactes, et ainsi maximiser la rétrocompatibilité avec le format mono existant. Ce mode de réalisation n’utilise qu’un seul octet pour la requête CMR. Dans une variante de réalisation, une seconde requête d’adaptation spécifiant au moins un format et/ou une bande audio du codec étendu est insérée à la suite de la dite requête. Selon un troisième mode de réalisation, un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono est utilisé pour informer de l’existence d’un second code spécifiant un format et/ou un débit du codec étendu à utiliser. De la même façon, un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono est utilisé pour informer de l’existence d’un second code spécifiant un format et/ou un débit du codec étendu utilisé en émission. Les avantages sont similaires au deuxième mode de réalisation, avec cependant un inconvénient qui rend ce troisième mode moins avantageux en termes de débit supplémentaire, en revanche le rend plus général par l’utilisation d’un octet supplémentaire qui permet de signaler un changement de format immersif. L’invention vise un terminal de communication comportant un circuit de traitement apte à mettre en œuvre un procédé de génération de format de transport de données audio lors d’une session de communication temps réel avec un dispositif de communication, dans lequel le format de transport de données pour un codec audio étendu, étendant un codec audio mono, réutilise le format de transport de données dudit codec audio mono, au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, étant utilisé pour signaler le codec audio étendu et/ou transmettre au moins des informations du débit du codec audio étendu. L’invention se rapporte également à un format de transport de données audio pour un codec audio étendu réutilisant un format de transport de données d’un codec audio mono dans lequel au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. Un tel format de transport est conforme à l’un quelconque des modes de réalisation décrits précédemment. L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de génération conforme à l'invention, selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. De telles instructions peuvent être stockées durablement dans un support mémoire non transitoire du terminal de communication mettant en œuvre le procédé de transport selon l’invention. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise également un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus. Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile, un disque dur ou un SSD. D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par un exemple un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé transport précité. Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : FIG. 1 , FIG. 1 , FIG. 1 , FIG. 1 , FIG. 1 , FIG. 1 , FIG. 1 , FIG. 1 et FIG. 1 illustrent le format de transport défini pour le codec EVS, décrits précédemment ; FIG. 2 illustre un mode de réalisation d’un système de communication voix sur IP et d’un procédé de génération d’un format de transport de données selon un mode de réalisation de l’invention ainsi qu’un procédé de réception d’un tel format de transport données ; FIG. 3 , FIG. 3 , FIG. 3 et FIG. 3 illustrent un premier mode de réalisation selon l’invention d’un format de transport adapté au codec étendu IVAS étendant un codec audio mono EVS, et au codec mono EVS par l’utilisation d’un champ non utilisé et existant du format de transport de données du codec audio mono pour signaler le codec audio étendu et par l’utilisation d’un autre champ pour transmettre au moins des informations du débit du codec audio étendu ; FIG. 4 , FIG. 4 , FIG. 4 , FIG. 4 et FIG. 4 illustrent un deuxième et troisième mode de réalisation selon l’invention d’un format de transport adapté au codec étendu IVAS et au codec mono EVS par l’utilisation d’au moins un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono pour transmettre des informations du débit du codec étendu à utiliser ; FIG. 5 illustre un quatrième mode de réalisation selon l’invention d’un format de transport adapté au codec étendu IVAS et au codec mono EVS par l’utilisation d’au moins un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono pour informer de l’existence d’un second code spécifiant un format et/ou un débit du codec étendu à utiliser en réception ou en émission ; FIG. 5 et FIG. 5 illustrent les codes de formats de codage étendu et les codes de débit spécifiés par ce second code selon la réception ou l’émission ; FIG. 6 illustre un quatrième mode de réalisation selon l’invention d’un format de transport adapté au codec étendu IVAS et au codec mono EVS par l’utilisation des champs tels que définis à la FIG. 4 et à la FIG. 5 ; et FIG. 7 illustre un mode de réalisation matérielle d’un terminal mettant en œuvre le procédé de génération de format de transport de données selon un mode de réalisation ainsi qu’un procédé de réception d’un tel format de transport données. L’invention va maintenant être décrite ci-dessous en référence aux figures 2 à 7. La FIG. 2 illustre un exemple de système de communication bidirectionnel entre deux dispositifs de communication A et B, par exemple deux terminaux de communication A et B ou un terminal de communication A et un équipement réseau B (ou vice-versa). Les dispositifs de communication mettent en œuvre un procédé de génération de format de transport de données audio selon un mode de réalisation de l’invention. Le signal acoustique ambiant est par exemple capté par un ou plusieurs microphones (101 et 151) de chaque côté de la communication. Le signal distant est restitué sur un ou plusieurs haut-parleurs (102 et 152). Les signaux audios captés et restitués subissent en général différents traitements acoustiques en émission (101 et 151) et en réception (103 et 153) comme par exemple : • conversion analogique/numérique, contrôle de gain, réduction de bruit, annulation d'écho, etc…, en émission • conversion numérique/analogique, contrôle de gain, etc…, en réception. La figure ne représente pas ici les traitements acoustiques ni le réseau (dont les traitements et équipements de type antennes, modem, …) reliant les deux terminaux, par souci de concision et de clarté. Dans un mode de réalisation, un des dispositifs A ou B peut être remplacé par un équipement réseau, qui peut être une « media gateway » (ex : IMS-AGW), un pont de conférence (ex : MRFP), un serveur de boite vocale, etc. Pour ne pas alourdir le texte, on décrit par la suite l’exemple d’une communication entre deux terminaux A et B, avec la compréhension que l’un des terminaux peut être une terminaison réseau (sans prise de son / rendu acoustique en général). Dans le cas où l’un des terminaux est un équipement réseau, l’interface fournissant les signaux en entrée du codeur ou récupérant les signaux en sortie du décodeur/renderer est directement électrique. Le terminal A comporte un émetteur 101 et un récepteur 103 tandis que le terminal B comporte un émetteur 151 et un récepteur 153. Les deux terminaux A et B sont typiquement configurés en fonction d’un échange d’offre(s)/réponse(s) selon le protocole SDP (pour « Session Description Protocol » en anglais), via les blocs respectifs 100 et 150. Typiquement cette configuration SDP sert au moins lors de l’instanciation (initialisation ou ré-initialisation) de l’émetteur et du récepteur ; dans des variantes de l’invention on pourra considérer que cette configuration est interne au terminal et permet de configurer l’offre SDP du terminal et sa réponse. Dans des variantes de l'invention d'autres protocoles de signalisation de capacités/configurations média (descriptions de session) équivalents ou dérivés de SDP pourront être utilisés de façon équivalente. Les émetteurs ont des fonctions de codage, de génération de paquets RTP en rajoutant les entêtes protocolaires pour générer un format de transport (payload format) correspondant au format de codage. Un émetteur a également une fonction d’adaptation éventuelle du transport (agrégation, redondance ou autre) ainsi qu’une fonction de transmission des paquets. Ainsi, un émetteur d’un dispositif de communication tel que décrit met en œuvre un procédé de génération de format de transport de données audio lors d’une session de communication temps réel avec un autre dispositif de communication. Pour cela, comme décrit plus en détails ultérieurement, le format de transport de données pour un codec audio étendu (IVAS) étendant un codec audio mono (EVS), réutilise le format de transport de données dudit codec audio mono. Au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. Les récepteurs ont des fonctions de réception des paquets RTP, d’extraction des champs de l’entête RTP, de décodage du format de transport et décodage des trames qui peut inclure la gestion de buffer de gigue, le décodeur audio et la correction de pertes de trames perdues. Ainsi un récepteur d’un dispositif de communication est apte à recevoir et décoder un format de transport tel que généré par un émetteur d’un autre dispositif de communication. Pour cela, il extrait au moins un champ non utilisé et existant du format de transport de données du codec audio mono (EVS) et vérifie s’il signale le codec audio étendu (IVAS) et/ou donne des informations du débit du codec audio étendu (IVAS). Dans un mode de réalisation décrit ultérieurement, c’est un autre champ du format de transport de données qui est utilisé pour transmettre au moins des informations du débit du codec audio étendu. Les terminaux A et B comportent un bloc de décodage de requête (blocs 107 et 157), en particulier de requêtes CMR telles que décrites aux figures 4 à 6 ultérieurement. Le bloc 107 ou 157 consiste à lire la partie concernée du paquet associé au codec (IVAS incluant EVS). On suppose ici que le résultat du décodage de requête par les blocs 107 et 157 est par exemple mémorisé dans un élément mémoire appelé ici "adaptation_info" contenant une structure partagée avec la partie émission (blocs 101 et 151) et cet élément "adaptation_info" comprend lui-même un élément mémorisé "adaptation_info.updated" qui vaut 1 quand une requête (CMR ou autre) a été reçue et 0 sinon. Le bloc 101 ou 151 vérifie, avant de coder chaque nouvelle trame, si la valeur de "adaptation_info.updated" est à 1 et si c’est le cas il configure le codage selon le débit demandé ou le format de données demandé. Plusieurs modes de réalisation pour la génération du format de transport de données lors d’une communication entre les deux terminaux A et B et le format de transport de données sont maintenant décrits. Ce format de transport de paquets de données échangé entre les terminaux est compatible avec le codage et décodage immersif de signal audio tel que mis en œuvre par un codec IVAS. Ce format de transport de données est également rétro compatible avec le codage et décodage s’un signal audio mono par exemple mis en œuvre par un codec mono EVS. Ce format de transport de données peut également être utilisé pour le stockage de données et donc être enregistré dans une mémoire accessible par les terminaux de communication. Avant de détailler un exemple détaillé de format de transport pour IVAS, on s’intéresse d’abord aux cas d’usage du codec IVAS. Le cas d’usage le plus simple pour IVAS comprend un appel entre deux terminaux connectés sur un réseau, par exemple 5G. Ces terminaux peuvent être des smartphones équipés de plusieurs microphones et supporter les formats suivants : Mono : cas de repli sur un appel compatible EVS, étant donné qu’EVS est inclus dans IVAS Stéréo avec prise de son sur 2 micros du téléphone ou avec son stéréo issu d’un traitement d’une antenne microphonique Binaural : uniquement dans le cas où un téléphone est connecté à des oreillettes qui intègrent des microphones et ainsi capter un son binaural naturel MASA : format avec un signal mono ou stéréo complété par des informations spatiales issues d’une analyse de scène comme décrit dans 3GPP Tdoc S4-220443, “MASA format updates,” April 2022, Source: Nokia, Orange Cette liste n’est pas exhaustive, cet exemple permet simplement de montrer que le format de codage supporté et affiché dans SDP pour IVAS serait par exemple une liste : [MONO, STEREO, BINAURAL, MASA1, MASA2] On peut considérer que le format MONO est redondant dans cette liste et qu’il est forcément inclus comme format de base dans le codec IVAS puisqu’EVS est inclus dans IVAS. On peut aussi considérer que STEREO et BINAURAL sont des formats à 2 canaux qui sont codés de façon quasiment identique, donc ils pourraient être associés en un seul type de format codé pour la définition des capacités du terminal : la principale justification de différencier BINAURAL est pour adresser les cas d’usage où des microphones sont placés sur des oreillettes en cours de communication, alors que STEREO est pour les microphones sur un smartphone. De même MASA1 et MASA2 pourraient être tous les deux supportés mais dans un appel à priori seul un type de format devrait être utilisé à la fois, même si en théorie les traitements acoustiques pourraient être en amont de l’analyse MASA et donc permettre une commutation en temps-réel. Si les deux terminaux A et B ont les mêmes capacités de codage/décodage/rendu, le terminal recevant une telle offre pourrait soit choisir un format unique, soit garder une liste (complète ou partielle) ce qui suppose une commutation de format potentielle possible pendant l’appel. En réalité il semble plus réaliste et plus simple de ne sélectionner qu’un format stéréo ou immersif, avec éventuellement la possibilité de dégrader le nombre de canaux dans un même type de format, en particulier à l’émission pour garder une prise de son cohérente dans le temps, découplée du codage. Dans IVAS il n’y a pas de signalisation interne au train binaire du codec pour différencier STEREO et BINAURAL, donc il est important de négocier des formats différents, de sorte que le rendu puisse s’adapter et que le terminal en réception n’accepte le BINAURAL que lorsqu’un casque d’écoute ou des oreillettes sont utilisés pour une écoute directe. Le fait de garder plus qu’un format stéréo/immersif soulève également une ambiguïté liée à l’ordre des formats qui normalement indique une préférence (du meilleur au moins bon). Par la suite on suppose qu’un seul format stéréo/immersif est sélectionné en SDP par le récepteur d’une offre SDP IVAS – cela autorise cependant de potentiellement réduire ou augmenter le nombre de canaux (par exemple de HOA3 à FOA, ou 5.1 à stéréo et inversement) dans la limite du format maximal négocié (par exemple HOA3 ou 5.1). Les règles de sélection de format restent à définir si plus d’un format est proposé et supporté, elles dépassent le cadre de l’invention. Si un changement de format de codage est nécessaire, alors une renégociation SDP doit être employée. Ce cas d’usage simple se complique si l’on imagine un scénario où l’un des terminaux passe d’un réseau 5G (avec support d’IVAS) à un réseau 4G ne supportant que le codec EVS. Dans ce cas de « handover », il est important de ne pas couper l’appel et si possible d’éviter une renégociation de codec de bout en bout en cours d’appel – ce qui impliquerait un long temps d’interruption - et aussi d’éviter un transcodage entre IVAS et EVS dans une passerelle média (« media gateway ») dans le réseau. On rappelle aussi qu’EVS est typiquement utilisé avec des débits de 5.9 à 13.2 ou 24.4 kbit/s dans une bande de type « nb-wb » ou « nb-swb » ou encore « swb », tandis que les débits d’IVAS ne débutent qu’à partir de 13.2 kbit/s et la bande NB n’est pas supportée par IVAS (hors mono). Il est donc important que le format de payload IVAS prenne en compte ces contraintes. Dans le cas de « handover », on pourrait aussi imaginer que certaines solutions réseaux préfèrent malgré tout transcoder entre IVAS et EVS dans une « media gateway » (MGW) pour éviter de gérer trop finement les cas de « handover » ; cependant, il serait possible par exemple que la MGW ne supporte toutes les combinaisons de format / débit / bande codée (ex : bande FB) et la MGW pourrait envoyer un CMR à un des terminaux pour forcer le codeur à changer de format / débit / bande. On peut également prendre un autre exemple de cas d’usage où un terminal compatible IVAS (et donc EVS puisqu’IVAS inclut EVS) se connecte à un pont de conférence spatialisée ou une plateforme de jeu vidéo. Typiquement le téléphone pourrait n’envoyer qu’en mono mais recevoir par exemple en binaural ou même dans un format multicanal comme 5.1. Si le terminal recevant un flux immersif est connecté à un casque d’écoute ou des oreillettes il semble préférable de recevoir ou décoder un signal binaural. Dans tous les cas le terminal en réception pourrait indiquer ses capacités de décodage et rendu (renderer) sous la forme d’une liste comme avec des éléments séparés par des tirets pour indiquer que certains formats sont inclus dans d’autres et indiqués sous la forme d’un intervalle de type format minimal-format maximal (ex : STEREO-5_1), ce qui donnerait une liste de capacité de décodage/rendu comme : [MONO, BINAURAL, STEREO-5_1] La partie réception dépend en général d’une chaîne audio de rendu qui doit être initialisée mais qui peut être découplée du décodage, ce qui permet de passer d’un casque à une écoute sur un haut-parleur unique d’un smartphone puis un système 5_1 dans un véhicule ou une salle de réunion. Ainsi, contrairement au cas de l’émission, il est moins problématique de signaler une liste de formats possible en réception. Par contre, il peut y avoir une certaine ambiguïté sur l’ordre à utiliser qui pourrait indiquer une préférence, mais on peut supposer que le terminal en réception utiliserait le format le plus approprié en fonction du contexte de rendu/d’écoute. Là encore, ces aspects de négociation restent ouverts et dépassent le cadre de l’invention. Par contre, il est important de prendre en compte la présence de paramètres SDP qui peuvent impacter le format de transport. On suppose ici que les paramètres existants pour EVS sont repris dans IVAS et qu’on rajoute au moins un paramètre supplémentaire appelé par exemple « fmt-send » permettant de négocier les capacités de format stéréo/immersif codé. On peut aussi considérer qu’un terminal peut aussi déclarer un autre paramètre spécifique à IVAS « fmt-recv » qui indiquerait quels formats de réception sont supportés pour le rendu, ce qui permet d’éviter de sélectionner par exemple un codage en MC714 si le rendu est limité à STEREO. Dans les modes de réalisation décrits ci-dessous, on spécifie des formats de transport du codec immersif IVAS permettant : d’assurer une continuité de service entre les codecs IVAS et EVS s’assurer d’un repli possible au format mono du codec EVS prévu dans le codec IVAS, même si l’appel en cours a été négocié pour un format d’entrée / sortie immersif (stéréo, etc.). Ainsi, il est possible d’utiliser le codec IVAS mais de commuter au codec EVS dans un bout de la chaîne sans arrêter ou renégocier un appel. de définir un format de transport du codec IVAS le plus simple possible comme une extension naturelle du format de transport du codec EVS. Ainsi, selon les modes de réalisation décrits ci-dessous, le format de transport de données audio pour un codec audio étendu (IVAS) utilise une extension d’un format de transport de données d’un codec audio mono (EVS), au moins un champ existant du format de transport de données du codec audio mono, non utilisé ou réservé, étant utilisé pour transmettre au moins des informations du débit du codec audio étendu (stéréo/immersif) ou pour signaler le codec audio étendu. Avant de décrire différents modes de réalisation selon l’invention, on donne d’abord des exemples illustrant comment le codec IVAS pourrait être négocié comme une extension du codec EVS au niveau SDP. Ces exemples ne sont en aucun cas définitifs car le format de payload est encore totalement ouvert. L’annexe 1 décrit une offre SDP (simplifiée) du terminal A Ce premier exemple traite d’une offre SDP qui permet d’initier un appel audio avec le codec IVAS incluant le codec EVS. Le port UDP, le profil AVP et le type du payload (PT) sont indiqués dans la ligne media « m ». Les numéros de type de payload sont PT=96 pour IVAS ou 97 pour EVS. Les parties « rtpmap » et « fmtp » indiquent les paramètres du format du media. On suppose ici qu’IVAS et EVS sont proposés dans l’offre avec le « telephone event » usuel en téléphonie. L’annexe 2 décrit un exemple possible de réponse SDP (simplifiée) du terminal B. Iici on considère que seule l’offre IVAS est retenue avec des restrictions et le « telephone event » est aussi conservé (typiquement obligatoire pour les services de téléphonie). Les paramètres SDP à l’annexe 1 et 2 ne sont ici décrits qu’à titre illustratif. Pour simplifier, on suppose que les paramètres existants (br, bw) sont réutilisés et étendus, et on a rajouté des paramètres spécifiant les formats de codage et rendu supportés par les terminaux (sous la forme d’une liste entre crochets). On considère ici que les paramètres SDP d’EVS correspondants au MONO sont différenciés des paramètres SDP d’IVAS, en effet IVAS a des particularités comme un débit commençant à 13.2 kbit/s ou une bande audio NB qui n’est pas supportée, ce qui oblige à différencier en général ces paramètres. Des règles peuvent être définies pour assurer une cohérence, par exemple sur le paramètre « cmr ». Dans un premier mode de réalisation, l’extension du format de transport s’effectue en prévoyant une extension du format de données d’entête définissant la table de contenu « ToC » d’EVS. On s’intéresse ici au format de transport du codec EVS du mode « header-full ». Selon ce mode de réalisation, on a comme octet ToC, le même format qu’EVS qui est repris et étendu pour IVAS. Ainsi l’octet ToC d’IVAS a comme définition la même que l’octet ToC d’EVS illustré en FIG. 1 et décrit ci-dessus. Le premier bit H=0 permet de distinguer un octet ToC d’un octet CMR en entête de payload. Le bit F vaut 1 si la trame codée correspondant à l’octet ToC est suivie par une autre trame. Il vaut 0 si la trame correspondante est la dernière dans le payload, ce qui implique que l’octet ToC est le dernier et qu’aucun autre octet ToC ne suit celui-ci. Dans le premier mode de réalisation, l’octet ToC pour IVAS reprend la structure de l’octet ToC d’EVS comme montré à la FIG. 3 . Le champ FT_IVAS (6 bits) est défini selon les tableaux représentés en figures 3b, 3c, 3d. A la FIG. 3 , on y voit la même configuration que pour le codec EVS en FIG. 1 , c'est-à-dire que le champ FT est divisé en 3 parties EVS mode (1 bit), Unused/Q bit (1 bit) selon le bit de mode EVS, et débit EVS (4 bits). Cependant, ici, le champ « Unused/Q bit d’EVS est remplacé par un champ spécifiant l’utilisation d’un codec IVAS (bit à 1) ou non (bit à 0). Si ce champ est à 0, on reste dans la définition du tableau de la FIG. 1 , en revanche, si ce bit est à 1, alors le champ suivant indiquant pour EVS les débits possibles, va utiliser les mêmes codes pour cette fois indiquer les débits possibles du codec IVAS. La FIG. 3 illustre ce cas de figure où on voit que le premier champ sur 1 bit, à 0, montre le mode EVS ou IVAS (à l’inverse du mode AMR WB IO de la FIG. 1 ), le deuxième champ sur 1 bit (à 1) montre que le codec IVAS est utilisé et les codes du champ suivant sur 4 bits indiquent les différents débits possibles du codec IVAS (de 13.2 à 512 kbit/s, ainsi que IVAS SID et SPEECH_LOST). Ici IVAS SID correspond aux trames SID codées correspondant aux trames inactives quand le mode DTX d’IVAS est activé ; SPEECH_LOST indique une trame perdue. La FIG. 3 est identique à la FIG. 1 pour la partie EVS AMR-WB IO. Ainsi, le format de transport issu du codec EVS est étendu pour le codec IVAS, une trame codée EVS peut être indiquée comme dans le payload format d’EVS et il n’est pas nécessaire de prévoir un autre format spécifique au codec IVAS car toutes les données nécessaires pour indiquer le type de trame IVAS peuvent être représentées en exploitant le bit inutilisé du champ FT dans le format de payload EVS. Dans des variantes, des extensions supplémentaires de l'octet ToC peuvent être prévues. Celles-ci ne sont pas décrites ici car elles restent en discussion et à définir pour le codec IVAS, mais elles peuvent être similaires par exemple à l'idée des "PI_frame" de la deuxième proposition citée dans l'état de l'art. Comme il n'y a aucun champ disponible dans la FIG. 3 , ces extensions pourraient être signalées de différentes façons. soit on utilise une extension d'entête RTP (hors payload) soit on prend un autre code comme le code 'For future use' de la FIG. 3 qui est normalement pour EVS Primary (EVS bit rate = '1101') mais qui dans le contexte IVAS indiquerait une trame de données spécifiques à IVAS. Dans un deuxième mode de réalisation, au moins un octet existant de requête d’adaptation de codec (CMR), comprenant un champ non utilisé ou réservé du codec audio mono EVS, est utilisé pour transmettre au moins des informations du débit du codec à utiliser, et de façon optionnelle on pourra selon l’invention rajouter un octet supplémentaire spécifique à IVAS. On s’intéresse ici au format de transport du codec EVS du mode « header-full ». Pour définir le format de transport du codec IVAS, on étend le format de transport du codec EVS en étendant l’utilisation de l’octet CMR. Ainsi l’octet CMR d’IVAS selon l’invention suit la même définition que l’octet CMR d’EVS illustré en FIG. 1 et repris ici à la FIG. 4 . décrit ci-dessus avec une extension mineure des champs T et D ; ce dernier est ici nommé D_IVAS pour le différencier du champ D défini dans EVS. Le premier bit H a comme valeur H=1 pour spécifier qu’une requête CMR existe. Les champs T (3 bits) et D_IVAS (4 bits) sont définis comme sur les tableaux de la FIG. 1 à l’exception des valeurs associées au champ T=’ 111’ qui sont modifiées selon les valeurs définies dans le tableau illustré à la FIG. 4 . Ainsi, les valeurs définies comme ‘Reserved’ dans le format CMR d’EVS sont maintenant définies comme des débits du codec IVAS de 13.2 à 512 kbit/s. Ce mode de réalisation permet donc de définir une requête d’adaptation du débit, c'est-à-dire le débit que le terminal émettant la requête CMR souhaite recevoir. Dans un troisième mode de réalisation, il sera possible d’autoriser – contrairement à EVS - d’avoir plus qu’un octet CMR dans un paquet pour le codec IVAS, comme illustré à la FIG. 4 . Si un CMR doit être transporté dans le paquet courant, on pourra d’abord insérer un premier octet en entête du payload dans le deuxième mode de réalisation et comme à la FIG. 4 , ce qui permet d’effectuer une requête de changer de débit IVAS ou un basculement vers un mode EVS mono - sauf si NO_REQ est utilisé, dans ce cas le CMR véhicule une requête « vide ». Ensuite, de façon optionnelle, on pourra ajouter un second octet CMR, dont le premier bit plus significatif H sera aussi mis à 1, pour différencier l’octet d’un octet ToC. Les 7 bits restants représentent alors un changement de format à l’émission, on peut par exemple utiliser les 5 derniers bits FMT_IVAS pour indiquer le format de codage comme à la FIG. 4 et les 2 autres bits BW_IVAS restant pour indiquer la bande audio (WB, SWB, FB pour IVAS) comme à la FIG. 4 . Cet ajout optionnel d’un second octet CMR ne pose aucun problème d’ambiguité pour l’écriture / la lecture du payload : à la lecture, on commence par lire le premier octet, si le bit MSB est à 1, il s’agit d’un CMR, ensuite on lit le deuxième octet, si le MSB est aussi à 1, il s’agit encore d’une requête CMR, et dans ce cas le troisième octet sera de type ToC avec un MSB à 0 selon l’invention. On note que la FIG. 4 inclut des champs reservés (Reserved) pour permettre une éventuelle extension des formats de codage d’IVAS, par exemple pour des applications de rendu séparé entre réseau (edge, cloud) et terminal selon la méthode de split rendering. Dans un quatrième mode de réalisation de l’invention, les valeurs associées au champ T=’ 111’ sont modifiées d’une autre façon, comme illustré à la FIG. 5 . Dans ce mode de réalisation, un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono EVS est utilisé pour informer de l’existence d’un second code spécifiant le débit du codec à utiliser en réception. Ainsi, dans l’exemple illustré à la FIG. 5 , les codes D=‘0000’ et D=’0001’ initialement définies comme « Reserved » pour le codec EVS, sont remplacés par d’autres codes nommés « Escape Input » et « Escape Output », où ‘escape’ est ici une indication d’extension d’un octet CMR par un autre octet. Ainsi, si l’octet CMR est défini par T = ‘111’ et D=’0000’, dans le cas de « Escape Input », cela indique qu’un octet CMR supplémentaire est défini immédiatement après le premier octet CMR et ce second octet a des valeurs par exemple selon le format CF (4 bits) BR (4 bits) tels que définis dans le tableau illustré à la FIG. 5 . Cet octet supplémentaire indique une requête pour changer le format de codage immersif (valeurs définis par le code CF pour « code format ») et/ou le débit (valeurs définies par le code BR pour « Bit rate ») en réception, c'est-à-dire le débit que le terminal émettant la requête CMR souhaite recevoir. Contrairement au troisième mode de réalisation, cette variante en référence à la FIG. 5 ne permet pas de différencier STEREO / BINAURAL ni MASA1 / MASA2 ce qui pourrait être un problème dans certaines applications. De façon similaire, si l’octet CMR est défini est T = ‘111’ et D=’0001’, dans le cas de « Escape Output », cela indique qu’un octet CMR supplémentaire est défini immédiatement après le premier octet CMR et ce second octet a des valeurs par exemple selon le format CF (4 bits) BR (4 bits) tels que définis dans le tableau illustré à la FIG. 5 . Cet octet supplémentaire indique une requête pour informer du format de décodage/rendu immersif (valeurs définis par le code CF pour « code format ») et/ou demander de changer le débit (valeurs définies par le code BR pour « Bit rate ») en émission, c'est-à-dire le débit que l’émetteur de la requête CMR envoie. Dans un cinquième mode de réalisation, il sera possible de combiner des variantes précédentes pour avoir un format d’octet CMR comme illustré à la FIG. 6 . Dans des variantes, le ou les champ(s) CMR (dans un ou deux octets CMR) selon l’invention pourront être insérés dans un paquet RTCP (de type RTCP-APP ou RTCP-FB) dans le cas où une adaptation selon le profil AVPF est autorisée ; dans ce cas le ou les champs CMR peuvent ne pas être utilisés dans les paquets RTP. De plus, l’utilisation du CMR (uniquement changement de débit et/ou format) pourra être contrôlée par un paramètre SDP comme le paramètre « cmr » déjà défini dans le format de payload du codec EVS. L’invention a été décrite jusqu’ici avec un format de transport en mode « header-full ». Dans des variantes de l’invention, on pourra utiliser pour le codec étendu IVAS un mode de format de transport par défaut comme dans EVS. On a en fait deux façons d’appliquer ce mode par défaut : mode compact d’EVS réutilisé tel quel (avec tailles protégées telles que définies dans 3GPP TS 26.445 Annexe A) et mode header-full pour EVS/IVAS selon l’invention (avec un bourrage de zéros pour éviter les conflits de taille. Mode compact d’IVAS pour les débits de 13200 à 512000 bit/s avec des tailles protégées comme dans le tableau 3 ci-dessous. Mode Payload Size (bits) Bitrate (kbps) IVAS SID 104 5.2 IVAS 264 13.2 IVAS 328 16.4 IVAS 488 24.4 IVAS 640 32 IVAS 960 48 IVAS 1280 64 IVAS 1920 96 IVAS 2560 128 IVAS 5120 256 IVAS 7680 384 IVAS 10240 512 Dans des variantes, le format de transport du codec étendu (IVAS) pourra aussi inclure la possibilité d’étendre l’entête RTP, par exemple pour transporter des informations comme l’orientation d’un terminal. Le format de payload du codec IVAS selon l’invention suppose qu’un changement de format est possible au moins entre mono et format stéréo/immersif, à l’émission comme à la réception. La commutation mono (EVS) et stéréo/immersif (IVAS) doit pouvoir se faire à n’importe quelle trame temporelle, en particulier suite à la réception d’un CMR selon l’invention. On rappelle que le retard algorithmique du codec EVS est de 30.9375 ms en NB et 32 ms pour les autres bandes (WB, SWB, FB). Pour IVAS, le retard algorithmique est de 32 ms (ex : stéréo) à 38 ms. Pour pouvoir commuter sans problème d’alignement temporel, il est donc important de synchroniser les parties codage et décodage/rendu en appliquant la différence de retard nécessaire en fonction du mode d’opération. On notera également qu’en cas de rendu binaural, un éventuel retard dû à la binauralisation et la présence éventuelle de réverbération additionnelle doivent être pris en compte pour assurer une commutation sans artefacts. On suppose ici que la commutation peut se faire par « reset » du codage. Afin d’éviter un temps de convergence du signal audio trop long, il est possible de resynchroniser des mémoires / états du codec EVS/IVAS en fonction des trames passées et d’utiliser une réduction ou augmentation de canaux / paramètres « intelligente » en fonction des formats. Au décodage il faut aussi pouvoir s’assurer qu’une perte de trame n’impacte pas sévèrement la commutation (ex : première trame mono perdue après une série de trames IVAS, avant de recevoir les autres trames EVS). On prend ici le cas concret d’une commutation entre IVAS STEREO et EVS (mono). A la trame T on suppose qu’on est en STEREO, à la trame T+1, suite à la réception d’un CMR, le codage passe en mode EVS mono. Idéalement les bandes audio codées pour IVAS et EVS doivent être identiques (ex : SWB). Comme IVAS comprend un mode de réduction de canaux de stéréo à mono compatible EVS, la principale difficulté dans la commutation consiste à éviter une discontinuité du signal lorsqu’il sera décodé et aussi à bien initialiser les états du codec pendant la commutation. Au décodage (à la réception), la commutation STEREO à MONO est détectée lors de la lecture du payload qui est STEREO à la trame T et MONO (EVS) à la trame T+1. Dans ce cas, le « reset » est une solution simple qui pourrait malgré tout résulter en des artéfacts audio. On peut ici considérer que le retard algorithmique au décodage peut être exploité pour effectuer un fondu enchaîné des sorties audio des trames T et T+1. La même approche peut être utilisée pour l’autre sens de commutation (de MONO à STEREO) avec un reset des états et l’utilisation d’un fondu enchaîné au décodage. Cet exemple se généralise aux autres formats stéréo : pour le format BINAURAL, le traitement est très similaire au cas STEREO. Pour les autres formats immersifs, le passage à MONO implique une réduction du nombre de canaux. La commutation peut être assurée par une réinitalisation (reset) des états du codec avec éventuellement l’utilisation d’un fondu enchaîné. La FIG. 7 décrit à présent un exemple de réalisation matérielle d’un dispositif de communication, par exemple un terminal de communication mettant en œuvre le procédé de génération de format de transport de données selon l’invention, tels que décrits en référence aux figures 3 à 6 décrites ci-dessus. 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 œuvre le procédé de transport selon l’invention. 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 support de stockage tel qu’une mémoire flash, un disque dur ou tout autre support de stockage non-transitoire. Le processeur de traitement met en œuvre le procédé de transport tel que décrit en référence à la FIG. 2 , et selon les formats décrits en référence aux figures 3 à 6, selon les instructions de programme PG. Le terminal TA comporte un module de communication 12 apte à recevoir et transmettre des données temps réel à un réseau de communication R et apte à lire des données de signalisation ou de configuration de type SDP 13 soit à travers la signalisation émise dans le réseau soit dans la mémoire 11 du terminal. Le terminal comprend un module récepteur 14 apte à recevoir et à décoder un format de transport tel que généré par un émetteur d’un autre dispositif de communication et tel que décrit en référence aux figures 3 à 6. Pour cela il extrait des champs de l’entête RTP, notamment les valeurs transmises dans les champs existant, non utilisé ou réservé, du format de transport de données du codec audio mono, pour connaitre au moins les informations de débit du codec audio étendu. Le module récepteur est également apte à gérer une mémoire de réception, à décoder les trames reçues et la corriger d’éventuelles pertes de trames. Le terminal comprend un module émetteur 15 apte à coder et générer des paquets RTP en rajoutant les entêtes protocolaires pour générer un format de transport (payload format) correspondant au format de codage. Un émetteur a également une fonction d’adaptation éventuelle du transport (agrégation, redondance ou autre) ainsi qu’une fonction de transmission des paquets. Ainsi, le module émetteur met en œuvre un procédé de génération de format de transport de données audio lors d’une session de communication temps réel avec un autre dispositif de communication. Pour cela, le format de transport de données pour un codec audio étendu (IVAS) étendant un codec audio mono (EVS), réutilise le format de transport de données du codec audio mono. Au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. Plusieurs modes de réalisation de ce format de transport de données sont décrits en référence aux figures 3 à 6. 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 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 œuvre 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 œuvre une fonction ou un ensemble de 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é. ANNEXE 1 Offre SDP (simplifiée) du terminal A m=audio 54590 RTP/AVP 96 97 98 a=rtpmap:96 IVAS/16000 a=fmtp:96 evs=[br=9.6-24.4;bw=swb;max-red=0]; ivas=[br=13.2-48;bw=swb;fmt-send=[ STEREO,MASA1-MASA2];fmt-recv=[STEREO,BINAURAL]] a=rtpmap:97 EVS/16000 a=fmtp:97 br=9.6-24.4;bw=swb;max-red=0 a=rtpmap:98 telephone-event/16000 a=fmtp:98 0-15 a=ptime:20 a=maxptime:20 ANNEXE 2 Réponse SDP (simplifiée) du terminal B m=audio 54590 RTP/AVP 96 98 a=rtpmap:96 IVAS/16000 a=fmtp:96 evs=[br=9.6-24.4;bw=swb;max-red=0]; ivas=[br=13.2-24.4;bw=swb;fmt-send=[ STEREO];fmt-recv=[STEREO]] a=rtpmap:98 telephone-event/16000 a=fmtp:98 0-15 a=ptime:20 a=maxptime:20 Procédé de génération de format de transport de données audio lors d’une session de communication temps réel entre dispositifs de communication (A,B), dans lequel le format de transport de données pour un codec audio étendu (IVAS), étendant un codec audio mono (EVS), réutilise le format de transport de données dudit codec audio mono, et où au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. Procédé selon la revendication 1, dans lequel un champ non utilisé et existant du format de transport de données dudit codec audio mono est utilisé pour signaler le codec audio étendu et un autre champ est utilisé pour transmettre au moins des informations du débit du codec audio étendu. Procédé selon la revendication 1, dans lequel, au moins un champ existant de requête d’adaptation de codec (CMR), non utilisé ou réservé, du codec audio mono est utilisé pour transmettre au moins des informations du débit du codec étendu à utiliser. Procédé selon la revendication 3, dans lequel chacun des débits possibles du codec étendu est indiqué dans un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec mono. Procédé selon la revendication 3, dans lequel un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono est utilisé pour informer de l’existence d’un second code spécifiant un format et/ou un débit du codec étendu à utiliser en réception. Procédé selon la revendication 3, dans lequel un champ existant de requête d’adaptation de codec, non utilisé ou réservé, du codec audio mono est utilisé pour informer de l’existence d’un second code spécifiant un format et/ou un débit du codec étendu utilisé en émission. Terminal de communication comportant un circuit de traitement apte à mettre en œuvre un procédé de génération de format de transport de données audio lors d’une session de communication temps réel avec un dispositif de communication, dans lequel le format de transport de données pour un codec audio étendu (IVAS), étendant un codec audio mono (EVS), réutilise le format de transport de données dudit codec audio mono, au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono, étant utilisé pour transmettre au moins des informations du débit du codec audio étendu. Format de transport de données audio pour un codec audio étendu (IVAS), étendant un codec audio mono, réutilisant le format de transport de données dudit codec audio mono (EVS) dans lequel au moins un champ existant, non utilisé ou réservé, du format de transport de données dudit codec audio mono est utilisé pour signaler le codec audio étendu et/ou pour transmettre au moins des informations du débit du codec audio étendu. Programme informatique comportant des instructions de code pour la mise en œuvre des étapes du procédé de génération selon l’une des revendications 1 à 6, lorsque ces instructions sont exécutées par un processeur. Support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l’exécution du procédé de génération selon l’une des revendications 1 à 6.