Network Working Group T. Schierl
Request for Comments: 5583 Fraunhofer HHI
Category: Standards Track S. Wenger
Independent
July 2009
Network Working Group T. Schierl
Request for Comments: 5583 Fraunhofer HHI
Category: Standards Track S. Wenger
Independent
July 2009
Signaling Media Decoding Dependency in the Session Description Protocol (SDP)
会话描述协议（SDP）中的信令媒体解码依赖性
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.
此备忘录定义了语义，允许在会话描述协议（SDP）中用信号表示具有相同媒体类型的不同媒体描述的解码依赖性。例如，如果由于使用分层或多描述媒体编码过程而在不同的网络流中分离和传输媒体数据，则这是必需的。
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 media format description(s).
定义了一种新的分组类型“DDP”——解码依赖关系，将与名为“会话描述协议中的媒体线分组”的RFC3388结合使用。此外，指定描述由媒体标识属性和媒体格式描述指示的“DDP”组中的媒体流的关系的属性。
Status of This Memo
关于下段备忘
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。本协议某些部分的版权控制人
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.
材料可能未授予IETF信托允许在IETF标准过程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Motivation, Use Cases, and Architecture .........................5
4.1. Motivation .................................................5
4.2. Use Cases ..................................................7
5. Signaling Media Dependencies ....................................7
5.1. Design Principles ..........................................7
5.2. Semantics ..................................................8
5.2.1. SDP Grouping Semantics for Decoding Dependency ......8
5.2.2. "depend" Attribute for Dependency Signaling
per Media-Stream ....................................8
6. Usage of New Semantics in SDP ..................................10
6.1. Usage with the SDP Offer/Answer Model .....................10
6.2. Declarative usage .........................................12
6.3. Usage with AVP and SAVP RTP Profiles ......................12
6.4. Usage with Capability Negotiation .........................12
6.5. Examples ..................................................12
7. Security Considerations ........................................15
8. IANA Considerations ............................................15
9. Informative Note on "The SDP (Session Description Protocol)
Grouping Framework" ............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. Acknowledgements .....................................18
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Motivation, Use Cases, and Architecture .........................5
4.1. Motivation .................................................5
4.2. Use Cases ..................................................7
5. Signaling Media Dependencies ....................................7
5.1. Design Principles ..........................................7
5.2. Semantics ..................................................8
5.2.1. SDP Grouping Semantics for Decoding Dependency ......8
5.2.2. "depend" Attribute for Dependency Signaling
per Media-Stream ....................................8
6. Usage of New Semantics in SDP ..................................10
6.1. Usage with the SDP Offer/Answer Model .....................10
6.2. Declarative usage .........................................12
6.3. Usage with AVP and SAVP RTP Profiles ......................12
6.4. Usage with Capability Negotiation .........................12
6.5. Examples ..................................................12
7. Security Considerations ........................................15
8. IANA Considerations ............................................15
9. Informative Note on "The SDP (Session Description Protocol)
Grouping Framework" ............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. Acknowledgements .....................................18
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.
SDP会话描述可以包含一个或多个媒体描述，每个描述标识单个媒体流。介质描述由一行“m=”标识。今天，如果存在多个“m=”行表示相同的媒体类型，则接收者无法识别这些媒体之间的特定关系。
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. 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 media. Senders, network elements, or receivers can suppress sending/forwarding/subscribing/decoding individual Media Partitions and still preserve perhaps suboptimal, but still useful, media quality.
根据定义，多描述编码（MDC）或分层媒体比特流包含在其自己的媒体流中传送的一个或多个媒体分区。我们感兴趣的是具有两个或多个媒体分区的分层和MDC比特流。在自己的会话中承载多个媒体分区是采用分层或MDC编码媒体的关键用例之一。发送方、网络元件或接收方可以抑制发送/转发/订阅/解码单个媒体分区，并且仍然保持可能次优但仍然有用的媒体质量。
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. This document defines an SDP extension to indicate such a decoding dependency.
与此备忘录相关的所有媒体比特流的一个特性是，它们的媒体分区具有定义良好的使用关系。例如，在分层编码中，如果没有“较低”的介质分区，“较高”的介质分区是无用的。在MDC编码中，媒体分区是互补的——接收到的媒体分区越多，复制质量可能越好。本文档定义了一个SDP扩展以指示这种解码依赖性。
The trigger for the present memo has been the standardization process of the RTP payload format for the Scalable Video Coding (SVC) extension to ITU-T Rec. H.264 / MPEG-4 AVC [AVT-RTP-SVC]. When drafting [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) [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.
本备忘录的触发因素是ITU-T Rec.H.264/MPEG-4 AVC[AVT-RTP-SVC]可伸缩视频编码（SVC）扩展的RTP有效载荷格式的标准化过程。在起草[AVT-RTP-SVC]时，观察到上述信令支持方面的不足不是SVC特有的，而是适用于所有分层或MDC编解码器。因此，本备忘录提供了一个通用解决方案。很可能，利用本备忘录机制的第二种技术将是多视图视频编码。在多视图编码（MVC）[AVT-RTP-MVC]中，视图之间的分层依赖关系用于提高编码效率，因此，MVC关于SDP信令的特性与SVC的特性相当。
The mechanisms defined herein are media transport protocol dependent, and applicable only in conjunction with the use of RTP [RFC3550].
本文定义的机制依赖于媒体传输协议，并且仅适用于RTP[RFC3550]的使用。
The SDP grouping of Media Lines of different media types is out of scope of this memo.
不同媒体类型的媒体行的SDP分组不在本备忘录的范围内。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Media stream: As per [RFC4566].
媒体流：根据[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.
媒体分区：用于独立传输的媒体比特流的子集。整数个媒体分区形成一个媒体比特流。在分层编码中，媒体分区表示作为一个单元处理的一个或多个层。在MDC编码中，媒体分区表示作为一个单元处理的一个或多个描述。
Decoding dependency: The class of relationships Media Partitions have to each other. At present, this memo defines two decoding dependencies: layered coding and Multiple 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.
分层编码依赖关系：每个媒体分区只有在它所依赖的所有媒体分区都可用时才有用（即可以解码）。因此，媒体分区之间的依赖关系创建了一个有向图。注：通常，在分层编码中，使用的媒体分区越多（遵循上述规则），再现质量可能越好。
Multiple 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.
多描述编码（MDC）依赖关系：形成媒体比特流需要N个或M个媒体分区，但这些媒体分区之间没有层次结构。大多数MDC方案的目标是在解码更多媒体分区时提高再现的媒体质量。某些MDC方案需要多个介质分区才能形成一个操作点。
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 that 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.
某些质量点、错误恢复能力或其他属性，不包括任何其他媒体分区。在MDC编码技术中，MDC媒体比特流的一个子集，它符合所讨论的MDC编码标准。
This memo is concerned with two types of decoding dependencies: layered and multi-description. The transport of layered and Multiple Description Coding share as key motivators the desire for media adaptation to network conditions, i.e., related to bandwidth, error rates, connectivity of endpoints in multicast or broadcast scenarios, and the like.
本备忘录涉及两种类型的解码依赖：分层和多描述。分层和多描述编码共享的传输是媒体适应网络条件（即，与多播或广播场景中的带宽、错误率、端点连接等相关）的愿望的关键激励因素。
o Layered decoding dependency:
o 分层解码相关性：
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.
在分层编码中，媒体比特流的分区称为媒体层或简单的层。一个或多个层可以在[RFC4566]意义上的不同媒体流中传输。一个典型的用例称为接收器驱动的分层多播，其中接收器根据质量或比特率要求选择媒体流的组合。
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 Operation Point of a layered coding scheme, including knowledge about all the other layers that need to be decoded.
早在20世纪90年代中期，当时可用的分层媒体格式和编解码器主要（甚至完全）设想了一种一维层次结构。也就是说，每个所谓的增强层仅指“下面”的一个层。唯一的例外是自包含的基础层。因此，一个增强层的识别完全指定分层编码方案的操作点，包括关于需要解码的所有其他层的知识。
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-dimensional hierarchy. A receiver needs only to decode data conveyed over this transport address and lower transport addresses to decode this Operation Point.
SDP[RFC4566]包含对这种用例和媒体格式的基本支持，因为它允许在特定媒体描述中发送一系列传输地址的信号。根据定义，较高的传输地址标识一维层次结构中的较高层。接收器只需解码通过此传输地址和较低传输地址传输的数据即可解码此操作点。
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
较新的媒体格式与这种简单的一维层次结构不同，因为可以实现高度复杂（至少是树形）的依赖层次结构。行业已经确定了这些复杂层次结构的引人注目的用例。因此，支持它是可取的。然而，SDP在其
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 dependencies may also exist in a Multi-View Coding environment. Views may be coded using inter-view dependencies to increase coding efficiency. This results in Media Bitstreams, that 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 Multiple descriptive decoding dependency:
o 多描述解码相关性：
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.
在MDC最基本的形式中，每个媒体分区形成媒体的独立表示。也就是说，对任何媒体分区的解码产生有用的再现媒体数据。当有多个媒体分区可用时，解码器可以联合处理它们，从而提高媒体质量。如果所有原始媒体分区都可用于解码，则可获得最高的复制质量。
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.
还可以设想更复杂形式的多描述编码，即，其中至少需要M个总媒体分区中的N个可用，以允许有意义的解码。
MDC has not yet been embraced heavily by the media standardization community, though it is the subject of a lot of academic research. As an example, we refer to [MDC].
MDC还没有被媒体标准化社区广泛接受，尽管它是许多学术研究的主题。例如，我们参考[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.
在本备忘录中，我们讨论了MDC，因为我们a）设想MDC媒体格式将在本备忘录的有效期内投入实际使用，b）其信令解决方案与分层编码的解决方案非常相似。
o Other decoding dependency relationships:
o 其他解码依赖关系：
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 new decoding dependency types. If such an extension becomes necessary, as formally required in Section 5.2.2, the new decoding dependency type MUST be documented in an IETF Standards-Track document.
在撰写本文时，除了上述两种解码依赖关系之外，还没有发现任何需要标准化的解码依赖关系。然而，可以通过为新的解码依赖类型引入新的代码点来扩展此备忘录的机制。如有必要，如第5.2.2节正式要求的那样，必须在IETF标准跟踪文件中记录新的解码依赖类型。
o Receiver-driven layered multicast:
o 接收器驱动的分层多播：
This technology is discussed in [RFC3550] and references therein. We refrain from elaborating further; the subject is well known and understood.
[RFC3550]及其参考文献中讨论了该技术。我们避免进一步阐述；这个主题是众所周知的，也被理解的。
o Multiple end-to-end transmission with different properties:
o 具有不同属性的多个端到端传输：
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 (QoS) (guaranteed quality / best effort), or other factors.
假设采用单播和点对点拓扑，其中一个端点向另一个端点发送媒体。进一步假设不同形式的媒体传输可用。差异可能在于传输成本（免费、收费）、可用保护（无保护/安全）、服务质量（QoS）（保证质量/尽力而为）或其他因素。
Layered and MDC coding allows matching of the media characteristics to the available transmission path(s). For example, in layered coding, 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-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.
分层和MDC编码允许媒体特性与可用传输路径匹配。例如，在分层编码中，在高QoS上传输基本层是有意义的。另一方面，增强层可以尽最大努力传达，因为它们的特性是“可选的”——很好，但对于媒体消费来说不是必需的。在不同的场景中，可以在非加密会话中提供基本层作为免费预览。加密的增强层引用此基础层并允许最佳质量的回放；但是，只有拥有密钥的用户才能访问它，密钥可能是通过条件接收机制分发的。
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 media descriptions grouped according to this specification MUST have the same media type. Other dependencies relations expressed by SDP grouping have to be addressed in other specifications. A media description MUST NOT be part of more than one group of the grouping type defined in this specification.
相关性信令仅在用“m=”行描述的媒体描述和分配的媒体标识属性（“mid”）之间可行，如[RFC3388]中所定义。根据本规范分组的所有介质描述必须具有相同的介质类型。SDP分组表示的其他依赖关系必须在其他规范中解决。媒体描述不能是本规范中定义的分组类型的多个组的一部分。
This specification defines a new grouping semantic Decoding Dependency "DDP":
本规范定义了一个新的分组语义解码依赖项“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 media format description (RTP payload type number) within a media description. In a DDP group, all media streams MUST have the same type of decoding dependency (as signaled by the attribute defined in Section 5.2.2). All media streams MUST contain at least one Operation Point. The DDP group type informs a receiver about the requirement for handling the media streams of the group according to the new media level attribute "depend", as defined in Section 5.2.2.
DDP将由mid属性标识的媒体流与DDP组相关联。每个媒体流必须由整数个媒体分区组成。媒体流由媒体描述中的会话唯一媒体格式描述（RTP有效负载类型编号）标识。在DDP组中，所有媒体流必须具有相同类型的解码相关性（如第5.2.2节中定义的属性所示）。所有媒体流必须至少包含一个操作点。DDP组类型根据第5.2.2节中定义的新媒体级属性“依赖”，通知接收方处理组媒体流的要求。
When using multiple codecs, e.g., for the Offer/Answer model, the media streams MUST have the same dependency structure, regardless of which media format description (RTP payload type number) is used.
当使用多个编解码器时，例如对于提供/应答模型，媒体流必须具有相同的依赖结构，而不管使用哪种媒体格式描述（RTP有效负载类型编号）。
This memo defines a new media-level attribute, "depend", with the following ABNF [RFC5234]. The identification-tag is defined in [RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used as defined in [RFC4566].
此备忘录定义了一个新的媒体级属性“depend”，带有以下ABNF[RFC5234]。识别标签在[RFC3388]中定义。在以下ABNF、fmt、令牌、SP和CRLF中，按照[RFC4566]中的定义使用。
<CODE BEGINS> Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
<CODE BEGINS>版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
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.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
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 =
"a=depend:" dependent-fmt SP dependency-tag
*(";" SP dependent-fmt SP dependency-tag) CRLF
depend-attribute =
"a=depend:" dependent-fmt SP dependency-tag
*(";" SP dependent-fmt SP dependency-tag) CRLF
dependency-tag =
dependency-type *1( SP identification-tag ":"
fmt-dependency *("," fmt-dependency ))
dependency-tag =
dependency-type *1( SP identification-tag ":"
fmt-dependency *("," fmt-dependency ))
dependency-type = "lay" / "mdc" / token
依赖项类型=“lay”/“mdc”/token
dependent-fmt = fmt
dependent-fmt = fmt
fmt-dependency = fmt <CODE ENDS>
fmt相关性=fmt<代码结束>
dependency-tag indicates one or more dependencies of one dependent-fmt in the media description. These dependencies are signaled as fmt-dependency values, which indicate fmt values of other media descriptions. These other media descriptions are identified by their identification-tag values in the depend-attribute. There MUST be exactly one dependency-tag indicated per dependent-fmt.
dependency tag表示媒体描述中一个相关fmt的一个或多个依赖项。这些相关性被标记为fmt相关性值，表示其他媒体描述的fmt值。这些其他媒体描述由其在Dependen属性中的标识标签值标识。每个从属fmt必须只指示一个从属标记。
dependent-fmt indicates the media format description, as defined in [RFC4566], that depends on one or more media format descriptions in the media description indicated by the value of the identification-tag within the dependency-tag.
dependent fmt表示[RFC4566]中定义的媒体格式描述，该描述取决于媒体描述中的一个或多个媒体格式描述，该描述由dependent标签中标识标签的值表示。
fmt-dependency indicates the media format description in the media description identified by the identification-tag within the dependency-tag, on which the dependent-fmt of the dependent media
fmt dependency表示媒体描述中的媒体格式描述，该描述由dependency标记中的标识标记标识，从属媒体的从属fmt依赖于该标识
description depends. In case a list of fmt-dependency values is given, any element of the list is sufficient to satisfy the dependency, at the choice of the decoding entity.
描述视情况而定。在给出fmt依赖值的列表的情况下，列表的任何元素都足以满足解码实体选择的依赖性。
The depend-attribute describes the decoding dependency. The depend-attribute MUST be followed by a sequence of dependent-fmt and the corresponding dependency-tag fields, which identify all related media format descriptions in all related media descriptions of the dependent-fmt. The attribute MAY be used with multicast as well as with unicast transport addresses. The following dependency-type values are defined in this memo:
dependen属性描述解码依赖关系。dependent属性后面必须跟一系列dependent fmt和相应的dependent tag字段，这些字段标识dependent fmt的所有相关媒体描述中的所有相关媒体格式描述。该属性可用于多播以及单播传输地址。此备忘录中定义了以下依赖项类型值：
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 media streams required for decoding the Operation Point MUST be identified by identification-tag and fmt-dependency following the "lay" string.
o lay：分层解码依赖项——将所描述的媒体流标识为分层媒体比特流的一个或多个媒体分区。当使用“lay”时，解码操作点所需的所有媒体流必须通过“lay”字符串后面的标识标签和fmt相关性进行标识。
o mdc: Multi-descriptive decoding 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 Point MUST be identified by identification-tag and fmt-dependency following the "mdc" string.
o mdc：多描述解码相关性——表示所描述的媒体流是mdc媒体比特流集合的一部分。根据定义，组的至少N个媒体流需要从操作点可用。N和M的值取决于媒体比特流的属性，并且在此上下文中不发送信号。使用“mdc”时，必须通过标识标签和“mdc”字符串后面的fmt依赖项来标识操作点所需的所有媒体流。
Further, dependency types MUST be defined in a Standards-Track document.
此外，必须在标准跟踪文档中定义依赖项类型。
The backward compatibility in Offer/Answer is generally handled as specified in Section 8.4 of [RFC3388], as summarized below.
报价/应答中的向后兼容性通常按照[RFC3388]第8.4节的规定处理，总结如下。
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).
根据实现的不同，不理解DDP分组（或者根本不理解行分组，或者只是不理解DDP语义）的节点应该响应包含DDP分组的提议（1）回答忽略分组属性，或者（2）拒绝请求（例如，此处不接受488或SIP中不接受606）。
In case (1), if the original sender of the offer still wishes to establish communications, it SHOULD generate a new offer with 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 case (2), if the sender of the original offer has identified that the refusal to the request is caused by the use of DDP grouping, and if the sender of the offer still wishes to establish the session, it SHOULD retry the request with an offer including only a single media stream.
在情况（1）中，如果要约的原始发送者仍希望建立通信，则其应使用表示操作点的单个媒体流生成新要约。注意：在大多数情况下，这将是分层媒体比特流的基本层，同样可能是包含一组增强层的操作点，只要它们都是单个媒体流的一部分。在情况（2）中，如果原始要约的发送方已确定拒绝请求是由于使用DDP分组造成的，并且如果要约的发送方仍希望建立会话，则其应使用仅包括单个媒体流的要约重试请求。
If the answerer understands the DDP semantics, it is necessary to take the "depend" attribute into consideration in the Offer/Answer procedure. The main rule for the "depend" attribute is that the offerer decides the number of media streams and the dependency between them. The answerer cannot change the dependency relations.
如果应答者理解DDP语义，则有必要在提供/应答过程中考虑“depend”属性。“depend”属性的主要规则是，提供方决定媒体流的数量以及它们之间的依赖关系。回答者不能改变依赖关系。
For unicast sessions where the answerer receives media, i.e., for offers including media streams that have a directionality indicated by "sendonly", "sendrecv", or have no directionality indicated, the answerer MAY remove media Operation Points. The answerer MUST use the dependency relations provided in the offer when sending media. The answerer MAY send according to all of the Operation Points present in the offer, even if the answerer has removed some of those Operation Points. Thus, an answerer can limit the number of Operation Points being delivered to the answerer while the answerer can still send media to the offerer using all of the Operation Points indicated in the offer.
对于应答者接收媒体的单播会话，即对于包括具有由“sendonly”、“sendrecv”指示的方向性或没有指示的方向性的媒体流的要约，应答者可以移除媒体操作点。应答者在发送媒体时必须使用报价中提供的依赖关系。应答者可根据报价中的所有操作点发送，即使应答者已删除其中一些操作点。因此，应答者可以限制发送给应答者的操作点的数量，而应答者仍然可以使用报价中指示的所有操作点向报价者发送媒体。
For multicast sessions, the answerer MUST accept all Operation Points and their related decoding dependencies or MUST remove non-accepted Operation Points completely. Due to the nature of multicast, the receiver can select which Operation Points it actually receives and processes. For multicast sessions that allow the answerer to also send data, the answerer MAY send all of the offered Operation Points.
对于多播会话，应答者必须接受所有操作点及其相关解码依赖项，或者必须完全删除未接受的操作点。由于多播的性质，接收器可以选择它实际接收和处理的操作点。对于允许应答者也发送数据的多播会话，应答者可以发送所有提供的操作点。
In any case, if the answerer cannot accept one or more offered Operation Points and/or the media stream's dependencies, the answerer MAY re-invite with an offer including acceptable Operation Points and/or dependencies.
在任何情况下，如果应答者不能接受一个或多个提供的操作点和/或媒体流的依赖性，则应答者可以使用包括可接受的操作点和/或依赖性的提供重新邀请。
Note: Applications may limit the possibility of performing a re-invite. The previous offer is also a good hint to the capabilities of the other agent.
注意：应用程序可能会限制执行重新邀请的可能性。前面的提议也很好地暗示了另一个代理的功能。
If a Real Time Streaming Protocol (RTSP) receiver understands signaling according to this memo, it SHALL set up all media streams that are required to decode the Operation Point of its choice.
如果实时流协议（RTSP）接收器根据本备忘录理解信令，则应设置解码其选择的操作点所需的所有媒体流。
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 types included in the SDP can be processed, then obviously no setup can occur.
如果RTSP接收器不理解此备忘录中定义的信令，则返回正常SDP处理。必须区分两种可能的情况：（1）如果SDP中包括的媒体类型中的至少一种在接收器的能力范围内，则它通常根据特定于实现的设置标准在这些候选媒体中进行选择。（2） 如果无法处理SDP中包含的任何媒体类型，则显然无法进行设置。
The signaling mechanisms defined in this document MUST NOT be used to negotiate between using the attribute-value pair (AVP) [RFC3551] and SAVP [RFC3711] profile for RTP. However, both profiles MAY be used separately or jointly with the signaling mechanism defined in this document.
本文件中定义的信令机制不得用于在RTP使用属性值对（AVP）[RFC3551]和SAVP[RFC3711]配置文件之间进行协商。然而，这两个配置文件可以单独使用，也可以与本文件中定义的信令机制联合使用。
This memo does not cover the interaction with Capability Negotiation [MMUSIC]. This issue is for further study and will be addressed in a different memo.
本备忘录不包括与能力协商[MMUSIC]的交互。这一问题有待进一步研究，将在另一份备忘录中讨论。
a.) Example for signaling layered decoding dependency:
a、 ）信令分层解码依赖性的示例：
The example below shows a session description with three media descriptions, all of type video and with layered decoding dependency ("lay"). Each of the media descriptions includes two possible media format descriptions with different encoding parameters as, e.g., "packetization-mode" (not shown in the example) for the media subtypes "H264" and "H264-SVC" given by the "a=rtpmap:"-line. The first media description includes two H264 payload types as media format descriptions, "96" and "97", as defined in [RFC3984] and represents the base layer Operation Point (identified by "mid:L1"). The two other media descriptions (identified by "mid:L2" and "mid:L3") include H264-SVC payload types as defined in [AVT-RTP-SVC], which contain enhancements to the base layer Operation Point or the first enhancement layer Operation Point (media description identified by "mid:L2").
下面的示例显示了具有三种媒体描述的会话描述，均为视频类型，并具有分层解码相关性（“lay”）。每个媒体描述包括具有不同编码参数的两种可能的媒体格式描述，例如，“a=rtpmap:”-行给出的媒体子类型“H264”和“H264-SVC”的“打包模式”（示例中未示出）。第一个媒体描述包括两个H264有效负载类型作为媒体格式描述，“96”和“97”，如[RFC3984]中所定义，并表示基本层操作点（由“mid:L1”标识）。其他两种介质描述（由“mid:L2”和“mid:L3”标识）包括[AVT-RTP-SVC]中定义的H264-SVC有效负载类型，其中包含对基本层操作点或第一增强层操作点的增强（由“mid:L2”标识的介质描述）。
The example shows the dependencies of the media format descriptions of the different media descriptions indicated by "DDP" grouping, "mid", and "depend" attributes. The "depend" attribute is used with the decoding dependency type "lay" indicating layered decoding dependency. For example, the third media description ("m=video 40004...") identified by "mid:L3" has different dependencies on the media format descriptions of the two other media descriptions: Media format description "100" depends on media format description "96" or "97" of the media description indentified by "mid:L1". This is an exclusive-OR, i.e., payload type "100" may be used with payload type "96" or with "97", but one of the two combinations is required for decoding payload type "100".
该示例显示了由“DDP”分组、“mid”和“Dependen”属性指示的不同媒体描述的媒体格式描述的相关性。“depend”属性与表示分层解码相关性的解码相关性类型“lay”一起使用。例如，由“mid:L3”标识的第三媒体描述（“m＝视频40004…”）对另外两个媒体描述的媒体格式描述具有不同的依赖性：媒体格式描述“100”依赖于由“mid:L1”标识的媒体描述的媒体格式描述“96”或“97”。这是异或，即有效载荷类型“100”可与有效载荷类型“96”或“97”一起使用，但解码有效载荷类型“100”需要两种组合中的一种。
For media format description "101", it is different. This one depends on two of the other media descriptions at the same time, i.e., it depends on media format description "97" of the media description indentified by "mid:L1" and it also depends on media format description "99" of the media description indentified by "mid:L2". For decoding media format description "101", both media format description "97" and media format description "99" are required by definition.
对于媒体格式描述“101”，则不同。这一个同时取决于其他两个媒体描述，即，它取决于由“mid:L1”标识的媒体描述的媒体格式描述“97”，也取决于由“mid:L2”标识的媒体描述的媒体格式描述“99”。对于解码媒体格式描述“101”，定义要求媒体格式描述“97”和媒体格式描述“99”。
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 L1 L2 L3
m=video 40000 RTP/AVP 96 97
b=AS:90
a=framerate:15
a=rtpmap:96 H264/90000
a=rtpmap:97 H264/90000
a=mid:L1
m=video 40002 RTP/AVP 98 99
b=AS:64
a=framerate:15
a=rtpmap:98 H264-SVC/90000
a=rtpmap:99 H264-SVC/90000
a=mid:L2
a=depend:98 lay L1:96,97; 99 lay L1:97
m=video 40004 RTP/AVP 100 101
b=AS:128
a=framerate:30
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264-SVC/90000
a=mid:L3
a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99
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 L1 L2 L3
m=video 40000 RTP/AVP 96 97
b=AS:90
a=framerate:15
a=rtpmap:96 H264/90000
a=rtpmap:97 H264/90000
a=mid:L1
m=video 40002 RTP/AVP 98 99
b=AS:64
a=framerate:15
a=rtpmap:98 H264-SVC/90000
a=rtpmap:99 H264-SVC/90000
a=mid:L2
a=depend:98 lay L1:96,97; 99 lay L1:97
m=video 40004 RTP/AVP 100 101
b=AS:128
a=framerate:30
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264-SVC/90000
a=mid:L3
a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99
b.) Example for signaling of multi-descriptive decoding dependency:
b、 ）多描述解码相关性的信令示例：
The example shows a session description with three media descriptions, all of type video and with multi-descriptive decoding dependency. Each of the media descriptions includes one media format description. The example shows the dependencies of the media format descriptions of the different media descriptions indicated by "DDP" grouping, "mid", and "depend" attributes. The "depend" attribute is used with the decoding dependency type "mdc" indicating layered decoding dependency. For example, media format description "104" in the media description ("m=video 40000...") with "mid:M1" depends on the two other media descriptions. It depends on media format description "105" of media description with "mid:M2", and it also depends on media format description "106" of media description with "mid:M3". In case of the multi-descriptive decoding dependency, media format description "105" and "106" can be used by definition to enhance the decoding process of media format description "104", but they are not required for decoding.
该示例显示了具有三种媒体描述的会话描述，均为视频类型，并具有多描述解码依赖性。每个媒体描述包括一个媒体格式描述。该示例显示了由“DDP”分组、“mid”和“Dependen”属性指示的不同媒体描述的媒体格式描述的相关性。“depend”属性与表示分层解码依赖的解码依赖类型“mdc”一起使用。例如，媒体描述（“m=video 40000…”）中带有“mid:M1”的媒体格式描述“104”取决于其他两种媒体描述。它取决于媒体描述的媒体格式描述“105”和“mid:M2”，也取决于媒体描述的媒体格式描述“106”和“mid:M3”。在多描述解码依赖性的情况下，媒体格式描述“105”和“106”可以被定义为用于增强媒体格式描述“104”的解码过程，但是解码不需要它们。
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 M1 M2 M3
m=video 40000 RTP/AVP 104
a=mid:M1
a=depend:104 mdc M2:105 M3:106
m=video 40002 RTP/AVP 105
a=mid:M2
a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106
a=mid:M3
a=depend:106 mdc M1:104 M2:105
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 M1 M2 M3
m=video 40000 RTP/AVP 104
a=mid:M1
a=depend:104 mdc M2:105 M3:106
m=video 40002 RTP/AVP 105
a=mid:M2
a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106
a=mid:M3
a=depend:106 mdc M1:104 M2:105
All security implications of SDP apply.
SDP的所有安全影响均适用。
There may be a risk of manipulation of 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.
攻击者可能有操纵会话描述的依赖性信令的风险。这可能误导接收机或中间盒，例如，接收机可能试图从不形成操作点的多个RTP分组流中合成媒体比特流，尽管信令使其相信它将形成有效的操作点，这对媒体解码过程具有潜在的致命后果。建议接收方对SDP执行完整性检查，并遵循SDP的安全注意事项，仅信任来自受信任源的SDP。
The following contact information shall be used for all registrations included here:
以下联系信息应用于此处包含的所有注册：
Contact: Thomas Schierl
email: ts@thomas-schierl.de
tel: +49-30-31002-227
Contact: Thomas Schierl
email: ts@thomas-schierl.de
tel: +49-30-31002-227
The following semantics have been registered by IANA in Semantics for the "group" SDP Attribute under SDP Parameters.
IANA已在SDP参数下的“group”SDP属性的语义中注册了以下语义。
Semantics Token Reference
------------------- ----- ---------
Decoding Dependency DDP RFC 5583
Semantics Token Reference
------------------- ----- ---------
Decoding Dependency DDP RFC 5583
The SDP media-level attribute "depend" has been registered by IANA in Semantics for "att-field (media level only)". The registration procedure in Section 8.2.4 of [RFC4566] applies.
IANA已在语义上为“att字段（仅媒体级别）”注册了SDP媒体级别属性“depend”。[RFC4566]第8.2.4节中的注册程序适用。
SDP Attribute ("att-field (media level only)"):
SDP属性（“att字段（仅媒体级别）”）：
Attribute name: depend Long form: decoding dependency Type of name: att-field Type of attribute: media level only Subject to charset: no Purpose: RFC 5583 Reference: RFC 5583 Values: see this document and registrations below.
属性名称：依赖长格式：解码依赖项名称类型：att字段属性类型：媒体级别仅受字符集约束：无用途：RFC 5583参考：RFC 5583值：请参阅下面的文档和注册。
The following semantics have been registered by IANA in Semantics for the "depend" SDP Attribute under SDP Parameters:
IANA已在SDP参数下“depend”SDP属性的语义中注册了以下语义：
Semantics of the "depend" SDP attribute:
“depend”SDP属性的语义：
Semantics Token Reference
---------------------------- ----- ---------
Layered decoding dependency lay RFC 5583
Multi-descriptive decoding dependency mdc RFC 5583
Semantics Token Reference
---------------------------- ----- ---------
Layered decoding dependency lay RFC 5583
Multi-descriptive decoding dependency mdc RFC 5583
New registrations for semantics of the "depend" SDP attribute are added by the "Specification Required" policy as defined in [RFC5226].
[RFC5226]中定义的“所需规范”策略添加了“依赖”SDP属性语义的新注册。
9. Informative Note on "The SDP (Session Description Protocol) Grouping Framework"
9. 关于“SDP（会话描述协议）分组框架”的资料性说明
Currently, there is ongoing work on [RFC3388bis]. In [RFC3388bis], the grouping mechanism is extended in a way that a media description can be part of more than one group of the same grouping type in the same session description. However, media descriptions grouped by this document must be at most part of one group of the type "DDP" in the same session description.
目前，正在进行[RFC3388bis]方面的工作。在[RFC3388bis]中，分组机制的扩展方式是，媒体描述可以是同一会话描述中相同分组类型的多个组的一部分。但是，按此文档分组的媒体描述在同一会话描述中最多只能是一组“DDP”类型的媒体描述的一部分。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388]Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[AVT-RTP-SVC] Wenger, S., Wang Y.-K., Schierl, T. and A. Eleftheriadis, "RTP Payload Format for SVC Video", Work in Progress, March 2009.
[AVT-RTP-SVC]Wenger，S.，Wang Y.-K.，Schierl，T.和A.Eleftheriadis，“SVC视频的RTP有效载荷格式”，正在进行的工作，2009年3月。
[RFC3388bis] Camarillo, G "The SDP (Session Description Protocol) Grouping Framework", Work in Progress, January 2009.
[RFC3388bis]Camarillo，G“SDP（会话描述协议）分组框架”，正在进行的工作，2009年1月。
[MMUSIC] Andreasen, F., "SDP Capability Negotiation", Work in Progress, May 2009.
[MMUSIC]Andreasen，F.，“SDP能力谈判”，正在进行的工作，2009年5月。
[AVT-RTP-MVC] Wang, Y.-K. and T. Schierl, "RTP Payload Format for MVC Video", Work in Progress, February 2009.
[AVT-RTP-MVC]Wang，Y.-K.和T.Schierl，“MVC视频的RTP有效载荷格式”，正在进行的工作，2009年2月。
[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.
[MDC]Vitali，A.，Borneo，A.，Fumagalli，M.，和R.Rinaldo，“使用标准兼容多描述编码的IP视频：IETF提案”，分组视频研讨会，2006年4月，中国杭州。
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, February 2005.
[RFC3984]Wenger，S.，Hannuksela，M.，Stockhammer，T.，Westerlund，M.，和D.Singer，“H.264视频的RTP有效载荷格式”，RFC 3984，2005年2月。
The author Thomas Schierl of Fraunhofer HHI is sponsored by the European Commission under the contract number FP7-ICT-214063, project SEA.
Fraunhofer HHI的作者Thomas Schierl由欧盟委员会赞助，合同号为FP7-ICT-214063，SEA项目。
We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and constructive comments to this memo.
我们还要感谢马格纳斯·韦斯特隆德、约尔格·奥特、阿里·贝根、丹·温、赫尔穆特·伯克林和让·弗朗索瓦·穆勒对这份备忘录提出的宝贵和建设性意见。
Authors' Addresses
作者地址
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587德国柏林
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de
Stephan Wenger 2400 Skyfarm Dr. Hillsborough, CA 94010 USA
Stephan Wenger 2400 Skyfarm Hillsborough博士，美国加利福尼亚州94010
Phone: +1-415-713-5473
EMail: stewe@stewe.org
Phone: +1-415-713-5473
EMail: stewe@stewe.org