Content for TR 26.982 Word version: 18.0.0

3.1 Terms 3.2 Symbols 3.3 Abbreviations 4.1 General 4.2 Study on Multiparty RTT requirements from other standards
...

1 Scope p. 6

The present document provides the protocol details for the Multiparty Real-Time Text (Multiparty RTT) service in the IP Multimedia (IM) Core Network (CN) subsystem based on the requirements from TS 22.173.

The Multiparty RTT service is an operator specific service by which an operator enables the subscribers in conference to use real-time text during the conference session.

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to support the Multiparty RTT service.

2 References p. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.173: "Multimedia Telephony Service and supplementary services".

[3]

TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".

[4]

TS 24.147: "Conferencing Using IP Multimedia Core Network; Stage 3".

[5]

ITU-T T.140: Protocol for multimedia application text conversation, 02/1998, and T.140 Addendum 1, 02/2000

[6]

RFC 5194 (2008): "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)"

[7]

ITU-T F.700: Framework Recommendation for multimedia services, 11/2000

[8]

RFC 9071 (2021): "RTP-Mixer Formatting of Multiparty Real-Time Text"

[9]

RFC 8865 (2021): "T.140 Real-Time Text Conversation over WebRTC Data Channels"

[10]

RFC 4103 (2005): "RTP Payload for Text Conversation", G. Hellstrom and P. Jones.

3 Definitions of terms, symbols and abbreviations p. 6

3.1 Terms p. 6

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2 Symbols p. 7

void

3.3 Abbreviations p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

Application Server

BFCP

Binary Floor Control Protocol

CSCF

Call Session Control Function

Data Channel

IMS

IP Multimedia Subsystem

ITU-T

International Telecommunication Union-Telecommunication Standardization Sector

MRF

Multimedia Resource Function

MTSI

Multimedia Telephony Service over IMS

PRACK

Provisional Response Acknowledgement

RTC

Real-Time Communication

RTP

Real-time Transport Protocol

RTT

Real-Time Text

SDP

Session Description Protocol

SIP

Session Initiation Protocol

User Equipment

WebRTC

Web Real-Time Communication

4 Introduction of multiparty real-time text (Multiparty RTT) p. 7

4.1 General p. 7

Real-time text (RTT) may be used during conference sessions so that all call participants are enabled to create and send RTT to the other participants, and the text being presented in readable chunks growing in real time with indication of source. The presentation provides an approximate view of the relative timing of text from different parties.

The MTSI client in terminal may support multiparty real-time text (Multiparty RTT) as defined in this clause, the Multiparty RTT functionality has two solutions, over RTP and over IMS data channel. For the case of DCMTSI client in terminal, only the IMS data channel based solution is applicable.

The Multiparty RTT functionality for MTSI enables support of real-time text communication between each participant in a conference session. It addresses scenarios in some special groups of people, e.g., deaf person calls emergency service using RTT.

4.2 Study on Multiparty RTT requirements from other standards p. 7

4.2.1 General requirements p. 7

The general Multiparty RTT requirements from existing standards are listed as follows:

A solution should be applicable to IMS as specified in TS 23.228. Additionally, TS 24.147 provides the protocol details for conferencing within IMS based on SIP, SIP Events, SDP and the Binary Floor Control BFCP.
If text loss is detected or suspected, a missing text marker should be inserted in the text stream as defined in ITU-T T.140 [5].
The display of text from the members of the conversation should be arranged so that the text from each participant is clearly readable, and its source and the relative timing of entered text is visualized in the display. Mechanisms for looking back in the contents from the current session should be provided. The text should be displayed as soon as it is received as defined in ITU-T T.140 [5].
It should be possible to use real-time text in conferences both as a medium of discussion between individual participants (for example, for sidebar discussions in real-time text while listening to the main conference audio) and for central support of the conference with real-time text interpretation of speech. Further session setup and control requirements can be found in RFC 5194.

4.2.2 Performance requirements p. 8

The Multiparty RTT performance requirements from existing standards are listed as follows:

The mixer performance requirements can be expressed in one number, extracted from the user requirements on real-time text expressed in ITU-T F.700 [7], where it is stated that for "good" usability, text characters should not be delayed more than 1 second from creation to presentation. For "usable" usability the figure is 2 seconds.
If buffering is provided in the data channel, it should not delay transmission more than 500ms. A buffering time of 300ms is recommended when the application or end-to-end network conditions are not known to require another value as indicated in RFC 4103.