draft-ietf-mmusic-decoding-dependency-01.txt   draft-ietf-mmusic-decoding-dependency-02.txt 
Network Working Group T. Schierl Network Working Group T. Schierl
Internet-Draft Fraunhofer HHI Internet-Draft Fraunhofer HHI
Intended status: Standards Track S. Wenger Intended status: Standards Track S. Wenger
Expires: August 24, 2008 Nokia Expires: November 25, 2008 Nokia
February 25, 2008 May 25, 2008
Signaling media decoding dependency in Session Description Protocol Signaling media decoding dependency in Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-decoding-dependency-01 draft-ietf-mmusic-decoding-dependency-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2008. This Internet-Draft will expire on November 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo defines semantics that allow for signaling the decoding This memo defines semantics that allow for signaling the decoding
dependency of different media descriptions with the same media type in dependency of different media descriptions with the same media type in
the Session Description Protocol (SDP). This is required, for example, the Session Description Protocol (SDP). This is required, for example,
if media data is separated and transported in different network streams 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 as a result of the use of a layered or multiple descriptive media coding
process. process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be A new grouping type "DDP" -- decoding dependency -- is defined, to be
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in used in conjunction with RFC 3388 entitled "Grouping of Media Lines in
the Session Description Protocol". In addition, an attribute is the Session Description Protocol". In addition, an attribute is
specified describing the relationship of the media streams in a "DDP" specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and RTP payload group indicated by media identification attribute(s) and media format
type(s). description(s).
Table of Contents Table of Contents
1. Introduction .................................................. 4 1. Introduction .................................................. 4
2. Terminology ................................................... 4 2. Terminology ................................................... 5
3. Definitions ................................................... 5 3. Definitions ................................................... 5
4. Motivation, Use Cases, and Architecture ....................... 6 4. Motivation, Use Cases, and Architecture ....................... 6
4.1. Motivation .................................................. 6 4.1. Motivation .................................................. 6
4.2. Use cases ................................................... 7 4.2. Use cases ................................................... 8
5. Signaling Media Dependencies .................................. 8 5. Signaling Media Dependencies .................................. 8
5.1. Design Principles ........................................... 8 5.1. Design Principles ........................................... 8
5.2. Semantics ................................................... 8 5.2. Semantics ................................................... 9
5.2.1. SDP grouping semantics for decoding dependency............. 8 5.2.1. SDP grouping semantics for decoding dependency ............ 9
5.2.2. Attribute for dependency signaling per media-stream........ 9 5.2.2. Attribute for dependency signaling per media-stream ....... 9
6. Usage of new semantics in SDP ................................ 10 6. Usage of new semantics in SDP ................................ 10
6.1. Usage with the SDP Offer/Answer Model ...................... 10 6.1. Usage with the SDP Offer/Answer Model ...................... 10
6.2. Declarative usage .......................................... 10 6.2. Declarative usage .......................................... 11
6.3. Usage with Capability Negotiation .......................... 10 6.3. Usage with Capability Negotiation .......................... 11
6.4. Examples ................................................... 11 6.4. Examples ................................................... 12
7. Security Considerations ...................................... 12 7. Security Considerations ...................................... 13
8. IANA Considerations .......................................... 12 8. IANA Considerations........................................... 14
9. Open Issues .................................................. 13 9. References ................................................... 15
10. References ................................................... 13 9.1. Normative References ....................................... 15
10.1. Normative References ...................................... 13 9.2. Informative References ..................................... 15
10.2. Informative References .................................... 13 Appendix A. Changes From Earlier Versions ....................... 16
Appendix A. Changes From Earlier Versions........................ 14 Authors' Addresses ............................................... 17
Authors' Addresses................................................ 15 Full Copyright Statement ......................................... 17
Full Copyright Statement.......................................... 15 Intellectual Property Statement .................................. 17
Intellectual Property Statement................................... 15 Acknowledgements ................................................. 18
Acknowledgements.................................................. 16
1. Introduction 1. Introduction
An SDP session description may contain one or more media An SDP session description may contain one or more media
descriptions, each identifying a single media stream. A media descriptions, each identifying a single media stream. A media
description is identified by one "m=" line. Today, if more than one description is identified by one "m=" line. Today, if more than one
"m=" lines exist indicating the same media type, a receiver cannot "m=" lines exist indicating the same media type, a receiver cannot
identify a specific relationship between those media. identify a specific relationship between those media.
A Multiple Description Coding (MDC) or layered Media Bitstream A Multiple Description Coding (MDC) or layered Media Bitstream
contains, by definition, one or more Media Partitions that are contains, by definition, one or more Media Partitions that are
conveyed in their own media stream. In Multi View Coding (MVC) [I- conveyed in their own media stream. The cases we are interested in
D.wang-avt-rtp-mvc] layered dependencies between views are used to are layered and MDC Bitstreams with two or more Media Partitions.
increase the coding efficiency. 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 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, the key use cases for employing layered or MDC coded media. Senders,
network elements, or receivers can suppress network elements, or receivers can suppress
sending/forwarding/subscribing/decoding individual Media Partitions sending/forwarding/subscribing/decoding individual Media Partitions
and still preserve perhaps suboptimal, but still useful media and still preserve perhaps suboptimal, but still useful media
quality. quality.
One property of all Media Bitstreams relevant to this memo is that One property of all Media Bitstreams relevant to this memo is that
their Media Partitions have a well-defined usage relationship. For their Media Partitions have a well-defined usage relationship. For
example, in layered coding, "higher" Media Partitions are useless example, in layered coding, "higher" Media Partitions are useless
without "lower" ones. In MDC coding, Media Partitions are without "lower" ones. In MDC coding, Media Partitions are
complementary -- the more Media Partitions one receives, the better a complementary -- the more Media Partitions one receives, the better a
reproduced quality may be. At present, SDP and its supporting reproduced quality may be. At present, SDP and its extensions lack
infrastructure of RFCs lack the means to express such a usage the means to express such a usage relationship.
relationship.
Trigger for the present memo has been the standardization process of Trigger for the present memo has been the standardization process of
the RTP payload format for the Scalable Video Coding extension to 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 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 [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 in signaling support is one that is not specific to SVC, but applies
to all layered or MDC codecs. Therefore, this memo presents a to all layered or MDC codecs. Therefore, this memo presents a
generic solution. 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, The mechanisms defined herein are media transport protocol dependent,
i.e. applicable to the use of RTP [RFC3550] only. and applicable only in conjunction with the use of RTP [RFC3550].
The SDP grouping of Media Lines of different media types is out of The SDP grouping of Media Lines of different media types is out of
scope of this memo. scope of this memo.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
Media stream: Media stream:
As per [RFC4566]. As per [RFC4566].
skipping to change at page 5, line 29 skipping to change at page 5, line 32
Media Partition: Media Partition:
A subset of a Media Bitstream intended for independent A subset of a Media Bitstream intended for independent
transportation. An integer number of Media Partitions forms a Media transportation. An integer number of Media Partitions forms a Media
Bitstream. In layered coding, a Media Partition represents one or Bitstream. In layered coding, a Media Partition represents one or
more layers that are handled as a unit. In MDC coding, a Media more layers that are handled as a unit. In MDC coding, a Media
Partition represents one or more descriptions that are handled as a Partition represents one or more descriptions that are handled as a
unit. unit.
Decoding dependency: Decoding dependency:
The class of relationships media partitions have to each other. At The class of relationships media partitions have to each other. At
present, this memo defines two decoding dependencies: layering and present, this memo defines two decoding dependencies: layered coding
multiple description. and multiple description coding.
Layered coding dependency: Layered coding dependency:
Each Media Partition is only useful (i.e. can be decoded) when all of Each Media Partition is only useful (i.e. can be decoded) when all of
the Media Partitions it depends on are available. The dependencies the Media Partitions it depends on are available. The dependencies
between the Media Partitions therefore create a directed graph. between the Media Partitions therefore create a directed graph.
Note: normally, in layered coding, the more Media Partitions are Note: normally, in layered coding, the more Media Partitions are
employed (following the rule above), the better a reproduced quality employed (following the rule above), the better a reproduced quality
is possible. is possible.
Multi description coding (MDC) dependency: Multi description coding (MDC) dependency:
skipping to change at page 6, line 13 skipping to change at page 6, line 18
certain point of quality, error resilience, or another property, and certain point of quality, error resilience, or another property, and
does not include any other Media Partitions. In MDC coding, a subset does not include any other Media Partitions. In MDC coding, a subset
of an MDC Media Bitstream that is compliant with the MDC coding of an MDC Media Bitstream that is compliant with the MDC coding
standard in question. standard in question.
4. Motivation, Use Cases, and Architecture 4. Motivation, Use Cases, and Architecture
4.1. Motivation 4.1. Motivation
This memo is concerned with two types of decoding dependencies: This memo is concerned with two types of decoding dependencies:
layered, and multi-description. The transport of layered and multi layered and multi-description. The transport of layered and multi
description coding share as key motivators the desire for media description coding share as key motivators the desire for media
adaptation to network conditions, i.e. related to bandwidth, error adaptation to network conditions, i.e., related to bandwidth, error
rates, connectivity of endpoints in multicast or broadcast scenarios, rates, connectivity of endpoints in multicast or broadcast scenarios,
and similar. and similar.
o Layered decoding dependency: o Layered decoding dependency:
In layered coding, the partitions of a Media Bitstream are known as In layered coding, the partitions of a Media Bitstream are known as
media layers or simply layers. One or more layers may be transported media layers or simply layers. One or more layers may be
in different media streams in the sense of [RFC4566]. A classic use transported in different media streams in the sense of [RFC4566].
case is known as receiver-driven layered multicast, in which a A classic use case is known as receiver-driven layered multicast,
receiver selects a combination of media streams in response to in which a receiver selects a combination of media streams in
quality or bit-rate requirements. response to quality or bit-rate requirements.
Back in the mid 1990s, the then available layered media formats and Back in the mid 1990s, the then available layered media formats and
codecs envisioned primarily (or even exclusively) a one-dimensional codecs envisioned primarily (or even exclusively) a one-dimensional
hierarchy of layers. That is, each so-called enhancement layer hierarchy of layers. That is, each so-called enhancement layer
referred to exactly one layer "below". The single exception has been referred to exactly one layer "below". The single exception has
the base layer, which is self-contained. Therefore, the been the base layer, which is self-contained. Therefore, the
identification of one enhancement layer fully specifies the operation identification of one enhancement layer fully specifies the
point of a layered coding scheme, including knowledge about all the Operation point of a layered coding scheme, including knowledge
other layers that need to be decoded. about all the other layers that need to be decoded.
[RFC4566] contains rudimentary support for exactly this use case and SDP [RFC4566] contains rudimentary support for exactly this use
media formats, in that it allows for signaling a range of transport case and media formats, in that it allows for signaling a range of
addresses in a certain media description. By definition, a higher transport addresses in a certain media description. By definition,
transport address identifies a higher layer in the one-dimensional a higher transport address identifies a higher layer in the one-
hierarchy. A receiver needs only to decode data conveyed over this dimensional hierarchy. A receiver needs only to decode data
transport address and lower transport addresses to decode this conveyed over this transport address and lower transport addresses
Operation Point. to decode this Operation Point.
Newer media formats depart from this simple one-dimensional Newer media formats depart from this simple one-dimensional
hierarchy, in that highly complex (at least tree-shaped) dependency hierarchy, in that highly complex (at least tree-shaped) dependency
hierarchies can be implemented. Compelling use cases for these hierarchies can be implemented. Compelling use cases for these
complex hierarchies have been identified by industry. Support for it complex hierarchies have been identified by industry. Support for
is therefore desirable. However, SDP, in its current form, does not it is therefore desirable. However, SDP, in its current form, does
allow for the signaling of these complex relationships. Therefore, not allow for the signaling of these complex relationships.
receivers cannot make an informed decision on which layers to Therefore, receivers cannot make an informed decision on which
subscribe (in case of layered multicast). layers to subscribe (in case of layered multicast).
Layered decoding dependency may also exit in a Multi View Coding Layered decoding dependencies may also exist in a Multi View Coding
environment. Views may be coded using inter-view dependencies to environment. Views may be coded using inter-view dependencies to
increase coding efficiency. This results in Media Bitstreams, which increase coding efficiency. This results in Media Bitstreams,
logically may be separated into Media Partitions representing which logically may be separated into Media Partitions representing
different views of the reconstructed video signal. These Media different views of the reconstructed video signal. These Media
Partitions cannot be decoded independently, and, therefore, other Partitions cannot be decoded independently, and, therefore, other
Media Partitions are required for reconstruction. To express this Media Partitions are required for reconstruction. To express this
relationship, the signaling needs to express the dependencies of the relationship, the signaling needs to express the dependencies of
views, which in turn are Media Partitions in the sense of this the views, which in turn are Media Partitions in the sense of this
document. document.
o Multi descriptive decoding dependency: o Multi descriptive decoding dependency:
In the most basic form of MDC, each Media Partition forms an In the most basic form of MDC, each Media Partition forms an
independent representation of the media. That is, decoding of any of independent representation of the media. That is, decoding of any
the Media Partitions yields useful reproduced media data. When more of the Media Partitions yields useful reproduced media data. When
than one Media Partition is available, then a decoder can process more than one Media Partition is available, then a decoder can
them jointly, and the resulting media quality increases. The highest process them jointly, and the resulting media quality increases.
reproduced quality is available if all original Media Partitions are The highest reproduced quality is available if all original Media
available for decoding. Partitions are available for decoding.
More complex forms of multiple description coding can also be More complex forms of multiple description coding can also be
envisioned, i.e. where, as a minimum, N out of M total Media envisioned, i.e. where, as a minimum, N out of M total Media
Partitions need to be available to allow meaningful decoding. Partitions need to be available to allow meaningful decoding.
MDC has not yet been embraced heavily by the media standardization MDC has not yet been embraced heavily by the media standardization
community, though it is subject of a lot of academic research. As an community, though it is subject of a lot of academic research. As
example, we refer to [MDC]. an example, we refer to [MDC].
In this memo, we cover MDC because we a) envision that MDC media In this memo, we cover MDC because we a) envision that MDC media
formats will come into practical use within the lifetime of this formats will come into practical use within the lifetime of this
memo, and b) the solution for its signaling is very similar to the memo, and b) the solution for its signaling is very similar to the
one of layered coding. one of layered coding.
o Other decoding dependency relationships:
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 a new decoding
dependency types, if a need could be shown. If such an extension
were becoming 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 4.2. Use cases
o Receiver driven layered multicast 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 This technology is discussed in [RFC3550] and references therein.
We refrain from elaborating further; the subject is well known and
understood. understood.
o Multiple end-to-end transmission with different properties o Multiple end-to-end transmission with different properties:
Assume a unicast and point-to-point topology, wherein one endpoint Assume a unicast and point-to-point topology, wherein one endpoint
sends media to another. Assume further that different forms of media sends media to another. Assume further that different forms of
transmission are available. The difference may lie in the cost of media transmission are available. The difference may lie in the
the transmission (free, charged), in the available protection cost of the transmission (free, charged), in the available
(unprotected/secure), in the quality of service (guaranteed quality / protection (unprotected/secure), in the quality of service
best effort), or other factors. (guaranteed quality / best effort), or other factors.
Layered and MDC coding allow to match the media characteristics to Layered and MDC coding allow to match the media characteristics to
the available transmission path(s). For example, in layered coding the available transmission path(s). For example, in layered
it makes sense to convey the base layer over high QoS. Enhancement coding, it makes sense to convey the base layer over high QoS.
layers, on the other hand, can be conveyed over best effort, as they Enhancement layers, on the other hand, can be conveyed over best
are "optional" in their characteristic -- nice to have, but non- effort, as they are "optional" in their characteristic -- nice to
essential for media consumption. In a different scenario, the base have, but non-essential for media consumption. In a different
layer may be offered in a non-encrypted session as a free preview. scenario, the base layer may be offered in a non-encrypted session
An encrypted enhancement layer references this base layer and allows as a free preview. An encrypted enhancement layer references this
optimal quality play-back; however, it is only accessible to users base layer and allows optimal quality play-back; however, it is
who have the key, which may have been distributed by a conditional only accessible to users who have the key, which may have been
access mechanism. distributed by a conditional access mechanism.
5. Signaling Media Dependencies 5. Signaling Media Dependencies
5.1. Design Principles 5.1. Design Principles
The dependency signaling is only feasible between media descriptions The dependency signaling is only feasible between media descriptions
described with an "m="-line and with an assigned media identification described with an "m="-line and with an assigned media identification
attribute ("mid"), as defined in [RFC3388]. attribute ("mid"), as defined in [RFC3388]. All "m=" lines grouped
according to this specification MUST have the same media type.
5.2. Semantics 5.2. Semantics
5.2.1. SDP grouping semantics for decoding dependency 5.2.1. SDP grouping semantics for decoding dependency
This specification defines a new grouping semantic This specification defines a new grouping semantic
Decoding Dependency "DDP": Decoding Dependency "DDP":
DDP associates a media stream, identified by its mid attribute, with DDP associates a media stream, identified by its mid attribute, with
a DDP group. Each media stream MUST be composed of an integer number a DDP group. Each media stream MUST be composed of an integer number
of Media Partitions. A media stream is identified by a session- of Media Partitions. A media stream is identified by a session-
unique RTP payload type number within a "m="-line. In a DDP group, unique media format description (RTP payload type number) within a
all media streams MUST have the same type of decoding dependency (as "m="-line. In a DDP group, all media streams MUST have the same type
signaled by the attribute defined in 5.2.2). All media streams MUST of decoding dependency (as signaled by the attribute defined in
contain at least one operation point. The DDP group type informs a 5.2.2). All media streams MUST contain at least one Operation point.
receiver about the requirement for treating the media streams of the The DDP group type informs a receiver about the requirement for
group according to the new media level attribute "depend", as defined handling the media streams of the group according to the new media
in 5.2.2. level attribute "depend", as defined in 5.2.2.
When using multiple codecs, e.g. for Offer/Answer model, the media When using multiple codecs, e.g. for Offer/Answer model, the media
streams MUST have the same dependency structure, regardless which streams MUST have the same dependency structure, regardless which
payload type number is used. media format description (RTP payload type number) is used.
5.2.2. Attribute for dependency signaling per media-stream 5.2.2. Attribute for dependency signaling per media-stream
This memo defines a new media-level attribute, "depend", with the This memo defines a new media-level attribute, "depend", with the
following ABNF [RFC4234]. The "identification-tag" is defined in following ABNF [RFC5234]. The identification-tag is defined in
[RFC3388]: [RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used
as defined in [RFC4566].
depend-attribute = "a" "=" "depend" ":" depend-attribute =
( dependent-payload-type dependency-tag ";" ) "a=depend:" dependent-fmt SP dependency-tag
*( SP dependent-payload-type dependency-tag ";" ) *(";" SP dependent-fmt SP dependency-tag) CRLF
CRLF
dependency-tag = dependency-type
*1( SP identification-tag ":"
payload-type-dependency
*( "," payload-type-dependency )
)
dependency-type = "lay" / "mdc"
"dependent-payload-type", indicates the payload type number, as dependency-tag =
defined in [RFC4566], that depends on a "payload-type-dependency" in dependency-type *1( SP identification-tag ":"
the "m="-line indicated by the value of "identification-tag" within fmt-dependency *("," fmt-dependency ))
the "dependency-tag".
"payload-type-dependency", indicates the payload type number in the dependency-type = "lay"
"m="-line identified by the "identification-tag" within the / "mdc"
"dependency-tag", which the "dependent-payload-type" number of the / token
dependent "m="-line depends on.
The "depend"-attribute describes the decoding dependency. The dependent-fmt = fmt
"depend"-attribute MAY be followed by a sequence of "dependency- fmt-dependency = fmt
tag"(s) which identify all related RTP payload types in all related
dependent-fmt, indicates the media format description, as defined in
[RFC4566], that depends on one or more media format description in
the "m="-line indicated by the value of identification-tag within the
dependency-tag.
fmt-dependency, indicates the media format description in the "m="-
line identified by the identification-tag within the dependency-tag,
which the dependent-fmt of the dependent "m="-line depends on.
The depend-attribute describes the decoding dependency. The depend-
attribute MAY be followed by a sequence of dependency-tag fields
which identify all related media format description in all related
"m="-lines. The attribute MAY be used with multicast as well as with "m="-lines. The attribute MAY be used with multicast as well as with
unicast transport addresses. The following types of dependencies are unicast transport addresses. The following dependency-types values
defined: are defined in this memo:
o lay: Layered decoding dependency -- identifies the described media o lay: Layered decoding dependency -- identifies the described media
stream as one or more Media Partitions of a layered Media Bitstream. stream as one or more Media Partitions of a layered Media
When "lay" is used, all required media streams for the Operation Bitstream. When "lay" is used, all media streams required for
Point MUST be identified by "identification-tag" and "payload-type- decoding the Operation Point MUST be identified by identification-
dependency" following the "lay" string. tag and fmt-dependency following the "lay" string.
o mdc: Multi descriptive coding dependency -- signals that the o mdc: Multi descriptive coding dependency -- signals that the
described media stream is part of a set of a MDC Media Bitstream. By described media stream is part of a set of a MDC Media Bitstream.
definition, at least N out of M media streams of the group need to be By definition, at least N out of M media streams of the group need
available to from an Operation Point. The values of N and M depend on to be available to from an Operation Point. The values of N and M
the properties of the Media Bitstream and are not signaled within depend on the properties of the Media Bitstream and are not
this context. When "mdc" is used, all required media streams for the signaled within this context. When "mdc" is used, all required
Operation Point MUST be identified by "identification-tag" and media streams for the Operation point MUST be identified by
"payload-type-dependency" following the "mdc" string. identification-tag and fmt-dependency following the "mdc" string.
Further dependency types MUST be defined in a standards-track
document.
6. Usage of new semantics in SDP 6. Usage of new semantics in SDP
6.1. Usage with the SDP Offer/Answer Model 6.1. Usage with the SDP Offer/Answer Model
The backward compatibility in offer / answer is generally handled as The backward compatibility in offer / answer is generally handled as
specified in [RFC3388]. specified in [RFC3388], section 8.4, as summarized below.
Depending on the implementation, a node that does not understand DDP Depending on the implementation, a node that does not understand DDP
grouping (either does not understand line grouping at all, or just grouping (either does not understand line grouping at all, or just
does not understand the DDP semantics) SHOULD respond to an offer does not understand the DDP semantics) SHOULD respond to an offer
containing DDP grouping either (1) with an answer that ignores the containing DDP grouping either (1) with an answer that ignores the
grouping attribute or (2) with a refusal to the request (e.g., 488 grouping attribute or (2) with a refusal to the request (e.g., 488
Not acceptable here or 606 Not acceptable in SIP). Not acceptable here or 606 Not acceptable in SIP).
In the first case, the original sender of the offer MUST respond by In the first case, the original sender of the offer MUST respond by
offering a single media stream that represents an Operation Point. offering a single media stream that represents an Operation Point.
skipping to change at page 10, line 48 skipping to change at page 11, line 32
Operation Point of its choice. Operation Point of its choice.
If an RTSP receiver does not understand the signaling defined within If an RTSP receiver does not understand the signaling defined within
this memo, it falls back to normal SDP processing. Two likely cases 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 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 included in the SDP is within the receiver's capabilities, it selects
among those candidates according to implementation specific criteria among those candidates according to implementation specific criteria
for setup, as usual. (2) If none of the media type included in the for setup, as usual. (2) If none of the media type included in the
SDP can be processed, then obviously no setup can occur. SDP can be processed, then obviously no setup can occur.
Edt. Note: we received a comment from Joerg Ott as follows [JO: Maybe
double-check that the RTSP Transport: header is sufficiently explicit
to allow this kind of choice. SAVPF has some discussion on what do
with RTSP.]. Neither of us feels competent in following up this
point. Input of the MMUSIC WG is requested. If the WG feels that
there is no need to address this comment, perhaps we can remove this
whole paragraph? An alternative would be to use language comparable
to section 6.3 below, and leave the issue for further study. We DO
NOT want to see a normative dependency to RTSP v2 in this draft due
to timing and deployment considerations.
6.3. Usage with Capability Negotiation 6.3. Usage with Capability Negotiation
This memo does not cover the interaction with Capability Negotiation This memo does not cover the interaction with Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation]. This issue should be [I-D.ietf-mmusic-sdp-capability-negotiation]. This issue is for
addressed in a different memo. further study and will be addressed in a different memo.
6.4. Examples 6.4. Examples
a.) Example for signaling layered decoding dependency dependency: a.) Example for signaling layered decoding dependency:
The example shows a session description with three "m"-lines,
all of type video. Each of the "m"-lines include two possible
media format descriptions, in the example: RTP payload types.
The first "m"-line includes a H264 payload type as defined by
[RFC3984] and the other "m"-lines include H264-SVC payload
types. The example shows the dependencies of the RTP payload
types of the different "m"-lines indicated by "DDP" grouping,
"mid" and "depend" attributes.
v=0 v=0
o=svcsrv 289083124 289083124 IN IP4 host.example.com o=svcsrv 289083124 289083124 IN IP4 host.example.com
s=LAYERED VIDEO SIGNALING Seminar s=LAYERED VIDEO SIGNALING Seminar
t=0 0 t=0 0
c=IN IP4 192.0.2.1/127 c=IN IP4 192.0.2.1/127
a=group:DDP 1 2 3 4 a=group:DDP 1 2 3 4
m=video 40000 RTP/AVP 94 194 m=video 40000 RTP/AVP 96 97
b=AS:96 b=AS:90
a=framerate:15 a=framerate:15
a=rtpmap:94 H264/90000 a=rtpmap:96 H264/90000
a=rtpmap: 194 H264/90000 a=rtpmap:97 H264/90000
a=mid:1 a=mid:1
m=video 40002 RTP/AVP 95 195 m=video 40002 RTP/AVP 98 99
b=AS:64 b=AS:64
a=framerate:15 a=framerate:15
a=rtpmap:95 H264-SVC/90000 a=rtpmap:98 H264-SVC/90000
a=rtpmap:195 H264-SVC/90000 a=rtpmap:99 H264-SVC/90000
a=mid:2 a=mid:2
a=depend:95 lay 1:94,194; 195 lay 1:194; a=depend:98 lay 1:96,97; 99 lay 1:97
m=video 40004 RTP/AVP 96 196 m=video 40004 RTP/AVP 100 101
b=AS:128 b=AS:128
a=framerate:30 a=framerate:30
a=rtpmap:96 H264-SVC/90000 a=rtpmap:100 H264-SVC/90000
a=rtpmap:196 H264-SVC/90000 a=rtpmap:101 H264-SVC/90000
a=mid:3 a=mid:3
a=depend:96 lay 1:94,194; 196 lay 1:194; a=depend:100 lay 1:96 2:98; 101 lay 1:97 2:99
m=video 40004 RTP/SAVP 100 200 m=video 40006 RTP/SAVP 102 103
c=IN IP4 192.0.2.2/127 c=IN IP4 192.0.2.2/127
b=AS:512 b=AS:512
k=uri:conditional-access-server.example.com k=uri:conditional-access-server.example.com
a=framerate:30 a=framerate:30
a=rtpmap:100 H264-SVC/90000 a=rtpmap:102 H264-SVC/90000
a=rtpmap:200 H264-SVC/90000 a=rtpmap:103 H264-SVC/90000
a=mid:4 a=mid:4
a=depend:100 lay 1:94,194 3:96; 200 lay 1:194 3:196; a=depend:102 lay 1:96,97 2:98; 103 lay 1:97 2:99
b.) Example for signaling of multi descriptive coding dependency: b.) Example for signaling of multi descriptive coding dependency:
The example shows a session description with three "m"-lines,
all of type video. Each of the "m"-lines includes one media
format description, in the example: RTP payload type, with multi
descriptive decoding dependency. The example shows the
dependencies of the RTP payload types of the different "m"-lines
indicated by "DDP" grouping, "mid" and "depend" attributes.
v=0 v=0
o=mdcsrv 289083124 289083124 IN IP4 host.example.com o=mdcsrv 289083124 289083124 IN IP4 host.example.com
s=MULTI DESCRIPTION VIDEO SIGNALING Seminar s=MULTI DESCRIPTION VIDEO SIGNALING Seminar
t=0 0 t=0 0
c=IN IP4 192.0.2.1/127 c=IN IP4 192.0.2.1/127
a=group:DDP 1 2 3 a=group:DDP 1 2 3
m=video 40000 RTP/AVP 94
m=video 40000 RTP/AVP 104
a=mid:1 a=mid:1
a=depend:94 mdc 2:95 3:96; a=depend:104 mdc 2:105 3:106
m=video 40002 RTP/AVP 95 m=video 40002 RTP/AVP 105
a=mid:2 a=mid:2
a=depend:95 mdc 1:94 3:96; a=depend:105 mdc 1:104 3:106
m=video 40004 RTP/AVP 96 m=video 40004 RTP/AVP 106
c=IN IP4 192.0.2.2/127 c=IN IP4 192.0.2.2/127
a=mid:3 a=mid:3
a=depend:96 mdc 1:94 2:95; a=depend:106 mdc 1:104 2:105
7. Security Considerations 7. Security Considerations
All security implications of SDP apply. All security implications of SDP apply.
There may be a risk of manipulation the dependency signaling of a There may be a risk of manipulation the dependency signaling of a
session description by an attacker. This may mislead a receiver or session description by an attacker. This may mislead a receiver or
middle box, e.g. a receiver may try to compose a bitstream that does middle box, e.g. a receiver may try to compose a media bitstream out
not form an Operation Point, although the signaling made it believe of several RTP packet streams that does not form an Operation Point,
it would form a valid Operation Point, with potential fatal although the signaling made it believe it would form a valid
consequences for the media decoding process. It is recommended that Operation Point, with potential fatal consequences for the media
the receiver SHOULD perform an integrity check on SDP and follow the decoding process. It is recommended that the receiver SHOULD perform
security considerations of SDP to only trust SDP from trusted an integrity check on SDP and follow the security considerations of
sources. SDP to only trust SDP from trusted sources.
8. IANA Considerations 8. IANA Considerations
This document defines the "DDP" semantics to be used with grouping of The following contact information shall be used for all registrations
media lines in SDP as defined in RFC 3388. The "DDP" semantics included here:
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 media- Contact: Thomas Schierl
level attribute. The purpose of this attribute is to express a mailto:schierl@hhi.fhg.de
dependency, which may exist between "m"-lines of a media session. tel:+49-30-31002-227
9. Open Issues 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.
- Requirement on media stream: With the new draft, different media Semantics Token Reference
streams can be present in a DDP group, that is different codecs ------------------- ----- ---------
may be used within the same DDP group? Decoding Dependency DDP RFC XXXX
- IANA registration for 'lay' and 'mdc'?
10. References The SDP media level attribute "depend" has been registered by IANA in
Semantics for "att-field (media level only)".
10.1. Normative References 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 coding dependency mdc RFC XXXX
9. References
9.1. Normative References
[RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of [RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of
Media Lines in the Session Description Protocol (SDP)", Media Lines in the Session Description Protocol (SDP)",
RFC 3388, December 2002. RFC 3388, December 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08, (work in
progress), December 2008
10.2. Informative References 9.2. Informative References
[I-D.ietf-avt-rtp-svc] [I-D.ietf-avt-rtp-svc]
Wenger, S., Wang Y.-K. and T. Schierl, "RTP Payload Format Wenger, S., Wang Y.-K.,T. Schierl and A. Eleftheriadis,
for SVC Video", draft-ietf-avt-rtp-svc-07 (work in "RTP Payload Format for SVC Video",
progress), February 2008. draft-ietf-avt-rtp-svc-09 (work in progress), May 2008.
[MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, [MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo,
"Video over IP using Standard-Compatible Multiple "Video over IP using Standard-Compatible Multiple
Description Coding: an IETF proposal", Packet Video Description Coding: an IETF proposal", Packet Video
Workshop, April 2006, Hangzhou, China Workshop, April 2006, Hangzhou, China
[I-D.wang-avt-rtp-mvc] [I-D.wang-avt-rtp-mvc]
Wang, Y.-K. and T. Schierl, "RTP Payload Format Wang, Y.-K. and T. Schierl, "RTP Payload Format
for MVC Video", draft-wang-avt-rtp-mvc-00 (work in for MVC Video", draft-wang-avt-rtp-mvc-01 (work in
progress), November 2007. progress), February 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08, (work in
progress), December 2007
[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. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
A.1 Changes from individual submission A.1 Changes from individual submission
19Dec06 / TS: 19Dec06 / TS:
removed SSRC multiplexing and with that various information about RTP removed SSRC multiplexing and with that various information about RTP
draft title correction draft title correction
corrected SDP reference corrected SDP reference
editorial modifications throughout the document editorial modifications throughout the document
skipping to change at page 15, line 5 skipping to change at page 16, line 39
A.2 Changes from draft-ietf-mmusic-decoding-dependency-00 to A.2 Changes from draft-ietf-mmusic-decoding-dependency-00 to
draft-ietf-mmusic-decoding-dependency-01: draft-ietf-mmusic-decoding-dependency-01:
21-Feb08: Enhanced mechanism by multiple "payload-type-dependencies" 21-Feb08: Enhanced mechanism by multiple "payload-type-dependencies"
for the same "mid". Typically the case, when using different for the same "mid". Typically the case, when using different
packetization modes as defined in RFC3984. packetization modes as defined in RFC3984.
25-Feb08: Modification throughout informative part of definition 25-Feb08: Modification throughout informative part of definition
section section
Different codecs may be present within the same DDP group. Different codecs may be present within the same DDP group.
A.3 Changes from draft-ietf-mmusic-decoding-dependency-01 to
draft-ietf-mmusic-decoding-dependency-02:
19-Mar08: Fixed PT# in example, removed unused references, updated
ABNF reference in text, IANA section updates, require std. track doc
for new dependencies, editorial changes
23-May08: Replacing payload-type with media format description/fmt,
renaming of dependent-payload-type to dependent-fmt, renaming
payload-type-dependency to fmt-dependency, editorial changes.
Authors' Addresses Authors' Addresses
Thomas Schierl Thomas Schierl
Fraunhofer HHI Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin D-10587 Berlin
Germany Germany
Phone: +49-30-31002-227 Phone: +49-30-31002-227
Email: schierl@hhi.fhg.de Email: schierl@hhi.fhg.de
skipping to change at page 16, line 21 skipping to change at page 18, line 22
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements Acknowledgements
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. 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
and Joerg Ott for their valuable and constructive comments to this
memo.
 End of changes. 78 change blocks. 
195 lines changed or deleted 283 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/