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]