idnits 2.17.1 draft-chen-rtp-bv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1890 (ref. '5') (Obsoleted by RFC 3551) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Juin-Hwey Chen 3 draft-chen-rtp-bv-01.txt Cheng-Chieh Lee 4 September 3, 2003 Winnie Lee 5 Expires: March 3, 2004 Jes Thyssen 6 Broadcom Corporation 8 RTP Payload Format for BroadVoice Speech Codecs 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 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 Internet- 18 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/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes the RTP payload format for the 33 BroadVoice(TM) narrowband and wideband speech codecs developed by 34 Broadcom Corporation. The document also provides specifications for 35 the use of BroadVoice with MIME and SDP. 37 Table of Contents 39 1. Introduction....................................................2 40 2. Background......................................................2 41 3. RTP Payload Format for BroadVoice16 Narrowband Codec............3 42 3.1 BroadVoice16 Bit Stream Definition..........................3 43 3.2 Multiple BroadVoice16 Frames in An RTP Packets..............4 44 4. RTP Payload Format for BroadVoice32 Wideband Codec..............5 45 4.1 BroadVoice32 Bit Stream Definition..........................5 46 4.2 Multiple BroadVoice32 Frames in An RTP Packet...............7 47 5. Storage Format..................................................7 48 6. IANA Considerations.............................................8 49 6.1 MIME registration of BroadVoice16...........................8 50 6.2 MIME registration of BroadVoice32...........................9 52 7. Mapping To SDP Parameters......................................10 53 8. Security Considerations........................................11 54 9. References.....................................................11 55 10. Authors' Addresses............................................11 57 1. Introduction 59 This document specifies the payload format for sending BroadVoice 60 encoded speech or audio signals using the Real-time Transport 61 Protocol (RTP) [1]. The sender may send one or more BroadVoice 62 codec data frames per packet, depending on the application scenario, 63 based on network conditions, bandwidth availability, delay 64 requirements, and packet-loss tolerance. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 68 this document are to be interpreted as described in RFC 2119 [2]. 70 2. Background 72 BroadVoice [3] is a speech codec family developed by Broadcom for 73 VoIP applications, including Voice over Cable, Voice over DSL, and 74 IP phone applications. BroadVoice achieves high speech quality with 75 a low coding delay and relatively low codec complexity. 77 The BroadVoice codec family contains two codec versions. The 78 narrowband version of BroadVoice, called BroadVoice16, or BV16 for 79 short, encodes 8 kHz-sampled narrowband speech at a bit rate of 80 16 kilobits/second, or 16 kbit/s. The wideband version of 81 BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled 82 wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use 83 very similar (but not identical) coding algorithms; they share most 84 of their algorithm modules. 86 To minimize the delay in real-time two-way communications, both the 87 BV16 and BV32 encode speech with a very small frame size of 5 ms 88 without using any look ahead. This allows VoIP systems based on 89 BroadVoice to have a very low end-to-end system delay, by using a 90 packet size as small as 5 ms if necessary. 92 BroadVoice also has relatively low codec complexity when compared 93 with other ITU-T standard speech codecs based on CELP (Coded Excited 94 Linear Prediction), such as G.728, G.729, G.723.1, G.722.2, etc. 95 Full-duplex implementations of the BV16 and BV32 take around 12 and 96 17 MIPS, respectively, on general-purpose 16-bit fixed-point DSPs. 97 The total memory footprints of the BV16 and BV32, including program 98 size, data tables, and data RAM, are around 12 kwords, or 24 kbytes. 100 3. RTP Payload Format for BroadVoice16 Narrowband Codec 102 The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, 103 so the RTP timestamp MUST be in units of 1/8000 of a second. The RTP 104 payload for the BroadVoice16 has the format shown in the figure 105 below. No additional header specific to this payload format is 106 required. 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | RTP Header [1] | 112 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 113 | | 114 | one or more frames of BroadVoice16 | 115 | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 When more than one codec data frame is present in a single RTP 119 packet, the timestamp is, as always, that of the oldest data frame 120 represented in the RTP packet. 122 If BroadVoice16 is used for applications with silence compression, 123 the first BroadVoice16 packet after a silence period during which 124 packets have not been transmitted contiguously, SHOULD have the 125 the marker bit in the RTP data header set to one. The marker bit 126 in all other packets is zero. Applications without silence 127 suppression MUST set the marker bit to zero. 129 The assignment of an RTP payload type for this new packet format is 130 outside the scope of this document, and will not be specified here. 131 It is expected that the RTP profile for a particular class of 132 applications will assign a payload type for this encoding, or if 133 that is not done then a payload type in the dynamic range shall be 134 chosen. 136 3.1 BroadVoice16 Bit Stream Definition 138 The BroadVoice16 encoder operates on speech frames of 5 ms 139 corresponding to 40 samples at a sampling rate of 8000 samples per 140 second. For every 5 ms frame, the encoder encodes the 40 141 consecutive audio samples into 80 bits, or 10 octets. Thus, the 142 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame 143 is octet-aligned, and no padding bits are required. The bit 144 allocation for the encoded parameters of the BroadVoice16 codec 145 is listed in the following table. 147 Encoded Parameter Codeword Number of bits per frame 148 ------------------------------------------------------------ 149 Line Spectrum Pairs L0,L1 7+7=14 150 Pitch Lag PL 7 151 Pitch Gain PG 5 152 Log-Gain LG 4 153 Excitation Vectors V0,...,V9 5*10=50 154 ------------------------------------------------------------ 155 Total: 80 bits 157 The mapping of the encoded parameters in an 80-bit BroadVoice16 data 158 frame is defined in the following figure. This figure shows the bit 159 packing in "network byte order", also known as big-endian order. 160 The bits of each 32-bit word are numbered 0 to 31, with the most 161 significant bit on the left and numbered 0. The octets (bytes) of 162 each word are transmitted most significant octet first. The bits of 163 data field for each encoded parameter are numbered in the same 164 order, with the most significant bit on the left. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | L0 | L1 | PL | PG | LG | V0| 170 | | | | | | | 171 |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| 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | V0 | V1 | V2 | V3 | V4 | V5 | V6 | 174 | | | | | | | | 175 |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| 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |V| V7 | V8 | V9 | 178 |6| | | | 179 |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 1: BroadVoice16 bit packing 184 3.2 Multiple BroadVoice16 Frames in An RTP Packet 186 More than one BroadVoice16 frame may be included in a single RTP 187 packet by a sender. Senders have the following additional 188 restrictions: 190 o SHOULD NOT include more BroadVoice16 frames in a single RTP 191 packet than will fit in the MTU of the RTP transport protocol. 193 o MUST NOT split a BroadVoice16 frame between RTP packets. 195 o BroadVoice16 frames in an RTP packet MUST be consecutive. 197 It is RECOMMENDED that the number of frames contained within an RTP 198 packet is consistent with the application. For example, in a 199 telephony application where delay is important, the fewer frames per 200 packet the lower the delay, whereas for a delay insensitive 201 streaming or messaging application, many frames per packet would be 202 acceptable. 204 Information describing the number of frames contained in an RTP 205 packet is not transmitted as part of the RTP payload. The only way 206 to determine the number of BroadVoice16 frames is to count the total 207 number of octets within the RTP packet, and divide the octet count 208 by 10. 210 4. RTP Payload Format for BroadVoice32 Wideband Codec 212 The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 213 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. 214 The RTP payload for the BroadVoice32 has the format shown in the 215 figure below. No additional header specific to this payload format 216 is required. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | RTP Header [1] | 222 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 223 | | 224 | one or more frames of BroadVoice32 | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 When more than one codec data frame is present in a single RTP 229 packet, the timestamp is, as always, that of the oldest data frame 230 represented in the RTP packet. 232 If BroadVoice32 is used for applications with silence compression, 233 the first BroadVoice32 packet after a silence period during which 234 packets have not been transmitted contiguously, SHOULD have the 235 the marker bit in the RTP data header set to one. The marker bit 236 in all other packets is zero. Applications without silence 237 suppression MUST set the marker bit to zero. 239 The assignment of an RTP payload type for this new packet format is 240 outside the scope of this document, and will not be specified here. 241 It is expected that the RTP profile for a particular class of 242 applications will assign a payload type for this encoding, or if 243 that is not done then a payload type in the dynamic range shall be 244 chosen. 246 4.1 BroadVoice32 Bit Stream Definition 248 The BroadVoice32 encoder operates on speech frames of 5 ms 249 corresponding to 80 samples at a sampling rate of 16000 samples per 250 second. For every 5 ms frame, the encoder encodes the 80 251 consecutive audio samples into 160 bits, or 20 octets. Thus, the 252 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame 253 is octet-aligned, and no padding bits are required. The bit 254 allocation for the encoded parameters of the BroadVoice32 codec 255 is listed in the following table. 256 Number of bits 257 Encoded Parameter Codeword per frame 258 --------------------------------------------------------------- 259 Line Spectrum Pairs L0,L1,L2 7+5+5=17 260 Pitch Lag PL 8 261 Pitch Gain PG 5 262 Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10 263 Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60 264 Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60 265 --------------------------------------------------------------- 266 Total: 160 bits 268 The mapping of the encoded parameters in a 160-bit BroadVoice32 data 269 frame is defined in the following figure. This figure shows the bit 270 packing in "network byte order", also known as big-endian order. 271 The bits of each 32-bit word are numbered 0 to 31, with the most 272 significant bit on the left and numbered 0. The octets (bytes) of 273 each word are transmitted most significant octet first. The bits of 274 data field for each encoded parameter are numbered in the same 275 order, with the most significant bit on the left. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | L0 | L1 | L2 | PL | PG |LG0| 281 | | | | | | | 282 |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| 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | LG0 | LG1 | VA0 | VA1 | VA2 | VA3 | 285 | | | | | | | 286 |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| 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | VA4 | VA5 | VA6 | VA7 | VA8 |VA9| 289 | | | | | | | 290 |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| 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | VA9 | VB0 | VB1 | VB2 | VB3 | VB4 | 293 | | | | | | | 294 |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| 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |VB4| VB5 | VB6 | VB7 | VB8 | VB9 | 297 | | | | | | | 298 |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| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 2: BroadVoice32 bit packing 303 4.2 Multiple BroadVoice32 Frames in An RTP Packet 305 More than one BroadVoice32 frame may be included in a single RTP 306 packet by a sender. Senders have the following additional 307 restrictions: 309 o SHOULD NOT include more BroadVoice32 frames in a single RTP 310 packet than will fit in the MTU of the RTP transport protocol. 312 o MUST NOT split a BroadVoice32 frame between RTP packets. 314 o BroadVoice32 frames in an RTP packet MUST be consecutive. 316 It is RECOMMENDED that the number of frames contained within an RTP 317 packet is consistent with the application. For example, in a 318 telephony application where delay is important, the fewer frames per 319 packet the lower the delay, whereas for a delay insensitive 320 streaming or messaging application, many frames per packet would be 321 acceptable 322 Information describing the number of frames contained in an RTP 323 packet is not transmitted as part of the RTP payload. The only way 324 to determine the number of BroadVoice32 frames is to count the total 325 number of octets within the RTP packet, and divide the octet count 326 by 20. 328 5. Storage Format 330 The storage format is used for storing speech frames, e.g., as a 331 file or e-mail attachment. 333 The file begins with a header that includes only a magic number to 334 identify the codec that is used. The magic number for the 335 BroadVoice16 narrowband codec MUST correspond to the ASCII character 336 string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in 337 hexadecimal format. The magic number for the BroadVoice32 wideband 338 codec MUST correspond to the ASCII character string "#!BV32\n", or 339 "0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded 340 bit stream of either BroadVoice16 or BroadVoice32, but not both. In 341 other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be 342 mixed in the same file. 344 After the header that contains the magic number identifying the 345 codec used, the encoded codec data frames are stored in a sequential 346 order, as shown below. 348 +--------+---------------+---------------+-----+---------------+ 349 | Header | Codec frame 1 | Codec frame 2 | ... | Codec frame N | 350 +--------+---------------+---------------+-----+---------------+ 352 6. IANA Considerations 354 Two new MIME sub-types as described in this section are to be 355 registered. 357 The MIME names for the BV16 and BV32 codecs are to be allocated from 358 the IETF tree since these two codecs are expected to be widely used 359 for Voice-over-IP applications, espcially in Voice over Cable 360 applications. 362 6.1 MIME registration of BroadVoice16 364 MIME media type name: audio 366 MIME media subtype name: BV16 368 Required Parameter: none 369 Optional parameters: 370 The following parameters apply to RTP transfer only. 372 ptime: Defined as usual for RTP audio (see RFC 2327). 374 maxptime: The maximum amount of media which can be encapsulated 375 in each packet, expressed as time in milliseconds. The time 376 SHALL be calculated as the sum of the time the media present 377 in the packet represents. The time SHOULD be a multiple of the 378 duration of a single codec data frame (5 ms). 380 Encoding considerations: 381 This type is defined for transfer of BV16-encoded data via RTP 382 using the payload format specified in Sections 3 of RFC xxxx. 383 It is also defined for other transfer methods using the storage 384 format specified in Section 5 of RFC xxxx. Audio data is binary 385 data, and must be encoded for non-binary transport; the Base64 386 encoding is suitable for Email. 388 Security considerations: 389 See Section 8 "Security Considerations" of RFC xxxx. 391 Public specification: 392 The BroadVoice16 codec has been specified in [3]. 394 Additional information: 395 The following information applies to storage format only. 397 Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21 398 0x42 0x56 0x31 0x36 0x0A" in hexadecimal) 400 File extensions: bvn, BVN (stands for "BroadVoice, Narrowband") 402 Macintosh file type code: none 404 Object identifier or OID: none 406 Intended usage: 407 COMMON. It is expected that many VoIP applications, especially 408 Voice over Cable applications, will use this type. 410 Person & email address to contact for further information: 411 Juin-Hwey (Raymond) Chen 412 rchen@broadcom.com 414 Author/Change controller: 415 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 416 Change Controller: IETF Audio/Video Transport Working Group 418 6.2 MIME registration of BroadVoice32 420 MIME media type name: audio 422 MIME media subtype name: BV32 424 Required Parameter: none 426 Optional parameters: 427 The following parameters apply to RTP transfer only. 429 ptime: Defined as usual for RTP audio (see RFC 2327). 431 maxptime: The maximum amount of media which can be encapsulated 432 in each packet, expressed as time in milliseconds. The time 433 SHALL be calculated as the sum of the time the media present 434 in the packet represents. The time MUST be a multiple of the 435 duration of a single codec data frame (5 ms). 437 Encoding considerations: 438 This type is defined for transfer of BV32-encoded data via RTP 439 using the payload format specified in Sections 4 of RFC xxxx. 440 It is also defined for other transfer methods using the storage 441 format specified in Section 5 of RFC xxxx. Audio data is binary 442 data, and must be encoded for non-binary transport; the Base64 443 encoding is suitable for Email. 445 Security considerations: 446 See Section 8 "Security Considerations" of RFC xxxx. 448 Additional information: 449 The following information applies to storage format only. 451 Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21 452 0x42 0x56 0x33 0x32 0x0A" in hexadecimal) 454 File extensions: bvw, BVW (stands for "BroadVoice, Wideband") 456 Macintosh file type code: none 458 Object identifier or OID: none 460 Intended usage: 461 COMMON. It is expected that many VoIP applications, especially 462 Voice over Cable applications, will use this type. 464 Person & email address to contact for further information: 465 Juin-Hwey (Raymond) Chen 466 rchen@broadcom.com 468 Author/Change controller: 469 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 470 Change Controller: IETF Audio/Video Transport Working Group 472 7. Mapping To SDP Parameters 474 The information carried in the MIME media type specification has a 475 specific mapping to fields in the Session Description Protocol (SDP) 476 [4], which is commonly used to describe RTP sessions. When SDP is 477 used to specify sessions employing the BroadVoice16 or BroadVoice32 478 codec, the mapping is as follows: 480 - The MIME type ("audio") goes in SDP "m=" as the media name. 482 - The MIME subtype (payload format name) goes in SDP "a=rtpmap" 483 as the encoding name. The RTP clock rate in "a=rtpmap" MUST 484 be 8000 for BV16 and 16000 for BV32. 486 - The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 487 and "a=maxptime" attributes, respectively. 489 - Any remaining parameters go in the SDP "a=fmtp" attribute by 490 copying them directly from the MIME media type string as a 491 semicolon separated list of parameter=value pairs. 493 An example of the media representation in SDP for describing BV16 494 might be: 496 m=audio 49120 RTP/AVP 97 497 a=rtpmap:97 BV16/8000 499 An example of the media representation in SDP for describing BV32 500 might be: 502 m=audio 49122 RTP/AVP 99 503 a=rtpmap:99 BV32/16000 505 8. Security Considerations 507 RTP packets using the payload format defined in this specification 508 are subject to the security considerations discussed in the RTP 509 specification [1] and any appropriate profile (for example, [5]). 510 This implies that confidentiality of the media streams is achieved 511 by encryption. Because the data compression used with this payload 512 format is applied end-to-end, encryption may be performed after 513 compression so there is no conflict between the two operations. 515 A potential denial-of-service threat exists for data encoding using 516 compression techniques that have non-uniform receiver-end 517 computational load. The attacker can inject pathological datagrams 518 into the stream which are complex to decode and cause the receiver 519 to become overloaded. However, the encodings covered in this 520 document do not exhibit any significant non-uniformity. 522 9. References 524 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 525 A Transport Protocol for Real-Time Applications", IETF RFC 1889, 526 January 1996. 528 [2] S. Bradner, "Key words for use in RFCs to Indicate requirement 529 Levels", BCP 14, RFC 2119, March 1997. 531 [3] BroadVoice(TM)16 Speech Codec Specification, Revision 1.1, July 532 20, 2003, submitted to PacketCable vendor meetings at 533 CableLabs(R) as part of the ECR process for updating the 534 PacketCable(TM) Audio/Video Codecs Specification, Cable 535 Television Laboratories, Inc. 537 [4] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 538 IETF RFC 2327, April 1998 540 [5] H. Schulzrinne, "RTP Profile for Audio and Video Conferences 541 with Minimal Control" IETF RFC 1890, January 1996. 543 10. Authors' Addresses 545 Juin-Hwey (Raymond) Chen 546 Broadcom Corporation 547 Room A3032 548 16215 Alton Parkway 549 Irvine, CA 92618 550 USA 551 Phone: +1 949 926 6288 552 Email: rchen@broadcom.com 554 Cheng-Chieh Lee 555 Broadcom Corporation 556 Room 202 557 3F-2, Lane 99, Puding Rd, 558 HsinChu City, Taiwan 300 559 Phone: +886 3 516 1176� � 560 Email: cclee@broadcom.com 561 Winnie Lee 562 Broadcom Corporation 563 Room A2012E 564 200-13711 International Place 565 Richmond, British Columbia V6V 2Z8 566 Canada 567 Phone: +1 604 233 8605 568 Email: wlee@broadcom.com 570 Jes Thyssen 571 Broadcom Corporation 572 Room A3053 573 16215 Alton Parkway 574 Irvine, CA 92618 575 USA 576 Phone: +1 949 926 5768 577 Email: jthyssen@broadcom.com