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