WG MMUSIC Keith Drage, Ed. Internet Draft Juergen Stoetzer-Bradler Intended status: Standards track Albrecht Schwarz Expires: April 2016 Alcatel-Lucent October 2, 2015 T.140 Text Conversation over Data Channels draft-schwarz-mmusic-t140-usage-data-channel-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 2, 2016. Schwarz Expires April 2, 2016 [Page 1] Internet-Draft SDP codepoints for gateway control October 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies how the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based external negotiation defined in [I- D.ietf-mmusic-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two T.140 over data channel endpoints), and a gateway configuration (connecting an T.140 over data channel endpoint with an T.140 over RTP/UDP endpoint). Table of Contents 1. Introduction...................................................3 1.1. Motivation................................................3 1.2. Framework of WebRTC data applications.....................4 2. Conventions....................................................4 2.1. Prescriptive language.....................................4 2.2. Notation..................................................5 3. Terminology and abbreviations..................................5 3.1. Terminology used..........................................5 3.2. Abbreviations used........................................5 4. Prinicples.....................................................6 4.1. T.140 Data Channel........................................6 4.2. Session Mapping...........................................6 5. End-to-End Configuration.......................................7 5.1. Basic T.140 Support.......................................7 5.1.1. Session Negotiation..................................7 5.1.1.1. Use of dcmap Attribute..........................7 5.1.1.2. Use of dcsa Attribute...........................7 5.1.1.3. Example SDP Negotiation.........................8 5.1.2. Session Opening......................................8 5.1.3. Data Framing.........................................9 Schwarz Expires April 2, 2016 [Page 2] Internet-Draft SDP codepoints for gateway control October 2015 5.1.4. Data Sending and Reporting...........................9 5.1.5. Session Closing......................................9 5.2. Support of T.140-specific Functions.......................9 6. Gateway Configurations........................................10 6.1. Introduction.............................................10 6.2. Gateway-embedded Interworking Functions for T.140........10 6.2.1. WebRTC T.140 text to IP text telephony in text conversation mode..........................................10 6.2.2. WebRTC T.140 text to IP text telephony in text relay mode.......................................................10 6.2.3. WebRTC T.140 text to IP text telephony in text pass- through mode...............................................11 6.2.4. WebRTC T.140 text to PSTN text telephony............11 6.3. Example gateway configuration in more detail.............11 6.3.1. Interworking support by WebRTC gateway..............12 6.3.2. WebRTC domain: SCTP stream configuration............12 6.3.3. Non-WebRTC domain: "RFC 4103/RTP"-endpoint emulation12 7. Security Considerations.......................................13 8. IANA Considerations...........................................13 9. References....................................................13 9.1. Normative References.....................................13 9.2. Informative References...................................13 10. Acknowledgments..............................................14 11. CHANGE LOG...................................................16 11.1. Initial draft-schwarz-mmusic-t140-usage-data-channel-00.16 11.1.1. Status.............................................16 11.1.2. Changes against "draft-ietf-mmusic-msrp-usage-data- channel-01"................................................16 11.2. Changes against draft-schwarz-mmusic-t140-usage-data- channel-01....................................................16 11.3. Changes against draft-schwarz-mmusic-t140-usage-data- channel-02....................................................16 12. Backup material: Discussion of realtime text service handling within WebRTC....................................................17 1. Introduction 1.1. Motivation Recommendation ITU-T T.140 [ITU-T T.140] defines a protocol for text conversation, also known as realtime text or text telephony. The native transport for IP networks is based on the Real-time Transport Protocol (RTP; see [RFC4103]) due to its inherent realtime characteristics, similar as conversational audio and video services. WebRTC text conversation is based on T.140, but considered as "data traffic" component (despite the fact of the native RTP-based Schwarz Expires April 2, 2016 [Page 3] Internet-Draft SDP codepoints for gateway control October 2015 transport in non-WebRTC environments), see [I-D.ietf-rtcweb-data- channel]. NOTE - The decision to transport realtime text over a data channel in WebRTC (instead of RTP based transport) is constituted by use case "U-C 5: Realtime text chat during an audio and/or video call with an individual or with multiple people in a conference", see clause 3.2/[I-D.ietf-rtcweb-data-channel]. This document defines the SDP-based negotiation and transport of the T.140 protocol over data channels, where a data channel is a bi- directional communication channel running on top of SCTP/DTLS (as per [I-D.ietf-rtcweb-data-channel]) and where T.140 is instantiated as a sub-protocol of this data channel. Considering an T.140 endpoint being an T.140 application that uses data channel from WebRTC specifications [I-D.ietf-rtcweb-data- channel], this document describes two configurations where the other endpoint is respectively either another T.140 over data channel endpoint (e.g., a WebRTC application) or an T.140 endpoint using native RTP transport. 1.2. Framework of WebRTC data applications There are multiple IP application protocols which using WebRTC data channels as transport, such as MSRP or BFCP besides T.140. The SDP- based indication and negotiation of such WebRTC data applications at call control signalling level follows common principles. The first WebRTC application from this suite is/was the MSRP-based instant messaging service for WebRTC, see [I-D.ietf-mmusic-msrp-usage-data- channel]. This specification for T.140 was derived from that document and uses an aligned clause structuring. It may be noted that the T.140 protocol as such is much simpler in comparison to the MSRP, which requires an extensive set of SDP elements (in comparison to T.140) for the description of specific MSRP services and their protocol parameter settings. 2. Conventions 2.1. Prescriptive language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Schwarz Expires April 2, 2016 [Page 4] Internet-Draft SDP codepoints for gateway control October 2015 2.2. Notation The brief notation "T.140" is used as a synonym for the text conversation protocol according to [ITU-T T.140]. 3. Terminology and abbreviations 3.1. Terminology used This document uses the following terms: Data channel: A WebRTC data channel as specified in [I-D.ietf- rtcweb-data-channel]. T.140 data channel: A data channel specifically used to transport the text and presentation control information of one T.140 session. External negotiation: Data channel negotiation based on out-of-band or in-band mechanisms other than the Data Channel Establishment Protocol specified in [I-D.ietf-rtcweb-data-protocol]. In-band: Transmission through the peer-to-peer SCTP association. Out-of-band: Transmission through the call control signaling path, e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer model [RFC3264]. Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDP offerer 3.2. Abbreviations used DS0 Digital Signal 0 (1 x 64 kilobits per second) DTLS Datagram Transport Layer Security GCP Gateway Control Protocol ITU-T International Telecommunication Union Telecommunication Standardization Sector IWF Interworking Function JSEP Javascript Session Establishment Protocol Schwarz Expires April 2, 2016 [Page 5] Internet-Draft SDP codepoints for gateway control October 2015 MG (H.248) Media Gateway MGC (H.248) Media Gateway Controller PDU Protocol Data Unit RTP Real-time Transport Protocol SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol TDM (Synchronous) Time Division Multiplexing ToIP Text over IP TLS Transport Layer Security UA User Agent UDP User Datagram Protocol VBD Voiceband Data 4. Prinicples 4.1. T.140 Data Channel In this document, an T.140 data channel is a data channel for which the instantiated sub-protocol is "t140", and where the T.140-related negotiation is done as part of the SDP-based external negotiation method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. NOTE - This WebRTC term of a "T.140 data channel" is actually synonym to the originally introduced concept of a "T.140 data channel"] for the T.140 protocol back in 1998, see [ITU-T T.140], clause 4.3. 4.2. Session Mapping In this design, the T.140 session maps to the SCTP association and the "SCTP stream pair" assigned to the data channel, and each T.140 session maps to one data channel exactly. Schwarz Expires April 2, 2016 [Page 6] Internet-Draft SDP codepoints for gateway control October 2015 5. End-to-End Configuration This section describes the network configuration where each T.140 endpoint is running T.140 over a data channel. 5.1. Basic T.140 Support 5.1.1. Session Negotiation 5.1.1.1. Use of dcmap Attribute The SDP offer SHALL include a dcmap attribute line (defined in [I- D.ietf-mmusic-data-channel-sdpneg], within the media description for the SCTP association for each T.140 data channel session to be negotiated. The attribute includes the following data channel parameters: o "label=" labelstring o "subprotocol=" "t140" 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. Rest of the SDP offer/answer procedures are per [I-D.ietf-mmusic- data-channel-sdpneg]. The following is an example of the dcmap attribute for an T.140 session to be negotiated (on default SCTP port 5000) with stream=3 and without any label: a=dcmap:3 subprotocol="t140" 5.1.1.2. Use of dcsa Attribute The SDP offer MAY also include a dcsa attribute line (defined in [I- D.ietf-mmusic-data-channel-sdpneg]) within the media description for the SCTP association for each T.140-specific SDP attribute to be negotiated for each T.140 data channel being negotiated. The T.140-specific items that can be negotiated include at least following attribute: o defined in [RFC4103], clause 6: the media format parameter "character transmission rate", indicated with "cps". Schwarz Expires April 2, 2016 [Page 7] Internet-Draft SDP codepoints for gateway control October 2015 NOTE - The "cps" parameter is optional and only required for specific network interworking cases, see clause 6/[RFC4103]. It is expected that this SDP parameter is for instance not required for end-to-end text/T.140 data channels between two or multiple WebRTC clients, but might be for instance required in case of interworking with PSTN text telephony (see clause 6.2.4). The SDP answer SHALL include zero or more corresponding dcsa attribute lines for each negotiated T.140 session, according to the T.140-specific attribute negotiation rules in the corresponding specifications. A new SDP offer/answer MAY update the T.140 subprotocol attribute(s) while keeping the same subprotocol a=dcmap description. 5.1.1.3. Example SDP Negotiation The following is an example of an "m"-line for data channels in an SDP offer that includes the attributes needed to establish a T.140 session: m=application 911 /DTLS/SCTP webrtc-datachannel c=IN IP4 11.9.19.65 a=max-message-size:1000 ; "much smaller than e.g. MSRP" a=sctp-port 5000 a=dcmap:1 label="text conversation";subprotocol="t140" a=dcsa:1 cps=30 ; "the RFC4103 default value as example" 5.1.2. Session Opening [ITU-T T.140], clause 6.1 describes the generic T.140 session control functions at high-level and a signalling protocol independent manner. WebRTC-embedded T.140 sessions uses the data channel established for this T.140 session by the generic data channel opening procedure defined in [I-D.ietf-mmusic-data-channel- sdpneg]. As soon as this data channel is opened, the T.140 session is actually in the (virtual) state "data transfer ready". NOTE - The user plane protocol T.140 itself is stateless. The (T.140)-session-endpoint could be abstracted by a two-state model from signalling plane perspective (with states "Idle" and "Data Transfer Ready"). Schwarz Expires April 2, 2016 [Page 8] Internet-Draft SDP codepoints for gateway control October 2015 5.1.3. Data Framing Each T140block is sent on the corresponding SCTP stream using standard T.140 transmission procedures, as defined in [ITU-T T.140], with each T.140 chunk delivered in a single SCTP user message. NOTE - A T140block as service data unit represents one or multiple characters according to the syntax of clause 8 in [ITU-T T.140]. 5.1.4. Data Sending and Reporting Data sending and reporting procedures SHALL conform to [ITU-T T.140]. 5.1.5. Session Closing Closing of an T.140 session SHALL be done using the generic data channel closing procedure defined in [I-D.ietf-mmusic-data-channel- sdpneg]. The port value for the "m="-line SHOULD NOT be changed (e.g., to zero) when closing an T.140 session (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. The SDP answerer SHALL ensure that no dcmap or dcsa attributes are present in the SDP answer if no corresponding attributes are present in the received SDP offer. 5.2. Support of T.140-specific Functions In general, the recommended procedures of clause 5 from [RFC4103] SHOULD be applicable as well for SCTP-based transport of T.140. NOTE - [RFC4103] defines T.-140-over-RTP: the procedures of clauses 5.1 and 5.2 are transport protocol independent, hence valid for SCTP too. Clauses 5.3 and 5.4 are RTP specific due unreliable transport, hence not expected to be relevant for SCTP (to be confirmed). Schwarz Expires April 2, 2016 [Page 9] Internet-Draft SDP codepoints for gateway control October 2015 6. Gateway Configurations 6.1. Introduction This section describes the network configuration where one T.140 endpoint uses data channels as T.140 transport, the other T.140 endpoint uses a different protocol stack. There is consequently an interworking function (IWF) in the media plane required, associated with correspondent interworking in the signalling plane. Such type of IWFs are provided by gateway devices, given here by WebRTC gateways as defined by [I-D.ietf-rtcweb-gateways], [ITU-T H.248.94], [3GPP 29.334], etc. 6.2. Gateway-embedded Interworking Functions for T.140 There are a plethora of interworking functions knowns for T.140 [ITU-T T.140] due to the long history and usage of this service in legacy packet-switched and circuit-switched networks. Some examples are indicated below. 6.2.1. WebRTC T.140 text to IP text telephony in text conversation mode Service "IP text telephony in text conversation mode": Transport service according to [RFC4103]. Media plane IWF: "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" to "T.140-over-RTP/UDP" 6.2.2. WebRTC T.140 text to IP text telephony in text relay mode Service "IP text telephony in text relay mode": Transport of T.140 over IP networks, according to [ITU-T V.151]. Also known as Text-over-IP (ToIP). Media plane IWF: "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" to "T.140-over-IP TLP-UDP". NOTE: [ITU-T V.151] uses the concept of an "IP Transport Layer Protocol" (IP-TLP) above the native IP transport layer, which Schwarz Expires April 2, 2016 [Page 10] Internet-Draft SDP codepoints for gateway control October 2015 again allows different framing protocol options (such as RTP-based or SPRT-based framing (Simple Packet Relay Transport, see Annex B of [ITU-T V.150.1])). 6.2.3. WebRTC T.140 text to IP text telephony in text pass-through mode Service "IP text telephony in text pass-through mode": Transport of analogue PSTN text telephones signals over PCM encoded voice over IP networks, according to [ITU-T V.152]. Also known as Voiceband-over-IP (VBDoIP). Media plane IWF: "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" to "text/modem-over-G.711-over-RTP/UDP". NOTE: This is the VBD mode according to [ITU-T V.152], using ITU-T G.711 as VBD codec (i.e., a different codec configuration as in comparison to G.711 as audio codec). 6.2.4. WebRTC T.140 text to PSTN text telephony Service "PSTN text telephony": Transport of analogue PSTN text telephones signals over a) analogue lines or b) circuit-switched 64-kbit/s channels. Media plane IWF: "T.140-over-SCTP stream-over-SCTP association-over-DTLS-over-L4" to "text/modem-over-DS0/TDM" (in case of circuit-switched networks). 6.3. Example gateway configuration in more detail The signalling plane and media plane interworking functions are elaborated in more detail at the example of a WebRTC gateway with support of interworking to IP text telephony in text conversation mode. Schwarz Expires April 2, 2016 [Page 11] Internet-Draft SDP codepoints for gateway control October 2015 This example describes the network configuration where one T.140 endpoint uses data channels as T.140 transport, the other T.140 endpoint uses RTP/UDP connections as T.140 transport, and the two T.140 endpoints interwork via an appropriate interworking function (see also [ITU-T H.248.94], Appendix <#>). 6.3.1. Interworking support by WebRTC gateway The WebRTC gateway interconnects two IP network domains, - there are specific considerations: 1. WebRTC domain: Application specific configuration of the SCTP stream is necessary in order to satisfy T.140 requirements concerning reliable transport. 2. Non-WebRTC domain: The WebRTC gateway needs to emulate a "T.140/RTP"-endpoint in the non-WebRTC domain, which implies an RTP source/RTP sink behaviour according to [RFC4103]. Hence, the WEBRTC gateway is required to be aware about the IP application protocol T.140 despite the fact of transparent forwarding mode. The "T.140 awareness" by the WEBRTC gateway is limited to the detection of active/silence periods related to the transfer of T.140 PDUs, as well as a "packet loss concealment" method related to incoming T.140/RTP packets. Next two sub-clauses refer to possible solutions. 6.3.2. WebRTC domain: SCTP stream configuration FIXTHIS 6.3.3. Non-WebRTC domain: "RFC 4103/RTP"-endpoint emulation There are three aspects of consideration: R1: Inactivity of T.140 traffic in RTP send direction? R2: Incoming RTP packets out of order? R3: Incoming RTP packets lost? See [ITU-T H.248.94], Appendix <#> concerning possible WebRTC gateway behaviour in order to address above events. Schwarz Expires April 2, 2016 [Page 12] Internet-Draft SDP codepoints for gateway control October 2015 7. Security Considerations FIXTHIS 8. IANA Considerations FIXTHIS 9. References 9.1. Normative References [RFC2119] RFC 2119 (03/1997), "Key words for use in RFCs to Indicate Requirement Levels", BCP 14. [RFC3264] RFC 3264 (06/2002), "An Offer/Answer Model with the Session Description Protocol (SDP)". [RFC4103] RFC 4103 (06/2005), "RTP Payload for Text Conversation". [RFC4566] RFC 4566 (07/2006), "SDP: Session Description Protocol". [I-D.ietf-rtcweb-data-protocol] draft-ietf-rtcweb-data-channel (##/2015), "WebRTC Data Channel Establishment Protocol". [I-D.ietf-rtcweb-data-channel] http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data- channel/draft-ietf-rtcweb-data-channel (##/2015), "WebRTC Data Channels". [I-D.ietf-mmusic-data-channel-sdpneg] draft-ietf-mmusic-data- channel-sdpneg (##/2015), "SDP-based Data Channel Negotiation". [I-D.ietf-mmusic-msrp-usage-data-channel] draft-ietf-mmusic-msrp- usage-data-channel (##/2015), "MSRP over Data Channels". [ITU-T T.140] Recommendation ITU-T T.140 (02/1998), "Protocol for multimedia application text conversation". Free copy via: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- T.140-199802-I!!PDF-E&type=items 9.2. Informative References [I-D.ietf-rtcweb-gateways] draft-ietf-rtcweb-gateways (##/2015), "WebRTC Gateways". Schwarz Expires April 2, 2016 [Page 13] Internet-Draft SDP codepoints for gateway control October 2015 [ITU-T H.248.94] Recommendation ITU-T H.248.94 (10/2015), "Web- based real-time communication services - H.248 protocol support and profile guidelines". Status: still work in progress in ITU-T SG16 Question 3 Free copy via: FIXTHIS [ITU-T V.151] Recommendation ITU-T V.151 (05/2006), "Procedures for the end-to-end connection of analogue PSTN text telephones over an IP network utilizing text relay". Free copy via: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- V.151-200605-I!!PDF-E&type=items [ITU-T V.152] Recommendation ITU-T V.152 (09/2010), "Procedures for supporting voice-band data over IP networks". Free copy via: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC- V.152-201009-I!!PDF-E&type=items [3GPP 29.334] 3GPP TS 29.334 Release 13 (2015), "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IMS Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW); Iq Interface; Stage 3". Free copy via: ftp://ftp.3gpp.org/specs/archive/29_series/29.334/ 10. Acknowledgments FIXTHIS Schwarz Expires April 2, 2016 [Page 14] Internet-Draft SDP codepoints for gateway control October 2015 Authors' Addresses Keith Drage (editor) Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon UK Email: keith.drage@alcatel-lucent.com Dr. Juergen Stoetzer-Bradler Alcatel-Lucent Lorenzstrasse 10 D-70435 Stuttgart GERMANY Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com Dr. Albrecht Schwarz Alcatel-Lucent Lorenzstrasse 10 D-70435 Stuttgart GERMANY Email: Albrecht.Schwarz@alcatel-lucent.com Schwarz Expires April 2, 2016 [Page 15] Internet-Draft SDP codepoints for gateway control October 2015 11. CHANGE LOG 11.1. Initial draft-schwarz-mmusic-t140-usage-data-channel-00 11.1.1. Status o The initial document represents a skeleton where still a number of clauses are still empty. o The intention is to propose a document structure aligned with the MSRP draft, and to emphasize WebRTC gateway flavours. 11.1.2. Changes against "draft-ietf-mmusic-msrp-usage-data-channel-01" o Replace protocol "MSRP" by "T.140" plus protocol specific adaptations o Initial scope of gateway section 11.2. Changes against draft-schwarz-mmusic-t140-usage-data-channel-01 o Reference to rtcweb draft inserted which defines realtime text transport in WebRTC. o Initial input text added to the majority of "placeholder sections" from the -00 version. 11.3. Changes against draft-schwarz-mmusic-t140-usage-data-channel-02 o uppercase of modal vers o clause 5.1.1.2: clarification fixed o clause 5.1.2: clarification fixed o clause 5.1.3: clarification fixed o clause 5.2: clarification fixed o clause 6.3: initial description inserted Schwarz Expires April 2, 2016 [Page 16] Internet-Draft SDP codepoints for gateway control October 2015 12. Backup material: Discussion of realtime text service handling within WebRTC {Editor's comment: this clause is only temporary and will be deleted again as soon as draft becomes technically stable.} RTCWEB email threads (non-exhaustive list): o 2012-11 Subject: "[rtcweb] Text communication in RTCWEB sessions" https://mailarchive.ietf.org/arch/msg/rtcweb/Vx6ZbLPPh4vsG25UPZlR Xq_ffM0 o 2012-11 Subject: "[rtcweb] Text communication requirements for RTCWEB" https://mailarchive.ietf.org/arch/msg/rtcweb/JXesT_A6vOMs_N05fWaF DGPKryo o 2012-11 Subject: "[rtcweb] Text communication SDP in RTCWEB" https://mailarchive.ietf.org/arch/msg/rtcweb/EQI3Trtzmhnlh15Jocil TxbWHt0 o 2012-11 Subject: "[rtcweb] Consensus call on Text Communication" https://mailarchive.ietf.org/arch/msg/rtcweb/viAKLXAAs0mKXL8xwXRB 1nthPhg o 2012-12 Subject: "[rtcweb] Real-time text implementations" https://mailarchive.ietf.org/arch/msg/rtcweb/YNlKMFuzbVo2SnZHzICy ruf4x9I o 2013-05 Subject: "[rtcweb] RTT (was Re: No Plan)" https://mailarchive.ietf.org/arch/msg/rtcweb/iDXc5DFMJIgiEPCWnyvV dNFlOPo o 2013-05 Subject: "[rtcweb] RTT Education: Neat Demonstration of NON-peer-to-peer RTT (for future webrtc standardization purposes)" https://mailarchive.ietf.org/arch/msg/rtcweb/bfUUQXP_cG- 63wBpS0JH62vCf4c o 2013-12 Subject: "[rtcweb] Real-time text" https://mailarchive.ietf.org/arch/msg/rtcweb/Hsvm7gzybT1MNYXBzbJR EOvy3zY o 2014-08 Subject: "[rtcweb] draft-ietf-rtcweb-data-channel failure handling description" https://mailarchive.ietf.org/arch/msg/rtcweb/BqBrwBlrT4h9aAmEzQkY b-3on7Q Schwarz Expires April 2, 2016 [Page 17] Internet-Draft SDP codepoints for gateway control October 2015 o 2015-02 Subject: "[rtcweb] Use of redundancy and RFC 2119 language in draft-ietf-rtcweb-fec-00" https://mailarchive.ietf.org/arch/msg/rtcweb/HYMplbKGmBOUUR_VQiAB BjMfDBY Schwarz Expires April 2, 2016 [Page 18]