[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

WG MMUSIC                                              Keith Drage, Ed.
Internet Draft                                 Juergen Stoetzer-Bradler
Intended status: Standards track                       Albrecht Schwarz
Expires: October 2016                                             Nokia
                                                          April 4, 2016


                T.140 Text Conversation over Data Channels
            draft-schwarz-mmusic-t140-usage-data-channel-03.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 October 4, 2016.




Schwarz                Expires October 4, 2016                 [Page 1]


Internet-Draft    SDP codepoints for gateway control         April 2016


Copyright Notice

   Copyright (c) 2016 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 October 4, 2016                 [Page 2]


Internet-Draft    SDP codepoints for gateway control         April 2016


         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. Gateway configuration and procedures in more detail......12
         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...................................14
   10. Acknowledgments..............................................15
   11. CHANGE LOG...................................................17
      11.1. Initial draft-schwarz-mmusic-t140-usage-data-channel-00.17
         11.1.1. Status.............................................17
         11.1.2. Changes against "draft-ietf-mmusic-msrp-usage-data-
         channel-01"................................................17
      11.2. Changes against draft-schwarz-mmusic-t140-usage-data-
      channel-01....................................................17
      11.3. Changes against draft-schwarz-mmusic-t140-usage-data-
      channel-02....................................................17
      11.4. Changes against draft-schwarz-mmusic-t140-usage-data-
      channel-03....................................................17
   12. Backup material: Discussion of realtime text service handling
   within WebRTC....................................................18

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.



Schwarz                Expires October 4, 2016                 [Page 3]


Internet-Draft    SDP codepoints for gateway control         April 2016


   WebRTC text conversation is based on T.140, but considered as "data
   traffic" component (despite the fact of the native RTP-based
   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 October 4, 2016                 [Page 4]


Internet-Draft    SDP codepoints for gateway control         April 2016


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 October 4, 2016                 [Page 5]


Internet-Draft    SDP codepoints for gateway control         April 2016


   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 October 4, 2016                 [Page 6]


Internet-Draft    SDP codepoints for gateway control         April 2016


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 October 4, 2016                 [Page 7]


Internet-Draft    SDP codepoints for gateway control         April 2016


     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 <L4>/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";
                   ordered=true;max-time=???;max-retr=??? ; NOTE 1
         a=dcsa:1 fmtp:- cps=30  ; NOTE 2

     NOTE 1 - Maximum number of retransmissions = ??? (because FIXTHIS
     <Gunnar>);
              Maximum retransmission timing     = ??? (because FIXTHIS
     <Gunnar>).

     NOTE 2 - "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].



Schwarz                Expires October 4, 2016                 [Page 8]


Internet-Draft    SDP codepoints for gateway control         April 2016


   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").



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


Schwarz                Expires October 4, 2016                 [Page 9]


Internet-Draft    SDP codepoints for gateway control         April 2016


     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).



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.

   Editor's note: clause 6.2 should be moved in an informative
   Appendix. Normative scope of this draft is 6.2.1 only.

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":




Schwarz                Expires October 4, 2016                [Page 10]


Internet-Draft    SDP codepoints for gateway control         April 2016


     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
     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).


Schwarz                Expires October 4, 2016                [Page 11]


Internet-Draft    SDP codepoints for gateway control         April 2016




6.3. Gateway configuration and procedures 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.

   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:


Schwarz                Expires October 4, 2016                [Page 12]


Internet-Draft    SDP codepoints for gateway control         April 2016


   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. The required
   gateway T.140 protocol interventions SHALL be compliant to
   [RFC4103], [ITU-T T.140] and [ITU-T T.140Add1].

   Editor's note: it was mentioned that an "application level" keep
   alive mechanism might need to be supported by the WebRTC gateway in
   case of NAT traversal support requirements, i.e.,.a mechanism such
   as outlined by RFC 6263 "Application Mechanism for Keeping Alive the
   NAT Mappings Associated with RTP / RTP Control Protocol (RTCP)
   Flows".

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".


Schwarz                Expires October 4, 2016                [Page 13]


Internet-Draft    SDP codepoints for gateway control         April 2016


   [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

   [ITU-T T.140Add1] Recommendation ITU-T T.140 Addendum 1 (02/2000),
             "Protocol for multimedia application text conversation -
             Addendum 1".
             Free copy via:
             https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-
             T.140-200002-I!Add1!PDF-E&type=items

9.2. Informative References

   [I-D.ietf-rtcweb-gateways] draft-ietf-rtcweb-gateways (##/2015),
             "WebRTC Gateways".

   [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






Schwarz                Expires October 4, 2016                [Page 14]


Internet-Draft    SDP codepoints for gateway control         April 2016


   [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 October 4, 2016                [Page 15]


Internet-Draft    SDP codepoints for gateway control         April 2016


Authors' Addresses

   Keith Drage (editor)
   Nokia
   Quadrant, Stonehill Green, Westlea
   Swindon
   UK

   Email: keith.drage@nokia.com


   Dr. Juergen Stoetzer-Bradler
   Nokia
   Lorenzstrasse 10
   D-70435 Stuttgart
   GERMANY

   Email: Juergen.Stoetzer-Bradler@nokia.com


   Dr. Albrecht Schwarz
   Nokia
   Lorenzstrasse 10
   D-70435 Stuttgart
   GERMANY

   Email: Albrecht.Schwarz@nokia.com






















Schwarz                Expires October 4, 2016                [Page 16]


Internet-Draft    SDP codepoints for gateway control         April 2016


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

11.4. Changes against draft-schwarz-mmusic-t140-usage-data-channel-03

   o  Editorial: update of author addresses

   o  Indication of some issues for clarification (by editor notes)



Schwarz                Expires October 4, 2016                [Page 17]


Internet-Draft    SDP codepoints for gateway control         April 2016




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





Schwarz                Expires October 4, 2016                [Page 18]


Internet-Draft    SDP codepoints for gateway control         April 2016


   o  2014-08 Subject: "[rtcweb] draft-ietf-rtcweb-data-channel failure
      handling description"
      https://mailarchive.ietf.org/arch/msg/rtcweb/BqBrwBlrT4h9aAmEzQkY
      b-3on7Q

   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 October 4, 2016                [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/