Network Working Group O. Levin
Request for Comments: 4574 Microsoft Corporation
Category: Standards Track G. Camarillo
Ericsson
August 2006
Network Working Group O. Levin
Request for Comments: 4574 Microsoft Corporation
Category: Standards Track G. Camarillo
Ericsson
August 2006
The Session Description Protocol (SDP) Label Attribute
会话描述协议（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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context.
本文档定义了一个新的会话描述协议（SDP）媒体级属性：“标签”。“label”属性携带指向使用SDP的任意网络应用程序上下文中的媒体流的指针。SDP文档的发送者可以将“标签”属性附加到特定的媒体流。然后，每个媒体流都可以引用其特定应用程序上下文中提供的指针。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Motivation for the New label Attribute ..........................2
4. The Label Attribute .............................................3
5. The Label Attribute in the Offer/Answer Model ...................4
6. Example .........................................................4
7. Security Considerations .........................................4
8. IANA Considerations .............................................5
9. Acknowledgements ................................................5
10. References .....................................................6
10.1. Normative References ......................................6
10.2. Informative References ....................................6
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Motivation for the New label Attribute ..........................2
4. The Label Attribute .............................................3
5. The Label Attribute in the Offer/Answer Model ...................4
6. Example .........................................................4
7. Security Considerations .........................................4
8. IANA Considerations .............................................5
9. Acknowledgements ................................................5
10. References .....................................................6
10.1. Normative References ......................................6
10.2. Informative References ....................................6
SDP is being used by a variety of distributed-over-the-network applications. These applications deal with multiple sessions being described by SDP [4] and serving multiple users or services in the context of a single application instance. Applications of this kind need a means to identify a particular media stream across multiple SDP descriptions exchanged with different users.
SDP正被各种分布式网络应用程序所使用。这些应用程序处理SDP[4]描述的多个会话，并在单个应用程序实例的上下文中为多个用户或服务提供服务。这类应用程序需要一种方法来识别与不同用户交换的多个SDP描述中的特定媒体流。
The XCON framework is an example of a centralized conference architecture that uses SDP according to the offer/answer mechanism defined in [3] to establish media streams with each of the conference participants. Additionally, XCON identifies the need to uniquely identify a media stream in terms of its role in a conference regardless of its media type, transport protocol, and media format. This can be accomplished by using an external document that points to the appropriate media stream and provides information (e.g., the media stream's role in the conference) about it. The SIP Event Package for Conference State [7] defines and uses a concrete format for such external documents.
XCON框架是集中式会议体系结构的一个示例，它根据[3]中定义的提供/应答机制使用SDP与每个会议参与者建立媒体流。此外，XCON根据媒体流在会议中的角色识别唯一标识媒体流的需要，而不考虑其媒体类型、传输协议和媒体格式。这可以通过使用指向适当媒体流并提供相关信息（例如，媒体流在会议中的角色）的外部文档来实现。会议状态的SIP事件包[7]定义并使用此类外部文档的具体格式。
This specification defines the SDP [4] "label" media-level attribute, which provides a pointer to a media stream that is described by an 'm' line in an SDP session description.
本规范定义了SDP[4]“标签”媒体级别属性，该属性提供指向SDP会话描述中由“m”行描述的媒体流的指针。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
Even though SDP and its extensions already provide a few ways to refer to a media stream, none of them is appropriate to be used in the context of external documents that may be created before the session description itself and need to be handled by automata.
尽管SDP及其扩展已经提供了几种引用媒体流的方法，但它们都不适合在会话描述本身之前创建的外部文档上下文中使用，并且需要由自动机处理。
The 'i' SDP attribute, defined in RFC 2327 [4], can be used to label media streams. Nevertheless, values of the 'i' attribute are intended for human users and not for automata.
RFC 2327[4]中定义的“i”SDP属性可用于标记媒体流。然而，“i”属性的值是针对人类用户的，而不是针对自动机的。
The 'mid' SDP attribute, defined in RFC 3388 [6], can be used to identify media streams as well. Nevertheless, the scope of 'mid' is too limited to be used by applications dealing with multiple SDP sessions. This is because values of the 'mid' attribute are meaningful in the context of a single SDP session, not in the context of a broader application (e.g., a multiparty application).
RFC 3388[6]中定义的“mid”SDP属性也可用于标识媒体流。然而，“mid”的范围太有限，无法由处理多个SDP会话的应用程序使用。这是因为“mid”属性的值在单个SDP会话的上下文中是有意义的，而不是在更广泛的应用程序（例如，多方应用程序）的上下文中。
Another way of referring to a media stream is by using the order of the 'm' line in the SDP session document (e.g., the 5th media stream in the session description). This is the mechanism used in the offer/answer model [3].
引用媒体流的另一种方式是使用SDP会话文档中“m”行的顺序（例如，会话描述中的第5个媒体流）。这是提供/应答模型中使用的机制[3]。
The problem with this mechanism is that it can only be used to refer to media streams in session descriptions that exist already. There are scenarios where a static document needs to refer, using a pointer, to a media stream that will be negotiated by SDP means and created in the future. When the media stream is eventually created, the application needs to label the media stream so that the pointer in the static document points to the proper media stream in the session description.
此机制的问题在于，它只能用于引用已经存在的会话描述中的媒体流。在某些情况下，静态文档需要使用指针引用将由SDP协商并在将来创建的媒体流。最终创建媒体流时，应用程序需要标记媒体流，以便静态文档中的指针指向会话描述中的正确媒体流。
This specification defines a new media-level value attribute: 'label'. Its formatting in SDP is described by the following ABNF [2]:
此规范定义了一个新的媒体级别值属性：“标签”。其在SDP中的格式由以下ABNF[2]描述：
label-attribute = "a=label:" pointer
label-attribute = "a=label:" pointer
pointer = token
pointer = token
token = 1*(token-char)
token = 1*(token-char)
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
The token-char and token elements are defined in [4] but included here to provide support for the implementor of this SDP feature.
token char和token元素在[4]中有定义，但在这里包含它们是为了为SDP特性的实现者提供支持。
The 'label' attribute contains a token that is defined by an application and is used in its context. The new attribute can be attached to 'm' lines in multiple SDP documents allowing the application to logically group the media streams across SDP sessions when necessary.
“label”属性包含由应用程序定义并在其上下文中使用的标记。新属性可以附加到多个SDP文档中的“m”行，允许应用程序在必要时跨SDP会话对媒体流进行逻辑分组。
This specification does not define a means to discover whether or not the peer endpoint understands the 'label' attribute because 'label' values are informative only at the offer/answer model level.
本规范未定义发现对等端点是否理解“标签”属性的方法，因为“标签”值仅在提供/应答模型级别提供信息。
At the offer/answer level, it means that the fact that an offer does not contain label attributes does not imply that the answer should not have them. It also means that the fact that an offer contains label attributes does not imply that the answer should have them too.
在报价/应答级别，这意味着报价不包含标签属性并不意味着答案不应该包含标签属性。这还意味着，报价包含标签属性这一事实并不意味着答案也应该包含标签属性。
In addition to the basic offer/answer rule above, applications that use 'label' as a pointer to media streams MUST specify its usage constraints. For example, such applications MAY mandate support for 'label'. In this case, the application will define means for negotiation of the 'label' attribute support as a part of its specification.
除了上面的基本提供/应答规则外，使用“标签”作为媒体流指针的应用程序必须指定其使用限制。例如，此类应用程序可能要求支持“标签”。在这种情况下，应用程序将定义协商“标签”属性支持的方法，作为其规范的一部分。
The following is an example of an SDP session description that uses the 'label' attribute:
以下是使用“标签”属性的SDP会话描述示例：
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
i=A Seminar on the session description protocol
c=IN IP4 192.0.2.2
t=0 0
m=audio 6886 RTP/AVP 0
a=label:1
m=audio 22334 RTP/AVP 0
a=label:2
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
i=A Seminar on the session description protocol
c=IN IP4 192.0.2.2
t=0 0
m=audio 6886 RTP/AVP 0
a=label:1
m=audio 22334 RTP/AVP 0
a=label:2
An attacker may attempt to add, modify, or remove 'label' attributes from a session description. This could result in an application behaving in a non-desirable way. So, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [5], S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [5]. Other applications MAY use a different form of integrity protection.
攻击者可能试图添加、修改或删除会话描述中的“标签”属性。这可能导致应用程序以不理想的方式运行。因此，强烈建议对SDP会话描述应用完整性保护。对于SIP[5]中的会话描述，S/MIME是提供端到端完整性保护的自然选择，如RFC 3261[5]中所述。其他应用程序可能使用不同形式的完整性保护。
The IANA has registered the following new SDP attribute:
IANA已注册以下新的SDP属性：
Contact name: Orit Levin oritl@microsoft.com.
联系人姓名：Orit Levinoritl@microsoft.com.
Attribute name: "label".
属性名称：“标签”。
Type of attribute: Media level.
属性类型：媒体级别。
Subject to charset: Not.
以字符集为准：不。
Purpose of attribute: The 'label' attribute associates a media stream with a label. This label allows the media stream to be referenced by external documents.
属性用途：“标签”属性将媒体流与标签相关联。此标签允许外部文档引用媒体流。
Allowed attribute values: A token.
允许的属性值：标记。
Robert Sparks, Adam Roach, and Rohan Mahy provided useful comments on this document.
Robert Sparks、Adam Roach和Rohan Mahy对该文件提供了有用的评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[4] Handley，M.，Jacobson，V.和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[6] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[7] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[7] Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
Authors' Addresses
作者地址
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
奥利特·莱文微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: oritl@microsoft.com
EMail: oritl@microsoft.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。