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: 5391 France Telecom
Category: Standards Track November 2008
<span class="h1">RTP Payload Format for ITU-T Recommendation G.711.1</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) 2008 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 specifies a Real-time Transport Protocol (RTP) payload
format to be used for the ITU Telecommunication Standardization
Sector (ITU-T) G.711.1 audio codec. Two media type registrations are
also included.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</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-4">4</a>
<a href="#section-4.1">4.1</a>. Payload Header .............................................<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Audio Data .................................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Payload Format Parameters .......................................<a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. PCMA-WB Media Type Registration ............................<a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. PCMU-WB Media Type Registration ............................<a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. Mapping to SDP Parameters ..................................<a href="#page-9">9</a>
<a href="#section-5.3.1">5.3.1</a>. Offer-Answer Model Considerations ...................<a href="#page-9">9</a>
<a href="#section-5.3.2">5.3.2</a>. Declarative SDP Considerations .....................<a href="#page-11">11</a>
<a href="#section-6">6</a>. G.711 Interoperability .........................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Congestion Control .............................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-12">12</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-13">13</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-13">13</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The ITU Telecommunication Standardization Sector (ITU-T)
Recommendation G.711.1 [<a href="#ref-ITU-G.711.1" title=""Wideband embedded extension for G.711 pulse code modulation"">ITU-G.711.1</a>] is an embedded wideband
extension of the Recommendation G.711 [<a href="#ref-ITU-G.711" title=""Pulse code modulation (PCM) of voice frequencies"">ITU-G.711</a>] audio codec. This
document specifies a payload format for packetization of G.711.1
encoded audio signals into the Real-time Transport Protocol (RTP).
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.711.1 is a G.711 embedded wideband speech and audio coding
algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is
fully interoperable with G.711. Hence, an efficient deployment in
existing G.711-based Voice over IP (VoIP) infrastructures is
foreseen.
The codec operates on 5-ms frames, and the default sampling rate is
16 kHz. Input and output at 8 kHz are also supported for narrowband
modes.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
The encoder produces an embedded bitstream structured in three layers
corresponding to three available bit rates: 64, 80, and 96 kbps. The
bitstream can be truncated at the decoder side or by any component of
the communication system to adjust, "on the fly", the bit rate to the
desired value.
The following table gives more details on these layers.
+-------+------------------------+----------+
| Layer | Description | Bit rate |
+-------+------------------------+----------+
| L0 | G.711 compatible | 64 kbps |
| L1 | narrowband enhancement | 16 kbps |
| L2 | wideband enhancement | 16 kbps |
+-------+------------------------+----------+
Table 1: Layers description
The combinations of these three layers results in the definition of
four modes, as per the following table.
+------+----+----+----+------------+----------+
| Mode | L0 | L1 | L2 | Audio band | Bit rate |
+------+----+----+----+------------+----------+
| R1 | x | | | narrowband | 64 kbps |
| R2a | x | x | | narrowband | 80 kbps |
| R2b | x | | x | wideband | 80 kbps |
| R3 | x | x | x | wideband | 96 kbps |
+------+----+----+----+------------+----------+
Table 2: Modes description
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. RTP Header Usage</span>
The format of the RTP header is specified in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. The payload
format defined in this document uses the fields of the header in a
manner consistent with that specification.
marker (M):
G.711.1 does not define anything specific regarding Discontinuous
Transmission (DTX), a.k.a. silence suppression. Codec-independent
mechanisms may be used, like the generic comfort-noise payload
format defined in [<a href="./rfc3389" title=""Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)"">RFC3389</a>].
For applications that send either no packets or occasional
comfort-noise packets during silence, the first packet of a
talkspurt -- that is, the first packet after a silence period
during which packets have not been transmitted contiguously --
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
SHOULD be distinguished by setting the marker bit in the RTP data
header to one. The marker bit in all other packets is zero. The
beginning of a talkspurt MAY be used to adjust the playout delay
to reflect changing network delays. Applications without silence
suppression MUST set the marker bit to zero.
payload type (PT):
The assignment of an RTP payload type for this packet format is
outside the scope of this 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-5.3">Section 5.3</a>).
timestamp:
The RTP timestamp clock frequency is the same as the default
sampling frequency: 16 kHz.
G.711.1 has also the capability to operate with 8-kHz sampled
input/output signals. 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 5 ms, corresponding to 80 samples at
16 kHz. Thus, the timestamp is increased by 80 for each
consecutive frame.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Payload Format</span>
The complete payload consists of a payload header of 1 octet,
followed by one or more consecutive G.711.1 audio frames of the same
mode.
The mode may change between packets, but not within a packet.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Payload Header</span>
The payload header is illustrated below.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| MI |
+-+-+-+-+-+-+-+-+
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
The five most significant bits are reserved for further extension and
MUST be set to zero and MUST be ignored by receivers.
The Mode Index (MI) field (3 bits) gives the mode of the following
frame(s) as per the table:
+------------+--------------+------------+
| Mode Index | G.711.1 mode | Frame size |
+------------+--------------+------------+
| 1 | R1 | 40 octets |
| 2 | R2a | 50 octets |
| 3 | R2b | 50 octets |
| 4 | R3 | 60 octets |
+------------+--------------+------------+
Table 3: Modes in payload header
All other values of MI are reserved for future use and MUST NOT be
used.
Payloads received with an undefined MI value MUST be discarded.
If a restricted mode-set has been set up by the signaling (see
<a href="#section-5">Section 5</a>), payloads received with an MI value not in this set MUST
be discarded.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Audio Data</span>
After this payload header, the consecutive audio frames are packed in
order of time, that is, oldest first. All frames MUST be of the same
mode, indicated by the MI field of the payload header.
Within a frame, layers are always packed in the same order: L0 then
L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode
R3. This is illustrated below.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
+-------------------------------+
R1 | L0 |
+-------------------------------+
+-------------------------------+--------+
R2a | L0 | L1 |
+-------------------------------+--------+
+-------------------------------+--------+
R2b | L0 | L2 |
+-------------------------------+--------+
+-------------------------------+--------+--------+
R3 | L0 | L1 | L2 |
+-------------------------------+--------+--------+
The size of one frame is given by the mode, as per Table 3, 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="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Payload Format Parameters</span>
This section defines the parameters that may be used to configure
optional features in the G.711.1 RTP transmission.
Both A-law and mu-law G.711 are supported in the core layer L0, but
there is no interoperability between A-law and mu-law. So two media
types with the same parameters will be defined: audio/PCMA-WB for
A-law core, and audio/PCMU-WB for mu-law core. This is consistent
with the audio/PCMA and audio/PCMU media types separation for G.711
audio.
The parameters are defined here as part of the media subtype
registrations for the G.711.1 codec. A mapping of the parameters
into the Session Description Protocol (SDP) [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</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="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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. PCMA-WB Media Type Registration</span>
This registration is done using the template defined in [<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>] and
following [<a href="./rfc4855" title=""Media Type Registration of RTP Payload Formats"">RFC4855</a>].
Type name: audio
Subtype name: PCMA-WB
Required parameters: none
Optional parameters:
mode-set: restricts the active codec mode set to a subset of all
modes. Possible values are a comma-separated list of modes
from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of <a href="./rfc5391">RFC</a>
<a href="./rfc5391">5391</a>). The modes are listed in order of preference; first is
preferred. If mode-set is specified, frames encoded with modes
outside of the subset MUST NOT be sent in any RTP payload. If
not present, all codec modes are allowed.
ptime: the recommended length of time (in milliseconds)
represented by the media in a packet. It should be an integer
multiple of 5 ms (the frame size). See <a href="./rfc4566#section-6">Section 6 of RFC 4566</a>.
maxptime: the maximum length of time (in milliseconds) that can
be encapsulated in a packet. It should be an integer multiple
of 5 ms (the frame size). See <a href="./rfc4566#section-6">Section 6 of RFC 4566</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>.
Security considerations: See <a href="./rfc5391#section-8">Section 8 of RFC 5391</a>.
Interoperability considerations: none
Published specification: <a href="./rfc5391">RFC 5391</a>
Applications that 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
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP.
Author: Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. PCMU-WB Media Type Registration</span>
This registration is done using the template defined in [<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>] and
following [<a href="./rfc4855" title=""Media Type Registration of RTP Payload Formats"">RFC4855</a>].
Type name: audio
Subtype name: PCMU-WB
Required parameters: none
Optional parameters:
mode-set: restricts the active codec mode-set to a subset of all
modes. Possible values are a comma-separated list of modes
from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of <a href="./rfc5391">RFC</a>
<a href="./rfc5391">5391</a>). The modes are listed in order of preference; first is
preferred. If mode-set is specified, frames encoded with modes
outside of the subset MUST NOT be sent in any RTP payload. If
not present, all codec modes are allowed.
ptime: the recommended length of time (in milliseconds)
represented by the media in a packet. It should be an integer
multiple of 5 ms (the frame size). See <a href="./rfc4566#section-6">Section 6 of RFC 4566</a>.
maxptime: the maximum length of time (in milliseconds) that can
be encapsulated in a packet. It should be an integer multiple
of 5 ms (the frame size). See <a href="./rfc4566#section-6">Section 6 of RFC 4566</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>.
Security considerations: See <a href="./rfc5391#section-8">Section 8 of RFC 5391</a>.
Interoperability considerations: none
Published specification: <a href="./rfc5391">RFC 5391</a>
Applications that use this media type: Audio and video conferencing
tools.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
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.
Author: Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</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. When SDP
is used to specify sessions employing the G.711.1 codec, the mapping
is as follows:
o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
16000 for G.711.1.
o The parameter "mode-set" goes in the SDP "a=fmtp" attribute by
copying it as a "mode-set=<value>" string.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Offer-Answer Model Considerations</span>
The following considerations apply when using SDP offer-answer
procedures [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>] to negotiate the use of G.711.1 payload in RTP:
o Since G.711.1 is an extension of G.711, the offerer SHOULD
announce G.711 support in its "m=audio" line, with G.711.1
preferred. This will allow interoperability with both G.711.1 and
G.711-only capable parties. This is done by offering the PCMA
media subtype in addition to PCMA-WB, and/or PCMU in addition to
PCMU-WB.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
Below is an example part of such an offer, for A-law:
m=audio 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
As a reminder, the payload format for G.711 is defined in <a href="./rfc3551#section-4.5.14">Section</a>
<a href="./rfc3551#section-4.5.14">4.5.14 of [RFC3551]</a>.
o The "mode-set" parameter is bi-directional; i.e., the restricted
mode-set applies to media both to be received and sent by the
declaring entity. If a mode-set was supplied in the offer, the
answerer MUST return either the same mode-set or a subset of this
mode-set. The answerer MAY change the preference order. If no
mode-set was supplied in the offer, the anwerer MAY return a mode-
set to restrict the possible modes. In any case, the mode-set in
the answer then applies for both offerer and answerer. The
offerer MUST NOT send frames of a mode that has been removed by
the answerer.
For multicast sessions, if "mode-set" is supplied in the offer,
the answerer SHALL only participate in the session if it supports
the offered mode-set.
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" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</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.
Below are some example parts of SDP offer-answer exchanges.
o Example 1
Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law
m=audio 54874 RTP/AVP 96 97 0 8
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
Answer: all modes accepted, both mu- and A-law.
m=audio 59452 RTP/AVP 96 97
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
o Example 2
Offer: G.711.1 all modes, with G.711 fallback, prefers A-law
m=audio 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000
Answer: wants only A-law mode R3
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4
o Example 3
Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
Answer: accepted
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
If the answerer had wanted to restrict to one mode, it would have
answered with only one value in the mode-set, for example mode-
set=3 for mode R2b.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Declarative SDP Considerations</span>
For declarative use of SDP, nothing specific is defined for this
payload format. The configuration given by the SDP MUST be used when
sending and/or receiving media in the session.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. G.711 Interoperability</span>
The L0 layer of G.711.1 is fully interoperable with G.711, and is
embedded in all modes of G.711.1. This provides an easy G.711.1 -
G.711 transcoding process.
A gateway or any other network device receiving a G.711.1 packet can
easily extract a G.711-compatible payload, without the need to decode
and re-encode the audio signal. It simply has to take the audio data
of the payload, and strip the upper layers (L1 and/or L2), if any.
If a G.711.1 packet contains several frames, the concatenation of the
L0 layers of each frame will form a G.711-compatible payload.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
<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" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]
and any appropriate profile (for example, [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>]).
The embedded nature of G.711.1 audio data can be helpful for
congestion control, since a coding mode with a lower bit rate can be
selected when needed. This property is usable only when multiple
modes have been negotiated (either no "mode-set" parameter in the SDP
or a "mode-set" with at least two modes).
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="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and any appropriate profile (for example,
[<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</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 the Secure Real-time Transport Protocol
(SRTP) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>], MAY be used.
This payload format and the G.711.1 encoding do not exhibit any
significant non-uniformity in the receiver-end computational load,
and thus they are unlikely to pose a denial-of-service threat due to
the receipt of pathological datagrams. In addition, they do not
contain any type of active content such as scripts.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
Two new media subtypes (audio/PCMA-WB and audio/PCMU-WB) have been
registered by IANA. See Sections <a href="#section-5.1">5.1</a> and <a href="#section-5.2">5.2</a>.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
<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-ITU-G.711.1">ITU-G.711.1</a>] International Telecommunications Union, "Wideband
embedded extension for G.711 pulse code modulation",
ITU-T Recommendation G.711.1, March 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.
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)", <a href="./rfc3264">RFC</a>
<a href="./rfc3264">3264</a>, June 2002.
[<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-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.
[<a id="ref-RFC4288">RFC4288</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-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-RFC4855">RFC4855</a>] Casner, S., "Media Type Registration of RTP Payload
Formats", <a href="./rfc4855">RFC 4855</a>, February 2007.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-ITU-G.711">ITU-G.711</a>] International Telecommunications Union, "Pulse code
modulation (PCM) of voice frequencies", ITU-T
Recommendation G.711, November 1988.
[<a id="ref-RFC3389">RFC3389</a>] Zopf, R., "Real-time Transport Protocol (RTP) Payload
for Comfort Noise (CN)", <a href="./rfc3389">RFC 3389</a>, September 2002.
[<a id="ref-RFC3711">RFC3711</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.
<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="./rfc5391">RFC 5391</a> RTP Payload Format for G.711.1 November 2008</span>
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 14]
</pre>
|
