idnits 2.17.1 draft-mckay-qcelp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Interleave (LLL): 3 bits MUST have a value between 0 and 5 inclusive. The remaining two values (6 and 7) MUST not be used by senders. If this field is non-zero, interleaving is enabled. All receivers MUST support interleaving. Senders MAY support interleaving. Senders that do not support interleaving MUST set field LLL and NNN to zero. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o MUST not bundle more CODEC data frames in a single RTP packet than will fit in the MTU of the RTP transport protocol. For the purpose of computing the maximum bundling value, all CODEC data frames should be assumed to have the Rate 1 size. -- 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.) -- The document date (August 5, 1998) is 9395 days in the past. Is this intentional? 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. '1' ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Kyle J. McKay 3 draft-mckay-qcelp-01.txt Eric C. Rosen 4 Expires: October 1998 QUALCOMM Incorporated 5 August 5, 1998 7 RTP Payload Format for PureVoice(tm) Audio 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [3]. 33 ABSTRACT 35 This document describes the RTP payload format for 36 PureVoice(tm) Audio. The packet format supports variable 37 interleaving to reduce the effect of packet loss on audio 38 quality. 40 1 Introduction 42 This document describes how compressed PureVoice audio as produced by 43 the QUALCOMM PureVoice CODEC [1] may be formatted for use as an RTP 44 payload type. A method is provided to interleave the output of the 45 compressor to reduce quality degradation due to lost packets. 46 Furthermore, the sender may choose various interleave settings based 47 on the importance of low end-to-end delay versus greater tolerance 48 for lost packets. 50 2 Background 52 The Electronic Industries Association (EIA) & Telecommunications 53 Industry Association (TIA) standard IS-733 [1] defines an audio 54 compression algorithm for use in CDMA applications. In addition to 55 being the standard CODEC for all wireless CDMA terminals, the 56 QUALCOMM PureVoice CODEC (a.k.a. Qcelp) is used in several Internet 57 applications most notably JFax(tm), Apple(r) QuickTime(tm), and 58 Eudora(r). 60 The Qcelp CODEC [1] compresses each 20 milliseconds of 8000 Hz, 16- 61 bit sampled input speech into one of four different size output 62 frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits) 63 or Rate 1/8 (20 bits). The CODEC chooses the output frame rate based 64 on analysis of the input speech and the current operating mode 65 (either normal or reduced rate). For typical speech patterns, this 66 results in an average output of 6.8 k bits/sec for normal mode and 67 4.7 k bits/sec for reduced rate mode. 69 3 RTP/Qcelp Packet Format 71 The RTP timestamp is in 1/8000 of a second units. The RTP payload 72 data for the Qcelp CODEC has the following format: 74 0 1 2 3 75 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 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | RTP Header [2] | 78 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 79 |E|R| LLL | NNN | | 80 +-+-+-+-+-+-+-+-+ one or more codec data frames | 81 | .... | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 The RTP header has the expected values as described in [2]. The 85 extension bit is not set. The marker bit MAY be set at the beginning 86 of a talkspurt. The codec data frames are aligned on octet 87 boundaries. When interleaving is in use, and/or multiple codec data 88 frames are present in a single RTP packet, the timestamp is, as 89 always, that of the oldest data represented in the RTP packet. The 90 other fields have the following meaning: 92 Encrypted (E): 1 bit 93 MUST by set to zero by sender except when data frames are 94 encrypted. Senders MAY support encryption. Receivers MAY 95 optionally support encryption but MUST examine this bit to detect 96 and discard encrypted payloads if encryption is not supported. 97 Encryption is discussed further in Section (6). 99 Reserved (R): 1 bit 100 MUST be set to zero by sender, ignored by receiver. 102 Interleave (LLL): 3 bits 103 MUST have a value between 0 and 5 inclusive. The remaining two 104 values (6 and 7) MUST not be used by senders. If this field is 105 non-zero, interleaving is enabled. All receivers MUST support 106 interleaving. Senders MAY support interleaving. Senders that do 107 not support interleaving MUST set field LLL and NNN to zero. 109 Interleave Index (NNN): 3 bits 110 MUST have a value less than or equal to the value of LLL. Values 111 of NNN greater than the value of LLL are invalid. 113 3.1 Receiving Invalid Values 115 On receipt of an RTP packet with an invalid value of the LLL or NNN 116 field, the RTP packet MUST be treated as lost by the receiver for the 117 purpose of generating erasure frames as described in section 4. 119 3.2 CODEC data frame format 121 The output of the Qcelp CODEC must be converted into CODEC data 122 frames for inclusion in the RTP payload as follows: 124 a. The lower nibble of Octet 0 of each CODEC data frame defines the 125 rate and total size of the frame. The upper nibble is reserved. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | RRRR | T | Vocoder data frame octets as in [1] .... | 131 +-+-+-+-+-+-+-+-+ + 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 The interpretation of Octet 0 of each CODEC data frame is defined 136 as follows: 138 Reserved (RRRR): 4 bits 139 MUST by set to zero by sender. MUST be ignored by receivers. 141 Frame Type (T): 4 bits 142 Defines (by value) the frame rate and size of the vocoder data 143 octets that immediately follow according to the following 144 mapping: 145 TOTAL CODEC 146 FRAME FRAME Data frame 148 TYPE (T) RATE size (octets) 149 --------+-----------+---------------- 150 0 | Blank | 1 151 1 | 1/8 | 4 152 2 | 1/4 | 8 153 3 | 1/2 | 17 154 4 | 1 | 35 155 5 | Reserved | 8 156 14 | Erasure | 1 158 All other Frame Type values not listed above are reserved. 159 Receipt of a CODEC data frame with a reserved frame-type MUST 160 be considered invalid data as described in 3.1. 162 b. The bits as numbered in the standard [1] from highest to lowest 163 are packed into octets. The highest numbered bit (265 for Rate 1, 164 123 for Rate 1/2, 53 for Rate 1/4 and 19 for Rate 1/8) is placed 165 in the most significant bit (Internet bit 0) of octet 1 of the 166 CODEC data frame. The second highest numbered bit (264 for Rate 167 1, etc.) is placed in the second most significant bit (Internet 168 bit 1) of octet 1 of the data frame. This continues so that bit 169 258 from the standard Rate 1 frame is placed in the least 170 significant bit of octet 1. Bit 257 from the standard is placed 171 in the most significant bit of octet 2 and so on, until bit 0 from 172 the standard Rate 1 frame is placed in Internet bit 1 of octet 34 173 of the CODEC data frame. The remaining unused bits of the last 174 octet of the CODEC data frame MUST be set to zero. 176 Here is a detail of how a Rate 1/8 frame is converted into a CODEC 177 data frame: 178 CODEC data frame 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | |1|1|1|1|1|1|1|1|1|1| | | | | | | | | | | | | | | 184 | 1 (Rate 1/8) |9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|Z|Z|Z|Z| 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Octet 0 of the data frame has value 1 (see table above) indicating 188 the total data frame length (including octet 0) is 4 octets. Bits 189 19 through 0 from the standard Rate 1/8 frame are placed as 190 indicated with bits marked with "Z" being set to zero. The Rate 191 1, 1/4 and 1/2 standard frames are converted similarly. 193 3.3 Bundling CODEC data frames 195 As indicated in section 3, more than one CODEC data frame MAY be 196 included in a single RTP packet by a sender. Receivers MUST handle 197 bundles of up to 10 CODEC data frames in a single RTP packet. 199 Furthermore, senders have the following additional restrictions: 201 o MUST not bundle more CODEC data frames in a single RTP packet than 202 will fit in the MTU of the RTP transport protocol. For the purpose 203 of computing the maximum bundling value, all CODEC data frames 204 should be assumed to have the Rate 1 size. 206 o MUST never bundle more than 10 CODEC data frames in a single RTP 207 packet. 209 o Once beginning transmission with a given SSRC and given bundling 210 value, MUST NOT increase the bundling value. If the bundling value 211 needs to be increased, a new SSRC number MUST be used. 213 o MAY decrease the bundling value only between interleave groups (see 214 section 3.4). If the bundling value is decreased, it MUST NOT be 215 increased (even to the original value), although it may be 216 decreased again at a later time. 218 3.3.1 Determining the number of bundled CODEC data frames 220 Since no count is transmitted as part of the RTP payload and the 221 CODEC data frames have differing lengths, the only way to determine 222 how many CODEC data frames are present in the RTP packet is to 223 examine octet 0 of each CODEC data frame in sequence until the end of 224 the RTP packet is reached. 226 3.4 Interleaving CODEC data frames 228 Interleaving is meaningful only when more than one CODEC data frame 229 is bundled into a single RTP packet. 231 All receivers MUST support interleaving. Senders MAY support 232 interleaving. 234 Given a time-ordered sequence of output frames from the Qcelp CODEC 235 numbered 0..n, a bundling value B, and an interleave value L where n 236 = B * (L+1) - 1, the output frames are placed into RTP packets as 237 follows (the values of the fields LLL and NNN are indicated for each 238 RTP packet): 240 First RTP Packet in Interleave group: 241 LLL=L, NNN=0 242 Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of 243 B frames 245 Second RTP Packet in Interleave group: 246 LLL=L, NNN=1 247 Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a 248 total of B frames 250 This continues to the last RTP packet in the interleave group: 252 L+1 RTP Packet in Interleave group: 253 LLL=L, NNN=L 254 Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a 255 total of B frames 257 Senders MUST transmit in timestamp-increasing order. Furthermore, 258 within each interleave group, the RTP packets making up the 259 interleave group MUST be transmitted in value-increasing order of the 260 NNN field. While this does not guarantee reduced end-to-end delay on 261 the receiving end, when packets are delivered in order by the 262 underlying network, delay will be reduced to the minimum possible. 264 Additionally, senders have the following restrictions: 266 o Once beginning transmission with a given SSRC and given interleave 267 value, MUST NOT increase the interleave value. If the interleave 268 value needs to be increased, a new SSRC number MUST be used. 270 o MAY decrease the interleave value only between interleave groups. 271 If the interleave value is decreased, it MUST NOT be increased 272 (even to the original value), although it may be decreased again at 273 a later time. 275 3.5 Finding Interleave Group Boundaries 277 Given an RTP packet with sequence number S, interleave value (field 278 LLL) L, and interleave index value (field NNN) N, the interleave 279 group consists of RTP packets with sequence numbers from S-N to S-N+L 280 inclusive. In other words, the Interleave group always consists of 281 L+1 RTP packets with sequential sequence numbers. The bundling value 282 for all RTP packets in an interleave group MUST be the same. 284 The receiver determines the expected bundling value for all RTP 285 packets in an interleave group by the number of CODEC data frames 286 bundled in the first RTP packet of the interleave group received. 287 Note that this may not be the first RTP packet of the interleave 288 group sent if packets are delivered out of order by the underlying 289 network. 291 On receipt of an RTP packet in an interleave group with other than 292 the expected bundling value, the receiver MAY discard CODEC data 293 frames off the end of the RTP packet or add erasure CODEC data frames 294 to the end of the packet in order to manufacture a substitute packet 295 with the expected bundling value. The receiver MAY instead choose to 296 discard the whole interleave group and play silence. 298 3.6 Reconstructing Interleaved Audio 300 Given an RTP sequence number ordered set of RTP packets in an 301 interleave group numbered 0..L, where L is the interleave value and B 302 is the bundling value, and CODEC data frames within each RTP packet 303 that are numbered in order from first to last with the numbers 1..B, 304 the original, time-ordered sequence of output frames from the CODEC 305 may be reconstructed as follows: 307 First L+1 frames: 308 Frame 0 from packet 0 of interleave group 309 Frame 0 from packet 1 of interleave group 310 And so on up to... 311 Frame 0 from packet L of interleave group 313 Second L+1 frames: 314 Frame 1 from packet 0 of interleave group 315 Frame 1 from packet 1 of interleave group 316 And so on up to... 317 Frame 1 from packet L of interleave group 319 And so on up to... 321 Bth L+1 frames: 322 Frame B from packet 0 of interleave group 323 Frame B from packet 1 of interleave group 324 And so on up to... 325 Frame B from packet L of interleave group 327 3.6.1 Additional Receiver Responsibility 329 Assume that the receiver has begun playing frames from an interleave 330 group. The time has come to play frame x from packet n of the 331 interleave group. Further assume that packet n of the interleave 332 group has not been received. As described in section 4, an erasure 333 frame will be sent to the Qcelp CODEC. 335 Now, assume that packet n of the interleave group arrives before 336 frame x+1 of that packet is needed. Receivers SHOULD use frame x+1 337 of the newly received packet n rather than substituting an erasure 338 frame. In other words, just because packet n wasn't available the 339 first time it was needed to reconstruct the interleaved audio, the 340 receiver SHOULD NOT assume it's not available when it's subsequently 341 needed for interleaved audio reconstruction. 343 4 Handling lost RTP packets 345 The Qcelp CODEC supports the notion of erasure frames. These are 346 frames that for whatever reason are not available. When 347 reconstructing interleaved audio or playing back non-interleaved 348 audio, erasure frames MUST be fed to the Qcelp CODEC for all of the 349 missing packets. 351 Receivers MUST use the timestamp clock to determine how many CODEC 352 data frames are missing. Each CODEC data frame advances the 353 timestamp clock EXACTLY 160 counts. 355 Since the bundling value may vary (it can only decrease), the 356 timestamp clock is the only reliable way to calculate exactly how 357 many CODEC data frames are missing when a packet is dropped. 359 Specifically when reconstructing interleaved audio, a missing RTP 360 packet in the interleave group should be treated as containing B 361 erasure CODEC data frames where B is the bundling value for that 362 interleave group. 364 5 Discussion 366 The Qcelp CODEC interpolates the missing audio content when given an 367 erasure frame. However, the best quality is perceived by the 368 listener when erasure frames are not consecutive. This makes 369 interleaving desirable as it increases audio quality when dropped 370 packets are more likely. 372 On the other hand, interleaving can greatly increase the end-to-end 373 delay. Where an interactive session is desired, an interleave (field 374 LLL) value of 0 or 1 and a bundling factor of 4 or less is 375 recommended. 377 When end-to-end delay is not a concern, a bundling value of at least 378 4 and an interleave (field LLL) value of 4 or 5 is recommended 379 subject to MTU limitations. 381 The restrictions on senders set forth in sections 3.3 and 3.4 382 guarantee that after receipt of the first payload packet from the 383 sender, the receiver can allocate a well-known amount of buffer space 384 that will be sufficient for all future reception from the same SSRC 385 value. Less buffer space may be required at some point in the future 386 if the sender decreases the bundling value or interleave, but never 387 more buffer space. This prevents the possibility of the receiver 388 needing to allocate more buffer space (with the possible result that 389 none is available) should the bundling value or interleave value be 390 increased by the sender. Also, were the interleave or bundling value 391 to increase, the receiver could be forced to pause playback while it 392 receives the additional packets necessary for playback at an 393 increased bundling value or increased interleave. 395 6 Encrypted RTP/Qcelp Packet Format 397 Senders may optionally encrypt PureVoice data frames as a means of 398 guarding against eavesdropping. Applications may use any appropriate 399 algorithm to encrypt data frames. The encryption algorithm, key 400 length, key exchange mechanisms, and other encryption algorithm 401 parameters are not defined here. 403 When encrypted data frames are sent, the first bit in the RTP payload 404 is set to one and additional crypto payload fields are defined 405 according to the following format: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | RTP Header [2] | 411 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 412 |E|R| LLL | NNN |R|K| CSL | zero or more cryptosync | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 414 | octets, followed by zero or two cryptocheck octets, | 415 | followed by one or more encrypted codec data frames ... | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 The RTP header has the expected values as described earlier. The 419 remaining fields have the following meaning: 421 Encrypted (E): 1 bit 422 MUST by set to one by sender when data frames are encrypted. 424 Reserved (R): 1 bit 425 MUST be set to zero by sender, ignored by receiver. 427 Interleave (LLL): 3 bits 428 As defined in Section (3). 430 Interleave Index (NNN): 3 bits 431 As defined in Section (3). 433 Reserved (R): 1 bit 434 MUST be set to zero by sender, ignored by receiver. 436 Cryptocheck Presence (K): 1 bit 437 Indicates the presence or absence of two octets comprising a 438 single 16 bit cryptocheck word to follow any cryptosync octets in 439 the payload. The bit is set if and only if a cryptocheck word 440 follows. The generation of the cryptocheck is considered 441 application dependent and outside the scope of this description. 442 However, it is provided as a means to allow the receiver to 443 routinely validate the use of consistent keys and other aspects of 444 the encryption process. The cryptocheck word could simply consist 445 of an encrypted known-value or be generated by encrypting the 446 output of a hash function applied to the plaintext vocoder data 447 (or other data). 449 Cryptosync Length (CSL): 6 bits 450 Indicates (by value) the number of cryptosync octets which follow 451 later in the payload. The length and meaning of the cryptosync 452 octets are dependent on the encryption algorithm and is considered 453 application specific and outside the scope of this description. 454 The cryptosync octets could contain a Cipher Block Chaining mode 455 initialization vector (IV) or a Counter Mode Encryption state 456 variable (SV) [4]. 458 7 Security Considerations 460 The presence of the cryptocheck provides an obvious mechanism to 461 compromise encryption if adequate care in defining the cryptocheck 462 is not taken. Encrypting a fixed known or well documented value 463 (such as the RTP header timestamp) could be a particularly poor 464 design choice, for example. 466 Although no specific encryption algorithms are endorsed here, 467 techniques with low overhead requirements are expected to be more 468 popular, and these techniques may be more susceptible to spoofing 469 and authentication attacks than techniques which include 470 additional (redundant) information. 472 To reduce overhead, no mechanism for interoperability between 473 applications using different encryption algorithms is defined 474 here. Rather, it is expected that applications will exchange this 475 and other encryption related information in advance of streaming 476 audio. 478 8 References 480 [1] TIA/EIA/IS-733. TR45: High Rate Speech Service Option for 481 Wideband Spread Spectrum Communications Systems. Available 482 from Global Engineering +1 800 854 7179 or +1 303 792 2181. 483 May also be ordered online at http://www.eia.org/eng/. 485 [2] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 486 "RTP: A Transport Protocol for Real-Time Applications", RFC 487 1889, Audio-Video Transport Working Group, January 1996. 489 [3] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", RFC 2119, March 1997. 492 [4] Schneier, B., "Applied Cryptography: Protocols, Algorithms, 493 and Source Code", John Wiley & Sons, ISBN: 0471128457, 494 October, 1995. 496 Authors' Address 498 Kyle J. McKay 499 Eric C. Rosen 500 QUALCOMM, Inc. 501 6455 Lusk Boulevard 502 San Diego, CA 92121 503 USA 505 Phone: +1 619 587 1121 507 EMail: 508 "Kyle J. McKay" 509 "Eric C. Rosen"