draft-ietf-mmusic-t140-usage-data-channel-06.txt   draft-ietf-mmusic-t140-usage-data-channel-07.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: RFC8373 (if approved) September 30, 2019 Updates: RFC8373 (if approved) October 17, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: April 2, 2020 Expires: April 19, 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-06 draft-ietf-mmusic-t140-usage-data-channel-07
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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 2, 2020. This Internet-Draft will expire on April 19, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . 14
9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 14 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15
9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 15 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . 18 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 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) [RFC4103]. 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 1: This WebRTC term of a "T.140 data channel" is actually
synonym to the originally introduced concept of a "T.140 data synonym to the originally introduced concept of a "T.140 data
channel" for the T.140 protocol, see Section 4.3 of [T140]. channel" for the T.140 protocol, see Section 4.3 of [T140].
NOTE 2: The decision to transport realtime text over a data channel, NOTE 2: The decision to transport real-time text over a data channel,
instead of using RTP based transport [RFC4103], in WebRTC is instead of using RTP based transport [RFC4103], in WebRTC is
constituted by use-case "U-C 5: Realtime text chat during an audio 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 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]. 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
skipping to change at page 4, line 17 skipping to change at page 4, line 17
| Transmission reliability | reliable | | Transmission reliability | reliable |
| Transmission order | in-order | | Transmission order | in-order |
| Label | See Section 4.1 and Section 6 | | Label | See Section 4.1 and Section 6 |
+--------------------------+-------------------------------+ +--------------------------+-------------------------------+
NOTE: T.140 requires the transport channel to provide transmission of NOTE: T.140 requires the transport channel to provide transmission of
real-time text without duplication and in original order. Therefore, real-time text without duplication and in original order. Therefore,
T.140 does not specify reliable and ordered transmission of T.140 T.140 does not specify reliable and ordered transmission of T.140
data on the application layer. Instead, when RTP based transport is data on the application layer. Instead, when RTP based transport is
used, the RTP sequence number is used to detect packet loss and out- used, the RTP sequence number is used to detect packet loss and out-
of-order packets, and a redundancy mechanism using the RTP timestamp of-order packets, and a redundancy mechanism is used to achieve
is used to achieve reliable delivery of T.140 data. By using the reliable delivery of T.140 data. By using the WebRTC data channel
WebRTC data channel reliable and in-order transmission features reliable and in-order transmission features
[I-D.ietf-rtcweb-data-channel] for the T.140 data channel, there is [I-D.ietf-rtcweb-data-channel] for the T.140 data channel, there is
no need for a redundancy mechanism or a mechanism to detect data loss no need for a redundancy mechanism or a mechanism to detect data loss
and out-of-order delivery on the application level. The latency and out-of-order delivery on the application level. The latency
characteristics of the T.140 data channel is also regarded to be characteristics of the T.140 data channel is also regarded to be
sufficient to meet the application requirements of T.140. sufficient to meet the application requirements of T.140.
4. SDP Considerations 4. SDP Considerations
The generic SDP considerations, including the SDP Offer/Answer The generic SDP considerations, including the SDP Offer/Answer
procedures, for negotiating a WebRTC data channel are defined in procedures, for negotiating a WebRTC data channel are defined in
[I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP
considerations that are specific to a T.140 data channel. considerations that are specific to a T.140 data channel.
4.1. Use of dcmap Attribute 4.1. Use of dcmap Attribute
An offerer and answerer MUST, in each offer and answer, include an An offerer and answerer MUST, in each offer and answer, include an
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 descripton (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. If
the offerer includes a label attribute parameter, the answerer MUST the offerer includes a label attribute parameter, the answerer MUST
NOT change the value in the answer. 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 negotied 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 and max-time
attribute parameters in the 'dcmap' attribute. attribute parameters in the 'dcmap' attribute.
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 an SDP An offerer and answerer MAY, in each offer and answer, include one or
'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m= more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in
section describing the SCTP association used to realize the T.140 the m= section describing the SCTP association used to realize the
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 [I-D.ietf-mmusic-data-channel-sdpneg]. following the rules in Section 6.7 of
[I-D.ietf-mmusic-data-channel-sdpneg].
4.2.1. Maximum Character Transmission Rate 4.2.1. Maximum Character Transmission Rate
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.
skipping to change at page 6, line 37 skipping to change at page 6, line 40
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. An offerer and answerer MUST mark no impact on a T.140 data channel.
the direction of the text by sending a direction attribute inside
'dcsa' attribute.
4.2.3.1. Negotiate Text Direction 4.2.3.1. Negotiate Text Direction
4.2.3.1.1. Generating an Offer 4.2.3.1.1. Generating an Offer
If the offerer wishes to both send or 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,
skipping to change at page 7, line 23 skipping to change at page 7, line 23
If the offerer wishes to neither send or receive text on a T.140 data If the offerer wishes to neither send or receive text on a T.140 data
channel, it MUST mark the data channel as inactive with a 'inactive' channel, it MUST mark the data channel as inactive with a 'inactive'
attribute inside a 'dcsa' attribute. 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 When the offerer receives an answer to the offer, if the answerer has
marked a data channel as sendrecv (implicit or explicit) or recvonly marked a data channel as sendrecv (implicit or explicit) or recvonly
in the answer, the offerer can start to send T.140 data as soon as 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 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 marked the data channel as inactive or sendonly, the offerer MUST NOT
send any T.140 data. send any T.140 data.
As the answerer implementation might not support the procedures in As the answerer implementation might not support the procedures in
this section, if the answerer has not marked the direction of a T.140 this section, if the answerer has not marked the direction of a T.140
data channel in accordance with the procedures above, it is data channel in accordance with the procedures above, it is
RECOMMENDED that the offerer does not process that as an error RECOMMENDED that the offerer does not process that as an error
situation, but rather assume that the answerer might both send and situation, but rather assume that the answerer might both send and
receive T.140 data on the data channel. receive T.140 data on the data channel.
4.2.3.1.2. Generating an Answer 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
sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', (implicitly or explicitly), sendonly, recvonly or inactive with a
'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute
If the answerer does not explicitly mark the data channel, a inside a 'dcsa' attribute.
'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied.
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
skipping to change at page 9, line 11 skipping to change at page 9, line 11
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", apply.
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:1 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:1 fmtp:- cps=20 a=dcsa:2 fmtp:- cps=20
a=dcsa:1 hlang-send:es eo a=dcsa:2 hlang-send:es eo
a=dcsa:1 hlang-recv:es eo a=dcsa:2 hlang-recv:es eo
Answer: Answer:
m=application 911 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 5000 a=sctp-port 6000
a=dcmap:1 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:1 fmtp:- cps=20 a=dcsa:2 fmtp:- cps=20
a=dcsa:1 hlang-send:eo a=dcsa:2 hlang-send:eo
a=dcsa:1 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 language to be used for the real-time text rate is indicated. No preference for the language to be used for the
conversation is indicated. real-time text conversation is indicated.
Offer: Offer:
m=application 911 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=dcmap:1 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:1 recvonly a=dcsa:2 recvonly
Answer: Answer:
m=application 911 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 5000 a=sctp-port 6000
a=dcmap:1 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:1 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 high-level and a signalling protocol independent manner. functions at high-level and a signalling protocol independent manner.
The list below describes how the functions are realized when using a The list below describes how the functions are realized when using a
T.140 data channel. T.140 data channel.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
[I-D.ietf-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
o Data: Data sent on an established T.140 data channel (Section 5.2) o Data: Data sent on an established T.140 data channel (Section 5.2)
5.2. Data Encoding and Sending 5.2. Data Encoding and Sending
T.140 text is encoded and framed as T140blocks [RFC4103]. T.140 text is encoded and framed as T140blocks [RFC4103].
Each T140block is sent on the SCTP stream [RFC4960] used to realize Each T140block is sent on the SCTP stream [RFC4960] used to realize
the T.140 data channel using standard T.140 transmission procedures the T.140 data channel using standard T.140 transmission procedures
[T140]. One or more T140blocks can be sent in a single SCTP user [T140]. One or more T140blocks can be sent in a single SCTP user
message [RFC4960]. Unlike RTP based transport for realtime text message [RFC4960]. Unlike RTP based transport for real-time text
[RFC4103], T.140 data channels do not use redundant transmission of [RFC4103], T.140 data channels do not use redundant transmission of
text. The reason for this is that the T.140 data channel achieves text. The reason for this is that the T.140 data channel achieves
robust transmission by using the "reliable" mode of the data channel. robust transmission by using the "reliable" mode of the data channel.
Data sending and reporting procedures conform to [T140]. Data sending and reporting procedures conform to [T140].
See Section 8 of [T140] for coding details. See Section 8 of [T140] 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.
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 buffering time being 500 ms. It can also be used
for staying within the maximum character transmission rate for staying within the maximum character transmission rate
(Section 4.2), if such has been provided by the peer. (Section 4.2), if such has been provided by the peer.
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 buffer time. It is RECOMMENDED to use the default
skipping to change at page 13, line 18 skipping to change at page 13, line 24
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] the gateway SHOULD insert the T.140 missing text marker [T140ad1]
in the data sent on the outgoing T.140 data channel. 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 on the T.140 data channel was lost. that data sent by the remote T.140 data channel endpoint was lost
due to the data channel failure.
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
gateway SHOULD insert the T.140 missing text marker [T140ad1] in
the data sent on the outgoing T.140 data channel if it detects or
suspects that data sent or to be sent on the T.140 data channel
was lost during the failure.
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, a mechanism to provide such end-to-end
encryption has not been defined. encryption has not been defined.
7. Update to RFC 8373 7. Update to RFC 8373
This document updates RFC 8373, by defining how the SDP hlang-send This document updates RFC 8373 [RFC8373], by defining how the SDP
and hlang-recv attributes are used for the "application/webrtc- hlang-send and hlang-recv attributes are used for the "application/
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 retreive
the modality if the subprotocol supports multiple modalities. the modality if the subprotocol supports multiple modalities.
8. Security Considerations 8. Security Considerations
skipping to change at page 18, line 27 skipping to change at page 18, line 45
conversation"", February 2000. conversation"", 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.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data- Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015. protocol-09 (work in progress), January 2015.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
 End of changes. 32 change blocks. 
56 lines changed or deleted 73 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/