Patch by David Rowe: normalize16() on Blackfin now writes data 16-bit at a time
[speexdsp.git] / doc / draft-herlein-avt-rtp-speex-00.txt
1
2
3
4
5 Internet Engineering Task Force                          Greg Herlein
6 Internet Draft                                        Jean-Marc Valin
7 draft-herlein-avt-rtp-speex-00.txt                       Simon Morlat
8 March 3, 2004                                          Roger Hardiman
9 Expires: September 3, 2004                                  Phil Kerr
10
11
12                  RTP Payload Format for the Speex Codec
13
14 Status of this Memo
15
16    This document is an Internet-Draft and is in full conformance with
17    all provisions of Section 10 of RFC 2026.
18
19    Internet-Drafts are working documents of the Internet Engineering
20    Task Force (IETF), its areas, and its working groups.  Note that
21    other groups may also distribute working documents as Internet-
22    Drafts.
23
24    Internet-Drafts are draft documents valid for a maximum of six
25    months and may be updated, replaced, or obsoleted by other
26    documents at any time.  It is inappropriate to use Internet-Drafts
27    as reference material or to cite them other than as "work in
28    progress".
29
30    The list of current Internet-Drafts can be accessed at
31    http://www.ietf.org/ietf/1id-abstracts.txt
32
33    To view the list Internet-Draft Shadow Directories, see
34    http://www.ietf.org/shadow.html.
35
36
37 Copyright Notice
38
39    Copyright (C) The Internet Society (2003).  All Rights Reserved.
40
41
42 Abstract
43
44    Speex is an open-source voice codec suitable for use in Voice over
45    IP (VoIP) type applications.  This document describes the payload
46    format for Speex generated bit streams within an RTP packet.  Also
47    included here are the necessary details for the use of Speex with
48    the Session Description Protocol (SDP) and a preliminary method of
49    using Speex within H.323 applications.
50
51
52 1. Conventions used in this document
53
54    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
55    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
56    document are to be interpreted as described in RFC 2119 [5].
57
58 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 1]
59 ^L
60 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
61
62
63 2. Overview of the Speex Codec
64
65    Speex is based on the CELP [12] encoding technique with support for 
66    either narrowband (nominal 8kHz), wideband (nominal 16kHz) or 
67    ultra-wideband (nominal 32kHz), and (non-optimal) rates up to 48 kHz 
68    sampling also available.  The main characteristics can be summarized 
69    as follows:
70
71    o  Free software/open-source
72    o  Integration of wideband and narrowband in the same bit-stream
73    o  Wide range of bit-rates available
74    o  Dynamic bit-rate switching and variable bit-rate (VBR)
75    o  Voice Activity Detection (VAD, integrated with VBR)
76    o  Variable complexity
77
78
79 3. RTP payload format for Speex
80
81    For RTP based transportation of Speex encoded audio the standard 
82    RTP header [2] is followed by one or more payload data blocks. 
83    An optional padding terminator may also be used. 
84
85       0                   1                   2                   3
86       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
87      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
88      |                         RTP Header                            |
89      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
90      |                 one or more frames of Speex ....              |
91      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
92      |        one or more frames of Speex ....       |    padding    |
93      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
94
95
96 3.1 RTP Header
97
98       0                   1                   2                   3
99       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
100      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
101      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
102      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
103      |                           timestamp                           |
104      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
105      |           synchronization source (SSRC) identifier            |
106      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
107      |            contributing source (CSRC) identifiers             |
108      |                              ...                              |
109      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
110
111
112    The RTP header begins with an octet of fields (V, P, X, and CC) to   
113    support specialized RTP uses (see [8] and [9] for details). For 
114    Speex the following values are used.
115
116 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 2]
117 ^L
118 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
119
120
121    Version (V): 2 bits
122       This field identifies the version of RTP. The version
123       used by this specification is two (2).
124
125    Padding (P): 1 bit
126       If the padding bit is set, the packet contains one or more
127       additional padding octets at the end which are not part of
128       the payload.  P is set if the total packet size is less than 
129       the MTU.  
130
131    Extension (X): 1 bit
132       If the extension, X, bit is set, the fixed header MUST be 
133       followed by exactly one header extension, with a format defined 
134       in Section 5.3.1. of [8], 
135
136    CSRC count (CC): 4 bits
137       The CSRC count contains the number of CSRC identifiers.
138
139    Marker (M): 1 bit
140       The M bit indicates if the packet contains comfort noise.  This 
141       field is used in conjunction with the cng SDP attribute and is 
142       detailed further in section 5 below.  In normal usage this bit 
143       is set if the packet contains comfort noise.
144
145    Payload Type (PT): 7 bits
146       An RTP profile for a class of applications is expected to assign 
147       a payload type for this format, or a dynamically allocated 
148       payload type SHOULD be chosen which designates the payload as 
149       Speex.
150
151    Sequence number: 16 bits
152       The sequence number increments by one for each RTP data packet
153       sent, and may be used by the receiver to detect packet loss and
154       to restore packet sequence.  This field is detailed further in
155       [2].
156
157    Timestamp: 32 bits
158       A timestamp representing the sampling time of the first sample of
159       the first Speex packet in the RTP packet.  The clock frequency 
160       MUST be set to the sample rate of the encoded audio data.
161
162       Speex uses 20 msec frames and a variable sampling rate clock.  
163       The RTP timestamp MUST be in units of 1/X of a second where X 
164       is the sample rate used.  Speex uses a nominal 8kHz sampling rate
165       for narrowband use, a nominal 16kHz sampling rate for wideband use, 
166       and a nominal 32kHz sampling rate for ultra-wideband use.
167
168    SSRC/CSRC identifiers: 
169       These two fields, 32 bits each with one SSRC field and a maximum 
170       of 16 CSRC fields, are as defined in [2].  
171
172
173
174 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 3]
175 ^L
176 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
177
178
179 3.2 Speex payload
180
181    For the purposes of packetizing the bit stream in RTP, it is only
182    necessary to consider the sequence of bits as output by the Speex
183    encoder [11], and present the same sequence to the decoder.  The 
184    payload format described here maintains this sequence.  
185
186    A typical Speex frame, encoded at the maximum bitrate, is approx.
187    110 octets and the total number of Speex frames SHOULD be kept 
188    less than the path MTU to prevent fragmentation.  Speex frames MUST
189    NOT be fragmented across multiple RTP packets,
190
191    An RTP packet MAY contain Speex frames of the same bit rate or of
192    varying bit rates, since the bit-rate for a frame is conveyed in
193    band with the signal.
194
195    The encoding and decoding algorithm can change the bit rate at any
196    20 msec frame boundary, with the bit rate change notification provided
197    in-band with the bit stream.  Each frame contains both "mode" 
198    (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate) 
199    information in the bit stream.  No out-of-band notification is 
200    required for the decoder to process changes in the bit rate sent 
201    by the encoder.
202
203    It is RECOMMENDED that values of 8000, 16000 and 32000 be used 
204    for normal internet telephony applications, though the sample 
205    rate is supported at rates as low as 6000 Hz and as high as 
206    48 kHz.
207
208    The RTP payload MUST be padded to provide an integer number of
209    octets as the payload length.  These padding bits are LSB aligned
210    in network byte order and consist of a 0 followed by all ones
211    (until the end of the octet).  This padding is only required for
212    the last frame in the packet, and only to ensure the packet
213    contents ends on an octet boundary.
214
215
216 3.2.1 Example Speex packet
217
218    In the example below we have a single Speex frame with 5 bits
219    of padding to ensure the packet size falls on an octet boundary.
220
221     0                   1                   2                   3
222     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
223    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
224    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
225    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
226    |                           timestamp                           |
227    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
228    |         synchronization source (SSRC) identifier              |
229    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
230
231
232 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 4]
233 ^L
234 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
235
236
237     0                   1                   2                   3
238     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
239    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
240    |         contributing source (CSRC) identifiers                |
241    |                              ...                              |
242    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
243    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244    |                        ..speex data..                         |
245    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
246    |                        ..speex data..               |0 1 1 1 1|
247    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
248
249
250 3.4 Multiple Speex frames in a RTP packet
251
252    Below is an example of two Speex frames contained within one RTP 
253    packet.  The Speex frame length in this example fall on an octet
254    boundary so there is no padding.
255
256    Speex codecs [11] are able to detect the the bitrate from the
257    payload and are responsible for detecting the 20 msec boundaries
258    between each frame.
259
260     0                   1                   2                   3
261     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
262    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
263    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
264    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
265    |                           timestamp                           |
266    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
267    |         synchronization source (SSRC) identifier              |
268    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
269    |         contributing source (CSRC) identifiers                |
270    |                              ...                              |
271    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
272    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
273    |                        ..speex data..                         |
274    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
275    |        ..speex data..         |        ..speex data..         |
276    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
277    |                        ..speex data..                         |
278    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
279
280
281 4. MIME registration of Speex
282
283    Full definition of the MIME type for Speex will be part of the Ogg
284    Vorbis MIME type definition application [10].  
285
286    MIME media type name: audio
287
288    MIME subtype: speex
289
290 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 5]
291 ^L
292 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
293
294
295    Optional parameters:
296
297    Required parameters: to be included in the Ogg MIME specification.
298
299    Encoding considerations:
300
301    Security Considerations:
302          See Section 6 of RFC 3047.
303
304    Interoperability considerations: none
305
306    Published specification:  
307
308    Applications which use this media type:
309
310    Additional information: none
311
312    Person & email address to contact for further information:
313          Greg Herlein <gherlein@herlein.com>
314          Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca>
315
316    Intended usage: COMMON
317
318    Author/Change controller:
319          Author:  Greg Herlein <gherlein@herlein.com>
320          Change controller: Greg Herlein <gherlein@herlein.com>
321
322    This transport type signifies that the content is to be interpreted
323    according to this document if the contents are transmitted over RTP. 
324    Should this transport type appear over a lossless streaming protocol
325    such as TCP, the content encapsulation should be interpreted as an 
326    Ogg Stream in accordance with RFC 3534, with the exception that the
327    content of the Ogg Stream may be assumed to be Speex audio and 
328    Speex audio only.
329
330
331 5. SDP usage of Speex
332
333    When conveying information by SDP [4], the encoding name MUST be
334    set to "speex".  An example of the media representation in SDP for
335    offering a single channel of Speex at 8000 samples per second might
336    be:
337
338         m=audio 8088 RTP/AVP 97
339         a=rtpmap:97 speex/8000
340
341    Note that the RTP payload type code of 97 is defined in this media
342    definition to be 'mapped' to the speex codec at an 8kHz sampling
343    frequency using the 'a=rtpmap' line.  Any number from 96 to 127
344    could have been chosen (the allowed range for dynamic types).  
345
346
347
348 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 6]
349 ^L
350 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
351
352
353    The value of the sampling frequency is typically 8000 for narrow band
354    operation, 16000 for wide band operation, and 32000 for ultra-wide
355    band operation.
356
357    If for some reason the offerer has bandwidth limitations, the client 
358    may use the "b=" header, as explained in SDP [4]. The following example
359    illustrates the case where the offerer cannot receive more than
360    10 kbit/s.
361
362         m=audio 8088 RTP/AVP 97
363         b=AS:10
364         a=rtmap:97 speex/8000
365
366    In this case, if the remote part agrees, it should configure its
367    Speex encoder so that it does not use modes that produce more than
368    10 kbit/s. Note that the "b=" constraint also applies on all
369    payload types that may be proposed in the media line ("m=").
370
371    An other way to make recommendations to the remote Speex encoder
372    is to use its specific parameters via the a=fmtp: directive.  The
373    following parameters are defined for use in this way:
374
375          ptime: duration of each packet in milliseconds.
376
377          sr:    actual sample rate in Hz.
378
379          ebw:   encoding bandwidth - either 'narrow' or 'wide' or 
380                 'ultra' (corresponds to nominal 8000, 16000, and
381                 32000 Hz sampling rates).
382
383          vbr:   variable bit rate  - either 'on' 'off' or 'vad'
384                 (defaults to off).  If on, variable bit rate is
385                 enabled.  If off, disabled.  If set to 'vad' then
386                 constant bit rate is used but silence will be encoded
387                 with special short frames to indicate a lack of voice
388                 for that period.
389
390          cng:   comfort noise generation - either 'on' or 'off'. If
391                 off then silence frames will be silent; if 'on' then
392                 those frames will be filled with comfort noise.
393
394          mode:  Speex encoding mode. Can be {1,2,3,4,5,6,any}
395                 defaults to 3 in narrowband, 6 in wide and ultra-wide.
396
397          penh:  use of perceptual enhancement. 1 indicates 
398                 to the decoder that perceptual enhancement is recommended,
399                 0 indicates that it is not. Defaults to on (1).
400
401
402
403
404
405
406 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 7]
407 ^L
408 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
409
410
411    Examples:
412
413         m=audio 8008 RTP/AVP 97
414         a=rtpmap:97 speex/8000
415         a=fmtp:97 mode=4
416
417    This examples illustrate an offerer that wishes to receive
418    a Speex stream at 8000Hz, but only using speex mode 3.
419  
420    The offerer may suggest to the remote decoder to activate
421    its perceptual enhancement filter like this:
422    
423         m=audio 8088 RTP/AVP 97
424         a=rtmap:97 speex/8000
425         a=fmtp:97 penh=1 
426         
427    Several Speex specific parameters can be given in a single
428    a=fmtp line provided that they are separated by a semi-colon:
429    
430         a=fmtp:97 mode=any;penh=1
431
432    The offerer may indicate that it wishes to send variable bit rate
433    frames with comfort noise:
434
435         m=audio 8088 RTP/AVP 97
436         a=rtmap:97 speex/8000
437         a=fmtp:97 vbr=on;cng=on
438
439    The "ptime" attribute is used to denote the packetization 
440    interval (ie, how many milliseconds of audio is encoded in a 
441    single RTP packet).  Since Speex uses 20 msec frames, ptime values 
442    of multiples of 20 denote multiple Speex frames per packet.  
443    Values of ptime which are not multiples of 20 MUST be ignored 
444    and clients MUST use the default value of 20 instead.
445    
446    In the example below the ptime value is set to 40, indicating that 
447    there are 2 frames in each packet.   
448    
449         m=audio 8008 RTP/AVP 97
450         a=rtpmap:97 speex/8000
451         a=ptime:40
452         
453    Note that the ptime parameter applies to all payloads listed
454    in the media line and is not used as part of an a=fmtp directive.
455
456    Values of ptime not multiple of 20 msec are meaningless, so the 
457    receiver of such ptime values MUST ignore them.  If during the 
458    life of an RTP session the ptime value changes, when there are 
459    multiple Speex frames for example, the SDP value must also reflect 
460    the new value. 
461
462
463
464 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 8]
465 ^L
466 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
467
468
469    Care must be taken when setting the value of ptime so that the 
470    RTP packet size does not exceed the path MTU. 
471
472
473 6. ITU H.323/H.245 Use of Speex
474
475    Application is underway to make Speex a standard ITU codec.
476    However, until that is finalized, Speex MAY be used in H.323 [6] by
477    using a non-standard codec block definition in the H.245 [7] codec
478    capability negotiations.  
479
480
481 6.1 NonStandardMessage format
482
483    For Speex use in H.245 [7] based systems, the fields in the
484    NonStandardMessage should be:
485
486    t35CountryCode   = Hex: B5
487    t35Extension     = Hex: 00
488    manufacturerCode = Hex: 0026
489    [Length of the Binary Sequence (8 bit number)]
490    [Binary Sequence consisting of an ASCII string, no NULL terminator]
491
492    The binary sequence is an ascii string merely for ease of use.
493    The string is not null terminated.  The format of this string is
494
495        speex [optional variables]
496    
497    The optional variables are identical to those used for the SDP
498    a=fmtp strings discussed in section 5 above.  The string is built
499    to be all on one line, each key-value pair separated by a
500    semi-colon.  The optional variables MAY be omitted, which causes
501    the default values to be assumed.  They are:
502
503        ebw=narrow;mode=3;vbr=off;cng=off;ptime=20;sr=8000;penh=no;
504
505    The fifth byte of the block is the length of the binary sequence.
506
507    NOTE:  this method can result in the advertising of a large number
508    of Speex 'codecs' based on the number of variables possible.  For
509    most VoIP applications, use of the default binary sequence of
510    'speex' is RECOMMENDED to be used in addition to all other options.
511    This maximizes the chances that two H.323 based applications that
512    support Speex can find a mutual codec.   
513
514
515 6.2 RTP Payload Types
516
517    Dynamic payload type codes MUST be negotiated 'out-of-band'
518    for the assignment of a dynamic payload type from the
519    range of 96-127.  H.323 applications MUST use the H.245
520    H2250LogicalChannelParameters encoding to accomplish this.  
521
522 Herlein, Valin, et. al.     Expires September 3, 2004            [Page 9]
523 ^L
524 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
525
526
527 7. Security Considerations
528
529    RTP packets using the payload format defined in this specification
530    are subject to the security considerations discussed in the RTP
531    specification [2], and any appropriate RTP profile.  This implies
532    that confidentiality of the media streams is achieved by encryption.
533    Because the data compression used with this payload format is applied
534    end-to-end, encryption may be performed after compression so there is
535    no conflict between the two operations.
536
537    A potential denial-of-service threat exists for data encodings using
538    compression techniques that have non-uniform receiver-end
539    computational load.  The attacker can inject pathological datagrams
540    into the stream which are complex to decode and cause the receiver to
541    be overloaded.  However, this encoding does not exhibit any
542    significant non-uniformity.
543
544    As with any IP-based protocol, in some circumstances a receiver may
545    be overloaded simply by the receipt of too many packets, either
546    desired or undesired.  Network-layer authentication may be used to
547    discard packets from undesired sources, but the processing cost of
548    the authentication itself may be too high.  
549
550
551 8. Normative References
552
553    1.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
554        9, RFC 2026, October 1996.
555
556    2.  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
557        A Transport Protocol for real-time applications", RFC 1889,
558        January 1996.
559
560    3.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
561        Extensions (MIME) Part One: Format of Internet Message Bodies",
562        RFC 2045, November 1996.
563
564    4.  Handley, M. and V. Jacobson, "SDP: Session Description 
565        Protocol", RFC 2327, April 1998.
566
567    5.  Bradner, S., "Key words for use in RFCs to Indicate Requirement
568        Levels", BCP 14, RFC 2119, March 1997.
569
570    6.  ITU-T Recommendation H.323.  "Packet-based Multimedia 
571        Communications Systems," 1998.
572
573    7.  ITU-T Recommendation H.245 (1998), "Control of communications
574        between Visual Telephone Systems and Terminal Equipment".
575
576    8.  RTP: A transport protocol for real-time applications. Work   
577        in progress, draft-ietf-avt-rtp-new-12.txt.
578
579 Herlein, Valin, et. al.   Expires September 3, 2004             [Page 10]
580 ^L
581 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
582
583
584    9.  RTP Profile for Audio and Video Conferences with Minimal  
585        Control.  Work in progress, draft-ietf-avt-profile-new-13.txt.
586
587    10. L. Walleij, "The application/ogg Media Type", RFC 3534, May 
588        2003.
589
590
591 8.1 Informative References
592
593    11. Speexenc/speexdec, reference command-line encoder/decoder, 
594        Speex website, http://www.speex.org/
595  
596    12. CELP, U.S. Federal Standard 1016.  National Technical 
597        Information Service (NTIS) website, http://www.ntis.gov/ 
598
599
600 9. Acknowledgments
601
602    The authors would like to thank Equivalence Pty Ltd of Australia
603    for their assistance in attempting to standardize the use of Speex
604    in H.323 applications, and for implementing Speex in their open
605    source OpenH323 stack.  The authors would also like to thank Brian
606    C. Wiles <brian@streamcomm.com> of StreamComm for his assistance in
607    developing the proposed standard for Speex use in H.323
608    applications.
609
610    The authors would also like to thank the following members of the 
611    Speex and AVT communities for their input:  Ross Finlayson, 
612    Federico Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund.
613
614
615 10. Author's Address
616
617    Greg Herlein <gherlein@herlein.com>
618    2034 Filbert Street
619    San Francisco, CA 
620    United States 94123
621    
622
623    Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca>
624    Department of Electrical and Computer Engineering
625    University of Sherbrooke
626    2500 blvd UniversitüÃü­üÃé
627    Sherbrooke, Quebec, Canada, J1K 2R1
628
629
630    Simon MORLAT <simon.morlat@linphone.org>
631    35, av de Vizille App 42
632    38000 GRENOBLE
633    FRANCE
634
635
636
637
638 Herlein, Valin, et. al.   Expires September 3, 2004             [Page 11]
639 ^L
640 Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
641
642
643    Roger Hardiman <roger@freebsd.org>
644    49 Nettleton Road
645    Cheltenham
646    Gloucestershire
647    GL51 6NR
648    England
649
650
651    Phil Kerr <philkerr@elec.gla.ac.uk>
652    Centre for Music Technology
653    University of Glasgow
654    Glasgow
655    G12 8LT
656    Scotland
657
658
659 10. Full Copyright Statement
660
661    Copyright (C) The Internet Society (2003).  All Rights Reserved.
662
663    This document and translations of it may be copied and furnished to
664    others, and derivative works that comment on or otherwise explain it
665    or assist in its implementation may be prepared, copied, published
666    and distributed, in whole or in part, without restriction of any
667    kind, provided that the above copyright notice and this paragraph are
668    included on all such copies and derivative works.  However, this
669    document itself may not be modified in any way, such as by removing
670    the copyright notice or references to the Internet Society or other
671    Internet organizations, except as needed for the purpose of
672    developing Internet standards in which case the procedures for
673    copyrights defined in the Internet Standards process must be
674    followed, or as required to translate it into languages other than
675    English.
676
677    The limited permissions granted above are perpetual and will not be
678    revoked by the Internet Society or its successors or assigns.
679
680    This document and the information contained herein is provided on an
681    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
682    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
683    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
684    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
685    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
686
687
688 Acknowledgement
689
690    Funding for the RFC Editor function is currently provided by the
691    Internet Society.
692
693
694
695
696 Herlein, Valin, et. al.   Expires September 3, 2004             [Page 12]
697 ^L
698
699