Optimized format for transporting audio data during a Voice over IP communication session

Abstract

Optimized Audio Data Transport Format for a Voice over IP Communication Session. The invention relates to a method for generating an audio data transport format during a real-time communication session between communication devices (A, B), wherein the data transport format for an extended audio codec (IVAS), extending a mono audio codec (EVS), reuses the data transport format of said mono audio codec, and wherein at least one existing, unused or reserved field of the data transport format of said mono audio codec is used to signal the extended audio codec and / or to transmit at least some bitrate information of the extended audio codec. The invention also relates to a data transport format thus generated and to a communication terminal implementing the method for generating such a transport format. Abstract figure: Figure 2

Description

Title of the invention: Optimized format for transporting audio data from a voice over IP communication session Technical field

[0001] The present invention relates to the field of telecommunications and more particularly to packet communication networks. In this type of network, it is possible to route data streams associated with real-time services.

[0002] The Internet protocol, called IP for "Internet Protocol", developed by the IETF, for "Internet Engineering Task Force", is implemented on packet communication networks to support both non-real-time services such as data transfer services, web page consultation, electronic messaging, and real-time or conversational services, such as IP telephony, IP video telephony or IP video broadcasting.

[0003] The invention relates more particularly to the generation and reception of payload (also called transport format) for the transport of data coded according to the RTP protocol (for "Real-Time Transport Protocol" in English) during real-time communication between two communication devices, for example between two communication terminals or between a communication terminal and network equipment, to process real-time signals such as voice or video signals. Prior art

[0004] Reference is made to the IETF RFC 3550 and RFC 4566 specifications for the known state-of-the-art bases on the RTP protocol as well as the SDP (Session Description Protocol) protocol.

[0005] The payload format for transporting data by the RTP protocol, "RTP payload format" in English, also called transport format in the rest of the document, is defined for the EVS codec in the 3GPP TS 26.445 Annex A specification.

[0006] We recall that the EVS code (for "Enhanced Voice Services" in English) was standardized by the 3GPP organization at the end of 2014. It is currently defined in three source code versions: • Fixed point source code (3GPP TS 26.442)

[0007] • Floating point source code (3GPP TS 26.443)

[0008] • Alternative version of the floating point source code (3GPP TS 26.452)

[0009] It works with 20 ms frames and at different sampling frequencies (8, 16, 32, 48 kHz) for mono signals. Stereo or multichannel signals can be encoded in multi-mono only, that is, by encoding the channels separately, without possible metadata. The EVS codec defines 4 types of audio bands:

[0010] - narrow band called Narrowband (NB)

[0011] - Wideband (WB)

[0012] - Super-wideband (SWB)

[0013] - full band called Fullband (FB)

[0014] It includes two modes of operation: - “Primary” mode: in this case it operates at a constant bit rate of 7.2 kbit / s to 128 kbit / s and also includes a special mode called VBR with an average bit rate of 5.9 kbit / s - these bit rates are designated as “EVS primary modes” (or “primary modes”). - Backward compatible mode with AMR-WB called “AMR-WB IO”: in this case it operates at AMR-WB speeds, i.e. 6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85 kbit / s.

[0015] Furthermore, the EVS codec allows for optimized coding of silences by discontinuous transmission (DTX), which includes voice activity detection (VAD) and comfort noise generation (CNG). When DTX is enabled, inactive frames are coded by Silence Insertion Descriptor (SID) frames, which are generally sent every 160 ms.

[0016] In addition, EVS includes a special mode called “channel-aware mode” (CAM) limited to 13.2 kbit / s in WB and SWB, and which uses partial redundancy to improve robustness to frame losses.

[0017] The transport format for transporting EVS-encoded data over RTP is defined in Annex A of the TS 26.445 specification. This format is illustrated in Figures 1a to 11i.

[0018] There are two different modes for forming EVS packets:

[0019] • The default mode: the packets are either in "Compact" format, or in "Compact" format. "Header-full", to avoid size conflicts between these two modes, priority is given to the Compact mode whose sizes are "protected", while the sizes of the "Header-full" mode are penalized by adding zero padding in case of conflict with a size of the "Compact" mode.

[0020] • The "Header-full" mode which consists of adding payload headers (one byte of CMR for “Coded Mode Request” according to the SDP parameter “cmr”, one or more ToC bytes for “Table of Content” to describe the multiplexed frames and be able to extract them) before the coded data which correspond to one or more coded frames.

[0021] Examples of RTP payload in "Compact" format are given in figures 1a and 1b for the EVS Primary and EVS AMR-WB 10 cases, respectively; we observe in particular that for EVS Primary the payload is limited to the SD coded data (for "Speech data" in English), without any transport header and without any possibility of signaling an adaptation request ([Fig. la]); for EVS AMR-WB 10, the data coded in "Compact" mode are reorganized (some bits are permuted) and a CMR code mode change request field (for "Coded Mode Request" in English) reduced to 3 bits is defined as header ([Fig.lb]). This particular case of CMR on 3 bits is not detailed here.

[0022] Examples of RTP payload in "header-full" format are given in Figures 1c and 1d. In the first case ([Fig. 1c]), a single frame is transported and a ToC (Table of Content) header byte (8 bits) is inserted. In the second case ([Fig. 1d]), two frames are transported in the same packet with 2 ToC headers (2 bytes) and a CMR field (1 byte) is also used.

[0023] A detailed definition of these fields is given in specification TS 26.445, Annex A. For the sake of brevity, all the details of this specification are not repeated here.

[0024] The choice of payload mode (either default or header-full) is controlled by the EVS codec's SDP (Session Description Protocol) parameter called "hf-only".

[0025] We do not review here the complete list of SDP parameters of the EVS codec (see 3GPP TS 26.445 Annex A), but we recall that there are global parameters, parameters specific to the EVS Primary mode (e.g.: "br" or "bw") and parameters specific to EVS AMR-WB IO (e.g.: "mode-set").

[0026] It is possible to adapt the EVS codec by codec mode change requests (CMR), which is a form of in-band signaling, i.e. in the RTP stream. CMR is not possible in "compact" format except for EVS AMR-WB IO (with restrictions).

[0027] For EVS, in header-full mode, the CMR byte (8 bits) is divided into three parts shown in [Fig. 1c]:

[0028] • H (1 bit): always at 1 (specifying a CMR request)

[0029] • T (3 bits): bits indicating the type of request to distinguish the different modes EVS Primary in NB, WB, SWB, FB (including VBR, CAM modes) and EVS AMR-WB IO.

[0030] • D (4 bits): CMR request

[0031] The possible values ​​of the CMR field are defined in the specification TS 26.445, Annex A and specify the different modes that the codec can take. They are recalled in [Fig.lg]. It can be observed that certain values ​​are indicated as not used 'Not Used' or reserved 'Reserved' and a value indicated as 'NO_REQ' is an empty CMR query.

[0032] Similarly for EVS the ToC byte (8 bits) is divided into 3 parts represented in [Fig.lf]:

[0033] • H (1 bit): always 0 (to distinguish the byte as being a ToC field and not CMR)

[0034] • F (1 bit): If F=1, another frame follows the current frame, if F=0, it is the last frame of the packet.

[0035] • FT (6 bits): bits indicating the "Frame type" either EVS Primary or EVS AMR-WB IO (including SID mode).

[0036] This field is itself divided into 3 parts defined in the tables represented in figures Ih and li and as defined in tables A.4 and A.5 of the 3GPP TS 26.445 specification: EVS mode (1 bit), Unused / Q bit (1 bit) according to the EVS mode bit, and EVS rate (4 bits).

[0037] Note that for EVS it is also possible to add bit stuffing ("padding" bytes) at the end of the payload. In this case the "P" bit (for "Padding") in the RTP header can be - optionally - set to 1 and the additional bits must be added; the last byte of this "padding" contains the number of bytes added to the end of the payload (including this last byte).

[0038] The IVAS (Immersive Voice and Audio Services) codec is currently being defined. A high-level description of the current state of the codec is given in 3GPP TS 26.250 Vl.0.0 dated 15 / 09 / 2023.

[0039] The IVAS codec is an extension of the EVS codec to represent stereo and immersive formats. It is identical to EVS for mono coding.

[0040] For stereo and immersive formats, the IVAS codec bitrate ranges from 13.2 to 512 kbit / s (with restrictions depending on the exact format).

[0041] The different input formats of the IVAS encoder are defined in Table 1 below:

[0042] [Tables 1] Mono Format Type Input Format Name Description MONO Mono (EVS) 2 channels STEREO Stereo BINAURAL Binaural ISM (Independent Stream with Metadata) ISM1 1 mono object with metadata ISM2 2 independent mono objects with metadata ISM3 3 independent mono objects with metadata ISM4 4 independent mono objects with metadata SBA (scene-based audio) FOA Ambisonics 1st order HOA2 Ambisonics 2nd order HOA3 Ambisonics 3rd order MC (multichannel) MC51 5.1 multichannel MC71 7.1 multichannel MC512 5.1+2 multichannel MC514 5.1+4 multichannel MC714 7.1+4 multichannel MASA (Metadata Assisted Spatial Audio) MASA1 1-channel MASA (metadata-assisted spatial audio) format MASA2 1-channel MASA (metadata-assisted spatial audio) format 2 channels OSBA (object-based audio with scene-based audio) OSBA Combination of FOA / HOA2 / HOA3 and ISM OMASA (object-based audio with metadata-assisted spatial audio) OMASA Combination of MASA and ISM

[0043] It is not excluded that other coding modes will be introduced later in the development of the codec, for example for immersive rendering applications divided between pre-rendering in the network (edge ​​or cloud) and broadcasting of a pre-rendered signal to a terminal using at least one other format of the IVAS codec which is not listed in Table 1.

[0044] The bitrate of the IVAS codec actually depends on the input format (in bit / s): - Mono: identical to EVS Stereo: 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, MAS A, MC: 13200, 16400, 24400, 32000, 48000, 64000, 80000, 96000, 128000, 160000, 192000, 256000, 384000, 512000

[0045] If additional formats are added to Table 1, it can be assumed that the bit rate would be defined among these rates ranging from 13200 to 512000 bit / s.

[0046] The different output formats of the IVAS decoder / renderer are defined in Table 2 below:

[0047] [Tables2] Mono Format Type Input Format Name Description MONO Mono stereo STEREO Binaural stereo BINAURAL Binaural (with / without reverb) MC (Multichannel) 5_1 5.1 multichannel 7_1 7.1 multichannel 5_1_2 5.1+2 multichannel 5_1_4 5.1+4 multichannel 7_1_4 7.1+4 multichannel custom “Custom” speaker configuration SBA (Scene-Based Audio) FOA Ambisonics order 1 H0A2 Ambisonics order 2 H0A3 Ambisonics order 3 External External “Proprietary” format for an external renderer

[0048] It is important to note that the algorithmic delay of the IVAS codec depends on the coding / decoding format, it is 32 ms for the stereo format and it ranges from 32 to 38 ms for input formats other than stereo.

[0049] The payload format for transporting data by the RTP protocol, also called transport format (“payload format”) for the IVAS codec, is not yet defined.

[0050] Two proposals have recently been published: A first proposal is given in the document at the following link, dated “September 7, 2023:

[0051] https: / / forge.3gpp.org / rep / ivas-codec-pc / ivas-codec / -Zwikis / uploads / 5d3146bd2f9548 a609c3f2dlef431363 / ivas-rtp-payload-format.pdf

[0052] This first proposal assumes that the transport format of the IVAS codec is different from EVS. In this proposal, no compact mode is proposed in order to keep only a "header-full" type mode and thus avoid complications and dependencies on an SDP parameter.

[0053] To be able to switch in the same call between a mono mode (EVS) and an immersive mode (IVAS), according to this proposal, it would be necessary to negotiate the two formats of transport at the same time, which is not possible in multimedia services over IMS (for “IP Multimedia SubSystem” in English).

[0054] Furthermore, in an asymmetric communication where the uplink sends for example a mono coded signal and the downlink receives an immersive coded signal, as in a spatial conference bridge scenario, the first proposition implies that two different codecs are instantiated in each direction (EVS and IVAS) from a transport format point of view ("payload format").

[0055] A second proposal is given in the document of the following link, dated “September 11, 2023:

[0056] https: / / forge.3gpp.org / rep / ivas-codec-pc / ivas-codec / -Zwikis / uploads / 23f8cb74ba3631 300f44804d2640f46f / Nokia-IVAS-RTP-Payload-draft-v 1 .pdf

[0057] This second proposal defines a compact mode for IVAS which implies a list of protected packet sizes. However, if the compact mode were also retained for the mono format of IVAS which corresponds to EVS, there would be a conflict between the EVS Primary (mono) and IVAS packet sizes; it would be necessary to add additional zero padding rules either on EVS Primary or on IVAS, which is not attractive.

[0058] This proposal does not define any CMR for IVAS, and relies on the RTCP protocol (for "Real-Time Control Protocol" in English) to convey adaptation requests, whereas voice over IMS relies on the RTP profile called AVP (for "Audio Video Profile" in English) and not AVPF (for "Audio Video Profile with Feedback" in English). Thus the use of RTCP (RTCP-APP or RTCP-FB) is not possible in this context of multimedia services over IMS.

[0059] This second proposal changes the ToC (Table of Content) byte format defined for EVS (TS 26.445 Annex A) to include in the case of IVAS additional signaling information and a 4-bit flow indication.

[0060] It should be noted that even if the mono format seems to be taken into account, the bitrates associated with EVS are not explicitly listed, which implies that the mono format (EVS) is not really transported in compact mode. This proposal also adds a new idea of ​​transporting so-called "processing information" frames to convey non-audio information such as the orientation of a terminal, the importance of a format.

[0061] Thus, the existing transport format proposals for the IVAS codec are not compatible with voice transport applications or multimedia services on IMS, which can be problematic for deploying the codecs in communication services.

[0062] Furthermore, these different proposals do not allow easy switching in the same call between a mono mode using an EVS type codec and a mode immersive using a single IVAS type codec, without having to cut and restart a call. They do not ensure continuity of service between the mono format (EVS) and the stereo / immersive formats (IVAS) Statement of the invention

[0063] The invention improves the state of the art.

[0064] For this purpose, the invention aims at a method for generating an audio data transport format during a communication session between communication devices, in which the data transport format for an extended audio codec, extending a mono audio codec, reuses the data transport format of said mono audio codec, and where at least one existing, unused or reserved field of the data transport format of said mono audio codec is used to signal the extended audio codec and / or to transmit at least information on the bit rate of the extended audio codec.

[0065] In the same way, the invention aims at a method for receiving audio data transport format during a real-time communication session between communication devices, in which the data transport format for an extended audio codec extending a mono audio codec, reuses the data transport format of said mono audio codec, and where at least one existing field, unused or reserved, of the data transport format of said mono audio codec, is used to signal the extended audio codec and / or to transmit at least information of the rate of the extended audio codec.

[0066] Thus, a single data format is specified for both the IVAS extended codec and the EVS codec, which makes it possible on the one hand to easily switch from one codec to another during the same call, in a manner compatible with multimedia services on IMS which can only select a single transport format and negotiate only a single transport format.

[0067] According to a first embodiment, an unused and existing field of the data transport format of said mono audio codec is used to signal the extended audio codec and another field is used to transmit at least information of the rate of the extended audio codec.

[0068] This allows for maximum compatibility with the existing mono format when switching by keeping the meaning of all other predefined values ​​intact, and thus maximizing backward compatibility with the existing mono format.

[0069] In a second embodiment, at least one existing, unused or reserved codec adaptation request field of the mono audio codec is used to transmit at least information of the rate of an extended codec to be used.

[0070] In a particular embodiment, each of the possible rates of the extended codec is specified in an existing, unused or reserved, mono codec adaptation request field.

[0071] Again, this allows for maximum compatibility with the existing mono format when requesting to switch from stereo / immersive mode to mono mode, keeping the meaning of all other predefined CMR values ​​intact, and thus maximizing backward compatibility with the existing mono format. This embodiment uses only a single byte for the CMR request.

[0072] In an alternative embodiment, a second adaptation request specifying at least one format and / or one audio band of the extended codec is inserted following said request.

[0073] According to a third embodiment, an existing unused or reserved codec adaptation request field of the mono audio codec is used to inform of the existence of a second codec specifying a format and / or a rate of the extended codec to be used.

[0074] Similarly, an existing unused or reserved codec adaptation request field of the mono audio codec is used to inform of the existence of a second codec specifying a format and / or a rate of the extended codec used in transmission.

[0075] The advantages are similar to the second embodiment, with however a drawback which makes this third mode less advantageous in terms of additional flow rate, on the other hand makes it more general by the use of an additional byte which makes it possible to signal a change of immersive format.

[0076] The invention relates to a communication terminal comprising a processing circuit capable of implementing a method for generating an audio data transport format during a real-time communication session with a communication device, in which the data transport format for an extended audio codec, extending a mono audio codec, reuses the data transport format of said mono audio codec, at least one existing, unused or reserved field of the data transport format of said mono audio codec, being used to signal the extended audio codec and / or transmit at least information on the bit rate of the extended audio codec.

[0077] The invention also relates to an audio data transport format for an extended audio codec reusing a data transport format of a mono audio codec in which at least one existing, unused or reserved field of the data transport format of said mono audio codec is used to signal the extended audio codec and / or to transmit at least information of the rate of the extended audio codec.

[0078] Such a transport format is in accordance with any of the embodiments described above.

[0079] The invention also relates to a computer program comprising ins- instructions for implementing the generation method according to the invention, according to any one of the particular embodiments described above, when said program is executed by a processor.

[0080] Such instructions can be stored permanently in a non-transitory memory medium of the communication terminal implementing the transport method according to the invention.

[0081] This program may use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0082] The invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.

[0083] The recording medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a mobile medium, a hard disk or an SSD.

[0084] On the other hand, the recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program it contains is remotely executable. The program according to the invention may in particular be downloaded over a network, for example an Internet-type network.

[0085] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned transport method.

[0086] According to an exemplary embodiment, the present technique is implemented by means of software and / or hardware components. Brief description of the drawings

[0087] Other characteristics and advantages of the invention will appear more clearly on reading the following description of particular embodiments, given as simple illustrative and non-limiting examples, and the appended drawings, among which:

[0088] [Fig.la], [Fig.lb], [Fig.lc], [Fig.ld], [Fig.le], [Fig.lf], [Fig.lg], [Fig.lh] and [Fig.li] illustrate the transport format defined for the EVS codec, described previously;

[0089] [Fig.2] illustrates an embodiment of a voice over IP communication system and a method of generating a data transport format according to an embodiment of the invention as well as a method of receiving such a transport format data ;

[0090] [Fig.3a], [Fig.3b], [Fig.3c] and [Fig.3d] illustrate a first embodiment according to the invention of a transport format adapted to the extended IVAS codec extending an EVS mono audio codec, and to the EVS mono codec by the use of an unused and existing field of the data transport format of the mono audio codec to signal the extended audio codec and by the use of another field to transmit at least information of the rate of the extended audio codec;

[0091] [Fig.4a], [Fig.4b], [Fig.4c], [Fig.4d] and [Fig.4e] illustrate a second and third embodiment according to the invention of a transport format adapted to the IVAS extended codec and to the EVS mono codec by the use of at least one existing codec adaptation request field, unused or reserved, of the mono audio codec to transmit information of the rate of the extended codec to be used;

[0092] [Fig.5a] illustrates a fourth embodiment according to the invention of a transport format adapted to the IVAS extended codec and to the EVS mono codec by the use of at least one existing codec adaptation request field, unused or reserved, of the mono audio codec to inform of the existence of a second code specifying a format and / or a bit rate of the extended codec to be used in reception or transmission;

[0093] [Fig.5b] and [Fig.5c] illustrate the extended coding format codes and the rate codes specified by this second code depending on reception or transmission;

[0094] [Fig.6] illustrates a fourth embodiment according to the invention of a transport format adapted to the extended IVAS codec and to the mono EVS codec by the use of the fields as defined in [Fig.4b] and [Fig.5a]; and

[0095] [Fig.7] illustrates a hardware embodiment of a terminal implementing the method for generating a data transport format according to one embodiment as well as a method for receiving such a data transport format. Description of the embodiments

[0096] The invention will now be described below with reference to Figures 2 to 7.

[0097] [Fig.2] illustrates an example of a two-way communication system between two communication devices A and B, for example two communication terminals A and B or a communication terminal A and a network device B (or vice versa).

[0098] The communication devices implement a method for generating an audio data transport format according to one embodiment of the invention. The ambient acoustic signal is for example picked up by one or more microphones (101 and 151) on each side of the communication.

[0099] The remote signal is reproduced on one or more loudspeakers (102 and 152). The audio signals captured and reproduced generally undergo different treatments acoustics in transmission (101 and 151) and in reception (103 and 153) such as for example:

[0100] • analog / digital conversion, gain control, noise reduction, cancellation echo, etc. in transmission

[0101] • digital / analog conversion, gain control, etc. on reception.

[0102] The figure here does not represent the acoustic treatments or the network (whose treatments and equipment such as antennas, modem, etc.) connecting the two terminals, for the sake of conciseness and clarity.

[0103] In one embodiment, one of the devices A or B can be replaced by network equipment, which can be a “media gateway” (e.g.: IMS-AGW), a conference bridge (e.g.: MRFP), a voicemail server, etc. In order not to make the text too long, we describe below the example of a communication between two terminals A and B, with the understanding that one of the terminals can be a network termination (without sound recording / acoustic rendering in general).

[0104] In the case where one of the terminals is network equipment, the interface providing the input signals of the encoder or recovering the output signals of the decoder / renderer is directly electrical.

[0105] Terminal A comprises a transmitter 101 and a receiver 103 while terminal B comprises a transmitter 151 and a receiver 153. The two terminals A and B are typically configured according to an exchange of offer(s) / response(s) according to the SDP protocol (for “Session Description Protocol” in English), via the respective blocks 100 and 150. Typically this SDP configuration is used at least during the instantiation (initialization or re-initialization) of the transmitter and the receiver; in variants of the invention it may be considered that this configuration is internal to the terminal and makes it possible to configure the SDP offer of the terminal and its response. In variants of the invention other signaling protocols for media capabilities / configurations (session descriptions) equivalent to or derived from SDP may be used in an equivalent manner.

[0106] Transmitters have functions of coding, generation of RTP packets by adding protocol headers to generate a transport format (payload format) corresponding to the coding format. A transmitter also has a function of possible adaptation of the transport (aggregation, redundancy or other) as well as a function of transmission of packets.

[0107] Thus, a transmitter of a communication device as described implements a method for generating an audio data transport format during a real-time communication session with another communication device.

[0108] For this, as described in more detail later, the data transport format for an extended audio codec (IVAS) extending a mono audio codec (EVS), reuses the data transport format of said mono audio codec. At least one existing, unused or reserved field of the data transport format of said mono audio codec, is used to signal the extended audio codec and / or to transmit at least information of the rate of the extended audio codec.

[0109] Receivers have functions of receiving RTP packets, extracting fields from the RTP header, decoding the transport format and decoding frames which may include jitter buffer management, audio decoding and correction of lost frames.

[0110] Thus a receiver of a communication device is able to receive and decode a transport format as generated by a transmitter of another communication device. To do this, it extracts at least one unused and existing field from the data transport format of the mono audio codec (EVS) and checks whether it signals the extended audio codec (IVAS) and / or gives information on the bit rate of the extended audio codec (IVAS). In an embodiment described later, it is another field of the data transport format which is used to transmit at least information on the bit rate of the extended audio codec.

[0111] Terminals A and B comprise a request decoding block (blocks 107 and 157), in particular for CMR requests as described in Figures 4 to 6 later. Block 107 or 157 consists of reading the relevant part of the packet associated with the codec (IVAS including EVS). It is assumed here that the result of the request decoding by blocks 107 and 157 is for example stored in a memory element called here "adaptation_info" containing a structure shared with the transmission part (blocks 101 and 151) and this "adaptation_info" element itself comprises a stored element "adaptation_info.updated" which is equal to 1 when a request (CMR or other) has been received and 0 otherwise. Block 101 or 151 checks, before encoding each new frame, whether the value of "adaptation_info.updated" is 1 and if so it configures the encoding according to the requested bit rate or the requested data format.

[0112] Several embodiments for generating the data transport format during a communication between the two terminals A and B and the data transport format are now described. This data packet transport format exchanged between the terminals is compatible with the immersive coding and decoding of audio signal as implemented by an IVAS codec. This data transport format is also backward compatible with the coding and decoding of a mono audio signal, for example implemented by an EVS mono codec.

[0113] This data transport format can also be used for data storage and therefore be recorded in a memory accessible by communication terminals.

[0114] Before detailing a detailed example of a transport format for IVAS, we first look at the use cases of the IVAS codec.

[0115] The simplest use case for IVAS involves a call between two terminals connected over a network, for example 5G. These terminals can be smartphones equipped with multiple microphones and support the following formats: - Mono: fallback case on an EVS compatible call, given that EVS is included in IVAS - Stereo with sound recording on 2 telephone microphones or with stereo sound from processing of a microphone antenna - Binaural: only when a phone is connected to earphones that incorporate microphones and thus capture natural binaural sound - MASA: format with a mono or stereo signal supplemented by spatial information from a scene analysis as described in 3GPP Tdoc S4-220443, “MASA format updates,” April 2022, Source: Nokia, Orange

[0116] This list is not exhaustive, this example simply shows that the coding format supported and displayed in SDP for IVAS would be, for example, a list:

[0117] [MONO, STEREO, BINAURAL, MASA1, MASA2]

[0118] We can consider that the MONO format is redundant in this list and that it is necessarily included as a basic format in the IVAS codec since EVS is included in IVAS.

[0119] We can also consider that STEREO and BINAURAL are 2-channel formats that are coded in a nearly identical way, so they could be combined into a single type of coded format for defining terminal capabilities: the main justification for differentiating BINAURAL is to address use cases where microphones are placed on earpieces during communication, while STEREO is for microphones on a smartphone.

[0120] Similarly MASA1 and MASA2 could both be supported but in a call a priori only one type of format should be used at a time, even if in theory the acoustic treatments could be upstream of the MASA analysis and therefore allow real-time switching.

[0121] If both terminals A and B have the same coding / decoding / rendering capabilities, the terminal receiving such an offer could either choose a single format or keep a list (complete or partial) which supposes a potential format switching possible during the call. In reality it seems more realistic and simpler to select only a stereo or immersive format, with possibly the possibility of degrading the number of channels in the same type of format, in particular during transmission to keep a coherent sound recording over time, decoupled from the coding.

[0122] In IVAS there is no internal signaling to the codec bitstream for dif STEREO and BINAURAL, so it is important to negotiate different formats, so that the rendering can adapt and the receiving terminal only accepts BINAURAL when headphones or earphones are used for direct listening.

[0123] Keeping more than one stereo / immersive format also raises an ambiguity related to the order of formats which normally indicates a preference (from best to worst).

[0124] Subsequently, it is assumed that a single stereo / immersive format is selected in SDP by the receiver of an IVAS SDP offer - this however allows the number of channels to potentially be reduced or increased (for example from HO A3 to FOA, or 5.1 to stereo and vice versa) within the limit of the maximum negotiated format (for example HO A3 or 5.1). The format selection rules remain to be defined if more than one format is offered and supported; they are beyond the scope of the invention.

[0125] If a change in encoding format is necessary, then SDP renegotiation must be employed.

[0126] This simple use case becomes more complicated if we imagine a scenario where one of the terminals switches from a 5G network (with IVAS support) to a 4G network supporting only EVS codec. In this handover case, it is important not to cut the call and if possible to avoid end-to-end codec renegotiation during the call - which would involve a long interruption time - and also to avoid transcoding between IVAS and EVS in a media gateway in the network.

[0127] It is also recalled that EVS is typically used with bit rates of 5.9 to 13.2 or 24.4 kbit / s in a band of the "nb-wb" or "nb-swb" or "swb" type, while IVAS bit rates only start from 13.2 kbit / s and the NB band is not supported by IVAS (except mono). It is therefore important that the IVAS payload format takes these constraints into account.

[0128] In the case of "handover", one could also imagine that certain network solutions would still prefer to transcode between IVAS and EVS in a "media gateway" (MGW) to avoid managing "handover" cases too finely; however, it would be possible, for example, that the MGW does not support all combinations of format / bit rate / coded band (e.g.: FB band) and the MGW could send a CMR to one of the terminals to force the encoder to change format / bit rate / band.

[0129] We can also take another example of a use case where an IVAS compatible terminal (and therefore EVS since IVAS includes EVS) connects to a spatial conference bridge or a video game platform. Typically the telephone could only send in mono but receive for example in binaural or even in a multichannel format like 5.1.

[0130] If the terminal receiving an immersive stream is connected to a headset or earphones it seems preferable to receive or decode a binaural signal.

[0131] In all cases the receiving terminal could indicate its decoding and rendering capabilities (renderer) in the form of a list such as with elements separated by hyphens to indicate that certain formats are included in others and indicated in the form of a minimum format-maximum format type interval (e.g.: STEREO-5_1), which would give a list of decoding / rendering capabilities such as:

[0132] [MONO, BINAURAL, STEREO-5_1]

[0133] The reception part generally depends on a rendering audio chain which must be initialized but which can be decoupled from the decoding, which makes it possible to go from a headset to listening on a single speaker of a smartphone then a 5_1 system in a vehicle or a meeting room. Thus, unlike in the case of transmission, it is less problematic to signal a list of possible formats in reception. On the other hand, there may be some ambiguity on the order to be used which could indicate a preference, but it can be assumed that the receiving terminal would use the most appropriate format depending on the rendering / listening context.

[0134] Here again, these negotiation aspects remain open and go beyond the scope of the invention. On the other hand, it is important to take into account the presence of SDP parameters which can impact the transport format. It is assumed here that the existing parameters for EVS are taken over in IVAS and that at least one additional parameter called for example "fmt-send" is added to negotiate the coded stereo / immersive format capabilities. It can also be considered that a terminal can also declare another parameter specific to IVAS "fmt-recv" which would indicate which reception formats are supported for rendering, which makes it possible to avoid selecting for example an MC714 coding if the rendering is limited to STEREO.

[0135] In the embodiments described below, transport formats of the IVAS immersive codec are specified allowing: - to ensure continuity of service between IVAS and EVS codes - ensure that the EVS codec can fall back to mono format as provided in the IVAS codec, even if the current call has been negotiated for an immersive input / output format (stereo, etc.). Thus, it is possible to use the IVAS codec but switch to the EVS codec at one end of the chain without stopping or renegotiating a call. - to define the simplest possible IVAS codec transport format as a natural extension of the EVS codec transport format.

[0136] Thus, according to the embodiments described below, the audio data transport format for an extended audio codec (IVAS) uses an extension of a data transport format of a mono audio codec (EVS), at least one existing field of the unused or reserved mono audio codec data transport format used to convey at least extended (stereo / immersive) audio codec bitrate information or to signal extended audio codec.

[0137] Before describing different embodiments according to the invention, examples are first given illustrating how the IVAS codec could be negotiated as an extension of the EVS codec at the SDP level. These examples are by no means definitive because the payload format is still completely open.

[0138] Appendix 1 describes a (simplified) SDP offer of terminal A

[0139] This first example deals with an SDP offer that allows initiating an audio call with the IVAS codec including the EVS codec. The UDP port, the VP profile A and the payload type (PT) are indicated in the media line "m". The payload type numbers are PT=96 for IVAS or 97 for EVS.

[0140] The "rtpmap" and "fmtp" parts indicate the media format parameters.

[0141] It is assumed here that IVAS and EVS are offered in the offer with the “telephoned event » usual in telephony.

[0142] Appendix 2 describes a possible example of a (simplified) SDP response from terminal B.

[0143] here we consider that only the IVAS offer is retained with restrictions and the “telephoned event” is also retained (typically obligatory for telephone services).

[0144] The SDP parameters in Appendix 1 and 2 are described here for illustrative purposes only. For simplicity, it is assumed that the existing parameters (br, bw) are reused and extended, and parameters specifying the coding and rendering formats supported by the terminals have been added (in the form of a list in square brackets).

[0145] It is considered here that the EVS SDP parameters corresponding to MONO are differentiated from the IVAS SDP parameters, in fact IVAS has particularities such as a bit rate starting at 13.2 kbit / s or an NB audio band which is not supported, which requires these parameters to be differentiated in general. Rules can be defined to ensure consistency, for example on the "cmr" parameter.

[0146] In a first embodiment, the extension of the transport format is carried out by providing an extension of the header data format defining the EVS table of contents “ToC”. Here, we are interested in the transport format of the EVS codec of the “header-full” mode.

[0147] According to this embodiment, the ToC byte has the same format as EVS, which is taken up and extended for IVAS.

[0148] Thus the IVAS ToC byte has the same definition as the EVS ToC byte illustrated in [Fig. If] and described above.

[0149] The first bit H=0 makes it possible to distinguish a ToC byte from a CMR byte in the payload header.

[0150] The F bit is set to 1 if the coded frame corresponding to the ToC byte is followed by another frame. It is set to 0 if the corresponding frame is the last in the payload, which implies that the ToC byte is the last and that no other ToC byte follows it.

[0151] In the first embodiment, the ToC byte for IVAS takes up the structure of the ToC byte of EVS as shown in [Fig.3a].

[0152] The FT_IVAS field (6 bits) is defined according to the tables shown in figures 3b, 3c, 3d.

[0153] In [Fig.3b], we see the same configuration as for the EVS codec in [Fig.lh], that is to say that the FT field is divided into 3 parts EVS mode (1 bit), Unused / Q bit (1 bit) according to the EVS mode bit, and EVS rate (4 bits). However, here, the EVS "Unused / Q bit" field is replaced by a field specifying the use of an IVAS codec (bit at 1) or not (bit at 0). If this field is at 0, we remain in the definition of the table in [Fig.lh], on the other hand, if this bit is at 1, then the following field indicating the possible rates for EVS, will use the same codes to this time indicate the possible rates of the IVAS codec.

[0154] [Fig.3c] illustrates this scenario where we see that the first 1-bit field, at 0, shows the EVS or IVAS mode (unlike the AMR WB IO mode of [Fig.li]), the second 1-bit field (at 1) shows that the IVAS codec is used and the codes of the following 4-bit field indicate the different possible bit rates of the IVAS codec (from 13.2 to 512 kbit / s, as well as IVAS SID and SPEECH_LOST). Here IVAS SID corresponds to the coded SID frames corresponding to the inactive frames when the IVAS DTX mode is activated; SPEECH_LOST indicates a lost frame.

[0155] [Fig.3d] is identical to [Fig.li] for the EVS AMR-WB IO part.

[0156] Thus, the transport format from the EVS codec is extended for the IVAS codec, an EVS coded frame can be indicated as in the EVS payload format and it is not necessary to provide another format specific to the IVAS codec because all the data necessary to indicate the type of IVAS frame can be represented by exploiting the unused bit of the FT field in the EVS payload format.

[0157] In variants, additional extensions of the ToC byte can be provided. These are not described here because they remain under discussion and to be defined for the IVAS codec, but they can be similar for example to the idea of ​​the "PI_frame" of the second proposal cited in the state of the art. Since there is no field available in [Fig.3c], these extensions could be signaled in different ways, either using an RTP header extension (outside the payload) or taking another code like the 'For future use' code of [Fig.3b] which is normally for EVS Primary (EVS bit rate = '1101') but which in the IVAS context would indicate an IVAS-specific data frame.

[0158] In a second embodiment, at least one existing request byte codec adaptation (CMR), comprising an unused or reserved field of the EVS mono audio codec, is used to transmit at least information on the codec rate to be used, and optionally, according to the invention, an additional byte specific to IVAS can be added.

[0159] We are interested here in the transport format of the EVS codec of the “header-full” mode. To define the transport format of the IVAS codec, we extend the transport format of the EVS codec by extending the use of the CMR byte.

[0160] Thus the IVAS CMR byte according to the invention follows the same definition as the EVS CMR byte illustrated in [Fig. 1c] and reproduced here in [Fig. 4a]. described above with a minor extension of the T and D fields; the latter is here named D_IVAS to differentiate it from the D field defined in EVS.

[0161] The first bit H has the value H=1 to specify that a CMR request exists.

[0162] The fields T (3 bits) and D_IVAS (4 bits) are defined as in the tables of the [Fig.lg] except for the values ​​associated with the field T=' 111' which are modified according to the values ​​defined in the table illustrated in [Fig.4b].

[0163] Thus, the values ​​defined as 'Reserved' in the EVS CMR format are now defined as IVAS codec rates from 13.2 to 512 kbit / s. This embodiment therefore makes it possible to define a rate adaptation request, i.e. the rate that the terminal sending the CMR request wishes to receive.

[0164] In a third embodiment, it will be possible to authorize - unlike EVS - to have more than one CMR byte in a packet for the IVAS codec, as illustrated in [Fig.4c]. If a CMR must be transported in the current packet, it will first be possible to insert a first byte in the header of the payload in the second embodiment and as in [Fig.4a], which allows to make a request to change IVAS rate or a switch to a mono EVS mode - unless NO_REQ is used, in which case the CMR carries an "empty" request. Then, optionally, it will be possible to add a second CMR byte, whose first most significant bit H will also be set to 1, to differentiate the byte from a ToC byte. The remaining 7 bits then represent a change of format at transmission, for example, it is possible to use the last 5 FMT_IVAS bits to indicate the coding format as in [Fig.4e] and the other 2 remaining BW_IVAS bits to indicate the audio band (WB, SWB, FB for IVAS) as in [Fig.4d]. This optional addition of a second CMR byte does not pose any ambiguity problem for writing / reading the payload: when reading, we start by reading the first byte, if the MSB bit is at 1, it is a CMR, then we read the second byte, if the MSB is also at 1, it is still a CMR request, and in this case the third byte will be of the ToC type with an MSB at 0 according to the invention.

[0165] Note that [Fig.4e] includes reserved fields (Reserved) to allow for possible extension of IVAS coding formats, for example for applications separate rendering between network (edge, cloud) and terminal using the split rendering method.

[0166] In a fourth embodiment of the invention, the values ​​associated with the field T='111' are modified in another way, as illustrated in [Fig.5a]. In this embodiment, an existing unused or reserved codec adaptation request field of the EVS mono audio codec is used to inform of the existence of a second codec specifying the codec rate to be used in reception. Thus, in the example illustrated in [Fig.5a], the codes D='0000' and D='0001' initially defined as "Reserved" for the EVS codec are replaced by other codes named "Escape Input" and "Escape Output", where 'escape' is here an indication of extension of a CMR byte by another byte.

[0167] Thus, if the CMR byte is defined by T = '111' and D='0000', in the case of "Escape Input", this indicates that an additional CMR byte is defined immediately after the first CMR byte and this second byte has values ​​for example according to the format CF (4 bits) BR (4 bits) as defined in the table illustrated in [Fig.5b]. This additional byte indicates a request to change the immersive coding format (values ​​defined by the code CF for "code format") and / or the bit rate (values ​​defined by the code BR for "Bit rate") in reception, i.e. the bit rate that the terminal sending the CMR request wishes to receive.

[0168] Unlike the third embodiment, this variant with reference to [Fig.5b] does not allow differentiation between STEREO / BINAURAL or MAS Al / MASA2 which could be a problem in certain applications.

[0169] Similarly, if the CMR byte is defined is T = '111' and D='0001', in the case of "Escape Output", this indicates that an additional CMR byte is defined immediately after the first CMR byte and this second byte has values ​​for example according to the format CF (4 bits) BR (4 bits) as defined in the table shown in [Fig.5c]. This additional byte indicates a request to inform the decoding / immersive rendering format (values ​​defined by the code CF for "code format") and / or request to change the bit rate (values ​​defined by the code BR for "Bit rate") in transmission, i.e. the bit rate that the sender of the CMR request sends.

[0170] In a fifth embodiment, it will be possible to combine previous variants to have a CMR byte format as illustrated in [Fig.6].

[0171] In variants, the CMR field(s) (in one or two CMR bytes) according to the invention may be inserted into an RTCP packet (of the RTCP-APP or RTCP-FB type) in the case where an adaptation according to the AVPF profile is authorized; in this case the CMR field(s) may not be used in the RTP packets. In addition, the use of the CMR (only change of bit rate and / or format) may be controlled by an SDP parameter such as the “cmr” parameter already defined in the EVS codec payload format.

[0172] The invention has been described so far with a transport format in mode "header-full". In variants of the invention, a default transport format mode can be used for the IVAS extended codec, as in EVS. There are actually two ways to apply this default mode: - compact EVS mode reused as is (with protected sizes as defined in 3GPP TS 26.445 Annex A) and header-full mode for EVS / IVAS according to the invention (with zero padding to avoid size conflicts. - IVAS compact mode for bitrates from 13200 to 512000 bit / s with protected sizes as in Table 3 below.

[0173] [Tables3] 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

[0174] In variants, the extended codec transport format (IVAS) may also include the possibility of extending the RTP header, for example to transport information such as the orientation of a terminal.

[0175] The payload format of the IVAS codec according to the invention assumes that a change of format is possible at least between mono and stereo / immersive format, both on transmission and on reception.

[0176] Mono (EVS) and stereo / immersive (IVAS) switching must be able to be done at any time frame, in particular following the reception of a CMR according to the invention.

[0177] We recall that the algorithmic delay of the EVS codec is 30.9375 ms in NB and 32 ms for the other bands (WB, SWB, FB).

[0178] For IVAS, the algorithmic delay is 32 ms (e.g. stereo) to 38 ms. To be able to switch without time alignment problems, it is therefore important to synchronize the coding and decoding / rendering parts by applying the necessary delay difference depending on the operating mode. It should also be noted that in the case of binaural rendering, a possible delay due to binauralization and the possible presence of additional reverberation must be taken into account to ensure switching without artifacts.

[0179] It is assumed here that the switching can be done by "resetting" the coding. In order to avoid too long an audio signal convergence time, it is possible to resynchronize memories / states of the EVS / IVAS codec according to the past frames and to use an "intelligent" reduction or increase of channels / parameters according to the formats.

[0180] During decoding, it is also necessary to be able to ensure that a loss of frame does not severely impact the switching (e.g.: first mono frame lost after a series of IVAS frames, before receiving the other EVS frames).

[0181] Here we take the concrete case of switching between IVAS STEREO and EVS (mono).

[0182] At frame T we assume that we are in STEREO, at frame T+1, following reception of a CMR, the encoding switches to EVS mono mode. Ideally, the audio bands encoded for IVAS and EVS should be identical (e.g., SWB). Since IVAS includes an EVS-compatible stereo-to-mono channel reduction mode, the main difficulty in switching is to avoid signal discontinuity when decoded and also to properly initialize the codec states during switching.

[0183] At decoding (at reception), the STEREO to MONO switching is detected when reading the payload which is STEREO at frame T and MONO (EVS) at frame T+1. In this case, the “reset” is a simple solution which could nevertheless result in audio artifacts. Here we can consider that the algorithmic delay at decoding can be exploited to crossfade the audio outputs of frames T and T+1.

[0184] The same approach can be used for the other switching direction (from MONO to STEREO) with a reset of the states and the use of a crossfade during decoding.

[0185] This example generalizes to other stereo formats: for the BINAURAL format, the processing is very similar to the STEREO case. For other immersive formats, switching to MONO involves a reduction in the number of channels. Switching can be achieved by resetting the codec states, possibly using a crossfade.

[0186] [Fig.7] now describes an example of a hardware embodiment of a communication device, for example a communication terminal implementing the method for generating data transport format according to the invention, as described with reference to figures 3 to 6 described above.

[0187] The terminal TA comprises a storage space 11, for example a memory MEM, a processing unit 10 comprising a processor P, controlled by a computer program PG, stored in the memory 11 and implementing the transport method according to the invention.

[0188] At initialization, the code instructions of the program PG are for example loaded into a RAM memory (not shown) before being executed by the processor P of the processing unit 10. The program instructions can be stored on a storage medium such as a flash memory, a hard disk or any other non-transitory storage medium.

[0189] The processing processor implements the transport method as described with reference to [Fig.2], and according to the formats described with reference to Figures 3 to 6, according to the PG program instructions.

[0190] The terminal TA comprises a communication module 12 capable of receiving and transmitting real-time data to a communication network R and capable of reading signaling or configuration data of the SDP type 13 either through the signaling transmitted in the network or in the memory 11 of the terminal.

[0191] The terminal comprises a receiver module 14 capable of receiving and decoding a transport format as generated by a transmitter of another communication device and as described with reference to FIGS. 3 to 6. For this purpose, it extracts fields from the RTP header, in particular the values ​​transmitted in the existing, unused or reserved fields, of the data transport format of the mono audio codec, in order to know at least the bit rate information of the extended audio codec. The receiver module is also capable of managing a reception memory, decoding the received frames and correcting any frame losses.

[0192] The terminal comprises a transmitter module 15 capable of encoding and generating RTP packets by adding the protocol headers to generate a transport format (payload format) corresponding to the coding format. A transmitter also has a function for possible adaptation of the transport (aggregation, redundancy or other) as well as a packet transmission function.

[0193] Thus, the transmitter module implements a method for generating an audio data transport format during a real-time communication session with another communication device.

[0194] For this, the data transport format for an extended audio codec (IVAS) extending a mono audio codec (EVS), reuses the data transport format of the mono audio codec. At least one existing, unused or reserved field of the data transport format of said mono audio codec, is used to signal the audio codec extended and / or to transmit at least information of the rate of the extended audio codec. Several embodiments of this data transport format are described with reference to Figures 3 to 6.

[0195] The term module can correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.)

[0196] The terminal is for example a telephone, a smartphone, a tablet, a computer, a residential gateway or a connected object. APPENDIX 1

[0197] SDP offer (simplified) of 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=s wb ;fmt- send=[ STEREO, MASAl-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 ANNEX 2

[0198] SDP response (simplified) from 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

Claims

Claims

1. Method for generating an audio data transport format during a real-time communication session between communication devices (A, B), in which the data transport format for an extended audio codec (IVAS), extending a mono audio codec (EVS), reuses the data transport format of said mono audio codec, and where at least one existing, unused or reserved field of the data transport format of said mono audio codec is used to signal the extended audio codec and / or to transmit at least information of the rate of the extended audio codec.

2. The method of claim 1, wherein an unused and existing field of the data transport format of said mono audio codec is used to signal the extended audio codec and another field is used to convey at least information of the rate of the extended audio codec.

3. The method of claim 1, wherein at least one existing, unused or reserved codec adaptation request (CMR) field of the mono audio codec is used to transmit at least information of the rate of the extended codec to be used.

4. The method of claim 3, wherein each of the possible rates of the extended codec is indicated in an existing, unused or reserved codec adaptation request field of the mono codec.

5. A method according to claim 3, wherein an existing unused or reserved codec adaptation request field of the mono audio codec is used to inform of the existence of a second codec specifying a format and / or bit rate of the extended codec to be used in reception.

6. The method of claim 3, wherein an existing unused or reserved codec adaptation request field of the mono audio codec is used to inform of the existence of a second codec specifying a format and / or bit rate of the extended codec used in transmission.

7. Communication terminal comprising a processing circuit capable of implementing a method for generating an audio data transport format during a real-time communication session with a communication device, in which the data transport format for an extended audio codec (IVAS), extending a mono audio codec (EVS), reuses the data transport format of said codec mono audio, at least one existing, unused or reserved field of the data transport format of said mono audio codec being used to transmit at least information of the rate of the extended audio codec.

8. Audio data transport format for an extended audio codec (IVAS), extending a mono audio codec, reusing the data transport format of said mono audio codec (EVS) in which at least one existing, unused or reserved field of the data transport format of said mono audio codec is used to signal the extended audio codec and / or to transmit at least information of the rate of the extended audio codec.

9. Computer program comprising code instructions for implementing the steps of the generation method according to one of claims 1 to 6, when these instructions are executed by a processor.

10. Storage medium, readable by a processor, storing a computer program comprising instructions for executing the generation method according to one of claims 1 to 6.

Images