A Multimedia Telephony Service for IMS call uses the Call Session Control Function (CSCF) mechanisms to route control-plane signalling between the UEs involved in the call (see Figure 4.1). In the control plane, Application Servers (AS) should be present and may provide supplementary services such as call hold/resume, call forwarding and multi-party calls, etc. The scope of the present document is to specify the media path. In the example in Figure 4.1, it is routed directly between the PS Domains outside the IMS.

The call setup for an MTSI client in terminal using fixed access is the same as shown in Figure 4.1 for 3GPP terminals except that a fixed access is used instead of the 3GPP access and that the PS Domain is not necessarily used.

The functional components of a terminal including an MTSI client in terminal using 3GPP access are shown in Figure 4.2. An MTSI client in terminal using fixed access can have the same functional components except that it does not have any 3GPP Layer 2 protocol.

The scope of the present document is to specify media handling and interaction, which includes media control, media codecs, as well as transport of media and control data. General control-related elements of an MTSI client, such as SIP signalling (TS 24.229), fall outside this scope, albeit parts of the session setup handling and session control for conversational media are defined here:

• usage of SDP (RFC 4566) and SDP capability negotiation (RFC 5939) in SIP invitations for capability negotiation and media stream setup.
• set-up and control of the individual media streams between clients. It also includes interactivity, such as adding and dropping of media components.

Transport of media consists of the encapsulation of the coded media in a transport protocol as well as handling of coded media received from the network. This is shown in Figure 4.2 as the "packet based network interface" and is displayed, for conversational media, in more detail in the user-plane protocol stack in Figure 4.3. The basic MTSI client defined here specifies media codecs for speech, video, still images and text (see clause 5). Data channels do not require use of any codec but allows for real-time interaction in parallel to the conversational media (see clause 6.2.10). The User interface in Figure 4.2 interacts with a web page and a related script received through a downlink data channel to handle the data channel I/O and data formatting. All conversational media components are transported over RTP with each respective payload format mapped onto the RTP (RFC 3550) streams. The data channels are using SCTP (RFC 4960) over DTLS (RFC 8261), used as specified for WebRTC data channels (RFC 8831).

An MTSI client may also support non-conversational media, for example IMS messaging. The functional entities and the protocols used for IMS messaging are described in TS 24.247. The 3GPP Layer 2 protocol to be interfaced with MTSI client is PDCP (TS 36.323) for EPC. For 5GC, another user-plane protocol, SDAP (TS 37.324), is used on top of PDCP as shown in clause 4.4.1 of TS 38.300. It is assumed that the SDAP would be configured without header for both directions in the typical MTSI cases, effectively interfacing with PDCP, as SDAP header would be needed only when more than one QoS flows are multiplexed in a DRB or reflective mapping is enabled.

A Media Resource Function Processor (MRFP), see TS 23.002, may be inserted in the media path for certain supplementary services (e.g. conference) and/or to provide transcoding and may therefore act as a MTSI client together with other network functions, such as a MRFC. A Media Gateway (MGW), see TS 23.002, may be used to provide inter-working between different networks and services. For example, a MTSI MGW may provide inter-working between MTSI and 3G-324M services. The MTSI MGW may have more limited functionality than other MTSI clients, e.g. when it comes to the supported bitrates of media. The inter-working aspects are described in more detail in clause 12.