| |
| |
| AVT Working Group G. Herlein |
| Internet-Draft S. Morlat |
| Expires: July 2, 2005 J. Jean-Marc |
| R. Hardiman |
| P. Kerr |
| January 01, 2005 |
| |
| |
| draft-herlein-speex-rtp-profile-03 |
| RTP Payload Format for the Speex Codec |
| |
| Status of this Memo |
| |
| This document is an Internet-Draft and is subject to all provisions |
| of section 3 of RFC 3667. By submitting this Internet-Draft, each |
| author represents that any applicable patent or other IPR claims of |
| which he or she is aware have been or will be disclosed, and any of |
| which he or she become aware will be disclosed, in accordance with |
| RFC 3668. |
| |
| Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |
| other groups may also distribute working documents as |
| Internet-Drafts. |
| |
| Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |
| |
| The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |
| |
| The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |
| |
| This Internet-Draft will expire on July 2, 2005. |
| |
| Copyright Notice |
| |
| Copyright (C) The Internet Society (2005). |
| |
| Abstract |
| |
| Speex is an open-source voice codec suitable for use in Voice over IP |
| (VoIP) type applications. This document describes the payload format |
| for Speex generated bit streams within an RTP packet. Also included |
| here are the necessary details for the use of Speex with the Session |
| Description Protocol (SDP) and a preliminary method of using Speex |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 1] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| within H.323 applications. |
| |
| Table of Contents |
| |
| 1. Conventions used in this document . . . . . . . . . . . . . 3 |
| 2. Overview of the Speex Codec . . . . . . . . . . . . . . . . 4 |
| 3. RTP payload format for Speex . . . . . . . . . . . . . . . . 5 |
| 4. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 5. Speex payload . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 6. Example Speex packet . . . . . . . . . . . . . . . . . . . . 9 |
| 7. Multiple Speex frames in a RTP packet . . . . . . . . . . . 10 |
| 8. MIME registration of Speex . . . . . . . . . . . . . . . . . 11 |
| 9. SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . 12 |
| 10. ITU H.323/H.245 Use of Speex . . . . . . . . . . . . . . . . 15 |
| 11. NonStandardMessage format . . . . . . . . . . . . . . . . . 16 |
| 12. RTP Payload Types . . . . . . . . . . . . . . . . . . . . . 17 |
| 13. Security Considerations . . . . . . . . . . . . . . . . . . 18 |
| 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 |
| 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 15.1 Normative References . . . . . . . . . . . . . . . . . . . 20 |
| 15.2 Informative References . . . . . . . . . . . . . . . . . . 20 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 |
| Intellectual Property and Copyright Statements . . . . . . . 22 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 2] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 1. Conventions used in this document |
| |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in RFC 2119 [1]. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 3] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 2. Overview of the Speex Codec |
| |
| Speex is based on the CELP [10] encoding technique with support for |
| either narrowband (nominal 8kHz), wideband (nominal 16kHz) or |
| ultra-wideband (nominal 32kHz), and (non-optimal) rates up to 48 kHz |
| sampling also available. The main characteristics can be summarized |
| as follows: |
| |
| o Free software/open-source |
| o Integration of wideband and narrowband in the same bit-stream |
| o Wide range of bit-rates available |
| o Dynamic bit-rate switching and variable bit-rate (VBR) |
| o Voice Activity Detection (VAD, integrated with VBR) |
| o Variable complexity |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 4] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 3. RTP payload format for Speex |
| |
| For RTP based transportation of Speex encoded audio the standard RTP |
| header [2] is followed by one or more payload data blocks. An |
| optional padding terminator may also be used. |
| |
| 0 1 2 3 |
| 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RTP Header | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | one or more frames of Speex .... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | one or more frames of Speex .... | padding | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 5] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 4. RTP Header |
| |
| 0 1 2 3 |
| 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P|X| CC |M| PT | sequence number | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | timestamp | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | synchronization source (SSRC) identifier | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | contributing source (CSRC) identifiers | |
| | ... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| The RTP header begins with an octet of fields (V, P, X, and CC) to |
| support specialized RTP uses (see [2] and [7] for details). For |
| Speex the following values are used. |
| |
| Version (V): 2 bits |
| |
| This field identifies the version of RTP. The version used by this |
| specification is two [2]. |
| |
| Padding (P): 1 bit |
| |
| If the padding bit is set, the packet contains one or more additional |
| padding octets at the end which are not part of the payload. P is |
| set if the total packet size is less than the MTU. |
| |
| Extension (X): 1 bit |
| |
| If the extension, X, bit is set, the fixed header MUST be followed by |
| exactly one header extension, with a format defined in Section 5.3.1. |
| of [2]. |
| |
| CSRC count (CC): 4 bits |
| |
| The CSRC count contains the number of CSRC identifiers. |
| |
| Marker (M): 1 bit |
| |
| The M bit indicates if the packet contains comfort noise. This field |
| is used in conjunction with the cng SDP attribute and is detailed |
| further in section 5 below. In normal usage this bit is set if the |
| packet contains comfort noise. |
| |
| Payload Type (PT): 7 bits |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 6] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| An RTP profile for a class of applications is expected to assign a |
| payload type for this format, or a dynamically allocated payload type |
| SHOULD be chosen which designates the payload as Speex. |
| |
| Sequence number: 16 bits |
| |
| The sequence number increments by one for each RTP data packet sent, |
| and may be used by the receiver to detect packet loss and to restore |
| packet sequence. This field is detailed further in [2]. |
| |
| Timestamp: 32 bits |
| |
| A timestamp representing the sampling time of the first sample of the |
| first Speex packet in the RTP packet. The clock frequency MUST be |
| set to the sample rate of the encoded audio data. Speex uses 20 msec |
| frames and a variable sampling rate clock. The RTP timestamp MUST be |
| in units of 1/X of a second where X is the sample rate used. Speex |
| uses a nominal 8kHz sampling rate for narrowband use, a nominal 16kHz |
| sampling rate for wideband use, and a nominal 32kHz sampling rate for |
| ultra-wideband use. |
| |
| SSRC/CSRC identifiers: |
| |
| These two fields, 32 bits each with one SSRC field and a maximum of |
| 16 CSRC fields, are as defined in [2]. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 7] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 5. Speex payload |
| |
| For the purposes of packetizing the bit stream in RTP, it is only |
| necessary to consider the sequence of bits as output by the Speex |
| encoder [9], and present the same sequence to the decoder. The |
| payload format described here maintains this sequence. |
| |
| A typical Speex frame, encoded at the maximum bitrate, is approx. |
| 110 octets and the total number of Speex frames SHOULD be kept less |
| than the path MTU to prevent fragmentation. Speex frames MUST NOT be |
| fragmented across multiple RTP packets, |
| |
| An RTP packet MAY contain Speex frames of the same bit rate or of |
| varying bit rates, since the bit-rate for a frame is conveyed in band |
| with the signal. |
| |
| The encoding and decoding algorithm can change the bit rate at any 20 |
| msec frame boundary, with the bit rate change notification provided |
| in-band with the bit stream. Each frame contains both "mode" |
| (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate) |
| information in the bit stream. No out-of-band notification is |
| required for the decoder to process changes in the bit rate sent by |
| the encoder. |
| |
| It is RECOMMENDED that values of 8000, 16000 and 32000 be used for |
| normal internet telephony applications, though the sample rate is |
| supported at rates as low as 6000 Hz and as high as 48 kHz. |
| |
| The RTP payload MUST be padded to provide an integer number of octets |
| as the payload length. These padding bits are LSB aligned in network |
| octet order and consist of a 0 followed by all ones (until the end of |
| the octet). This padding is only required for the last frame in the |
| packet, and only to ensure the packet contents ends on an octet |
| boundary. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 8] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 6. Example Speex packet |
| |
| In the example below we have a single Speex frame with 5 bits of |
| padding to ensure the packet size falls on an octet boundary. |
| |
| 0 1 2 3 |
| 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P|X| CC |M| PT | sequence number | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | timestamp | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | synchronization source (SSRC) identifier | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |
| 0 1 2 3 |
| 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 |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | contributing source (CSRC) identifiers | |
| | ... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | ..speex data.. | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | ..speex data.. |0 1 1 1 1| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 9] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 7. Multiple Speex frames in a RTP packet |
| |
| Below is an example of two Speex frames contained within one RTP |
| packet. The Speex frame length in this example fall on an octet |
| boundary so there is no padding. |
| |
| Speex codecs [9] are able to detect the the bitrate from the payload |
| and are responsible for detecting the 20 msec boundaries between each |
| frame. |
| |
| 0 1 2 3 |
| 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P|X| CC |M| PT | sequence number | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | timestamp | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | synchronization source (SSRC) identifier | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | contributing source (CSRC) identifiers | |
| | ... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | ..speex data.. | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | ..speex data.. | ..speex data.. | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | ..speex data.. | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 10] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 8. MIME registration of Speex |
| |
| Full definition of the MIME [3] type for Speex will be part of the |
| Ogg Vorbis MIME type definition application [8]. |
| |
| MIME media type name: audio |
| |
| MIME subtype: speex |
| |
| Optional parameters: |
| |
| Required parameters: to be included in the Ogg MIME specification. |
| |
| Encoding considerations: |
| |
| Security Considerations: |
| |
| See Section 6 of RFC 3047. |
| |
| Interoperability considerations: none |
| |
| Published specification: |
| |
| Applications which use this media type: |
| |
| Additional information: none |
| |
| Person & email address to contact for further information: |
| |
| Greg Herlein <gherlein@herlein.com> |
| Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca> |
| |
| Intended usage: COMMON |
| |
| Author/Change controller: |
| |
| Author: Greg Herlein <gherlein@herlein.com> |
| Change controller: Greg Herlein <gherlein@herlein.com> |
| Change controller: IETF AVT Working Group |
| |
| This transport type signifies that the content is to be interpreted |
| according to this document if the contents are transmitted over RTP. |
| Should this transport type appear over a lossless streaming protocol |
| such as TCP, the content encapsulation should be interpreted as an |
| Ogg Stream in accordance with [8], with the exception that the |
| content of the Ogg Stream may be assumed to be Speex audio and Speex |
| audio only. |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 11] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 9. SDP usage of Speex |
| |
| When conveying information by SDP [4], the encoding name MUST be set |
| to "speex". An example of the media representation in SDP for |
| offering a single channel of Speex at 8000 samples per second might |
| be: |
| |
| m=audio 8088 RTP/AVP 97 |
| a=rtpmap:97 speex/8000 |
| |
| Note that the RTP payload type code of 97 is defined in this media |
| definition to be 'mapped' to the speex codec at an 8kHz sampling |
| frequency using the 'a=rtpmap' line. Any number from 96 to 127 could |
| have been chosen (the allowed range for dynamic types). |
| |
| The value of the sampling frequency is typically 8000 for narrow band |
| operation, 16000 for wide band operation, and 32000 for ultra-wide |
| band operation. |
| |
| If for some reason the offerer has bandwidth limitations, the client |
| may use the "b=" header, as explained in SDP [4]. The following |
| example illustrates the case where the offerer cannot receive more |
| than 10 kbit/s. |
| |
| m=audio 8088 RTP/AVP 97 |
| b=AS:10 |
| a=rtmap:97 speex/8000 |
| |
| In this case, if the remote part agrees, it should configure its |
| Speex encoder so that it does not use modes that produce more than 10 |
| kbit/s. Note that the "b=" constraint also applies on all payload |
| types that may be proposed in the media line ("m="). |
| |
| An other way to make recommendations to the remote Speex encoder is |
| to use its specific parameters via the a=fmtp: directive. The |
| following parameters are defined for use in this way: |
| |
| ptime: duration of each packet in milliseconds. |
| |
| sr: actual sample rate in Hz. |
| |
| ebw: encoding bandwidth - either 'narrow' or 'wide' or 'ultra' |
| (corresponds to nominal 8000, 16000, and 32000 Hz sampling rates). |
| |
| vbr: variable bit rate - either 'on' 'off' or 'vad' (defaults |
| to off). If on, variable bit rate is enabled. If off, disabled. |
| If set to 'vad' then constant bit rate is used but silence will be |
| encoded with special short frames to indicate a lack of voice for |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 12] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| that period. |
| |
| cng: comfort noise generation - either 'on' or 'off'. If off |
| then silence frames will be silent; if 'on' then those frames will |
| be filled with comfort noise. |
| |
| mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to |
| 3 in narrowband, 6 in wide and ultra-wide. |
| |
| penh: use of perceptual enhancement. 1 indicates to the decoder |
| that perceptual enhancement is recommended, 0 indicates that it is |
| not. Defaults to on (1). |
| |
| |
| Examples: |
| |
| m=audio 8008 RTP/AVP 97 |
| a=rtpmap:97 speex/8000 |
| a=fmtp:97 mode=4 |
| |
| This examples illustrate an offerer that wishes to receive a Speex |
| stream at 8000Hz, but only using speex mode 3. |
| |
| The offerer may suggest to the remote decoder to activate its |
| perceptual enhancement filter like this: |
| |
| m=audio 8088 RTP/AVP 97 |
| a=rtmap:97 speex/8000 |
| a=fmtp:97 penh=1 |
| |
| Several Speex specific parameters can be given in a single a=fmtp |
| line provided that they are separated by a semi-colon: |
| |
| a=fmtp:97 mode=any;penh=1 |
| |
| The offerer may indicate that it wishes to send variable bit rate |
| frames with comfort noise: |
| |
| m=audio 8088 RTP/AVP 97 |
| a=rtmap:97 speex/8000 |
| a=fmtp:97 vbr=on;cng=on |
| |
| The "ptime" attribute is used to denote the packetization interval |
| (ie, how many milliseconds of audio is encoded in a single RTP |
| packet). Since Speex uses 20 msec frames, ptime values of multiples |
| of 20 denote multiple Speex frames per packet. Values of ptime which |
| are not multiples of 20 MUST be ignored and clients MUST use the |
| default value of 20 instead. |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 13] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| In the example below the ptime value is set to 40, indicating that |
| there are 2 frames in each packet. |
| |
| m=audio 8008 RTP/AVP 97 |
| a=rtpmap:97 speex/8000 |
| a=ptime:40 |
| |
| Note that the ptime parameter applies to all payloads listed in the |
| media line and is not used as part of an a=fmtp directive. |
| |
| Values of ptime not multiple of 20 msec are meaningless, so the |
| receiver of such ptime values MUST ignore them. If during the life |
| of an RTP session the ptime value changes, when there are multiple |
| Speex frames for example, the SDP value must also reflect the new |
| value. |
| |
| Care must be taken when setting the value of ptime so that the RTP |
| packet size does not exceed the path MTU. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 14] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 10. ITU H.323/H.245 Use of Speex |
| |
| Application is underway to make Speex a standard ITU codec. However, |
| until that is finalized, Speex MAY be used in H.323 [5] by using a |
| non-standard codec block definition in the H.245 [6] codec capability |
| negotiations. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 15] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 11. NonStandardMessage format |
| |
| For Speex use in H.245 [6] based systems, the fields in the |
| NonStandardMessage should be: |
| |
| t35CountryCode = Hex: B5 |
| t35Extension = Hex: 00 |
| manufacturerCode = Hex: 0026 |
| [Length of the Binary Sequence (8 bit number)] |
| [Binary Sequence consisting of an ASCII string, no NULL |
| terminator] |
| |
| The binary sequence is an ascii string merely for ease of use. The |
| string is not null terminated. The format of this string is |
| |
| speex [optional variables] |
| |
| The optional variables are identical to those used for the SDP a=fmtp |
| strings discussed in section 5 above. The string is built to be all |
| on one line, each key-value pair separated by a semi-colon. The |
| optional variables MAY be omitted, which causes the default values to |
| be assumed. They are: |
| |
| ebw=narrow;mode=3;vbr=off;cng=off;ptime=20;sr=8000;penh=no; |
| |
| The fifth octet of the block is the length of the binary sequence. |
| |
| NOTE: this method can result in the advertising of a large number of |
| Speex 'codecs' based on the number of variables possible. For most |
| VoIP applications, use of the default binary sequence of 'speex' is |
| RECOMMENDED to be used in addition to all other options. This |
| maximizes the chances that two H.323 based applications that support |
| Speex can find a mutual codec. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 16] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 12. RTP Payload Types |
| |
| Dynamic payload type codes MUST be negotiated 'out-of-band' for the |
| assignment of a dynamic payload type from the range of 96-127. H.323 |
| applications MUST use the H.245 H2250LogicalChannelParameters |
| encoding to accomplish this. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 17] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 13. Security Considerations |
| |
| RTP packets using the payload format defined in this specification |
| are subject to the security considerations discussed in the RTP |
| specification [2], and any appropriate RTP profile. This implies |
| that confidentiality of the media streams is achieved by encryption. |
| Because the data compression used with this payload format is applied |
| end-to-end, encryption may be performed after compression so there is |
| no conflict between the two operations. |
| |
| A potential denial-of-service threat exists for data encodings using |
| compression techniques that have non-uniform receiver-end |
| computational load. The attacker can inject pathological datagrams |
| into the stream which are complex to decode and cause the receiver to |
| be overloaded. However, this encoding does not exhibit any |
| significant non-uniformity. |
| |
| As with any IP-based protocol, in some circumstances a receiver may |
| be overloaded simply by the receipt of too many packets, either |
| desired or undesired. Network-layer authentication may be used to |
| discard packets from undesired sources, but the processing cost of |
| the authentication itself may be too high. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 18] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 14. Acknowledgments |
| |
| The authors would like to thank Equivalence Pty Ltd of Australia for |
| their assistance in attempting to standardize the use of Speex in |
| H.323 applications, and for implementing Speex in their open source |
| OpenH323 stack. The authors would also like to thank Brian C. Wiles |
| <brian@streamcomm.com> of StreamComm for his assistance in developing |
| the proposed standard for Speex use in H.323 applications. |
| |
| The authors would also like to thank the following members of the |
| Speex and AVT communities for their input: Ross Finlayson, Federico |
| Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 19] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| 15. References |
| |
| 15.1 Normative References |
| |
| [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement |
| Levels", RFC 2119. |
| |
| [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, |
| "RTP: A Transport Protocol for real-time applications", RFC |
| 3550. |
| |
| [3] "Multipurpose Internet Mail Extensions (MIME) Part One: Format |
| of Internet Message Bodies", RFC 2045. |
| |
| [4] Jacobson, V. and M. Handley, "SDP: Session Description |
| Protocol", RFC 2327. |
| |
| [5] "Packet-based Multimedia Communications Systems", ITU-T |
| Recommendation H.323. |
| |
| [6] "Control of communications between Visual Telephone Systems and |
| Terminal Equipment", ITU-T Recommendation H.245. |
| |
| [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video |
| Conferences with Minimal Control.", RFC 3551. |
| |
| [8] Walleij, L., "The application/ogg Media Type", RFC 3534. |
| |
| 15.2 Informative References |
| |
| [9] "Speexenc/speexdec, reference command-line encoder/decoder", |
| Speex website http://www.speex.org/. |
| |
| [10] "CELP, U.S. Federal Standard 1016.", National Technical |
| Information Service (NTIS) website http://www.ntis.gov/. |
| |
| |
| Authors' Addresses |
| |
| Greg Herlein |
| 2034 Filbert Street |
| San Francisco, California 94123 |
| United States |
| |
| EMail: gherlein@herlein.com |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 20] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| Simon Morlat |
| 35, av de Vizille App 42 |
| Grenoble 38000 |
| France |
| |
| EMail: simon.morlat@linphone.org |
| |
| |
| Jean-Marc Valin |
| Department of Electrical and Computer Engineering |
| University of Sherbrooke |
| 2500 blvd Universite |
| Sherbrooke, Quebec J1K 2R1 |
| Canada |
| |
| EMail: jean-marc.valin@hermes.usherb.ca |
| |
| |
| Roger Hardiman |
| 49 Nettleton Road |
| Cheltenham, Gloucestershire GL51 6NR |
| England |
| |
| EMail: roger@freebsd.org |
| |
| |
| Phil Kerr |
| England |
| |
| EMail: phil@plus24.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 21] |
| |
| Internet-Draft draft-herlein-speex-rtp-profile-03 January 2005 |
| |
| |
| Intellectual Property Statement |
| |
| The IETF takes no position regarding the validity or scope of any |
| Intellectual Property Rights or other rights that might be claimed to |
| pertain to the implementation or use of the technology described in |
| this document or the extent to which any license under such rights |
| might or might not be available; nor does it represent that it has |
| made any independent effort to identify any such rights. Information |
| on the procedures with respect to rights in RFC documents can be |
| found in BCP 78 and BCP 79. |
| |
| Copies of IPR disclosures made to the IETF Secretariat and any |
| assurances of licenses to be made available, or the result of an |
| attempt made to obtain a general license or permission for the use of |
| such proprietary rights by implementers or users of this |
| specification can be obtained from the IETF on-line IPR repository at |
| http://www.ietf.org/ipr. |
| |
| The IETF invites any interested party to bring to its attention any |
| copyrights, patents or patent applications, or other proprietary |
| rights that may cover technology that may be required to implement |
| this standard. Please address the information to the IETF at |
| ietf-ipr@ietf.org. |
| |
| |
| Disclaimer of Validity |
| |
| This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET |
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, |
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE |
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| |
| |
| Copyright Statement |
| |
| Copyright (C) The Internet Society (2005). This document is subject |
| to the rights, licenses and restrictions contained in BCP 78, and |
| except as set forth therein, the authors retain all their rights. |
| |
| |
| Acknowledgment |
| |
| Funding for the RFC Editor function is currently provided by the |
| Internet Society. |
| |
| |
| |
| |
| Herlein, et al. Expires July 2, 2005 [Page 22] |
| |