This clause defines how speech media should be handled in MTSI MGWs in inter-working scenarios between an MTSI client in terminal using 3GPP access and a non-3GPP IP network and between an MTSI client in terminal using fixed access and a non-3GPP IP network. This clause therefore defines requirements for what the MTSI MGW needs to support and how it should behave during session setup and session modification. A few SDP examples are included in Annex A.10.

It is important to optimize the quality-bandwidth compromise, even though the NNI uses a fixed IP network. For this reason, the following preference order should be used by MTSI MGWs unless another preference order is defined in bilateral agreements between the operators or configured otherwise by the operator:

• The best option is if a codec can be used end-to-end. For example, using AMR or AMR-WB end-to-end is preferable over transcoding through G.711 or G.722 respectively.
• The second best solution is to use G.711 or G.722 as inter-connection codecs, for narrow-band and wide-band speech respectively, since these codecs offer a good quality while keeping a reasonable bit rate.
• The linear 16 bit PCM format should only be used as the last resort, when none of the above solutions are possible.

If a wide-band speech session is possible, then fall-back to narrow-band speech should be avoided whenever possible, unless another preference order is indicated in the SDP.

MTSI MGWs offering speech communication over the NNI shall support the RTP/AVP profile and should support the RTP/AVPF profile, [40]. If the RTP/AVPF profile is supported then the SDP Capability Negotiation (SDPCapNeg) framework shall also be supported, [69]. An MTSI MGW supporting EVS should support the RTCP-APP signalling for speech adaptation defined in clause 10.2.1.

The payload format to be used for AMR and AMR-WB encoded media is defined in clause 12.3.2.1. The payload format to be used for EVS encoded media is defined in [125]. The MTSI MGW shall support the following payload SDP parameters for AMR and AMR-WB: octet-align, mode-set, mode-change-period, mode-change-capability, mode-change-neighbor, maxptime, ptime, channels and max-red. The payload format to be used for G.711 encoded media is defined in RFC 3551, for both μ-law (PCMU) and A-law (PCMA). The payload format to be used for G.722 encoded media is defined in RFC 3551. The payload format to be used for linear 16 bit PCM is the L16 format defined in RFC 3551. When this format is used for narrow-band speech then the rate (sampling frequency) indicated on the a=rtpmap line shall be 8000. When this format is used for wide-band speech then the rate (sampling frequency) indicated on the a=rtpmap line shall be 16000. The payload formats to be used for the other codecs are listed in clause 18.4.3.

For the G.711, G.722 and linear 16 bit PCM formats, the frame length shall be 20 ms, i.e. 160 and 320 speech samples in each frame for narrow-band and wide-band speech respectively. MTSI MGWs offering speech communication over the NNI shall support encapsulating up to 4 non-redundant speech frames into the RTP packets. MTSI MGWs may support application layer redundancy. If redundancy is supported then the MTSI MGW should support encapsulating up to 8 redundant speech frames in the RTP packets. Thereby, an RTP packet may contain up to 12 frames, up to 4 non-redundant and up to 8 redundant frames. An MTSI MGW setting up a speech session should align the ptime and maxptime between the networks so that the same packetization can be used end-to-end, even when transcoding is used. The MGW should use the packetization schemes indicated by the ptime value in the SDP offer and answer. If no ptime value is present in the SDP then the MGW should encapsulate 1 frame per packet or the packetization used by the end-point clients. The MTSI MGW should preserve the packetization used by the end-point clients to minimize the buffering times otherwise caused by jitter. For example, if one end-point adapts the packetization to use 2 frames per packet then the MTSI MGW should adapt the packetization to the other end-point to also use 2 frames per packet. This applies also when the MTSI MGW performs transcoding. The packet size can become quite large for some combinations of formats and packetization. If the packet size exceeds the Maximum Transfer Unit (MTU) of the network then the MTSI MGW should encapsulate fewer frames per packet. When the MTSI MGW does not perform any transcoding then it shall be transparent to the packetization schemes used by the end-point clients.

The RTP implementation shall include an RTCP implementation. MTSI MGWs offering speech should support AVPF (RFC 4585) configured to operate in early mode. When allocating RTCP bandwidth, it is recommended to allocate RTCP bandwidth and set the values for the "b=RR:" and the "b=RS:" parameters such that a good compromise between the RTCP reporting needs for the application and bandwidth utilization is achieved, see also SDP examples in Annex A.10. When an MTSI MGW uses tandem-free inter-working between two PS networks then it should align the RTCP bandwidths such that RTCP packets can be sent with the same frequency in both networks. This is to allow for sending adaptation requests end-to-end without being forced to buffer the requests in the MTSI MGW. The value of "trr-int" should be set to zero or not transmitted at all (in which case the default "trr-int" value of zero will be assumed) when Reduced-Size RTCP (see clause 7.3.6) is not used. For speech sessions, between the MTSI client in terminal and the MTSI MGW, it is beneficial to keep the size of RTCP packets as small as possible in order to reduce the potential disruption of RTCP onto the RTP stream in bandwidth-limited channels. RTCP packet sizes can be minimized by using Reduced-Size RTCP packets or using the parts of RTCP compound packets (according to RFC 3550) which are required by the application. The MTSI MGW shall be capable of adapting the session to handle possible congestion. For AMR and AMR-WB encoded media, the MTSI MGW shall support the adaptation signalling method using RTCP APP packets as defined in clause 10.2, both towards the MTSI client in terminal and towards the remote network. As the IP client in the remote network may or may not support the RTCP APP signalling method, the MTSI MGW shall also be capable of using the inband CMR in the AMR payload. When receiving inband CMR in the payload from the remote network, the MTSI MGW does not need to move the adaptation signalling to RTCP APP packets before sending it to the MTSI client in terminal. For PCM, G.722 and linear 16 bit PCM encoded media, the MTSI MGW shall support RFC 3550 for signalling the experienced quality using RTCP Sender Reports and Receiver Reports. For a given RTP based media stream to/from the MTSI client in terminal, the MTSI MGW shall transmit RTCP packets from and receive RTCP packets to the same port number. For a given RTP based media stream to/from the remote network, the MTSI MGW shall transmit RTCP packets from and receive RTCP packets on the same port number, not necessarily the same port number as used to/from the MTSI client in terminal. This facilitates inter-working with fixed/broadband access. However, the MTSI MGW may, based on configuration or local policy, accept RTCP packets that are not received from the same remote port where RTCP packets are sent by either the MTSI client in terminal or the remote network.

For AMR and AMR-WB encoded media, the MTSI MGW shall follow the same requirements when inter-working with other IP network as when inter-working with GERAN/UTRAN CS, see clause 12.3.2.1. For a given RTP based media stream to/from the MTSI client in terminal, the MTSI MGW shall transmit RTP packets from and receive RTP packets to the same port number. For a given RTP based media stream to/from the remote network, the MTSI MGW shall transmit RTP packets from and receive RTP packets on the same port number, not necessarily the same port number as used to/from the MTSI client in terminal. This facilitates inter-working with fixed/broadband access. However, the MTSI MGW may, based on configuration or local policy, accept RTP packets that are not received from the same remote port where RTP packets are sent by either the MTSI client in terminal or the remote network.

The MTSI MGW shall be capable of dynamically adding and dropping speech media during the session. The MTSI MGW may use the original SDP offer received from the MTSI client in terminal when creating an SDP offer that is to be sent outbound to the remote network. If the MTSI MGW adds codecs to the SDP offer then it shall follow the recommendations of clause 12.7.2.3 when creating the outbound SDP offer and when selecting which codec to include in the outbound SDP answer. If the MTSI MGW generates an SDP offer based on the offer received from the MTSI client in terminal, it should maintain the ptime and maxptime values as indicated by the MTSI client in terminal. If the MTSI MGW generates an SDP offer without using the SDP offer from the MTSI client in terminal then it should define the ptime and maxptime values in accordance in clause 12.7.2.6, i.e. the preferred values for ptime and maxptime are 20 and 80 respectively. If the MTSI MGW does not support AVPF (nor SDPCapNeg) then it shall not include the corresponding lines in the SDP offer that is sent to the remote network.

In case of interworking, the audio levels should be aligned to ensure suitable audio levels to the end users. This is especially important when codecs with different overload points are used on each side of the MTSI MGW as this can result in an asymmetrical loudness between the end points. For MTSI client in terminal using fixed access, clause 18.8 applies to ensure proper audio alignment. For communications requiring interworking with other IMS or non-IMS IP networks, terminals connected to these networks may use different codecs, which have different overload points. In this case, it is recommended that the MTSI MGW doing transcoding ensure proper audio level alignment. This alignment shall be performed such that the nominal level is preserved (0 dBm0 shall be maintained to 0 dBm0). As an example, a fixed CAT-IQ DECT terminal implementing G.722 with a 9 dBm0 overload point as recommended in ITU-T Recommendation G.722 [78] might need some audio level alignment in case of wideband voice interworking with a 3GPP terminal using AMR-WB with a 3.14 dBm0 overload point. The audio level alignment may use dynamic range control to prevent saturation or clipping.