idnits 2.17.1 draft-chen-rtp-bv-02.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 : ---------------------------------------------------------------------------- No issues found here. 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) == Missing Reference: '2' is mentioned on line 558, but not defined ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-14 ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1890 (ref. '6') (Obsoleted by RFC 3551) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Juin-Hwey Chen 2 draft-chen-rtp-bv-02.txt Cheng-Chieh Lee 3 November 20, 2003 Winnie Lee 4 Expires: May 20, 2004 Jes Thyssen 5 Broadcom Corporation 7 RTP Payload Format for BroadVoice Speech Codecs 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes the RTP payload format for the 32 BroadVoice(TM) narrowband and wideband speech codecs developed by 33 Broadcom Corporation. The document also provides specifications for 34 the use of BroadVoice with MIME and SDP. 36 Table of Contents 38 1. Introduction....................................................2 39 2. Background......................................................2 40 3. RTP Payload Format for BroadVoice16 Narrowband Codec............3 41 3.1 BroadVoice16 Bit Stream Definition..........................3 42 3.2 Multiple BroadVoice16 Frames in An RTP Packets..............4 43 4. RTP Payload Format for BroadVoice32 Wideband Codec..............5 44 4.1 BroadVoice32 Bit Stream Definition..........................5 45 4.2 Multiple BroadVoice32 Frames in An RTP Packet...............7 46 5. Storage Format..................................................7 47 6. IANA Considerations.............................................8 48 6.1 MIME registration of BroadVoice16...........................8 49 6.2 MIME registration of BroadVoice32...........................9 51 7. Mapping To SDP Parameters......................................10 52 8. Security Considerations........................................11 53 9. References.....................................................11 54 10. Authors' Addresses............................................11 56 1. Introduction 58 This document specifies the payload format for sending BroadVoice 59 encoded speech or audio signals using the Real-time Transport 60 Protocol (RTP) [1]. The sender may send one or more BroadVoice 61 codec data frames per packet, depending on the application scenario, 62 based on network conditions, bandwidth availability, delay 63 requirements, and packet-loss tolerance. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 67 this document are to be interpreted as described in RFC 2119 [2]. 69 2. Background 71 BroadVoice [3] is a speech codec family developed by Broadcom for 72 VoIP applications, including Voice over Cable, Voice over DSL, and 73 IP phone applications. BroadVoice achieves high speech quality with 74 a low coding delay and relatively low codec complexity. 76 The BroadVoice codec family contains two codec versions. The 77 narrowband version of BroadVoice, called BroadVoice16, or BV16 for 78 short, encodes 8 kHz-sampled narrowband speech at a bit rate of 79 16 kilobits/second, or 16 kbit/s. The wideband version of 80 BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled 81 wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use 82 very similar (but not identical) coding algorithms; they share most 83 of their algorithm modules. 85 To minimize the delay in real-time two-way communications, both the 86 BV16 and BV32 encode speech with a very small frame size of 5 ms 87 without using any look ahead. This allows VoIP systems based on 88 BroadVoice to have a very low end-to-end system delay, by using a 89 packet size as small as 5 ms if necessary. 91 BroadVoice also has relatively low codec complexity when compared 92 with other ITU-T standard speech codecs based on CELP (Coded Excited 93 Linear Prediction), such as G.728, G.729, G.723.1, G.722.2, etc. 94 Full-duplex implementations of the BV16 and BV32 take around 12 and 95 17 MIPS, respectively, on general-purpose 16-bit fixed-point DSPs. 96 The total memory footprints of the BV16 and BV32, including program 97 size, data tables, and data RAM, are around 12 kwords, or 24 kbytes. 99 3. RTP Payload Format for BroadVoice16 Narrowband Codec 101 The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, 102 so the RTP timestamp MUST be in units of 1/8000 of a second. The RTP 103 payload for the BroadVoice16 has the format shown in the figure 104 below. No additional header specific to this payload format is 105 required. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | RTP Header [1] | 111 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 112 | | 113 | one or more frames of BroadVoice16 | 114 | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 When more than one codec data frame is present in a single RTP 118 packet, the timestamp is, as always, that of the oldest data frame 119 represented in the RTP packet. 121 If BroadVoice16 is used for applications with silence compression, 122 the first BroadVoice16 packet after a silence period during which 123 packets have not been transmitted contiguously, SHOULD have the 124 marker bit in the RTP data header set to one. The marker bit 125 in all other packets is zero. Applications without silence 126 suppression MUST set the marker bit to zero. 128 The assignment of an RTP payload type for this new packet format is 129 outside the scope of this document, and will not be specified here. 130 It is expected that the RTP profile for a particular class of 131 applications will assign a payload type for this encoding, or if 132 that is not done then a payload type in the dynamic range shall be 133 chosen. 135 3.1 BroadVoice16 Bit Stream Definition 137 The BroadVoice16 encoder operates on speech frames of 5 ms 138 corresponding to 40 samples at a sampling rate of 8000 samples per 139 second. For every 5 ms frame, the encoder encodes the 40 140 consecutive audio samples into 80 bits, or 10 octets. Thus, the 141 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame 142 is octet-aligned, and no padding bits are required. The bit 143 allocation for the encoded parameters of the BroadVoice16 codec 144 is listed in the following table. 146 Encoded Parameter Codeword Number of bits per frame 147 ------------------------------------------------------------ 148 Line Spectrum Pairs L0,L1 7+7=14 149 Pitch Lag PL 7 150 Pitch Gain PG 5 151 Log-Gain LG 4 152 Excitation Vectors V0,...,V9 5*10=50 153 ------------------------------------------------------------ 154 Total: 80 bits 156 The mapping of the encoded parameters in an 80-bit BroadVoice16 data 157 frame is defined in the following figure. This figure shows the bit 158 packing in "network byte order", also known as big-endian order. 159 The bits of each 32-bit word are numbered 0 to 31, with the most 160 significant bit on the left and numbered 0. The octets (bytes) of 161 each word are transmitted most significant octet first. The bits of 162 data field for each encoded parameter are numbered in the same 163 order, with the most significant bit on the left. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | L0 | L1 | PL | PG | LG | V0| 169 | | | | | | | 170 |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| 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | V0 | V1 | V2 | V3 | V4 | V5 | V6 | 173 | | | | | | | | 174 |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| 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |V| V7 | V8 | V9 | 177 |6| | | | 178 |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 1: BroadVoice16 bit packing 183 3.2 Multiple BroadVoice16 Frames in An RTP Packet 185 More than one BroadVoice16 frame may be included in a single RTP 186 packet by a sender. Senders have the following additional 187 restrictions: 189 o SHOULD NOT include more BroadVoice16 frames in a single RTP 190 packet than will fit in the MTU of the RTP transport protocol. 192 o MUST NOT split a BroadVoice16 frame between RTP packets. 194 o BroadVoice16 frames in an RTP packet MUST be consecutive. 196 Since multiple BroadVoice16 frames in an RTP packet MUST be 197 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 198 recovering the timestamps of all frames within a packet is easy. 199 The oldest frame within an RTP packet has the same timestamp as the 200 RTP packet, as mentioned above. To obtain the timestamp of the 201 frame that is N frames order than the oldest frame in the packet, 202 one simply adds 5*N ms worth of time units to the timestamp of the 203 RTP packet. 205 It is RECOMMENDED that the number of frames contained within an RTP 206 packet is consistent with the application. For example, in a 207 telephony application where delay is important, the fewer frames per 208 packet the lower the delay, whereas for a delay insensitive 209 streaming or messaging application, many frames per packet would be 210 acceptable. 212 Information describing the number of frames contained in an RTP 213 packet is not transmitted as part of the RTP payload. The only way 214 to determine the number of BroadVoice16 frames is to count the total 215 number of octets within the RTP packet, and divide the octet count 216 by 10. 218 4. RTP Payload Format for BroadVoice32 Wideband Codec 220 The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 221 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. 222 The RTP payload for the BroadVoice32 has the format shown in the 223 figure below. No additional header specific to this payload format 224 is required. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | RTP Header [1] | 230 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 231 | | 232 | one or more frames of BroadVoice32 | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 When more than one codec data frame is present in a single RTP 237 packet, the timestamp is, as always, that of the oldest data frame 238 represented in the RTP packet. 240 If BroadVoice32 is used for applications with silence compression, 241 the first BroadVoice32 packet after a silence period during which 242 packets have not been transmitted contiguously, SHOULD have the 243 marker bit in the RTP data header set to one. The marker bit 244 in all other packets is zero. Applications without silence 245 suppression MUST set the marker bit to zero. 247 The assignment of an RTP payload type for this new packet format is 248 outside the scope of this document, and will not be specified here. 249 It is expected that the RTP profile for a particular class of 250 applications will assign a payload type for this encoding, or if 251 that is not done then a payload type in the dynamic range shall be 252 chosen. 254 4.1 BroadVoice32 Bit Stream Definition 256 The BroadVoice32 encoder operates on speech frames of 5 ms 257 corresponding to 80 samples at a sampling rate of 16000 samples per 258 second. For every 5 ms frame, the encoder encodes the 80 259 consecutive audio samples into 160 bits, or 20 octets. Thus, the 260 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame 261 is octet-aligned, and no padding bits are required. The bit 262 allocation for the encoded parameters of the BroadVoice32 codec 263 is listed in the following table. 264 Number of bits 265 Encoded Parameter Codeword per frame 266 --------------------------------------------------------------- 267 Line Spectrum Pairs L0,L1,L2 7+5+5=17 268 Pitch Lag PL 8 269 Pitch Gain PG 5 270 Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10 271 Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60 272 Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60 273 --------------------------------------------------------------- 274 Total: 160 bits 276 The mapping of the encoded parameters in a 160-bit BroadVoice32 data 277 frame is defined in the following figure. This figure shows the bit 278 packing in "network byte order", also known as big-endian order. 279 The bits of each 32-bit word are numbered 0 to 31, with the most 280 significant bit on the left and numbered 0. The octets (bytes) of 281 each word are transmitted most significant octet first. The bits of 282 data field for each encoded parameter are numbered in the same 283 order, with the most significant bit on the left. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | L0 | L1 | L2 | PL | PG |LG0| 289 | | | | | | | 290 |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| 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | LG0 | LG1 | VA0 | VA1 | VA2 | VA3 | 293 | | | | | | | 294 |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| 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | VA4 | VA5 | VA6 | VA7 | VA8 |VA9| 297 | | | | | | | 298 |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| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | VA9 | VB0 | VB1 | VB2 | VB3 | VB4 | 301 | | | | | | | 302 |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| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |VB4| VB5 | VB6 | VB7 | VB8 | VB9 | 305 | | | | | | | 306 |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| 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 2: BroadVoice32 bit packing 311 4.2 Multiple BroadVoice32 Frames in An RTP Packet 313 More than one BroadVoice32 frame may be included in a single RTP 314 packet by a sender. Senders have the following additional 315 restrictions: 317 o SHOULD NOT include more BroadVoice32 frames in a single RTP 318 packet than will fit in the MTU of the RTP transport protocol. 320 o MUST NOT split a BroadVoice32 frame between RTP packets. 322 o BroadVoice32 frames in an RTP packet MUST be consecutive. 324 Since multiple BroadVoice32 frames in an RTP packet MUST be 325 consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, 326 recovering the timestamps of all frames within a packet is easy. 327 The oldest frame within an RTP packet has the same timestamp as the 328 RTP packet, as mentioned above. To obtain the timestamp of the 329 frame that is N frames order than the oldest frame in the packet, 330 one simply adds 5*N ms worth of time units to the timestamp of the 331 RTP packet. 333 It is RECOMMENDED that the number of frames contained within an RTP 334 packet is consistent with the application. For example, in a 335 telephony application where delay is important, the fewer frames per 336 packet the lower the delay, whereas for a delay insensitive 337 streaming or messaging application, many frames per packet would be 338 acceptable. 340 Information describing the number of frames contained in an RTP 341 packet is not transmitted as part of the RTP payload. The only way 342 to determine the number of BroadVoice32 frames is to count the total 343 number of octets within the RTP packet, and divide the octet count 344 by 20. 346 5. Storage Format 348 The storage format is used for storing speech frames, e.g., as a 349 file or e-mail attachment. 351 The file begins with a header that includes only a magic number to 352 identify the codec that is used. The magic number for the 353 BroadVoice16 narrowband codec MUST correspond to the ASCII character 354 string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in 355 hexadecimal format. The magic number for the BroadVoice32 wideband 356 codec MUST correspond to the ASCII character string "#!BV32\n", or 357 "0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded 358 bit stream of either BroadVoice16 or BroadVoice32, but not both. In 359 other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be 360 mixed in the same file. 362 After the header that contains the magic number identifying the 363 codec used, the encoded codec data frames are stored in a sequential 364 order, as shown below. 366 +--------+---------------+---------------+-----+---------------+ 367 | Header | Codec frame 1 | Codec frame 2 | ... | Codec frame N | 368 +--------+---------------+---------------+-----+---------------+ 370 6. IANA Considerations 372 Two new MIME sub-types as described in this section are to be 373 registered. 375 The MIME names for the BV16 and BV32 codecs are to be allocated from 376 the IETF tree since these two codecs are expected to be widely used 377 for Voice-over-IP applications, espcially in Voice over Cable 378 applications. 380 6.1 MIME registration of BroadVoice16 382 MIME media type name: audio 384 MIME media subtype name: BV16 386 Required Parameter: none 388 Optional parameters: 389 The following parameters apply to RTP transfer only. 391 ptime: Defined as usual for RTP audio (see RFC 2327). 393 maxptime: See [4] for its definition. The maxptime SHOULD be a 394 multiple of the duration of a single codec data frame (5 ms). 396 Encoding considerations: 397 This type is defined for transfer of BV16-encoded data via RTP 398 using the payload format specified in Sections 3 of RFC xxxx. 399 It is also defined for other transfer methods using the storage 400 format specified in Section 5 of RFC xxxx. Audio data is binary 401 data, and must be encoded for non-binary transport; the Base64 402 encoding is suitable for Email. 404 Security considerations: 405 See Section 8 "Security Considerations" of RFC xxxx. 407 Public specification: 408 The BroadVoice16 codec has been specified in [3]. 410 Additional information: 411 The following information applies to storage format only. 413 Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21 414 0x42 0x56 0x31 0x36 0x0A" in hexadecimal) 416 File extensions: bvn, BVN (stands for "BroadVoice, Narrowband") 418 Macintosh file type code: none 420 Object identifier or OID: none 422 Intended usage: 423 COMMON. It is expected that many VoIP applications, especially 424 Voice over Cable applications, will use this type. 426 Person & email address to contact for further information: 427 Juin-Hwey (Raymond) Chen 428 rchen@broadcom.com 430 Author/Change controller: 431 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 432 Change Controller: IETF Audio/Video Transport Working Group 434 6.2 MIME registration of BroadVoice32 436 MIME media type name: audio 438 MIME media subtype name: BV32 440 Required Parameter: none 442 Optional parameters: 443 The following parameters apply to RTP transfer only. 445 ptime: Defined as usual for RTP audio (see RFC 2327). 447 maxptime: See [4] for its definition. The maxptime SHOULD be a 448 multiple of the duration of a single codec data frame (5 ms). 450 Encoding considerations: 451 This type is defined for transfer of BV32-encoded data via RTP 452 using the payload format specified in Sections 4 of RFC xxxx. 453 It is also defined for other transfer methods using the storage 454 format specified in Section 5 of RFC xxxx. Audio data is binary 455 data, and must be encoded for non-binary transport; the Base64 456 encoding is suitable for Email. 458 Security considerations: 459 See Section 8 "Security Considerations" of RFC xxxx. 461 Additional information: 462 The following information applies to storage format only. 464 Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21 465 0x42 0x56 0x33 0x32 0x0A" in hexadecimal) 467 File extensions: bvw, BVW (stands for "BroadVoice, Wideband") 469 Macintosh file type code: none 471 Object identifier or OID: none 473 Intended usage: 474 COMMON. It is expected that many VoIP applications, especially 475 Voice over Cable applications, will use this type. 477 Person & email address to contact for further information: 478 Juin-Hwey (Raymond) Chen 479 rchen@broadcom.com 481 Author/Change controller: 482 Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com 483 Change Controller: IETF Audio/Video Transport Working Group 485 7. Mapping To SDP Parameters 487 The information carried in the MIME media type specification has a 488 specific mapping to fields in the Session Description Protocol (SDP) 489 [5], which is commonly used to describe RTP sessions. When SDP is 490 used to specify sessions employing the BroadVoice16 or BroadVoice32 491 codec, the mapping is as follows: 493 - The MIME type ("audio") goes in SDP "m=" as the media name. 495 - The MIME subtype (payload format name) goes in SDP "a=rtpmap" 496 as the encoding name. The RTP clock rate in "a=rtpmap" MUST 497 be 8000 for BV16 and 16000 for BV32. 499 - The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 500 and "a=maxptime" attributes, respectively. 502 - Any remaining parameters go in the SDP "a=fmtp" attribute by 503 copying them directly from the MIME media type string as a 504 semicolon separated list of parameter=value pairs. 506 An example of the media representation in SDP for describing BV16 507 might be: 509 m=audio 49120 RTP/AVP 97 510 a=rtpmap:97 BV16/8000 512 An example of the media representation in SDP for describing BV32 513 might be: 515 m=audio 49122 RTP/AVP 99 516 a=rtpmap:99 BV32/16000 518 8. Security Considerations 520 RTP packets using the payload format defined in this specification 521 are subject to the security considerations discussed in the RTP 522 specification [1] and any appropriate profile (for example, [6]). 523 This implies that confidentiality of the media streams is achieved 524 by encryption. Because the data compression used with this payload 525 format is applied end-to-end, encryption may be performed after 526 compression so there is no conflict between the two operations. 528 A potential denial-of-service threat exists for data encoding using 529 compression techniques that have non-uniform receiver-end 530 computational load. The attacker can inject pathological datagrams 531 into the stream which are complex to decode and cause the receiver 532 to become overloaded. However, the encodings covered in this 533 document do not exhibit any significant non-uniformity. 535 9. Normative References 537 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 538 A Transport Protocol for Real-Time Applications", IETF RFC 1889, 539 January 1996 541 [3] BroadVoice(TM)16 Speech Codec Specification, Revision 1.2, 542 October 30, 2003, submitted to PacketCable vendor meetings at 543 CableLabs(R) as part of the ECR process for updating the 544 PacketCable(TM) Audio/Video Codecs Specification, Cable 545 Television Laboratories, Inc. 547 [4] M. Handley et al., "SDP: Session Description Protocol", 548 draft-ietf-mmusic-sdp-new-14.txt, September 4, 2003. 550 [5] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 551 IETF RFC 2327, April 1998 553 [6] H. Schulzrinne, "RTP Profile for Audio and Video Conferences 554 with Minimal Control" IETF RFC 1890, January 1996. 556 9.1 Informative References . 558 [2] S. Bradner, "Key words for use in RFCs to Indicate requirement 559 Levels", BCP 14, RFC 2119, March 1997. 561 10. Authors' Addresses 563 Juin-Hwey (Raymond) Chen 564 Broadcom Corporation 565 Room A3032 566 16215 Alton Parkway 567 Irvine, CA 92618 568 USA 569 Phone: +1 949 926 6288 570 Email: rchen@broadcom.com 571 Cheng-Chieh Lee 572 Broadcom Corporation 573 Room 202 574 3F-2, Lane 99, Puding Rd, 575 HsinChu City, Taiwan 300 576 Phone: +886 3 516 1176� � 577 Email: cclee@broadcom.com 579 Winnie Lee 580 Broadcom Corporation 581 Room A2012E 582 200-13711 International Place 583 Richmond, British Columbia V6V 2Z8 584 Canada 585 Phone: +1 604 233 8605 586 Email: wlee@broadcom.com 588 Jes Thyssen 589 Broadcom Corporation 590 Room A3053 591 16215 Alton Parkway 592 Irvine, CA 92618 593 USA 594 Phone: +1 949 926 5768 595 Email: jthyssen@broadcom.com