draft-ietf-mmusic-decoding-dependency-00.txt   draft-ietf-mmusic-decoding-dependency-01.txt 
MMUSIC 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: May 11, 2008 Nokia Expires: August 24, 2008 Nokia
November 12, 2007 February 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-00 draft-ietf-mmusic-decoding-dependency-01
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 2, line ? 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 May 11, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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. group indicated by media identification attribute(s) and RTP payload
type(s).
Table of Content Table of Contents
1. Introduction .................................................. 4 1. Introduction .................................................. 4
2. Terminology ................................................... 4 2. Terminology ................................................... 4
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 ................................................... 7
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 ................................................... 8
5.2.1. SDP grouping semantics for decoding dependency ............ 8 5.2.1. SDP grouping semantics for decoding dependency............. 8
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 .......................................... 10
6.3. Usage with Capability Negotiation .......................... 10 6.3. Usage with Capability Negotiation .......................... 10
6.4. Examples ................................................... 10 6.4. Examples ................................................... 11
7. Security Considerations ...................................... 12 7. Security Considerations ...................................... 12
8. IANA Considerations .......................................... 12 8. IANA Considerations .......................................... 12
9. Acknowledgements ............................................. 12 9. Open Issues .................................................. 13
10. References ................................................... 13 10. References ................................................... 13
10.1. Normative References ...................................... 13 10.1. Normative References ...................................... 13
10.2. Informative References .................................... 13 10.2. Informative References .................................... 13
11. Author's Addresses ........................................... 13 Appendix A. Changes From Earlier Versions........................ 14
12. Intellectual Property Statement .............................. 14 Authors' Addresses................................................ 15
13. Disclaimer of Validity ....................................... 14 Full Copyright Statement.......................................... 15
14. Copyright Statement .......................................... 14 Intellectual Property Statement................................... 15
15. RFC Editor Considerations .................................... 14 Acknowledgements.................................................. 16
16. Change Log: .................................................. 15
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) [MVC] conveyed in their own media stream. In Multi View Coding (MVC) [I-
dependencies between views are used for increasing coding efficiency. D.wang-avt-rtp-mvc] layered dependencies between views are used to
The cases we are interested in are a layered, MDC and MVC Bitstreams increase the coding efficiency. The cases we are interested in are
with two or more Media Partitions. Carrying more than one Media layered and MDC Bitstreams with two or more Media Partitions.
Partition in its own session is one of the key use cases for Carrying more than one Media Partition in its own session is one of
employing layered or MDC coded media. In MVC, different views or the key use cases for employing layered or MDC coded media Senders,
Media Partitions, all e.g. depending on a base view, are conveyed in network elements, or receivers can suppress
different sessions. Senders, network elements, or receivers can sending/forwarding/subscribing/decoding individual Media Partitions
suppress sending/forwarding/subscribing/decoding individual Media and still preserve perhaps suboptimal, but still useful media
Partitions and still preserve perhaps suboptimal, but still useful quality.
media 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 complementary -- the more Media Partitions one receives, the better a
the reproduced quality may be possible. At present, SDP and its reproduced quality may be. At present, SDP and its supporting
supporting infrastructure of RFCs lack the means to express such a infrastructure of RFCs lack the means to express such a usage
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's 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.
The mechanisms defined herein are media transport protocol The mechanisms defined herein are media transport protocol dependent,
independent, i.e. applicable beyond the use of RTP [RFC3550]. i.e. applicable to the use of RTP [RFC3550] only.
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].
skipping to change at page 5, line 25 skipping to change at page 5, line 25
A valid, decodable stream, containing all media partitions generated A valid, decodable stream, containing all media partitions generated
by the encoder. A Media Bitstream normally conforms to a media by the encoder. A Media Bitstream normally conforms to a media
coding standard. coding standard.
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. In Multi View Coding (MVC), a media partition is a view which unit.
may depend on other views.
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: layering and
multiple description. multiple description.
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. The dependencies in a layered Media Bitstream can be is possible.
also caused by Multi View Coding (MVC), using inter-view dependencies
for increasing coding efficiency.
Multi description coding (MDC) dependency: Multi description coding (MDC) dependency:
N of M Media Partitions are required to form a Media Bitstream, but N of M Media Partitions are required to form a Media Bitstream, but
there is no hierarchy between these Media Partitions. Most MDC there is no hierarchy between these Media Partitions. Most MDC
schemes aim at an increase of reproduced media quality when more schemes aim at an increase of reproduced media quality when more
media partitions are decoded. Some MDC schemes require more than one media partitions are decoded. Some MDC schemes require more than one
Media Partition to form an Operation point. Media Partition to form an Operation point.
Operation point: Operation point:
In layered coding, a subset of a layered Media Bitstream that In layered coding, a subset of a layered Media Bitstream that
includes all Media Partitions required for reconstruction at a includes all Media Partitions required for reconstruction at a
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. In MVC, an operation point, represents a standard in question.
number of views, which are decodeable with the set of available Media
Partitions.
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,
skipping to change at page 7, line 12 skipping to change at page 7, line 8
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 it
is therefore desirable. However, SDP, in its current form, does not is therefore desirable. However, SDP, in its current form, does not
allow for the signaling of these complex relationships. Therefore, allow for the signaling of these complex relationships. Therefore,
receivers cannot make an informed decision on which layers to receivers cannot make an informed decision on which layers to
subscribe (in case of layered multicast). subscribe (in case of layered multicast).
Layered decoding dependency may also exit in a Multi View Coding Layered decoding dependency may also exit in a Multi View Coding
(MVC). Views may be coded using inter-view dependencies for environment. Views may be coded using inter-view dependencies to
increasing coding efficiency. This results in Media Bitstreams, increase coding efficiency. This results in Media Bitstreams, which
which logically may be separated into Media Partitions representing logically may be separated into Media Partitions representing
different views by the reconstructed video signal. These Media different views of the reconstructed video signal. These Media
Partitions cannot be decoded independently, thus other Media Partitions cannot be decoded independently, and, therefore, other
Partitions are used for reconstruction. This requires signaling of Media Partitions are required for reconstruction. To express this
dependencies of views separated in Media Partitions. 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: 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 of
the Media Partitions yields useful reproduced media data. When more the Media Partitions yields useful reproduced media data. When more
than one Media Partition is available, then a decoder can process than one Media Partition is available, then a decoder can process
them jointly, and the resulting media quality increases. The highest them jointly, and the resulting media quality increases. The highest
reproduced quality is available if all original Media Partitions are reproduced quality is available if all original Media Partitions are
available for decoding. available for decoding.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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. All media streams of a DDP group MUST have the of Media Partitions. A media stream is identified by a session-
same type of decoding dependency (as signaled by the attribute unique RTP payload type number within a "m="-line. In a DDP group,
defined in 5.2.2), and MUST belong to one Media Bitstream. All media all media streams MUST have the same type of decoding dependency (as
streams (identified by an "m="-line) MUST contain at least one signaled by the attribute defined in 5.2.2). All media streams MUST
operation point. The DDP group type informs a receiver about the contain at least one operation point. The DDP group type informs a
requirement for treating the payload type numbers of the media receiver about the requirement for treating the media streams of the
streams of the group according to the new media level attribute group according to the new media level attribute "depend", as defined
"depend", as defined in 5.2.2. 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. 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 [RFC4234]. The "identification-tag" is defined in
[RFC3388]: [RFC3388]:
depend-attribute = "a" "=" "depend" ":" depend-attribute = "a" "=" "depend" ":"
payload-type dependency-tag ( dependent-payload-type dependency-tag ";" )
*("," SP payload- type dependency-tag ) *( SP dependent-payload-type dependency-tag ";" )
CRLF CRLF
dependency-tag = dependency-type 1*( SP identification-tag":" dependency-tag = dependency-type
payload-type-dependency ) *1( SP identification-tag ":"
payload-type-dependency
*( "," payload-type-dependency )
)
dependency-type = "lay" / "mdc" dependency-type = "lay" / "mdc"
"payload-type", indicates the payload type number, as defined in "dependent-payload-type", indicates the payload type number, as
[RFC4566], of the media description in question for which the defined in [RFC4566], that depends on a "payload-type-dependency" in
dependencies are indicated in the pair(s) of "identification-tag" and the "m="-line indicated by the value of "identification-tag" within
"payload-type-dependency" following the "dependency-type". the "dependency-tag".
"payload-type-dependency", indicates the payload type number of the "payload-type-dependency", indicates the payload type number in the
media stream indicated by the identification-tag, which the payload "m="-line identified by the "identification-tag" within the
type number of the media stream in question depends on. "dependency-tag", which the "dependent-payload-type" number of the
dependent "m="-line depends on.
The "depend"-attribute describes the decoding dependency. The The "depend"-attribute describes the decoding dependency. The
"depend"-attribute MAY be followed by a sequence of identification- "depend"-attribute MAY be followed by a sequence of "dependency-
tag(s) which identify all related media streams. The attribute MAY tag"(s) which identify all related RTP payload types in all related
be used with multicast as well as with unicast transport addresses. "m="-lines. The attribute MAY be used with multicast as well as with
The following types of dependencies are defined: unicast transport addresses. The following types of dependencies are
defined:
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 or multi view stream as one or more Media Partitions of a layered Media Bitstream.
coding (MVC) Media Bitstream. When "lay" is used, all required media When "lay" is used, all required media streams for the Operation
streams for the Operation Point MUST be identified by identification- Point MUST be identified by "identification-tag" and "payload-type-
tag(s) following the "lay" string. 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 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
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 signaled this context. When "mdc" is used, all required media streams for the
within this context. When "mdc" is used, all required media Operation Point MUST be identified by "identification-tag" and
streams for the Operation Point MUST be identified by identification- "payload-type-dependency" following the "mdc" string.
tag(s) following the "lay" string.
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].
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 (only possible with "lay" dependency) or (2) with grouping attribute or (2) with a refusal to the request (e.g., 488
a refusal to the request (e.g., 488 Not acceptable here or 606 Not Not acceptable here or 606 Not acceptable in SIP).
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.
Note: in most cases, this will be the base layer of a layered Media Note: in most cases, this will be the base layer of a layered Media
Bitstream, equally possible are Operation Points containing a set of Bitstream, equally possible are Operation Points containing a set of
enhancement layers as long as all are part of a single media stream. 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 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 establish the session, it SHOULD re-try the request with an offer
including only a single media stream. including only a single media stream.
skipping to change at page 10, line 44 skipping to change at page 11, line 4
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.
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 will be [I-D.ietf-mmusic-sdp-capability-negotiation]. This issue should be
addressed in a second memo. 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 dependency:
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
skipping to change at page 11, line 23 skipping to change at page 11, line 30
m=video 40000 RTP/AVP 94 194 m=video 40000 RTP/AVP 94 194
b=AS:96 b=AS:96
a=framerate:15 a=framerate:15
a=rtpmap:94 H264/90000 a=rtpmap:94 H264/90000
a=rtpmap:194 H264/90000 a=rtpmap:194 H264/90000
a=mid:1 a=mid:1
m=video 40002 RTP/AVP 95 195 m=video 40002 RTP/AVP 95 195
b=AS:64 b=AS:64
a=framerate:15 a=framerate:15
a=rtpmap:95 SVC/90000 a=rtpmap:95 H264-SVC/90000
a=rtpmap:195 SVC/90000 a=rtpmap:195 H264-SVC/90000
a=mid:2 a=mid:2
a=depend:95 lay 1:94,195 lay 1:194 a=depend:95 lay 1:94,194; 195 lay 1:194;
m=video 40004 RTP/AVP 96 196 m=video 40004 RTP/AVP 96 196
b=AS:128 b=AS:128
a=framerate:30 a=framerate:30
a=rtpmap:96 SVC/90000 a=rtpmap:96 H264-SVC/90000
a=rtpmap:196 SVC/90000 a=rtpmap:196 H264-SVC/90000
a=mid:3 a=mid:3
a=depend:96 lay 1:94, 196 lay 1:194 a=depend:96 lay 1:94,194; 196 lay 1:194;
m=video 40004 RTP/SAVP 100 200 m=video 40004 RTP/SAVP 100 200
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 SVC/90000 a=rtpmap:100 H264-SVC/90000
a=rtpmap:200 SVC/90000 a=rtpmap:200 H264-SVC/90000
a=mid:4 a=mid:4
a=depend:100 lay 1:94 3:96,200 lay 1:194, 3:196 a=depend:100 lay 1:94,194 3:96; 200 lay 1:194 3:196;
b.) Example for signaling of multi descriptive coding dependency: b.) Example for signaling of multi descriptive coding dependency:
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 94
a=mid:1 a=mid:1
a=depend:94 mdc 2:95 3:96 a=depend:94 mdc 2:95 3:96;
m=video 40002 RTP/AVP 95 m=video 40002 RTP/AVP 95
a=mid:2 a=mid:2
a=depend:95 mdc 1:94 3:96 a=depend:95 mdc 1:94 3:96;
m=video 40004 RTP/AVP 96 m=video 40004 RTP/AVP 96
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:96 mdc 1:94 2:95;
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 bitstream that does
not form an Operation Point, although the signaling made it believe not form an Operation Point, although the signaling made it believe
it would form a valid Operation Point, with potential fatal it would form a valid Operation Point, with potential fatal
skipping to change at page 12, line 44 skipping to change at page 13, line 9
This document defines the "DDP" semantics to be used with grouping of This document defines the "DDP" semantics to be used with grouping of
media lines in SDP as defined in RFC 3388. The "DDP" semantics 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 defined in this memo are to be registered by the IANA when it is
published in standard track RFCs. published in standard track RFCs.
The attribute "depend" is to be registered by IANA as a new media- The attribute "depend" is to be registered by IANA as a new media-
level attribute. The purpose of this attribute is to express a level attribute. The purpose of this attribute is to express a
dependency, which may exist between "m"-lines of a media session. dependency, which may exist between "m"-lines of a media session.
9. Acknowledgements 9. Open Issues
Funding for the RFC Editor function is currently provided by the - Requirement on media stream: With the new draft, different media
Internet Society. Further, the author Thomas Schierl of Fraunhofer streams can be present in a DDP group, that is different codecs
HHI is sponsored by the European Commission under the contract number may be used within the same DDP group?
FP6-IST-0028097, project ASTRALS. - IANA registration for 'lay' and 'mdc'?
10. References 10. References
10.1. Normative References 10.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.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 5234, January 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-07, (work in draft-ietf-mmusic-sdp-capability-negotiation-08, (work in
progress), October 2008 progress), December 2008
10.2. Informative References 10.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. and T. Schierl, "RTP Payload Format
for SVC Video", draft-ietf-avt-rtp-svc-02 (work in for SVC Video", draft-ietf-avt-rtp-svc-07 (work in
progress), June 2007. progress), February 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
[MVC] Joint Video Team, "Joint Draft 4 of MVC ", available [I-D.wang-avt-rtp-mvc]
from http://ftp3.itu.ch/av-arch/jvt- Wang, Y.-K. and T. Schierl, "RTP Payload Format
site/2007_06_Geneva/JVT-X209.zip, Geneva, for MVC Video", draft-wang-avt-rtp-mvc-00 (work in
Switzerland, June 2007. progress), November 2007.
11. Author's Addresses Appendix A. Changes From Earlier Versions
Thomas Schierl Phone: +49-30-31002-227 A.1 Changes from individual submission
Fraunhofer HHI Email: schierl@hhi.fhg.de
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
signaling"
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.
21-Jun07: Numerous editorial changes and reworked section 6.
11-Nov07: Added Payload Type of media stream in question to
dependency signaling. Note on usage with Cap. Negotiation. Added
multi view coding (MVC) dependency as part of 'lay'-dependency. Added
ref. to MVC activity at ITU-T/MPEG.
A.2 Changes from draft-ietf-mmusic-decoding-dependency-00 to
draft-ietf-mmusic-decoding-dependency-01:
21-Feb08: Enhanced mechanism by multiple "payload-type-dependencies"
for the same "mid". Typically the case, when using different
packetization modes as defined in RFC3984.
25-Feb08: Modification throughout informative part of definition
section
Different codecs may be present within the same DDP group.
Authors' Addresses
Thomas Schierl
Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin D-10587 Berlin
Germany Germany
Stephan Wenger Phone: +1-650-862-7368 Phone: +49-30-31002-227
Nokia Email: stewe@stewe.org Email: schierl@hhi.fhg.de
Stephan Wenger
Nokia
955 Page Mill Road 955 Page Mill Road
Palo Alto, CA, 94304 Palo Alto, CA, 94304
USA USA
12. Intellectual Property Statement Phone: +1-650-862-7368
Email: stewe@stewe.org
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 14, line 31 skipping to change at page 16, line 18
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
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.
13. Disclaimer of Validity Acknowledgements
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.
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
none
16. Change Log:
19Dec06 / TS: Funding for the RFC Editor function is currently provided by the
removed SSRC multiplexing and with that various information about RTP Internet Society.
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
signaling"
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.
21-Jun07: Numerous editorial changes and reworked section 6.
11-Nov07: Added Payload Type of media stream in question to
dependency signaling. Note on usage with Cap. Negotiation. Added
multi view coding (MVC) dependency as part of 'lay'-dependency. Added
ref. to MVC activity at ITU-T/MPEG.
 End of changes. 55 change blocks. 
151 lines changed or deleted 184 lines changed or added

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