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
|
<pre>Network Working Group P. Luthi
Request for Comments: 5577 Tandberg
Obsoletes: <a href="./rfc3047">3047</a> R. Even
Category: Standards Track Gesher Erove Ltd
July 2009
<span class="h1">RTP Payload Format for ITU-T Recommendation G.722.1</span>
Abstract
International Telecommunication Union (ITU-T) Recommendation G.722.1
is a wide-band audio codec. This document describes the payload
format for including G.722.1-generated bit streams within an RTP
packet. The document also describes the syntax and semantics of the
Session Description Protocol (SDP) parameters needed to support
G.722.1 audio codec.
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 in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Luthi & Even Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. RTP Usage for G.722.1 ...........................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. RTP G.722.1 Header Fields ..................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. RTP Payload Format for G.722.1 .............................<a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. Multiple G.722.1 Frames in an RTP Packet ...................<a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Computing the Number of G.722.1 Frames .....................<a href="#page-6">6</a>
<a href="#section-4">4</a>. IANA Considerations .............................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Media Type Registration ....................................<a href="#page-6">6</a>
<a href="#section-4.1.1">4.1.1</a>. Registration of Media Type audio/G7221 ..............<a href="#page-6">6</a>
<a href="#section-5">5</a>. SDP Parameters ..................................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. Usage with the SDP Offer/Answer Model ......................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Changes from <a href="./rfc3047">RFC 3047</a> ...........................................<a href="#page-9">9</a>
<a href="#section-8">8</a>. Acknowledgments .................................................<a href="#page-9">9</a>
<a href="#section-9">9</a>. References ......................................................<a href="#page-9">9</a>
<a href="#section-9.1">9.1</a>. Normative References .......................................<a href="#page-9">9</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
ITU-T G.722.1 [<a href="#ref-ITU.G7221" title=""Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss"">ITU.G7221</a>] is a low-complexity coder; it compresses 50
Hz - 14 kHz audio signals into one of the following bit rates: 24
kbit/s, 32 kbit/s, or 48 kbit/s.
The coder may be used for speech, music, and other types of audio.
Some of the applications for which this coder is suitable are:
o Real-time communications such as videoconferencing and telephony
o Streaming audio
o Archival and messaging
ITU-T G.722.1 [<a href="#ref-ITU.G7221" title=""Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss"">ITU.G7221</a>] uses 20-ms frames and a sampling rate clock
of 16 kHz or 32kHz. The encoding and decoding algorithm can change
the bit rate at any 20-ms frame boundary, but no bit rate change
notification is provided in-band with the bit stream.
For any given bit rate, the number of bits in a frame is a constant.
Within this fixed frame, G.722.1 uses variable-length coding (e.g.,
Huffman coding) to represent most of the encoded parameters. All
variable-length codes are transmitted in order from the leftmost bit
(most significant bit -- MSB) to the rightmost bit (least significant
bit -- LSB), see [<a href="#ref-ITU.G7221" title=""Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss"">ITU.G7221</a>] for more details.
<span class="grey">Luthi & Even Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or
32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s, or 48
kbit/s at 32 Khz sample rate. However, the coding algorithm itself
has the capability to run at any user-specified bit rate (not just
24, 32, and 48 kbit/s) while maintaining an audio bandwidth of 50 Hz
to 14 kHz. This rate change is accomplished by a linear scaling of
the codec operation, resulting in frames with size in bits equal to
1/50 of the corresponding bit rate.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] and
indicate requirement levels for compliant RTP implementations.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. RTP Usage for G.722.1</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. RTP G.722.1 Header Fields</span>
The RTP header is defined in the RTP specification [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. This
section defines how fields in the RTP header are used.
Payload Type (PT): The assignment of an RTP payload type for this
packet format is outside the scope of this document; it is
specified by the RTP profile under which this payload format is
used, or it is signaled dynamically out-of-band (e.g., using SDP).
Marker (M) bit: The M bit is set to zero.
Extension (X) bit: Defined by the RTP profile used.
Timestamp: A 32-bit word that corresponds to the sampling instant
for the first frame in the RTP packet. The sampling frequency can
be 16 Khz or 32 Khz. The RTP timestamp clock frequency of 32 Khz
SHOULD be used unless only an RTP stream sampled at 16 Khz is
going to be sent.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. RTP Payload Format for G.722.1</span>
The RTP payload for G.722.1 has the format shown in Figure 1. No
additional header fields specific to this payload format are
required.
<span class="grey">Luthi & Even Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of G.722.1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP payload for G.722.1.
Because bit rate is not signaled in-band, a separate out-of-band
method is REQUIRED to indicate the bit rate (see <a href="#section-5">Section 5</a> for an
example of signaling bit rate information using SDP). For the
payload format specified here, the bit rate MUST remain constant for
a particular payload type value. An application MAY switch bit rates
and clock rates from packet to packet by defining different payload
type values and switching between them.
The use of Huffman coding means that it is not possible to identify
the various encoded parameters/fields contained within the bit stream
without first completely decoding the entire frame. For the purposes
of packetizing the bit stream in RTP, it is only necessary to
consider the sequence of bits as output by the G.722.1 encoder and to
present the same sequence to the decoder. The payload format
described here maintains this sequence.
When operating at 24 kbit/s, 480 bits (60 octets) are produced per
frame. When operating at 32 kbit/s, 640 bits (80 octets) are
produced per frame. When operating at 48 kbit/s, 960 bits (120
octets) are produced per frame. Thus, all three bit rates allow for
octet alignment without the need for padding bits.
Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into
an octet-aligned RTP payload.
<span class="grey">Luthi & Even Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
first bit last bit
transmitted transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480, 640, or 960) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP RTP
octet 1 octet 2 octet
60, 80, 120
Figure 2: The G.722.1 encoder bit stream is split into
a sequence of octets (60, 80, or 120 depending on
the bit rate), and each octet is in turn
mapped into an RTP octet.
When operating at non-standard rates, the payload format MUST follow
the guidelines illustrated in Figure 2. It is RECOMMENDED that
values in the range 16000 to 48000 be used. Non-standard rates MUST
have a value that is a multiple of 400 (this maintains octet
alignment and does not then require (undefined) padding bits for each
frame if not octet aligned). For example, a bit rate of 16.4 kbit/s
will result in a frame of size 328 bits or 41 octets, which is mapped
into RTP per Figure 2.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Multiple G.722.1 Frames in an RTP Packet</span>
A sender may include more than one consecutive G.722.1 frame in a
single RTP packet.
Senders have the following additional restrictions:
o Sender SHOULD NOT include more G.722.1 frames in a single RTP
packet than will fit in the MTU of the RTP transport protocol.
o All frames contained in a single RTP packet MUST be of the same
length and sampled at the same clock rate. They MUST have the
same bit rate (octets per frame).
<span class="grey">Luthi & Even Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
o Frames MUST NOT be split between RTP packets.
It is RECOMMENDED that the number of frames contained within an RTP
packet be consistent with the application. For example, in a
telephony application where delay is important, the fewer frames per
packet, the lower the delay; whereas for a delay-insensitive
streaming or messaging application, many frames per packet would be
acceptable.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Computing the Number of G.722.1 Frames</span>
Information describing the number of frames contained in an RTP
packet is not transmitted as part of the RTP payload. The only way
to determine the number of G.722.1 frames is to count the total
number of octets within the RTP packet and divide the octet count by
the number of expected octets per frame. This expected octet-per-
frame count is derived from the bit rate and is therefore a function
of the payload type.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
This document updates the G7221 media type described in <a href="./rfc3047">RFC 3047</a>.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Media Type Registration</span>
This section describes the media types and names associated with this
payload format. The section registers the media types, as per <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a> [<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>]
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Registration of Media Type audio/G7221</span>
Media type name: audio
Media subtype name: G7221
Required parameters:
bitrate: the data rate for the audio bit stream. This parameter
is mandatory because the bit rate is not signaled within the
G.722.1 bit stream. At the standard G.722.1 bit rates, the value
MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000,
32000, or 48000 at 32 Khz sample rate. If using the non-standard
bit rates, then it is RECOMMENDED that values in the range 16000
to 48000 be used. Non-standard rates MUST have a value that is a
multiple of 400 (this maintains octet alignment and does not then
require (undefined) padding bits for each frame if not octet
aligned).
<span class="grey">Luthi & Even Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
Optional parameters:
rate: RTP timestamp clock rate, which is equal to the sampling
rate. If the parameter is not specified, a clock rate of 16 Khz
is assumed.
ptime: see <a href="./rfc4566">RFC 4566</a>. SHOULD be a multiple of 20 ms.
maxptime: see <a href="./rfc4566">RFC 4566</a>. SHOULD be a multiple of 20 ms.
Encoding considerations:
This media type is framed and binary, see <a href="./rfc4288#section-4.8">Section 4.8 in
[RFC4288]</a>.
Security considerations: See <a href="#section-6">Section 6</a>
Interoperability considerations:
Terminals SHOULD offer a media type at 16 Khz sample rate in order
to interoperate with terminals that do not support the new 32 Khz
sample rate.
Published specification: <a href="./rfc5577">RFC 5577</a>.
Applications that use this media type:
Audio and Video streaming and conferencing applications.
Additional information: none
Person and email address to contact for further information :
Roni Even: ron.even.tlv@gmail.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="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. Transport within other framing
protocols is not defined at this time.
Author: Roni Even
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
<span class="grey">Luthi & Even Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SDP Parameters</span>
The media types audio/G7221 are mapped to fields in the Session
Description Protocol (SDP) [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] as follows:
o The media name in the "m=" line of SDP MUST be audio.
o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the
media subtype).
o The parameter "rate" goes in "a=rtpmap" as clock rate parameter.
o Only one bitrate SHALL be defined (using the "bitrate=" parameter
in the a=fmtp line) for each payload type.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Usage with the SDP Offer/Answer Model</span>
When offering G.722.1 over RTP using SDP in an Offer/Answer model
[<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>], the following considerations are necessary.
The combination of the clock rate in the rtpmap and the bitrate
parameter defines the configuration of each payload type. Each
configuration intended to be used MUST be declared.
There are two sampling clock rates defined for G.722.1 in this
document. <a href="./rfc3047">RFC 3047</a> [<a href="./rfc3047" title=""RTP Payload Format for ITU-T Recommendation G.722.1"">RFC3047</a>] supports only the 16 Khz clock rate.
Therefore, a system that wants to use G.722.1 SHOULD offer a payload
type with clock rate of 16000 for backward interoperability.
An example of an offer that includes a 16000 and 32000 clock rate is:
m=audio 49000 RTP/AVP 121 122
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:122 G7221/32000
a=fmtp:122 bitrate=48000
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and any appropriate RTP profile. The main
security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity, and
source authenticity. Confidentiality is achieved by encryption of
the RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity-protection mechanism. Such a
cryptographic system may also allow the authentication of the source
<span class="grey">Luthi & Even Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at
least source authentication capable of determining if an RTP packet
is from a member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signaling protocol employed.
Therefore, a single mechanism is not sufficient; although, if
suitable, usage of the Secure Real-time Transport Protocol (SRTP) is
[<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] recommended. Another mechanism that may be used is IPsec
[<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] Transport Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] (RTP over TCP);
other alternatives may exist.
This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data.
Nor does the RTP payload format contain any active content.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Changes from <a href="./rfc3047">RFC 3047</a></span>
This specification obsoletes <a href="./rfc3047">RFC 3047</a>, adding the support for the
Superwideband (14 Khz) audio support defined in annex C of the new
revision of ITU-T G.722.1.
Other changes:
Updated the text to be in line with the current rules for RFCs and
with media type registration conforming to <a href="./rfc4288">RFC 4288</a>.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The authors would like to thank Tom Taylor for his contribution to
this work.
<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.G7221">ITU.G7221</a>] International Telecommunications Union, "Low-complexity
coding at 24 and 32 kbit/s for hands-free operation in
systems with low frame loss", ITU-T Recommendation
G.722.1, 2005.
[<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">Luthi & Even Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", <a href="./rfc3264">RFC 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-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3047">RFC3047</a>] Luthi, P., "RTP Payload Format for ITU-T Recommendation
G.722.1", <a href="./rfc3047">RFC 3047</a>, January 2001.
[<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.
[<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-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
August 2008.
<span class="grey">Luthi & Even Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5577">RFC 5577</a> G7221 July 2009</span>
Authors' Addresses
Patrick Luthi
Tandberg
Philip Pedersens vei 22
1366 Lysaker
Norway
EMail: patrick.luthi@tandberg.no
Roni Even
Gesher Erove Ltd
14 David Hamelech
Tel Aviv 64953
Israel
EMail: ron.even.tlv@gmail.com
Luthi & Even Standards Track [Page 11]
</pre>
|
