idnits 2.17.1 draft-ietf-mmusic-t140-usage-data-channel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 5, 2019) is 1694 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 5' is mentioned on line 187, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Possible downref: Non-RFC (?) normative reference: ref. 'T140' -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1' Summary: 2 errors (**), 0 flaws (~~), 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 5, 2019 5 Intended status: Standards Track 6 Expires: March 8, 2020 8 T.140 Real-time Text Conversation over WebRTC Data Channels 9 draft-ietf-mmusic-t140-usage-data-channel-00 11 Abstract 13 This document specifies how a WebRTC data channel can be used as a 14 transport mechanism for Real-time text using the ITU-T Protocol for 15 multimedia application text conversation (Recommendation ITU-T 16 T.140), and how the SDP offer/answer mechanism can be used to 17 negotiate such data channel, referred to as T.140 data channel. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 8, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 3 57 3.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 4 58 3.2.1. Maximum Character Transmission . . . . . . . . . . . 4 59 3.2.2. Real-time Text Conversation Languages . . . . . . . . 5 60 3.2.3. Real-time Text Direction . . . . . . . . . . . . . . 5 61 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 8 63 4.1. Session Layer Functions . . . . . . . . . . . . . . . . . 8 64 4.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 9 65 4.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 9 66 4.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 9 67 4.5. Multi-party Considerations . . . . . . . . . . . . . . . 9 68 5. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 69 6. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 12 73 8.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 12 74 8.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 12 75 8.4. SDP Media Direction Attributes . . . . . . . . . . . . . 13 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 10.2. Informative References . . . . . . . . . . . . . . . . . 16 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 The ITU-T Protocol for multimedia application text conversation 85 (Recommendation ITU-T T.140) [T140] defines a protocol for text 86 conversation, also known as real-time text. The native transport for 87 IP networks is the "RTP Payload for Text Conversation" [RFC4103] 88 mechanism, based on the Real-time Transport Protocol (RTP) [RFC4103]. 90 This document specifies how a WebRTC data channel 91 [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism 92 for T.140, and how the SDP offer/answer mechanism 93 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such 94 data channel. 96 In this document, a T.140 data channel refers to a WebRTC data 97 channel for which the instantiated sub-protocol is "t140", and where 98 the channel is negotiated using the SDP-based external negotiation 99 method [I-D.ietf-mmusic-data-channel-sdpneg]. 101 NOTE 1: This WebRTC term of a "T.140 data channel" is actually 102 synonym to the originally introduced concept of a "T.140 data 103 channel" for the T.140 protocol, see Section 4.3 of [T140]. 105 NOTE 2: The decision to transport realtime text over a data channel, 106 instead of using RTP based transport [RFC4103], in WebRTC is 107 constituted by use-case "U-C 5: Realtime text chat during an audio 108 and/or video call with an individual or with multiple people in a 109 conference", see Section 3.2 of [I-D.ietf-rtcweb-data-channel]. 111 The brief notation "T.140" is used as a synonym for the text 112 conversation protocol according to [T140]. 114 This document is based on an earlier Internet draft edited by Keith 115 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. SDP Considerations 127 The generic SDP considerations, including the SDP Offer/Answer 128 proceudres, for negotiating a WebRTC data channel are defined in 129 [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP 130 considerations that are specific to a T.140 data channel. 132 3.1. Use of dcmap Attribute 134 An offerer and answerer MUST, in each offer and answer, include an 135 SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the 136 SDP media descripton (m= section) [RFC4566] describing the SCTP 137 association [RFC4960] used to realize the T.140 data channel. 139 The offerer and answerer MUST include the subprotocol attribute 140 parameter, with a "t140" parameter value, in the 'dcmap' attribute 141 value. 143 The offerer and answerer MAY include the priority attribute parameter 144 and the label attribute parameter in the 'dcmap' attribute value. If 145 the offerer includes a label attribute parameter, the answerer MUST 146 NOT change the value in the answer. 148 NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data 149 channel is negotied using the mechanism defined in 150 [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value 151 has to be the same in both directions. That rule also applies to 152 data channels negotiated using the mechanism defined in this 153 document. 155 The offerer and answerer MUST NOT include the max-retr, max-time and 156 ordered attribute parameters in the 'dcmap' attribute. 158 Below is an example of the 'dcmap' attribute for a T.140 data channel 159 with stream=3 and without any label: 161 a=dcmap:3 subprotocol="t140" 163 3.2. Use of dcsa Attribute 165 An offerer and answerer MAY, in each offer and answer, include an SDP 166 'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m= 167 section describing the SCTP association used to realize the T.140 168 data channel. 170 3.2.1. Maximum Character Transmission 172 A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to 173 indicate a maximum character transmission rate [RFC4103]. The 'cps' 174 attribute parameter is used indicate the maximum character 175 transmission rate that the endpoint that includes the attribute is 176 able to receive. The 'format' attribute parameter is not used with 177 T.140 data channels, and MUST be set to "-". 179 If the 'fmtp' attribute is not included, it indicates that no maximum 180 character transmission rate is indicated. It does not mean that the 181 default value of 30 applies [RFC4103]. 183 The offerer and answerer MAY modify the 'cps' attribute parameter 184 value in subsequent offers and answers. 186 NOTE: The 'cps' attribute parameter is especially useful when a T.140 187 data channel endpoint is acting as a gateway [Section 5] and is 188 interworking with a T.140 transport mechanism that have restrictions 189 on how many characters can be sent per second. 191 3.2.2. Real-time Text Conversation Languages 193 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' 194 attributes [RFC8373] to negotiate the language to be used for the 195 real-time text conversation. 197 For a T.140 data channel, the modality is "written" [RFC8373]. 199 3.2.3. Real-time Text Direction 201 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 202 'sendrecv' and 'inactive' attributes [RFC4566] to negotite the 203 direction in which text can be transmitted in a real-time text 204 conversation, following the procedures in [RFC3264]. 206 NOTE: A WebRTC data channel is always bi-directional. The usage of 207 the 'dcsa' attribute only affects the direction in which 208 implementations are allowed to transmit text on a T.140 data channel. 210 The offer/answer rules for the direction attributes are based on the 211 rules for unicast streams defined in [RFC3264], as described below. 212 Note that the rules only apply to the direction attributes. 214 NOTE: As for any other attribute included in a 'dcsa' attribute, the 215 direction attributes only apply to the T.140 data channel for which 216 the 'dcsa' attribute is used. They have no impact on other data 217 channels. 219 Session level direction attributes [RFC4566] have no impact on a 220 T.140 data channel. An offerer and answerer MUST mark the direction 221 of the text by sending a direction attribute inside aEUR~dcsa- 222 attribute. 224 3.2.3.1. Negotiate Text Direction 226 3.2.3.1.1. Generating an Offer 228 If the offerer wishes to both send or receive text on a T.140 data 229 channel, it SHOULD mark the data channel as sendrecv with a 230 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does 231 not explicitly mark the data channel, a 'sendrecv' attribute inside a 232 'dcsa' attribute is implicitly applied. 234 If the offerer wishes to only send text on a T.140 data channel, it 235 MUST mark the data channel as sendonly with a 'sendonly' attribute 236 inside a 'dcsa' attribute. 238 If the offerer wishes to only receive text on a T.140 data channel, 239 it MUST mark the data channel as recvonly with a 'recvonly' attribute 240 inside a 'dcsa' attribute. 242 If the offerer wishes to neither send or receive text on a T.140 data 243 channel, it MUST mark the data channel as inactive with a 'inactive' 244 attribute inside a 'dcsa' attribute. 246 If the offerer has marked a data channel as sendrecv (implicit or 247 explicit) or recvonly, it MUST be prepared to receive T.140 data as 248 soon as the state of the T.140 data channel allows it. 250 When the offerer receives an answer to the offer, if the answerer has 251 marked a data channel as sendrecv (implicit or explicit) or recvonly 252 in the answer, the offerer can start to send T.140 data as soon as 253 the state of the T.140 data channel allows it. If the answerer has 254 marked the data channel as inactive or sendonly, the offerer MUST NOT 255 send any T.140 data. 257 3.2.3.1.2. Generating an Answer 259 When the answerer accepts an offer, and marks the direction of the 260 text in the corresponding answer, the marking is based on the marking 261 (explicit or implicit) in the offer. 263 If the offerer marked the data channel as sendrecv (implicitly or 264 explicitly), the answerer MUST mark the data channel as sendrecv, 265 sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 266 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. 267 If the answerer does not explicitly mark the data channel, a 268 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. 270 If the offerer marked the data channel as sendonly, the answerer MUST 271 mark the data channel as recvonly or inactive with a 'recvonly' 272 respective 'inactive' attribute inside a 'dcsa' attribute. 274 If the offerer marked the data channel as recvonly, the answerer MUST 275 mark the data channel as sendonly or inactive with a 'sendonly' 276 respective 'inactive' attribute inside a 'dcsa' attribute. 278 If the offerer marked the data channel as inactive, the answerer MUST 279 mark the data channel as inactive with a 'inactive' attribute inside 280 a 'dcsa' attribute. 282 If the answerer has marked a data channel as sendrecv or recvonly, it 283 MUST be prepared to receive data as soon as the state of the T.140 284 data channel allows transmission of data. 286 3.2.3.2. Modify Text Direction 288 If an endpoint wishes to modify a previously negotiated text 289 direction in an ongoing session, it MUST initiate an offer that 290 indicates the new direction, following the rules in 291 Section 3.2.3.1.1. If the answerer accepts the offer it follows the 292 procedures in Section 3.2.3.1.2. 294 3.3. Examples 296 Below is an example of an m= section describing a T.140 data channel, 297 where the maximum character transmission rate is set to 20, and the 298 text transmission direction is set to "sendrecv". 300 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 301 c=IN IP6 2001:db8::3 302 a=max-message-size:1000 303 a=sctp-port 5000 304 a=dcmap:1 label="text conversation";subprotocol="t140" 305 a=dcsa:1 fmtp:- cps=20 306 a=dcsa:1 sendrecv 308 Below is an example of an m= section of an offer for a T.140 data 309 channel offering real-time text conversation in Spanish and 310 Esperanto, and an m= section in the associated answer accepting 311 Esperanto. 313 Offer: 315 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 316 c=IN IP6 2001:db8::3 317 a=max-message-size:1000 318 a=sctp-port 5000 319 a=dcmap:1 label="ACME customer service";subprotocol="t140" 320 a=dcsa:1 fmtp:- cps=30 321 a=dcsa:1 hlang-send:es eo 322 a=dcsa:1 hlang-recv:es eo 324 Answer: 326 m=application 911 UDP/DTLS/SCTP webrtc-datachannel 327 c=IN IP6 2001:db8::1 328 a=max-message-size:1000 329 a=sctp-port 5000 330 a=dcmap:1 label="ACME customer service";subprotocol="t140" 331 a=dcsa:1 fmtp:- cps=30 332 a=dcsa:1 hlang-send:eo 333 a=dcsa:1 hlang-recv:eo 335 4. T.140 Considerations 337 4.1. Session Layer Functions 339 Section 6.1 of [T140] describes the generic T.140 session control 340 functions at high-level and a signalling protocol independent manner. 341 The list below describes how the functions are realized when using a 342 T.140 data channel. 344 o Prepare session: An endpoint can indicate its support of T.140 345 data channels using signalling specific means (e.g., using SIP 346 OPTIONS [RFC3261]), or by indicating the support in an offer or 347 answer (Section 3) 348 o Initiate session: An offer used to request the establishment of a 349 T.140 data channel (Section 3) 350 o Accept session: An answer used to accept a request to establish a 351 T.140 data channel (Section 3) 352 o Deny session: An answer used to reject a request to establish a 353 T.140 data channel, using the generic procedures for rejecting a 354 data channel [I-D.ietf-mmusic-data-channel-sdpneg] 355 o Disconnect session: An offer or answer used to disable a 356 previously established T.140 data channel, using the generic 357 procedures for closing a data channel 358 [I-D.ietf-mmusic-data-channel-sdpneg] 359 o Data: Data sent on an established T.140 data channel (Section 4.2) 361 4.2. Data Encoding and Sending 363 T.140 text is encoded and framed as T140blocks [RFC4103]. 365 Each T140block is sent on the SCTP stream [RFC4960] used to realize 366 the T.140 data channel using standard T.140 transmission procedures 367 [T140]. One or more T140blocks can be sent in a single SCTP user 368 message [RFC4960]. Unlike RTP based transport for realtime text 369 [RFC4103], T.140 data channels do not use redundant transmission of 370 text. The reason for this is that the T.140 data channel achieves 371 robust transmission by using the "reliable" mode of the data channel. 373 Data sending and reporting procedures conform to [T140]. 375 See Section 8 of [T140] for coding details. 377 4.3. Data Buffering 379 As described in [T140], buffering can be used to reduce overhead, 380 with the maximum buffering time being 500 ms. It can also be used 381 for staying within the maximum character transmission rate 382 (Section 3.2), if such has been provided by the peer. 384 An implementation needs to take the user requirements for smooth flow 385 and low latency in real-time text conversation into consideration 386 when assigning a buffer time. It is RECOMMENDED to use the default 387 transmission interval of 300 milliseconds [RFC4103], or lower, for 388 T.140 data channels. 390 4.4. Loss of T140blocks 392 In case of network failure or congestion, T.140 data channels might 393 fail and get torn down. If this happens but the session sustains, it 394 is RECOMMENDED that a low number of retries are made to reestablish 395 the T.140 data channels. If reestablishment of the T.140 data 396 channel is successful, an implementation MUST evaluate if any 397 T140blocks were lost. Retransmission of already successfully 398 transmitted T140blocks MUST be avoided, and missing text markers 399 [T140ad1] SHOULD be inserted in the received data stream where loss 400 is detected or suspected. 402 4.5. Multi-party Considerations 404 If an implementation needs to support multi-party scenarios, the 405 implementation needs to support multiple simultaneous T.140 data 406 channels, one for each remote party. At the time of writing this 407 document, this is true even in scenarios where each participant 408 communicate via a centralized conference server. The reason is that, 409 unlike RTP media, WebRTC data channels and the T.140 protocol do not 410 support the indication of the source of T.140 data. The SDP 'dcmap' 411 attribute label attribute parameter (Section 3.1) can be used by the 412 offerer to provide additional information about each T.140 data 413 channel, and help implementations to distinguish between them. 415 NOTE: Future extensions to T.140, or to the T140block, might allow 416 indicating the source of T.140 data, in which case it might be 417 possible to use a single T.140 data channel to transport data from 418 multiple remote sources. That is useful for multi-party aware 419 clients that are able present the conference in a way that is adapted 420 to user expectations regarding presentation style and real-time 421 performance. Conference mixers that use a single T.140 data channel 422 to transmit real-time text towards clients might, without any 423 protocol extensions, produce a multi-party presentation completely 424 within the text stream, and with limitations in real-time performance 425 and presentation style. 427 5. Gateway Considerations 429 A number of real-time text transports and protocols have been defined 430 for both packet switched and circuit switched networks. Many are 431 based on the ITU-T T.140 protocol on application and presentation 432 level [T140]. At the time of writing this document, some mechanisms 433 are no longer used, as the technologies they use have been obsoleted 434 etc, while others are still in use. 436 When performing interworking between T.140 data channels and real- 437 time text in other transports and protocols, a number of factors need 438 to be considered. At the time of writing this document, the most 439 common IP-based real-time text transport is the RTP based mechanism 440 defined in [RFC4103]. While this document does not define a complete 441 interworking solution, this list below provides some guidance and 442 considerations to take into account when designing a gateway for 443 interworking between T.140 data channels and RTP-based T.140 444 transport: 446 o For each T.140 data channel there is an RTP stream for real-time 447 text [RFC4103] . Redundancy is by default declared and used on 448 RTP stream. On the T.140 data channel there is no redundancy, but 449 the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of 450 T.140 the data channel is set. 451 o During a normal text flow, T140blocks received from one network 452 are forwarded towards the other network. Keep-alive traffic is 453 implicit on the T.140 data channel. A gateway might have to 454 extract keep-alives from incoming RTP streams, and MAY generate 455 keep-alives on outgoing RTP streams. 457 o If the gateway detects or suspects loss of data on the RTP stream, 458 the gateway gateway SHOULD insert the T.140 missing text marker 459 [T140ad1] in the data sent on the outgoing T.140 data channel. 460 o If the gateway detects that the T.140 data channel has failed and 461 got torn down, once the data channel has been reestablished the 462 gateway SHOULD insert the T.140 missing text marker [T140ad1] in 463 the data sent on the outgoing RTP stream if it detects or suspects 464 that data on the T.140 data channel was lost. 465 o The gateway MUST indicate the same text transmission direction 466 (Section 3.2.3) on the T.140 data channel and the RTP stream. 468 NOTE: In order for the gateway to insert a missing text marker, or to 469 perform other actions that require that the gateway has access to the 470 T.140 data, the T.140 data cannot be encrypted end-to-end between the 471 T.140 data channel endpoint and the RTP endpoint. At the time of 472 writing this document, a mechanism to provide such end-to-end 473 encryption has not been defined. 475 6. Update to RFC 8373 477 This document updates RFC 8373, by defining how the SDP hlang-send 478 and hlang-recv attributes are used for the "application/webrtc- 479 datachannel" media type. 481 SDP offerers and answerers MUST NOT include the attributes directly 482 in the m= section associated with the 'application/webrtc- 483 datachannel' media type. Instead, the attributes MUST be associated 484 with individual data channels, using the SDP 'dcsa' attribute. A 485 specification that defines a subprotocol that uses the attributes 486 MUST specify the modality for that subprotocol, or how to retreive 487 the modality if the subprotocol supports multiple modalities. 489 7. Security Considerations 491 The generic security considerations for WebRTC data channels are 492 defined in [I-D.ietf-rtcweb-data-channel]. As data channels are 493 always encrypted by design, the T.140 data channels will also be 494 encrypted. 496 The generic security considerations for the SDP-based external 497 negotiation method are defined in 498 [I-D.ietf-mmusic-data-channel-sdpneg]. 500 8. IANA considerations 502 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 503 RFC number of this document.] 505 8.1. Subprotocol Identifier t140 507 This document adds the subprotocol identifier "t140" to the 508 "WebSocket Subprotocol Name Registry" as follows: 510 +--------------------------+-------------+ 511 | Subprotocol Identifier: | t140 | 512 | Subprotocol Common Name: | ITU-T T.140 | 513 | Subprotocol Definition: | RFCXXXX | 514 | Reference: | RFCXXXX | 515 +--------------------------+-------------+ 517 8.2. SDP fmtp Attribute 519 This document modifies the usage of the SDP 'fmtp' attribute, if this 520 attribute is included in an SDP 'dcsa' attribute and associated with 521 an T.140 real-time text session over a WebRTC data channel. The 522 modified usage is described in Section 3.2.1. 524 The usage level "dcsa(t140)" is added to the IANA registration of the 525 SDP 'fmtp' attribute as follows: 527 +-----------------------+-------------------------------------------+ 528 | Contact name: | MMUSIC Chairs | 529 | Contact email: | mmusic-chairs@ietf.org | 530 | Attribute name: | fmtp | 531 | Usage level: | dcsa(t140) | 532 | Purpose: | Indicate the maximum transmission rate | 533 | | that an endpoint is willing to recive on | 534 | | a T.140 data channel. | 535 | Reference: | RFCXXXX | 536 +-----------------------+-------------------------------------------+ 538 8.3. SDP Language Attributes 540 This document modifies the usage of the SDP 'hlang-send' and 'hlang- 541 recv' attributes, if these attributes are included in SDP 'dcsa' 542 attributes associated with an T.140 data channel. The modified usage 543 is described in Section 3.2.2. 545 The usage level "dcsa(t140)" is added to the IANA registration of the 546 SDP 'hlang-send' attribute as follows: 548 +-----------------------+-------------------------------------------+ 549 | Contact name: | MMUSIC Chairs | 550 | Contact email: | mmusic-chairs@ietf.org | 551 | Attribute name: | hlang-send | 552 | Usage level: | dcsa(t140) | 553 | Purpose: | Negotiate the language to be used on a | 554 | | T.140 data channel. | 555 | Reference: | RFCXXXX | 556 +-----------------------+-------------------------------------------+ 558 The usage level "dcsa(t140)" is added to the IANA registration of the 559 SDP 'hlang-recv' attribute as follows: 561 +-----------------------+-------------------------------------------+ 562 | Contact name: | MMUSIC Chairs | 563 | Contact email: | mmusic-chairs@ietf.org | 564 | Attribute name: | hlang-recv | 565 | Usage level: | dcsa(t140) | 566 | Purpose: | Negotiate the language to be used on a | 567 | | T.140 data channel. | 568 | Reference: | RFCXXXX | 569 +-----------------------+-------------------------------------------+ 571 8.4. SDP Media Direction Attributes 573 This document modifies the usage of the SDP 'sendonly', 'recvonly', 574 'sendrecv' and 'inactive' attributes, if these attributes are 575 included in SDP 'dcsa' attributes associated T.140 data channel. The 576 modified usage is described in Section 3.2.3. 578 The usage level "dcsa(t140)" is added to the IANA registration of the 579 SDP 'sendonly' attribute as follows: 581 +-----------------------+-------------------------------------------+ 582 | Contact name: | MMUSIC Chairs | 583 | Contact email: | mmusic-chairs@ietf.org | 584 | Attribute name: | sendonly | 585 | Usage level: | dcsa(t140) | 586 | Purpose: | Negotiate the direction in which real- | 587 | | time text can be sent on a T.140 data | 588 | | channel. | 589 | Reference: | RFCXXXX | 590 +-----------------------+-------------------------------------------+ 592 The usage level "dcsa(t140)" is added to the IANA registration of the 593 SDP 'recvonly' attribute as follows: 595 +-----------------------+-------------------------------------------+ 596 | Contact name: | MMUSIC Chairs | 597 | Contact email: | mmusic-chairs@ietf.org | 598 | Attribute name: | recvonly | 599 | Usage level: | dcsa(t140) | 600 | Purpose: | Negotiate the direction in which real- | 601 | | time text can be sent on a T.140 data | 602 | | channel. | 603 | Reference: | RFCXXXX | 604 +-----------------------+-------------------------------------------+ 606 The usage level "dcsa(t140)" is added to the IANA registration of the 607 SDP 'sendrecv' attribute as follows: 609 +-----------------------+-------------------------------------------+ 610 | Contact name: | MMUSIC Chairs | 611 | Contact email: | mmusic-chairs@ietf.org | 612 | Attribute name: | sendrecv | 613 | Usage level: | dcsa(t140) | 614 | Purpose: | Negotiate the direction in which real- | 615 | | time text can be sent on a T.140 data | 616 | | channel. | 617 | Reference: | RFCXXXX | 618 +-----------------------+-------------------------------------------+ 620 The usage level "dcsa(t140)" is added to the IANA registration of the 621 SDP 'inactive' attribute as follows: 623 +-----------------------+-------------------------------------------+ 624 | Contact name: | MMUSIC Chairs | 625 | Contact email: | mmusic-chairs@ietf.org | 626 | Attribute name: | inactive | 627 | Usage level: | dcsa(t140) | 628 | Purpose: | Negotiate the direction in which real- | 629 | | time text can be sent on a T.140 data | 630 | | channel. | 631 | Reference: | RFCXXXX | 632 +-----------------------+-------------------------------------------+ 634 9. Acknowledgements 636 This document is based on an earlier Internet draft edited by Keith 637 Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. 639 Thomas Belling provided useful comments on the initial (pre- 640 submission) version of the draft. Gunnar Hellstrom provided comments 641 and text on the draft. 643 10. References 645 10.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, . 652 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 653 with Session Description Protocol (SDP)", RFC 3264, 654 DOI 10.17487/RFC3264, June 2002, . 657 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 658 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 659 . 661 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 662 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 663 July 2006, . 665 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 666 RFC 4960, DOI 10.17487/RFC4960, September 2007, 667 . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time 674 Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, 675 . 677 [I-D.ietf-rtcweb-data-channel] 678 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 679 Channels", draft-ietf-rtcweb-data-channel-13 (work in 680 progress), January 2015. 682 [I-D.ietf-mmusic-data-channel-sdpneg] 683 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 684 Even, "SDP-based Data Channel Negotiation", draft-ietf- 685 mmusic-data-channel-sdpneg-28 (work in progress), May 686 2019. 688 [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), "Protocol 689 for multimedia application text conversation"", February 690 1998. 692 [T140ad1] ITU-T, "Recommendation ITU-T.140 aEUR" Addendum 1 693 (02/2000), "Protocol for multimedia application text 694 conversation"", February 2000. 696 10.2. Informative References 698 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 699 A., Peterson, J., Sparks, R., Handley, M., and E. 700 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 701 DOI 10.17487/RFC3261, June 2002, . 704 [I-D.ietf-rtcweb-data-protocol] 705 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 706 Establishment Protocol", draft-ietf-rtcweb-data- 707 protocol-09 (work in progress), January 2015. 709 Author's Address 711 Christer Holmberg 712 Ericsson 713 Hirsalantie 11 714 Jorvas 02420 715 Finland 717 Email: christer.holmberg@ericsson.com