draft-ietf-mmusic-t140-usage-data-channel-05.txt   draft-ietf-mmusic-t140-usage-data-channel-06.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: RFC8373 (if approved) September 23, 2019 Updates: RFC8373 (if approved) September 30, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: March 26, 2020 Expires: April 2, 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-05 draft-ietf-mmusic-t140-usage-data-channel-06
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 March 26, 2020. This Internet-Draft will expire on April 2, 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . 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 . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 9 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 9 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10
5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 10 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11
5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 10 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11
5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 10 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11
5.5. Multi-party Considerations . . . . . . . . . . . . . . . 11 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 11 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12
7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 12 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 13 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14
9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 13 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 14
9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 13 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 14
9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 14 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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) [RFC4103]. mechanism, based on the Real-time Transport Protocol (RTP) [RFC4103].
This document specifies how a WebRTC data channel This document specifies how a WebRTC data channel
skipping to change at page 4, line 12 skipping to change at page 4, line 12
The following WebRTC data channel property values The following WebRTC data channel property values
[I-D.ietf-rtcweb-data-channel] apply to a T.140 data channel: [I-D.ietf-rtcweb-data-channel] apply to a T.140 data channel:
+--------------------------+-------------------------------+ +--------------------------+-------------------------------+
| Subprotocol Identifier | t140 | | Subprotocol Identifier | t140 |
| 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
real-time text without duplication and in original order. Therefore,
T.140 does not specify reliable and ordered transmission of T.140
data on the application layer. Instead, when RTP based transport is
used, the RTP sequence number is used to detect packet loss and out-
of-order packets, and a redundancy mechanism using the RTP timestamp
is used to achieve reliable delivery of T.140 data. By using the
WebRTC data channel reliable and in-order transmission features
[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
and out-of-order delivery on the application level. The latency
characteristics of the T.140 data channel is also regarded to be
sufficient to meet the application requirements of T.140.
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
skipping to change at page 5, line 12 skipping to change at page 5, line 26
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 an SDP
'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m= 'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m=
section describing the SCTP association used to realize the T.140 section describing the SCTP association used to realize the T.140
data channel. data channel.
If an offerer or answere receives a 'dcsa' attribute that contains an If an offerer or answerer receives a 'dcsa' attribute that contains
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 [I-D.ietf-mmusic-data-channel-sdpneg].
NOTE: At the time of writing this specification, the latest verion of 4.2.1. Maximum Character Transmission Rate
the API defined in [W3C.webrtc] does not support the use of the SDP
attributes defined in this section.
4.2.1. Maximum Character Transmission
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 "-".
skipping to change at page 12, line 12 skipping to change at page 13, line 12
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 gateway SHOULD insert the T.140 missing text marker the gateway SHOULD insert the T.140 missing text marker [T140ad1]
[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 on the T.140 data channel was lost.
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
skipping to change at page 16, line 7 skipping to change at page 17, line 7
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
10. Acknowledgements 10. Acknowledgements
This document is based on an earlier Internet draft edited by Keith This document is based on an earlier Internet draft edited by Keith
Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.
Thomas Belling provided useful comments on the initial (pre- Thomas Belling provided useful comments on the initial (pre-
submission) version of the draft. Gunnar Hellstrom provided comments submission) version of the draft. Gunnar Hellstrom provided comments
and text on the draft. Paul Kyzivat provides comments on the draft. and text on the draft. Paul Kyzivat and Bernard Aboba provided
comments on the draft.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
skipping to change at page 17, line 32 skipping to change at page 18, line 32
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>.
[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.
[W3C.webrtc]
Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A.,
Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time
Communication Between Browsers", World Wide Web Consortium
WD CR-webrtc-20180927, September 2018,
<https://www.w3.org/TR/2018/CR-webrtc-20180927>.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 12 change blocks. 
41 lines changed or deleted 45 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/