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 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 that the encoder at the receiver’s side use VMR-WB mode 1.
No interleaving is used. Note that in the example below the last
octet in both speech frames is padded with zeros to make them octet
aligned.
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. Any mapping of the parameters to a signaling
protocol MUST support all parameters. Therefore, an implementation
of this payload format in an application using SDP is required to
understand all the payload parameters in their SDP-mapped form. This
requirement ensures that an implementation always can decide whether
it is capable of communicating.
To enable efficient interoperable interconnection with AMR-WB and to
ensure that a VMR-WB terminal appropriately declares itself as a
AMR-WB-capable terminal (see Section 9.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.
6.4.1. 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, does 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., the unavailability of a packet when it is 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 available
frame (sequential order). In other words, the unavailability of a
packet in an interleave group at a certain time should not invalidate
the other packets within that interleave group that may arrive later.
7. Congestion Control
The general congestion control considerations for transporting RTP
data apply to VMR-WB speech over RTP as well. However, the multimode
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.
8. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in RTP
[3] and any applicable profile such as AVP [9] or SAVP [10].
As this format transports encoded audio, the main security issues
include confidentiality, integrity protection, and data origin
authentication of the audio itself. The payload format itself does
not have any built-in security mechanisms. Any suitable external
mechanisms, such as SRTP [10], MAY be used.
This payload format and the VMR-WB decoder do not exhibit any
significant non-uniformity in the receiver-side computational
complexity for packet processing; thus, they are unlikely to pose a
denial-of-service threat due to the receipt of pathological data.
8.1. Confidentiality
In order to ensure confidentiality of the encoded audio, all audio
data bits MUST be encrypted. There is less need to encrypt the
payload header or the table of contents since they only carry
information about the frame type. This information could also be
useful to a third party, for example, for quality monitoring.
The use of interleaving in conjunction with encryption can have a
negative impact on the confidentiality for a short period of time.
Consider the following packets (in brackets) containing frame numbers
as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a typical
continuous diagonal interleaving pattern). The originator wishes to
deny some participants the ability to hear material starting at time
16. Simply changing the key on the packet with the timestamp at or
after 16, and denying the new key to those participants, does not
achieve this; frames 17, 18, and 21 have been supplied in prior
packets under the prior key, and error concealment may make the audio
intelligible at least as far as frame 18 or 19, and possibly further.
8.2. Authentication and Integrity
To authenticate the sender of the speech, an external mechanism MUST
be used. It is RECOMMENDED that such a mechanism protects both the
complete RTP header and the payload (speech and data bits).
Data tampering by a man-in-the-middle attacker could replace audio
content and also result in erroneous depacketization/decoding that
could lower the audio quality. For example, tampering with the CMR
field may result in speech of a different quality than desired.
9. Payload Format Parameters
This section defines the parameters that may be used to select
optional features in the VMR-WB RTP payload formats.
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. In control protocols
that do not use MIME or SDP, the media type parameters must be mapped
to the appropriate format used with that control protocol.
9.1. VMR-WB RTP Payload 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 in VoIP applications. This MIME registration
only covers real-time transfers via RTP.
Note, the receiver MUST ignore any unspecified parameter and use the
default values instead. Also note that if no input parameters are
defined, the default values will be used.
Media Type name: audio
Media subtype name: VMR-WB
Required parameters: none
Furthermore, if the interleaving parameter is present, the parameter
"octet-align=1" MUST also be present.
OPTIONAL parameters:
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.
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.
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 only defined for transfer of VMR-WB-encoded data
via RTP (RFC 3550) using the payload formats specified in
Section 6 of RFC 4348.
Security considerations:
See Section 8 of RFC 4348.
Public specification:
The VMR-WB speech codec is specified in
3GPP2 specifications C.S0052-0 version 1.0.
Transfer methods are specified in RFC 4348.
Additional information:
Person & email address to contact for further information:
Sassan Ahmadi, Ph.D. sassan.ahmadi@ieee.org
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
9.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 sessions. When SDP is
used to specify sessions employing the VMR-WB codec, the mapping is
as follows:
- The media type ("audio") goes in SDP "m=" as the media name.
- The media 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 be either
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", if present, is specified
subsequent to the MIME subtype and RTP clock rate as an encoding
parameter in the "a=rtpmap" attribute.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and
"a=maxptime" attributes, respectively.
- 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 examples of 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 octet-align=1; interleaving=30
a=maxptime:100
9.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 symmetrically, 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 receive for recvonly and
sendrecv streams. For sendonly streams, the value indicates what
the agent desires to use.
- To maintain interoperability among all implementations of VMR-WB
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 have 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
from 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
DTX support and capability, 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
- 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 of octet-align mode of operation.
Example:
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000
a=rtpmap:99 AMR-WB/16000
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
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 provide the parameters that SHALL be
used when receiving and/or sending the configured stream.
10. IANA Considerations
The IANA has registered one new MIME subtype (audio/VMR-WB); see
Section 9.
11. 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.
12. References
12.1. 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, July 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[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] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "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, June 2002.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
12.2. Informative References
[7] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia
Services", 3GPP2 Technical Specification, September 2005.
[8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[10] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[11] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
Any 3GPP2 document can be downloaded from the 3GPP2 web server,
"http://www.3gpp2.org/", see specifications.
Author’s Address
Dr. Sassan Ahmadi
EMail: sassan.ahmadi@ieee.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information