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
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Network Working Group A. Sollaud
Request for Comments: 4749 France Telecom
Category: Standards Track October 2006
<span class="h1">RTP Payload Format for the G.729.1 Audio Codec</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) The Internet Society (2006).
Abstract
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) G.729.1 audio codec. A media type registration is included
for this payload format.
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>. Embedded Bit Rates Considerations ...............................<a href="#page-3">3</a>
<a href="#section-4">4</a>. RTP Header Usage ................................................<a href="#page-3">3</a>
<a href="#section-5">5</a>. Payload Format ..................................................<a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. Payload Structure ..........................................<a href="#page-4">4</a>
<a href="#section-5.2">5.2</a>. Payload Header: MBS Field ..................................<a href="#page-4">4</a>
<a href="#section-5.3">5.3</a>. Payload Header: FT Field ...................................<a href="#page-6">6</a>
<a href="#section-5.4">5.4</a>. Audio Data .................................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Payload Format Parameters .......................................<a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. Media Type Registration ....................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Mapping to SDP Parameters ..................................<a href="#page-8">8</a>
<a href="#section-6.2.1">6.2.1</a>. Offer-Answer Model Considerations ...................<a href="#page-9">9</a>
<a href="#section-6.2.2">6.2.2</a>. Declarative SDP Considerations .....................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Congestion Control .............................................<a href="#page-11">11</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-12">12</a>
<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="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
<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-1" title=""G.729 based Embedded Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729"">1</a>] is a scalable and wideband extension of the
recommendation G.729 [<a href="#ref-9" title=""Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear- prediction (CS-ACELP)"">9</a>] audio codec. This document specifies the
payload format for packetization of G.729.1 encoded audio signals
into the Real-time Transport Protocol (RTP).
The payload format itself is described in <a href="#section-5">Section 5</a>. A media type
registration and the details for the use of G.729.1 with SDP are
given in <a href="#section-6">Section 6</a>.
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">RFC 2119</a> [<a href="#ref-2" title=""Key words for use in RFCs to Indicate Requirement Levels"">2</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
G.729.1 is an 8-32 kbps scalable wideband (50-7000 Hz) speech and
audio coding algorithm interoperable with G.729, G.729 Annex A, and
G.729 Annex B. It provides a standardized solution for packetized
voice applications that allows a smooth transition from narrowband to
wideband telephony.
The most important services addressed are IP telephony and
videoconferencing, either for enterprise corporate networks or for
mass market (like Public Switched Telephone Network (PSTN) emulation
over DSL or wireless access). Target devices can be IP phones or
other VoIP handsets, home gateways, media gateways, IP Private Branch
Exchange (IPBX), trunking equipment, voice messaging servers, etc.
For all those applications, the scalability feature allows tuning the
bit rate versus quality trade-off, possibly in a dynamic way during a
session, taking into account service requirements and network
transport constraints.
The G.729.1 coder produces an embedded bitstream structured in 12
layers corresponding to 12 available bit rates between 8 and 32 kbps.
The first layer, at 8 kbps, is called the core layer and is bitstream
compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second
layer improves the narrowband quality. Upper layers provide wideband
audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps granularity
allowing graceful quality improvements. Only the core layer is
mandatory to decode understandable speech; upper layers provide
quality enhancement and wideband enlargement.
<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="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
The codec operates on 20-ms frames, and the default sampling rate is
16 kHz. Input and output at 8 kHz are also supported, at all bit
rates.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Embedded Bit Rates Considerations</span>
The embedded property of G.729.1 streams provides a mechanism to
adjust the bandwidth demand. At any time, a sender can change its
sending bit rate without external signalling, and the receiver will
be able to properly decode the frames. It may help to control
congestion, since the bandwidth can be adjusted by selecting another
bit rate.
The ability to adjust the bandwidth may also help when having a fixed
bandwidth link dedicated to voice calls, for example in a residential
or trunking gateway. In that case, the system can change the bit
rates depending on the number of simultaneous calls. This will only
impact the sending bandwidth. In order to adjust the receiving
bandwidth as well, we introduce an in-band signalling to request the
other party to change its own sending bit rate. This in-band request
is called MBS, for Maximum Bit rate Supported. It is described in
<a href="#section-5.2">Section 5.2</a>. Note that it is only useful for two-way unicast G.729.1
traffic, because when A sends an in-band MBS to B in order to request
that B modify its sending bit rate, it concerns the stream from B to
A. If there is no G.729.1 stream in the reverse direction, the MBS
will have no effect.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. RTP Header Usage</span>
The format of the RTP header is specified in <a href="./rfc3550">RFC 3550</a> [<a href="#ref-3" title=""RTP: A Transport Protocol for Real-Time Applications"">3</a>]. This
payload format uses the fields of the header in a manner consistent
with that specification.
The RTP timestamp clock frequency is the same as the default sampling
frequency: 16 kHz.
G.729.1 has also the capability to operate with 8 kHz sampled input/
output signals at all bit rates. It does not affect the bitstream,
and the decoder does not require a priori knowledge about the
sampling rate of the original signal at the input of the encoder.
Therefore, depending on the implementation and the audio acoustic
capabilities of the devices, the input of the encoder and/or the
output of the decoder can be configured at 8 kHz; however, a 16 kHz
RTP clock rate MUST always be used.
The duration of one frame is 20 ms, corresponding to 320 samples at
16 kHz. Thus the timestamp is increased by 320 for each consecutive
frame.
<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="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
The M bit MUST be set to zero in all packets.
The assignment of an RTP payload type for this packet format is
outside the scope of the document, and will not be specified here.
It is expected that the RTP profile under which this payload format
is being used will assign a payload type for this codec or specify
that the payload type is to be bound dynamically (see <a href="#section-6.2">Section 6.2</a>).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Payload Format</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Payload Structure</span>
The complete payload consists of a payload header of 1 octet,
followed by zero or more consecutive audio frames at the same bit
rate.
The payload header consists of two fields: MBS (see <a href="#section-5.2">Section 5.2</a>) and
FT (see <a href="#section-5.3">Section 5.3</a>).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBS | FT | |
+-+-+-+-+-+-+-+-+ +
: zero or more frames at the same bit rate :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Payload Header: MBS Field</span>
MBS (4 bits): maximum bit rate supported. Indicates a maximum bit
rate to the encoder at the site of the receiver of this payload. The
value of the MBS field is set according to the following table:
<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="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
+-------+--------------+
| MBS | max bit rate |
+-------+--------------+
| 0 | 8 kbps |
| 1 | 12 kbps |
| 2 | 14 kbps |
| 3 | 16 kbps |
| 4 | 18 kbps |
| 5 | 20 kbps |
| 6 | 22 kbps |
| 7 | 24 kbps |
| 8 | 26 kbps |
| 9 | 28 kbps |
| 10 | 30 kbps |
| 11 | 32 kbps |
| 12-14 | (reserved) |
| 15 | NO_MBS |
+-------+--------------+
The MBS is used to tell the other party the maximum bit rate one can
receive. The encoder MUST NOT exceed the sending rate indicated by
the received MBS. Note that, due to the embedded property of the
coding scheme, the encoder can send frames at the MBS rate or any
lower rate. As long as it does not exceed the MBS, the encoder can
change its bit rate at any time without previous notice.
Note that the MBS is a codec bit rate; the actual network bit rate is
higher and depends on the overhead of the underlying protocols.
The MBS received is valid until the next MBS is received, i.e., a
newly received MBS value overrides the previous one.
If a payload with a reserved MBS value is received, the MBS MUST be
ignored.
The MBS field MUST be set to 15 for packets sent to a multicast group
and MUST be ignored on packets received from a multicast group.
The MBS field MUST be set to 15 in all packets when the actual MBS
value is sent through non-RTP means. This is out of the scope of
this specification.
See Sections <a href="#section-3">3</a> and <a href="#section-7">7</a> for more details on the use of MBS for
congestion control.
<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="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Payload Header: FT Field</span>
FT (4 bits): Frame type of the frame(s) in this packet, as per the
following table:
+-------+---------------+------------+
| 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-14 | (reserved) | |
| 15 | NO_DATA | 0 |
+-------+---------------+------------+
The FT value 15 (NO_DATA) indicates that there is no audio data in
the payload. This MAY be used to update the MBS value when there is
no audio frame to transmit. The payload will then be reduced to the
payload header.
If a payload with a reserved FT value is received, the whole payload
MUST be ignored.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Audio Data</span>
Audio data of a payload contains one or more consecutive audio frames
at the same bit rate. The audio frames are packed in order of time,
that is, oldest first.
The size of one frame is given by the FT field, as per the table in
<a href="#section-5.3">Section 5.3</a>, and the actual number of frames is easy to infer from
the size of the audio data part:
nb_frames = (size_of_audio_data) / (size_of_one_frame).
Only full frames must be considered. So if there is a remainder to
the division above, the corresponding remaining bytes in the received
payload MUST be ignored.
<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="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
Note that if FT=15, there will be no audio frame in the payload.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Payload Format Parameters</span>
This section defines the parameters that may be used to configure
optional features in the G.729.1 RTP transmission.
The parameters are defined here as part of the media subtype
registration for the G.729.1 codec. A mapping of the parameters into
the Session Description Protocol (SDP) [<a href="#ref-5" title=""SDP: Session Description Protocol"">5</a>] is also provided for those
applications that use SDP. In control protocols that do not use MIME
or SDP, the media type parameters must be mapped to the appropriate
format used with that control protocol.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Media Type Registration</span>
This registration is done using the template defined in <a href="./rfc4288">RFC 4288</a> [<a href="#ref-6" title=""Media Type Specifications and Registration Procedures"">6</a>]
and following <a href="./rfc3555">RFC 3555</a> [<a href="#ref-7" title=""MIME Type Registration of RTP Payload Formats"">7</a>].
Type name: audio
Subtype name: G7291
Required parameters: none
Optional parameters:
maxbitrate: the absolute maximum codec bit rate for the session, in
bits per second. Permissible values are 8000, 12000, 14000,
16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000.
32000 is implied if this parameter is omitted. The maxbitrate
restricts the range of bit rates which can be used. The bit rates
indicated by FT and MBS fields in the RTP packets MUST NOT exceed
maxbitrate.
mbs: the current maximum codec bit rate supported as a receiver, in
bits per second. Permissible values are in the same set as for
the maxbitrate parameter, with the constraint that mbs MUST be
lower or equal to maxbitrate. If the mbs parameter is omitted, it
is set to the maxbitrate value. So if both mbs and maxbitrate are
omitted, they are both set to 32000. The mbs parameter
corresponds to a MBS value in the RTP packets as per table in
<a href="./rfc4749#section-5.2">Section 5.2 of RFC 4749</a>. Note that this parameter may be
dynamically updated by the MBS field of the RTP packets sent; it
is not an absolute value for the session.
ptime: the recommended length of time (in milliseconds) represented
by the media in a packet. See <a href="./rfc4566#section-6">Section 6 of RFC 4566</a> [<a href="#ref-5" title=""SDP: Session Description Protocol"">5</a>].
<span class="grey">Sollaud Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
maxptime: the maximum length of time (in milliseconds) that can be
encapsulated in a packet. See <a href="./rfc4566#section-6">Section 6 of RFC 4566</a> [<a href="#ref-5" title=""SDP: Session Description Protocol"">5</a>]
Encoding considerations: This media type is framed and contains
binary data; see <a href="./rfc4288#section-4.8">Section 4.8 of RFC 4288</a> [<a href="#ref-6" title=""Media Type Specifications and Registration Procedures"">6</a>].
Security considerations: See <a href="./rfc4749#section-8">Section 8 of RFC 4749</a>
Interoperability considerations: none
Published specification: <a href="./rfc4749">RFC 4749</a>
Applications which use this media type: Audio and video conferencing
tools.
Additional information: none
Person & email address to contact for further information:
Aurelien Sollaud, aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [<a href="#ref-3" title=""RTP: A Transport Protocol for Real-Time Applications"">3</a>].
Author: Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.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="#ref-5" title=""SDP: Session Description Protocol"">5</a>], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the G.729.1 codec, the mapping is
as follows:
o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("G7291") goes in SDP "a=rtpmap" as the encoding
name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729.1.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
<span class="grey">Sollaud Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type string as a semicolon
separated list of parameter=value pairs.
Some example SDP session descriptions utilizing G.729.1 encodings
follow.
Example 1: default parameters
m=audio 53146 RTP/AVP 98
a=rtpmap:98 G7291/16000
Example 2: recommended packet duration of 40 ms (=2 frames), maximum
bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a
loaded PSTN gateway which can operate at 12 kbps but asks to
initially reduce the bit rate to 8 kbps.
m=audio 51258 RTP/AVP 99
a=rtpmap:99 G7291/16000
a=fmtp:99 maxbitrate=12000; mbs=8000
a=ptime:40
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Offer-Answer Model Considerations</span>
The following considerations apply when using SDP offer-answer
procedures [<a href="#ref-8" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">8</a>] to negotiate the use of G.729.1 payload in RTP:
o Since G.729.1 is an extension of G.729, the offerer SHOULD
announce G.729 support in its "m=audio" line, with G.729.1
preferred. This will allow interoperability with both G.729.1 and
G.729-only capable parties.
Below is an example of such an offer:
m=audio 55954 RTP/AVP 98 18
a=rtpmap:98 G7291/16000
a=rtpmap:18 G729/8000
If the answerer supports G.729.1, it will keep the payload type 98
in its answer, and the conversation will be done using G.729.1.
Else, if the answerer supports only G.729, it will leave only the
payload type 18 in its answer, and the conversation will be done
using G.729 (the payload format for G.729 is defined in <a href="./rfc3551#section-4.5.6">Section</a>
<a href="./rfc3551#section-4.5.6">4.5.6 of RFC 3551</a> [<a href="#ref-4" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">4</a>]).
<span class="grey">Sollaud Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
Note that when used at 8 kbps in G.729-compatible mode, the
G.729.1 decoder supports G.729 Annex B. Therefore, Annex B can be
advertised (by default, annexb=yes for G729 media type; see
<a href="./rfc3555#section-4.1.9">Section 4.1.9 of RFC 3555</a> [<a href="#ref-7" title=""MIME Type Registration of RTP Payload Formats"">7</a>]).
o The "maxbitrate" parameter is bi-directional. If the offerer sets
a maxbitrate value, the answerer MUST reply with a smaller or
equal value. The actual maximum bit rate for the session will be
the minimum.
o If the received value for "maxbitrate" is between 8000 and 32000
but not in the permissible values set, it SHOULD be read as the
closest lower valid value. If the received value is lower than
8000 or greater than 32000, the session MUST be rejected.
o The "mbs" parameter is not symmetric. Values in the offer and the
answer are independent and take into account local constraints.
One party MUST NOT start sending frames at a bit rate higher than
the "mbs" of the other party. The parameter allows announcing
this value, prior to the sending of any packet, to prevent the
remote sender from exceeding the MBS at the beginning of the
session.
o If the received value for "mbs" is greater or equal to 8000 but
not in the permissible values set, it SHOULD be read as the
closest lower valid value. If the received value is lower than
8000, the session MUST be rejected.
o The parameters "ptime" and "maxptime" will in most cases not
affect interoperability. The SDP offer-answer handling of the
"ptime" parameter is described in <a href="./rfc3264">RFC 3264</a> [<a href="#ref-8" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">8</a>]. The "maxptime"
parameter MUST be handled in the same way.
o Any unknown parameter in an offer MUST be ignored by the receiver
and MUST NOT be included in the answer.
Some special rules apply for mono-directional traffic:
o For sendonly streams, the "mbs" parameter is useless and SHOULD
NOT be used.
o For recvonly streams, the "mbs" parameter is the only way to
communicate the MBS to the sender, since there is no RTP stream
towards it. So to request a bit rate change, the receiver will
need to use an out-of-band mechanism, like a SIP RE-INVITE.
<span class="grey">Sollaud Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
Some special rules apply for multicast:
o The "mbs" parameter MUST NOT be used.
o The "maxbitrate" 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.
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Declarative SDP Considerations</span>
For declarative use of SDP such as in SAP [<a href="#ref-10" title=""Session Announcement Protocol"">10</a>] and RTSP [<a href="#ref-11" title=""Real Time Streaming Protocol (RTSP)"">11</a>], the
following considerations apply:
o The "mbs" parameter MUST NOT be used.
o The "maxbitrate" 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-7" href="#section-7">7</a>. Congestion Control</span>
Congestion control for RTP SHALL be used in accordance with <a href="./rfc3550">RFC 3550</a>
[<a href="#ref-3" title=""RTP: A Transport Protocol for Real-Time Applications"">3</a>] and any appropriate profile (for example, <a href="./rfc3551">RFC 3551</a> [<a href="#ref-4" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">4</a>]). The
embedded and variable bit rates capability of G.729.1 provides a
mechanism that may help to control congestion; see <a href="#section-3">Section 3</a> for more
details.
The number of frames encapsulated in each RTP payload influences the
overall bandwidth of the RTP stream, due to the header overhead.
Packing more frames in each RTP payload can reduce the number of
packets sent and hence the header overhead, at the expense of
increased delay and reduced error robustness.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in the
RTP specification [<a href="#ref-3" title=""RTP: A Transport Protocol for Real-Time Applications"">3</a>] and any appropriate profile (for example, <a href="./rfc3551">RFC</a>
<a href="./rfc3551">3551</a> [<a href="#ref-4" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">4</a>]).
As this format transports encoded speech/audio, the main security
issues include confidentiality, integrity protection, and
authentication of the speech/audio itself. The payload format itself
does not have any built-in security mechanisms. Any suitable
external mechanisms, such as SRTP [<a href="#ref-12" title=""The Secure Real-time Transport Protocol (SRTP)"">12</a>], MAY be used.
<span class="grey">Sollaud Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
This payload format and the G.729.1 encoding do not exhibit any
significant non-uniformity in the receiver-end computational load and
thus are unlikely to pose a denial-of-service threat due to the
receipt of pathological datagrams.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA has registered audio/G7291 as a media subtype; see <a href="#section-6.1">Section 6.1</a>.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-1">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-2">2</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.
[<a id="ref-3">3</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-4">4</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.
[<a id="ref-5">5</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-6">6</a>] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>, <a href="./rfc4288">RFC 4288</a>, December 2005.
[<a id="ref-7">7</a>] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", <a href="./rfc3555">RFC 3555</a>, July 2003.
[<a id="ref-8">8</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", <a href="./rfc3264">RFC 3264</a>, June 2002.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-9">9</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-10">10</a>] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", <a href="./rfc2974">RFC 2974</a>, October 2000.
<span class="grey">Sollaud Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
[<a id="ref-11">11</a>] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", <a href="./rfc2326">RFC 2326</a>, April 1998.
[<a id="ref-12">12</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
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
<span class="grey">Sollaud Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4749">RFC 4749</a> RTP Payload Format for G.729.1 October 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sollaud Standards Track [Page 14]
</pre>
|
