idnits 2.17.1 draft-holmberg-mmusic-t140-usage-data-channel-01.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 29, 2019) is 1702 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 182, but not defined == Unused Reference: 'RFC3264' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'V151' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'V152' is defined on line 487, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 Updates: RFC8373 (if approved) August 29, 2019 5 Intended status: Standards Track 6 Expires: March 1, 2020 8 T.140 Real-time Text Conversation over WebRTC Data Channels 9 draft-holmberg-mmusic-t140-usage-data-channel-01 11 Abstract 13 This document specifies how a WebRTC data channel can be used as a 14 transport mechanism for Real-time text using the ITU-T Protocol for 15 multimedia application text conversation (Recommendation ITU-T 16 T.140), and how the SDP offer/answer mechanism can be used to 17 negotiate such data channel, referred to as T.140 data channel. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 1, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 3 57 3.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 4 58 3.2.1. Maximum Character Transmission . . . . . . . . . . . 4 59 3.2.2. Real-time Text Conversation Languages . . . . . . . . 4 60 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Session Layer Functions . . . . . . . . . . . . . . . . . 6 63 4.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 6 64 4.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 6 65 4.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 7 66 4.5. Multi-party Considerations . . . . . . . . . . . . . . . 7 67 5. Gateway Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 9 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The ITU-T Protocol for multimedia application text conversation 80 (Recommendation ITU-T T.140) [T140] defines a protocol for text 81 conversation, also known as real-time text. The native transport for 82 IP networks is the "RTP Payload for Text Conversation" [RFC4103] 83 mechanism, based on the Real-time Transport Protocol (RTP) [RFC4103]. 85 This document specifies how a WebRTC data channel 86 [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism 87 for T.140, and how the SDP offer/answer mechanism 88 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such 89 data channel. 91 In this document, a T.140 data channel refers to a WebRTC data 92 channel for which the instantiated sub-protocol is "t140", and where 93 the channel is negotiated using the SDP-based external negotiation 94 method [I-D.ietf-mmusic-data-channel-sdpneg]. 96 NOTE 1: This WebRTC term of a "T.140 data channel" is actually 97 synonym to the originally introduced concept of a "T.140 data 98 channel" for the T.140 protocol, see Section 4.3 of [T140]. 100 NOTE 2: The decision to transport realtime text over a data channel, 101 instead of using RTP based transport [RFC4103], in WebRTC is 102 constituted by use-case "U-C 5: Realtime text chat during an audio 103 and/or video call with an individual or with multiple people in a 104 conference", see Section 3.2 of [I-D.ietf-rtcweb-data-channel]. 106 The brief notation "T.140" is used as a synonym for the text 107 conversation protocol according to [T140]. 109 This document is based on an earlier Internet draft edited by Keith 110 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 112 2. Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. SDP Considerations 122 The generic SDP considerations, including the SDP Offer/Answer 123 proceudres, for negotiating a WebRTC data channel are defined in 124 [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP 125 considerations that are specific to a T.140 data channel. 127 3.1. Use of dcmap Attribute 129 An offerer and answerer MUST, in each offer and answer, include an 130 SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the 131 SDP media descripton (m= section) [RFC4566] describing the SCTP 132 association [RFC4960] used to realize the T.140 data channel. 134 The offerer and answerer MUST include the subprotocol attribute 135 parameter, with a "t140" parameter value, in the 'dcmap' attribute 136 value. 138 The offerer and answerer MAY include the priority attribute parameter 139 and the label attribute parameter in the 'dcmap' attribute value. If 140 the offerer includes a label attribute parameter, the answerer MUST 141 NOT change the value in the answer. 143 NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data 144 channel is negotied using the mechanism defined in 145 [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value 146 has to be the same in both directions. That rule also applies also 147 to data channels negotiated using the mechanism defined in this 148 document. 150 The offerer and answerer MUST NOT include the max-retr, max-time and 151 ordered attribute parameters in the 'dcmap' attribute. 153 Below is an example of the 'dcmap' attribute for an T.140 data 154 channel with stream=3 and without any label: 156 a=dcmap:3 subprotocol="t140" 158 3.2. Use of dcsa Attribute 160 An offerer and answerer MAY, in each offer and answer, include an SDP 161 'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m= 162 section describing the SCTP association used to realize the T.140 163 data channel. 165 3.2.1. Maximum Character Transmission 167 A 'dcsa' attribute can contain the SDP fmtp attribute used to 168 indicate a maximum character transmission rate [RFC4103]. The 'cps' 169 attribute parameter is used indicate the maximum character 170 transmission rate that the endpoint that includes the attribute is 171 able to receive. The 'format' attribute parameter is not used with 172 T.140 data channels, and MUST be set to "-". 174 If the fmtp attribute is not included, it indicates that no maximum 175 character transmission rate is indicated. It does not mean that the 176 default value of 30 applies [RFC4103]. 178 The offerer and answerer MAY modify the 'cps' attribute parameter 179 value in subsequent offers and answers. 181 NOTE: The 'cps' attribute parameter is especially useful when a T.140 182 data channel endpoint is acting as a gateway [Section 5] and is 183 interworking with a T.140 transport mechanism that have restrictions 184 on how many characters can be sent per second. 186 3.2.2. Real-time Text Conversation Languages 188 'dcsa' attributes can contain the SDP hlang-send and hlang-recv 189 attributes [RFC8373] to negotiate the language to be used for the 190 real-time text conversation. 192 For a T.140 data channel, the modality is "written" [RFC8373]. 194 3.3. Examples 196 Below is an example of an m= section describing a T.140 data channel, 197 where the maximum character transmission rate is set to 20. 199 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 200 c=IN IP6 2001:db8::3 201 a=max-message-size:1000 202 a=sctp-port 5000 203 a=dcmap:1 label="text conversation";subprotocol="t140" 204 a=dcsa:1 fmtp:- cps=20 206 Below is an example of an m= section of an offer for a T.140 data 207 channel offering real-time text conversation in Spanish and 208 Esperanto, and an m= section in the associated answer accepting 209 Esperanto. 211 Offer: 213 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 214 c=IN IP6 2001:db8::3 215 a=max-message-size:1000 216 a=sctp-port 5000 217 a=dcmap:1 label="ACME customer service";subprotocol="t140" 218 a=dcsa:1 fmtp:- cps=30 219 a=dcsa:1 hlang-send:es eo 220 a=dcsa:1 hlang-recv:es eo 222 Answer: 224 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 225 c=IN IP6 2001:db8::1 226 a=max-message-size:1000 227 a=sctp-port 5000 228 a=dcmap:1 label="ACME customer service";subprotocol="t140" 229 a=dcsa:1 fmtp:- cps=30 230 a=dcsa:1 hlang-send:eo 231 a=dcsa:1 hlang-recv:eo 233 4. T.140 Considerations 235 4.1. Session Layer Functions 237 Section 6.1 of [T140] describes the generic T.140 session control 238 functions at high-level and a signalling protocol independent manner. 239 The list below describes how the functions are realized when using a 240 T.140 data channel. 242 o Prepare session: An endpoint can indicate its support of T.140 243 data channels using signalling specific means (e.g., using SIP 244 OPTIONS [RFC3261]), or by indicating the support in an offer or 245 answer (Section 3) 246 o Initiate session: An offer used to request the establishment of a 247 T.140 data channel (Section 3) 248 o Accept session: An answer used to accept a request to establish a 249 T.140 data channel (Section 3) 250 o Deny session: An answer used to reject a request to establish a 251 T.140 data channel, using the generic procedures for rejecting a 252 data channel [I-D.ietf-mmusic-data-channel-sdpneg] 253 o Disconnect session: An offer or answer used to disable a 254 previously established T.140 data channel, using the generic 255 procedures for closing a data channel 256 [I-D.ietf-mmusic-data-channel-sdpneg] 257 o Data: Data sent on an established T.140 data channel (Section 4.2) 259 4.2. Data Encoding and Sending 261 T.140 text is encoded and framed as T140blocks [RFC4103]. 263 Each T140block is sent on the SCTP stream [RFC4960] used to realize 264 the T.140 data channel using standard T.140 transmission procedures 265 [T140]. One or more T140blocks can be sent in a single SCTP user 266 message [RFC4960]. Unlike RTP based transport for realtime text 267 [RFC4103], T.140 data channels do not use redundant transmission of 268 text. 270 Data sending and reporting procedures conform to [T140]. 272 See Section 8 of [T140] for coding details. 274 4.3. Data Buffering 276 As described in [T140], buffering can be used to reduce overhead, 277 with the maximum buffering time being 500 ms. It can also be used 278 for staying within the maximum character transmission rate 279 (Section 3.2), if such has been provided by the peer. 281 An implementation needs to take the user requirements for smooth flow 282 and low latency in real-time text conversation into consideration 283 when assigning a buffer time. It is RECOMMENDED to use the default 284 transmission interval of 300 milliseconds [RFC4103], or lower, also 285 for T.140 data channels. 287 4.4. Loss of T140blocks 289 In case of network failure or congestion, T140 data channels might 290 fail and get torn down. If this happens but the session sustains, it 291 is RECOMMENDED that a low number of retries are made to reestablish 292 the T140 data channels. If reestablishment of the T140 data channel 293 is successful, an implementation MUST evaluate if any T140blocks were 294 lost. Retransmission of already transmitted T140blocks MUST be 295 avoided, and missing text markers [T140ad1] SHOULD be inserted in the 296 received data stream where loss is detected or suspected. 298 An implementation needs to take the user requirements for smooth flow 299 and low latency in real-time text conversation into consideration 300 when assigning a buffer time. It is RECOMMENDED to use the default 301 transmission interval of 300 milliseconds [RFC4103], or lower, also 302 for T.140 data channels. 304 4.5. Multi-party Considerations 306 If an implementation needs to support multi-party scenarios, the 307 implementation needs to support multiple simultaneous T.140 data 308 channels, one for each remote party. At the time of writing this 309 document, this is true even in scenarios where each participants 310 communicate via a centralized conference server. The reason is that, 311 unlike RTP media, WebRTC data channels and the T.140 protocol do not 312 support the indication of the source of T.140 data. The SDP 'dcmap' 313 attribute label attribute parameter (Section 3.1) can be used by the 314 offerer to provide additional information about each T.140 data 315 channel, and help implementations to distinguish between them. 317 NOTE: Future extensions to T.140, or to the T140block, might allow 318 indicating the source of T.140 data, in which case it might be 319 possible to use a single T.140 data channel to transport data from 320 multiple remote sources. 322 5. Gateway Considerations 324 A number of real-time text transports and protocols have been defined 325 for both packet switched and circuit switched networks. Many are 326 based on the ITU-T T.140 protocol on application and presentation 327 level [T140]. At the time of writing this document, some mechanisms 328 are no longer used, as the technologies they use have been obsoleted 329 etc, while others are still in use. 331 When performing interworking between T.140 data channels and another 332 real-time text transports and protocols with real-time text in 333 another, a number of factors need to be considered. At the time of 334 writing this document, the most common IP-based real-time text 335 transport is the RTP based mechanism defined in [RFC4103]. While 336 this document does not define a complete interworking solution, this 337 list below provides some guidance and considerations to take into 338 account when designing an gateway for interworking between T140 data 339 channels and RTP-based T.140 transport: 341 o For each T.140 data channel there is an RTP stream for real-time 342 text [RFC4103] . Redundancy is by default declared and used on 343 RTP stream. On the T.140 data channel there is no redundancy, but 344 the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of 345 T.140 the data channel is set. 346 o During a normal text flow, T140blocks received from one network 347 are forwarded towards the other network. Keep-alive traffic is 348 implicit on the T.140 data channel. A gateway might have to 349 extract keep-alives from incoming RTP streams, and MAY generate 350 keep-alives on outgoing RTP streams. 351 o It is RECOMMENDED that the gateway uses the same transmission 352 interval on both the T140 data channel and the RTP stream, if 353 possible. That will reduce the delay caused by buffering. 354 o If the gateway detects or suspects loss of data on the RTP stream, 355 the gateway gateway SHOULD insert the T.140 missing text marker 356 [T140ad1] in the data sent on the outgoing T.140 data channel. 357 o If the gateway detects or suspects loss of data on the T.140 data 358 channel, the gateway gateway SHOULD insert the T.140 missing text 359 marker [T140ad1] in the data sent on the outgoing RTP stream. 360 o If the gateway detects that the T.140 data channel has failed and 361 got torn down, once the data channel has been reestablished the 362 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 363 the data sent on the outgoing RTP stream. 365 NOTE: In order for the gateway to insert a missing text marker, or to 366 perform other actions that require that the gateway has access to the 367 T.140 data, the T.140 data cannot be encrypted end-to-end between the 368 T.140 data channel endpoint and the RTP endpoint. At the time of 369 writing this document, a mechanism to provide such end-to-end 370 encryption has not been defined. 372 6. Update to RFC 8373 374 This document updates RFC 8373, by defining how the SDP hlang-send 375 and hlang-recv attributes are used for the "application/webrtc- 376 datachannel" media type. 378 SDP offerers and answerers MUST NOT include the attributes directly 379 in the m= section associated with the 'application/webrtc- 380 datachannel' media type. Instead, the attributes MUST be associated 381 with individual data channels, using the SDP 'dcsa' attribute. A 382 specification that defines a subprotocol that uses the attributes 383 MUST specify the modality for that subprotocol, or how to retreive 384 the modality if the subprotocol supports multiple modalities. 386 7. Security Considerations 388 The generic security considerations for WebRTC data channels are 389 defined in [I-D.ietf-rtcweb-data-channel]. As data channels are 390 always encrypted by design, the T.140 data channels will also be 391 encrypted. 393 The generic security considerations for the SDP-based external 394 negotiation method are defined in 395 [I-D.ietf-mmusic-data-channel-sdpneg]. 397 8. IANA considerations 399 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 400 RFC number of this document.] 402 This document adds the subprotocol identifier "t140" to the 403 "WebSocket Subprotocol Name Registry" as follows: 405 +--------------------------+-------------+ 406 | Subprotocol Identifier: | t140 | 407 | Subprotocol Common Name: | ITU-T T.140 | 408 | Subprotocol Definition: | RFCXXXX | 409 | Reference: | RFCXXXX | 410 +--------------------------+-------------+ 412 9. Acknowledgements 414 This document is based on an earlier Internet draft edited by Keith 415 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 417 Thomas Belling provided useful comments on the initial (pre- 418 submission) version of the draft. Gunnar Hellstrom provided comments 419 and text on the draft. 421 10. References 423 10.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, . 430 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 431 with Session Description Protocol (SDP)", RFC 3264, 432 DOI 10.17487/RFC3264, June 2002, . 435 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 436 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 437 . 439 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 440 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 441 July 2006, . 443 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 444 RFC 4960, DOI 10.17487/RFC4960, September 2007, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time 452 Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, 453 . 455 [I-D.ietf-rtcweb-data-channel] 456 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 457 Channels", draft-ietf-rtcweb-data-channel-13 (work in 458 progress), January 2015. 460 [I-D.ietf-mmusic-data-channel-sdpneg] 461 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 462 Even, "SDP-based Data Channel Negotiation", draft-ietf- 463 mmusic-data-channel-sdpneg-28 (work in progress), May 464 2019. 466 [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), "Protocol 467 for multimedia application text conversation"", February 468 1998. 470 [T140ad1] ITU-T, "Recommendation ITU-T.140 aEUR" Addendum 1 471 (02/2000), "Protocol for multimedia application text 472 conversation"", February 2000. 474 10.2. Informative References 476 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 477 A., Peterson, J., Sparks, R., Handley, M., and E. 478 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 479 DOI 10.17487/RFC3261, June 2002, . 482 [V151] ITU-T, "Recommendation ITU-T V.151 (05/2006), "Procedures 483 for the end-to-end connection of analogue PSTN text 484 telephones over an IP network utilizing text relay"", May 485 2006. 487 [V152] ITU-T, "Recommendation ITU-T V.152 (09/2010), "Procedures 488 for supporting voice-band data over IP networks"", 489 September 2010. 491 [I-D.ietf-rtcweb-data-protocol] 492 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 493 Establishment Protocol", draft-ietf-rtcweb-data- 494 protocol-09 (work in progress), January 2015. 496 Author's Address 498 Christer Holmberg 499 Ericsson 500 Hirsalantie 11 501 Jorvas 02420 502 Finland 504 Email: christer.holmberg@ericsson.com