T.140 Real-time Text Conversation over WebRTC Data Channels
EricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.com
Transport
MMUSIC Working GroupSDPITU-TT.140Data ChannelWebRTCreal-time text
This document specifies how a 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 SDP offer/answer mechanism can be used to negotiate
such data channel, referred to as T.140 data channel. The document updates
RFC 8373.
The ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140)
defines a protocol for text conversation, also known as
real-time text. The native transport for IP networks is the "RTP Payload for Text Conversation"
mechanism, based on the Real-time Transport Protocol (RTP) .
This document specifies how a WebRTC data channel
can be used as a transport mechanism for T.140, and how the SDP offer/answer mechanism
can be used to negotiate such data channel.
In this document, a T.140 data channel refers to a WebRTC data channel for which
the instantiated sub-protocol is "t140", and where the channel is negotiated
using the SDP-based external negotiation method .
NOTE: The decision to transport real-time text using a WebRTC data channel,
instead of using RTP based transport ,
is 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",
see Section 3.2 of .
The brief notation "T.140" is used as a synonym for the text
conversation protocol according to .
defines the generic data channel properties for
a T.140 data channel, and defines how they are conveyed
in an SDP dcmap attribute. While this document defines how to establish a
T.140 data channel using the SDP-based external negotiation method
, the generic T.140 and gateway
considerations defined in ,
and of this document can also be applied when a T.140 data channel
is established using another mechanism (e.g., the mechanism defined in
). Section 5 of
defines the mapping between the
SDP dcmap attribute parameters and the protocol parameters used in
.
This document is based on an earlier Internet draft edited by Keith Drage,
Juergen Stoetzer-Bradler and Albrecht Schwarz.
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
when, and only when, they appear in all capitals, as shown here.
The following WebRTC data channel property values
apply to a T.140 data channel:
Subprotocol Identifiert140Transmission reliabilityreliableTransmission orderin-orderLabelSee and
NOTE: T.140 requires the transport channel to provide transmission of real-time text without
duplication and in original order. Therefore, T.140 does not specify reliable and ordered
transmission of T.140 data on the application layer. Instead, when RTP based transport is used,
the RTP sequence number is used to detect packet loss and out-of-order packets, and a redundancy
mechanism is used to achieve reliable delivery of T.140 data. By using
the WebRTC data channel reliable and in-order transmission features
for the T.140 data channel, there is no need for a redundancy mechanism or a mechanism to detect
data loss and out-of-order delivery on the application level. The latency characteristics of the
T.140 data channel is also regarded to be sufficient to meet the application requirements of T.140.
The generic SDP considerations, including the SDP Offer/Answer procedures, for
negotiating a WebRTC data channel are defined in .
This section defines the SDP considerations that are specific to a T.140 data channel.
An offerer and answerer MUST, in each offer and answer, include an SDP 'dcmap'
attribute in the SDP media
description (m= section) describing the SCTP association
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 value.
The offerer and answerer MAY include the priority attribute parameter and
the label attribute parameter in the 'dcmap' attribute value. If the offerer
includes a label attribute parameter, the answerer MUST NOT change the value
in the answer.
NOTE: As specified in ,
when a data channel is negotiated using the mechanism defined in ,
the label attribute parameter value has to be the same in both directions. That rule also
applies to data channels negotiated using the mechanism defined in this document.
The offerer and answerer MUST NOT include the max-retr and max-time
attribute parameters in the 'dcmap' attribute.
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 MAY, in each offer and answer, include one or more
SDP 'dcsa' attributes
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 which 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 .
A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to indicate
a maximum character transmission rate . 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 MUST be set to "-".
If the 'fmtp' attribute is not included, the default value of 30 applies .
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 'fmtp' attribute that
is not according to the procedure above the offerer or answerer MUST discard the 'dcsa'
attribute.
NOTE: The 'cps' attribute parameter is especially useful when a T.140 data channel
endpoint is acting as a gateway () and is interworking with
a T.140 transport mechanism that have restrictions on how many characters can be sent
per second.
'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes
to negotiate the language to be used for the real-time
text conversation.
For a T.140 data channel, the modality is "written" .
'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendrecv' and
'inactive' attributes to negotiate the direction in
which text can be transmitted in a real-time text conversation.
NOTE: A WebRTC data channel is always bi-directional. The usage of the 'dcsa'
attribute only affects the direction in which implementations are allowed to
transmit text on a T.140 data channel.
The offer/answer rules for the direction attributes are based on the rules
for unicast streams defined in , as described below.
Note that the rules only apply to the direction attributes.
Session level direction attributes 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, a
'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied.
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 (implicit or explicit) 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 marking is based on the marking (explicit or implicit)
in the offer.
If the offerer marked the data channel as sendrecv (implicitly or explicitly),
the answerer MUST mark the data channel as sendrecv (implicitly or explicitly), sendonly, recvonly or inactive
with a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute
inside a 'dcsa' attribute.
If the offerer marked the data channel as sendonly, the answerer MUST
mark the data channel as recvonly or inactive with a 'recvonly' respective
'inactive' attribute 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' respective
'inactive' attribute 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, if the answerer has marked a
data channel as sendrecv (implicit or explicit) 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.
As the answerer implementation might not support the direction procedures in this section, 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 does not process that
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 .
If the answerer accepts the offer it follows the procedures in
.
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 and the default
text transmission 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 describes the generic T.140 session
control functions at high-level and a signalling protocol
independent manner. 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 signalling specific means (e.g., using SIP OPTIONS ), or by indicating the support in an
offer or answer ()Initiate session: An offer used to request the establishment of a
T.140 data channel ()Accept session: An answer used to accept a request to establish a
T.140 data channel ()Deny session: An answer used to reject a request to establish
a T.140 data channel, using the generic procedures for rejecting
a data channel Disconnect session: An offer or answer used to disable a previously
established T.140 data channel, using the generic procedures for closing
a data channel Data: Data sent on an established T.140 data channel ()
T.140 text is encoded and framed as T140blocks .
Each T140block is sent on the SCTP stream used to
realize the T.140 data channel using standard T.140 transmission procedures
. One or more T140blocks can be sent in a single
SCTP user message . Unlike RTP based transport for
real-time text , T.140 data channels do not use redundant
transmission of text. The reason for this is that the T.140 data channel achieves
robust transmission by using the "reliable" mode of the data channel.
Data sending and reporting procedures conform to .
See Section 8 of for coding details.
NOTE: The T.140 coding details contain information on optional control
codes for controlling the presentation which may not be supported by the
presentation level of the receiving application. The receiving application
is expected to handle reception of such T.140 control codes appropriately
(e.g. ignore and skip them) even if their effect on the presentation is not supported.
As described in , buffering can be used to reduce
overhead, with the maximum buffering time being 500 ms. It can also be used for
staying within the maximum character transmission rate (),
if such has been provided by the peer.
An implementation needs to take the user requirements for smooth flow and low
latency in real-time text conversation into consideration when assigning a buffer time.
It is RECOMMENDED to use the default transmission interval of 300 milliseconds
, or lower, for T.140 data channels.
In case of network failure or congestion, T.140 data channels might fail and get torn down.
If this happens but the session sustains, it is RECOMMENDED that a low number of
retries are made to reestablish the T.140 data channels. If reestablishment of
the T.140 data channel is successful, an implementation MUST evaluate if any
T140blocks were lost. Retransmission of already successfully transmitted T140blocks MUST be
avoided, and missing text markers SHOULD be inserted in the received
data stream where loss is detected or suspected.
NOTE: If the SCTP association used to realize the T.140 data channel
fails and get torn down, it needs to be re-established before the T.140 data channel can be
reestablished. The procedure after the reestablishment of the T.140 data channel defined in
this section apply no matter if only the T.140 data channel, or the whole SCTP association,
got torn down.
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
communicate via a centralized conference server. The reason is that, unlike RTP media,
WebRTC data channels and the T.140 protocol do not support the indication of the source
of T.140 data. The SDP 'dcmap' attribute label attribute parameter ()
can be used by the offerer to provide additional information about each T.140 data channel, and help
implementations to distinguish between them.
NOTE: Future extensions to T.140, or to the T140block, might allow indicating 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 e.g., include human readable text
labels in the real-time text stream that indicates the source whenever the conference server
switches the source. This would allow the receiver to present real-time text from different
sources separated. The procedures of such mechanism is outside the scope of this document.
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 on application and presentation level .
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 . While this document
does not define a complete interworking solution, this 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 .
Redundancy is by default declared and used on RTP stream. On the T.140 data channel
there is no redundancy, but the reliable property
of T.140 the data channel is set.
During a normal text flow, T140blocks received from one network are forwarded towards the other network.
Keep-alive traffic is implicit on the T.140 data channel. A gateway might have to extract keep-alives from
incoming RTP streams, and MAY generate keep-alives 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 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 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 due to the data channel failure.
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 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 () on the T.140 data channel
and the RTP stream.
NOTE: In order for the gateway to insert a missing text marker, or to perform other actions that require that the
gateway has 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.
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 security considerations for WebRTC data channels
are defined in . As data channels
are always encrypted by design, the T.140 data channels will
also be encrypted.
The generic security considerations for the SDP-based external
negotiation method are defined in .
There are no additional T.140 data channel specific security considerations.
[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the RFC number of this document.]
This document adds the subprotocol identifier "t140" to the "WebSocket Subprotocol Name Registry" as follows:
Subprotocol Identifier:t140Subprotocol Common Name:ITU-T T.140Subprotocol Definition:RFCXXXXReference:RFCXXXX
This document modifies the usage of the SDP 'fmtp' attribute, if this attribute is
included in an SDP 'dcsa' attribute and associated with an T.140 real-time text session
over a WebRTC data channel. The modified usage is described in .
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'fmtp' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:fmtpUsage level:dcsa(t140)Purpose:
Indicate the maximum transmission rate that an endpoint is willing to receive on a T.140 data channel.
Reference:RFCXXXX
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 an T.140 data channel.
The modified usage is described in .
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'hlang-send' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:hlang-sendUsage level:dcsa(t140)Purpose:
Negotiate the language to be used on a T.140 data channel.
Reference:RFCXXXX
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'hlang-recv' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:hlang-recvUsage level:dcsa(t140)Purpose:
Negotiate the language to be used on a T.140 data channel.
Reference:RFCXXXX
This document modifies the usage of the SDP 'sendonly', 'recvonly', 'sendrecv' and 'inactive' attributes,
if these attributes are included in SDP 'dcsa' attributes associated T.140 data channel. The modified usage
is described in .
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'sendonly' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:sendonlyUsage level:dcsa(t140)Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:RFCXXXX
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'recvonly' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:recvonlyUsage level:dcsa(t140)Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:RFCXXXX
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'sendrecv' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:sendrecvUsage level:dcsa(t140)Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:RFCXXXX
The usage level "dcsa(t140)" is added to the IANA registration of the SDP 'inactive' attribute as follows:
Contact name:IESGContact email:iesg@ietf.orgAttribute name:inactiveUsage level:dcsa(t140)Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:RFCXXXX
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 draft. Gunnar Hellstrom provided comments and text on the draft. Paul
Kyzivat and Bernard Aboba provided comments on the draft.
Recommendation ITU-T T.140 (02/1998), Protocol for
multimedia application text conversationITU-TRecommendation ITU-T.140 Addendum 1 - (02/2000), Protocol for
multimedia application text conversationITU-T