idnits 2.17.1 draft-ietf-mmusic-t140-usage-data-channel-14.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 == Unrecognized Status in 'Intended status: Standards TrackGunnar Hellstrom Accessible Communicatio', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (April 10, 2020) is 1467 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) ** 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: 1 error (**), 0 flaws (~~), 2 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: 8373 (if approved) G. Hellstrom 5 Intended status: Standards TrackGunnar Hellstrom Accessible Communicatio 6 Expires: October 12, 2020 April 10, 2020 8 T.140 Real-time Text Conversation over WebRTC Data Channels 9 draft-ietf-mmusic-t140-usage-data-channel-14 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. This 18 document updates RFC 8373 to specify its use with WebRTC data 19 channels. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 12, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4 58 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4 60 4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5 61 4.2.1. Maximum Character Transmission Rate . . . . . . . . . 5 62 4.2.2. Real-time Text Conversation Languages . . . . . . . . 6 63 4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 7 64 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10 67 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11 68 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11 69 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11 70 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12 71 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12 72 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14 76 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 15 77 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15 78 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 11.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 The ITU-T Protocol for multimedia application text conversation 88 (Recommendation ITU-T T.140) [T140] defines a protocol for text 89 conversation, also known as real-time text. The transport used for 90 IP networks is the "RTP Payload for Text Conversation" [RFC4103] 91 mechanism, based on the Real-time Transport Protocol (RTP) [RFC3550]. 93 This document specifies how a WebRTC data channel 94 [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism 95 for T.140, and how the SDP offer/answer mechanism for data channels 97 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such a 98 data channel. 100 In this document, a T.140 data channel refers to a WebRTC data 101 channel for which the instantiated sub-protocol is "t140", and where 102 the channel is negotiated using the SDP-based external negotiation 103 method [I-D.ietf-mmusic-data-channel-sdpneg]. 105 NOTE: The decision to transport real-time text using a WebRTC data 106 channel, instead of using RTP based transport [RFC4103], is motivated 107 by use-case "U-C 5: Real-time text chat during an audio and/or video 108 call with an individual or with multiple people in a conference", see 109 Section 3.2 of [I-D.ietf-rtcweb-data-channel]. 111 The brief notation "T.140" is used as a name for the text 112 conversation protocol according to [T140]. 114 Real-time text is intended to be entered by human users from a 115 keyboard, handwriting recognition, voice recognition or any other 116 input method. The rate of character entry is usually at a level of a 117 few characters per second or less. 119 Section 3 defines the generic data channel properties for a T.140 120 data channel, and Section 4 defines how they are conveyed in an SDP 121 dcmap attribute. While this document defines how to establish a 122 T.140 data channel using the SDP-based external negotiation method 123 [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway 124 considerations defined in Section 3, Section 5 and Section 6 of this 125 document can also be applied when a T.140 data channel is established 126 using another mechanism (e.g., the mechanism defined in 127 [I-D.ietf-rtcweb-data-protocol]). Section 5 of 128 [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the 129 SDP dcmap attribute parameters and the protocol parameters used in 130 [I-D.ietf-rtcweb-data-protocol]. 132 This document updates [RFC8373], by defining how the SDP hlang-send 133 and hlang-recv attributes are used for the "application/webrtc- 134 datachannel" media type. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. WebRTC Data Channel Considerations 146 The following WebRTC data channel property values 147 [I-D.ietf-rtcweb-data-channel] apply to a T.140 data channel: 149 +--------------------------+-------------------------------+ 150 | Subprotocol Identifier | t140 | 151 | Transmission reliability | reliable | 152 | Transmission order | in-order | 153 | Label | See Section 4.1 and Section 6 | 154 +--------------------------+-------------------------------+ 156 NOTE: T.140 requires the transport channel to provide transmission of 157 real-time text without duplication and in original order. Therefore, 158 T.140 does not specify reliable and ordered transmission of T.140 159 data on the application layer. Instead, when RTP based transport is 160 used, the RTP sequence number is used to detect packet loss and out- 161 of-order packets, and a redundancy mechanism is used to achieve 162 reliable delivery of T.140 data. By using the WebRTC data channel 163 reliable and in-order transmission features 164 [I-D.ietf-rtcweb-data-channel] for the T.140 data channel, there is 165 no need for a redundancy mechanism or a mechanism to detect data loss 166 and out-of-order delivery at the application level. The latency 167 characteristics of the T.140 data channel is also regarded to be 168 sufficient to meet the application requirements of T.140. 170 4. SDP Considerations 172 The generic SDP considerations, including the SDP Offer/Answer 173 procedures [RFC3264], for negotiating a WebRTC data channel are 174 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. This section, and 175 its subsections, define the SDP considerations that are specific to a 176 T.140 data channel, identified by an SDP 'dcmap' attribute 177 [I-D.ietf-mmusic-data-channel-sdpneg] with a "t140" attribute 178 parameter value. 180 4.1. Use of dcmap Attribute 182 An offerer and answerer MUST, in each offer and answer, include an 183 SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the 184 SDP media description (m= section) [I-D.ietf-mmusic-rfc4566bis] 185 describing the SCTP association [RFC4960] used to realize the T.140 186 data channel. 188 The offerer and answerer MUST include the subprotocol attribute 189 parameter, with a "t140" parameter value, in the 'dcmap' attribute 190 value. 192 The offerer and answerer MAY include the priority attribute parameter 193 and the label attribute parameter in the 'dcmap' attribute value, as 194 specified in [I-D.ietf-mmusic-data-channel-sdpneg]. 196 NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data 197 channel is negotiated using the mechanism defined in 198 [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value 199 has to be the same in both directions. That rule also applies to 200 data channels negotiated using the mechanism defined in this 201 document. 203 The offerer and answerer MUST NOT include the max-retr or the max- 204 time attribute parameters in the 'dcmap' attribute. If either of 205 those attribute parameters is received in an offer, the answerer MUST 206 reject the offer. If either of those attribute parameters is 207 received in an answer the offerer MUST NOT accept the answer. 208 Instead, the answerer MUST take appropriate actions, e.g., by sending 209 a new offer without a T.140 data channel, or by terminating the 210 session. 212 If the ordered attribute parameter is included in the 'dcmap' 213 attribute, it MUST be assigned the value 'true'. 215 Below is an example of the 'dcmap' attribute for a T.140 data channel 216 with stream id=3 and without any label: 218 a=dcmap:3 subprotocol="t140" 220 4.2. Use of dcsa Attribute 222 An offerer and answerer can, in each offer and answer, include one or 223 more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in 224 the m= section describing the SCTP association used to realize the 225 T.140 data channel. 227 If an offerer or answerer receives a 'dcsa' attribute that contains 228 an SDP attribute which usage has not been defined for a T.140 data 229 channel, the offerer or answerer should ignore the 'dcsa' attribute, 230 following the rules in Section 6.7 of 231 [I-D.ietf-mmusic-data-channel-sdpneg]. 233 4.2.1. Maximum Character Transmission Rate 235 A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to 236 indicate a maximum character transmission rate [RFC4103]. The 'cps' 237 attribute parameter is used to indicate the maximum character 238 transmission rate that the endpoint that includes the attribute is 239 able to receive, and the value is used as a mean value in characters 240 per second over any 10-second interval. 242 If the 'fmtp' attribute is included, the 'format' attribute parameter 243 MUST be set to "t140". 245 If no 'fmtp' attribute with a 'cps' attribute parameter is included, 246 the default value of 30 applies [RFC4103]. 248 The offerer and answerer MAY modify the 'cps' attribute parameter 249 value in subsequent offers and answers. 251 This document does not define any other usage of the 'fmtp' attribute 252 for a T.140 channel. If an offerer or answerer receives a 'dcsa' 253 attribute that contains an 'fmtp' attribute that is not according to 254 the procedure above, the offerer or answerer MUST ignore the 'dcsa' 255 attribute. 257 NOTE: The 'cps' attribute parameter is especially useful when a T.140 258 data channel endpoint is acting as a gateway (Section 6) and is 259 interworking with a T.140 transport mechanism that have restrictions 260 on how many characters can be sent per second. 262 If an endpoint receives text at a higher rate than it can handle, 263 e.g., because the sending endpoint does not support the 'cps' 264 attribute parameter, it SHOULD either indicate to the sending 265 endpoint that it is not willing to receive more text, using the 266 direction attributes (Section 4.2.3), or use a flow control mechanism 267 to reduce the rate. However, in certain applications, e.g. emergency 268 services, it is important to regain human interaction as soon as 269 possible, and it might therefore be more appropriate to simply 270 discard the received overflow, insert a mark for loss [T140ad1], and 271 continue to process the received text as soon as possible. 273 NOTE: At the time of writing this specification, the standardized API 274 for WebRTC data channels does not support flow control. Should such 275 be available at some point, a receiving endpoint might use it in 276 order to slow down the rate of text received from the sending 277 endpoint. 279 4.2.2. Real-time Text Conversation Languages 281 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' 282 attributes [RFC8373] to negotiate the language to be used for the 283 real-time text conversation. 285 For a T.140 data channel, the modality is "written" [RFC8373]. 287 4.2.3. Real-time Text Direction 289 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 290 'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to 291 negotiate the direction in which text can be transmitted in a real- 292 time text conversation. 294 NOTE: A WebRTC data channel is always bi-directional. The usage of 295 the 'dcsa' attribute only affects the direction in which 296 implementations are allowed to transmit text on a T.140 data channel. 298 The offer/answer rules for the direction attributes are based on the 299 rules for unicast streams defined in [RFC3264], as described below. 300 Note that the rules only apply to the direction attributes. 302 Session-level direction attributes [I-D.ietf-mmusic-rfc4566bis] have 303 no impact on a T.140 data channel. 305 4.2.3.1. Generating an Offer 307 If the offerer wishes to both send and receive text on a T.140 data 308 channel, it SHOULD mark the data channel as sendrecv with a 309 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does 310 not explicitly mark the data channel, an implicit 'sendrecv' 311 attribute inside a 'dcsa' attribute is applied by default. 313 If the offerer wishes to only send text on a T.140 data channel, it 314 MUST mark the data channel as sendonly with a 'sendonly' attribute 315 inside a 'dcsa' attribute. 317 If the offerer wishes to only receive text on a T.140 data channel, 318 it MUST mark the data channel as recvonly with a 'recvonly' attribute 319 inside a 'dcsa' attribute. 321 If the offerer wishes to neither send nor receive text on a T.140 322 data channel, it MUST mark the data channel as inactive with an 323 'inactive' attribute inside a 'dcsa' attribute. 325 If the offerer has marked a data channel as sendrecv (or if the 326 offerer did not explicitly mark the data channel) or recvonly, it 327 MUST be prepared to receive T.140 data as soon as the state of the 328 T.140 data channel allows it. 330 4.2.3.2. Generating an Answer 332 When the answerer accepts an offer, and marks the direction of the 333 text in the corresponding answer, the direction is based on the 334 marking (or the lack of explicit marking) in the offer. 336 If the offerer explicitly marked the data channel as sendrecv, or if 337 the offerer did not mark the data channel, the answerer SHOULD mark 338 the data channel as sendrecv, sendonly, recvonly or inactive with a 339 'sendrecv', 'sendonly', 'recvonly' or 'inactive' attribute 340 respectively inside a 'dcsa' attribute. If the answerer does not 341 explicitly mark the data channel, an implicit 'sendrecv' attribute 342 inside a 'dcsa' attribute is applied by default. 344 If the offerer marked the data channel as sendonly, the answerer MUST 345 mark the data channel as recvonly or inactive with a 'recvonly' or 346 'inactive' attribute respectively inside a 'dcsa' attribute. 348 If the offerer marked the data channel as recvonly, the answerer MUST 349 mark the data channel as sendonly or inactive with a 'sendonly' or 350 'inactive' attribute respectively inside a 'dcsa' attribute. 352 If the offerer marked the data channel as inactive, the answerer MUST 353 mark the data channel as inactive with an 'inactive' attribute inside 354 a 'dcsa' attribute. 356 If the answerer has marked a data channel as sendrecv or recvonly, it 357 MUST be prepared to receive data as soon as the state of the T.140 358 data channel allows transmission of data. 360 4.2.3.3. Offerer Receiving an Answer 362 When the offerer receives an answer to the offer and the answerer has 363 marked a data channel as sendrecv (or the answerer did not mark the 364 data channel) or recvonly in the answer, the offerer can start 365 sending T.140 data as soon as the state of the T.140 data channel 366 allows it. If the answerer has marked the data channel as inactive 367 or sendonly, the offerer MUST NOT send any T.140 data. 369 If the answerer has not marked the direction of a T.140 data channel 370 in accordance with the procedures above, it is RECOMMENDED that the 371 offerer does not process that as an error situation, but rather 372 assume that the answerer might both send and receive T.140 data on 373 the data channel. 375 4.2.3.4. Modify Text Direction 377 If an endpoint wishes to modify a previously negotiated text 378 direction in an ongoing session, it MUST initiate an offer that 379 indicates the new direction, following the rules in Section 4.2.3.1. 380 If the answerer accepts the offer it follows the procedures in 381 Section 4.2.3.2. 383 4.3. Examples 385 Below is an example of an m= section of an offer for a T.140 data 386 channel offering real-time text conversation in Spanish and 387 Esperanto, and an m= section in the associated answer accepting 388 Esperanto. The maximum character transmission rate is set to 20. As 389 the offerer and answerer have not explicitly indicated the real-time 390 text direction, the default direction "sendrecv" applies. 392 Offer: 394 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 395 c=IN IP6 2001:db8::3 396 a=max-message-size:1000 397 a=sctp-port 5000 398 a=setup:actpass 399 a=dcmap:2 label="ACME customer service";subprotocol="t140" 400 a=dcsa:2 fmtp:t140 cps=20 401 a=dcsa:2 hlang-send:es eo 402 a=dcsa:2 hlang-recv:es eo 404 Answer: 406 m=application 2004 UDP/DTLS/SCTP webrtc-datachannel 407 c=IN IP6 2001:db8::1 408 a=max-message-size:1000 409 a=sctp-port 6000 410 a=setup:passive 411 a=dcmap:2 label="ACME customer service";subprotocol="t140" 412 a=dcsa:2 fmtp:t140 cps=20 413 a=dcsa:2 hlang-send:eo 414 a=dcsa:2 hlang-recv:eo 416 Below is an example of an m= section of an offer for a T.140 data 417 channel where the offerer wishes to only receive real-time text, and 418 an m= section in the associated answer indicating that the answerer 419 will only send real-time text. No maximum character transmission 420 rate is indicated. No preference for the language to be used for the 421 real-time text conversation is indicated. 423 Offer: 425 m=application 1400 UDP/DTLS/SCTP webrtc-datachannel 426 c=IN IP6 2001:db8::3 427 a=max-message-size:1000 428 a=sctp-port 5000 429 a=setup:actpass 430 a=dcmap:2 label="ACME customer service";subprotocol="t140" 431 a=dcsa:2 recvonly 433 Answer: 435 m=application 2400 UDP/DTLS/SCTP webrtc-datachannel 436 c=IN IP6 2001:db8::1 437 a=max-message-size:1000 438 a=sctp-port 6000 439 a=setup:passive 440 a=dcmap:2 label="ACME customer service";subprotocol="t140" 441 a=dcsa:2 sendonly 443 5. T.140 Considerations 445 5.1. Session Layer Functions 447 Section 6.1 of [T140] describes the generic T.140 session control 448 functions at a high-level in a signalling protocol independent 449 manner. The list below describes how the functions are realized when 450 using a T.140 data channel. 452 o Prepare session: An endpoint can indicate its support of T.140 453 data channels using signalling specific means (e.g., using SIP 454 OPTIONS [RFC3261]), or by indicating the support in an offer or 455 answer (Section 4) 456 o Initiate session: An offer used to request the establishment of a 457 T.140 data channel (Section 4) 458 o Accept session: An answer used to accept a request to establish a 459 T.140 data channel (Section 4) 460 o Deny session: An answer used to reject a request to establish a 461 T.140 data channel, using the generic procedures for rejecting a 462 data channel [I-D.ietf-mmusic-data-channel-sdpneg] 463 o Disconnect session: An offer or answer used to disable a 464 previously established T.140 data channel, using the generic 465 procedures for closing a data channel 466 [I-D.ietf-mmusic-data-channel-sdpneg] 467 o Data: Data sent on an established T.140 data channel (Section 5.2) 469 5.2. Data Encoding and Sending 471 T.140 text is encoded and framed as T140blocks [RFC4103]. 473 Each T140block is sent on the SCTP stream [RFC4960] used to realize 474 the T.140 data channel using standard T.140 transmission procedures 475 [T140]. One or more T140blocks can be sent in a single SCTP user 476 message [RFC4960]. Unlike RTP based transport for real-time text 477 [RFC4103], T.140 data channels do not use redundant transmission of 478 text. The reason for this is that the T.140 data channel achieves 479 robust transmission by using the "reliable" mode of the data channel. 481 Data sending procedures conform to [T140]. 483 See Section 8 of [T140] for coding details. 485 NOTE: The T.140 coding details contain information on optional 486 control codes for controlling the presentation which may not be 487 supported by the presentation level of the receiving application. 488 The receiving application is expected to handle reception of such 489 T.140 control codes appropriately (e.g. ignore and skip them) even if 490 their effect on the presentation is not supported. 492 5.3. Data Buffering 494 As described in [T140], buffering can be used to reduce overhead, 495 with the maximum assigned transmission interval of T140blocks from 496 the buffer being 500 ms as long as there is text to send. 498 Buffering MAY also be used for staying within the maximum character 499 transmission rate (Section 4.2). 501 An implementation needs to take the user requirements for smooth flow 502 and low latency in real-time text conversation into consideration 503 when assigning a transmission interval. It is RECOMMENDED to use the 504 default transmission interval of 300 milliseconds [RFC4103], for 505 T.140 data channels. Implementers might also use lower values for 506 specific applications requiring low latency, taking the increased 507 overhead in consideration. 509 5.4. Loss of T140blocks 511 In case of network failure or congestion, T.140 data channels might 512 fail and get torn down. If this happens but the session sustains, it 513 is RECOMMENDED that implementations try to reestablish the T.140 data 514 channels. As a T.140 data channel does not provide a mechanism for 515 the receiver to identify retransmitted T140blocks after channel 516 reestablishment, the sending endpoint MUST NOT retransmit T140blocks. 518 Similarly, a receiver SHOULD indicate to the user that there has been 519 a channel reestablishment, and that text might have been lost. This 520 MAY be done by inserting the missing text markers [T140ad1] or in any 521 other way evident to the user. 523 NOTE: If the SCTP association [RFC4960] used to realize the T.140 524 data channel fails and gets torn down, it needs to be re-established 525 before the T.140 data channel can be reestablished. The procedures 526 after the reestablishment of the T.140 data channel defined in this 527 section apply no matter if only the T.140 data channel, or the whole 528 SCTP association, got torn down. 530 5.5. Multi-party Considerations 532 If an implementation needs to support multi-party scenarios, the 533 implementation needs to support multiple simultaneous T.140 data 534 channels, one for each remote party. At the time of writing this 535 document, this is true even in scenarios where each participant 536 communicates via a centralized conference server. The reason is 537 that, unlike RTP media, WebRTC data channels and the T.140 protocol 538 do not support the indication of the source of T.140 data. The SDP 539 'dcmap' attribute label attribute parameter (Section 4.1) can be used 540 by the offerer to provide additional information about each T.140 541 data channel, and help implementations to distinguish between them. 543 NOTE: Future extensions to T.140, or to the T140block, might allow 544 indicating the source of T.140 data, in which case it might be 545 possible to use a single T.140 data channel to transport data from 546 multiple remote sources. The usage of a single T.140 data channel, 547 without any protocol extensions, would require the conference server 548 to only forward real-time text from one source at any given time, and 549 e.g., include human readable text labels in the real-time text stream 550 that indicate the source whenever the conference server switches the 551 source. This would allow the receiver to present real-time text from 552 different sources separately. The procedures of such mechanism are 553 outside the scope of this document. 555 6. Gateway Considerations 557 A number of real-time text transports and protocols have been defined 558 for both packet-switched and circuit-switched networks. Many are 559 based on the ITU-T T.140 protocol on application and presentation 560 level [T140]. At the time of writing this document, some mechanisms 561 are no longer used, as the technologies they use have been obsoleted, 562 while others are still in use. 564 When performing interworking between T.140 data channels and real- 565 time text in other transports and protocols, a number of factors need 566 to be considered. At the time of writing this document, the most 567 common IP-based real-time text transport is the RTP based mechanism 568 defined in [RFC4103]. While this document does not define a complete 569 interworking solution, this list below provides some guidance and 570 considerations to take into account when designing a gateway for 571 interworking between T.140 data channels and RTP-based T.140 572 transport: 574 o For each T.140 data channel there is an RTP stream for real-time 575 text [RFC4103]. Redundancy is by default declared and used on the 576 RTP stream. There is no redundancy on the T.140 data channel, but 577 the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] is set 578 on it. 579 o During a normal text flow, T140blocks received from one network 580 are forwarded towards the other network. Keep-alive traffic is 581 handled by lower layers on the T.140 data channel. A gateway 582 might have to extract keep-alives from incoming RTP streams, and 583 MAY generate keep-alives on outgoing RTP streams. 584 o If the gateway detects or suspects loss of data on the RTP stream, 585 and the lost data has not been retrieved using a redundancy 586 mechanism, the gateway SHOULD insert the T.140 missing text marker 587 [T140ad1] in the data sent on the outgoing T.140 data channel. 588 o If the gateway detects that the T.140 data channel has failed and 589 got torn down, once the data channel has been reestablished the 590 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 591 the data sent on the outgoing RTP stream if it detects or suspects 592 that data sent by the remote T.140 data channel endpoint was lost. 593 o If the gateway detects that the T.140 data channel has failed and 594 got torn down, once the data channel has been reestablished the 595 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 596 the data sent on the outgoing T.140 data channel if it detects or 597 suspects that data sent or to be sent on the T.140 data channel 598 was lost during the failure. 599 o The gateway MUST indicate the same text transmission direction 600 (Section 4.2.3) on the T.140 data channel and the RTP stream. 602 NOTE: In order for the gateway to insert a missing text marker, or to 603 perform other actions that require that the gateway has access to the 604 T.140 data, the T.140 data cannot be encrypted end-to-end between the 605 T.140 data channel endpoint and the RTP endpoint. At the time of 606 writing this document, no mechanism to provide such end-to-end 607 encryption is defined. 609 7. Update to RFC 8373 611 This document updates RFC 8373 [RFC8373], by defining how the SDP 612 hlang-send and hlang-recv attributes are used for the "application/ 613 webrtc-datachannel" media type. 615 SDP offerers and answerers MUST NOT include the attributes directly 616 in the m= section associated with the 'application/webrtc- 617 datachannel' media type. Instead, the attributes MUST be associated 618 with individual data channels, using the SDP 'dcsa' attribute. A 619 specification that defines a subprotocol that uses the attributes 620 MUST specify the modality for that subprotocol, or how to retrieve 621 the modality if the subprotocol supports multiple modalities. The 622 subprotocol is indicated using the SDP 'dcmap' attribute. 624 8. Security Considerations 626 The generic WebRTC security considerations are defined in 627 [I-D.ietf-rtcweb-security-arch] and [I-D.ietf-rtcweb-security]. 629 The generic security considerations for WebRTC data channels are 630 defined in [I-D.ietf-rtcweb-data-channel]. As data channels are 631 always encrypted by design, the T.140 data channels will also be 632 encrypted. 634 The generic security considerations for the SDP-based external 635 negotiation method are defined in 636 [I-D.ietf-mmusic-data-channel-sdpneg]. There are no additional T.140 637 data channel specific security considerations. 639 When performing interworking between T.140 data channels and real- 640 time text and the RTP based mechanism defined in [RFC4103], in order 641 for a gateway to insert a missing text marker, or to perform other 642 actions that require that the gateway has access to the T.140 data, 643 the T.140 data cannot be encrypted end-to-end between the T.140 data 644 channel endpoint and the RTP endpoint. 646 9. IANA considerations 648 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 649 RFC number of this document.] 651 9.1. Subprotocol Identifier t140 653 This document adds the subprotocol identifier "t140" to the 654 "WebSocket Subprotocol Name Registry" as follows: 656 +--------------------------+----------------------------+ 657 | Subprotocol Identifier: | t140 | 658 | Subprotocol Common Name: | ITU-T T.140 Real-Time Text | 659 | Subprotocol Definition: | RFCXXXX | 660 | Reference: | RFCXXXX | 661 +--------------------------+----------------------------+ 663 9.2. SDP fmtp Attribute 665 This document defines the usage of the SDP 'fmtp' attribute, if this 666 attribute is included in an SDP 'dcsa' attribute and associated with 667 an T.140 real-time text session over a WebRTC data channel. The 668 usage is defined in Section 4.2.1. 670 The usage level "dcsa(t140)" is added to the registration of the SDP 671 'fmtp' attribute in the Session Description Protocol (SDP) Parameters 672 registry as follows: 674 +-----------------------+-------------------------------------------+ 675 | Contact name: | IESG | 676 | Contact email: | iesg@ietf.org | 677 | Attribute name: | fmtp | 678 | Usage level: | dcsa(t140) | 679 | Purpose: | Indicate format parameters for a T.140 | 680 | | data channel, such as maximum character | 681 | | transmission rates. | 682 | Reference: | RFCXXXX | 683 +-----------------------+-------------------------------------------+ 685 9.3. SDP Language Attributes 687 This document modifies the usage of the SDP 'hlang-send' and 'hlang- 688 recv' attributes, if these attributes are included in SDP 'dcsa' 689 attributes associated with an T.140 data channel. The modified usage 690 is described in Section 4.2.2. 692 The usage level "dcsa(t140)" is added to the registration of the SDP 693 'hland-send' attribute in the Session Description Protocol (SDP) 694 Parameters registry as follows: 696 +-----------------------+-------------------------------------------+ 697 | Contact name: | IESG | 698 | Contact email: | iesg@ietf.org | 699 | Attribute name: | hlang-send | 700 | Usage level: | dcsa(t140) | 701 | Purpose: | Negotiate the language to be used on a | 702 | | T.140 data channel. | 703 | Reference: | RFCXXXX | 704 +-----------------------+-------------------------------------------+ 706 The usage level "dcsa(t140)" is added to the registration of the SDP 707 'hland-recv' attribute in the Session Description Protocol (SDP) 708 Parameters registry as follows: 710 +-----------------------+-------------------------------------------+ 711 | Contact name: | IESG | 712 | Contact email: | iesg@ietf.org | 713 | Attribute name: | hlang-recv | 714 | Usage level: | dcsa(t140) | 715 | Purpose: | Negotiate the language to be used on a | 716 | | T.140 data channel. | 717 | Reference: | RFCXXXX | 718 +-----------------------+-------------------------------------------+ 720 9.4. SDP Media Direction Attributes 722 This document modifies the usage of the SDP 'sendonly', 'recvonly', 723 'sendrecv' and 'inactive' attributes, if these attributes are 724 included in SDP 'dcsa' attributes associated T.140 data channel. The 725 modified usage is described in Section 4.2.3. 727 The usage level "dcsa(t140)" is added to the registration of the SDP 728 'sendonly' attribute in the Session Description Protocol (SDP) 729 Parameters registry as follows: 731 +-----------------------+-------------------------------------------+ 732 | Contact name: | IESG | 733 | Contact email: | iesg@ietf.org | 734 | Attribute name: | sendonly | 735 | Usage level: | dcsa(t140) | 736 | Purpose: | Negotiate the direction in which real- | 737 | | time text can be sent on a T.140 data | 738 | | channel. | 739 | Reference: | RFCXXXX | 740 +-----------------------+-------------------------------------------+ 742 The usage level "dcsa(t140)" is added to the registration of the SDP 743 'recvonly' attribute in the Session Description Protocol (SDP) 744 Parameters registry as follows: 746 +-----------------------+-------------------------------------------+ 747 | Contact name: | IESG | 748 | Contact email: | iesg@ietf.org | 749 | Attribute name: | recvonly | 750 | Usage level: | dcsa(t140) | 751 | Purpose: | Negotiate the direction in which real- | 752 | | time text can be sent on a T.140 data | 753 | | channel. | 754 | Reference: | RFCXXXX | 755 +-----------------------+-------------------------------------------+ 756 The usage level "dcsa(t140)" is added to the registration of the SDP 757 'sendrecv' attribute in the Session Description Protocol (SDP) 758 Parameters registry as follows: 760 +-----------------------+-------------------------------------------+ 761 | Contact name: | IESG | 762 | Contact email: | iesg@ietf.org | 763 | Attribute name: | sendrecv | 764 | Usage level: | dcsa(t140) | 765 | Purpose: | Negotiate the direction in which real- | 766 | | time text can be sent on a T.140 data | 767 | | channel. | 768 | Reference: | RFCXXXX | 769 +-----------------------+-------------------------------------------+ 771 The usage level "dcsa(t140)" is added to the registration of the SDP 772 'inactive' attribute in the Session Description Protocol (SDP) 773 Parameters registry as follows: 775 +-----------------------+-------------------------------------------+ 776 | Contact name: | IESG | 777 | Contact email: | iesg@ietf.org | 778 | Attribute name: | inactive | 779 | Usage level: | dcsa(t140) | 780 | Purpose: | Negotiate the direction in which real- | 781 | | time text can be sent on a T.140 data | 782 | | channel. | 783 | Reference: | RFCXXXX | 784 +-----------------------+-------------------------------------------+ 786 10. Acknowledgements 788 This document is based on an earlier Internet draft edited by Keith 789 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 791 Thomas Belling provided useful comments on the initial (pre- 792 submission) version of the draft. Paul Kyzivat and Bernard Aboba 793 provided comments on the draft. 795 11. References 797 11.1. Normative References 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, 801 DOI 10.17487/RFC2119, March 1997, . 804 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 805 with Session Description Protocol (SDP)", RFC 3264, 806 DOI 10.17487/RFC3264, June 2002, . 809 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 810 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 811 . 813 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 814 RFC 4960, DOI 10.17487/RFC4960, September 2007, 815 . 817 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 818 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 819 May 2017, . 821 [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time 822 Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, 823 . 825 [I-D.ietf-mmusic-rfc4566bis] 826 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 827 Session Description Protocol", draft-ietf-mmusic- 828 rfc4566bis-37 (work in progress), August 2019. 830 [I-D.ietf-rtcweb-data-channel] 831 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 832 Channels", draft-ietf-rtcweb-data-channel-13 (work in 833 progress), January 2015. 835 [I-D.ietf-mmusic-data-channel-sdpneg] 836 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 837 Even, "SDP-based Data Channel Negotiation", draft-ietf- 838 mmusic-data-channel-sdpneg-28 (work in progress), May 839 2019. 841 [I-D.ietf-rtcweb-security-arch] 842 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 843 rtcweb-security-arch-20 (work in progress), July 2019. 845 [I-D.ietf-rtcweb-security] 846 Rescorla, E., "Security Considerations for WebRTC", draft- 847 ietf-rtcweb-security-12 (work in progress), July 2019. 849 [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), Protocol for 850 multimedia application text conversation", February 1998. 852 [T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 - (02/2000), 853 Protocol for multimedia application text conversation", 854 February 2000. 856 11.2. Informative References 858 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 859 A., Peterson, J., Sparks, R., Handley, M., and E. 860 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 861 DOI 10.17487/RFC3261, June 2002, . 864 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 865 Jacobson, "RTP: A Transport Protocol for Real-Time 866 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 867 July 2003, . 869 [I-D.ietf-rtcweb-data-protocol] 870 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 871 Establishment Protocol", draft-ietf-rtcweb-data- 872 protocol-09 (work in progress), January 2015. 874 Authors' Addresses 876 Christer Holmberg 877 Ericsson 878 Hirsalantie 11 879 Jorvas 02420 880 Finland 882 Email: christer.holmberg@ericsson.com 884 Gunnar Hellstrom 885 Gunnar Hellstrom Accessible Communication 886 Esplanaden 30 887 Vendelso 136 70 888 Sweden 890 Email: gunnar.hellstrom@ghaccess.se