Audio/Video Transport Y. Hiwasaki
Internet-Draft H. Ohmuro
Intended status: Standards Track NTT Corporation
Expires: August 28, 2008 February 25, 2008
RTP payload format for mU-law EMbedded Codec for Low-delay IP
communication (UEMCLIP) speech codec
draft-ietf-avt-rtp-uemclip-04
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 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 1]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
Abstract
This document describes the RTP payload format of a mU-law EMbedded
Coder for Low-delay IP communication (UEMCLIP), an enhanced speech
codec of ITU-T G.711. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
3.2. Multiple frames in an RTP packet . . . . . . . . . . . . . 7
3.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Main Header . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Sub-layer . . . . . . . . . . . . . . . . . . . . . . 11
4. Transcoding between UEMCLIP and G.711 . . . . . . . . . . . . 13
5. Congestion Control Considerations . . . . . . . . . . . . . . 14
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15
6.1. Media type registration . . . . . . . . . . . . . . . . . 15
6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 16
6.2.1. Mode specification . . . . . . . . . . . . . . . . . . 17
6.3. Offer-Answer Model Considerations . . . . . . . . . . . . 17
6.3.1. Offer-Answer Guidelines . . . . . . . . . . . . . . . 18
6.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 2]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
1. Introduction
This document specifies the payload format for sending "mU-law
EMbedded Coder for Low-delay IP communication" (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 while achieving a very little media
transcoding load with the existing terminals, in which the
implementation of G.711 is mandatory.
It should be noted that, generally speaking, codecs are negotiated
and switched using SDP exchange. Also, [3] defines general RTP mixer
and translator models, where media transcoding may not take place at
the node. For those cases, the design concept of the embedded
structure is not useful. However, there are other cases when costly
transcoding is unavoidable in commonly deployed types of Multi-point
Control Units (MCUs) which terminates media and RTCP packets [9], and
when narrowband and wideband terminals co-exist. This embedded
bitstream structure can reduce the media transcoding to a simple
bitstream truncation.
The background and the basic idea of the media format is described in
Section 2. The details of the payload format are given in Section 3.
The transcoding issues with G.711 are discussed in Section 4, and the
considerations for congestion control are in Section 5. In
Section 6, the payload format parameters for a media type
registration for UEMCLIP RTP payload format and SDP mappings are
provided. The security considerations and IANA considerations are
dealt in Section 7 and Section 8, respectively.
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 28, 2008 [Page 3]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
2. Media Format Background
UEMCLIP is basically an enhanced version of u-law ITU-T G.711,
otherwise known as PCMU [8]. It is targeted at Voice over Internet
Protocol (VoIP) applications, and its main goal 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. In widely deployed
multi-point conferencing systems, the packets usually go through
RTCP-terminating MCUs, "Topo-RTCP-terminating-MCU" as defined in [9].
Because the G.711 bitstream is embedded in the bitstream, costly
media transcoding can be avoided in this case.
This document does not discuss the implementation details of the
encoder and decoder, but only describes the bitstream format.
Because of its scalable nature, there are a number of sub-bitstreams
(sub-layer) 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 UEMCLIP codec operates at 20-ms frame, and includes three sub-
coders as shown in Table 1. The core layer is u-law G.711 at 64
kbit/s, and other two are quality and bandwidth enhancement layers
with bit-rate of 16 kbit/s each.
+-------+---------------------+----------+--------------------------+
| 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
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 4]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
absent Modes 2 and 5 are reserved for possible 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 | 67.2 |
| | | | | | | | |
| 1 | 1 | 16 | x | - | x | 80 | 84.0 |
| | | | | | | | |
| 2 | - | - | - | - | - | - | - |
| | | | | | | | |
| 3 | 1 | 8 | x | x | - | 80 | 84.0 |
| | | | | | | | |
| 4 | 1 | 16 | x | x | x | 96 | 100.8 |
| | | | | | | | |
| 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.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
same sampling frequency or number of channels. The supported modes
would differ between implementations, thus the sender and the
receiver must negotiate what mode to use for transmission.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 5]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
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 (MH) followed by one or more (up to three)
sub-layers (SL) as shown in Figure 2.
+--+-------+//-+
|MH| SL #1 |...|
+--+-------+//-+
Figure 2: A UEMCLIP frame (bitstream format)
As a sub-layer, the core layer, i.e., "Layer a", MUST always be
included. It should be noted that the location of the core layer may
not be located at the top. The decoder MUST always refer to the
layer indices for proper decoding.
The UEMCLIP bitstream does not explicitly include the following
information: mode and sampling frequency (Fs). As described before,
this information MUST 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:
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.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 6]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
Timestamp: This encodes the sampling instant of the first speech
signal sample in the RTP data packet. For UEMCLIP streams, the
RTP timestamp MUST advance based on a clock which is multiple of
8000 (Hz). In cases where the audio sampling rate can change
during a session, the RTP timestamp rate MUST equal to the maximum
rate (in Hz) given in the mode range (see Section 6.2.1). This
implies that the RTP timestamp rate MUST NOT change during a
session. For example, during a session with 8-kHz audio sampling,
where a transition to a 16-kHz audio sampling mode is allowed, the
RTP time stamp must always advance using 16-kHz clock rate. For a
session using a fixed audio sampling mode, the RTP timestamp rate
should be either 8 or 16 kHz, based on the sampling rate.
Marker bit: If the codec is used for applications with discontinuous
transmission (DTX, or silence compression), the first packet after
a silence period during which packets have not been transmitted
contiguously SHOULD have the marker bit in the RTP data header set
to one. The marker bit in all other packets MUST be zero.
Applications without DTX MUST set the marker bit to zero.
3.2. Multiple frames in an RTP packet
More than one UEMCLIP frame may be included in a single RTP packet by
a sender. However, senders have the following additional
restrictions:
o A single RTP packet SHOULD NOT include more UEMCLIP frames than
will fit in the path MTU.
o All frames contained in a single RTP packet MUST be of the same
mode.
o Frames MUST NOT be split between RTP packets.
It is RECOMMENDED that the number of frames contained within an RTP
packet be consistent with the application. Since UEMCLIP is designed
for telephony application where delay has a great impact on the
quality, then fewer frames per packet for lower delay, is preferable.
3.3. Payload Data
In a UEMCLIP bitstream, all numbers are encoded in a network byte-
order.
3.3.1. Main Header
The main header (MH) is placed at the top of a frame and has size of
6 bytes. The content of the main header is shown in Figure 3.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 7]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MX | PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PC(cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: UEMCLIP main header format (MH)
Mixing information (MX): 8 bits
Mixing information field. This field is only relevant when Topo-
RTCP-terminating-MCUs are utilized to interpret these fields. See
Section 3.3.1.1 for details of the fields.
Packet-loss Concealment information (PC): 40 bits
Packet-loss concealment (PLC) information field. See
Section 3.3.1.2.
3.3.1.1. Mixing information field
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|R|V| PW1 |
|1|1|1| |
+-+-+-+-+-+-+-+-+
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. If any of these parameters is invalid, this
bit should be set to "0". This flag is used for a UEMCLIP-
conscious Topo-RTCP-terminating-MCU. This flag should be set to
"0" in case of upward transcoding from G.711 (See Section 4).
Reserved bit #1 (R1): 1 bit
This bit should be ignored. The default of this bit is 0.
VAD flag #1 (V1): 1 bit
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 8]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
Voice activity detection flag of the current frame, designed to be
used for MCU operations. 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. This flag is
specifically designed for mixing information. DTX judgment based
this flag is not recommended.
Power #1 (PW1): 5 bits
Signal power code of the current frame.
3.3.1.2. PLC information field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R2 |V| K |U| P1 |U| P2 | PW2 |
|2| |2| |1| |2| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R3 |
| |
+-+-+-+-+-+-+-+-+
Figure 5: PLC information field (PC)
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, this bit should be set to "0". Similarly to C1, this
flag should be set to "0" in case of upward transcoding from G.711
(See Section 4).
Reserved bit #2 (R2): 2 bits
These bits should be ignored. The default of these bits are 0.
VAD flag #2 (V2): 1 bit
Voice activity detection flag of the current frame, designed to be
used for packet-loss concealment. This might not be as same as V1
in the mixing information, and might not be synchronous to the
marker bit in the RTP header. DTX judgment based this flag is not
recommended.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 9]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
Frame indicator (K): 4 bits
This value indicates the frame offset of U2, P2 and PW2. Since it
is a better idea to carry the speech feature parameters as PLC
information in a different frame to maintain the speech quality,
this frame offset value gives which frame the parameters are to be
associated with. The value ranges between "0" and "15". If the
current frame number is N, for example, the value K indicates that
U2, P2 and PW2 are associated with frame of N-K. Frame indicator
is equal to the difference in the RTP sequence number when one
UEMCLIP frame is contained in a single RTP packet.
V/UV flag #1 (U1): 1 bit
Voiced/Unvoiced signal indicator of the current frame. This flag
being "0" indicates that the frame is a voiced signal segment, and
"1" indicates that it is an unvoiced signal segment.
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.
V/UV flag #2 (U2): 1 bit
Voiced/Unvoiced signal indicator of the offset frame. This flag
being "0" indicates that the frame is a voiced signal segment, and
"1" indicates that it is an unvoiced signal 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 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 #3 (R3): 8 bits
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 10]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
These bits should be ignored. The default of all bits are "0".
3.3.2. Sub-layer
Sub-layer (SL) 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.
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 |R4 | SB | LD ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
Figure 6: Sub-layer format (SL)
Channel index (CI): 2 bits
Indicates the channel number. For all modes given in Table 2,
this should be "0". 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 default value is "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.
For all the layers shown in Table 1, the layer indices are shown in
Table 3.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 11]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
+-------+----+----+----+
| Layer | CI | FI | QI |
+-------+----+----+----+
| a | 0 | 0 | 0 |
| | | | |
| b | 0 | 0 | 1 |
| | | | |
| c | 0 | 1 | 0 |
+-------+----+----+----+
Table 3: Layer indices
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 12]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
4. Transcoding between UEMCLIP and G.711
As given in Section 2, u-law encoded G.711 bitstream (Layer a) is the
core layer of a UEMCLIP bitstream, and is always embedded. This
means that media transcoding from UEMCLIP bitstream to G.711 does not
have to undergo decoding and re-encoding procedures, but simple
extraction would suffice. However, this does not apply for the
reverse procedure, i.e., transcoding from G.711 to UEMCLIP, because
the auxiliary information in the main header (MH) must be assigned
separately. It should be noted that this media transcoding is useful
only in RTP devices that terminate RTP and RTCP packets. This is
equivalent to a Point to Multipoint Using RTCP Terminating MCU (Topo-
RTCP-terminating-MCU) in [9] and all the requirements apply. This
means that a transcoding device of this sort MUST rewrite RTCP
packets, together with the RTP media packets.
The transcoding from UEMCLIP to u-law G.711 can be done easily by
finding an appropriate sub-layer. Within a frame, the transcoder
should look for a sub-layer with layer index "0x00", and subsequent
LD which has size of SB*8 bits (UEMCLIP has a 20-ms frame thus,
SB=160) are the actual G.711 bitstream data. It should be noted that
transcoder should not always 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. Since there are no means to generate
enhancement sub-layers, a G.711 bitstream can only be converted to
UEMCLIP Mode 0 bitstream. If the original G.711 bitstream is encoded
in A-law, it should first be converted to u-law to become the core
layer. Because a UEMCLIP frame size is 20 ms, u-law encoded G.711
bitstream MUST be a 160-sample chunk to become a core layer. For the
main header contents, when the UEMCLIP encoder is not available, it
should follow the following guidelines.
o The check bits for mixing and PLC (C1 and C2) are set to 0.
o The reserved bits (R1 to R3) in MH are set to respective default
values.
For the core layer (i.e., u-law G.711 bitstream), it should have the
following sub-layer header:
o All CI, FI, QI, and R4 MUST be 0.
o Sub-layer size (SB) MUST be 160 for 20 ms frame.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 13]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
5. Congestion Control Considerations
The general congestion control considerations for transporting RTP
data also apply to UEMCLIP over RTP [3] as well as any applicable RTP
profile like AVP [4].
The bandwidth of a UEMCLIP bitstream can be reduced by changing to
lower-bit-rate modes. The embedded layer structure of UEMCLIP may
help to control congestion, when dynamic mode changing (see
Section 6.2.1) is available, and the range of modes is obtained by
offer-answer negotiation as given in Section 6.3. It should be noted
that this involves proper RTCP handling when the bit-rate is modified
in an RTP translator or a mixer [3].
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. It should be treated with care because increased
delay means reduced quality.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 14]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
6. Payload Format Parameters
6.1. Media type registration
This registration is done using the template defined in [5] and
following [7].
Media type name: audio
Media subtype name: UEMCLIP
Required parameters:
Rate: Defines the sampling rate, and MUST be either 8000 or
16000. See Section 6.2.1 "Mode specification" of RFC xxxx
(this RFC) for details.
Optional parameters:
ptime: See RFC 4566 [6].
maxptime: See RFC 4566 [6].
mode: Indicates the range of dynamically changeable modes during
a session. Possible values are comma separated list of modes
from the supported mode set: 0, 1, 3, and 4. If only one mode
is specified, it means that the mode must not be changed during
the session. When not specified, the mode transmission
defaults to a singular mode as specified in Table 4. See
Section 6.2.1 "Mode specification" of RFC xxxx (this RFC) for
details.
Encoding considerations: This type is defined for transferring
UEMCLIP-encoded data via RTP using the payload format specified in
Section 3 "Payload Format" of RFC xxxx (this RFC). This media
type is framed and binary.
Security considerations: See Section 7 "Security Considerations" of
RFC xxxx (this RFC).
Interoperability considerations: This media may be readily
transcoded to u-law encoded ITU-T G.711. See Section 4
"Transcoding between UEMCLIP and G.711" of RFC xxxx (this RFC).
Published specification: RFC xxxx (This RFC)
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 15]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
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:
Author: Yusuke Hiwasaki
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
6.2. Mapping to SDP Parameters
The media types audio/UEMCLIP are mapped to fields in the Session
Description Protocol (SDP) [6] as follows:
Media name: The "m=" line of SDP MUST be audio.
Encoding name: Registered media subtype name should be used for the
"a=rtpmap" line.
Sampling Frequency: Depending on the mode, clock rate (sampling
frequency) specified in "a=rtpmap" MUST be selected from the ones
defined in Table 2. See Section 6.2.1 for details.
Encoding parameters: Since this is an audio stream, the encoding
parameters indicate the number of audio channels, and this SHOULD
default to "1", as selected from the ones defined in Table 2.
This is OPTIONAL.
Packet time: A frame length of any UEMCLIP is 20 ms, thus the
argument of "a=ptime" MUST be a multiple of "20". When not listed
in SDP, it should also default to the minimum size: "20".
UMECLIP specific: Any description specific to UEMCLIP are defined in
the Format Specification Parameters ("a=fmtp"). Each parameter
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 it does not
understand. This is to ensure the upper-compatibility with
parameters added in future enhancements. The mode specification
parameters should be defined here (see Section 6.2.1).
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 16]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
6.2.1. Mode specification
Since UEMCLIP codec can operate in number of modes (bit-rates), it is
desirable to specify the range of modes that an encoder or a decoder
can operate at. When exchanging SDP messages, an offerer should
specify all possible combination of mode numbers as arguments to
"mode=" in "a=fmtp" line, delimited by commas ",". In case of
specifying multiple modes, those SHOULD appear in the descending
priority order.
Although UEMCLIP decoders SHOULD accept bitstreams in any modes, an
implementation may fail to adopt to the dynamic mode changes during a
session. For this reason, an application may choose to operate
either with one fixed mode or with multiple modes that can be
dynamically changed. If the mode is to be fixed and changes are not
allowed, this can be indicated by specifying a single mode per
payload type.
The mode numbers that can be specified in a payload type as arguments
to "mode" are restricted by a combination of a clock rate and a
number of audio channels. This is because SDP binds a payload type
to a combination of a sampling frequency and a number of audio
channels. Table 4 gives selectable mode numbers that attributed with
clock rates. When mode specifications are not given at all, a
payload type MUST default to a single mode using the default value
specified in this table.
+------------+----------+------------------+--------------+
| Clock rate | Channels | Selectable modes | Default mode |
+------------+----------+------------------+--------------+
| 8000 | 1 | 0,3 | 0 |
| | | | |
| 16000 | 1 | 0,1,3,4 | 1 |
+------------+----------+------------------+--------------+
Table 4: Default modes
It should be noted that a mode attributed with a larger sampling
frequency (Fs) is not used in conjunction with smaller clock rates
specified in "a=rtpmap". This means that Modes 0 and 3 can be
specified in a payload type having clock rate of both 8000 and 16000
in "a=rtpmap", but Modes 1 and 4 cannot be specified with one having
clock rate of 8000.
6.3. Offer-Answer Model Considerations
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 17]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
6.3.1. Offer-Answer Guidelines
The procedures related to exchanging SDP messages MUST follow [2].
Followings are additional guidelines for establishing a session using
an offer-answer model.
o An offerer SHOULD offer every possible combination of UEMCLIP
payload type it can handle, i.e., sampling frequency, channel
number, and fmtp parameters, in a preferred order. When the
transmission bandwidth is restricted, it MUST be offered in
accordance to the restriction.
o When multiple UEMCLIP payload types are offered, it is RECOMMENDED
that the answerer selects a single UEMCLIP payload type and
answers it back.
o In a UEMCLIP payload type, an answerer MUST answer back suitable
mode number(s) as a subset of what has been offered.
o In an offering/answering SDP, any fmtp parameters which are not
known 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 A receiver of an SDP message MUST only use specified payload types
and modes. When a mode specification is missing, i.e., a mode is
not specified at all, the session MUST default to one single mode
without mode changes during a session. For this case, the default
mode values, as shown in Table 4, MUST be used based on the
sampling frequency and number of channels. This table must be
looked up only when there are no mode specifications, thus the
offerer/answerer MUST NOT assume that the default modes are always
available when it is not in the specified list of modes.
o When an offered condition does not fit an answerer's capabilities,
it naturally MUST NOT answer any of 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.
6.3.2. Examples
When an offerer indicates that he/she wishes to dynamically switch
between modes (0,1,3, and 4) during a session, an example of an
offered SDP can be:
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 18]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4,1,3,0
It should be noted that the listed modes appears in the offerer's
preference.
When an answerer can only operate in Modes 1 and 0 but can
dynamically switch between those modes during a session, an answerer
MUST delete the entries of Mode 3 and 4, and answer back as:
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1,0
As a result, both would start communicating in either Mode 1 or 0,
and can dynamically switch between those modes during the session.
On the other hand, when the answerer is capable of communicating
either in Modes 1 or 0, and cannot switch between modes during a
session, an example of such answer is as follows:
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1
As a result, both will start communicating in Mode 1. It should be
noted that mode change during this session is not allowed because the
answerer responded with a single mode, and answerer selected Mode 1
above Mode 0 according to the offered order.
If an offerer does not want a mode change during a session but is
capable of receiving either Modes 4 or 1 bitstreams, the SDP should
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 19]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
somewhat look like:
v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96 97
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1
and if the answerer prefers to communicate in Mode 1, an answer would
be:
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 97
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1
Please note that it is RECOMMENDED to select a single UEMCLIP payload
type for answers.
The "ptime" attribute is used to denote the desired packetization
interval. When not specified, it SHOULD default to 20. Since
UEMCLIP uses 20 msec frames, ptime values of multiples of 20 imply
multiple frames per packet. In the example below, the ptime is set
to 60, and this means that offerer wants to receive 3 frames in each
packet.
v=0
o=kosuke 2890844730 2890844730 IN IP4 anotherhost.example.com
s=-
c=IN IP4 anotherhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=ptime:60
a=rtpmap:96 UEMCLIP/16000/1
When mode specification is not present, it should default to a fixed
mode, and in this case, Mode 1 (see Section 6.2.1).
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 20]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
7. 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 by
other means.
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 and may force reading beyond the bitstream
boundaries.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 21]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
8. IANA Considerations
It is requested that one new media subtype (audio/UEMCLIP) is
registered by IANA. For details, see Section 6.1.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 22]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
9. References
9.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] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[7] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
[8] Casner, S., "Media Type Registration of Payload Formats in the
RTP Profile for Audio and Video Conferences", RFC 4856,
February 2007.
9.2. Informative References
[9] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
Hiwasaki & Ohmuro Expires August 28, 2008 [Page 23]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
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 28, 2008 [Page 24]
Internet-Draft RTP Payload Format for UEMCLIP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 28, 2008 [Page 25]
