Audio/Video Transport Y. Hiwasaki
Internet-Draft H. Ohmuro
Intended status: Standards Track NTT Corporation
Expires: March 30, 2007 September 26, 2006
RTP payload format for UEMCLIP speech codec
draft-hiwasaki-avt-rtp-uemclip-00
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 March 30, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 1]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
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
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Bitstream format . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Main Header . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Sub-layer data . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Layer index encoding . . . . . . . . . . . . . . . . . 12
4. G.711 interoperability . . . . . . . . . . . . . . . . . . . . 13
5. SIP considerations . . . . . . . . . . . . . . . . . . . . . . 14
5.1. SDP parameters . . . . . . . . . . . . . . . . . . . . . . 14
5.2. UEMCLIP specific . . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Dynamic transmission definition . . . . . . . . . . . 15
5.3. Offer-answer model considerations . . . . . . . . . . . . 16
6. Media type registration . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 2]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
1. Introduction
This document specifies the payload format for sending UEMCLIP
encoded speech using the Real-time Transport Protocol (RTP) [4].
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 March 30, 2007 [Page 3]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
2. 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 [6]. 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
development 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 shall be 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 March 30, 2007 [Page 4]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
+-------+---------------------+----------+--------------------------+
| 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. "Fs" is the sampling frequency in Hz. 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
As will be described in Section 3, 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 each
layers shown in the above table. The detail of the internal headers
and auxiliary information will be described later in Section 3.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 March 30, 2007 [Page 5]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
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 is to be used for transmission. For
this reason, using SIP is RECOMMENDED. The guideline of the SIP
negotiation procedure will be given in Section 5.
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 6]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
3. Bitstream 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 has
the following BNF format:
UEMCLIPFrame ::= MainHeader SubLayer+
As a "SubLayer", 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 3, where sub-
layer #1 can be any arbitrary sub-layer data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Main header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Main header (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Main header | Sub-header |Sub-layer #1 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Sub-layer #1 (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-header | Sub-layer #2 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Sub-layer #2 (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bitstream outline of a UEMCLIP frame
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 7]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
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, by means of SIP negotiation using
SDP. The guidelines of such procedures will be given in Section 5.
3.1. Main Header
The main header 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 4.
The "packet size" is encoded in network byte-order. The "packet
size" is the number that results from data size subtracted by number
of bytes allocated for ID, version, and packet size, i.e., 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | BS |C|R|V| PW1 |
| | |1|1|1| |
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|C|R|V| K |U| P1 |U| P2 |R| PW2 |
|2|3|2|2| |1| |2| |3| |
| | | | |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ES | EH |
| | |
|0 1 2 3 4 5 6 7| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Main header format
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.
Check bit #1 (C1): 1 bit
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 8]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
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
Not used (reserved). The value must be 0.
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.
Power #1 (PW1): 5 bits
Signal power code of the current frame. The power value is
quantized to 32 levels, i.e., 5 bits.
Check bit #2 (C2): 1 bit
Validity flag of V2, K, U1, P1, U2, 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 is has this flag set to "1", the payload data
should be ignored and packet-loss concealment should be performed
at 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
Not used (reserved). The value must be "0".
VAD flag #2 (V2): 1 bit
This should be as same as V1. This field is redundant.
Frame indicator (K): 4 bits
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 9]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
This value indicates the frame offset of the values U2 and P2
fields. Naturally, it ranges between "0" and "15".
V/UV flag #1 (U1): 1 bit
Voiced/Unvoiced 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.
Pitch lag #1 (P1): 7 bits
Pitch code of the current frame. The actual pitch lag is
calculated as P1+20 samples. Pitch lag must be 20 <= pitch length
<= 120. Codes ranging between "0x65" and "0x7F" are not used.
V/UV flag #2 (U2): 1 bit
Voice/Unvoice flag of the offset frame. This flag being "1"
indicates that the offset (k) frame is in unvoiced segment, and
"0" indicates that the frame is in voiced segment. The offset
value is defined as K.
Pitch lag #2 (P2): 7 bits
Pitch code of the offset frame. The actual pitch lag is
calculated as P2+20 samples. Pitch lag must be 20 <= pitch length
<= 120. Codes ranging between "0x65" and "0x7F" are not used.
The offset value is defined as K.
Reserved bit #3 (R3): 1 bit
Not used (reserved). The value must be 1.
Power #2 (PW2): 7 bits
Signal power code of the offset frame. The power value is
quantized to 128 levels, i.e., 7 bits. The offset value is
defined as K.
Enhanced-header Size (ES): 8 bits
Size of EH (enhanced header) in bytes.
Enhanced header (EH): 8*ES bits
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 10]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
Content of the enhanced header.
3.2. Sub-layer data
Sub-layer data is notated in the following BNF:
SubLayer ::= SubHeader LayerBitstream
where SubHeader and LayerBitstreams are the sub-header that indicates
the layer location and the number of bytes, and the actual
bitstreams, respectively. The sub-header is encoded with 2 bytes as
shown in Table Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CI| FI| QI| R4| SB | LD |
| | | | | | |
|0 1|0 1|0 1|0 1|0 1 2 3 4 5 6 7| ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Sub-header format
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 #4 (R4): 2 bits
Not used (reserved). The value must be "0".
Sub-layer Size (SB): 8 bits
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 11]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
Indicates the byte size of the following sub-layer data.
Layer Data (LD): SB*8 bits
The actual sub-layer data.
3.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.
+-------+----+----+----+
| Layer | CI | FI | QI |
+-------+----+----+----+
| a | 0 | 0 | 0 |
| | | | |
| b | 0 | 0 | 1 |
| | | | |
| c | 0 | 1 | 0 |
+-------+----+----+----+
Table 3: Layer indices
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 12]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
4. 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 SB=160) are the actual G.711 bitstream data.
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 13]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
5. SIP considerations
Basically, all UEMCLIP payload MUST follow what are described in [2]
and [5]. However, for UEMCLIP specific parameters, should be treated
as follows.
5.1. SDP parameters
Payload type: Since it is not registered in [5], 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 "20". When not
listed in SDP, it should also default to "20".
Bandwidth: As described in [2], 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.
5.2. UEMCLIP specific
Any description specific to UEMCLIP MUST be defined in the Format
Specification Parameters (fmtp). Each parameters MUST be separated
with ";", and if any attributes (value) exists, it MUST be defined
with "+".
The following defines the UEMCLIP specific parameters that can be
described. Any application/terminal MUST ignore any parameters that
does not appear here. This is to ensure the upper-compatibility with
later added parameters for the future enhancements.
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 14]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
5.2.1. Dynamic transmission definition
Since UEMCLIP codec can operate in number of modes, it is desirable
to specify the range of modes that encoder / decoder can operate at.
UEMCLIP decoders is designed to be able 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 allowed. Both modes MUST be used
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 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.
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
defined at all, 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
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 15]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
5.3. Offer-answer model considerations
The procedures related to exchanging SDP messages MUST follow [3].
For matters that are not specified in the document, the implementors
MUST follow the guidelines described as follows:
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 When packet interval (ptime) other than 20 is offered, it is an
error and an answerer MUST explicitly answer 20.
o An offerer SHOULD offer every possible combination of sampling
frequency, channel number, and fmtp parameters including dynamic/
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. This logic
is shown as a flow-chart in Figure ??. 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 Since the current implementation of UEMCLIP encoder does not
support mode changes after instantiations, transmitters SHOULD not
change the modes after establishing the session. Changing the
mode number MUST be restricted to the mode numbers that are
specified with "dynmode" by the answerer (note that the decoder
can always decode bitstreams in other modes.
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 March 30, 2007 [Page 16]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
6. Media type registration
This registration is done using the template defined in [7] and
following [6].
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 7 "Security Considerations" of
this document.
Interoperability considerations: See Section 4 of this document.
Published specification: (To be announced)
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 <hiwasaki.yusuke@lab.ntt.co.jp>
Author/Change controller:
Author: Yusuke Hiwasaki, <hiwasaki.yusuke@lab.ntt.co.jp>
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 17]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
7. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [cite] and any appropriate profile (for example,
[cite]). 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 March 30, 2007 [Page 18]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
8. Congestion Control
The general congestion control considerations for transporting RTP
data apply to UEMCLIP over RTP [4] as well as any applicable RTP
profile like AVP [5]. 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 March 30, 2007 [Page 19]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
9. IANA considerations
It is requested that one new media subtype (audio/UEMCLIP) is
registered by IANA. For details, see Section 6.
Hiwasaki & Ohmuro Expires March 30, 2007 [Page 20]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
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] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
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 March 30, 2007 [Page 21]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
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 March 30, 2007 [Page 22]
Internet-Draft RTP Payload Format for UEMCLIP September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 March 30, 2007 [Page 23]