Updated Blackfin version of compute_pitch_error()
[speexdsp.git] / doc / draft-ietf-avt-rtp-speex-00.txt
1
2
3
4 AVT Working Group                                             G. Herlein
5 Internet-Draft                                                 S. Morlat
6 Expires: April 15, 2006                                     J. Jean-Marc
7                                                              R. Hardiman
8                                                                  P. Kerr
9                                                         October 12, 2005
10
11
12                       draft-ietf-avt-rtp-speex-00
13                  RTP Payload Format for the Speex Codec
14
15 Status of this Memo
16
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.
21
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.
26
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."
31
32    The list of current Internet-Drafts can be accessed at
33    http://www.ietf.org/ietf/1id-abstracts.txt.
34
35    The list of Internet-Draft Shadow Directories can be accessed at
36    http://www.ietf.org/shadow.html.
37
38    This Internet-Draft will expire on April 15, 2006.
39
40 Copyright Notice
41
42    Copyright (C) The Internet Society (2005).
43
44 Abstract
45
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).
51
52
53
54
55 Herlein, et al.          Expires April 15, 2006                 [Page 1]
56 \f
57 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
58
59
60 Editors Note
61
62    All references to RFC XXXX are to be replaced by references to the
63    RFC number of this memo, when published.
64
65 Table of Contents
66
67    1.   Conventions used in this document  . . . . . . . . . . . . .   3
68    2.   Overview of the Speex Codec  . . . . . . . . . . . . . . . .   3
69    3.   RTP payload format for Speex . . . . . . . . . . . . . . . .   3
70    4.   RTP Header . . . . . . . . . . . . . . . . . . . . . . . . .   3
71    5.   Speex payload  . . . . . . . . . . . . . . . . . . . . . . .   5
72    6.   Example Speex packet . . . . . . . . . . . . . . . . . . . .   6
73    7.   Multiple Speex frames in a RTP packet  . . . . . . . . . . .   6
74    8.   MIME registration of Speex . . . . . . . . . . . . . . . . .   7
75    9.   SDP usage of Speex . . . . . . . . . . . . . . . . . . . . .   8
76    10.  ITU H.323 Use of Speex . . . . . . . . . . . . . . . . . . .  10
77    11.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
78    12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11
79    13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
80      13.1   Normative References . . . . . . . . . . . . . . . . . .  11
81      13.2   Informative References . . . . . . . . . . . . . . . . .  12
82         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  12
83         Intellectual Property and Copyright Statements . . . . . . .  14
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111 Herlein, et al.          Expires April 15, 2006                 [Page 2]
112 \f
113 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
114
115
116 1.  Conventions used in this document
117
118    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120    document are to be interpreted as described in RFC 2119 [1].
121
122 2.  Overview of the Speex Codec
123
124    Speex is based on the CELP [8] encoding technique with support for
125    either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra-
126    wideband (nominal 32kHz), and (non-optimal) rates up to 48 kHz
127    sampling also available.  The main characteristics can be summarized
128    as follows:
129
130    o  Free software/open-source
131    o  Integration of wideband and narrowband in the same bit-stream
132    o  Wide range of bit-rates available
133    o  Dynamic bit-rate switching and variable bit-rate (VBR)
134    o  Voice Activity Detection (VAD, integrated with VBR)
135    o  Variable complexity
136
137 3.  RTP payload format for Speex
138
139    For RTP based transportation of Speex encoded audio the standard RTP
140    header [2] is followed by one or more payload data blocks.  An
141    optional padding terminator may also be used.
142
143         0                   1                   2                   3
144         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
145        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
146        |                         RTP Header                            |
147        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
148        |                 one or more frames of Speex ....              |
149        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
150        |        one or more frames of Speex ....       |    padding    |
151        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
152
153
154 4.  RTP Header
155
156
157
158
159
160
161
162
163
164
165
166
167 Herlein, et al.          Expires April 15, 2006                 [Page 3]
168 \f
169 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
170
171
172         0                   1                   2                   3
173         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
174        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
175        |V=2|P|X|  CC   |M|     PT      |       sequence number         |
176        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
177        |                           timestamp                           |
178        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
179        |           synchronization source (SSRC) identifier            |
180        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
181        |            contributing source (CSRC) identifiers             |
182        |                              ...                              |
183        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
184
185    The RTP header begins with an octet of fields (V, P, X, and CC) to
186    support specialized RTP uses (see [2] and [5] for details).  For
187    Speex the following values are used.
188
189    Version (V): 2 bits
190
191    This field identifies the version of RTP.  The version used by this
192    specification is two [2].
193
194    Padding (P): 1 bit
195
196    If the padding bit is set, the packet contains one or more additional
197    padding octets at the end which are not part of the payload.
198
199    Extension (X): 1 bit
200
201    If the extension, X, bit is set, the fixed header MUST be followed by
202    exactly one header extension, with a format defined in Section 5.3.1.
203    of [2].
204
205    CSRC count (CC): 4 bits
206
207    The CSRC count contains the number of CSRC identifiers.
208
209    Marker (M): 1 bit
210
211    The M bit indicates if the packet contains comfort noise.  This field
212    is used in conjunction with the cng SDP attribute and conforms to
213    Section 4.1. of [5].
214
215    Payload Type (PT): 7 bits
216
217    An RTP profile for a class of applications is expected to assign a
218    payload type for this format, or a dynamically allocated payload type
219    SHOULD be chosen which designates the payload as Speex.
220
221
222
223 Herlein, et al.          Expires April 15, 2006                 [Page 4]
224 \f
225 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
226
227
228    Sequence number: 16 bits
229
230    The sequence number increments by one for each RTP data packet sent,
231    and may be used by the receiver to detect packet loss and to restore
232    packet sequence.  This field is detailed further in [2].
233
234    Timestamp: 32 bits
235
236    A timestamp representing the sampling time of the first sample of the
237    first Speex packet in the RTP packet.  The clock frequency MUST be
238    set to the sample rate of the encoded audio data.  Speex uses 20 msec
239    frames and a variable sampling rate clock.  The RTP timestamp MUST be
240    in units of 1/X of a second where X is the sample rate used.  Speex
241    uses a nominal 8kHz sampling rate for narrowband use, a nominal 16kHz
242    sampling rate for wideband use, and a nominal 32kHz sampling rate for
243    ultra-wideband use.
244
245    SSRC/CSRC identifiers:
246
247    These two fields, 32 bits each with one SSRC field and a maximum of
248    16 CSRC fields, are as defined in [2].
249
250 5.  Speex payload
251
252    For the purposes of packetizing the bit stream in RTP, it is only
253    necessary to consider the sequence of bits as output by the Speex
254    encoder [7], and present the same sequence to the decoder.  The
255    payload format described here maintains this sequence.
256
257    A typical Speex frame, encoded at the maximum bitrate, is approx. 110
258    octets and the total number of Speex frames SHOULD be kept less than
259    the path MTU to prevent fragmentation.  Speex frames MUST NOT be
260    fragmented across multiple RTP packets,
261
262    An RTP packet MAY contain Speex frames of the same bit rate or of
263    varying bit rates, since the bit-rate for a frame is conveyed in band
264    with the signal.
265
266    The encoding and decoding algorithm can change the bit rate at any 20
267    msec frame boundary, with the bit rate change notification provided
268    in-band with the bit stream.  Each frame contains both "mode"
269    (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate)
270    information in the bit stream.  No out-of-band notification is
271    required for the decoder to process changes in the bit rate sent by
272    the encoder.
273
274    It is RECOMMENDED that values of 8000, 16000 and 32000 be used for
275    normal internet telephony applications, though the sample rate is
276
277
278
279 Herlein, et al.          Expires April 15, 2006                 [Page 5]
280 \f
281 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
282
283
284    supported at rates as low as 6000 Hz and as high as 48 kHz.
285
286    The RTP payload MUST be padded to provide an integer number of octets
287    as the payload length.  These padding bits are LSB aligned in network
288    octet order and consist of a 0 followed by all ones (until the end of
289    the octet).  This padding is only required for the last frame in the
290    packet, and only to ensure the packet contents ends on an octet
291    boundary.
292
293 6.  Example Speex packet
294
295    In the example below we have a single Speex frame with 5 bits of
296    padding to ensure the packet size falls on an octet boundary.
297
298        0                   1                   2                   3
299        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
300       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
301       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
302       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
303       |                           timestamp                           |
304       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
305       |         synchronization source (SSRC) identifier              |
306       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
307
308        0                   1                   2                   3
309        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
310       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
311       |         contributing source (CSRC) identifiers                |
312       |                              ...                              |
313       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
314       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
315       |                        ..speex data..                         |
316       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
317       |                        ..speex data..               |0 1 1 1 1|
318       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
319
320
321 7.  Multiple Speex frames in a RTP packet
322
323    Below is an example of two Speex frames contained within one RTP
324    packet.  The Speex frame length in this example fall on an octet
325    boundary so there is no padding.
326
327    Speex codecs [7] are able to detect the bitrate from the payload and
328    are responsible for detecting the 20 msec boundaries between each
329    frame.
330
331
332
333
334
335 Herlein, et al.          Expires April 15, 2006                 [Page 6]
336 \f
337 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
338
339
340        0                   1                   2                   3
341        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
342       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
343       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
344       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
345       |                           timestamp                           |
346       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
347       |         synchronization source (SSRC) identifier              |
348       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
349       |         contributing source (CSRC) identifiers                |
350       |                              ...                              |
351       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
352       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
353       |                        ..speex data..                         |
354       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
355       |        ..speex data..         |        ..speex data..         |
356       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
357       |                        ..speex data..                         |
358       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
359
360
361 8.  MIME registration of Speex
362
363    Full definition of the MIME [3] type for Speex will be part of the
364    Ogg Vorbis MIME type definition application [6].
365
366    MIME media type name: audio
367
368    MIME subtype: speex
369
370    Optional parameters:
371
372    Required parameters: to be included in the Ogg MIME specification.
373
374    Encoding considerations:
375
376    This type is only defined for transfer via HTTP as specified in RFC
377    XXXX.
378
379    Security Considerations:
380
381    See Section 6 of RFC 3047.
382
383    Interoperability considerations: none
384
385    Published specification:
386
387    Applications which use this media type:
388
389
390
391 Herlein, et al.          Expires April 15, 2006                 [Page 7]
392 \f
393 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
394
395
396    Additional information: none
397
398    Person & email address to contact for further information:
399
400       Greg Herlein <gherlein@herlein.com>
401       Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
402
403    Intended usage: COMMON
404
405    Author/Change controller:
406
407       Author:  Greg Herlein <gherlein@herlein.com>
408       Change controller: Greg Herlein <gherlein@herlein.com>
409       Change controller: IETF AVT Working Group
410
411    This transport type signifies that the content is to be interpreted
412    according to this document if the contents are transmitted over RTP.
413    Should this transport type appear over a lossless streaming protocol
414    such as TCP, the content encapsulation should be interpreted as an
415    Ogg Stream in accordance with [6], with the exception that the
416    content of the Ogg Stream may be assumed to be Speex audio and Speex
417    audio only.
418
419 9.  SDP usage of Speex
420
421    When conveying information by SDP [4], the encoding name MUST be set
422    to "speex".  An example of the media representation in SDP for
423    offering a single channel of Speex at 8000 samples per second might
424    be:
425
426       m=audio 8088 RTP/AVP 97
427       a=rtpmap:97 speex/8000
428
429    Note that the RTP payload type code of 97 is defined in this media
430    definition to be 'mapped' to the speex codec at an 8kHz sampling
431    frequency using the 'a=rtpmap' line.  Any number from 96 to 127 could
432    have been chosen (the allowed range for dynamic types).
433
434    The value of the sampling frequency is typically 8000 for narrow band
435    operation, 16000 for wide band operation, and 32000 for ultra-wide
436    band operation.
437
438    If for some reason the offerer has bandwidth limitations, the client
439    may use the "b=" header, as explained in SDP [4].  The following
440    example illustrates the case where the offerer cannot receive more
441    than 10 kbit/s.
442
443
444
445
446
447 Herlein, et al.          Expires April 15, 2006                 [Page 8]
448 \f
449 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
450
451
452       m=audio 8088 RTP/AVP 97
453       b=AS:10
454       a=rtmap:97 speex/8000
455
456    In this case, if the remote part agrees, it should configure its
457    Speex encoder so that it does not use modes that produce more than 10
458    kbit/s.  Note that the "b=" constraint also applies on all payload
459    types that may be proposed in the media line ("m=").
460
461    An other way to make recommendations to the remote Speex encoder is
462    to use its specific parameters via the a=fmtp: directive.  The
463    following parameters are defined for use in this way:
464
465       ptime: duration of each packet in milliseconds.
466
467       sr:    actual sample rate in Hz.
468
469       ebw:   encoding bandwidth - either 'narrow' or 'wide' or 'ultra'
470       (corresponds to nominal 8000, 16000, and 32000 Hz sampling rates).
471
472       vbr:   variable bit rate  - either 'on' 'off' or 'vad' (defaults
473       to off).  If on, variable bit rate is enabled.  If off, disabled.
474       If set to 'vad' then constant bit rate is used but silence will be
475       encoded with special short frames to indicate a lack of voice for
476       that period.
477
478       cng:   comfort noise generation - either 'on' or 'off'.  If off
479       then silence frames will be silent; if 'on' then those frames will
480       be filled with comfort noise.
481
482       mode:  Speex encoding mode.  Can be {1,2,3,4,5,6,any} defaults to
483       3 in narrowband, 6 in wide and ultra-wide.
484
485
486    Examples:
487
488       m=audio 8008 RTP/AVP 97
489       a=rtpmap:97 speex/8000
490       a=fmtp:97 mode=4
491
492    This examples illustrate an offerer that wishes to receive a Speex
493    stream at 8000Hz, but only using speex mode 4.
494
495    Several Speex specific parameters can be given in a single a=fmtp
496    line provided that they are separated by a semi-colon:
497
498
499
500
501
502
503 Herlein, et al.          Expires April 15, 2006                 [Page 9]
504 \f
505 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
506
507
508       a=fmtp:97 mode=any;mode=1
509
510    The offerer may indicate that it wishes to send variable bit rate
511    frames with comfort noise:
512
513       m=audio 8088 RTP/AVP 97
514       a=rtmap:97 speex/8000
515       a=fmtp:97 vbr=on;cng=on
516
517    The "ptime" attribute is used to denote the packetization interval
518    (ie, how many milliseconds of audio is encoded in a single RTP
519    packet).  Since Speex uses 20 msec frames, ptime values of multiples
520    of 20 denote multiple Speex frames per packet.  Values of ptime which
521    are not multiples of 20 MUST be ignored and clients MUST use the
522    default value of 20 instead.
523
524    In the example below the ptime value is set to 40, indicating that
525    there are 2 frames in each packet.
526
527       m=audio 8008 RTP/AVP 97
528       a=rtpmap:97 speex/8000
529       a=ptime:40
530
531    Note that the ptime parameter applies to all payloads listed in the
532    media line and is not used as part of an a=fmtp directive.
533
534    Values of ptime not multiple of 20 msec are meaningless, so the
535    receiver of such ptime values MUST ignore them.  If during the life
536    of an RTP session the ptime value changes, when there are multiple
537    Speex frames for example, the SDP value must also reflect the new
538    value.
539
540    Care must be taken when setting the value of ptime so that the RTP
541    packet size does not exceed the path MTU.
542
543 10.  ITU H.323 Use of Speex
544
545    It is outside the scope of this document to cover the use of Speex
546    and H.323, more details may be found on the Speex website [9].
547
548 11.  Security Considerations
549
550    RTP packets using the payload format defined in this specification
551    are subject to the security considerations discussed in the RTP
552    specification [2], and any appropriate RTP profile.  This implies
553    that confidentiality of the media streams is achieved by encryption.
554    Because the data compression used with this payload format is applied
555    end-to-end, encryption may be performed after compression so there is
556
557
558
559 Herlein, et al.          Expires April 15, 2006                [Page 10]
560 \f
561 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
562
563
564    no conflict between the two operations.
565
566    A potential denial-of-service threat exists for data encodings using
567    compression techniques that have non-uniform receiver-end
568    computational load.  The attacker can inject pathological datagrams
569    into the stream which are complex to decode and cause the receiver to
570    be overloaded.  However, this encoding does not exhibit any
571    significant non-uniformity.
572
573    As with any IP-based protocol, in some circumstances a receiver may
574    be overloaded simply by the receipt of too many packets, either
575    desired or undesired.  Network-layer authentication may be used to
576    discard packets from undesired sources, but the processing cost of
577    the authentication itself may be too high.
578
579 12.  Acknowledgments
580
581    The authors would like to thank Equivalence Pty Ltd of Australia for
582    their assistance in attempting to standardize the use of Speex in
583    H.323 applications, and for implementing Speex in their open source
584    OpenH323 stack.  The authors would also like to thank Brian C. Wiles
585    <brian@streamcomm.com> of StreamComm for his assistance in developing
586    the proposed standard for Speex use in H.323 applications.
587
588    The authors would also like to thank the following members of the
589    Speex and AVT communities for their input:  Ross Finlayson, Federico
590    Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund.
591
592 13.  References
593
594 13.1  Normative References
595
596    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
597         Levels", RFC 2119.
598
599    [2]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
600         "RTP: A Transport Protocol for real-time applications",
601         RFC 3550.
602
603    [3]  "Multipurpose Internet Mail Extensions (MIME) Part One: Format
604         of Internet Message Bodies", RFC 2045.
605
606    [4]  Jacobson, V. and M. Handley, "SDP: Session Description
607         Protocol", RFC 2327.
608
609    [5]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
610         Conferences with Minimal Control.", RFC 3551.
611
612
613
614
615 Herlein, et al.          Expires April 15, 2006                [Page 11]
616 \f
617 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
618
619
620    [6]  Walleij, L., "The application/ogg Media Type", RFC 3534.
621
622 13.2  Informative References
623
624    [7]  "Speexenc/speexdec, reference command-line encoder/decoder",
625         Speex website http://www.speex.org/.
626
627    [8]  "CELP, U.S. Federal Standard 1016.", National Technical
628         Information Service (NTIS) website http://www.ntis.gov/.
629
630    [9]  "ITU H.323/H.245 Use of Speex", Speex
631         website http://www.speex.org/itu/.
632
633
634 Authors' Addresses
635
636    Greg Herlein
637    2034 Filbert Street
638    San Francisco, California  94123
639    United States
640
641    Email: gherlein@herlein.com
642
643
644    Simon Morlat
645    35, av de Vizille App 42
646    Grenoble  38000
647    France
648
649    Email: simon.morlat@linphone.org
650
651
652    Jean-Marc Valin
653    Department of Electrical and Computer Engineering
654    University of Sherbrooke
655    2500 blvd Universite
656    Sherbrooke, Quebec  J1K 2R1
657    Canada
658
659    Email: jean-marc.valin@usherbrooke.ca
660
661
662
663
664
665
666
667
668
669
670
671 Herlein, et al.          Expires April 15, 2006                [Page 12]
672 \f
673 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
674
675
676    Roger Hardiman
677    49 Nettleton Road
678    Cheltenham, Gloucestershire  GL51 6NR
679    England
680
681    Email: roger@freebsd.org
682
683
684    Phil Kerr
685    England
686
687    Email: phil@plus24.com
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727 Herlein, et al.          Expires April 15, 2006                [Page 13]
728 \f
729 Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
730
731
732 Intellectual Property Statement
733
734    The IETF takes no position regarding the validity or scope of any
735    Intellectual Property Rights or other rights that might be claimed to
736    pertain to the implementation or use of the technology described in
737    this document or the extent to which any license under such rights
738    might or might not be available; nor does it represent that it has
739    made any independent effort to identify any such rights.  Information
740    on the procedures with respect to rights in RFC documents can be
741    found in BCP 78 and BCP 79.
742
743    Copies of IPR disclosures made to the IETF Secretariat and any
744    assurances of licenses to be made available, or the result of an
745    attempt made to obtain a general license or permission for the use of
746    such proprietary rights by implementers or users of this
747    specification can be obtained from the IETF on-line IPR repository at
748    http://www.ietf.org/ipr.
749
750    The IETF invites any interested party to bring to its attention any
751    copyrights, patents or patent applications, or other proprietary
752    rights that may cover technology that may be required to implement
753    this standard.  Please address the information to the IETF at
754    ietf-ipr@ietf.org.
755
756
757 Disclaimer of Validity
758
759    This document and the information contained herein are provided on an
760    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
761    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
762    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
763    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
764    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
765    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
766
767
768 Copyright Statement
769
770    Copyright (C) The Internet Society (2005).  This document is subject
771    to the rights, licenses and restrictions contained in BCP 78, and
772    except as set forth therein, the authors retain all their rights.
773
774
775 Acknowledgment
776
777    Funding for the RFC Editor function is currently provided by the
778    Internet Society.
779
780
781
782
783 Herlein, et al.          Expires April 15, 2006                [Page 14]
784 \f