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
|
Internet Engineering Task Force (IETF) M. Perumal
Request for Comments: 7261 Cisco Systems
Category: Standards Track P. Ravindran
ISSN: 2070-1721 NSN
May 2014
Offer/Answer Considerations for G723 Annex A and G729 Annex B
Abstract
This document provides the offer/answer considerations for the annexa
parameter of G723 and the annexb parameter of G729, G729D, and G729E
when the value of the annexa or annexb parameter does not match in
the Session Description Protocol (SDP) offer and answer.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7261.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Perumal & Ravindran Standards Track [Page 1]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . 3
3.1. Considerations for Use of Comfort Noise Frames . . . . . 3
3.2. Offer/Answer Considerations for G723 Annex A . . . . . . 3
3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex
B, and G729E Annex B . . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Offer with G729 annexb=yes and Answer with G729 annexb=no 5
4.2. Offer with G729 annexb=yes and Answer with G729 and No
annexb Parameter . . . . . . . . . . . . . . . . . . . . 5
4.3. Offer with G729 and No annexb Parameter and Answer with
G729 annexb=no . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[RFC4856] describes the annexa parameter for G723 as follows:
annexa: indicates that Annex A, voice activity detection, is used
or preferred. Permissible values are "yes" and "no" (without the
quotes); "yes" is implied if this parameter is omitted.
Also, [RFC4856] describes the annexb parameter for G729, G729D, and
G729E as follows:
annexb: indicates that Annex B, voice activity detection, is used
or preferred. Permissible values are "yes" and "no" (without the
quotes); "yes" is implied if this parameter is omitted.
However, a problem arises when the value of the annexa or annexb
parameter does not match in the SDP [RFC4566] offer and answer.
For example, if the offer has G729 with annexb=yes and the answer has
G729 with annexb=no, it can be interpreted in two different ways:
o The offerer and answerer proceed as if G729 is negotiated with
annexb=yes, or
o The offerer and answerer proceed as if G729 is negotiated with
annexb=no.
Perumal & Ravindran Standards Track [Page 2]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
Since this is not clear in the existing specifications, various
implementations have interpreted the offer/answer in their own ways,
resulting in a different codec being chosen to call failure, when the
parameter value does not match in the offer and answer.
[RFC3264] requires SDP extensions that define new fmtp parameters to
specify their proper interpretation in offer/answer. This document
specifies the proper interpretation for the annexa and annexb
parameters in offer/answer.
2. Terminology
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 [RFC2119].
3. Offer/Answer Considerations
The general objective of the offer/answer considerations is to make
sure that if the offerer or answerer indicates it does not support
Annex A or Annex B, then Annex A or Annex B is not used.
3.1. Considerations for Use of Comfort Noise Frames
[RFC3551] states that:
Receivers MUST accept comfort noise frames if restriction of their
use has not been signaled. The MIME registration for G729 in RFC
3555 specifies a parameter that MAY be used with MIME or SDP to
restrict the use of comfort noise frames.
Hence, if the SDP offer or answer indicates that comfort noise is not
supported, comfort noise frames MUST NOT be used.
3.2. Offer/Answer Considerations for G723 Annex A
When the offer or answer has G723 and the annexa parameter is absent,
the offerer or answerer knows that it has implied the default
"annexa=yes". This is because the annexa attribute is part of the
original registration of audio/G723 [RFC4856]. All implementations
that support G723 understand the annexa attribute. Hence, this case
MUST be considered as if the offer or answer has G723 with
annexa=yes.
When the offer has G723 with annexa=yes and the answer has G723 with
annexa=no, the offerer and answerer MUST proceed as if G723 is
negotiated with annexa=no.
Perumal & Ravindran Standards Track [Page 3]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
When the offer has G723 with annexa=no, after the offer/answer
completion the offerer and answerer MUST proceed as if G723 is
negotiated with annexa=no.
When the offer has G723 with annexa=no, the reason for not
mandating that the answer MUST have annexa=no for G723 is that
there are implementations that omit the annexa parameter in
answer. In such cases, the offerer and answerer proceed as if
G723 is negotiated with annexa=no.
When the offer has G723 with no annexa parameter and the answer has
G723 with annexa=yes, the offerer and answerer MUST proceed as if
G723 is negotiated with annexa=yes.
3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex B, and
G729E Annex B
In this section, G729 represents any of G729 or G729D or G729E.
When the offer or answer has G729 and the annexb parameter is absent,
the offerer or answerer knows that it has implied the default
"annexb=yes". This is because the annexb attribute is part of the
original registration of audio/G729 [RFC4856]. All implementations
that support G729 understand the annexb attribute. Hence, this case
MUST be considered as if the offer or answer has G729 with
annexb=yes.
When the offer has G729 with annexb=yes and the answer has G729 with
annexb=no, the offerer and answerer MUST proceed as if G729 is
negotiated with annexb=no.
When the offer has G729 with annexb=no, after the offer/answer
completion the offerer and answerer MUST proceed as if G729 is
negotiated with annexb=no.
When the offer has G729 with annexb=no, the reason for not
mandating that the answer MUST have annexb=no for G729 is that
there are implementations that omit the annexb parameter in the
answer. In such cases, the offerer and answerer proceed as if
G729 is negotiated with annexb=no.
When the offer has G729 with no annexb parameter and the answer has
G729 with annexb=yes, the offerer and answerer MUST proceed as if
G729 is negotiated with annexb=yes.
Perumal & Ravindran Standards Track [Page 4]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
4. Examples
4.1. Offer with G729 annexb=yes and Answer with G729 annexb=no
[Offer with G729 annexb=yes]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
[Answer with G729 annexb=no]
v=0
o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
s=
c=IN IP4 host.bangalore.example.com
t=0 0
m=audio 19140 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
In the above example, the offerer and answerer proceed as if G729 is
negotiated with annexb=no.
4.2. Offer with G729 annexb=yes and Answer with G729 and No annexb
Parameter
[Offer with G729 annexb=yes]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
Perumal & Ravindran Standards Track [Page 5]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
[Answer with G729 and no annexb parameter]
v=0
o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
s=
c=IN IP4 host.bangalore.example.com
t=0 0
m=audio 19140 RTP/AVP 18
a=rtpmap:18 G729/8000
In the above example, the offerer and answerer proceed as if G729 is
negotiated with annexb=yes.
4.3. Offer with G729 and No annexb Parameter and Answer with G729
annexb=no
[Offer with G729 and no annexb parameter]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 18
a=rtpmap:18 G729/8000
[Answer with G729 annexb=no]
v=0
o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
s=
c=IN IP4 host.bangalore.example.com
t=0 0
m=audio 19140 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
In the above example, the offerer and answerer proceed as if G729 is
negotiated with annexb=no.
5. Security Considerations
The guidelines described in [RFC6562] are to be followed for Use of
Voice Activity Detection (i.e., Annex A or Annex B) with the Secure
Real-time Transport Protocol (SRTP).
Perumal & Ravindran Standards Track [Page 6]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
6. Acknowledgments
Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson),
Ali C. Begen (Cisco), Paul Kyzivat (Huawei), Roni Even (Huawei),
Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming
(Digium), Dale Worley (Avaya), Cullen Jennings (Cisco), Ari Keranen
(Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud
(Orange), SM, Stephen Casner, Keith Drage (Alcatel-Lucent), Stephen
Farrell, Barry Leiba, and Ted Lemon for their valuable input and
comments. Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet)
provided useful suggestions at the mic at IETF 83.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", RFC
4856, February 2007.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, March
2012.
Perumal & Ravindran Standards Track [Page 7]
^L
RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014
Authors' Addresses
Muthu Arul Mozhi Perumal
Cisco Systems
Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
EMail: mperumal@cisco.com
Parthasarathi Ravindran
NSN
Manyata Embassy Business park
Bangalore, Karnataka 560045
India
EMail: partha@parthasarathi.co.in
Perumal & Ravindran Standards Track [Page 8]
^L
|
