Audio/Video Transport Y. Hiwasaki Internet-Draft H. Ohmuro Intended status: Standards Track NTT Corporation Expires: August 24, 2007 February 20, 2007 RTP payload format for UEMCLIP speech codec draft-hiwasaki-avt-rtp-uemclip-01 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 August 24, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Hiwasaki & Ohmuro Expires August 24, 2007 [Page 1] Internet-Draft RTP Payload Format for UEMCLIP February 2007 Abstract This document describes the RTP payload format of an ITU-T G.711 enhanced speech codec, UEMCLIP. The bitstream has a scalable structure with an embedded u-Law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Media Format Background . . . . . . . . . . . . . . . . . . . 4 3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 7 3.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Main Header . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Sub-layer data . . . . . . . . . . . . . . . . . . . . 11 4. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . 14 5. G.711 interoperability . . . . . . . . . . . . . . . . . . . . 15 6. Congestion Control Considerations . . . . . . . . . . . . . . 16 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 17 7.1. Media type registration . . . . . . . . . . . . . . . . . 17 7.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 18 7.2.1. Dynamic transmission definition . . . . . . . . . . . 18 7.3. Offer-answer Model Considerations . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Hiwasaki & Ohmuro Expires August 24, 2007 [Page 2] Internet-Draft RTP Payload Format for UEMCLIP February 2007 1. Introduction This document specifies the payload format for sending UEMCLIP encoded speech using the Real-time Transport Protocol (RTP) [3]. UEMCLIP is an enhanced version of u-law ITU-T G.711, and designed to help the market for smooth transition towards the forthcoming wideband communication environment and while maintaining the interoperability and less transcoding load with the existing terminals, in which the implementation of G.711 is mandatory. The payload format is described in Section 3. The interoperability with G.711 issues are discussed in Section 5. In Section 7.1, a media type registration for UEMCLIP RTP payload format is provided. 1.1. Terminology 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 [1]. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 3] Internet-Draft RTP Payload Format for UEMCLIP February 2007 2. Media Format Background UEMCLIP stands for "U-law EMbedded Coder for Low-delay IP communication", and is basically an enhanced version of u-law ITU-T G.711, otherwise known as PCMU [5]. It is developed for VoIP (Voice over Internet Protocol) applications, and is especially suitable for wideband multi-point conferencing [8]. The main goal of this codec is to provide a wideband communication platform that is highly interoperable with existing terminals equipped with G.711, and to stimulate the market to gradually shift to the wideband communication. Because the G.711 bitstream is embedded in the bitstream, costly transcoding would be avoided especially when interoperating with narrowband terminals. This document does not discuss the implementation detail of the encoder and decoder, but only describes the bitstream format. [Editing note: The rest of the paragraph are subject to change according to the form of disclosure, which is yet to be decided.] The implementation detail will be publicly available from NTT by other means, and the use of such encoder and decoder implementation shall be licensed under reasonable and non-discriminatory (RAND) condition. The codec is intended for NTT's Next-Generation Network (NGN) in which the trial service is launched in December 2006. Because of its scalable nature, there are a number of sub-bitstreams (layer data) with in a UEMCLIP bitstream. By choosing appropriate sub-layers, the codec can adapt to the following requirements: o Sampling frequency, o Number of channels, o Speech quality, and o Bit-rate. The current implementation of UEMCLIP codec includes three sub- coders, as shown in Table 1. The core layer is G.711 core, and other two are quality and bandwidth enhancement layers with bit-rate of 16 kbit/s each. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 4] Internet-Draft RTP Payload Format for UEMCLIP February 2007 +-------+---------------------+----------+--------------------------+ | Layer | Description | Bit-rate | Coding algorithm | +-------+---------------------+----------+--------------------------+ | a | G.711 core | 64 | u-Law PCM | | | | | | | b | Lower-band | 16 | Time domain block | | | enhancement | | quantization | | | | | | | c | Higher-band | 16 | MDCT block quantization | +-------+---------------------+----------+--------------------------+ Table 1: Sub-layer description Based on these sub-layers, UEMCLIP codec operates in four modes as shown in Table 2. Here, "Fs" is the sampling frequency in kHz. The absent Modes 2 and 5 are reserved for future extension to 32 kHz sampling modes. As the mode definition is expected to grow, any other modes not defined in this table MUST NOT be used for compatibility and interoperability reasons. +------+----+----+-------+-------+-------+-------------+------------+ | Mode | Ch | Fs | Layer | Layer | Layer | Bit-rate | Total | | | | | a | b | c | w/o headers | bit-rate | | | | | | | | [kbps] | [kbps] | +------+----+----+-------+-------+-------+-------------+------------+ | 0 | 1 | 8 | x | - | - | 64 | 68.8 | | | | | | | | | | | 1 | 1 | 16 | x | - | x | 80 | 85.6 | | | | | | | | | | | 2 | - | - | - | - | - | - | - | | | | | | | | | | | 3 | 1 | 8 | x | x | - | 80 | 85.6 | | | | | | | | | | | 4 | 1 | 16 | x | x | x | 96 | 102.4 | | | | | | | | | | | 5 | - | - | - | - | - | - | - | +------+----+----+-------+-------+-------+-------------+------------+ Table 2: Mode description UEMCLIP bitstream contains internal headers and other side- information apart from the layer data. This results in total bit- rate larger than the sum of the layers shown in the above table. The detail of the internal headers and auxiliary information are described in Section 3.2.1. Defining the sampling frequency and the number of channels does not result in a singular mode, i.e., there can be multiple modes for the Hiwasaki & Ohmuro Expires August 24, 2007 [Page 5] Internet-Draft RTP Payload Format for UEMCLIP February 2007 same sampling frequency or number of channels. The supported modes would differ from the implementations, thus the sender and the receiver must exchange what mode to use for transmission. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 6] Internet-Draft RTP Payload Format for UEMCLIP February 2007 3. Payload Format As an RTP payload, UEMCLIP bitstream can contain one or more frames as shown in Figure 1. 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 UEMCLIP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 1: RTP payload format UEMCLIP bitstream has a scalable structure, thus it is possible to reconstruct the signal by decoding a part of it. A UEMCLIP frame is composed of a main header followed by one or more sub-layers. As a sub-layer, the core layer, i.e., "Layer a", MUST always be included. It should be noted that the location of the base layer may not be located at the top. The decoder MUST always refer to the layer ID for proper decoding. The bitstream, for the case of enhancement header with length 0, is shown in Figure 2, where sub-layer #1 can be any arbitrary sub-layer data. +--+-------+-------+-------+-------+//-+ |MH| SD #1 | SD #2 | SD #3 | SD #4 |...| | | | | | | | +--+-------+-------+-------+-------+//-+ Figure 2: A UEMCLIP frame (bitstream format) The UEMCLIP bitstream does not include the following information: a) the codec type, b) Mode, c) I/O sampling frequency, and d) encoder version. As described before, these information SHOULD be exchanged while establishing a connection, for example, by means of SDP. 3.1. RTP Header Usage Each RTP packet starts with a fixed RTP header, as explained in [3]. The following fields of the RTP fixed header used specifically for UEMCLIP streams are emphasized: Hiwasaki & Ohmuro Expires August 24, 2007 [Page 7] Internet-Draft RTP Payload Format for UEMCLIP February 2007 Payload type: The assignment of an RTP payload type for this packet format is outside the scope of this document, however, it is expected that a payload type in the dynamic range shall be assigned. Timestamp: This encodes the sampling instant of the first speech signal sample in the RTP data packet. For UEMCLIP streams, the RTP timestamp is based on a 50-kHz clock. Marker bit: This bit shall not be used and MUST be zero. 3.2. Payload Data 3.2.1. Main Header The main header (MH) is placed at the top of a payload and has size of 10 bytes with additional optional enhanced header size. The content of the main header is defined in Figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | BS | MX | | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5|0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PC | | | |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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PC(cont'd) | ES | EH | | | | (if exists) | |2 3 4 5 6 7 8 9|0 1 2 3 4 5 6 7| ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+ Figure 3: UEMCLIP main header format (MH) Identification (ID): 8 bits The value should be "0x95". Byte size (BS): 16 bits Indicates the byte size of the following UEMCLIP payload. This means that the RTP header size, ID and BS are not included. It is encoded in network byte-order. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 8] Internet-Draft RTP Payload Format for UEMCLIP February 2007 Mixing information (MX): 8 bits Mixing information field. Packet-loss Concealment information (PC): 40 bits Packet-loss concealment (PLC) information field. Enhanced-header Size (ES): 8 bits Size of EH (enhanced header) in bytes. Enhanced header (EH): 8*ES bits Content of the enhanced header. When ES is 0, the enhanced header is non-existent. 3.2.1.1. Mixing information field 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |C|R|V| PW1 | |1|1|1| | | | | |0 1 2 3 4| +-+-+-+-+-+-+-+-+ Figure 4: Mixing information field (MX) Check bit #1 (C1): 1 bit Validity flag of V1 and PW1. This bit being "1" indicates that both parameters are valid, and "0" indicates that the parameters should be ignored. Reserved bit #1 (R1): 1 bit This bit should be ignored. VAD flag #1 (V1): 1 bit Voice activity detection flag of the current frame. This flag being "1" indicates that the frame is an active (voice) segment, and "0" indicates that it is an inactive (non-voice) or a silent segment. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 9] Internet-Draft RTP Payload Format for UEMCLIP February 2007 Power #1 (PW1): 5 bits Signal power code of the current frame. 3.2.1.2. PLC information field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|C|R|V| K |R| P1 |R| P2 | PW2 | |2|3|2|2| |3| |4| | | | | | | |0 1 2 3| |0 1 2 3 4 5 6| |0 1 2 3 4 5 6|0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R5 | | | |0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+ Figure 5: PLC information field (PC) Check bit #2 (C2): 1 bit Validity flag of V2, K, P1, P2, and PW2. If the flag is "1", it means that all these parameters are valid, and "0" means that the parameters should be ignored. If any of these parameters is invalid, C1 should be set to "0". Check bit #3 (C3): 1 bit Payload validity indicator. This flag is normally set to "0". If a received packet has this flag set to "1", the payload data should be ignored and packet-loss concealment should be performed by the receiver. This flag is used in case of a multi-point conferencing, where the upstream packet was lost and the mixing server did not execute packet-loss concealment. Reserved bit #2 (R2): 1 bit This bit should be ignored. VAD flag #2 (V2): 1 bit Voice activity detection flag of the current frame. This may be as same as V1 in the mixing information. Frame indicator (K): 4 bits Hiwasaki & Ohmuro Expires August 24, 2007 [Page 10] Internet-Draft RTP Payload Format for UEMCLIP February 2007 This value indicates the frame offset of P2 and PW2. Since it is a better idea to carry the pitch and power parameters as PLC information in a different frame, this frame offset value gives which frame the parameters are to be associated with. Since there are 4 bits allocated, it ranges between "0" and "15". Reserved bit #3 (R3): 1 bit This bit should be ignored. Pitch lag #1 (P1): 7 bits Pitch code of the current frame. The actual pitch lag is calculated as P1+20 samples in 8-kHz sampling rate. Pitch lag must be 20 <= pitch length <= 120. Codes ranging between "0x65" and "0x7F" are not used. Reserved bit #4 (R4): 1 bit This bit should be ignored. Pitch lag #2 (P2): 7 bits Pitch code of the offset frame. The actual pitch lag is calculated as P2+20 samples in 8-kHz sampling rate. Pitch lag must be 20 <= pitch length <= 120. Codes ranging between "0x65" and "0x7F" are not used. The offset value is defined as K. Power #2 (PW2): 8 bits Signal power code of the offset frame. The offset value is defined as K. Reserved bits #5 (R5): 8 bits These bits should be ignored. 3.2.2. Sub-layer data Sub-layer data (SD) is a sub-header followed by layer bitstreams, as shown in Figure 6. The sub-header indicates the layer location and the number of bytes. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 11] Internet-Draft RTP Payload Format for UEMCLIP February 2007 0 1 2 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 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+ | CI| FI| QI| R6| SB | LD ... | | | | | | | | |0 1|0 1|0 1|0 1|0 1 2 3 4 5 6 7| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+ Figure 6: Sub-layer format (SD) Channel index (CI): 2 bits Indicates the channel number. For all modes given in Table 2, this should be "0x1". The detail is given in Table 3. Frequency index (FI): 2 bits Indicates the frequency number. "0" means that the layer is in the base frequency band, higher number means that the layer is in respective frequency band. The detail is given in Table 3. Quality index (QI): 2 bits Indicates the quality layer number. "0" means that the layer is in the base layer, and higher number means that the layer is in respective quality layer. The detail is given in Table 3. Reserved #6 (R6): 2 bits Not used (reserved). The value must be "0". Sub-layer Size (SB): 8 bits Indicates the byte size of the following sub-layer data. Layer Data (LD): SB*8 bits The actual sub-layer data. 3.2.2.1. Layer index encoding The layer index is encoded using values of channel number, quality number, and frequency-band number encoded with 2-bits each, in the appearing order. The last 2 bits are reserved for future use, and all implementation should ignore this field. For all the layers shown in Table 1, the layer indices are shown in Table 3. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 12] Internet-Draft RTP Payload Format for UEMCLIP February 2007 +-------+----+----+----+ | Layer | CI | FI | QI | +-------+----+----+----+ | a | 0 | 0 | 0 | | | | | | | b | 0 | 0 | 1 | | | | | | | c | 0 | 1 | 0 | +-------+----+----+----+ Table 3: Layer indices Hiwasaki & Ohmuro Expires August 24, 2007 [Page 13] Internet-Draft RTP Payload Format for UEMCLIP February 2007 4. Payload Examples (to be written) Hiwasaki & Ohmuro Expires August 24, 2007 [Page 14] Internet-Draft RTP Payload Format for UEMCLIP February 2007 5. G.711 interoperability As given in Section 2, G.711 (u-Law) bitstream (Layer a) is the core layer, and is always embedded. This means that transcoding from UEMCLIP bitstream to G.711 does not have to undergo the usual decoding and re-encoding procedures, but simple extraction would only suffice. However, this does not apply for the reverse procedure, i.e., transcoding from G.711 to UEMCLIP, because the side information in the main header must be calculated separately. The transcoding from UEMCLIP to G.711 can be done easily by finding an appropriate sub-layer. The transcoder should look for a sub-layer with the layer index of 0x00, and subsequent LD which has size of SB*8 bits (usually for 20ms frame, SB=160) are the actual G.711 bitstream data. It should be noted that transcoder should not expect the core layer to be located right after the main header. On the other hand, the transcoding from G.711 to UEMCLIP is not entirely straight-forward. For the main header contents, it should follow the following guidelines. o ID must be set "0x95". o Byte size (BS) should be set 7 bytes of the main header, plus sub- header size (2) added with number of samples in G.711 (SB) . o The enhanced-header size (ES) set to "0x00". o The check bit for mixing and PLC (C1 and C2) should be set 0. o The payload validity indicator (C3) should be set 0. For the sub-layer header, it should be o All CI, FI, QI, R6 MUST be 0. o Sub-layer size (SB) MUST be 160 for 20ms frame. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 15] Internet-Draft RTP Payload Format for UEMCLIP February 2007 6. Congestion Control Considerations The general congestion control considerations for transporting RTP data apply to UEMCLIP over RTP [3] as well as any applicable RTP profile like AVP [4]. UEMCLIP does not have any built-in mechanism for reducing the bandwidth. Packing more frames in each RTP payload can reduce the number of packets sent, and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced error robustness against packet losses. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 16] Internet-Draft RTP Payload Format for UEMCLIP February 2007 7. Payload Format Parameters 7.1. Media type registration This registration is done using the template defined in [6] and following [5]. MIME media type name: audio MIME media subtype name: UEMCLIP Required parameters: (T.B.D.) Optional parameters: (T.B.D.) Encoding considerations: This type is defined for transferring UEMCLIP-encoded data via RTP using the payload format specified in Section 3. Audio data is binary data and must be encoded for non- binary transport; the Base64 encoding is suitable for e-mail. Security considerations: See Section 8 "Security Considerations" of this document. Interoperability considerations: See Section 5 of this document. Published specification: (T.B. assigned) Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: None Intended usage: COMMON Person & email address to contact for further information: Yusuke Hiwasaki Author/Change controller: Author: Yusuke Hiwasaki Change Controller: IETF Audio/Video Transport Working Group delegated from the IESG Hiwasaki & Ohmuro Expires August 24, 2007 [Page 17] Internet-Draft RTP Payload Format for UEMCLIP February 2007 7.2. Mapping to SDP Parameters Payload type: Since it is not registered in [4], any RTP packets that carry UEMCLIP as payload type MUST be treated as a dynamic payload type. Codec name: MIME registered codec name should be used. Sampling Frequency: Depending on the mode to communicate, sampling frequency MUST be selected from the ones defined in Table 2. Channel numbers: It SHOULD default to "1", as selected from the ones defined in Table 2. Packet intervals: Since frame length of any UEMCLIP is 20ms, when specifying a=ptime line, the argument MUST be a multiple of "20". When not listed in SDP, it should also default to the minimum size: "20". Bandwidth: As described in [7], bandwidth line is OPTIONAL. When there is no bandwidth restrictions, the numbers MUST be the largest value out of the Table 2, and the unit should be ``kbit/s'' with the fraction raised to the unit, including header overheads down to Layer 3. If any restrictions apply, then the value MUST be the largest of the Table 2 that satisfy the restriction, by the same calculation procedure. It MUST NOT encode with bit-rate larger than the answered bit-rate bandwidth. UMECLIP specific: Any description specific to UEMCLIP are defined in the Format Specification Parameters (fmtp). Each parameters MUST be separated with ";", and if any attributes (value) exists, it MUST be defined with "+". For compatibility reasons, any application/terminal MUST ignore any parameters that does not appear below. This is to ensure the upper-compatibility with later added parameters for the future enhancements. 7.2.1. Dynamic transmission definition Since UEMCLIP codec can operate in number of modes, it is desirable to specify the range of modes that an encoder or a decoder can operate at. UEMCLIP decoders are designed to accept bitstreams in any modes. However, the implementation limitation may fail to adopt to the dynamic bit-rate change. Thus introduced here is two concepts: "dynamic mode" (denoted as "dynmode"), where the dynamic mode (bit- rate) change is allowed, and "fixed mode" (denoted as "fixmode"), where the change is not permitted. Both modes MUST be used Hiwasaki & Ohmuro Expires August 24, 2007 [Page 18] Internet-Draft RTP Payload Format for UEMCLIP February 2007 exclusively. "fixmode" is used to specify no modification of the operating mode (bit-rate) during the session. It MUST operate exclusively to "dynmode". It should specify the possible combination of mode numbers, delimited by commas ",". When offering a "fixmode", the offerer SHOULD list the mode numbers in descending priority order. The answerer MUST select a single suitable mode number and reply as "fixmode" with one argument. On the otherhand, "dynmode" is used to allow modification of the operating mode during the session. It MUST operate exclusively to "fixmode". The offerer should specify the possible combination of mode numbers, delimited by commas ",". The answerer can either select a number of suitable modes and reply as "dynmode" in the same manner, or select a single sitable mode number and reply as "fixmode" with one argument. The mode numbers that can be specified as arguments to "fixmode" or "dynmode" are restricted by a combination of a sampling frequency and a number of audio channels, as shown in Table 2. This is because SDP binds a payload type to a combination of a sampling frequency and a number of audio channels. When a "fixmode" or "dynmode" is not given, it MUST be interpreted as being defaulting to the fixed mode ("fixmode") and MUST use the default value specified in Table 4. +---------+----------+------------------+--------------+ | Fs [Hz] | Channels | Selectable modes | Default mode | +---------+----------+------------------+--------------+ | 8000 | 1 | 0,3 | 0 | | | | | | | 16000 | 1 | 1,4 | 1 | +---------+----------+------------------+--------------+ Table 4: Default modes 7.3. Offer-answer Model Considerations The procedures related to exchanging SDP messages MUST follow [2]. o When multiple UEMCLIP dynamic payload type number is offered, an answerer SHOULD select a single payload type number, i.e., one sampling frequency and channel condition. o The ptime SHOULD be 20. o An offerer SHOULD offer every possible combination of sampling frequency, channel number, and fmtp parameters including dynamic/ Hiwasaki & Ohmuro Expires August 24, 2007 [Page 19] Internet-Draft RTP Payload Format for UEMCLIP February 2007 fixed mode. When the transmission bandwidth is restricted, it MUST be offered in accordance to the restriction. o When offering/answering SDP, any fmtp parameters which are undefined MUST be ignored. If any unknown/undefined parameters should be offered, an answerer MUST delete the entry from the answer message. In this case, the offerer MUST use the default value for any deleted parameters. o If a dynamic mode ("dynmode") is offered, an answerer MUST select either "dynmode" or "fixmode", according to ones capabilities. When fixed mode ("fixmode") is offered, an answerer MUST only answer "fixmode". In the case of answering fixed mode ("fixmode"), answerer MUST select a single mode out of offered mode, regardless of dynamic/fixed mode specification. If a mode is not offered at all, the session MUST default to fixed mode, and the default mode value, as shown in Table 4, MUST be used, based on the sampling frequency and number of channels specified elsewhere. o When an offered condition does not fit an answerer's capabilities, it naturally MUST not answer the conditions, and session MAY proceed to re-INVITE, if possible. If a condition (mode) is decided upon, an offerer and an answerer MUST transmit on this condition. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 20] Internet-Draft RTP Payload Format for UEMCLIP February 2007 8. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3] and any appropriate profiles. This implies that confidentiality of the media streams is achieved by encryption. A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver output to become overloaded. However, UEMCLIP covered in this document do not exhibit any significant non-uniformity. Another potential threats are memory attacks by illegal layer indices or byte numbers. The implementor of the decoder should always be aware that the indicated numbers may be corrupted and does not point to the right sub-layer or the allows reading beyond the bitstream boundaries. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 21] Internet-Draft RTP Payload Format for UEMCLIP February 2007 9. IANA Considerations It is requested that one new media subtype (audio/UEMCLIP) is registered by IANA. For details, see Section 7.1. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 22] Internet-Draft RTP Payload Format for UEMCLIP February 2007 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [5] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. [6] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 10.2. Informative References [8] Hiwasaki, Y., Ohmuro, H., Mori, T., Kurihara, S., and A. Kataoka, "A G.711 Embedded Wideband Speech Coding for VoIP Conferences", IEICE Trans. Inf. & Syst., vol.E89-D no. 9, September 2006. Hiwasaki & Ohmuro Expires August 24, 2007 [Page 23] Internet-Draft RTP Payload Format for UEMCLIP February 2007 Authors' Addresses Yusuke Hiwasaki NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan Phone: +81(422)59-4815 Email: hiwasaki.yusuke@lab.ntt.co.jp Hitoshi Ohmuro NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan Phone: +81(422)59-2151 Email: ohmuro.hitoshi@lab.ntt.co.jp Hiwasaki & Ohmuro Expires August 24, 2007 [Page 24] Internet-Draft RTP Payload Format for UEMCLIP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hiwasaki & Ohmuro Expires August 24, 2007 [Page 25]