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]