draft-ietf-mmusic-decoding-dependency-02.txt   draft-ietf-mmusic-decoding-dependency-03.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: November 25, 2008 Nokia Expires: March 24, 2009 Nokia
May 25, 2008 September 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-02 draft-ietf-mmusic-decoding-dependency-03
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 November 25, 2008. This Internet-Draft will expire on March 24, 2009.
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,
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Terminology ................................................... 5 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 ................................................... 8 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 ................................................... 9 5.2. Semantics ................................................... 9
5.2.1. SDP grouping semantics for decoding dependency ............ 9 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 ................................ 11
6.1. Usage with the SDP Offer/Answer Model ...................... 10 6.1. Usage with the SDP Offer/Answer Model ...................... 11
6.2. Declarative usage .......................................... 11 6.2. Declarative usage .......................................... 11
6.3. Usage with Capability Negotiation .......................... 11 6.3. Usage with Capability Negotiation .......................... 11
6.4. Examples ................................................... 12 6.4. Examples ................................................... 11
7. Security Considerations ...................................... 13 7. Security Considerations ...................................... 14
8. IANA Considerations........................................... 14 8. IANA Considerations .......................................... 14
9. References ................................................... 15 9. Informative note on RFC 3388bis .............................. 15
9.1. Normative References ....................................... 15 10. References ................................................... 15
9.2. Informative References ..................................... 15 10.1. Normative References ....................................... 15
Appendix A. Changes From Earlier Versions ....................... 16 10.2. Informative References ..................................... 15
Authors' Addresses ............................................... 17 Appendix A. Changes From Earlier Versions........................ 16
Full Copyright Statement ......................................... 17 Authors' Addresses................................................ 17
Intellectual Property Statement .................................. 17 Full Copyright Statement.......................................... 18
Acknowledgements ................................................. 18 Intellectual Property Statement................................... 18
Acknowledgements.................................................. 19
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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 extensions lack reproduced quality may be. This document defines an SDP extension to
the means to express such a usage relationship. indicate such a decoding dependency.
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. Likely, the second technology utilizing the generic solution. Likely, the second technology utilizing the
mechanisms of this memo will be Multi-View video coding. In Multi mechanisms of this memo will be Multi-View video coding. In Multi
View Coding (MVC) [I-D.wang-avt-rtp-mvc] layered dependencies between View Coding (MVC) [I-D.wang-avt-rtp-mvc] layered dependencies between
skipping to change at page 5, line 48 skipping to change at page 5, line 48
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:
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. standard in question.
4. Motivation, Use Cases, and Architecture 4. Motivation, Use Cases, and Architecture
4.1. Motivation 4.1. Motivation
skipping to change at page 6, line 39 skipping to change at page 6, line 39
A classic use case is known as receiver-driven layered multicast, A classic use case is known as receiver-driven layered multicast,
in which a receiver selects a combination of media streams in in which a receiver selects a combination of media streams in
response to 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 referred to exactly one layer "below". The single exception has
been 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 identification of one enhancement layer fully specifies the
Operation point of a layered coding scheme, including knowledge Operation Point of a layered coding scheme, including knowledge
about all the other layers that need to be decoded. about all the other layers that need to be decoded.
SDP [RFC4566] contains rudimentary support for exactly this use SDP [RFC4566] contains rudimentary support for exactly this use
case and media formats, in that it allows for signaling a range of case and media formats, in that it allows for signaling a range of
transport addresses in a certain media description. By definition, transport addresses in a certain media description. By definition,
a higher transport address identifies a higher layer in the one- a higher transport address identifies a higher layer in the one-
dimensional hierarchy. A receiver needs only to decode data dimensional hierarchy. A receiver needs only to decode data
conveyed over this transport address and lower transport addresses conveyed over this transport address and lower transport addresses
to decode this Operation Point. to decode this Operation Point.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
layers to subscribe (in case of layered multicast). layers to subscribe (in case of layered multicast).
Layered decoding dependencies may also exist 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, increase coding efficiency. This results in Media Bitstreams,
which 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 relationship, the signaling needs to express the dependencies of
the 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 independent representation of the media. That is, decoding of any
of the Media Partitions yields useful reproduced media data. When of the Media Partitions yields useful reproduced media data. When
more than one Media Partition is available, then a decoder can more than one Media Partition is available, then a decoder can
process them jointly, and the resulting media quality increases. process them jointly, and the resulting media quality increases.
The highest reproduced quality is available if all original Media The highest reproduced quality is available if all original Media
skipping to change at page 8, line 8 skipping to change at page 8, line 8
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: o Other decoding dependency relationships:
At the time of writing, no decoding dependency relationships beyond At the time of writing, no decoding dependency relationships beyond
the two mentioned above have been identified that would warrant the two mentioned above have been identified that would warrant
standardization. However, the mechanisms of this memo could be standardization. However, the mechanisms of this memo could be
extended by introducing new codepoints for a new decoding extended by introducing new codepoints for new decoding dependency
dependency types, if a need could be shown. If such an extension types. If such an extension becomes necessary, as formally
were becoming necessary, as formally required in section 5.2.2, the required in section 5.2.2, the new decoding dependency type MUST be
new decoding dependency type MUST be documented in an IETF documented in an IETF standard's track document.
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. This technology is discussed in [RFC3550] and references therein.
We refrain from elaborating further; the subject is well known and 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:
skipping to change at page 9, line 4 skipping to change at page 8, line 48
base layer and allows optimal quality play-back; however, it is base layer and allows optimal quality play-back; however, it is
only accessible to users who have the key, which may have been only accessible to users who have the key, which may have been
distributed by a conditional 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]. All "m=" lines grouped attribute ("mid"), as defined in [RFC3388]. All media descriptions
according to this specification MUST have the same media type. grouped according to this specification MUST have the same media
type. Other dependencies relations expressed by SDP grouping have to
be addressed in other specifications. A media description MUST NOT
be part of more than one group of the grouping type defined in this
specification.
5.2. Semantics 5.2. 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 media format description (RTP payload type number) within a unique media format description (RTP payload type number) within a
"m="-line. In a DDP group, all media streams MUST have the same type media description. In a DDP group, all media streams MUST have the
of decoding dependency (as signaled by the attribute defined in same type of decoding dependency (as signaled by the attribute
5.2.2). All media streams MUST contain at least one Operation point. defined in 5.2.2). All media streams MUST contain at least one
The DDP group type informs a receiver about the requirement for Operation Point. The DDP group type informs a receiver about the
handling the media streams of the group according to the new media requirement for handling the media streams of the group according to
level attribute "depend", as defined in 5.2.2. the new media 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
media format description (RTP 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 - "depend"
This memo defines a new media-level attribute, "depend", with the This memo defines a new media-level attribute, "depend", with the
following ABNF [RFC5234]. The identification-tag is defined in following ABNF [RFC5234]. The identification-tag is defined in
[RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used [RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used
as defined in [RFC4566]. as defined in [RFC4566].
depend-attribute = depend-attribute =
"a=depend:" dependent-fmt SP dependency-tag "a=depend:" dependent-fmt SP dependency-tag
*(";" SP dependent-fmt SP dependency-tag) CRLF *(";" SP dependent-fmt SP dependency-tag) CRLF
skipping to change at page 10, line 6 skipping to change at page 10, line 6
dependency-type *1( SP identification-tag ":" dependency-type *1( SP identification-tag ":"
fmt-dependency *("," fmt-dependency )) fmt-dependency *("," fmt-dependency ))
dependency-type = "lay" dependency-type = "lay"
/ "mdc" / "mdc"
/ token / token
dependent-fmt = fmt dependent-fmt = fmt
fmt-dependency = fmt fmt-dependency = fmt
dependency-tag, indicates one or more dependencies of one dependent-
fmt in the media description. These dependencies are signaled as
fmt-dependency values, which indicate fmt values of other media
descriptions. These other media descriptions are identified by their
identification-tag values in the depend-attribute. There MUST be
exactly one dependency-tag indicated per dependent-fmt.
dependent-fmt, indicates the media format description, as defined in dependent-fmt, indicates the media format description, as defined in
[RFC4566], that depends on one or more media format description in [RFC4566], that depends on one or more media format description in
the "m="-line indicated by the value of identification-tag within the the media description indicated by the value of identification-tag
dependency-tag. within the dependency-tag.
fmt-dependency, indicates the media format description in the "m="- fmt-dependency, indicates the media format description in the media
line identified by the identification-tag within the dependency-tag, description identified by the identification-tag within the
which the dependent-fmt of the dependent "m="-line depends on. dependency-tag, which the dependent-fmt of the dependent media
description depends on.
The depend-attribute describes the decoding dependency. The depend- The depend-attribute describes the decoding dependency. The depend-
attribute MAY be followed by a sequence of dependency-tag fields attribute MUST be followed by a sequence of dependent-fmt and the
which identify all related media format description in all related corresponding dependency-tag fields which identify all related media
"m="-lines. The attribute MAY be used with multicast as well as with format description in all related media descriptions of the
unicast transport addresses. The following dependency-types values dependent-fmt. The attribute MAY be used with multicast as well as
are defined in this memo: with unicast transport addresses. The following dependency-types
values 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 stream as one or more Media Partitions of a layered Media
Bitstream. When "lay" is used, all media streams required for Bitstream. When "lay" is used, all media streams required for
decoding the Operation Point MUST be identified by identification- decoding the Operation Point MUST be identified by identification-
tag and fmt-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 decoding 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 By definition, at least N out of M media streams of the group need
to be available to from an Operation Point. The values of N and M to be available to from an Operation Point. The values of N and M
depend on the properties of the Media Bitstream and are not depend on the properties of the Media Bitstream and are not
signaled within this context. When "mdc" is used, all required signaled within this context. When "mdc" is used, all required
media streams for the Operation point MUST be identified by media streams for the Operation Point MUST be identified by
identification-tag and fmt-dependency following the "mdc" string. identification-tag and fmt-dependency following the "mdc" string.
Further dependency types MUST be defined in a standards-track Further dependency types MUST be defined in a standards-track
document. 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], section 8.4, as summarized below. 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, if the original sender of the offer still wishes
offering a single media stream that represents an Operation Point. to establish communications, it SHOULD generate a new offer with a
Note: in most cases, this will be the base layer of a layered Media single media stream that represents an Operation Point. Note: in
Bitstream, equally possible are Operation Points containing a set of most cases, this will be the base layer of a layered Media Bitstream,
enhancement layers as long as all are part of a single media stream. equally possible are Operation Points containing a set of enhancement
In the second case, if the sender of the offer still wishes to layers as long as all are part of a single media stream. In the
establish the session, it SHOULD re-try the request with an offer second case, if the sender of the offer still wishes to establish the
including only a single media stream. session, it SHOULD re-try the request with an offer including only a
single media stream.
6.2. Declarative usage 6.2. Declarative usage
If an RTSP receiver understands signaling according to this memo, it If an RTSP receiver understands signaling according to this memo, it
SHALL setup all media streams that are required to decode the SHALL setup all media streams that are required to decode the
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 is for [I-D.ietf-mmusic-sdp-capability-negotiation]. This issue is for
further study and will be 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: a.) Example for signaling layered decoding dependency:
The example shows a session description with three "m"-lines, The example shows a session description with three media
all of type video. Each of the "m"-lines include two possible descriptions, all of type video and with layered decoding
media format descriptions, in the example: RTP payload types. dependency ("lay"). Each of the media description includes two
The first "m"-line includes a H264 payload type as defined by possible media format descriptions with different encoding
[RFC3984] and the other "m"-lines include H264-SVC payload parameters as, e.g. "packetization-mode" for the media subtypes
types. The example shows the dependencies of the RTP payload H264 and H264-SVC given by the "a=rtpmap:"-line (not shown in
types of the different "m"-lines indicated by "DDP" grouping, the example below). The first media description includes two
"mid" and "depend" attributes. H264 payload types, 96 and 97, as defined by [RFC3984] and
represents the base layer operation point. Payload type 96 and
97 may differ, e.g. in the used H264 packetization modes (not
shown in this example). The other media descriptions include
H264-SVC payload types as defined by [I-D.ietf-avt-rtp-svc],
which contain enhancements to other layers. The example shows
the dependencies of the RTP payload types of the different media
descriptions indicated by "DDP" grouping, "mid" and "depend"
attributes. The "depend" attribute is used with the decoding
dependency type "lay" indicating layered decoding dependency.
For example, the third media description ("m=video 40004...")
with "mid:L3" has different dependencies to the media format
descriptions of the two other media descriptions: Media format
description "100" depends on media format description "96" of
the media description indentified by "mid:L1". The media format
description "101" of the media description indentified by
"mid:L3" depends on two of the other media descriptions. This
media format description depends on media format description
"97" of the media description indentified by "mid:L1" and also
depends on media format description "99" of the media
description indentified by "mid:L2". For decoding media format
description "101" both media format description "97" and media
format description "99" are required by definition.
v=0 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 L1 L2 L3
m=video 40000 RTP/AVP 96 97 m=video 40000 RTP/AVP 96 97
b=AS:90 b=AS:90
a=framerate:15 a=framerate:15
a=rtpmap:96 H264/90000 a=rtpmap:96 H264/90000
a=rtpmap:97 H264/90000 a=rtpmap:97 H264/90000
a=mid:1 a=mid:L1
m=video 40002 RTP/AVP 98 99 m=video 40002 RTP/AVP 98 99
b=AS:64 b=AS:64
a=framerate:15 a=framerate:15
a=rtpmap:98 H264-SVC/90000 a=rtpmap:98 H264-SVC/90000
a=rtpmap:99 H264-SVC/90000 a=rtpmap:99 H264-SVC/90000
a=mid:2 a=mid:L2
a=depend:98 lay 1:96,97; 99 lay 1:97 a=depend:98 lay L1:96,97; 99 lay L1:97
m=video 40004 RTP/AVP 100 101 m=video 40004 RTP/AVP 100 101
b=AS:128 b=AS:128
a=framerate:30 a=framerate:30
a=rtpmap:100 H264-SVC/90000 a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264-SVC/90000 a=rtpmap:101 H264-SVC/90000
a=mid:3 a=mid:L3
a=depend:100 lay 1:96 2:98; 101 lay 1:97 2:99 a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99
m=video 40006 RTP/SAVP 102 103
c=IN IP4 192.0.2.2/127
b=AS:512
k=uri:conditional-access-server.example.com
a=framerate:30
a=rtpmap:102 H264-SVC/90000
a=rtpmap:103 H264-SVC/90000
a=mid:4
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 decoding dependency:
The example shows a session description with three "m"-lines, The example shows a session description with three media
all of type video. Each of the "m"-lines includes one media descriptions, all of type video and with multi descriptive
format description, in the example: RTP payload type, with multi decoding dependency. Each of the media descriptions includes
descriptive decoding dependency. The example shows the one media format description. The example shows the
dependencies of the RTP payload types of the different "m"-lines dependencies of the media format descriptions of the different
indicated by "DDP" grouping, "mid" and "depend" attributes. media descriptions indicated by "DDP" grouping, "mid" and
"depend" attributes. The "depend" attribute is used with the
decoding dependency type "mdc" indicating layered decoding
dependency. For example, media format description "104" in the
media description ("m=video 40000...") with "mid:M1" depends on
the two other media descriptions. It depends on media format
description "105" of media description with "mid:M2" and also
depends on media format description "106" of media description
with "mid:M3". In case of the multi descriptive decoding
dependency, media format description "105" and "106" can be used
by definition to enhance the decoding process of media format
description "104", but they are not required for decoding.
v=0 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 M1 M2 M3
m=video 40000 RTP/AVP 104 m=video 40000 RTP/AVP 104
a=mid:1 a=mid:M1
a=depend:104 mdc 2:105 3:106 a=depend:104 mdc M2:105 M3:106
m=video 40002 RTP/AVP 105 m=video 40002 RTP/AVP 105
a=mid:2 a=mid:M2
a=depend:105 mdc 1:104 3:106 a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106 m=video 40004 RTP/AVP 106
c=IN IP4 192.0.2.2/127 a=mid:M3
a=mid:3 a=depend:106 mdc M1:104 M2:105
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 media bitstream out middle box, e.g. a receiver may try to compose a media bitstream out
of several RTP packet streams that does not form an Operation Point, of several RTP packet streams that does not form an Operation Point,
although the signaling made it believe it would form a valid although the signaling made it believe it would form a valid
skipping to change at page 14, line 17 skipping to change at page 14, line 29
decoding process. It is recommended that the receiver SHOULD perform decoding process. It is recommended that the receiver SHOULD perform
an integrity check on SDP and follow the security considerations of an integrity check on SDP and follow the security considerations of
SDP to only trust SDP from trusted sources. SDP to only trust SDP from trusted sources.
8. IANA Considerations 8. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
included here: included here:
Contact: Thomas Schierl Contact: Thomas Schierl
mailto:schierl@hhi.fhg.de mailto:mail@thomas-schierl.de
tel:+49-30-31002-227 tel:+49-30-31002-227
The following semantics have been registered by IANA in Semantics for The following semantics have been registered by IANA in Semantics for
the "group" SDP Attribute under SDP Parameters the "group" SDP Attribute under SDP Parameters
http://www.iana.org/assignments/sdp-parameters. http://www.iana.org/assignments/sdp-parameters.
Semantics Token Reference Semantics Token Reference
------------------- ----- --------- ------------------- ----- ---------
Decoding Dependency DDP RFC XXXX Decoding Dependency DDP RFC XXXX
skipping to change at page 15, line 8 skipping to change at page 15, line 18
Values: see this document and registrations below. Values: see this document and registrations below.
The following semantics have been registered by IANA in Semantics for The following semantics have been registered by IANA in Semantics for
the "depend" SDP Attribute under SDP Parameters: the "depend" SDP Attribute under SDP Parameters:
Semantics of the "depend" SDP attribute: Semantics of the "depend" SDP attribute:
Semantics Token Reference Semantics Token Reference
---------------------------- ----- --------- ---------------------------- ----- ---------
Layered decoding dependency lay RFC XXXX Layered decoding dependency lay RFC XXXX
multi descriptive coding dependency mdc RFC XXXX Multi descriptive decoding dependency mdc RFC XXXX
9. References 9. Informative note on RFC 3388bis
9.1. Normative References Currently, there is ongoing work on [I-D.ietf-mmusic-rfc3388bis]. In
[I-D.ietf-mmusic-rfc3388bis], the grouping mechanism is extended in a
way that a media description can be part of more than one group of
the same grouping type in the same session description. However,
media descriptions grouped by this draft must be at most part of one
group of the type "DDP" in the same session description.
[RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session 10. References
Description Protocol", RFC 4566, July 2006.
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of [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
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.
[RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
9.2. Informative References 10.2. Informative References
[I-D.ietf-avt-rtp-svc] [I-D.ietf-avt-rtp-svc]
Wenger, S., Wang Y.-K.,T. Schierl and A. Eleftheriadis, Wenger, S., Wang Y.-K.,T. Schierl and A. Eleftheriadis,
"RTP Payload Format for SVC Video", "RTP Payload Format for SVC Video",
draft-ietf-avt-rtp-svc-09 (work in progress), May 2008. draft-ietf-avt-rtp-svc-13 (work in progress), July 2008.
[I-D.ietf-mmusic-rfc3388bis]
Camarillo, G "The SDP (Session Description Protocol)
Grouping Framework",
Draft-ietf-mmusic-rfc3388bis-01 (work in progress), July
2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-09, (work in
progress), July 2009.
[I-D.wang-avt-rtp-mvc]
Wang, Y.-K. and T. Schierl, "RTP Payload Format
for MVC Video", draft-wang-avt-rtp-mvc-02 (work in
progress), August 2008.
[MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, [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]
Wang, Y.-K. and T. Schierl, "RTP Payload Format
for MVC Video", draft-wang-avt-rtp-mvc-01 (work in
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., [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M.,
and Singer, D., "RTP Payload Format for H.264 Video", RFC and Singer, D., "RTP Payload Format for H.264 Video", RFC
3984, February 2005. 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
skipping to change at page 17, line 5 skipping to change at page 17, line 30
A.3 Changes from draft-ietf-mmusic-decoding-dependency-01 to A.3 Changes from draft-ietf-mmusic-decoding-dependency-01 to
draft-ietf-mmusic-decoding-dependency-02: draft-ietf-mmusic-decoding-dependency-02:
19-Mar08: Fixed PT# in example, removed unused references, updated 19-Mar08: Fixed PT# in example, removed unused references, updated
ABNF reference in text, IANA section updates, require std. track doc ABNF reference in text, IANA section updates, require std. track doc
for new dependencies, editorial changes for new dependencies, editorial changes
23-May08: Replacing payload-type with media format description/fmt, 23-May08: Replacing payload-type with media format description/fmt,
renaming of dependent-payload-type to dependent-fmt, renaming renaming of dependent-payload-type to dependent-fmt, renaming
payload-type-dependency to fmt-dependency, editorial changes. payload-type-dependency to fmt-dependency, editorial changes.
A.4 Changes from draft-ietf-mmusic-decoding-dependency-02 to
draft-ietf-mmusic-decoding-dependency-03:
09-July08: Incorporated comments from Ali, Dan and Jean-Francois sent
to the mailing list on June 23rd, June 24th and July 4th
respectively.
15-August08: Constraint for media description to be part of not more
than one DDP group. Informative note on RFC3388bis.
10-September08: Added text on dependency-tag to section 5.2.2. In
5.2.2, "depend:" attribute MUST be followed by sequence of
identifications-tags + dependency-tags (before it was MAY). Text on
example a) in 6.4 improved.
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: mail@thomas-schierl.de
Stephan Wenger Stephan Wenger
Nokia Nokia
955 Page Mill Road 955 Page Mill Road
Palo Alto, CA, 94304 Palo Alto, CA, 94304
USA USA
Phone: +1-650-862-7368 Phone: +1-650-862-7368
Email: stewe@stewe.org Email: stewe@stewe.org
skipping to change at page 18, line 24 skipping to change at page 19, line 19
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. Further, the author Thomas Schierl of Fraunhofer Internet Society. Further, the author Thomas Schierl of Fraunhofer
HHI is sponsored by the European Commission under the contract number HHI is sponsored by the European Commission under the contract number
FP7-ICT-214063, project SEA. We want to also thank Magnus Westerlund FP7-ICT-214063, project SEA.
and Joerg Ott for their valuable and constructive comments to this We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan
memo. Wing, and Jean-Francois Mule for their valuable and constructive
comments to this memo.
 End of changes. 49 change blocks. 
136 lines changed or deleted 180 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/