Network Working Group J. Lennox
Request for Comments: 5576 Vidyo
Category: Standards Track J. Ott
Helsinki University of Technology
T. Schierl
Fraunhofer HHI
June 2009
Network Working Group J. Lennox
Request for Comments: 5576 Vidyo
Category: Standards Track J. Ott
Helsinki University of Technology
T. Schierl
Fraunhofer HHI
June 2009
Source-Specific Media Attributes in the Session Description Protocol (SDP)
会话描述协议（SDP）中的源特定媒体属性
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 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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources.
会话描述协议（SDP）提供用于描述多媒体会话和多媒体会话内的单个媒体流（例如，实时传输协议（RTP）会话）的属性的机制，但不提供用于描述媒体流内的单个媒体源的任何机制。本文档定义了一种机制，用于描述SDP中由同步源（SSRC）标识符标识的RTP媒体源，将属性与这些源关联，并表示源之间的关系。它还定义了几个源级属性，可用于描述媒体源的属性。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview ........................................................3
4. Media Attributes ................................................4
4.1. The "ssrc" Media Attribute .................................5
4.2. The "ssrc-group" Media Attribute ...........................6
5. Usage of Identified Source Identifiers in RTP ...................7
6. Source Attributes ...............................................8
6.1. The "cname" Source Attribute ...............................8
6.2. The "previous-ssrc" Source Attribute .......................9
6.3. The "fmtp" Source Attribute ................................9
6.4. Other Source Attributes ...................................10
7. Examples .......................................................10
8. Usage With the Offer/Answer Model ..............................11
9. Backward Compatibility .........................................11
10. Formal Grammar ................................................12
11. Security Considerations .......................................13
12. IANA Considerations ...........................................14
12.1. New SDP Media-Level Attributes ...........................14
12.2. Registry for Source-Level Attributes .....................14
12.3. Registry for Source Grouping Semantics ...................15
13. References ....................................................16
13.1. Normative References .....................................16
13.2. Informative References ...................................16
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview ........................................................3
4. Media Attributes ................................................4
4.1. The "ssrc" Media Attribute .................................5
4.2. The "ssrc-group" Media Attribute ...........................6
5. Usage of Identified Source Identifiers in RTP ...................7
6. Source Attributes ...............................................8
6.1. The "cname" Source Attribute ...............................8
6.2. The "previous-ssrc" Source Attribute .......................9
6.3. The "fmtp" Source Attribute ................................9
6.4. Other Source Attributes ...................................10
7. Examples .......................................................10
8. Usage With the Offer/Answer Model ..............................11
9. Backward Compatibility .........................................11
10. Formal Grammar ................................................12
11. Security Considerations .......................................13
12. IANA Considerations ...........................................14
12.1. New SDP Media-Level Attributes ...........................14
12.2. Registry for Source-Level Attributes .....................14
12.3. Registry for Source Grouping Semantics ...................15
13. References ....................................................16
13.1. Normative References .....................................16
13.2. Informative References ...................................16
The Session Description Protocol (SDP) [RFC4566] provides mechanisms to describe attributes of multimedia sessions and of media streams (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream.
会话描述协议（SDP）[RFC4566]提供用于描述多媒体会话和多媒体会话内的媒体流（例如，实时传输协议（RTP）[RFC3550]会话）的属性的机制，但不提供用于描述媒体流内的单个媒体源的任何机制。
Several recently proposed protocols, notably RTP single-source multicast [EXT-SSM], have found it useful to describe specific media sources in SDP messages. Single-source multicast, in particular, needs to ensure that receivers' RTP synchronization source (SSRC) identifiers do not collide with those of media senders, as the RTP specification [RFC3550] requires that colliding sources change their SSRC values after a collision has been detected. Earlier work has used mechanisms specific to each protocol to describe the individual sources of an RTP session.
最近提出的几个协议，特别是RTP单源多播[EXT-SSM]，发现在SDP消息中描述特定媒体源非常有用。单源多播尤其需要确保接收方的RTP同步源（SSRC）标识符不会与媒体发送方的标识符冲突，因为RTP规范[RFC3550]要求冲突源在检测到冲突后更改其SSRC值。早期的工作使用了特定于每个协议的机制来描述RTP会话的各个源。
Moreover, whereas the Real-time Transport Protocol (RTP) [RFC3550] is defined as allowing multiple sources in an RTP session (for example, if a user has more than one camera), SDP has no existing mechanism for an endpoint to indicate that it will be using multiple sources or to describe their characteristics individually.
此外，尽管实时传输协议（RTP）[RFC3550]被定义为在RTP会话中允许多个源（例如，如果用户有多个摄像头），但SDP没有端点指示其将使用多个源或单独描述其特征的现有机制。
To address all these problems, this document defines a mechanism to describe RTP sources, identified by their synchronization source (SSRC) identifier, in SDP, to associate attributes with these sources, and to express relationships among individual sources. It also defines a number of new SDP attributes that apply to individual sources ("source-level" attributes), describes how a number of existing media stream ("media-level") attributes can also be applied at the source level, and establishes IANA registries for source-level attributes and source grouping semantics.
为了解决所有这些问题，本文定义了一种机制来描述SDP中由同步源（SSRC）标识符标识的RTP源，将属性与这些源关联，并表示各个源之间的关系。它还定义了许多应用于单个源的新SDP属性（“源级别”属性），描述了许多现有媒体流（“媒体级别”）属性如何也可以应用于源级别，并为源级别属性和源分组语义建立IANA注册表。
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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
In the Real-time Transport Protocol (RTP) [RFC3550], an association among a group of communicating participants is known as an RTP Session. An RTP session is typically associated with a single transport address (in the case of multicast) or communication flow (in the case of unicast), though RTP translators and single-source multicast [EXT-SSM] can make the situation more complex. RTP topologies are discussed in more detail in [RFC5117].
在实时传输协议（RTP）[RFC3550]中，一组通信参与者之间的关联称为RTP会话。RTP会话通常与单个传输地址（在多播的情况下）或通信流（在单播的情况下）相关联，尽管RTP转换器和单源多播[EXT-SSM]会使情况更加复杂。[RFC5117]中详细讨论了RTP拓扑。
Within an RTP session, the source of a single stream of RTP packets is known as a synchronization source (SSRC). Every synchronization source is identified by a 32-bit numeric identifier. In addition, receivers (who may never send RTP packets) also have source
在RTP会话中，单个RTP数据包流的源称为同步源（SSRC）。每个同步源都由一个32位数字标识符标识。此外，接收器（可能永远不会发送RTP数据包）也有源
identifiers, which are used to identify their RTP Control Protocol (RTCP) receiver reports and other feedback messages.
标识符，用于标识其RTP控制协议（RTCP）接收器报告和其他反馈消息。
Messages of the Session Description Protocol (SDP) [RFC4566], known as session descriptions, describe multimedia sessions. A multimedia session is a set of multimedia senders and receivers as well as the data streams flowing from senders to receivers. A multimedia session contains a number of media streams, which are the individual RTP sessions or other media paths over which one type of multimedia data is carried. Information that applies to an entire multimedia session is called session-level information, while information pertaining to one media stream is called media-level information. The collection of all the information describing a media stream is known as a media description. (Media descriptions are also sometimes known informally as SDP "m"-lines, after the SDP syntax that begins a media description.) Several standard information elements are defined at both the session level and the media level. Extended information can be included at both levels through the use of attributes.
会话描述协议（SDP）[RFC4566]的消息称为会话描述，用于描述多媒体会话。多媒体会话是一组多媒体发送方和接收方以及从发送方流向接收方的数据流。多媒体会话包含多个媒体流，这些媒体流是单个RTP会话或承载一种类型多媒体数据的其他媒体路径。适用于整个多媒体会话的信息称为会话级信息，而与一个媒体流有关的信息称为媒体级信息。描述媒体流的所有信息的集合称为媒体描述。（媒体描述有时也被非正式地称为SDP“m”-行，在开始媒体描述的SDP语法之后。）在会话级别和媒体级别都定义了几个标准信息元素。通过使用属性，可以在两个级别上包含扩展信息。
(The term "media stream" does not appear in the SDP specification itself, but is used by a number of SDP extensions, for instance, Interactive Connectivity Establishment (ICE) [ICE], to denote the object described by an SDP media description. This term is unfortunately rather confusing, as the RTP specification [RFC3550] uses the term "media stream" to refer to an individual media source or RTP packet stream, identified by an SSRC, whereas an SDP media stream describes an entire RTP session, which can contain any number of RTP sources. In this document, the term "media stream" means an SDP media stream, i.e., the thing described by an SDP media description, whereas "media source" is used for a single source of media packets, i.e., an RTP media stream.)
（术语“媒体流”未出现在SDP规范中，但被许多SDP扩展（例如，交互式连接建立（ICE）[ICE]）用于表示SDP媒体描述所描述的对象。不幸的是，该术语相当混乱，因为RTP规范[RFC3550]使用了该术语“媒体流”指由SSRC标识的单个媒体源或RTP包流，而SDP媒体流描述整个RTP会话，可包含任意数量的RTP源。在本文件中，术语“媒体流”指SDP媒体流，即SDP媒体描述所描述的事物，而“媒体源”用于单个媒体包源，即RTP媒体流。）
The core SDP specification does not have any way of describing individual media sources, particularly RTP synchronization sources, within a media stream. To address this problem, in this document we introduce a third level of information, called source-level information. Syntactically, source-level information is described by a new SDP media-level attribute, "ssrc", which identifies specific synchronization sources within an RTP session and acts as a meta-attribute mapping source-level attribute information to these sources.
核心SDP规范没有任何方法来描述媒体流中的单个媒体源，特别是RTP同步源。为了解决这个问题，在本文中，我们介绍了第三级信息，称为源代码级信息。从语法上讲，源级信息由一个新的SDP媒体级属性“ssrc”描述，该属性标识RTP会话中的特定同步源，并充当将源级属性信息映射到这些源的元属性。
This document also defines an SDP media-level attribute, "ssrc-group", which can represent relationships among media sources within an RTP session in much the same way as the "group" attribute [RFC3388] represents relationships among media streams within a multimedia session.
本文档还定义了SDP媒体级属性“ssrc group”，该属性可以表示RTP会话中媒体源之间的关系，其方式与“group”属性[RFC3388]表示多媒体会话中媒体流之间的关系大致相同。
This section defines two media-level attributes, "ssrc" and "ssrc-group".
本节定义了两个媒体级属性，“ssrc”和“ssrc组”。
a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value>
a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value>
The SDP media attribute "ssrc" indicates a property (known as a "source-level attribute") of a media source (RTP stream) within an RTP session. <ssrc-id> is the synchronization source (SSRC) ID of the source being described, interpreted as a 32-bit unsigned integer in network byte order and represented in decimal. <attribute> or <attribute>:<value> represents the source-level attribute specific to the given media source. The source-level attribute follows the syntax of the SDP "a=" line. It thus consists of either a single attribute name (a flag) or an attribute name and value, e.g., "cname:user@example.com". No attributes of the former type are defined by this document.
SDP媒体属性“ssrc”表示RTP会话中媒体源（RTP流）的属性（称为“源级别属性”）<ssrc id>是所描述源的同步源（ssrc）id，按网络字节顺序解释为32位无符号整数，并以十进制表示<属性>或<attribute>：<value>表示特定于给定媒体源的源级别属性。源级别属性遵循SDP“a=”行的语法。因此，它由单个属性名称（标志）或属性名称和值组成，例如，“cname:user@example.com". 本文档未定义前一种类型的属性。
Within a media stream, "ssrc" attributes with the same value of <ssrc-id> describe different attributes of the same media sources. Across media streams, <ssrc-id> values are not correlated (unless correlation is indicated by media-stream grouping or some other mechanism) and MAY be repeated.
在媒体流中，具有相同值<ssrc id>的“ssrc”属性描述相同媒体源的不同属性。跨媒体流，<ssrc id>值不相关（除非通过媒体流分组或其他机制指示相关），并且可以重复。
Each "ssrc" media attribute specifies a single source-level attribute for the given <ssrc-id>. For each source mentioned in SDP, the source-level attribute "cname", defined in Section 6.1, MUST be provided. Any number of other source-level attributes for the source MAY also be provided.
每个“ssrc”媒体属性为给定的<ssrc id>指定一个源级别属性。对于SDP中提到的每个源，必须提供第6.1节中定义的源级属性“cname”。还可以提供源的任何数量的其他源级属性。
The "ssrc" media attribute MAY be used for any RTP-based media transport. It is not defined for other transports.
“ssrc”媒体属性可用于任何基于RTP的媒体传输。它没有为其他传输定义。
If any other SDP attributes also mention RTP SSRC values (for example, Multimedia Internet KEYing (MIKEY) [RFC3830] [RFC4567]), the values used MUST be consistent. (These attributes MAY provide additional information about a source described by an "ssrc" attribute or MAY describe additional sources.)
如果任何其他SDP属性也提到RTP SSRC值（例如，多媒体互联网键控（MIKEY）[RFC3830][RFC4567]），则使用的值必须一致。（这些属性可以提供关于“ssrc”属性所描述的源的附加信息，或者可以描述附加源。）
Though the source-level attributes specified by the ssrc property follow the same syntax as session-level and media-level attributes, they are defined independently. All source-level attributes MUST be registered with IANA, using the registry defined in Section 12.2.
尽管ssrc属性指定的源级别属性与会话级别和媒体级别属性遵循相同的语法，但它们是独立定义的。所有源级属性必须使用第12.2节中定义的注册表向IANA注册。
Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "ssrc" attribute.
第10节中的图4给出了“ssrc”属性的一个正式扩展的巴科斯-诺尔形式（ABNF）[RFC5234]语法。
The "ssrc" media attribute is not dependent on charset.
“ssrc”媒体属性不依赖于字符集。
a=ssrc-group:<semantics> <ssrc-id> ...
a=ssrc组：<semantics><ssrc id>。。。
The SDP media attribute "ssrc-group" expresses a relationship among several sources of an RTP session. It is analogous to the "group" session-level attribute [RFC3388], which expresses a relationship among media streams in an SDP multimedia session (i.e., a relationship among several logically related RTP sessions). As sources are already identified by their SSRC IDs, no analogous property to the "mid" attribute is necessary; groups of sources are identified by their SSRC IDs directly.
SDP媒体属性“ssrc group”表示RTP会话的多个源之间的关系。它类似于“组”会话级别属性[RFC3388]，它表示SDP多媒体会话中媒体流之间的关系（即，多个逻辑相关RTP会话之间的关系）。由于源已经通过其SSRC ID识别，因此不需要与“mid”属性类似的属性；源组由其SSRC ID直接标识。
The <semantics> parameter is taken from the specification of the "group" attribute [RFC3388]. The initial semantic values defined for the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] and FEC (Forward Error Correction) [RFC4756]. In each case, the relationship among the grouped sources is the same as the relationship among corresponding sources in media streams grouped using the SDP "group" attribute.
<semantics>参数取自“group”属性[RFC3388]的规范。为“ssrc group”属性定义的初始语义值是FID（流标识）[RFC3388]和FEC（前向纠错）[RFC4756]。在每种情况下，分组源之间的关系与使用SDP“group”属性分组的媒体流中的相应源之间的关系相同。
Though the "ssrc-group" semantic values follow the same syntax as "group" semantic values, they are defined independently. All "ssrc-group" semantic values MUST be registered with IANA, using the registry defined in Section 12.3.
尽管“ssrc组”语义值遵循与“组”语义值相同的语法，但它们是独立定义的。所有“ssrc组”语义值必须使用第12.3节中定义的注册表向IANA注册。
(The other "group" semantics registered with IANA as of this writing are not useful for source grouping. LS (Lip Synchronization) [RFC3388] is redundant for sources within a media stream as RTP sources with the same CNAME are implicitly synchronized in RTP. SRF (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network Address Types) [RFC4091] refer specifically to the media stream's transport characteristics. CS (Composite Session) [FLUTE] is used to group FLUTE sessions, and so is not applicable to RTP.)
（在撰写本文时向IANA注册的其他“组”语义对于源分组不有用。LS（Lip同步）[RFC3388]对于媒体流中的源是冗余的，因为具有相同CNAME的RTP源在RTP.SRF（单一保留流）[RFC3524]和ANAT（备用网络地址类型）中隐式同步。）[RFC4091]具体指媒体流的传输特性。CS（复合会话）[FLUTE]用于分组FLUTE会话，因此不适用于RTP。）
The "ssrc-group" attribute indicates the sources in a group by listing the <ssrc-id>s of the sources in the group. It MUST list at least one <ssrc-id> for a group and MAY list any number of additional ones. Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined by a corresponding "ssrc:" line in the same media description.
“ssrc group”属性通过列出组中源的<ssrc id>来指示组中的源。它必须为一个组列出至少一个<ssrc id>，并且可以列出任意数量的附加id。“ssrc group”属性中列出的每个<ssrc id>必须由同一介质描述中的相应“ssrc:”行定义。
The "ssrc-group" media attribute is not dependent on charset.
“ssrc group”媒体属性不依赖于字符集。
Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "ssrc-group" attribute.
第10节中的图5给出了“ssrc group”属性的一个正式扩展的巴科斯-诺尔形式（ABNF）[RFC5234]语法。
The synchronization source identifiers used in an RTP session are chosen randomly and independently by endpoints. As such, it is possible for two RTP endpoints to choose the same SSRC identifier. Though the probability of this is low, the RTP specification [RFC3550] requires that all RTP endpoints MUST be prepared to detect and resolve collisions.
RTP会话中使用的同步源标识符由端点随机独立选择。因此，两个RTP端点可以选择相同的SSRC标识符。尽管这种可能性很低，但RTP规范[RFC3550]要求所有RTP端点必须做好检测和解决冲突的准备。
As a result, all endpoints MUST be prepared for the fact that information about specific sources identified in a media stream might be out of date. The actual binding between SSRCs and source CNAMEs can only be identified by the source description (SDES) RTCP packets transmitted on the RTP session.
因此，所有端点都必须做好准备，以防媒体流中标识的特定源的信息可能已过时。SSRC和源CNAMEs之间的实际绑定只能通过RTP会话上传输的源描述（SDES）RTCP数据包来识别。
When endpoints are choosing their own local SSRC values for media streams for which source-level attributes have been specified, they MUST NOT use for themselves any SSRC identifiers mentioned in media descriptions they have received for the media stream.
当端点为已指定源级别属性的媒体流选择其自己的本地SSRC值时，它们不得为自己使用它们收到的媒体流的媒体描述中提到的任何SSRC标识符。
However, sources identified by SDP source-level attributes do not otherwise affect RTP transport logic. Specifically, sources that are only known through SDP, for which neither RTP nor RTCP packets have been received, MUST NOT be counted for RTP group size estimation, and report blocks MUST NOT be sent for them in SR or RR RTCP messages.
但是，由SDP源级别属性标识的源不会影响RTP传输逻辑。具体而言，RTP组大小估计中不得计算仅通过SDP知道的源（未收到RTP或RTCP数据包），也不得在SR或RR RTCP消息中为其发送报告块。
Endpoints MUST NOT assume that only the sources mentioned in SDP will be present in an RTP session; additional sources, with previously unmentioned SSRC IDs, can be added at any time, and endpoints MUST be prepared to receive packets from these sources. (How endpoints handle such packets is not specified here; they SHOULD be handled in the same manner as packets from additional sources would be handled had the endpoint not received any a=ssrc: attributes at all.)
端点不得假设RTP会话中仅存在SDP中提到的源；可以随时添加具有以前未提及的SSRC ID的其他源，并且端点必须准备好接收来自这些源的数据包。（此处未指定端点如何处理此类数据包；处理这些数据包的方式应与处理来自其他来源的数据包的方式相同，前提是端点根本没有收到任何a=ssrc:属性。）
An endpoint that observes an SSRC collision between its explicitly signaled source and another entity that has not explicitly signaled an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by 5*1.5*Td, where Td is the deterministic, calculated, reporting interval for receivers defined in Section 6.3.1 of the RTP specification [RFC3550], to see whether the conflict still exists. (This gives precedence to explicitly signaled sources and places the burden of collision resolution on non-signaled sources.) SSRC collisions between multiple explicitly-signaled sources, however, MUST be acted upon immediately.
观察到其显式信号源和未显式信号SSRC的另一实体之间SSRC冲突的端点可将其RTP冲突解决行动[RFC3550]延迟5*1.5*Td，其中Td是RTP规范[RFC3550]第6.3.1节中定义的接收器的确定、计算、报告间隔，看看冲突是否仍然存在。（这优先于显式信号源，并将冲突解决的负担放在非信号源上。）但是，必须立即对多个显式信号源之间的SSRC冲突采取行动。
If, following RTP's collision-resolution procedures [RFC3550], a source identified by source-level attributes has been forced to change its SSRC identifier, the author of the SDP containing the source-level attributes for these sources SHOULD send out an updated SDP session description with the new SSRC if the mechanism by which SDP is being distributed for the multimedia session has a mechanism to distribute updated SDP. This updated SDP MUST include a "previous-ssrc" source-level attribute, described in Section 6.2, listing the source's previous SSRC ID. (If only a single source with a given CNAME has collided, the other RTP session members can infer a correspondence between the source's old and new SSRC IDs without requiring an updated session description. However, if more than one source collides at once, or if sources are leaving and re-joining, this inference is not possible. To avoid confusion, therefore, sending updated SDP messages is always RECOMMENDED.)
如果按照RTP的冲突解决程序[RFC3550]，由源级别属性标识的源已被强制更改其SSRC标识符，如果为多媒体会话分发SDP的机制具有分发更新SDP的机制，则包含这些源的源级别属性的SDP的作者应使用新SSRC发送更新的SDP会话描述。此更新的SDP必须包含“先前ssrc”源级别属性，如第6.2节所述，列出源的先前ssrc ID。（如果只有一个具有给定CNAME的源发生冲突，则其他RTP会话成员可以推断源的旧SSRC ID和新SSRC ID之间的对应关系，而无需更新会话描述。但是，如果一次有多个源发生冲突，或者如果源离开并重新加入，则无法进行此推断。为避免混淆n、 因此，始终建议发送更新的SDP消息。）
Endpoints MUST NOT reuse the same SSRC ID for identified sources with the same CNAME for at least the duration of the RTP session's participant timeout interval (see Section 6.3.5 of [RFC3550]). They SHOULD NOT reuse any SSRC ID ever mentioned in SDP (either by themselves or by other endpoints) for the entire lifetime of the RTP session.
端点不得在RTP会话的参与者超时时间间隔内（见[RFC3550]第6.3.5节）对具有相同CNAME的已识别源重复使用相同的SSRC ID。在RTP会话的整个生命周期中，他们不应该重用SDP中提到的任何SSRC ID（由他们自己或其他端点）。
Endpoints MUST be prepared for the possibility that other parties in the session do not understand SDP source-level attributes, unless some higher-level mechanism normatively requires them. See Section 9 for more discussion of this.
端点必须为会话中的其他各方不理解SDP源级别属性的可能性做好准备，除非某些更高级别的机制规范性地要求它们。有关这方面的更多讨论，请参见第9节。
This section describes specific source attributes that can be applied to RTP sources.
本节描述可应用于RTP源的特定源属性。
a=ssrc:<ssrc-id> cname:<cname>
a=ssrc:<ssrc-id> cname:<cname>
The "cname" source attribute associates a media source with its Canonical End-Point Identifier (CNAME) source description (SDES) item. This MUST be the CNAME value that the media sender will place in its RTCP SDES packets; it therefore MUST follow the syntax conventions of CNAME defined in the RTP specification [RFC3550]. If a session participant receives an RTCP SDES packet associating this SSRC with a different CNAME, it SHOULD assume there has been an SSRC collision and that the description of the source that was carried in the SDP description is not applicable to the actual source being received. This source attribute is REQUIRED to be present if any source attributes are present for a source. The "cname" attribute
“cname”源属性将媒体源与其规范端点标识符（cname）源描述（SDES）项相关联。这必须是媒体发送方将放入其RTCP SDES数据包中的CNAME值；因此，它必须遵循RTP规范[RFC3550]中定义的CNAME语法约定。如果会话参与者收到将此SSRC与不同CNAME关联的RTCP SDES数据包，则应假定存在SSRC冲突，并且SDP描述中包含的源描述不适用于接收的实际源。如果源存在任何源属性，则需要存在此源属性。“cname”属性
MUST NOT occur more than once for the same ssrc-id within a given media stream.
对于给定媒体流中的同一ssrc id，不能出现多次。
The "cname" source attribute is not dependent on charset.
“cname”源属性不依赖于字符集。
Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "cname" attribute.
第10节中的图6给出了“cname”属性的一个正式扩展的Backus-Naur-Form（ABNF）[RFC5234]语法。
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...
a=ssrc:<ssrc id>以前的ssrc:<ssrc id>。。。
The "previous-ssrc" source attribute associates a media source with previous source identifiers used for the same media source. Following an SSRC change due to an SSRC collision involving a media source described in SDP, the updated session description describing the source's new SSRC (described in Section 5) MUST include the "previous-ssrc" attribute associating the new SSRC with the old one. If further updated SDP descriptions are published describing the media source, the "previous-ssrc" attribute SHOULD be included if the session description was generated before the participant timeout of the old SSRC, and MAY be included after that point. This attribute, if present, MUST list at least one previous SSRC and MAY list any number of additional SSRCs for the source if the source has collided more than once. This attribute MUST be present only once for each source.
“previous ssrc”源属性将媒体源与用于同一媒体源的先前源标识符相关联。由于涉及SDP中描述的媒体源的SSRC冲突而导致SSRC更改后，描述源的新SSRC的更新会话描述（第5节中描述）必须包括将新SSRC与旧SSRC关联的“先前SSRC”属性。如果发布了描述媒体源的进一步更新的SDP描述，则如果会话描述是在旧ssrc的参与者超时之前生成的，则应包含“previous ssrc”属性，并且可以在该点之后包含。此属性（如果存在）必须列出至少一个以前的SSRC，并且如果源发生多次碰撞，则可以列出源的任意数量的附加SSRC。对于每个源，此属性只能出现一次。
The "previous-ssrc" source attribute is not dependent on charset.
“previous ssrc”源属性不依赖于字符集。
Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the previous-ssrc attribute.
第10节中的图7给出了前一个ssrc属性的一个正式扩展的巴科斯-诺尔形式（ABNF）[RFC5234]语法。
a=ssrc:<ssrc> fmtp:<format> <format specific parameters>
a=ssrc:<ssrc> fmtp:<format> <format specific parameters>
The "fmtp" source attribute allows format-specific parameters to be conveyed about a given source. The <format> parameter MUST be one of the media formats (i.e., RTP payload types) specified for the media stream. The meaning of the <format specific parameters> is unique for each media type. This parameter MUST only be used for media types for which source-level format parameters have explicitly been specified; media-level format parameters MUST NOT be carried over blindly.
“fmtp”源属性允许传递有关给定源的特定于格式的参数。<format>参数必须是为媒体流指定的媒体格式之一（即RTP有效负载类型）。<format specific parameters>的含义对于每种媒体类型都是唯一的。此参数只能用于已明确指定源级别格式参数的媒体类型；媒体级格式参数不得盲目携带。
The "fmtp" source attribute is not dependent on charset.
“fmtp”源属性不依赖于字符集。
This document only defines source attributes that are necessary or useful for an endpoint to decode and render the sources in a media stream. It does not include any attributes that would contribute to an endpoint's decision to accept or reject a stream, e.g., in an offer/answer exchange. Such attributes are for future consideration.
本文档仅定义端点在媒体流中解码和呈现源所必需或有用的源属性。它不包括任何有助于端点决定接受或拒绝流的属性，例如，在提供/应答交换中。这些属性供将来考虑。
This section gives several examples of SDP descriptions of media sessions containing source attributes. For brevity, only the media sections of the descriptions are given.
本节给出了包含源属性的媒体会话的SDP描述的几个示例。为简洁起见，仅给出描述的媒体部分。
m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@example.com
m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@example.com
Figure 1: Example of a declaration of a single synchronization source
图1：单个同步源的声明示例
The example in Figure 1 shows an audio stream advertising a single source.
图1中的示例显示了一个为单个源做广告的音频流。
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:12345 cname:another-user@example.com
a=ssrc:67890 cname:another-user@example.com
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:12345 cname:another-user@example.com
a=ssrc:67890 cname:another-user@example.com
Figure 2: Example of a media stream containing several independent sources from a single session member
图2：包含来自单个会话成员的多个独立源的媒体流示例
The example in Figure 2 shows a video stream where one participant (identified by a single CNAME) has several cameras. The sources could be further distinguished by RTCP Source Description (SDES) information.
图2中的示例显示了一个视频流，其中一个参与者（由单个CNAME标识）有多个摄像头。可通过RTCP源描述（SDES）信息进一步区分源。
m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@example.com
a=ssrc:22222 cname:user3@example.com
a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@example.com
a=ssrc:44444 cname:user3@example.com
m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@example.com
a=ssrc:22222 cname:user3@example.com
a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@example.com
a=ssrc:44444 cname:user3@example.com
Figure 3: Example of the relationships among several retransmission sources
图3：几个重传源之间的关系示例
The example in Figure 3 shows how the relationships among sources used for RTP retransmission [RFC4588] can be explicitly signaled. This prevents the complexity of associating original sources with retransmission sources when SSRC multiplexing is used for RTP retransmission, as is described in Section 5.3 of [RFC4588].
图3中的示例显示了用于RTP重传[RFC4588]的源之间的关系如何被显式通知。如[RFC4588]第5.3节所述，当SSRC多路复用用于RTP重传时，这防止了将原始源与重传源关联的复杂性。
When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific attributes describe only the sources that each party is willing to send (whether it is sending RTP data or RTCP report blocks). No mechanism is provided by which an answer can accept or reject individual sources within a media stream; if the set of sources in a media stream is unacceptable, the answerer's only option is to reject the media stream or the entire multimedia session.
当与SDP提供/应答模型[RFC3264]一起使用时，SDP源特定属性仅描述各方愿意发送的源（无论是发送RTP数据还是RTCP报告块）。没有提供应答可以接受或拒绝媒体流中的单个源的机制；如果媒体流中的源集不可接受，应答者的唯一选择是拒绝媒体流或整个多媒体会话。
The SSRC IDs for sources described by an SDP answer MUST be distinct from the SSRC IDs for sources of that media stream in the offer. Similarly, new SSRC IDs in an updated offer MUST be distinct from the SSRC IDs for that media stream established in the most recent offer/ answer exchange for the session and SHOULD be distinct from any SSRC ID ever used by either party within the multimedia session (whether or not it is still being used).
SDP应答描述的源的SSRC ID必须与报价中该媒体流源的SSRC ID不同。类似地，更新要约中的新SSRC ID必须与会话的最新要约/应答交换中建立的媒体流的SSRC ID不同，并且应与任何一方在多媒体会话中使用过的任何SSRC ID不同（无论是否仍在使用）。
According to the definition of SDP, interpreters of SDP session descriptions ignore unknown attributes. Thus, endpoints MUST be prepared that recipients of their RTP media session may not understand their explicit source descriptions, unless some external mechanism indicates that they were understood. In some cases (such as RTP Retransmission [RFC4588]), this may constrain some choices about the bitstreams that are transmitted.
根据SDP的定义，SDP会话描述的解释器忽略未知属性。因此，端点必须做好准备，使其RTP媒体会话的接收者可能无法理解其明确的源描述，除非某些外部机制表明它们已被理解。在某些情况下（例如RTP重传[RFC4588]），这可能会限制关于传输的比特流的一些选择。
Source descriptions are specified in this document such that RTP endpoints that are compliant with the RTP specification [RFC3550] will be able to decode the media streams they describe whether or not they support explicit source descriptions. However, some deployed RTP implementations may not actually support multiple media sources in a media stream. Media senders MAY wish to restrict themselves to a single source at a time unless they have some means of concluding that the receivers of the media stream support source multiplexing.
本文档中规定了源描述，因此符合RTP规范[RFC3550]的RTP端点将能够解码它们描述的媒体流，无论它们是否支持显式源描述。但是，一些已部署的RTP实现可能实际上不支持媒体流中的多个媒体源。媒体发送者可能希望一次将自己限制为单个源，除非他们有某种手段得出媒体流的接收器支持源多路复用的结论。
This section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the new media and source attributes defined in this document. Grammars for existing session or media attributes that have been extended to be source attributes are not included.
本节为本文档中定义的每个新媒体和源属性提供了一个正式的扩展巴科斯诺尔形式（ABNF）[RFC5234]语法。不包括已扩展为源属性的现有会话或媒体属性的语法。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
o 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
o 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.
o 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
o 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.
o 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 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.
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
ssrc-attr = "ssrc:" ssrc-id SP attribute ; The base definition of "attribute" is in RFC 4566. ; (It is the content of "a=" lines.)
ssrc attr=“ssrc:”ssrc id SP属性；“属性”的基本定义见RFC 4566；（这是“a=”行的内容。）
ssrc-id = integer ; 0 .. 2**32 - 1
ssrc-id = integer ; 0 .. 2**32 - 1
attribute =/ ssrc-attr
属性=/ssrc attr
Figure 4: Syntax of the "ssrc" media attribute
图4：“ssrc”媒体属性的语法
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
semantics = "FEC" / "FID" / token
; Matches RFC 3388 definition and
; IANA registration rules in this doc.
semantics = "FEC" / "FID" / token
; Matches RFC 3388 definition and
; IANA registration rules in this doc.
token = <as defined in RFC 4566>
token = <as defined in RFC 4566>
attribute =/ ssrc-group-attr
属性=/ssrc组属性
Figure 5: Syntax of the "ssrc-group" media attribute
图5：“ssrc组”媒体属性的语法
cname-attr = "cname:" cname
cname attr=“cname:”cname
cname = byte-string ; Following the syntax conventions for CNAME as defined in RFC 3550. ; The definition of "byte-string" is in RFC 4566.
cname=字节字符串；遵循RFC 3550中定义的CNAME语法约定；“字节字符串”的定义见RFC 4566。
attribute =/ cname-attr
属性=/cname attr
Figure 6: Syntax of the "cname" source attribute
图6：“cname”源属性的语法
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
attribute =/ previous-ssrc-attr
属性=/上一个ssrc属性
Figure 7: Syntax of the "previous-ssrc" source attribute
图7：“PreviousSSRC”源属性的语法
All the security implications of RTP [RFC3550] and of SDP [RFC4566] apply. Explicitly describing the multiplexed sources of an RTP media stream does not appear to add any further security issues.
RTP[RFC3550]和SDP[RFC4566]的所有安全含义均适用。明确描述RTP媒体流的多路复用源似乎不会增加任何进一步的安全问题。
This document defines two SDP media-level attributes: "ssrc" and "ssrc-group". These attributes have been registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)".
本文档定义了两个SDP媒体级属性：“ssrc”和“ssrc组”。IANA已在“att字段（仅媒体级别）”下的“会话描述协议（SDP）参数”下注册了这些属性。
The "ssrc" attribute is used to identify characteristics of media sources within a media stream. Its format is defined in Section 4.1.
“ssrc”属性用于标识媒体流中媒体源的特征。其格式见第4.1节。
The "ssrc-group" attribute is used to identify relationships among media sources within a media stream. Its format is defined in Section 4.2.
“ssrc group”属性用于标识媒体流中媒体源之间的关系。其格式见第4.2节。
This specification creates a new IANA registry named "att-field (source level)" within the SDP parameters registry. Source attributes MUST be registered with IANA and documented under the same rules as for SDP session-level and media-level attributes as specified in [RFC4566].
本规范在SDP参数注册表中创建一个名为“att字段（源级别）”的新IANA注册表。源属性必须向IANA注册，并按照与[RFC4566]中规定的SDP会话级和媒体级属性相同的规则进行记录。
New attribute registrations are accepted according to the "Specification Required" policy of [RFC5226], provided that the specification includes the following information:
根据[RFC5226]的“所需规范”政策接受新的属性注册，前提是规范包括以下信息：
o contact name, email address, and telephone number
o 联系人姓名、电子邮件地址和电话号码
o attribute name (as it will appear in SDP)
o 属性名称（将在SDP中显示）
o long-form attribute name in English
o 英文长格式属性名
o whether the attribute value is subject to the charset attribute
o 属性值是否受charset属性的约束
o a one-paragraph explanation of the purpose of the attribute
o 对属性目的的一段解释
o a specification of appropriate attribute values for this attribute
o 此属性的适当属性值的规范
The above is the minimum that IANA will accept. The Expert Reviewer will determine if the proposed attributes are expected to see widespread use and interoperability; in that case, the attributes MUST be specified in a Standards Track RFC.
以上是IANA将接受的最低要求。专家评审员将确定提议的属性是否有望得到广泛使用和互操作性；在这种情况下，必须在标准跟踪RFC中指定属性。
Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability.
注册提交人应确保规范符合SDP属性的精神，最值得注意的是，该属性是平台独立的，因为它不对操作系统进行隐含假设，也不会以可能抑制互操作性的方式命名特定软件。
Source-level attributes that are substantially similar in semantics to existing session-level or media-level attributes SHOULD reuse the same attribute name as those session-level or media-level attributes. Source-level attributes SHOULD NOT reuse attribute names of session-level or media-level attributes that are unrelated or substantially different.
在语义上与现有会话级别或媒体级别属性基本相似的源级别属性应重用与这些会话级别或媒体级别属性相同的属性名称。源级属性不应重复使用不相关或实质不同的会话级或媒体级属性的属性名称。
The initial set of source attribute names, with definitions in Section 6 of this document, is in Figure 8.
图8显示了源属性名称的初始集合以及本文档第6节中的定义。
Type SDP Name Reference
---- ------------------ ---------
att-field (source level)
cname [RFC5576]
previous-ssrc [RFC5576]
fmtp [RFC5576]
Type SDP Name Reference
---- ------------------ ---------
att-field (source level)
cname [RFC5576]
previous-ssrc [RFC5576]
fmtp [RFC5576]
Figure 8: Initial contents of the IANA Source Attribute Registry
图8:IANA源属性注册表的初始内容
This specification creates a new IANA registry named 'Semantics for the "ssrc-group" SDP Attribute' within the SDP parameters registry. Source group semantics MUST be defined in Standards Track RFCs, under the same rules as [RFC3388].
此规范在SDP参数注册表中创建一个名为“ssrc group”SDP属性语义”的新IANA注册表。源组语义必须按照与[RFC3388]相同的规则在标准跟踪RFCs中定义。
The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication:
RFC的IANA注意事项部分必须包括以下信息，这些信息与出版物的RFC编号一起出现在IANA注册表中：
o A brief description of the semantics.
o 对语义的简要描述。
o Token to be used within the group attribute. This token may be of any length, but SHOULD be no more than four characters long.
o 要在组属性中使用的标记。此标记可以是任意长度，但长度不应超过四个字符。
o Reference to a Standards Track RFC.
o 参考标准跟踪RFC。
Source grouping semantic values that are substantially similar to existing media grouping semantic values SHOULD reuse the same semantics name as those media grouping semantics. Source grouping semantics SHOULD NOT reuse source grouping semantic names that are unrelated or substantially different.
与现有媒体分组语义值基本相似的源分组语义值应重用与这些媒体分组语义相同的语义名称。源分组语义不应重用不相关或本质不同的源分组语义名称。
The initial set of source grouping semantic values, for the semantics specified in Section 4.2 of this document, is in Figure 9.
对于本文件第4.2节中指定的语义，源分组语义值的初始集合如图9所示。
Semantics Token Reference
------------------- ----- ---------
Flow Identification FID [RFC5576]
Forward Error Correction FEC [RFC5576]
Semantics Token Reference
------------------- ----- ---------
Flow Identification FID [RFC5576]
Forward Error Correction FEC [RFC5576]
Figure 9: Initial Contents of IANA Source Group Semantics Registry
图9:IANA源组语义注册表的初始内容
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[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月。
[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月。
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[RFC4756]李安，“会话描述协议中的前向纠错分组语义”，RFC4756，2006年11月。
[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. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[EXT-SSM] Schooler, E., Ott, J., and J. Chesterfield, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, March 2009.
[EXT-SSM]Schooler，E.，Ott，J.，和J.Chesterfield，“具有单播反馈的单源多播会话的RTCP扩展”，正在进行的工作，2009年3月。
[FLUTE] Mehta, H., "SDP Descriptors for FLUTE", Work in Progress, January 2006.
[长笛]Mehta，H.，“长笛的SDP描述符”，正在进行的工作，2006年1月。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，正在进行的工作，2007年10月。
[RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, April 2003.
[RFC3524]Camarillo，G.和A.Monrad，“媒体流到资源保留流的映射”，RFC 35242003年4月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091]Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）分组框架的替代网络地址类型（ANAT）语义”，RFC 4091，2005年6月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
Authors' Addresses
作者地址
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Sixth Floor Hackensack, NJ 07601 US
Jonathan Lennox Vidyo，Inc.美国新泽西州哈肯萨克大街433号哈肯萨克六楼，邮编：07601
EMail: jonathan@vidyo.com
EMail: jonathan@vidyo.com
Joerg Ott Helsinki University of Technology (TKK) Department of Communications and Networking PO Box 3000 FIN-02015 TKK Finland
赫尔辛基工业大学（TKK）通信与网络部PO盒3000 FIN 02015 TKK芬兰
EMail: jo@acm.org
EMail: jo@acm.org
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