idnits 2.17.1 draft-ietf-mmusic-t140-usage-data-channel-06.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 (September 30, 2019) is 1670 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 6' is mentioned on line 245, but not defined ** 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 (~~), 3 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) September 30, 2019 5 Intended status: Standards Track 6 Expires: April 2, 2020 8 T.140 Real-time Text Conversation over WebRTC Data Channels 9 draft-ietf-mmusic-t140-usage-data-channel-06 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 April 2, 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. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3 56 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4 58 4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5 59 4.2.1. Maximum Character Transmission Rate . . . . . . . . . 5 60 4.2.2. Real-time Text Conversation Languages . . . . . . . . 6 61 4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 6 62 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 10 64 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10 65 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11 66 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11 67 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11 68 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12 69 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14 74 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 14 75 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 14 76 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 15 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 11.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The ITU-T Protocol for multimedia application text conversation 86 (Recommendation ITU-T T.140) [T140] defines a protocol for text 87 conversation, also known as real-time text. The native transport for 88 IP networks is the "RTP Payload for Text Conversation" [RFC4103] 89 mechanism, based on the Real-time Transport Protocol (RTP) [RFC4103]. 91 This document specifies how a WebRTC data channel 92 [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism 93 for T.140, and how the SDP offer/answer mechanism 94 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such 95 data channel. 97 In this document, a T.140 data channel refers to a WebRTC data 98 channel for which the instantiated sub-protocol is "t140", and where 99 the channel is negotiated using the SDP-based external negotiation 100 method [I-D.ietf-mmusic-data-channel-sdpneg]. 102 NOTE 1: This WebRTC term of a "T.140 data channel" is actually 103 synonym to the originally introduced concept of a "T.140 data 104 channel" for the T.140 protocol, see Section 4.3 of [T140]. 106 NOTE 2: The decision to transport realtime text over a data channel, 107 instead of using RTP based transport [RFC4103], in WebRTC is 108 constituted by use-case "U-C 5: Realtime text chat during an audio 109 and/or video call with an individual or with multiple people in a 110 conference", see Section 3.2 of [I-D.ietf-rtcweb-data-channel]. 112 The brief notation "T.140" is used as a synonym for the text 113 conversation protocol according to [T140]. 115 Section 3 defines the generic data channel properties for a T.140 116 data channel, and Section 4 defines how they are conveyed in an SDP 117 dcmap attribute. While this document defines how to establish a 118 T.140 data channel using the SDP-based external negotiation method 119 [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway 120 considerations defined in Section 3, Section 5 and Section 6 of this 121 document can also be applied when a T.140 data channel is established 122 using another mechanism (e.g., the mechanism defined in 123 [I-D.ietf-rtcweb-data-protocol]). Section 5 of 124 [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the 125 SDP dcmap attribute parameters and the protocol parameters used in 126 [I-D.ietf-rtcweb-data-protocol]. 128 This document is based on an earlier Internet draft edited by Keith 129 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 131 2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 3. WebRTC Data Channel Considerations 141 The following WebRTC data channel property values 142 [I-D.ietf-rtcweb-data-channel] apply to a T.140 data channel: 144 +--------------------------+-------------------------------+ 145 | Subprotocol Identifier | t140 | 146 | Transmission reliability | reliable | 147 | Transmission order | in-order | 148 | Label | See Section 4.1 and Section 6 | 149 +--------------------------+-------------------------------+ 151 NOTE: T.140 requires the transport channel to provide transmission of 152 real-time text without duplication and in original order. Therefore, 153 T.140 does not specify reliable and ordered transmission of T.140 154 data on the application layer. Instead, when RTP based transport is 155 used, the RTP sequence number is used to detect packet loss and out- 156 of-order packets, and a redundancy mechanism using the RTP timestamp 157 is used to achieve reliable delivery of T.140 data. By using the 158 WebRTC data channel reliable and in-order transmission features 159 [I-D.ietf-rtcweb-data-channel] for the T.140 data channel, there is 160 no need for a redundancy mechanism or a mechanism to detect data loss 161 and out-of-order delivery on the application level. The latency 162 characteristics of the T.140 data channel is also regarded to be 163 sufficient to meet the application requirements of T.140. 165 4. SDP Considerations 167 The generic SDP considerations, including the SDP Offer/Answer 168 procedures, for negotiating a WebRTC data channel are defined in 169 [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP 170 considerations that are specific to a T.140 data channel. 172 4.1. Use of dcmap Attribute 174 An offerer and answerer MUST, in each offer and answer, include an 175 SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the 176 SDP media descripton (m= section) [I-D.ietf-mmusic-rfc4566bis] 177 describing the SCTP association [RFC4960] used to realize the T.140 178 data channel. 180 The offerer and answerer MUST include the subprotocol attribute 181 parameter, with a "t140" parameter value, in the 'dcmap' attribute 182 value. 184 The offerer and answerer MAY include the priority attribute parameter 185 and the label attribute parameter in the 'dcmap' attribute value. If 186 the offerer includes a label attribute parameter, the answerer MUST 187 NOT change the value in the answer. 189 NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data 190 channel is negotied using the mechanism defined in 191 [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value 192 has to be the same in both directions. That rule also applies to 193 data channels negotiated using the mechanism defined in this 194 document. 196 The offerer and answerer MUST NOT include the max-retr and max-time 197 attribute parameters in the 'dcmap' attribute. 199 If the ordered attribute parameter is included in the 'dcmap' 200 attribute, it MUST be assigned the value 'true'. 202 Below is an example of the 'dcmap' attribute for a T.140 data channel 203 with stream id=3 and without any label: 205 a=dcmap:3 subprotocol="t140" 207 4.2. Use of dcsa Attribute 209 An offerer and answerer MAY, in each offer and answer, include an SDP 210 'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m= 211 section describing the SCTP association used to realize the T.140 212 data channel. 214 If an offerer or answerer receives a 'dcsa' attribute that contains 215 an SDP attribute which usage has not been defined for a T.140 data 216 channel, the offerer or answerer should ignore the 'dcsa' attribute, 217 following the rules in [I-D.ietf-mmusic-data-channel-sdpneg]. 219 4.2.1. Maximum Character Transmission Rate 221 A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to 222 indicate a maximum character transmission rate [RFC4103]. The 'cps' 223 attribute parameter is used to indicate the maximum character 224 transmission rate that the endpoint that includes the attribute is 225 able to receive, and the value is used as a mean value in characters 226 per second over any 10-second interval. 228 If the 'fmtp' attribute is included, the 'format' attribute parameter 229 MUST be set to "-". 231 If the 'fmtp' attribute is not included, it indicates that no maximum 232 character transmission rate is indicated. It does not mean that the 233 default value of 30 applies [RFC4103]. 235 The offerer and answerer MAY modify the 'cps' attribute parameter 236 value in subsequent offers and answers. 238 This document does not define any other usage of the 'fmtp' attribute 239 for a T.140 channel. If an offerer or answerer receives a 'dcsa' 240 attribute that contains 'fmtp' attribute that is not according to the 241 procedure above the offerer or answerer MUST discard the 'dcsa' 242 attribute. 244 NOTE: The 'cps' attribute parameter is especially useful when a T.140 245 data channel endpoint is acting as a gateway [Section 6] and is 246 interworking with a T.140 transport mechanism that have restrictions 247 on how many characters can be sent per second. 249 4.2.2. Real-time Text Conversation Languages 251 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' 252 attributes [RFC8373] to negotiate the language to be used for the 253 real-time text conversation. 255 For a T.140 data channel, the modality is "written" [RFC8373]. 257 4.2.3. Real-time Text Direction 259 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 260 'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to 261 negotite the direction in which text can be transmitted in a real- 262 time text conversation. 264 NOTE: A WebRTC data channel is always bi-directional. The usage of 265 the 'dcsa' attribute only affects the direction in which 266 implementations are allowed to transmit text on a T.140 data channel. 268 The offer/answer rules for the direction attributes are based on the 269 rules for unicast streams defined in [RFC3264], as described below. 270 Note that the rules only apply to the direction attributes. 272 Session level direction attributes [I-D.ietf-mmusic-rfc4566bis] have 273 no impact on a T.140 data channel. An offerer and answerer MUST mark 274 the direction of the text by sending a direction attribute inside 275 'dcsa' attribute. 277 4.2.3.1. Negotiate Text Direction 279 4.2.3.1.1. Generating an Offer 281 If the offerer wishes to both send or receive text on a T.140 data 282 channel, it SHOULD mark the data channel as sendrecv with a 283 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does 284 not explicitly mark the data channel, a 'sendrecv' attribute inside a 285 'dcsa' attribute is implicitly applied. 287 If the offerer wishes to only send text on a T.140 data channel, it 288 MUST mark the data channel as sendonly with a 'sendonly' attribute 289 inside a 'dcsa' attribute. 291 If the offerer wishes to only receive text on a T.140 data channel, 292 it MUST mark the data channel as recvonly with a 'recvonly' attribute 293 inside a 'dcsa' attribute. 295 If the offerer wishes to neither send or receive text on a T.140 data 296 channel, it MUST mark the data channel as inactive with a 'inactive' 297 attribute inside a 'dcsa' attribute. 299 If the offerer has marked a data channel as sendrecv (implicit or 300 explicit) or recvonly, it MUST be prepared to receive T.140 data as 301 soon as the state of the T.140 data channel allows it. 303 When the offerer receives an answer to the offer, if the answerer has 304 marked a data channel as sendrecv (implicit or explicit) or recvonly 305 in the answer, the offerer can start to send T.140 data as soon as 306 the state of the T.140 data channel allows it. If the answerer has 307 marked the data channel as inactive or sendonly, the offerer MUST NOT 308 send any T.140 data. 310 As the answerer implementation might not support the procedures in 311 this section, if the answerer has not marked the direction of a T.140 312 data channel in accordance with the procedures above, it is 313 RECOMMENDED that the offerer does not process that as an error 314 situation, but rather assume that the answerer might both send and 315 receive T.140 data on the data channel. 317 4.2.3.1.2. Generating an Answer 319 When the answerer accepts an offer, and marks the direction of the 320 text in the corresponding answer, the marking is based on the marking 321 (explicit or implicit) in the offer. 323 If the offerer marked the data channel as sendrecv (implicitly or 324 explicitly), the answerer MUST mark the data channel as sendrecv, 325 sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 326 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. 327 If the answerer does not explicitly mark the data channel, a 328 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. 330 If the offerer marked the data channel as sendonly, the answerer MUST 331 mark the data channel as recvonly or inactive with a 'recvonly' 332 respective 'inactive' attribute inside a 'dcsa' attribute. 334 If the offerer marked the data channel as recvonly, the answerer MUST 335 mark the data channel as sendonly or inactive with a 'sendonly' 336 respective 'inactive' attribute inside a 'dcsa' attribute. 338 If the offerer marked the data channel as inactive, the answerer MUST 339 mark the data channel as inactive with a 'inactive' attribute inside 340 a 'dcsa' attribute. 342 If the answerer has marked a data channel as sendrecv or recvonly, it 343 MUST be prepared to receive data as soon as the state of the T.140 344 data channel allows transmission of data. 346 4.2.3.2. 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 351 Section 4.2.3.1.1. If the answerer accepts the offer it follows the 352 procedures in Section 4.2.3.1.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, and 360 the default text transmission direction "sendrecv", apply. 362 Offer: 364 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 365 c=IN IP6 2001:db8::3 366 a=max-message-size:1000 367 a=sctp-port 5000 368 a=dcmap:1 label="ACME customer service";subprotocol="t140" 369 a=dcsa:1 fmtp:- cps=20 370 a=dcsa:1 hlang-send:es eo 371 a=dcsa:1 hlang-recv:es eo 373 Answer: 375 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 376 c=IN IP6 2001:db8::1 377 a=max-message-size:1000 378 a=sctp-port 5000 379 a=dcmap:1 label="ACME customer service";subprotocol="t140" 380 a=dcsa:1 fmtp:- cps=20 381 a=dcsa:1 hlang-send:eo 382 a=dcsa:1 hlang-recv:eo 384 Below is an example of an m= section of an offer for a T.140 data 385 channel where the offerer wishes to only receive real-time text, and 386 an m= section in the associated answer indicating that the answerer 387 will only send real-time text. No maximum character transmission 388 rate is indicated. No language to be used for the real-time text 389 conversation is indicated. 391 Offer: 393 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 394 c=IN IP6 2001:db8::3 395 a=max-message-size:1000 396 a=sctp-port 5000 397 a=dcmap:1 label="ACME customer service";subprotocol="t140" 398 a=dcsa:1 recvonly 400 Answer: 402 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 403 c=IN IP6 2001:db8::1 404 a=max-message-size:1000 405 a=sctp-port 5000 406 a=dcmap:1 label="ACME customer service";subprotocol="t140" 407 a=dcsa:1 sendonly 409 5. T.140 Considerations 411 5.1. Session Layer Functions 413 Section 6.1 of [T140] describes the generic T.140 session control 414 functions at high-level and a signalling protocol independent manner. 415 The list below describes how the functions are realized when using a 416 T.140 data channel. 418 o Prepare session: An endpoint can indicate its support of T.140 419 data channels using signalling specific means (e.g., using SIP 420 OPTIONS [RFC3261]), or by indicating the support in an offer or 421 answer (Section 4) 422 o Initiate session: An offer used to request the establishment of a 423 T.140 data channel (Section 4) 424 o Accept session: An answer used to accept a request to establish a 425 T.140 data channel (Section 4) 426 o Deny session: An answer used to reject a request to establish a 427 T.140 data channel, using the generic procedures for rejecting a 428 data channel [I-D.ietf-mmusic-data-channel-sdpneg] 429 o Disconnect session: An offer or answer used to disable a 430 previously established T.140 data channel, using the generic 431 procedures for closing a data channel 432 [I-D.ietf-mmusic-data-channel-sdpneg] 433 o Data: Data sent on an established T.140 data channel (Section 5.2) 435 5.2. Data Encoding and Sending 437 T.140 text is encoded and framed as T140blocks [RFC4103]. 439 Each T140block is sent on the SCTP stream [RFC4960] used to realize 440 the T.140 data channel using standard T.140 transmission procedures 441 [T140]. One or more T140blocks can be sent in a single SCTP user 442 message [RFC4960]. Unlike RTP based transport for realtime text 443 [RFC4103], T.140 data channels do not use redundant transmission of 444 text. The reason for this is that the T.140 data channel achieves 445 robust transmission by using the "reliable" mode of the data channel. 447 Data sending and reporting procedures conform to [T140]. 449 See Section 8 of [T140] for coding details. 451 5.3. Data Buffering 453 As described in [T140], buffering can be used to reduce overhead, 454 with the maximum buffering time being 500 ms. It can also be used 455 for staying within the maximum character transmission rate 456 (Section 4.2), if such has been provided by the peer. 458 An implementation needs to take the user requirements for smooth flow 459 and low latency in real-time text conversation into consideration 460 when assigning a buffer time. It is RECOMMENDED to use the default 461 transmission interval of 300 milliseconds [RFC4103], or lower, for 462 T.140 data channels. 464 5.4. Loss of T140blocks 466 In case of network failure or congestion, T.140 data channels might 467 fail and get torn down. If this happens but the session sustains, it 468 is RECOMMENDED that a low number of retries are made to reestablish 469 the T.140 data channels. If reestablishment of the T.140 data 470 channel is successful, an implementation MUST evaluate if any 471 T140blocks were lost. Retransmission of already successfully 472 transmitted T140blocks MUST be avoided, and missing text markers 473 [T140ad1] SHOULD be inserted in the received data stream where loss 474 is detected or suspected. 476 NOTE: If the the SCTP association [RFC4960] used to realize the T.140 477 data channel fails and get torn down, it needs to be re-established 478 before the T.140 data channel can be reestablished. The procedure 479 after the reestablishment of the T.140 data channel defined in this 480 section apply no matter if only the T.140 data channel, or the whole 481 SCTP association, got torn down. 483 5.5. Multi-party Considerations 485 If an implementation needs to support multi-party scenarios, the 486 implementation needs to support multiple simultaneous T.140 data 487 channels, one for each remote party. At the time of writing this 488 document, this is true even in scenarios where each participant 489 communicate via a centralized conference server. The reason is that, 490 unlike RTP media, WebRTC data channels and the T.140 protocol do not 491 support the indication of the source of T.140 data. The SDP 'dcmap' 492 attribute label attribute parameter (Section 4.1) can be used by the 493 offerer to provide additional information about each T.140 data 494 channel, and help implementations to distinguish between them. 496 NOTE: Future extensions to T.140, or to the T140block, might allow 497 indicating the source of T.140 data, in which case it might be 498 possible to use a single T.140 data channel to transport data from 499 multiple remote sources. That is useful for multi-party aware 500 clients that are able present the conference in a way that is adapted 501 to user expectations regarding presentation style and real-time 502 performance. Conference mixers that use a single T.140 data channel 503 to transmit real-time text towards clients might, without any 504 protocol extensions, produce a multi-party presentation completely 505 within the text stream, and with limitations in real-time performance 506 and presentation style. 508 6. Gateway Considerations 510 A number of real-time text transports and protocols have been defined 511 for both packet switched and circuit switched networks. Many are 512 based on the ITU-T T.140 protocol on application and presentation 513 level [T140]. At the time of writing this document, some mechanisms 514 are no longer used, as the technologies they use have been obsoleted 515 etc, while others are still in use. 517 When performing interworking between T.140 data channels and real- 518 time text in other transports and protocols, a number of factors need 519 to be considered. At the time of writing this document, the most 520 common IP-based real-time text transport is the RTP based mechanism 521 defined in [RFC4103]. While this document does not define a complete 522 interworking solution, this list below provides some guidance and 523 considerations to take into account when designing a gateway for 524 interworking between T.140 data channels and RTP-based T.140 525 transport: 527 o For each T.140 data channel there is an RTP stream for real-time 528 text [RFC4103] . Redundancy is by default declared and used on 529 RTP stream. On the T.140 data channel there is no redundancy, but 530 the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of 531 T.140 the data channel is set. 532 o During a normal text flow, T140blocks received from one network 533 are forwarded towards the other network. Keep-alive traffic is 534 implicit on the T.140 data channel. A gateway might have to 535 extract keep-alives from incoming RTP streams, and MAY generate 536 keep-alives on outgoing RTP streams. 537 o If the gateway detects or suspects loss of data on the RTP stream, 538 the gateway SHOULD insert the T.140 missing text marker [T140ad1] 539 in the data sent on the outgoing T.140 data channel. 540 o If the gateway detects that the T.140 data channel has failed and 541 got torn down, once the data channel has been reestablished the 542 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 543 the data sent on the outgoing RTP stream if it detects or suspects 544 that data on the T.140 data channel was lost. 545 o The gateway MUST indicate the same text transmission direction 546 (Section 4.2.3) on the T.140 data channel and the RTP stream. 548 NOTE: In order for the gateway to insert a missing text marker, or to 549 perform other actions that require that the gateway has access to the 550 T.140 data, the T.140 data cannot be encrypted end-to-end between the 551 T.140 data channel endpoint and the RTP endpoint. At the time of 552 writing this document, a mechanism to provide such end-to-end 553 encryption has not been defined. 555 7. Update to RFC 8373 557 This document updates RFC 8373, by defining how the SDP hlang-send 558 and hlang-recv attributes are used for the "application/webrtc- 559 datachannel" media type. 561 SDP offerers and answerers MUST NOT include the attributes directly 562 in the m= section associated with the 'application/webrtc- 563 datachannel' media type. Instead, the attributes MUST be associated 564 with individual data channels, using the SDP 'dcsa' attribute. A 565 specification that defines a subprotocol that uses the attributes 566 MUST specify the modality for that subprotocol, or how to retreive 567 the modality if the subprotocol supports multiple modalities. 569 8. Security Considerations 571 The generic security considerations for WebRTC data channels are 572 defined in [I-D.ietf-rtcweb-data-channel]. As data channels are 573 always encrypted by design, the T.140 data channels will also be 574 encrypted. 576 The generic security considerations for the SDP-based external 577 negotiation method are defined in 578 [I-D.ietf-mmusic-data-channel-sdpneg]. 580 9. IANA considerations 582 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 583 RFC number of this document.] 585 9.1. Subprotocol Identifier t140 587 This document adds the subprotocol identifier "t140" to the 588 "WebSocket Subprotocol Name Registry" as follows: 590 +--------------------------+-------------+ 591 | Subprotocol Identifier: | t140 | 592 | Subprotocol Common Name: | ITU-T T.140 | 593 | Subprotocol Definition: | RFCXXXX | 594 | Reference: | RFCXXXX | 595 +--------------------------+-------------+ 597 9.2. SDP fmtp Attribute 599 This document modifies the usage of the SDP 'fmtp' attribute, if this 600 attribute is included in an SDP 'dcsa' attribute and associated with 601 an T.140 real-time text session over a WebRTC data channel. The 602 modified usage is described in Section 4.2.1. 604 The usage level "dcsa(t140)" is added to the IANA registration of the 605 SDP 'fmtp' attribute as follows: 607 +-----------------------+-------------------------------------------+ 608 | Contact name: | MMUSIC Chairs | 609 | Contact email: | mmusic-chairs@ietf.org | 610 | Attribute name: | fmtp | 611 | Usage level: | dcsa(t140) | 612 | Purpose: | Indicate the maximum transmission rate | 613 | | that an endpoint is willing to recive on | 614 | | a T.140 data channel. | 615 | Reference: | RFCXXXX | 616 +-----------------------+-------------------------------------------+ 618 9.3. SDP Language Attributes 620 This document modifies the usage of the SDP 'hlang-send' and 'hlang- 621 recv' attributes, if these attributes are included in SDP 'dcsa' 622 attributes associated with an T.140 data channel. The modified usage 623 is described in Section 4.2.2. 625 The usage level "dcsa(t140)" is added to the IANA registration of the 626 SDP 'hlang-send' attribute as follows: 628 +-----------------------+-------------------------------------------+ 629 | Contact name: | MMUSIC Chairs | 630 | Contact email: | mmusic-chairs@ietf.org | 631 | Attribute name: | hlang-send | 632 | Usage level: | dcsa(t140) | 633 | Purpose: | Negotiate the language to be used on a | 634 | | T.140 data channel. | 635 | Reference: | RFCXXXX | 636 +-----------------------+-------------------------------------------+ 638 The usage level "dcsa(t140)" is added to the IANA registration of the 639 SDP 'hlang-recv' attribute as follows: 641 +-----------------------+-------------------------------------------+ 642 | Contact name: | MMUSIC Chairs | 643 | Contact email: | mmusic-chairs@ietf.org | 644 | Attribute name: | hlang-recv | 645 | Usage level: | dcsa(t140) | 646 | Purpose: | Negotiate the language to be used on a | 647 | | T.140 data channel. | 648 | Reference: | RFCXXXX | 649 +-----------------------+-------------------------------------------+ 651 9.4. SDP Media Direction Attributes 653 This document modifies the usage of the SDP 'sendonly', 'recvonly', 654 'sendrecv' and 'inactive' attributes, if these attributes are 655 included in SDP 'dcsa' attributes associated T.140 data channel. The 656 modified usage is described in Section 4.2.3. 658 The usage level "dcsa(t140)" is added to the IANA registration of the 659 SDP 'sendonly' attribute as follows: 661 +-----------------------+-------------------------------------------+ 662 | Contact name: | MMUSIC Chairs | 663 | Contact email: | mmusic-chairs@ietf.org | 664 | Attribute name: | sendonly | 665 | Usage level: | dcsa(t140) | 666 | Purpose: | Negotiate the direction in which real- | 667 | | time text can be sent on a T.140 data | 668 | | channel. | 669 | Reference: | RFCXXXX | 670 +-----------------------+-------------------------------------------+ 671 The usage level "dcsa(t140)" is added to the IANA registration of the 672 SDP 'recvonly' attribute as follows: 674 +-----------------------+-------------------------------------------+ 675 | Contact name: | MMUSIC Chairs | 676 | Contact email: | mmusic-chairs@ietf.org | 677 | Attribute name: | recvonly | 678 | Usage level: | dcsa(t140) | 679 | Purpose: | Negotiate the direction in which real- | 680 | | time text can be sent on a T.140 data | 681 | | channel. | 682 | Reference: | RFCXXXX | 683 +-----------------------+-------------------------------------------+ 685 The usage level "dcsa(t140)" is added to the IANA registration of the 686 SDP 'sendrecv' attribute as follows: 688 +-----------------------+-------------------------------------------+ 689 | Contact name: | MMUSIC Chairs | 690 | Contact email: | mmusic-chairs@ietf.org | 691 | Attribute name: | sendrecv | 692 | Usage level: | dcsa(t140) | 693 | Purpose: | Negotiate the direction in which real- | 694 | | time text can be sent on a T.140 data | 695 | | channel. | 696 | Reference: | RFCXXXX | 697 +-----------------------+-------------------------------------------+ 699 The usage level "dcsa(t140)" is added to the IANA registration of the 700 SDP 'inactive' attribute as follows: 702 +-----------------------+-------------------------------------------+ 703 | Contact name: | MMUSIC Chairs | 704 | Contact email: | mmusic-chairs@ietf.org | 705 | Attribute name: | inactive | 706 | Usage level: | dcsa(t140) | 707 | Purpose: | Negotiate the direction in which real- | 708 | | time text can be sent on a T.140 data | 709 | | channel. | 710 | Reference: | RFCXXXX | 711 +-----------------------+-------------------------------------------+ 713 10. Acknowledgements 715 This document is based on an earlier Internet draft edited by Keith 716 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 718 Thomas Belling provided useful comments on the initial (pre- 719 submission) version of the draft. Gunnar Hellstrom provided comments 720 and text on the draft. Paul Kyzivat and Bernard Aboba provided 721 comments on the draft. 723 11. References 725 11.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, . 732 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 733 with Session Description Protocol (SDP)", RFC 3264, 734 DOI 10.17487/RFC3264, June 2002, . 737 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 738 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 739 . 741 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 742 RFC 4960, DOI 10.17487/RFC4960, September 2007, 743 . 745 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 746 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 747 May 2017, . 749 [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time 750 Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, 751 . 753 [I-D.ietf-mmusic-rfc4566bis] 754 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 755 Session Description Protocol", draft-ietf-mmusic- 756 rfc4566bis-37 (work in progress), August 2019. 758 [I-D.ietf-rtcweb-data-channel] 759 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 760 Channels", draft-ietf-rtcweb-data-channel-13 (work in 761 progress), January 2015. 763 [I-D.ietf-mmusic-data-channel-sdpneg] 764 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 765 Even, "SDP-based Data Channel Negotiation", draft-ietf- 766 mmusic-data-channel-sdpneg-28 (work in progress), May 767 2019. 769 [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), "Protocol 770 for multimedia application text conversation"", February 771 1998. 773 [T140ad1] ITU-T, "Recommendation ITU-T.140 aEUR" Addendum 1 774 (02/2000), "Protocol for multimedia application text 775 conversation"", February 2000. 777 11.2. Informative References 779 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 780 A., Peterson, J., Sparks, R., Handley, M., and E. 781 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 782 DOI 10.17487/RFC3261, June 2002, . 785 [I-D.ietf-rtcweb-data-protocol] 786 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 787 Establishment Protocol", draft-ietf-rtcweb-data- 788 protocol-09 (work in progress), January 2015. 790 Author's Address 792 Christer Holmberg 793 Ericsson 794 Hirsalantie 11 795 Jorvas 02420 796 Finland 798 Email: christer.holmberg@ericsson.com