Network Working Group J. Hautakorpi
Request for Comments: 4796 G. Camarillo
Category: Standards Track Ericsson
February 2007
Network Working Group J. Hautakorpi
Request for Comments: 4796 G. Camarillo
Category: Standards Track Ericsson
February 2007
The Session Description Protocol (SDP) Content 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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines a new Session Description Protocol (SDP) media-level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content.
本文档定义了一个新的会话描述协议（SDP）媒体级属性“内容”。“内容”属性将媒体流的内容定义为比媒体描述行更详细的级别。SDP会话描述的发送方可以将“内容”属性附加到一个或多个媒体流。然后，接收应用程序可以根据每个媒体流的内容对其进行不同的处理（例如，在大屏幕或小屏幕上显示）。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Related Techniques . . . . . . . . . . . . . . . . . . . . . . 2
4. Motivation for the New Content Attribute . . . . . . . . . . . 3
5. The Content Attribute . . . . . . . . . . . . . . . . . . . . 4
6. The Content Attribute in the Offer/Answer Model . . . . . . . 5
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informational References . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Related Techniques . . . . . . . . . . . . . . . . . . . . . . 2
4. Motivation for the New Content Attribute . . . . . . . . . . . 3
5. The Content Attribute . . . . . . . . . . . . . . . . . . . . 4
6. The Content Attribute in the Offer/Answer Model . . . . . . . 5
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informational References . . . . . . . . . . . . . . . . 9
The Session Description Protocol (SDP) [1] is a protocol that is intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. One of the most typical use cases of SDP is where it is used with the Session Initiation Protocol (SIP) [5].
会话描述协议（SDP）[1]是一种旨在描述多媒体会话的协议，用于会话公告、会话邀请和其他形式的多媒体会话启动。SDP最典型的用例之一是它与会话启动协议（SIP）一起使用[5]。
There are situations where one application receives several similar media streams, which are described in an SDP session description. The media streams can be similar in the sense that their content cannot be distinguished just by examining their media description lines (e.g., two video streams). The 'content' attribute is needed so that the receiving application can treat each media stream appropriately based on its content.
存在一个应用程序接收多个类似媒体流的情况，这些媒体流在SDP会话描述中描述。媒体流的相似之处在于，仅通过检查其媒体描述行（例如，两个视频流）无法区分其内容。需要“content”属性，以便接收应用程序可以根据其内容适当地处理每个媒体流。
This specification defines the SDP 'content' media-level attribute, which provides more information about the media stream than the 'm' line in an SDP session description.
此规范定义了SDP“内容”媒体级别属性，该属性提供了有关媒体流的更多信息，而不是SDP会话描述中的“m”行。
The main purpose of this specification is to allow applications to take automated actions based on the 'content' attributes. However, this specification does not define those actions. Consequently, two implementations can behave completely differently when receiving the same 'content' attribute.
本规范的主要目的是允许应用程序根据“内容”属性自动执行操作。但是，本规范并未定义这些操作。因此，当接收相同的“内容”属性时，两个实现的行为可能完全不同。
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 [3], and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照BCP 14、RFC 2119[3]中的描述进行解释，并指出合规实施的要求级别。
The 'label' attribute [10] enables a sender to attach a pointer to a particular media stream. The namespace of the 'label' attribute itself is unrestricted; so, in principle, it could also be used to convey information about the content of a media stream. However, in practice, this is not possible because of the need for backward compatibility. Existing implementations of the 'label' attribute already use values from that unrestricted namespace in an application-specific way. So, it is not possible to reserve portions of the 'label' attribute's namespace without possible conflict with already used application-specific labels.
“标签”属性[10]允许发送方将指针附加到特定媒体流。“label”属性本身的名称空间不受限制；因此，原则上，它也可以用来传递有关媒体流内容的信息。然而，在实践中，这是不可能的，因为需要向后兼容。“label”属性的现有实现已经以特定于应用程序的方式使用来自该无限制命名空间的值。因此，如果不与已使用的特定于应用程序的标签发生冲突，就不可能保留“label”属性命名空间的一部分。
It is possible to assign semantics to a media stream with an external document that uses the 'label' attribute as a pointer. The downside of this approach is that it requires an external document. Therefore, this kind of mechanism is only applicable to special use cases where such external documents are used (e.g., centralized conferencing).
可以通过使用“label”属性作为指针的外部文档为媒体流分配语义。这种方法的缺点是需要外部文档。因此，这种机制仅适用于使用此类外部文档的特殊用例（例如，集中式会议）。
Yet another way to attach semantics to a media stream is to use the 'i' SDP attribute, defined in [1]. However, values of the 'i' attribute are intended for human users and not for automata.
将语义附加到媒体流的另一种方法是使用[1]中定义的“i”SDP属性。但是，“i”属性的值是针对人类用户的，而不是针对自动机的。
Currently, SDP does not provide any means for describing the content of a media stream (e.g., speaker's image, slides, sign language) in a form that the application can understand. Of course, the end user can see the content of the media stream and read its title, but the application cannot understand what the media stream contains.
目前，SDP不提供任何用于以应用程序能够理解的形式描述媒体流内容（例如，说话人的图像、幻灯片、手语）的方法。但用户看不到流媒体的标题和流媒体所包含的内容，只能阅读流媒体的最终内容。
The application that is receiving multiple similar (e.g., same type and format) media streams needs, in some cases, to know what the contents of those streams are. This kind of situation occurs, for example, in cases where presentation slides, the speaker's image, and sign language are transported as separate media streams. It would be desirable that the receiving application could distinguish them in a way that it could handle them automatically in an appropriate manner.
在某些情况下，接收多个类似（例如，相同类型和格式）媒体流的应用程序需要知道这些流的内容。例如，在演示幻灯片、演讲者的图像和手语作为单独的媒体流传输的情况下，就会出现这种情况。希望接收应用程序能够以一种能够以适当方式自动处理它们的方式来区分它们。
+--------------------------------------+
|+------------++----------------------+|
|| || ||
|| speaker's || ||
|| image || ||
|| || ||
|+------------+| presentation ||
|+------------+| slides ||
|| || ||
|| sign || ||
|| language || ||
|| || ||
|+------------++----------------------+|
+--------------------------------------+
+--------------------------------------+
|+------------++----------------------+|
|| || ||
|| speaker's || ||
|| image || ||
|| || ||
|+------------+| presentation ||
|+------------+| slides ||
|| || ||
|| sign || ||
|| language || ||
|| || ||
|+------------++----------------------+|
+--------------------------------------+
Figure 1: Application's Screen
图1：应用程序的屏幕
Figure 1 shows a screen of a typical communication application. The 'content' attribute makes it possible for the application to decide where to show each media stream. From an end user's perspective, it
图1显示了一个典型通信应用程序的屏幕。“content”属性使应用程序可以决定在何处显示每个媒体流。从最终用户的角度来看，它
is desirable that the user does not need to arrange each media stream every time a new media session starts.
希望用户不需要在每次新媒体会话开始时安排每个媒体流。
The 'content' attribute could also be used in more complex situations. An example of such a situation is an application controlling equipment in an auditorium. An auditorium can have many different output channels for video (e.g., main screen and two smaller screens) and audio (e.g., main speakers and headsets for the participants). In this kind of environment, a lot of interaction from the end user who operates the application would be required in absence of cues from a controlling application. The 'content' attribute would make it possible, for example, for an end user to specify, only once, which output each media stream of a given session should use. The application could automatically apply the same media layout for subsequent sessions. So, the 'content' attribute can help reduce the amount of required end-user interaction considerably.
“content”属性也可以用于更复杂的情况。这种情况的一个例子是礼堂中的应用程序控制设备。礼堂可以有许多不同的视频输出通道（例如，主屏幕和两个较小的屏幕）和音频输出通道（例如，供参与者使用的主扬声器和耳机）。在这种环境中，在没有来自控制应用程序的提示的情况下，需要操作应用程序的最终用户进行大量交互。例如，“content”属性可以让最终用户只指定一次给定会话的每个媒体流应该使用的输出。应用程序可以为后续会话自动应用相同的媒体布局。因此，“内容”属性有助于大大减少所需的最终用户交互量。
This specification defines a new media-level value attribute, 'content'. Its formatting in SDP is described by the following ABNF (Augmented Backus-Naur Form) [2]:
此规范定义了一个新的媒体级别值属性“content”。它在SDP中的格式由以下ABNF（扩展的巴科斯-诺尔格式）[2]描述：
content-attribute = "a=content:" mediacnt-tag
mediacnt-tag = mediacnt *("," mediacnt)
mediacnt = "slides" / "speaker" / "sl" / "main"
/ "alt" / mediacnt-ext
mediacnt-ext = token
content-attribute = "a=content:" mediacnt-tag
mediacnt-tag = mediacnt *("," mediacnt)
mediacnt = "slides" / "speaker" / "sl" / "main"
/ "alt" / mediacnt-ext
mediacnt-ext = token
The 'content' attribute contains one or more tokens, which MAY be attached to a media stream by a sending application. An application MAY attach a 'content' attribute to any media stream it describes.
“content”属性包含一个或多个令牌，发送应用程序可以将其附加到媒体流。应用程序可以将“内容”属性附加到它描述的任何媒体流。
This document provides a set of pre-defined values for the 'content' attribute. Other values can be defined in the future. The pre-defined values are:
本文档为“内容”属性提供了一组预定义值。以后可以定义其他值。预定义值为：
slides: the media stream includes presentation slides. The media type can be, for example, a video stream or a number of instant messages with pictures. Typical use cases for this are online seminars and courses. This is similar to the 'presentation' role in H.239 [12].
幻灯片：媒体流包括演示幻灯片。媒体类型可以是，例如，视频流或许多带有图片的即时消息。这方面的典型用例是在线研讨会和课程。这类似于H.239[12]中的“演示”角色。
speaker: the media stream contains the image of the speaker. The media can be, for example, a video stream or a still image. Typical use cases for this are online seminars and courses.
演讲者：媒体流包含演讲者的图像。例如，媒体可以是视频流或静止图像。这方面的典型用例是在线研讨会和课程。
sl: the media stream contains sign language. A typical use case for this is an audio stream that is translated into sign language, which is sent over a video stream.
sl：媒体流包含手语。这方面的一个典型用例是翻译成手语的音频流，通过视频流发送。
main: the media stream is taken from the main source. A typical use case for this is a concert where the camera is shooting the performer.
主：媒体流取自主源。这方面的一个典型用例是一场音乐会，其中摄像机正在拍摄表演者。
alt: the media stream is taken from the alternative source. A typical use case for this is an event where the ambient sound is separated from the main sound. The alternative audio stream could be, for example, the sound of a jungle. Another example is the video of a conference room, while the main stream carries the video of the speaker. This is similar to the 'live' role in H.239.
alt：媒体流取自替代源。这方面的典型用例是环境声音与主声音分离的事件。例如，可选音频流可以是丛林的声音。另一个例子是会议室的视频，而主流则传输演讲者的视频。这类似于H.239中的“实时”角色。
All these values can be used with any media type. We chose not to restrict each value to a particular set of media types in order not to prevent applications from using innovative combinations of a given value with different media types.
所有这些值都可以用于任何媒体类型。我们选择不将每个值限制为一组特定的媒体类型，以避免应用程序使用具有不同媒体类型的给定值的创新组合。
The application can make decisions on how to handle a single media stream based on both the media type and the value of the 'content' attribute. If the application does not implement any special logic for the handling of a given media type and 'content' value combination, it applies the application's default handling for the media type.
应用程序可以根据媒体类型和“内容”属性的值来决定如何处理单个媒体流。如果应用程序没有实现处理给定媒体类型和“内容”值组合的任何特殊逻辑，它将应用应用程序对媒体类型的默认处理。
Note that the same 'content' attribute value can occur more than once in a single session description.
请注意，相同的“内容”属性值可以在单个会话描述中出现多次。
This specification does not define a means to discover whether the peer endpoint understands the 'content' attribute because 'content' values are just informative at the offer/answer model [8] level. The fact that the peer endpoint does not understand the 'content' attribute does not keep the media session from being established. The only consequence is that end user interaction on the receiving side may be required to direct the individual media streams appropriately.
本规范未定义发现对等端点是否理解“content”属性的方法，因为“content”值只是提供/应答模型[8]级别的信息。对等端点不理解“内容”属性这一事实并不妨碍媒体会话的建立。唯一的结果是可能需要接收侧的最终用户交互来适当地引导各个媒体流。
The 'content' attribute describes the data that the application generating the SDP session description intends to send over a particular media stream. The 'content' values for both directions of a media stream do not need to be the same. Therefore, an SDP answer MAY contain 'content' attributes even if none were present in the offer. Similarly, the answer MAY contain no 'content' attributes even if they were present in the offer. Furthermore, the values of 'content' attributes do not need to match in an offer and an answer.
“content”属性描述生成SDP会话描述的应用程序打算通过特定媒体流发送的数据。媒体流的两个方向的“内容”值不需要相同。因此，即使报价中没有“内容”属性，SDP答案也可能包含“内容”属性。同样，答案可能不包含“内容”属性，即使它们出现在报价中。此外，“内容”属性的值不需要在报价和答案中匹配。
The 'content' attribute can also be used in scenarios where SDP is used in a declarative style. For example, 'content' attributes can be used in SDP session descriptors that are distributed with Session Announcement Protocol (SAP) [9].
“content”属性也可用于SDP以声明式样式使用的场景。例如，“内容”属性可用于与会话公告协议（SAP）一起分发的SDP会话描述符[9]。
There are two examples in this section. The first example, shown below, uses a single 'content' attribute value per media stream:
本节中有两个示例。下面显示的第一个示例使用每个媒体流的单个“内容”属性值：
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Second lecture from information technology
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides
m=video 53334 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Second lecture from information technology
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides
m=video 53334 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl
The second example, below, is a case where there is more than one 'content' attribute value per media stream. The difference with the previous example is that now the conferencing system might automatically mix the video streams from the presenter and slides:
下面的第二个示例是每个媒体流有多个“内容”属性值的情况。与前一个示例的不同之处在于，现在会议系统可能会自动混合来自演示者和幻灯片的视频流：
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Second lecture from information technology
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides,speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Second lecture from information technology
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides,speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl
The values of 'content' attribute, defined in Section 5, can also be used with Synchronized Multimedia Integration Language (SMIL) [11]. SMIL contains a 'param' element, which is used for describing the content of a media flow. However, this 'param' element, like the 'content' attribute, provides an application-specific description of the media content.
第5节中定义的“内容”属性值也可与同步多媒体集成语言（SMIL）[11]一起使用。SMIL包含一个“param”元素，用于描述媒体流的内容。但是，此“param”元素与“content”属性类似，提供媒体内容的特定于应用程序的描述。
Details on how to use the values of the 'content' attribute with SMIL's 'param' element are outside the scope of this specification.
有关如何将“content”属性的值与SMIL的“param”元素一起使用的详细信息不在本规范的范围内。
An attacker may attempt to add, modify, or remove 'content' attributes from a session description. Depending on how an implementation chooses to react to the presence or absence of a given 'content' attribute, this could result in an application behaving in an undesirable way; therefore, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions.
攻击者可能试图添加、修改或删除会话描述中的“内容”属性。根据实现如何选择对给定“内容”属性的存在或不存在作出反应，这可能导致应用程序以不希望的方式运行；因此，强烈建议对SDP会话描述应用完整性保护。
Integrity protection can be provided for a session description carried in an SIP [5], e.g., by using S/MIME [6] or Transport Layer Security (TLS) [7].
可以为SIP[5]中携带的会话描述提供完整性保护，例如，通过使用S/MIME[6]或传输层安全性（TLS）[7]。
It is assumed that values of 'content' attribute do not contain data that would be truly harmful if it is exposed to a possible attacker. It must be noted that the initial set of values does not contain any data that would require confidentiality protection. However, S/MIME and TLS can be used to protect confidentiality, if needed.
假设“content”属性的值不包含如果暴露给可能的攻击者会真正有害的数据。必须注意的是，初始值集不包含任何需要保密保护的数据。但是，如果需要，可以使用S/MIME和TLS来保护机密性。
This document defines a new 'content' attribute for SDP. It also defines an initial set of values for it. Some general information regarding the 'content' attribute is presented in the following:
本文档为SDP定义了一个新的“内容”属性。它还为它定义了一组初始值。有关“内容”属性的一些一般信息如下所示：
Contact name: Jani Hautakorpi <Jani.Hautakorpi@ericsson.com>.
联系人姓名：Jani Hautakorpi<Jani。Hautakorpi@ericsson.com>.
Attribute name: 'content'.
属性名称：“内容”。
Type of attribute Media level.
媒体级别属性的类型。
Subject to charset: No.
以字符集为准：否。
Purpose of attribute: The 'content' attribute gives information from the content of the media stream to the receiving application.
属性用途：“内容”属性将媒体流内容中的信息提供给接收应用程序。
Allowed attribute values: "slides", "speaker", "sl", "main", "alt", and any other registered values.
允许的属性值：“幻灯片”、“扬声器”、“sl”、“主”、“alt”和任何其他注册值。
The IANA created a subregistry for 'content' attribute values under the Session Description Protocol (SDP) Parameters registry. The initial values for the subregistry are as follows:
IANA为会话描述协议（SDP）参数注册表下的“内容”属性值创建了一个子域。次区域的初始值如下所示：
Value of 'content' attribute Reference Description
---------------------------- --------- -----------
slides RFC 4796 Presentation slides
speaker RFC 4796 Image from the speaker
sl RFC 4796 Sign language
main RFC 4796 Main media stream
alt RFC 4796 Alternative media stream
Value of 'content' attribute Reference Description
---------------------------- --------- -----------
slides RFC 4796 Presentation slides
speaker RFC 4796 Image from the speaker
sl RFC 4796 Sign language
main RFC 4796 Main media stream
alt RFC 4796 Alternative media stream
As per the terminology in RFC 2434 [4], the registration policy for new values for the 'content' parameter shall be 'Specification Required'.
根据RFC 2434[4]中的术语，“内容”参数新值的注册策略应为“要求规范”。
If new values for 'content' attributes are specified in the future, they should consist of a meta description of the contents of a media stream. New values for 'content' attributes should not describe things like what to do in order to handle a stream.
如果将来指定了“内容”属性的新值，则这些值应包含媒体流内容的元描述。“content”属性的新值不应该描述处理流所要做的事情。
The authors would like to thank Arnoud van Wijk and Roni Even, who provided valuable ideas for this document. We wish to also thank Tom Taylor for his thorough review.
作者要感谢Arnoud van Wijk和Roni，他们为本文件提供了宝贵的想法。我们还要感谢Tom Taylor的全面审查。
[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[1] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[6] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[7] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[9] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[10] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[10] Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 45742006年8月。
[11] Michel, T. and J. Ayars, "Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition]", World Wide Web Consortium Recommendation REC-SMIL2-20050107, January 2005, <http://www.w3.org/TR/2005/REC-SMIL2-20050107>.
[11] Michel，T.和J.Ayars，“同步多媒体集成语言（SMIL 2.0）-[第二版]”，万维网联盟建议REC-SMIL2-20050107，2005年1月<http://www.w3.org/TR/2005/REC-SMIL2-20050107>.
[12] ITU-T, "Infrastructure of audiovisual services - Systems aspects; Role management and additional media channels for H.300-series terminals", Series H H.239, July 2003.
[12] ITU-T，“视听服务基础设施——系统方面；H.300系列终端的角色管理和附加媒体频道”，系列H.239，2003年7月。
Authors' Addresses
作者地址
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Jani.Hautakorpi@ericsson.com
EMail: Jani.Hautakorpi@ericsson.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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。