speexdsp: fix SSE2 support
[speexdsp.git] / doc / draft-ietf-avt-rtp-speex-05-tmp.txt
1
2
3
4 AVT                                                           G. Herlein
5 Internet-Draft
6 Intended status: Standards Track                                J. Valin
7 Expires: August 19, 2008                                           CSIRO
8                                                             A. Heggestad
9                                                              Creytiv.com
10                                                               A. Moizard
11                                                                  Antisip
12                                                        February 16, 2008
13
14
15                  RTP Payload Format for the Speex Codec
16                       draft-ietf-avt-rtp-speex-05
17
18 Status of this Memo
19
20    By submitting this Internet-Draft, each author represents that any
21    applicable patent or other IPR claims of which he or she is aware
22    have been or will be disclosed, and any of which he or she becomes
23    aware will be disclosed, in accordance with Section 6 of BCP 79.
24
25    Internet-Drafts are working documents of the Internet Engineering
26    Task Force (IETF), its areas, and its working groups.  Note that
27    other groups may also distribute working documents as Internet-
28    Drafts.
29
30    Internet-Drafts are draft documents valid for a maximum of six months
31    and may be updated, replaced, or obsoleted by other documents at any
32    time.  It is inappropriate to use Internet-Drafts as reference
33    material or to cite them other than as "work in progress."
34
35    The list of current Internet-Drafts can be accessed at
36    http://www.ietf.org/ietf/1id-abstracts.txt.
37
38    The list of Internet-Draft Shadow Directories can be accessed at
39    http://www.ietf.org/shadow.html.
40
41    This Internet-Draft will expire on August 19, 2008.
42
43 Copyright Notice
44
45    Copyright (C) The IETF Trust (2008).
46
47
48
49
50
51
52
53
54
55 Herlein, et al.          Expires August 19, 2008                [Page 1]
56
57 Internet-Draft                    Speex                    February 2008
58
59
60 Abstract
61
62    Speex is an open-source voice codec suitable for use in Voice over IP
63    (VoIP) type applications.  This document describes the payload format
64    for Speex generated bit streams within an RTP packet.  Also included
65    here are the necessary details for the use of Speex with the Session
66    Description Protocol (SDP).
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
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 August 19, 2008                [Page 2]
112
113 Internet-Draft                    Speex                    February 2008
114
115
116 Editors Note
117
118    All references to RFC XXXX are to be replaced by references to the
119    RFC number of this memo, when published.
120
121
122 Table of Contents
123
124    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
125    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
126    3.  RTP usage for Speex  . . . . . . . . . . . . . . . . . . . . .  6
127      3.1.  RTP Speex Header Fields  . . . . . . . . . . . . . . . . .  6
128      3.2.  RTP payload format for Speex . . . . . . . . . . . . . . .  6
129      3.3.  Speex payload  . . . . . . . . . . . . . . . . . . . . . .  6
130      3.4.  Example Speex packet . . . . . . . . . . . . . . . . . . .  7
131      3.5.  Multiple Speex frames in a RTP packet  . . . . . . . . . .  7
132    4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
133      4.1.  Media Type Registration  . . . . . . . . . . . . . . . . .  9
134        4.1.1.  Registration of media type audio/speex . . . . . . . .  9
135    5.  SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . . 12
136      5.1.  Example supporting all modes, prefer mode 4  . . . . . . . 15
137      5.2.  Example supporting only mode 3 and 5 . . . . . . . . . . . 15
138      5.3.  Example with Variable Bit Rate and Comfort Noise . . . . . 15
139      5.4.  Example with Voice Activity Detection  . . . . . . . . . . 15
140      5.5.  Example with Multiple sampling rates . . . . . . . . . . . 15
141      5.6.  Example with ptime and Multiple Speex frames . . . . . . . 16
142      5.7.  Example with Complete Offer/Answer exchange  . . . . . . . 16
143    6.  Implementation Guidelines  . . . . . . . . . . . . . . . . . . 17
144    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
145    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
146    9.  Copying conditions . . . . . . . . . . . . . . . . . . . . . . 20
147    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
148      10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
149      10.2. Informative References . . . . . . . . . . . . . . . . . . 21
150    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
151    Intellectual Property and Copyright Statements . . . . . . . . . . 23
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167 Herlein, et al.          Expires August 19, 2008                [Page 3]
168
169 Internet-Draft                    Speex                    February 2008
170
171
172 1.  Introduction
173
174    Speex is based on the CELP [CELP] encoding technique with support for
175    either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra-
176    wideband (nominal 32kHz).  The main characteristics can be summarized
177    as follows:
178
179    o  Free software/open-source
180
181    o  Integration of wideband and narrowband in the same bit-stream
182
183    o  Wide range of bit-rates available
184
185    o  Dynamic bit-rate switching and variable bit-rate (VBR)
186
187    o  Voice Activity Detection (VAD, integrated with VBR)
188
189    o  Variable complexity
190
191    The Speex codec supports a wide range of bit-rates from 2.15 kbit/s
192    to 44 kbit/s.  In some cases however, it may not be possible for an
193    implementation to include support for all rates (e.g. because of
194    bandwidth, RAM or CPU constraints).  In those cases, to be compliant
195    with this specification, implementations MUST support at least
196    narrowband (8 kHz) encoding and decoding at 8 kbit/s bit-rate
197    (narrowband mode 3).  Support for narrowband at 15 kbit/s (narrowband
198    mode 5) is RECOMMENDED and support for wideband at 27.8 kbit/s
199    (wideband mode 8) is also RECOMMENDED.  The sampling rate MUST be 8,
200    16 or 32 kHz.
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223 Herlein, et al.          Expires August 19, 2008                [Page 4]
224
225 Internet-Draft                    Speex                    February 2008
226
227
228 2.  Terminology
229
230    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
231    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
232    document are to be interpreted as described in RFC2119 [RFC2119] and
233    indicate requirement levels for compliant RTP implementations.
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279 Herlein, et al.          Expires August 19, 2008                [Page 5]
280
281 Internet-Draft                    Speex                    February 2008
282
283
284 3.  RTP usage for Speex
285
286 3.1.  RTP Speex Header Fields
287
288    The RTP header is defined in the RTP specification [RFC3550].  This
289    section defines how fields in the RTP header are used.
290
291       Payload Type (PT): The assignment of an RTP payload type for this
292       packet format is outside the scope of this document; it is
293       specified by the RTP profile under which this payload format is
294       used, or signaled dynamically out-of-band (e.g., using SDP).
295
296       Marker (M) bit: The M bit is set to one on the first packet sent
297       after a silence period, during which packets have not been
298       transmitted contiguously.
299
300       Extension (X) bit: Defined by the RTP profile used.
301
302       Timestamp: A 32-bit word that corresponds to the sampling instant
303       for the first frame in the RTP packet.
304
305 3.2.  RTP payload format for Speex
306
307    The RTP payload for Speex has the format shown in Figure 1.  No
308    additional header fields specific to this payload format are
309    required.  For RTP based transportation of Speex encoded audio the
310    standard RTP header [RFC3550] is followed by one or more payload data
311    blocks.  An optional padding terminator may also be used.
312
313         0                   1                   2                   3
314         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
315        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316        |                         RTP Header                            |
317        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
318        |                 one or more frames of Speex ....              |
319        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
320        |        one or more frames of Speex ....       |    padding    |
321        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
322
323                      Figure 1: RTP payload for Speex
324
325 3.3.  Speex payload
326
327    For the purposes of packetizing the bit stream in RTP, it is only
328    necessary to consider the sequence of bits as output by the Speex
329    encoder [speex_manual], and present the same sequence to the decoder.
330    The payload format described here maintains this sequence.
331
332
333
334
335 Herlein, et al.          Expires August 19, 2008                [Page 6]
336
337 Internet-Draft                    Speex                    February 2008
338
339
340    A typical Speex frame, encoded at the maximum bitrate, is approx. 110
341    octets and the total number of Speex frames SHOULD be kept less than
342    the path MTU to prevent fragmentation.  Speex frames MUST NOT be
343    fragmented across multiple RTP packets,
344
345    An RTP packet MAY contain Speex frames of the same bit rate or of
346    varying bit rates, since the bit-rate for a frame is conveyed in band
347    with the signal.
348
349    The encoding and decoding algorithm can change the bit rate at any 20
350    msec frame boundary, with the bit rate change notification provided
351    in-band with the bit stream.  Each frame contains both sampling rate
352    (narrowband, wideband or ultra-wideband) and "mode" (bit-rate)
353    information in the bit stream.  No out-of-band notification is
354    required for the decoder to process changes in the bit rate sent by
355    the encoder.
356
357    The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz.
358
359    The RTP payload MUST be padded to provide an integer number of octets
360    as the payload length.  These padding bits are LSB aligned in network
361    octet order and consist of a 0 followed by all ones (until the end of
362    the octet).  This padding is only required for the last frame in the
363    packet, and only to ensure the packet contents ends on an octet
364    boundary.
365
366 3.4.  Example Speex packet
367
368    In the example below we have a single Speex frame with 5 bits of
369    padding to ensure the packet size falls on an octet boundary.
370
371        0                   1                   2                   3
372        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
373       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374       |                      RTP Header                               |
375       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
376       |                        ..speex data..                         |
377       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378       |                        ..speex data..               |0 1 1 1 1|
379       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
380
381 3.5.  Multiple Speex frames in a RTP packet
382
383    Below is an example of two Speex frames contained within one RTP
384    packet.  The Speex frame length in this example fall on an octet
385    boundary so there is no padding.
386
387    The Speex decoder [speex_manual] can detect the bitrate from the
388
389
390
391 Herlein, et al.          Expires August 19, 2008                [Page 7]
392
393 Internet-Draft                    Speex                    February 2008
394
395
396    payload and is responsible for detecting the 20 msec boundaries
397    between each frame.
398
399        0                   1                   2                   3
400        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
401       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
402       |                      RTP Header                               |
403       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
404       |                     ..speex frame 1..                         |
405       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406       |       ..speex frame 1..       |      ..speex frame 2..        |
407       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408       |                      ..speex frame 2..                        |
409       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447 Herlein, et al.          Expires August 19, 2008                [Page 8]
448
449 Internet-Draft                    Speex                    February 2008
450
451
452 4.  IANA Considerations
453
454    This document defines the Speex media type.
455
456 4.1.  Media Type Registration
457
458    This section describes the media types and names associated with this
459    payload format.  The section registers the media types, as per
460    RFC4288 [RFC4288]
461
462 4.1.1.  Registration of media type audio/speex
463
464    Media type name: audio
465
466    Media subtype name: speex
467
468    Required parameters:
469
470       rate: RTP timestamp clock rate, which is equal to the sampling
471       rate in Hz.  The sampling rate MUST be either 8000, 16000, or
472       32000.
473
474    Optional parameters:
475
476       ptime: SHOULD be a multiple of 20 msec [RFC4566]
477
478       maxptime: SHOULD be a multiple of 20 msec [RFC4566]
479
480       vbr: variable bit rate - either 'on' 'off' or 'vad' (defaults to
481       off).  If on, variable bit rate is enabled.  If off, disabled.  If
482       set to 'vad' then constant bit rate is used but silence will be
483       encoded with special short frames to indicate a lack of voice for
484       that period.
485
486
487       cng: comfort noise generation - either 'on' or 'off'.  If off then
488       silence frames will be silent; if 'on' then those frames will be
489       filled with comfort noise.
490
491
492       mode: List supported Speex decoding modes.  The valid modes are
493       different for narrowband and wideband, and are defined as follows:
494
495       *  {1,2,3,4,5,6,7,8,any} for narrowband
496
497       *  {0,1,2,3,4,5,6,7,8,9,10,any} for wideband and ultra-wideband
498
499       Several 'mode' parameters can be provided.  In this case, the
500
501
502
503 Herlein, et al.          Expires August 19, 2008                [Page 9]
504
505 Internet-Draft                    Speex                    February 2008
506
507
508       remote party SHOULD configure its encoder using the first
509       supported mode provided.  When 'any' is used, the offerer
510       indicates that it supports all decoding modes.  If the 'mode'
511       parameter is not provided, the mode value is considered to be
512       equivalent to 'mode=3;mode=any' in narrowband and
513       'mode=8;mode=any' in wideband and ultra-wideband.  Note that each
514       Speex frame does contains the mode (or bit-rate) that should be
515       used to decode it.  Thus application MUST be able to decode any
516       Speex frame unless the SDP clearly specify that some modes are not
517       supported. (e.g., by not including 'mode=any')
518
519    Encoding considerations:
520
521       This media type is framed and binary, see section 4.8 in
522       [RFC4288].
523
524    Security considerations: See Section 6
525
526    Interoperability considerations:
527
528       None.
529
530    Published specification:
531
532       RFC XXXX [RFC Editor: please replace by the RFC number of this
533       memo, when published]
534
535    Applications which use this media type:
536
537       Audio streaming and conferencing applications.
538
539    Additional information: none
540
541    Person and email address to contact for further information :
542
543       Alfred E. Heggestad: aeh@db.org
544
545    Intended usage: COMMON
546
547    Restrictions on usage:
548
549       This media type depends on RTP framing, and hence is only defined
550       for transfer via RTP [RFC3550].  Transport within other framing
551       protocols is not defined at this time.
552
553    Author: Alfred E. Heggestad
554
555    Change controller:
556
557
558
559 Herlein, et al.          Expires August 19, 2008               [Page 10]
560
561 Internet-Draft                    Speex                    February 2008
562
563
564       IETF Audio/Video Transport working group delegated from the IESG.
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615 Herlein, et al.          Expires August 19, 2008               [Page 11]
616
617 Internet-Draft                    Speex                    February 2008
618
619
620 5.  SDP usage of Speex
621
622    The information carried in the media type specification has a
623    specific mapping to fields in the Session Description Protocol (SDP)
624    [RFC4566], which is commonly used to describe RTP sessions.  When SDP
625    is used to specify sessions employing the Speex codec, the mapping is
626    as follows:
627
628    o  The media type ("audio") goes in SDP "m=" as the media name.
629
630    o  The media subtype ("speex") goes in SDP "a=rtpmap" as the encoding
631       name.  The required parameter "rate" also goes in "a=rtpmap" as
632       the clock rate.
633
634    o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
635       "a=maxptime" attributes, respectively.
636
637    o  Any remaining parameters go in the SDP "a=fmtp" attribute by
638       copying them directly from the media type string as a semicolon
639       separated list of parameter=value pairs.
640
641    The tables below include the equivalence between modes and bitrates
642    for narrowband, wideband and ultra-wideband.  Also, the corresponding
643    "Speex quality" setting (see SPEEX_SET_QUALITY in The Speex Codec
644    Manual [speex_manual]) is included as an indication.
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671 Herlein, et al.          Expires August 19, 2008               [Page 12]
672
673 Internet-Draft                    Speex                    February 2008
674
675
676                   +------+---------------+-------------+
677                   | mode | Speex quality |   bitrate   |
678                   +------+---------------+-------------+
679                   |   1  |       0       | 2.15 kbit/s |
680                   |      |               |             |
681                   |   2  |       2       | 5.95 kbit/s |
682                   |      |               |             |
683                   |   3  |     3 or 4    | 8.00 kbit/s |
684                   |      |               |             |
685                   |   4  |     5 or 6    | 11.0 kbit/s |
686                   |      |               |             |
687                   |   5  |     7 or 8    | 15.0 kbit/s |
688                   |      |               |             |
689                   |   6  |       9       | 18.2 kbit/s |
690                   |      |               |             |
691                   |   7  |       10      | 24.6 kbit/s |
692                   |      |               |             |
693                   |   8  |       1       | 3.95 kbit/s |
694                   +------+---------------+-------------+
695
696                    Mode vs Bitrate table for narrowband
697
698                                   Table 1
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 August 19, 2008               [Page 13]
728
729 Internet-Draft                    Speex                    February 2008
730
731
732    +------+---------------+------------------+------------------------+
733    | mode | Speex quality | wideband bitrate | ultra wideband bitrate |
734    +------+---------------+------------------+------------------------+
735    |   0  |       0       |    3.95 kbit/s   |       5.75 kbit/s      |
736    |      |               |                  |                        |
737    |   1  |       1       |    5.75 kbit/s   |       7.55 kbit/s      |
738    |      |               |                  |                        |
739    |   2  |       2       |    7.75 kbit/s   |       9.55 kbit/s      |
740    |      |               |                  |                        |
741    |   3  |       3       |    9.80 kbit/s   |       11.6 kbit/s      |
742    |      |               |                  |                        |
743    |   4  |       4       |    12.8 kbit/s   |       14.6 kbit/s      |
744    |      |               |                  |                        |
745    |   5  |       5       |    16.8 kbit/s   |       18.6 kbit/s      |
746    |      |               |                  |                        |
747    |   6  |       6       |    20.6 kbit/s   |       22.4 kbit/s      |
748    |      |               |                  |                        |
749    |   7  |       7       |    23.8 kbit/s   |       25.6 kbit/s      |
750    |      |               |                  |                        |
751    |   8  |       8       |    27.8 kbit/s   |       29.6 kbit/s      |
752    |      |               |                  |                        |
753    |   9  |       9       |    34.2 kbit/s   |       36.0 kbit/s      |
754    |      |               |                  |                        |
755    |  10  |       10      |    42.2 kbit/s   |       44.0 kbit/s      |
756    +------+---------------+------------------+------------------------+
757
758            Mode vs Bitrate table for wideband and ultra-wideband
759
760                                   Table 2
761
762    The Speex parameters indicate the decoding capabilities of the agent,
763    and what the agent prefers to receive.
764
765    The Speex parameters in an SDP Offer/Answer exchange are completely
766    orthogonal, and there is no relationship between the SDP Offer and
767    the Answer.
768
769    Several Speex specific parameters can be given in a single a=fmtp
770    line provided that they are separated by a semi-colon:
771
772              a=fmtp:97 mode=1;mode=any;vbr=on
773
774    Some example SDP session descriptions utilizing Speex encodings
775    follow.
776
777
778
779
780
781
782
783 Herlein, et al.          Expires August 19, 2008               [Page 14]
784
785 Internet-Draft                    Speex                    February 2008
786
787
788 5.1.  Example supporting all modes, prefer mode 4
789
790    The offerer indicates that it wishes to receive a Speex stream at
791    8000Hz, and wishes to receive Speex 'mode 4'.  It is important to
792    understand that any other mode might still be sent by remote party:
793    the device might have bandwidth limitation or might only be able to
794    send 'mode=3'.  Thus, application that support all decoding modes
795    SHOULD include 'mode=any' as shown in the example below:
796
797              m=audio 8088 RTP/AVP 97
798              a=rtpmap:97 speex/8000
799              a=fmtp:97 mode=4;mode=any
800
801 5.2.  Example supporting only mode 3 and 5
802
803    The offerer indicates the mode he wishes to receive (Speex 'mode 3').
804    This offer indicates mode 3 and mode 5 are supported and that no
805    other modes are supported.  The remote party MUST NOT configure its
806    encoder using another Speex mode.
807
808              m=audio 8088 RTP/AVP 97
809              a=rtmap:97 speex/8000
810              a=fmtp:97 mode=3;mode=5
811
812 5.3.  Example with Variable Bit Rate and Comfort Noise
813
814    The offerer indicates that it wishes to receive variable bit rate
815    frames with comfort noise:
816
817              m=audio 8088 RTP/AVP 97
818              a=rtmap:97 speex/8000
819              a=fmtp:97 vbr=on;cng=on
820
821 5.4.  Example with Voice Activity Detection
822
823    The offerer indicates that it wishes to use silence suppression.  In
824    this case vbr=vad parameter will be used:
825
826              m=audio 8088 RTP/AVP 97
827              a=rtmap:97 speex/8000
828              a=fmtp:97 vbr=vad
829
830 5.5.  Example with Multiple sampling rates
831
832    The offerer indicates that it wishes to receive Speex audio at 16000
833    Hz with mode 10 (42.2 kbit/s), alternatively Speex audio at 8000 Hz
834    with mode 7 (24.6 kbit/s).  The offerer supports decoding all modes.
835
836
837
838
839 Herlein, et al.          Expires August 19, 2008               [Page 15]
840
841 Internet-Draft                    Speex                    February 2008
842
843
844              m=audio 8088 RTP/AVP 97 98
845              a=rtmap:97 speex/16000
846              a=fmtp:97 mode=10;mode=any
847              a=rtmap:98 speex/8000
848              a=fmtp:98 mode=7;mode=any
849
850 5.6.  Example with ptime and Multiple Speex frames
851
852    The "ptime" attribute is used to denote the packetization interval
853    (ie, how many milliseconds of audio is encoded in a single RTP
854    packet).  Since Speex uses 20 msec frames, ptime values of multiples
855    of 20 denote multiple Speex frames per packet.  Values of ptime which
856    are not multiples of 20 MUST be rounded up to the first multiple of
857    20 above the ptime value.
858
859    In the example below the ptime value is set to 40, indicating that
860    there are 2 frames in each packet.
861
862              m=audio 8088 RTP/AVP 97
863              a=rtpmap:97 speex/8000
864              a=ptime:40
865
866    Note that the ptime parameter applies to all payloads listed in the
867    media line and is not used as part of an a=fmtp directive.
868
869    Care must be taken when setting the value of ptime so that the RTP
870    packet size does not exceed the path MTU.
871
872 5.7.  Example with Complete Offer/Answer exchange
873
874    The offerer indicates that it wishes to receive Speex audio at 16000
875    Hz, alternatively Speex audio at 8000 Hz.  The offerer does support
876    ALL modes because no mode is specified.
877
878              m=audio 8088 RTP/AVP 97 98
879              a=rtmap:97 speex/16000
880              a=rtmap:98 speex/8000
881
882    The answerer indicates that it wishes to receive Speex audio at 8000
883    Hz, which is the only sampling rate it supports.  The answerer does
884    support ALL modes because no mode is specified.
885
886              m=audio 8088 RTP/AVP 99
887              a=rtmap:99 speex/8000
888
889
890
891
892
893
894
895 Herlein, et al.          Expires August 19, 2008               [Page 16]
896
897 Internet-Draft                    Speex                    February 2008
898
899
900 6.  Implementation Guidelines
901
902    Implementations that supports Speex are responsible for correctly
903    decoding incoming Speex frames.
904
905    Each Speex frame does contains all needed informations to decode
906    itself.  In particular, the 'mode' and 'ptime' values proposed in the
907    SDP contents MUST NOT be used for decoding: those values are not
908    needed to properly decode a RTP Speex stream.
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951 Herlein, et al.          Expires August 19, 2008               [Page 17]
952
953 Internet-Draft                    Speex                    February 2008
954
955
956 7.  Security Considerations
957
958    RTP packets using the payload format defined in this specification
959    are subject to the security considerations discussed in the RTP
960    specification [RFC3550], and any appropriate RTP profile.  This
961    implies that confidentiality of the media streams is achieved by
962    encryption.  Because the data compression used with this payload
963    format is applied end-to-end, encryption may be performed after
964    compression so there is no conflict between the two operations.
965
966    A potential denial-of-service threat exists for data encodings using
967    compression techniques that have non-uniform receiver-end
968    computational load.  The attacker can inject pathological datagrams
969    into the stream which are complex to decode and cause the receiver to
970    be overloaded.  However, this encoding does not exhibit any
971    significant non-uniformity.
972
973    As with any IP-based protocol, in some circumstances a receiver may
974    be overloaded simply by the receipt of too many packets, either
975    desired or undesired.  Network-layer authentication may be used to
976    discard packets from undesired sources, but the processing cost of
977    the authentication itself may be too high.
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007 Herlein, et al.          Expires August 19, 2008               [Page 18]
1008
1009 Internet-Draft                    Speex                    February 2008
1010
1011
1012 8.  Acknowledgements
1013
1014    The authors would like to thank Equivalence Pty Ltd of Australia for
1015    their assistance in attempting to standardize the use of Speex in
1016    H.323 applications, and for implementing Speex in their open source
1017    OpenH323 stack.  The authors would also like to thank Brian C. Wiles
1018    <brian@streamcomm.com> of StreamComm for his assistance in developing
1019    the proposed standard for Speex use in H.323 applications.
1020
1021    The authors would also like to thank the following members of the
1022    Speex and AVT communities for their input: Ross Finlayson, Federico
1023    Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund, Colin
1024    Perkins, Ivo Emanuel Goncalves.
1025
1026    Thanks to former authors of this document; Simon Morlat, Roger
1027    Hardiman, Phil Kerr.
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063 Herlein, et al.          Expires August 19, 2008               [Page 19]
1064
1065 Internet-Draft                    Speex                    February 2008
1066
1067
1068 9.  Copying conditions
1069
1070    The authors agree to grant third parties the irrevocable right to
1071    copy, use and distribute the work, with or without modification, in
1072    any medium, without royalty, provided that, unless separate
1073    permission is granted, redistributed modified works do not contain
1074    misleading author, version, name of work, or endorsement information.
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119 Herlein, et al.          Expires August 19, 2008               [Page 20]
1120
1121 Internet-Draft                    Speex                    February 2008
1122
1123
1124 10.  References
1125
1126 10.1.  Normative References
1127
1128    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1129               Requirement Levels", BCP 14, RFC 2119, March 1997.
1130
1131    [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
1132               Jacobson, "RTP: A Transport Protocol for Real-Time
1133               Applications", STD 64, RFC 3550, July 2003.
1134
1135    [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1136               Description Protocol", RFC 4566, July 2006.
1137
1138 10.2.  Informative References
1139
1140    [CELP]     "CELP, U.S. Federal Standard 1016.", National Technical
1141               Information Service (NTIS) website http://www.ntis.gov/.
1142
1143    [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
1144               Registration Procedures", BCP 13, RFC 4288, December 2005.
1145
1146    [speex_manual]
1147               Valin, J., "The Speex Codec Manual", Speex
1148               website http://www.speex.org/docs/.
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175 Herlein, et al.          Expires August 19, 2008               [Page 21]
1176
1177 Internet-Draft                    Speex                    February 2008
1178
1179
1180 Authors' Addresses
1181
1182    Greg Herlein
1183    2034 Filbert Street
1184    San Francisco, California  94123
1185    United States
1186
1187    Email: gherlein@herlein.com
1188
1189
1190    Jean-Marc Valin
1191    CSIRO
1192    PO Box 76
1193    Epping, NSW  1710
1194    Australia
1195
1196    Email: jean-marc.valin@usherbrooke.ca
1197
1198
1199    Alfred E. Heggestad
1200    Creytiv.com
1201    Biskop J. Nilssonsgt. 20a
1202    Oslo  0659
1203    Norway
1204
1205    Email: aeh@db.org
1206
1207
1208    Aymeric Moizard
1209    Antisip
1210    4 Quai Perrache
1211    Lyon  69002
1212    France
1213
1214    Email: jack@atosc.org
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231 Herlein, et al.          Expires August 19, 2008               [Page 22]
1232
1233 Internet-Draft                    Speex                    February 2008
1234
1235
1236 Full Copyright Statement
1237
1238    Copyright (C) The IETF Trust (2008).
1239
1240    This document is subject to the rights, licenses and restrictions
1241    contained in BCP 78, and except as set forth therein, the authors
1242    retain all their rights.
1243
1244    This document and the information contained herein are provided on an
1245    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1246    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1247    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1248    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1249    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1250    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1251
1252
1253 Intellectual Property
1254
1255    The IETF takes no position regarding the validity or scope of any
1256    Intellectual Property Rights or other rights that might be claimed to
1257    pertain to the implementation or use of the technology described in
1258    this document or the extent to which any license under such rights
1259    might or might not be available; nor does it represent that it has
1260    made any independent effort to identify any such rights.  Information
1261    on the procedures with respect to rights in RFC documents can be
1262    found in BCP 78 and BCP 79.
1263
1264    Copies of IPR disclosures made to the IETF Secretariat and any
1265    assurances of licenses to be made available, or the result of an
1266    attempt made to obtain a general license or permission for the use of
1267    such proprietary rights by implementers or users of this
1268    specification can be obtained from the IETF on-line IPR repository at
1269    http://www.ietf.org/ipr.
1270
1271    The IETF invites any interested party to bring to its attention any
1272    copyrights, patents or patent applications, or other proprietary
1273    rights that may cover technology that may be required to implement
1274    this standard.  Please address the information to the IETF at
1275    ietf-ipr@ietf.org.
1276
1277
1278 Acknowledgment
1279
1280    Funding for the RFC Editor function is provided by the IETF
1281    Administrative Support Activity (IASA).
1282
1283
1284
1285
1286
1287 Herlein, et al.          Expires August 19, 2008               [Page 23]
1288