Audio Video Transport WG Sassan Ahmadi
INTERNET-DRAFT Nokia Inc.
Expires: April 1, 2005 October 1, 2004
Real-Time Transport Protocol (RTP) Payload and File Storage
Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
<draft-ietf-avt-rtp-vmr-wb-04.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF AVT WG. Comments should
be directed to the AVT WG mailing list, avt@ietf.org.
Abstract
This document specifies a real-time transport protocol (RTP) payload
format to be used for the Variable-Rate Multimode Wideband (VMR-WB)
speech codec. The payload format is designed to be able to
interoperate with existing VMR-WB transport formats on non-IP
networks. In addition, a file format is specified for transport
of VMR-WB speech data in storage mode applications such as email
A MIME type registration is included, for VMR-WB, specifying use of
both the RTP payload and the storage formats.
VMR-WB is a variable-rate multimode wideband speech codec that has a
number of operating modes, one of which is interoperable with AMR-WB
(i.e., RFC 3267) audio codec at certain rates. Therefore, provisions
have been made in this draft to facilitate and simplify data packet
exchange between VMR-WB and AMR-WB in the interoperable mode with no
transcoding function involved.
Sassan Ahmadi [page 1]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
Table of Contents
1.Introduction.................................................2
2.Conventions and Acronyms.....................................3
3.The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec...4
3.1. Narrowband Speech Processing...........................5
3.2. Continuous vs. Discontinuous Transmission..............6
3.3. Support for Multi-Channel Session......................6
4. Robustness against Packet Loss..............................6
4.1. Forward Error Correction (FEC).........................6
4.2. Frame Interleaving and Multi-Frame Encapsulation.......8
5. VMR-WB Voice over IP scenarios..............................8
5.1. IP Terminal to IP Terminal.............................8
5.2. GW to IP Terminal......................................9
5.3. GW to GW (Between VMR-WB and AMR-WB Enabled Terminals).9
5.4. GW to GW (Between two VMR-WB Enabled Terminals).......10
6. VMR-WB RTP Payload Formats.................................11
6.1. RTP Header Usage.............................. .......11
6.2. Header-Free Payload Format............................12
6.3. Octet-Aligned Payload Format..........................13
6.3.1. Payload Structure................................13
6.3.2. The Payload Header...............................14
6.3.3. The Payload Table of Contents....................17
6.3.4. Speech Data......................................19
6.3.5. Payload Example..................................19
Basic Single Channel Payload Carrying Multiple Frames
6.4. Implementation Considerations.........................20
7. VMR-WB Storage Format......................................20
7.1. Single Channel Header.................................21
7.2. Multi-Channel Header..................................22
7.3. Speech Frames.........................................22
8. Congestion Control.........................................23
9. Security Considerations....................................24
9.1. Confidentiality.......................................24
9.2. Authentication........................................25
9.3. Decoding Validation and Provision for Lost or Late
Packets...............................................25
10. Payload Format Parameters.................................25
10.1. VMR-WB MIME Registration.............................26
10.2. Mapping MIME Parameters into SDP.....................28
10.3. Offer-Answer Model Considerations....................29
11. IANA Considerations.......................................31
12. Acknowledgements..........................................31
References....................................................31
Normative References.......................................31
Informative References.....................................32
Author's Address..............................................32
IPR Notice....................................................33
Copyright Notice..............................................33
1. Introduction
Sassan Ahmadi [page 2]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
This document specifies the payload format for packetization
of VMR-WB encoded speech signals into the Real-time Transport
Protocol (RTP) [3]. The VMR-WB payload formats support
transmission of single and multiple channels, frame
interleaving, multiple frames per payload, header-free
payload, the use of mode switching, and interoperation with
existing VMR-WB transport formats on non-IP networks, as
described in Section 3.
The payload format itself is specified in Section 6. A
related file format is specified in Section 7 for transport
of VMR-WB speech data in storage mode applications such as
email. In Section 10, a MIME type registration for VMR-WB is
provided.
Since VMR-WB is interoperable with AMR-WB at certain rates,
an attempt has been made throughout this document to maximize
the similarities with RFC 3267 while optimizing the payload
and storage formats for the non-interoperable modes of the
VMR-WB codec.
2. Conventions and Acronyms
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 RFC2119 [2].
The following acronyms are used in this document:
3GPP - The Third Generation Partnership Project
3GPP2 - The Third Generation Partnership Project 2
CDMA - Code Division Multiple Access
WCDMA - Wideband Code Division Multiple Access
GSM - Global System for Mobile Communications
AMR-WB - Adaptive Multi-Rate Wideband Codec
VMR-WB - Variable-Rate Multimode Wideband Codec
CMR - Codec Mode Request
GW - Gateway
DTX - Discontinuous Transmission
FEC - Forward Error Correction
SID - Silence Descriptor
TrFO - Transcoder-Free Operation
UDP - User Datagram Protocol
RTP - Real-Time Transport Protocol
RTCP - RTP Control Protocol
MIME - Multipurpose Internet Mail Extension
SDP - Session Description Protocol
VoIP - Voice-over-IP
The term "interoperable mode" in this document refers to VMR-WB
mode 3, which is interoperable with AMR-WB codec modes 0, 1, and 2.
Sassan Ahmadi [page 3]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
The term "non-interoperable modes" in this document refers to
VMR-WB modes 0, 1, and 2.
The term "frame-block" is used in this document to describe
the time-synchronized set of speech frames in a multi-channel
VMR-WB session. In particular, in an N-channel session, a
frame-block will contain N speech frames, one from each of the
channels, and all N speech frames represent exactly the same time
period.
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec
VMR-WB is the wideband speech-coding standard developed by
Third Generation Partnership Project 2 (3GPP2) for
encoding/decoding wideband/narrowband speech content in
multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a
source-controlled variable-rate multimode wideband speech
codec. It has a number of operating modes, where each mode is
a tradeoff between voice quality and average data rate. The
operating mode in VMR-WB is chosen based on the traffic
condition of the network and the desired quality of
service. The desired average data rate (ADR) in each mode
is obtained by encoding speech frames at permissible rates
compliant with CDMA2000 system depending on the
instantaneous characteristics of input speech and the
maximum and minimum rate constraints imposed by the network
operator.
While VMR-WB is a native CDMA codec complying with
all CDMA system requirements, it is further interoperable
with AMR-WB [4] at 12.65, 8.85, and 6.60 kbps. This is due to
the fact that VMR-WB and AMR-WB share the
same core technology. This feature enables Transcoder Free
(TrFO) interconnections between VMR-WB and AMR-WB across
different wireless/wireline systems (e.g., GSM/WCDMA and
CDMA2000) without use of unnecessary complex media format
conversion.
Note that the concept of mode in VMR-WB is different from that of
AMR-WB where each fixed-rate AMR-WB codec mode is adapted to
prevailing channel conditions by a tradeoff between total number of
source-coding and channel-coding bits.
VMR-WB is able to transition between various modes with no
degradation in voice quality that is attributable to the mode
switching itself. The operating mode of the VMR-WB encoder
may be switched seamlessly without prior knowledge of the
decoder. Any non-interoperable mode (i.e., VMR-WB mode 0, 1, or 2)
can be chosen depending on the traffic conditions (e.g.,
network congestion) and the desired quality of service.
While in the interoperable mode (i.e., VMR-WB mode 3), mode
Sassan Ahmadi [page 4]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
switching between VMR-WB modes is not allowed because there is only
one AMR-WB interoperable mode in VMR-WB. Since the AMR-WB codec
may request a mode change, depending on channel conditions,
in-band data included in VMR-WB frame structure (see Section
8 of [1] for more details), is used during an interoperable
interconnection to switch between VMR-WB frame types 0, 1, and
2 in VMR-WB mode 3 (corresponding to AMR-WB codec modes 0, 1, or 2).
As mentioned earlier, VMR-WB is compliant with CDMA2000 system
with the permissible encoding rates shown in Table 1.
+---------------------------+-----------------+---------------+
| Frame Type | Bits per Packet | Encoding Rate |
| | (Frame Size) | (kbps) |
+---------------------------+-----------------+---------------+
| Full-Rate | 266 | 13.3 |
| Half-Rate | 124 | 6.2 |
| Quarter-Rate | 54 | 2.7 |
| Eighth-Rate | 20 | 1.0 |
| Blank | 0 | 0 |
| Erasure | 0 | 0 |
+---------------------------+-----------------+---------------+
Table 1: CDMA2000 system permissible frame types and their
associated encoding rates
VMR-WB is robust to high percentage of frame loss and
frames with corrupted rate information. The reception of
an Erasure (SPEECH_LOST) frame type at decoder invokes the
built-in frame error concealment mechanism. The built-in frame
error concealment mechanism in VMR-WB conceals the effect of
lost frames by exploiting in-band data and the information
available in the previous frames.
3.1. Narrowband Speech Processing
VMR-WB has the capability to operate with 8000 Hz sampled
input/output speech signals in all modes of operation [1].
Mode switching can be utilized to change the mode of
operation while processing narrowband speech signals.
The VMR-WB decoder does not need a priori knowledge about the
sampling rate of the original media (i.e., speech/audio signals
sampled at 8 or 16 kHz) at the input of the encoder. The VMR-WB
decoder, by default, generates 16000 Hz wideband output regardless
of the encoder input sampling frequency, unless instructed
otherwise.
Therefore, while this specification defines a 16000 Hz RTP clock
rate for VMR-WB codec, the injection and processing of 8000 Hz
narrowband media is also allowed. The choice of VMR-WB output
sampling frequency depends on the application/implementation and the
audio acoustic capabilities of the receiving side.
Sassan Ahmadi [page 5]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
3.2. Continuous vs. Discontinuous Transmission
The circuit-switched operation of VMR-WB within a CDMA
network requires continuous transmission of the speech data
during a conversation. The intrinsic source-controlled
variable-rate feature of the CDMA speech codecs is required
for optimal operation of the CDMA system and interference
control. However, VMR-WB has the capability to operate in a
discontinuous transmission mode for some packet-switched
applications over IP networks (e.g., VoIP), where the number of
transmitted bits and packets during silence period are
reduced to a minimum. The VMR-WB DTX operation is similar to
that of AMR-WB [4,12].
3.3 Support for Multi-Channel Session
Both the octet-aligned RTP payload format and the storage
format defined in this document support multi-channel audio
content (e.g., a stereophonic speech session).
Although VMR-WB codec itself does not support encoding of
multi-channel audio content into a single bit stream, it can
be used to separately encode and decode each of the
individual channels.
To transport (or store) the separately encoded multi-channel
content, the speech frames for all channels that are framed
and encoded for the same 20 ms periods are logically
collected in a frame-block.
At the session setup, out-of-band signaling must be used to
indicate the number of channels in the session and the order
of the speech frames from different channels in each frame-block.
When using SDP for signaling (see Section 10.2 for more
details), the number of channels is specified in the rtpmap
attribute and the order of channels carried in each frame-block
is implied by the number of channels as specified in Section
4.1 in [6].
4. Robustness against Packet Loss
The octet-aligned payload format described in this document
(see Section 6 for more details) supports several features
including forward error correction (FEC) and frame interleaving
in order to increase robustness against lost packets.
4.1. Forward Error Correction (FEC)
The simple scheme of repetition of previously sent data is
one way of achieving FEC. Another possible scheme, which is
more bandwidth efficient is to use payload external FEC; e.g.,
Sassan Ahmadi [page 6]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
RFC2733 [5], which generates extra packets containing repair
data.
The repetition method involves the simple retransmission of
previously transmitted frame-blocks together with the current
frame-block(s). This is done by using a sliding window to
group the speech frame-blocks to send in each payload. Figure
1 illustrates an example.
In this example each frame-block is retransmitted one time in
the following RTP payload packet. Here, f(n-2)..f(n+4)
denotes a sequence of speech frame-blocks and p(n-1)..p(n+4)
a sequence of payload packets.
The use of this approach does not require signaling at the
session setup. In other words, the speech sender can choose
to use this scheme without consulting the receiver. This is
because a packet containing redundant frames will not look
different from a packet with only new frames. The receiver
may receive multiple copies or versions of a frame for a
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmission.
certain timestamp if no packet is lost. If multiple versions
of the same speech frame are received, it is RECOMMENDED that
the highest rate be used by the speech decoder.
This redundancy scheme provides the same functionality as the
one described in RFC 2198 "RTP Payload for Redundant Audio
Data" [10]. In most cases the mechanism in this payload
format is more efficient and simpler than requiring both
endpoints to support RFC 2198. If the spread in time required
between the primary and redundant encodings is larger than 5
frame times, the bandwidth overhead of RFC 2198 will be lower.
The sender is responsible for selecting an appropriate amount
of redundancy based on feedback about the channel, e.g., in
RTCP receiver reports, or network traffic. A sender SHOULD NOT
base selection of FEC on the CMR, as this parameter most probably
was set based on non-IP information. The sender is also responsible
for avoiding congestion, which may be aggravated by redundant
transmission (see Section 8).
Sassan Ahmadi [page 7]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
4.2. Frame Interleaving and Multi-Frame Encapsulation
To decrease protocol overhead, the octet-aligned payload
format, described in Section 6, allows several speech
frame-blocks to be encapsulated into a single RTP packet.
One of the drawbacks of such approach is that in case of packet
loss this means loss of several consecutive speech frame-blocks,
which usually causes clearly audible distortion in the
reconstructed speech.
Interleaving of frame-blocks can improve the speech quality
in such cases by distributing the consecutive losses into a
series of single frame-block losses. However, interleaving
and bundling several frame-blocks per payload will also
increase end-to-end delay and is therefore not appropriate
for all types of applications. Streaming applications will
most likely be able to exploit interleaving to improve speech
quality in lossy transmission conditions.
The octet-aligned payload format supports the use of frame
interleaving as an option. For the encoder (speech sender) to
use frame interleaving in its outbound RTP packets for a
given session, the decoder (speech receiver) needs to
indicate its support via out-of-band means (see Section 10).
5. VMR-WB Voice over IP Scenarios
5.1 IP Terminal to IP Terminal
The primary scenario for this payload format is IP end-to-end
between two terminals incorporating VMR-WB codec, as shown in
Figure 2. Nevertheless, this scenario can be generalized to an
interoperable interconnection between VMR-WB and AMR-WB enabled IP
terminals using the offer-answer model described in Section 10.3.
This payload format is expected to be useful for both conversational
and streaming services.
+----------+ +----------+
| | | |
| TERMINAL |<----------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+----------+ +----------+
(or AMR-WB/RTP/UDP/IP)
Figure 2: IP terminal to IP terminal
A conversational service puts requirements on the payload
format. Low delay is a very important factor, i.e. fewer
speech frame-blocks per payload packet. Low overhead is also
required when the payload format traverses across low
bandwidth links, especially if the frequency of packets will
be high.
Sassan Ahmadi [page 8]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
Streaming service has less strict real-time requirements and
therefore can use a larger number of frame-blocks per packet
than conversational service. This reduces the overhead from
IP, UDP, and RTP headers. However, including several
frame-blocks per packet makes the transmission more vulnerable to
packet loss, so interleaving may be used to reduce the effect
of packet loss on speech quality. A streaming server handling
a large number of clients also needs a payload format that
requires as few resources as possible when doing packetization.
For VMR-WB enabled IP terminals at both ends, depending on the
implementation, all modes of the VMR-WB codec can be used in this
scenario. Also both header-free and octet-aligned payload
formats, see Section 6 for details, can be utilized. For the
interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB
mode 3 is used and all restrictions described in Section 10.3 apply.
5.2 GW to IP Terminal
Another scenario occurs when VMR-WB encoded speech will be
transmitted from a non-IP system (e.g., 3GPP2/CDMA2000 network) to
an IP terminal, and/or vice versa, as depicted in Figure 3.
VMR-WB over
3GPP2/CDMA2000 network
+------+ +----------+
| | | |
<-------------->| GW |<---------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+------+ +----------+
|
| IP network
|
Figure 3: GW to VoIP terminal scenario
VMR-WB's capability to seamlessly switch between operational
modes is exploited in CDMA (non-IP) networks to optimize
speech quality for a given traffic condition. To preserve
this functionality in scenarios including a gateway to an IP
network using the octet-aligned payload format, a codec mode
request (CMR) field is considered. The gateway will be
responsible for forwarding the CMR between the non-IP and IP
parts in both directions. The IP terminal SHOULD follow the
CMR forwarded by the gateway to optimize speech quality going
to the non-IP decoder. The mode control algorithm in the
gateway SHOULD accommodate the delay imposed by the IP
network on the response to CMR by the IP terminal.
The IP terminal SHOULD NOT set the CMR (see Section 6.3.2),
but the gateway can set the CMR value on frames going toward
the encoder in the non-IP part to optimize speech quality
Sassan Ahmadi [page 9]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
from that encoder to the gateway.
For the frames going toward the IP terminal, the gateway can
alternatively set a different CMR value, if desired, as one
means to control congestion on the IP network.
5.3 GW to GW (Between VMR-WB and AMR-WB Enabled Terminals)
A third likely scenario is that RTP/UDP/IP is used as
transport between two non-IP systems, i.e., IP is originated
and terminated in gateways on both sides of the IP transport,
as illustrated in Figure 4. This is the most likely scenario
for an interoperable interconnection between 3GPP/(GSM-WCDMA)/AMR-WB
and 3GPP2/CDMA2000/VMR-WB enabled mobile stations. In this scenario,
the VMR-WB enabled terminal also declares itself capable of AMR-WB
with restricted mode set as described in Section 10.3. The CMR value
may be set in packets received by the gateways on the IP network
side. The gateway should forward to the
VMR-WB over AMR-WB over
3GPP2/CDMA2000 network 3GPP/(GSM-WCDMA) network
+------+ +------+
(AMR-WB Payload) | | AMR-WB/RTP/UDP/IP | | (AMR-WB Payload)
<---------------->| GW |<----------------->| GW |<---------------->
| | | |
+------+ +------+
| IP network |
| |
Figure 4: GW to GW scenario (AMR-WB <-> VMR-WB
interoperable interconnection)
non-IP side a CMR value that is the minimum of two values (1)
the CMR value it receives on the IP side; and (2) a CMR value
it may choose for congestion control of transmission on the
IP side. The details of the traffic control algorithm are left to
the implementation.
During and upon initiation of an interoperable
interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3
can be used. There are three Frame Types (i.e., FT=0, 1, or
2 see Table 3) within this mode that are compatible with
AMR-WB codec modes 0, 1, and 2, respectively. If the AMR-WB codec is
engaged in an interoperable interconnection with VMR-WB, the active
AMR-WB codec mode set needs to be limited to 0, 1, and 2.
5.4 GW to GW (Between two VMR-WB Enabled Terminals)
The fourth example VoIP scenario comprises a RTP/UDP/IP
transport between two non-IP systems, i.e., IP is originated
Sassan Ahmadi [page 10]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
VMR-WB over VMR-WB over
3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
Figure 5: GW to GW scenario (a CDMA2000 MS-to-MS VoIP scenario)
and terminated in gateways on both sides of the IP transport,
as illustrated in Figure 5. This is the most likely scenario
for Mobile Station-to-Mobile Station (MS-to-MS) Transcoder-Free
(TrFO) interconnection between two 3GPP2/CDMA2000 terminals that
both use VMR-WB codec.
6. VMR-WB RTP Payload Formats
For a given session, the payload format can be either header
free or octet-aligned, depending on the mode of operation
that is established for the session via out-of-band means and
the application.
The header-free payload format is designed for maximum
bandwidth efficiency, simplicity, and low latency. Only one
codec data frame can be sent in each header-free payload
format. None of the payload header fields or ToC entries is
present (same consideration is also made in [11]).
In the octet-aligned payload format, all the fields in a
payload, including payload header, table of contents entries,
and speech frames themselves, are individually aligned to
octet boundaries to make implementations efficient.
Note that octet alignment of a field or payload means that
the last octet is padded with zeroes in the least significant
bits to fill the octet. Also note that this padding is
separate from padding indicated by the P bit in the RTP
header.
Between the two payload formats, only the octet-aligned
format has the capability to use the interleaving to make the
speech transport robust to packet loss.
The VMR-WB octet-aligned payload format in the interoperable
mode is identical to that of AMR-WB (i.e., RFC 3267).
6.1. RTP Header Usage
Sassan Ahmadi [page 11]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
The format of the RTP header is specified in [3]. This
payload format uses the fields of the header in a manner
consistent with that specification.
The RTP timestamp corresponds to the sampling instant of the
first sample encoded for the first frame-block in the packet.
The timestamp clock frequency is the same as the default sampling
frequency (i.e., 16 kHz), so the timestamp unit is in samples.
The duration of one speech frame-block is 20 ms for VMR-WB.
For normal wideband operation of VMR-WB, the input/output
sampling frequency is 16 kHz, corresponding to 320 samples
per frame from each channel. Thus, the timestamp is increased
by 320 for VMR-WB for each consecutive frame-block.
The VMR-WB codec is capable of processing speech/audio signals
sampled at 8 kHz. By default, the VMR-WB decoder output sampling
frequency is 16 kHz, unless instructed otherwise. Since the VMR-WB
RTP payload formats for the 8 and 16 kHz sampled media are identical
and the VMR-WB decoder does not need a priori knowledge about the
encoder input sampling frequency, a fixed RTP clock rate
of 16000 Hz is defined for VMR-WB codec. This would allow
injection or processing of 8 kHz sampled speech/audio media without
having to change the RTP clock rate.
The choice of VMR-WB output sampling frequency (i.e., 8 or 16 kHz)
depends on the application/implementation and the audio acoustic
capabilities of the receiving side.
A packet may contain multiple frame-blocks of encoded speech
or comfort noise parameters. If interleaving is employed, the
frame-blocks encapsulated into a payload are picked according
to the interleaving rules as defined in Section
6.3.2. Otherwise, each packet covers a period of one or more
contiguous 20 ms frame-block intervals. In case the data from
all the channels for a particular frame-block in the period
is missing, for example at a gateway from some other
transport format, it is possible to indicate that no data is
present for that frame-block rather than breaking a
multi-frame-block packet into two, as explained in Section 6.3.2.
No matter which payload format is used, the payload is always
made an integral number of octets long by padding with zero bits
if necessary. If additional padding is required to bring the
payload length to a larger multiple of octets or for some other
purpose, then the P bit in the RTP header MAY be set and padding
appended as specified in [3].
The RTP header marker bit (M) SHALL be always set to 0 if the
VMR-WB codec operates in continuous transmission. When
operating in discontinuous transmission (DTX), the RTP header
marker bit SHALL be set to 1 if the first frame-block carried
in the packet contains a speech frame, which is the first in
Sassan Ahmadi [page 12]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
a talkspurt. For all other packets the marker bit SHALL be
set to zero (M=0).
The assignment of an RTP payload type for this payload
format is outside the scope of this document, and will not be
specified here. It is expected that the RTP profile under
which this payload format is being used will assign a payload
type for this encoding or specify that the payload type is to
be bound dynamically (see Section 10).
6.2. Header-Free Payload Format
The header-free payload format is designed for maximum
bandwidth efficiency, simplicity, and minimum delay. Only one
speech data frame can be sent in each header-free payload
format. None of the payload header fields or ToC entries is
present. The encoding rate for the speech frame can be
determined from the length of the speech data frame, since
there is only one speech data frame in each header-free
payload format.
The use of the RTP header fields for header-free payload format
is the same as the corresponding one for the octet-aligned
payload format. The detailed bit mapping of speech data
packets permissible for this payload format is described in
Section 8 of [1].
Since the header-free payload format is not compatible with
AMR-WB RTP payload, only non-interoperable modes of VMR-WB SHALL
be used with this payload format. That is FT=0,1,2,and 9 SHALL NOT
be used with header-free payload format.
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 [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the mode of operation, using this payload format,
is decided by the transmitting (encoder) site. The default
mode of operation for VMR-WB encoder is mode 0 [1]. The mode
change request MAY also be sent through non-RTP means, which
is out of the scope of this specification.
6.3. Octet-Aligned Payload Format
6.3.1 Payload Structure
Sassan Ahmadi [page 13]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
The complete payload consists of a payload header, a payload table
of contents, and speech data representing one or more speech
frame-blocks. The following diagram shows the general payload format
layout:
+----------------+-------------------+----------------
| Payload header | Table of contents | Speech data ...
+----------------+-------------------+----------------
6.3.2. The Payload Header
In octet-aligned payload format the payload header consists
of a 4-bit CMR, 4 reserved bits, and optionally, an 8 bit
interleaving header, as shown below
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): Indicates a codec mode request sent to the speech
encoder at the site of the receiver of this payload. CMR value 15
indicates that no mode request is present, and other unused values
are reserved for future use.
The value of the CMR field is set according to the following Table:
+-------+----------------------------------------------------------+
| CMR | VMR-WB Operating Modes |
+-------+----------------------------------------------------------+
| 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) |
| 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) |
| 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) |
| 3 | VMR-WB mode 2 |
| 4 | VMR-WB mode 1 |
| 5 | VMR-WB mode 0 |
| 6 | VMR-WB mode 2 with maximum half-rate encoding |
| 7-14 | (reserved) |
| 15 | No Preference (no mode request is present) |
+-------+----------------------------------------------------------+
Table 2: List of valid CMR values and their associated VMR-WB
operating modes.
R: is a reserved bit that MUST be set to zero. The receiver
MUST ignore all R bits.
ILL (4 bits, unsigned integer): This is an OPTIONAL field
that is present only if interleaving is signaled out-of-band
for the session. ILL=L indicates to the receiver that the
interleaving length is L+1, in number of frame-blocks.
ILP (4 bits, unsigned integer): This is an OPTIONAL field
Sassan Ahmadi [page 14]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
that is present only if interleaving is signaled. ILP MUST
take a value between 0 and ILL, inclusive, indicating the
interleaving index for frame-blocks in this payload in the
interleave group. If the value of ILP is found greater than
ILL, the payload SHOULD be discarded.
ILL and ILP fields MUST be present in each packet in a
session if interleaving is signaled for the session.
The mode request received in the CMR field is valid until the
next CMR is received, i.e. a newly received CMR value
overrides the previous one. Therefore, if a terminal
continuously wishes to receive frames in the same mode x, it
needs to set CMR=x for all its outbound payloads, and if a
terminal has no preference in which mode to receive, it
SHOULD set CMR=15 in all its outbound payloads.
If receiving a payload with a CMR value, which is not valid,
the CMR MUST be ignored by the receiver.
In a multi-channel session, CMR SHOULD be interpreted by the
receiver of the payload as the desired encoding mode for all
the channels in the session, if the network allows.
There are two factors that affect the VMR-WB mode selection, (i) the
performance of any CDMA link connected via a gateway (e.g., in a GW
to IP terminal scenario), and (ii) the congestion state of an IP
network. The CDMA link performance is signaled via the CMR field,
which is not used by IP-only end-points. The IP network state is
monitored using, for example, RTCP. A sender needs to select the
operating mode to satisfy both these constraints (see Section 8).
The encoder SHOULD follow a received mode request, but MAY
change to a different mode if the network necessitates it,
for example to control congestion.
The CMR field MUST be set to 15 for packets sent to a
multicast group. The encoder in the speech sender SHOULD
ignore mode requests when sending speech to a multicast
session but MAY use RTCP feedback information as a hint that
a mode change is needed.
If interleaving option is utilized, interleaving MUST be performed
on a frame-block basis as opposed to a frame basis in a
multi-channel session.
The following example illustrates the arrangement of speech
frame-blocks in an interleave group during an interleave
session. Here we assume ILL=L for the interleave group that
starts at speech frame-block n. We also assume that the
first payload packet of the interleave group is s and the
number of speech frame-blocks carried in each payload is N.
Then we will have
Sassan Ahmadi [page 15]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
Payload s (the first packet of this interleave group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
Carry frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+
(N-1)*(L+1)
The next interleave group will start at frame-block n+N*(L+1).
There will be no interleaving effect unless the number of
frame-blocks per packet (N) is at least 2. Moreover, the
number of frame-blocks per payload (N) and the value of ILL
MUST NOT be changed inside an interleave group. In other
words, all payloads in an interleave group MUST have the same
ILL and MUST contain the same number of speech frame-blocks.
The sender of the payload MUST only apply interleaving if the
receiver has signaled its use through out-of-band means.
Since interleaving will increase buffering requirements at
the receiver, the receiver uses MIME parameter "interleaving=I" to
set the maximum number of frame-blocks allowed in an interleaving
group to I.
When performing interleaving the sender MUST use a proper number of
frame-blocks per payload (N) and ILL so that the resulting size of
an interleave group is less than or equal to I, i.e., N*(L+1)<=I.
The following example shows the ToC of three consecutive
packets, each carrying 3 frame-blocks, in an interleaved two
channel session. Here, the two channels are left (L) and right (R)
with L coming before R, and the interleaving length is 3 (i.e.,
ILL=2). This makes the interleave group 9 frame-blocks large.
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 4 Block 7
Sassan Ahmadi [page 16]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 3 Block 6 Block 9
6.3.3. The Payload Table of Contents
The table of contents (ToC) in octet-aligned payload format
consists of a list of ToC entries where each entry
corresponds to a speech frame carried in the payload, i.e.,
when interleaving is used, the frame-blocks in the ToC will
almost never be placed consecutive in time. Instead, the
presence and order of the frame-blocks in a packet will
+---------------------+
| list of ToC entries |
+---------------------+
follow the pattern described in 6.3.2.
A ToC entry for the octet-aligned payload format is as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The table of contents (ToC) consists of a list of ToC
entries, each representing a speech frame.
F (1 bit): If set to 1, indicates that this frame is followed
by another speech frame in this payload; if set to 0,
indicates that this frame is the last frame in this payload.
Sassan Ahmadi [page 17]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
FT (4 bits): Frame type index whose value is chosen according
to Table 3:
During the interoperable mode, FT=14 (SPEECH_LOST) and FT=15
(NO_DATA) are used to indicate frames that are either lost or
not being transmitted in this payload, respectively. FT=14 or
15 MAY be used in the non-interoperable modes to indicate
frame erasure or blank frame, respectively (see Section 2.1
of [1]).
If a payload with an invalid FT value is received, the payload MUST
be discarded.
+----+--------------------------------------------+-------------------+
| FT | Encoding Rate | Frame Size (Bits) |
+----+--------------------------------------------+-------------------+
| 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 |
| 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 |
| 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 |
| 3 | Full-Rate 13.3 kbps | 266 |
| 4 | Half-Rate 6.2 kbps | 124 |
| 5 | Quarter-Rate 2.7 kbps | 54 |
| 6 | Eighth-Rate 1.0 kbps | 20 |
| 7 | (reserved) | - |
| 8 | (reserved) | - |
| 9 | CNG (AMR-WB SID) | 35 |
| 10 | (reserved) | - |
| 11 | (reserved) | - |
| 12 | (reserved) | - |
| 13 | (reserved) | - |
| 14 | Erasure (AMR-WB SPEECH_LOST) | 0 |
| 15 | Blank (AMR-WB NO_DATA) | 0 |
+----+--------------------------------------------+-------------------+
Table 3:VMR-WB payload frame types for real-time transport and
storage formats
Note that for ToC entries with FT=14 or 15, there will be no
corresponding speech frame in the payload.
Depending on the application and the mode of operation of VMR-WB,
any combination of the permissible frame types (FT) shown in Table 3
MAY be used.
Q (1 bit): Frame quality indicator. If set to 0, indicates
the corresponding frame is corrupted. During the
interoperable mode, the receiver side (with AMR-WB codec)
should set the RX_TYPE to either SPEECH_BAD or SID_BAD
depending on the frame type (FT), if Q=0. The VMR-WB encoder
always sets Q bit to 1. The VMR-WB decoder may ignore the Q bit.
P bits: Padding bits MUST be set to zero and MUST be ignored by
a receiver.
For multi-channel sessions, the ToC entries of all frames
Sassan Ahmadi [page 18]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
from a frame-block are placed in the ToC in consecutive order.
Therefore, with N channels and K speech frame-blocks in a
packet, there MUST be N*K entries in the ToC, and the first N
entries will be from the first frame-block, the second N
entries will be from the second frame-block, and so on.
6.3.4. Speech Data
Speech data of a payload contains one or more speech frames as
described in the ToC of the payload.
Each speech frame represents 20 ms of speech encoded in one
of the available encoding rates depending on the operation
mode. The length of the speech frame is defined by the frame
type in the FT field with the following considerations:
- The last octet of each speech frame MUST be padded with
zeroes at the end if not all bits in the octet are used.
In other words, each speech frame MUST be octet-aligned.
- When multiple speech frames are present in the speech
data, the speech frames MUST be arranged one whole frame
after another.
The order and numbering notation of the speech data bits are
as specified in the VMR-WB standard specification [1].
The payload begins with the payload header of one octet or
two if frame interleaving is selected. The payload header is
followed by the table of contents consisting of a list of
one-octet ToC entries.
The speech data follows the table of contents. For the purpose of
packetization, all of the octets comprising a speech frame are
appended to the payload as a unit. The speech frames are packed in
the same order as their corresponding ToC entries are arranged in
the ToC list, with the exception that if a given frame has a ToC
entry with FT=14 or 15, there will be no data octets present for
that frame.
6.3.5. Payload Example: Basic Single Channel Payload Carrying Multiple
Frames
The following diagram shows an octet-aligned payload format
from a single channel session that carries two VMR-WB Full-Rate
frames (FT=3). In the payload, a codec mode request is
sent (e.g., CMR=4), requesting the encoder at the receiver's
side to use VMR-WB mode 1. No interleaving is used. Note, in
above example the last octet in both speech frames
is padded with zeros to make them octet-aligned.
Sassan Ahmadi [page 19]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | l |P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r= f1(264,265)
l= f2(264,265)
6.4. Implementation Considerations
An application implementing this payload format MUST
understand all the payload parameters in the out-of-band
signaling used. For example, if an application uses SDP, all
the SDP and MIME parameters in this document MUST be
understood. This requirement ensures that an implementation
always can decide if it is capable or not of communicating.
To enable efficient interoperable interconnection with AMR-WB
and to ensure that a VMR-WB terminal appropriately declares itself
as AMR-WB capable terminal (see Section 10.3), it is also
RECOMMENDED that a VMR-WB RTP payload implementation understand
relevant AMR-WB signaling.
To further ensure interoperability between various implementations
of VMR-WB, implementations SHALL support both header-free and
octet-aligned payload formats. Support of interleaving is optional.
7. VMR-WB Storage Format
The storage format is used for storing VMR-WB encoded speech
frames in a file or as an e-mail attachment. Multiple channel
content is also supported. The storage format described in section
is fully consistent with the one described in Section 8.5 of [1].
Note: The storage format described in this document uses several
magic numbers to differentiate between interoperable and
non-interoperable modes of VMR-WB as well as single and
multi-channel files. This may be accomplished in other ways that are
simpler and more straightforward that one should consider in design
of future storage formats. The use of different magic numbers and
file extensions for the files generated by the interoperable and
Sassan Ahmadi [page 20]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
non-interoperable modes of VMR-WB enables a file reader to decide if
it is capable of decoding the content without opening the file or
attempting to decode the content.
In general, VMR-WB file has the following structure:
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+
7.1. Single channel Header
A single channel VMR-WB file header contains only a magic number.
The magic number for single channel VMR-WB files containing
speech data generated in the non-interoperable modes; i.e.,
VMR-WB modes 0, 1, or 2, MUST consist of ASCII character
string
"#!VMR-WB\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x0a in hexadecimal).
Note, the "\n" is an important part of the magic numbers and
MUST be included in the comparison; otherwise, the single
channel magic number above will become indistinguishable from
that of the multi-channel file defined in the next section.
The magic number for single channel VMR-WB files containing
speech data generated in the interoperable mode; i.e., VMR-WB
mode 3, MUST consist of ASCII character string
"#!VMR-WB_I\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x5F 0x49 0x0a in
hexadecimal).
In the interoperable mode, a file generated by VMR-WB is decodable
with AMR-WB (with the exception of different magic numbers).
However, VMR-WB can only decode AMR-WB codec modes 0, 1, and 2.
The AMR-WB single channel magic number and AMR-WB file extension
[4] can also be used to store speech data generated by VMR-WB
encoder operating in the interoperable mode to facilitate decoding
of the file by an AMR-WB decoder. Since VMR-WB decoder is only
capable of decoding certain AMR-WB codec modes, it MUST be ensured
that only supported codec modes of AMR-WB are presented to the
VMR-WB decoder.
Sassan Ahmadi [page 21]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
7.2. Multi-channel Header
The multi-channel header consists of a magic number followed
by a 32-bit channel description field, giving the multi-channel
header the following structure:
+----------------------------+
| Magic Number |
+----------------------------+
| Channel Description Field |
+----------------------------+
The magic number for multi-channel VMR-WB files containing
speech data generated in the non-interoperable modes; i.e.,
VMR-WB modes 0, 1, or 2, MUST consist of the ASCII character string
"#!VMR-WB_MC1.0\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x5F 0x4D 0x43 0x31
0x2E 0x30 0x0a in hexadecimal).
The version number in the magic numbers refers to the version
of the file format.
The magic number for multi-channel VMR-WB files containing
speech data generated in the interoperable mode; i.e., VMR-WB
mode 3, MUST consist of the ASCII character string
"#!VMR-WB_MCI1.0\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x5F 0x4D 0x43 0x49
0x31 0x2E 0x30 0x0a in hexadecimal).
The 32-bit channel description field is defined as
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits: MUST be set to 0 when written, and a reader
MUST ignore them.
CHAN (4 bit unsigned integer): Indicates the number of audio
channels contained in this storage file. The valid values and
the order of the channels within a frame-block are specified
in Section 4.1 in [6].
The AMR-WB multi-channel magic number and AMR-WB file extension [4]
can also be used to store speech data generated by VMR-WB encoder
operating in the interoperable mode to facilitate decoding of the
file by an AMR-WB decoder. Since VMR-WB decoder is only capable of
decoding certain AMR-WB codec modes, it MUST be ensured that only
supported codec modes of AMR-WB are presented to the VMR-WB decoder.
Sassan Ahmadi [page 22]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
7.3. Speech Frames
After the file header, speech frame-blocks consecutive in time are
stored in the file. Each frame-block contains a number of
octet-aligned speech frames equal to the number of channels, and
stored in increasing order, starting with channel 1. Each stored
speech frame starts with a one-octet frame header with the following
format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The FT field is defined as shown in Table 3. Padding bits MUST be
set to zero and MUST be ignored by a receiver.
Q (1 bit): Frame quality indicator. If set to 0, indicates
the corresponding frame is corrupted. The VMR-WB encoder
always sets Q bit to 1. The VMR-WB decoder may ignore the Q bit.
Following this one octet header, the speech bits are placed
as defined in 6.3.4. The last octet of each frame is padded
with zeroes, if needed, to achieve octet alignment.
The following example shows a VMR-WB speech frame encoded at
Half-Rate (with 124 speech bits) in the storage format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| FT=4 |1|0|0| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |0|0|0|0|
+-+-+-+-+-+-+-+-+
Frame-blocks or speech frames lost in transmission MUST be stored as
Erasure/SPEECH_LOST (FT=14) and non-received frame-blocks between
SID updates during non-speech periods (when using DTX) MUST be
stored as Blank/NO_DATA frames (FT=15) in complete frame-blocks to
maintain synchronization with the original media.
8. Congestion Control
The general congestion control considerations for transporting RTP
data apply to VMR-WB speech over RTP as well. However, the multimode
Sassan Ahmadi [page 23]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
capability of VMR-WB speech codec may provide an advantage over
other payload formats for controlling congestion since the bandwidth
demand can be adjusted by selecting a different operating mode.
Another parameter that may impact the bandwidth demand for
VMR-WB is the number of frame-blocks that are encapsulated in
each RTP payload. Packing more frame-blocks in each RTP
payload can reduce the number of packets sent and hence the
overhead from RTP/UDP/IP headers, at the expense of increased delay.
If forward error correction (FEC) is used to alleviate the
packet loss, the amount of redundancy added by FEC will need
to be regulated so that the use of FEC itself does not cause
a congestion problem.
Congestion control for RTP SHALL be used in accordance with RFC 3550
[3] and any applicable RTP profile, for example RFC 3551 [6]. This
means that congestion control is required for any transmission over
unmanaged best-effort networks.
Congestion on the IP network is managed by the IP sender. Feedback
about congestion SHOULD be provided to that IP sender through RTCP
or other means, and then the sender can choose to avoid congestion
using the most appropriate mechanism. That may include selecting an
appropriate operating mode, but also includes adjusting the level of
redundancy or number of frames per packet.
9. Security Considerations
RTP packets using the payload formats defined in this specification
are subject to the general security considerations discussed in [3].
As this format transports encoded speech, the main security
issues include confidentiality and authentication of the
speech itself. The payload format itself does not have any
built-in security mechanisms. External mechanisms, such as
SRTP [9], MAY be used.
This payload format does not exhibit any significant non-uniformity
in the receiver side computational complexity for packet processing
and thus is unlikely to pose a denial-of-service threat due to the
receipt of pathological/corrupted data.
9.1. Confidentiality
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 profile (for example [6]).
This implies that confidentiality of the media streams is achieved
By encryption. Because the data compression used with this payload
format is applied end-to-end, encryption may be performed after
Sassan Ahmadi [page 24]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
compression so there is no conflict between the two operations.
Interleaving may affect encryption. Depending on the encryption
scheme used, there may be restrictions on, for example, the time
when keys can be changed. Specifically, the key change may need to
occur at the boundary between interleave groups.
9.2. Authentication
To authenticate the sender of the speech, an external mechanism MUST
be used. It is RECOMMENDED that such a mechanism protect all speech
data bits.
Data tampering by a man-in-the-middle attacker could result
in erroneous depacketization/decoding that could lower the
speech quality. For example, tampering with the CMR field may
result in speech in a different quality than desired.
To prevent a man-in-the-middle attacker from tampering with
the payload packets, some additional information besides the
speech bits SHOULD be protected.
This may include the payload header, ToC, RTP timestamp, RTP
sequence number, SSRC, RTP payload type, and the RTP marker bit.
9.3. Decoding Validation and Provision for Lost or Late Packets
When processing a received payload packet, if the receiver
finds that the calculated payload length, based on the
information of the session and the values found in the
payload header fields, do not match the size of the received
packet, the receiver SHOULD discard the packet to avoid
potential degradation of speech quality and to invoke the
VMR-WB built-in frame error concealment mechanism. Therefore,
invalid packets SHALL be treated as lost packets.
Late packets (i.e., unavailability of a packet when needed
for decoding at the receiver) should be treated as lost
packets. Furthermore, if the late packet is part of an
interleave group, depending upon the availability of the
other packets in that interleave group, decoding must be
resumed from the next (sequential order) available frame. In
other words, the unavailability of a packet in an interleave
group at certain time should not invalidate the other
packets within that interleave group that may arrive later.
10. Payload Format Parameters
This section defines the parameters that may be used to
select optional features in the VMR-WB payload and storage formats.
Sassan Ahmadi [page 25]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
The parameters are defined here as part of the MIME subtype
registration for the VMR-WB speech codec. A mapping of the
parameters into the Session Description Protocol (SDP) [5] is
also provided for those applications that use SDP. Equivalent
parameters could be defined elsewhere for use with control
protocols that do not use MIME or SDP.
10.1. VMR-WB MIME Registration
The MIME subtype for the Variable-Rate Multimode Wideband
(VMR-WB) audio codec is allocated from the IETF tree since
VMR-WB is expected to be a widely used speech codec in
multimedia streaming and messaging as well as VoIP
applications. This MIME registration covers both real-time
transfer via RTP and non-real-time transfers via stored
files.
Note, the receiver MUST ignore any unspecified parameter and
use the default values instead.
Media Type name: audio
Media subtype name: VMR-WB
Required parameters: none
Note that if no input parameters are defined, the default
values will be used.
Also note that if the interleaving parameter is present, the
parameter "octet-align=1" MUST also be present.
OPTIONAL parameters:
These parameters apply to both RTP payload and storage formats.
mode-set: Requested VMR-WB operating mode set. Restricts
the active operating modes to a subset of all
modes. Possible values are a comma separated
list of integer values. Currently, this list
includes modes 0,1,2, and 3 [1] but MAY be
extended in the future. If such mode-set is
specified during session initiation, the encoder
MUST NOT use modes outside of the subset. If not
present, all operating modes in the set 0 to 3 are
allowed for the session.
channels: The number of audio channels. The possible
values and their respective channel order
is specified in section 4.1 in [6]. If
omitted it has the default value of 1.
Sassan Ahmadi [page 26]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
These parameters apply to RTP payload only.
octet-align: RTP payload format, permissible values are 0 and
1. If 1, octet-aligned payload format SHALL be
used. If 0 or if not present, header-free payload
format is employed (default).
maxptime: See RFC 3267 [4]
interleaving: Indicates that frame-block level
interleaving SHALL be used for the session
and its value defines the maximum number of
frame-blocks allowed in an interleaving
group (see Section 6.3.1). If this
parameter is not present, interleaving
SHALL not be used. The presence of this
parameter also implies automatically that
octet-aligned operation SHALL be used.
ptime: see RFC2327 [5]. It SHALL be at least one
frame size for VMR-WB.
dtx: Permissible values are 0 and 1. The default
is 0 (i.e., No DTX) where VMR-WB normally
operates as a continuous variable-rate
codec. If dtx=1, the VMR-WB codec will
operate in discontinuous transmission mode
where silence descriptor (SID) frames are
sent by the VMR-WB encoder during silence
intervals with an adjustable update
frequency. The selection of the SID update-rate
depends on the implementation and
other network considerations that are
beyond the scope of this specification.
Encoding considerations:
This type is defined for transfer via both RTP (RFC
3550) and stored-file methods as described in Sections
6 and 7, respectively, of RFC XXXX. The stored file format is
binary data and must be encoded for non-binary
transport; the Base64 encoding is suitable in many cases.
Security considerations:
See Section 9 of RFC XXXX.
Public specification:
The VMR-WB speech codec is specified in following
3GPP2 specifications C.S0052-0 version 1.0.
Transfer methods are specified in RFC XXXX.
Additional information:
Sassan Ahmadi [page 27]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
The following applies to stored-file transfer method:
Magic numbers:
Single channel (for the non-interoperable modes)
ASCII character string "#!VMR-WB\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x0a in
hexadecimal)
Single channel (for the interoperable mode)
ASCII character string "#!VMR-WB_I\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x5F 0x49 0x0a
in hexadecimal)
Multi-channel (for the non-interoperable modes)
ASCII character string "#!VMR-WB_MC1.0\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x5F 0x4D 0x43
0x31 0x2E 0x30 0x0a in hexadecimal)
Multi-channel (for the interoperable mode)
ASCII character string "#!VMR-WB_MCI1.0\n"
(or 0x23 0x21 0x56 0x4d 0x52 0x2d 0x57 0x42 0x5F 0x4D 0x43
0x49 0x31 0x2E 0x30 0x0a in hexadecimal)
File extensions for the non-interoperable modes: vmr, VMR
Macintosh file type code: none
Object identifier or OID: none
File extensions for the interoperable mode: vmi, VMI
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
Sassan Ahmadi, Ph.D. Nokia Inc. USA
sassan.ahmadi@nokia.com
Intended usage: COMMON.
It is expected that many VoIP, multimedia messaging and
streaming applications (as well as mobile applications)
will use this type.
Author/Change controller:
IETF Audio/Video Transport working group delegated from the IESG
10.2. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification
has a specific mapping to fields in the Session Description
Protocol (SDP) [5], which is commonly used to describe RTP
Sassan Ahmadi [page 28]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
sessions. When SDP is used to specify sessions employing the
VMR-WB codec, the mapping is as follows:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP
"a=rtpmap" as the encoding name. The RTP clock rate in
"a=rtpmap" MUST be 16000 for VMR-WB.
- The parameter "channels" (number of channels) MUST
either be explicitly set to N or omitted, implying a
default value of 1. The values of N that are allowed is
specified in Section 4.1 in [6]. The parameter "channels" SHOULD
be specified subsequent to the MIME subtype and RTP clock rate as
an encoding parameter in the "a=rtpmap" attribute.
- The parameter "ptime" goes in the SDP "a=ptime" attribute.
- Any remaining parameters go in the SDP "a=fmtp" attribute
by copying them directly from the MIME media type string
as a semicolon separated list of parameter=value pairs.
Some example SDP session descriptions utilizing VMR-WB
encodings follow.
Example of usage of VMR-WB in a possible VoIP scenario
(wideband audio):
m=audio 49120 RTP/AVP 98
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
Example of usage of VMR-WB in a possible streaming scenario
(two channel stereo):
m=audio 49120 RTP/AVP 99
a=rtpmap:99 VMR-WB/16000/2
a=fmtp:99 interleaving=30; maxptime=100; octet-align=1
10.3. Offer-Answer Model Considerations
To achieve good interoperability for the VMR-WB RTP payload in an
Offer-Answer negotiation usage in SDP [13] the following
considerations are made:
- The rate, channel, and payload configuration parameters
(octet-align and interleaving) SHALL be used symmetric, i.e.
offer and answer must use the same values. The maximum size of
the interleaving buffer is, however, declarative, and each agent
specifies the value it supports.
- To maintain interoperability among all implementations of VMR-WB
Sassan Ahmadi [page 29]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
that may or may not support all the codec's modes of operation,
the operational modes that are supported by an implementation
MAY be identified at session initiation. The mode-set parameter
is declarative, and only operating modes that has been indicated
to be supported by both ends SHALL be used. If the answerer is
not supporting any of the operating modes provided in the offer,
the complete payload type declaration SHOULD be rejected by
removing it in the answer.
- The remaining parameters are all declarative; i.e. for sendonly
streams they provide parameters that the agent desires to use,
while for recvonly and sendrecv streams they declare the
parameters that it accepts to receive. The dtx parameter is used
to indicate support and capability of using DTX, while the media
sender is only RECOMMENDED to send using the DTX in these cases.
If DTX is not supported by the media sender, it will send media
without DTX, this will not affect interoperability only the
resource consumption.
- Both header-free and octet-aligned payload format configurations
MAY be offered by a VMR-WB enabled terminal. However, for an
interoperable interconnection with AMR-WB only octet-aligned
payload format SHALL be used.
- The parameters "maxptime" and "ptime" should in most cases not
affect the interoperability, however the setting of the
parameters can affect the performance of the application.
- To maintain interoperability with AMR-WB in cases where
negotiation is possible using the VMR-WB interoperable mode, a
VMR-WB enabled terminal SHOULD also declare itself capable of
AMR-WB with limited mode set (i.e., only AMR-WB codec modes 0,
1, and 2 are allowed) and octet-align mode of operation.
Example:
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000/1
a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 octet-align=1; mode-set=0,1,2
An example of offer-answer exchange for the VoIP scenario described
in Section 5.3 is as follows:
CDMA2000 terminal -> WCDMA terminal Offer:
m=audio 49120 RTP/AVP 98 97
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1
WCDMA terminal -> CDMA2000 terminal Answer:
m=audio 49120 RTP/AVP 97
Sassan Ahmadi [page 30]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1;
For declarative use of SDP such as in SAP [14] and RTSP [15], all
parameters are declarative and provides the parameters that SHALL be
used when receiving and/or sending the configured stream.
11. IANA Considerations
It is requested that one new MIME subtype (audio/VMR-WB) is
registered by IANA, see Section 10.
12. Acknowledgements
The author would like to thank Redwan Salami of VoiceAge
Corporation, Ari Lakaniemi of Nokia Inc., and IETF/AVT chairs Colin
Perkins and Magnus Westerlund for their technical comments
to improve this document.
Also, the author would like to acknowledge that some parts of
RFC 3267 [4] and RFC 3558 [11] have been used in this document.
References
Normative References
[1] 3GPP2 C.S0052-0 v1.0 "Source-Controlled Variable-Rate
Multimode Wideband Speech Codec (VMR-WB) Service Option
62 for Spread Spectrum Systems", 3GPP2 Technical Specification,
Oct. 2004.
[2] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Internet Engineering
Task Force, March 1997.
[3] H. Schulzrinne, S. Casner, R. Frederick, and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, Internet Engineering Task
Force, Sept. 2003.
[4] J. Sjoberg, et al., "Real-Time Transport Protocol (RTP)
Payload Format and File Storage Format for the Adaptive
Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 3267, Internet
Engineering Task Force, June 2002.
[5] M. Handley and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, Internet Engineering Task Force, April
1998.
Sassan Ahmadi [page 31]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
[6] H. Schulzrinne, "RTP Profile for Audio and Video
Conferences with Minimal Control" STD 65, RFC 3551, Internet
Engineering Task Force, July 2003.
Informative References
[7] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, Internet Engineering Task Force, January 2003.
[8] J. Rosenberg, and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, Internet
Engineering Task Force, December 1999.
[9] Baugher, et. al., "The Secure Real Time Transport Protocol",
RFC 3711, Internet Engineering Task Force, March 2004.
[10] C. Perkins, et al., "RTP Payload for Redundant Audio
Data", RFC 2198, Internet Engineering Task Force, September
1997.
[11] A. Li, "RTP Payload Format for Enhanced Variable Rate
Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558,
Internet Engineering Task Force, Sept. 2003.
[12] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source
Controlled Rate operation", version 5.0.0 (2001-03), 3rd
Generation Partnership Project (3GPP).
[13] J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, Internet
Engineering Task Force, June 2002.
[14] M. Handley, C. Perkins, and E. Whelan, "Session Announcement
Protocol (SAP)", RFC 2974, Internet Engineering Task Force,
Oct. 2000.
[15] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, Internet Engineering Task Force,
April 1998.
Any 3GPP2 document can be downloaded from the 3GPP2 web
server, "http://www.3gpp2.org/", see specifications.
Author's Address
The editor will serve as the point of contact for all
technical matters related to this document.
Dr. Sassan Ahmadi Phone: 1 (858) 831-5916
Fax: 1 (858) 831-4174
Sassan Ahmadi [page 32]
INTERNET-DRAFT VMR-WB RTP Payload & File Storage Formats Oct. 2004
Nokia Inc. Email: sassan.ahmadi@nokia.com
12278 Scripps Summit Dr.
San Diego, CA 92131 USA
This Internet-Draft expires in six months from October 1, 2004.
RFC Editor Considerations
The RFC editor is requested to replace all occurrences of XXXX with
the RFC number this document receives.
IPR Notice
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.
Copyright Notice
Copyright (C) The Internet Society (2004). 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.
Sassan Ahmadi [page 33]