Internet DRAFT - draft-schwarz-mmusic-t140-usage-data-channel
draft-schwarz-mmusic-t140-usage-data-channel
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]
