[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 draft-ietf-mmusic-t140-usage-data-channel

MMUSIC Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                          August 9, 2019
Expires: February 10, 2020


           T.140 Text Conversation over WebRTC Data Channels
            draft-holmberg-mmusic-t140-usage-data-channel-00

Abstract

   This document specifies how a WebRTC data channel can be used as a
   transport mechanism for the ITU-T Protocol for multimedia application
   text conversation (Recommendation ITU-T T.140), and how the SDP
   offer/answer mechanism can be used to negotiate such data channel,
   referred to as T.140 data channel.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 10, 2020.

Copyright Notice

   Copyright (c) 2019 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Holmberg                Expires February 10, 2020               [Page 1]


Internet-Draft             T.140 Data Channel                August 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SDP Considerations  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Use of dcmap Attribute  . . . . . . . . . . . . . . . . .   3
     3.2.  Use of dcsa Attribute . . . . . . . . . . . . . . . . . .   4
     3.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  T.140 Considerations  . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Session Layer Functions . . . . . . . . . . . . . . . . .   5
     4.2.  Data Encoding and Sending . . . . . . . . . . . . . . . .   5
     4.3.  Data Buffering  . . . . . . . . . . . . . . . . . . . . .   5
   5.  Gateway Considerations  . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The ITU-T Protocol for multimedia application text conversation
   (Recommendation ITU-T T.140) [T140] 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) [RFC4103].

   This document specifies how a WebRTC data channel
   [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism
   for T.140, and how the SDP offer/answer mechanism
   [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such
   data channel.

   In this document, a T.140 data channel refers to a WebRTC data
   channel for which the instantiated sub-protocol is "t140", and where
   the channel is negotiated using the SDP-based external negotiation
   method [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 Section 4.3 of [T140].

   NOTE - The decision to transport realtime text over a data channel,
   instead of using RTP based transport [RFC4103], in WebRTC is
   constituted by use-case "U-C 5: Realtime text chat during an audio




Holmberg                Expires February 10, 2020               [Page 2]


Internet-Draft             T.140 Data Channel                August 2019


   and/or video call with an individual or with multiple people in a
   conference", see Section 3.2 of [I-D.ietf-rtcweb-data-channel].

   The brief notation "T.140" is used as a synonym for the text
   conversation protocol according to [T140].

   This document is based on an earlier Internet draft edited by Keith
   Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  SDP Considerations

   The generic SDP considerations, including the SDP Offer/Answer
   proceudres, for negotiating a WebRTC data channel are defined in
   [I-D.ietf-mmusic-data-channel-sdpneg].  This section defines the SDP
   considerations that are specific to a T.140 data channel.

3.1.  Use of dcmap Attribute

   An offerer and answerer MUST, in each offer and answer, include an
   SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the
   SDP media descripton (m= line) [RFC4566] describing the SCTP
   association [RFC4960] used to realize the T.140 data channel.

   The offerer and answerer MUST include the following attribute
   parameters, and parameter values in the dcmap attribute:

   o  "label=" labelstring
   o  "subprotocol=" "t140"

   The offerer and answerer MUST NOT include the max-retr, max-time and
   ordered attribute parameters in the dcmap attribute.

   The offerer and answerer MAY, based on local policy, include the
   priority attribute parameter in the dcmap attribute value.

   Below is an example of the dcmap attribute for an T.140 data channel
   with stream=3 and without any label:

   a=dcmap:3 subprotocol="t140"




Holmberg                Expires February 10, 2020               [Page 3]


Internet-Draft             T.140 Data Channel                August 2019


3.2.  Use of dcsa Attribute

   An offerer and answerer MAY, in each offer and answer, include an SDP
   'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP
   media descripton (m= line) describing the SCTP association used to
   realize the T.140 data channel.

   If included, the 'dcsa' attribute contains the fmtp attribute used to
   indicate a maximum character transmission rate [RFC4103].  The 'cps'
   attribute parameter is used indicate the maximum character
   transmission rate that the endpoint that includes the attribute is
   able to handle.  The 'format' attribute parameter is not used with
   T.140 data channels, and MUST be set to "-".

   If not included, it indicates that no maximum character transmission
   rate is indicated.  It does not mean that the default value of 30
   applies [RFC4103].

   The offerer and answerer MAY modify the 'cpc' attribute parameter
   value in subsequent offers and answers.

   NOTE: The 'cps' attribute parameter is especially useful when a T.140
   data channel endpoint is acting as a gateway [Section 5] and is
   interworking with a T.140 transport mechanism that have restrictions
   on how many characters can be sent per second.

   Below is an example of the dcsa attribute for an T.140 data channel
   with a 'cps' attribute parameter with a attribute parameter value of
   20:

   a=dcsa:1 fmtp:- cps=20

3.3.  Example

   Below is an example of an SDP media description (m= line) describing
   an SCTP association used to realize a T.140 data channel.


       m=application 911 UDP/DTLS/SCTP webrtc-datachannel
       c=IN IP6 2001:db8::3
       a=max-message-size:1000
       a=sctp-port 5000
       a=dcmap:1 label="text conversation";subprotocol="t140"
       a=dcsa:1 fmtp:- cps=20







Holmberg                Expires February 10, 2020               [Page 4]


Internet-Draft             T.140 Data Channel                August 2019


4.  T.140 Considerations

4.1.  Session Layer Functions

   Section 6.1 of [T140] describes the generic T.140 session control
   functions at high-level and a signalling protocol independent manner.
   The list below describes how the functions are realized when using a
   T.140 data channel.

   o  Prepare session: An endpoint can indicate its support of T.140
      data channels using signalling specific means (e.g., using SIP
      OPTIONS [RFC3261]), or by indicating the support in an offer or
      answer (Section 3)
   o  Initiate session: An offer used to request the establishment of a
      T.140 data channel (Section 3)
   o  Accept session: An answer used to accept a request to establish a
      T.140 data channel (Section 3)
   o  Deny session: An answer used to reject a request the establishment
      of a T.140 data channel, using the generic procedures for
      rejecting a data channel [I-D.ietf-mmusic-data-channel-sdpneg]
   o  Disconnect session: An offer or answer used to disable a
      previously established T.140 data channel, using the generic
      procedures for closing a data channel
      [I-D.ietf-mmusic-data-channel-sdpneg]
   o  Data: Data sent on an established T.140 data channel (Section 4.2)

4.2.  Data Encoding and Sending

   T.140 text is encoded and framed as T140blocks [RFC4103].

   Each T140block is sent on the SCTP stream [RFC4960] used to realize
   the T.140 data channel using standard T.140 transmission procedures
   [T140].  One or more T140blocks can be sent in a single SCTP user
   message [RFC4960].  Unlike RTP based transport for realtime text
   [RFC4103], T.140 data channels do not use reduntant transmission of
   text.

   Data sending and reporting procedures conform to [T140].

   See Section 8 of [T140] for coding details.

4.3.  Data Buffering

   As described in [T140], buffering can be used to reduce overhead,
   with the maximum buffering time being 500 ms.  It can also be used
   for staying within the maximum character transmission rate
   (Section 3.2), if such has been provided by the peer.




Holmberg                Expires February 10, 2020               [Page 5]


Internet-Draft             T.140 Data Channel                August 2019


5.  Gateway Considerations

   Multiple transport mechanisms have been defined for T.140 [T140], due
   to the long history and usage of the service in legacy packet-
   switched and circuit-switched networks.  Some examples are listed
   below:

   o  IP text telephony in text conversation mode [RFC4103]
   o  IP text telephony in text relay mode, also known as Text-over-IP
      (ToIP) [V151]
   o  IP text telephony in text pass-through mode, also known as
      Voiceband-over-IP (VBDoIP) [V152]
   o  PSTN text telephony

   In addition to simply moving text between two transport mechanisms, a
   gateway might have to perform procedures related to events like
   inactivity of T.140 traffic, RTP packets received out of order and
   loss of incoming RTP packets.

   The detailed gateway procedures for interworking between T.140 over
   data channel and other T.140 transport mechanisms are outside the
   scope of this document.

6.  Security Considerations

   The generic security considerations for WebRTC data channels are
   defined in [I-D.ietf-rtcweb-data-channel].  As data channels are
   always encrypted by design, the T.140 data channels will also be
   encrypted.

   The generic security considerations for the SDP-based external
   negotiation method are defined in
   [I-D.ietf-mmusic-data-channel-sdpneg].

7.  IANA considerations

   [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the
   RFC number of this document.]

   This document adds the subprotocol identifier "t140" to the
   "WebSocket Subprotocol Name Registry" as follows:

                +--------------------------+-------------+
                | Subprotocol Identifier:  | t140        |
                | Subprotocol Common Name: | ITU-T T.140 |
                | Subprotocol Definition:  | RFCXXXX     |
                | Reference:               | RFCXXXX     |
                +--------------------------+-------------+



Holmberg                Expires February 10, 2020               [Page 6]


Internet-Draft             T.140 Data Channel                August 2019


8.  Acknowledgements

   This document is based on an earlier Internet draft edited by Keith
   Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.

   Thomas Belling provided useful comments on the initial (pre-
   submission) version of the draft.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
              editor.org/info/rfc3264>.

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
              <https://www.rfc-editor.org/info/rfc4103>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <https://www.rfc-editor.org/info/rfc4566>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [I-D.ietf-rtcweb-data-channel]
              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
              Channels", draft-ietf-rtcweb-data-channel-13 (work in
              progress), January 2015.

   [I-D.ietf-mmusic-data-channel-sdpneg]
              Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
              Even, "SDP-based Data Channel Negotiation", draft-ietf-
              mmusic-data-channel-sdpneg-28 (work in progress), May
              2019.



Holmberg                Expires February 10, 2020               [Page 7]


Internet-Draft             T.140 Data Channel                August 2019


   [T140]     ITU-T, "Recommendation ITU-T T.140 (02/1998), "Protocol
              for multimedia application text conversation"", February
              1998.

9.2.  Informative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
              editor.org/info/rfc3261>.

   [V151]     ITU-T, "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"", May
              2006.

   [V152]     ITU-T, "Recommendation ITU-T V.152 (09/2010), "Procedures
              for supporting voice-band data over IP networks"",
              September 2010.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com





















Holmberg                Expires February 10, 2020               [Page 8]


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