Signaling of a request to adapt a voice-over-IP communication session

Abstract

A method, receiver device and terminal for signaling an adaptation request to adapt a coding/decoding of real-time signals of a real-time communication session, from a receiver device to a sender device. The method is such that the adaptation request relates to a demand for aggregation and/or redundancy of frames, that it is generated according to the existence of a signaling parameter arising from a phase of negotiation of codecs used during initialization of the communication session and in that it is transported via a real-time protocol of RTP type.

Claims

1. A method for signaling an adaptation request that requests adaptation of at least one of a coding or decoding of real-time signals on a real-time communication session between a first terminal and a second terminal, wherein the method comprises the following acts performed by the first terminal: verifying existence of a signaling parameter obtained in a phase of negotiation of codecs used during initialization of the communication session with the second terminal, the signaling parameter indicating a capacity to use an existing reserved or unused code of a Codec Mode Request (CMR) type to code a frame aggregation and/or redundancy request; determining the adaptation request, which relates to a frame aggregation and/or redundancy request; and in response to obtaining the signaling parameter, inserting the adaptation request into a payload format, using a field included in an existing reserved or unused mode-change request code of the Codec Mode Request (CMR) type to transport the adaptation request, via a real-time protocol of a Real Time Protocol (RTP) type and transporting the adaptation request toward the second terminal via the real-time protocol.

2. The method as claimed in claim 1, wherein, in the case where the first and second terminals use coders/decoders of Adaptive Multi-Rate (AMR) or AMR-Wide Band (WB) type, the first terminal uses at least one default unused CMR code value from 9 to 14 to code aggregation and redundancy requests that request aggregation and redundancies of various rates.

3. The method as claimed in claim 1, wherein, in the case where the first and second terminal use coders/decoders of Enhanced Voice Services (EVS) type, at least one default unused CMR code value is used to code the redundancy requests that request redundancies of various rates.

4. The method as claimed in claim 1, comprising using a field of a padding request at an end of signaling of the RTP protocol to transport the adaptation request that requests adaptation of the communication session.

5. A first terminal that transmits to a second terminal a signaling of an adaptation request that requests adaptation of the coding/decoding of real-time signals on a real-time communication session between the first terminal and the second terminal, wherein the first terminal comprises: at least one processor; and at least one non-transitory computer-readable medium comprising instructions stored thereon, which when executed by the at least one processor configure the first terminal to: verify existence of a signaling parameter obtained in a phase of negotiation of codecs used that took place during initialization of the communication session, the signaling parameter indicating a capacity to use an existing reserved or unused code of a Codec Mode Request (CMR) type to code a frame aggregation and/or redundancy request; determine the adaptation request, which relates to a frame aggregation and/or redundancy request; and insert the adaptation request into a payload format, using a field included in an existing reserved or unused mode-change request code of the Codec Mode Request (CMR) type to transport the adaptation request, via a real-time protocol of a Real Time Protocol (RTP) type.

6. A non-transitory processor-readable storage medium storing a computer program containing instructions for execution of a method for signaling an adaptation request, when the instructions are executed by at least one processor of a first terminal, wherein the instructions configure the first terminal to: verifying existence of a signaling parameter obtained in a phase of negotiation of codecs used during initialization of a real-time communication session with a second terminal, the signaling parameter indicating a capacity to use an existing reserved or unused code of a Codec Mode Request (CMR) type to code a frame aggregation and/or redundancy request; determining the adaptation request, which requests adaptation of at least one of a coding or decoding of real-time signals of the communication session and which relates to a frame aggregation and/or redundancy request; and inserting the adaptation request into a payload format, using a field included in an existing reserved or unused mode-change request code of the Codec Mode Request (CMR) type to transport the adaptation request, via a real-time protocol of a Real Time Protocol (RTP) type and transporting the adaptation request toward the second terminal via the real-time protocol.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Other 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:

(2) FIG. 1 illustrates a known prior-art voice-over-IP communication system, which was described above;

(3) FIGS. 2a to 2d illustrate prior-art examples of IP packet formats in case of frame aggregation or redundancy, such as described above;

(4) FIGS. 3a to 3d illustrate the payload format for the AMR and AMR-WB codecs;

(5) FIGS. 4a to 4g illustrate the payload format for the EVS codec;

(6) FIGS. 5a to 5b illustrate prior-art examples of formats of RTCP APP packets such as described above;

(7) FIG. 6 illustrates one embodiment of a voice-over-IP communication system and of a signaling method according to the invention;

(8) FIG. 7 illustrates a more detailed embodiment of a voice-over-IP communication system according to the invention;

(9) FIG. 8 illustrates a payload format used, according to a first embodiment of the invention, to transport an adaptation request;

(10) FIG. 9 illustrates a payload format used, according to a second embodiment of the invention, to transport an adaptation request;

(11) FIG. 10 illustrates a payload format used, according to another embodiment of the invention, to transport an adaptation request; and

(12) FIG. 11 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

(13) FIG. 6 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 FIG. 1, the microphones and loudspeakers (101, 151, 102, 152) have been shown. The acoustic processing operations and the network connecting the two terminals have not been shown in FIG. 6, for the sake of conciseness and clarity.

(14) The terminal A comprises a sender 601 and a receiver 603 whereas the terminal B comprises a sender 651 and a receiver 653. 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 600 and 650. 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.

(15) The 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.

(16) The 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.

(17) The terminals A and B comprise a request-decoding block (blocks 607 and 657). Various embodiments of the extraction and decoding of these adaptation requests will be described below with reference to FIGS. 8 to 10. The block 607 or 657 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 607 and 657 is stored in an “adaptation_info” memory element containing a structure shared with the sending portion (blocks 601 and 651) 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 601 or 651 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 607 or 657.

(18) The terminals A and B comprise an adaptation block, 605 and 655, respectively, that implements a step of determining an adaptation to be made by the remote sender.

(19) The terminals A and B also comprise a request-coding block, 606 and 656, 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 605 and 655, is stored in a memory element called “cmr_request”, which contains a structure shared with the sending portion (blocks 601 and 651).

(20) In one embodiment of the invention, the terminals A and B are configured (blocks 600 and 650) 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 600 or 650) 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 600 and 650 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.

(21) The configuration blocks 600 and 650 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.

(22) The blocks 601, 603, 605, 606 and 607 in terminal A and the blocks 651, 653, 655, 656 and 657 in terminal B are considered to have access to a memory element that may be common to the transmission (601 and 606, for the example of terminal A) and to the reception (603, 605, 607 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 600 and 650, respectively) of the receiver, including blocks 603, 605 and 607 in terminal A and the blocks 653, 655 and 657 in terminal B. Here, adapt_enabled=0 if the parameter “adapt_red” is not present and 1 if it is present.

(23) As 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 600 and 650).

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

(25) This 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.

(26) The 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.

(27) The “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.

(28) In 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.

(29) Specifically, 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.

(30) In 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.

(31) As 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.

(32) However, 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.

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

(34) In 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.

(35) The signaling parameter is this time called “ext_adapt” and there are two complementary parameters: 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 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.

(36) In 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).

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

(38) In one embodiment of the invention, the blocks 605 and 655 are executed on each reception of a new RTP packet by the blocks 603 and 653, respectively. The receiver delivers at least the following information: the reception time of the RTP packets (in ms or according to the RTP clock of the media) the size of the RTP packets (in octets) information obtained from the RTP header: the RTP sequence number the RTP send time or timestamp

(39) From this information, the blocks 603 and 653 may estimate the following indicators: 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. 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: β=β.sub.0+β.sub.codec, where β.sub.codec is the bit rate of the codec (coding mode) and β.sub.0=β−β.sub.codec is 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).

(40) Below, two cases have been considered for the AMR and AMR-WB codecs: When adapt_enabled=0, the adaptation of the AMR and AMR-WB codecs is limited to a “basic” operation employing the existing CMR:

(41) A 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 600 and 650). This list is denoted {R.sub.0, . . . , R.sub.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.

(42) If N=1, the blocks 603 and 653 generate no adaptation requests via the memory element “cmr_request” (output of the blocks 605 and 655) other than a CMR indicating the rate R.sub.0 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.

(43) The coding rate of the preceding frame of index N−1 is denoted R.sub.i, where i denotes the index of one of the elements of {R.sub.0, . . . , R.sub.M-1}, corresponding to the rate of the preceding frame.

(44) If 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.sub.j immediately below the preceding rate, j being such that j=max(i−1,0) (the operator max(.Math.) here serves to ensure that the rate does not drop below the minimum rate R.sub.0) and this mode decision of the block 605 or 655 is converted by the sending portion into a CMR code (block 606 or 656) indicating the rate R.sub.j.

(45) When the loss rate is not too high (for example τ<10%) and the last change in rate took place 50 frames (1 second) ago for example, the mode decision of block 605 or 655 corresponds to the coding mode R.sub.j immediately below the available bandwidth i.e. j=arg max.sub.k{k|R.sub.kδβ.sub.0} if β.sub.0 R.sub.0 and j=0 otherwise.

(46) In 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.

(47) The blocks 605 and 655 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 605 or 655 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).

(48) At the moment that each new frame is coded, the sender 601 (or 651) accesses (in general in parallel with the block 605 or 655, 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. When adapt_enabled=1, the adaptation of the AMR and AMR-WB codecs is extended:

(49) Blocks 601 and 651 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 600 and 650), 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.

(50) In addition, blocks 603 and 653 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 603 and 653 separate them and insert the various coded frames into the reception-end jitter buffer depending on the type of transport, for example: 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 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.

(51) These two cases may also be combined.

(52) Details 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.

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

(54) The list of modes will once again be {R.sub.0, . . . , R.sub.M-1}, where M is the number of permitted modes.

(55) If 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.

(56) If the loss rate is not too high (for example τ<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 τ<10%) and the last change in rate took place 50 frames (1 second) ago for example, the mode decision of block 605 or 655 corresponds to the coding mode R.sub.j immediately below the available bandwidth i.e. j=arg max.sub.k{k|R.sub.kβ.sub.0} if β.sub.0R.sub.0 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.

(57) The adaptation decision is therefore represented, in one example, by way of a stored element “cmr_request” that comprises a plurality of elements: “cmr_request.updated”: this value is set to 1 if a new decision must be transmitted “cmr_request.requested_bitrate”: this value indicates the coding rate to be used 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.

(58) The adaptation decision (blocks 605 and 655) 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: 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”). 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.

(59) In the described embodiment, no adaptation decision to request a CAM mode will be generated by the blocks 605 and 655 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%.

(60) In 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.

(61) These 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).

(62) The 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”.

(63) An adaptation request corresponding to the adaptation determined in 605 and 655 is inserted into the current RTP packet by the respective blocks 606 and 656 used to code the request.

(64) Various ways in which these adaptation requests may be inserted are described below with reference to FIGS. 8 to 10.

(65) The respective blocks 607 and 657 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.

(66) Thus, FIG. 6 illustrates the steps implemented during the signaling method, namely, a step (600, 650) 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 (605, 655) of determining an adaptation request relating to a frame aggregation and/or redundancy request and a step (606, 656) 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.

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

(68) The blocks 705 and 755 for determining the adaptation to be made have the same functions as those described for blocks 605 and 655 with reference to FIG. 6.

(69) FIG. 7 shows that it is possible to distribute the functions that create the payload format between the coding blocks (701, 751) and the sending blocks (702, 752) depending on which one of these blocks forms the payload. The invention applies to both cases.

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

(71) The blocks 707 and 757 have the same functions as the blocks 607 and 657 described with reference to FIG. 6. 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.

(72) With reference to FIG. 8, the way in which the CMR codes such as defined below are used will now be described.

(73) In 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.

(74) In 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.

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

(76) For 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.

(77) Two cases of operation are distinguished between: When adapt_enabled=1, CMR codes defined as “reserved”, “not used” or “for future use” are used to make an extended request. 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 607 and 657) if CMR codes defined as “reserved”, “not used” or “for future use” are received, they are ignored.

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

(79) For 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.

(80) Likewise, for the EVS codec, as described with reference to FIG. 4g, the values with T=“111” and D other than “1111” are marked as reserved, this leaving 15 possible values.

(81) In 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.

(82) For 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%.

(83) For 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%).

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

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

(86) The 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.

(87) Table 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.

(88) It 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.

(89) TABLE-US-00001 TABLE 1 100% redundancy possible AMR (<12.2) 4.75 x 5.15 x 5.9 x 6.7 (x) 7.4 (x) 7.95 10.2 12.2

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

(91) Likewise, 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.

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

(93) TABLE-US-00002 TABLE 2 CMR Code AMR request 9 RED 2 × 4.75 10 RED 2 × 5.15 11 RED 2 × 5.9 12 RED 2 × 6.7 13 RED 2 × 7.4 14 Reserved

(94) In 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.

(95) TABLE-US-00003 TABLE 2a CMR Code AMR request 9 RED 2 × 4.75, offset 1 10 RED 2 × 5.9, offset 1 11 RED 2 × 7.4, offset 1 12 RED 2 × 4.75, offset 3 13 RED 2 × 5.9, offset 3 14 RED 2 × 7.4, offset 3

(96) In 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.

(97) TABLE-US-00004 TABLE 2b CMR code AMR request 9 RED 2 × 4.75 10 RED 2 × 5.15 11 RED 2 × 5.9 12 Agg 2 × 4.75 13 Agg 2 × 5.15 14 Agg 2 × 5.9

(98) It 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 605 and 606 (and 655 and 656) are constrained by the rates negotiated for the session, and therefore certain codes may not be used.

(99) It 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.

(100) Thus, if adapt_enabled=1, the blocks 605 and 655 (or 705 and 755) 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.

(101) It 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 605 and 655.

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

(103) TABLE-US-00005 TABLE 3 100% 100% redundancy redundancy possible possible AMR-WB (<12.65) (<23.85) 6.6 x x 8.85 x 12.65 (x) 14.25 15.85 18.25 19.85 23.05 23.85

(104) Depending 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.

(105) It 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.

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

(107) TABLE-US-00006 TABLE 4 CMR code AMR-WB request 9 RED 2 × 6.6 10 RED 2 × 8.85 11 RED 2 × 12.65 12 Agg 2 × 6.6 13 Agg 2 × 8.85 14 Agg 2 × 12.65

(108) In 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.

(109) TABLE-US-00007 TABLE 4a CMR code AMR-WB request 9 RED 2 × 6.6, offset = 1 10 RED 2 × 8.85, offset = 1 11 RED 2 × 12.65, offset = 1 12 RED 2 × 6.6, offset = 3 13 RED 2 × 8.85, offset = 3 14 RED 2 × 12.65, offset = 3

(110) In 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.

(111) Once again, if adapt_enabled=1, the blocks 605 and 655 (or 705 and 755) 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.

(112) It 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 605 and 655.

(113) The 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.

(114) The 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):

(115) TABLE-US-00008 TABLE 5 A1 A2 B1 B2 100% 100% 100% 100% redundancy redundancy redundancy redundancy possible possible possible possible (<13.2) (<24.4) (C13.2) (<24.4) EVS bw = nb − swb bw = nb − swb bw = swb bw = swb 5.9-VBR x [x] 7.2 (x) x 8 x 9.6 x (x) x 13.2 (x) (x) 16.4 24.4

(116) This 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.

(117) It 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.

(118) The number of CMR codes reserved for the EVS codecs is 15.

(119) For 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:

(120) TABLE-US-00009 TABLE 6 CMR code EVS request 111 0000 RED 2 × 7.2-NB 111 0001 RED 2 × 8-NB 111 0010 RED 2 × 9.6-NB 111 0011 RED 2 × 13.2-NB 111 0100 RED 2 × 7.2-WB 111 0101 RED 2 × 8-WB 111 0110 RED 2 × 9.6-WB 111 0111 RED 2 × 13.2-WB 111 1000 RED 2 × 7.2-SWB 111 1001 RED 2 × 8-SWB 111 1010 RED 2 × 9.6-SWB 111 1011 RED 2 × 13.2-SWB 111 1100 RED 2 × 6.6 111 1101 RED 2 × 8.85 111 1110 RED 2 × 12.65

(121) It 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.

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

(123) In 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.

(124) In 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.

(125) In 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).

(126) The 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 FIG. 8. 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.

(127) The adaptation request, which takes the form of new CMR codes, is therefore inserted into RTP packets defined by an RTP header (see FIG. 8). This header comprises the following fields: V for version, which identifies the RTP version 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 X for extension—if it is set to 1, the existing header is followed by an extension CC, for “CSRC count”, indicates the number of CSRC identifiers M, for “marker”, indicates whether the current data are particularly relevant to the application PT, for “payload type”, indicates the format of the payload “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 “Timestamp” to specify the send time of each packet and to allow the receiver to read the received samples at suitable intervals SSRC, for “Synchronization source”, which identifies each source of the same stream differently CSRC, for “Contributing sources”, which indicates the sources that contribute to the payload of the packet.

(128) It 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.

(129) This 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.

(130) Thus, 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.

(131) In a second embodiment, which is illustrated in FIG. 9, 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.

(132) In 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.

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

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

(135) Padding 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.

(136) In 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.

(137) In 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.

(138) For the AMR and AMR-WB codecs, the existing prior-art 4-bit CMR illustrated in FIG. 3c 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 FIG. 9; the 4 other bits in the MSB will be set to zero. In variants, the LSB and MSB will be inverted.

(139) The RTP header shown in FIG. 9 contains the following fields: V for version, which identifies the RTP version 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 FIG. 10. X for extension—if it is set to 1, the existing header is followed by an extension CC, for “CSRC count”, indicates the number of CSRC identifiers M, for “marker”, indicates whether the current data are particularly relevant to the application PT, for “payload type”, indicates the format of the payload “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 “Timestamp” to specify the send time of each packet and to allow the receiver to read the received samples at suitable intervals SSRC, for “Synchronization source”, which identifies each source of the same stream differently CSRC, for “Contributing sources”, which indicates the sources that contribute to the payload of the packet.

(140) The 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.

(141) For 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.

(142) However, 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.

(143) This 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.

(144) This solution also has the advantage of not modifying the RTP header of the packets.

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

(146) The operation of the various blocks of FIGS. 6 and 7 is unchanged, with the exception that the extended request is transported in a padding field.

(147) In 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 FIG. 10. 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.

(148) The operation of the various blocks of FIGS. 6 and 7 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.

(149) FIG. 11 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.

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

(151) On 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 10. 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.

(152) The processor implements the signaling method such as described with reference to FIG. 6, according to the instructions of the program PG.

(153) The terminal TA comprises a communication module 12 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 13 either via the signaling sent in the network or from the memory 11 of the terminal. L

(154) The 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 FIG. 6 or to FIG. 7.

(155) The 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.).

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

(157) TABLE-US-00010 APPENDIX 1 Conventional SDP offer m=audio 49152 RTP/AVP 97 98 99 100 101 b=AS:42 b=RS:0 b=RR:2000 a=rtpmap:97 EVS/16000/1 a=fmtp:97 br=9.6-24.4; bw=swb; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220 a=rtpmap:99 AMR-WB/16000/1 a=fmtp:99 mode-change-capability=2; max-red=220; octet- align=1 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220 a=rtpmap:101 AMR/8000/1 a=fmtp:101 mode-change-capability=2; max-red=220; octet- align=1 a=ptime:20 a=maxptime:240

(158) TABLE-US-00011 APPENDIX 2 SDP offer with an adaptation parameter m=audio 49152 RTP/AVP 97 98 99 100 101 a=adapt_red: red-offset=2 b=AS:42 b=RS:0 b=RR:2000 a=rtpmap:97 EVS/16000/1 a=fmtp:97 br=9.6-24.4; bw=swb; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220 a=rtpmap:99 AMR-WB/16000/1 a=fmtp:99 mode-change-capability=2; max-red=220; octet- align=1 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220 a=rtpmap:101 AMR/8000/1 a=fmtp:101 mode-change-capability=2; max-red=220; octet- align=1 a=ptime:20 a=maxptime:240

(159) TABLE-US-00012 APPENDIX 3 SDP offer with an adaptation parameter m=audio 49152 RTP/AVP 97 98 99 100 101 a=adapt_ext: red-offset = 1,2; agg=1 b=AS:42 b=RS:0 b=RR:2000 a=rtpmap:97 EVS/16000/1 a=fmtp:97 br=9.6-24.4; bw=swb; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220 a=rtpmap:99 AMR-WB/16000/1 a=fmtp:99 mode-change-capability=2; max-red=220; octet- align=1 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220 a=rtpmap:101 AMR/8000/1 a=fmtp:101 mode-change-capability=2; max-red=220; octet- align=1 a=ptime:20 a=maxptime:240

(160) Although 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.