[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

MMUSIC Working Group                                         T. Schierl
Internet Draft                                           Fraunhofer HHI
Intended status: Standards Track                              S. Wenger
Expires: September 4, 2007                                        Nokia
                                                          March 5, 2007

  Signaling media decoding dependency in Session Description Protocol

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 4, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


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
as a result of the use of a layered or multiple descriptive media coding

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

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"

Schierl & Wenger         Expires September 4, 2007             [page 2]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

Table of Content

   1.   Introduction..................................................4
   2.   Terminology...................................................4
   3.   Definitions...................................................4
   4.   Motivation, Use Cases, and Architecture.......................6
   4.1.   Motivation..................................................6
   4.2.   Use cases...................................................7
   5.   Signaling Media Dependencies..................................8
   5.1.   Design Principles...........................................8
   5.2.   Semantics...................................................8
   5.2.1.  SDP grouping semantics for decoding dependency.............8
   5.2.2.  Attribute for dependency signaling per media-stream........8
   6.   Usage of new semantics in SDP.................................9
   6.1.1.  Usage with the SDP Offer/Answer Model......................9
   6.1.2.  Usage with existing entities not supporting new signaling.10
   6.1.3.  Declarative usage.........................................10
   6.2.   Examples...................................................11
   7.   Security Considerations......................................12
   8.   IANA Considerations..........................................12
   9.   Acknowledgements.............................................12
   10.  References...................................................13
   10.1.  Normative References.......................................13
   10.2.  Informative References.....................................13
   11.  Author's Addresses...........................................13
   12.  Intellectual Property Statement..............................14
   13.  Disclaimer of Validity.......................................14
   14.  Copyright Statement..........................................14
   15.  RFC Editor Considerations....................................14
   16.  Open issues..................................................15
   17.  Change Log:..................................................15

Schierl & Wenger         Expires September 4, 2007             [page 3]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

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 that indicate the same media type, a receiver cannot
   identify a specific relationship between those media.

   A layered or Multiple Description Coded (MDC) Media Bitstream
   contains, by definition, one or more Media Partitions that are
   conveyed in their own media stream.  The only case we are interested
   in is a non-degraded layered/MDC Bitstream 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 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
   the reproduced quality gets.  At present, SDP and its supporting
   infrastructure of RFCs lack the means to express such a usage

   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's not specific to SVC, but applies
   to all layered or MDC codecs.  Therefore, this memo presents a
   generic solution.

   The mechanisms defined herein are media transport protocol
   independent, i.e. applicable beyond the use of RTP [RFC3550].

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119

3. Definitions

Schierl & Wenger         Expires September 4, 2007             [page 4]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   Media stream:
   As per [RFC4466].

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

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

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

   Layered/hierarchical 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 create a directed graph.  Note:
   normally, in layered/hierarchical 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 than are necessarily required to form an
   Operation Point.

   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 or error resilience, and does not include
   any other Media Partitions.  In MDC coding, a subset of a MDC Media
   Bitstream that is compliant with the MDC coding standard in question.

   The following terms are included for clarification on RTP [RFC3550]
   multiplexing techniques.  Further discussion can be found in section
   5.2 of [RFC3550].

Schierl & Wenger         Expires September 4, 2007             [page 5]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   Session multiplexing:  The Media Bitstream is distributed onto
   different RTP sessions, whereby each RTP session carries one RTP
   packet stream with one or more Media Partitions of the Media
   Bitstream.  Each RTP session requires a separate signaling and has a
   separate Timestamp, Sequence Number, and SSRC space.  Dependency
   between sessions MUST be signaled according to this memo.

4. Motivation, Use Cases, and Architecture

4.1. Motivation

   Two types of dependencies are discussed in the following in more
   detail: layered or hierarchical decoding dependency, and multi-
   description decoding dependency.  The transport of
   layered/hierarchical 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/hierarchical 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 network streams.  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

   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 decoding scheme, including knowledge about all the
   other layers that need to be decoded.

   [RFC4466] contains rudimentary support for exactly this use case and
   media formats, in that it allows for signaling a range of transport
   addresses for 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.

   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

Schierl & Wenger         Expires September 4, 2007             [page 6]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   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).

   o Multi descriptive decoding dependency:

   In the most basic form of multiple description coding (MDC), each
   partition forms an independent representation of the media.  That is,
   decoding of any of the Media Partition 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].

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

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

   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 and/or over an
   encrypted transmission path.  Enhancement layers, on the other hand,

Schierl & Wenger         Expires September 4, 2007             [page 7]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   can be conveyed over best effort, as they are "optional" in their
   characteristic -- nice to have, but non-essential for media
   consumption.  Similarly, while it is essential that the base layer is
   encrypted, there is (at least conceptually) a lesser need to encrypt
   the enhancement layer, as the enhancement layer is less important and
   useful without the (encrypted) base layer in terms of resulting video
   quality.  (This, of course depends highly on the media coding
   technology involved -- if the enhancement layer has some value in its
   own right, then it perhaps needs as strong encryption as the base
   layer.)  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.

5.2. Semantics

5.2.1.    SDP grouping semantics for decoding dependency

   This specification defines the new grouping semantics
   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.  All media streams of a DDP group MUST have the
   same type of coding dependency (as signaled by attribute defined in
   5.2.2) and MUST belong to one media bitstream.  All media streams
   MUST contain at least one operation point.  The DDP group type
   informs a receiver about the requirement for treating the media
   streams of the group according to the new media level attribute
   "depend", as defined in 5.2.2.

5.2.2.    Attribute for dependency signaling per media-stream

   This memo defines a new media-level value attribute, "depend", with
   the following ABNF [RFC4234]. The "identification-tag" (if used) is
   defined in [RFC3388]:

          depend-attribute     =  "a" "=" "depend" ":"

Schierl & Wenger         Expires September 4, 2007             [page 8]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

                                  *( SP identification-tag ) CRLF
          dependency-type-tag  = dependency
          dependency           = "lay" / "mdc"

   The "depend"-attribute describes the decoding dependency.  The
   "depend"-attribute may be followed by a sequence of identification-
   tag(s) which identify all related media streams.  The attribute MAY
   be used with multicast as well as with unicast transport addresses.
   The following types of dependencies are defined:

   o lay:  Layered decoding dependency -- identifies the described media
   stream as one or more partitions of a layered media bitstream.  When
   lay is used, all media streams MUST be identified by the following
   identification-tag(s) that are required for a successful use of the
   media stream.  The identification-tag(s) MUST be present when lay is
   in use.  Further the described media stream represents one operation
   point of the layered media bitstream.  As a result, all other media
   streams belonging to the same dependency group, but not identified by
   an identification-tag in the media description, are not required for
   a successful reproduction of the operation point represented by the
   media stream in question.  Hence, a media sender MAY omit sending
   them when that is advantageous from a scalability or transport

   o mdc:  Multi descriptive decoding dependency -- signals that the
   described media stream is or one more partitions of a multi
   description coding (MDC) media bitstream.  By definition, at least N
   out of M streams of the group MUST be received for allowing decoding
   the media, whereby N and M are media stream dependent and not
   signaled.  Receiving more than one media stream of the group may
   enhance the decodable quality of the media bitstream.  This type of
   dependency does not require the signaling of the depended media

6. Usage of new semantics in SDP

6.1.1.    Usage with the SDP Offer/Answer Model

   An Offerer offering partitions of a media streams in different "m"-
   lines SHALL use the signaling defined within this document, i.e. it
   SHALL indicate the "DDP" SDP-group for the involved "m"-lines and
   SHALL indicate their relation using the "depend" value.

   An Answerer supporting the signaling defined within this document
   that replies on an offer including the signaling defined within this
   document SHALL also use these mechanisms, i.e. it SHALL indicate the
   "DDP" SDP-group for the involved "m"-lines and SHALL indicate their

Schierl & Wenger         Expires September 4, 2007             [page 9]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   relation using the "depend" value.  An Answerer may further request a
   valid subset of the offered "m"-lines of one "DDP" group only.

   If an Answerer does not understand the signaling defined in this
   document, it should be able to detect a backward compatible "m"-line
   in the Session description.  This may be possible by e.g. offering a
   backward compatible, stand-alone partition of the media in a separate
   "m"-line.  Such a media description may point to the same transport
   address as used for an extended media session description using the
   features defined in this memo.  Following this reasoning, an Answerer
   can obtain minimum service quality (by decoding the base layer or a
   single description) even when it does not understand the mechanisms
   of this memo.

   If an Offerer do not support the signaling defined in this memo,
   typically no problem arises, since the signaling will not be used.
   In such a case, the offer of partitions of the same media in
   different "m"-lines will anyway not be possible.

6.1.2.    Usage with existing entities not supporting new signaling

   The feature of signaling the decoding dependency of media streams
   allows for indicating new media dependencies. By that, it allows for
   transmission of partitions of a media within different media streams.
   Since the aforementioned way of transmitting media is only feasible
   with future media coding standards, typically existing terminals or
   media gateways or not affected.  Currently the only existing case,
   where backward compatibility is an issue, is the use of SVC
   [I-D.ietf-avt-rtp-svc].  This is the case, since in SVC (as an
   example for a layered media coding standard) the base layer
   (representing the base quality of the media bit-stream) is backward
   compatible with the already existing profiles of the video coding
   standard H.264 [RFC3984].

6.1.3.    Declarative usage

   If a RTSP client understands the new signaling, it SHALL setup all
   media streams that are required to decode the desired quality.

   If an RTSP receiver does not understand the signaling defined within
   this memo, it should be able to request a backward compatible base
   representation of the media-bitstream in the session description, if
   such compatibility is feasible with the media codec in question.

   Furthermore, for RTSP as well as for SAP the signaling defined within
   this memo requires no additional restrictions, since the dependency
   signaling describes explicit relations of media streams identified by

Schierl & Wenger         Expires September 4, 2007             [page 10]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   "m"-lines.  RTSP allows for e.g. declaring the network address value,
   but this mechanism does not affect the signaling defined in here.

6.2. Examples

   a.)  Example for signaling transport of operation points of a layered
        video bitstream in different network streams:

          o=svcsrv 289083124 289083124 IN IP4 host.example.com
          t=0 0

          c=IN IP4
          a=group:DDP 1 2 3 4

          m=video 40000 RTP/AVP 94
          a=rtpmap:94 h264/90000

          m=video 40002 RTP/AVP 95
          a=rtpmap:95 svc1/90000
          a=depend:lay 1

          m=video 40004 RTP/AVP 96
          a=rtpmap:96 svc1/90000
          a=depend:lay 1

          m=video 40004 RTP/SAVP 100
          c=IN IP4
          a=rtpmap:100 svc1/90000
          a=depend:lay 1 3

   b.)  Example for signaling transport of streams of a multi
        description (MDC) video bitstream in different network streams:

Schierl & Wenger         Expires September 4, 2007             [page 11]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

          o=mdcsrv 289083124 289083124 IN IP4 host.example.com
          t=0 0

          c=IN IP4
          a=group:DDP 1 2 3
          m=video 40000 RTP/AVP 94

          m=video 40002 RTP/AVP 95

          m=video 40004 RTP/AVP 96
          c=IN IP4

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 application, e.g. a receiver may try to re-interleave
   media packets in a non-media standard conforming way.  Since the
   output of the aforementioned operation is served to a media decoder,
   this entity has anyway to be aware of losses in a media bit-stream or
   non-consistence of the media bit-stream.  It is recommended that the
   receiver SHOULD do integrity check on SDP and follow the security
   considerations of SDP to only trust SDP from trusted sources.

8. IANA Considerations

   This document defines the "DDP" semantics to be used with grouping of
   media lines in SDP as defined in RFC 3388. The "DDP" semantics
   defined in this memo are to be registered by the IANA when it is
   published in standard track RFCs.

   The attribute "depend" is to be registered by IANA as a new medial-
   level attribute.  The purpose of this attribute is to express a
   dependency, which may exist between "m"-lines of a media session.

9. Acknowledgements

Schierl & Wenger         Expires September 4, 2007             [page 12]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   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
   FP6-IST-0028097, project ASTRALS.

10.  References

10.1.     Normative References

[RFC4466]    Handley, M., Jacobson, V, and C. Perkins, "SDP: Session
             Description Protocol", IETF work in progress, July
[RFC3388]    Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of
             Media Lines in the Session Description Protocol (SDP)",
             RFC 3388, December 2002.
[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.
[RFC4234]    Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 4234, October 2005.

10.2.     Informative References

             Wenger, S., Wang Y.-K. and T. Schierl, "RTP Payload Format
             for SVC Video", draft-ietf-avt-rtp-svc-01 (work in
             progress), March 2007.
[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,
             Singer, D, "RTP Payload Format for H.264 Video", RFC 3984,
             February 2005.

11.  Author's Addresses

   Thomas Schierl                       Phone: +49-30-31002-227
   Fraunhofer HHI                       Email: schierl@hhi.fhg.de
   Einsteinufer 37
   D-10587 Berlin

   Stephan Wenger                       Phone: +358-50-486-0637
   Nokia Research Center                Email: stewe@stewe.org
   P.O. Box 100

Schierl & Wenger         Expires September 4, 2007             [page 13]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

   FIN-33721 Tampere

12.  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

   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

13.  Disclaimer of Validity

   This document and the information contained herein are provided on an

14.  Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

15.  RFC Editor Considerations


Schierl & Wenger         Expires September 4, 2007             [page 14]

Internet-Draft    draft-schierl-mmusic-layered-codec-03    March 2007

16.  Open issues

   Interaction with capability negotiation

17.  Change Log:

   19Dec06 / TS:
   removed SSRC multiplexing and with that various information about RTP
   draft title correction
   corrected SDP reference
   editorial modifications throughout the document
   added Stephan Wenger to the list of authors
   removed section "network elements not supporting dependency
   20-28Dec06 / TS, StW: Editorial improvements
   3Mar07 / TS: adjustment for new I-D style, added Offer/Answer text,
   corrected ABNF reference, added Security and IANA considerations,
   added section Usage with existing entities not supporting new
   signaling, added text for Declarative usage section, added Open
   issues section.

Schierl & Wenger         Expires September 4, 2007             [page 15]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/