idnits 2.17.1 draft-ietf-avt-rtp-bv-02.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 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-20 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 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-02.txt Winnie Lee 3 December 7, 2004 Jes Thyssen 4 Expires: June 7, 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. Normative References...........................................13 57 10.1 Informative References....................................13 58 11. Authors' Addresses.............................................13 60 1. Introduction 62 This document specifies the payload format for sending BroadVoice 63 encoded speech or audio signals using the Real-time Transport 64 Protocol (RTP) [1]. The sender may send one or more BroadVoice 65 codec data frames per packet, depending on the application scenario, 66 based on network conditions, bandwidth availability, delay 67 requirements, and packet-loss tolerance. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 71 this document are to be interpreted as described in RFC 2119 [2]. 73 2. Background 75 BroadVoice is a speech codec family developed by Broadcom for VoIP 76 applications, including Voice over Cable, Voice over DSL, and IP 77 phone applications. BroadVoice achieves high speech quality with 78 a low coding delay and relatively low codec complexity. 80 The BroadVoice codec family contains two codec versions. The 81 narrowband version of BroadVoice, called BroadVoice16 [3], or BV16 82 for short, encodes 8 kHz-sampled narrowband speech at a bit rate of 83 16 kilobits/second, or 16 kbit/s. The wideband version of 84 BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled 85 wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use 86 very similar (but not identical) coding algorithms; they share most 87 of their algorithm modules. 89 To minimize the delay in real-time two-way communications, both the 90 BV16 and BV32 encode speech with a very small frame size of 5 ms 91 without using any look ahead. This allows VoIP systems based on 92 BroadVoice to have a very low end-to-end system delay, by using a 93 packet size as small as 5 ms if necessary. 95 BroadVoice also has relatively low codec complexity when compared 96 with ITU-T standard speech codecs based on CELP (Coded Excited 97 Linear Prediction), such as G.728, G.729, G.723.1, G.722.2, etc. 98 Full-duplex implementations of the BV16 and BV32 take around 12 and 99 17 MIPS, respectively, on general-purpose 16-bit fixed-point DSPs. 100 The total memory footprints of the BV16 and BV32, including program 101 size, data tables, and data RAM, are around 12 kwords each, or 24 102 kbytes. 104 The BV16 codec was standardized by Cable Television Laboratories, 105 Inc. (CableLabs) as a standard codec for use in VoIP (Voice over 106 Internet Protocol) telephone services provided by cable operators. 107 More specifically, the BV16 codec was selected as one of the 108 mandatory audio codecs in PacketCable (TM) 1.1 Audio/Video Codecs 109 Specification [4]. 111 3. RTP Payload Format for BroadVoice16 Narrowband Codec 113 The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, 114 so the RTP timestamp MUST be in units of 1/8000 of a second. The 115 RTP timestamp indicates the sampling instant of the oldest audio 116 sample represented by the frame(s) present in the payload. The 117 RTP payload for the BroadVoice16 has the format shown in the figure 118 below. No additional header specific to this payload format is 119 required. 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | RTP Header [1] | 125 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 126 | | 127 | one or more frames of BroadVoice16 | 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 If BroadVoice16 is used for applications with silence compression, 131 the first BroadVoice16 packet after a silence period during which 132 packets have not been transmitted contiguously, SHOULD have the 133 marker bit in the RTP data header set to one. The marker bit 134 in all other packets is zero. Applications without silence 135 suppression MUST set the marker bit to zero. 137 The assignment of an RTP payload type for this new packet format is 138 outside the scope of this document, and will not be specified here. 139 It is expected that the RTP profile for a particular class of 140 applications will assign a payload type for this encoding, or if 141 that is not done then a payload type in the dynamic range shall be 142 chosen. 144 3.1 BroadVoice16 Bit Stream Definition 146 The BroadVoice16 encoder operates on speech frames of 5 ms 147 corresponding to 40 samples at a sampling rate of 8000 samples per 148 second. For every 5 ms frame, the encoder encodes the 40 149 consecutive audio samples into 80 bits, or 10 octets. Thus, the 150 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame 151 is octet-aligned, and no padding bits are required. The bit 152 allocation for the encoded parameters of the BroadVoice16 codec 153 is listed in the following table. 155 Encoded Parameter Codeword Number of bits per frame 156 ------------------------------------------------------------ 157 Line Spectrum Pairs L0,L1 7+7=14 158 Pitch Lag PL 7 159 Pitch Gain PG 5 160 Log-Gain LG 4 161 Excitation Vectors V0,...,V9 5*10=50 162 ------------------------------------------------------------ 163 Total: 80 bits 165 The mapping of the encoded parameters in an 80-bit BroadVoice16 data 166 frame is defined in the following figure. This figure shows the bit 167 packing in "network byte order", also known as big-endian order. 168 The bits of each 32-bit word are numbered 0 to 31, with the most 169 significant bit on the left and numbered 0. The octets (bytes) of 170 each word are transmitted most significant octet first. The bits of 171 data field for each encoded parameter are numbered in the same 172 order, with the most significant bit on the left. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | L0 | L1 | PL | PG | LG | V0| 179 | | | | | | | 180 |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| 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | V0 | V1 | V2 | V3 | V4 | V5 | V6 | 183 | | | | | | | | 184 |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| 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |V| V7 | V8 | V9 | 187 |6| | | | 188 |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: BroadVoice16 bit packing 193 3.2 Multiple BroadVoice16 Frames in an RTP Packet 195 More than one BroadVoice16 frame MAY be included in a single RTP 196 packet by a sender. Senders have the following additional 197 restrictions: 199 o SHOULD NOT include more BroadVoice16 frames in a single RTP 200 packet than will fit in the MTU of the RTP transport protocol. 202 o MUST NOT split a BroadVoice16 frame between RTP packets. 204 o BroadVoice16 frames in an RTP packet MUST be consecutive. 206 Since multiple BroadVoice16 frames in an RTP packet MUST be 207 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 208 recovering the timestamps of all frames within a packet is easy. 209 The oldest frame within an RTP packet has the same timestamp as the 210 RTP packet, as mentioned above. To obtain the timestamp of the 211 frame that is N frames later than the oldest frame in the packet, 212 one simply adds 5*N ms worth of time units to the timestamp of the 213 RTP packet. 215 It is RECOMMENDED that the number of frames contained within an RTP 216 packet is consistent with the application. For example, in a 217 telephony application where delay is important, the fewer frames per 218 packet the lower the delay, whereas for a delay insensitive 219 streaming or messaging application, many frames per packet would be 220 acceptable. 222 Information describing the number of frames contained in an RTP 223 packet is not transmitted as part of the RTP payload. The only way 224 to determine the number of BroadVoice16 frames is to count the total 225 number of octets within the RTP payload, and divide the octet count 226 by 10. 228 4. RTP Payload Format for BroadVoice32 Wideband Codec 230 The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 231 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. 232 The RTP timestamp indicates the sampling instant of the oldest 233 audio sample represented by the frame(s) present in the payload. 234 The RTP payload for the BroadVoice32 has the format shown in the 235 figure below. No additional header specific to this payload format 236 is required. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | RTP Header [1] | 242 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 243 | | 244 | one or more frames of BroadVoice32 | 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 If BroadVoice32 is used for applications with silence compression, 249 the first BroadVoice32 packet after a silence period during which 250 packets have not been transmitted contiguously, SHOULD have the 251 marker bit in the RTP data header set to one. The marker bit 252 in all other packets is zero. Applications without silence 253 suppression MUST set the marker bit to zero. 255 The assignment of an RTP payload type for this new packet format is 256 outside the scope of this document, and will not be specified here. 257 It is expected that the RTP profile for a particular class of 258 applications will assign a payload type for this encoding, or if 259 that is not done then a payload type in the dynamic range shall be 260 chosen. 262 4.1 BroadVoice32 Bit Stream Definition 264 The BroadVoice32 encoder operates on speech frames of 5 ms 265 corresponding to 80 samples at a sampling rate of 16000 samples per 266 second. For every 5 ms frame, the encoder encodes the 80 267 consecutive audio samples into 160 bits, or 20 octets. Thus, the 268 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame 269 is octet-aligned, and no padding bits are required. The bit 270 allocation for the encoded parameters of the BroadVoice32 codec 271 is listed in the following table. 272 Number of bits 273 Encoded Parameter Codeword per frame 274 --------------------------------------------------------------- 275 Line Spectrum Pairs L0,L1,L2 7+5+5=17 276 Pitch Lag PL 8 277 Pitch Gain PG 5 278 Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10 279 Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60 280 Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60 281 --------------------------------------------------------------- 282 Total: 160 bits 284 The mapping of the encoded parameters in a 160-bit BroadVoice32 data 285 frame is defined in the following figure. This figure shows the bit 286 packing in "network byte order", also known as big-endian order. 287 The bits of each 32-bit word are numbered 0 to 31, with the most 288 significant bit on the left and numbered 0. The octets (bytes) of 289 each word are transmitted most significant octet first. The bits of 290 data field for each encoded parameter are numbered in the same 291 order, with the most significant bit on the left. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | L0 | L1 | L2 | PL | PG |LG0| 297 | | | | | | | 298 |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| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | LG0 | LG1 | VA0 | VA1 | VA2 | VA3 | 301 | | | | | | | 302 |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| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | VA4 | VA5 | VA6 | VA7 | VA8 |VA9| 305 | | | | | | | 306 |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| 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | VA9 | VB0 | VB1 | VB2 | VB3 | VB4 | 309 | | | | | | | 310 |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| 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |VB4| VB5 | VB6 | VB7 | VB8 | VB9 | 313 | | | | | | | 314 |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| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2: BroadVoice32 bit packing 319 4.2 Multiple BroadVoice32 Frames in an RTP Packet 321 More than one BroadVoice32 frame MAY be included in a single RTP 322 packet by a sender. Senders have the following additional 323 restrictions: 325 o SHOULD NOT include more BroadVoice32 frames in a single RTP 326 packet than will fit in the MTU of the RTP transport protocol. 328 o MUST NOT split a BroadVoice32 frame between RTP packets. 330 o BroadVoice32 frames in an RTP packet MUST be consecutive. 332 Since multiple BroadVoice32 frames in an RTP packet MUST be 333 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 334 recovering the timestamps of all frames within a packet is easy. 335 The oldest frame within an RTP packet has the same timestamp as the 336 RTP packet, as mentioned above. To obtain the timestamp of the 337 frame that is N frames later than the oldest frame in the packet, 338 one simply adds 5*N ms worth of time units to the timestamp of the 339 RTP packet. 341 It is RECOMMENDED that the number of frames contained within an RTP 342 packet is consistent with the application. For example, in a 343 telephony application where delay is important, the fewer frames per 344 packet the lower the delay, whereas for a delay insensitive 345 streaming or messaging application, many frames per packet would be 346 acceptable. 348 Information describing the number of frames contained in an RTP 349 packet is not transmitted as part of the RTP payload. The only way 350 to determine the number of BroadVoice32 frames is to count the total 351 number of octets within the RTP payload, and divide the octet count 352 by 20. 354 5. Storage Format 356 The storage format is used for storing speech frames, e.g., as a 357 file or e-mail attachment. 359 The file begins with a header that includes only a magic number to 360 identify the codec that is used. The magic number for the 361 BroadVoice16 narrowband codec MUST correspond to the ASCII character 362 string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in 363 hexadecimal format. The magic number for the BroadVoice32 wideband 364 codec MUST correspond to the ASCII character string "#!BV32\n", or 365 "0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded 366 bit stream of either BroadVoice16 or BroadVoice32, but not both. In 367 other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be 368 mixed in the same file. 370 After the header that contains the magic number identifying the 371 codec used, the encoded codec data frames are stored in a sequential 372 order, as shown below. All encoded codec data frames must be 373 present, otherwise synchronization problems will arise. 375 +--------+---------------+---------------+-----+---------------+ 376 | Header | Codec frame 1 | Codec frame 2 | ... | Codec frame N | 377 +--------+---------------+---------------+-----+---------------+ 379 6. IANA Considerations 381 Two new MIME sub-types as described in this section are to be 382 registered. 384 The MIME names for the BV16 and BV32 codecs are to be allocated from 385 the IETF tree since these two codecs are expected to be widely used 386 for Voice-over-IP applications, especially in Voice over Cable 387 applications. 389 6.1 MIME Registration of BroadVoice16 for RTP 391 MIME media type name: audio 393 MIME media subtype name: BV16 395 Required parameter: none 397 Optional parameters: 398 The following parameters apply to RTP transfer only. 400 ptime: Defined as usual for RTP audio (see RFC YYYY [5]). 402 maxptime: See RFC YYYY [5] for its definition. The maxptime 403 SHOULD be a multiple of the duration of a single codec data 404 frame (5 ms). ). 406 Encoding considerations: 407 This type is defined for transfer of BV16-encoded data via RTP 408 using the payload format specified in Sections 3 of RFC xxxx. 409 It is also defined for other transfer methods using the storage 410 format specified in Section 5 of RFC xxxx. Audio data is binary 411 data, and must be encoded for non-binary transport; the Base64 412 encoding is suitable for Email. 414 Security considerations: 415 See Section 8 "Security Considerations" of RFC xxxx. 417 Public specification: 418 The BroadVoice16 codec has been specified in [3]. 420 Additional information: 421 The following information applies to storage format only. 423 Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21 424 0x42 0x56 0x31 0x36 0x0A" in hexadecimal) 426 File extensions: bvn, BVN (stands for "BroadVoice, Narrowband") 428 Macintosh file type code: none 430 Object identifier or OID: none 432 Intended usage: 433 COMMON. It is expected that many VoIP applications, especially 434 Voice over Cable applications, will use this type. 436 Person & email address to contact for further information: 437 Juin-Hwey (Raymond) Chen 438 rchen@broadcom.com 440 Author/Change controller: 441 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 442 Change Controller: IETF Audio/Video Transport Working Group 443 delegated from the IESG 445 6.2 MIME Registration of BroadVoice32 for RTP 447 MIME media type name: audio 449 MIME media subtype name: BV32 451 Required parameter: none 453 Optional parameters: 454 The following parameters apply to RTP transfer only. 456 ptime: Defined as usual for RTP audio (see RFC YYYY [5]). 458 maxptime: See RFC YYYY [5] for its definition. The maxptime 459 SHOULD be a multiple of the duration of a single codec data 460 frame (5 ms). 462 Encoding considerations: 463 This type is defined for transfer of BV32-encoded data via RTP 464 using the payload format specified in Sections 4 of RFC xxxx. 465 It is also defined for other transfer methods using the storage 466 format specified in Section 5 of RFC xxxx. Audio data is binary 467 data, and must be encoded for non-binary transport; the Base64 468 encoding is suitable for Email. 470 Security considerations: 471 See Section 8 "Security Considerations" of RFC xxxx . 473 Additional information: 474 The following information applies to storage format only. 476 Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21 477 0x42 0x56 0x33 0x32 0x0A" in hexadecimal) 479 File extensions: bvw, BVW (stands for "BroadVoice, Wideband") 481 Macintosh file type code: none 483 Object identifier or OID: none 485 Intended usage: 486 COMMON. It is expected that many VoIP applications, especially 487 Voice over Cable applications, will use this type. 489 Person & email address to contact for further information: 490 Juin-Hwey (Raymond) Chen 491 rchen@broadcom.com 493 Author/Change controller: 494 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 495 Change Controller: IETF Audio/Video Transport Working Group 496 delegated from the IESG 498 7. Mapping to SDP Parameters 500 The information carried in the MIME media type specification has a 501 specific mapping to fields in the Session Description Protocol (SDP) 502 [5], which is commonly used to describe RTP sessions. When SDP is 503 used to specify sessions employing the BroadVoice16 or BroadVoice32 504 codec, the mapping is as follows: 506 - The MIME type ("audio") goes in SDP "m=" as the media name. 508 - The MIME subtype (payload format name) goes in SDP "a=rtpmap" 509 as the encoding name. The RTP clock rate in "a=rtpmap" MUST 510 be 8000 for BV16 and 16000 for BV32. 512 - The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 513 and "a=maxptime" attributes, respectively. 515 An example of the media representation in SDP for describing BV16 516 might be: 518 m=audio 49120 RTP/AVP 97 519 a=rtpmap:97 BV16/8000 521 An example of the media representation in SDP for describing BV32 522 might be: 524 m=audio 49122 RTP/AVP 99 525 a=rtpmap:99 BV32/16000 527 7.1 Offer-Answer Model Considerations 529 No special considerations are need for using the SDP Offer/Answer 530 model [6] with the BV16 and BV32 RTP payload formats. 532 8. Security Considerations 534 RTP packets using the payload format defined in this specification 535 are subject to the security considerations discussed in the RTP 536 specification [1] and any appropriate profile (for example, [7]). 537 This implies that confidentiality of the media streams is achieved 538 by encryption. Because the data compression used with this payload 539 format is applied end-to-end, encryption may be performed after 540 compression so there is no conflict between the two operations. 542 A potential denial-of-service threat exists for data encoding using 543 compression techniques that have non-uniform receiver-end 544 computational load. The attacker can inject pathological datagrams 545 into the stream which are complex to decode and cause the receiver 546 to become overloaded. However, the encodings covered in this 547 document do not exhibit any significant non-uniformity. 549 9. Congestion Control 551 The general congestion control considerations for transporting RTP 552 data apply to BV16 and BV32 audio over RTP as well, see RTP [1] 553 and any applicable RTP profile like AVP [7]. BV16 and BV32 do not 554 have any built-in mechanism for reducing the bandwidth. Packing 555 more frames in each RTP payload can reduce the number of packets 556 sent and hence the overhead from IP/UDP/RTP headers, at the 557 expense of increased delay and reduced error robustness against 558 packet losses. 560 10. Normative References 562 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 563 A Transport Protocol for Real-Time Applications", STD 64, 564 RFC 3550, Internet Engineering Task Force, July 2003. 566 [2] S. Bradner, "Key words for use in RFCs to Indicate requirement 567 Levels", BCP 14, RFC 2119, Internet Engineering Task Force, 568 March 1997. 570 [3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech 571 Codec Specification, Revision 1.2, October 30, 2003. 573 [5] M. Handley et al., "SDP: Session Description Protocol", 574 draft-ietf-mmusic-sdp-new-20.txt, September 2004. 576 [6] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with 577 the Session Description Protocol (SDP)", RFC 3264, Internet 578 Engineering Task Force, June 2002. 580 [7] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 581 Conferences with Minimal Control", STD 65, RFC 3551, Internet 582 Engineering Task Force, July 2003. 584 10.1 Informative References 586 [4] Cable Television Laboratories, Inc., PacketCable(TM) 1.1 587 Audio/Video Codecs Specification, PKT-SP-CODEC 1.1-I01-040621, 588 June 21, 2004. 590 11. Authors' Addresses 592 Juin-Hwey (Raymond) Chen 593 Broadcom Corporation 594 Room A3032 595 16215 Alton Parkway 596 Irvine, CA 92618 597 USA 598 Phone: +1 949 926 6288 599 Email: rchen@broadcom.com 601 Winnie Lee 602 Broadcom Corporation 603 Room A2012E 604 200-13711 International Place 605 Richmond, British Columbia V6V 2Z8 606 Canada 607 Phone: +1 604 233 8605 608 Email: wlee@broadcom.com 610 Expires: June 7, 2005 612 Jes Thyssen 613 Broadcom Corporation 614 Room A3053 615 16215 Alton Parkway 616 Irvine, CA 92618 617 USA 618 Phone: +1 949 926 5768 619 Email: jthyssen@broadcom.com 621 Copyright (C) The Internet Society (2004). This document is subject 622 to the rights, licenses and restrictions contained in BCP 78, and 623 except as set forth therein, the authors retain all their rights. 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 628 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 629 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 630 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use 645 of such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository 647 at http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention 650 any copyrights, patents or patent applications, or other 651 proprietary rights that may cover technology that may be required 652 to implement this standard. Please address the information to the 653 IETF at ietf-ipr@ietf.org.