This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updates RFC 8373 to specify its use with WebRTC data channels.

This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8865.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

The ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) [T140] defines a protocol for text conversation, also known as real-time text. The transport used for IP networks is the "RTP Payload for Text Conversation" mechanism [RFC 4103], based on the Real-time Transport Protocol (RTP) [RFC 3550]. This document specifies how a Web Real-Time Communication (WebRTC) data channel [RFC 8831] can be used as a transport mechanism for T.140 and how the Session Description Protocol (SDP) offer/answer mechanism for data channels [RFC 8864] can be used to negotiate such a data channel. In this document, a T.140 data channel refers to a WebRTC data channel for which the instantiated subprotocol is "t140" and where the channel is negotiated using the SDP offer/answer mechanism [RFC 8864]. The brief notation "T.140" is used as a name for the text conversation protocol according to [T140]. Real-time text is intended to be entered by human users via a keyboard, handwriting recognition, voice recognition, or any other input method. The rate of character entry is usually at a level of a few characters per second or less. Section 3 defines the generic data channel properties for a T.140 data channel, and Section 4 defines how they are conveyed in an SDP 'dcmap' attribute. While this document defines how to negotiate a T.140 data channel using the SDP offer/answer mechanism [RFC 8864], the generic T.140 and gateway considerations defined in Sections [3], [5], and [6] of this document can also be applied when a T.140 data channel is established using another mechanism (e.g., the mechanism defined in [RFC 8832]). Section 5 of RFC 8864 defines the mapping between the SDP 'dcmap' attribute parameters and the protocol parameters used in [RFC 8832]. This document updates [RFC 8373] by defining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for the "application/webrtc-datachannel" media type.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

The following WebRTC data channel property values [RFC 8831] apply to a T.140 data channel: Table 1

The generic SDP considerations, including the SDP offer/answer procedures [RFC 3264], for negotiating a WebRTC data channel are defined in [RFC 8864]. This section, and its subsections, define the SDP considerations that are specific to a T.140 data channel, identified by the 'subprotocol' attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute.

An offerer and answerer MUST, in each offer and answer, include an SDP 'dcmap' attribute [RFC 8864] in the SDP media description ("m=" section) [RFC 4566] describing the Stream Control Transmission Protocol (SCTP) association [RFC 4960] used to realize the T.140 data channel. The offerer and answerer MUST include the 'subprotocol' attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute. The offerer and answerer MAY include the 'priority' attribute parameter and the 'label' attribute parameter in the 'dcmap' attribute value, as specified in [RFC 8864]. The offerer and answerer MUST NOT include the 'max-retr' or 'max-time' attribute parameter in the 'dcmap' attribute. If either of those attribute parameters is received in an offer, the answerer MUST reject the offer. If either of those attribute parameters is received in an answer, the offerer MUST NOT accept the answer. Instead, the answerer MUST take appropriate actions, e.g., by sending a new offer without a T.140 data channel or by terminating the session. If the 'ordered' attribute parameter is included in the 'dcmap' attribute, it MUST be assigned the value 'true'. Below is an example of the 'dcmap' attribute for a T.140 data channel with stream id=3 and without any label: a=dcmap:3 subprotocol="t140"

An offerer and answerer can, in each offer and answer, include one or more SDP 'dcsa' attributes [RFC 8864] in the "m=" section describing the SCTP association used to realize the T.140 data channel. If an offerer or answerer receives a 'dcsa' attribute that contains an SDP attribute whose usage has not been defined for a T.140 data channel, the offerer or answerer should ignore the 'dcsa' attribute, following the rules in Section 6.7 of RFC 8864.

A 'dcsa' attribute can contain the SDP 'fmtp' attribute, which is used to indicate a maximum character transmission rate [RFC 4103]. The 'cps' attribute parameter is used to indicate the maximum character transmission rate that the endpoint that includes the attribute is able to receive, and the value is used as a mean value in characters per second over any 10-second interval. If the 'fmtp' attribute is included, the 'format' attribute parameter value MUST be set to 't140'. If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of 30 applies [RFC 4103]. The offerer and answerer MAY modify the 'cps' attribute parameter value in subsequent offers and answers. This document does not define any other usage of the 'fmtp' attribute for a T.140 channel. If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that is not set according to the procedure above, the offerer or answerer MUST ignore the 'dcsa' attribute. If an endpoint receives text at a higher rate than it can handle, e.g., because the sending endpoint does not support the 'cps' attribute parameter, it SHOULD either (1) indicate to the sending endpoint that it is not willing to receive more text, using the direction attributes (Section 4.2.3) or (2) use a flow-control mechanism to reduce the rate. However, in certain applications, e.g., emergency services, it is important to regain human interaction as soon as possible, and it might therefore be more appropriate to simply discard the received overflow, insert a mark for loss [T140ad1], and continue to process the received text as soon as possible.

'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes [RFC 8373] to negotiate the language to be used for the real-time text conversation. For a T.140 data channel, the modality is "written" [RFC 8373].

'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendrecv', and 'inactive' attributes [RFC 4566] to negotiate the direction in which text can be transmitted in a real-time text conversation. The offer/answer rules for the direction attributes are based on the rules for unicast streams defined in [RFC 3264], as described below. Note that the rules only apply to the direction attributes. Session-level direction attributes [RFC 4566] have no impact on a T.140 data channel.

If the offerer wishes to both send and receive text on a T.140 data channel, it SHOULD mark the data channel as sendrecv with a 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does not explicitly mark the data channel, an implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default. If the offerer wishes to only send text on a T.140 data channel, it MUST mark the data channel as sendonly with a 'sendonly' attribute inside a 'dcsa' attribute. If the offerer wishes to only receive text on a T.140 data channel, it MUST mark the data channel as recvonly with a 'recvonly' attribute inside a 'dcsa' attribute. If the offerer wishes to neither send nor receive text on a T.140 data channel, it MUST mark the data channel as inactive with an 'inactive' attribute inside a 'dcsa' attribute. If the offerer has marked a data channel as sendrecv (or if the offerer did not explicitly mark the data channel) or recvonly, it MUST be prepared to receive T.140 data as soon as the state of the T.140 data channel allows it.

When the answerer accepts an offer and marks the direction of the text in the corresponding answer, the direction is based on the marking (or the lack of explicit marking) in the offer. If the offerer either explicitly marked the data channel as sendrecv or did not mark the data channel, the answerer SHOULD mark the data channel as sendrecv, sendonly, recvonly, or inactive with a 'sendrecv', 'sendonly', 'recvonly', or 'inactive' attribute, respectively, inside a 'dcsa' attribute. If the answerer does not explicitly mark the data channel, an implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default. If the offerer marked the data channel as sendonly, the answerer MUST mark the data channel as recvonly or inactive with a 'recvonly' or 'inactive' attribute, respectively, inside a 'dcsa' attribute. If the offerer marked the data channel as recvonly, the answerer MUST mark the data channel as sendonly or inactive with a 'sendonly' or 'inactive' attribute, respectively, inside a 'dcsa' attribute. If the offerer marked the data channel as inactive, the answerer MUST mark the data channel as inactive with an 'inactive' attribute inside a 'dcsa' attribute. If the answerer has marked a data channel as sendrecv or recvonly, it MUST be prepared to receive data as soon as the state of the T.140 data channel allows transmission of data.

When the offerer receives an answer to the offer and the answerer has marked a data channel as sendrecv (or the answerer did not mark the data channel) or recvonly in the answer, the offerer can start sending T.140 data as soon as the state of the T.140 data channel allows it. If the answerer has marked the data channel as inactive or sendonly, the offerer MUST NOT send any T.140 data. If the answerer has not marked the direction of a T.140 data channel in accordance with the procedures above, it is RECOMMENDED that the offerer not process that scenario as an error situation but rather assume that the answerer might both send and receive T.140 data on the data channel.

If an endpoint wishes to modify a previously negotiated text direction in an ongoing session, it MUST initiate an offer that indicates the new direction, following the rules in Section 4.2.3.1. If the answerer accepts the offer, it follows the procedures in Section 4.2.3.2.

Below is an example of an "m=" section of an offer for a T.140 data channel offering real-time text conversation in Spanish and Esperanto, and an "m=" section in the associated answer accepting Esperanto. The maximum character transmission rate is set to 20. As the offerer and answerer have not explicitly indicated the real-time text direction, the default direction "sendrecv" applies. Below is an example of an "m=" section of an offer for a T.140 data channel where the offerer wishes to only receive real-time text, and an "m=" section in the associated answer indicating that the answerer will only send real-time text. No maximum character transmission rate is indicated. No preference for the language to be used for the real-time text conversation is indicated.

Section 6.1 of [T140] describes the generic T.140 session control functions at a high level, in a manner that is independent of the signaling protocol. The list below describes how the functions are realized when using a T.140 data channel.

Prepare session:

An endpoint can indicate its support of T.140 data channels using signaling-specific means (e.g., using SIP OPTIONS [RFC 3261]) or by indicating the support in an offer or answer (Section 4).

Initiate session:

An offer is used to request the establishment of a T.140 data channel (Section 4).

Accept session:

An answer is used to accept a request to establish a T.140 data channel (Section 4).

Deny session:

An answer is used to reject a request to establish a T.140 data channel, using the generic procedures for rejecting a data channel [RFC 8864].

Disconnect session:

An offer or answer is used to disable a previously established T.140 data channel, using the generic procedures for closing a data channel [RFC 8864].

Data:

Data is sent on an established T.140 data channel (Section 5.2).

T.140 text is encoded and framed as T140blocks [RFC 4103]. Each T140block is sent on the SCTP stream [RFC 4960] used to realize the T.140 data channel using standard T.140 transmission procedures [T140]. One or more T140blocks can be sent in a single SCTP user message [RFC 4960]. Unlike RTP-based transport for real-time text [RFC 4103], T.140 data channels do not use redundant transmission of text; this is because the T.140 data channel achieves robust transmission by using the "reliable" mode of the data channel. Data-sending procedures conform to [T140]. See Section 8 of [T140] for coding details.

As described in [T140], buffering can be used to reduce overhead, with the maximum assigned transmission interval of T140blocks from the buffer being 500 ms as long as there is text to send. Buffering MAY also be used for staying within the maximum character transmission rate (Section 4.2). An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a transmission interval. It is RECOMMENDED to use the default transmission interval of 300 ms [RFC 4103], for T.140 data channels. Implementers might also use lower values for specific applications requiring low latency, taking the increased overhead into consideration.

In the case of network failure or congestion, T.140 data channels might fail and get torn down. If this happens but the session is sustained, it is RECOMMENDED that implementations try to reestablish the T.140 data channels. As a T.140 data channel does not provide a mechanism for the receiver to identify retransmitted T140blocks after channel reestablishment, the sending endpoint MUST NOT retransmit T140blocks. Similarly, a receiver SHOULD indicate to the user that a channel has been reestablished and text might have been lost. This MAY be done by inserting the missing text markers [T140ad1] or in any other way evident to the user.

If an implementation needs to support multi-party scenarios, the implementation needs to support multiple simultaneous T.140 data channels, one for each remote party. At the time of writing this document, this is true even in scenarios where each participant communicates via a centralized conference server. This is because, unlike RTP media, WebRTC data channels and the T.140 protocol do not support the indication of the source of T.140 data. The 'label' attribute parameter in the SDP 'dcmap' attribute (Section 4.1) can be used by the offerer to provide additional information about each T.140 data channel and help implementations to distinguish between them.

A number of real-time text transports and protocols have been defined for both packet-switched and circuit-switched networks. Many are based on the ITU-T T.140 protocol at the application and presentation levels [T140]. At the time of writing this document, some mechanisms are no longer used, as the technologies they use have been obsoleted, while others are still in use. When performing interworking between T.140 data channels and real-time text in other transports and protocols, a number of factors need to be considered. At the time of writing this document, the most common IP-based real-time text transport is the RTP-based mechanism defined in [RFC 4103]. While this document does not define a complete interworking solution, the list below provides some guidance and considerations to take into account when designing a gateway for interworking between T.140 data channels and RTP-based T.140 transport:

• For each T.140 data channel, there is an RTP stream for real-time text [RFC 4103]. Redundancy is by default declared and used on the RTP stream. There is no redundancy on the T.140 data channel, but the reliable property [RFC 8864] is set on it.
• During a normal text flow, T140blocks received from one network are forwarded towards the other network. Keepalive traffic is handled by lower layers on the T.140 data channel. A gateway might have to extract keepalives from incoming RTP streams and MAY generate keepalives on outgoing RTP streams.
• If the gateway detects or suspects loss of data on the RTP stream and the lost data has not been retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel.
• If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing RTP stream if it detects or suspects that data sent by the remote T.140 data channel endpoint was lost.
• If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel if it detects or suspects that data sent or to be sent on the T.140 data channel was lost during the failure.
• The gateway MUST indicate the same text transmission direction (Section 4.2.3) on the T.140 data channel and the RTP stream.

This document updates [RFC 8373] by defining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for the "application/webrtc-datachannel" media type. SDP offerers and answerers MUST NOT include the attributes directly in the "m=" section associated with the "application/webrtc-datachannel" media type. Instead, the attributes MUST be associated with individual data channels, using the SDP 'dcsa' attribute. A specification that defines a subprotocol that uses the attributes MUST specify the modality for that subprotocol, or how to retrieve the modality if the subprotocol supports multiple modalities. The subprotocol is indicated using the SDP 'dcmap' attribute.

The generic WebRTC security considerations are defined in [RFC 8826] and [RFC 8827]. The generic security considerations for WebRTC data channels are defined in [RFC 8831]. As data channels are always encrypted by design, the T.140 data channels will also be encrypted. The generic security considerations for negotiating data channels using the SDP offer/answer mechanism are defined in [RFC 8864]. There are no additional security considerations specific to T.140 data channels. When performing interworking between T.140 data channels and RTP-based T.140 transport [RFC 4103], in order for a gateway to insert a missing text marker or perform other actions that require that the gateway have access to the T.140 data, the T.140 data cannot be encrypted end to end between the T.140 data channel endpoint and the RTP endpoint.

Per this document, the subprotocol identifier "t140" has been added to the "WebSocket Subprotocol Name Registry" as follows:

Subprotocol Identifier:

t140

Subprotocol Common Name:

ITU-T T.140 Real-Time Text

Subprotocol Definition:

RFC 8865

Reference:

RFC 8865

This document defines the usage of the SDP 'fmtp' attribute, if this attribute is included in an SDP 'dcsa' attribute associated with a T.140 real-time text session over a WebRTC data channel. The usage is defined in Section 4.2.1. The usage level "dcsa (t140)" has been added to the registration of the SDP 'fmtp' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

fmtp

Usage level:

dcsa (t140)

Purpose:

Indicate format parameters for a T.140 data channel, such as maximum character transmission rates.

Reference:

RFC 8865

This document modifies the usage of the SDP 'hlang-send' and 'hlang-recv' attributes, if these attributes are included in SDP 'dcsa' attributes associated with a T.140 data channel. The modified usage is described in Section 4.2.2. The usage level "dcsa (t140)" has been added to the registration of the SDP 'hlang-send' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

hlang-send

Usage level:

dcsa (t140)

Purpose:

Negotiate the language to be used on a T.140 data channel.

Reference:

RFC 8865

The usage level "dcsa (t140)" has been added to the registration of the SDP 'hlang-recv' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

hlang-recv

Usage level:

dcsa (t140)

Purpose:

Negotiate the language to be used on a T.140 data channel.

Reference:

RFC 8865

This document modifies the usage of the SDP 'sendonly', 'recvonly', 'sendrecv', and 'inactive' attributes, if these attributes are included in SDP 'dcsa' attributes associated with a T.140 data channel. The modified usage is described in Section 4.2.3. The usage level "dcsa (t140)" has been added to the registration of the SDP 'sendonly' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

sendonly

Usage level:

dcsa (t140)

Purpose:

Negotiate the direction in which real-time text can be sent on a T.140 data channel.

Reference:

RFC 8865

The usage level "dcsa (t140)" has been added to the registration of the SDP 'recvonly' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

recvonly

Usage level:

dcsa (t140)

Purpose:

Negotiate the direction in which real-time text can be sent on a T.140 data channel.

Reference:

RFC 8865

The usage level "dcsa (t140)" has been added to the registration of the SDP 'sendrecv' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

sendrecv

Usage level:

dcsa (t140)

Purpose:

Negotiate the direction in which real-time text can be sent on a T.140 data channel.

Reference:

RFC 8865

The usage level "dcsa (t140)" has been added to the registration of the SDP 'inactive' attribute in the "Session Description Protocol (SDP) Parameters" registry as follows:

Contact name:

IESG

Contact email:

iesg@ietf.org

Attribute name:

inactive

Usage level:

dcsa (t140)

Purpose:

Negotiate the direction in which real-time text can be sent on a T.140 data channel.

Reference:

RFC 8865

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3264]

J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.

[RFC4103]

G. Hellstrom, and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>.

[RFC4566]

M. Handley, V. Jacobson, and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006,
<https://www.rfc-editor.org/info/rfc4566>.

[RFC4960]

R. Stewart, "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8373]

R. Gellens, "Negotiating Human Language in Real-Time Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018,
<https://www.rfc-editor.org/info/rfc8373>.

[RFC8826]

E. Rescorla, "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, January 2021,
<https://www.rfc-editor.org/info/rfc8826>.

[RFC8827]

E. Rescorla, "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021,
<https://www.rfc-editor.org/info/rfc8827>.

[RFC8831]

R Jesup, S Loreto, and M Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://www.rfc-editor.org/info/rfc8831>.

[RFC8864]

Huawei, K. Drage, M. Makaraju, R. Ejzak, J. Marcon, and R. Even, "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021,
<https://www.rfc-editor.org/info/rfc8864>.

[T140]

ITU-T, "Protocol for multimedia application text conversation", February 1998,
<https://www.itu.int/rec/T-REC-T.140-199802-I/en>.

[T140ad1]

ITU-T, "Recommendation ITU-T.140 Addendum 1 (02/2000), Protocol for multimedia application text conversation", February 2000,
<https://www.itu.int/rec/T-REC-T.140-200002-I!Add1/en>.

[RFC3261]

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.

[RFC3550]

H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003,
<https://www.rfc-editor.org/info/rfc3550>.

[RFC8832]

R. Jesup, S. Loreto, and M Tüxen, "WebRTC Data Channel Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832, January 2021,
<https://www.rfc-editor.org/info/rfc8832>.

This document is based on an earlier Internet-Draft edited by Keith Drage, Juergen Stoetzer-Bradler, and Albrecht Schwarz. Thomas Belling provided useful comments on the initial (pre-submission) version of the current document. Paul Kyzivat and Bernard Aboba provided comments on the document.

Christer Holmberg

Gunnar Hellström