RFC 8865

T.140 Real-Time Text Conversation over WebRTC Data Channels

📅 published January 2021, from ietf

RFC 8865: T.140 Real-Time Text Conversation over WebRTC Data Channels 💖

Okay bestie, this one's from January 2021 and it's a Standards Track document from the IETF ✨ It was written by C. Holmberg of Ericsson and G. Hellström (Gunnar Hellström, Accessible Communication) 🎀. It updates RFC 8373 and doesn't obsolete anything 🦋. The ISSN is 2070-1721. Its job is to show how a WebRTC data channel can carry real-time text, and how SDP offer/answer negotiates one of those channels, called a T.140 data channel 🌸

Abstract ✨

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.

Status of This Memo 💅

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.

Table of Contents 🌈

1.  Introduction
2.  Conventions
3.  WebRTC Data Channel Considerations
4.  SDP Considerations
  4.1.  Use of the 'dcmap' Attribute
  4.2.  Use of the 'dcsa' Attribute
    4.2.1.  Maximum Character Transmission Rate
    4.2.2.  Real-Time Text Conversation Languages
    4.2.3.  Real-Time Text Direction
  4.3.  Examples
5.  T.140 Considerations
  5.1.  Session-Layer Functions
  5.2.  Data Encoding and Sending
  5.3.  Data Buffering
  5.4.  Loss of T140blocks
  5.5.  Multi-party Considerations
6.  Gateway Considerations
7.  Update to RFC 8373
8.  Security Considerations
9.  IANA Considerations
  9.1.  Subprotocol Identifier "t140"
  9.2.  SDP 'fmtp' Attribute
  9.3.  SDP Language Attributes
  9.4.  SDP Media Direction Attributes
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

Okay so the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) [T140] defines a protocol for text conversation, which is also known as real-time text. On IP networks, the transport is the "RTP Payload for Text Conversation" mechanism [RFC4103], which is built on the Real-time Transport Protocol (RTP) [RFC3550].

This document specifies how a Web Real-Time Communication (WebRTC) data channel [RFC8831] can be used as a transport mechanism for T.140, and how the Session Description Protocol (SDP) offer/answer mechanism for data channels [RFC8864] 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 [RFC8864].

💭 NOTE: Why use a WebRTC data channel instead of RTP-based transport [RFC4103]? It's motivated by use case "U-C 5: Real-time text chat during an audio and/or video call with an individual or with multiple people in a conference". You can find that in Section 3.2 of [RFC8831]. Iconic reasoning 👑

The brief notation "T.140" is used as a name for the text conversation protocol according to [T140].

Real-time text is meant to be typed by human users on a keyboard, through handwriting recognition, voice recognition, or any other input method. The rate of character entry is usually a few characters per second or less 💖

Here's the map of the doc: 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. This document defines how to negotiate a T.140 data channel using the SDP offer/answer mechanism [RFC8864]. 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 (for example, the mechanism defined in [RFC8832]). Section 5 of [RFC8864] defines the mapping between the SDP 'dcmap' attribute parameters and the protocol parameters used in [RFC8832] 🧚

This document updates [RFC8373] by defining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for the "application/webrtc-datachannel" media type.

2. Conventions 🎀

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Translation: those capital words are the strict ones, so they carry real weight 😭 Lowercase ones are just regular English.

3. WebRTC Data Channel Considerations 🦋

The following WebRTC data channel property values [RFC8831] apply to a T.140 data channel:

              +--------------------------+-----------------+
              | Subprotocol Identifier   | t140            |
              +--------------------------+-----------------+
              | Transmission reliability | reliable        |
              +--------------------------+-----------------+
              | Transmission order       | in-order        |
              +--------------------------+-----------------+
              | Label                    | See Section 4.1 |
              +--------------------------+-----------------+

                                 Table 1
💭 NOTE: T.140 needs the transport channel to deliver real-time text without duplication and in its original order. So T.140 doesn't define reliable, ordered transmission at the application layer. With RTP-based transport, the RTP sequence number catches packet loss and out-of-order packets, and a redundancy mechanism gets the T.140 data delivered reliably. A WebRTC data channel already has reliable, in-order transmission [RFC8831], so the T.140 data channel doesn't need a redundancy mechanism or any application-level loss and out-of-order detection. The latency of the T.140 data channel is also considered good enough for what T.140 needs 🌈

4. SDP Considerations 💜

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

4.1. Use of the 'dcmap' Attribute 💅

An offerer and answerer MUST, in each offer and answer, include an SDP 'dcmap' attribute [RFC8864] in the SDP media description ("m=" section) [RFC4566] that describes the Stream Control Transmission Protocol (SCTP) association [RFC4960] 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 [RFC8864].

💭 NOTE: As specified in [RFC8831], when a data channel is negotiated using the mechanism defined in [RFC8832], the 'label' attribute parameter value has to be the same in both directions. That rule applies to data channels negotiated with the mechanism in this document too 🫶

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, for example, by sending a new offer without a T.140 data channel or by terminating the session. No retransmission limits here, babe 💀

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"

4.2. Use of the 'dcsa' Attribute 🌸

An offerer and answerer can, in each offer and answer, include one or more SDP 'dcsa' attributes [RFC8864] 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 [RFC8864]. Ignore it and keep vibing ✨

4.2.1. Maximum Character Transmission Rate

Okay so the dcsa attribute can carry the SDP fmtp attribute 💅, and that's how you signal a maximum character transmission rate [RFC4103] 🦋. The cps parameter says how fast the endpoint that includes it can receive text, and the value is a mean in characters per second over any 10-second interval ✨. It's giving "average over a window" energy, bestie 🫶.

If the fmtp attribute is included, the format attribute parameter value MUST be set to t140 🎀.

If there's no fmtp attribute with a cps parameter, the default value of 30 applies [RFC4103] 🌸.

The offerer and answerer MAY modify the cps parameter value in subsequent offers and answers 💜.

This document doesn't define any other use of the fmtp attribute for a T.140 channel 🙈. So if an offerer or answerer gets a dcsa attribute with an fmtp attribute that isn't set up by the procedure above, the offerer or answerer MUST ignore the dcsa attribute. Not me ignoring the vibe check 💀.

NOTE: The cps parameter is especially useful when a T.140 data channel endpoint is acting as a gateway (Section 6) and is interworking with a T.140 transport mechanism that has limits on how many characters can be sent per second ⭐.

If an endpoint gets text faster than it can handle, for example because the sending endpoint doesn't support the cps parameter, it SHOULD do one of two things 🔥. Option one: tell the sender it isn't willing to receive more text, using the direction attributes (Section 4.2.3) 🙅‍♀️. Option two: use a flow-control mechanism to slow the rate down 🐢. Hmm, but in some apps, like emergency services, getting a human back into the conversation ASAP is what matters most 🚨. So it might be better to just discard the overflow, insert a mark for loss [T140ad1], and keep processing the received text as fast as possible ⚡.

NOTE: When this spec was written, the standardized API for WebRTC data channels didn't support flow control 😭. If that ever changes, a receiving endpoint could use it to slow down how fast text arrives from the sender 🌈.

4.2.2. Real-Time Text Conversation Languages

dcsa attributes can carry the SDP hlang-send and hlang-recv attributes [RFC8373] to negotiate the language for the real-time text conversation 🌍✨.

For a T.140 data channel, the modality is "written" [RFC8373] 📝💖.

4.2.3. Real-Time Text Direction

dcsa attributes can carry the SDP sendonly, recvonly, sendrecv, and inactive attributes [RFC4566] to negotiate which direction text can go in during a real-time text conversation 🔁🦋.

NOTE: A WebRTC data channel is always bidirectional 🫢. The dcsa attribute only changes which direction implementations are allowed to transmit text on a T.140 data channel. That's the whole tea ☕.

The offer/answer rules for the direction attributes are based on the unicast stream rules in [RFC3264], as explained below 🧠. Just know the rules only apply to the direction attributes, okay? 💅

Session-level direction attributes [RFC4566] have no impact on a T.140 data channel 🙅‍♀️.

4.2.3.1. Generating an Offer

If the offerer wants 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 doesn't explicitly mark the data channel, an implicit sendrecv attribute inside a dcsa attribute gets applied by default 🌟.

If the offerer only wants to 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 only wants to 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 wants 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 didn't explicitly mark it) or recvonly, it MUST be ready to receive T.140 data as soon as the state of the T.140 data channel allows it 👂✨.

4.2.3.2. Generating an Answer

When the answerer accepts an offer and marks the direction of the text in the 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 didn't mark it at all, 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 doesn't explicitly mark the data channel, an implicit sendrecv attribute inside a dcsa attribute gets 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 ready to receive data as soon as the state of the T.140 data channel allows transmission of data 🚀.

4.2.3.3. Offerer Receiving an Answer

When the offerer gets an answer and the answerer has marked a data channel as sendrecv (or didn't mark it at all) or recvonly, 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 hasn't marked the direction of a T.140 data channel following the procedures above, it is RECOMMENDED that the offerer NOT treat that as an error. Instead, it should assume the answerer might both send and receive T.140 data on the data channel 🤷‍♀️💖.

4.2.3.4. Modifying the Text Direction

If an endpoint wants to change a previously negotiated text direction in an ongoing session, it MUST start 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 🫶.

4.3. Examples

Here's an example of an "m=" section of an offer for a T.140 data channel offering real-time text conversation in Spanish and Esperanto 🇪🇸🇪🇴, plus the "m=" section in the matching answer accepting Esperanto 🌈. The maximum character transmission rate is set to 20 💯. Since the offerer and answerer haven't explicitly set the real-time text direction, the default direction "sendrecv" applies 💅.

Offer:

m=application 911 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3
a=max-message-size:1000
a=sctp-port 5000
a=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:es eo
a=dcsa:2 hlang-recv:es eo

Answer:

m=application 2004 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1
a=max-message-size:1000
a=sctp-port 6000
a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:eo
a=dcsa:2 hlang-recv:eo

Here's another example, an "m=" section of an offer for a T.140 data channel where the offerer only wants to receive real-time text 👂, plus the "m=" section in the answer saying the answerer will only send real-time text 📤. No maximum character transmission rate is indicated, and no language preference is indicated either 🙈.

Offer:

m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3
a=max-message-size:1000
a=sctp-port 5000
a=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 recvonly

Answer:

m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1
a=max-message-size:1000
a=sctp-port 6000
a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 sendonly

5. T.140 Considerations ✨

5.1. Session-Layer Functions

Section 6.1 of [T140] describes the generic T.140 session control functions at a high level, in a way that doesn't depend on the signaling protocol 🧠. Here's how those functions work when you're using a T.140 data channel 💖.

Prepare session: An endpoint can show it supports T.140 data channels using signaling-specific means (for example, SIP OPTIONS [RFC3261]) or by indicating support in an offer or answer (Section 4) 🌸.

Initiate session: An offer is used to request setting up a T.140 data channel (Section 4) 📨.

Accept session: An answer is used to accept a request to set up a T.140 data channel (Section 4) ✅.

Deny session: An answer is used to reject a request to set up a T.140 data channel, using the generic procedures for rejecting a data channel [RFC8864] 🙅‍♀️.

Disconnect session: An offer or answer is used to disable a T.140 data channel that was already set up, using the generic procedures for closing a data channel [RFC8864] 👋.

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

5.2. Data Encoding and Sending

T.140 text is encoded and framed as T140blocks [RFC4103] 🎀.

Each T140block is sent on the SCTP stream [RFC4960] used to realize the T.140 data channel, using standard T.140 transmission procedures [T140] 🚀. One or more T140blocks can go in a single SCTP user message [RFC4960] 📦. Unlike RTP-based transport for real-time text [RFC4103], T.140 data channels don't use redundant transmission of text 🙅‍♀️. That's because the T.140 data channel gets 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 🤓.

NOTE: The T.140 coding details include optional control codes for controlling presentation, and these may not be supported by the presentation level of the receiving application 🙈. The receiving application is expected to handle these T.140 control codes appropriately (for example, ignore and skip them) even if their effect on the presentation isn't supported 🫶.

5.3. Data Buffering 🫧

okay so [T140] talks about buffering, and bestie, it's a total overhead-saver 💅 The max transmission interval for T140blocks coming out of the buffer is 500 ms, as long as there's text waiting to go 💖

Buffering MAY also be used for staying within the maximum character transmission rate (Section 4.2). ✨

Your app has to balance smooth flow with low latency when it picks a transmission interval, because real-time text chat is all about the vibes 🌸 It is RECOMMENDED to use the default transmission interval of 300 ms [RFC4103] for T.140 data channels 🎀 If your use case really needs low latency, lower values are an option, but you'll pay for it in extra overhead, so weigh that in 🦋

5.4. Loss of T140blocks 💔

okay, the sad part first: if there's a network failure or congestion, T.140 data channels can fail and get torn down 😭 If that happens but the session is still alive, it is RECOMMENDED that implementations try to reestablish the T.140 data channels 🫶

Here's the tea 🍵 A T.140 data channel has no way for the receiver to tell which T140blocks are retransmitted after the channel comes back, so the sending endpoint MUST NOT retransmit T140blocks, no exceptions 🙅‍♀️ On the flip side, a receiver SHOULD tell the user that the channel was reestablished and some text might have gone missing 👀 This MAY be done by inserting the missing text markers [T140ad1] or in any other way that's obvious to the user 🧚

NOTE: If the SCTP association [RFC4960] used to realize the T.140 data channel fails and gets torn down, it needs to be reestablished before the T.140 data channel can be reestablished. After the T.140 data channel is reestablished, the procedures defined in this section apply, regardless of whether only the T.140 data channel or the whole SCTP association got torn down.

5.5. Multi-party Considerations 👯‍♀️

If your implementation needs to handle multi-party scenarios, you need multiple simultaneous T.140 data channels, one for each remote party 💜 This is still true even when everyone talks through a centralized conference server, and that's because, unlike RTP media, WebRTC data channels and the T.140 protocol can't indicate where T.140 data came from 😤 The 'label' attribute parameter in the SDP 'dcmap' attribute (Section 4.1) can be used by the offerer to add extra info about each T.140 data channel, which helps implementations tell them apart 🏷️

NOTE: Future extensions to T.140 or the T140block might permit the indication of the source of T.140 data, in which case it might be possible to use a single T.140 data channel to transport data from multiple remote sources. The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward real-time text from one source at any given time and, for example, include human-readable text labels in the real-time text stream that indicate the source whenever the conference server switches the source. This would allow the receiver to present real-time text from different sources separately. The procedures for such a mechanism are outside the scope of this document.

6. Gateway Considerations 🌉

There are a bunch of real-time text transports and protocols out there for both packet-switched and circuit-switched networks ✨ Lots of them are built 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 because the technologies they relied on have been obsoleted, while others are still going strong 💅

When you're interworking between T.140 data channels and real-time text in other transports and protocols, there are several things to think about 🍓 At the time of writing this document, the most common IP-based real-time text transport is the RTP-based mechanism defined in [RFC4103]. This document doesn't define a complete interworking solution, but the list below gives some guidance and things to keep in mind when you design a gateway 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 [RFC4103]. Redundancy is declared and used on the RTP stream by default. There is no redundancy on the T.140 data channel, but the reliable property [RFC8864] 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.
NOTE: In order for the 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. At the time of writing this document, no mechanism to provide such end-to-end encryption is defined.
NOTE: The guidance and considerations above are for two-party connections. At the time of writing this specification, a multi-party solution for RTP-based T.140 transport had not yet been specified. Once such a solution is specified, it might have an impact on the above interworking guidance and considerations.

7. Update to RFC 8373 🔄

This document updates [RFC8373] 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 🏷️

8. Security Considerations 🔐

The generic WebRTC security considerations are defined in [RFC8826] and [RFC8827] 🛡️

The generic security considerations for WebRTC data channels are defined in [RFC8831]. Data channels are always encrypted by design, so 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 [RFC8864]. There are no additional security considerations specific to T.140 data channels 🙌

When you're interworking between T.140 data channels and RTP-based T.140 transport [RFC4103], the gateway has to be able to access the T.140 data in order to insert a missing text marker or perform other actions. That means the T.140 data cannot be encrypted end to end between the T.140 data channel endpoint and the RTP endpoint. 🚨

9. IANA Considerations 📋

9.1. Subprotocol Identifier "t140" 🏷️

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

9.2. SDP 'fmtp' Attribute 🎀

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

9.3. SDP Language Attributes 🌍

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

9.4. SDP Media Direction Attributes ✨

okay so this section is about the direction attributes, sendonly, recvonly, sendrecv, and inactive 💅. They only get the special treatment when they show up inside an SDP dcsa attribute tied to a T.140 data channel. That modified usage is explained in Section 4.2.3, so go check it out 🦋

The IANA registry for SDP Parameters gets a new usage level, dcsa (t140), added to each of the four attributes. It's the same entry each time, just with a different attribute name, so here they all are 💖

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
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
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
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

10. References 📚

10.1. Normative References 🔥

10.2. Informative References 🌸

Acknowledgements 🫶

This document is based on an earlier Internet-Draft edited by Keith Drage, Juergen Stoetzer-Bradler, and Albrecht Schwarz. Big thanks to them, honestly iconic 👑

Thomas Belling gave useful comments on the initial (pre-submission) version of the current document, and Paul Kyzivat and Bernard Aboba commented on the document too 💜

Authors' Addresses 🎀

Christer Holmberg
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland

Email: christer.holmberg@ericsson.com
Gunnar Hellström
Gunnar Hellström Accessible Communication
Esplanaden 30
SE-136 70 Vendelsö
Sweden

Email: gunnar.hellstrom@ghaccess.se
📦 where this page comes from