Multi-Stream MTSI Client

Description

The MSMTSI client (Multi-Stream MTSI Client) is defined in 3GPP TS 26.114 and TS 26.980 as an MTSI (Multimedia Telephony Service for IMS) client that supports multiple streams as specified in Annex S of TS 26.114. MTSI itself is the IMS-based multimedia telephony service that provides conversational voice, video, and text, built on the IMS framework and using protocols such as SIP for session control and RTP for media transport. The MSMTSI client extends this baseline by adding explicit, standards-compliant support for multiple simultaneous media streams.

Crucially, the definition distinguishes between simply handling more than one stream and being a true MSMTSI client. An ordinary MTSI client may add a second stream — for example, a second video added to an ongoing video telephony session, as illustrated in Annex A.11 of TS 26.114 — without being an MSMTSI client. Such ad hoc multi-stream behavior does not imply compliance with the specific requirements, signaling procedures, and media handling rules of Annex S. Only a client that is fully compliant with Annex S qualifies as an MSMTSI client.

Annex S defines the requirements for multi-stream operation, including how streams are negotiated and managed, how media components are associated, and how the client must behave when multiple streams of the same or different media types are active. Compliance with Annex S ensures that multi-stream sessions interoperate correctly between terminals and, where applicable, with network media functions. It covers aspects such as stream setup and teardown, media synchronization, and the handling of multiple media types within a single session.

The MSMTSI client concept matters because multi-stream multimedia telephony is increasingly relevant to use cases beyond simple two-party video calls. Scenarios such as adding a second camera view, sharing a presentation alongside a video call, or combining real-time video with other media streams demand well-defined behavior. Without a formal compliance point like Annex S, different implementations could negotiate and render multiple streams in incompatible ways, leading to interoperability failures.

The term has been defined identically since its introduction in Release 13 and has been carried through Releases 14 to 19 without substantive change. Its stability indicates a mature specification baseline for multi-stream MTSI, and it remains the reference definition for distinguishing compliant multi-stream clients from clients that merely happen to support an additional stream.

Purpose & Motivation

The MSMTSI client definition exists to draw a clear compliance boundary for multi-stream multimedia telephony. Before such a definition, an MTSI client could support more than one stream in an implementation-specific manner, but there was no standardized way to guarantee that multi-stream sessions would interoperate across vendors. The MSMTSI client, defined by full compliance with Annex S of TS 26.114, solves this by establishing a precise set of requirements that a client must meet to be considered multi-stream capable in the standardized sense.

The definition also addresses a subtle but important ambiguity: supporting multiple streams is not the same as being an MSMTSI client. A client that adds a second video to an ongoing video telephony session — a behavior illustrated in Annex A.11 — may do so without implementing the full Annex S procedures. By explicitly stating that such a client is an MSMTSI client only if it is fully compliant with Annex S, the specification prevents over-claiming and gives operators and vendors a reliable criterion for interoperability testing and procurement.

Introduced in Release 13 as part of the evolution of MTSI toward richer multi-stream services, the MSMTSI client concept reflects the growing demand for sessions that combine multiple media streams. It provides the standards-based foundation for consistent negotiation, synchronization, and rendering of multi-stream sessions, and its unchanged retention through Release 19 confirms that the original compliance model remains fit for purpose.