draft-ietf-mmusic-t140-usage-data-channel-11.txt   draft-ietf-mmusic-t140-usage-data-channel-12.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 8373 (if approved) December 19, 2019 Updates: 8373 (if approved) March 27, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: June 21, 2020 Expires: September 28, 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-11 draft-ietf-mmusic-t140-usage-data-channel-12
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. The negotiate such data channel, referred to as T.140 data channel. This
document updates RFC 8373. document updates RFC 8373 to specify its use with WebRTC data
channels.
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 June 21, 2020. This Internet-Draft will expire on September 28, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . 10
5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10
5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11
5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11
5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11
5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12
7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14
9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 14 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 15
9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15
9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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 transport used for conversation, also known as real-time text. The transport used 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 for data channels
[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 a
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: The decision to transport real-time text using a WebRTC data NOTE: The decision to transport real-time text using a WebRTC data
channel, instead of using RTP based transport [RFC4103], is motivated channel, instead of using RTP based transport [RFC4103], is motivated
by use-case "U-C 5: Real-time text chat during an audio and/or video 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 call with an individual or with multiple people in a conference", see
Section 3.2 of [I-D.ietf-rtcweb-data-channel]. Section 3.2 of [I-D.ietf-rtcweb-data-channel].
The brief notation "T.140" is used as a name for the text The brief notation "T.140" is used as a name for the text
conversation protocol according to [T140]. conversation protocol according to [T140].
Real-time text is intended to be entered by human users from a
keyboard, handwriting recognition, voice recognition or any other
input method. The rate of character entry is usually at a level of a
few characters per second or less.
Section 3 defines the generic data channel properties for a T.140 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
document can also be applied when a T.140 data channel is established document can also be applied when a T.140 data channel is established
using another mechanism (e.g., the mechanism defined in using another mechanism (e.g., the mechanism defined in
[I-D.ietf-rtcweb-data-protocol]). Section 5 of [I-D.ietf-rtcweb-data-protocol]). Section 5 of
[I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the
SDP dcmap attribute parameters and the protocol parameters used in SDP dcmap attribute parameters and the protocol parameters used in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
This document updates [RFC8373], by defining how the SDP hlang-send This document updates [RFC8373], by defining how the SDP hlang-send
and hlang-recv attributes are used for the "application/webrtc- and hlang-recv attributes are used for the "application/webrtc-
datachannel" media type. datachannel" media type.
This document is based on an earlier Internet draft edited by Keith
Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. WebRTC Data Channel Considerations 3. WebRTC Data Channel Considerations
skipping to change at page 4, line 46 skipping to change at page 4, line 51
SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the
SDP media description (m= section) [I-D.ietf-mmusic-rfc4566bis] SDP media description (m= section) [I-D.ietf-mmusic-rfc4566bis]
describing the SCTP association [RFC4960] used to realize the T.140 describing the SCTP association [RFC4960] used to realize the T.140
data channel. data channel.
The offerer and answerer MUST include the subprotocol attribute The offerer and answerer MUST include the subprotocol attribute
parameter, with a "t140" parameter value, in the 'dcmap' attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute
value. value.
The offerer and answerer MAY include the priority attribute parameter The offerer and answerer MAY include the priority attribute parameter
and the label attribute parameter in the 'dcmap' attribute value. If and the label attribute parameter in the 'dcmap' attribute value, as
the offerer includes a label attribute parameter, the answerer MUST specified in [I-D.ietf-mmusic-data-channel-sdpneg].
NOT change the value in the answer.
NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data
channel is negotiated using the mechanism defined in channel is negotiated using the mechanism defined in
[I-D.ietf-rtcweb-data-protocol], the label attribute parameter value [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value
has to be the same in both directions. That rule also applies to has to be the same in both directions. That rule also applies to
data channels negotiated using the mechanism defined in this data channels negotiated using the mechanism defined in this
document. document.
The offerer and answerer MUST NOT include the max-retr and max-time The offerer and answerer MUST NOT include the max-retr or the max-
attribute parameters in the 'dcmap' attribute. time attribute parameters in the 'dcmap' attribute. If any of the
attribute parameters is received in an offer, the answerer MUST
reject the offer. If any of the attribute parameters is received in
an answer the offerer MUST NOT accept the answer. Instead, the
answerer MUST take appropriate actions, e.g., by sending a new offer
without a T.140 data channel, or by terminating the session.
If the ordered attribute parameter is included in the 'dcmap' If the ordered attribute parameter is included in the 'dcmap'
attribute, it MUST be assigned the value 'true'. attribute, it MUST be assigned the value 'true'.
Below is an example of the 'dcmap' attribute for a T.140 data channel Below is an example of the 'dcmap' attribute for a T.140 data channel
with stream id=3 and without any label: with stream id=3 and without any label:
a=dcmap:3 subprotocol="t140" a=dcmap:3 subprotocol="t140"
4.2. Use of dcsa Attribute 4.2. Use of dcsa Attribute
An offerer and answerer MAY, in each offer and answer, include one or An offerer and answerer can, in each offer and answer, include one or
more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in
the m= section describing the SCTP association used to realize the the m= section describing the SCTP association used to realize the
T.140 data channel. T.140 data channel.
If an offerer or answerer receives a 'dcsa' attribute that contains 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 an SDP attribute which usage has not been defined for a T.140 data
channel, the offerer or answerer should ignore the 'dcsa' attribute, channel, the offerer or answerer should ignore the 'dcsa' attribute,
following the rules in Section 6.7 of following the rules in Section 6.7 of
[I-D.ietf-mmusic-data-channel-sdpneg]. [I-D.ietf-mmusic-data-channel-sdpneg].
skipping to change at page 5, line 44 skipping to change at page 6, line 5
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 "t140". MUST be set to "t140".
If the 'fmtp' attribute is not included, the default value of 30 If no 'fmtp' attribute with a 'cps' attribute parameter is included,
applies [RFC4103]. the 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 an 'fmtp' attribute that is not according to attribute that contains an 'fmtp' attribute that is not according to
the procedure above, the offerer or answerer MUST ignore the 'dcsa' the procedure above, the offerer or answerer MUST ignore 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.
If an endpoint receives text at a higher rate than it can handle,
e.g., because the sending endpoint does not support the 'cps'
attribute parameter, the receiving endpoint can indicate to the
sending endpoint that it is not willing to receive more text at the
moment, using the direction attributes (Section 4.2.3).
NOTE: At the time of writing this specification, the standardized API
for WebRTC data channels does not support flow control. Should such
be available at some point, a receiving endpoint might use it in
order to slow down the rate of text received from the sending
endpoint.
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
skipping to change at page 6, line 36 skipping to change at page 7, line 9
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. Generating an Offer 4.2.3.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, an implicit 'sendrecv' not explicitly mark the data channel, an implicit 'sendrecv'
attribute inside a 'dcsa' attribute is applied by default. attribute inside a 'dcsa' attribute is applied by default.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
Esperanto. The maximum character transmission rate is set to 20. As Esperanto. The maximum character transmission rate is set to 20. As
the offerer and answerer have not explicitly indicated the real-time the offerer and answerer have not explicitly indicated the real-time
text direction, the default direction "sendrecv" applies. text direction, the default 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=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20 a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:es eo a=dcsa:2 hlang-send:es eo
a=dcsa:2 hlang-recv:es eo a=dcsa:2 hlang-recv:es eo
Answer: Answer:
m=application 2004 UDP/DTLS/SCTP webrtc-datachannel m=application 2004 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 6000 a=sctp-port 6000
a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20 a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:eo a=dcsa:2 hlang-send:eo
a=dcsa:2 hlang-recv:eo a=dcsa:2 hlang-recv:eo
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 where the offerer wishes to only receive real-time text, and channel where the offerer wishes to only receive real-time text, and
an m= section in the associated answer indicating that the answerer an m= section in the associated answer indicating that the answerer
will only send real-time text. No maximum character transmission will only send real-time text. No maximum character transmission
rate is indicated. No preference for the language to be used for the rate is indicated. No preference for the language to be used for the
real-time text conversation is indicated. real-time text conversation is indicated.
Offer: Offer:
m=application 1400 UDP/DTLS/SCTP webrtc-datachannel m=application 1400 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=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 recvonly a=dcsa:2 recvonly
Answer: Answer:
m=application 2400 UDP/DTLS/SCTP webrtc-datachannel m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 6000 a=sctp-port 6000
a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 sendonly a=dcsa:2 sendonly
5. T.140 Considerations 5. T.140 Considerations
5.1. Session Layer Functions 5.1. Session Layer Functions
Section 6.1 of [T140] describes the generic T.140 session control Section 6.1 of [T140] describes the generic T.140 session control
functions at a high-level in a signalling protocol independent functions at a high-level in a signalling protocol independent
manner. The list below describes how the functions are realized when manner. The list below describes how the functions are realized when
skipping to change at page 11, line 31 skipping to change at page 11, line 31
NOTE: The T.140 coding details contain information on optional NOTE: The T.140 coding details contain information on optional
control codes for controlling the presentation which may not be control codes for controlling the presentation which may not be
supported by the presentation level of the receiving application. supported by the presentation level of the receiving application.
The receiving application is expected to handle reception of such The receiving application is expected to handle reception of such
T.140 control codes appropriately (e.g. ignore and skip them) even if T.140 control codes appropriately (e.g. ignore and skip them) even if
their effect on the presentation is not supported. their effect on the presentation is not supported.
5.3. Data Buffering 5.3. Data Buffering
As described in [T140], buffering can be used to reduce overhead, As described in [T140], buffering can be used to reduce overhead,
with the maximum buffering time being 500 ms. It can also be used with the maximum assigned transmission interval of T140blocks from
for staying within the maximum character transmission rate the buffer being 500 ms as long as there is text to send.
(Section 4.2), if such has been provided by the peer.
Buffering can also be used for staying within the maximum character
transmission rate (Section 4.2).
An implementation needs to take the user requirements for smooth flow An implementation needs to take the user requirements for smooth flow
and low latency in real-time text conversation into consideration and low latency in real-time text conversation into consideration
when assigning a buffer time. It is RECOMMENDED to use the default when assigning a transmission interval. It is RECOMMENDED to use the
transmission interval of 300 milliseconds [RFC4103], or lower, for default transmission interval of 300 milliseconds [RFC4103], for
T.140 data channels. T.140 data channels. Implementers MAY also use lower values, for
specific applications requiring low latency, taking the increased
overhead in consideration.
5.4. Loss of T140blocks 5.4. Loss of T140blocks
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 implementations tries to reestablish the T.140 is RECOMMENDED that implementations try to reestablish the T.140 data
data channels. If reestablishment of the T.140 data channel is channels. As a T.140 data channel does not provide a mechanism for
successful, an implementation MUST evaluate if any T140blocks were the receiver to identify retransmitted T140blocks after channel
lost. Retransmission of already successfully transmitted T140blocks reestablishment, the sending endpoint MUST NOT retransmit T140blocks
MUST be avoided, and missing text markers [T140ad1] SHOULD be unless it has strong indications that a T140block has been lost
inserted in the received data stream where loss is detected or during the data channel failure. Similarly, as a T.140 data channel
suspected. does not provide a mechanism for a receiver to detect lost T140blocks
during channel reestablishment, it MUST NOT insert missing text
markers [T140ad1] unless it has reasons to suspect that a T140block
might have been lost. Different mechanisms used by sending and
receiving endpoints to detect or suspect text loss are outside the
scope of this specification.
NOTE: If 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 gets torn down, it needs to be re-established data channel fails and gets 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 procedures
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
channels, one for each remote party. At the time of writing this channels, one for each remote party. At the time of writing this
document, this is true even in scenarios where each participant document, this is true even in scenarios where each participant
skipping to change at page 12, line 32 skipping to change at page 12, line 40
by the offerer to provide additional information about each T.140 by the offerer to provide additional information about each T.140
data channel, and help implementations to distinguish between them. data 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. The usage of a single T.140 data channel, multiple remote sources. The usage of a single T.140 data channel,
without any protocol extensions, would require the conference server without any protocol extensions, would require the conference server
to only forward real-time text from one source at any given time, and 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 e.g., include human readable text labels in the real-time text stream
that indicates the source whenever the conference server switches the that indicate the source whenever the conference server switches the
source. This would allow the receiver to present real-time text from source. This would allow the receiver to present real-time text from
different sources separated. The procedures of such mechanism is different sources separated. The procedures of such mechanism is
outside the scope of this document. 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
skipping to change at page 14, line 31 skipping to change at page 14, line 42
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:
+--------------------------+-------------+ +--------------------------+----------------------------+
| Subprotocol Identifier: | t140 | | Subprotocol Identifier: | t140 |
| Subprotocol Common Name: | ITU-T T.140 | | Subprotocol Common Name: | ITU-T T.140 Real-Time Text |
| Subprotocol Definition: | RFCXXXX | | Subprotocol Definition: | RFCXXXX |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+--------------------------+-------------+ +--------------------------+----------------------------+
9.2. SDP fmtp Attribute 9.2. SDP fmtp Attribute
This document defines the usage of the SDP 'fmtp' attribute, if this This document defines 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
usage is defined in Section 4.2.1. usage is defined 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: | IESG | | Contact name: | IESG |
| Contact email: | iesg@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 format parameters for a T.140 |
| | that an endpoint is willing to receive on | | | data channel, such as maximum character |
| | a T.140 data channel. | | | transmission rates. |
| 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.
 End of changes. 29 change blocks. 
48 lines changed or deleted 81 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/