In order to support inter-working between different networks it is good if common codecs for the connection can be found. Requirements for different networks are described in this clause. In some cases functionality is also needed in the network to make the inter-working possible (e.g. MGCF and MGW).
Inter-working functions are required between IMS and CS. There are separate functions, in e.g. a MGCF, for control-plane inter-working (see TS 29.163) and, in e.g. a IM-MGW, for user-plane inter-working. Control-plane inter-working includes for instance SIP ⇔ BICC and SIP ⇔ H.245 protocol translations, whereas user-plane inter-working requires transport protocol translations and possibly transcoding.
An interoperable set of speech, video and real-time text codecs is specified for 3G-324M and MTSI. Both video codec level and maximum bitrate can be specified as part of the call setup negotiation (see clause 12.2.5). Thus, it may be possible that the MTSI client in terminal and a CS UE agree on a common codec end-to-end without the need for MGW transcoding.
If a common codec is not found and the MTSI MGW does not support transcoding between any of the supported codecs, then the controlling MGCF may drop the unsupported media component. If the speech part cannot be supported, then the connection should not be set up.
A channel for real-time text is specified in ITU-T H.324. Presentation and coding is specified according to ITU-T Recommendation T.140, which is also used for MTSI clients (see clause 7.4.4). Inter-working is a matter of establishing the text transport channels and moving the text contents between the two transport levels.
The MTSI MGW should use a speech de-jitter buffer in the direction IMS to CS with sufficient performance to meet the 10 milliseconds maximum jitter requirement in clause 6.7.2 of ITU-T Recommendation H.324. H.324 specifies that transmission of each speech AL-SDU at the H.223 multiplex shall commence no later than 10 milliseconds after a whole multiple of the speech frame interval, measured from transmission of the first speech frame.
Temporary video rate variations can occur on the IMS side for example due to congestion. The video rate on the CS side, in contrast, is under full control of the CS side UE and the MGCF.
During session setup, the MGCF shall negotiate a video bitrate on the IMS side that allows all video bits to be conveyed to/from the CS link.
A buffer shall be maintained at the IM-MGW in the direction from the IMS to the CS side. The size of the buffer should be kept small enough to allow for a low end-to-end delay, yet large enough to conceal most network jitter on the IMS side. Temporary uneven traffic on the IMS side, beyond the handling capability of the buffer, should be handled as follows: if the buffer overflows, RTP packets should be dropped and the resulting loss and observed jitter should be reported by the means of an RTCP RR at the earliest possible sending time. The drop strategy may preferably be implemented media aware (i.e. favouring dropping predicted information over non-predicted information and similar techniques), or may be drop-head. If the buffer runs empty, the CS side should insert appropriate flag stuffing.
A buffer shall be maintained in the direction from the CS to the IMS side. The size of the buffer should be kept small enough to allow for a low end-to-end delay, but large enough to conceal most network jitter on the CS side. If the buffer overflows, then video bits must be dropped, preferably in a media-aware fashion, i.e. at GOB/slice/picture boundaries. IM-MGWs may also take into account the type of media data, i.e. coded with or without prediction. When the buffer runs empty, no activity is required on the IMS side.
If the CS video call is changed to a speech-only call (TS 23.172), the video component on the IMS side shall be dropped.
If RTP packet loss is detected on input to the MTSI MGW at the IMS side, including losses caused by buffer-full condition as described above, corresponding H.223 AL-SDU sequence number increments should be made on the CS side to enable loss detection and proper concealment in the receiving CS UE.
If packet loss is detected on the CS side, e.g. through H.223 AL-SDU sequence numbers, those losses should be indicated towards the IMS side through corresponding RTP packet sequence number increments. The deliberate increments made for this reason will be visible in the RTCP RR from the MTSI client and the MTSI MGW should take that into account when acting on RTCP RR from the MTSI client, as the CS side losses are not related to the IMS network conditions.
This is mainly relevant in the direction from CS to IMS. The H.223 AL-SDUs include a CRC that forms an unreliable indication of data corruption. On the IMS side, no generic protocol mechanisms are available to convey this CRC and/or the result of a CRC check. The MTSI MGW shall discard any AL-SDUs which fail a CRC check and are not of a payload type that supports the indication of possible bit errors in the RTP payload header or data. If such payload type is in use, the MTSI MGW may forward corrupted packets, but in this case shall indicate the possible corruption by the means available in the payload header or data. One example is setting the Q bit of RFC 4867 to 0 for AMR speech data that was carried in an H.223 AL-SDU with CRC indicating errors. Another example is setting the F bit of RFC 6184 for H.264 (AVC) NAL units or the F bit of RFC 7798 for H.265 (HEVC) NAL units that may contain bit errors.
The H.223 AL-SDU CRC is not fully fail-safe and it is therefore recommended that a MTSI client is designed to be robust and make concealment of corrupt media data, similar to the CS UE.
The same packet size and alignment requirements and considerations as defined in clause 7.5.2 of the present document and in TS 26.111 apply to the MTSI MGW and controlling MGCF, as it in that sense acts both as a MTSI client towards the IMS and as a CS UE towards the CS side. Maximum available buffer size for packetization of media data may differ between IMS and CS UE. To avoid non-favourable segmentation of data (especially video) by the MTSI MGW, the controlling MGCF should indicate the SDP 'a' attribute "3gpp_MaxRecvSDUSize" to the MTSI client in terminal. This attribute indicates the maximum SDU size of the application data (excluding RTP/UDP/IP headers) that can be transmitted to the receiver without segmentation. The specific maximum SDU size limit is determined by the MGCF from the H.245 bearer capability exchange between the CS UE and the MGCF. For example, the MTSI MGW determines this through the maximumAl2SDUSize and maximumAl3SDUSize fields of the H223Capability member in H.245 TerminalCapabilitySet message.
The ABNF for the maximum receive SDU size attribute is described as follows:
Max-receive-SDU-size-def = "a""=""3gpp_MaxRecvSDUSize"":" size-value CRLF
size-value = 1*5DIGIT
; 0 to 65535 in octets
The value "size-value" indicates the maximum SDU size of application data, excluding RTP/UDP/IP headers, that can be transmitted to the other end point without segmentation.
The parameter "3gpp_MaxRecvSDUSize" should be included in the SDP at the session level and/or at the media level. Its usage is governed by the following rules:
At the session level, the "3gpp_MaxRecvSDUSize" attribute shall apply to the combination of the data from all the media streams in the session.
At the media level, the "3gpp_MaxRecvSDUSize" attribute indicates to the MTSI client in terminal that this particular media stream in the session has a specific maximum SDU size limit beyond which received SDUs will be segmented before delivery to the CS UE.
If the "3gpp_MaxRecvSDUSize" attribute is included at the session and media levels, then the particular media streams have specific maximum SDU size limits for their own data while the session has an overall maximum SDU size limit for all the media data in the session.
The MGCF includes the "3gpp_MaxRecvSDUSize" attribute in the SDP offer or answer sent to the MTSI client in terminal after the MGCF determines the bearer capability of the CS UE (see Annex E of TS 29.163). Upon reception of the SDP offer or answer that includes the "3gpp_MaxRecvSDUSize" attribute, the MTSI client in terminal need not include this attribute in its subsequent exchange of messages with the MTSI MGW.
There are no offer/answer implications on the "3gpp_MaxRecvSDUSize" attribute. The "3gpp_MaxRecvSDUSize" attribute in the SDP from the MTSI MGW is only an indication to the MTSI client in terminal of the maximum SDU size that avoids segmentation for the specified media streams and/or session.
The IM-MGW and controlling MGCF should forward and translate the timing information between the IMS side (RTP timestamps, RTCP sender reports) and the CS side (H.245 message H223SkewIndication) to allow for media synchronization in the MTSI client in terminal and the CS UE. The MTSI MGW shall account for its own contribution to the skew in both directions. Note that transmission timing of H223SkewIndication and RTCP SR must be decoupled. H223SkewIndication has no timing restrictions, but is typically sent only once in the beginning of the session. RTCP SR timing is strictly regulated in RFC 3550, RFC 4585, and clause 7.3. To decouple send timings, the time shift information conveyed in H223SkewIndication and RTCP SR must be kept as part of the MTSI MGW/MGCF session state. H223SkewIndication should be sent at least once, and may be sent again when RTCP SR indicates a synchronization change. A synchronization change of less than 50 ms (value to be confirmed) should be considered insignificant and need not be signalled.