IMS and MTSI services are required to support inter-working with similar services operating on other IP networks, both IMS based and non-IMS based, TS 22.173. It is an operator option to provide transcoding when the end-to-end codec negotiation fails to agree on a codec to be used for the session. The requirements herein apply to MTSI MGWs when such transcoding is provided.
These requirements were designed for sessions carried with IP end-to-end, possibly inter-connected through one or more other IP networks.
A main objective is to harmonize the requirements for this inter-working case with the requirements for GERAN/UTRAN CS inter-working defined in clause 12.3. There is however one major difference as the MGW requirements in clause 12.3 apply only to the PS side of the MTSI MGW, i.e. between the MTSI MGW and the MTSI client in the terminal, while here there are requirements for the MTSI MGW both towards the MTSI client in the terminal and towards the remote network.
Most requirements included here apply only to the PS access towards the remote network but there are also requirements that target both the local MTSI client in terminal and the remote network or even only the local MTSI client.
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.
This clause applies to MTSI MGWs used for interworking between an MTSI client in terminal using 3GPP access and a client using another IMS or non-IMS IP network.
MTSI MGWs offering speech communication between an MTSI client in a terminal and a client in another IP network through a Network-to-Network Interface (NNI) using AMR shall support:
This clause applies to MTSI MGWs used for interworking between an MTSI client in terminal using fixed access and a client using another IMS or non-IMS IP network.
Media codecs for MTSI MGWs for speech inter-working between fixed access and IP clients in other IMS or non-IMS IP networks are specified in ETSI TS 181 005  in clause 6.2 for narrow-band codecs and in clause 6.3 for wide-band codecs. In addition, the MTSI MGW should support linear 16 bit PCM (L16) at 8 kHz sampling frequency for narrow-band speech. An MTSI MGW supporting wideband speech should also support linear 16 bit PCM (L16) at 16 kHz sampling frequency.
MTSI MGWs for speech inter-working between access and CS GERAN/UTRAN supporting AMR and AMR-WB shall follow clause 188.8.131.52.2 for the AMR and AMR-WB codecs. Tandem-free inter-working should be used whenever possible.
For the other codecs, the MTSI MGW shall follow the recommendations and requirements defined in clause 18 for the respective codec.
If the remote network supports AMR for narrowband speech and/or AMR-WB for wideband speech, then transcoding shall be avoided whenever possible. In this case, the MTSI MGW should not be included in the RTP path unless it is required for non transcoding related purposes. If the MTSI MGW is included in the RTP path then it shall support forwarding the RTP payload regardless of codec mode and packetization.
If the MTSI MGW is performing transcoding of AMR or AMR-WB then it shall be capable of restricting mode changes, both mode change period and mode changes to neighboring mode, if this is required by the remote network.
Requirements applicable to MTSI MGW for DTMF events are described in Annex G.
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, RFC 4585. If the RTP/AVPF profile is supported then the SDP Capability Negotiation (SDPCapNeg) framework shall also be supported, RFC 5939.
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 184.108.40.206. The payload format to be used for EVS encoded media is defined in TS 26.445. 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 220.127.116.11.
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 18.104.22.168 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 22.214.171.124, 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  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.
An MTSI MGW can be used to enable ECN within the local network when the local ECN-capable MTSI client in terminal is in a network that properly handles ECN-marked packets, and either the remote network cannot be confirmed to properly handle ECN-marked packets or the remote terminal does not support or use ECN.
If ECN is supported in the MTSI MGW, then the MTSI MGW shall also:
support RTP/AVPF and SDPCapNeg if the MTSI MGW supports RTCP AVPF ECN feedback messages;
be capable of enabling end-to-end rate adaptation between the local MTSI client in terminal and the remote client by performing the following towards the local MTSI client in terminal:
negotiate the use of ECN;
support ECN as described in this specification for the MTSI client in terminal, except that the MTSI MGW does not determine whether ECN can be used based on the Radio Access Technology.
An MTSI MGW can also be used to enable ECN end-to-end if the remote client uses ECN in a different way than what is described in this specification for the MTSI client in terminal, e.g. if the remote client only supports probing for the ECN initiation phase or it needs the RTCP AVPF ECN feedback messages.
The codec and other considerations for real-time text described in the present document for MTSI clients in terminal using 3GPP access apply also to MTSI clients in terminal using fixed access. There are thus no inter-working considerations on the media level between these types of end-points.
If different IP versions are used by the offerer and the answerer, information in the SDP offer or answer related to IP version and QoS negotiation should be modified appropriately by the MTSI MGW so that the offerer and the answerer agree with an identical or similar source bit-rates.
For video, b=AS in IPv6 should be assumed to be a product of b=AS in IPv4 and 1.04, rounded down to a nearest integer, when other information that can be used to re-compute b=AS in IPv6 from b=AS in IPv4 is not present. Likewise, b=AS in IPv4 should be assumed to be a product of b=AS in IPv6 and 0.96, rounded up to a nearest integer. These formulas meet the relationship of b=AS values for 176×144 and 320×240 in Table N.x. Depending on service policy or codec configuration, other formulas can be used.
An MTSI MGW for interworking between IPv4 and IPv6 networks supporting the 'a=bw-info' attribute (see clause 19) shall re-compute the bandwidth properties signalled with this attribute if only bandwidths for either IPv4 or IPv6 are present. If bandwidth properties are provided with values for both IPv4 and IPv6 then the MTSI MGW should not re-compute the bandwidths.
The meaning of "none" and "NO_REQ" for EVS (as specified in TS 26.445 is not equivalent to code-point "CMR=15" for AMR and AMR-WB (as specified according to TS 26.114 and RFC 4867 with its errata):
For AMR-WB, CMR=15 overrides the previously received CMR value (corresponding to a speech mode or CMR=15). In other words, when an MTSI client receives CMR15 it is no longer restricted for its outbound packets by the previously received CMR, however it still complies with the negotiated mode-set.
For EVS, the 'NO_REQ' and 'none' CMR code points mean that there is no request and this CMR value shall be ignored. In other words, when an MTSI client receives NO_REQ or 'none' for EVS it is still restricted for its outbound packets by the previously received CMR (if any) and in addition it still complies within the negotiated codec operation modes.
MGWs in the path, repacking between the RTP format according to RFC 4867 and the EVS RTP format in TS 26.445 shall translate between these code-points (in transcoder-free operation):
When translating a single frame per packet from AMR-WB to EVS (AMR-WB IO): CMR=15 shall be replaced by the highest possible of EVS AMR-WB IO allowed in the session.
When translating a single frame per packet from EVS (AMR-WB IO) to AMR-WB: NO_REQ and none shall be replaced by the previously sent CMR (or the highest possible of AMR-WB allowed in the session if no request has been sent since the beginning of the session).
When translating more than one frame per packet (e.g. from 1 frame per packet to 2 frames per packets or vice versa), the MGW may have to "combine" or "repeat" CMRs following same translation as for the single frame per packet when applicable.
The above translation rules apply except when MGW wants to change the CMR. An example is when a MGW detects problems at an early stage in uplink which may require the MGW to send a CMR to limit bitrate at a lower value than the incoming CMR from the remote media receiver.