forked from cdh4u/draft-datachannel-t140
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-holmberg-mmusic-t140-usage-data-channel.txt
448 lines (290 loc) · 16.3 KB
/
draft-holmberg-mmusic-t140-usage-data-channel.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
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: [email protected]
Holmberg Expires February 10, 2020 [Page 8]