Network Working Group T. Schierl Internet-Draft Fraunhofer HHI Intended status: Standards Track S. Wenger Expires:
August 24,November 25, 2008 Nokia FebruaryMay 25, 2008 Signaling media decoding dependency in Session Description Protocol (SDP) draft-ietf-mmusic-decoding-dependency-01draft-ietf-mmusic-decoding-dependency-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 24,November 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and RTP payload type(s).media format description(s). Table of Contents 1. Introduction .................................................. 4 2. Terminology ................................................... 45 3. Definitions ................................................... 5 4. Motivation, Use Cases, and Architecture ....................... 6 4.1. Motivation .................................................. 6 4.2. Use cases ................................................... 78 5. Signaling Media Dependencies .................................. 8 5.1. Design Principles ........................................... 8 5.2. Semantics ................................................... 89 5.2.1. SDP grouping semantics for decoding dependency............. 8dependency ............ 9 5.2.2. Attribute for dependency signaling per media-stream........media-stream ....... 9 6. Usage of new semantics in SDP ................................ 10 6.1. Usage with the SDP Offer/Answer Model ...................... 10 6.2. Declarative usage .......................................... 1011 6.3. Usage with Capability Negotiation .......................... 1011 6.4. Examples ................................................... 1112 7. Security Considerations ...................................... 1213 8. IANA Considerations .......................................... 12Considerations........................................... 14 9. Open Issues .................................................. 13 10.References ................................................... 13 10.1.15 9.1. Normative References ...................................... 13 10.2........................................ 15 9.2. Informative References .................................... 13..................................... 15 Appendix A. Changes From Earlier Versions........................ 14Versions ....................... 16 Authors' Addresses................................................ 15Addresses ............................................... 17 Full Copyright Statement.......................................... 15Statement ......................................... 17 Intellectual Property Statement................................... 15 Acknowledgements.................................................. 16Statement .................................. 17 Acknowledgements ................................................. 18 1. Introduction An SDP session description may contain one or more media descriptions, each identifying a single media stream. A media description is identified by one "m=" line. Today, if more than one "m=" lines exist indicating the same media type, a receiver cannot identify a specific relationship between those media. A Multiple Description Coding (MDC) or layered Media Bitstream contains, by definition, one or more Media Partitions that are conveyed in their own media stream. In Multi View Coding (MVC) [I- D.wang-avt-rtp-mvc] layered dependencies between views are used to increase the coding efficiency.The cases we are interested in are layered and MDC Bitstreams with two or more Media Partitions. Carrying more than one Media Partition in its own session is one of the key use cases for employing layered or MDC coded mediamedia. Senders, network elements, or receivers can suppress sending/forwarding/subscribing/decoding individual Media Partitions and still preserve perhaps suboptimal, but still useful media quality. One property of all Media Bitstreams relevant to this memo is that their Media Partitions have a well-defined usage relationship. For example, in layered coding, "higher" Media Partitions are useless without "lower" ones. In MDC coding, Media Partitions are complementary -- the more Media Partitions one receives, the better a reproduced quality may be. At present, SDP and its supporting infrastructure of RFCsextensions lack the means to express such a usage relationship. Trigger for the present memo has been the standardization process of the RTP payload format for the Scalable Video Coding extension to ITU-T Rec. H.264 / MPEG-4 AVC [I-D.ietf-avt-rtp-svc]. When drafting [I-D.ietf-avt-rtp-svc] ,[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 to all layered or MDC codecs. Therefore, this memo presents a generic solution. Likely, the second technology utilizing the mechanisms of this memo will be Multi-View video coding. In Multi View Coding (MVC) [I-D.wang-avt-rtp-mvc] layered dependencies between views are used to increase the coding efficiency, and, therefore, the properties of MVC with respect to the SDP signaling are comparable to those of SVC. The mechanisms defined herein are media transport protocol dependent, i.e.and applicable toonly in conjunction with the use of RTP [RFC3550] only.[RFC3550]. The SDP grouping of Media Lines of different media types is out of scope of this memo. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions Media stream: As per [RFC4566]. Media Bitstream: A valid, decodable stream, containing all media partitions generated by the encoder. A Media Bitstream normally conforms to a media coding standard. Media Partition: A subset of a Media Bitstream intended for independent transportation. An integer number of Media Partitions forms a Media Bitstream. In layered coding, a Media Partition represents one or more layers that are handled as a unit. In MDC coding, a Media Partition represents one or more descriptions that are handled as a unit. Decoding dependency: The class of relationships media partitions have to each other. At present, this memo defines two decoding dependencies: layeringlayered coding and multiple description.description coding. Layered coding dependency: Each Media Partition is only useful (i.e. can be decoded) when all of the Media Partitions it depends on are available. The dependencies between the Media Partitions therefore create a directed graph. Note: normally, in layered coding, the more Media Partitions are employed (following the rule above), the better a reproduced quality is possible. Multi description coding (MDC) dependency: N of M Media Partitions are required to form a Media Bitstream, but there is no hierarchy between these Media Partitions. Most MDC schemes aim at an increase of reproduced media quality when more media partitions are decoded. Some MDC schemes require more than one Media Partition to form an Operation point. Operation point: In layered coding, a subset of a layered Media Bitstream that includes all Media Partitions required for reconstruction at a certain point of quality, error resilience, or another property, and does not include any other Media Partitions. In MDC coding, a subset of an MDC Media Bitstream that is compliant with the MDC coding standard in question. 4. Motivation, Use Cases, and Architecture 4.1. Motivation This memo is concerned with two types of decoding dependencies: layered,layered and multi-description. The transport of layered and multi description coding share as key motivators the desire for media adaptation to network conditions, i.e.i.e., related to bandwidth, error rates, connectivity of endpoints in multicast or broadcast scenarios, and similar. o Layered decoding dependency: In layered coding, the partitions of a Media Bitstream are known as media layers or simply layers. One or more layers may be transported in different media streams in the sense of [RFC4566]. A classic use case is known as receiver-driven layered multicast, in which a receiver selects a combination of media streams in response to quality or bit-rate requirements. Back in the mid 1990s, the then available layered media formats and codecs envisioned primarily (or even exclusively) a one-dimensional hierarchy of layers. That is, each so-called enhancement layer referred to exactly one layer "below". The single exception has been the base layer, which is self-contained. Therefore, the identification of one enhancement layer fully specifies the operationOperation point of a layered coding scheme, including knowledge about all the other layers that need to be decoded. SDP [RFC4566] contains rudimentary support for exactly this use case and media formats, in that it allows for signaling a range of transport addresses in a certain media description. By definition, a higher transport address identifies a higher layer in the one-dimensionalone- dimensional hierarchy. A receiver needs only to decode data conveyed over this transport address and lower transport addresses to decode this Operation Point. Newer media formats depart from this simple one-dimensional hierarchy, in that highly complex (at least tree-shaped) dependency hierarchies can be implemented. Compelling use cases for these complex hierarchies have been identified by industry. Support for it is therefore desirable. However, SDP, in its current form, does not allow for the signaling of these complex relationships. Therefore, receivers cannot make an informed decision on which layers to subscribe (in case of layered multicast). Layered decoding dependencydependencies may also exitexist in a Multi View Coding environment. Views may be coded using inter-view dependencies to increase coding efficiency. This results in Media Bitstreams, which logically may be separated into Media Partitions representing different views of the reconstructed video signal. These Media Partitions cannot be decoded independently, and, therefore, other Media Partitions are required for reconstruction. To express this relationship, the signaling needs to express the dependencies of the views, which in turn are Media Partitions in the sense of this document. o Multi descriptive decoding dependency: In the most basic form of MDC, each Media Partition forms an independent representation of the media. That is, decoding of any of the Media Partitions yields useful reproduced media data. When more than one Media Partition is available, then a decoder can process them jointly, and the resulting media quality increases. The highest reproduced quality is available if all original Media Partitions are available for decoding. More complex forms of multiple description coding can also be envisioned, i.e. where, as a minimum, N out of M total Media Partitions need to be available to allow meaningful decoding. MDC has not yet been embraced heavily by the media standardization community, though it is subject of a lot of academic research. As an example, we refer to [MDC]. In this memo, we cover MDC because we a) envision that MDC media formats will come into practical use within the lifetime of this memo, and b) the solution for its signaling is very similar to the one of layered coding. o Other decoding dependency relationships: At the time of writing, no decoding dependency relationships beyond the two mentioned above have been identified that would warrant standardization. However, the mechanisms of this memo could be extended by introducing new codepoints for a new decoding dependency types, if a need could be shown. If such an extension were becoming necessary, as formally required in section 5.2.2, the new decoding dependency type MUST be documented in an IETF standard's track document. 4.2. Use cases o Receiver driven layered multicastmulticast: This technology is discussed in [RFC3550] and references therein. We refrain from elaborating further; the subject is well known and understood. o Multiple end-to-end transmission with different propertiesproperties: Assume a unicast and point-to-point topology, wherein one endpoint sends media to another. Assume further that different forms of media transmission are available. The difference may lie in the cost of the transmission (free, charged), in the available protection (unprotected/secure), in the quality of service (guaranteed quality / best effort), or other factors. Layered and MDC coding allow to match the media characteristics to the available transmission path(s). For example, in layered codingcoding, it makes sense to convey the base layer over high QoS. Enhancement layers, on the other hand, can be conveyed over best effort, as they are "optional" in their characteristic -- nice to have, but non- essentialnon-essential for media consumption. In a different scenario, the base layer may be offered in a non-encrypted session as a free preview. An encrypted enhancement layer references this base layer and allows optimal quality play-back; however, it is only accessible to users who have the key, which may have been distributed by a conditional access mechanism. 5. Signaling Media Dependencies 5.1. Design Principles The dependency signaling is only feasible between media descriptions described with an "m="-line and with an assigned media identification attribute ("mid"), as defined in [RFC3388]. All "m=" lines grouped according to this specification MUST have the same media type. 5.2. Semantics 5.2.1. SDP grouping semantics for decoding dependency This specification defines a new grouping semantic Decoding Dependency "DDP": DDP associates a media stream, identified by its mid attribute, with a DDP group. Each media stream MUST be composed of an integer number of Media Partitions. A media stream is identified by a session- unique RTPmedia format description (RTP payload type numbernumber) within a "m="-line. In a DDP group, all media streams MUST have the same type of decoding dependency (as signaled by the attribute defined in 5.2.2). All media streams MUST contain at least one operationOperation point. The DDP group type informs a receiver about the requirement for treatinghandling the media streams of the group according to the new media level attribute "depend", as defined in 5.2.2. When using multiple codecs, e.g. for Offer/Answer model, the media streams MUST have the same dependency structure, regardless which media format description (RTP payload type numbernumber) is used. 5.2.2. Attribute for dependency signaling per media-stream This memo defines a new media-level attribute, "depend", with the following ABNF [RFC4234].[RFC5234]. The "identification-tag"identification-tag is defined in [RFC3388]:[RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used as defined in [RFC4566]. depend-attribute = "a" "=" "depend" ":" ( dependent-payload-type dependency-tag ";" ) *("a=depend:" dependent-fmt SP dependent-payload-typedependency-tag ";" )*(";" SP dependent-fmt SP dependency-tag) CRLF dependency-tag = dependency-type *1( SP identification-tag ":" payload-type-dependency *( "," payload-type-dependency ) )fmt-dependency *("," fmt-dependency )) dependency-type = "lay" / "mdc" "dependent-payload-type",/ token dependent-fmt = fmt fmt-dependency = fmt dependent-fmt, indicates the payload type number,media format description, as defined in [RFC4566], that depends on a "payload-type-dependency" in the "m="-line indicatedone or more media format description in the "m="-line indicated by the value of "identification-tag"identification-tag within the "dependency-tag". "payload-type-dependency",dependency-tag. fmt-dependency, indicates the payload type numbermedia format description in the "m="-line"m="- line identified by the "identification-tag"identification-tag within the "dependency-tag",dependency-tag, which the "dependent-payload-type" numberdependent-fmt of the dependent "m="-line depends on. The "depend"-attributedepend-attribute describes the decoding dependency. The "depend"-attributedepend- attribute MAY be followed by a sequence of "dependency- tag"(s)dependency-tag fields which identify all related RTP payload typesmedia format description in all related "m="-lines. The attribute MAY be used with multicast as well as with unicast transport addresses. The following types of dependenciesdependency-types values are defined:defined in this memo: o lay: Layered decoding dependency -- identifies the described media stream as one or more Media Partitions of a layered Media Bitstream. When "lay" is used, all requiredmedia streams required for decoding the Operation Point MUST be identified by "identification-tag"identification- tag and "payload-type- dependency"fmt-dependency following the "lay" string. o mdc: Multi descriptive coding dependency -- signals that the described media stream is part of a set of a MDC Media Bitstream. By definition, at least N out of M media streams of the group need to be available to from an Operation Point. The values of N and M depend on the properties of the Media Bitstream and are not signaled within this context. When "mdc" is used, all required media streams for the Operation Pointpoint MUST be identified by "identification-tag"identification-tag and "payload-type-dependency"fmt-dependency following the "mdc" string. Further dependency types MUST be defined in a standards-track document. 6. Usage of new semantics in SDP 6.1. Usage with the SDP Offer/Answer Model The backward compatibility in offer / answer is generally handled as specified in [RFC3388].[RFC3388], section 8.4, as summarized below. Depending on the implementation, a node that does not understand DDP grouping (either does not understand line grouping at all, or just does not understand the DDP semantics) SHOULD respond to an offer containing DDP grouping either (1) with an answer that ignores the grouping attribute or (2) with a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP). In the first case, the original sender of the offer MUST respond by offering a single media stream that represents an Operation Point. Note: in most cases, this will be the base layer of a layered Media Bitstream, equally possible are Operation Points containing a set of enhancement layers as long as all are part of a single media stream. In the second case, if the sender of the offer still wishes to establish the session, it SHOULD re-try the request with an offer including only a single media stream. 6.2. Declarative usage If an RTSP receiver understands signaling according to this memo, it SHALL setup all media streams that are required to decode the Operation Point of its choice. If an RTSP receiver does not understand the signaling defined within 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 included in the SDP is within the receiver's capabilities, it selects among those candidates according to implementation specific criteria for setup, as usual. (2) If none of the media type included in the 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 This memo does not cover the interaction with Capability Negotiation [I-D.ietf-mmusic-sdp-capability-negotiation]. This issue shouldis for further study and will be addressed in a different memo. 6.4. Examples a.) Example for signaling layered decoding dependencydependency: The example shows a session description with three "m"-lines, all of type video. Each of the "m"-lines include two possible media format descriptions, in the example: RTP payload types. The first "m"-line includes a H264 payload type as defined by [RFC3984] and the other "m"-lines include H264-SVC payload types. The example shows the dependencies of the RTP payload types of the different "m"-lines indicated by "DDP" grouping, "mid" and "depend" attributes. v=0 o=svcsrv 289083124 289083124 IN IP4 host.example.com s=LAYERED VIDEO SIGNALING Seminar t=0 0 c=IN IP4 192.0.2.1/127 a=group:DDP 1 2 3 4 m=video 40000 RTP/AVP 94 194 b=AS:9696 97 b=AS:90 a=framerate:15 a=rtpmap:94a=rtpmap:96 H264/90000 a=rtpmap: 194a=rtpmap:97 H264/90000 a=mid:1 m=video 40002 RTP/AVP 95 19598 99 b=AS:64 a=framerate:15 a=rtpmap:95a=rtpmap:98 H264-SVC/90000 a=rtpmap:195a=rtpmap:99 H264-SVC/90000 a=mid:2 a=depend:95a=depend:98 lay 1:94,194; 1951:96,97; 99 lay 1:194;1:97 m=video 40004 RTP/AVP 96 196100 101 b=AS:128 a=framerate:30 a=rtpmap:96a=rtpmap:100 H264-SVC/90000 a=rtpmap:196a=rtpmap:101 H264-SVC/90000 a=mid:3 a=depend:96a=depend:100 lay 1:94,194; 1961:96 2:98; 101 lay 1:194;1:97 2:99 m=video 4000440006 RTP/SAVP 100 200102 103 c=IN IP4 192.0.2.2/127 b=AS:512 k=uri:conditional-access-server.example.com a=framerate:30 a=rtpmap:100a=rtpmap:102 H264-SVC/90000 a=rtpmap:200a=rtpmap:103 H264-SVC/90000 a=mid:4 a=depend:100a=depend:102 lay 1:94,194 3:96; 2001:96,97 2:98; 103 lay 1:194 3:196;1:97 2:99 b.) Example for signaling of multi descriptive coding dependency: The example shows a session description with three "m"-lines, all of type video. Each of the "m"-lines includes one media format description, in the example: RTP payload type, with multi descriptive decoding dependency. The example shows the dependencies of the RTP payload types of the different "m"-lines indicated by "DDP" grouping, "mid" and "depend" attributes. v=0 o=mdcsrv 289083124 289083124 IN IP4 host.example.com s=MULTI DESCRIPTION VIDEO SIGNALING Seminar t=0 0 c=IN IP4 192.0.2.1/127 a=group:DDP 1 2 3 m=video 40000 RTP/AVP 94104 a=mid:1 a=depend:94a=depend:104 mdc 2:95 3:96;2:105 3:106 m=video 40002 RTP/AVP 95105 a=mid:2 a=depend:95a=depend:105 mdc 1:94 3:96;1:104 3:106 m=video 40004 RTP/AVP 96106 c=IN IP4 192.0.2.2/127 a=mid:3 a=depend:96a=depend:106 mdc 1:94 2:95;1:104 2:105 7. Security Considerations All security implications of SDP apply. There may be a risk of manipulation the dependency signaling of a session description by an attacker. This may mislead a receiver or middle box, e.g. a receiver may try to compose a media bitstream out of several RTP packet streams that does not form an Operation Point, although the signaling made it believe it would form a valid Operation Point, with potential fatal consequences for the media decoding process. It is recommended that the receiver SHOULD perform an integrity check on SDP and follow the security considerations of SDP to only trust SDP from trusted sources. 8. IANA Considerations This document defines the "DDP" semantics toThe following contact information shall be used with grouping of media lines in SDP as defined in RFC 3388.for all registrations included here: Contact: Thomas Schierl mailto:firstname.lastname@example.org tel:+49-30-31002-227 The "DDP"following semantics defined in this memo are to behave been registered by theIANA when it is publishedin standard track RFCs.Semantics for the "group" SDP Attribute under SDP Parameters http://www.iana.org/assignments/sdp-parameters. Semantics Token Reference ------------------- ----- --------- Decoding Dependency DDP RFC XXXX The SDP media level attribute "depend" is to behas been registered by IANA as a new media-in Semantics for "att-field (media level attribute. The purposeonly)". SDP Attribute ("att-field (media level only)"): Attribute name: depend Long form: decoding dependency Type of this attribute is to express a dependency, which may exist between "m"-linesname: att-field Type of a media session. 9. Open Issues - Requirement onattribute: media stream: With the new draft, different media streams can be present in a DDP group, that is different codecs may be used within the same DDP group? -level only Subject to charset: no Purpose: RFC XXXX Reference: RFC XXXX Values: see this document and registrations below. The following semantics have been registered by IANA registrationin Semantics for 'lay' and 'mdc'? 10.the "depend" SDP Attribute under SDP Parameters: Semantics of the "depend" SDP attribute: Semantics Token Reference ---------------------------- ----- --------- Layered decoding dependency lay RFC XXXX multi descriptive coding dependency mdc RFC XXXX 9. References 10.1.9.1. Normative References [RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [I-D.ietf-mmusic-sdp-capability-negotiation] Andreasen, F., "SDP Capability Negotiation", draft-ietf-mmusic-sdp-capability-negotiation-08, (work in progress), December 2008 10.2.9.2. Informative References [I-D.ietf-avt-rtp-svc] Wenger, S., Wang Y.-K.Y.-K.,T. Schierl and T. Schierl,A. Eleftheriadis, "RTP Payload Format for SVC Video", draft-ietf-avt-rtp-svc-07draft-ietf-avt-rtp-svc-09 (work in progress), FebruaryMay 2008. [MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, "Video over IP using Standard-Compatible Multiple Description Coding: an IETF proposal", Packet Video Workshop, April 2006, Hangzhou, China [I-D.wang-avt-rtp-mvc] Wang, Y.-K. and T. Schierl, "RTP Payload Format for MVC Video", draft-wang-avt-rtp-mvc-00draft-wang-avt-rtp-mvc-01 (work in progress), November 2007.February 2008. [I-D.ietf-mmusic-sdp-capability-negotiation] Andreasen, F., "SDP Capability Negotiation", draft-ietf-mmusic-sdp-capability-negotiation-08, (work in progress), December 2007 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M., and Singer, D., "RTP Payload Format for H.264 Video", RFC 3984, February 2005. Appendix A. Changes From Earlier Versions A.1 Changes from individual submission 19Dec06 / TS: removed SSRC multiplexing and with that various information about RTP draft title correction corrected SDP reference editorial modifications throughout the document added Stephan Wenger to the list of authors removed section "network elements not supporting dependency signaling" 20-28Dec06 / TS, StW: Editorial improvements 3Mar07 / TS: adjustment for new I-D style, added Offer/Answer text, corrected ABNF reference, added Security and IANA considerations, added section Usage with existing entities not supporting new signaling, added text for Declarative usage section, added Open issues section. 21-Jun07: Numerous editorial changes and reworked section 6. 11-Nov07: Added Payload Type of media stream in question to dependency signaling. Note on usage with Cap. Negotiation. Added multi view coding (MVC) dependency as part of 'lay'-dependency. Added ref. to MVC activity at ITU-T/MPEG. A.2 Changes from draft-ietf-mmusic-decoding-dependency-00 to draft-ietf-mmusic-decoding-dependency-01: 21-Feb08: Enhanced mechanism by multiple "payload-type-dependencies" for the same "mid". Typically the case, when using different packetization modes as defined in RFC3984. 25-Feb08: Modification throughout informative part of definition section Different codecs may be present within the same DDP group. A.3 Changes from draft-ietf-mmusic-decoding-dependency-01 to draft-ietf-mmusic-decoding-dependency-02: 19-Mar08: Fixed PT# in example, removed unused references, updated ABNF reference in text, IANA section updates, require std. track doc for new dependencies, editorial changes 23-May08: Replacing payload-type with media format description/fmt, renaming of dependent-payload-type to dependent-fmt, renaming payload-type-dependency to fmt-dependency, editorial changes. Authors' Addresses Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany Phone: +49-30-31002-227 Email: email@example.com Stephan Wenger Nokia 955 Page Mill Road Palo Alto, CA, 94304 USA Phone: +1-650-862-7368 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. Further, the author Thomas Schierl of Fraunhofer HHI is sponsored by the European Commission under the contract number FP7-ICT-214063, project SEA. We want to also thank Magnus Westerlund and Joerg Ott for their valuable and constructive comments to this memo.