idnits 2.17.1 draft-schwarz-mmusic-t140-usage-data-channel-03.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 abstract seems to contain references ([I-D.ietf-mmusic-data-channel-sdpneg]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The labelstring is set by the T.140 application according to [I-D.ietf-mmusic-data-channel-sdpneg]. The max-retr, max-time and ordered parameters SHALL not be used. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 4, 2016) is 2944 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: 'I-D.ietf-rtcweb-jsep' is mentioned on line 210, but not defined == Missing Reference: 'ITU-T V.150.1' is mentioned on line 472, but not defined == Unused Reference: 'RFC4566' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-msrp-usage-data-channel' is defined on line 602, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Duplicate reference: draft-ietf-rtcweb-data-channel, mentioned in 'I-D.ietf-rtcweb-data-channel', was also mentioned in 'I-D.ietf-rtcweb-data-protocol'. -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T T.140' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T T.140Add1' Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WG MMUSIC Keith Drage, Ed. 2 Internet Draft Juergen Stoetzer-Bradler 3 Intended status: Standards track Albrecht Schwarz 4 Expires: October 2016 Nokia 5 April 4, 2016 7 T.140 Text Conversation over Data Channels 8 draft-schwarz-mmusic-t140-usage-data-channel-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on October 4, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. 57 Abstract 59 This document specifies how the ITU-T Protocol for multimedia 60 application text conversation (Recommendation ITU-T T.140) can be 61 instantiated as a data channel sub-protocol, using the SDP 62 offer/answer exchange-based external negotiation defined in [I- 63 D.ietf-mmusic-data-channel-sdpneg]. Two network configurations are 64 documented: a WebRTC end-to-end configuration (connecting two T.140 65 over data channel endpoints), and a gateway configuration 66 (connecting an T.140 over data channel endpoint with an T.140 over 67 RTP/UDP endpoint). 69 Table of Contents 71 1. Introduction...................................................3 72 1.1. Motivation................................................3 73 1.2. Framework of WebRTC data applications.....................4 74 2. Conventions....................................................4 75 2.1. Prescriptive language.....................................4 76 2.2. Notation..................................................5 77 3. Terminology and abbreviations..................................5 78 3.1. Terminology used..........................................5 79 3.2. Abbreviations used........................................5 80 4. Prinicples.....................................................6 81 4.1. T.140 Data Channel........................................6 82 4.2. Session Mapping...........................................6 83 5. End-to-End Configuration.......................................7 84 5.1. Basic T.140 Support.......................................7 85 5.1.1. Session Negotiation..................................7 86 5.1.1.1. Use of dcmap Attribute..........................7 87 5.1.1.2. Use of dcsa Attribute...........................7 88 5.1.1.3. Example SDP Negotiation.........................8 89 5.1.2. Session Opening......................................8 90 5.1.3. Data Framing.........................................9 91 5.1.4. Data Sending and Reporting...........................9 92 5.1.5. Session Closing......................................9 93 5.2. Support of T.140-specific Functions.......................9 94 6. Gateway Configurations........................................10 95 6.1. Introduction.............................................10 96 6.2. Gateway-embedded Interworking Functions for T.140........10 97 6.2.1. WebRTC T.140 text to IP text telephony in text 98 conversation mode..........................................10 99 6.2.2. WebRTC T.140 text to IP text telephony in text relay 100 mode.......................................................10 101 6.2.3. WebRTC T.140 text to IP text telephony in text pass- 102 through mode...............................................11 103 6.2.4. WebRTC T.140 text to PSTN text telephony............11 104 6.3. Gateway configuration and procedures in more detail......12 105 6.3.1. Interworking support by WebRTC gateway..............12 106 6.3.2. WebRTC domain: SCTP stream configuration............12 107 6.3.3. Non-WebRTC domain: "RFC 4103/RTP"-endpoint emulation12 108 7. Security Considerations.......................................13 109 8. IANA Considerations...........................................13 110 9. References....................................................13 111 9.1. Normative References.....................................13 112 9.2. Informative References...................................14 113 10. Acknowledgments..............................................15 114 11. CHANGE LOG...................................................17 115 11.1. Initial draft-schwarz-mmusic-t140-usage-data-channel-00.17 116 11.1.1. Status.............................................17 117 11.1.2. Changes against "draft-ietf-mmusic-msrp-usage-data- 118 channel-01"................................................17 119 11.2. Changes against draft-schwarz-mmusic-t140-usage-data- 120 channel-01....................................................17 121 11.3. Changes against draft-schwarz-mmusic-t140-usage-data- 122 channel-02....................................................17 123 11.4. Changes against draft-schwarz-mmusic-t140-usage-data- 124 channel-03....................................................17 125 12. Backup material: Discussion of realtime text service handling 126 within WebRTC....................................................18 128 1. Introduction 130 1.1. Motivation 132 Recommendation ITU-T T.140 [ITU-T T.140] defines a protocol for text 133 conversation, also known as realtime text or text telephony. The 134 native transport for IP networks is based on the Real-time Transport 135 Protocol (RTP; see [RFC4103]) due to its inherent realtime 136 characteristics, similar as conversational audio and video services. 138 WebRTC text conversation is based on T.140, but considered as "data 139 traffic" component (despite the fact of the native RTP-based 140 transport in non-WebRTC environments), see [I-D.ietf-rtcweb-data- 141 channel]. 143 NOTE - The decision to transport realtime text over a data channel 144 in WebRTC (instead of RTP based transport) is constituted by use 145 case "U-C 5: Realtime text chat during an audio and/or video call 146 with an individual or with multiple people in a conference", see 147 clause 3.2/[I-D.ietf-rtcweb-data-channel]. 149 This document defines the SDP-based negotiation and transport of the 150 T.140 protocol over data channels, where a data channel is a bi- 151 directional communication channel running on top of SCTP/DTLS (as 152 per [I-D.ietf-rtcweb-data-channel]) and where T.140 is instantiated 153 as a sub-protocol of this data channel. 155 Considering an T.140 endpoint being an T.140 application that uses 156 data channel from WebRTC specifications [I-D.ietf-rtcweb-data- 157 channel], this document describes two configurations where the other 158 endpoint is respectively either another T.140 over data channel 159 endpoint (e.g., a WebRTC application) or an T.140 endpoint using 160 native RTP transport. 162 1.2. Framework of WebRTC data applications 164 There are multiple IP application protocols which using WebRTC data 165 channels as transport, such as MSRP or BFCP besides T.140. The SDP- 166 based indication and negotiation of such WebRTC data applications at 167 call control signalling level follows common principles. The first 168 WebRTC application from this suite is/was the MSRP-based instant 169 messaging service for WebRTC, see [I-D.ietf-mmusic-msrp-usage-data- 170 channel]. This specification for T.140 was derived from that 171 document and uses an aligned clause structuring. 173 It may be noted that the T.140 protocol as such is much simpler in 174 comparison to the MSRP, which requires an extensive set of SDP 175 elements (in comparison to T.140) for the description of specific 176 MSRP services and their protocol parameter settings. 178 2. Conventions 180 2.1. Prescriptive language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC-2119 [RFC2119]. 186 2.2. Notation 188 The brief notation "T.140" is used as a synonym for the text 189 conversation protocol according to [ITU-T T.140]. 191 3. Terminology and abbreviations 193 3.1. Terminology used 195 This document uses the following terms: 197 Data channel: A WebRTC data channel as specified in [I-D.ietf- 198 rtcweb-data-channel]. 200 T.140 data channel: A data channel specifically used to transport 201 the text and presentation control information of one T.140 session. 203 External negotiation: Data channel negotiation based on out-of-band 204 or in-band mechanisms other than the Data Channel Establishment 205 Protocol specified in [I-D.ietf-rtcweb-data-protocol]. 207 In-band: Transmission through the peer-to-peer SCTP association. 209 Out-of-band: Transmission through the call control signaling path, 210 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 211 model [RFC3264]. 213 Peer: From the perspective of one of the agents in a session, its 214 peer is the other agent. Specifically, from the perspective of the 215 SDP offerer, the peer is the SDP answerer. From the perspective of 216 the SDP answerer, the peer is the SDP offerer 218 3.2. Abbreviations used 220 DS0 Digital Signal 0 (1 x 64 kilobits per second) 222 DTLS Datagram Transport Layer Security 224 GCP Gateway Control Protocol 226 ITU-T International Telecommunication Union Telecommunication 227 Standardization Sector 229 IWF Interworking Function 231 JSEP Javascript Session Establishment Protocol 232 MG (H.248) Media Gateway 234 MGC (H.248) Media Gateway Controller 236 PDU Protocol Data Unit 238 RTP Real-time Transport Protocol 240 SCTP Stream Control Transmission Protocol 242 SDP Session Description Protocol 244 SIP Session Initiation Protocol 246 TCP Transmission Control Protocol 248 TDM (Synchronous) Time Division Multiplexing 250 ToIP Text over IP 252 TLS Transport Layer Security 254 UA User Agent 256 UDP User Datagram Protocol 258 VBD Voiceband Data 260 4. Prinicples 262 4.1. T.140 Data Channel 264 In this document, an T.140 data channel is a data channel for which 265 the instantiated sub-protocol is "t140", and where the T.140-related 266 negotiation is done as part of the SDP-based external negotiation 267 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 269 NOTE - This WebRTC term of a "T.140 data channel" is actually 270 synonym to the originally introduced concept of a "T.140 data 271 channel"] for the T.140 protocol back in 1998, see [ITU-T T.140], 272 clause 4.3. 274 4.2. Session Mapping 276 In this design, the T.140 session maps to the SCTP association and 277 the "SCTP stream pair" assigned to the data channel, and each T.140 278 session maps to one data channel exactly. 280 5. End-to-End Configuration 282 This section describes the network configuration where each T.140 283 endpoint is running T.140 over a data channel. 285 5.1. Basic T.140 Support 287 5.1.1. Session Negotiation 289 5.1.1.1. Use of dcmap Attribute 291 The SDP offer SHALL include a dcmap attribute line (defined in [I- 292 D.ietf-mmusic-data-channel-sdpneg], within the media description for 293 the SCTP association for each T.140 data channel session to be 294 negotiated. 296 The attribute includes the following data channel parameters: 298 o "label=" labelstring 300 o "subprotocol=" "t140" 302 The labelstring is set by the T.140 application according to [I- 303 D.ietf-mmusic-data-channel-sdpneg]. The max-retr, max-time and 304 ordered parameters SHALL not be used. 306 Rest of the SDP offer/answer procedures are per [I-D.ietf-mmusic- 307 data-channel-sdpneg]. 309 The following is an example of the dcmap attribute for an T.140 310 session to be negotiated (on default SCTP port 5000) with stream=3 311 and without any label: 313 a=dcmap:3 subprotocol="t140" 315 5.1.1.2. Use of dcsa Attribute 317 The SDP offer MAY also include a dcsa attribute line (defined in [I- 318 D.ietf-mmusic-data-channel-sdpneg]) within the media description for 319 the SCTP association for each T.140-specific SDP attribute to be 320 negotiated for each T.140 data channel being negotiated. 322 The T.140-specific items that can be negotiated include at least 323 following attribute: 325 o defined in [RFC4103], clause 6: the media format parameter 326 "character transmission rate", indicated with "cps". 328 NOTE - The "cps" parameter is optional and only required for 329 specific network interworking cases, see clause 6/[RFC4103]. It is 330 expected that this SDP parameter is for instance not required for 331 end-to-end text/T.140 data channels between two or multiple WebRTC 332 clients, but might be for instance required in case of 333 interworking with PSTN text telephony (see clause 6.2.4). 335 The SDP answer SHALL include zero or more corresponding dcsa 336 attribute lines for each negotiated T.140 session, according to the 337 T.140-specific attribute negotiation rules in the corresponding 338 specifications. 340 A new SDP offer/answer MAY update the T.140 subprotocol attribute(s) 341 while keeping the same subprotocol a=dcmap description. 343 5.1.1.3. Example SDP Negotiation 345 The following is an example of an "m"-line for data channels in an 346 SDP offer that includes the attributes needed to establish a T.140 347 session: 349 m=application 911 /DTLS/SCTP webrtc-datachannel 350 c=IN IP4 11.9.19.65 351 a=max-message-size:1000 ; "much smaller than e.g. MSRP" 352 a=sctp-port 5000 353 a=dcmap:1 label="text conversation";subprotocol="t140"; 354 ordered=true;max-time=???;max-retr=??? ; NOTE 1 355 a=dcsa:1 fmtp:- cps=30 ; NOTE 2 357 NOTE 1 - Maximum number of retransmissions = ??? (because FIXTHIS 358 ); 359 Maximum retransmission timing = ??? (because FIXTHIS 360 ). 362 NOTE 2 - "the RFC4103 default value as example". 364 5.1.2. Session Opening 366 [ITU-T T.140], clause 6.1 describes the generic T.140 session 367 control functions at high-level and a signalling protocol 368 independent manner. WebRTC-embedded T.140 sessions uses the data 369 channel established for this T.140 session by the generic data 370 channel opening procedure defined in [I-D.ietf-mmusic-data-channel- 371 sdpneg]. 373 As soon as this data channel is opened, the T.140 session is 374 actually in the (virtual) state "data transfer ready". 376 NOTE - The user plane protocol T.140 itself is stateless. The 377 (T.140)-session-endpoint could be abstracted by a two-state model 378 from signalling plane perspective (with states "Idle" and "Data 379 Transfer Ready"). 381 5.1.3. Data Framing 383 Each T140block is sent on the corresponding SCTP stream using 384 standard T.140 transmission procedures, as defined in [ITU-T T.140], 385 with each T.140 chunk delivered in a single SCTP user message. 387 NOTE - A T140block as service data unit represents one or multiple 388 characters according to the syntax of clause 8 in [ITU-T T.140]. 390 5.1.4. Data Sending and Reporting 392 Data sending and reporting procedures SHALL conform to [ITU-T 393 T.140]. 395 5.1.5. Session Closing 397 Closing of an T.140 session SHALL be done using the generic data 398 channel closing procedure defined in [I-D.ietf-mmusic-data-channel- 399 sdpneg]. 401 The port value for the "m="-line SHOULD NOT be changed (e.g., to 402 zero) when closing an T.140 session (unless all data channels are 403 being closed and the SCTP association is no longer needed), since 404 this would close the SCTP association and impact all of the data 405 channels. 407 The SDP answerer SHALL ensure that no dcmap or dcsa attributes are 408 present in the SDP answer if no corresponding attributes are present 409 in the received SDP offer. 411 5.2. Support of T.140-specific Functions 413 In general, the recommended procedures of clause 5 from [RFC4103] 414 SHOULD be applicable as well for SCTP-based transport of T.140. 416 NOTE - [RFC4103] defines T.-140-over-RTP: the procedures of 417 clauses 5.1 and 5.2 are transport protocol independent, hence 418 valid for SCTP too. Clauses 5.3 and 5.4 are RTP specific due 419 unreliable transport, hence not expected to be relevant for SCTP 420 (to be confirmed). 422 6. Gateway Configurations 424 6.1. Introduction 426 This section describes the network configuration where one T.140 427 endpoint uses data channels as T.140 transport, the other T.140 428 endpoint uses a different protocol stack. There is consequently an 429 interworking function (IWF) in the media plane required, associated 430 with correspondent interworking in the signalling plane. Such type 431 of IWFs are provided by gateway devices, given here by WebRTC 432 gateways as defined by [I-D.ietf-rtcweb-gateways], [ITU-T H.248.94], 433 [3GPP 29.334], etc. 435 6.2. Gateway-embedded Interworking Functions for T.140 437 There are a plethora of interworking functions knowns for T.140 438 [ITU-T T.140] due to the long history and usage of this service in 439 legacy packet-switched and circuit-switched networks. Some examples 440 are indicated below. 442 Editor's note: clause 6.2 should be moved in an informative 443 Appendix. Normative scope of this draft is 6.2.1 only. 445 6.2.1. WebRTC T.140 text to IP text telephony in text conversation mode 447 Service "IP text telephony in text conversation mode": 449 Transport service according to [RFC4103]. 451 Media plane IWF: 453 "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" 454 to "T.140-over-RTP/UDP" 456 6.2.2. WebRTC T.140 text to IP text telephony in text relay mode 458 Service "IP text telephony in text relay mode": 460 Transport of T.140 over IP networks, according to [ITU-T V.151]. 461 Also known as Text-over-IP (ToIP). 463 Media plane IWF: 465 "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" 466 to "T.140-over-IP TLP-UDP". 468 NOTE: [ITU-T V.151] uses the concept of an "IP Transport Layer 469 Protocol" (IP-TLP) above the native IP transport layer, which 470 again allows different framing protocol options (such as RTP-based 471 or SPRT-based framing (Simple Packet Relay Transport, see Annex B 472 of [ITU-T V.150.1])). 474 6.2.3. WebRTC T.140 text to IP text telephony in text pass-through mode 476 Service "IP text telephony in text pass-through mode": 478 Transport of analogue PSTN text telephones signals over PCM 479 encoded voice over IP networks, according to [ITU-T V.152]. Also 480 known as Voiceband-over-IP (VBDoIP). 482 Media plane IWF: 484 "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" 485 to "text/modem-over-G.711-over-RTP/UDP". 487 NOTE: This is the VBD mode according to [ITU-T V.152], using ITU-T 488 G.711 as VBD codec (i.e., a different codec configuration as in 489 comparison to G.711 as audio codec). 491 6.2.4. WebRTC T.140 text to PSTN text telephony 493 Service "PSTN text telephony": 495 Transport of analogue PSTN text telephones signals over a) 496 analogue lines or b) circuit-switched 64-kbit/s channels. 498 Media plane IWF: 500 "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" 501 to "text/modem-over-DS0/TDM" (in case of circuit-switched 502 networks). 504 6.3. Gateway configuration and procedures in more detail 506 The signalling plane and media plane interworking functions are 507 elaborated in more detail at the example of a WebRTC gateway with 508 support of interworking to IP text telephony in text conversation 509 mode. 511 This example describes the network configuration where one T.140 512 endpoint uses data channels as T.140 transport, the other T.140 513 endpoint uses RTP/UDP connections as T.140 transport, and the two 514 T.140 endpoints interwork via an appropriate interworking function 515 (see also [ITU-T H.248.94], Appendix <#>). 517 6.3.1. Interworking support by WebRTC gateway 519 The WebRTC gateway interconnects two IP network domains, - there are 520 specific considerations: 522 1. WebRTC domain: 524 Application specific configuration of the SCTP stream is necessary 525 in order to satisfy T.140 requirements concerning reliable 526 transport. 528 2. Non-WebRTC domain: 530 The WebRTC gateway needs to emulate a "T.140/RTP"-endpoint in the 531 non-WebRTC domain, which implies an RTP source/RTP sink behaviour 532 according to [RFC4103]. Hence, the WEBRTC gateway is required to 533 be aware about the IP application protocol T.140 despite the fact 534 of transparent forwarding mode. The "T.140 awareness" by the 535 WEBRTC gateway is limited to the detection of active/silence 536 periods related to the transfer of T.140 PDUs, as well as a 537 "packet loss concealment" method related to incoming T.140/RTP 538 packets. 540 Next two sub-clauses refer to possible solutions. 542 6.3.2. WebRTC domain: SCTP stream configuration 544 FIXTHIS 546 6.3.3. Non-WebRTC domain: "RFC 4103/RTP"-endpoint emulation 548 There are three aspects of consideration: 550 R1: Inactivity of T.140 traffic in RTP send direction? 552 R2: Incoming RTP packets out of order? 554 R3: Incoming RTP packets lost? 556 See [ITU-T H.248.94], Appendix <#> concerning possible WebRTC 557 gateway behaviour in order to address above events. The required 558 gateway T.140 protocol interventions SHALL be compliant to 559 [RFC4103], [ITU-T T.140] and [ITU-T T.140Add1]. 561 Editor's note: it was mentioned that an "application level" keep 562 alive mechanism might need to be supported by the WebRTC gateway in 563 case of NAT traversal support requirements, i.e.,.a mechanism such 564 as outlined by RFC 6263 "Application Mechanism for Keeping Alive the 565 NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) 566 Flows". 568 7. Security Considerations 570 FIXTHIS 572 8. IANA Considerations 574 FIXTHIS 576 9. References 578 9.1. Normative References 580 [RFC2119] RFC 2119 (03/1997), "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14. 583 [RFC3264] RFC 3264 (06/2002), "An Offer/Answer Model with the 584 Session Description Protocol (SDP)". 586 [RFC4103] RFC 4103 (06/2005), "RTP Payload for Text Conversation". 588 [RFC4566] RFC 4566 (07/2006), "SDP: Session Description Protocol". 590 [I-D.ietf-rtcweb-data-protocol] draft-ietf-rtcweb-data-channel 591 (##/2015), "WebRTC Data Channel Establishment Protocol". 593 [I-D.ietf-rtcweb-data-channel] 594 http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data- 595 channel/draft-ietf-rtcweb-data-channel (##/2015), "WebRTC 596 Data Channels". 598 [I-D.ietf-mmusic-data-channel-sdpneg] draft-ietf-mmusic-data- 599 channel-sdpneg (##/2015), "SDP-based Data Channel 600 Negotiation". 602 [I-D.ietf-mmusic-msrp-usage-data-channel] draft-ietf-mmusic-msrp- 603 usage-data-channel (##/2015), "MSRP over Data Channels". 605 [ITU-T T.140] Recommendation ITU-T T.140 (02/1998), "Protocol for 606 multimedia application text conversation". 607 Free copy via: 608 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- 609 T.140-199802-I!!PDF-E&type=items 611 [ITU-T T.140Add1] Recommendation ITU-T T.140 Addendum 1 (02/2000), 612 "Protocol for multimedia application text conversation - 613 Addendum 1". 614 Free copy via: 615 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- 616 T.140-200002-I!Add1!PDF-E&type=items 618 9.2. Informative References 620 [I-D.ietf-rtcweb-gateways] draft-ietf-rtcweb-gateways (##/2015), 621 "WebRTC Gateways". 623 [ITU-T H.248.94] Recommendation ITU-T H.248.94 (10/2015), "Web- 624 based real-time communication services - H.248 protocol 625 support and profile guidelines". 626 Status: still work in progress in ITU-T SG16 Question 3 627 Free copy via: FIXTHIS 629 [ITU-T V.151] Recommendation ITU-T V.151 (05/2006), "Procedures for 630 the end-to-end connection of analogue PSTN text telephones 631 over an IP network utilizing text relay". 632 Free copy via: 633 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- 634 V.151-200605-I!!PDF-E&type=items 636 [ITU-T V.152] Recommendation ITU-T V.152 (09/2010), "Procedures for 637 supporting voice-band data over IP networks". 638 Free copy via: 639 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- 640 V.152-201009-I!!PDF-E&type=items 642 [3GPP 29.334] 3GPP TS 29.334 Release 13 (2015), "Digital cellular 643 telecommunications system (Phase 2+); Universal Mobile 644 Telecommunications System (UMTS); LTE; IMS Application 645 Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW); Iq 646 Interface; Stage 3". 647 Free copy via: 648 ftp://ftp.3gpp.org/specs/archive/29_series/29.334/ 650 10. Acknowledgments 652 FIXTHIS 654 Authors' Addresses 656 Keith Drage (editor) 657 Nokia 658 Quadrant, Stonehill Green, Westlea 659 Swindon 660 UK 662 Email: keith.drage@nokia.com 664 Dr. Juergen Stoetzer-Bradler 665 Nokia 666 Lorenzstrasse 10 667 D-70435 Stuttgart 668 GERMANY 670 Email: Juergen.Stoetzer-Bradler@nokia.com 672 Dr. Albrecht Schwarz 673 Nokia 674 Lorenzstrasse 10 675 D-70435 Stuttgart 676 GERMANY 678 Email: Albrecht.Schwarz@nokia.com 680 11. CHANGE LOG 682 11.1. Initial draft-schwarz-mmusic-t140-usage-data-channel-00 684 11.1.1. Status 686 o The initial document represents a skeleton where still a number 687 of clauses are still empty. 689 o The intention is to propose a document structure aligned with the 690 MSRP draft, and to emphasize WebRTC gateway flavours. 692 11.1.2. Changes against "draft-ietf-mmusic-msrp-usage-data-channel-01" 694 o Replace protocol "MSRP" by "T.140" plus protocol specific 695 adaptations 697 o Initial scope of gateway section 699 11.2. Changes against draft-schwarz-mmusic-t140-usage-data-channel-01 701 o Reference to rtcweb draft inserted which defines realtime text 702 transport in WebRTC. 704 o Initial input text added to the majority of "placeholder 705 sections" from the -00 version. 707 11.3. Changes against draft-schwarz-mmusic-t140-usage-data-channel-02 709 o uppercase of modal vers 711 o clause 5.1.1.2: clarification fixed 713 o clause 5.1.2: clarification fixed 715 o clause 5.1.3: clarification fixed 717 o clause 5.2: clarification fixed 719 o clause 6.3: initial description inserted 721 11.4. Changes against draft-schwarz-mmusic-t140-usage-data-channel-03 723 o Editorial: update of author addresses 725 o Indication of some issues for clarification (by editor notes) 727 12. Backup material: Discussion of realtime text service handling 728 within WebRTC 730 {Editor's comment: this clause is only temporary and will be deleted 731 again as soon as draft becomes technically stable.} 733 RTCWEB email threads (non-exhaustive list): 735 o 2012-11 Subject: "[rtcweb] Text communication in RTCWEB sessions" 736 https://mailarchive.ietf.org/arch/msg/rtcweb/Vx6ZbLPPh4vsG25UPZlR 737 Xq_ffM0 739 o 2012-11 Subject: "[rtcweb] Text communication requirements for 740 RTCWEB" 741 https://mailarchive.ietf.org/arch/msg/rtcweb/JXesT_A6vOMs_N05fWaF 742 DGPKryo 744 o 2012-11 Subject: "[rtcweb] Text communication SDP in RTCWEB" 745 https://mailarchive.ietf.org/arch/msg/rtcweb/EQI3Trtzmhnlh15Jocil 746 TxbWHt0 748 o 2012-11 Subject: "[rtcweb] Consensus call on Text Communication" 749 https://mailarchive.ietf.org/arch/msg/rtcweb/viAKLXAAs0mKXL8xwXRB 750 1nthPhg 752 o 2012-12 Subject: "[rtcweb] Real-time text implementations" 753 https://mailarchive.ietf.org/arch/msg/rtcweb/YNlKMFuzbVo2SnZHzICy 754 ruf4x9I 756 o 2013-05 Subject: "[rtcweb] RTT (was Re: No Plan)" 757 https://mailarchive.ietf.org/arch/msg/rtcweb/iDXc5DFMJIgiEPCWnyvV 758 dNFlOPo 760 o 2013-05 Subject: "[rtcweb] RTT Education: Neat Demonstration of 761 NON-peer-to-peer RTT (for future webrtc standardization 762 purposes)" 763 https://mailarchive.ietf.org/arch/msg/rtcweb/bfUUQXP_cG- 764 63wBpS0JH62vCf4c 766 o 2013-12 Subject: "[rtcweb] Real-time text" 767 https://mailarchive.ietf.org/arch/msg/rtcweb/Hsvm7gzybT1MNYXBzbJR 768 EOvy3zY 770 o 2014-08 Subject: "[rtcweb] draft-ietf-rtcweb-data-channel failure 771 handling description" 772 https://mailarchive.ietf.org/arch/msg/rtcweb/BqBrwBlrT4h9aAmEzQkY 773 b-3on7Q 775 o 2015-02 Subject: "[rtcweb] Use of redundancy and RFC 2119 776 language in draft-ietf-rtcweb-fec-00" 777 https://mailarchive.ietf.org/arch/msg/rtcweb/HYMplbKGmBOUUR_VQiAB 778 BjMfDBY