FR 3071997 A1 20190405 FR 1759203 A 20171002 Signalisation d'une requête d'adaptation d'une session de communication en voix sur I P 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 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 électroniques, 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 à une signalisation de requête d'adaptation de codage/décodage de signaux temps réels comme les signaux de voix ou de 15 vidéo lors d'une session de communication temps-réel entre deux terminaux de communication. 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 20 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: - 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 25 les services multimédia sur IMS (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 30 utilise la syntaxe de SDP pour définir des descriptions de session WebRTC (avec un échange par WebSocket ou un autre moyen). - H.323/H.245. 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. On se limite ici au cas d'un signal audio mono, le signal acoustique ambiant 35 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. 2 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 traitements acoustiques en émission et en réception (103 et 153) comme par exemple: - conversion analogique/numérique, contrôle de gain, réduction de bruit, 5 annulation d'écho, etc..., en émission - conversion numérique/analogique, contrôle de gain, etc..., en réception. Le signal audio prétraité en émission est codé par trames successives - avec typiquement une longueur de trame (en général fixe) allant de 10 à 60 ms - et les trames codées sont mises sous forme de paquets IP (104 et 154). Les paquets sont typiquement 10 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 IP/UDP (pour "User Datagram Protocol" en anglais). On notera que le protocole UDP peut être remplacé par un autre protocole de transport, par exemple par TOP (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 à 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 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 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é pour des fins d'adaptation la requête transportée peut être perdue. L'envoi des paquets par le protocole RTCP peut être discontinu et non répétitif, ce qui peut rendre l'adaptation moins réactive et dépendante des conditions réseaux (pertes de paquets, etc.). - "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 même requête dans plusieurs paquets successifs (typiquement toutes les 20 ms 3 pour les codecs comme AMR, AMR-WB ou EVS considérés plus loin). 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 5 fonctionne. On rappelle qu'il existe différents profils de protocole RTP, dont les principaux sont AVP (Pour « Audio Video Profile » en anglais) selon la spécification RFC 3551 et AVPF (Pour « Audio Video Profile with Feedback » en anglais) selon la spécification RFC 4585. Sans perte de généralité, on ne revoit pas ici leurs versions intégrant la sécurité (SAVP et SAVPF où le 10 préfixe « S » signifie « Secure » en anglais) car les aspects de sécurité dépassent le cadre de l'invention. Une différence majeure entre AVP et AVPF tient aux contraintes temporelles d'envoi de paquets RTCP: avec AVP on ne peut envoyer un paquet RTCP qu'en moyenne toutes les 5 secondes, ce qui n'est en général pas suffisant pour avoir une adaptation réactive en cas de conditions réseaux très variables. De plus, avec le protocole AVFP on peut utiliser 15 des messages de rétroaction RTCP FB (FB pour « FeedBack ») alors que seuls les paquets RTCP APP (APP pour "Application defined") sont définis dans AVP pour transporter un feedback en dehors des rapports RTCP (SR et RR). En général, plusieurs types de dégradation peuvent potentiellement affecter la qualité 20 de la voix sur IP: - bande passante variable / congestion du réseau - pertes, dé-séquencement, répétition de paquets - retard, variation du retard de transmission des paquets - dérive d'horloge entre les terminaux 25 Ils existent différentes solutions pour pallier ces dégradations différentes, dont des 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). Pour que l'émetteur puisse s'adapter et décider de son adaptation (adaptation "basée 30 émetteur"), celui-ci doit recevoir un « feedback » du récepteur distant indiquant par exemple le taux de perte observé ou la bande passante disponible estimée par le récepteur distant. Dans une adaptation "basée récepteur", le « feedback » reçu par l'émetteur local (104) est une décision d'adaptation (par exemple le choix du mode ou débit à utiliser) prise par le récepteur distant (155) - ce feedback est transmis en passant par l'émetteur distant 35 (154) puis le récepteur local (105). 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 4 blocs 104 et 155; ce sens inverse n'est pas représenté sur la figure1 pour ne pas alourdir cette figure. 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- 5 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). 10 Lorsque la négociation de l'appel utilise le protocole SDP, la possibilité d'utiliser cette adaptation du débit paquet dépend des paramètres "ptime" et "maxptime" définissant respectivement les longueurs minimum et maximum possibles d'une trame. Par exemple pour ptime=20 et maxptime=240, un paquet représente 20 ms de signal et il est possible de multiplexer jusqu'à 12 trames par paquet. 15 Les figures 2a à 2d illustrent des exemples de formats de paquets IP avec l'envoi d'une ou plusieurs trames par paquet. On considère que le mode de génération par défaut de paquets correspond au cas de la figure 2a où la trame courante N est mise dans le paquet P, où on peut considérer que P = N dans ce cas. Un exemple de "f rame bundling" est donné à la figure 2b où les trames N et N - 1 sont mises dans le paquet P - le rythme paquet est 20 donc deux fois moins élevé que le rythme trame et on peut considérer que P = [N12] (1_.] représente l'arrondi à l'entier inférieur). Lorsqu'un codec est nnulti-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 25 d'une requête de changement de débit reçue par « feedback » (décision "basée récepteur"). On peut noter qu'il existe également d'autres solutions que l'adaptation du codage pour éviter la congestion - ces solutions alternatives ne fonctionnement pas au niveau RTP ou au niveau de la couche application, mais à plus bas niveau. Elles ne seront pas développées ici car sortant du cadre de l'invention. 30 On notera enfin que pour les applications non-temps-réel utilisant le protocole TOP (Pour « Transmission Control Protocol » en anglais), une approche classique d'adaptation aux conditions canal consiste à varier le débit TOP, en utilisant un « feedback » où le récepteur envoie une demande de retransmission (ARQ pour « Automatic ReQuest ») avec l'indication des paquets non reçus; le débit TOP est adapté en fonction de ce « feedback ». L'indication 35 de congestion en TOP est à l'origine limitée à l'indication de pertes et elle a été étendue à d'autres paramètres (analyse de l'évolution du temps de transmission aller-retour ou RU pour « round-trip time » en anglais, etc.). 5 Pour une dégradation due à une perte de paquets, une approche minimaliste pour gérer ce type de dégradation est d'appliquer une correction de pertes de trame au niveau du récepteur. Cette approche n'est que réactive et ne peut pas toujours très bien "dissimuler" des "trous" (informations manquantes, non reçues) dans le signal décodé, en particulier 5 lorsque plusieurs trames consécutives sont perdues ou si le codec utilisé est sensible aux pertes (par exemple pour un codec prédictif). Il faut également assurer un retour rapide à la normale ("recovery") dans le signal audio; la correction de pertes de trames perdues produit souvent des artéfacts qui sont plus ou moins audibles selon le type de codec et la méthode de correction de pertes utilisée. La correction de pertes peut être mise en oeuvre dans le 10 décodeur audio ou intégrée au récepteur dans les opérations d'adaptation du buffer de gigue (en "allongeant" le signal actuel et en le "fusionnant" avec le signal futur une fois disponible et décodé). Une meilleure approche pour contrer les pertes de trames est d'utiliser de la redondance en répétant des trames codées entières ou partielles (par exemple, des 15 paramètres codés importants); cette approche a cependant un coût en termes de débit et de retard. Des exemples d'utilisation de redondance partielle sont données pour les codecs I ETF OPUS (mode "inbandfec") et 3GPP EVS ("channel-aware mode") connus de l'homme de l'art. Des exemples d'utilisation de redondance complète (ou "application layer redundancy" en 20 anglais) sont données au chapitre 10 de la spécification 3GPP TS 26.114 (version 15.0.0) pour les codecs AMR, AMR-WB et EVS. Dans la suite, la "redondance complète" sera résumée en "redondance". Les figures 2c et 2d illustrent des cas de redondance où la trame codée N est répétée dans un paquet suivant avec une distance appelée "offset" et notée K - pour K = 1 25 représenté à la figure 2c, le paquet N contient la trame N et la trame précédente N-1, tandis que pour K = 2 représenté à la figure 2d, le paquet N contient la trame N et la trame N- 2 ainsi qu'une trame vide (NO DATA). Pour un offset K plus grand, le nombre de trames vides (NO DATA) "insérées" entre la trame courante d'indice N et la trame redondante d'indice N-K est K-1. On notera qu'il est possible de combiner la redondance et 30 l'agrégation de trames, ce cas n'est pas détaillé ici (voir 3GPP TS 26.114 figures 10.12 et 10.13). Lorsque la négociation de l'appel utilise le protocole SDP, l'utilisation de ce type de redondance au niveau applicatif ("application layer redundancy") dépend du paramètre "maxred" lorsque celui-ci est défini dans le format de transport pour un codec donné. 35 Typiquement le paramètre "max-red" donne la durée maximale (en ms) - à l'émetteur - entre la transmission d'une trame (dite primaire) et la transmission d'une version redondante; ce paramètre permet donc de fixer un retard maximal lorsque la redondance est utilisée. Par exemple "max-red=20" indique qu'il est possible d'utiliser la redondance et qu'une trame 6 redondante peut être transmise jusqu'à 20 ms après la trame originale. En général, quand "max-red" est fixé à 0, cela revient à désactiver l'utilisation de la redondance et si "max-red" n'est pas présent comme paramètre de signalisation (attribut SDP), cela indique qu'aucune limitation n'existe sur l'utilisation de la redondance - dans la limite où la bande passante 5 globale spécifiée par le paramètre SDP « b=AS : » selon l'IETF RFC 4566 et les modes de codage autorisés dans la session sont respectés. Pour les autres types de dégradation cités, une méthode classique pour absorber la gigue réseau, gérer les dé-séquencements et les répétitions de paquets, et rétablir un flux 10 synchrone consiste à utiliser un buffer de gigue en réception. On distingue les buffers fixes et les buffers adaptatifs. Ces buffers permettent aussi en général de gérer les problèmes de dérive d'horloge. La gestion du buffer de gigue n'est pas revue ici car elle dépasse le cadre de l'invention. La spécification 3GPP TS 26.114 comme vu précédemment, décrit les méthodes 15 possibles d'adaptation du codage. Pour la voix plusieurs mécanismes y sont décrits pour signaler un « feedback » ou des requêtes d'adaptation: - l'utilisation de requêtes CMR (Pour « Codec Mode Request » en anglais) - l'utilisation de paquets RTCP de type RTCP APP (APP pour «APFlication-defined» en anglais) 20 Les figures 3a à 3d décrivent le format de transport ("payload format" en anglais) des codecs AMR et AMR-WB. La spécification détaillée du « payload » RTP pour AMR et AMRWB se trouve dans la spécification I ETF RFC 4867. On ne décrit ici en détails que le mode appelé "bandwidth-efficient" mais on rappelle qu'il existe aussi un autre mode appelé « octet-aligned ». Dans le mode « octet-aligned » tous les champs de la charge utile (ou 25 « payload » en anglais) - l'entête du payload, les entrées ToC, les données codées - sont alignés individuellement (avec un bourrage de zéros si nécessaire) pour que la longueur (en bits) de ces champs soit un multiple de 8 (donc que ces champs soient sur un nombre entier d'octets) ; dans le mode « bandwidth-efficient » cet alignement à un nombre entier d'octets n'est utilisé que sur le payload complet, donc ce mode peut être vu comme plus efficace car il 30 requiert moins de bourrage de zéros et donc donne des paquets de taille minimale entre les deux formats. Par ailleurs, le mode « octet-aligned » offre plus de fonctionnalités comme la capacité de trier des données codées par robustesse (« robust sorting » en anglais), d'utiliser de l'entrelacement, ou un code CRC sur la trame pour rendre le transport plus robuste aux pertes de trames ou aux erreurs binaires. 35 Le payload d'un paquet pour AMR et AMR-WB est décrit à la figure 3a: elle comprend un entête PH (pour « Payload Header » en anglais), un champ ToC (pour "Table of Content" en anglais) et les données codées SD (pour « Speech data » en anglais) par AMR ou AMRWB. Dans le mode "bandwidth efficient", l'entête est simplement un champ de requête de 7 changement de mode de codec CMR (pour « Codec Mode Request » en anglais) sur 4 bits comme indiqué à la figure 3b ; la définition des indices à la figure 3c est dérivée de la table la de la spécification 3GPP TS 26.101, intitulée "AMR Speech Codec Frame Structure", version 14.0.0, pour le codec AMR et de la table la de la spécification 3GPP TS 26.201 5 intitulée "AMR Wideband speech codec; Frame Structure", version 14.0.0, pour le codec AMR- WB. Ces indices définissent des modes de codage différents avec un débit différent respectivement pour le codec AMR et AMR-WB. Le champ ToC consiste en une liste d'entrée ToC sur 6 bits, où la i-ième entrée 10 représente la i-ième trame contenue dans le paquet courant. Chaque entrée ToC a le format donné à la figure 3d où: - F (1 bit): F=1 indique que la trame courante est suivie par une autre trame dans le payload; F=0 indique que c'est la dernière trame du paquet. - FT (4 bits): indice "Frame Type" qui signale que la trame courante est codée par un 15 certain mode AMR or AMR-WB ou qu'il s'agit d'une trame de description de silence (SI D) ou d'une trame non transmise (NO DATA). - 0(1 bit): indice "Frame quality", si 0=0 la trame est endommagée. Il est donc possible de transporter plusieurs trames codées en AMR et AMR-WB et le champ ToC permet de les démultiplexer sans ambiguité. 20 A noter qu'il est possible d'ajouter un bourrage de bits (des octets de "padding") à la fin du payload. Dans ce cas le bit "F '(pour "Padding") dans l'entête RTP peut être - de façon optionnelle - mis à 1 et les bits supplémentaires doivent être ajoutés comme spécifié dans le RFC 3550 ; le dernier octet de ce "padding" contient le nombre d'octets ajoutés à la fin du payload (incluant ce dernier octet). 25 Le codec 3GPP EVS utilise un codage multi-modes. Ce codec EVS (pour « Enhanced Voice Services » en anglais) a été normalisé fin 2014. Il est actuellement défini dans deux versions de codes sources: - Code source en virgule fixe (3GPP TS 26.442) 30 - Code source en virgule flottante (3GPP TS 26.443) Le signal d'entrée du codec EVS est échantillonné à la fréquence de 8, 16, 32 ou 48 kHz et le codec peut représenter des bandes audio téléphoniques (narrowband, NB), élargie (wideband, WB), super-élargie (super-wideband, SWB) ou pleine bande (fullband, FB). Les débits du codec EVS sont divisés en deux modes: 35 o "EVS Primary" qui comprend o Des modes de codage à débit fixe: 7.2, 8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96, 128 kbit/s 8 o Un mode de codage à débit variable (VBR) avec un débit moyen proche de 5.9 kbit/s pour la parole active et qui utilise en fait une combinaison de modes de codage à 2.8, 7.2 et 8 kbit/s o Un mode "channel-aware" (CAM) à 13.2 kbit/s en WB et SWB 5 uniquement (qui utilise une forme de redondance partielle pour améliorer la robustesse aux pertes de trame) o "EVS AMR-WB 10" dont les débits sont identiques au codec 3GPP AMR-WB (9 modes de 6.6 à 23.85 kbit/s) A cela s'ajoute le mode de transmission discontinue (DTX) dans lequel les trames 10 détectées comme inactives sont remplacées par des trames SI D (SI D Primary ou SI D AMR- WB 10) qui sont transmises de façon intermittente, en moyenne une fois toutes les 8 trames. Les détails algorithmiques du codec EVS sont fournis dans les spécifications 3GPP TS 26.441 à 26.450 et ils ne sont donc pas repris ici. Le format de transport pour transporter sur protocole RTP des données codées par 15 EVS est défini à l'annexe A de la spécification TS 26.445. Ce format est illustré aux figures 4a à 4g. 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, 20 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" 25 Des exemples de charge utile RTP au format "Compact" sont données aux figures 4a et 4b pour les cas EVS Primary et EVS AMR-WB10, respectivement; on observe en particulier que pour EVS Primary la charge utile se résume aux données codées, sans aucune entête de transport et sans aucune possibilité de signaler une requête d'adaptation (Fig. 4a); pour EVS AMR-WB 10, les données codées en mode "Compact" sont réorganisés (certains bits sont 30 permutés) et un CMR réduit à 3 bits est défini comme entête (Fig. 4b). Ce cas particulier de CMR sur 3 bits n'est pas détaillé ici car il n'y a aucun code CMR libre dans cet espace de signalisation réduit à 3 bits, donc aucune possibilité de signaler une requête autre qu'un changement de débit sur 3 bits. Des exemples de charge utile RTP au format "header-full" sont donnés aux figures 4c 35 et 4d. Dans le premier cas (Hg. 4c), une seule trame est transportée et un octet (8 bits) d'entête ToC est inséré. Dans le second cas (Fig. 4d), 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é. En comparaison avec le format de payload des codecs AMR et AMR-WB on peut donc 9 observer que le format de payload "Header-full" du codec EVS reprend les concepts de CMR et ToC mais ces champs sont définis sur des octets (8 bits), donc naturellement "octet aligned" dans le mode "Header-full", le premier bit (MSB) étant à 1 pour CMR et 0 pour ToC. Une définition de ces champs est donnée dans la spécification TS 26.445, Annexe A. 5 Par souci de concision on ne reprend pas ici tous les détails de la spécification TS 26.445, Annexe A. Le champ CMR sur 8 bits est divisé en trois parties: - H (1 bit) : toujours à 1 - T (3 bits): bits indiquant le type de requête pour distinguer les différents modes EVS 10 Primary en NB, WB, SWB, FB (dont les modes VBR, CAM) et EVS AMR-WB 10. - 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 définissent les différents modes que peut prendre le codec. Elles sont rappelées à la figure 4g. Certains codes ne sont pas utilisés. 15 De façon similaire le champ ToC sur 8 bits est divisé en 3 parties: - H (1 bit): toujours à 0 - 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 10 (incluant 20 le mode SI D). Ce champ est lui-même 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). 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 comme 25 spécifié dans le RFC 3550 ; le dernier octet de ce "padding" contient le nombre d'octets ajoutés à la fin du payload (incluant ce dernier octet). L'utilisation de RTCP APP pour la voix sur 1 MS est détaillée dans le chapitre 10 de la spécification 3GPP TS 26.114. Le format d'un paquet RTCPAPP est illustré à la figure 5a. On 30 ne revoit pas ici la signification des champs de l'entête RTCP (V, P, PT, length, SSRGCSRC). Le champ « Name » est par convention fixé à "3GM7" pour « 3GPP MTSI Release 7 ». La partie utile concerne les données ajoutées dans le champ "Application dependent data". Cette partie contient un champ d'identification de requête (ID) suivi par des données (Figure 5b). Plusieurs valeurs d'I D (sur 4 bits) sont spécifiées dans TS 26.114. 35 Certaines valeurs d'ID s'appliquent à tous les codecs: - ID = 0 0 0 0: Padding (bourrage de zéros) 10 - ID = 0 0 0 1: Requête d'activation de redondance ("RedReq") - dans ce cas les données suivant l'ID sont sur 12 bits, et chaque bit (i= 1 à 12 en partant de la fin) indique s'il faut répéter le paquet N-i (si le bit est à 1) ou non (si le bit est à 0). - ID = 0 0 1 0: requête d'agrégation ("FrameAggReq") - dans ce cas les 5 données suivant l'ID sont sur 4 bits, et seulement 4 valeurs (parmi 16 possibles) sont pré- définies correspondant à la transmission de 1 à 4 trames par paquets D'autres valeurs s'appliquent à des codecs spécifiques: - ID = 0 0 1 1: requête CMR pour changer de mode (débit de codage) pour AMR et AMR-WB ("AmrCmr") 10 - ID = 01 00: requête de changement de mode pour EVS (EVS Primary) - ID = 0 1 0 1: requête de changement de bande audio codée pour EVS -NB, WB, SWB ou FB ("EvsBandwidthReq") - ID = 0 1 1 0: requête pour activer le mode channel-aware (CAM) d'EVS (" EvsPar Red Req") 15 - ID = 0 1 1 1: requête pour basculer de EVS Primary à EVS AMR-WB 10 ("Evsl oModeReq") - ID = 1 0 0 0: requête pour basculer de EVS AMR-WB 10 vers EVS Primary ("EvsPrimaryModeReq") On notera qu'il est possible de combiner plusieurs requêtes RTCP APP dans un même 20 paquet RTCP APP (par exemple une requête d'activation de redondance et une requête d'agrégation). Ainsi, les requêtes d'adaptation actuelles permises par le champ CMR dans des paquets RTP pour les codecs AMR, AMR-WB et EVS ne sont pas suffisants pour effectuer tout 25 type d'adaptation. En particulier, le CMR est limité à des changements de débit commandés par le récepteur, pour les codecs AMR et AMR-WB, et des changements de débit, de bande audio codée et de contrôle de mode CAM pour le codec EVS. La requête par le récepteur d'une autre forme d'adaptation que celles permises par CMR, comme la redondance ou l'agrégation de trames, requiert l'utilisation de RTCP APP dans 30 les applications de voix sur I MS (comme spécifiées dans la spécification TS 26.114). Or RTCP APP, pour être utilisable, requiert le profil AVPF. Les applications de téléphonie actuelles de type VoLTE (pour « Voice over LTE (Long Term Evolution) » en anglais désignant une technique de transport de la voix sur les réseaux de téléphonie mobile 4G LTE spécifiée dans GSMAIR.92 et de type VoWifi (pour « Voice over 35 Wi-Fi » en anglais) désignant une technique de transport de la voix sur le réseau Wi-Fi spécifiée dans GSMA I R.65, sont basées sur le profil minimaliste de voix sur I MS, où le profil AVPF n'est pas autorisé pour la voix ; seul le profil RTP AVP est autorisé. Ceci implique que 11 les paquets RTCP de type RTCP APP (ou RTCP FB) ne peuvent pas être utilisés dans ces applications. Quand le profil AVP est autorisé et en fonction des limitations de débit (champs SR et RR en SDP), l'usage réel de RTCP est limité au mieux à l'envoi de rapports "basiques" de type 5 Sender Report (SR) et/ou Receiver Report (RR) qui ont en particulier une fonctionnalité réseau d'envoi de message de maintien de connexion active ("keep-alive" en anglais). L'adaptation de "type émetteur" est donc fortement contrainte par le fait que le « feedback du récepteur par RTP n'est pas assez régulier et limité à quelques indicateurs de qualité « basiques ». 10 Il existe ainsi un besoin d'une méthode qui permette au récepteur de commander dans la bande (dans un flux RTP) différents types d'adaptation, de façon réactive et robuste, pour tout type de codecs audio ou vidéo. La présente invention vient améliorer la situation. 15 Elle propose à cet effet, un procédé de signalisation d'une requête d'adaptation de codage/décodage de signaux temps réels d'une session de communication temps réel, de la part d'un dispositif récepteur vers un dispositif émetteur. La requête d'adaptation est telle qu'elle concerne une demande d'agrégation et/ou de redondance de trames, qu'elle est générée selon l'existence d'un paramètre de signalisation issue de la phase de négociation de 20 codecs utilisés lors de l'initialisation de la session de communication et qu'elle est transportée via un protocole temps réel de type RTP. Ainsi, l'utilisation du protocole RTP pour demander une adaptation permet d'avoir une adaptation réactive contrairement à l'envoi de paquets RTCP qui n'est pas effectué en temps réel. 25 Les demandes d'adaptation concernent des adaptations différentes que les changements de mode de codage existants dans l'art antérieur. Cette signalisation de requête permet donc d'étendre les possibilités d'adaptations réactives. Les différents modes particuliers de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé 30 de signalisation défini ci-dessus. Dans un premier mode de réalisation, un champ inclus dans une requête de changement de mode de type CMR est utilisé pour transporter la requête d'adaptation de la session de communication. Ce type de transport de requête a l'avantage de ne pas augmenter la taille des 35 paquets IP. Il permet d'utiliser des valeurs de CMR non encore utilisées dans les méthodes de l'état de l'art, pour spécifier d'autres types d'adaptation. 12 Dans un mode de réalisation particulier où les dispositifs émetteurs et récepteurs utilisent des codeurs/décodeurs de type AMR ou AMR-WB, les codes CMR 9 à 14 sont utilisés pour coder des requêtes d'agrégation et de redondance de différents débits. Ces codes sont réservés pour des utilisations futures et peuvent de façon 5 avantageuse définir des adaptations de type agrégation ou redondance. Dans un mode de réalisation particulier où les dispositifs émetteurs et récepteurs utilisent des codeurs/décodeurs de type EVS, les valeurs de code CMR avec T = "111" et D, autre que "1111", sont utilisés pour coder des requêtes de redondance de différents débits. Ces codes sont réservés pour des utilisations futures et peuvent de façon 10 avantageuse définir des adaptations de type agrégation ou redondance. Dans un deuxième mode de réalisation, un champ de la requête de remplissage de fin de signalisation du protocole RTP est utilisé pour transporter la requête d'adaptation de la session de communication. Ce type de transport de requête a également l'avantage de permettre à la fois de 15 demander une adaptation de demande d'agrégation et/ou de redondance et de demander une adaptation de mode de codage. L'utilisation d'un champ de remplissage de fin de signalisation devient alors utile pour spécifier un autre type d'adaptation. La présente invention vise également un dispositif récepteur transmettant une signalisation d'une requête d'adaptation de codage/décodage de signaux temps réels d'une 20 session de communication temps réel, vers un dispositif émetteur distant Ce dispositif est tel qu'il comporte : - un module de vérification de l'existence d'un paramètre de signalisation issue de la phase de négociation de codecs utilisés lors de l'initialisation de la session de communication ; 25 - un module d'adaptation apte à déterminer une requête d'adaptation concernant une demande d'agrégation et/ou de redondance de trames et ; - un module d'insertion de la requête dans un format de transport via un protocole temps réel de type RTP. Ce dispositif présente les mêmes avantages que le procédé décrit précédemment, 30 qu'il met en oeuvre. L'invention vise également un terminal de communication comportant un dispositif récepteur tel que décrit. Elle vise un programme informatique comportant des instructions de code pour la mise en oeuvre des étapes du procédé de signalisation tel que décrit, lorsque ces instructions 35 sont exécutées par un processeur. Enfin l'invention se rapporte à un support de stockage, lisible par un processeur, intégré ou non au dispositif récepteur, éventuellement amovible, mémorisant un programme informatique mettant en oeuvre un procédé de signalisation tel que décrit précédemment. 13 D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : - la figure 1 illustre un système de communication de voix sur IP connu de l'état de 5 l'art et décrit précédemment ; - les figures 2a à 2d illustrent des exemples de l'état de l'art, de formats de paquets IP en cas d'agrégation de trames ou de redondance, tel que décrit précédemment ; - les figures 3a à 3d illustrent le format de transport pour les codecs AMR et AMR- 10 WB ; - les figures 4a à 4g illustrent le format de transport pour le codec EVS ; - les figures 5a à 5b illustrent des exemples de l'état de l'art, de formats de paquets de type RTCP APP tels que décrits précédemment ; - la figure 6 illustre un mode de réalisation d'un système de communication voix 15 sur IP et d'un procédé de signalisation selon l'invention ; - la figure 7 illustre un mode de réalisation plus détaillé d'un système de communication voix sur IP selon l'invention ; - la figure 8 illustre un format de transport utilisé selon un premier mode de réalisation de l'invention pour transporter une requête d'adaptation ; 20 - la figure 9 illustre un format de transport utilisé selon un deuxième mode de réalisation de l'invention pour transporter une requête d'adaptation ; - la figure 10 illustre un format de transport utilisé selon un autre mode de réalisation de l'invention pour transporter une requête d'adaptation ; et - la figure 11 illustre un mode de réalisation matérielle d'un terminal comportant un 25 dispositif récepteur mettant en oeuvre le procédé de signalisation selon un mode de réalisation. La figure 6 illustre un exemple de système de communication bidirectionnel entre deux terminaux A et B, mettant en oeuvre un procédé de signalisation de requête selon un 30 mode de réalisation de l'invention. On retrouve comme à la figure 1 les micros et haut- parleurs (101, 151, 102, 152). La figure ne représente pas ici les traitements acoustiques ni le réseau reliant les deux terminaux, par souci de concision et de clarté. Le terminal A comporte un émetteur 601 et un récepteur 603 tandis que le terminal B comporte un émetteur 651 et un récepteur 653. Les deux terminaux A et B sont typiquement 35 configurés en fonction d'un échange d'offre(s)/réponse(s) selon le protocole SDP, via les blocs respectifs 600 et 650. 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 14 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 5 rajoutant les entêtes protocolaires et en formant un payload correspondant au format de codage et à l'adaptation éventuelle du transport (agrégation, redondance ou autre) ainsi qu'une fonction de transmission des paquets. 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 payload qui peut inclure la gestion de buffer de 10 gigue, le décodage de trames reçues et la correction de pertes de trames perdues. Les terminaux A et B comportent un bloc de décodage de requête (blocs 607 et 657). Différents modes de réalisation d'extraction et de décodage de ces requêtes d'adaptation seront décrits ultérieurement en référence aux figures 8 à 10. Le bloc 607 ou 657 consiste à lire la partie concernée du paquet associé au codec (AMR, AMR-WB ou EVS). On suppose ici 15 que le résultat du décodage de requête par les blocs 607 et 657 est mémorisé dans un élément mémoire "adaptation info" contenant une structure partagée avec la partie émission (blocs 601 et 651) 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 601 ou 651 vérifie, avant de coder chaque nouvelle trame, si la 20 valeur de "adaptation info.updated" est à 1 et si c'est le cas il configure le codage et éventuellement le transport (redondance, agrégation) selon les modes de réalisation de l'invention, en fonction d'éléments complémentaires (par exemple "adaptation info.requested bitrate" pour le débit demandé, ou "adaptation info.red" pour l'activation ou non de la redondance, etc.) issus de la requête reçue et décodée par le bloc 25 607 ou 657. Les terminaux A et B comportent un bloc d'adaptation, respectivement 605 et 655, mettant en oeuvre une étape de détermination d'une adaptation à réaliser par l'émetteur distant. Les terminaux A et B comportent également un bloc de codage de requête, 30 respectivement 606 et 656, mettant en oeuvre une étape de codage d'une adaptation à réaliser par l'émetteur distant. Comme pour le bloc de décodage de requête, le résultat du codage de l'adaptation à réaliser par l'émetteur distant issu des blocs 605 ou 655 est mémorisé dans un élément de mémoire appelé « cmr request » contenant une structure partagée avec la partie émission (blocs 601 et 651). 35 Dans un mode de réalisation de l'invention, les terminaux A et B sont configurés (blocs 600 et 650) en fonction de l'existence ou non d'un paramètre de signalisation SDP appelé dans un premier mode de réalisation « adapt red » (par l'intermédiaire d'un bloc 600 15 ou 650 de lecture de signalisation SDP) issue de la phase de négociation ou de configuration de codecs utilisés lors de l'initialisation (ou de la ré-initialisation) de la session de communication. Le nom "adapt red" fait ici référence à la redondance (au sens d' "application-layer redundancy") et comme on le verra plus loin d'autres noms sont possibles 5 et sont utilisés dans des variantes, sans changer la nature de l'invention. Les configurations négociées dans les blocs 600 et 650 sont mémorisées dans des éléments mémoires (non représentés sur la figure) qui contiennent une structure partagée entre l'émetteur et le récepteur de chaque terminal A et B. 10 Les blocs de configuration 600 et 650 vérifient dans un premier temps la condition pour utiliser une requête étendue, qui est ici l'existence d'un paramètre de signalisation SDP appelé « adapt red On considère que les blocs 601, 603, 605, 606, 607 dans le terminal A et blocs 651, 653, 655, 656, 657 dans le terminal B ont accès à un élément mémoire qui peut être commun 15 à l'émission (601 et 606 pour l'exemple du terminal A) et à la réception (603, 605, 607 pour l'exemple du terminal A) ou bien séparé entre émission et réception. Cet élément est ici appelé "adapt enabled" mémorisant si le paramètre de signalisation SDP "adapt red" a été défini ou non lors de l'initialisation du récepteur (bloc 600 et 650 respectivement) incluant les blocs 603, 605 et 607 dans le terminal A et les blocs 653, 655 et 657 dans le terminal B. On 20 considère ici que adapt enabled =0 si le paramètre" adapt red" n'est pas présent et 1 s'il est présent. Comme expliqué ci-dessus, la présence du paramètre de signalisation autorise un type de requête d'adaptation étendue. On notera qu'il est aussi possible que le paramètre de signalisation soit complété par un ou plusieurs paramètres complémentaires, comme par 25 exemple un paramètre « red-offset » qui permet d'indiquer l'offset à utiliser en cas de redondance 100% (ou les offsets à utiliser en cas de redondance à 200% ou plus). Dans un mode de réalisation, un autre élément mémoire appelé "red offset" est également accessible à tous les blocs d'un terminal A ou B et celui-ci permet de configurer l'intervalle entre les trames primaires et les trames redondantes, en fonction de la configuration SDP (blocs 600 et 30 650). On donne en Annexe 1 un exemple d'offre SDP classique en voix sur I MS. Ce premier exemple traite d'une offre SDP qui permet d'initier un appel audio avec l'un des codecs voix suivants : AMR, AMR-WB et EVS. Le port UDP, le profil AVP et le type du 35 payload (PT) sont indiqués dans la ligne media « m ». Les numéros de type de payload sont PT= 97, PT= 98 ou 99, FI= 100 ou 101 pour EVS, AMR-WB et AMR respectivement. 16 La bande passante maximale du media offert dans la partie « b=AS » peut être modifiée selon les besoins et ici elle correspond au débit maximal supporté par EVS qui est 24.4kbit/s sur I Fv4. Les parties « rtpmap » et « fmtp » indiquent les paramètres du format du media. La 5 fréquence de l'horloge RTP pour les codecs listés est de 16kHz pour EVS et AMR-WB et de 8kHz pour AMR. Le paramètre « mode-change-capability » négocie la fréquence de changement de mode, il est ici fixé à 2 ce qui indique un changement toutes les 2 trames pour assurer une interopérabilité maximale avec les systèmes de type GSM. Concernant le paramètre « max-red » à 220, celui-ci permet d'utiliser l'intervalle maximal de 220 ms entre 10 la trame originale et la trame redondante). On donne en Annexe 2, un deuxième exemple d'offre SDP, selon un mode de réalisation de l'invention, où l'on a ajouté un paramètre d'adaptation global à tous les codecs audio, qui indique la capacité d'utiliser un champ CMR étendu ou un autre type de requête (padding ou extension d'entête RTP) que l'on va décrire ultérieurement, pour le cas de la 15 redondance. En effet, pour que l'émetteur distant puisse mettre en oeuvre l'adaptation décodée par le récepteur, il faut qu'il comprenne la requête d'adaptation qui va lui être transmise. La signalisation SDP issue de la négociation de codec lors de l'initialisation de la session de communication définie ce type de capacité pour les codecs des terminaux respectifs. 20 Dans le cas où un terminal selon l'invention a la capacité de s'adapter avec un CMR étendu pour commander un changement de type agrégation, redondance de trames ou un autre type d'adaptation spécifique à l'application, la signalisation SDP comprend un paramètre défini « adapt red » (ou un autre nom dans des variantes) qui indique que le terminal sait utiliser un type de requête étendu qui est dans le mode de réalisation principal le champ CMR 25 de façon étendu en utilisant les codes CMR « reserved » et/ou « not used » d'une façon prédéfinie. Comme expliqué plus loin, selon l'invention la valeur du champ « b=AS: » pourra être modifié lorsque le paramètre SDP indiquant une capacité d'adaptation étendue « adapt red» est présent, de sorte qu'il soit possible d'utiliser une redondance 100% efficace. 30 Ainsi pour supporter une redondance à 100% avec EVS avec un mode à 13.2 kbit/s et un offset K il faudra typiquement doubler la valeur de « b=AS: » définie pour 13.2 kbit/s quand une seule trame est transportée (30 pour I Fv4) et ajouter le nombre d'octets pour indiquer NO DATA (soit K - 1 octets de ToC) ; pour K = 2 on aura donc b=AS :61. Cependant, dans l'exemple ci-dessus on considère que le champ « b=AS: » reste 35 défini par rapport au débit nécessaire pour transporter une seule trame par paquet au débit maximal autorisé parmi tous les codecs listés. Dans des variantes de réalisation, le paramètre SDP "adapt red" pourra être dans la partie "fmtp", donc spécifique à chaque codec. 17 On donne en Annexe 3, un troisième exemple d'offre SDP, selon un mode de réalisation de l'invention, où l'on a ajouté un paramètre d'adaptation global à tous les codecs audio, qui indique la capacité d'utiliser un champ CMR étendu ou un autre type de requête (padding ou extension d'entête RTP) que l'on va décrire ultérieurement, pour le cas plus 5 général de la redondance et de l'agrégation. Le paramètre de signalisation est cette fois-ci appelé « ext adapt » et deux paramètres complémentaires sont : - un paramètre « red-offset » précisant deux valeurs, la première donnant l'offset à utiliser en cas de la redondance 100%, la seconde indiquant qu'il est 10 aussi possible de signaler (et utiliser) une redondance 200% avec l'offset correspondant pour la seconde trame redondante dans un paquet - un paramètre « agg » précisant le type d'agrégation autorisé, précisé comme une liste, ici le singleton « 1 » indique que seule une trame peut être transportée par paquet. 15 Dans d'autres variantes, on pourra adopter d'autres syntaxes de signalisation, par exemple on pourra utiliser le paramètre de signalisation comme indicateur principal de la capacité à utiliser des requêtes d'adaptation étendues, et ensuite des paramètres supplémentaires différents pour activer ou non l'utilisation de requêtes spécifiques (redondance, agrégation ou autre). 20 Dans des variantes de réalisation, le paramètre SDP "adapt ext" pourra être dans la partie "fmtp", donc spécifique à chaque codec. Dans un mode de réalisation de l'invention, les blocs 605 et 655 sont exécutés à chaque réception d'un nouveau paquet RTP par les blocs 603 et 653, respectivement. Le 25 récepteur fournit au moins les informations suivantes: - le temps de réception du paquet RTP (en ms ou selon l'horloge RTP du media) - la taille du paquet RTP (en octets) - les informations issues de l'entête RTP: 30 o le numéro de séquence RTP o le temps d'émission ou "timestamp" RTP A partir de ces informations, les blocs 603 et 653 peuvent estimer les indicateurs suivants: - Taux de perte -c sur un horizon pré-déterminé (par exemple environ sur les 5 35 dernières secondes). Un exemple de réalisation est donné à l'annexe A.3 de la RFC 3550 où la quantité « fraction » est calculée pour les rapports RTCP SR/RR. Dans des variantes, d'autres méthodes d'estimation seront utilisées. 18 - Bande passante disponible 13 estimée en kbit/s au niveau IP. Différentes méthodes d'estimation existent, on prend ici l'exemple de l'estimation basée sur un filtre de Kalman donné dans l'article de G. Carlucci et al., «Analysis and Design of the Google Congestion Control for Web Real-time 5 Communication (WebRTC) », Proc. MMSys, May 2016. On considère ici que la bande passante estimée est de la forme : 13=130 + ,codec, OÙ Pcodec est le débit du codec (mode de codage) et fi = 13- Pcodec est la partie de la bande passante utilisée en plus du débit de codage (dues aux entêtes protocolaires et éventuellement à l'utilisation de requêtes étendues). 10 On considère ci-dessous les deux cas pour les codecs AMR et AMR-WB: - Quand adapt enabled=0, l'adaptation pour le codec AMR et AMR-WB est limitée à un fonctionnement "basique" avec le CMR existant: Une seule trame est transportée par paquet, les requêtes d'adaptation pour activer 15 ou désactiver la redondance et l'agrégation ne sont pas disponibles et l'adaptation se limite à envoyer un CMR pour changer le débit de codage (mode) parmi la liste des débits (modes) autorisés par la session, selon la configuration SDP (blocs 600 et 650). On note cette liste { Ro, --., Rm_,} où M est le nombre de modes autorisés. Par exemple pour AMR il est recommandé de négocier les M = 4 modes suivants {4.75, 5.9, 7.4, 12.2} et pour AMR-WB 20 les M = 3 modes suivants {6.6, 8.85, 12.65} pour maximiser l'inter-opérabilité avec les systèmes 3G mais il est aussi possible de négocier pour AMR-WB une offre/réponse ouverte avec M = 9 modes {6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85} car les 3 débits les plus faibles {6.6, 8.85, 12.65} sont aussi présents dans ces 9 modes et un CMR peut limiter le débit maximal à au plus 12.65 kbit/s pour inter-opérer; cependant il existe 25 aussi des cas où N= 1 seul mode est autorisé, par exemple {12.2} pour AMR. Si N= 1, les blocs 603 et 653 ne génèrent aucune requête d'adaptation par le biais de l'élément mémoire « cmr request » (en sortie des blocs 605 ou 655) autre qu'un CMR indiquant le débit Ro ou bien un CMR avec un code fixé à 15 (NO REQ). On suppose ci-dessous que N>1 et on donne ci-dessous un exemple d'algorithme de décision d'adaptation. 30 Dans des variantes de l'invention d'autres critères et d'autres méthodes de décision pourront être utilisées sans changer la nature de l'invention. Le débit de codage de la trame précédente d'indice N-1 est noté R, où i dénote l'indice d'un des éléments de { Ro, --., Rm_1} correspondant au débit de la trame précédente. Si le taux de perte est trop important (par exemple T 10%), on suppose que 35 l'estimation de bande passante disponible n'est pas assez fiable et le critère 13 n'est pas utilisé ; dans ce cas, si en plus de la condition de taux de perte trop important, le dernier changement de débit a eu lieu depuis par exemple 50 trames (1 seconde), on abaisse le débit par précaution, en sélectionnant le débit Ri immédiatement inférieur au débit précédent tel 19 que j = max(i - 1,0) (l'opérateur max(.) sert ici à s'assurer qu'on ne descend pas plus bas que le débit minimal Ro) et cette décision de mode du bloc 605 ou 655 sera convertie par la partie émission en un code CMR (bloc 606 ou 656) pour indiquer le débit Ri. Quand le taux de perte n'est pas trop important (par exemple T 13.2 kbit/s, et la redondance 100% ne sera utilisée que pour un taux de perte > 6%. Dans des exemples de réalisation de l'invention, l'adaptation à effectuer est de type 35 agrégation de trames, selon différents modes que l'on va décrire ultérieurement ou bien de type redondance de trames selon également différents modes décrits ultérieurement, ou encore d'un autre type d'adaptation spécifique à l'application. L'adaptation peut comprendre à la fois de l'agrégation et de la redondance ou un autre type d'adaptation spécifique. 22 Ces types d'adaptations sont par exemple utiles pour modifier le débit de paquets, corriger les trames reçues erronés ou perdues, etc. ce qui n'est en général pas possible avec une adaptation limitée à la modification du débit de codage (sauf pour le codec EVS où le mode CAM permet partiellement de traiter le problème de pertes de trame, mais ce mode est 5 spécifique à EVS en WB et SWB à 13.2 kbit/s et est typiquement moins performant que la redondance à 100% à fort taux de pertes). Le principe de fonctionnement des blocs des terminaux A et B restent le même: leur fonctionnement dépend de la configuration SDP et de l'élément mémoire "adapt enabled". Une requête d'adaptation correspondant à l'adaptation déterminée en 605 et 655 est 10 insérée dans le paquet RTP courant par les blocs 606 et 656 respectifs, de codage de la requête. Différents modes de réalisation d'insertion de ces requêtes d'adaptation seront décrits ultérieurement en référence aux figures 8 à 10. Les blocs 607 et 657 respectifs de décodage de la requête permettent d'extraire et de 15 décoder les requêtes reçues d'un paquet RTP, du récepteur distant, pour que les émetteurs puissent mettre en oeuvre les adaptations demandées. En particulier, on considère ici un exemple de réalisation où l'émetteur accède à des éléments mémorisés « adaptation info et « cmr request » avec éventuellement des éléments mémorisés complémentaires. Ainsi, la figure 6 illustre les étapes mises en oeuvre lors du procédé de signalisation, à savoir, 20 une étape de vérification (600, 650) de l'existence d'un paramètre de signalisation issue de la phase de négociation ou de configuration de codecs utilisés lors de l'initialisation de la session de communication, une étape de détermination (605, 655) d'une requête d'adaptation concernant une demande d'agrégation et/ou de redondance de trames et une étape d'insertion (606, 656) de la requête dans un format de transport via un protocole temps réel 25 de type RTP. Dans des variantes de l'invention, d'autres façons d'échanger les informations que les structures partagées (sous forme d'éléments mémorisés) telles que « cmr request », « adaptation info » ou « adapt enabled » pourront être utilisées. La figure 7 illustre un mode de réalisation plus détaillé que celui de la figure 6 30 décrite ci-dessus. Dans ce mode de réalisation, les blocs émetteurs de la figure 6 sont divisés en des blocs de codage (701 et 751) et d'émission (702 et 752) mettant en oeuvre la génération et la transmission de paquets RTP. Les blocs récepteurs de la figure 6 sont divisés en des blocs de décodage (704 et 754) qui peuvent inclure la gestion de buffer de gigue, le décodage de trames reçues et la correction de pertes de trames perdues et de réception (703 35 et 753). Dans une application de Vol P, les blocs 701 et 702 (ou 751 et 752) sont exécutés en parallèle en "multi-thread" avec la partie liée au codage (701 ou 751) qui dépend des évènements liés à la carte son d'entrée (liée au bloc 701) et avec la partie émission sur le réseau (bloc 702 ou 752) qui dépend des évènements réseaux; de la même façon dans la 23 partie réception, la réception des paquets (703 et 753) peut fonctionner en parallèle de la génération audio (704 et 754). Les blocs 705 et 755 de détermination de l'adaptation à mettre en oeuvre ont les mêmes fonctions que celles décrites à la figure 6 pour les blocs 605 et 655. 5 La figure 7 permet de montrer qu'il est possible de distribuer les fonctions de création du format de payload entre le codage (701, 751) et l'émetteur (702,752) selon que le payload est formé par l'un ou l'autre de ces blocs. L'invention s'applique à ces deux cas. Les requêtes pour ces adaptations ainsi déterminées sont codées par les blocs 706 et 756 et insérés dans un paquet RTP soit par l'intermédiaire du module de codage 701 ou 751, 10 soit par l'intermédiaire de l'émetteur mettant en oeuvre la mise en paquets 702 ou 752. Les blocs 707 et 757 ont les mêmes fonctions que les blocs 607 et 657 décrits en figure 6. Selon la méthode mise en oeuvre pour transporter la requête d'adaptation, la requête décodée sera envoyée soit au bloc de codage soit au bloc d'émission de la partie émetteur. 15 On décrit maintenant, en référence à la figure 8, comment les codes CMR tels que définis ci-dessous sont utilisés. Dans un premier mode de réalisation, la requête d'adaptation déterminée par le récepteur d'un terminal est codée dans un champ d'une requête de changement de mode de 20 type CMR pour être transportée vers l'émetteur du terminal distant. Dans ce mode de réalisation, la signalisation de négociation entre les codecs des terminaux à l'initialisation de la session de communication définie un paramètre d'adaptation « adapt red » ou « adapt ext » ou un autre nom identifiant une capacité à utiliser une requête étendue comme vu précédemment, permettant d'utiliser un champ CMR qui soit 25 compréhensible à la fois du récepteur et de l'émetteur des terminaux distants. Lorsque ce paramètre est défini, un champ de code CMR est déterminé pour spécifier le type d'adaptation désiré. Pour les codecs AMR, AMR-WB et EVS tels que décrits précédemment, des codes réservés pour un usage futur ou inutilisés, servent selon l'invention à indiquer des requêtes 30 étendues de changement de mode. Ces codes sont limités à quelques valeurs pour les codecs cités. On distingue deux cas de fonctionnement: - Quand adapt enabled=1, on utilise des codes CMR définis comme "reserved", "not used" ou "for future use" pour indiquer une requête 35 étendue. - Quand adapt enabled= 0, seuls les codes CMR pré-définis dans RFC 4867 pour AMR et AMR-WB et TS 26.445 Annexe A pour EVS, sont utilisés. A la 24 réception (blocs 607, 657), si des codes CMRs définis comme "reserved", "not used" ou "for future use" sont reçus, ils sont ignorés. Dans un mode de réalisation, le format de codage de ces requêtes inclus dans des 5 champs CMR « réservés » ou inutilisés est décrit ici. Pour les codecs AMR et AMR-WB, les valeurs de CMR entre 8 et 14 (inclusivement) et entre 9 et 14 (inclusivement) sont réservées à un usage futur. Elles sont donc utilisées de façon conditionnelle quand un paramètre de signalisation selon l'invention est défini lors de la négociation de codec et leur utilisation est dédiée à signaler des requêtes de type 10 redondance, agrégation ou autre. De même pour le codec EVS, comme représenté en référence à la figure 4g, les valeurs avec T = "111" et D autre que "1111, sont marqués comme réservé ("Reserved"), ce qui laisse 15 valeurs possibles. Dans une variante de réalisation, les valeurs marquées comme non utilisées ("Not 15 used") peuvent également être utilisées, ce qui augmente alors considérablement le nombre de possibilité de codes libres; ceci n'est cependant applicable que pour le codec EVS. Pour une adaptation de redondance, principalement utilisée pour remplacer des trames manquantes, la redondance 100% consiste à répéter une trame passée (à l'offset K) 20 dans le paquet courant P. Quand les pertes de trames sont aléatoires (loi uniforme avec des valeurs indépendantes et identiquement distribuées ou i.i.d.), cette redondance à 100% permet de transformer un taux de perte de 10% en un taux de perte de 1%. On considère ici, dans un premier exemple de réalisation, que, pour des réseaux cellulaires de type LTE où des mécanismes de gestion de QoS sont déjà mis en place et 25 négociés pour un appel téléphonique, ce niveau de redondance à 100% est suffisant et qu'il n'est pas nécessaire de considérer des cas de redondance plus élevées (ex: 200 ou 300%). Dans l'exemple décrit ici, on considère qu'il est peu nécessaire de combiner à la fois une agrégation de trames et la redondance. On développe ici une version contrainte de signalisation de requête d'agrégation de 30 trames ou de redondance. On décrit ici les cas possibles de redondance pour les codecs AMR, AMR-WB et EVS pour un débit maximum associé au format de transport respectivement d'environ 12.2 kbit/s pour AMR, 12.65 ou 23.85 kbit/s pour AMR-WB et 13.2 ou 24.4 kbit/s pour EVS. 35 Le tableau 1 ci-dessous montre, pour un codec AMR avec un débit d'environ 12.2 kbit/s, que la redondance est limitée à 3 cas de redondance possibles, notés "2x R" où R est le débit répété. On notera qu'ici l'offset n'est pas spécifié et en pratique le débit associé au 25 format de transport sera plus élevé que le double de R si des informations ToC de type « NO DATA » doivent être insérées pour indiquer l'offset dans le payload. On notera que lorsque la redondance est activée, si le débit courant du paquet P est à un débit de 12.2 kbit/s et qu'on commute vers une redondance à 2x5.9 kbit/s à partir du 5 paquet suivant P+1, le premier paquet (d'indice P+1) contient normalement la trame courante avec un débit à 5.9 kbit/s et la trame précédente à un débit de 12.2 kbit/s. Cest seulement au paquet suivant (d'indice P+ 2) que l'on aura 2 trames à 5.9 kbit/s. Pour le premier paquet, le débit est alors supérieur au débit maximum autorisé. Si la valeur de « b=AS: » du paramètre SDP le permet, cette méthode pour le premier paquet de transition 10 est utilisé sinon, si cette valeur n'autorise pas la surcharge, pour éviter une surcharge temporaire (12.2+5.9), le paquet P+1 ne contiendra que la trame codée à 5.9 kbit/s. AMR Possible en redondance 100% ( REVENDICATIONS1. Procédé de signalisation d'une requête d'adaptation de codage/décodage de signaux temps réels d'une session de communication temps réel, de la part d'un dispositif récepteur vers un dispositif émetteur, caractérisé en ce que la requête d'adaptation concerne une demande d'agrégation et/ou de redondance de trames, qu'elle est générée selon l'existence d'un paramètre de signalisation issue de la phase de négociation de codecs utilisés lors de l'initialisation de la session de communication et en ce qu'elle est transportée via un protocole temps réel de type RTP. 2. Procédé selon la revendication 1, dans lequel un champ inclus dans une requête de changement de mode de type CMR est utilisé pour transporter la requête d'adaptation de la session de communication. 3. Procédé selon la revendication 2, dans lequel, dans le cas où les dispositifs émetteurs et récepteurs utilisent des codeurs/décodeurs de type AMR ou AMRWB, les codes CMR 9 à 14 sont utilisés pour coder des requêtes d'agrégation et de redondances de différents débits. 4. Procédé selon la revendication 2, dans lequel, dans le cas où les dispositifs émetteurs et récepteurs utilisent des codeurs/décodeurs de type EVS, les valeurs de code CMR avec T = "111" et D, autre que "1111", sont utilisés pour coder des requêtes de redondances de différents débits. 5. Procédé selon la revendication 1, dans lequel un champ de la requête de remplissage de fin de signalisation du protocole RTP est utilisé pour transporter la requête d'adaptation de la session de communication. 6. Dispositif récepteur transmettant une signalisation d'une requête d'adaptation de codage/décodage de signaux temps réels d'une session de communication temps réel, vers un dispositif émetteur distant, caractérisé en ce qu'il comporte : - un module de vérification de l'existence d'un paramètre de signalisation issue de la phase de négociation de codecs utilisés lors de l'initialisation de la session de communication ; - un module d'adaptation apte à déterminer une requête d'adaptation concernant une demande d'agrégation et/ou de redondance de trames et ; 39 - un module d'insertion de la requête dans un format de transport via un protocole temps réel de type RTP. 7. Terminal de communication comportant un dispositif récepteur selon la 5 revendication 6. 8. Programme informatique comportant des instructions de code pour la mise en oeuvre des étapes du procédé de signalisation selon l'une des revendications 1 à 5, lorsque ces instructions sont exécutées par un processeur. 10 9. Support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l'exécution du procédé de signalisation selon l'une des revendications 1 à 5. 15 20