idnits 2.17.1 draft-holmberg-mmusic-t140-usage-data-channel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 9, 2019) is 1694 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 5' is mentioned on line 167, but not defined == Unused Reference: 'RFC3264' is defined on line 303, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Possible downref: Non-RFC (?) normative reference: ref. 'T140' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track August 9, 2019 5 Expires: February 10, 2020 7 T.140 Text Conversation over WebRTC Data Channels 8 draft-holmberg-mmusic-t140-usage-data-channel-00 10 Abstract 12 This document specifies how a WebRTC data channel can be used as a 13 transport mechanism for the ITU-T Protocol for multimedia application 14 text conversation (Recommendation ITU-T T.140), and how the SDP 15 offer/answer mechanism can be used to negotiate such data channel, 16 referred to as T.140 data channel. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 10, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 3 56 3.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 4 57 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Session Layer Functions . . . . . . . . . . . . . . . . . 5 60 4.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 5 61 4.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 5 62 5. Gateway Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 9.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The ITU-T Protocol for multimedia application text conversation 74 (Recommendation ITU-T T.140) [T140] defines a protocol for text 75 conversation, also known as realtime text or text telephony. The 76 native transport for IP networks is based on the Real-time Transport 77 Protocol (RTP) [RFC4103]. 79 This document specifies how a WebRTC data channel 80 [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism 81 for T.140, and how the SDP offer/answer mechanism 82 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such 83 data channel. 85 In this document, a T.140 data channel refers to a WebRTC data 86 channel for which the instantiated sub-protocol is "t140", and where 87 the channel is negotiated using the SDP-based external negotiation 88 method [I-D.ietf-mmusic-data-channel-sdpneg]. 90 NOTE - This WebRTC term of a "T.140 data channel" is actually synonym 91 to the originally introduced concept of a "T.140 data channel"] for 92 the T.140 protocol back in 1998, see Section 4.3 of [T140]. 94 NOTE - The decision to transport realtime text over a data channel, 95 instead of using RTP based transport [RFC4103], in WebRTC is 96 constituted by use-case "U-C 5: Realtime text chat during an audio 97 and/or video call with an individual or with multiple people in a 98 conference", see Section 3.2 of [I-D.ietf-rtcweb-data-channel]. 100 The brief notation "T.140" is used as a synonym for the text 101 conversation protocol according to [T140]. 103 This document is based on an earlier Internet draft edited by Keith 104 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 106 2. Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. SDP Considerations 116 The generic SDP considerations, including the SDP Offer/Answer 117 proceudres, for negotiating a WebRTC data channel are defined in 118 [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP 119 considerations that are specific to a T.140 data channel. 121 3.1. Use of dcmap Attribute 123 An offerer and answerer MUST, in each offer and answer, include an 124 SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the 125 SDP media descripton (m= line) [RFC4566] describing the SCTP 126 association [RFC4960] used to realize the T.140 data channel. 128 The offerer and answerer MUST include the following attribute 129 parameters, and parameter values in the dcmap attribute: 131 o "label=" labelstring 132 o "subprotocol=" "t140" 134 The offerer and answerer MUST NOT include the max-retr, max-time and 135 ordered attribute parameters in the dcmap attribute. 137 The offerer and answerer MAY, based on local policy, include the 138 priority attribute parameter in the dcmap attribute value. 140 Below is an example of the dcmap attribute for an T.140 data channel 141 with stream=3 and without any label: 143 a=dcmap:3 subprotocol="t140" 145 3.2. Use of dcsa Attribute 147 An offerer and answerer MAY, in each offer and answer, include an SDP 148 'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP 149 media descripton (m= line) describing the SCTP association used to 150 realize the T.140 data channel. 152 If included, the 'dcsa' attribute contains the fmtp attribute used to 153 indicate a maximum character transmission rate [RFC4103]. The 'cps' 154 attribute parameter is used indicate the maximum character 155 transmission rate that the endpoint that includes the attribute is 156 able to handle. The 'format' attribute parameter is not used with 157 T.140 data channels, and MUST be set to "-". 159 If not included, it indicates that no maximum character transmission 160 rate is indicated. It does not mean that the default value of 30 161 applies [RFC4103]. 163 The offerer and answerer MAY modify the 'cpc' attribute parameter 164 value in subsequent offers and answers. 166 NOTE: The 'cps' attribute parameter is especially useful when a T.140 167 data channel endpoint is acting as a gateway [Section 5] and is 168 interworking with a T.140 transport mechanism that have restrictions 169 on how many characters can be sent per second. 171 Below is an example of the dcsa attribute for an T.140 data channel 172 with a 'cps' attribute parameter with a attribute parameter value of 173 20: 175 a=dcsa:1 fmtp:- cps=20 177 3.3. Example 179 Below is an example of an SDP media description (m= line) describing 180 an SCTP association used to realize a T.140 data channel. 182 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 183 c=IN IP6 2001:db8::3 184 a=max-message-size:1000 185 a=sctp-port 5000 186 a=dcmap:1 label="text conversation";subprotocol="t140" 187 a=dcsa:1 fmtp:- cps=20 189 4. T.140 Considerations 191 4.1. Session Layer Functions 193 Section 6.1 of [T140] describes the generic T.140 session control 194 functions at high-level and a signalling protocol independent manner. 195 The list below describes how the functions are realized when using a 196 T.140 data channel. 198 o Prepare session: An endpoint can indicate its support of T.140 199 data channels using signalling specific means (e.g., using SIP 200 OPTIONS [RFC3261]), or by indicating the support in an offer or 201 answer (Section 3) 202 o Initiate session: An offer used to request the establishment of a 203 T.140 data channel (Section 3) 204 o Accept session: An answer used to accept a request to establish a 205 T.140 data channel (Section 3) 206 o Deny session: An answer used to reject a request the establishment 207 of a T.140 data channel, using the generic procedures for 208 rejecting a data channel [I-D.ietf-mmusic-data-channel-sdpneg] 209 o Disconnect session: An offer or answer used to disable a 210 previously established T.140 data channel, using the generic 211 procedures for closing a data channel 212 [I-D.ietf-mmusic-data-channel-sdpneg] 213 o Data: Data sent on an established T.140 data channel (Section 4.2) 215 4.2. Data Encoding and Sending 217 T.140 text is encoded and framed as T140blocks [RFC4103]. 219 Each T140block is sent on the SCTP stream [RFC4960] used to realize 220 the T.140 data channel using standard T.140 transmission procedures 221 [T140]. One or more T140blocks can be sent in a single SCTP user 222 message [RFC4960]. Unlike RTP based transport for realtime text 223 [RFC4103], T.140 data channels do not use reduntant transmission of 224 text. 226 Data sending and reporting procedures conform to [T140]. 228 See Section 8 of [T140] for coding details. 230 4.3. Data Buffering 232 As described in [T140], buffering can be used to reduce overhead, 233 with the maximum buffering time being 500 ms. It can also be used 234 for staying within the maximum character transmission rate 235 (Section 3.2), if such has been provided by the peer. 237 5. Gateway Considerations 239 Multiple transport mechanisms have been defined for T.140 [T140], due 240 to the long history and usage of the service in legacy packet- 241 switched and circuit-switched networks. Some examples are listed 242 below: 244 o IP text telephony in text conversation mode [RFC4103] 245 o IP text telephony in text relay mode, also known as Text-over-IP 246 (ToIP) [V151] 247 o IP text telephony in text pass-through mode, also known as 248 Voiceband-over-IP (VBDoIP) [V152] 249 o PSTN text telephony 251 In addition to simply moving text between two transport mechanisms, a 252 gateway might have to perform procedures related to events like 253 inactivity of T.140 traffic, RTP packets received out of order and 254 loss of incoming RTP packets. 256 The detailed gateway procedures for interworking between T.140 over 257 data channel and other T.140 transport mechanisms are outside the 258 scope of this document. 260 6. Security Considerations 262 The generic security considerations for WebRTC data channels are 263 defined in [I-D.ietf-rtcweb-data-channel]. As data channels are 264 always encrypted by design, the T.140 data channels will also be 265 encrypted. 267 The generic security considerations for the SDP-based external 268 negotiation method are defined in 269 [I-D.ietf-mmusic-data-channel-sdpneg]. 271 7. IANA considerations 273 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 274 RFC number of this document.] 276 This document adds the subprotocol identifier "t140" to the 277 "WebSocket Subprotocol Name Registry" as follows: 279 +--------------------------+-------------+ 280 | Subprotocol Identifier: | t140 | 281 | Subprotocol Common Name: | ITU-T T.140 | 282 | Subprotocol Definition: | RFCXXXX | 283 | Reference: | RFCXXXX | 284 +--------------------------+-------------+ 286 8. Acknowledgements 288 This document is based on an earlier Internet draft edited by Keith 289 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 291 Thomas Belling provided useful comments on the initial (pre- 292 submission) version of the draft. 294 9. References 296 9.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, . 303 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 304 with Session Description Protocol (SDP)", RFC 3264, 305 DOI 10.17487/RFC3264, June 2002, . 308 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 309 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 310 . 312 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 313 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 314 July 2006, . 316 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 317 RFC 4960, DOI 10.17487/RFC4960, September 2007, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [I-D.ietf-rtcweb-data-channel] 325 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 326 Channels", draft-ietf-rtcweb-data-channel-13 (work in 327 progress), January 2015. 329 [I-D.ietf-mmusic-data-channel-sdpneg] 330 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 331 Even, "SDP-based Data Channel Negotiation", draft-ietf- 332 mmusic-data-channel-sdpneg-28 (work in progress), May 333 2019. 335 [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), "Protocol 336 for multimedia application text conversation"", February 337 1998. 339 9.2. Informative References 341 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 342 A., Peterson, J., Sparks, R., Handley, M., and E. 343 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 344 DOI 10.17487/RFC3261, June 2002, . 347 [V151] ITU-T, "Recommendation ITU-T V.151 (05/2006), "Procedures 348 for the end-to-end connection of analogue PSTN text 349 telephones over an IP network utilizing text relay"", May 350 2006. 352 [V152] ITU-T, "Recommendation ITU-T V.152 (09/2010), "Procedures 353 for supporting voice-band data over IP networks"", 354 September 2010. 356 Author's Address 358 Christer Holmberg 359 Ericsson 360 Hirsalantie 11 361 Jorvas 02420 362 Finland 364 Email: christer.holmberg@ericsson.com