draft-ietf-mmusic-t140-usage-data-channel-07.txt   draft-ietf-mmusic-t140-usage-data-channel-08.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: RFC8373 (if approved) October 17, 2019 Updates: 8373 (if approved) November 19, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: April 19, 2020 Expires: May 22, 2020
T.140 Real-time Text Conversation over WebRTC Data Channels T.140 Real-time Text Conversation over WebRTC Data Channels
draft-ietf-mmusic-t140-usage-data-channel-07 draft-ietf-mmusic-t140-usage-data-channel-08
Abstract Abstract
This document specifies how a WebRTC data channel can be used as a 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 transport mechanism for Real-time text using the ITU-T Protocol for
multimedia application text conversation (Recommendation ITU-T multimedia application text conversation (Recommendation ITU-T
T.140), and how the SDP offer/answer mechanism can be used to T.140), and how the SDP offer/answer mechanism can be used to
negotiate such data channel, referred to as T.140 data channel. negotiate such data channel, referred to as T.140 data channel. The
document updates RFC 8373.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2020. This Internet-Draft will expire on May 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3
4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4
4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4 4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4
4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5 4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5
4.2.1. Maximum Character Transmission Rate . . . . . . . . . 5 4.2.1. Maximum Character Transmission Rate . . . . . . . . . 5
4.2.2. Real-time Text Conversation Languages . . . . . . . . 6 4.2.2. Real-time Text Conversation Languages . . . . . . . . 6
4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 6 4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 6
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 10 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 9
5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 9
5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 10
5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 10
5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 10
5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 11
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 11
7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 13
9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 14 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 14
9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 14
9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The ITU-T Protocol for multimedia application text conversation The ITU-T Protocol for multimedia application text conversation
(Recommendation ITU-T T.140) [T140] defines a protocol for text (Recommendation ITU-T T.140) [T140] defines a protocol for text
conversation, also known as real-time text. The native transport for conversation, also known as real-time text. The native transport for
IP networks is the "RTP Payload for Text Conversation" [RFC4103] IP networks is the "RTP Payload for Text Conversation" [RFC4103]
mechanism, based on the Real-time Transport Protocol (RTP) [RFC3550]. mechanism, based on the Real-time Transport Protocol (RTP) [RFC3550].
This document specifies how a WebRTC data channel This document specifies how a WebRTC data channel
[I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism
for T.140, and how the SDP offer/answer mechanism for T.140, and how the SDP offer/answer mechanism
[I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such
data channel. data channel.
In this document, a T.140 data channel refers to a WebRTC data In this document, a T.140 data channel refers to a WebRTC data
channel for which the instantiated sub-protocol is "t140", and where channel for which the instantiated sub-protocol is "t140", and where
the channel is negotiated using the SDP-based external negotiation the channel is negotiated using the SDP-based external negotiation
method [I-D.ietf-mmusic-data-channel-sdpneg]. method [I-D.ietf-mmusic-data-channel-sdpneg].
NOTE 1: This WebRTC term of a "T.140 data channel" is actually NOTE: The decision to transport real-time text using a WebRTC data
synonym to the originally introduced concept of a "T.140 data channel, instead of using RTP based transport [RFC4103], is motivated
channel" for the T.140 protocol, see Section 4.3 of [T140]. 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
NOTE 2: The decision to transport real-time text over a data channel, Section 3.2 of [I-D.ietf-rtcweb-data-channel].
instead of using RTP based transport [RFC4103], in WebRTC is
constituted 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 [I-D.ietf-rtcweb-data-channel].
The brief notation "T.140" is used as a synonym for the text The brief notation "T.140" is used as a synonym for the text
conversation protocol according to [T140]. conversation protocol according to [T140].
Section 3 defines the generic data channel properties for a T.140 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 data channel, and Section 4 defines how they are conveyed in an SDP
dcmap attribute. While this document defines how to establish a dcmap attribute. While this document defines how to establish a
T.140 data channel using the SDP-based external negotiation method T.140 data channel using the SDP-based external negotiation method
[I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway
considerations defined in Section 3, Section 5 and Section 6 of this considerations defined in Section 3, Section 5 and Section 6 of this
skipping to change at page 5, line 44 skipping to change at page 5, line 44
A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to
indicate a maximum character transmission rate [RFC4103]. The 'cps' indicate a maximum character transmission rate [RFC4103]. The 'cps'
attribute parameter is used to indicate the maximum character attribute parameter is used to indicate the maximum character
transmission rate that the endpoint that includes the attribute is transmission rate that the endpoint that includes the attribute is
able to receive, and the value is used as a mean value in characters able to receive, and the value is used as a mean value in characters
per second over any 10-second interval. per second over any 10-second interval.
If the 'fmtp' attribute is included, the 'format' attribute parameter If the 'fmtp' attribute is included, the 'format' attribute parameter
MUST be set to "-". MUST be set to "-".
If the 'fmtp' attribute is not included, it indicates that no maximum If the 'fmtp' attribute is not included, the default value of 30
character transmission rate is indicated. It does not mean that the applies [RFC4103].
default value of 30 applies [RFC4103].
The offerer and answerer MAY modify the 'cps' attribute parameter The offerer and answerer MAY modify the 'cps' attribute parameter
value in subsequent offers and answers. value in subsequent offers and answers.
This document does not define any other usage of the 'fmtp' attribute 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' for a T.140 channel. If an offerer or answerer receives a 'dcsa'
attribute that contains 'fmtp' attribute that is not according to the attribute that contains 'fmtp' attribute that is not according to the
procedure above the offerer or answerer MUST discard the 'dcsa' procedure above the offerer or answerer MUST discard the 'dcsa'
attribute. attribute.
NOTE: The 'cps' attribute parameter is especially useful when a T.140 NOTE: The 'cps' attribute parameter is especially useful when a T.140
data channel endpoint is acting as a gateway [Section 6] and is data channel endpoint is acting as a gateway (Section 6) and is
interworking with a T.140 transport mechanism that have restrictions interworking with a T.140 transport mechanism that have restrictions
on how many characters can be sent per second. on how many characters can be sent per second.
4.2.2. Real-time Text Conversation Languages 4.2.2. Real-time Text Conversation Languages
'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv'
attributes [RFC8373] to negotiate the language to be used for the attributes [RFC8373] to negotiate the language to be used for the
real-time text conversation. real-time text conversation.
For a T.140 data channel, the modality is "written" [RFC8373]. For a T.140 data channel, the modality is "written" [RFC8373].
4.2.3. Real-time Text Direction 4.2.3. Real-time Text Direction
'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly',
'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to 'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to
negotite the direction in which text can be transmitted in a real- negotiate the direction in which text can be transmitted in a real-
time text conversation. time text conversation.
NOTE: A WebRTC data channel is always bi-directional. The usage of NOTE: A WebRTC data channel is always bi-directional. The usage of
the 'dcsa' attribute only affects the direction in which the 'dcsa' attribute only affects the direction in which
implementations are allowed to transmit text on a T.140 data channel. implementations are allowed to transmit text on a T.140 data channel.
The offer/answer rules for the direction attributes are based on the The offer/answer rules for the direction attributes are based on the
rules for unicast streams defined in [RFC3264], as described below. rules for unicast streams defined in [RFC3264], as described below.
Note that the rules only apply to the direction attributes. Note that the rules only apply to the direction attributes.
Session level direction attributes [I-D.ietf-mmusic-rfc4566bis] have Session level direction attributes [I-D.ietf-mmusic-rfc4566bis] have
no impact on a T.140 data channel. no impact on a T.140 data channel.
4.2.3.1. Negotiate Text Direction 4.2.3.1. Generating an Offer
4.2.3.1.1. Generating an Offer
If the offerer wishes to both send and receive text on a T.140 data 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 channel, it SHOULD mark the data channel as sendrecv with a
'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does
not explicitly mark the data channel, a 'sendrecv' attribute inside a not explicitly mark the data channel, a 'sendrecv' attribute inside a
'dcsa' attribute is implicitly applied. 'dcsa' attribute is implicitly applied.
If the offerer wishes to only send text on a T.140 data channel, it 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 MUST mark the data channel as sendonly with a 'sendonly' attribute
inside a 'dcsa' attribute. inside a 'dcsa' attribute.
If the offerer wishes to only receive text on a T.140 data channel, 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 it MUST mark the data channel as recvonly with a 'recvonly' attribute
inside a 'dcsa' attribute. inside a 'dcsa' attribute.
If the offerer wishes to neither send or receive text on a T.140 data If the offerer wishes to neither send nor receive text on a T.140
channel, it MUST mark the data channel as inactive with a 'inactive' data channel, it MUST mark the data channel as inactive with an
attribute inside a 'dcsa' attribute. 'inactive' attribute inside a 'dcsa' attribute.
If the offerer has marked a data channel as sendrecv (implicit or 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 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. soon as the state of the T.140 data channel allows it.
When the offerer receives an answer to the offer, if the answerer has 4.2.3.2. Generating an Answer
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 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.
4.2.3.1.2. Generating an Answer
When the answerer accepts an offer, and marks the direction of the When the answerer accepts an offer, and marks the direction of the
text in the corresponding answer, the marking is based on the marking text in the corresponding answer, the marking is based on the marking
(explicit or implicit) in the offer. (explicit or implicit) in the offer.
If the offerer marked the data channel as sendrecv (implicitly or If the offerer marked the data channel as sendrecv (implicitly or
explicitly), the answerer MUST mark the data channel as sendrecv explicitly), the answerer MUST mark the data channel as sendrecv
(implicitly or explicitly), sendonly, recvonly or inactive with a (implicitly or explicitly), sendonly, recvonly or inactive with a
'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute
inside a 'dcsa' attribute. inside a 'dcsa' attribute.
If the offerer marked the data channel as sendonly, the answerer MUST If the offerer marked the data channel as sendonly, the answerer MUST
mark the data channel as recvonly or inactive with a 'recvonly' mark the data channel as recvonly or inactive with a 'recvonly'
respective 'inactive' attribute inside a 'dcsa' attribute. respective 'inactive' attribute inside a 'dcsa' attribute.
If the offerer marked the data channel as recvonly, the answerer MUST If the offerer marked the data channel as recvonly, the answerer MUST
mark the data channel as sendonly or inactive with a 'sendonly' mark the data channel as sendonly or inactive with a 'sendonly'
respective 'inactive' attribute inside a 'dcsa' attribute. respective 'inactive' attribute inside a 'dcsa' attribute.
If the offerer marked the data channel as inactive, the answerer MUST If the offerer marked the data channel as inactive, the answerer MUST
mark the data channel as inactive with a 'inactive' attribute inside mark the data channel as inactive with an 'inactive' attribute inside
a 'dcsa' attribute. a 'dcsa' attribute.
If the answerer has marked a data channel as sendrecv or recvonly, it 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 MUST be prepared to receive data as soon as the state of the T.140
data channel allows transmission of data. data channel allows transmission of data.
4.2.3.2. Modify Text Direction 4.2.3.3. Offerer Receiving an Answer
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.
4.2.3.4. Modify Text Direction
If an endpoint wishes to modify a previously negotiated text If an endpoint wishes to modify a previously negotiated text
direction in an ongoing session, it MUST initiate an offer that direction in an ongoing session, it MUST initiate an offer that
indicates the new direction, following the rules in indicates the new direction, following the rules in Section 4.2.3.1.
Section 4.2.3.1.1. If the answerer accepts the offer it follows the If the answerer accepts the offer it follows the procedures in
procedures in Section 4.2.3.1.2. Section 4.2.3.2.
4.3. Examples 4.3. Examples
Below is an example of an m= section of an offer for a T.140 data 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 channel offering real-time text conversation in Spanish and
Esperanto, and an m= section in the associated answer accepting Esperanto, and an m= section in the associated answer accepting
Esperanto. The maximum character transmission rate is set to 20, and Esperanto. The maximum character transmission rate is set to 20 and
the default text transmission direction "sendrecv", apply. the default text transmission direction "sendrecv" applies.
Offer: Offer:
m=application 911 UDP/DTLS/SCTP webrtc-datachannel m=application 911 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 5000 a=sctp-port 5000
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:- cps=20 a=dcsa:2 fmtp:- cps=20
a=dcsa:2 hlang-send:es eo a=dcsa:2 hlang-send:es eo
skipping to change at page 12, line 5 skipping to change at page 11, line 10
In case of network failure or congestion, T.140 data channels might 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 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 is RECOMMENDED that a low number of retries are made to reestablish
the T.140 data channels. If reestablishment of the T.140 data the T.140 data channels. If reestablishment of the T.140 data
channel is successful, an implementation MUST evaluate if any channel is successful, an implementation MUST evaluate if any
T140blocks were lost. Retransmission of already successfully T140blocks were lost. Retransmission of already successfully
transmitted T140blocks MUST be avoided, and missing text markers transmitted T140blocks MUST be avoided, and missing text markers
[T140ad1] SHOULD be inserted in the received data stream where loss [T140ad1] SHOULD be inserted in the received data stream where loss
is detected or suspected. is detected or suspected.
NOTE: If the the SCTP association [RFC4960] used to realize the T.140 NOTE: If the SCTP association [RFC4960] used to realize the T.140
data channel fails and get torn down, it needs to be re-established data channel fails and get torn down, it needs to be re-established
before the T.140 data channel can be reestablished. The procedure before the T.140 data channel can be reestablished. The procedure
after the reestablishment of the T.140 data channel defined in this 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 section apply no matter if only the T.140 data channel, or the whole
SCTP association, got torn down. SCTP association, got torn down.
5.5. Multi-party Considerations 5.5. Multi-party Considerations
If an implementation needs to support multi-party scenarios, the If an implementation needs to support multi-party scenarios, the
implementation needs to support multiple simultaneous T.140 data implementation needs to support multiple simultaneous T.140 data
skipping to change at page 12, line 28 skipping to change at page 11, line 33
communicate via a centralized conference server. The reason is that, communicate via a centralized conference server. The reason is that,
unlike RTP media, WebRTC data channels and the T.140 protocol do not 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' support the indication of the source of T.140 data. The SDP 'dcmap'
attribute label attribute parameter (Section 4.1) can be used by the attribute label attribute parameter (Section 4.1) can be used by the
offerer to provide additional information about each T.140 data offerer to provide additional information about each T.140 data
channel, and help implementations to distinguish between them. channel, and help implementations to distinguish between them.
NOTE: Future extensions to T.140, or to the T140block, might allow 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 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 possible to use a single T.140 data channel to transport data from
multiple remote sources. That is useful for multi-party aware multiple remote sources. The usage of a single T.140 data channel,
clients that are able present the conference in a way that is adapted without any protocol extensions, would require the conference server
to user expectations regarding presentation style and real-time to only forward real-time text from one source at any given time, and
performance. Conference mixers that use a single T.140 data channel e.g., include human readable text labels in the real-time text stream
to transmit real-time text towards clients might, without any that indicates the source whenever the conference server switches the
protocol extensions, produce a multi-party presentation completely source. This would allow the receiver to present real-time text from
within the text stream, and with limitations in real-time performance different sources separated. The procedures of such mechanism is
and presentation style. outside the scope of this document.
6. Gateway Considerations 6. Gateway Considerations
A number of real-time text transports and protocols have been defined A number of real-time text transports and protocols have been defined
for both packet switched and circuit switched networks. Many are for both packet-switched and circuit-switched networks. Many are
based on the ITU-T T.140 protocol on application and presentation based on the ITU-T T.140 protocol on application and presentation
level [T140]. At the time of writing this document, some mechanisms level [T140]. At the time of writing this document, some mechanisms
are no longer used, as the technologies they use have been obsoleted are no longer used, as the technologies they use have been obsoleted,
etc, while others are still in use. while others are still in use.
When performing interworking between T.140 data channels and real- When performing interworking between T.140 data channels and real-
time text in other transports and protocols, a number of factors need time text in other transports and protocols, a number of factors need
to be considered. At the time of writing this document, the most to be considered. At the time of writing this document, the most
common IP-based real-time text transport is the RTP based mechanism common IP-based real-time text transport is the RTP based mechanism
defined in [RFC4103]. While this document does not define a complete defined in [RFC4103]. While this document does not define a complete
interworking solution, this list below provides some guidance and interworking solution, this list below provides some guidance and
considerations to take into account when designing a gateway for considerations to take into account when designing a gateway for
interworking between T.140 data channels and RTP-based T.140 interworking between T.140 data channels and RTP-based T.140
transport: transport:
skipping to change at page 13, line 18 skipping to change at page 12, line 26
text [RFC4103] . Redundancy is by default declared and used on text [RFC4103] . Redundancy is by default declared and used on
RTP stream. On the T.140 data channel there is no redundancy, but RTP stream. On the T.140 data channel there is no redundancy, but
the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of
T.140 the data channel is set. T.140 the data channel is set.
o During a normal text flow, T140blocks received from one network o During a normal text flow, T140blocks received from one network
are forwarded towards the other network. Keep-alive traffic is are forwarded towards the other network. Keep-alive traffic is
implicit on the T.140 data channel. A gateway might have to implicit on the T.140 data channel. A gateway might have to
extract keep-alives from incoming RTP streams, and MAY generate extract keep-alives from incoming RTP streams, and MAY generate
keep-alives on outgoing RTP streams. keep-alives on outgoing RTP streams.
o If the gateway detects or suspects loss of data on the RTP stream, o If the gateway detects or suspects loss of data on the RTP stream,
the gateway SHOULD insert the T.140 missing text marker [T140ad1] and the lost data has not been retrieved using a redundancy
in the data sent on the outgoing T.140 data channel. mechanism, the gateway SHOULD insert the T.140 missing text marker
[T140ad1] in the data sent on the outgoing T.140 data channel.
o If the gateway detects that the T.140 data channel has failed and o If the gateway detects that the T.140 data channel has failed and
got torn down, once the data channel has been reestablished the got torn down, once the data channel has been reestablished the
gateway SHOULD insert the T.140 missing text marker [T140ad1] in gateway SHOULD insert the T.140 missing text marker [T140ad1] in
the data sent on the outgoing RTP stream if it detects or suspects 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 that data sent by the remote T.140 data channel endpoint was lost
due to the data channel failure. due to the data channel failure.
o If the gateway detects that the T.140 data channel has failed and o If the gateway detects that the T.140 data channel has failed and
got torn down, once the data channel has been reestablished the got torn down, once the data channel has been reestablished the
gateway SHOULD insert the T.140 missing text marker [T140ad1] in 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 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 suspects that data sent or to be sent on the T.140 data channel
was lost during the failure. was lost during the failure.
o The gateway MUST indicate the same text transmission direction o The gateway MUST indicate the same text transmission direction
(Section 4.2.3) on the T.140 data channel and the RTP stream. (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 to 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 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, 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 T.140 data channel endpoint and the RTP endpoint. At the time of
writing this document, a mechanism to provide such end-to-end writing this document, no mechanism to provide such end-to-end
encryption has not been defined. encryption is defined.
7. Update to RFC 8373 7. Update to RFC 8373
This document updates RFC 8373 [RFC8373], by defining how the SDP This document updates RFC 8373 [RFC8373], by defining how the SDP
hlang-send and hlang-recv attributes are used for the "application/ hlang-send and hlang-recv attributes are used for the "application/
webrtc-datachannel" media type. webrtc-datachannel" media type.
SDP offerers and answerers MUST NOT include the attributes directly SDP offerers and answerers MUST NOT include the attributes directly
in the m= section associated with the 'application/webrtc- in the m= section associated with the 'application/webrtc-
datachannel' media type. Instead, the attributes MUST be associated datachannel' media type. Instead, the attributes MUST be associated
with individual data channels, using the SDP 'dcsa' attribute. A with individual data channels, using the SDP 'dcsa' attribute. A
specification that defines a subprotocol that uses the attributes specification that defines a subprotocol that uses the attributes
MUST specify the modality for that subprotocol, or how to retreive MUST specify the modality for that subprotocol, or how to retrieve
the modality if the subprotocol supports multiple modalities. the modality if the subprotocol supports multiple modalities. The
subprotocol is indicated using the SDP 'dcmap' attribute.
8. Security Considerations 8. Security Considerations
The generic security considerations for WebRTC data channels are The generic security considerations for WebRTC data channels are
defined in [I-D.ietf-rtcweb-data-channel]. As data channels are defined in [I-D.ietf-rtcweb-data-channel]. As data channels are
always encrypted by design, the T.140 data channels will also be always encrypted by design, the T.140 data channels will also be
encrypted. encrypted.
The generic security considerations for the SDP-based external The generic security considerations for the SDP-based external
negotiation method are defined in negotiation method are defined in
[I-D.ietf-mmusic-data-channel-sdpneg]. [I-D.ietf-mmusic-data-channel-sdpneg]. There are no additional T.140
data channel specific security considerations.
9. IANA considerations 9. IANA considerations
[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the
RFC number of this document.] RFC number of this document.]
9.1. Subprotocol Identifier t140 9.1. Subprotocol Identifier t140
This document adds the subprotocol identifier "t140" to the This document adds the subprotocol identifier "t140" to the
"WebSocket Subprotocol Name Registry" as follows: "WebSocket Subprotocol Name Registry" as follows:
skipping to change at page 15, line 6 skipping to change at page 14, line 16
This document modifies the usage of the SDP 'fmtp' attribute, if this This document modifies the usage of the SDP 'fmtp' attribute, if this
attribute is included in an SDP 'dcsa' attribute and associated with attribute is included in an SDP 'dcsa' attribute and associated with
an T.140 real-time text session over a WebRTC data channel. The an T.140 real-time text session over a WebRTC data channel. The
modified usage is described in Section 4.2.1. modified usage is described in Section 4.2.1.
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'fmtp' attribute as follows: SDP 'fmtp' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | fmtp | | Attribute name: | fmtp |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Indicate the maximum transmission rate | | Purpose: | Indicate the maximum transmission rate |
| | that an endpoint is willing to recive on | | | that an endpoint is willing to receive on |
| | a T.140 data channel. | | | a T.140 data channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
9.3. SDP Language Attributes 9.3. SDP Language Attributes
This document modifies the usage of the SDP 'hlang-send' and 'hlang- This document modifies the usage of the SDP 'hlang-send' and 'hlang-
recv' attributes, if these attributes are included in SDP 'dcsa' recv' attributes, if these attributes are included in SDP 'dcsa'
attributes associated with an T.140 data channel. The modified usage attributes associated with an T.140 data channel. The modified usage
is described in Section 4.2.2. is described in Section 4.2.2.
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'hlang-send' attribute as follows: SDP 'hlang-send' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | hlang-send | | Attribute name: | hlang-send |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Negotiate the language to be used on a | | Purpose: | Negotiate the language to be used on a |
| | T.140 data channel. | | | T.140 data channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'hlang-recv' attribute as follows: SDP 'hlang-recv' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | hlang-recv | | Attribute name: | hlang-recv |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Negotiate the language to be used on a | | Purpose: | Negotiate the language to be used on a |
| | T.140 data channel. | | | T.140 data channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
9.4. SDP Media Direction Attributes 9.4. SDP Media Direction Attributes
This document modifies the usage of the SDP 'sendonly', 'recvonly', This document modifies the usage of the SDP 'sendonly', 'recvonly',
'sendrecv' and 'inactive' attributes, if these attributes are 'sendrecv' and 'inactive' attributes, if these attributes are
included in SDP 'dcsa' attributes associated T.140 data channel. The included in SDP 'dcsa' attributes associated T.140 data channel. The
modified usage is described in Section 4.2.3. modified usage is described in Section 4.2.3.
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'sendonly' attribute as follows: SDP 'sendonly' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | sendonly | | Attribute name: | sendonly |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Negotiate the direction in which real- | | Purpose: | Negotiate the direction in which real- |
| | time text can be sent on a T.140 data | | | time text can be sent on a T.140 data |
| | channel. | | | channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'recvonly' attribute as follows: SDP 'recvonly' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | recvonly | | Attribute name: | recvonly |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Negotiate the direction in which real- | | Purpose: | Negotiate the direction in which real- |
| | time text can be sent on a T.140 data | | | time text can be sent on a T.140 data |
| | channel. | | | channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'sendrecv' attribute as follows: SDP 'sendrecv' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | sendrecv | | Attribute name: | sendrecv |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Negotiate the direction in which real- | | Purpose: | Negotiate the direction in which real- |
| | time text can be sent on a T.140 data | | | time text can be sent on a T.140 data |
| | channel. | | | channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
The usage level "dcsa(t140)" is added to the IANA registration of the The usage level "dcsa(t140)" is added to the IANA registration of the
SDP 'inactive' attribute as follows: SDP 'inactive' attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | inactive | | Attribute name: | inactive |
| Usage level: | dcsa(t140) | | Usage level: | dcsa(t140) |
| Purpose: | Negotiate the direction in which real- | | Purpose: | Negotiate the direction in which real- |
| | time text can be sent on a T.140 data | | | time text can be sent on a T.140 data |
| | channel. | | | channel. |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
10. Acknowledgements 10. Acknowledgements
skipping to change at page 18, line 29 skipping to change at page 17, line 37
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[I-D.ietf-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
Even, "SDP-based Data Channel Negotiation", draft-ietf- Even, "SDP-based Data Channel Negotiation", draft-ietf-
mmusic-data-channel-sdpneg-28 (work in progress), May mmusic-data-channel-sdpneg-28 (work in progress), May
2019. 2019.
[T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), "Protocol [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), Protocol for
for multimedia application text conversation"", February multimedia application text conversation", February 1998.
1998.
[T140ad1] ITU-T, "Recommendation ITU-T.140 aEUR" Addendum 1 [T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 - (02/2000),
(02/2000), "Protocol for multimedia application text Protocol for multimedia application text conversation",
conversation"", February 2000. February 2000.
11.2. Informative References 11.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
 End of changes. 38 change blocks. 
104 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/