Content for  TS 26.114  Word version:  18.4.0

Figure 10.6 below illustrates how the three requests are used by the transmitter. In this case, RTCP_APP_REQ_RED is equal to "000000000101".

• The speech encoder generates frames every 20 ms.
• The speech frames are buffered in the aggregation buffer until it is possible to generate a payload chunk with the number of frames requested by either ptime at session setup or by RTCP_APP_REQ_AGG during a session.
• The current payload chunk is used when constructing the current RTP packet.
• The history buffer contains previously transmitted payload chunks. The length of this buffer needs to be dimensioned to store the maximum number of payload chunks that are possible. This value is based on the max-red value, the maxptime values and from the minimum number of frames that the transmitter will encapsulate in the RTP packets. In this case, the buffer length is selected to 11 payload chunks since this corresponds to the worst case of max-red=220, maxptime=240 and one frame per payload chunk.
• After transmitting the current RTP packet, the content of the history buffer is shifted, the current payload chunk is shifted in to the history buffer as P(n-1) and the oldest payload chunk P(n-11) is shifted out.
• When constructing the (provisional) RTP payload, the selected preceding payload chunks are selected from the history buffer and added to the current payload chunk. In order to form a valid RTP payload, the transmitter needs to verify that the maxptime value is not exceeded. If the provisional RTP payload is longer than what maxptime allows, then the oldest speech frames shall be removed until the length (in time) of the payload no longer violates the maxptime value. NO_DATA frames in the beginning or at the end of the payload does not need to be transmitted and are therefore removed. The RTP Time Stamp needs to be incremented when a NO_DATA frames are removed from the beginning of the payload. A (provisional) RTP packet containing only NO_DATA frames does not need to be transmitted.

Note also that the transmitter is not allowed to send frames that are older than the max-red value that the transmitter has indicated in the SDP.

It should be noted that RTCP_APP_REQ_AGG and RTCP_APP_REQ_RED are independent. Furthermore, it should also be noted that different redundant payload chunks may contain different number of speech frames.

RTCP_APP_REQ_EPRR:

Codecs: The DATA field a 4-bit field and is encoded as described in the table below. The rate request indicates the maximum codec mode (highest bit-rate) that the receiver wants to receive. The sender may use a lower codec mode (lower bit-rate) when sending. The rate request shall comply with the media type parameters that are negotiated in the session.

RTCP_APP_REQ_EBWR:

Codecs: The DATA field is a 4-bit field b0…b3, corresponding to bit 4 to bit 7 in the octet:

• b0 set to '1' = request for narrowband.
• b1 set to '1' = request for wideband.
• b2 set to '1' = request for super-wideband.
• b3 set to '1' = request for fullband.

Each bit in the DATA field indicates a bandwidth that the receiver wants to receive. One or several of these four bits can be set to '1'. For example, a request for '1110' indicates that the receiver wants to receive narrowband, wideband or super-wideband speech but not fullband speech. The bandwidth request shall comply with the media type parameters that are negotiated in the session.

RTCP_APP_REQ_EPRED:

Codecs: The DATA field is a 4-bit field and is encoded as described in the table below.

Since channel-aware mode is only defined for the EVS Primary 13.2 kbps mode then sending an EVS Channel Aware Request also implies changing to the EVS Primary mode and to the 13.2 kbps bit-rate and possibly also changing the audio bandwidth to either WB or SWB.

RTCP_APP_REQ_EP2I:

Codecs: The DATA field is an 11-bit field where the first 9 bits (b4-b12) are used to indicate the AMR-WB codec modes that are allowed and the 2 last bits (b13 and b14) are flags to set mode-change-period and mode-change-neighbor as follows:

• first 9 bits for mode-set:
  • b4 = '0': AMR-WB 6.60 not allowed
    b4 = '1': AMR-WB 6.60 allowed,
  • b5 = '0': AMR-WB 8.85 not allowed
    b5 = '1': AMR-WB 8.85 allowed,
  • b6 = '0': AMR-WB 12.65 not allowed
    b6 = '1': AMR-WB 12.65 allowed,
  • b7 = '0': AMR-WB 14.25 not allowed
    b7 = '1': AMR-WB 14.25 allowed,
  • b8 = '0': AMR-WB 15.85 not allowed
    b8 = '1': AMR-WB 15.85 allowed,
  • b9 = '0': AMR-WB 18.25 not allowed
    b9 = '1': AMR-WB 18.25 allowed,
  • b10 = '0': AMR-WB 19.85 not allowed
    b10 = '1': AMR-WB 19.85 allowed,
  • b11 = '0': AMR-WB 23.05 not allowed
    b11 = '1': AMR-WB 23.05 allowed,
  • b12 = '0': AMR-WB 23.85 not allowed
    b12 = '1': AMR-WB 23.85 allowed.
• flags:
  • b13 = '0': mode-change-period=1,
    b13 = '1': mode-change-period=2,
  • b14 = '0': mode-change-neightbor=0,
    b14 = '1': mode-change-neightbor=1.

An MTSI client sending this request shall set at least one of the mode-set bits to '1'. An MTSI client receiving a request with all zeroes shall ignore the request. The mode-set indicated in the EVS Primary mode to EVS AMR-WB IO mode Switching Request can only allow codec modes that have been negotiated in SDP offer-answer. This request cannot be used to allow codec modes that have not been negotiated in SDP offer-answer. An MTSI client sending this request should also send an RTCP_APP_CMR to indicate the codec mode that should be used after switching to EVS AMR-WB IO mode. An MTSI client receiving this request without a request for a codec mode should use the rules for Initial Codec Mode (ICM) defined in clause 7.5.2.1.6 to determine the codec mode that should be used after switching to EVS AMR-WB IO mode. The last bit (b15) 'R' is reserved for future use. An MTSI client sending this request shall set it to '0'. An MTSI client receiving this request shall ignore this bit.

RTCP_APP_REQ_EI2P:

Codecs: The DATA field is a 4-bit field which is reserved for future use. All four bits are set to '0'. The bitrates and bandwidths that can be used after switching to EVS Primary mode are the same as negotiated at session setup or in a preceding session modification.