idnits 2.17.1 draft-ietf-avt-rtp-bv-03.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 675. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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: 5 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-03.txt Winnie Lee 3 February 17, 2005 Jes Thyssen 4 Expires: August 17, 2005 Broadcom Corporation 6 RTP Payload and Storage Format for BroadVoice Speech Codecs 8 Status of This Memo 10 By submitting this Internet-Draft, we certify that any applicable 11 patent or other IPR claims of which we are aware have been 12 disclosed, or will be disclosed, and any of which we become aware 13 will be disclosed, in accordance with RFC 3668. 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 and the storage 34 format for the BroadVoice(TM) narrowband and wideband speech codecs 35 developed by Broadcom Corporation. The document also provides 36 specifications 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. Storage Format..................................................8 49 6. IANA Considerations.............................................9 50 6.1 MIME Registration of BroadVoice16...........................9 51 6.2 MIME Registration of BroadVoice32..........................10 52 7. Mapping to SDP Parameters......................................11 53 7.1 Offer-Answer Model Considerations..........................12 54 8. Security Considerations........................................12 55 9. Congestion Control.............................................12 56 10. Acknowledgments................................................13 57 11. References.....................................................13 58 11.1 Normative References......................................13 59 11.2 Informative References....................................13 60 12. Authors' Addresses.............................................14 61 13. RFC-Editor Consideration.......................................14 63 1. Introduction 65 This document specifies the payload format for sending BroadVoice 66 encoded speech or audio signals using the Real-time Transport 67 Protocol (RTP) [1]. The sender may send one or more BroadVoice 68 codec data frames per packet, depending on the application scenario, 69 based on network conditions, bandwidth availability, delay 70 requirements, and packet-loss tolerance. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 74 this document are to be interpreted as described in RFC 2119 [2]. 76 2. Background 78 BroadVoice is a speech codec family developed by Broadcom for VoIP 79 applications, including Voice over Cable, Voice over DSL, and IP 80 phone applications. BroadVoice achieves high speech quality with 81 a low coding delay and relatively 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 (Voice 109 over Internet Protocol) telephone services provided by cable 110 operators. More specifically, the BV16 codec was selected as one 111 of the mandatory audio codecs in PacketCable (TM) 1.5 Audio/Video 112 Codecs Specification [4]. 114 3. RTP Payload Format for BroadVoice16 Narrowband Codec 116 The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, 117 so the RTP timestamp MUST be in units of 1/8000 of a second. The 118 RTP timestamp indicates the sampling instant of the oldest audio 119 sample represented by the frame(s) present in the payload. The 120 RTP payload for the BroadVoice16 has the format shown in the figure 121 below. No additional header specific to this payload format is 122 required. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | RTP Header [1] | 128 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 129 | | 130 | one or more frames of BroadVoice16 | 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 If BroadVoice16 is used for applications with silence compression, 134 the first BroadVoice16 packet after a silence period during which 135 packets have not been transmitted contiguously, SHOULD have the 136 marker bit in the RTP data header set to one. The marker bit 137 in all other packets is zero. Applications without silence 138 suppression MUST set the marker bit to zero. 140 The assignment of an RTP payload type for this new packet format is 141 outside the scope of this document, and will not be specified here. 142 It is expected that the RTP profile for a particular class of 143 applications will assign a payload type for this encoding, or if 144 that is not done then a payload type in the dynamic range shall be 145 chosen. 147 3.1 BroadVoice16 Bit Stream Definition 149 The BroadVoice16 encoder operates on speech frames of 5 ms 150 corresponding to 40 samples at a sampling rate of 8000 samples per 151 second. For every 5 ms frame, the encoder encodes the 40 152 consecutive audio samples into 80 bits, or 10 octets. Thus, the 153 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame 154 is octet-aligned, and no padding bits are required. The bit 155 allocation for the encoded parameters of the BroadVoice16 codec 156 is listed in the following table. 158 Encoded Parameter Codeword Number of bits per frame 159 ------------------------------------------------------------ 160 Line Spectrum Pairs L0,L1 7+7=14 161 Pitch Lag PL 7 162 Pitch Gain PG 5 163 Log-Gain LG 4 164 Excitation Vectors V0,...,V9 5*10=50 165 ------------------------------------------------------------ 166 Total: 80 bits 168 The mapping of the encoded parameters in an 80-bit BroadVoice16 data 169 frame is defined in the following figure. This figure shows the bit 170 packing in "network byte order", also known as big-endian order. 171 The bits of each 32-bit word are numbered 0 to 31, with the most 172 significant bit on the left and numbered 0. The octets (bytes) of 173 each word are transmitted most significant octet first. The bits of 174 data field for each encoded parameter are numbered in the same 175 order, with the most significant bit on the left. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | L0 | L1 | PL | PG | LG | V0| 182 | | | | | | | 183 |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| 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | V0 | V1 | V2 | V3 | V4 | V5 | V6 | 186 | | | | | | | | 187 |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| 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |V| V7 | V8 | V9 | 190 |6| | | | 191 |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: BroadVoice16 bit packing 196 3.2 Multiple BroadVoice16 Frames in an RTP Packet 198 More than one BroadVoice16 frame MAY be included in a single RTP 199 packet by a sender. Senders have the following additional 200 restrictions: 202 o SHOULD NOT include more BroadVoice16 frames in a single RTP 203 packet than will fit in the MTU of the RTP transport protocol. 205 o MUST NOT split a BroadVoice16 frame between RTP packets. 207 o BroadVoice16 frames in an RTP packet MUST be consecutive. 209 Since multiple BroadVoice16 frames in an RTP packet MUST be 210 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 211 recovering the timestamps of all frames within a packet is easy. 212 The oldest frame within an RTP packet has the same timestamp as the 213 RTP packet, as mentioned above. To obtain the timestamp of the 214 frame that is N frames later than the oldest frame in the packet, 215 one simply adds 5*N ms worth of time units to the timestamp of the 216 RTP packet. 218 It is RECOMMENDED that the number of frames contained within an RTP 219 packet is consistent with the application. For example, in a 220 telephony application where delay is important, the fewer frames per 221 packet the lower the delay, whereas for a delay insensitive 222 streaming or messaging application, many frames per packet would be 223 acceptable. 225 Information describing the number of frames contained in an RTP 226 packet is not transmitted as part of the RTP payload. The only way 227 to determine the number of BroadVoice16 frames is to count the total 228 number of octets within the RTP payload, and divide the octet count 229 by 10. 231 4. RTP Payload Format for BroadVoice32 Wideband Codec 233 The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 234 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. 235 The RTP timestamp indicates the sampling instant of the oldest 236 audio sample represented by the frame(s) present in the payload. 237 The RTP payload for the BroadVoice32 has the format shown in the 238 figure below. No additional header specific to this payload format 239 is required. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | RTP Header [1] | 245 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 246 | | 247 | one or more frames of BroadVoice32 | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 If BroadVoice32 is used for applications with silence compression, 252 the first BroadVoice32 packet after a silence period during which 253 packets have not been transmitted contiguously, SHOULD have the 254 marker bit in the RTP data header set to one. The marker bit 255 in all other packets is zero. Applications without silence 256 suppression MUST set the marker bit to zero. 258 The assignment of an RTP payload type for this new packet format is 259 outside the scope of this document, and will not be specified here. 260 It is expected that the RTP profile for a particular class of 261 applications will assign a payload type for this encoding, or if 262 that is not done then a payload type in the dynamic range shall be 263 chosen. 265 4.1 BroadVoice32 Bit Stream Definition 267 The BroadVoice32 encoder operates on speech frames of 5 ms 268 corresponding to 80 samples at a sampling rate of 16000 samples per 269 second. For every 5 ms frame, the encoder encodes the 80 270 consecutive audio samples into 160 bits, or 20 octets. Thus, the 271 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame 272 is octet-aligned, and no padding bits are required. The bit 273 allocation for the encoded parameters of the BroadVoice32 codec 274 is listed in the following table. 275 Number of bits 276 Encoded Parameter Codeword per frame 277 --------------------------------------------------------------- 278 Line Spectrum Pairs L0,L1,L2 7+5+5=17 279 Pitch Lag PL 8 280 Pitch Gain PG 5 281 Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10 282 Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60 283 Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60 284 --------------------------------------------------------------- 285 Total: 160 bits 287 The mapping of the encoded parameters in a 160-bit BroadVoice32 data 288 frame is defined in the following figure. This figure shows the bit 289 packing in "network byte order", also known as big-endian order. 290 The bits of each 32-bit word are numbered 0 to 31, with the most 291 significant bit on the left and numbered 0. The octets (bytes) of 292 each word are transmitted most significant octet first. The bits of 293 data field for each encoded parameter are numbered in the same 294 order, with the most significant bit on the left. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | L0 | L1 | L2 | PL | PG |LG0| 300 | | | | | | | 301 |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| 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | LG0 | LG1 | VA0 | VA1 | VA2 | VA3 | 304 | | | | | | | 305 |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| 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | VA4 | VA5 | VA6 | VA7 | VA8 |VA9| 308 | | | | | | | 309 |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| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | VA9 | VB0 | VB1 | VB2 | VB3 | VB4 | 312 | | | | | | | 313 |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| 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |VB4| VB5 | VB6 | VB7 | VB8 | VB9 | 316 | | | | | | | 317 |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| 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 2: BroadVoice32 bit packing 322 4.2 Multiple BroadVoice32 Frames in an RTP Packet 324 More than one BroadVoice32 frame MAY be included in a single RTP 325 packet by a sender. Senders have the following additional 326 restrictions: 328 o SHOULD NOT include more BroadVoice32 frames in a single RTP 329 packet than will fit in the MTU of the RTP transport protocol. 331 o MUST NOT split a BroadVoice32 frame between RTP packets. 333 o BroadVoice32 frames in an RTP packet MUST be consecutive. 335 Since multiple BroadVoice32 frames in an RTP packet MUST be 336 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 337 recovering the timestamps of all frames within a packet is easy. 338 The oldest frame within an RTP packet has the same timestamp as the 339 RTP packet, as mentioned above. To obtain the timestamp of the 340 frame that is N frames later than the oldest frame in the packet, 341 one simply adds 5*N ms worth of time units to the timestamp of the 342 RTP packet. 344 It is RECOMMENDED that the number of frames contained within an RTP 345 packet is consistent with the application. For example, in a 346 telephony application where delay is important, the fewer frames per 347 packet the lower the delay, whereas for a delay insensitive 348 streaming or messaging application, many frames per packet would be 349 acceptable. 351 Information describing the number of frames contained in an RTP 352 packet is not transmitted as part of the RTP payload. The only way 353 to determine the number of BroadVoice32 frames is to count the total 354 number of octets within the RTP payload, and divide the octet count 355 by 20. 357 5. Storage Format 359 The storage format is used for storing speech frames, e.g., as a 360 file or e-mail attachment. 362 The file begins with a header that includes only a magic number to 363 identify the codec that is used. The magic number for the 364 BroadVoice16 narrowband codec MUST correspond to the ASCII character 365 string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in 366 hexadecimal format. The magic number for the BroadVoice32 wideband 367 codec MUST correspond to the ASCII character string "#!BV32\n", or 368 "0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded 369 bit stream of either BroadVoice16 or BroadVoice32, but not both. In 370 other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be 371 mixed in the same file. 373 After the header that contains the magic number identifying the 374 codec used, the encoded codec data frames are stored in a sequential 375 order, as shown below. All encoded codec data frames must be 376 present, otherwise synchronization problems will arise. 378 +--------+---------------+---------------+-----+---------------+ 379 | Header | Codec frame 1 | Codec frame 2 | ... | Codec frame N | 380 +--------+---------------+---------------+-----+---------------+ 382 6. IANA Considerations 384 Two new MIME sub-types as described in this section are to be 385 registered. 387 The MIME names for the BV16 and BV32 codecs are to be allocated from 388 the IETF tree since these two codecs are expected to be widely used 389 for Voice-over-IP applications, especially in Voice over Cable 390 applications. 392 6.1 MIME Registration of BroadVoice16 for RTP 394 MIME media type name: audio 396 MIME media subtype name: BV16 398 Required parameter: none 400 Optional parameters: 401 The following parameters apply to RTP transfer only. 403 ptime: Defined as usual for RTP audio (see RFC 2327 [5]). 405 maxptime: See RFC 2327 [5] for its definition. The maxptime 406 SHOULD be a multiple of the duration of a single codec data 407 frame (5 ms). 409 Encoding considerations: 410 This type is defined for transfer of BV16-encoded data via RTP 411 using the payload format specified in Sections 3 of RFC XXXX. 412 It is also defined for other transfer methods using the storage 413 format specified in Section 5 of RFC XXXX. Audio data is binary 414 data, and must be encoded for non-binary transport; the Base64 415 encoding is suitable for Email. 417 Security considerations: 418 See Section 8 "Security Considerations" of RFC XXXX. 420 Public specification: 421 The BroadVoice16 codec has been specified in [3]. 423 Additional information: 424 The following information applies to storage format only. 426 Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21 427 0x42 0x56 0x31 0x36 0x0A" in hexadecimal) 429 File extensions: bvn, BVN (stands for "BroadVoice, Narrowband") 431 Macintosh file type code: none 433 Object identifier or OID: none 435 Intended usage: 436 COMMON. It is expected that many VoIP applications, especially 437 Voice over Cable applications, will use this type. 439 Person & email address to contact for further information: 440 Juin-Hwey (Raymond) Chen 441 rchen@broadcom.com 443 Author/Change controller: 444 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 445 Change Controller: IETF Audio/Video Transport Working Group 446 delegated from the IESG 448 6.2 MIME Registration of BroadVoice32 for RTP 450 MIME media type name: audio 452 MIME media subtype name: BV32 454 Required parameter: none 456 Optional parameters: 457 The following parameters apply to RTP transfer only. 459 ptime: Defined as usual for RTP audio (see RFC 2327 [5]). 461 maxptime: See RFC 2327 [5] for its definition. The maxptime 462 SHOULD be a multiple of the duration of a single codec data 463 frame (5 ms). 465 Encoding considerations: 466 This type is defined for transfer of BV32-encoded data via RTP 467 using the payload format specified in Sections 4 of RFC XXXX. 468 It is also defined for other transfer methods using the storage 469 format specified in Section 5 of RFC XXXX. Audio data is binary 470 data, and must be encoded for non-binary transport; the Base64 471 encoding is suitable for Email. 473 Security considerations: 474 See Section 8 "Security Considerations" of RFC XXXX. 476 Additional information: 477 The following information applies to storage format only. 479 Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21 480 0x42 0x56 0x33 0x32 0x0A" in hexadecimal) 482 File extensions: bvw, BVW (stands for "BroadVoice, Wideband") 484 Macintosh file type code: none 486 Object identifier or OID: none 488 Intended usage: 489 COMMON. It is expected that many VoIP applications, especially 490 Voice over Cable applications, will use this type. 492 Person & email address to contact for further information: 493 Juin-Hwey (Raymond) Chen 494 rchen@broadcom.com 496 Author/Change controller: 497 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 498 Change Controller: IETF Audio/Video Transport Working Group 499 delegated from the IESG 501 7. Mapping to SDP Parameters 503 The information carried in the MIME media type specification has a 504 specific mapping to fields in the Session Description Protocol (SDP) 505 [5], which is commonly used to describe RTP sessions. When SDP is 506 used to specify sessions employing the BroadVoice16 or BroadVoice32 507 codec, the mapping is as follows: 509 - The MIME type ("audio") goes in SDP "m=" as the media name. 511 - The MIME subtype (payload format name) goes in SDP "a=rtpmap" 512 as the encoding name. The RTP clock rate in "a=rtpmap" MUST 513 be 8000 for BV16 and 16000 for BV32. 515 - The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 516 and "a=maxptime" attributes, respectively. 518 An example of the media representation in SDP for describing BV16 519 might be: 521 m=audio 49120 RTP/AVP 97 522 a=rtpmap:97 BV16/8000 524 An example of the media representation in SDP for describing BV32 525 might be: 527 m=audio 49122 RTP/AVP 99 528 a=rtpmap:99 BV32/16000 530 7.1 Offer-Answer Model Considerations 532 No special considerations are need for using the SDP Offer/Answer 533 model [6] with the BV16 and BV32 RTP payload formats. 535 8. Security Considerations 537 RTP packets using the payload format defined in this specification 538 are subject to the security considerations discussed in the RTP 539 specification [1] and any appropriate profile (for example, [7]). 540 This implies that confidentiality of the media streams is achieved 541 by encryption. Because the data compression used with this payload 542 format is applied end-to-end, encryption may be performed after 543 compression so there is no conflict between the two operations. 545 A potential denial-of-service threat exists for data encoding using 546 compression techniques that have non-uniform receiver-end 547 computational load. The attacker can inject pathological datagrams 548 into the stream which are complex to decode and cause the receiver 549 to become overloaded. However, the encodings covered in this 550 document do not exhibit any significant non-uniformity. 552 9. Congestion Control 554 The general congestion control considerations for transporting RTP 555 data apply to BV16 and BV32 audio over RTP as well, see RTP [1] 556 and any applicable RTP profile like AVP [7]. BV16 and BV32 do not 557 have any built-in mechanism for reducing the bandwidth. Packing 558 more frames in each RTP payload can reduce the number of packets 559 sent and hence the overhead from IP/UDP/RTP headers, at the 560 expense of increased delay and reduced error robustness against 561 packet losses. 563 10. Acknowledgments 565 The authors would like to thank Magnus Westerlung, Colin Perkins, 566 Allison Mankin, and Jean-Francois Mule for their review of this 567 document. 569 11. References 571 11.1 Normative References 573 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 574 A Transport Protocol for Real-Time Applications", STD 64, 575 RFC 3550, Internet Engineering Task Force, July 2003. 577 [2] S. Bradner, "Key words for use in RFCs to Indicate requirement 578 Levels", BCP 14, RFC 2119, Internet Engineering Task Force, 579 March 1997. 581 [3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech 582 Codec Specification, Revision 1.2, October 30, 2003. 584 [5] M. Handley and V. Jacobson, "SDP: Session Description 585 Protocol", RC 2327, April 1998. 587 [6] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with 588 the Session Description Protocol (SDP)", RFC 3264, Internet 589 Engineering Task Force, June 2002. 591 [7] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 592 Conferences with Minimal Control", STD 65, RFC 3551, Internet 593 Engineering Task Force, July 2003. 595 11.2 Informative References 597 [4] Cable Television Laboratories, Inc., PacketCable(TM) 1.5 598 Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128, 599 January 28, 2005. 600 http://www.cablelabs.com/specifications/archives/ 602 12. Authors' Addresses 604 Juin-Hwey (Raymond) Chen 605 Broadcom Corporation 606 Room A3032 607 16215 Alton Parkway 608 Irvine, CA 92618 609 USA 610 Phone: +1 949 926 6288 611 Email: rchen@broadcom.com 613 Winnie Lee 614 Broadcom Corporation 615 Room A2012E 616 200-13711 International Place 617 Richmond, British Columbia V6V 2Z8 618 Canada 619 Phone: +1 604 233 8605 620 Email: wlee@broadcom.com 622 Jes Thyssen 623 Broadcom Corporation 624 Room A3053 625 16215 Alton Parkway 626 Irvine, CA 92618 627 USA 628 Phone: +1 949 926 5768 629 Email: jthyssen@broadcom.com 631 13. RFC-Editor Consideration 633 The RFC-editor is kindly requested to perform the following 634 modifications upon the publication of this specification: 636 - Replace all occurrences of RFC XXXX with the RFC number this 637 specification receives when being published. 639 - Remove this Section. 641 Expires: August 17, 2005 643 Copyright (C) The Internet Society (2005). This document is subject 644 to the rights, licenses and restrictions contained in BCP 78, and 645 except as set forth therein, the authors retain all their rights. 647 This document and the information contained herein are provided on an 648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 650 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 651 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 652 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 655 The IETF takes no position regarding the validity or scope of any 656 Intellectual Property Rights or other rights that might be claimed to 657 pertain to the implementation or use of the technology described in 658 this document or the extent to which any license under such rights 659 might or might not be available; nor does it represent that it has 660 made any independent effort to identify any such rights. Information 661 on the procedures with respect to rights in RFC documents can be 662 found in BCP 78 and BCP 79. 664 Copies of IPR disclosures made to the IETF Secretariat and any 665 assurances of licenses to be made available, or the result of an 666 attempt made to obtain a general license or permission for the use 667 of such proprietary rights by implementers or users of this 668 specification can be obtained from the IETF on-line IPR repository 669 at http://www.ietf.org/ipr. 671 The IETF invites any interested party to bring to its attention 672 any copyrights, patents or patent applications, or other 673 proprietary rights that may cover technology that may be required 674 to implement this standard. Please address the information to the 675 IETF at ietf-ipr@ietf.org.