idnits 2.17.1 draft-ietf-avt-rtp-speex-05.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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 676. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (February 16, 2008) is 5914 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT G. Herlein 3 Internet-Draft 4 Intended status: Standards Track J. Valin 5 Expires: August 19, 2008 CSIRO 6 A. Heggestad 7 Creytiv.com 8 A. Moizard 9 Antisip 10 February 16, 2008 12 RTP Payload Format for the Speex Codec 13 draft-ietf-avt-rtp-speex-05 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 19, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 Speex is an open-source voice codec suitable for use in Voice over IP 47 (VoIP) type applications. This document describes the payload format 48 for Speex generated bit streams within an RTP packet. Also included 49 here are the necessary details for the use of Speex with the Session 50 Description Protocol (SDP). 52 Editors Note 54 All references to RFC XXXX are to be replaced by references to the 55 RFC number of this memo, when published. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. RTP usage for Speex . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. RTP Speex Header Fields . . . . . . . . . . . . . . . . . 6 63 3.2. RTP payload format for Speex . . . . . . . . . . . . . . . 6 64 3.3. Speex payload . . . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Example Speex packet . . . . . . . . . . . . . . . . . . . 7 66 3.5. Multiple Speex frames in a RTP packet . . . . . . . . . . 7 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Media Type Registration . . . . . . . . . . . . . . . . . 9 69 4.1.1. Registration of media type audio/speex . . . . . . . . 9 70 5. SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1. Example supporting all modes, prefer mode 4 . . . . . . . 15 72 5.2. Example supporting only mode 3 and 5 . . . . . . . . . . . 15 73 5.3. Example with Variable Bit Rate and Comfort Noise . . . . . 15 74 5.4. Example with Voice Activity Detection . . . . . . . . . . 15 75 5.5. Example with Multiple sampling rates . . . . . . . . . . . 15 76 5.6. Example with ptime and Multiple Speex frames . . . . . . . 16 77 5.7. Example with Complete Offer/Answer exchange . . . . . . . 16 78 6. Implementation Guidelines . . . . . . . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 81 9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 20 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 Intellectual Property and Copyright Statements . . . . . . . . . . 23 88 1. Introduction 90 Speex is based on the CELP [CELP] encoding technique with support for 91 either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra- 92 wideband (nominal 32kHz). The main characteristics can be summarized 93 as follows: 95 o Free software/open-source 97 o Integration of wideband and narrowband in the same bit-stream 99 o Wide range of bit-rates available 101 o Dynamic bit-rate switching and variable bit-rate (VBR) 103 o Voice Activity Detection (VAD, integrated with VBR) 105 o Variable complexity 107 The Speex codec supports a wide range of bit-rates from 2.15 kbit/s 108 to 44 kbit/s. In some cases however, it may not be possible for an 109 implementation to include support for all rates (e.g. because of 110 bandwidth, RAM or CPU constraints). In those cases, to be compliant 111 with this specification, implementations MUST support at least 112 narrowband (8 kHz) encoding and decoding at 8 kbit/s bit-rate 113 (narrowband mode 3). Support for narrowband at 15 kbit/s (narrowband 114 mode 5) is RECOMMENDED and support for wideband at 27.8 kbit/s 115 (wideband mode 8) is also RECOMMENDED. The sampling rate MUST be 8, 116 16 or 32 kHz. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC2119 [RFC2119] and 123 indicate requirement levels for compliant RTP implementations. 125 3. RTP usage for Speex 127 3.1. RTP Speex Header Fields 129 The RTP header is defined in the RTP specification [RFC3550]. This 130 section defines how fields in the RTP header are used. 132 Payload Type (PT): The assignment of an RTP payload type for this 133 packet format is outside the scope of this document; it is 134 specified by the RTP profile under which this payload format is 135 used, or signaled dynamically out-of-band (e.g., using SDP). 137 Marker (M) bit: The M bit is set to one on the first packet sent 138 after a silence period, during which packets have not been 139 transmitted contiguously. 141 Extension (X) bit: Defined by the RTP profile used. 143 Timestamp: A 32-bit word that corresponds to the sampling instant 144 for the first frame in the RTP packet. 146 3.2. RTP payload format for Speex 148 The RTP payload for Speex has the format shown in Figure 1. No 149 additional header fields specific to this payload format are 150 required. For RTP based transportation of Speex encoded audio the 151 standard RTP header [RFC3550] is followed by one or more payload data 152 blocks. An optional padding terminator may also be used. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | RTP Header | 158 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 159 | one or more frames of Speex .... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | one or more frames of Speex .... | padding | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: RTP payload for Speex 166 3.3. Speex payload 168 For the purposes of packetizing the bit stream in RTP, it is only 169 necessary to consider the sequence of bits as output by the Speex 170 encoder [speex_manual], and present the same sequence to the decoder. 171 The payload format described here maintains this sequence. 173 A typical Speex frame, encoded at the maximum bitrate, is approx. 110 174 octets and the total number of Speex frames SHOULD be kept less than 175 the path MTU to prevent fragmentation. Speex frames MUST NOT be 176 fragmented across multiple RTP packets, 178 An RTP packet MAY contain Speex frames of the same bit rate or of 179 varying bit rates, since the bit-rate for a frame is conveyed in band 180 with the signal. 182 The encoding and decoding algorithm can change the bit rate at any 20 183 msec frame boundary, with the bit rate change notification provided 184 in-band with the bit stream. Each frame contains both sampling rate 185 (narrowband, wideband or ultra-wideband) and "mode" (bit-rate) 186 information in the bit stream. No out-of-band notification is 187 required for the decoder to process changes in the bit rate sent by 188 the encoder. 190 The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz. 192 The RTP payload MUST be padded to provide an integer number of octets 193 as the payload length. These padding bits are LSB aligned in network 194 octet order and consist of a 0 followed by all ones (until the end of 195 the octet). This padding is only required for the last frame in the 196 packet, and only to ensure the packet contents ends on an octet 197 boundary. 199 3.4. Example Speex packet 201 In the example below we have a single Speex frame with 5 bits of 202 padding to ensure the packet size falls on an octet boundary. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | RTP Header | 208 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 209 | ..speex data.. | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | ..speex data.. |0 1 1 1 1| 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 3.5. Multiple Speex frames in a RTP packet 216 Below is an example of two Speex frames contained within one RTP 217 packet. The Speex frame length in this example fall on an octet 218 boundary so there is no padding. 220 The Speex decoder [speex_manual] can detect the bitrate from the 221 payload and is responsible for detecting the 20 msec boundaries 222 between each frame. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | RTP Header | 228 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 229 | ..speex frame 1.. | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ..speex frame 1.. | ..speex frame 2.. | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ..speex frame 2.. | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 4. IANA Considerations 238 This document defines the Speex media type. 240 4.1. Media Type Registration 242 This section describes the media types and names associated with this 243 payload format. The section registers the media types, as per 244 RFC4288 [RFC4288] 246 4.1.1. Registration of media type audio/speex 248 Media type name: audio 250 Media subtype name: speex 252 Required parameters: 254 rate: RTP timestamp clock rate, which is equal to the sampling 255 rate in Hz. The sampling rate MUST be either 8000, 16000, or 256 32000. 258 Optional parameters: 260 ptime: SHOULD be a multiple of 20 msec [RFC4566] 262 maxptime: SHOULD be a multiple of 20 msec [RFC4566] 264 vbr: variable bit rate - either 'on' 'off' or 'vad' (defaults to 265 off). If on, variable bit rate is enabled. If off, disabled. If 266 set to 'vad' then constant bit rate is used but silence will be 267 encoded with special short frames to indicate a lack of voice for 268 that period. 270 cng: comfort noise generation - either 'on' or 'off'. If off then 271 silence frames will be silent; if 'on' then those frames will be 272 filled with comfort noise. 274 mode: List supported Speex decoding modes. The valid modes are 275 different for narrowband and wideband, and are defined as follows: 277 * {1,2,3,4,5,6,7,8,any} for narrowband 279 * {0,1,2,3,4,5,6,7,8,9,10,any} for wideband and ultra-wideband 281 Several 'mode' parameters can be provided. In this case, the 282 remote party SHOULD configure its encoder using the first 283 supported mode provided. When 'any' is used, the offerer 284 indicates that it supports all decoding modes. If the 'mode' 285 parameter is not provided, the mode value is considered to be 286 equivalent to 'mode=3;mode=any' in narrowband and 287 'mode=8;mode=any' in wideband and ultra-wideband. Note that each 288 Speex frame does contains the mode (or bit-rate) that should be 289 used to decode it. Thus application MUST be able to decode any 290 Speex frame unless the SDP clearly specify that some modes are not 291 supported. (e.g., by not including 'mode=any') 293 Encoding considerations: 295 This media type is framed and binary, see section 4.8 in 296 [RFC4288]. 298 Security considerations: See Section 6 300 Interoperability considerations: 302 None. 304 Published specification: 306 RFC XXXX [RFC Editor: please replace by the RFC number of this 307 memo, when published] 309 Applications which use this media type: 311 Audio streaming and conferencing applications. 313 Additional information: none 315 Person and email address to contact for further information : 317 Alfred E. Heggestad: aeh@db.org 319 Intended usage: COMMON 321 Restrictions on usage: 323 This media type depends on RTP framing, and hence is only defined 324 for transfer via RTP [RFC3550]. Transport within other framing 325 protocols is not defined at this time. 327 Author: Alfred E. Heggestad 329 Change controller: 331 IETF Audio/Video Transport working group delegated from the IESG. 333 5. SDP usage of Speex 335 The information carried in the media type specification has a 336 specific mapping to fields in the Session Description Protocol (SDP) 337 [RFC4566], which is commonly used to describe RTP sessions. When SDP 338 is used to specify sessions employing the Speex codec, the mapping is 339 as follows: 341 o The media type ("audio") goes in SDP "m=" as the media name. 343 o The media subtype ("speex") goes in SDP "a=rtpmap" as the encoding 344 name. The required parameter "rate" also goes in "a=rtpmap" as 345 the clock rate. 347 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 348 "a=maxptime" attributes, respectively. 350 o Any remaining parameters go in the SDP "a=fmtp" attribute by 351 copying them directly from the media type string as a semicolon 352 separated list of parameter=value pairs. 354 The tables below include the equivalence between modes and bitrates 355 for narrowband, wideband and ultra-wideband. Also, the corresponding 356 "Speex quality" setting (see SPEEX_SET_QUALITY in The Speex Codec 357 Manual [speex_manual]) is included as an indication. 359 +------+---------------+-------------+ 360 | mode | Speex quality | bitrate | 361 +------+---------------+-------------+ 362 | 1 | 0 | 2.15 kbit/s | 363 | | | | 364 | 2 | 2 | 5.95 kbit/s | 365 | | | | 366 | 3 | 3 or 4 | 8.00 kbit/s | 367 | | | | 368 | 4 | 5 or 6 | 11.0 kbit/s | 369 | | | | 370 | 5 | 7 or 8 | 15.0 kbit/s | 371 | | | | 372 | 6 | 9 | 18.2 kbit/s | 373 | | | | 374 | 7 | 10 | 24.6 kbit/s | 375 | | | | 376 | 8 | 1 | 3.95 kbit/s | 377 +------+---------------+-------------+ 379 Mode vs Bitrate table for narrowband 381 Table 1 383 +------+---------------+------------------+------------------------+ 384 | mode | Speex quality | wideband bitrate | ultra wideband bitrate | 385 +------+---------------+------------------+------------------------+ 386 | 0 | 0 | 3.95 kbit/s | 5.75 kbit/s | 387 | | | | | 388 | 1 | 1 | 5.75 kbit/s | 7.55 kbit/s | 389 | | | | | 390 | 2 | 2 | 7.75 kbit/s | 9.55 kbit/s | 391 | | | | | 392 | 3 | 3 | 9.80 kbit/s | 11.6 kbit/s | 393 | | | | | 394 | 4 | 4 | 12.8 kbit/s | 14.6 kbit/s | 395 | | | | | 396 | 5 | 5 | 16.8 kbit/s | 18.6 kbit/s | 397 | | | | | 398 | 6 | 6 | 20.6 kbit/s | 22.4 kbit/s | 399 | | | | | 400 | 7 | 7 | 23.8 kbit/s | 25.6 kbit/s | 401 | | | | | 402 | 8 | 8 | 27.8 kbit/s | 29.6 kbit/s | 403 | | | | | 404 | 9 | 9 | 34.2 kbit/s | 36.0 kbit/s | 405 | | | | | 406 | 10 | 10 | 42.2 kbit/s | 44.0 kbit/s | 407 +------+---------------+------------------+------------------------+ 409 Mode vs Bitrate table for wideband and ultra-wideband 411 Table 2 413 The Speex parameters indicate the decoding capabilities of the agent, 414 and what the agent prefers to receive. 416 The Speex parameters in an SDP Offer/Answer exchange are completely 417 orthogonal, and there is no relationship between the SDP Offer and 418 the Answer. 420 Several Speex specific parameters can be given in a single a=fmtp 421 line provided that they are separated by a semi-colon: 423 a=fmtp:97 mode=1;mode=any;vbr=on 425 Some example SDP session descriptions utilizing Speex encodings 426 follow. 428 5.1. Example supporting all modes, prefer mode 4 430 The offerer indicates that it wishes to receive a Speex stream at 431 8000Hz, and wishes to receive Speex 'mode 4'. It is important to 432 understand that any other mode might still be sent by remote party: 433 the device might have bandwidth limitation or might only be able to 434 send 'mode=3'. Thus, application that support all decoding modes 435 SHOULD include 'mode=any' as shown in the example below: 437 m=audio 8088 RTP/AVP 97 438 a=rtpmap:97 speex/8000 439 a=fmtp:97 mode=4;mode=any 441 5.2. Example supporting only mode 3 and 5 443 The offerer indicates the mode he wishes to receive (Speex 'mode 3'). 444 This offer indicates mode 3 and mode 5 are supported and that no 445 other modes are supported. The remote party MUST NOT configure its 446 encoder using another Speex mode. 448 m=audio 8088 RTP/AVP 97 449 a=rtmap:97 speex/8000 450 a=fmtp:97 mode=3;mode=5 452 5.3. Example with Variable Bit Rate and Comfort Noise 454 The offerer indicates that it wishes to receive variable bit rate 455 frames with comfort noise: 457 m=audio 8088 RTP/AVP 97 458 a=rtmap:97 speex/8000 459 a=fmtp:97 vbr=on;cng=on 461 5.4. Example with Voice Activity Detection 463 The offerer indicates that it wishes to use silence suppression. In 464 this case vbr=vad parameter will be used: 466 m=audio 8088 RTP/AVP 97 467 a=rtmap:97 speex/8000 468 a=fmtp:97 vbr=vad 470 5.5. Example with Multiple sampling rates 472 The offerer indicates that it wishes to receive Speex audio at 16000 473 Hz with mode 10 (42.2 kbit/s), alternatively Speex audio at 8000 Hz 474 with mode 7 (24.6 kbit/s). The offerer supports decoding all modes. 476 m=audio 8088 RTP/AVP 97 98 477 a=rtmap:97 speex/16000 478 a=fmtp:97 mode=10;mode=any 479 a=rtmap:98 speex/8000 480 a=fmtp:98 mode=7;mode=any 482 5.6. Example with ptime and Multiple Speex frames 484 The "ptime" attribute is used to denote the packetization interval 485 (ie, how many milliseconds of audio is encoded in a single RTP 486 packet). Since Speex uses 20 msec frames, ptime values of multiples 487 of 20 denote multiple Speex frames per packet. Values of ptime which 488 are not multiples of 20 MUST be rounded up to the first multiple of 489 20 above the ptime value. 491 In the example below the ptime value is set to 40, indicating that 492 there are 2 frames in each packet. 494 m=audio 8088 RTP/AVP 97 495 a=rtpmap:97 speex/8000 496 a=ptime:40 498 Note that the ptime parameter applies to all payloads listed in the 499 media line and is not used as part of an a=fmtp directive. 501 Care must be taken when setting the value of ptime so that the RTP 502 packet size does not exceed the path MTU. 504 5.7. Example with Complete Offer/Answer exchange 506 The offerer indicates that it wishes to receive Speex audio at 16000 507 Hz, alternatively Speex audio at 8000 Hz. The offerer does support 508 ALL modes because no mode is specified. 510 m=audio 8088 RTP/AVP 97 98 511 a=rtmap:97 speex/16000 512 a=rtmap:98 speex/8000 514 The answerer indicates that it wishes to receive Speex audio at 8000 515 Hz, which is the only sampling rate it supports. The answerer does 516 support ALL modes because no mode is specified. 518 m=audio 8088 RTP/AVP 99 519 a=rtmap:99 speex/8000 521 6. Implementation Guidelines 523 Implementations that supports Speex are responsible for correctly 524 decoding incoming Speex frames. 526 Each Speex frame does contains all needed informations to decode 527 itself. In particular, the 'mode' and 'ptime' values proposed in the 528 SDP contents MUST NOT be used for decoding: those values are not 529 needed to properly decode a RTP Speex stream. 531 7. Security Considerations 533 RTP packets using the payload format defined in this specification 534 are subject to the security considerations discussed in the RTP 535 specification [RFC3550], and any appropriate RTP profile. This 536 implies that confidentiality of the media streams is achieved by 537 encryption. Because the data compression used with this payload 538 format is applied end-to-end, encryption may be performed after 539 compression so there is no conflict between the two operations. 541 A potential denial-of-service threat exists for data encodings using 542 compression techniques that have non-uniform receiver-end 543 computational load. The attacker can inject pathological datagrams 544 into the stream which are complex to decode and cause the receiver to 545 be overloaded. However, this encoding does not exhibit any 546 significant non-uniformity. 548 As with any IP-based protocol, in some circumstances a receiver may 549 be overloaded simply by the receipt of too many packets, either 550 desired or undesired. Network-layer authentication may be used to 551 discard packets from undesired sources, but the processing cost of 552 the authentication itself may be too high. 554 8. Acknowledgements 556 The authors would like to thank Equivalence Pty Ltd of Australia for 557 their assistance in attempting to standardize the use of Speex in 558 H.323 applications, and for implementing Speex in their open source 559 OpenH323 stack. The authors would also like to thank Brian C. Wiles 560 of StreamComm for his assistance in developing 561 the proposed standard for Speex use in H.323 applications. 563 The authors would also like to thank the following members of the 564 Speex and AVT communities for their input: Ross Finlayson, Federico 565 Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund, Colin 566 Perkins, Ivo Emanuel Goncalves. 568 Thanks to former authors of this document; Simon Morlat, Roger 569 Hardiman, Phil Kerr. 571 9. Copying conditions 573 The authors agree to grant third parties the irrevocable right to 574 copy, use and distribute the work, with or without modification, in 575 any medium, without royalty, provided that, unless separate 576 permission is granted, redistributed modified works do not contain 577 misleading author, version, name of work, or endorsement information. 579 10. References 581 10.1. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 587 Jacobson, "RTP: A Transport Protocol for Real-Time 588 Applications", STD 64, RFC 3550, July 2003. 590 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 591 Description Protocol", RFC 4566, July 2006. 593 10.2. Informative References 595 [CELP] "CELP, U.S. Federal Standard 1016.", National Technical 596 Information Service (NTIS) website http://www.ntis.gov/. 598 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 599 Registration Procedures", BCP 13, RFC 4288, December 2005. 601 [speex_manual] 602 Valin, J., "The Speex Codec Manual", Speex 603 website http://www.speex.org/docs/. 605 Authors' Addresses 607 Greg Herlein 608 2034 Filbert Street 609 San Francisco, California 94123 610 United States 612 Email: gherlein@herlein.com 614 Jean-Marc Valin 615 CSIRO 616 PO Box 76 617 Epping, NSW 1710 618 Australia 620 Email: jean-marc.valin@usherbrooke.ca 622 Alfred E. Heggestad 623 Creytiv.com 624 Biskop J. Nilssonsgt. 20a 625 Oslo 0659 626 Norway 628 Email: aeh@db.org 630 Aymeric Moizard 631 Antisip 632 4 Quai Perrache 633 Lyon 69002 634 France 636 Email: jack@atosc.org 638 Full Copyright Statement 640 Copyright (C) The IETF Trust (2008). 642 This document is subject to the rights, licenses and restrictions 643 contained in BCP 78, and except as set forth therein, the authors 644 retain all their rights. 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 649 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 650 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 651 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Intellectual Property 656 The IETF takes no position regarding the validity or scope of any 657 Intellectual Property Rights or other rights that might be claimed to 658 pertain to the implementation or use of the technology described in 659 this document or the extent to which any license under such rights 660 might or might not be available; nor does it represent that it has 661 made any independent effort to identify any such rights. Information 662 on the procedures with respect to rights in RFC documents can be 663 found in BCP 78 and BCP 79. 665 Copies of IPR disclosures made to the IETF Secretariat and any 666 assurances of licenses to be made available, or the result of an 667 attempt made to obtain a general license or permission for the use of 668 such proprietary rights by implementers or users of this 669 specification can be obtained from the IETF on-line IPR repository at 670 http://www.ietf.org/ipr. 672 The IETF invites any interested party to bring to its attention any 673 copyrights, patents or patent applications, or other proprietary 674 rights that may cover technology that may be required to implement 675 this standard. Please address the information to the IETF at 676 ietf-ipr@ietf.org. 678 Acknowledgment 680 Funding for the RFC Editor function is provided by the IETF 681 Administrative Support Activity (IASA).