Content for  TS 26.114  Word version:  19.0.0

This clause describes how the speech media should be packetized during a session. It includes definitions both for the cases where the access type is known and one default operation for the case when the access type is not known. Requirements for transmission of DTMF events are described in Annex G.

Use default operation as defined in clause 7.5.2.1.2.

Use default operation as defined in clause 7.5.2.1.2, except that the MTSI client in terminal

• should send two speech frames encapsulated in each RTP packet unless the session setup or adaptation request defines that the other PS end-point want to receive another encapsulation variant;
• should request receiving two speech frames encapsulated in each RTP packet but shall accept any number of frames per RTP packet up to the maximum limit of 12 speech frames per RTP packet.

Use default operation as defined in clause 7.5.2.1.2, except that the MTSI client in terminal:

• should send 0, 1, 2, 3 or 4 non-redundant speech frames encapsulated in each RTP packet unless the session setup or adaptation request defines that other PS end-point want to receive another encapsulation variant;
• should request receiving 1 to 4 speech frames in each RTP packet but shall accept any number of frames per RTP packet up to the maximum limit of 12 speech frames per RTP packet;
• may use application layer redundancy, in which case the MTSI client in terminal may encapsulate up to 12 speech frames in each RTP packet, with a maximum of four non-redundant speech frames.

To avoid congestion on the link and to improve inter-working with CS GERAN when AMR or AMR-WB is used and when more than one codec mode is allowed in the session, the MTSI client in terminal should limit the initial codec mode (ICM) to one of the lowest codec modes for an Initial Waiting Time from the beginning of the RTP stream, or until it receives one of the following:

• a frame-block with rate control information; or:
• an RTCP message with rate control information; or:
• reception quality feedback information, e.g. PLR or jitter in RTCP Sender Reports or Receiver Reports, indicating that the currently used codec mode is too high for the current operating condition.

The value for the Initial Waiting Time is 600 ms when ECN is not used and 500 ms when ECN is used, unless configured differently by the MTSI Media Adaptation Management as described in clause 17. The rate control information can either be: a CMR with a value other than '15' in the RTP payload; or a CMR with a value other than '15' in an RTCP_APP message (see clause 10.2.1). If no rate control information is received within the Initial Waiting Time, then the sending MTSI client in terminal should gradually increase the codec mode from the ICM towards the highest codec mode allowed in the session. While not detecting poor transmission performance or not receiving rate control information, the sending MTSI client in terminal should use step-wise up-switch to avoid introducing congestion during the upwards adaptation. The step-wise up-switch should be performed by switching to the next higher codec mode in the allowed mode set and then waiting for an Initial Up-switch Waiting Time before each subsequent up-switch until the first down-switch occurs. The value for the Initial Up-switch Waiting Time is 600 ms when ECN is not used and 500 ms when ECN is used, unless configured differently by the MTSI Media Adaptation Management as described in clause 17. The following rules can be used for determining the ICM:

• If 1 codec mode is included in the mode-set then this should be the ICM.
• If 2 or 3 codec modes are included in the mode-set then the ICM should be the codec mode with the lowest rate.
• If 4 or more codec modes are included in the mode-set then the ICM should be the codec mode with the 2nd lowest rate.

Use the default operation as defined in clause 7.5.2.1.2.

When the EVS AMR-WB IO mode is used from the start of the session, the Initial Codec Mode (ICM) should be selected as defined in clause 7.5.2.1.6 for AMR-WB. When EVS Primary mode is used from the start of the session, the following principles apply for the selection of the Initial Codec Mode bit-rate (ICMbr):

• If GBR is known and if GBR is less than MBR, the ICMbr should be aligned with the GBR or should be lower than GBR.

When EVS Primary mode is used from the start of the session, the Initial Codec Mode audio bandwidth (ICMab) should be the highest audio bandwidth negotiated for the Initial Codec Mode bit-rate (ICMbr).

An MTSI client may support dual-mono operation for EVS. The packetization of dual-mono for EVS is described in TS 26.445. When the EVS Primary mode is used for dual-mono encoding, the Header-full format must be used for all RTP packets. When offering dual-mono for an RTP payload type number, the number of channels is set to 2, see SDP example in clause A.14.

When the EVS codec embedded in the IVAS is used from the start of the session, then clause 7.5.2.1.8 applies. When the IVAS Immersive mode is used from the start of the session, the following principles apply for the selection of the Initial Codec Mode bit-rate (ICMbr):

• If GBR is known and if GBR is less than MBR, the ICMbr should be aligned with the GBR or should be lower than the GBR.

When IVAS Immersive mode is used from the start of the session, the Initial IVAS Coded Format (ICMicf) should be the most preferred immersive format negotiated for the session and the Initial Codec Mode audio bandwidth (ICMab) should be the highest audio bandwidth negotiated for the Initial Codec Mode bit-rate (ICMbr).