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
|
<pre>Network Working Group A. Sollaud
Request for Comments: 5459 France Telecom
Updates: <a href="./rfc4749">4749</a> January 2009
Category: Standards Track
<span class="h1">G.729.1 RTP Payload Format Update:</span>
<span class="h1">Discontinuous Transmission (DTX) Support</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/</a>
<a href="http://trustee.ietf.org/license-info">license-info</a>) 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 updates the Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous
Transmission (DTX) support to the <a href="./rfc4749">RFC 4749</a> specification, in a
backward-compatible way. An updated media type registration is
included for this payload format.
<span class="grey">Sollaud Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5459">RFC 5459</a> G.729.1 DTX Support in RTP January 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Background ......................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. RTP Header Usage ................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Payload Format ..................................................<a href="#page-3">3</a>
<a href="#section-5">5</a>. Payload Format Parameters .......................................<a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. Media Type Registration Update .............................<a href="#page-4">4</a>
<a href="#section-5.2">5.2</a>. Mapping to SDP Parameters ..................................<a href="#page-5">5</a>
<a href="#section-5.2.1">5.2.1</a>. DTX Offer-Answer Model Considerations ...............<a href="#page-5">5</a>
<a href="#section-5.2.2">5.2.2</a>. DTX Declarative SDP Considerations ..................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Congestion Control ..............................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-6">6</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-6">6</a>
<a href="#section-9">9</a>. References ......................................................<a href="#page-6">6</a>
<a href="#section-9.1">9.1</a>. Normative References .......................................<a href="#page-6">6</a>
<a href="#section-9.2">9.2</a>. Informative References .....................................<a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The International Telecommunication Union (ITU-T) Recommendation
G.729.1 [<a href="#ref-ITU-G.729.1" title=""G.729 based Embedded Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729"">ITU-G.729.1</a>] is a scalable and wideband extension of the
Recommendation G.729 [<a href="#ref-ITU-G.729" title=""Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS- ACELP)"">ITU-G.729</a>] audio codec. [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] specifies
the payload format for packetization of G.729.1-encoded audio signals
into the Real-time Transport Protocol (RTP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
Annex C of G.729.1 [<a href="#ref-ITU-G.729.1-C" title=""G.729.1 DTX/CNG scheme"">ITU-G.729.1-C</a>] adds Discontinuous Transmission
(DTX) support to G.729.1. This document updates the RTP payload
format to allow usage of this Annex.
Only changes or additions to [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] will be described in the
following sections.
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
G.729.1 supports Discontinuous Transmission (DTX), a.k.a. "silence
suppression". It means that the coder includes a Voice Activity
Detection (VAD) algorithm to determine if an audio frame contains
silence or actual audio. During silence periods, the coder may
significantly decrease the transmitted bit rate by sending a small
frame called a Silence Insertion Descriptor (SID) and then stop
transmission. The receiver's decoder will generate comfort noise
(CNG) according to the parameters contained in the SID. This DTX/CNG
scheme is specified in [<a href="#ref-ITU-G.729.1-C" title=""G.729.1 DTX/CNG scheme"">ITU-G.729.1-C</a>].
<span class="grey">Sollaud Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5459">RFC 5459</a> G.729.1 DTX Support in RTP January 2009</span>
The G.729.1 SID has an embedded structure. The core SID is the same
as the legacy G.729 SID [<a href="#ref-ITU-G.729-B" title=""A silence compression scheme for G.729 optimized for terminals conforming to Recommendation V.70"">ITU-G.729-B</a>]. The first enhancement layer
adds some parameters for narrowband comfort noise, while a second
enhancement layer adds wideband information. The G.729.1 SID can be
2, 3, or 6 octets long.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. RTP Header Usage</span>
The fields of the RTP header must be used as described in [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>],
except for the Marker (M) bit.
If DTX is used, the first packet of a talkspurt -- that is, the first
packet after a silence period during which packets have not been
transmitted contiguously -- MUST be distinguished by setting the M
bit in the RTP data header to 1. The M bit in all other packets MUST
be set to 0. The beginning of a talkspurt MAY be used to adjust the
playout delay to reflect changing network delays.
If DTX is not used, the M bit MUST be set to 0 in all packets.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Payload Format</span>
The payload format is the same as in [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>], with the option to
add a SID at the end.
So the complete payload consists of a payload header of 1 octet (MBS
(maximum bit rate supported) and FT (frame type) fields), followed by
zero or more consecutive audio frames at the same bit rate, followed
by zero or one SID.
Note that this is consistent with the payload format of G.729
described in <a href="./rfc3551#section-4.5.6">section 4.5.6 of [RFC3551]</a>.
To be able to transport a SID alone -- that is, without actual audio
frames -- we assign the FT value 14 to the SID. When using FT=14,
only a single SID frame SHALL be included in the payload. The actual
SID size (2, 3, or 6 octets) is inferred from the payload size: it is
the size of what is left after the payload header.
When a SID is appended to actual audio frames, the FT value remains
the one describing the encoding rate of the audio frames. Since the
SID is much smaller than any other frame, it can be easily detected
at the receiver side, and it will not hinder the calculation of the
number of frames. The actual SID size is inferred from the payload
size: it is the size of what is left after the audio frames.
<span class="grey">Sollaud Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5459">RFC 5459</a> G.729.1 DTX Support in RTP January 2009</span>
<a href="./rfc4749#section-5.4">Section 5.4 of [RFC4749]</a> mandates to ignore the remaining bytes after
complete frames. This document overrides that statement: the
receiver of the payload must consider these remaining bytes as a SID
frame. If the size of this remainder is not a valid SID frame size
(2, 3, or 6 octets), the receiver MUST ignore these bytes.
The full FT table is given for convenience:
+-------+---------------+-------------------+
| FT | encoding rate | frame size |
+-------+---------------+-------------------+
| 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets |
| 2 | 14 kbps | 35 octets |
| 3 | 16 kbps | 40 octets |
| 4 | 18 kbps | 45 octets |
| 5 | 20 kbps | 50 octets |
| 6 | 22 kbps | 55 octets |
| 7 | 24 kbps | 60 octets |
| 8 | 26 kbps | 65 octets |
| 9 | 28 kbps | 70 octets |
| 10 | 30 kbps | 75 octets |
| 11 | 32 kbps | 80 octets |
| 12-13 | (reserved) | - |
| 14 | SID | 2, 3, or 6 octets |
| 15 | NO_DATA | 0 |
+-------+---------------+-------------------+
DTX has no impact on the MBS definition and use.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Payload Format Parameters</span>
Parameters defined in [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] are not modified. We add a new
optional parameter to configure DTX.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Media Type Registration Update</span>
We add a new optional parameter to the audio/G7291 media subtype:
dtx: indicates that Discontinuous Transmission (DTX) is used or
preferred. Permissible values are 0 and 1. 0 means no DTX. 1
means DTX support, as described in Annex C of ITU-T Recommendation
G.729.1. 0 is implied if this parameter is omitted.
When DTX is turned off, the RTP payload MUST NOT contain a SID, and
the FT value 14 MUST NOT be used.
<span class="grey">Sollaud Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5459">RFC 5459</a> G.729.1 DTX Support in RTP January 2009</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Mapping to SDP Parameters</span>
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], which is commonly used to describe RTP sessions.
The mapping described in [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] remains unchanged.
The "dtx" parameter goes in the SDP "a=fmtp" attribute.
Some example partial SDP session descriptions utilizing G.729.1
encodings follow.
Example 1: default parameters (DTX off)
m=audio 57586 RTP/AVP 96
a=rtpmap:96 G7291/16000
Example 2: recommended packet duration of 40 ms (=2 frames), maximum
bit rate is 20 kbps, DTX supported and preferred.
m=audio 49987 RTP/AVP 97
a=rtpmap:97 G7291/16000
a=fmtp:97 maxbitrate=20000; dtx=1
a=ptime:40
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. DTX Offer-Answer Model Considerations</span>
The offer-answer model considerations of [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] fully apply. In
this section, we only define the management of the "dtx" parameter.
The "dtx" parameter concerns both sending and receiving, so both
sides of a bi-directional session MUST have the same DTX setting. If
one party indicates that it does not support DTX, DTX must be
deactivated both ways. In other words, DTX is actually activated if,
and only if, "dtx=1" in the offer and in the answer.
A special rule applies for multicast: the "dtx" parameter becomes
declarative and MUST NOT be negotiated. This parameter is fixed, and
a participant MUST use the configuration that is provided for the
session.
An RTP receiver compliant with only <a href="./rfc4749">RFC 4749</a> and not this
specification will ignore the "dtx" parameter and will not include it
in its answer, so DTX will not be activated in this case. As a
remark, if that happened, this kind of receiver would not be confused
by an RTP stream with DTX because <a href="./rfc4749">RFC 4749</a> requires that the bytes
that are now used for SID frames be ignored. But during the silence
<span class="grey">Sollaud Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5459">RFC 5459</a> G.729.1 DTX Support in RTP January 2009</span>
period, the receiver would then react using packet loss concealment
instead of comfort noise generation, leading to bad audio quality.
This justifies the use of the "dtx" parameter, even if the payload
format is backward-compatible at the binary level.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. DTX Declarative SDP Considerations</span>
The "dtx" parameter is declarative and provides the parameter that
SHALL be used when receiving and/or sending the configured stream.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Congestion Control</span>
The congestion control considerations of [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] apply.
The use of DTX can help congestion control by reducing the number of
transmitted RTP packets and the average bandwidth of audio streams.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The security considerations of [<a href="./rfc4749" title=""RTP Payload Format for the G.729.1 Audio Codec"">RFC4749</a>] apply.
By observing the RTP flow with DTX, an attacker could see when and
for how long people are speaking. This is a general fact for DTX,
and G.729.1 DTX introduces no new specific issue.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA has assigned a new optional parameter for media subtype (audio/
G7291); see <a href="#section-5.1">Section 5.1</a>.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-ITU-G.729.1">ITU-G.729.1</a>] International Telecommunications Union, "G.729 based
Embedded Variable bit-rate coder: An 8-32 kbit/s
scalable wideband coder bitstream interoperable with
G.729", ITU-T Recommendation G.729.1, May 2006.
[<a id="ref-ITU-G.729.1-C">ITU-G.729.1-C</a>] International Telecommunications Union, "G.729.1
DTX/CNG scheme", ITU-T Recommendation G.729.1 Annex
C, May 2008.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Sollaud Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5459">RFC 5459</a> G.729.1 DTX Support in RTP January 2009</span>
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-RFC4749">RFC4749</a>] Sollaud, A., "RTP Payload Format for the G.729.1
Audio Codec", <a href="./rfc4749">RFC 4749</a>, October 2006.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-ITU-G.729">ITU-G.729</a>] International Telecommunications Union, "Coding of
speech at 8 kbit/s using conjugate-structure
algebraic-code-excited linear-prediction (CS-
ACELP)", ITU-T Recommendation G.729, March 1996.
[<a id="ref-ITU-G.729-B">ITU-G.729-B</a>] International Telecommunications Union, "A silence
compression scheme for G.729 optimized for terminals
conforming to Recommendation V.70", ITU-T
Recommendation G.729 Annex B, October 1996.
[<a id="ref-RFC3551">RFC3551</a>] Schulzrinne, H. and S. Casner, "RTP Profile for
Audio and Video Conferences with Minimal Control",
STD 65, <a href="./rfc3551">RFC 3551</a>, July 2003.
Author's Address
Aurelien Sollaud
France Telecom
2 avenue Pierre Marzin
Lannion Cedex 22307
France
Phone: +33 2 96 05 15 06
EMail: aurelien.sollaud@orange-ftgroup.com
Sollaud Standards Track [Page 7]
</pre>
|
