(SDP) [6] 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.
The data format and parameters are only specified for real-time
transport in RTP.
7.1. Media Type Registration
The media type for the Extended Adaptive Multi-Rate Wideband
(AMR-WB+) codec is allocated from the IETF tree, since AMR-WB+ is
expected to be a widely used audio codec in general streaming
applications.
Note: Parameters not listed below MUST be ignored by the receiver.
Media Type name: audio
Media subtype name: AMR-WB+
Required parameters:
None
Optional parameters:
channels: The maximum number of audio channels used by the
audio frames. Permissible values are 1 (mono) or 2
(stereo). If no parameter is present, the maximum
number of channels is 2 (stereo). Note: When set to
1, implicitly the stereo frame types cannot be used.
interleaving: Indicates that interleaved mode SHALL
be used for the payload. The parameter specifies
the number of transport frame slots required in a
deinterleaving buffer (including the frame that is
ready to be consumed). Its value is equal to one
plus the maximum number of frames that precede any
frame in transmission order and follow the frame in
RTP timestamp order. The value MUST be greater than
zero. If this parameter is not present,
interleaved mode SHALL NOT be used.
int-delay: The minimal media time delay in RTP timestamp ticks
that is needed in the deinterleaving buffer, i.e.,
the difference in RTP timestamp ticks between the
earliest and latest audio frame present in the
deinterleaving buffer.
ptime: See Section 6 in RFC 2327 [6].
maxptime: See Section 8 in RFC 3267 [7].
Restriction on Usage:
This type is only defined for transfer via RTP (STD 64).
Encoding considerations:
An RTP payload according to this format is binary data
and thus may need to be appropriately encoded in non-
binary environments. However, as long as used within
RTP, no encoding is necessary.
Security considerations:
See Section 6 of RFC 4352.
Interoperability considerations:
To maintain interoperability with AMR-WB-capable end-
points, in cases where negotiation is possible and the
AMR-WB+ end-point supporting this format also supports
RFC 3267 for AMR-WB transport, an AMR-WB+ end-point
SHOULD declare itself also as AMR-WB capable (i.e.,
supporting also "audio/AMR-WB" as specified in RFC
3267).
As the AMR-WB+ decoder is capable of performing stereo
to mono conversions, all receivers of AMR-WB+ should be
able to receive both stereo and mono, although the
receiver is only capable of playout of mono signals.
Public specification:
RFC 4352
3GPP TS 26.290, see reference [1] of RFC 4352
Additional information:
This MIME type is not applicable for file storage.
Instead, file storage of AMR-WB+ encoded audio is
specified within the 3GPP-defined ISO-based multimedia
file format defined in 3GPP TS 26.244; see reference
[14] of RFC 4352. This file format has the MIME types
"audio/3GPP" or "video/3GPP" as defined by RFC 3839
[15].
Person & email address to contact for further information:
magnus.westerlund@ericsson.com
ari.lakaniemi@nokia.com
Intended usage: COMMON.
It is expected that many IP-based streaming
applications will use this type.
Change controller:
IETF Audio/Video Transport working group delegated from
the IESG.
7.2. Mapping Media Type Parameters into SDP
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[6], which is commonly used to describe RTP sessions. When SDP is
used to specify an RTP session using this RTP payload format, the
mapping is as follows:
- The media type ("audio") is used in SDP "m=" as the media name.
- The media type (payload format name) is used in SDP "a=rtpmap" as
the encoding name. The RTP clock rate in "a=rtpmap" SHALL be
72000 for AMR-WB+, and the encoding parameter number of channels
MUST either be explicitly set to 1 or 2, or be omitted, implying
the default value of 2.
- The parameters "ptime" and "maxptime" are placed in the SDP
attributes "a=ptime" and "a=maxptime", respectively.
- Any remaining parameters are placed 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.
7.2.1. Offer-Answer Model Considerations
To achieve good interoperability in an Offer-Answer [8] negotiation
usage, the following considerations should be taken into account:
For negotiable offer/answer usage the following interpretation rules
SHALL be applied:
- The "interleaving" parameter is symmetric, thus requiring that the
answerer must also include it for the answer to an offered payload
type that contains the parameter. However, the buffer space value
is declarative in usage in unicast. For multicast usage, the same
value in the response is required in order to accept the payload
type. For streams declared as sendrecv or recvonly: The receiver
will accept reception of streams using the interleaved mode of the
payload format. The value declares the amount of buffer space the
receiver has available for the sender to utilize. For sendonly
streams, the parameter indicates the desired configuration and
amount of buffer space. An answerer is RECOMMENDED to respond
using the offered value, if capable of using it.
- The "int-delay" parameter is declarative. For streams declared as
sendrecv or recvonly, the value indicates the maximum initial
delay the receiver will accept in the deinterleaving buffer. For
sendonly streams, the value is the amount of media time the sender
desires to use. The value SHOULD be copied into any response.
- The "channels" parameter is declarative. For "sendonly" streams,
it indicates the desired channel usage, stereo and mono, or mono
only. For "recvonly" and "sendrecv" streams, the parameter
indicates what the receiver accepts to use. As any receiver will
be capable of receiving stereo frame type and perform local mixing
within the AMR-WB+ decoder, there is normally only one reason to
restrict to mono only: to avoid spending bit-rate on data that are
not utilized if the front-end is only capable of mono.
- The "ptime" parameter works as indicated by the offer/answer model
[8]; "maxptime" SHALL be used in the same way.
- To maintain interoperability with AMR-WB in cases where
negotiation is possible, an AMR-WB+ capable end-point that also
implements the AMR-WB payload format [7] is RECOMMENDED to declare
itself capable of AMR-WB as it is a subset of the AMR-WB+ codec.
In declarative usage, like SDP in RTSP [16] or SAP [17], the
following interpretation of the parameters SHALL be done:
- The "interleaving" parameter, if present, configures the payload
format in that mode, and the value indicates the number of frames
that the deinterleaving buffer is required to support to be able
to handle this session correctly.
- The "int-delay" parameter indicates the initial buffering delay
required to receive this stream correctly.
- The "channels" parameter indicates if the content being
transmitted can contain either both stereo and mono rates, or only
mono.
- All other parameters indicate values that are being used by the
sending entity.
7.2.2. Examples
One example of an SDP session description utilizing AMR-WB+ mono and
stereo encoding follows.
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB+/72000/2
a=fmtp:99 interleaving=30; int-delay=86400
a=maxptime:100
Note that the payload format (encoding) names are commonly shown in
uppercase. Media subtypes are commonly shown in lowercase. These
names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in MIME types and in the default
mapping to the SDP a=fmtp attribute.
8. IANA Considerations
The IANA has registered one new MIME subtype (audio/amr-wb+); see
Section 7.
9. Contributors
Daniel Enstrom has contributed in writing the codec introduction
section. Stefan Bruhn has contributed by writing the ISF recovery
algorithm.
10. Acknowledgements
The authors would like to thank Redwan Salami and Stefan Bruhn for
their significant contributions made throughout the writing and
reviewing of this document. Dave Singer contributed by reviewing and
suggesting improved language. Anisse Taleb and Ingemar Johansson
contributed by implementing the payload format and thus helped locate
some flaws. We would also like to acknowledge Qiaobing Xie, coauthor
of RFC 3267, on which this document is based.
11. References
11.1. Normative References
[1] 3GPP TS 26.290 "Audio codec processing functions; Extended
Adaptive Multi-Rate Wideband (AMR-WB+) codec; Transcoding
functions", version 6.3.0 (2005-06), 3rd Generation Partnership
Project (3GPP).
[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] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise
aspects", version 6.0.0 (2004-12), 3rd Generation Partnership
Project (3GPP).
[5] 3GPP TS 26.193 "AMR Wideband speech codec; Source Controlled
Rate operation", version 6.0.0 (2004-12), 3rd Generation
Partnership Project (3GPP).
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[7] 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.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
11.2. Informative References
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[11] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[12] 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.
[13] 3GPP TS 26.233 "Packet Switched Streaming service", version
5.7.0 (2005-03), 3rd Generation Partnership Project (3GPP).
[14] 3GPP TS 26.244 "Transparent end-to-end packet switched streaming
service (PSS); 3GPP file format (3GP)", version 6.4.0 (2005-09),
3rd Generation Partnership Project (3GPP).
[15] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
Generation Partnership Project (3GPP) Multimedia files", RFC
3839, July 2004.
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[17] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[18] 3GPP TS 26.140 "Multimedia Messaging Service (MMS); Media
formats and codes", version 6.2.0 (2005-03), 3rd Generation
Partnership Project (3GPP).
[19] 3GPP TS 26.140 "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", version 6.3.0 (2005-12), 3rd Generation
Partnership Project (3GPP).
Any 3GPP document can be downloaded from the 3GPP webserver,
"http://www.3gpp.org/", see specifications.
Authors’ Addresses
Johan Sjoberg
Ericsson Research
Ericsson AB
SE-164 80 Stockholm
SWEDEN
Phone: +46 8 7190000
EMail: Johan.Sjoberg@ericsson.com
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm
SWEDEN
Phone: +46 8 7190000
EMail: Magnus.Westerlund@ericsson.com
Ari Lakaniemi
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
FINLAND
Phone: +358-71-8008000
EMail: ari.lakaniemi@nokia.com
Stephan Wenger
Nokia Corporation
P.O. Box 100
FIN-33721 Tampere
FINLAND
Phone: +358-50-486-0637
EMail: Stephan.Wenger@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).