idnits 2.17.1 draft-ietf-mmusic-t140-usage-data-channel-11.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 (December 19, 2019) is 1590 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 (~~), 1 warning (==), 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) December 19, 2019 5 Intended status: Standards Track 6 Expires: June 21, 2020 8 T.140 Real-time Text Conversation over WebRTC Data Channels 9 draft-ietf-mmusic-t140-usage-data-channel-11 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. The 18 document updates RFC 8373. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 21, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3 57 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4 59 4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5 60 4.2.1. Maximum Character Transmission Rate . . . . . . . . . 5 61 4.2.2. Real-time Text Conversation Languages . . . . . . . . 6 62 4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 6 63 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10 66 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11 67 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11 68 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11 69 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12 70 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14 75 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 14 76 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15 77 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 11.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 The ITU-T Protocol for multimedia application text conversation 87 (Recommendation ITU-T T.140) [T140] defines a protocol for text 88 conversation, also known as real-time text. The transport used for 89 IP networks is the "RTP Payload for Text Conversation" [RFC4103] 90 mechanism, based on the Real-time Transport Protocol (RTP) [RFC3550]. 92 This document specifies how a WebRTC data channel 93 [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism 94 for T.140, and how the SDP offer/answer mechanism 95 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such 96 data channel. 98 In this document, a T.140 data channel refers to a WebRTC data 99 channel for which the instantiated sub-protocol is "t140", and where 100 the channel is negotiated using the SDP-based external negotiation 101 method [I-D.ietf-mmusic-data-channel-sdpneg]. 103 NOTE: The decision to transport real-time text using a WebRTC data 104 channel, instead of using RTP based transport [RFC4103], is motivated 105 by use-case "U-C 5: Real-time text chat during an audio and/or video 106 call with an individual or with multiple people in a conference", see 107 Section 3.2 of [I-D.ietf-rtcweb-data-channel]. 109 The brief notation "T.140" is used as a name for the text 110 conversation protocol according to [T140]. 112 Section 3 defines the generic data channel properties for a T.140 113 data channel, and Section 4 defines how they are conveyed in an SDP 114 dcmap attribute. While this document defines how to establish a 115 T.140 data channel using the SDP-based external negotiation method 116 [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway 117 considerations defined in Section 3, Section 5 and Section 6 of this 118 document can also be applied when a T.140 data channel is established 119 using another mechanism (e.g., the mechanism defined in 120 [I-D.ietf-rtcweb-data-protocol]). Section 5 of 121 [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the 122 SDP dcmap attribute parameters and the protocol parameters used in 123 [I-D.ietf-rtcweb-data-protocol]. 125 This document updates [RFC8373], by defining how the SDP hlang-send 126 and hlang-recv attributes are used for the "application/webrtc- 127 datachannel" media type. 129 This document is based on an earlier Internet draft edited by Keith 130 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. WebRTC Data Channel Considerations 142 The following WebRTC data channel property values 143 [I-D.ietf-rtcweb-data-channel] apply to a T.140 data channel: 145 +--------------------------+-------------------------------+ 146 | Subprotocol Identifier | t140 | 147 | Transmission reliability | reliable | 148 | Transmission order | in-order | 149 | Label | See Section 4.1 and Section 6 | 150 +--------------------------+-------------------------------+ 152 NOTE: T.140 requires the transport channel to provide transmission of 153 real-time text without duplication and in original order. Therefore, 154 T.140 does not specify reliable and ordered transmission of T.140 155 data on the application layer. Instead, when RTP based transport is 156 used, the RTP sequence number is used to detect packet loss and out- 157 of-order packets, and a redundancy mechanism is used to achieve 158 reliable delivery of T.140 data. By using the WebRTC data channel 159 reliable and in-order transmission features 160 [I-D.ietf-rtcweb-data-channel] for the T.140 data channel, there is 161 no need for a redundancy mechanism or a mechanism to detect data loss 162 and out-of-order delivery at the application level. The latency 163 characteristics of the T.140 data channel is also regarded to be 164 sufficient to meet the application requirements of T.140. 166 4. SDP Considerations 168 The generic SDP considerations, including the SDP Offer/Answer 169 procedures, for negotiating a WebRTC data channel are defined in 170 [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP 171 considerations that are specific to a T.140 data channel. 173 4.1. Use of dcmap Attribute 175 An offerer and answerer MUST, in each offer and answer, include an 176 SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the 177 SDP media description (m= section) [I-D.ietf-mmusic-rfc4566bis] 178 describing the SCTP association [RFC4960] used to realize the T.140 179 data channel. 181 The offerer and answerer MUST include the subprotocol attribute 182 parameter, with a "t140" parameter value, in the 'dcmap' attribute 183 value. 185 The offerer and answerer MAY include the priority attribute parameter 186 and the label attribute parameter in the 'dcmap' attribute value. If 187 the offerer includes a label attribute parameter, the answerer MUST 188 NOT change the value in the answer. 190 NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data 191 channel is negotiated using the mechanism defined in 192 [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value 193 has to be the same in both directions. That rule also applies to 194 data channels negotiated using the mechanism defined in this 195 document. 197 The offerer and answerer MUST NOT include the max-retr and max-time 198 attribute parameters in the 'dcmap' attribute. 200 If the ordered attribute parameter is included in the 'dcmap' 201 attribute, it MUST be assigned the value 'true'. 203 Below is an example of the 'dcmap' attribute for a T.140 data channel 204 with stream id=3 and without any label: 206 a=dcmap:3 subprotocol="t140" 208 4.2. Use of dcsa Attribute 210 An offerer and answerer MAY, in each offer and answer, include one or 211 more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in 212 the m= section describing the SCTP association used to realize the 213 T.140 data channel. 215 If an offerer or answerer receives a 'dcsa' attribute that contains 216 an SDP attribute which usage has not been defined for a T.140 data 217 channel, the offerer or answerer should ignore the 'dcsa' attribute, 218 following the rules in Section 6.7 of 219 [I-D.ietf-mmusic-data-channel-sdpneg]. 221 4.2.1. Maximum Character Transmission Rate 223 A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to 224 indicate a maximum character transmission rate [RFC4103]. The 'cps' 225 attribute parameter is used to indicate the maximum character 226 transmission rate that the endpoint that includes the attribute is 227 able to receive, and the value is used as a mean value in characters 228 per second over any 10-second interval. 230 If the 'fmtp' attribute is included, the 'format' attribute parameter 231 MUST be set to "t140". 233 If the 'fmtp' attribute is not included, the default value of 30 234 applies [RFC4103]. 236 The offerer and answerer MAY modify the 'cps' attribute parameter 237 value in subsequent offers and answers. 239 This document does not define any other usage of the 'fmtp' attribute 240 for a T.140 channel. If an offerer or answerer receives a 'dcsa' 241 attribute that contains an 'fmtp' attribute that is not according to 242 the procedure above, the offerer or answerer MUST ignore the 'dcsa' 243 attribute. 245 NOTE: The 'cps' attribute parameter is especially useful when a T.140 246 data channel endpoint is acting as a gateway (Section 6) and is 247 interworking with a T.140 transport mechanism that have restrictions 248 on how many characters can be sent per second. 250 4.2.2. Real-time Text Conversation Languages 252 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' 253 attributes [RFC8373] to negotiate the language to be used for the 254 real-time text conversation. 256 For a T.140 data channel, the modality is "written" [RFC8373]. 258 4.2.3. Real-time Text Direction 260 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 261 'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to 262 negotiate the direction in which text can be transmitted in a real- 263 time text conversation. 265 NOTE: A WebRTC data channel is always bi-directional. The usage of 266 the 'dcsa' attribute only affects the direction in which 267 implementations are allowed to transmit text on a T.140 data channel. 269 The offer/answer rules for the direction attributes are based on the 270 rules for unicast streams defined in [RFC3264], as described below. 271 Note that the rules only apply to the direction attributes. 273 Session level direction attributes [I-D.ietf-mmusic-rfc4566bis] have 274 no impact on a T.140 data channel. 276 4.2.3.1. Generating an Offer 278 If the offerer wishes to both send and receive text on a T.140 data 279 channel, it SHOULD mark the data channel as sendrecv with a 280 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does 281 not explicitly mark the data channel, an implicit 'sendrecv' 282 attribute inside a 'dcsa' attribute is applied by default. 284 If the offerer wishes to only send text on a T.140 data channel, it 285 MUST mark the data channel as sendonly with a 'sendonly' attribute 286 inside a 'dcsa' attribute. 288 If the offerer wishes to only receive text on a T.140 data channel, 289 it MUST mark the data channel as recvonly with a 'recvonly' attribute 290 inside a 'dcsa' attribute. 292 If the offerer wishes to neither send nor receive text on a T.140 293 data channel, it MUST mark the data channel as inactive with an 294 'inactive' attribute inside a 'dcsa' attribute. 296 If the offerer has marked a data channel as sendrecv (or if the 297 offerer did not explicitly mark the data channel) or recvonly, it 298 MUST be prepared to receive T.140 data as soon as the state of the 299 T.140 data channel allows it. 301 4.2.3.2. Generating an Answer 303 When the answerer accepts an offer, and marks the direction of the 304 text in the corresponding answer, the direction is based on the 305 marking (or the lack of explicit marking) in the offer. 307 If the offerer explicitly marked the data channel as sendrecv, or if 308 the offerer did not mark the data channel, the answerer SHOULD mark 309 the data channel as sendrecv, sendonly, recvonly or inactive with a 310 'sendrecv', 'sendonly', 'recvonly' or 'inactive' attribute 311 respectively inside a 'dcsa' attribute. If the answerer does not 312 explicitly mark the data channel, an implicit 'sendrecv' attribute 313 inside a 'dcsa' attribute is applied by default. 315 If the offerer marked the data channel as sendonly, the answerer MUST 316 mark the data channel as recvonly or inactive with a 'recvonly' or 317 'inactive' attribute respectively inside a 'dcsa' attribute. 319 If the offerer marked the data channel as recvonly, the answerer MUST 320 mark the data channel as sendonly or inactive with a 'sendonly' or 321 'inactive' attribute respectively inside a 'dcsa' attribute. 323 If the offerer marked the data channel as inactive, the answerer MUST 324 mark the data channel as inactive with an 'inactive' attribute inside 325 a 'dcsa' attribute. 327 If the answerer has marked a data channel as sendrecv or recvonly, it 328 MUST be prepared to receive data as soon as the state of the T.140 329 data channel allows transmission of data. 331 4.2.3.3. Offerer Receiving an Answer 333 When the offerer receives an answer to the offer and the answerer has 334 marked a data channel as sendrecv (or the answerer did not mark the 335 data channel) or recvonly in the answer, the offerer can start 336 sending T.140 data as soon as the state of the T.140 data channel 337 allows it. If the answerer has marked the data channel as inactive 338 or sendonly, the offerer MUST NOT send any T.140 data. 340 If the answerer has not marked the direction of a T.140 data channel 341 in accordance with the procedures above, it is RECOMMENDED that the 342 offerer does not process that as an error situation, but rather 343 assume that the answerer might both send and receive T.140 data on 344 the data channel. 346 4.2.3.4. Modify Text Direction 348 If an endpoint wishes to modify a previously negotiated text 349 direction in an ongoing session, it MUST initiate an offer that 350 indicates the new direction, following the rules in Section 4.2.3.1. 351 If the answerer accepts the offer it follows the procedures in 352 Section 4.2.3.2. 354 4.3. Examples 356 Below is an example of an m= section of an offer for a T.140 data 357 channel offering real-time text conversation in Spanish and 358 Esperanto, and an m= section in the associated answer accepting 359 Esperanto. The maximum character transmission rate is set to 20. As 360 the offerer and answerer have not explicitly indicated the real-time 361 text direction, the default direction "sendrecv" applies. 363 Offer: 365 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 366 c=IN IP6 2001:db8::3 367 a=max-message-size:1000 368 a=sctp-port 5000 369 a=dcmap:2 label="ACME customer service";subprotocol="t140" 370 a=dcsa:2 fmtp:t140 cps=20 371 a=dcsa:2 hlang-send:es eo 372 a=dcsa:2 hlang-recv:es eo 374 Answer: 376 m=application 2004 UDP/DTLS/SCTP webrtc-datachannel 377 c=IN IP6 2001:db8::1 378 a=max-message-size:1000 379 a=sctp-port 6000 380 a=dcmap:2 label="ACME customer service";subprotocol="t140" 381 a=dcsa:2 fmtp:t140 cps=20 382 a=dcsa:2 hlang-send:eo 383 a=dcsa:2 hlang-recv:eo 385 Below is an example of an m= section of an offer for a T.140 data 386 channel where the offerer wishes to only receive real-time text, and 387 an m= section in the associated answer indicating that the answerer 388 will only send real-time text. No maximum character transmission 389 rate is indicated. No preference for the language to be used for the 390 real-time text conversation is indicated. 392 Offer: 394 m=application 1400 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=dcmap:2 label="ACME customer service";subprotocol="t140" 399 a=dcsa:2 recvonly 401 Answer: 403 m=application 2400 UDP/DTLS/SCTP webrtc-datachannel 404 c=IN IP6 2001:db8::1 405 a=max-message-size:1000 406 a=sctp-port 6000 407 a=dcmap:2 label="ACME customer service";subprotocol="t140" 408 a=dcsa:2 sendonly 410 5. T.140 Considerations 412 5.1. Session Layer Functions 414 Section 6.1 of [T140] describes the generic T.140 session control 415 functions at a high-level in a signalling protocol independent 416 manner. The list below describes how the functions are realized when 417 using a T.140 data channel. 419 o Prepare session: An endpoint can indicate its support of T.140 420 data channels using signalling specific means (e.g., using SIP 421 OPTIONS [RFC3261]), or by indicating the support in an offer or 422 answer (Section 4) 423 o Initiate session: An offer used to request the establishment of a 424 T.140 data channel (Section 4) 425 o Accept session: An answer used to accept a request to establish a 426 T.140 data channel (Section 4) 427 o Deny session: An answer used to reject a request to establish a 428 T.140 data channel, using the generic procedures for rejecting a 429 data channel [I-D.ietf-mmusic-data-channel-sdpneg] 430 o Disconnect session: An offer or answer used to disable a 431 previously established T.140 data channel, using the generic 432 procedures for closing a data channel 433 [I-D.ietf-mmusic-data-channel-sdpneg] 434 o Data: Data sent on an established T.140 data channel (Section 5.2) 436 5.2. Data Encoding and Sending 438 T.140 text is encoded and framed as T140blocks [RFC4103]. 440 Each T140block is sent on the SCTP stream [RFC4960] used to realize 441 the T.140 data channel using standard T.140 transmission procedures 442 [T140]. One or more T140blocks can be sent in a single SCTP user 443 message [RFC4960]. Unlike RTP based transport for real-time text 444 [RFC4103], T.140 data channels do not use redundant transmission of 445 text. The reason for this is that the T.140 data channel achieves 446 robust transmission by using the "reliable" mode of the data channel. 448 Data sending and reporting procedures conform to [T140]. 450 See Section 8 of [T140] for coding details. 452 NOTE: The T.140 coding details contain information on optional 453 control codes for controlling the presentation which may not be 454 supported by the presentation level of the receiving application. 455 The receiving application is expected to handle reception of such 456 T.140 control codes appropriately (e.g. ignore and skip them) even if 457 their effect on the presentation is not supported. 459 5.3. Data Buffering 461 As described in [T140], buffering can be used to reduce overhead, 462 with the maximum buffering time being 500 ms. It can also be used 463 for staying within the maximum character transmission rate 464 (Section 4.2), if such has been provided by the peer. 466 An implementation needs to take the user requirements for smooth flow 467 and low latency in real-time text conversation into consideration 468 when assigning a buffer time. It is RECOMMENDED to use the default 469 transmission interval of 300 milliseconds [RFC4103], or lower, for 470 T.140 data channels. 472 5.4. Loss of T140blocks 474 In case of network failure or congestion, T.140 data channels might 475 fail and get torn down. If this happens but the session sustains, it 476 is RECOMMENDED that implementations tries to reestablish the T.140 477 data channels. If reestablishment of the T.140 data channel is 478 successful, an implementation MUST evaluate if any T140blocks were 479 lost. Retransmission of already successfully transmitted T140blocks 480 MUST be avoided, and missing text markers [T140ad1] SHOULD be 481 inserted in the received data stream where loss is detected or 482 suspected. 484 NOTE: If the SCTP association [RFC4960] used to realize the T.140 485 data channel fails and gets torn down, it needs to be re-established 486 before the T.140 data channel can be reestablished. The procedure 487 after the reestablishment of the T.140 data channel defined in this 488 section apply no matter if only the T.140 data channel, or the whole 489 SCTP association, got torn down. 491 5.5. Multi-party Considerations 493 If an implementation needs to support multi-party scenarios, the 494 implementation needs to support multiple simultaneous T.140 data 495 channels, one for each remote party. At the time of writing this 496 document, this is true even in scenarios where each participant 497 communicates via a centralized conference server. The reason is 498 that, unlike RTP media, WebRTC data channels and the T.140 protocol 499 do not support the indication of the source of T.140 data. The SDP 500 'dcmap' attribute label attribute parameter (Section 4.1) can be used 501 by the offerer to provide additional information about each T.140 502 data channel, and help implementations to distinguish between them. 504 NOTE: Future extensions to T.140, or to the T140block, might allow 505 indicating the source of T.140 data, in which case it might be 506 possible to use a single T.140 data channel to transport data from 507 multiple remote sources. The usage of a single T.140 data channel, 508 without any protocol extensions, would require the conference server 509 to only forward real-time text from one source at any given time, and 510 e.g., include human readable text labels in the real-time text stream 511 that indicates the source whenever the conference server switches the 512 source. This would allow the receiver to present real-time text from 513 different sources separated. The procedures of such mechanism is 514 outside the scope of this document. 516 6. Gateway Considerations 518 A number of real-time text transports and protocols have been defined 519 for both packet-switched and circuit-switched networks. Many are 520 based on the ITU-T T.140 protocol on application and presentation 521 level [T140]. At the time of writing this document, some mechanisms 522 are no longer used, as the technologies they use have been obsoleted, 523 while others are still in use. 525 When performing interworking between T.140 data channels and real- 526 time text in other transports and protocols, a number of factors need 527 to be considered. At the time of writing this document, the most 528 common IP-based real-time text transport is the RTP based mechanism 529 defined in [RFC4103]. While this document does not define a complete 530 interworking solution, this list below provides some guidance and 531 considerations to take into account when designing a gateway for 532 interworking between T.140 data channels and RTP-based T.140 533 transport: 535 o For each T.140 data channel there is an RTP stream for real-time 536 text [RFC4103]. Redundancy is by default declared and used on the 537 RTP stream. There is no redundancy on the T.140 data channel, but 538 the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] is set 539 on it. 540 o During a normal text flow, T140blocks received from one network 541 are forwarded towards the other network. Keep-alive traffic is 542 implicit on the T.140 data channel. A gateway might have to 543 extract keep-alives from incoming RTP streams, and MAY generate 544 keep-alives on outgoing RTP streams. 545 o If the gateway detects or suspects loss of data on the RTP stream, 546 and the lost data has not been retrieved using a redundancy 547 mechanism, the gateway SHOULD insert the T.140 missing text marker 548 [T140ad1] in the data sent on the outgoing T.140 data channel. 549 o If the gateway detects that the T.140 data channel has failed and 550 got torn down, once the data channel has been reestablished the 551 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 552 the data sent on the outgoing RTP stream if it detects or suspects 553 that data sent by the remote T.140 data channel endpoint was lost. 554 o If the gateway detects that the T.140 data channel has failed and 555 got torn down, once the data channel has been reestablished the 556 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 557 the data sent on the outgoing T.140 data channel if it detects or 558 suspects that data sent or to be sent on the T.140 data channel 559 was lost during the failure. 560 o The gateway MUST indicate the same text transmission direction 561 (Section 4.2.3) on the T.140 data channel and the RTP stream. 563 NOTE: In order for the gateway to insert a missing text marker, or to 564 perform other actions that require that the gateway has access to the 565 T.140 data, the T.140 data cannot be encrypted end-to-end between the 566 T.140 data channel endpoint and the RTP endpoint. At the time of 567 writing this document, no mechanism to provide such end-to-end 568 encryption is defined. 570 7. Update to RFC 8373 572 This document updates RFC 8373 [RFC8373], by defining how the SDP 573 hlang-send and hlang-recv attributes are used for the "application/ 574 webrtc-datachannel" media type. 576 SDP offerers and answerers MUST NOT include the attributes directly 577 in the m= section associated with the 'application/webrtc- 578 datachannel' media type. Instead, the attributes MUST be associated 579 with individual data channels, using the SDP 'dcsa' attribute. A 580 specification that defines a subprotocol that uses the attributes 581 MUST specify the modality for that subprotocol, or how to retrieve 582 the modality if the subprotocol supports multiple modalities. The 583 subprotocol is indicated using the SDP 'dcmap' attribute. 585 8. Security Considerations 587 The generic security considerations for WebRTC data channels are 588 defined in [I-D.ietf-rtcweb-data-channel]. As data channels are 589 always encrypted by design, the T.140 data channels will also be 590 encrypted. 592 The generic security considerations for the SDP-based external 593 negotiation method are defined in 594 [I-D.ietf-mmusic-data-channel-sdpneg]. There are no additional T.140 595 data channel specific security considerations. 597 9. IANA considerations 599 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 600 RFC number of this document.] 602 9.1. Subprotocol Identifier t140 604 This document adds the subprotocol identifier "t140" to the 605 "WebSocket Subprotocol Name Registry" as follows: 607 +--------------------------+-------------+ 608 | Subprotocol Identifier: | t140 | 609 | Subprotocol Common Name: | ITU-T T.140 | 610 | Subprotocol Definition: | RFCXXXX | 611 | Reference: | RFCXXXX | 612 +--------------------------+-------------+ 614 9.2. SDP fmtp Attribute 616 This document defines the usage of the SDP 'fmtp' attribute, if this 617 attribute is included in an SDP 'dcsa' attribute and associated with 618 an T.140 real-time text session over a WebRTC data channel. The 619 usage is defined in Section 4.2.1. 621 The usage level "dcsa(t140)" is added to the IANA registration of the 622 SDP 'fmtp' attribute as follows: 624 +-----------------------+-------------------------------------------+ 625 | Contact name: | IESG | 626 | Contact email: | iesg@ietf.org | 627 | Attribute name: | fmtp | 628 | Usage level: | dcsa(t140) | 629 | Purpose: | Indicate the maximum transmission rate | 630 | | that an endpoint is willing to receive on | 631 | | a T.140 data channel. | 632 | Reference: | RFCXXXX | 633 +-----------------------+-------------------------------------------+ 635 9.3. SDP Language Attributes 637 This document modifies the usage of the SDP 'hlang-send' and 'hlang- 638 recv' attributes, if these attributes are included in SDP 'dcsa' 639 attributes associated with an T.140 data channel. The modified usage 640 is described in Section 4.2.2. 642 The usage level "dcsa(t140)" is added to the IANA registration of the 643 SDP 'hlang-send' attribute as follows: 645 +-----------------------+-------------------------------------------+ 646 | Contact name: | IESG | 647 | Contact email: | iesg@ietf.org | 648 | Attribute name: | hlang-send | 649 | Usage level: | dcsa(t140) | 650 | Purpose: | Negotiate the language to be used on a | 651 | | T.140 data channel. | 652 | Reference: | RFCXXXX | 653 +-----------------------+-------------------------------------------+ 655 The usage level "dcsa(t140)" is added to the IANA registration of the 656 SDP 'hlang-recv' attribute as follows: 658 +-----------------------+-------------------------------------------+ 659 | Contact name: | IESG | 660 | Contact email: | iesg@ietf.org | 661 | Attribute name: | hlang-recv | 662 | Usage level: | dcsa(t140) | 663 | Purpose: | Negotiate the language to be used on a | 664 | | T.140 data channel. | 665 | Reference: | RFCXXXX | 666 +-----------------------+-------------------------------------------+ 668 9.4. SDP Media Direction Attributes 670 This document modifies the usage of the SDP 'sendonly', 'recvonly', 671 'sendrecv' and 'inactive' attributes, if these attributes are 672 included in SDP 'dcsa' attributes associated T.140 data channel. The 673 modified usage is described in Section 4.2.3. 675 The usage level "dcsa(t140)" is added to the IANA registration of the 676 SDP 'sendonly' attribute as follows: 678 +-----------------------+-------------------------------------------+ 679 | Contact name: | IESG | 680 | Contact email: | iesg@ietf.org | 681 | Attribute name: | sendonly | 682 | Usage level: | dcsa(t140) | 683 | Purpose: | Negotiate the direction in which real- | 684 | | time text can be sent on a T.140 data | 685 | | channel. | 686 | Reference: | RFCXXXX | 687 +-----------------------+-------------------------------------------+ 689 The usage level "dcsa(t140)" is added to the IANA registration of the 690 SDP 'recvonly' attribute as follows: 692 +-----------------------+-------------------------------------------+ 693 | Contact name: | IESG | 694 | Contact email: | iesg@ietf.org | 695 | Attribute name: | recvonly | 696 | Usage level: | dcsa(t140) | 697 | Purpose: | Negotiate the direction in which real- | 698 | | time text can be sent on a T.140 data | 699 | | channel. | 700 | Reference: | RFCXXXX | 701 +-----------------------+-------------------------------------------+ 703 The usage level "dcsa(t140)" is added to the IANA registration of the 704 SDP 'sendrecv' attribute as follows: 706 +-----------------------+-------------------------------------------+ 707 | Contact name: | IESG | 708 | Contact email: | iesg@ietf.org | 709 | Attribute name: | sendrecv | 710 | Usage level: | dcsa(t140) | 711 | Purpose: | Negotiate the direction in which real- | 712 | | time text can be sent on a T.140 data | 713 | | channel. | 714 | Reference: | RFCXXXX | 715 +-----------------------+-------------------------------------------+ 716 The usage level "dcsa(t140)" is added to the IANA registration of the 717 SDP 'inactive' attribute as follows: 719 +-----------------------+-------------------------------------------+ 720 | Contact name: | IESG | 721 | Contact email: | iesg@ietf.org | 722 | Attribute name: | inactive | 723 | Usage level: | dcsa(t140) | 724 | Purpose: | Negotiate the direction in which real- | 725 | | time text can be sent on a T.140 data | 726 | | channel. | 727 | Reference: | RFCXXXX | 728 +-----------------------+-------------------------------------------+ 730 10. Acknowledgements 732 This document is based on an earlier Internet draft edited by Keith 733 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 735 Thomas Belling provided useful comments on the initial (pre- 736 submission) version of the draft. Gunnar Hellstrom provided comments 737 and text on the draft. Paul Kyzivat and Bernard Aboba provided 738 comments on the draft. 740 11. References 742 11.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, 746 DOI 10.17487/RFC2119, March 1997, . 749 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 750 with Session Description Protocol (SDP)", RFC 3264, 751 DOI 10.17487/RFC3264, June 2002, . 754 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 755 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 756 . 758 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 759 RFC 4960, DOI 10.17487/RFC4960, September 2007, 760 . 762 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 763 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 764 May 2017, . 766 [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time 767 Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, 768 . 770 [I-D.ietf-mmusic-rfc4566bis] 771 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 772 Session Description Protocol", draft-ietf-mmusic- 773 rfc4566bis-37 (work in progress), August 2019. 775 [I-D.ietf-rtcweb-data-channel] 776 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 777 Channels", draft-ietf-rtcweb-data-channel-13 (work in 778 progress), January 2015. 780 [I-D.ietf-mmusic-data-channel-sdpneg] 781 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 782 Even, "SDP-based Data Channel Negotiation", draft-ietf- 783 mmusic-data-channel-sdpneg-28 (work in progress), May 784 2019. 786 [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), Protocol for 787 multimedia application text conversation", February 1998. 789 [T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 - (02/2000), 790 Protocol for multimedia application text conversation", 791 February 2000. 793 11.2. Informative References 795 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 796 A., Peterson, J., Sparks, R., Handley, M., and E. 797 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 798 DOI 10.17487/RFC3261, June 2002, . 801 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 802 Jacobson, "RTP: A Transport Protocol for Real-Time 803 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 804 July 2003, . 806 [I-D.ietf-rtcweb-data-protocol] 807 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 808 Establishment Protocol", draft-ietf-rtcweb-data- 809 protocol-09 (work in progress), January 2015. 811 Author's Address 813 Christer Holmberg 814 Ericsson 815 Hirsalantie 11 816 Jorvas 02420 817 Finland 819 Email: christer.holmberg@ericsson.com