T.140 Real-Time Text Conversation over WebRTC Data Channels
updates
- rfc-8373 — Negotiating Human Language in Real-Time Communications
Extracted elements (27)
Session-level SDP direction attributes have no impact on T.140 data channels; direction is instead negotiated per-channel via 'dcsa' attributes. This is necessary because a WebRTC data channel is always bidirectional at the transport layer, so direction restrictions must be applied at the application level.
The 'hlang-send' and 'hlang-recv' attributes (RFC 8373) are placed in 'dcsa' rather than directly in the 'm=' section because they need to be scoped to individual data channels, not the entire SCTP association. A subprotocol specification must define the modality, which for T.140 is 'written'.
Using WebRTC data channels' built-in reliable and in-order transmission eliminates the need for the RTP-level redundancy mechanism and application-layer loss/reorder detection that RFC 4103 requires. The latency characteristics of WebRTC data channels are considered sufficient for T.140's real-time text requirements.
Multi-party T.140 scenarios require one T.140 data channel per remote party because neither WebRTC data channels nor the T.140 protocol support source indication within a single channel. The 'label' attribute in 'dcmap' can help implementations distinguish between channels.
When a gateway interworks between T.140 data channels and RTP-based T.140 transport: redundancy is used on the RTP stream but not on the data channel; keepalives are handled at lower layers on the data channel but may need to be extracted or generated on the RTP side; and missing text markers should be inserted whenever data loss is detected in either direction.
A gateway performing interworking between T.140 data channels and RTP-based T.140 transport MUST indicate the same text transmission direction on both the T.140 data channel and the RTP stream.
After a T.140 data channel failure and reestablishment, the sending endpoint MUST NOT retransmit T140blocks, as the channel provides no mechanism for the receiver to identify retransmitted blocks. The receiver SHOULD indicate to the user that text may have been lost, for example by inserting missing text markers.
An offerer and answerer MUST include the SDP 'dcmap' attribute in each offer and answer, with the 'subprotocol' attribute parameter set to 't140', in the 'm=' section describing the SCTP association used to realize the T.140 data channel.
An offerer wishing to only send text MUST mark the data channel as 'sendonly'; to only receive, it MUST mark it 'recvonly'; to neither send nor receive, it MUST mark it 'inactive'. If marked sendrecv or not explicitly marked, the endpoint MUST be prepared to receive T.140 data as soon as the channel allows it.
If an endpoint receives text at a higher rate than it can handle and the sending endpoint does not support 'cps', the receiver SHOULD either signal unwillingness to receive more text via direction attributes, or use flow control to reduce the rate. In emergency services contexts, discarding overflow and inserting a loss marker may be more appropriate.
If an endpoint wishes to modify a previously negotiated text direction in an ongoing session, it MUST initiate an offer indicating the new direction following the offer generation rules in Section 4.2.3.1.
If the 'ordered' attribute parameter is included in the 'dcmap' attribute, it MUST be assigned the value 'true', reflecting T.140's requirement for in-order delivery.
If the SDP 'fmtp' attribute is included in a 'dcsa' attribute for a T.140 data channel, the 'format' attribute parameter value MUST be set to 't140'. The 'cps' parameter indicates the maximum character transmission rate (characters per second, mean over any 10-second interval) the endpoint can receive; default is 30.
It is RECOMMENDED that implementations try to reestablish T.140 data channels if they fail due to network failure or congestion, provided the session itself is sustained.
It is RECOMMENDED to use a default transmission interval of 300 ms for T.140 data channels, with a maximum of 500 ms. Buffering MAY be used to reduce overhead or to stay within the maximum character transmission rate.
SDP offerers and answerers MUST NOT include the 'hlang-send' or 'hlang-recv' attributes directly in the 'm=' section for 'application/webrtc-datachannel'; they MUST instead be associated with individual data channels using the 'dcsa' attribute. This updates RFC 8373.
The offerer and answerer MUST NOT include the 'max-retr' or 'max-time' attribute parameters in the 'dcmap' attribute. If either parameter is received in an offer, the answerer MUST reject the offer; if received in an answer, the offerer MUST NOT accept it.
When the offerer marks a channel as sendonly, the answerer MUST mark it recvonly or inactive. When the offerer marks it recvonly, the answerer MUST mark it sendonly or inactive. When the offerer marks it inactive, the answerer MUST also mark it inactive.
A T.140 data channel is a WebRTC data channel with subprotocol identifier 't140', using reliable and in-order transmission, negotiated via the SDP offer/answer mechanism. These channel properties replace the redundancy and loss-detection mechanisms required by RTP-based T.140 transport.
The 'cps' attribute parameter in the SDP 'fmtp' attribute inside a 'dcsa' attribute indicates the maximum character transmission rate the endpoint can receive, expressed as a mean value in characters per second over any 10-second interval. The default value is 30 if not specified.
The SDP 'dcsa' attribute carries T.140-specific SDP attributes scoped to the individual data channel, including 'fmtp' for maximum character transmission rate, 'hlang-send'/'hlang-recv' for language negotiation, and 'sendonly'/'recvonly'/'sendrecv'/'inactive' for text direction.
The SDP 'hlang-send' and 'hlang-recv' attributes (from RFC 8373) can be included in 'dcsa' attributes to negotiate the language for real-time text conversation. For a T.140 data channel, the modality is 'written'.
The subprotocol identifier 't140' has been added to the IANA 'WebSocket Subprotocol Name Registry', identifying ITU-T T.140 Real-Time Text as the subprotocol, with RFC 8865 as the defining reference.
The usage level 'dcsa (t140)' has been added to the registrations of the SDP 'sendonly', 'recvonly', 'sendrecv', and 'inactive' attributes in the 'Session Description Protocol (SDP) Parameters' registry, covering their use to negotiate real-time text direction on T.140 data channels.
T.140 data channels inherit WebRTC's always-on encryption by design, providing confidentiality for real-time text. No additional security considerations specific to T.140 data channels are defined beyond those in RFC 8826, RFC 8827, and RFC 8864.
When a gateway interworks between T.140 data channels and RTP-based transport, the T.140 data cannot be encrypted end-to-end between the data channel endpoint and the RTP endpoint, because the gateway requires access to plaintext T.140 data to insert missing text markers and perform other actions.
T.140 text is encoded and framed as T140blocks as defined in RFC 4103. One or more T140blocks can be sent in a single SCTP user message. Unlike RTP-based transport, no redundant transmission is used because the data channel's 'reliable' mode provides robust delivery.