idnits 2.17.1 draft-ietf-avt-rtp-bv-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 616. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Juin-Hwey Chen 2 draft-ietf-avt-rtp-bv-04.txt Winnie Lee 3 April 4, 2005 Jes Thyssen 4 Expires: October 4, 2005 Broadcom Corporation 6 RTP Payload Format for BroadVoice Speech Codecs 8 Status of This Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes the RTP payload format for the 34 BroadVoice(TM) narrowband and wideband speech codecs developed by 35 Broadcom Corporation. The document also provides specifications 36 for the use of BroadVoice with MIME and SDP. 38 Table of Contents 40 1. Introduction....................................................2 41 2. Background......................................................2 42 3. RTP Payload Format for BroadVoice16 Narrowband Codec............3 43 3.1 BroadVoice16 Bit Stream Definition..........................4 44 3.2 Multiple BroadVoice16 Frames in an RTP Packet...............5 45 4. RTP Payload Format for BroadVoice32 Wideband Codec..............6 46 4.1 BroadVoice32 Bit Stream Definition..........................6 47 4.2 Multiple BroadVoice32 Frames in an RTP Packet...............8 48 5. IANA Considerations.............................................8 49 5.1 MIME Registration of BroadVoice16...........................9 50 5.2 MIME Registration of BroadVoice32...........................9 51 6. Mapping to SDP Parameters......................................10 52 6.1 Offer-Answer Model Considerations..........................11 53 7. Security Considerations........................................11 54 8. Congestion Control.............................................11 55 9. Acknowledgments................................................12 56 10. References.....................................................12 57 10.1 Normative References......................................12 58 10.2 Informative References....................................12 59 11. Authors' Addresses.............................................13 60 12. RFC-Editor Consideration.......................................13 62 1. Introduction 64 This document specifies the payload format for sending BroadVoice 65 encoded speech or audio signals using the Real-time Transport 66 Protocol (RTP) [1]. The sender may send one or more BroadVoice 67 codec data frames per packet, depending on the application scenario, 68 based on network conditions, bandwidth availability, delay 69 requirements, and packet-loss tolerance. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 73 this document are to be interpreted as described in RFC 2119 [2]. 75 2. Background 77 BroadVoice is a speech codec family developed by Broadcom for VoIP 78 (Voice over Internet Protocol) applications, including Voice over 79 Cable, Voice over DSL, and IP phone applications. BroadVoice 80 achieves high speech quality with a low coding delay and relatively 81 low codec complexity. 83 The BroadVoice codec family contains two codec versions. The 84 narrowband version of BroadVoice, called BroadVoice16 [3], or BV16 85 for short, encodes 8 kHz-sampled narrowband speech at a bit rate of 86 16 kilobits/second, or 16 kbit/s. The wideband version of 87 BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled 88 wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use 89 very similar (but not identical) coding algorithms; they share most 90 of their algorithm modules. 92 To minimize the delay in real-time two-way communications, both the 93 BV16 and BV32 encode speech with a very small frame size of 5 ms 94 without using any look ahead. This allows VoIP systems based on 95 BroadVoice to have a very low end-to-end system delay, by using a 96 packet size as small as 5 ms if necessary. 98 BroadVoice also has relatively low codec complexity when compared 99 with ITU-T standard speech codecs based on CELP (Coded Excited 100 Linear Prediction), such as G.728, G.729, G.723.1, G.722.2, etc. 101 Full-duplex implementations of the BV16 and BV32 take around 12 and 102 17 MIPS, respectively, on general-purpose 16-bit fixed-point DSPs. 103 The total memory footprints of the BV16 and BV32, including program 104 size, data tables, and data RAM, are around 12 kwords each, or 24 105 kbytes. 107 The PacketCable(TM) project of Cable Television Laboratories, Inc. 108 (CableLabs(r)) has chosen the BV16 codec for use in VoIP telephone 109 services provided by cable operators. More specifically, the BV16 110 codec was selected as one of the mandatory audio codecs in 111 PacketCable (TM) 1.5 Audio/Video Codecs Specification [4]. 113 3. RTP Payload Format for BroadVoice16 Narrowband Codec 115 The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, 116 so the RTP timestamp MUST be in units of 1/8000 of a second. The 117 RTP timestamp indicates the sampling instant of the oldest audio 118 sample represented by the frame(s) present in the payload. The 119 RTP payload for the BroadVoice16 has the format shown in the figure 120 below. No additional header specific to this payload format is 121 required. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | RTP Header [1] | 127 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 128 | | 129 | one or more frames of BroadVoice16 | 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 If BroadVoice16 is used for applications with silence compression, 133 the first BroadVoice16 packet after a silence period during which 134 packets have not been transmitted contiguously, SHOULD have the 135 marker bit in the RTP data header set to one. The marker bit 136 in all other packets is zero. Applications without silence 137 suppression MUST set the marker bit to zero. 139 The assignment of an RTP payload type for this new packet format is 140 outside the scope of this document, and will not be specified here. 141 It is expected that the RTP profile for a particular class of 142 applications will assign a payload type for this encoding, or if 143 that is not done then a payload type in the dynamic range shall be 144 chosen. 146 3.1 BroadVoice16 Bit Stream Definition 148 The BroadVoice16 encoder operates on speech frames of 5 ms 149 corresponding to 40 samples at a sampling rate of 8000 samples per 150 second. For every 5 ms frame, the encoder encodes the 40 151 consecutive audio samples into 80 bits, or 10 octets. Thus, the 152 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame 153 is octet-aligned, and no padding bits are required. The bit 154 allocation for the encoded parameters of the BroadVoice16 codec 155 is listed in the following table. 157 Encoded Parameter Codeword Number of bits per frame 158 ------------------------------------------------------------ 159 Line Spectrum Pairs L0,L1 7+7=14 160 Pitch Lag PL 7 161 Pitch Gain PG 5 162 Log-Gain LG 4 163 Excitation Vectors V0,...,V9 5*10=50 164 ------------------------------------------------------------ 165 Total: 80 bits 167 The mapping of the encoded parameters in an 80-bit BroadVoice16 data 168 frame is defined in the following figure. This figure shows the bit 169 packing in "network byte order", also known as big-endian order. 170 The bits of each 32-bit word are numbered 0 to 31, with the most 171 significant bit on the left and numbered 0. The octets (bytes) of 172 each word are transmitted most significant octet first. The bits of 173 data field for each encoded parameter are numbered in the same 174 order, with the most significant bit on the left. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | L0 | L1 | PL | PG | LG | V0| 181 | | | | | | | 182 |0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3|0 1| 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | V0 | V1 | V2 | V3 | V4 | V5 | V6 | 185 | | | | | | | | 186 |2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3| 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |V| V7 | V8 | V9 | 189 |6| | | | 190 |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: BroadVoice16 bit packing 195 3.2 Multiple BroadVoice16 Frames in an RTP Packet 197 More than one BroadVoice16 frame MAY be included in a single RTP 198 packet by a sender. Senders have the following additional 199 restrictions: 201 o SHOULD NOT include more BroadVoice16 frames in a single RTP 202 packet than will fit in the MTU of the RTP transport protocol. 204 o MUST NOT split a BroadVoice16 frame between RTP packets. 206 o BroadVoice16 frames in an RTP packet MUST be consecutive. 208 Since multiple BroadVoice16 frames in an RTP packet MUST be 209 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 210 recovering the timestamps of all frames within a packet is easy. 211 The oldest frame within an RTP packet has the same timestamp as the 212 RTP packet, as mentioned above. To obtain the timestamp of the 213 frame that is N frames later than the oldest frame in the packet, 214 one simply adds 5*N ms worth of time units to the timestamp of the 215 RTP packet. 217 It is RECOMMENDED that the number of frames contained within an RTP 218 packet is consistent with the application. For example, in a 219 telephony application where delay is important, the fewer frames per 220 packet the lower the delay, whereas for a delay insensitive 221 streaming or messaging application, many frames per packet would be 222 acceptable. 224 Information describing the number of frames contained in an RTP 225 packet is not transmitted as part of the RTP payload. The only way 226 to determine the number of BroadVoice16 frames is to count the total 227 number of octets within the RTP payload, and divide the octet count 228 by 10. 230 4. RTP Payload Format for BroadVoice32 Wideband Codec 232 The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 233 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. 234 The RTP timestamp indicates the sampling instant of the oldest 235 audio sample represented by the frame(s) present in the payload. 236 The RTP payload for the BroadVoice32 has the format shown in the 237 figure below. No additional header specific to this payload format 238 is required. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | RTP Header [1] | 244 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 245 | | 246 | one or more frames of BroadVoice32 | 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 If BroadVoice32 is used for applications with silence compression, 251 the first BroadVoice32 packet after a silence period during which 252 packets have not been transmitted contiguously, SHOULD have the 253 marker bit in the RTP data header set to one. The marker bit 254 in all other packets is zero. Applications without silence 255 suppression MUST set the marker bit to zero. 257 The assignment of an RTP payload type for this new packet format is 258 outside the scope of this document, and will not be specified here. 259 It is expected that the RTP profile for a particular class of 260 applications will assign a payload type for this encoding, or if 261 that is not done then a payload type in the dynamic range shall be 262 chosen. 264 4.1 BroadVoice32 Bit Stream Definition 266 The BroadVoice32 encoder operates on speech frames of 5 ms 267 corresponding to 80 samples at a sampling rate of 16000 samples per 268 second. For every 5 ms frame, the encoder encodes the 80 269 consecutive audio samples into 160 bits, or 20 octets. Thus, the 270 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame 271 is octet-aligned, and no padding bits are required. The bit 272 allocation for the encoded parameters of the BroadVoice32 codec 273 is listed in the following table. 274 Number of bits 275 Encoded Parameter Codeword per frame 276 --------------------------------------------------------------- 277 Line Spectrum Pairs L0,L1,L2 7+5+5=17 278 Pitch Lag PL 8 279 Pitch Gain PG 5 280 Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10 281 Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60 282 Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60 283 --------------------------------------------------------------- 284 Total: 160 bits 286 The mapping of the encoded parameters in a 160-bit BroadVoice32 data 287 frame is defined in the following figure. This figure shows the bit 288 packing in "network byte order", also known as big-endian order. 289 The bits of each 32-bit word are numbered 0 to 31, with the most 290 significant bit on the left and numbered 0. The octets (bytes) of 291 each word are transmitted most significant octet first. The bits of 292 data field for each encoded parameter are numbered in the same 293 order, with the most significant bit on the left. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | L0 | L1 | L2 | PL | PG |LG0| 299 | | | | | | | 300 |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4|0 1| 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | LG0 | LG1 | VA0 | VA1 | VA2 | VA3 | 303 | | | | | | | 304 |2 3 4|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5| 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | VA4 | VA5 | VA6 | VA7 | VA8 |VA9| 307 | | | | | | | 308 |0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1| 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | VA9 | VB0 | VB1 | VB2 | VB3 | VB4 | 311 | | | | | | | 312 |2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3| 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |VB4| VB5 | VB6 | VB7 | VB8 | VB9 | 315 | | | | | | | 316 |4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5| 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 2: BroadVoice32 bit packing 321 4.2 Multiple BroadVoice32 Frames in an RTP Packet 323 More than one BroadVoice32 frame MAY be included in a single RTP 324 packet by a sender. Senders have the following additional 325 restrictions: 327 o SHOULD NOT include more BroadVoice32 frames in a single RTP 328 packet than will fit in the MTU of the RTP transport protocol. 330 o MUST NOT split a BroadVoice32 frame between RTP packets. 332 o BroadVoice32 frames in an RTP packet MUST be consecutive. 334 Since multiple BroadVoice32 frames in an RTP packet MUST be 335 consecutive, and since BroadVoice32 has a fixed frame size of 5 ms, 336 recovering the timestamps of all frames within a packet is easy. 337 The oldest frame within an RTP packet has the same timestamp as the 338 RTP packet, as mentioned above. To obtain the timestamp of the 339 frame that is N frames later than the oldest frame in the packet, 340 one simply adds 5*N ms worth of time units to the timestamp of the 341 RTP packet. 343 It is RECOMMENDED that the number of frames contained within an RTP 344 packet is consistent with the application. For example, in a 345 telephony application where delay is important, the fewer frames per 346 packet the lower the delay, whereas for a delay insensitive 347 streaming or messaging application, many frames per packet would be 348 acceptable. 350 Information describing the number of frames contained in an RTP 351 packet is not transmitted as part of the RTP payload. The only way 352 to determine the number of BroadVoice32 frames is to count the total 353 number of octets within the RTP payload, and divide the octet count 354 by 20. 356 5. IANA Considerations 358 Two new MIME sub-types as described in this section are to be 359 registered. 361 The MIME names for the BV16 and BV32 codecs are to be allocated from 362 the IETF tree since these two codecs are expected to be widely used 363 for Voice-over-IP applications, especially in Voice over Cable 364 applications. 366 5.1 MIME Registration of BroadVoice16 for RTP 368 MIME media type name: audio 370 MIME media subtype name: BV16 372 Required parameter: none 374 Optional parameters: 375 ptime: Defined as usual for RTP audio (see RFC 2327 [5]). 377 maxptime: See RFC 2327 [5] for its definition. The maxptime 378 SHOULD be a multiple of the duration of a single codec data 379 frame (5 ms). 381 Encoding considerations: 382 This type is defined for transfer of BV16-encoded data via RTP 383 using the payload format specified in Sections 3 of RFC XXXX. 384 Audio data is binary data and must be encoded for non-binary 385 transport; the Base64 encoding is suitable for Email. 387 Security considerations: 388 See Section 7 "Security Considerations" of RFC XXXX. 390 Public specification: 391 The BroadVoice16 codec has been specified in [3]. 393 Intended usage: 394 COMMON. It is expected that many VoIP applications, especially 395 Voice over Cable applications, will use this type. 397 Person & email address to contact for further information: 398 Juin-Hwey (Raymond) Chen 399 rchen@broadcom.com 401 Author/Change controller: 402 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 403 Change Controller: IETF Audio/Video Transport Working Group 404 delegated from the IESG 406 5.2 MIME Registration of BroadVoice32 for RTP 408 MIME media type name: audio 410 MIME media subtype name: BV32 412 Required parameter: none 413 Optional parameters: 414 ptime: Defined as usual for RTP audio (see RFC 2327 [5]). 416 maxptime: See RFC 2327 [5] for its definition. The maxptime 417 SHOULD be a multiple of the duration of a single codec data 418 frame (5 ms). 420 Encoding considerations: 421 This type is defined for transfer of BV32-encoded data via RTP 422 using the payload format specified in Sections 4 of RFC XXXX. 423 Audio data is binary data and must be encoded for non-binary 424 transport; the Base64 encoding is suitable for Email. 426 Security considerations: 427 See Section 7 "Security Considerations" of RFC XXXX. 429 Intended usage: 430 COMMON. It is expected that many VoIP applications, especially 431 Voice over Cable applications, will use this type. 433 Person & email address to contact for further information: 434 Juin-Hwey (Raymond) Chen 435 rchen@broadcom.com 437 Author/Change controller: 438 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 439 Change Controller: IETF Audio/Video Transport Working Group 440 delegated from the IESG 442 6. Mapping to SDP Parameters 444 The information carried in the MIME media type specification has a 445 specific mapping to fields in the Session Description Protocol (SDP) 446 [5], which is commonly used to describe RTP sessions. When SDP is 447 used to specify sessions employing the BroadVoice16 or BroadVoice32 448 codec, the mapping is as follows: 450 - The MIME type ("audio") goes in SDP "m=" as the media name. 452 - The MIME subtype (payload format name) goes in SDP "a=rtpmap" 453 as the encoding name. The RTP clock rate in "a=rtpmap" MUST 454 be 8000 for BV16 and 16000 for BV32. 456 - The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 457 and "a=maxptime" attributes, respectively. 459 An example of the media representation in SDP for describing BV16 460 might be: 462 m=audio 49120 RTP/AVP 97 463 a=rtpmap:97 BV16/8000 465 An example of the media representation in SDP for describing BV32 466 might be: 468 m=audio 49122 RTP/AVP 99 469 a=rtpmap:99 BV32/16000 471 6.1 Offer-Answer Model Considerations 473 No special considerations are need for using the SDP Offer/Answer 474 model [6] with the BV16 and BV32 RTP payload formats. 476 7. Security Considerations 478 RTP packets using the payload format defined in this specification 479 are subject to the security considerations discussed in the RTP 480 specification [1] and any appropriate profile (for example, [7]). 481 This implies that confidentiality of the media streams is achieved 482 by encryption. Because the data compression used with this payload 483 format is applied end-to-end, encryption may be performed after 484 compression so there is no conflict between the two operations. 486 A potential denial-of-service threat exists for data encoding using 487 compression techniques that have non-uniform receiver-end 488 computational load. The attacker can inject pathological datagrams 489 into the stream which are complex to decode and cause the receiver 490 to become overloaded. However, the encodings covered in this 491 document do not exhibit any significant non-uniformity. 493 8. Congestion Control 495 The general congestion control considerations for transporting RTP 496 data apply to BV16 and BV32 audio over RTP as well, see RTP [1] 497 and any applicable RTP profile like AVP [7]. BV16 and BV32 do not 498 have any built-in mechanism for reducing the bandwidth. Packing 499 more frames in each RTP payload can reduce the number of packets 500 sent and hence the overhead from IP/UDP/RTP headers, at the 501 expense of increased delay and reduced error robustness against 502 packet losses. 504 9. Acknowledgments 506 The authors would like to thank Magnus Westerlung, Colin Perkins, 507 Allison Mankin, and Jean-Francois Mule for their review of this 508 document. 510 10. References 512 10.1 Normative References 514 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 515 A Transport Protocol for Real-Time Applications", STD 64, 516 RFC 3550, Internet Engineering Task Force, July 2003. 518 [2] S. Bradner, "Key words for use in RFCs to Indicate requirement 519 Levels", BCP 14, RFC 2119, Internet Engineering Task Force, 520 March 1997. 522 [3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech 523 Codec Specification, Revision 1.2, October 30, 2003. 525 [5] M. Handley and V. Jacobson, "SDP: Session Description 526 Protocol", RC 2327, April 1998. 528 [6] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with 529 the Session Description Protocol (SDP)", RFC 3264, Internet 530 Engineering Task Force, June 2002. 532 [7] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 533 Conferences with Minimal Control", STD 65, RFC 3551, Internet 534 Engineering Task Force, July 2003. 536 10.2 Informative References 538 [4] Cable Television Laboratories, Inc., PacketCable(TM) 1.5 539 Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128, 540 January 28, 2005. 541 http://www.cablelabs.com/specifications/archives/ 543 11. Authors' Addresses 545 Juin-Hwey (Raymond) Chen 546 Broadcom Corporation 547 Room A3020 548 16215 Alton Parkway 549 Irvine, CA 92618 550 USA 551 Phone: +1 949 926 6288 552 Email: rchen@broadcom.com 554 Winnie Lee 555 Broadcom Corporation 556 Room A2012E 557 200-13711 International Place 558 Richmond, British Columbia V6V 2Z8 559 Canada 560 Phone: +1 604 233 8605 561 Email: wlee@broadcom.com 563 Jes Thyssen 564 Broadcom Corporation 565 Room A3018 566 16215 Alton Parkway 567 Irvine, CA 92618 568 USA 569 Phone: +1 949 926 5768 570 Email: jthyssen@broadcom.com 572 12. RFC-Editor Consideration 574 The RFC-editor is kindly requested to perform the following 575 modifications upon the publication of this specification: 577 - Replace all occurrences of RFC XXXX with the RFC number this 578 specification receives when being published. 580 - Remove this Section. 582 Expires: October 4, 2005 584 Copyright (C) The Internet Society (2005). This document is subject 585 to the rights, licenses and restrictions contained in BCP 78, and 586 except as set forth therein, the authors retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 591 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 592 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 593 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 The IETF takes no position regarding the validity or scope of any 597 Intellectual Property Rights or other rights that might be claimed to 598 pertain to the implementation or use of the technology described in 599 this document or the extent to which any license under such rights 600 might or might not be available; nor does it represent that it has 601 made any independent effort to identify any such rights. Information 602 on the procedures with respect to rights in RFC documents can be 603 found in BCP 78 and BCP 79. 605 Copies of IPR disclosures made to the IETF Secretariat and any 606 assurances of licenses to be made available, or the result of an 607 attempt made to obtain a general license or permission for the use 608 of such proprietary rights by implementers or users of this 609 specification can be obtained from the IETF on-line IPR repository 610 at http://www.ietf.org/ipr. 612 The IETF invites any interested party to bring to its attention 613 any copyrights, patents or patent applications, or other 614 proprietary rights that may cover technology that may be required 615 to implement this standard. Please address the information to the 616 IETF at ietf-ipr@ietf.org.