draft-ietf-mmusic-decoding-dependency-08.txt   rfc5583.txt 
Network Working Group T. Schierl Network Working Group T. Schierl
Internet-Draft Fraunhofer HHI Request for Comments: 5583 Fraunhofer HHI
Intended status: Standards Track S. Wenger Category: Standards Track S. Wenger
Expires: October 2, 2009 Nokia Independent
April 3, 2009 Signaling Media Decoding Dependency in
the Session Description Protocol (SDP)
Signaling media decoding dependency in Session Description Protocol
(SDP)
draft-ietf-mmusic-decoding-dependency-08
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Abstract
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo defines semantics that allow for signaling the decoding
and may be updated, replaced, or obsoleted by other documents at any dependency of different media descriptions with the same media type
time. It is inappropriate to use Internet-Drafts as reference in the Session Description Protocol (SDP). This is required, for
material or to cite them other than as "work in progress." example, if media data is separated and transported in different
network streams as a result of the use of a layered or multiple
descriptive media coding process.
The list of current Internet-Drafts can be accessed at A new grouping type "DDP" -- decoding dependency -- is defined, to be
http://www.ietf.org/ietf/1id-abstracts.txt. used in conjunction with RFC 3388 entitled "Grouping of Media Lines
in the Session Description Protocol". In addition, an attribute is
specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and media format
description(s).
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 2, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
This memo defines semantics that allow for signaling the decoding 10, 2008. The person(s) controlling the copyright in some of this
dependency of different media descriptions with the same media type in material may not have granted the IETF Trust the right to allow
the Session Description Protocol (SDP). This is required, for example, modifications of such material outside the IETF Standards Process.
if media data is separated and transported in different network streams Without obtaining an adequate license from the person(s) controlling
as a result of the use of a layered or multiple descriptive media coding the copyright in such materials, this document may not be modified
process. outside the IETF Standards Process, and derivative works of it may
A new grouping type "DDP" -- decoding dependency -- is defined, to be not be created outside the IETF Standards Process, except to format
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in it for publication as an RFC or to translate it into languages other
the Session Description Protocol". In addition, an attribute is than English.
specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and media format
description(s).
Table of Contents Table of Contents
1. Introduction .................................................. 4 1. Introduction ....................................................3
2. Terminology ................................................... 5 2. Terminology .....................................................4
3. Definitions ................................................... 5 3. Definitions .....................................................4
4. Motivation, Use Cases, and Architecture ....................... 6 4. Motivation, Use Cases, and Architecture .........................5
4.1. Motivation .................................................. 6 4.1. Motivation .................................................5
4.2. Use cases ................................................... 8 4.2. Use Cases ..................................................7
5. Signaling Media Dependencies .................................. 8 5. Signaling Media Dependencies ....................................7
5.1. Design Principles ........................................... 8 5.1. Design Principles ..........................................7
5.2. Semantics ................................................... 9 5.2. Semantics ..................................................8
5.2.1. SDP grouping semantics for decoding dependency ............ 9 5.2.1. SDP Grouping Semantics for Decoding Dependency ......8
5.2.2. "depend" attribute for dependency signaling per media-stream 5.2.2. "depend" Attribute for Dependency Signaling
................................................................... 9 per Media-Stream ....................................8
6. Usage of new semantics in SDP ................................ 11 6. Usage of New Semantics in SDP ..................................10
6.1. Usage with the SDP Offer/Answer Model ...................... 11 6.1. Usage with the SDP Offer/Answer Model .....................10
6.2. Declarative usage .......................................... 12 6.2. Declarative usage .........................................12
6.3. Usage with AVP and SAVP RTP profiles ....................... 12 6.3. Usage with AVP and SAVP RTP Profiles ......................12
6.4. Usage with Capability Negotiation .......................... 12 6.4. Usage with Capability Negotiation .........................12
6.5. Examples ................................................... 13 6.5. Examples ..................................................12
7. Security Considerations ...................................... 15 7. Security Considerations ........................................15
8. IANA Considerations .......................................... 15 8. IANA Considerations ............................................15
9. Informative note on RFC 3388bis .............................. 16 9. Informative Note on "The SDP (Session Description Protocol)
10. References ................................................... 16 Grouping Framework" ............................................16
10.1. Normative References ....................................... 16 10. References ....................................................16
10.2. Informative References ..................................... 17 10.1. Normative References .....................................16
Appendix A. Acknowledgements .................................... 18 10.2. Informative References ...................................17
Authors' Addresses ............................................... 18 Appendix A. Acknowledgements .....................................18
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. The cases we are interested in conveyed in their own media stream. The cases we are interested in
are layered and MDC Bitstreams with two or more Media Partitions. are layered and MDC Bitstreams with two or more Media Partitions.
Carrying more than one Media Partition in its own session is one of Carrying more than one Media Partition in its own session is one of
the key use cases for employing layered or MDC coded media. Senders, the key use cases for employing layered or MDC-coded media. Senders,
network elements, or receivers can suppress network elements, or receivers can suppress
sending/forwarding/subscribing/decoding individual Media Partitions sending/forwarding/subscribing/decoding individual Media Partitions
and still preserve perhaps suboptimal, but still useful media and still preserve perhaps suboptimal, but still useful, media
quality. quality.
One property of all Media Bitstreams relevant to this memo is that One property of all Media Bitstreams relevant to this memo is that
their Media Partitions have a well-defined usage relationship. For their Media Partitions have a well-defined usage relationship. For
example, in layered coding, "higher" Media Partitions are useless example, in layered coding, "higher" Media Partitions are useless
without "lower" ones. In MDC coding, Media Partitions are without "lower" ones. In MDC coding, Media Partitions are
complementary -- the more Media Partitions one receives, the better a complementary -- the more Media Partitions one receives, the better a
reproduced quality may be. This document defines an SDP extension to reproduced quality may be. This document defines an SDP extension to
indicate such a decoding dependency. indicate such a decoding dependency.
Trigger for the present memo has been the standardization process of The trigger for the present memo has been the standardization process
the RTP payload format for the Scalable Video Coding extension to of the RTP payload format for the Scalable Video Coding (SVC)
ITU-T Rec. H.264 / MPEG-4 AVC [I-D.ietf-avt-rtp-svc]. When drafting extension to ITU-T Rec. H.264 / MPEG-4 AVC [AVT-RTP-SVC]. When
[I-D.ietf-avt-rtp-svc], it was observed that the aforementioned lack drafting [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) [AVT-RTP-MVC], layered dependencies between views
views are used to increase the coding efficiency, and, therefore, the are used to increase the coding efficiency, and, therefore, the
properties of MVC with respect to the SDP signaling are comparable to properties of MVC with respect to the SDP signaling are comparable to
those of SVC. those of SVC.
The mechanisms defined herein are media transport protocol dependent, The mechanisms defined herein are media transport protocol dependent,
and applicable only in conjunction with the use of RTP [RFC3550]. and applicable only in conjunction with the use of RTP [RFC3550].
The SDP grouping of Media Lines of different media types is out of The SDP grouping of Media Lines of different media types is out of
scope of this memo. scope of this memo.
2. Terminology 2. Terminology
skipping to change at page 5, line 18 skipping to change at page 4, line 18
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
Media stream: Media stream:
As per [RFC4566]. As per [RFC4566].
Media Bitstream: Media Bitstream:
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. unit.
Decoding dependency: Decoding dependency:
The class of relationships media partitions have to each other. At The class of relationships Media Partitions have to each other. At
present, this memo defines two decoding dependencies: layered coding present, this memo defines two decoding dependencies: layered coding
and multiple description coding. and Multiple Description Coding.
Layered coding dependency: Layered coding dependency:
Each Media Partition is only useful (i.e. can be decoded) when all of Each Media Partition is only useful (i.e., can be decoded) when all
the Media Partitions it depends on are available. The dependencies of the Media Partitions it depends on are available. The
between the Media Partitions therefore create a directed graph. dependencies between the Media Partitions therefore create a directed
Note: normally, in layered coding, the more Media Partitions are graph. Note: normally, in layered coding, the more Media Partitions
employed (following the rule above), the better a reproduced quality are employed (following the rule above), the better a reproduced
is possible. quality is possible.
Multi description coding (MDC) dependency: Multiple 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 that does not include any other Media Partitions. In MDC coding, a
of an MDC Media Bitstream that is compliant with the MDC coding subset of an MDC Media Bitstream that is compliant with the MDC
standard in question. coding standard in question.
4. Motivation, Use Cases, and Architecture 4. Motivation, Use Cases, and Architecture
4.1. Motivation 4.1. Motivation
This memo is concerned with two types of decoding dependencies: This memo is concerned with two types of decoding dependencies:
layered and multi-description. The transport of layered and multi layered and multi-description. The transport of layered and Multiple
description coding share as key motivators the desire for media Description Coding share as key motivators the desire for media
adaptation to network conditions, i.e., related to bandwidth, error adaptation to network conditions, i.e., related to bandwidth, error
rates, connectivity of endpoints in multicast or broadcast scenarios, rates, connectivity of endpoints in multicast or broadcast scenarios,
and similar. and the like.
o Layered decoding dependency: o Layered decoding dependency:
In layered coding, the partitions of a Media Bitstream are known as In layered coding, the partitions of a Media Bitstream are known
media layers or simply layers. One or more layers may be as media layers or simply layers. One or more layers may be
transported in different media streams in the sense of [RFC4566]. transported in different media streams in the sense of [RFC4566].
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
codecs envisioned primarily (or even exclusively) a one-dimensional and codecs envisioned primarily (or even exclusively) a one-
hierarchy of layers. That is, each so-called enhancement layer dimensional hierarchy of layers. That is, each so-called
referred to exactly one layer "below". The single exception has enhancement layer referred to exactly one layer "below". The
been the base layer, which is self-contained. Therefore, the single exception has been the base layer, which is self-contained.
identification of one enhancement layer fully specifies the Therefore, the identification of one enhancement layer fully
Operation Point of a layered coding scheme, including knowledge specifies the Operation Point of a layered coding scheme,
about all the other layers that need to be decoded. including knowledge 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
a higher transport address identifies a higher layer in the one- definition, a higher transport address identifies a higher layer
dimensional hierarchy. A receiver needs only to decode data in the one-dimensional hierarchy. A receiver needs only to decode
conveyed over this transport address and lower transport addresses data conveyed over this transport address and lower transport
to decode this Operation Point. addresses to decode this Operation Point.
Newer media formats depart from this simple one-dimensional Newer media formats depart from this simple one-dimensional
hierarchy, in that highly complex (at least tree-shaped) dependency hierarchy, in that highly complex (at least tree-shaped)
hierarchies can be implemented. Compelling use cases for these dependency hierarchies can be implemented. Compelling use cases
complex hierarchies have been identified by industry. Support for for these complex hierarchies have been identified by industry.
it is therefore desirable. However, SDP, in its current form, does Support for it is therefore desirable. However, SDP, in its
not allow for the signaling of these complex relationships. current form, does not allow for the signaling of these complex
Therefore, receivers cannot make an informed decision on which relationships. Therefore, receivers cannot make an informed
layers to subscribe (in case of layered multicast). decision on which 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
environment. Views may be coded using inter-view dependencies to Coding environment. Views may be coded using inter-view
increase coding efficiency. This results in Media Bitstreams, dependencies to increase coding efficiency. This results in Media
which logically may be separated into Media Partitions representing Bitstreams, that logically may be separated into Media Partitions
different views of the reconstructed video signal. These Media representing different views of the reconstructed video signal.
Partitions cannot be decoded independently, and, therefore, other These Media Partitions cannot be decoded independently, and,
Media Partitions are required for reconstruction. To express this therefore, other Media Partitions are required for reconstruction.
relationship, the signaling needs to express the dependencies of To express this relationship, the signaling needs to express the
the views which in turn are Media Partitions in the sense of this dependencies of the views, which in turn are Media Partitions in
document. the sense of this document.
o Multi descriptive decoding dependency: o Multiple 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
Partitions are available for decoding. Partitions are available for decoding.
More complex forms of multiple description coding can also be More complex forms of Multiple Description Coding can also be
envisioned, i.e. where, as a minimum, N out of M total Media envisioned, i.e., where, as a minimum, N-out-of-M total Media
Partitions need to be available to allow meaningful decoding. Partitions need to be available to allow meaningful decoding.
MDC has not yet been embraced heavily by the media standardization MDC has not yet been embraced heavily by the media standardization
community, though it is subject of a lot of academic research. As community, though it is the subject of a lot of academic research.
an example, we refer to [MDC]. As an example, we refer to [MDC].
In this memo, we cover MDC because we a) envision that MDC media In this memo, we cover MDC because we a) envision that MDC media
formats will come into practical use within the lifetime of this formats will come into practical use within the lifetime of this
memo, and b) the solution for its signaling is very similar to the memo, and b) the solution for its signaling is very similar to the
one of layered coding. one of layered coding.
o Other decoding dependency relationships: o Other decoding dependency relationships:
At the time of writing, no decoding dependency relationships beyond At the time of writing, no decoding dependency relationships
the two mentioned above have been identified that would warrant beyond the two mentioned above have been identified that would
standardization. However, the mechanisms of this memo could be warrant standardization. However, the mechanisms of this memo
extended by introducing new codepoints for new decoding dependency could be extended by introducing new codepoints for new decoding
types. If such an extension becomes necessary, as formally dependency types. If such an extension becomes necessary, as
required in section 5.2.2, the new decoding dependency type MUST be formally required in Section 5.2.2, the new decoding dependency
documented in an IETF standard's track document. type MUST be documented in an IETF Standards-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:
Assume a unicast and point-to-point topology, wherein one endpoint Assume a unicast and point-to-point topology, wherein one endpoint
sends media to another. Assume further that different forms of sends media to another. Assume further that different forms of
media transmission are available. The difference may lie in the media transmission are available. The difference may lie in the
cost of the transmission (free, charged), in the available cost of the transmission (free, charged), in the available
protection (unprotected/secure), in the quality of service protection (unprotected/secure), in the quality of service (QoS)
(guaranteed quality / best effort), or other factors. (guaranteed quality / best effort), or other factors.
Layered and MDC coding allow to match the media characteristics to Layered and MDC coding allows matching of the media
the available transmission path(s). For example, in layered characteristics to the available transmission path(s). For
coding, it makes sense to convey the base layer over high QoS. example, in layered coding, it makes sense to convey the base
Enhancement layers, on the other hand, can be conveyed over best layer over high QoS. Enhancement layers, on the other hand, can
effort, as they are "optional" in their characteristic -- nice to be conveyed over best effort, as they are "optional" in their
have, but non-essential for media consumption. In a different characteristic -- nice to have, but non-essential for media
scenario, the base layer may be offered in a non-encrypted session consumption. In a different scenario, the base layer may be
as a free preview. An encrypted enhancement layer references this offered in a non-encrypted session as a free preview. An
base layer and allows optimal quality play-back; however, it is encrypted enhancement layer references this base layer and allows
only accessible to users who have the key, which may have been optimal quality play-back; however, it is only accessible to users
distributed by a conditional access mechanism. who have the key, which may have been 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 media descriptions attribute ("mid"), as defined in [RFC3388]. All media descriptions
grouped according to this specification MUST have the same media grouped according to this specification MUST have the same media
type. Other dependencies relations expressed by SDP grouping have to type. Other dependencies relations expressed by SDP grouping have to
be addressed in other specifications. A media description MUST NOT be addressed in other specifications. A media description MUST NOT
be part of more than one group of the grouping type defined in this be part of more than one group of the grouping type defined in this
specification. 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
Decoding Dependency "DDP": 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
media description. In a DDP group, all media streams MUST have the media description. In a DDP group, all media streams MUST have the
same type of decoding dependency (as signaled by the attribute same type of decoding dependency (as signaled by the attribute
defined in 5.2.2). All media streams MUST contain at least one defined in Section 5.2.2). All media streams MUST contain at least
Operation Point. The DDP group type informs a receiver about the one Operation Point. The DDP group type informs a receiver about the
requirement for handling the media streams of the group according to requirement for handling the media streams of the group according to
the new media level attribute "depend", as defined in 5.2.2. . the new media level attribute "depend", as defined in Section 5.2.2.
When using multiple codecs, e.g. for Offer/Answer model, the media When using multiple codecs, e.g., for the Offer/Answer model, the
streams MUST have the same dependency structure, regardless which media streams MUST have the same dependency structure, regardless of
media format description (RTP payload type number) is used. which media format description (RTP payload type number) is used.
5.2.2. "depend" attribute for dependency signaling per media-stream 5.2.2. "depend" 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 [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].
<CODE BEGINS>
Copyright (c) 2009 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
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
dependency-tag = dependency-tag =
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"
skipping to change at page 10, line 4 skipping to change at page 9, line 34
dependency-tag = dependency-tag =
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
<CODE ENDS>
dependency-tag, indicates one or more dependencies of one dependent- dependency-tag indicates one or more dependencies of one dependent-
fmt in the media description. These dependencies are signaled as fmt in the media description. These dependencies are signaled as
fmt-dependency values, which indicate fmt values of other media fmt-dependency values, which indicate fmt values of other media
descriptions. These other media descriptions are identified by their descriptions. These other media descriptions are identified by their
identification-tag values in the depend-attribute. There MUST be identification-tag values in the depend-attribute. There MUST be
exactly one dependency-tag indicated per dependent-fmt. 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 descriptions in
the media description indicated by the value of identification-tag the media description indicated by the value of the identification-
within the dependency-tag. tag within the dependency-tag.
fmt-dependency, indicates the media format description in the media fmt-dependency indicates the media format description in the media
description identified by the identification-tag within the description identified by the identification-tag within the
dependency-tag, which the dependent-fmt of the dependent media dependency-tag, on which the dependent-fmt of the dependent media
description depends on. In case a list of fmt-dependency values is description depends. In case a list of fmt-dependency values is
given, any element of the list is sufficient to satisfy the given, any element of the list is sufficient to satisfy the
dependency, at the choice of the decoding entity. dependency, at the choice of the decoding entity.
The depend-attribute describes the decoding dependency. The depend- The depend-attribute describes the decoding dependency. The depend-
attribute MUST be followed by a sequence of dependent-fmt and the attribute MUST be followed by a sequence of dependent-fmt and the
corresponding dependency-tag fields which identify all related media corresponding dependency-tag fields, which identify all related media
format descriptions in all related media descriptions of the format descriptions in all related media descriptions of the
dependent-fmt. The attribute MAY be used with multicast as well as dependent-fmt. The attribute MAY be used with multicast as well as
with unicast transport addresses. The following dependency-types with unicast transport addresses. The following dependency-type
values are defined in this memo: 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
decoding the Operation Point MUST be identified by identification- for decoding the Operation Point MUST be identified by
tag and fmt-dependency following the "lay" string. identification-tag and fmt-dependency following the "lay"
string.
o mdc: Multi descriptive decoding 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
By definition, at least N out of M media streams of the group need Bitstream. By definition, at least N-out-of-M media streams
to be available to from an Operation Point. The values of N and M of the group need to be available to from an Operation Point.
depend on the properties of the Media Bitstream and are not The values of N and M depend on the properties of the Media
signaled within this context. When "mdc" is used, all required Bitstream and are not signaled within this context. When
media streams for the Operation Point MUST be identified by "mdc" is used, all required media streams for the Operation
identification-tag and fmt-dependency following the "mdc" string. Point MUST be identified by 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 Section 8.4 of [RFC3388], 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 case (1), if the original sender of the offer still wishes to In case (1), if the original sender of the offer still wishes to
establish communications, it SHOULD generate a new offer with a establish communications, it SHOULD generate a new offer with a
single media stream that represents an Operation Point. single media stream that represents an Operation Point. Note: in
Note: in most cases, this will be the base layer of a layered Media most cases, this will be the base layer of a layered Media Bitstream,
Bitstream, equally possible are Operation Points containing a set of equally possible are Operation Points containing a set of enhancement
enhancement layers as long as all are part of a single media stream. layers as long as all are part of a single media stream. In case
In case (2), if the sender of the original offer has identified that (2), if the sender of the original offer has identified that the
the refusal to the request is caused by the use of DDP grouping, and refusal to the request is caused by the use of DDP grouping, and if
if the sender of the offer still wishes to establish the session, it the sender of the offer still wishes to establish the session, it
SHOULD re-try the request with an offer including only a single media SHOULD retry the request with an offer including only a single media
stream. stream.
If the answerer understands the DDP semantics, it is necessary to If the answerer understands the DDP semantics, it is necessary to
take the "depend" attribute into consideration in the offer/answer take the "depend" attribute into consideration in the Offer/Answer
procedure. The main rule for the "depend" attribute is that the procedure. The main rule for the "depend" attribute is that the
offerer decides the number of media streams and the dependency offerer decides the number of media streams and the dependency
between them. The answerer cannot change the dependency relations. between them. The answerer cannot change the dependency relations.
For unicast sessions where the answerer receives media, i.e. for For unicast sessions where the answerer receives media, i.e., for
offers including media streams that have a directionality indicated offers including media streams that have a directionality indicated
by "sendonly", "sendrecv" or have no directionality indicated, the by "sendonly", "sendrecv", or have no directionality indicated, the
answerer MAY remove media operation points. The answerer MUST use the answerer MAY remove media Operation Points. The answerer MUST use
dependency relations provided in the offer when sending media. The the dependency relations provided in the offer when sending media.
answerer MAY send according to all of the operation points present in The answerer MAY send according to all of the Operation Points
the offer, even if the answerer has removed some of those operation present in the offer, even if the answerer has removed some of those
points. Thus an answerer can limit the number of operation points Operation Points. Thus, an answerer can limit the number of
being delivered to the answerer while the answerer can still send Operation Points being delivered to the answerer while the answerer
media to the offerer using all of the operation points indicated in can still send media to the offerer using all of the Operation Points
the offer. indicated in the offer.
For multicast sessions, the answerer MUST accept all operation points For multicast sessions, the answerer MUST accept all Operation Points
and their related decoding dependencies or MUST remove non-accepted and their related decoding dependencies or MUST remove non-accepted
operation points completely. Due to the nature of multicast, the Operation Points completely. Due to the nature of multicast, the
receiver can select which operation points, it actually receives and receiver can select which Operation Points it actually receives and
processes. For multicast sessions that allow the answerer to also processes. For multicast sessions that allow the answerer to also
send data, the answerer MAY send all of the offered operations send data, the answerer MAY send all of the offered Operation Points.
points.
In any case, if the answerer cannot accept one or more offered In any case, if the answerer cannot accept one or more offered
operation points and/or the media stream's dependencies, the answerer Operation Points and/or the media stream's dependencies, the answerer
MAY re-invite with an offer including acceptable operation points MAY re-invite with an offer including acceptable Operation Points
and/or dependencies. and/or dependencies.
Note: Applications may limit the possibilities to perform a re- Note: Applications may limit the possibility of performing a re-
invite. The previous offer is also a good hint to the capabilities of invite. The previous offer is also a good hint to the capabilities
the other agent. of the other agent.
6.2. Declarative usage 6.2. Declarative usage
If an RTSP receiver understands signaling according to this memo, it If a Real Time Streaming Protocol (RTSP) receiver understands
SHALL setup all media streams that are required to decode the signaling according to this memo, it SHALL set up all media streams
Operation Point of its choice. that are required to decode the 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 types 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 AVP and SAVP RTP profiles 6.3. Usage with AVP and SAVP RTP Profiles
The signaling mechanisms defined in this draft MUST NOT be used to The signaling mechanisms defined in this document MUST NOT be used to
negotiate between using AVP [RFC3551] and SAVP [RFC3711] profile for negotiate between using the attribute-value pair (AVP) [RFC3551] and
RTP. But both profiles MAY be used separately or jointly with the SAVP [RFC3711] profile for RTP. However, both profiles MAY be used
signaling mechanism defined in this draft. separately or jointly with the signaling mechanism defined in this
document.
6.4. Usage with Capability Negotiation 6.4. 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 [MMUSIC]. This issue is for further study and will be addressed in a
further study and will be addressed in a different memo. different memo.
6.5. Examples 6.5. Examples
a.) Example for signaling layered decoding dependency: a.) Example for signaling layered decoding dependency:
The example below shows a session description with three media The example below shows a session description with three media
descriptions, all of type video and with layered decoding descriptions, all of type video and with layered decoding
dependency ("lay"). Each of the media description includes two dependency ("lay"). Each of the media descriptions includes two
possible media format descriptions with different encoding possible media format descriptions with different encoding
parameters as, e.g. "packetization-mode" (not shown in the parameters as, e.g., "packetization-mode" (not shown in the
example) for the media subtypes "H264" and "H264-SVC" given by example) for the media subtypes "H264" and "H264-SVC" given by the
the "a=rtpmap:"-line. The first media description includes two "a=rtpmap:"-line. The first media description includes two H264
H264 payload types as media format descriptions, "96" and "97", payload types as media format descriptions, "96" and "97", as
as defined in [RFC3984] and represents the base layer operation defined in [RFC3984] and represents the base layer Operation Point
point (identified by "mid:L1"). The two other media (identified by "mid:L1"). The two other media descriptions
descriptions (identified by "mid:L2" and "mid:L3") include H264- (identified by "mid:L2" and "mid:L3") include H264-SVC payload
SVC payload types as defined in [I-D.ietf-avt-rtp-svc], which types as defined in [AVT-RTP-SVC], which contain enhancements to
contain enhancements to the base layer operation point or the the base layer Operation Point or the first enhancement layer
first enhancement layer operation point (media description Operation Point (media description identified by "mid:L2").
identified by "mid:L2").
Note: The SDP examples in [I-D.ietf-avt-rtp-svc] use numbers for
the mid values instead of using tokens like "L1", "L2" and "L3".
The example shows the dependencies of the media format The example shows the dependencies of the media format
descriptions of the different media descriptions indicated by descriptions of the different media descriptions indicated by
"DDP" grouping, "mid" and "depend" attributes. The "depend" "DDP" grouping, "mid", and "depend" attributes. The "depend"
attribute is used with the decoding dependency type "lay" attribute is used with the decoding dependency type "lay"
indicating layered decoding dependency. For example, the third indicating layered decoding dependency. For example, the third
media description ("m=video 40004...") indentified by "mid:L3" media description ("m=video 40004...") identified by "mid:L3" has
has different dependencies on the media format descriptions of different dependencies on the media format descriptions of the two
the two other media descriptions: other media descriptions: Media format description "100" depends
Media format description "100" depends on media format on media format description "96" or "97" of the media description
description "96" or "97" of the media description indentified by indentified by "mid:L1". This is an exclusive-OR, i.e., payload
"mid:L1". This is an exclusive-OR, i.e. payload type "100" may type "100" may be used with payload type "96" or with "97", but
be used with payload type "96" or with "97", but one of the two one of the two combinations is required for decoding payload type
combinations is required for decoding payload type "100". "100".
For media format description "101", it is different. This one For media format description "101", it is different. This one
depends on two of the other media descriptions at the same time, depends on two of the other media descriptions at the same time,
i.e. it depends on media format description "97" of the media i.e., it depends on media format description "97" of the media
description indentified by "mid:L1" and it also depends on media description indentified by "mid:L1" and it also depends on media
format description "99" of the media description indentified by format description "99" of the media description indentified by
"mid:L2". For decoding media format description "101" both "mid:L2". For decoding media format description "101", both media
media format description "97" and media format description "99" format description "97" and media format description "99" are
are required by definition. 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 L1 L2 L3 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
skipping to change at page 14, line 28 skipping to change at page 14, line 32
a=mid:L2 a=mid:L2
a=depend:98 lay L1:96,97; 99 lay L1: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:L3 a=mid:L3
a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99 a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99
b.) Example for signaling of multi descriptive decoding dependency: b.) Example for signaling of multi-descriptive decoding dependency:
The example shows a session description with three media The example shows a session description with three media
descriptions, all of type video and with multi descriptive descriptions, all of type video and with multi-descriptive
decoding dependency. Each of the media descriptions includes decoding dependency. Each of the media descriptions includes one
one media format description. The example shows the media format description. The example shows the dependencies of
dependencies of the media format descriptions of the different the media format descriptions of the different media descriptions
media descriptions indicated by "DDP" grouping, "mid" and indicated by "DDP" grouping, "mid", and "depend" attributes. The
"depend" attributes. The "depend" attribute is used with the "depend" attribute is used with the decoding dependency type "mdc"
decoding dependency type "mdc" indicating layered decoding indicating layered decoding dependency. For example, media format
dependency. For example, media format description "104" in the description "104" in the media description ("m=video 40000...")
media description ("m=video 40000...") with "mid:M1" depends on with "mid:M1" depends on the two other media descriptions. It
the two other media descriptions. It depends on media format depends on media format description "105" of media description
description "105" of media description with "mid:M2" and also with "mid:M2", and it also depends on media format description
depends on media format description "106" of media description "106" of media description with "mid:M3". In case of the multi-
with "mid:M3". In case of the multi descriptive decoding descriptive decoding dependency, media format description "105"
dependency, media format description "105" and "106" can be used and "106" can be used by definition to enhance the decoding
by definition to enhance the decoding process of media format process of media format description "104", but they are not
description "104", but they are not required for decoding. 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 M1 M2 M3 a=group:DDP M1 M2 M3
m=video 40000 RTP/AVP 104 m=video 40000 RTP/AVP 104
a=mid:M1 a=mid:M1
a=depend:104 mdc M2:105 M3:106 a=depend:104 mdc M2:105 M3:106
skipping to change at page 15, line 23 skipping to change at page 15, line 25
a=mid:M2 a=mid:M2
a=depend:105 mdc M1:104 M3:106 a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106 m=video 40004 RTP/AVP 106
a=mid:M3 a=mid:M3
a=depend:106 mdc M1:104 M2:105 a=depend:106 mdc M1:104 M2: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 of 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
Operation Point, with potential fatal consequences for the media Operation Point, with potential fatal consequences for the media
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:mail@thomas-schierl.de email: ts@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.
Semantics Token Reference Semantics Token Reference
------------------- ----- --------- ------------------- ----- ---------
Decoding Dependency DDP RFC XXXX Decoding Dependency DDP RFC 5583
The SDP media level attribute "depend" has been registered by IANA in The SDP media-level attribute "depend" has been registered by IANA in
Semantics for "att-field (media level only)". The registration Semantics for "att-field (media level only)". The registration
procedure in section 8.2.4 of [RFC4566] applies. procedure in Section 8.2.4 of [RFC4566] applies.
SDP Attribute ("att-field (media level only)"): SDP Attribute ("att-field (media level only)"):
Attribute name: depend Attribute name: depend
Long form: decoding dependency Long form: decoding dependency
Type of name: att-field Type of name: att-field
Type of attribute: media level only Type of attribute: media level only
Subject to charset: no Subject to charset: no
Purpose: RFC XXXX Purpose: RFC 5583
Reference: RFC XXXX Reference: RFC 5583
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 5583
Multi descriptive decoding dependency mdc RFC XXXX Multi-descriptive decoding dependency mdc RFC 5583
New registrations for semantics of the "depend" SDP attribute are New registrations for semantics of the "depend" SDP attribute are
added by the "Specification Required" policy as defined in [RFC5226]. added by the "Specification Required" policy as defined in [RFC5226].
9. Informative note on RFC 3388bis 9. Informative Note on "The SDP (Session Description Protocol)
Grouping Framework"
Currently, there is ongoing work on [I-D.ietf-mmusic-rfc3388bis]. In Currently, there is ongoing work on [RFC3388bis]. In [RFC3388bis],
[I-D.ietf-mmusic-rfc3388bis], the grouping mechanism is extended in a the grouping mechanism is extended in a way that a media description
way that a media description can be part of more than one group of can be part of more than one group of the same grouping type in the
the same grouping type in the same session description. However, same session description. However, media descriptions grouped by
media descriptions grouped by this draft must be at most part of one this document must be at most part of one group of the type "DDP" in
group of the type "DDP" in the same session description. the same session description.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Media Lines in the Session Description Protocol (SDP)", Schulzrinne, "Grouping of Media Lines in the Session
RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[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.
[RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
July 2003. and Video Conferences with Minimal Control", STD 65,
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. RFC 3551, July 2003.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
[RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session K. Norrman, "The Secure Real-time Transport Protocol
Description Protocol", RFC 4566, July 2006. (SRTP)", RFC 3711, March 2004.
[RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP26, RFC5226, May [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
2008 Session Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
5226, May 2008.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-avt-rtp-svc] [AVT-RTP-SVC] Wenger, S., Wang Y.-K., Schierl, T. and A.
Wenger, S., Wang Y.-K., T. Schierl and A. Eleftheriadis, Eleftheriadis, "RTP Payload Format for SVC Video", Work
"RTP Payload Format for SVC Video", in Progress, March 2009.
draft-ietf-avt-rtp-svc-18 (work in progress), March
2009. [RFC3388bis] Camarillo, G "The SDP (Session Description Protocol)
[I-D.ietf-mmusic-rfc3388bis] Grouping Framework", Work in Progress, January 2009.
Camarillo, G "The SDP (Session Description Protocol)
Grouping Framework", [MMUSIC] Andreasen, F., "SDP Capability Negotiation", Work in
draft-ietf-mmusic-rfc3388bis-02 (work in progress), January Progress, May 2009.
2009.
[I-D.ietf-mmusic-sdp-capability-negotiation] [AVT-RTP-MVC] Wang, Y.-K. and T. Schierl, "RTP Payload Format for MVC
Andreasen, F., "SDP Capability Negotiation", Video", Work in Progress, February 2009.
draft-ietf-mmusic-sdp-capability-negotiation-09, (work in
progress), July 2008.
[I-D.wang-avt-rtp-mvc]
Wang, Y.-K. and T. Schierl, "RTP Payload Format
for MVC Video", draft-wang-avt-rtp-mvc-03 (work in
progress), February 2009.
[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.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M.,
and Singer, D., "RTP Payload Format for H.264 Video", RFC [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T.,
3984, February 2005. Westerlund, M., and D. Singer, "RTP Payload Format for
H.264 Video", RFC 3984, February 2005.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Funding for the RFC Editor function is currently provided by the The author Thomas Schierl of Fraunhofer HHI is sponsored by the
Internet Society. Further, the author Thomas Schierl of Fraunhofer European Commission under the contract number FP7-ICT-214063, project
HHI is sponsored by the European Commission under the contract number SEA.
FP7-ICT-214063, project SEA.
We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan
Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and
constructive comments to this memo. constructive comments to this memo.
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: mail@thomas-schierl.de EMail: ts@thomas-schierl.de
Stephan Wenger Stephan Wenger
Nokia 2400 Skyfarm Dr.
955 Page Mill Road Hillsborough, CA 94010
Palo Alto, CA, 94304
USA USA
Phone: +1-650-862-7368 Phone: +1-415-713-5473
Email: stewe@stewe.org EMail: stewe@stewe.org
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
 End of changes. 93 change blocks. 
332 lines changed or deleted 367 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/