Signalling of a request to adapt a voice-over-ip communication session

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is a Section 371 National Stage Application of International Application No. PCT/FR2018/052256, filed Sep. 14, 2018, the content of which is incorporated herein by reference in its entirety, and published as WO 2019/068982 on Apr. 11, 2019, not in English.

FIELD OF THE DISCLOSURE

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

0003The Internet protocol (IP) developed by the IETF (for Internet Engineering Task Force) is implemented in packet communication networks both to support non real-time services such as data transfer services, website-browsing services and electronic-messaging services, and real-time or conversational services, such as telephony over IP, video telephony over IP or even video streaming over IP.

0004The invention more particularly relates to a signaling of an adaptation request that requests adaptation of the coding/decoding of real-time signals such as voice or video signals during a real-time communication session between two communication terminals.

BACKGROUND OF THE DISCLOSURE

0005An example of an existing voice-over-IP communication system is described with reference to <figref idref="DRAWINGS">FIG. 1</figref>. This figure illustrates a bidirectional voice-over-IP (VoIP) communication system with two telephony terminals (<b>100</b> and <b>150</b>) connected by an IP packet network (<b>125</b>). The “signaling plane” is not shown in this figure; however possible solutions for setting up and managing calls may be based on various known protocols such as: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0006">SIP/SDP (for Session Initiation Protocol/Session Description Protocol) according to IETF specifications RFC 3261 and RFC 4566, as in multimedia services over IMS (for IP Multimedia SubSystem). In order to facilitate signaling exchanges on media capacities and the associated offers/answers, it is also possible to use “SDPcapneg” according to IETF specification RFC 5939.</li><li id="ul0002-0002" num="0007">JSEP (for JavaScript Session Establishment Protocol) which uses SDP syntax to define WebRTC session descriptions (with an exchange via WebSocket or another means).</li><li id="ul0002-0003" num="0008">H.323/H.245.</li></ul></li></ul>

0009<figref idref="DRAWINGS">FIG. 1</figref> is a simplified view of the “media plane” and of the audio chain used when the call is set up. Here, only the case of a mono audio signal is considered, the ambient acoustic signal for example being captured by a microphone (<b>101</b> and <b>151</b>) at each end of the communication. It will be noted that the case of a mono input/output signal may easily be generalized to a multichannel case.

0010The remote signal is rendered via a loudspeaker (<b>102</b> and <b>152</b>). The captured and rendered audio signals in general undergo various acoustic processing operations when sent and when received (<b>103</b> and <b>153</b>) such as for example: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0011">analog/digital conversion, gain control, noise reduction, echo cancellation, etc., when sent</li><li id="ul0004-0002" num="0012">digital/analog conversion, gain control, etc., when received.</li></ul></li></ul>

0013When sent, the preprocessed audio signal is coded into successive frames—typically with an (in general fixed) frame length ranging from 10 to 60 ms—and the coded frames are formed into IP packets (<b>104</b> and <b>154</b>).

0014The packets are typically transported using the RTP protocol (RTP standing for Real Time Protocol), which is described in IETF specification RFC 3550, this protocol being located above the IP/UDP (for User Datagram Protocol) transport protocols. It will be noted that the UDP protocol may be replaced by another transport protocol, for example by TCP (for Transmission Control Protocol) in order in particular to facilitate passage through networks with NAT (for Network Address Translation), proxies or firewalls.

0015When received (<b>105</b> and <b>155</b>), the packets are delivered to a jitter buffer that aims to compensate for variations in the reception times, and the signal is decoded (while compensating for any loss of frames) and lastly the reconstructed signal is post-processed (<b>103</b> and <b>153</b>) and rendered.

0016The communication is here assumed to be bidirectional and the communication system thus forms a closed-loop system with feedback. The feedback may be transported in two ways: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0017">“Out of band” (i.e. contained in packets that form an additional stream with respect to the RTP media stream). Typically, the RTCP protocol (RTCP standing for Real-Time Control Protocol) is used as feedback channel. RTCP allows control packets to be transmitted in packets separate from the RTP stream. It will be recalled that RTCP packets may be of substantial size and therefore result in a non-negligible additional bit rate; in addition, the possible loss of packets may be problematic, because if RTCP is used for adaptation purposes the transported request may be lost. The transmission of packets using RTCP protocol may be discontinuous and non-repetitive, this possibly making the adaptation less reactive and dependent on the network conditions (packet losses, etc.).</li><li id="ul0006-0002" num="0018">“In band” (i.e. in the RTP media stream). This type of feedback may be considered more robust than RTCP because it is possible to repeat a given request in a plurality of successive packets (typically every 20 ms for codecs such as AMR, AMR-WB or EVS, which are considered below). It will be noted that in certain situations (call waiting, listening to voicemail, etc.), it is possible for the RTP packets to be sent in a single direction, however it is here assumed that the transmission of RTP packets is bidirectional for the feedback to work.</li></ul></li></ul>

0019It will be recalled that there are various RTP-protocol profiles the main ones of which are AVP (for Audio Video Profile) according to specification RFC 3551 and AVPF (for Audio Video Profile with Feedback) according to specification RFC 4585. Without loss of generality, the secure versions thereof (SAVP and SAVPF where the prefix “S” means “Secure”) are not reviewed here because these security aspects are beyond the scope of the invention. A major difference between AVP and AVPF is the time constraints on the transmission of RTCP packets: with AVP it is possible to send an RTCP packet on average only every 5 seconds, this in general being insufficient to achieve a reactive adaptation in case of very variable network conditions. In addition, with the AVFP protocol it is possible to use RTCP FB (FB for FeedBack) messages whereas only RTCP APP (APP for “Application defined”) packets are defined in AVP for transporting feedback outside of the RTCP reports (SR and RR).

0020In general, a plurality of types of degradation may potentially affect the quality of voice over IP: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0021">variable bandwidth/congestion of the network</li><li id="ul0008-0002" num="0022">losses, de-sequencing, repetition of packets</li><li id="ul0008-0003" num="0023">delay, variation in packet transmission delay</li><li id="ul0008-0004" num="0024">clock drift between the terminals</li></ul></li></ul>

0025There are various solutions for mitigating these various types of degradation, including terminal adaptation solutions. Two types of adaptation may be distinguished between in VoIP terminals: sender-based adaptation and receiver-based adaptation.

0026For the sender to be able to adapt and decide on its adaptation (“sender-based” adaptation), said sender must receive feedback from the remote receiver indicating, for example, the observed loss rate or the available bandwidth as estimated by the remote receiver.

0027In a “receiver-based” adaptation, the feedback received by the local sender (<b>104</b>) is an adaptation decision (for example the choice of the mode or rate to be used) made by the remote receiver (<b>155</b>)—this feedback is transmitted first to the remote sender (<b>154</b>) then to the local receiver (<b>105</b>).

0028In <figref idref="DRAWINGS">FIG. 1</figref>, this feedback is indicated by dashed arrows pointing in the direction from the receiver <b>155</b> to the sender <b>104</b>. Of course, this feedback may be given in the other direction of the communication, with feedback, from the receiver <b>105</b> to the sender <b>154</b>, transmitted via the blocks <b>104</b> and <b>155</b>; this inverse direction is not shown in <figref idref="DRAWINGS">FIG. 1</figref> in order not to clutter this figure.

0029In one example of adaptation solutions, to control variation in bandwidth or congestion of the network, it is possible to implement the techniques described below.

0030When a codec operates at a fixed rate, one adaptation solution for modifying the actual data rate over the network consists in varying the number of consecutive signal frames in a packet (frame bundling) and thus varying the packet rate and the relative rate of IP/UDP/RTP protocol headers (and of protocol headers of lower layers). When the call negotiation uses the SDP protocol, the ability to use this adaptation of the packet rate depends on the parameters “ptime” and “maxptime”, which respectively define the minimum and maximum possible lengths of a frame. For example, for ptime=20 and time maxptime=240, a packet represents 20 ms of signal and it is possible to multiplex up to 12 frames per packet.

0031<figref idref="DRAWINGS">FIGS. 2<i>a </i>to 2<i>d </i></figref>illustrate examples of IP packet formats in which one or more frames are sent per packet. The default packet generation mode is considered to correspond to the case of <figref idref="DRAWINGS">FIG. 2<i>a </i></figref>in which the current frame N is placed in packet P, i.e. in which it is possible to consider that P=N. An example of frame bundling is given in <figref idref="DRAWINGS">FIG. 2<i>b</i></figref>, in which frames N and N−1 are placed in packet P—the packet rate is therefore two times lower than the frame rate and it is possible to consider that P=└N/2┘ (└⋅┘ represents rounding to the integer below).

0032When a codec is multi-rate, it is also possible to change the rate of the codec. This change in rate may be carried out depending on the available bandwidth as estimated by the remote receiver and received by feedback (“sender-based” decision) or depending on a rate change request received by feedback (“receiver-based” decision).

0033It will be noted that there are also solutions other than coding adaptation to avoid congestion—these alternative solutions do not operate at the RTP level or at the application-layer level, but at a lower level. They will not be described here because they are beyond the scope of the invention.

0034It will lastly be noted that, for non real-time applications using the TCP protocol (TCP standing for Transmission Control Protocol), one conventional approach to adaptation to channel conditions consists in varying the TCP rate using feedback via which the receiver sends a retransmission request (ARQ for Automatic ReQuest) with an indication of the packets not received; the TCP rate is adapted depending on this feedback. The indication of congestion in TCP was originally limited to the indication of losses but it has since been extended to other parameters (analysis of the variation over time in RTT (for Round-Trip Time), etc.).

0035For a degradation due to packet loss, a minimalist approach to managing this type of degradation is to apply a frame-loss correction in the receiver. This approach is merely reactive and cannot always “hide” very well “holes” (i.e. missing information that is not received) in the decoded signal, in particular when a plurality of consecutive frames are lost or if the codec used is sensitive to losses (a predictive codec for example). It is also necessary to ensure a rapid recovery (return to normal) of the audio signal; the correction for lost frames often produces artefacts that will be more or less audible depending on the type of codec and the loss correction method used. The loss correction may be implemented in the audio decoder or integrated in the receiver into the adaptation operations of the jitter buffer (by “lengthening” the current signal and “stitching” it with the future signal once available and decoded).

0036A better approach to countering frame losses is to use redundancy, i.e. to repeat entire or partial coded frames (for example, important coded parameters); this approach however has a cost in terms of data rate and delay.

0037Examples of use of partial redundancy are given for the IETF OPUS (“inbandfec” mode) and 3GPP EVS (“channel-aware mode”) codecs, which are known to those skilled in the art. Examples of use of complete redundancy (or “application-layer redundancy”) are given in section 10 of the 3GPP specification TS 26.114 (version 15.0.0) for the AMR, AMR-WB and EVS codecs. Below, “application-layer redundancy” will be shortened to “redundancy”.

0038<figref idref="DRAWINGS">FIGS. 2<i>c </i>and 2<i>d </i></figref>illustrate cases of redundancy in which the coded frame N is repeated in a following packet with a distance, called the “offset”, that is denoted K—for K=1, which is shown in <figref idref="DRAWINGS">FIG. 2<i>c</i></figref>, the packet N contains the frame N and the preceding frame N−1, whereas for K=2, which is shown in <figref idref="DRAWINGS">FIG. 2<i>d</i></figref>, the packet N contains the frame N and the frame N−2, and an empty frame (NO_DATA). For a larger offset K, the number of empty frames (NO_DATA) “inserted” between the current frame of index N and the redundant frame of index N−K is K−1. It will be noted that it is possible to combine frame redundancy and frame aggregation, this case not being described in detail here (see 3GPP TS 26.114 FIGS. 10.12 and 10.13).

0039When the call negotiation uses the SDP protocol, the use of this type of application-layer redundancy depends on the “max-red” parameter when the latter is defined in the payload format for a given codec. Typically the “max-red” parameter gives the maximum duration (in ms)—as measured by the sender—between the transmission of a frame (called the primary frame) and the transmission of a redundant version; this parameter therefore allows a maximum delay to be set when redundancy is used. For example “max-red=20” indicates that it is possible to use redundancy and that a redundant frame may be transmitted up to 20 ms after the original frame. In general, when “max-red” is set to 0, this amounts to deactivating use of redundancy and if “max-red” is not present as a signaling parameter (SDP attribute), this indicates that there is no limitation on the use of redundancy—provided that the global passband specified by the SDP parameter “b=AS:” according to IETF RFC 4566 and the coding modes permitted in the session are respected.

0040For the other types of degradation mentioned, a conventional method used to absorb network jitter, to manage packet repetitions and desequencing, and to re-establish a synchronous stream consists in using a jitter buffer on reception. Static buffers and adaptive buffers are distinguished between. These buffers in general also allow problems with clock drift to be managed. The management of jitter buffers is not reviewed here because it is beyond the scope of the invention.

0041The 3GPP specification TS 26.114 describes, as seen above, possible coding-adaptation methods. For voice, a plurality of mechanisms for signaling feedback or adaptation requests are described therein: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0042">use of CMR requests (CMR standing for Codec Mode Request)</li><li id="ul0010-0002" num="0043">the use of RTCP packets of RTCP APP type (APP standing for APPlication-defined)</li></ul></li></ul>

0044<figref idref="DRAWINGS">FIGS. 3<i>a </i>to 3<i>d </i></figref>illustrate the payload format of the AMR and AMR-WB codecs. The detailed specification of the RTP payload for AMR and AMR-WB may be found in the IETF specification RFC 4867. The mode said to be “bandwidth-efficient” is the only one described here, but it will be recalled that there is another mode that is said to be “octet-aligned”. In the octet-aligned mode all the fields of the payload—the header of the payload, the ToC entries, the coded data—are individually aligned (with zero padding if necessary) so that the length (in bits) of these fields is a multiple of 8 (therefore these fields are an integer number of octets in length); in the bandwidth-efficient mode this alignment to an integer number of octets is used only on the complete payload, and therefore this mode may be considered to be more efficient because it requires less zero padding and therefore, of the two formats, it gives the packets of smallest size. However, the octet-aligned mode has more functionalities, such as the ability to sort the coded data by robustness (robust sorting), to use interleaving, or to use a CRC code in the frame to make the transport more robust with respect to frame losses or bit errors.

0045The payload of a packet for AMR and AMR-WB is illustrated in <figref idref="DRAWINGS">FIG. 3<i>a</i></figref>: it comprises a PH header (PH standing for Payload Header), a ToC field (ToC standing for Table of Contents) and the SD data (SD standing for Speech Data) coded using AMR or AMR-WB. In the bandwidth-efficient mode, the header is simply a CMR (for Codec Mode Request) field on 4 bits as indicated in <figref idref="DRAWINGS">FIG. 3<i>b</i></figref>; the definition of the indices in <figref idref="DRAWINGS">FIG. 3<i>c </i></figref>is that of table 1a of the 3GPP specification TS 26.101, which is entitled “AMR Speech Codec Frame Structure”, version 14.0.0, for the AMR codec, and that of table 1a of version 14.0.0 of the 3GPP specification TS 26.201, which is entitled “AMR Wideband Speech Codec; Frame Structure”, for the AMR-WB codec.

0046These indices define different coding modes with different rates for the AMR and AMR-WB codec respectively.

0047The ToC field consists of a ToC entry list on 6 bits, in which the ith entry represents the ith frame contained in the current packet. Each ToC entry has the format given in <figref idref="DRAWINGS">FIG. 3<i>d</i></figref>, in which: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0048">F (1 bit): F=1 indicates that the current frame is followed by another frame in the payload; F=0 indicates that it is the last frame of the packet.</li><li id="ul0012-0002" num="0049">FT (4 bits): frame-type index, which indicates that the current frame has been coded using a certain AMR or AMR-WB mode or that it is a question of a silence identifier (SID) or of a non-transmitted frame (NO_DATA).</li><li id="ul0012-0003" num="0050">Q (1 bit): frame-quality index, if Q=0 the frame is damaged.</li></ul></li></ul>

0051It is therefore possible to transport a plurality of frames coded in AMR and in AMR-WB and the ToC field allows them to be demultiplexed unambiguously.

0052It will be noted that it is possible to add bit padding (octets of padding) at the end of the payload. In this case the bit “P” (for Padding) in the RTP header may, optionally, be set to 1 and the additional bits added as specified in RFC 3550; the last octet of this padding contains the number of octets added at the end of the payload (including this last octet).

0053The 3GPP EVS codec uses multi-mode coding. This EVS codec (EVS standing for Enhanced Voice Services) was standardized at the end of 2014. It is currently defined in two source-code versions: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0054">source code in fixed-point format (3GPP TS 26.442)</li><li id="ul0014-0002" num="0055">source code in floating-point format (3GPP TS 26.443)</li></ul></li></ul>

0056The input signal of the EVS codec is sampled at a frequency of 8, 16, 32 or 48 kHz and the codec may represent narrowband (NB), wideband (WB), super-wideband (SWP) or fullband (FB) telephonic audio bandwidths. The data rates of the EVS codec are divided into two modes: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0057">EVS Primary, which comprises <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0058">fixed bit rate coding modes: 7.2, 8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96 and 128 kb/s</li><li id="ul0017-0002" num="0059">a variable bit rate (VBR) coding mode with an average rate close to 5.9 kbit/s for active speech and that in fact uses a combination of coding modes at 2.8, 7.2 and 8 kbit/s</li><li id="ul0017-0003" num="0060">a channel-aware mode (CAM) at 13.2 kbit/s in WB and SWB only (which uses a form of partial redundancy to improve robustness to frame losses)</li></ul></li><li id="ul0016-0002" num="0061">EVS AMR-WB IO the bit rates of which are identical to the 3GPP AMR-WB codec (9 modes of 6.6 to 23.85 kbit/s)</li></ul></li></ul>

0062In addition to the above there is the discontinuous transmission (DTX) mode in which frames detected to be inactive are replaced by SID frames (SID Primary or SID AMR-WB IO) which are transmitted intermittently, on average once every 8 frames. Algorithmic details of the EVS codec are given in the 3GPP specifications TS 26.441 to 26.450 and they are therefore not repeated here.

0063The payload format for transporting with the RTP protocol data coded using EVS is defined in appendix A of the specification TS 26.445. This format is illustrated in <figref idref="DRAWINGS">FIGS. 4<i>a </i></figref>to <b>4</b><i>g. </i>

0064There are two different modes for forming the EVS packets: <ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0000"><ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0065">The mode by default: the packets are either in compact format or in header-full format, in order to avoid conflicts in size between these two modes priority is given to the compact mode the sizes of which are “protected”, whereas the sizes of the header-full mode are penalized by adding zero padding in case of conflict with a size of the compact mode.</li><li id="ul0019-0002" num="0066">The header-full mode</li></ul></li></ul>

0067Examples of RTP payloads in compact format are given in <figref idref="DRAWINGS">FIGS. 4<i>a </i>and 4<i>b </i></figref>for the case of EVS Primary and of EVS AMR-WB IO, respectively; it may in particular be seen that for EVS Primary the payload is merely coded data, there being no payload header and it being impossible to signal an adaptation request (<figref idref="DRAWINGS">FIG. 4<i>a</i></figref>); for EVS AMR-WB IO, data coded in compact mode are reorganized (certain bits are permutated) and a CMR decreased to 3 bits is defined as header (<figref idref="DRAWINGS">FIG. 4<i>b</i></figref>). This particular 3-bit CMR case is not described in detail here because there is no free CMR code in this 3-bit signaling space, and therefore it is impossible to make any request other than a 3-bit change of rate.

0068Examples of RTP payload in header-full format are given in <figref idref="DRAWINGS">FIGS. 4<i>c </i>and 4<i>d</i></figref>. In the first case (FIG. <b>4</b><i>c</i>), a single frame is transported and a ToC header octet (8 bits) is inserted. In the second case (<figref idref="DRAWINGS">FIG. 4<i>d</i></figref>), two frames are transported in the same packet with 2 ToC headers (2 octets) and a CMR field (1 octet) is also used. In comparison with the payload format of the AMR and AMR-WB codecs, it may therefore be seen that the header-full payload format of the EVS codec also implements CMR and ToC concepts but that these fields are defined using octets (8 bits) and therefore, in the header-full mode, naturally octet aligned, the first bit (MSB) being set to 1 for the CMR and to 0 for the ToC.

0069A definition of these fields is given in the specification TS 26.445, Appendix A. For the sake of conciseness, all the details of the specification TS 26. 445, Appendix A will not be repeated here.

0070The 8-bit CMR field is divided into three portions: <ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0000"><ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0071">H (1 bit): always 1</li><li id="ul0021-0002" num="0072">T (3 bits): bits indicating the type of request in order to distinguish between the various NB, WB, SWB and FB Primary EVS modes (which include the VBR and CAM modes) and EVS AMR-WB IO mode.</li><li id="ul0021-0003" num="0073">D (4 bits): CMR request</li></ul></li></ul>

0074The possible values of the CMR field are defined in the specification TS 26.445, Appendix A and define the various modes of the codec. They are recalled in <figref idref="DRAWINGS">FIG. 4<i>g</i></figref>. Certain codes are not used.

0075Similarly, the 8-bit ToC field is divided into 3 portions: <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0000"><ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0076">H (1 bit): always 0</li><li id="ul0023-0002" num="0077">F (1 bit): If F=1, another frame follows the current frame, if F=0, it is a question of the last frame of the packet.</li><li id="ul0023-0003" num="0078">FT (6 bits): bits indicating the frame type, i.e. EVS Primary or EVS AMR-WB IO (including the SID mode). This field is itself divided into 3 portions: EVS mode (1 bit), Unused/Q bit (1 bit) depending on the EVS-mode bit, and EVS rate (4 bits).</li></ul></li></ul>

0079It will be noted that for EVS it is also possible to add bit padding (octets of padding) at the end of the payload. In this case the bit “P” (for Padding) in the RTP header may—optionally—be set to 1 and the additional bits added as specified in RFC 3550; the last octet of this padding contains the number of octets added to the end of the payload (including this last octet).

0080The use of RTCP APP for voice over IMS is detailed in section 10 of the 3GPP specification TS 26.114. The format of an RTCP APP packet is illustrated in <figref idref="DRAWINGS">FIG. 5<i>a</i></figref>. The meaning of the fields of the RTCP header (V, P, PT, length, SSRC/CSRC) is not reviewed here. The “Name” field is by convention set to “3GM7” for “3GPP MTSI Release 7”. The payload portion relates to data added in the “Application dependent data” field. This portion contains a header identification field (ID) followed by data (<figref idref="DRAWINGS">FIG. 5<i>b</i></figref>). A plurality of ID values (on 4 bits) are specified in TS 26.114.

0081Certain ID values apply to all the codecs: <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0000"><ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0082">ID=0 0 0 0: padding (zero padding)</li><li id="ul0025-0002" num="0083">ID=0 0 0 1: redundancy activation request (“RedReq”)—in this case, the data following the ID are on 12 bits, and each bit (i=1 to 12 starting from the end) indicates whether it is necessary to repeat packet N−i (if the bit is set to 1) or not (if the bit is set to 0).</li><li id="ul0025-0003" num="0084">ID=0 0 1 0: aggregation request (“FrameAggReq”)—in this case, the data following the ID are on 4 bits, and only 4 values (among 16 possible values), corresponding to the transmission of 1 to 4 frames per packet, are predefined.</li></ul></li></ul>

0085Other values apply to specific codecs: <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0000"><ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0086">ID=0 0 1 1: CMR request to change mode (coding rate) for AMR and AMR-WB (“AmrCmr”)</li><li id="ul0027-0002" num="0087">ID=0 1 0 0: mode change request for EVS (EVS Primary)</li><li id="ul0027-0003" num="0088">ID=0 1 0 1: coded audio bandwidth change request for NB, WB, SWB or FB EVS (“EvsBandwidthReq”)</li><li id="ul0027-0004" num="0089">ID=0 1 1 0: request to activate the EVS channel-aware mode (CAM) (“EvsParRedReq”)</li><li id="ul0027-0005" num="0090">ID=0 1 1 1: request to switch from EVS Primary to EVS AMR-WB IO (“EvsIoModeReq”)</li><li id="ul0027-0006" num="0091">ID=1 0 0 0: request to switch from EVS AMR-WB IO to EVS Primary (“EvsPrimaryModeReq”)</li></ul></li></ul>

0092It will be noted that it is possible to combine a plurality of RTCP APP requests in the same RTCP APP packet (for example a redundancy activation request and an aggregation request).

0093Thus, the current adaptation requests permitted by the CMR field in RTP packets for AMR, AMR-WB and EVS codecs are insufficient to perform every possible type of adaptation. In particular, the CMR is limited to changes in rate as specified by the receiver, for the AMR and AMR-WB codecs, and changes in rate, coded audio bandwidth and CAM mode control for the EVS codec.

0094The request by the receiver of a form of adaptation other than those permitted by CMR, such as frame aggregation or redundancy, requires the use of RTCP APP in voice-over-IMS applications (as specified in specification TS 26.114). However, to be usable, RTCP APP requires the AVPF profile.

0095Current telephony applications of VoLTE type (VoLTE standing for Voice over LTE (Long Term Evolution), which is a technique for transporting speech over the 4G LTE cell phone networks specified in GSMA IR.92) and of VoWifi type (VoWifi standing for Voice over Wi-Fi, which is a technique for transporting speech over Wi-Fi networks, and which is specified in GSMA IR.65) are based on the minimalist profile of voice over IMS, in which the AVPF profile is not permitted for voice; only the RTP AVP profile is permitted. This implies that RTCP packets of RTCP APP (or RTCP FB) type cannot be used in these applications.

0096When the AVP profile is permitted and depending on rate limitations (SR and RR fields in SDP), the actual uses of RTCP is limited at best to the transmission of “basic” reports of the following types: Sender Report (SR) and/or Receiver Report (RR), the network functionality of which is in particular to transmit keep-alive messages. “Sender-based” adaptation is therefore highly constrained by the fact that the feedback of the receiver in RTP is not regular enough and limited to a few “basic” quality indicators.

0097There is thus a need for a method that allows the receiver to reactively and robustly specify in-band (in an RTP stream) various types of adaptation, for any type of audio or video codec.

0098The present invention aims to improve the situation.

0099To this end, it provides a method for signaling an adaptation request that requests adaptation of the coding/decoding of real-time signals of a real-time communication session, on behalf of a receiving device, to a sending device. The adaptation request is such that it relates to a frame redundancy and/or aggregation request, that it is generated depending on the existence of a signaling parameter obtained in the phase of negotiation of the codecs used that took place during the initialization of the communication session and that it is transported via a real-time protocol of RTP type.

0100Thus, the use of the RTP protocol to request an adaptation makes it possible to obtain a reactive adaptation, contrary to the transmission of RTCP packets, which is not carried out in real-time.

0101The adaptation requests relate to adaptations different from the coding-mode changes of the prior art. This request signaling therefore allows the possibilities of reactive adaptation to be broadened.

0102The various particular embodiments mentioned below may be added independently or in combination to one another, in the steps of the signaling method defined above.

0103In a first embodiment, a field included in a mode-change request of CMR type is used to transport the adaptation request that requests adaptation of the communication session.

0104This type of request transport has the advantage of not increasing the size of the IP packets. It allows CMR values that have not been used in prior-art methods to be used to specify other types of adaptation.

0105In one particular embodiment in which the sending and receiving devices use coders/decoders of AMR or AMR-WB type, CMR codes 9 to 14 are used to code aggregation and redundancy requests that request aggregation and redundancies of various rates.

0106These codes are reserved for future uses and may advantageously define adaptations of aggregation or redundancy type.

0107In one particular embodiment in which the sending and receiving devices use coders/decoders of EVS type, CMR code values with T=“111” and D other than “1111” are used to code the redundancy requests that request redundancies of various rates.

0108These codes are reserved for future uses and may advantageously define adaptations of aggregation or redundancy type.

0109In a second embodiment, a field of the padding request at the end of the signaling of the RTP protocol is used to transport the adaptation request that requests adaptation of the communication session.

0110This type of request transport also has the advantage of allowing both an aggregation and/or redundancy adaptation request and a coding-mode adaptation request be made. The use of a padding field at the end of the signaling then becomes useful to specify another type of adaptation.

0111The present invention also relates to a receiving device that transmits a signaling of an adaptation request that requests adaptation of the coding/decoding of real-time signals of a real-time communication session, to a remote sending device. This device is such that it comprises: <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0000"><ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0112">a module for verifying the existence of a signaling parameter obtained in the phase of negotiation of the codecs used that took place during the initialization of the communication session;</li><li id="ul0029-0002" num="0113">an adapting module able to determine an adaptation request relating to a frame aggregation and/or redundancy request; and</li><li id="ul0029-0003" num="0114">a module for inserting the request into a payload format via a real-time protocol of RTP type.</li></ul></li></ul>

0115This device has the same advantages as the method described above, which it implements.

0116The invention also relates to a communication terminal comprising a receiving device such as described.

0117It relates to a computer program containing code instructions for implementing steps of the signaling method such as described, when these instructions are executed by a processor.

0118Lastly, the invention relates to a processor-readable storage medium (which may or may not be integrated into the receiving device and which may optionally be removable) storing a computer program that implements a signaling method such as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

0119Other features and advantages of the invention will become clearer on reading the following description, which is given merely by way of nonlimiting example, with reference to the appended drawings, in which:

0120<figref idref="DRAWINGS">FIG. 1</figref> illustrates a known prior-art voice-over-IP communication system, which was described above;

0121<figref idref="DRAWINGS">FIGS. 2<i>a </i>to 2<i>d </i></figref>illustrate prior-art examples of IP packet formats in case of frame aggregation or redundancy, such as described above;

0122<figref idref="DRAWINGS">FIGS. 3<i>a </i>to 3<i>d </i></figref>illustrate the payload format for the AMR and AMR-WB codecs;

0123<figref idref="DRAWINGS">FIGS. 4<i>a </i>to 4<i>g </i></figref>illustrate the payload format for the EVS codec;

0124<figref idref="DRAWINGS">FIGS. 5<i>a </i>to 5<i>b </i></figref>illustrate prior-art examples of formats of RTCP APP packets such as described above;

0125<figref idref="DRAWINGS">FIG. 6</figref> illustrates one embodiment of a voice-over-IP communication system and of a signaling method according to the invention;

0126<figref idref="DRAWINGS">FIG. 7</figref> illustrates a more detailed embodiment of a voice-over-IP communication system according to the invention;

0127<figref idref="DRAWINGS">FIG. 8</figref> illustrates a payload format used, according to a first embodiment of the invention, to transport an adaptation request;

0128<figref idref="DRAWINGS">FIG. 9</figref> illustrates a payload format used, according to a second embodiment of the invention, to transport an adaptation request;

0129<figref idref="DRAWINGS">FIG. 10</figref> illustrates a payload format used, according to another embodiment of the invention, to transport an adaptation request; and

0130<figref idref="DRAWINGS">FIG. 11</figref> illustrates a hardware embodiment of a terminal comprising a receiving device that implements the signaling method according to one embodiment.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

0131<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of a system for bidirectional communication between two terminals A and B, implementing a request-signaling method according to one embodiment of the invention. As in <figref idref="DRAWINGS">FIG. 1</figref>, the microphones and loudspeakers (<b>101</b>, <b>151</b>, <b>102</b>, <b>152</b>) have been shown. The acoustic processing operations and the network connecting the two terminals have not been shown in <figref idref="DRAWINGS">FIG. 6</figref>, for the sake of conciseness and clarity.

0132The terminal A comprises a sender <b>601</b> and a receiver <b>603</b> whereas the terminal B comprises a sender <b>651</b> and a receiver <b>653</b>. The two terminals A and B are typically configured, depending on an exchange of one or more offers/one or more answers according to the SDP protocol, via the respective blocks <b>600</b> and <b>650</b>. Typically, this SDP configuration is at least employed during the instantiation (initialization or re-initialization) of the sender and of the receiver; in variants of the invention this configuration may be considered to be internal to the terminal and to allow the SDP offer of the terminal and the answer thereto to be configured. In variants of the invention, other protocols for signaling media capacity/configurations (session descriptions) equivalent to or derived from SDP will possibly be used equivalently.

0133The senders perform the following functions: coding, generation of RTP packets by adding protocol headers and forming a payload corresponding to the coding format and to the transport adaptation (aggregation, redundancy, inter alia) if any is required and transmission of the packets.

0134The receivers perform the following functions: reception of the RTP packets, extraction of the fields of the RTP header, decoding of the payload (which may include the jitter buffer management) decoding of received frames and correction of lost-frame losses.

0135The terminals A and B comprise a request-decoding block (blocks <b>607</b> and <b>657</b>). Various embodiments of the extraction and decoding of these adaptation requests will be described below with reference to <figref idref="DRAWINGS">FIGS. 8 to 10</figref>. The block <b>607</b> or <b>657</b> reads the relevant portion of the packet associated with the codec (AMR, AMR-WB or EVS). It is assumed here that the result of the decoding of the request by the blocks <b>607</b> and <b>657</b> is stored in an “adaptation_info” memory element containing a structure shared with the sending portion (blocks <b>601</b> and <b>651</b>) and that this “adaptation_info” element itself comprises a stored element “adaptation_info.updated” that is equal to 1 when a (CMR, inter alia) request has been received and 0 otherwise. The block <b>601</b> or <b>651</b> verifies, before coding each new frame, whether the “adaptation_info.updated” value is 1 and if this is the case it configures the coding and optionally the transport (redundancy, aggregation) according to the embodiments of the invention, depending on complementary elements (for example “adaption_info.requested_bitrate” with respect to the requested bit rate, or “adaptation_info.red” with respect to the activation or not of redundancy, etc.) obtained from the request received and decoded by the block <b>607</b> or <b>657</b>.

0136The terminals A and B comprise an adaptation block, <b>605</b> and <b>655</b>, respectively, that implements a step of determining an adaptation to be made by the remote sender.

0137The terminals A and B also comprise a request-coding block, <b>606</b> and <b>656</b>, respectively, that implements a step of coding an adaptation to be made by the remote sender. As for the request-decoding block, the result of the coding of the adaptation to be made by the remote sender, which is obtained from blocks <b>605</b> and <b>655</b>, is stored in a memory element called “cmr_request”, which contains a structure shared with the sending portion (blocks <b>601</b> and <b>651</b>).

0138In one embodiment of the invention, the terminals A and B are configured (blocks <b>600</b> and <b>650</b>) depending on the existence or not of an SDP signaling parameter called, in a first embodiment, “adapt_red” (via an SDP signaling read-out block <b>600</b> or <b>650</b>) obtained in the phase of negotiation or configuration of the codecs used that took place during the initialization (or the re-initialization) of the communication session. The name “adapt_red” here makes reference to redundancy (in the sense of application-layer redundancy) but, as will be seen below, other names are possible, and are used in variants, without changing the nature of the invention. The configurations negotiated in the block <b>600</b> and <b>650</b> are stored in memory elements (not shown in the figure) that contain a structure shared between the sender and the receiver of each terminal A and B.

0139The configuration blocks <b>600</b> and <b>650</b> first verify whether the condition required to use an extended request, which is here the existence of an SDP signaling parameter called “adapt_red”, is met.

0140The blocks <b>601</b>, <b>603</b>, <b>605</b>, <b>606</b> and <b>607</b> in terminal A and the blocks <b>651</b>, <b>653</b>, <b>655</b>, <b>656</b> and <b>657</b> in terminal B are considered to have access to a memory element that may be common to the transmission (<b>601</b> and <b>606</b>, for the example of terminal A) and to the reception (<b>603</b>, <b>605</b>, <b>607</b> for the example of terminal A) or indeed separate between transmission and reception. This element is here called “adapt_enabled” and stores whether the SDP signaling parameter “adapt_red” was defined or not during the initialization (blocks <b>600</b> and <b>650</b>, respectively) of the receiver, including blocks <b>603</b>, <b>605</b> and <b>607</b> in terminal A and the blocks <b>653</b>, <b>655</b> and <b>657</b> in terminal B. Here, adapt_enabled=0 if the parameter “adapt_red” is not present and 1 if it is present.

0141As explained above, the presence of the signaling parameter permits a type of extended adaptation request. It will be noted that it is also possible for the signaling parameter to be complemented by one or more complementary parameters, such as for example a “red-offset” parameter that allows the offset to be used in case of 100% redundancy (or the offsets to be used in case of redundancy of 200% or higher) to be indicated. In one embodiment, another memory element called “red_offset” is also accessible to all the blocks of a terminal A or B and allows the interval between the primary frames and the redundant frames to be configured depending on the SDP configuration (blocks <b>600</b> and <b>650</b>).

0142In Appendix 1 an example of a conventional voice-over-IMS SDP offer is given.

0143This first example relates to an SDP offer that allows an audio call to be initiated with one of the following voice codecs: AMR, AMR-WB and EVS. The UDP port, the AVP profile and the payload type (PT) are indicated in media line “m”. The payload type numbers are PT=97, PT=98 or 99, PT=100 or 101 for EVS, AMR-WB and AMR, respectively.

0144The maximum bandwidth of the media specified in the portion “b=AS:” may be modified depending on the requirements and here it corresponds to the maximum bit rate supported by EVS, which is 24.4 kbit/s over Ipv4.

0145The “rtpmap” and “fmtp” portions indicate the parameters of the format of the media. The frequency of the RTP clock for the listed codecs is 16 kHz for EVS and AMR-WB and 8 kHz for AMR. The “mode-change-capability” parameter negotiates the mode-change frequency: it is here set to 2, this indicating a change every 2 frames, in order to ensure maximum interoperability with GSM systems. Regarding the “max-red” parameter, which is 220, the latter allows the maximum interval of 220 ms between the original frame and the redundant frame to be used.

0146In Appendix 2, a second example τs given of an SDP offer according to one embodiment of the invention, in which a global adaptation parameter has been added to all the audio codecs, this parameter indicating the capacity to use an extended CMR field or another type of request (padding or RTP header extension) that will be described below, for the case of redundancy.

0147Specifically, for the remote sender to be able to make the adaptation decoded by the receiver, it is necessary for it to understand the adaptation request that has been transmitted to it. The SDP signaling obtained from the codec negotiation that took place during the initialization of the communication session defines this type of capacity for the codecs of the respective terminals.

0148In the case where a terminal according to the invention has the capacity to conform to an extended CMR with a view to commanding a frame redundancy or aggregation type change or another type of adaptation specific to the application, the SDP signaling comprises a defined parameter “adapt_red” (or one having another name in variants) that indicates that the terminal knows how to use an extended request that is formed, in the main embodiment, by extending the CMR field using the CMR codes “reserved” and/or “not used” in a predefined way.

0149As explained below, according to the invention, the value of the field “b=AS:” will possibly be modified when the SDP parameter “adapt_red” indicating an extended adaptation capacity is present, so that it is possible to use 100% redundancy effectively. Thus, to support a 100% redundancy with EVS with a mode at 13.2 kbit/s and an offset K it will typically be necessary to double the value of “b=AS:” defined for 13.2 kbit/s when a single frame is transported (30 for Ipv4) and to add the number of octets for indicating NO_DATA (i.e. K−1 octets of ToC); therefore, for K=2 b=AS: will be 61.

0150However, in the above example the field “b=AS:” is considered to remain defined with respect to the rate necessary to transport a single frame per packet at the maximum rate permitted by all the listed codecs.

0151In variant embodiments, the SDP parameter “adapt_red” will possibly be in the “fmtp” portion, and therefore specific to each codec.

0152In Appendix 3, a third example τs given of an SDP offer according to one embodiment of the invention, in which a global adaptation parameter has been added to all the audio codecs, this parameter indicating the capacity to use an extended CMR field or another type of request (padding or RTP header extension) that will be described below, for the more general case of redundancy and of aggregation.

0153The signaling parameter is this time called “ext_adapt” and there are two complementary parameters: <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0000"><ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0154">a “red-offset” parameter that specifies two values, the first giving the offset to be used in case of 100% redundancy, the second indicating that it is also possible to signal (and to use) a 200% redundancy with the corresponding offset for the redundant second frame in a packet</li><li id="ul0031-0002" num="0155">an “agg” parameter specifying the type of aggregations permitted, which are given in list format—here the singleton “1” indicates that only one frame may be transported per packet.</li></ul></li></ul>

0156In other variants, other signaling syntaxes may be used: for example τt might be possible to use the signaling parameter as main indicator of the capacity to use extended adaptation requests, and then different additional parameters to activate or not the use of specific requests (redundancy, aggregation inter alia).

0157In variant embodiments, the SDP parameter “adapt_ext” will possibly be in the “fmtp” portion, and therefore specific to each codec.

0158In one embodiment of the invention, the blocks <b>605</b> and <b>655</b> are executed on each reception of a new RTP packet by the blocks <b>603</b> and <b>653</b>, respectively. The receiver delivers at least the following information: <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0000"><ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0159">the reception time of the RTP packets (in ms or according to the RTP clock of the media)</li><li id="ul0033-0002" num="0160">the size of the RTP packets (in octets)</li><li id="ul0033-0003" num="0161">information obtained from the RTP header: <ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0162">the RTP sequence number</li><li id="ul0034-0002" num="0163">the RTP send time or timestamp</li></ul></li></ul></li></ul>

0164From this information, the blocks <b>603</b> and <b>653</b> may estimate the following indicators: <ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0000"><ul id="ul0036" list-style="none"><li id="ul0036-0001" num="0165">Loss rate τ over a predetermined horizon (for example about the last 5 seconds). An example of an embodiment is given in appendix A.3 of RFC 3550 in which the quantity “fraction” is computed for the RTCP SR/RR reports. In variants, other estimating methods will be used.</li><li id="ul0036-0002" num="0166">Available bandwidth β, estimated in kbit/s at the IP level. Various estimating methods exist and the example τs given here of estimation based on a Kalman filter, as described in the article by G. Carlucci et al., “Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)”, Proc. MMSys, May 2016. The estimated bandwidth is here considered to be of the form: β=β₀+β_codec, where β_codecis the bit rate of the codec (coding mode) and β₀=β−β_codecis the portion of the bandwidth used in addition to the coding bit rate (due to the protocol headers and potentially to the use of extended requests).</li></ul></li></ul>

0167Below, two cases have been considered for the AMR and AMR-WB codecs: <ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0000"><ul id="ul0038" list-style="none"><li id="ul0038-0001" num="0168">When adapt_enabled=0, the adaptation of the AMR and AMR-WB codecs is limited to a “basic” operation employing the existing CMR:</li></ul></li></ul>

0169A single frame is transported per packet, the adaptation requests for activating or deactivating the redundancy and aggregation are not available and the adaptation is limited to sending a CMR to change the coding rate (mode) among the list of rates (modes) permitted by the session, depending on the SDP configuration (blocks <b>600</b> and <b>650</b>). This list is denoted {R₀, . . . , R_M-1} where M is the number of permitted modes. For example, for AMR it is recommended to negotiate the M=4 following modes {4.75, 5.9, 7.4, 12.2} and for AMR-WB the M=3 following modes {6.6, 8.85, 12.65} in order to maximize interoperability with 3G systems but it is also possible in AMR-WB to negotiate an open offer/answer with M=9 modes {6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85} because the 3 lowest rates {6.6, 8.85, 12.65} are also present in these 9 modes and a CMR may limit the maximum rate to the highest 12.65 kbit/s for interoperation; however, there are also cases where only N=1 single mode is permitted, for example {12.2} for AMR.

0170If N=1, the blocks <b>603</b> and <b>653</b> generate no adaptation requests via the memory element “cmr_request” (output of the blocks <b>605</b> and <b>655</b>) other than a CMR indicating the rate R₀or indeed a CMR with a code set to (NO_REQ). Below it is assumed that N>1 and an example of an adaptation decision algorithm is given below. In variants of the invention other criteria and other deciding methods will possibly be used without changing the nature of the invention.

0171The coding rate of the preceding frame of index N−1 is denoted R_i, where i denotes the index of one of the elements of {R₀, . . . , R_M-1}, corresponding to the rate of the preceding frame.

0172If the loss rate is too high (for example τ10%) it is assumed that the estimation of available bandwidth is not reliable enough and the criterion β, is not used; in this case, if in addition to the condition of a loss rate that is too high, the last change in rate took place 50 frames (1 second) ago for example, the rate is lowered by precaution, by selecting the rate R_jimmediately below the preceding rate, j being such that j=max(i−1,0) (the operator max(·) here serves to ensure that the rate does not drop below the minimum rate R₀) and this mode decision of the block <b>605</b> or <b>655</b> is converted by the sending portion into a CMR code (block <b>606</b> or <b>656</b>) indicating the rate R_j.

0173When the loss rate is not too high (for example τ&lt;10%) and the last change in rate took place 50 frames (1 second) ago for example, the mode decision of block <b>605</b> or <b>655</b> corresponds to the coding mode R_jimmediately below the available bandwidth i.e. j=arg max_k{k|R_kδβ₀} if β₀R₀and j=0 otherwise.

0174In variants of the invention, the condition of 50 frames will possibly be modified—it here serves to stabilize the decision and prevent too frequent changes.

0175The blocks <b>605</b> and <b>655</b> store in memory the current mode decision via a stored element that is here denoted “cmr_request” which contains an element “cmr_request.updated” and an element “cmr_request.requested_bitrate” and these blocks verify the received packet sizes. If the remote sender has not executed the request of the local receiver (other than NO_REQ)—which is verified by comparing the rate of the codec used (derived from the size of the received packets) with the rate associated with the sent CMR—the last mode decision will be repeated in order to ensure a robust transmission of this decision. If no decision to change the current mode is necessary, the block <b>605</b> or <b>655</b> will indicate that a CMR must be sent using a “cmr_request.updated” element set to 1, “updated=0” otherwise being required. In variants of the invention, the decision will be repeated a predefined number of times (for example 3 times).

0176At the moment that each new frame is coded, the sender <b>601</b> (or <b>651</b>) accesses (in general in parallel with the block <b>605</b> or <b>655</b>, via a “mutex” or “critical section”) the stored element “cmr_request.updated” and if this element is equal to 1, the sender will add a CMR field to the current packet with the corresponding value of “cmr_request.requested_bitrate”. Otherwise, if the element “cmr_request.updated” is equal to 0, the sender will indicate either a CMR of “NO_REQ” type (no request) for AMR, AMR-WB or EVS, or provide no CMR if the EVS codec is configured to not send a CMR when no request is to be sent. <ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0000"><ul id="ul0040" list-style="none"><li id="ul0040-0001" num="0177">When adapt_enabled=1, the adaptation of the AMR and AMR-WB codecs is extended:</li></ul></li></ul>

0178Blocks <b>601</b> and <b>651</b> comprise a buffer (a queue) of coded frames in order not to have to recode the same frame a plurality of times. This buffer of coded frames is here considered to be configured, according to the SDP parameters (block <b>600</b> and <b>650</b>), by computing the maximum number of coded frames to be stored according to the parameters “max-red” and “maxptime”. For example, if max-red=220 and/or maxptime=240, the buffer will possibly be adjusted to store up to 12 coded frames.

0179In addition, blocks <b>603</b> and <b>653</b> read out the ToC field and detect the one or more frames in the current packet, in order to manage the case of redundancy or aggregation. If more than one frame is detected in the current packet, blocks <b>603</b> and <b>653</b> separate them and insert the various coded frames into the reception-end jitter buffer depending on the type of transport, for example: <ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0000"><ul id="ul0042" list-style="none"><li id="ul0042-0001" num="0180">If the current packet contains an aggregation of frames, the frames of the current packet are separated and the frames are inserted depending on the timestamp of the RTP packet and on the time interval separating these frames</li><li id="ul0042-0002" num="0181">If the current packet contains a redundancy, the receiver verifies whether the primary redundant frame corresponding to a given frame has already been received and if this is the case deletes the duplicate, otherwise the frame is inserted into the jitter buffer.</li></ul></li></ul>

0182These two cases may also be combined.

0183Details regarding the adaptation of the jitter buffer and the impact on the algorithm for managing the jitter buffer of the various types of adaptation are not given here. For example, in the case of redundancy or aggregation, it is important for the jitter buffer to take into account the transport configuration used, in order to adjust the audio-signal generation delay with a view to exploiting redundant frames or to adjusting the estimation of the network jitter.

0184An example of an extended adaptation algorithm is given below, firstly in the case of redundancy.

0185The list of modes will once again be {R₀, . . . , R_M-1}, where M is the number of permitted modes.

0186If the loss rate is too high (for example τ≥10%) and the last change in rate took place 50 frames (1 second) ago for example, the adaptation decision consists in activating the 100% redundancy. In one example, the rate 2×R immediately below the current rate will be selected and if no rate 2×R meets this condition the lowest rate 2×R will be selected. In this case, the “cmr_request.updated” element is set to 1 and the additional elements “cmr_request.requested_bitrate” and “cmr_request.red” are set to R and 1, respectively, in order to indicate that a request with 100% redundancy with the rate R must be sent.

0187If the loss rate is not too high (for example τ&lt;10%), the adaptation decision consists in deactivating the redundancy. In this case, the algorithm described above is again used: when the loss rate is not too high (for example τ&lt;10%) and the last change in rate took place 50 frames (1 second) ago for example, the mode decision of block <b>605</b> or <b>655</b> corresponds to the coding mode R_jimmediately below the available bandwidth i.e. j=arg max_k{k|R_kβ₀} if β₀R₀and j=0 otherwise. In this case, the “cmr_request.updated” element is set to 1 and the additional elements “cmr_request.requested_bitrate” and “cmr_request.red” are set to R and 0, respectively, in order to indicate that a conventional CMR request must be sent.

0188The adaptation decision is therefore represented, in one example, by way of a stored element “cmr_request” that comprises a plurality of elements: <ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0000"><ul id="ul0044" list-style="none"><li id="ul0044-0001" num="0189">“cmr_request.updated”: this value is set to 1 if a new decision must be transmitted</li><li id="ul0044-0002" num="0190">“cmr_request.requested_bitrate”: this value indicates the coding rate to be used</li><li id="ul0044-0003" num="0191">in variants of the invention, other criteria and other decision methods will possibly be used without changing the nature of the invention. In particular, in case of aggregation, a stored element for example called “cmr_request.agg” will be defined to indicate that an aggregation request must be sent.</li></ul></li></ul>

0192The adaptation decision (blocks <b>605</b> and <b>655</b>) for the EVS codec is similar to the description given below for the AMR and AMR-WB codecs. However, a plurality of specificities must be taken into account: <ul id="ul0045" list-style="none"><li id="ul0045-0001" num="0000"><ul id="ul0046" list-style="none"><li id="ul0046-0001" num="0193">the EVS codec allows the CAM mode, which is a “robust” mode of 13.2 kbit/s in WB and SWB, to be activated—this mode is normally configured using SDP (see Appendix A of TS 26.445 for the details of the parameter “ch-aw-recv”).</li><li id="ul0046-0002" num="0194">All the (NB, WB, FWB and FB) audio bandwidths are not supported at all rates (see table A.6 of TS 26.445). Thus, to generate a CMR, if the session permits an audio bandwidth range (for example bw=nb-swb), if the current rate is SWB-9.6 kbit/s, and if the adaptation decides to drop to 8 kbit/s, it will be necessary to generate a CMR to indicate the WB-8 kbit/s mode, and therefore the change in rate may involve in the case of the EVS codec a change of coded audio bandwidth, contrary to AMR or AMR-WB.</li></ul></li></ul>

0195In the described embodiment, no adaptation decision to request a CAM mode will be generated by the blocks <b>605</b> and <b>655</b> to simplify the implementation. In variants, it will be possible to activate the CAM mode if for example the loss rate is for example <6% and if the estimated available bandwidth is >13.2 kbit/s, and 100% redundancy will be used only for a loss rate >6%.

0196In examples of embodiments of the invention, the adaptation to be made is of frame-aggregation type, according to various embodiments that will be described below, or indeed of frame-redundancy type, also according to various embodiments described below, or even another type of adaptation specific to the application. The adaptation may comprise both aggregation and redundancy or another specific type of adaptation.

0197These types of adaptation are for example used to modify the packet rate, to correct erroneous received or lost frames, etc. this in general not being possible with an adaptation limited to the modification of the coding rate (except for the EVS codec in which the CAM mode partially allows the problem of frame losses to be addressed, but this mode is specific to WB and SWB EVS at 13.2 kbit/s and is typically less effective than 100% redundancy at high loss rates).

0198The operating principle of the blocks of terminals A and B remain the same: their operation depends on the SDP configuration and on the memory element “adapt_enabled”.

0199An adaptation request corresponding to the adaptation determined in <b>605</b> and <b>655</b> is inserted into the current RTP packet by the respective blocks <b>606</b> and <b>656</b> used to code the request.

0200Various ways in which these adaptation requests may be inserted are described below with reference to <figref idref="DRAWINGS">FIGS. 8 to 10</figref>.

0201The respective blocks <b>607</b> and <b>657</b> for decoding the request allow the request received, in an RTP packet, from a remote receiver, to be extracted and decoded so that the senders can make the requested adaptations. In particular, an example of an embodiment in which the sender accesses stored elements “adaptation_info” and “cmr_request” and optionally additional stored elements is considered here.

0202Thus, <figref idref="DRAWINGS">FIG. 6</figref> illustrates the steps implemented during the signaling method, namely, a step (<b>600</b>, <b>650</b>) of verifying the existence of a signaling parameter obtained in the phase of negotiation or configuration of the codecs used that took place during the initialization of the communication session, a step (<b>605</b>, <b>655</b>) of determining an adaptation request relating to a frame aggregation and/or redundancy request and a step (<b>606</b>, <b>656</b>) of inserting the request into a payload format via a real-time protocol of RTP type. In variants of the invention, other ways of exchanging information other than shared structures (taking the form of stored elements) such as “cmr_request”, “adaptation_info” or “adapt_enabled” will possibly be used.

0203<figref idref="DRAWINGS">FIG. 7</figref> illustrates an embodiment that is more detailed than that of <figref idref="DRAWINGS">FIG. 6</figref> described above. In this embodiment, the sender blocks of <figref idref="DRAWINGS">FIG. 6</figref> are divided into coding blocks (<b>701</b> and <b>751</b>) and sending blocks (<b>702</b> and <b>752</b>) that implement the generation and transmission of RTP packets. The receiver blocks of <figref idref="DRAWINGS">FIG. 6</figref> are divided into decoding blocks (<b>704</b> and <b>754</b>) that may manage the jitter-buffer, decode the received frames and correct for lost-frame and reception losses (<b>703</b> and <b>753</b>). In a VoIP application, the blocks <b>701</b> and <b>702</b> (or <b>751</b> and <b>752</b>) are executed in parallel in multi-thread with the portion related to coding (<b>701</b> or <b>751</b>), which depends on events related to the input soundcard (connected to the block <b>701</b>), and with the portion that transmits to the network (block <b>702</b> or <b>752</b>), which depends on network events; in the same way, in the receiving portion, the packets (<b>703</b> and <b>753</b>) may be received in parallel to the audio generation (<b>704</b> and <b>754</b>).

0204The blocks <b>705</b> and <b>755</b> for determining the adaptation to be made have the same functions as those described for blocks <b>605</b> and <b>655</b> with reference to <figref idref="DRAWINGS">FIG. 6</figref>.

0205<figref idref="DRAWINGS">FIG. 7</figref> shows that it is possible to distribute the functions that create the payload format between the coding blocks (<b>701</b>, <b>751</b>) and the sending blocks (<b>702</b>, <b>752</b>) depending on which one of these blocks forms the payload. The invention applies to both cases.

0206The requests for these adaptations thus determined are coded using blocks <b>706</b> and <b>756</b> and inserted into an RTP packet either by the coding module <b>701</b> or <b>751</b> or by the sender <b>702</b> or <b>752</b> that implements the encapsulation into packets.

0207The blocks <b>707</b> and <b>757</b> have the same functions as the blocks <b>607</b> and <b>657</b> described with reference to <figref idref="DRAWINGS">FIG. 6</figref>. Depending on the method employed to transport the adaptation request, the decoded request will be sent either to the coding block or to the sending block of the sending portion.

0208With reference to <figref idref="DRAWINGS">FIG. 8</figref>, the way in which the CMR codes such as defined below are used will now be described.

0209In a first embodiment, the adaptation request determined by the receiver of a terminal is coded in a field of a mode-change request of CMR type in order to be transported to the sender of the remote terminal.

0210In this embodiment, the signaling of the negotiation between the codecs of the terminals that takes place on initialization of the communication session defines an adaptation parameter “adapt_red” or “adapt_ext” or another name identifying a capacity to use an extended request as seen above, allowing a CMR field that is comprehensible both to the receiver and to the sender of the remote terminals to be employed.

0211When this parameter is defined, a CMR code field is defined to specify the desired type of adaptation.

0212For the AMR, AMR-WB and EVS codecs such as described above, codes that are reserved for future use or that are unused are employed, according to the invention, to make extended mode-change requests. These codes are limited to a few values for the aforementioned codecs.

0213Two cases of operation are distinguished between: <ul id="ul0047" list-style="none"><li id="ul0047-0001" num="0000"><ul id="ul0048" list-style="none"><li id="ul0048-0001" num="0214">When adapt_enabled=1, CMR codes defined as “reserved”, “not used” or “for future use” are used to make an extended request.</li><li id="ul0048-0002" num="0215">When adapt_enabled=0, only the CMR codes defined in RFC 4867 for AMR and AMR-WB and TS 26.445 Appendix A for EVS are used. Reception-end (blocks <b>607</b> and <b>657</b>) if CMR codes defined as “reserved”, “not used” or “for future use” are received, they are ignored.</li></ul></li></ul>

0216The coding format of these requests included in “reserved” or unused CMR fields is described here, for one embodiment.

0217For the AMR and AMR-WB codecs, the CMR values between 8 and 14 (inclusively) and between 9 and 14 (inclusively) are reserved for future use. They are therefore conditionally used when a signaling parameter according to the invention is defined during the codec negotiation and their use is dedicated to signaling redundancy, aggregation or other types of request.

0218Likewise, for the EVS codec, as described with reference to <figref idref="DRAWINGS">FIG. 4<i>g</i></figref>, the values with T=“111” and D other than “1111” are marked as reserved, this leaving 15 possible values.

0219In one variant embodiment, values marked as not used may also be used, this then considerably increasing the number of possible free codes; this is however applicable only to the EVS codec.

0220For a redundancy adaptation (mainly used to replace missing frames) 100% redundancy consists in repeating a past frame (with the offset K) in the current packet P. When the frame losses are random (uniform law with independent and identically distributed or i.i.d. values), this 100% redundancy allows a loss rate of 10% to be converted into a loss rate of 1%.

0221For cellular networks of LTE type in which QOS management mechanisms are already in place and negotiated when making a telephone call, this 100% redundancy level is, in a first example of an embodiment, considered to be sufficient and it is considered not necessary to consider cases of higher redundancy (e.g. 200 or 300%).

0222In the example described here, it is considered to be unnecessary to combine both frame aggregation and redundancy.

0223Here, a constrained version of the signaling of the frame aggregation or redundancy request is developed.

0224The possible cases of redundancy for the AMR, AMR-WB and EVS codecs are described here for a maximum rate associated with the payload format of about 12.2 kbit/s for AMR, 12.65 or 23.85 kbit/s for AMR-WB and 13.2 or 24.4 kbit/s for EVS, respectively.

0225Table 1 below shows, for an AMR codec with a rate of about 12.2 kbit/s, that the redundancy is limited to 3 possible redundancy cases, denoted “2×R” where R is the repeated rate. It will be noted here that the offset is not specified and in practice the rate associated with the payload format will be higher than twice R if ToC information of NO_DATA type must be inserted to indicate the offset in the payload.

0226It will be noted that when redundancy is activated, if the current rate of packet P is a rate of 12.2 kbit/s and if a redundancy of 2×5.9 kbit/s is switched to starting from the following packet P+1, the first packet (of index P+1) normally contains the current frame with a rate at 5.9 kbit/s and the preceding frame at a rate of 12.2 kbit/s. It is only in the following packet (of index P+2) that there will be 2 frames at 5.9 kbit/s. For the first packet, the rate is then higher than the maximum permitted rate. If the value of “b=AS:” of the SDP parameter allows it, this method is used for the first transition packet otherwise, if this value does not permit the overload, to prevent a temporary overload (12.2+5.9), the packet P+1 will contain only the frame coded at 5.9 kbit/s.

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="28pt" align="center" /><colspec colname="2" colwidth="154pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 1</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry /><entry>100% redundancy possible</entry></row><row><entry /><entry>AMR</entry><entry>(&lt;12.2)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="28pt" align="char" char="." /><colspec colname="2" colwidth="154pt" align="center" /><tbody valign="top"><row><entry /><entry>4.75</entry><entry>x</entry></row><row><entry /><entry>5.15</entry><entry>x</entry></row><row><entry /><entry>5.9</entry><entry>x</entry></row><row><entry /><entry>6.7</entry><entry>(x)</entry></row><row><entry /><entry>7.4</entry><entry>(x)</entry></row><row><entry /><entry>7.95</entry></row><row><entry /><entry>10.2</entry></row><row><entry /><entry>12.2</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0227It is possible to envision allowing 2×6.7 and 2×7.4 redundancy depending on the value of “b=AS:”.

0228Likewise, in the case of a frame aggregation adaptation, for the same maximum rate limitation, for the AMR codec, the same cases as those shown in table 1 above are found to be usable.

0229It is therefore possible to define the following CMR codes (table 2) for the AMR codec with “RED” for redundancy:

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="126pt" align="center" /><colspec colname="2" colwidth="91pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CMR Code</entry><entry>AMR request</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="126pt" align="char" char="." /><colspec colname="2" colwidth="91pt" align="left" /><tbody valign="top"><row><entry>9</entry><entry>RED 2 × 4.75</entry></row><row><entry>10</entry><entry>RED 2 × 5.15</entry></row><row><entry>11</entry><entry>RED 2 × 5.9</entry></row><row><entry>12</entry><entry>RED 2 × 6.7</entry></row><row><entry>13</entry><entry>RED 2 × 7.4</entry></row><row><entry>14</entry><entry>Reserved</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0230In variants, in particular when no complementary SDP parameter allows the redundancy offset to be specified, it will be possible to use the CMR codes specified in table 2a for AMR. This allows both the redundancy rate and the offset to be used (here 1 or 3) to be specified. The rates of 5.15 and 6.7 in this example will also be noted.

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="center" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 2a</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CMR Code</entry><entry>AMR request</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="char" char="." /><colspec colname="2" colwidth="105pt" align="left" /><tbody valign="top"><row><entry>9</entry><entry>RED 2 × 4.75, offset 1</entry></row><row><entry>10</entry><entry>RED 2 × 5.9, offset 1</entry></row><row><entry>11</entry><entry>RED 2 × 7.4, offset 1</entry></row><row><entry>12</entry><entry>RED 2 × 4.75, offset 3</entry></row><row><entry>13</entry><entry>RED 2 × 5.9, offset 3</entry></row><row><entry>14</entry><entry>RED 2 × 7.4, offset 3</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0231In other variants, it will also be possible to combine redundancy and aggregation with two frames per packet as shown in the table 2b, with “Agg” for aggregation.

0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="126pt" align="center" /><colspec colname="2" colwidth="91pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 2b</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CMR code</entry><entry>AMR request</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="126pt" align="char" char="." /><colspec colname="2" colwidth="91pt" align="left" /><tbody valign="top"><row><entry>9</entry><entry>RED 2 × 4.75</entry></row><row><entry>10</entry><entry>RED 2 × 5.15</entry></row><row><entry>11</entry><entry>RED 2 × 5.9</entry></row><row><entry>12</entry><entry>Agg 2 × 4.75</entry></row><row><entry>13</entry><entry>Agg 2 × 5.15</entry></row><row><entry>14</entry><entry>Agg 2 × 5.9</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0232It will be recalled here that the CMR codes are listed here in order to allow a “generic” request independent of the permitted rates (SDP parameter “mode-set” for AMR). Of course, the blocks <b>605</b> and <b>606</b> (and <b>655</b> and <b>656</b>) are constrained by the rates negotiated for the session, and therefore certain codes may not be used.

0233It is here assumed that the offset for the redundancy is specified during the SDP negotiation with a parameter that may be named “red-offset” and that will typically be associated with the SDP parameter allowing the CMR code to be used to be identified. If this “red-offset” parameter is not available, a request-signaling solution such as for example given in table 2a will possibly be used.

0234Thus, if adapt_enabled=1, the blocks <b>605</b> and <b>655</b> (or <b>705</b> and <b>755</b>) will verify the value of “cmr_request.updated” and if this value is set to 1, these blocks will convert the complementary data stored in “cmr_request”. In particular, for the case of table 2, if cmr_request.red=1, the element “cmr_request.requested_bitrate” will be used to find the CMR code from 9 to 13. If cmr_request.red=0, the element “cmr_request.requested_bitrate” will be used to find the CMR code from 0 to 7 that corresponds to the rate.

0235It is assumed here that the constraints imposed by the SDP parameters (b=AS, maxptime, max-red, etc.) have already been taken into account by the decision blocks <b>605</b> and <b>655</b>.

0236In table 3 below, the same approach is now illustrated for the codec AMR-WB with provision made for the two maximum rates.

0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="91pt" align="center" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 3</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>100%</entry><entry>100%</entry></row><row><entry /><entry>redundancy</entry><entry>redundancy</entry></row><row><entry /><entry>possible</entry><entry>possible</entry></row><row><entry>AMR-WB</entry><entry>(&lt;12.65)</entry><entry>(&lt;23.85)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84pt" align="char" char="." /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="91pt" align="center" /><tbody valign="top"><row><entry>6.6</entry><entry>x</entry><entry>x</entry></row><row><entry>8.85</entry><entry /><entry>x</entry></row><row><entry>12.65</entry><entry /><entry>(x)</entry></row><row><entry>14.25</entry></row><row><entry>15.85</entry></row><row><entry>18.25</entry></row><row><entry>19.85</entry></row><row><entry>23.05</entry></row><row><entry>23.85</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0237Depending on whether the maximum rate of the codec is 12.65 kbit/s or 23.85 kbit/s and depending on the value of “b=AS:” and the rates permitted in the session (see the parameter “mode-set”), it may be seen that 100% redundancy allows only one case (2×6.6) for the rate 12.65 kbit/s or three cases for the rate 23.85 kbit/s.

0238It will be noted that the 3rd case of 100% redundancy for 12.65 kbit/s exceeds a little the nominal rate of 23.85 kbit/s and, in this case, it is necessary to ensure that the service is suitably dimensioned for a rate slightly higher than the “normal” rate of the AMR-WB codec, this typically being achieved by modifying the value of “b=AS” in the signaling of the SDP negotiation to a higher value.

0239It is therefore possible to define the following CMR codes (table 4) for the AMR-WB codec:

0000<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119pt" align="center" /><colspec colname="2" colwidth="98pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 4</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CMR code</entry><entry>AMR-WB request</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119pt" align="char" char="." /><colspec colname="2" colwidth="98pt" align="left" /><tbody valign="top"><row><entry>9</entry><entry>RED 2 × 6.6</entry></row><row><entry>10</entry><entry>RED 2 × 8.85</entry></row><row><entry>11</entry><entry>RED 2 × 12.65</entry></row><row><entry>12</entry><entry>Agg 2 × 6.6</entry></row><row><entry>13</entry><entry>Agg 2 × 8.85</entry></row><row><entry>14</entry><entry>Agg 2 × 12.65</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0240In variants, the space in which extended requests are signaled will possibly be restricted to redundancy and various offsets, for example as shown in table 4a.

0000<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="center" /><colspec colname="2" colwidth="119pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 4a</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CMR code</entry><entry>AMR-WB request</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="char" char="." /><colspec colname="2" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>9</entry><entry>RED 2 × 6.6, offset = 1</entry></row><row><entry>10</entry><entry>RED 2 × 8.85, offset = 1</entry></row><row><entry>11</entry><entry>RED 2 × 12.65, offset = 1</entry></row><row><entry>12</entry><entry>RED 2 × 6.6, offset = 3</entry></row><row><entry>13</entry><entry>RED 2 × 8.85, offset = 3</entry></row><row><entry>14</entry><entry>RED 2 × 12.65, offset = 3</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0241In variants of the invention, the order of these values will possibly be modified and certain values will possibly be deleted in all the tables. It will also be possible to define additional variants for example integrating 200% redundancy or options for the value of the redundancy offset.

0242Once again, if adapt_enabled=1, the blocks <b>605</b> and <b>655</b> (or <b>705</b> and <b>755</b>) will verify the value of “cmr_request.updated” and if this value is set to 1, these blocks will convert the complementary data stored in “cmr_request”. In particular, for the case of table 4, if cmr_request.red=1, the element “cmr_request.requested_bitrate” will be used to find the CMR code from 9 to 11. If cmr_request.red=0, the element “cmr_request.requested_bitrate” will be used to find the CMR code from 0 to 8 that corresponds to the rate.

0243It is assumed here that the constraints imposed by the SDP parameters (b=AS, maxptime, max-red, etc.) have already been taken into account by the decision blocks <b>605</b> and <b>655</b>.

0244The same approach may be used for the EVS codec. However, unlike the AMR and AMR-WB codecs, the EVS codec comprises a plurality of operating modes: EVS-NB, EVS-WB, EVS-SWB, EVS-FB and EVS AMR-WB IO, and specific modes such as VBR or CAM.

0245The case for EVS AMR-WB IO is considered here to be derivable from the AMR-WB case discussed above. For the “EVS Primary” portion, setting aside the coded audio bandwidth, it is possible to define the following table (table 5):

0000<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="49pt" align="center" /><colspec colname="3" colwidth="49pt" align="center" /><colspec colname="4" colwidth="42pt" align="center" /><colspec colname="5" colwidth="42pt" align="center" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 5</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry /><entry>A1</entry><entry>A2</entry><entry>B1</entry><entry>B2</entry></row><row><entry /><entry>100%</entry><entry>100%</entry><entry>100%</entry><entry>100%</entry></row><row><entry /><entry>redundancy</entry><entry>redundancy</entry><entry>redundancy</entry><entry>redundancy</entry></row><row><entry /><entry>possible</entry><entry>possible</entry><entry>possible</entry><entry>possible</entry></row><row><entry /><entry>(&lt;13.2)</entry><entry>(&lt;24.4)</entry><entry>(C13.2)</entry><entry>(&lt;24.4)</entry></row><row><entry>EVS</entry><entry>bw = nb − swb</entry><entry>bw = nb − swb</entry><entry>bw = swb</entry><entry>bw = swb</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>5.9-VBR</entry><entry>x</entry><entry>[x]</entry><entry /><entry /></row><row><entry>7.2</entry><entry>(x)</entry><entry>x</entry></row><row><entry>8</entry><entry /><entry>x</entry></row><row><entry>9.6</entry><entry /><entry>x</entry><entry>(x)</entry><entry>x</entry></row><row><entry>13.2</entry><entry /><entry>(x)</entry><entry /><entry>(x)</entry></row><row><entry>16.4</entry></row><row><entry>24.4</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0246This table is here based on the GSMA specification IR.92 V11.0 (15 Jun. 2017) in which 5 configurations (profiles) are defined for EVS. Only the four configurations (A1, A2, B1, B2) that allow an adaptation space of redundancy or aggregation type to be obtained are considered here.

0247It will be noted that the use of redundancy or aggregation in the VBR mode is debatable and potentially complicates the implementation of the encapsulation into packets. For this reason, the VBR mode is indicated here with the notation “[x]” in table 5. Here consideration will be restricted to fixed rates. However, in variants it will also be possible to include the VBR mode in CMR codes according to the invention.

0248The number of CMR codes reserved for the EVS codecs is 15.

0249For the AMR-WB codecs, it has been seen that there are 6 cases. For the EVS codec, adaptation may be limited to the NB, WB and SWB modes because the FB mode starts only at 16.4 kbit/s. It is therefore possible to define the following CMR codes (table 6) for the EVS codec:

0000<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="center" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 6</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CMR code</entry><entry>EVS request</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>111 0000</entry><entry>RED 2 × 7.2-NB</entry></row><row><entry>111 0001</entry><entry>RED 2 × 8-NB</entry></row><row><entry>111 0010</entry><entry>RED 2 × 9.6-NB</entry></row><row><entry>111 0011</entry><entry>RED 2 × 13.2-NB</entry></row><row><entry>111 0100</entry><entry>RED 2 × 7.2-WB</entry></row><row><entry>111 0101</entry><entry>RED 2 × 8-WB</entry></row><row><entry>111 0110</entry><entry>RED 2 × 9.6-WB</entry></row><row><entry>111 0111</entry><entry>RED 2 × 13.2-WB</entry></row><row><entry>111 1000</entry><entry>RED 2 × 7.2-SWB</entry></row><row><entry>111 1001</entry><entry>RED 2 × 8-SWB</entry></row><row><entry>111 1010</entry><entry>RED 2 × 9.6-SWB</entry></row><row><entry>111 1011</entry><entry>RED 2 × 13.2-SWB</entry></row><row><entry>111 1100</entry><entry>RED 2 × 6.6</entry></row><row><entry>111 1101</entry><entry>RED 2 × 8.85</entry></row><row><entry>111 1110</entry><entry>RED 2 × 12.65</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0250It may be seen that this table does not comprise code values for an aggregation adaptation. Details are not given here of the values chosen among the “Not used” values to make the extended requests, for the sake of conciseness. However, the examples given for the AMR and AMR-WB codecs may be extended to the EVS codec.

0251In one possible embodiment, it is possible, in this case, to use the “Not used” CMR values to define aggregation modes.

0252In variants of the invention, the order of these values will possibly be modified and certain values will possibly be deleted or replaced. In particular, in variants of the invention, for the AMR, AMR-WB and EVS codecs, a CMR code will possibly be reserved for signaling types of adaptation other than redundancy and aggregation.

0253In other variants of the invention, aggregation will not be used and instead CMR codes will possibly be reserved for the (limited) cases of 200% redundancy (this approximately tripling the bit rate): AMR at 4.75 kbit/s, AMR-WB at 6.6 kbit/s, EVS from 7.2 to 8 kbit/s for Primary (for NB and WB bandwidths), at 9.6 kbit/s for Primary (NB, WB and SWB bandwidths) and at 6.6 kbit/s for EVS AMR-WB IO.

0254In the case of the AMR and AMR-WB codecs, the CMR field is always present, and for EVS it is also always present in the case of EVS AMR-WB IO (on 3 bits in compact mode and one octet in header-full mode); however in EVS Primary modes, whether or not it is present depends on the SDP parameter called “cmr” (see Appendix A of TS 26. 445 for the associated details).

0255The CMR field is a header of the payload data of the RTP payload format for the AMR, AMR-WB and EVS codecs; the existing field for these codecs remains the same, as indicated in <figref idref="DRAWINGS">FIG. 8</figref>. However, this field is designated “ext.CMR” or “extended CMR” in the sense that the values currently defined as reserved for future use (“for future use”, “reserved”) and optionally unused values (“not used”) are now used as defined above to indicate an adaptation request, providing that a signaling parameter activates this feature.

0256The adaptation request, which takes the form of new CMR codes, is therefore inserted into RTP packets defined by an RTP header (see <figref idref="DRAWINGS">FIG. 8</figref>). This header comprises the following fields: <ul id="ul0049" list-style="none"><li id="ul0049-0001" num="0000"><ul id="ul0050" list-style="none"><li id="ul0050-0001" num="0257">V for version, which identifies the RTP version</li><li id="ul0050-0002" num="0258">P for padding—if it is set to 1, the packet contains padding octets at the end of the packet in addition to the payload</li><li id="ul0050-0003" num="0259">X for extension—if it is set to 1, the existing header is followed by an extension</li><li id="ul0050-0004" num="0260">CC, for “CSRC count”, indicates the number of CSRC identifiers</li><li id="ul0050-0005" num="0261">M, for “marker”, indicates whether the current data are particularly relevant to the application</li><li id="ul0050-0006" num="0262">PT, for “payload type”, indicates the format of the payload</li><li id="ul0050-0007" num="0263">“Sequence number” is incremented by 1 for each RTP packet sent and allows the receiver to detect losses and to repair the sequences of packets</li><li id="ul0050-0008" num="0264">“Timestamp” to specify the send time of each packet and to allow the receiver to read the received samples at suitable intervals</li><li id="ul0050-0009" num="0265">SSRC, for “Synchronization source”, which identifies each source of the same stream differently</li><li id="ul0050-0010" num="0266">CSRC, for “Contributing sources”, which indicates the sources that contribute to the payload of the packet.</li></ul></li></ul>

0267It will be noted that it is possible to add one or more signaling parameters to, for example, parameterize the offset in the case of 100% redundancy.

0268This embodiment of the invention has the advantage of not increasing the size of the IP packets and of not modifying the RTP header of the packets.

0269Thus, it is always possible to perform an RTP header compression in certain cases of use, without this having an impact on the adaptation requests. This solution however has the drawback of generating only a limited signaling space and is applicable only to coders that define the CMR concept and for which a number of free codes is sufficient.

0270In a second embodiment, which is illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, the adaptation request determined by the receiver of a terminal is coded into a field of the padding request at the end of the signaling of the protocol to be transported to the sender of the remote terminal.

0271In this embodiment, the negotiation signaling between the codecs of the terminals that takes place on initialization of the communication session defines, as seen above, an adaptation parameter “adapt_red” or “adapt_ext” allowing this padding field to be used and that is comprehensible both to the receiver and to the sender of the remote terminals.

0272When this parameter is defined, a padding field is defined to specify the desired type of adaptation.

0273A one-octet padding field (PAD.Req) is used, a one-octet extended CMR code such as defined above being inserted therein.

0274Padding is typically inserted at the end of the payload, and to avoid decreasing the effectiveness of the header compression, the bit “P” of the RTP header will not be set to 1. In contrast, padding will be inserted with the request followed by an additional octet indicating the number of padding octets according to RFC 3550. This approach allows potential impacts on existing terminals to be avoided.

0275In variants, the padding bits (before the last added octet indicating the number of padding octets) will use the same syntax as in the request-coding format of RTCP APP according to TS 26.114 (section 10), with in particular a prefix on 4 “ID” bits.

0276In variants, for the EVS codec, the padding normally set by default to zero in header-full mode during “packet encapsulation” will be replaced by the padding according to the invention. This has the advantage of minimizing the number of additional octets.

0277For the AMR and AMR-WB codecs, the existing prior-art 4-bit CMR illustrated in <figref idref="DRAWINGS">FIG. 3<i>c </i></figref>will still be used but the new “CMR codes” such as defined in the first embodiment will be inserted on 4 bits in the LSB, at the end of the bit stream as illustrated in <figref idref="DRAWINGS">FIG. 9</figref>; the 4 other bits in the MSB will be set to zero. In variants, the LSB and MSB will be inverted.

0278The RTP header shown in <figref idref="DRAWINGS">FIG. 9</figref> contains the following fields: <ul id="ul0051" list-style="none"><li id="ul0051-0001" num="0000"><ul id="ul0052" list-style="none"><li id="ul0052-0001" num="0279">V for version, which identifies the RTP version</li><li id="ul0052-0002" num="0280">P for padding—if it is set to 1, the packet contains padding octets at the end of the packet in addition to the payload. According to the invention, it is preferable not to set the padding bit to 1 in order not to decrease the effectiveness of the header compression. In variants, this bit will be set to 1 as in the variant embodiment corresponding to <figref idref="DRAWINGS">FIG. 10</figref>.</li><li id="ul0052-0003" num="0281">X for extension—if it is set to 1, the existing header is followed by an extension</li><li id="ul0052-0004" num="0282">CC, for “CSRC count”, indicates the number of CSRC identifiers</li><li id="ul0052-0005" num="0283">M, for “marker”, indicates whether the current data are particularly relevant to the application</li><li id="ul0052-0006" num="0284">PT, for “payload type”, indicates the format of the payload</li><li id="ul0052-0007" num="0285">“Sequence number” is incremented by 1 for each RTP packet sent and allows the receiver to detect losses and to repair the sequences of packets</li><li id="ul0052-0008" num="0286">“Timestamp” to specify the send time of each packet and to allow the receiver to read the received samples at suitable intervals</li><li id="ul0052-0009" num="0287">SSRC, for “Synchronization source”, which identifies each source of the same stream differently</li><li id="ul0052-0010" num="0288">CSRC, for “Contributing sources”, which indicates the sources that contribute to the payload of the packet.</li></ul></li></ul>

0289The payload data therefore comprise the conventional CMR field, the ToC field such as defined above, the speech data and the adaptation request such as defined.

0290For the EVS codec, the padding field is used in the same way at the end of the bit stream to insert the CMR code such as defined in the first embodiment.

0291However, in this case, the CMR for the AMR and AMR-WB codecs will have to be set to “NO_REQ” and the signaling parameter will allow it to be understood that the padding field with the one-octet “extended CMR” is to be taken into consideration.

0292This embodiment has the advantage of being able to specify both a conventional change of mode, via an in existing CMR code, and a different adaptation request, via use of a new code in a different location in the payload format.

0293This solution also has the advantage of not modifying the RTP header of the packets.

0294Thus, it is still possible to perform an RTP header compression in certain cases of use, without this having an impact on the adaptation requests.

0295The operation of the various blocks of <figref idref="DRAWINGS">FIGS. 6 and 7</figref> is unchanged, with the exception that the extended request is transported in a padding field.

0296In one possible embodiment, the adaptation request such as defined by the new CMR codes will possibly be inserted in the header of the RTP payload format as illustrated in <figref idref="DRAWINGS">FIG. 10</figref>. However, this method has the drawback, on the one hand, of increasing the size of the RTP packets and, on the other hand, of decreasing the effectiveness of existing header-compression methods because the extension bit (X) of the RTP header must be set to 1.

0297The operation of the various blocks of <figref idref="DRAWINGS">FIGS. 6 and 7</figref> is unchanged, with the exception that the extended request is transported in a padding field. The header extension is here assumed to be signaled according to RFC 5285 with the “extmap” field. In variants, other extension methods will be used.

0298<figref idref="DRAWINGS">FIG. 11</figref> now illustrates an example of a hardware embodiment of a communication terminal comprising a receiving device able to implement the signaling method according to the invention, in particular using at least one signaling or configuration parameter of SDP type.

0299The terminal TA comprises a storage space <b>11</b>, for example a memory MEM, a processing unit <b>10</b> comprising a processor P, which is controlled by a computer program PG, which is stored in the memory <b>11</b> and which implements the signaling method according to the invention.

0300On initialization, the code instructions of the program PG are for example loaded into a RAM (not shown) before being executed by the processor P of the processing unit <b>10</b>. The program instructions may be stored on a storage medium such as a flash memory, a hard disk or any other non-volatile storage medium.

0301The processor implements the signaling method such as described with reference to <figref idref="DRAWINGS">FIG. 6</figref>, according to the instructions of the program PG.

0302The terminal TA comprises a communication module <b>12</b> able to receive and transmit real-time data from and to a communication network and able to read signaling or configuration data of SDP type <b>13</b> either via the signaling sent in the network or from the memory <b>11</b> of the terminal. L

0303The terminal comprises a receiving device including a module for verifying the existence of a signaling parameter obtained in the phase of negotiation of the codecs used that took place during the initialization of the communication session, an adapting module able to determine an adaptation request relating to a frame aggregation and/or redundancy request, and a module for inserting the request into a payload format via a real-time protocol of RTP type. These modules are such as described with reference to <figref idref="DRAWINGS">FIG. 6</figref> or to <figref idref="DRAWINGS">FIG. 7</figref>.

0304The term module can correspond either to a software component or to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally to any element of a program able to implement a function or a set of functions such as described for the modules in question. In the same way, a hardware component corresponds to any element of a hardware assembly able to implement a function or a set of functions for the module in question (integrated circuit, chip card, memory card, etc.).

0305The terminal is for example a telephone, a smart phone, a tablet, a computer, a residential gateway or a connected thing.

0000<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX 1</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Conventional SDP offer</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>m=audio 49152 RTP/AVP 97 98 99 100 101</entry></row><row><entry /><entry>b=AS:42</entry></row><row><entry /><entry>b=RS:0</entry></row><row><entry /><entry>b=RR:2000</entry></row><row><entry /><entry>a=rtpmap:97 EVS/16000/1</entry></row><row><entry /><entry>a=fmtp:97 br=9.6-24.4; bw=swb; max-red=220</entry></row><row><entry /><entry>a=rtpmap:98 AMR-WB/16000/1</entry></row><row><entry /><entry>a=fmtp:98 mode-change-capability=2; max-red=220</entry></row><row><entry /><entry>a=rtpmap:99 AMR-WB/16000/1</entry></row><row><entry /><entry>a=fmtp:99 mode-change-capability=2; max-red=220; octet-</entry></row><row><entry /><entry>align=1</entry></row><row><entry /><entry>a=rtpmap:100 AMR/8000/1</entry></row><row><entry /><entry>a=fmtp:100 mode-change-capability=2; max-red=220</entry></row><row><entry /><entry>a=rtpmap:101 AMR/8000/1</entry></row><row><entry /><entry>a=fmtp:101 mode-change-capability=2; max-red=220; octet-</entry></row><row><entry /><entry>align=1</entry></row><row><entry /><entry>a=ptime:20</entry></row><row><entry /><entry>a=maxptime:240</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX 2</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SDP offer with an adaptation parameter</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>m=audio 49152 RTP/AVP 97 98 99 100 101</entry></row><row><entry /><entry>a=adapt_red: red-offset=2</entry></row><row><entry /><entry>b=AS:42</entry></row><row><entry /><entry>b=RS:0</entry></row><row><entry /><entry>b=RR:2000</entry></row><row><entry /><entry>a=rtpmap:97 EVS/16000/1</entry></row><row><entry /><entry>a=fmtp:97 br=9.6-24.4; bw=swb; max-red=220</entry></row><row><entry /><entry>a=rtpmap:98 AMR-WB/16000/1</entry></row><row><entry /><entry>a=fmtp:98 mode-change-capability=2; max-red=220</entry></row><row><entry /><entry>a=rtpmap:99 AMR-WB/16000/1</entry></row><row><entry /><entry>a=fmtp:99 mode-change-capability=2; max-red=220; octet-</entry></row><row><entry /><entry>align=1</entry></row><row><entry /><entry>a=rtpmap:100 AMR/8000/1</entry></row><row><entry /><entry>a=fmtp:100 mode-change-capability=2; max-red=220</entry></row><row><entry /><entry>a=rtpmap:101 AMR/8000/1</entry></row><row><entry /><entry>a=fmtp:101 mode-change-capability=2; max-red=220; octet-</entry></row><row><entry /><entry>align=1</entry></row><row><entry /><entry>a=ptime:20</entry></row><row><entry /><entry>a=maxptime:240</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX 3</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SDP offer with an adaptation parameter</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>m=audio 49152 RTP/AVP 97 98 99 100 101</entry></row><row><entry /><entry>a=adapt_ext: red-offset = 1,2; agg=1</entry></row><row><entry /><entry>b=AS:42</entry></row><row><entry /><entry>b=RS:0</entry></row><row><entry /><entry>b=RR:2000</entry></row><row><entry /><entry>a=rtpmap:97 EVS/16000/1</entry></row><row><entry /><entry>a=fmtp:97 br=9.6-24.4; bw=swb; max-red=220</entry></row><row><entry /><entry>a=rtpmap:98 AMR-WB/16000/1</entry></row><row><entry /><entry>a=fmtp:98 mode-change-capability=2; max-red=220</entry></row><row><entry /><entry>a=rtpmap:99 AMR-WB/16000/1</entry></row><row><entry /><entry>a=fmtp:99 mode-change-capability=2; max-red=220; octet-</entry></row><row><entry /><entry>align=1</entry></row><row><entry /><entry>a=rtpmap:100 AMR/8000/1</entry></row><row><entry /><entry>a=fmtp:100 mode-change-capability=2; max-red=220</entry></row><row><entry /><entry>a=rtpmap:101 AMR/8000/1</entry></row><row><entry /><entry>a=fmtp:101 mode-change-capability=2; max-red=220; octet-</entry></row><row><entry /><entry>align=1</entry></row><row><entry /><entry>a=ptime:20</entry></row><row><entry /><entry>a=maxptime:240</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0306Although the present disclosure has been described with reference to one or more examples, workers skilled in the art will recognize that changes may be made in form and detail without departing from the scope of the disclosure and/or the appended claims.