data that cannot be used. Second, it makes the configuration of
the bit stream explicit to the receiver so that whenever a packet
is lost, the receiver can identify which kind of frame(s) has been
lost to aid error mitigation.
The format for the value for this parameter is to represent each
substream of the bit stream by a single character indicating its
type, immediately followed by the number of audio channels
resulting if a frame of that substream (plus any other required
substreams) is decoded. Note that even though Low-Frequency
Effects (LFE) channels are often described as "fractional"
channels (e.g., the ".1" in 5.1), for this parameter, an LFE
channel is counted as one (e.g., a 5.1-channel configuration is
indicated as 6). The configuration of the bit stream MUST match
the value of this parameter for the duration of the session.
Allowed values for the substream type are as follows:
i - Independent substream.
d - Dependent substream.
The E-AC-3 specification [ETSI] defines which configurations of bit
streams are legal, which constrains the values the bitStreamConfig
parameter will take. Each program starts with, and contains exactly
one, independent substream (’i’). Each independent substream is
followed by between 0 and 8 dependent substreams (’d’), which belong
to the same program. See Section 2.1.2 for more discussion of
programs and substreams.
For example, consider a bit stream containing two programs:
* the first program with
+ a six-channel independent substream
+ a dependent substream containing the additional channels needed
for eight channels
+ a second dependent substream containing the further channels
needed for 14 channels
* along with a second program with
+ another six-channel independent substream
+ a dependent substream containing the additional channels needed
for eight channels
Then the configuration of the bit stream is indicated as follows:
bitStreamConfig = i6d8d14i6d8
When the bitStreamConfig parameter is being used in an offer/answer
exchange, zero (0) for the number of channels for a substream in an
answer is used to indicate a substream that the answerer desires not
to receive.
Encoding considerations:
This media type is framed and contains binary data.
Security considerations:
See Section 6 of RFC 4598.
Interoperability considerations:
To maintain interoperability with AC-3-capable end-points, in cases
where negotiation is possible, an E-AC-3 end-point SHOULD declare
itself also as AC-3 capable (i.e., supporting also "audio/ac3" as
specified in RFC 4184 [RFC4184]). Note that all E-AC-3 end-points
are required to be AC-3 capable.
Published specification:
RFC 4598 and ETSI TS 102.366 [ETSI].
Applications that use this media type:
Multichannel audio compression of audio, and audio for video.
Additional information:
Magic number(s): The first two octets of an E-AC-3 frame are
always the synchronization word, which has the hex value
0x0B77.
Person & email address to contact for further information:
Brian Link <bdl@dolby.com> IETF AVT working group.
Intended usage:
COMMON
Restrictions on usage:
This media type depends on RTP framing, and hence is only defined
for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time.
Author/Change controller:
IETF Audio/Video Transport Working Group delegated from the IESG.
5.2. SDP Usage
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[RFC2327], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing E-AC-3, the mapping is as
follows:
o The Media type ("audio") goes in SDP "m=" as the media name.
o The Media subtype ("eac3") goes in SDP "a=rtpmap" as the encoding
name.
o The required parameter "rate" also goes in "a=rtpmap" as the clock
rate. (The optional "channels" rtpmap encoding parameter is not
used. Instead, the information is included in the optional
parameter bitStreamConfig.)
o The optional parameter "bitStreamConfig" goes in the SDP "a=fmtp"
attribute.
The following is an example of the SDP data for E-AC-3:
m=audio 49111 RTP/AVP 100
a=rtpmap:100 eac3/48000
a=fmtp:100 bitStreamConfig i6d8d14i6d8
Certain considerations are needed when SDP is used to perform
offer/answer exchanges [RFC3264].
o The "rate" is a symmetric parameter, and the answer MUST use the
same value or the answerer removes the payload type.
o The "bitStreamConfig" parameter is declarative and indicates, for
sendonly, the intended arrangement of substreams in the bit
stream, along with the channel configuration, to transmit, and for
recvonly or sendrecv, the desired bit stream arrangement and
channel configuration to receive. The format of the
bitStreamConfig value in an answer MAY differ from the offer value
by replacing the number of channels for any undesired substreams
with ’0’. It is valid to zero out dependent substreams containing
undesired channel configurations and to zero out all the
substreams of an undesired program. Then the sender MAY reoffer
the stream in the receiver’s preferred configuration if it is
capable of providing that configuration. Note that all receivers
are capable of receiving, and all decoders are capable of
decoding, any of the legal bit stream configurations, so the
parameter exchange is not needed for interoperability. The
parameter exchange might be used to help optimize the transmission
to the number of programs or channels the receiver requests.
o Since an AC-3 bit stream is a special case of an E-AC-3 bit
stream, it is permissible for an AC-3 bit stream to be carried in
the E-AC-3 payload format. To ensure interoperability with
receivers that support the AC-3 payload format but not the E-AC-3
payload format, a sender that desires to send an AC-3 bit stream
in the E-AC-3 payload format SHOULD also offer the session in the
AC-3 payload format by including payload types for both media
subtypes: ’ac3’ and ’eac3’.
6. Security Considerations
The payload format described in this document is subject to the
security considerations defined in RTP [RFC3550] and in any
applicable RTP profile (e.g., [RFC3551]). To protect the user’s
privacy and any copyrighted material, confidentiality protection
would have to be applied. To also protect against modification by
intermediate entities and ensure the authenticity of the stream,
integrity protection and authentication would be required.
Confidentiality, integrity protection, and authentication have to be
solved by a mechanism external to this payload format, for example,
Secure Real-time Transport Protocol (SRTP) [RFC3711].
The E-AC-3 format is designed so that the validity of data frames can
be determined by decoders. The required decoder response to a
malformed frame is to discard the malformed data and conceal the
errors in the audio output until a valid frame is detected and
decoded. This is expected to prevent crashes and other abnormal
decoder behavior in response to errors or attacks.
7. Congestion Control
The general congestion control considerations for transporting RTP
data apply to E-AC-3 audio over RTP as well; see RTP [RFC3550], and
any applicable RTP profile (e.g., [RFC3551]).
E-AC-3 is a variable bit rate coding system so it is possible to use
a variety of techniques to adapt to network bandwidth.
8. IANA Considerations
The IANA has registered a new media subtype for E-AC-3 (see Section
5).
9. References
9.1. Normative References
[ETSI] ETSI, "Digital Audio Compression (AC-3, Enhanced AC-3)
Standard", TS 102 366, February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for
AC-3 Audio", RFC 4184, October 2005.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
9.2. Informative References
[2004AES] Fielder, L., Andersen, R., Crockett, B., Davidson, G.,
Davis, M., Turner, S., Vinton, M., and P. Williams,
"Introduction to Dolby Digital Plus, an Enhancement to the
Dolby Digital Coding System", Preprint 6196, Presented at
the 117th Convention of the Audio Engineering Society,
October 2004.
[1994AES] Todd, C., Davidson, G., Davis, M., Fielder, L., Link, B.,
and S. Vernon, "AC-3: Flexible Perceptual Coding for Audio
Transmission and Storage", Preprint 3796, Presented at the
96th Convention of the Audio Engineering Society, May
1994.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December
1999.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Author’s Address
Brian Link
Dolby Laboratories
100 Potrero Ave.
San Francisco, CA 94103
US
Phone: +1 415 558 0200
EMail: bdl@dolby.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).