Network Working Group                                        T. Schierl
Internet-Draft                                           Fraunhofer HHI
Intended status: Standards Track                              S. Wenger
Expires: April 20, 2009                                           Nokia
                                                       October 21, 2008



  Signaling media decoding dependency in Session Description Protocol
                                 (SDP)
                draft-ietf-mmusic-decoding-dependency-04


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 BCP 79.

   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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 20, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

This memo defines semantics that allow for signaling the decoding
dependency of different media descriptions with the same media type in
the Session Description Protocol (SDP).  This is required, for example,
if media data is separated and transported in different network streams


Schierl & Wenger          Expires April 20, 2009               [Page 1]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


as a result of the use of a layered or multiple descriptive media coding
process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in
the Session Description Protocol".  In addition, an attribute is
specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and media format
description(s).









































Schierl & Wenger          Expires April 20, 2009               [Page 2]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008



Table of Contents

   1.  Introduction .................................................. 4
   2.  Terminology ................................................... 5
   3.  Definitions ................................................... 5
   4.  Motivation, Use Cases, and Architecture ....................... 6
   4.1.  Motivation .................................................. 6
   4.2.  Use cases ................................................... 8
   5.  Signaling Media Dependencies .................................. 8
   5.1.  Design Principles ........................................... 8
   5.2.  Semantics ................................................... 9
   5.2.1.  SDP grouping semantics for decoding dependency ............ 9
   5.2.2.  "depend" attribute for dependency signaling per media-stream
   ................................................................... 9
   6.  Usage of new semantics in SDP ................................ 11
   6.1.  Usage with the SDP Offer/Answer Model ...................... 11
   6.2.  Declarative usage .......................................... 11
   6.3.  Usage with Capability Negotiation .......................... 11
   6.4.  Examples ................................................... 12
   7.  Security Considerations ...................................... 14
   8.  IANA Considerations .......................................... 14
   9.  Informative note on RFC 3388bis .............................. 15
   10. References ................................................... 15
   10.1. Normative References ....................................... 15
   10.2. Informative References ..................................... 16
   Appendix A.  Acknowledgements..................................... 16
   Authors' Addresses................................................ 17
   Full Copyright Statement.......................................... 18
   Intellectual Property Statement................................... 18























Schierl & Wenger          Expires April 20, 2009               [Page 3]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008



1.   Introduction

   An SDP session description may contain one or more media
   descriptions, each identifying a single media stream.  A media
   description is identified by one "m=" line.  Today, if more than one
   "m=" lines exist indicating the same media type, a receiver cannot
   identify a specific relationship between those media.

   A Multiple Description Coding (MDC) or layered Media Bitstream
   contains, by definition, one or more Media Partitions that are
   conveyed in their own media stream.  The cases we are interested in
   are layered and MDC Bitstreams with two or more Media Partitions.
   Carrying more than one Media Partition in its own session is one of
   the key use cases for employing layered or MDC coded media.  Senders,
   network elements, or receivers can suppress
   sending/forwarding/subscribing/decoding individual Media Partitions
   and still preserve perhaps suboptimal, but still useful media
   quality.

   One property of all Media Bitstreams relevant to this memo is that
   their Media Partitions have a well-defined usage relationship.  For
   example, in layered coding, "higher" Media Partitions are useless
   without "lower" ones.  In MDC coding, Media Partitions are
   complementary -- the more Media Partitions one receives, the better a
   reproduced quality may be.  This document defines an SDP extension to
   indicate such a decoding dependency.

   Trigger for the present memo has been the standardization process of
   the RTP payload format for the Scalable Video Coding extension to
   ITU-T Rec. H.264 / MPEG-4 AVC [I-D.ietf-avt-rtp-svc].  When drafting
   [I-D.ietf-avt-rtp-svc], it was observed that the aforementioned lack
   in signaling support is one that is not specific to SVC, but applies
   to all layered or MDC codecs.  Therefore, this memo presents a
   generic solution.  Likely, the second technology utilizing the
   mechanisms of this memo will be Multi-View video coding.  In Multi
   View Coding (MVC) [I-D.wang-avt-rtp-mvc] layered dependencies between
   views are used to increase the coding efficiency, and, therefore, the
   properties of MVC with respect to the SDP signaling are comparable to
   those of SVC.

   The mechanisms defined herein are media transport protocol dependent,
   and applicable only in conjunction with the use of RTP [RFC3550].

   The SDP grouping of Media Lines of different media types is out of
   scope of this memo.



Schierl & Wenger          Expires April 20, 2009               [Page 4]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008



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 BCP 14, RFC 2119
   [RFC2119].

3.   Definitions

   Media stream:
   As per [RFC4566].

   Media Bitstream:
   A valid, decodable stream, containing all media partitions generated
   by the encoder.  A Media Bitstream normally conforms to a media
   coding standard.

   Media Partition:
   A subset of a Media Bitstream intended for independent
   transportation.  An integer number of Media Partitions forms a Media
   Bitstream.  In layered coding, a Media Partition represents one or
   more layers that are handled as a unit.  In MDC coding, a Media
   Partition represents one or more descriptions that are handled as a
   unit.

   Decoding dependency:
   The class of relationships media partitions have to each other.  At
   present, this memo defines two decoding dependencies: layered coding
   and multiple description coding.

   Layered coding dependency:
   Each Media Partition is only useful (i.e. can be decoded) when all of
   the Media Partitions it depends on are available.  The dependencies
   between the Media Partitions therefore create a directed graph.
   Note: normally, in layered coding, the more Media Partitions are
   employed (following the rule above), the better a reproduced quality
   is possible.

   Multi description coding (MDC) dependency:
   N of M Media Partitions are required to form a Media Bitstream, but
   there is no hierarchy between these Media Partitions.  Most MDC
   schemes aim at an increase of reproduced media quality when more
   media partitions are decoded.  Some MDC schemes require more than one
   Media Partition to form an Operation Point.




Schierl & Wenger          Expires April 20, 2009               [Page 5]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


   Operation Point:
   In layered coding, a subset of a layered Media Bitstream that
   includes all Media Partitions required for reconstruction at a
   certain point of quality, error resilience, or another property, and
   does not include any other Media Partitions.  In MDC coding, a subset
   of an MDC Media Bitstream that is compliant with the MDC coding
   standard in question.

4.   Motivation, Use Cases, and Architecture

4.1. Motivation

   This memo is concerned with two types of decoding dependencies:
   layered and multi-description.  The transport of layered and multi
   description coding share as key motivators the desire for media
   adaptation to network conditions, i.e., related to bandwidth, error
   rates, connectivity of endpoints in multicast or broadcast scenarios,
   and similar.

   o Layered decoding dependency:

     In layered coding, the partitions of a Media Bitstream are known as
     media layers or simply layers.  One or more layers may be
     transported in different media streams in the sense of [RFC4566].
     A classic use case is known as receiver-driven layered multicast,
     in which a receiver selects a combination of media streams in
     response to quality or bit-rate requirements.

     Back in the mid 1990s, the then available layered media formats and
     codecs envisioned primarily (or even exclusively) a one-dimensional
     hierarchy of layers.  That is, each so-called enhancement layer
     referred to exactly one layer "below".  The single exception has
     been the base layer, which is self-contained.  Therefore, the
     identification of one enhancement layer fully specifies the
     Operation Point of a layered coding scheme, including knowledge
     about all the other layers that need to be decoded.

     SDP [RFC4566] contains rudimentary support for exactly this use
     case and media formats, in that it allows for signaling a range of
     transport addresses in a certain media description.  By definition,
     a higher transport address identifies a higher layer in the one-
     dimensional hierarchy.  A receiver needs only to decode data
     conveyed over this transport address and lower transport addresses
     to decode this Operation Point.





Schierl & Wenger          Expires April 20, 2009               [Page 6]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


     Newer media formats depart from this simple one-dimensional
     hierarchy, in that highly complex (at least tree-shaped) dependency
     hierarchies can be implemented.  Compelling use cases for these
     complex hierarchies have been identified by industry.  Support for
     it is therefore desirable.  However, SDP, in its current form, does
     not allow for the signaling of these complex relationships.
     Therefore, receivers cannot make an informed decision on which
     layers to subscribe (in case of layered multicast).

     Layered decoding dependencies may also exist in a Multi View Coding
     environment.  Views may be coded using inter-view dependencies to
     increase coding efficiency.  This results in Media Bitstreams,
     which logically may be separated into Media Partitions representing
     different views of the reconstructed video signal.  These Media
     Partitions cannot be decoded independently, and, therefore, other
     Media Partitions are required for reconstruction.  To express this
     relationship, the signaling needs to express the dependencies of
     the views which in turn are Media Partitions in the sense of this
     document.

   o Multi descriptive decoding dependency:

     In the most basic form of MDC, each Media Partition forms an
     independent representation of the media.  That is, decoding of any
     of the Media Partitions yields useful reproduced media data.  When
     more than one Media Partition is available, then a decoder can
     process them jointly, and the resulting media quality increases.
     The highest reproduced quality is available if all original Media
     Partitions are available for decoding.

     More complex forms of multiple description coding can also be
     envisioned, i.e. where, as a minimum, N out of M total Media
     Partitions need to be available to allow meaningful decoding.

     MDC has not yet been embraced heavily by the media standardization
     community, though it is subject of a lot of academic research.  As
     an example, we refer to [MDC].

     In this memo, we cover MDC because we a) envision that MDC media
     formats will come into practical use within the lifetime of this
     memo, and b) the solution for its signaling is very similar to the
     one of layered coding.

   o Other decoding dependency relationships:





Schierl & Wenger          Expires April 20, 2009               [Page 7]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


     At the time of writing, no decoding dependency relationships beyond
     the two mentioned above have been identified that would warrant
     standardization.  However, the mechanisms of this memo could be
     extended by introducing new codepoints for new decoding dependency
     types.  If such an extension becomes necessary, as formally
     required in section 5.2.2, the new decoding dependency type MUST be
     documented in an IETF standard's track document.

4.2. Use cases

   o Receiver driven layered multicast:

     This technology is discussed in [RFC3550] and references therein.
     We refrain from elaborating further; the subject is well known and
     understood.

   o Multiple end-to-end transmission with different properties:

     Assume a unicast and point-to-point topology, wherein one endpoint
     sends media to another.  Assume further that different forms of
     media transmission are available.  The difference may lie in the
     cost of the transmission (free, charged), in the available
     protection (unprotected/secure), in the quality of service
     (guaranteed quality / best effort), or other factors.

     Layered and MDC coding allow to match the media characteristics to
     the available transmission path(s).  For example, in layered
     coding, it makes sense to convey the base layer over high QoS.
     Enhancement layers, on the other hand, can be conveyed over best
     effort, as they are "optional" in their characteristic -- nice to
     have, but non-essential for media consumption.  In a different
     scenario, the base layer may be offered in a non-encrypted session
     as a free preview.  An encrypted enhancement layer references this
     base layer and allows optimal quality play-back; however, it is
     only accessible to users who have the key, which may have been
     distributed by a conditional access mechanism.

5.   Signaling Media Dependencies

5.1. Design Principles

   The dependency signaling is only feasible between media descriptions
   described with an "m="-line and with an assigned media identification
   attribute ("mid"), as defined in [RFC3388].  All media descriptions
   grouped according to this specification MUST have the same media
   type.  Other dependencies relations expressed by SDP grouping have to



Schierl & Wenger          Expires April 20, 2009               [Page 8]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


   be addressed in other specifications.  A media description MUST NOT
   be part of more than one group of the grouping type defined in this
   specification.

5.2. Semantics

5.2.1.    SDP grouping semantics for decoding dependency

   This specification defines a new grouping semantic
   Decoding Dependency "DDP":

   DDP associates a media stream, identified by its mid attribute, with
   a DDP group.  Each media stream MUST be composed of an integer number
   of Media Partitions.  A media stream is identified by a session-
   unique media format description (RTP payload type number) within a
   media description. In a DDP group, all media streams MUST have the
   same type of decoding dependency (as signaled by the attribute
   defined in 5.2.2).  All media streams MUST contain at least one
   Operation Point.  The DDP group type informs a receiver about the
   requirement for handling the media streams of the group according to
   the new media level attribute "depend", as defined in 5.2.2. .

   When using multiple codecs, e.g. for Offer/Answer model, the media
  streams MUST have the same dependency structure, regardless which
  media format description (RTP payload type number) is used.

5.2.2.    "depend" attribute for dependency signaling per media-stream

   This memo defines a new media-level attribute, "depend", with the
   following ABNF [RFC5234].  The identification-tag is defined in
   [RFC3388].  In the following ABNF, fmt, token, SP, and CRLF are used
   as defined in [RFC4566].

     depend-attribute =
             "a=depend:" dependent-fmt SP dependency-tag
                *(";" SP dependent-fmt SP dependency-tag) CRLF

     dependency-tag   =
             dependency-type *1( SP identification-tag ":"
             fmt-dependency *("," fmt-dependency ))

     dependency-type  = "lay"
                      / "mdc"
                      / token

     dependent-fmt = fmt



Schierl & Wenger          Expires April 20, 2009               [Page 9]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008



     fmt-dependency = fmt

   dependency-tag, indicates one or more dependencies of one dependent-
   fmt in the media description.  These dependencies are signaled as
   fmt-dependency values, which indicate fmt values of other media
   descriptions.  These other media descriptions are identified by their
   identification-tag values in the depend-attribute.  There MUST be
   exactly one dependency-tag indicated per dependent-fmt.

   dependent-fmt, indicates the media format description, as defined in
   [RFC4566], that depends on one or more media format description in
   the media description indicated by the value of identification-tag
   within the dependency-tag.

   fmt-dependency, indicates the media format description in the media
   description identified by the identification-tag within the
   dependency-tag, which the dependent-fmt of the dependent media
   description depends on.  In case a list of fmt-dependency values is
   given, any element of the list is sufficient to satisfy the
   dependency, at the choice of the decoding entity.

   The depend-attribute describes the decoding dependency.  The depend-
   attribute MUST be followed by a sequence of dependent-fmt and the
   corresponding dependency-tag fields which identify all related media
   format descriptions in all related media descriptions of the
   dependent-fmt.  The attribute MAY be used with multicast as well as
   with unicast transport addresses.  The following dependency-types
   values are defined in this memo:

  o lay:  Layered decoding dependency -- identifies the described media
     stream as one or more Media Partitions of a layered Media
     Bitstream.  When "lay" is used, all media streams required for
     decoding the Operation Point MUST be identified by identification-
     tag and fmt-dependency following the "lay" string.

  o mdc:  Multi descriptive decoding dependency -- signals that the
     described media stream is part of a set of a MDC Media Bitstream.
     By definition, at least N out of M media streams of the group need
     to be available to from an Operation Point.  The values of N and M
     depend on the properties of the Media Bitstream and are not
     signaled within this context.  When "mdc" is used, all required
     media streams for the Operation Point MUST be identified by
     identification-tag and fmt-dependency following the "mdc" string.





Schierl & Wenger          Expires April 20, 2009               [Page 10]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


   Further dependency types MUST be defined in a standards-track
   document.

6.   Usage of new semantics in SDP

6.1. Usage with the SDP Offer/Answer Model

   The backward compatibility in offer / answer is generally handled as
   specified in [RFC3388], section 8.4, as summarized below.

   Depending on the implementation, a node that does not understand DDP
   grouping (either does not understand line grouping at all, or just
   does not understand the DDP semantics) SHOULD respond to an offer
   containing DDP grouping either (1) with an answer that ignores the
   grouping attribute or (2) with a refusal to the request (e.g., 488
   Not acceptable here or 606 Not acceptable in SIP).

   In the first case, if the original sender of the offer still wishes
   to establish communications, it SHOULD generate a new offer with a
   single media stream that represents an Operation Point.  Note: in
   most cases, this will be the base layer of a layered Media Bitstream,
   equally possible are Operation Points containing a set of enhancement
   layers as long as all are part of a single media stream.  In the
   second case, if the sender of the offer still wishes to establish the
   session, it SHOULD re-try the request with an offer including only a
   single media stream.

6.2. Declarative usage

   If an RTSP receiver understands signaling according to this memo, it
   SHALL setup all media streams that are required to decode the
   Operation Point of its choice.

   If an RTSP receiver does not understand the signaling defined within
   this memo, it falls back to normal SDP processing.  Two likely cases
   have to be distinguished: (1) if at least one of the media types
   included in the SDP is within the receiver's capabilities, it selects
   among those candidates according to implementation specific criteria
   for setup, as usual. (2) If none of the media type included in the
   SDP can be processed, then obviously no setup can occur.

6.3.  Usage with Capability Negotiation

   This memo does not cover the interaction with Capability Negotiation
   [I-D.ietf-mmusic-sdp-capability-negotiation].  This issue is for
   further study and will be addressed in a different memo.



Schierl & Wenger          Expires April 20, 2009               [Page 11]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008



6.4. Examples

   a.)  Example for signaling layered decoding dependency:

        The example below shows a session description with three media
        descriptions, all of type video and with layered decoding
        dependency ("lay").  Each of the media description includes two
        possible media format descriptions with different encoding
        parameters as, e.g. "packetization-mode" (not shown in the
        example) for the media subtypes "H264" and "H264-SVC" given by
        the "a=rtpmap:"-line.  The first media description includes two
        H264 payload types as media format descriptions, "96" and "97",
        as defined in [RFC3984] and represents the base layer operation
        point (identified by "mid:L1").  The two other media
        descriptions (identified by "mid:L2" and "mid:L3") include H264-
        SVC payload types as defined in [I-D.ietf-avt-rtp-svc], which
        contain enhancements to the base layer operation point or the
        first enhancement layer operation point (media description
        identified by "mid:L2").  The example shows the dependencies of
        the media format descriptions of the different media
        descriptions indicated by "DDP" grouping, "mid" and "depend"
        attributes.  The "depend" attribute is used with the decoding
        dependency type "lay" indicating layered decoding dependency.
        For example, the third media description ("m=video 40004...")
        indentified by "mid:L3" has different dependencies on the media
        format descriptions of the two other media descriptions:
        Media format description "100" depends on media format
        description "96" or "97" of the media description indentified by
        "mid:L1".  This is an exclusive-OR, i.e. payload type "100" may
        be used with payload type "96" or with "97", but one of the two
        combinations is required for decoding payload type "100".
        For media format description "101", it is different.  This one
        depends on two of the other media descriptions at the same time,
        i.e. it depends on media format description "97" of the media
        description indentified by "mid:L1" and it also depends on media
        format description "99" of the media description indentified by
        "mid:L2".  For decoding media format description "101" both
        media format description "97" and media format description "99"
        are required by definition.

          v=0
          o=svcsrv 289083124 289083124 IN IP4 host.example.com
          s=LAYERED VIDEO SIGNALING Seminar
          t=0 0
          c=IN IP4 192.0.2.1/127



Schierl & Wenger          Expires April 20, 2009               [Page 12]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


          a=group:DDP L1 L2 L3
          m=video 40000 RTP/AVP 96 97
          b=AS:90
          a=framerate:15
          a=rtpmap:96 H264/90000
          a=rtpmap:97 H264/90000
          a=mid:L1
          m=video 40002 RTP/AVP 98 99
          b=AS:64
          a=framerate:15
          a=rtpmap:98 H264-SVC/90000
          a=rtpmap:99 H264-SVC/90000
          a=mid:L2
          a=depend:98 lay L1:96,97; 99 lay L1:97
          m=video 40004 RTP/AVP 100 101
          b=AS:128
          a=framerate:30
          a=rtpmap:100 H264-SVC/90000
          a=rtpmap:101 H264-SVC/90000
          a=mid:L3
          a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99


   b.)  Example for signaling of multi descriptive decoding dependency:

        The example shows a session description with three media
        descriptions, all of type video and with multi descriptive
        decoding dependency.  Each of the media descriptions includes
        one media format description.  The example shows the
        dependencies of the media format descriptions of the different
        media descriptions indicated by "DDP" grouping, "mid" and
        "depend" attributes.  The "depend" attribute is used with the
        decoding dependency type "mdc" indicating layered decoding
        dependency.  For example, media format description "104" in the
        media description ("m=video 40000...") with "mid:M1" depends on
        the two other media descriptions.  It depends on media format
        description "105" of media description with "mid:M2" and also
        depends on media format description "106" of media description
        with "mid:M3".  In case of the multi descriptive decoding
        dependency, media format description "105" and "106" can be used
        by definition to enhance the decoding process of media format
        description "104", but they are not required for decoding.

          v=0
          o=mdcsrv 289083124 289083124 IN IP4 host.example.com
          s=MULTI DESCRIPTION VIDEO SIGNALING Seminar



Schierl & Wenger          Expires April 20, 2009               [Page 13]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


          t=0 0
          c=IN IP4 192.0.2.1/127
          a=group:DDP M1 M2 M3
          m=video 40000 RTP/AVP 104
          a=mid:M1
          a=depend:104 mdc M2:105 M3:106
          m=video 40002 RTP/AVP 105
          a=mid:M2
          a=depend:105 mdc M1:104 M3:106
          m=video 40004 RTP/AVP 106
          a=mid:M3
          a=depend:106 mdc M1:104 M2:105

7.   Security Considerations

   All security implications of SDP apply.

   There may be a risk of manipulation the dependency signaling of a
   session description by an attacker.  This may mislead a receiver or
   middle box, e.g. a receiver may try to compose a media bitstream out
   of several RTP packet streams that does not form an Operation Point,
   although the signaling made it believe it would form a valid
   Operation Point, with potential fatal consequences for the media
   decoding process.  It is recommended that the receiver SHOULD perform
   an integrity check on SDP and follow the security considerations of
   SDP to only trust SDP from trusted sources.

8.   IANA Considerations

   The following contact information shall be used for all registrations
   included here:

   Contact:      Thomas Schierl
                 mailto:mail@thomas-schierl.de
                 tel:+49-30-31002-227


   The following semantics have been registered by IANA in Semantics for
   the "group" SDP Attribute under SDP Parameters
   http://www.iana.org/assignments/sdp-parameters.

   Semantics              Token     Reference
   -------------------    -----     ---------
   Decoding Dependency    DDP       RFC XXXX





Schierl & Wenger          Expires April 20, 2009               [Page 14]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


   The SDP media level attribute "depend" has been registered by IANA in
   Semantics for "att-field (media level only)".

   SDP Attribute ("att-field (media level only)"):

   Attribute name:     depend
   Long form:          decoding dependency
   Type of name:       att-field
   Type of attribute:  media level only
   Subject to charset: no
   Purpose:            RFC XXXX
   Reference:          RFC XXXX
   Values:             see this document and registrations below.


   The following semantics have been registered by IANA in Semantics for
   the "depend" SDP Attribute under SDP Parameters:

   Semantics of the "depend" SDP attribute:

   Semantics                                Token     Reference
   ----------------------------             -----     ---------
   Layered decoding dependency              lay       RFC XXXX
   Multi descriptive decoding dependency    mdc       RFC XXXX


9.   Informative note on RFC 3388bis

   Currently, there is ongoing work on [I-D.ietf-mmusic-rfc3388bis].  In
   [I-D.ietf-mmusic-rfc3388bis], the grouping mechanism is extended in a
   way that a media description can be part of more than one group of
   the same grouping type in the same session description.  However,
   media descriptions grouped by this draft must be at most part of one
   group of the type "DDP" in the same session description.

10.  References

10.1.     Normative References

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3388]    Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of
             Media Lines in the Session Description Protocol (SDP)",
             RFC 3388, December 2002.





Schierl & Wenger          Expires April 20, 2009               [Page 15]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


[RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.
[RFC4566]    Handley, M., Jacobson, V, and C. Perkins, "SDP: Session
             Description Protocol", RFC 4566, July 2006.
[RFC5234]    Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 5234, January 2008.

10.2.     Informative References

[I-D.ietf-avt-rtp-svc]
             Wenger, S., Wang Y.-K., T. Schierl and A. Eleftheriadis,
             "RTP Payload Format for SVC Video",
             draft-ietf-avt-rtp-svc-14 (work in progress), September
             2008.
[I-D.ietf-mmusic-rfc3388bis]
             Camarillo, G "The SDP (Session Description Protocol)
             Grouping Framework",
             draft-ietf-mmusic-rfc3388bis-01 (work in progress), July
             2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
             Andreasen, F., "SDP Capability Negotiation",
             draft-ietf-mmusic-sdp-capability-negotiation-09, (work in
             progress), July 2008.
[I-D.wang-avt-rtp-mvc]
             Wang, Y.-K. and T. Schierl, "RTP Payload Format
             for MVC Video", draft-wang-avt-rtp-mvc-02 (work in
             progress), August 2008.
[MDC]        Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo,
             "Video over IP using Standard-Compatible Multiple
             Description Coding: an IETF proposal", Packet Video
             Workshop, April 2006, Hangzhou, China.
[RFC3984]    Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M.,
             and Singer, D., "RTP Payload Format for H.264 Video", RFC
             3984, February 2005.


Appendix A.  Acknowledgements

   Funding for the RFC Editor function is currently provided by the
   Internet Society.  Further, the author Thomas Schierl of Fraunhofer
   HHI is sponsored by the European Commission under the contract number
   FP7-ICT-214063, project SEA.
   We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan
   Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and
   constructive comments to this memo.



Schierl & Wenger          Expires April 20, 2009               [Page 16]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008




Authors' Addresses

   Thomas Schierl
   Fraunhofer HHI
   Einsteinufer 37
   D-10587 Berlin
   Germany

   Phone: +49-30-31002-227
   Email: mail@thomas-schierl.de

   Stephan Wenger
   Nokia
   955 Page Mill Road
   Palo Alto, CA, 94304
   USA

   Phone: +1-650-862-7368
   Email: stewe@stewe.org




























Schierl & Wenger          Expires April 20, 2009               [Page 17]


Internet-Draft   draft-ietf-mmusic-decoding-dependency-04   October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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 Statement

   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.










Schierl & Wenger          Expires April 20, 2009               [Page 18]