Internet DRAFT - draft-feiten-avt-bsacmode-for-rfc3640
draft-feiten-avt-bsacmode-for-rfc3640
IETF AVT WG B. Feiten
Internet-Draft I. Wolf
Expires: August 11, 2005 T-Systems
International
T. Guenkova-Luy
A. Schorr
University of Ulm
A. Kassler
Karlstad University
February 11, 2005
New mode for rfc3640: AAC-BSAC with MPEG-21 gBSD
draft-feiten-avt-bsacmode-for-rfc3640-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of 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 draft proposes a mode for RFC 3640 to support an MPEG-4 AAC-BSAC
audio codec format with an optional attached bitstream description.
The bitstream description employs the MPEG-21 generalized Bitstream
Syntax Description Language (gBSDL). The description is attached as
auxiliary header and can be used to support adaptation.
Feiten, et al. Expires August 11, 2005 [Page 1]
Internet-Draft New BSAC mode for rfc3640 March 2005
Table of Contents
1. Definitions 2
1.1. Glossary 2
1.2. Terminology 2
2. Introduction 2
3. Mode Scalable Bitrate BSAC 3
4. Example for gBSD-BSAC RTP packet 5
5. IANA Considerations 5
5.1. MIME Type Registration 5
5.2. Registration of Mode Definitions 5
6. Security Considerations 6
References 6
Authors' Addresses 6
Acknowledgements 7
Copyright Notice 7
Liability notice 7
1. Definitions
1.1. Glossary
AAC - Advanced audio coding
AU - MPEG-4 Systems Access Unit
BSAC - Bit sliced arithmetic coding
gBSD - generalized Bitstream Description Language
MPEG - ISO Sc29Wg11 Moving Pcitures Expert Group
MPEG-21 DIA - MPEG-21 Part 7 - Digital Item Adaptation
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
2. Introduction
This draft proposes a new mode for RFC 3640 [1] to support the MPEG-4
AAC-BSAC audio codec. In addition, the new mode shall allow attaching
a bitstream description to support the scaling of the bitrate. The
bitstream description employs the MPEG-21 generalized Bitstream Syntax
Description Language (gBSDL). The MPEG-21 digital item adaptation
framework can be used for content agnostic adaptation of the bitrate.
A bitstream description with a related transformation style sheet is
used by an adaptation processor, e.g. a content adaptation node
located in the network, to adapt the bitstream. The adaptation can
take constraints like network characteristics and terminal
capabilities under consideration. The adaptation framework is fully
described in the MPEG-21 Part-7 Digital Item Adaptation [2].
Feiten, et al. Expires August 11, 2005 [Page 2]
Internet-Draft New BSAC mode for rfc3640 March 2005
RFC 3640 so far defines five modes:
Generic generic
Constant Bitrate Celp CELP-cbr
Variable Bitrate Celp CELP-vbr
Low Bitrate AAC AAC-lbr
High Bitrate AAC AAC-hbr
Additional modes are expected to be defined in future RFCs. Each
additional mode MUST be in full compliance with RFC 3640.
Any new mode for RFC 3640 MUST be defined such that an implementation
including all the features described in RFC 3640 can decode the
payload format corresponding to this new mode. For this reason, a mode
MUST NOT specify new default values for MIME parameters. In
particular, MIME parameters that configure the RTP payload MUST be
present (unless they have the default value), even if its presence is
redundant in case the mode assigns a fixed value to a parameter. A
mode may additionally define that:
o Some MIME parameters are required instead of optional,
o Some MIME parameters have fixed values (or ranges), and
o There are rules restricting the mode's usage.
3. Mode Scalable Bitrate BSAC
This draft proposes a new mode "Scalable Bitrate BSAC" named "BSAC-
gbsd". The mode is signalled with the SDP [3] fmtp parameter
mode=BSAC-gbsd [4]. The mode supports the transportation of variable
size BSAC frames. In one RTP packet, either one or more complete BSAC
frames are carried, or a fragment of a single BSAC frame is carried.
The BSAC frames are allowed to be interleaved and hence receivers MUST
support de-interleaving. The maximum size of a BSAC frame in this
mode is 2048 octets.
This mode makes use of the AU Header Section and the Auxiliary Section
followed by either one BSAC frame, several concatenated BSAC frames,
or a fragment of a single BSAC frame.
For reasons of efficiency the AU Header Section is only used if
several BSAC frames are packet together. In that case for each BSAC
frame contained in the payload, there MUST be an AU-header in the AU
Header Section to provide:
a) the size of each BSAC frame in the payload and
b) index information for computing the sequence (and hence timing)
Feiten, et al. Expires August 11, 2005 [Page 3]
Internet-Draft New BSAC mode for rfc3640 March 2005
To code the maximum size of a BSAC frame requires 11 bits.
Therefore, in this configuration 11 bits are allocated to the AU-
size, and 5 bits to the AU-Index(-delta) field. Thus, each AU-header
has a size of 2 octets. Each AU-Index field MUST be coded with the
value 0. In the AU Header Section, the concatenated AU-headers MUST be
preceded by the 16-bit AU-headers-length field, as specified in
section 3.2.1. of RFC 3640.
The Auxiliary Section MAY contain a description of the bitstream. The
description uses the MPEG-21-DIA generalized bitstream description
language (gBSD). The description provides information on the scaling
structure of the AU data section.
The AU Data Section consists of either one BSAC frame, several
concatenated BSAC frames, or a fragment of a single BSAC frame.
In addition to the already required MIME format parameters,
auxiliaryDataSizeLength MUST be present. An auxiliaryDataSizeLength of
2 octets SHALL be used to simplify the decoding. The parameters
sizeLength, indexLength, indexDeltaLength MAY be used to configure the
AU Header Section. If the sizeLength parameter is not present it is
assumed that no AU Header Section is used and a single frame is stored
in the payload.
Furthermore, the BSAC frames have a constant duration that is
signalled as SDP fmtp parameter [3].
For example:
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/2
a=fmtp:96 streamtype=5; profile-level-id=22; mode=BSAC-gbsd;
config=2C90; sizeLength=11; indexLength=5; indexDeltaLength=5;
auxiliaryDataSizeLength=16; constantDuration=1024
Note: The a=fmtp line has been wrapped to fit the page; it comprises a
single line in the SDP file.
The hexadecimal value of the "config" parameter is the
AudioSpecificConfig(), as defined in ISO/IEC 14496-3.
Feiten, et al. Expires August 11, 2005 [Page 4]
Internet-Draft New BSAC mode for rfc3640 March 2005
4. Example for gBSD-BSAC RTP packet
In this example, the RTP packet contains 2 complete BSAC frames.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 |V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | AU-headers-length | AU-header 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | AU-header 2 | auxiliary-data-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | auxiliary-data (gbsD) |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSAC frame 1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest of BSAC frame 1 | BSAC frame 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest of BSAC frame 2 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. IANA Considerations
This section describes the MIME types and names associated with this
new mode for payload format.
5.1. MIME Type Registration
Only a new mode is defined.
5.2. Registration of Mode Definitions
RFC 3640 can be used in a number of modes. The mode of operation is
signaled using the "mode" MIME parameter. New modes may be defined at
any time. These modes MUST be registered with IANA, to ensure that
there is not a clash of names.
The following additional mode MAY be signalled in RFC 3640
mode=BSAC-gbsd.
Person & email address to contact for further information:
Authors of the draft, IETF Audio/Video Transport working group.
Intended usage: COMMON
Feiten, et al. Expires August 11, 2005 [Page 5]
Internet-Draft New BSAC mode for rfc3640 March 2005
6. Security Considerations
RTP packets using mod defined in this specification are subject to the
security considerations discussed in the RFC 3640 [1]. 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 on the compressed data so
there is no conflict between the two operations. Future application
that support that adaptation of encrypted scalable bitstreams require
appropriate encryption systems.
The packet processing complexity of this payload type (i.e., excluding
media data processing) does not exhibit any significant non-uniformity
in the receiver side to cause a denial-of-service threat. However, it
is possible to inject non-compliant MPEG streams (Audio, Video, and
Systems) so that the receiver/decoder's buffers are overloaded, which
might compromise the functionality of the receiver or even crash it.
Authentication mechanisms can be used to validate the sender and the
data to prevent security problems due to non-compliant malignant
MPEG-4 streams.
References
[1] J. van der Meer et al.: RTP Payload Format for Transport of
MPEG-4 Elementary Streams, IETF RFC 3640, November 2003
[2] ISO/IEC 21000-7: Digital Item Adaptation, International
Standard, 2004.
[3] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] Wolf, I. et al.: MPEG-21 DIA based delivery using SDPng and
RTP. ISO/IEC JTC1/SC29/WG11/ MPEG2004/M10996, July 2004.
Authors' Addresses
Bernhard Feiten
T-Systems International GmbH
Goslarer Ufer 35, 10589 Berlin, Germany
Tel: +49 (0)30 3497 2528
Fax: +49 (0)30 3497 2929
e-Mail: Bernhard.Feiten@t-systems.com
Ingo Wolf
T-Systems International GmbH
Goslarer Ufer 35, 10589 Berlin, Germany
Tel: +49 (0)30 3497 2526
Fax: +49 (0)30 3497 2929
E-mail: wolfi@t-systems.com
Feiten, et al. Expires August 11, 2005 [Page 6]
Internet-Draft New BSAC mode for rfc3640 March 2005
Teodora Guenkova-Luy
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4148
Fax: +49 (0)731 502-4142
e-Mail: guenkova@vs.informatik.uni-ulm.de
Andreas Schorr
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4147
Fax: +49 (0)731 502-4142
e-Mail: schorr@informatik.uni-ulm.de
Andreas Kassler
Computer Science Department, Karlstad University,
Universitetgatan 2, 65188 Karlstad, Sweden
Tel: ++46 (0)54 700-2168
e-Mail: kassler@ieee.org
Acknowledgements
The work described in this draft is based on results of IST FP6
Integrated Project DAIDALOS. DAIDALOS receives research funding from
the European Community's Sixth Framework Programme. Apart from this,
the European Commission has no responsibility for the content of this
draft. The information in this document is provided as is and no
guarantee or warranty is given that the information is fit for any
particular purpose. The user thereof uses the information at its sole
risk and liability.
Copyright Notice
Copyright (C) The Internet Society (2005). 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.
Liability notice
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.
Feiten, et al. Expires August 11, 2005 [Page 7]
IETF AVT WG B. Feiten
Internet-Draft I. Wolf
Expires: August 11, 2005 T-Systems
International
T. Guenkova-Luy
A. Schorr
University of Ulm
A. Kassler
Karlstad University
February 11, 2005
New mode for rfc3640: AAC-BSAC with MPEG-21 gBSD
draft-feiten-avt-bsacmode-for-rfc3640-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of 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 draft proposes a mode for RFC 3640 to support an MPEG-4 AAC-BSAC
audio codec format with an optional attached bitstream description.
The bitstream description employs the MPEG-21 generalized Bitstream
Syntax Description Language (gBSDL). The description is attached as
auxiliary header and can be used to support adaptation.
Feiten, et al. Expires August 11, 2005 [Page 1]
Internet-Draft New BSAC mode for rfc3640 March 2005
Table of Contents
1. Definitions 2
1.1. Glossary 2
1.2. Terminology 2
2. Introduction 2
3. Mode Scalable Bitrate BSAC 3
4. Example for gBSD-BSAC RTP packet 5
5. IANA Considerations 5
5.1. MIME Type Registration 5
5.2. Registration of Mode Definitions 5
6. Security Considerations 6
References 6
Authors' Addresses 6
Acknowledgements 7
Copyright Notice 7
Liability notice 7
1. Definitions
1.1. Glossary
AAC - Advanced audio coding
AU - MPEG-4 Systems Access Unit
BSAC - Bit sliced arithmetic coding
gBSD - generalized Bitstream Description Language
MPEG - ISO Sc29Wg11 Moving Pcitures Expert Group
MPEG-21 DIA - MPEG-21 Part 7 - Digital Item Adaptation
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
2. Introduction
This draft proposes a new mode for RFC 3640 [1] to support the MPEG-4
AAC-BSAC audio codec. In addition, the new mode shall allow attaching
a bitstream description to support the scaling of the bitrate. The
bitstream description employs the MPEG-21 generalized Bitstream Syntax
Description Language (gBSDL). The MPEG-21 digital item adaptation
framework can be used for content agnostic adaptation of the bitrate.
A bitstream description with a related transformation style sheet is
used by an adaptation processor, e.g. a content adaptation node
located in the network, to adapt the bitstream. The adaptation can
take constraints like network characteristics and terminal
capabilities under consideration. The adaptation framework is fully
described in the MPEG-21 Part-7 Digital Item Adaptation [2].
Feiten, et al. Expires August 11, 2005 [Page 2]
Internet-Draft New BSAC mode for rfc3640 March 2005
RFC 3640 so far defines five modes:
Generic generic
Constant Bitrate Celp CELP-cbr
Variable Bitrate Celp CELP-vbr
Low Bitrate AAC AAC-lbr
High Bitrate AAC AAC-hbr
Additional modes are expected to be defined in future RFCs. Each
additional mode MUST be in full compliance with RFC 3640.
Any new mode for RFC 3640 MUST be defined such that an implementation
including all the features described in RFC 3640 can decode the
payload format corresponding to this new mode. For this reason, a mode
MUST NOT specify new default values for MIME parameters. In
particular, MIME parameters that configure the RTP payload MUST be
present (unless they have the default value), even if its presence is
redundant in case the mode assigns a fixed value to a parameter. A
mode may additionally define that:
o Some MIME parameters are required instead of optional,
o Some MIME parameters have fixed values (or ranges), and
o There are rules restricting the mode's usage.
3. Mode Scalable Bitrate BSAC
This draft proposes a new mode "Scalable Bitrate BSAC" named "BSAC-
gbsd". The mode is signalled with the SDP [3] fmtp parameter
mode=BSAC-gbsd [4]. The mode supports the transportation of variable
size BSAC frames. In one RTP packet, either one or more complete BSAC
frames are carried, or a fragment of a single BSAC frame is carried.
The BSAC frames are allowed to be interleaved and hence receivers MUST
support de-interleaving. The maximum size of a BSAC frame in this
mode is 2048 octets.
This mode makes use of the AU Header Section and the Auxiliary Section
followed by either one BSAC frame, several concatenated BSAC frames,
or a fragment of a single BSAC frame.
For reasons of efficiency the AU Header Section is only used if
several BSAC frames are packet together. In that case for each BSAC
frame contained in the payload, there MUST be an AU-header in the AU
Header Section to provide:
a) the size of each BSAC frame in the payload and
b) index information for computing the sequence (and hence timing)
Feiten, et al. Expires August 11, 2005 [Page 3]
Internet-Draft New BSAC mode for rfc3640 March 2005
To code the maximum size of a BSAC frame requires 11 bits.
Therefore, in this configuration 11 bits are allocated to the AU-
size, and 5 bits to the AU-Index(-delta) field. Thus, each AU-header
has a size of 2 octets. Each AU-Index field MUST be coded with the
value 0. In the AU Header Section, the concatenated AU-headers MUST be
preceded by the 16-bit AU-headers-length field, as specified in
section 3.2.1. of RFC 3640.
The Auxiliary Section MAY contain a description of the bitstream. The
description uses the MPEG-21-DIA generalized bitstream description
language (gBSD). The description provides information on the scaling
structure of the AU data section.
The AU Data Section consists of either one BSAC frame, several
concatenated BSAC frames, or a fragment of a single BSAC frame.
In addition to the already required MIME format parameters,
auxiliaryDataSizeLength MUST be present. An auxiliaryDataSizeLength of
2 octets SHALL be used to simplify the decoding. The parameters
sizeLength, indexLength, indexDeltaLength MAY be used to configure the
AU Header Section. If the sizeLength parameter is not present it is
assumed that no AU Header Section is used and a single frame is stored
in the payload.
Furthermore, the BSAC frames have a constant duration that is
signalled as SDP fmtp parameter [3].
For example:
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/2
a=fmtp:96 streamtype=5; profile-level-id=22; mode=BSAC-gbsd;
config=2C90; sizeLength=11; indexLength=5; indexDeltaLength=5;
auxiliaryDataSizeLength=16; constantDuration=1024
Note: The a=fmtp line has been wrapped to fit the page; it comprises a
single line in the SDP file.
The hexadecimal value of the "config" parameter is the
AudioSpecificConfig(), as defined in ISO/IEC 14496-3.
Feiten, et al. Expires August 11, 2005 [Page 4]
Internet-Draft New BSAC mode for rfc3640 March 2005
4. Example for gBSD-BSAC RTP packet
In this example, the RTP packet contains 2 complete BSAC frames.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 |V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | AU-headers-length | AU-header 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | AU-header 2 | auxiliary-data-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | auxiliary-data (gbsD) |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSAC frame 1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest of BSAC frame 1 | BSAC frame 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest of BSAC frame 2 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. IANA Considerations
This section describes the MIME types and names associated with this
new mode for payload format.
5.1. MIME Type Registration
Only a new mode is defined.
5.2. Registration of Mode Definitions
RFC 3640 can be used in a number of modes. The mode of operation is
signaled using the "mode" MIME parameter. New modes may be defined at
any time. These modes MUST be registered with IANA, to ensure that
there is not a clash of names.
The following additional mode MAY be signalled in RFC 3640
mode=BSAC-gbsd.
Person & email address to contact for further information:
Authors of the draft, IETF Audio/Video Transport working group.
Intended usage: COMMON
Feiten, et al. Expires August 11, 2005 [Page 5]
Internet-Draft New BSAC mode for rfc3640 March 2005
6. Security Considerations
RTP packets using mod defined in this specification are subject to the
security considerations discussed in the RFC 3640 [1]. 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 on the compressed data so
there is no conflict between the two operations. Future application
that support that adaptation of encrypted scalable bitstreams require
appropriate encryption systems.
The packet processing complexity of this payload type (i.e., excluding
media data processing) does not exhibit any significant non-uniformity
in the receiver side to cause a denial-of-service threat. However, it
is possible to inject non-compliant MPEG streams (Audio, Video, and
Systems) so that the receiver/decoder's buffers are overloaded, which
might compromise the functionality of the receiver or even crash it.
Authentication mechanisms can be used to validate the sender and the
data to prevent security problems due to non-compliant malignant
MPEG-4 streams.
References
[1] J. van der Meer et al.: RTP Payload Format for Transport of
MPEG-4 Elementary Streams, IETF RFC 3640, November 2003
[2] ISO/IEC 21000-7: Digital Item Adaptation, International
Standard, 2004.
[3] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] Wolf, I. et al.: MPEG-21 DIA based delivery using SDPng and
RTP. ISO/IEC JTC1/SC29/WG11/ MPEG2004/M10996, July 2004.
Authors' Addresses
Bernhard Feiten
T-Systems International GmbH
Goslarer Ufer 35, 10589 Berlin, Germany
Tel: +49 (0)30 3497 2528
Fax: +49 (0)30 3497 2929
e-Mail: Bernhard.Feiten@t-systems.com
Ingo Wolf
T-Systems International GmbH
Goslarer Ufer 35, 10589 Berlin, Germany
Tel: +49 (0)30 3497 2526
Fax: +49 (0)30 3497 2929
E-mail: wolfi@t-systems.com
Feiten, et al. Expires August 11, 2005 [Page 6]
Internet-Draft New BSAC mode for rfc3640 March 2005
Teodora Guenkova-Luy
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4148
Fax: +49 (0)731 502-4142
e-Mail: guenkova@vs.informatik.uni-ulm.de
Andreas Schorr
Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel: +49 (0)731 502-4147
Fax: +49 (0)731 502-4142
e-Mail: schorr@informatik.uni-ulm.de
Andreas Kassler
Computer Science Department, Karlstad University,
Universitetgatan 2, 65188 Karlstad, Sweden
Tel: ++46 (0)54 700-2168
e-Mail: kassler@ieee.org
Acknowledgements
The work described in this draft is based on results of IST FP6
Integrated Project DAIDALOS. DAIDALOS receives research funding from
the European Community's Sixth Framework Programme. Apart from this,
the European Commission has no responsibility for the content of this
draft. The information in this document is provided as is and no
guarantee or warranty is given that the information is fit for any
particular purpose. The user thereof uses the information at its sole
risk and liability.
Copyright Notice
Copyright (C) The Internet Society (2005). 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.
Liability notice
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.
Feiten, et al. Expires August 11, 2005 [Page 7]
