Network Working Group M. Handley
Request for Comments: 4566 UCL
Obsoletes: 2327, 3266 V. Jacobson
Category: Standards Track Packet Design
C. Perkins
University of Glasgow
July 2006
Network Working Group M. Handley
Request for Comments: 4566 UCL
Obsoletes: 2327, 3266 V. Jacobson
Category: Standards Track Packet Design
C. Perkins
University of Glasgow
July 2006
SDP: Session Description Protocol
会话描述协议
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 memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
此备忘录定义了会话描述协议（SDP）。SDP用于描述多媒体会话，用于会话公告、会话邀请和其他形式的多媒体会话启动。
Table of Contents
目录
1. Introduction ....................................................3
2. Glossary of Terms ...............................................3
3. Examples of SDP Usage ...........................................4
3.1. Session Initiation .........................................4
3.2. Streaming Media ............................................4
3.3. Email and the World Wide Web ...............................4
3.4. Multicast Session Announcement .............................4
4. Requirements and Recommendations ................................5
4.1. Media and Transport Information ............................6
4.2. Timing Information .........................................6
4.3. Private Sessions ...........................................7
4.4. Obtaining Further Information about a Session ..............7
4.5. Categorisation .............................................7
4.6. Internationalisation .......................................7
1. Introduction ....................................................3
2. Glossary of Terms ...............................................3
3. Examples of SDP Usage ...........................................4
3.1. Session Initiation .........................................4
3.2. Streaming Media ............................................4
3.3. Email and the World Wide Web ...............................4
3.4. Multicast Session Announcement .............................4
4. Requirements and Recommendations ................................5
4.1. Media and Transport Information ............................6
4.2. Timing Information .........................................6
4.3. Private Sessions ...........................................7
4.4. Obtaining Further Information about a Session ..............7
4.5. Categorisation .............................................7
4.6. Internationalisation .......................................7
5. SDP Specification ...............................................7
5.1. Protocol Version ("v=") ...................................10
5.2. Origin ("o=") .............................................11
5.3. Session Name ("s=") .......................................12
5.4. Session Information ("i=") ................................12
5.5. URI ("u=") ................................................13
5.6. Email Address and Phone Number ("e=" and "p=") ............13
5.7. Connection Data ("c=") ....................................14
5.8. Bandwidth ("b=") ..........................................16
5.9. Timing ("t=") .............................................17
5.10. Repeat Times ("r=") ......................................18
5.11. Time Zones ("z=") ........................................19
5.12. Encryption Keys ("k=") ...................................19
5.13. Attributes ("a=") ........................................21
5.14. Media Descriptions ("m=") ................................22
6. SDP Attributes .................................................24
7. Security Considerations ........................................31
8. IANA Considerations ............................................33
8.1. The "application/sdp" Media Type ..........................33
8.2. Registration of Parameters ................................34
8.2.1. Media Types ("media") ..............................34
8.2.2. Transport Protocols ("proto") ......................34
8.2.3. Media Formats ("fmt") ..............................35
8.2.4. Attribute Names ("att-field") ......................36
8.2.5. Bandwidth Specifiers ("bwtype") ....................37
8.2.6. Network Types ("nettype") ..........................37
8.2.7. Address Types ("addrtype") .........................38
8.2.8. Registration Procedure .............................38
8.3. Encryption Key Access Methods .............................39
9. SDP Grammar ....................................................39
10. Summary of Changes from RFC 2327 ..............................44
11. Acknowledgements ..............................................45
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................46
5. SDP Specification ...............................................7
5.1. Protocol Version ("v=") ...................................10
5.2. Origin ("o=") .............................................11
5.3. Session Name ("s=") .......................................12
5.4. Session Information ("i=") ................................12
5.5. URI ("u=") ................................................13
5.6. Email Address and Phone Number ("e=" and "p=") ............13
5.7. Connection Data ("c=") ....................................14
5.8. Bandwidth ("b=") ..........................................16
5.9. Timing ("t=") .............................................17
5.10. Repeat Times ("r=") ......................................18
5.11. Time Zones ("z=") ........................................19
5.12. Encryption Keys ("k=") ...................................19
5.13. Attributes ("a=") ........................................21
5.14. Media Descriptions ("m=") ................................22
6. SDP Attributes .................................................24
7. Security Considerations ........................................31
8. IANA Considerations ............................................33
8.1. The "application/sdp" Media Type ..........................33
8.2. Registration of Parameters ................................34
8.2.1. Media Types ("media") ..............................34
8.2.2. Transport Protocols ("proto") ......................34
8.2.3. Media Formats ("fmt") ..............................35
8.2.4. Attribute Names ("att-field") ......................36
8.2.5. Bandwidth Specifiers ("bwtype") ....................37
8.2.6. Network Types ("nettype") ..........................37
8.2.7. Address Types ("addrtype") .........................38
8.2.8. Registration Procedure .............................38
8.3. Encryption Key Access Methods .............................39
9. SDP Grammar ....................................................39
10. Summary of Changes from RFC 2327 ..............................44
11. Acknowledgements ..............................................45
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................46
When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants.
启动多媒体电话会议、IP语音通话、流式视频或其他会话时，需要向参与者传达媒体详细信息、传输地址和其他会话描述元数据。
SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description -- it does not incorporate a transport protocol, and it is intended to use different transport protocols as appropriate, including the Session Announcement Protocol [14], Session Initiation Protocol [15], Real Time Streaming Protocol [16], electronic mail using the MIME extensions, and the Hypertext Transport Protocol.
SDP为此类信息提供了标准表示形式，而不管该信息是如何传输的。SDP纯粹是一种用于会话描述的格式——它不包含传输协议，并打算根据需要使用不同的传输协议，包括会话公告协议[14]、会话启动协议[15]、实时流协议[16]、使用MIME扩展的电子邮件、，以及超文本传输协议。
SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description.
SDP是通用的，因此可以在广泛的网络环境和应用中使用。但是，它并不打算支持会话内容或媒体编码的协商：这被视为超出会话描述的范围。
This memo obsoletes RFC 2327 [6] and RFC 3266 [10]. Section 10 outlines the changes introduced in this memo.
本备忘录废除了RFC 2327[6]和RFC 3266[10]。第10节概述了本备忘录中引入的变更。
The following terms are used in this document and have specific meaning within the context of this document.
以下术语在本文件中使用，在本文件上下文中具有特定含义。
Conference: A multimedia conference is a set of two or more communicating users along with the software they are using to communicate.
会议：多媒体会议是由两个或两个以上的通信用户以及他们用来通信的软件组成的集合。
Session: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session.
会话：多媒体会话是一组多媒体发送方和接收方以及从发送方流向接收方的数据流。多媒体会议是多媒体会话的一个示例。
Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session.
会话描述：一种定义良好的格式，用于传递足够的信息以发现和参与多媒体会话。
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 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
The Session Initiation Protocol (SIP) [15] is an application-layer control protocol for creating, modifying, and terminating sessions such as Internet multimedia conferences, Internet telephone calls, and multimedia distribution. The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. These session descriptions are commonly formatted using SDP. When used with SIP, the offer/answer model [17] provides a limited framework for negotiation using SDP.
会话发起协议（SIP）[15]是一种应用层控制协议，用于创建、修改和终止会话，如Internet多媒体会议、Internet电话呼叫和多媒体分发。用于创建会话的SIP消息包含会话描述，允许参与者就一组兼容的媒体类型达成一致。这些会话描述通常使用SDP格式化。当与SIP一起使用时，提供/应答模型[17]为使用SDP进行协商提供了有限的框架。
The Real Time Streaming Protocol (RTSP) [16], is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters.
实时流协议（RTSP）[16]是一种应用程序级协议，用于控制具有实时属性的数据传输。RTSP提供了一个可扩展的框架，以支持实时数据（如音频和视频）的受控按需交付。RTSP客户端和服务器协商一组适当的媒体交付参数，部分使用SDP语法来描述这些参数。
Alternative means of conveying session descriptions include electronic mail and the World Wide Web (WWW). For both email and WWW distribution, the media type "application/sdp" is used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner.
传达会话描述的其他方式包括电子邮件和万维网（WWW）。对于电子邮件和WWW分发，使用媒体类型“应用程序/sdp”。这使得能够以标准方式从WWW客户端或邮件阅读器自动启动参与会话的应用程序。
Note that announcements of multicast sessions made only via email or the WWW do not have the property that the receiver of a session announcement can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope.
注意，仅通过电子邮件或WWW进行的多播会话的通知不具有会话通知的接收者必然能够接收会话的属性，因为多播会话可能在范围内受到限制，并且可以在该范围之外访问WWW服务器或接收电子邮件。
In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically sends packets containing a description of the session to a well-known multicast group. These advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session.
为了协助多播多媒体会议和其他多播会话的广告，并将相关会话设置信息传达给预期参与者，可以使用分布式会话目录。这样的会话目录的实例周期性地将包含会话描述的包发送到众所周知的多播组。这些播发由其他会话目录接收，以便潜在的远程参与者可以使用会话描述启动参与会话所需的工具。
One protocol used to implement such a distributed directory is the Session Announcement Protocol (SAP) [14]. SDP provides the recommended session description format for such session announcements.
用于实现这种分布式目录的一个协议是会话公告协议（SAP）[14]。SDP为此类会话公告提供了建议的会话描述格式。
The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. Media streams can be many-to-many. Sessions need not be continually active.
SDP的目的是在多媒体会话中传送关于媒体流的信息，以允许会话描述的接收者参与会话。SDP主要用于互联网，尽管它具有足够的通用性，可以描述其他网络环境中的会议。媒体流可以是多对多。会话不需要一直处于活动状态。
Thus far, multicast-based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and it is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant.
到目前为止，Internet上基于多播的会话不同于许多其他形式的会议，因为任何接收通信的人都可以加入会话（除非会话通信被加密）。在这样的环境中，SDP有两个主要目的。它是一种传达会话存在性的手段，也是一种传达足够信息以加入和参与会话的手段。在单播环境中，只有后一个目的可能是相关的。
An SDP session description includes the following:
SDP会话描述包括以下内容：
o Session name and purpose
o 会话名称和目的
o Time(s) the session is active
o 会话处于活动状态的时间
o The media comprising the session
o 组成会议的媒体
o Information needed to receive those media (addresses, ports, formats, etc.)
o 接收这些媒体所需的信息（地址、端口、格式等）
As resources necessary to participate in a session may be limited, some additional information may also be desirable:
由于参加一次会议所需的资源可能有限，还需要一些额外的信息：
o Information about the bandwidth to be used by the session
o 有关会话要使用的带宽的信息
o Contact information for the person responsible for the session
o 会议负责人的联系信息
In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to any non-participants that may need to know. (This latter feature is primarily useful when SDP is used with a multicast session announcement protocol.)
通常，SDP必须传递足够的信息，使应用程序能够加入会话（加密密钥可能除外），并向可能需要知道的任何非参与者宣布要使用的资源。（当SDP与多播会话公告协议一起使用时，后一个功能主要有用。）
An SDP session description includes the following media information:
SDP会话描述包括以下媒体信息：
o The type of media (video, audio, etc.)
o 媒体类型（视频、音频等）
o The transport protocol (RTP/UDP/IP, H.320, etc.)
o 传输协议（RTP/UDP/IP、H.320等）
o The format of the media (H.261 video, MPEG video, etc.)
o 媒体格式（H.261视频、MPEG视频等）
In addition to media format and transport protocol, SDP conveys address and port details. For an IP multicast session, these comprise:
除了媒体格式和传输协议外，SDP还传递地址和端口详细信息。对于IP多播会话，它们包括：
o The multicast group address for media
o 媒体的多播组地址
o The transport port for media
o 媒体的传输端口
This address and port are the destination address and destination port of the multicast stream, whether being sent, received, or both.
此地址和端口是多播流的目标地址和目标端口，无论是发送的还是接收的，或者两者都是。
For unicast IP sessions, the following are conveyed:
对于单播IP会话，传达以下信息：
o The remote address for media
o 媒体的远程地址
o The remote transport port for media
o 媒体的远程传输端口
The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote address and remote port to which data is sent. Some media types may redefine this behaviour, but this is NOT RECOMMENDED since it complicates implementations (including middleboxes that must parse the addresses to open Network Address Translation (NAT) or firewall pinholes).
此地址和端口的语义取决于定义的媒体和传输协议。默认情况下，这应该是数据发送到的远程地址和远程端口。某些媒体类型可能会重新定义此行为，但不建议这样做，因为这会使实现复杂化（包括必须解析地址才能打开网络地址转换（NAT）或防火墙针孔的中间盒）。
Sessions may be either bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey:
会话在时间上可以是有界的，也可以是无界的。无论它们是否有界，它们可能仅在特定时间处于活动状态。SDP可以传达：
o An arbitrary list of start and stop times bounding the session
o 会话边界的开始和停止时间的任意列表
o For each bound, repeat times such as "every Wednesday at 10am for one hour"
o 对于每次出行，重复“每周三上午10点，持续一小时”等时间
This timing information is globally consistent, irrespective of local time zone or daylight saving time (see Section 5.9).
无论当地时区或夏令时如何，该计时信息都是全局一致的（见第5.9节）。
It is possible to create both public sessions and private sessions. SDP itself does not distinguish between these; private sessions are typically conveyed by encrypting the session description during distribution. The details of how encryption is performed are dependent on the mechanism used to convey SDP; mechanisms are currently defined for SDP transported using SAP [14] and SIP [15], and others may be defined in the future.
可以创建公共会话和私有会话。SDP本身并不区分这些；私有会话通常通过在分发期间加密会话描述来传输。如何执行加密的细节取决于用于传输SDP的机制；目前使用SAP[14]和SIP[15]为SDP传输定义了机制，将来可能会定义其他机制。
If a session announcement is private, it is possible to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to know which encryption scheme is used for each media.
如果会话公告是私有的，则可以使用该私有公告来传送对会议中的每个媒体进行解码所需的加密密钥，包括足够的信息来知道每个媒体使用哪种加密方案。
A session description should convey enough information to decide whether or not to participate in a session. SDP may include additional pointers in the form of Uniform Resource Identifiers (URIs) for more information about the session.
会话描述应传达足够的信息，以决定是否参加会话。SDP可以包括统一资源标识符（uri）形式的附加指针，以获得关于会话的更多信息。
When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter session announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated (the "a=cat:" attribute; see Section 6).
当SAP或任何其他播发机制正在分发许多会话描述时，可能需要从那些不感兴趣的会话公告中筛选感兴趣的会话公告。SDP支持会话的分类机制，该机制能够实现自动化（“a=cat:”属性；请参见第6节）。
The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding [5] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalisation only applies to free-text fields (session name and background information), and not to SDP as a whole.
SDP规范建议在UTF-8编码中使用ISO10646字符集[5]，以允许表示多种不同的语言。然而，为了有助于紧凑表示，SDP还允许在需要时使用其他字符集，如ISO 8859-1。国际化仅适用于自由文本字段（会话名称和背景信息），而不适用于整个SDP。
An SDP session description is denoted by the media type "application/sdp" (See Section 8).
SDP会话描述由媒体类型“应用程序/SDP”表示（参见第8节）。
An SDP session description is entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII subset of UTF-8, but textual fields and attribute values MAY use the full ISO 10646 character set. Field and
SDP会话描述完全是使用UTF-8编码的ISO10646字符集的文本。SDP字段名和属性名仅使用UTF-8的US-ASCII子集，但文本字段和属性值可能使用完整的ISO 10646字符集。场与
attribute values that use the full UTF-8 character set are never directly compared, hence there is no requirement for UTF-8 normalisation. The textual form, as opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance portability, to enable a variety of transports to be used, and to allow flexible, text-based toolkits to be used to generate and process session descriptions. However, since SDP may be used in environments where the maximum permissible size of a session description is limited, the encoding is deliberately compact. Also, since announcements may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed session announcements that could be detected easily and discarded. This also allows rapid discarding of encrypted session announcements for which a receiver does not have the correct key.
使用完整UTF-8字符集的属性值从不直接比较，因此不需要UTF-8规范化。与ASN.1或XDR等二进制编码不同，选择文本形式是为了增强可移植性，使用各种传输，并允许使用灵活的基于文本的工具包来生成和处理会话描述。然而，由于SDP可用于会话描述的最大允许大小受到限制的环境中，因此编码故意紧凑。此外，由于公告可能通过非常不可靠的方式传输或被中间缓存服务器损坏，因此编码的设计具有严格的顺序和格式规则，因此大多数错误都会导致格式错误的会话公告，很容易被检测到并丢弃。这还允许快速丢弃接收方没有正确密钥的加密会话通知。
An SDP session description consists of a number of lines of text of the form:
SDP会话描述由以下格式的多行文本组成：
<type>=<value>
<type>=<value>
where <type> MUST be exactly one case-significant character and <value> is structured text whose format depends on <type>. In general, <value> is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace MUST NOT be used on either side of the "=" sign.
其中<type>必须正好是一个区分大小写的字符，<value>是格式取决于<type>的结构化文本。通常，<value>是由单个空格字符或自由格式字符串分隔的多个字段，除非特定字段另有定义，否则它是区分大小写的。不能在“=”符号的两侧使用空格。
An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a "v=" line and continues to the first media-level section. Each media-level section starts with an "m=" line and continues to the next media-level section or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value.
SDP会话描述由会话级部分和零个或多个媒体级部分组成。会话级别部分以“v=”行开始，并继续到第一个媒体级别部分。每个媒体级别部分都以“m=”行开头，然后继续到下一个媒体级别部分或整个会话描述的结尾。通常，会话级别值是所有介质的默认值，除非被等效介质级别值覆盖。
Some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a "*".
每个描述中的一些行是必需的，一些是可选的，但所有行都必须完全按照此处给出的顺序出现（固定顺序大大增强了错误检测，并允许使用简单的解析器）。可选项目用“*”标记。
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore any session description that contains a type letter that it does not understand. The attribute mechanism ("a=" described below) is the primary means for extending SDP and tailoring it to particular applications or media. Some attributes (the ones listed in Section 6 of this memo) have a defined meaning, but others may be added on an application-, media-, or session-specific basis. An SDP parser MUST ignore any attribute it doesn't understand.
类型字母的集合故意很小，不打算扩展——SDP解析器必须完全忽略任何包含它不理解的类型字母的会话描述。属性机制（“a=”如下所述）是扩展SDP并使其适应特定应用程序或媒体的主要手段。某些属性（本备忘录第6节中列出的属性）具有定义的含义，但其他属性可以根据应用程序、媒体或会话的具体情况添加。SDP解析器必须忽略它不理解的任何属性。
An SDP session description may contain URIs that reference external content in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in some cases, making the session description non-self-contained.
SDP会话描述可能包含引用“u=”、“k=”和“a=”行中的外部内容的URI。在某些情况下，这些URI可能会被取消引用，从而使会话描述不自包含。
The connection ("c=") and attribute ("a=") information in the session-level section applies to all the media of that session unless overridden by connection information or an attribute of the same name in the media description. For instance, in the example below, each media behaves as if it were given a "recvonly" attribute.
会话级别部分中的连接（“c=”）和属性（“a=”）信息适用于该会话的所有媒体，除非被连接信息或媒体描述中的同名属性覆盖。例如，在下面的示例中，每个媒体的行为都好像被赋予了“recvonly”属性。
An example SDP description is:
SDP描述示例如下：
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
Text fields such as the session name and information are octet strings that may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers SHOULD be tolerant and also accept records terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding (the presence of the "a=charset" attribute may force some fields to be interpreted differently).
会话名称和信息等文本字段是八位字节字符串，可以包含任何八位字节，但0x00（Nul）、0x0a（ASCII换行符）和0x0d（ASCII回车符）除外。序列CRLF（0x0d0a）用于结束记录，尽管解析器应该是宽容的，并且也接受以单个换行符终止的记录。如果不存在“a=charset”属性，则必须将这些八位字节字符串解释为包含UTF-8编码的ISO-10646字符（存在“a=charset”属性可能会强制对某些字段进行不同的解释）。
A session description can contain domain names in the "o=", "u=", "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply with [1], [2]. Internationalised domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in [11] and MUST NOT be directly represented in UTF-8 or any other encoding (this requirement is for compatibility with RFC 2327 and other SDP-related standards, which predate the development of internationalised domain names).
会话描述可以在“o=”、“u=”、“e=”、“c=”和“A=”行中包含域名。SDP中使用的任何域名必须符合[1]、[2]。国际化域名（IDN）必须使用[11]中定义的ASCII兼容编码（ACE）形式表示，不得直接用UTF-8或任何其他编码表示（此要求是为了与RFC 2327和其他SDP相关标准兼容，这些标准早于国际化域名的开发）。
v=0
v=0
The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number.
“v=”字段给出会话描述协议的版本。此备忘录定义了版本0。没有次要版本号。
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
The "o=" field gives the originator of the session (her username and the address of the user's host) plus a session identifier and version number:
“o=”字段提供会话的发起人（她的用户名和用户主机的地址）以及会话标识符和版本号：
<username> is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user IDs. The <username> MUST NOT contain spaces.
<username>是用户在发起主机上的登录名，如果发起主机不支持用户ID的概念，则为“-”。<username>不能包含空格。
<sess-id> is a numeric string such that the tuple of <username>, <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a globally unique identifier for the session. The method of <sess-id> allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) format timestamp be used to ensure uniqueness [13].
<sess id>是一个数字字符串，使得<username>、<sess id>、<nettype>、<addrtype>和<unicast address>的元组构成会话的全局唯一标识符。<sess id>分配方法由创建工具决定，但有人建议使用网络时间协议（NTP）格式的时间戳来确保唯一性[13]。
<sess-version> is a version number for this session description. Its usage is up to the creating tool, so long as <sess-version> is increased when a modification is made to the session data. Again, it is RECOMMENDED that an NTP format timestamp is used.
<sess version>是此会话描述的版本号。它的使用取决于创建工具，只要在修改会话数据时增加<sess version>。同样，建议使用NTP格式的时间戳。
<nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8).
<nettype>是一个给出网络类型的文本字符串。最初，“IN”定义为“互联网”，但将来可能会注册其他值（见第8节）。
<addrtype> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 8).
<addrtype>是一个文本字符串，给出以下地址的类型。最初定义了“IP4”和“IP6”，但将来可能会注册其他值（见第8节）。
<unicast-address> is the address of the machine from which the session was created. For an address type of IP4, this is either the fully qualified domain name of the machine or the dotted-decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully qualified domain name of the machine or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful (for example, a local address MUST NOT be included in an application-level referral that might leave the scope).
<unicast address>是从中创建会话的计算机的地址。对于IP 4的地址类型，这是机器的完全限定域名或机器IP版本4地址的点十进制表示。对于IP 6的地址类型，这是机器的完全限定域名或机器IP版本6地址的压缩文本表示。对于IP4和IP6，完全限定域名是应该给出的形式，除非不可用，在这种情况下，可以替换全局唯一地址。本地IP地址不得用于SDP描述可能离开该地址有意义的作用域的任何上下文中（例如，本地地址不得包含在可能离开该作用域的应用程序级引用中）。
In general, the "o=" field serves as a globally unique identifier for this version of this session description, and the subfields excepting the version taken together identify the session irrespective of any modifications.
通常，“o=”字段用作此会话描述版本的全局唯一标识符，并且除一起使用的版本外的子字段标识会话，而不考虑任何修改。
For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary <username> and private <unicast-address> MAY be chosen to populate the "o=" field, provided that these are selected in a manner that does not affect the global uniqueness of the field.
出于隐私原因，有时需要混淆会话发起人的用户名和IP地址。如果这是一个问题，可以选择任意<username>和私有<unicast address>来填充“o=”字段，前提是选择这些字段的方式不会影响字段的全局唯一性。
s=<session name>
s=<session name>
The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e., a single space as the session name).
“s=”字段是文本会话名称。每个会话描述必须有且只有一个“s=”字段。“s=”字段不能为空，并且应包含ISO10646字符（但也请参见“a=charset”属性）。如果会话没有有意义的名称，则应使用值“s=（即，一个空格作为会话名称）。
i=<session description>
i=<session description>
The "i=" field provides textual information about the session. There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If the "a=charset" attribute is not present, the "i=" field MUST contain ISO 10646 characters in UTF-8 encoding.
“i=”字段提供有关会话的文本信息。每个会话描述最多只能有一个会话级别“i=”字段，每个媒体最多只能有一个“i=”字段。如果存在“a=charset”属性，则它指定“i=”字段中使用的字符集。如果“a=charset”属性不存在，“i=”字段必须包含UTF-8编码的ISO 10646字符。
A single "i=" field MAY also be used for each media definition. In media definitions, "i=" fields are primarily intended for labelling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions.
每个媒体定义也可以使用一个“i=”字段。在媒体定义中，“i=”字段主要用于标记媒体流。因此，当单个会话具有多个相同媒体类型的不同媒体流时，它们最有可能有用。一个例子是两个不同的白板，一个用于幻灯片，一个用于反馈和问题。
The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata.
“i=”字段旨在提供会话或媒体流用途的自由形式的人类可读描述。它不适合用自动机进行解析。
u=<uri>
u=<uri>
A URI is a Uniform Resource Identifier as used by WWW clients [7]. The URI should be a pointer to additional information about the session. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description.
URI是WWW客户端使用的统一资源标识符[7]。URI应该是指向有关会话的其他信息的指针。此字段是可选的，但如果存在，则必须在第一个媒体字段之前指定。每个会话描述不允许超过一个URI字段。
e=<email-address>
p=<phone-number>
e=<email-address>
p=<phone-number>
The "e=" and "p=" lines specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement.
“e=”和“p=”行指定会议负责人的联系信息。这不一定是创建会议公告的同一个人。
Inclusion of an email address or phone number is OPTIONAL. Note that the previous version of SDP specified that either an email field or a phone field MUST be specified, but this was widely ignored. The change brings the specification into line with common usage.
包含电子邮件地址或电话号码是可选的。请注意，以前版本的SDP指定必须指定电子邮件字段或电话字段，但这被广泛忽略。这一变化使规范与常用规范保持一致。
If an email address or phone number is present, it MUST be specified before the first media field. More than one email or phone field can be given for a session description.
如果存在电子邮件地址或电话号码，则必须在第一个媒体字段之前指定。可以为会话描述提供多个电子邮件或电话字段。
Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164) preceded by a "+". Spaces and hyphens may be used to split up a phone field to aid readability if desired. For example:
电话号码应以国际公共电信号码（见ITU-T建议E.164）的形式给出，前面加“+”。如果需要，可以使用空格和连字符分隔电话字段，以提高可读性。例如：
p=+1 617 555-6011
p=+1617555-6011
Both email addresses and phone numbers can have an OPTIONAL free text string associated with them, normally giving the name of the person who may be contacted. This MUST be enclosed in parentheses if it is present. For example:
电子邮件地址和电话号码都可以有一个可选的自由文本字符串与之关联，通常给出可能联系的人的姓名。如果有，必须用括号括起来。例如：
e=j.doe@example.com (Jane Doe)
e=j。doe@example.com（无名氏）
The alternative RFC 2822 [29] name quoting convention is also allowed for both email addresses and phone numbers. For example:
电子邮件地址和电话号码也允许使用RFC 2822[29]名称引用约定。例如：
e=Jane Doe <j.doe@example.com>
e=Jane Doe <j.doe@example.com>
The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate session-level "a=charset" attribute is set.
自由文本字符串应采用UTF-8编码的ISO-10646字符集，或者，如果设置了适当的会话级别“a=charset”属性，则应采用ISO-8859-1或其他编码。
c=<nettype> <addrtype> <connection-address>
c=<nettype> <addrtype> <connection-address>
The "c=" field contains connection data.
“c=”字段包含连接数据。
A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media.
会话描述必须在每个媒体描述中至少包含一个“c=”字段，或者在会话级别包含一个“c=”字段。它可能包含单个会话级别“c=”字段和每个介质描述的附加“c=”字段，在这种情况下，每介质值将覆盖相应介质的会话级别设置。
The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8).
第一个子字段（“<nettype>”）是网络类型，它是给出网络类型的文本字符串。最初，“IN”的定义是指“互联网”，但将来可能会注册其他值（见第8节）。
The second sub-field ("<addrtype>") is the address type. This allows SDP to be used for sessions that are not IP based. This memo only defines IP4 and IP6, but other values MAY be registered in the future (see Section 8).
第二个子字段（“<addrtype>”）是地址类型。这允许SDP用于非基于IP的会话。本备忘录仅定义了IP4和IP6，但将来可能会注册其他值（见第8节）。
The third sub-field ("<connection-address>") is the connection address. OPTIONAL sub-fields MAY be added after the connection address depending on the value of the <addrtype> field.
第三个子字段（“<connection address>”）是连接地址。根据<addrtype>字段的值，可以在连接地址之后添加可选子字段。
When the <addrtype> is IP4 and IP6, the connection address is defined as follows:
当<addrtype>为IP4和IP6时，连接地址定义如下：
o If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited.
o 如果会话是多播，则连接地址将是IP多播组地址。如果会话不是多播，则连接地址包含由其他属性字段确定的预期数据源或数据中继或数据接收器的单播IP地址。不期望在通过多播公告进行通信的会话描述中给出单播地址，尽管这并不是禁止的。
o Sessions using an IPv4 multicast connection address MUST also have a time to live (TTL) value present in addition to the multicast address. The TTL and the address together define the scope with which multicast packets sent in this conference will be sent. TTL values MUST be in the range 0-255. Although the TTL MUST be specified, its use to scope multicast traffic is deprecated;
o 使用IPv4多播连接地址的会话除了多播地址外，还必须具有生存时间（TTL）值。TTL和地址一起定义了在此会议中发送的多播数据包的范围。TTL值必须在0-255范围内。尽管必须指定TTL，但不推荐将其用于作用域多播流量；
applications SHOULD use an administratively scoped address instead.
应用程序应改为使用管理范围的地址。
The TTL for the session is appended to the address using a slash as a separator. An example is:
会话的TTL使用斜杠作为分隔符附加到地址。例如：
c=IN IP4 224.2.36.42/127
c=在IP4224.2.36.42/127中
IPv6 multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for IPv6 multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of conferences.
IPv6多播不使用TTL作用域，因此IPv6多播不能存在TTL值。预计IPv6作用域地址将用于限制会议的范围。
Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality (and hence bandwidth) by only subscribing to a subset of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. For applications requiring multiple multicast groups, we allow the following notation to be used for the connection address:
分层或分层编码方案是数据流，其中来自单个媒体源的编码被分成若干层。接收机可以通过只订阅这些层的子集来选择所需的质量（以及带宽）。这种分层编码通常在多个多播组中传输，以允许多播修剪。这种技术只需要一定层次结构的站点就可以保持不需要的流量。对于需要多个多播组的应用程序，我们允许将以下符号用于连接地址：
<base multicast address>[/<ttl>]/<number of addresses>
<base multicast address>[/<ttl>]/<number of addresses>
If the number of addresses is not given, it is assumed to be one. Multicast addresses so assigned are contiguously allocated above the base address, so that, for example:
如果未给出地址数，则假定为一个。这样分配的多播地址在基址上方连续分配，例如：
c=IN IP4 224.2.1.1/127/3
c=IN IP4 224.2.1.1/127/3
would state that addresses 224.2.1.1, 224.2.1.2, and 224.2.1.3 are to be used at a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description:
将说明地址224.2.1.1、224.2.1.2和224.2.1.3将以127的TTL使用。这在语义上与在媒体描述中包含多个“c=”行相同：
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127
Similarly, an IPv6 example would be:
类似地，IPv6示例如下：
c=IN IP6 FF15::101/3
c=IN IP6 FF15::101/3
which is semantically equivalent to:
语义上等同于：
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103
(remembering that the TTL field is not present in IPv6 multicast).
（请记住，IPv6多播中不存在TTL字段）。
Multiple addresses or "c=" lines MAY be specified on a per-media basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. They MUST NOT be specified for a session-level "c=" field.
仅当多个地址或“c=”行在分层或分层编码方案中为不同层提供多播地址时，才可以按媒体指定多个地址或“c=”行。不能为会话级别“c=”字段指定它们。
The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses.
上述多个地址的斜杠符号不得用于IP单播地址。
b=<bwtype>:<bandwidth>
b=<bwtype>:<bandwidth>
This OPTIONAL field denotes the proposed bandwidth to be used by the session or media. The <bwtype> is an alphanumeric modifier giving the meaning of the <bandwidth> figure. Two values are defined in this specification, but other values MAY be registered in the future (see Section 8 and [21], [25]):
此可选字段表示会话或媒体使用的建议带宽。<bwtype>是一个字母数字修饰符，给出了<bandwidth>图的含义。本规范中定义了两个值，但将来可能会注册其他值（参见第8节和[21]、[25]）：
CT If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=CT:..." line SHOULD be supplied for the session giving the proposed upper limit to the bandwidth used (the "conference total" bandwidth). The primary purpose of this is to give an approximate idea as to whether two or more sessions can coexist simultaneously. When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions.
CT如果会话或会话中媒体的带宽与作用域中隐含的带宽不同，则应为会话提供“b=CT:…”行，给出所用带宽的建议上限（“会议总”带宽）。其主要目的是给出两个或多个会话是否可以同时共存的大致概念。将CT修改器与RTP一起使用时，如果多个RTP会话是会议的一部分，则会议总数指所有RTP会话的总带宽。
AS The bandwidth is interpreted to be application specific (it will be the application's concept of maximum bandwidth). Normally, this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP-based applications, AS gives the RTP "session bandwidth" as defined in Section 6.2 of [19].
由于带宽被解释为特定于应用程序（它将是应用程序的最大带宽概念）。通常，如果适用，这将与应用程序的“最大带宽”控件上设置的内容一致。对于基于RTP的应用，AS给出了[19]第6.2节中定义的RTP“会话带宽”。
Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously.
请注意，CT给出了所有站点上所有媒体的总带宽数字。AS给出了单个站点上单个媒体的带宽数字，尽管可能有多个站点同时发送。
A prefix "X-" is defined for <bwtype> names. This is intended for experimental purposes only. For example:
为<bwtype>名称定义前缀“X-”。这仅用于实验目的。例如：
b=X-YZ:128
b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers SHOULD be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST be alphanumeric and, although no length limit is given, it is recommended that they be short.
不建议使用“X-”前缀：相反，新的修饰符应该在标准名称空间中向IANA注册。SDP解析器必须忽略具有未知修饰符的带宽字段。修饰符必须是字母数字，虽然没有给出长度限制，但建议缩短。
The <bandwidth> is interpreted as kilobits per second by default. The definition of a new <bwtype> modifier MAY specify that the bandwidth is to be interpreted in some alternative unit (the "CT" and "AS" modifiers defined in this memo use the default units).
默认情况下，<bandwidth>被解释为千比特每秒。新的<bwtype>修饰符的定义可以指定带宽以某种替代单位解释（本备忘录中定义的“CT”和“AS”修饰符使用默认单位）。
t=<start-time> <stop-time>
t=<start-time> <stop-time>
The "t=" lines specify the start and stop times for a session. Multiple "t=" lines MAY be used if a session is active at multiple irregularly spaced times; each additional "t=" line specifies an additional period of time for which the session will be active. If the session is active at regular times, an "r=" line (see below) should be used in addition to, and following, a "t=" line -- in which case the "t=" line specifies the start and stop times of the repeat sequence.
“t=”行指定会话的开始和停止时间。如果会话在多个不规则间隔的时间处于活动状态，则可以使用多个“t=”行；每个附加的“t=”行指定会话活动的附加时间段。如果会话在正常时间处于活动状态，则除了“t=”行之外，还应使用“r=”行（见下文）——在这种情况下，“t=”行指定重复序列的开始和停止时间。
The first and second sub-fields give the start and stop times, respectively, for the session. These values are the decimal representation of Network Time Protocol (NTP) time values in seconds since 1900 [13]. To convert these values to UNIX time, subtract decimal 2208988800.
第一和第二个子字段分别给出会话的开始和停止时间。这些值是自1900年以来以秒为单位的网络时间协议（NTP）时间值的十进制表示[13]。要将这些值转换为UNIX时间，请减去十进制2208988800。
NTP timestamps are elsewhere represented by 64-bit values, which wrap sometime in the year 2036. Since SDP uses an arbitrary length decimal representation, this should not cause an issue (SDP timestamps MUST continue counting seconds since 1900, NTP will use the value modulo the 64-bit limit).
NTP时间戳在其他地方由64位值表示，这些值在2036年的某个时候换行。由于SDP使用任意长度的十进制表示法，因此不应引起问题（SDP时间戳必须从1900年起继续计数秒，NTP将使用64位限制的模值）。
If the <stop-time> is set to zero, then the session is not bounded, though it will not become active until after the <start-time>. If the <start-time> is also zero, the session is regarded as permanent.
如果<stop time>设置为零，则会话不受限制，尽管它在<start time>之后才会变为活动状态。如果<start time>也为零，则会话被视为永久会话。
User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult.
用户界面应强烈阻止创建无限和永久会话，因为它们不提供会话实际何时终止的信息，因此会使调度变得困难。
The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time
当向用户显示未超时的无界会话时，一般假设无界会话将仅在距离当前时间半小时之前处于活动状态
or the session start time, whichever is the later. If behaviour other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end.
或会话开始时间，以较晚者为准。如果需要其他行为，则应给出结束时间，并在获得有关会话何时真正结束的新信息时进行适当修改。
Permanent sessions may be shown to the user as never being active unless there are associated repeat times that state precisely when the session will be active.
永久会话可能会向用户显示为从未处于活动状态，除非存在相关的重复时间，该重复时间正好表示会话将处于活动状态的时间。
r=<repeat interval> <active duration> <offsets from start-time>
r=<repeat interval> <active duration> <offsets from start-time>
"r=" fields specify repeat times for a session. For example, if a session is active at 10am on Monday and 11am on Tuesday for one hour each week for three months, then the <start-time> in the corresponding "t=" field would be the NTP representation of 10am on the first Monday, the <repeat interval> would be 1 week, the <active duration> would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" field stop time would be the NTP representation of the end of the last session three months later. By default, all fields are in seconds, so the "r=" and "t=" fields might be the following:
“r=”字段指定会话的重复时间。例如，如果一个会话在星期一上午10点和星期二上午11点处于活动状态，持续三个月，每周持续一小时，则相应“t=”字段中的<start time>将是第一个星期一上午10点的NTP表示，<repeat interval>将是1周，<active duration>将是1小时，偏移量为0和25小时。相应的“t=”字段停止时间将是三个月后最后一次会议结束时的NTP表示。默认情况下，所有字段均以秒为单位，因此“r=”和“t=”字段可能如下所示：
t=3034423619 3042462419 r=604800 3600 0 90000
t=3034423619 3042462419 r=604800 3600 90000
To make description more compact, times may also be given in units of days, hours, or minutes. The syntax for these is a number immediately followed by a single case-sensitive character. Fractional units are not allowed -- a smaller unit should be used instead. The following unit specification characters are allowed:
为了使描述更加简洁，时间也可以以天、小时或分钟为单位。它们的语法是一个数字，后跟一个区分大小写的字符。不允许使用分数单位——应使用更小的单位。允许使用以下装置规格字符：
d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness)
d-天（86400秒）小时（3600秒）米-分（60秒）秒-秒（允许完整）
Thus, the above session announcement could also have been written:
因此，上述会议公告也可以写成：
r=7d 1h 0 25h
r=7d 1h 0 25h
Monthly and yearly repeats cannot be directly specified with a single SDP repeat time; instead, separate "t=" fields should be used to explicitly list the session times.
不能使用单个SDP重复时间直接指定每月和每年的重复次数；相反，应使用单独的“t=”字段明确列出会话时间。
z=<adjustment time> <offset> <adjustment time> <offset> ....
z=<adjustment time> <offset> <adjustment time> <offset> ....
To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify offsets from the base time. This is required because different time zones change time at different times of day, different countries change to or from daylight saving time on different dates, and some countries do not have daylight saving time at all.
要计划跨越从夏令时到标准时间的更改或从夏令时到标准时间的更改的重复会话，必须指定与基准时间的偏移。这是必需的，因为不同的时区在一天中的不同时间更改时间，不同的国家在不同的日期更改为夏令时或从夏令时更改为夏令时，而有些国家根本没有夏令时。
Thus, in order to schedule a session that is at the same time winter and summer, it must be possible to specify unambiguously by whose time zone a session is scheduled. To simplify this task for receivers, we allow the sender to specify the NTP time that a time zone adjustment happens and the offset from the time when the session was first scheduled. The "z=" field allows the sender to specify a list of these adjustment times and offsets from the base time.
因此，为了安排在冬季和夏季同时举行的会议，必须能够明确指定会议安排的时区。为了简化接收方的此任务，我们允许发送方指定时区调整发生的NTP时间以及与首次调度会话时间的偏移量。“z=”字段允许发送方指定这些调整时间和与基准时间的偏移量的列表。
An example might be the following:
例如：
z=2882844526 -1h 2898848070 0
z=288284526-1h 2898848070 0
This specifies that at time 2882844526, the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 2898848070, the session's original time base is restored. Adjustments are always relative to the specified start time -- they are not cumulative. Adjustments apply to all "t=" and "r=" lines in a session description.
这指定在时间288284526时，计算会话重复时间的时基向后移动1小时，并且在时间2898848070时，恢复会话的原始时基。调整总是相对于指定的开始时间——它们不是累积的。调整适用于会话描述中的所有“t=”和“r=”行。
If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years' worth of adjustments in one session announcement.
如果一次会议可能持续几年，预计会议公告将定期修改，而不是在一次会议公告中传递几年的调整。
k=<method>
k=<method>:<encryption key>
k=<method>
k=<method>:<encryption key>
If transported over a secure and trusted channel, the Session Description Protocol MAY be used to convey encryption keys. A simple mechanism for key exchange is provided by the key field ("k="), although this is primarily supported for compatibility with older implementations and its use is NOT RECOMMENDED. Work is in progress to define new key exchange mechanisms for use with SDP [27] [28], and it is expected that new applications will use those mechanisms.
如果通过安全且可信的信道传输，则会话描述协议可用于传输加密密钥。密钥字段（“k=”）提供了一种简单的密钥交换机制，不过这主要是为了与旧的实现兼容，不建议使用。正在努力定义新的密钥交换机制，以便与SDP一起使用[27][28]，预计新的应用程序将使用这些机制。
A key field is permitted before the first media entry (in which case it applies to all media in the session), or for each media entry as required. The format of keys and their usage are outside the scope of this document, and the key field provides no way to indicate the encryption algorithm to be used, key type, or other information about the key: this is assumed to be provided by the higher-level protocol using SDP. If there is a need to convey this information within SDP, the extensions mentioned previously SHOULD be used. Many security protocols require two keys: one for confidentiality, another for integrity. This specification does not support transfer of two keys.
在第一个媒体条目之前（在这种情况下，它适用于会话中的所有媒体），或根据需要为每个媒体条目指定一个键字段。密钥的格式及其使用不在本文档的范围内，密钥字段无法指示要使用的加密算法、密钥类型或其他有关密钥的信息：假定这是由使用SDP的高级协议提供的。如果需要在SDP中传达此信息，则应使用前面提到的扩展。许多安全协议需要两个密钥：一个用于机密性，另一个用于完整性。本规范不支持两个密钥的传输。
The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given. The following methods are defined:
该方法指示用于通过外部手段或从给定的编码加密密钥获得可用密钥的机制。定义了以下方法：
k=clear:<encryption key>
k=clear:<encryption key>
The encryption key is included untransformed in this key field. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel. The encryption key is interpreted as text according to the charset attribute; use the "k=base64:" method to convey characters that are otherwise prohibited in SDP.
加密密钥未经转换包含在此密钥字段中。除非可以保证SDP通过安全通道传输，否则不得使用此方法。根据字符集属性将加密密钥解释为文本；使用“k=base64:”方法传递SDP中禁止的字符。
k=base64:<encoded encryption key>
k=base64:<encoded encryption key>
The encryption key is included in this key field but has been base64 encoded [12] because it includes characters that are prohibited in SDP. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel.
加密密钥包含在此密钥字段中，但已进行base64编码[12]，因为它包含SDP中禁止的字符。除非可以保证SDP通过安全通道传输，否则不得使用此方法。
k=uri:<URI to obtain key>
k=uri:<URI to obtain key>
A Uniform Resource Identifier is included in the key field. The URI refers to the data containing the key, and may require additional authentication before the key can be returned. When a request is made to the given URI, the reply should specify the encoding for the key. The URI is often an Secure Socket Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI ("https:"), although this is not required.
密钥字段中包含统一的资源标识符。URI指的是包含密钥的数据，在返回密钥之前可能需要额外的身份验证。当对给定URI发出请求时，应答应该指定密钥的编码。URI通常是受安全套接字层/传输层安全性（SSL/TLS）保护的HTTP URI（“https:”），尽管这不是必需的。
k=prompt
k=提示
No key is included in this SDP description, but the session or media stream referred to by this key field is encrypted. The user should be prompted for the key when attempting to join the session, and this user-supplied key should then be used to
此SDP描述中不包括密钥，但此密钥字段引用的会话或媒体流是加密的。尝试加入会话时，应提示用户输入密钥，然后应使用此用户提供的密钥
decrypt the media streams. The use of user-specified keys is NOT RECOMMENDED, since such keys tend to have weak security properties.
解密媒体流。不建议使用用户指定的密钥，因为此类密钥往往具有较弱的安全属性。
The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such a channel might be SDP embedded inside an S/MIME message or a TLS-protected HTTP session. It is important to ensure that the secure channel is with the party that is authorised to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to access the SDP.
除非可以保证SDP通过安全可靠的通道传输，否则不得使用密钥字段。此类通道的一个示例可能是嵌入在S/MIME消息或受TLS保护的HTTP会话中的SDP。重要的是要确保安全通道与被授权加入会话的一方（而不是中间人）在一起：如果使用缓存代理服务器，则重要的是要确保代理受信任或无法访问SDP。
a=<attribute>
a=<attribute>:<value>
a=<attribute>
a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both.
属性是扩展SDP的主要手段。属性可定义为用作“会话级”属性、“媒体级”属性，或两者兼而有之。
A media description may have any number of attributes ("a=" fields) that are media specific. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media.
介质描述可以具有任意数量的特定于介质的属性（“A=”字段）。这些属性称为“媒体级别”属性，并添加有关媒体流的信息。属性字段也可以添加到第一个媒体字段之前；这些“会话级别”属性传达的附加信息适用于整个会议，而不是个别媒体。
Attribute fields may be of two forms:
属性字段可以有两种形式：
o A property attribute is simply of the form "a=<flag>". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly".
o 属性属性的形式仅为“A=<flag>”。这些是二进制属性，属性的存在表示该属性是会话的属性。例如，“a=recvonly”。
o A value attribute is of the form "a=<attribute>:<value>". For example, a whiteboard could have the value attribute "a=orient: landscape"
o 值属性的形式为“A=<attribute>：<value>”。例如，白板可以具有值属性“a=方向：景观”
Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular.
属性解释取决于所调用的媒体工具。因此，会话描述的接收者在解释会话描述和属性时应该是可配置的。
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
属性名称必须使用ISO-10646/UTF-8的US-ASCII子集。
Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are to be interpreted as in ISO-10646 character set with UTF-8 encoding. Unlike other text fields, attribute values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be charset dependent, in which case its value should be interpreted in the session charset rather than in ISO-10646.
属性值是八位字节字符串，可以使用除0x00（Nul）、0x0A（LF）和0x0D（CR）之外的任何八位字节值。默认情况下，属性值将被解释为采用UTF-8编码的ISO-10646字符集。与其他文本字段不同，属性值通常不受“charset”属性的影响，因为这会使与已知值的比较出现问题。但是，定义属性时，可以将其定义为依赖于字符集，在这种情况下，其值应在会话字符集而不是ISO-10646中解释。
Attributes MUST be registered with IANA (see Section 8). If an attribute is received that is not understood, it MUST be ignored by the receiver.
属性必须向IANA注册（见第8节）。如果接收到不可理解的属性，则接收者必须忽略该属性。
m=<media> <port> <proto> <fmt> ...
m=<media><port><proto><fmt>。。。
A session description may contain a number of media descriptions. Each media description starts with an "m=" field and is terminated by either the next "m=" field or by the end of the session description. A media field has several sub-fields:
会话描述可以包含许多媒体描述。每个媒体描述以一个“m=”字段开始，并由下一个“m=”字段或会话描述结束时终止。媒体字段有几个子字段：
<media> is the media type. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future (see Section 8).
<media>是媒体类型。目前定义的媒体为“音频”、“视频”、“文本”、“应用程序”和“消息”，但该列表在将来可能会扩展（见第8节）。
<port> is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" field, and on the transport protocol defined in the <proto> sub-field of the media field. Other ports used by the media application (such as the RTP Control Protocol (RTCP) port [19]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example, "a=rtcp:" as defined in [22]).
<port>是媒体流发送到的传输端口。传输端口的含义取决于相关“c=”字段中指定的正在使用的网络，以及媒体字段的<proto>子字段中定义的传输协议。媒体应用程序使用的其他端口（例如RTP控制协议（RTCP）端口[19]）可以通过算法从基本媒体端口派生，或者可以在单独的属性中指定（例如，[22]中定义的“a=RTCP:”。
If non-contiguous ports are used or if they don't follow the parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute MUST be used. Applications that are requested to send media to a <port> that is odd and where the "a=rtcp:" is present MUST NOT subtract 1 from the RTP port: that is, they MUST send the RTP to the port indicated in <port> and send the RTCP to the port indicated in the "a=rtcp" attribute.
如果使用非连续端口，或者它们不遵循偶数RTP端口和奇数RTCP端口的奇偶校验规则，则必须使用“a=RTCP:”属性。请求将媒体发送到奇数且存在“a=rtcp:”的<port>的应用程序不得从RTP端口减去1：即，它们必须将RTP发送到<port>中指示的端口，并将rtcp发送到“a=rtcp”属性中指示的端口。
For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" field:
对于将分层编码流发送到单播地址的应用程序，可能需要指定多个传输端口。这是使用与“c=”字段中的IP多播地址类似的符号完成的：
m=<media> <port>/<number of ports> <proto> <fmt> ...
m=<media><port>/<number of ports><proto><fmt>。。。
In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session, and the <number of ports> denoting the number of RTP sessions. For example:
在这种情况下，使用的端口取决于传输协议。对于RTP，默认情况下，只有偶数端口用于数据，对应的一个较高的奇数端口用于属于RTP会话的RTCP，而<number of ports>表示RTP会话的数量。例如：
m=video 49170/2 RTP/AVP 31
m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). If non-contiguous ports are required, they must be signalled using a separate attribute (for example, "a=rtcp:" as defined in [22]).
将指定端口49170和49171形成一个RTP/RTCP对，49172和49173形成第二个RTP/RTCP对。RTP/AVP是传输协议，31是格式（见下文）。如果需要非连续端口，则必须使用单独的属性（例如，[22]中定义的“a=rtcp:”）向它们发送信号。
If multiple addresses are specified in the "c=" field and multiple ports are specified in the "m=" field, a one-to-one mapping from port to the corresponding address is implied. For example:
如果在“c=”字段中指定了多个地址，并且在“m=”字段中指定了多个端口，则表示从端口到相应地址的一对一映射。例如：
c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31
c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
这意味着地址224.2.1.1与端口49170和49171一起使用，地址224.2.1.2与端口49172和49173一起使用。
The semantics of multiple "m=" lines using the same transport address are undefined. This implies that, unlike limited past practice, there is no implicit grouping defined by such means and an explicit grouping framework (for example, [18]) should instead be used to express the intended semantics.
使用相同传输地址的多个“m=”行的语义未定义。这意味着，与有限的过去实践不同，不存在通过这种方式定义的隐式分组，而应该使用显式分组框架（例如，[18]）来表达预期的语义。
<proto> is the transport protocol. The meaning of the transport protocol is dependent on the address type field in the relevant "c=" field. Thus a "c=" field of IP4 indicates that the transport protocol runs over IP4. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 8):
<proto>是传输协议。传输协议的含义取决于相关“c=”字段中的地址类型字段。因此，IP4的“c=”字段表示传输协议在IP4上运行。定义了以下传输协议，但可通过向IANA注册新协议进行扩展（见第8节）：
* udp: denotes an unspecified protocol running over UDP.
* udp：表示在udp上运行的未指定协议。
* RTP/AVP: denotes RTP [19] used under the RTP Profile for Audio and Video Conferences with Minimal Control [20] running over UDP.
* RTP/AVP：表示在RTP配置文件下用于音频和视频会议的RTP[19]，具有通过UDP运行的最低控制[20]。
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [23] running over UDP.
* RTP/SAVP：表示在UDP上运行的安全实时传输协议[23]。
The main reason to specify the transport protocol in addition to the media format is that the same standard media formats may be carried over different transport protocols even when the network protocol is the same -- a historical example is vat Pulse Code Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible.
除了媒体格式之外，指定传输协议的主要原因是，即使网络协议相同，也可能在不同的传输协议上携带相同的标准媒体格式——历史上的一个例子是vat脉冲编码调制（PCM）音频和RTP PCM音频；另一种可能是TCP/RTP PCM音频。此外，还可以使用特定于传输协议但与格式无关的继电器和监视工具。
<fmt> is a media format description. The fourth and any subsequent sub-fields describe the format of the media. The interpretation of the media format depends on the value of the <proto> sub-field.
<fmt>是一种媒体格式描述。第四个和任何后续子字段描述媒体的格式。媒体格式的解释取决于<proto>子字段的值。
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session. For dynamic payload type assignments the "a=rtpmap:" attribute (see Section 6) SHOULD be used to map from an RTP payload type number to a media encoding name that identifies the payload format. The "a=fmtp:" attribute MAY be used to specify format parameters (see Section 6).
如果<proto>子字段为“RTP/AVP”或“RTP/SAVP”，则<fmt>子字段包含RTP有效负载类型编号。当给出有效负载类型编号的列表时，这意味着所有这些有效负载格式都可以在会话中使用，但这些格式中的第一种应用作会话的默认格式。对于动态有效负载类型分配，应使用“a=rtpmap:”属性（见第6节）将RTP有效负载类型编号映射到标识有效负载格式的媒体编码名称。“a=fmtp:”属性可用于指定格式参数（见第6节）。
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST reference a media type describing the format under the "audio", "video", "text", "application", or "message" top-level media types. The media type registration SHOULD define the packet format for use with UDP transport.
如果<proto>子字段为“udp”，则<fmt>子字段必须引用描述“音频”、“视频”、“文本”、“应用程序”或“消息”顶级媒体类型下格式的媒体类型。媒体类型注册应定义用于UDP传输的数据包格式。
For media using other transport protocols, the <fmt> field is protocol specific. Rules for interpretation of the <fmt> sub-field MUST be defined when registering new protocols (see Section 8.2.2).
对于使用其他传输协议的媒体，<fmt>字段是特定于协议的。注册新协议时，必须定义<fmt>子字段的解释规则（见第8.2.2节）。
The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4.
定义了以下属性。由于应用程序编写器可以根据需要添加新属性，因此此列表并不详尽。第8.2.4节定义了新属性的注册程序。
a=cat:<category>
a=cat:<category>
This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. It is a session-level attribute, and it is not dependent on charset.
此属性提供会话的点分隔层次类别。这是为了使接收器能够按类别过滤不需要的会话。没有类别的中央登记册。它是会话级属性，不依赖于字符集。
a=keywds:<keywords>
a=keywds:<keywords>
Like the cat attribute, this is to assist identifying wanted sessions at the receiver. This allows a receiver to select interesting session based on keywords describing the purpose of the session; there is no central registry of keywords. It is a session-level attribute. It is a charset-dependent attribute, meaning that its value should be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8.
与cat属性一样，这有助于在接收方识别想要的会话。这允许接收者基于描述会话目的的关键字选择感兴趣的会话；没有关键字的中央注册表。它是会话级属性。它是一个依赖于字符集的属性，这意味着如果指定了一个字符集，则应在为会话描述指定的字符集中解释它的值，或者默认情况下在ISO 10646/UTF-8中解释它的值。
a=tool:<name and version of tool>
a=tool:<name and version of tool>
This gives the name and version number of the tool used to create the session description. It is a session-level attribute, and it is not dependent on charset.
这将提供用于创建会话描述的工具的名称和版本号。它是会话级属性，不依赖于字符集。
a=ptime:<packet time>
a=ptime:<packet time>
This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media-level attribute, and it is not dependent on charset.
这给出了数据包中媒体表示的时间长度（以毫秒为单位）。这可能仅对音频数据有意义，但如果有意义，可以与其他媒体类型一起使用。无需知道解码RTP或vat音频的ptime，其目的是作为音频编码/打包的建议。它是媒体级属性，不依赖于字符集。
a=maxptime:<maximum packet time>
a=maxptime:<maximum packet time>
This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. For frame-based codecs, the time SHOULD be an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media-level attribute, and it is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non-updated implementations will ignore this attribute.
这将提供每个数据包中可封装的最大媒体量，以毫秒表示。时间应计算为数据包中存在的媒体代表的时间之和。对于基于帧的编解码器，时间应该是帧大小的整数倍。此属性可能仅对音频数据有意义，但如果有意义，可以与其他媒体类型一起使用。它是媒体级属性，不依赖于字符集。请注意，此属性是在RFC2327之后引入的，未更新的实现将忽略此属性。
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. It is a media-level attribute that is not dependent on charset.
此属性从RTP有效负载类型编号（在“m=”行中使用）映射到表示要使用的有效负载格式的编码名称。它还提供有关时钟速率和编码参数的信息。它是不依赖于字符集的媒体级属性。
Although an RTP profile may make static assignments of payload type numbers to payload formats, it is more common for that assignment to be done dynamically using "a=rtpmap:" attributes. As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as:
尽管RTP配置文件可能会将有效负载类型编号静态分配给有效负载格式，但更常见的是使用“a=rtpmap:”属性动态地完成分配。作为静态有效载荷类型的一个例子，考虑U-律PCM编码的单通道音频在8 kHz采样。这在RTP音频/视频配置文件中完全定义为有效负载类型0，因此不需要“a=rtpmap:”属性，发送到UDP端口49232的此类流的媒体可以指定为：
m=audio 49232 RTP/AVP 0
m=音频49232 RTP/AVP 0
An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it:
动态有效负载类型的一个示例是以16 kHz采样的16位线性编码立体声音频。如果我们希望对该流使用动态RTP/AVP有效负载类型98，则需要额外的信息来对其进行解码：
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
Up to one rtpmap attribute can be defined for each media format specified. Thus, we might have the following:
对于指定的每种媒体格式，最多可以定义一个rtpmap属性。因此，我们可能有以下情况：
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for encoding names, under the top-level media type denoted in the "m=" line. In the example above, the media types are "audio/l8" and "audio/l16".
指定使用动态有效负载类型的RTP配置文件必须定义一组有效的编码名称和/或注册编码名称的方法（如果该配置文件要与SDP一起使用）。“RTP/AVP”和“RTP/SAVP”配置文件在“m=”行中表示的顶级媒体类型下使用媒体子类型对名称进行编码。在上面的示例中，媒体类型是“audio/l8”和“audio/l16”。
For audio streams, <encoding parameters> indicates the number of audio channels. This parameter is OPTIONAL and may be omitted if the number of channels is one, provided that no additional parameters are needed.
对于音频流，<encoding parameters>表示音频通道的数量。此参数是可选的，如果通道数为一个，则可以忽略此参数，前提是不需要其他参数。
For video streams, no encoding parameters are currently specified.
对于视频流，当前未指定编码参数。
Additional encoding parameters MAY be defined in the future, but codec-specific parameters SHOULD NOT be added. Parameters added to an "a=rtpmap:" attribute SHOULD only be those required for a session directory to make the choice of appropriate media
将来可能会定义其他编码参数，但不应添加特定于编解码器的参数。添加到“a=rtpmap:”属性的参数应仅为会话目录选择适当媒体所需的参数
to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:").
参加会议。应在其他属性中添加特定于编解码器的参数（例如，“a=fmtp:”）。
Note: RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile) packetisation is required, the "ptime" attribute is used as given above.
注：RTP音频格式通常不包括有关每个数据包的采样数的信息。如果需要非默认（如RTP音频/视频配置文件中所定义）打包，则如上所述使用“ptime”属性。
a=recvonly
a=再次
This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media-level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets).
这指定工具应在适用的情况下以仅接收模式启动。它可以是会话级或媒体级属性，并且不依赖于字符集。请注意，RECVOLY仅适用于介质，不适用于任何相关的控制协议（例如，RECVOLY模式下基于RTP的系统仍应发送RTCP数据包）。
a=sendrecv
a=sendrecv
This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset.
这指定应在发送和接收模式下启动工具。对于具有默认为仅接收模式的工具的交互式会议，这是必需的。它可以是会话或媒体级属性，并且不依赖于字符集。
If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below).
如果“sendonly”、“RecVoOnly”、“inactive”和“sendrecv”属性均不存在，则对于非会议类型“broadcast”或“H332”的会话，应假定“sendrecv”为默认值（见下文）。
a=sendonly
a=仅发送
This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal.
这指定工具应在仅发送模式下启动。一个示例可能是，将对业务目的地使用不同于对业务源使用的单播地址。在这种情况下，可以使用两种媒体描述，一种仅发送，另一种仅接收。它可以是会话级或媒体级属性，但通常仅用作媒体属性。它不依赖于字符集。请注意，sendonly仅适用于介质，任何相关的控制协议（如RTCP）仍应正常接收和处理。
a=inactive
a=不活动
This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an
这指定应在非活动模式下启动工具。这对于交互式会议是必要的，用户可以在其中暂停其他用户。没有通过网络发送媒体
inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset.
非活动媒体流。请注意，基于RTP的系统仍应发送RTCP，即使启动时处于非活动状态。它可以是会话或媒体级属性，并且不依赖于字符集。
a=orient:<orientation>
a=orient:<orientation>
Normally this is only used for a whiteboard or presentation tool. It specifies the orientation of a the workspace on the screen. It is a media-level attribute. Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape). It is not dependent on charset.
通常，这仅用于白板或演示工具。它指定工作区在屏幕上的方向。它是媒体级属性。允许的值为“纵向”、“横向”和“海景”（倒置横向）。它不依赖于字符集。
a=type:<conference type>
a=type:<conference type>
This specifies the type of the conference. Suggested values are "broadcast", "meeting", "moderated", "test", and "H332". "recvonly" should be the default for "type:broadcast" sessions, "type:meeting" should imply "sendrecv", and "type:moderated" should indicate the use of a floor control tool and that the media tools are started so as to mute new sites joining the conference.
这将指定会议的类型。建议值为“广播”、“会议”、“主持人”、“测试”和“H332”。“类型：广播”会话的默认值应为“RecvoOnly”，“类型：meeting”应表示“sendrecv”，“类型：moderated”应表示使用了楼层控制工具，并且媒体工具已启动，以便使加入会议的新站点静音。
Specifying the attribute "type:H332" indicates that this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [26]. Media tools should be started "recvonly".
指定属性“type:H332”表示此松散耦合会话是ITU H.332规范中定义的H.332会话的一部分[26]。媒体工具应“重新启动”。
Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users.
建议指定属性“type:test”作为提示，除非另有明确要求，否则接收方可以安全地避免向用户显示此会话描述。
The type attribute is a session-level attribute, and it is not dependent on charset.
type属性是会话级属性，它不依赖于字符集。
a=charset:<character set>
a=charset:<character set>
This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. For example, the ISO 8859-1 is specified with the following SDP attribute:
这指定用于显示会话名称和信息数据的字符集。默认情况下，使用UTF-8编码的ISO-10646字符集。如果需要更紧凑的表示，可以使用其他字符集。例如，ISO 8859-1使用以下SDP属性指定：
a=charset:ISO-8859-1
a=字符集：ISO-8859-1
This is a session-level attribute and is not dependent on charset. The charset specified MUST be one of those registered with IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and MUST be compared against the IANA identifiers using a case-insensitive comparison. If the identifier is not recognised or not supported, all strings that are affected by it SHOULD be regarded as octet strings.
这是会话级属性，不依赖于字符集。指定的字符集必须是在IANA注册的字符集之一，如ISO-8859-1。字符集标识符是US-ASCII字符串，必须使用不区分大小写的比较与IANA标识符进行比较。如果标识符无法识别或不受支持，则受其影响的所有字符串都应视为八位字节字符串。
Note that a character set specified MUST still prohibit the use of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring the use of these characters MUST define a quoting mechanism that prevents these bytes from appearing within text fields.
请注意，指定的字符集仍然必须禁止使用字节0x00（Nul）、0x0A（LF）和0x0d（CR）。需要使用这些字符的字符集必须定义一种引用机制，以防止这些字节出现在文本字段中。
a=sdplang:<language tag>
a=sdplang:<language tag>
This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media. Multiple sdplang attributes can be provided either at session or media level if multiple languages in the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important.
这可以是会话级属性或媒体级属性。作为会话级别属性，它指定会话描述的语言。作为媒体级别属性，它指定与该媒体关联的任何媒体级别SDP信息字段的语言。如果会话描述或媒体中的多种语言使用多种语言，则可以在会话或媒体级别提供多个sdplang属性，在这种情况下，属性的顺序表示会话或媒体中各种语言的重要性从最重要到最不重要的顺序。
In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple descriptions SHOULD be sent describing the session, one in each language. However, this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED.
通常，不鼓励发送包含多种语言的会话描述。相反，应该发送多个描述会话的描述，每种语言一个。但是，这在所有传输机制中都是不可能的，因此虽然不建议使用多个sdplang属性，但也允许使用多个sdplang属性。
The "sdplang" attribute value must be a single RFC 3066 language tag in US-ASCII [9]. It is not dependent on the charset attribute. An "sdplang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm.
“sdplang”属性值必须是US-ASCII格式的单个RFC 3066语言标记[9]。它不依赖于charset属性。如果会话的范围足以跨越无法假定收件人语言的地理边界，或者会话使用的语言与本地假定的规范不同，则应指定“sdplang”属性。
a=lang:<language tag>
a=lang:<language tag>
This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the default language for the session being described. As a media-level attribute, it specifies the language for that media,
这可以是会话级属性或媒体级属性。作为会话级别属性，它指定所描述会话的默认语言。作为媒体级别属性，它指定该媒体的语言，
overriding any session-level language specified. Multiple lang attributes can be provided either at session or media level if the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important.
重写指定的任何会话级别语言。如果会话描述或媒体使用多种语言，则可以在会话或媒体级别提供多个lang属性，在这种情况下，属性的顺序表示会话或媒体中各种语言的重要性顺序，从最重要到最不重要。
The "lang" attribute value must be a single RFC 3066 language tag in US-ASCII [9]. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm.
“lang”属性值必须是US-ASCII格式的单个RFC 3066语言标记[9]。它不依赖于charset属性。如果会话的范围足以跨越无法假定收件人语言的地理边界，或者会话使用与本地假定规范不同的语言，则应指定“lang”属性。
a=framerate:<frame rate>
a=framerate:<frame rate>
This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "<integer>.<fraction>" are allowed. It is a media-level attribute, defined only for video media, and it is not dependent on charset.
这将提供以帧数/秒为单位的最大视频帧速率。其目的是作为视频数据编码的建议。允许使用符号“<integer><fraction>”对分数值进行十进制表示。它是一个媒体级属性，仅为视频媒体定义，不依赖于字符集。
a=quality:<quality>
a=quality:<quality>
This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value is in the range 0 to 10, with the following suggested meaning:
这为整数值编码的质量提供了建议。视频质量属性的目的是指定帧速率和静态图像质量之间的非默认权衡。对于视频，该值在0到10之间，建议含义如下：
10 - the best still-image quality the compression scheme can give. 5 - the default behaviour given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable.
10-压缩方案所能提供的最佳静态图像质量。5-未给出质量建议的默认行为。0-编解码器设计师认为仍然可用的最差静态图像质量。
It is a media-level attribute, and it is not dependent on charset.
它是媒体级属性，不依赖于字符集。
a=fmtp:<format> <format specific parameters>
a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given
此属性允许以SDP不必理解的方式传递特定于特定格式的参数。格式必须是为媒体指定的格式之一。特定于格式的参数可以是SDP需要传递和给定的任何一组参数
unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format.
对将使用此格式的媒体工具保持不变。每个格式最多允许一个此属性的实例。
It is a media-level attribute, and it is not dependent on charset.
它是媒体级属性，不依赖于字符集。
SDP is frequently used with the Session Initiation Protocol [15] using the offer/answer model [17] to agree on parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply.
SDP经常与会话启动协议[15]一起使用，使用提供/应答模型[17]来商定单播会话的参数。以这种方式使用时，这些协议的安全考虑因素适用。
SDP is a session description format that describes multimedia sessions. Entities receiving and acting upon an SDP message SHOULD be aware that a session description cannot be trusted unless it has been obtained by an authenticated transport protocol from a known and trusted source. Many different transport protocols may be used to distribute session description, and the nature of the authentication will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint SHOULD exercise care because, among other attacks, the media sessions received may not be the intended ones, the destination where media is sent to may not be the expected one, any of the parameters of the session may be incorrect, or the media security may be compromised. It is up to the endpoint to make a sensible decision taking into account the security risks of the application and the user preferences and may decide to ask the user whether or not to accept the session.
SDP是一种描述多媒体会话的会话描述格式。接收SDP消息并对其采取行动的实体应该意识到，会话描述不能被信任，除非它是通过经过身份验证的传输协议从已知的可信源获得的。许多不同的传输协议可用于分发会话描述，不同传输的身份验证的性质也不同。对于某些传输，通常不部署安全功能。如果未以可信方式获得会话描述，则端点应小心，因为在其他攻击中，接收到的媒体会话可能不是预期的，发送媒体的目的地可能不是预期的，会话的任何参数可能不正确，或者媒体安全可能受到威胁。考虑到应用程序的安全风险和用户偏好，由端点做出明智的决定，并可能决定询问用户是否接受会话。
One transport that can be used to distribute session descriptions is the Session Announcement Protocol (SAP). SAP provides both encryption and authentication mechanisms, but due to the nature of session announcements it is likely that there are many occasions where the originator of a session announcement cannot be authenticated because the originator is previously unknown to the receiver of the announcement and because no common public key infrastructure is available.
一种可用于分发会话描述的传输是会话公告协议（SAP）。SAP提供加密和身份验证机制，但是，由于会话公告的性质，在许多情况下，会话公告的发起者可能无法通过身份验证，因为该发起者以前对公告的接收者是未知的，并且没有公共公钥基础设施可用。
On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session should take a few precautions. Session descriptions contain information required to start software on the receiver's system. Software that parses a session description MUST NOT be able to start other software except that which is specifically configured as appropriate software to participate in multimedia sessions. It is normally considered inappropriate for software parsing a session
在通过未经验证的传输机制或从不受信任的一方接收会话描述时，解析会话的软件应采取一些预防措施。会话描述包含在接收器系统上启动软件所需的信息。解析会话描述的软件必须不能启动其他软件，除非专门配置为参与多媒体会话的适当软件。通常认为软件解析会话是不合适的
description to start, on a user's system, software that is appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving the user's consent. Thus, a session description arriving by session announcement, email, session invitation, or WWW page MUST NOT deliver the user into an interactive multimedia session unless the user has explicitly pre-authorised such action. As it is not always simple to tell whether or not a session is interactive, applications that are unsure should assume sessions are interactive.
说明：在用户系统上启动适合参与多媒体会话的软件，而无需事先通知用户将启动该软件并征得用户同意。因此，通过会话公告、电子邮件、会话邀请或WWW页面到达的会话描述不得将用户交付到交互式多媒体会话中，除非用户明确预先授权此类操作。由于判断会话是否是交互式的并不总是那么简单，因此不确定的应用程序应该假定会话是交互式的。
In this specification, there are no attributes that would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done, an application parsing a session description containing such attributes SHOULD either ignore them or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behaviour for an unknown attribute is to ignore it.
在本规范中，没有允许会话描述的接收者被通知以默认传输模式启动多媒体工具的属性。在某些情况下，定义这些属性可能是合适的。如果这样做，解析包含此类属性的会话描述的应用程序应该忽略它们，或者通知用户加入此会话将导致多媒体数据的自动传输。未知属性的默认行为是忽略它。
In certain environments, it has become common for intermediary systems to intercept and analyse session descriptions contained within other signalling protocols. This is done for a range of purposes, including but not limited to opening holes in firewalls to allow media streams to pass, or to mark, prioritize, or block traffic selectively. In some cases, such intermediary systems may modify the session description, for example, to have the contents of the session description match NAT bindings dynamically created. These behaviours are NOT RECOMMENDED unless the session description is conveyed in such a manner that allows the intermediary system to conduct proper checks to establish the authenticity of the session description, and the authority of its source to establish such communication sessions. SDP by itself does not include sufficient information to enable these checks: they depend on the encapsulating protocol (e.g., SIP or RTSP).
在某些环境中，中间系统拦截和分析包含在其他信令协议中的会话描述已变得很常见。这样做的目的有很多，包括但不限于在防火墙中打开漏洞以允许媒体流通过，或有选择地标记、优先排序或阻止流量。在某些情况下，此类中介系统可以修改会话描述，例如，使会话描述的内容与动态创建的NAT绑定匹配。除非以允许中间系统进行适当检查以确定会话描述的真实性及其来源建立此类通信会话的权限的方式传达会话描述，否则不推荐这些行为。SDP本身不包含足够的信息来启用这些检查：它们取决于封装协议（例如SIP或RTSP）。
Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. Moreover, the "k=" line provides no way to indicate or negotiate cryptographic key algorithms. As it provides for only a single symmetric key, rather than separate keys for confidentiality and integrity, its utility is severely limited. The use of the "k=" line is NOT RECOMMENDED, as discussed in Section 5.12.
使用“k=”字段会带来严重的安全风险，因为它以明文形式传递会话加密密钥。SDP不得用于传送密钥材料，除非可以保证SDP通过的通道是私有的且经过身份验证的。此外，“k=”行无法指示或协商加密密钥算法。由于它只提供一个对称密钥，而不是用于机密性和完整性的单独密钥，因此其实用性受到严重限制。如第5.12节所述，不建议使用“k=”行。
One media type registration from RFC 2327 is to be updated, as defined below.
将更新RFC 2327中的一个媒体类型注册，定义如下。
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
Type name: application
类型名称：应用程序
Subtype name: sdp
子类型名称：sdp
Required parameters: None.
所需参数：无。
Optional parameters: None.
可选参数：无。
Encoding considerations: SDP files are primarily UTF-8 format text. The "a=charset:" attribute may be used to signal the presence of other character sets in certain parts of an SDP file (see Section 6 of RFC 4566). Arbitrary binary content cannot be directly represented in SDP.
编码注意事项：SDP文件主要是UTF-8格式的文本。“a=charset:”属性可用于表示SDP文件某些部分中存在其他字符集（参见RFC 4566第6节）。无法在SDP中直接表示任意二进制内容。
Security considerations: See Section 7 of RFC 4566
安全注意事项：见RFC 4566第7节
Interoperability considerations: See RFC 4566
互操作性注意事项：参见RFC 4566
Published specification: See RFC 4566
已发布规范：见RFC 4566
Applications which use this media type: Voice over IP, video teleconferencing, streaming media, instant messaging, among others. See also Section 3 of RFC 4566.
使用这种媒体类型的应用程序：IP语音、视频会议、流媒体、即时消息等。另见RFC 4566第3节。
Additional information:
其他信息：
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp "
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp "
Person & email address to contact for further information:
Mark Handley <M.Handley@cs.ucl.ac.uk>
Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group <mmusic@ietf.org>
Person & email address to contact for further information:
Mark Handley <M.Handley@cs.ucl.ac.uk>
Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group <mmusic@ietf.org>
Intended usage: COMMON
预期用途：普通
Author/Change controller: Authors of RFC 4566 IETF MMUSIC working group delegated from the IESG
作者/变更控制员：由IESG授权的RFC 4566 IETF MMUSIC工作组的作者
There are seven field names that may be registered with IANA. Using the terminology in the SDP specification Backus-Naur Form (BNF), they are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and "addrtype".
IANA可以注册七个字段名。使用SDP规范Backus Naur表格（BNF）中的术语，它们是“媒体”、“原型”、“fmt”、“att字段”、“bwtype”、“nettype”和“addrtype”。
The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level media content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing top-level media content types, a Standards Track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [8].
介质类型集的规模较小，除非在极少数情况下，否则不应扩展。媒体名称的规则应与顶级媒体内容类型的规则相同，并且在可能的情况下，SDP应注册与MIME相同的名称。对于现有顶级媒体内容类型以外的媒体，必须为要注册的新顶级内容类型生成标准跟踪RFC，并且注册必须提供现有媒体名称不合适的充分理由（RFC 2434[8]的“标准操作”政策）。
This memo registers the media types "audio", "video", "text", "application", and "message".
此备忘录记录媒体类型“音频”、“视频”、“文本”、“应用程序”和“消息”。
Note: The media types "control" and "data" were listed as valid in the previous version of this specification [6]; however, their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent as defined in RFC 3840 [24]. If these media types are considered useful in the future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by RFC 3840).
注：介质类型“控制”和“数据”在本规范先前版本中列为有效[6]；然而，它们的语义从未被完全指定，也没有被广泛使用。这些媒体类型已在本规范中删除，尽管它们仍然是RFC 3840[24]中定义的SIP用户代理的有效媒体类型功能。如果这些媒体类型在将来被认为是有用的，则必须制作一份标准跟踪RFC来记录它们的使用情况。在此之前，应用程序不应该使用这些类型，也不应该在SIP功能声明中声明对它们的支持（即使它们存在于RFC3840创建的注册表中）。
The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo registers three values: "RTP/AVP" is a reference to RTP [19] used under the RTP Profile for Audio and Video Conferences with Minimal Control [20]
“proto”字段描述所使用的传输协议。这应参考标准跟踪协议RFC。本备忘录登记了三个值：“RTP/AVP”是指RTP配置文件下使用的RTP[19]，用于控制最少的音频和视频会议[20]
running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real-time Transport Protocol [23], and "udp" indicates an unspecified protocol over UDP.
在UDP/IP上运行，“RTP/SAVP”是对安全实时传输协议[23]的引用，“UDP”表示UDP上的未指定协议。
If other RTP profiles are defined in the future, their "proto" name SHOULD be specified in the same manner. For example, an RTP profile whose short name is "XYZ" would be denoted by a "proto" field of "RTP/XYZ".
如果将来定义了其他RTP配置文件，则应以相同的方式指定其“proto”名称。例如，短名称为“XYZ”的RTP配置文件将由“RTP/XYZ”的“proto”字段表示。
New transport protocols SHOULD be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable that it be Standards Track. Registrations MUST also define the rules by which their "fmt" namespace is managed (see below).
新的传输协议应向IANA注册。注册必须引用描述协议的RFC。这种RFC可以是实验性的或信息性的，尽管最好是标准跟踪。注册还必须定义管理其“fmt”命名空间的规则（见下文）。
Each transport protocol, defined by the "proto" field, has an associated "fmt" namespace that describes the media formats that may be conveyed by that protocol. Formats cover all the possible encodings that might want to be transported in a multimedia session.
由“proto”字段定义的每个传输协议都有一个相关的“fmt”名称空间，该名称空间描述了该协议可能传输的媒体格式。格式包括可能希望在多媒体会话中传输的所有可能的编码。
RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned by this session description, an additional "rtpmap" attribute MUST be included to specify the format name and parameters as defined by the media type registration for the payload format. It is RECOMMENDED that other RTP profiles that are registered (in combination with RTP) as SDP transport protocols specify the same rules for the "fmt" namespace.
“RTP/AVP”和“RTP/SAVP”配置文件下的RTP有效载荷格式必须使用有效载荷类型号作为其“fmt”值。如果有效负载类型编号由该会话描述动态分配，则必须包括附加的“rtpmap”属性，以指定有效负载格式的媒体类型注册所定义的格式名称和参数。建议（与RTP一起）注册为SDP传输协议的其他RTP配置文件为“fmt”命名空间指定相同的规则。
For the "udp" protocol, new formats SHOULD be registered. Use of an existing media subtype for the format is encouraged. If no media subtype exists, it is RECOMMENDED that a suitable one be registered through the IETF process [31] by production of, or reference to, a standards-track RFC that defines the transport protocol for the format.
对于“udp”协议，应注册新的格式。鼓励对格式使用现有媒体子类型。如果不存在媒体子类型，建议通过IETF过程[31]通过生成或引用定义格式传输协议的标准跟踪RFC来注册合适的媒体子类型。
For other protocols, formats MAY be registered according to the rules of the associated "proto" specification.
对于其他协议，可以根据相关“proto”规范的规则注册格式。
Registrations of new formats MUST specify which transport protocols they apply to.
新格式的注册必须指定它们适用于哪些传输协议。
Attribute field names ("att-field") MUST be registered with IANA and documented, because of noticeable issues due to conflicting attributes under the same name. Unknown attributes in SDP are simply ignored, but conflicting ones that fragment the protocol are a serious problem.
属性字段名称（“att字段”）必须向IANA注册并记录，因为相同名称下的属性冲突会引起明显问题。SDP中的未知属性会被忽略，但使协议碎片化的冲突属性是一个严重的问题。
New attribute registrations are accepted according to the "Specification Required" policy of RFC 2434, provided that the specification includes the following information:
根据RFC 2434的“要求规范”政策，接受新的属性注册，前提是规范包括以下信息：
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 type of attribute (session level, media level, or both)
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. Attributes that are expected to see widespread use and interoperability SHOULD be documented with a standards-track RFC that specifies the attribute more precisely.
以上是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属性的精神，最值得注意的是，该属性是平台独立的，因为它不对操作系统进行隐含假设，也不会以可能抑制互操作性的方式命名特定软件。
IANA has registered the following initial set of attribute names ("att-field" values), with definitions as in Section 6 of this memo (these definitions update those in RFC 2327):
IANA已注册了以下初始属性名称集（“att字段”值），其定义如本备忘录第6节所述（这些定义更新了RFC 2327中的定义）：
Name | Session or Media level? | Dependent on charset?
----------+-------------------------+----------------------
cat | Session | No
keywds | Session | Yes
tool | Session | No
ptime | Media | No
maxptime | Media | No
rtpmap | Media | No
recvonly | Either | No
sendrecv | Either | No
sendonly | Either | No
inactive | Either | No
orient | Media | No
type | Session | No
charset | Session | No
sdplang | Either | No
lang | Either | No
framerate | Media | No
quality | Media | No
fmtp | Media | No
Name | Session or Media level? | Dependent on charset?
----------+-------------------------+----------------------
cat | Session | No
keywds | Session | Yes
tool | Session | No
ptime | Media | No
maxptime | Media | No
rtpmap | Media | No
recvonly | Either | No
sendrecv | Either | No
sendonly | Either | No
inactive | Either | No
orient | Media | No
type | Session | No
charset | Session | No
sdplang | Either | No
lang | Either | No
framerate | Media | No
quality | Media | No
fmtp | Media | No
A proliferation of bandwidth specifiers is strongly discouraged.
强烈反对带宽说明符的激增。
New bandwidth specifiers ("bwtype" fields) MUST be registered with IANA. The submission MUST reference a standards-track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice.
必须向IANA注册新的带宽说明符（“bwtype”字段）。提交必须引用一个标准跟踪RFC，精确地指定带宽说明符的语义，并指明何时应该使用它，以及现有注册带宽说明符不够用的原因。
IANA has registered the bandwidth specifiers "CT" and "AS" with definitions as in Section 5.8 of this memo (these definitions update those in RFC 2327).
IANA已将带宽说明符“CT”和“AS”注册为本备忘录第5.8节中的定义（这些定义更新了RFC 2327中的定义）。
New network types (the "nettype" field) may be registered with IANA if SDP needs to be used in the context of non-Internet environments. Although these are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non-Internet application, such as when gatewaying an Internet telephone call into the Public Switched Telephone Network (PSTN). The number of network types should be small and should be rarely extended. A new network type cannot be registered without registering at least one address type to be used with that network
如果SDP需要在非互联网环境中使用，可以向IANA注册新的网络类型（“nettype”字段）。尽管这些通常不是IANA的专利，但在某些情况下，Internet应用程序可能需要与非Internet应用程序进行互操作，例如将Internet电话呼叫网关连接到公共交换电话网（PSTN）。网络类型的数量应该很少，并且应该很少扩展。如果未注册至少一个要用于该网络的地址类型，则无法注册新网络类型
type. A new network type registration MUST reference an RFC that gives details of the network type and address type and specifies how and when they would be used.
类型新的网络类型注册必须引用RFC，该RFC提供网络类型和地址类型的详细信息，并指定如何以及何时使用它们。
IANA has registered the network type "IN" to represent the Internet, with definition as in Sections 5.2 and 5.7 of this memo (these definitions update those in RFC 2327).
IANA已注册网络类型“IN”以表示互联网，定义见本备忘录第5.2节和第5.7节（这些定义更新了RFC 2327中的定义）。
New address types ("addrtype") may be registered with IANA. An address type is only meaningful in the context of a network type, and any registration of an address type MUST specify a registered network type or be submitted along with a network type registration. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Address types are not expected to be registered frequently.
新的地址类型（“addrtype”）可以在IANA注册。地址类型仅在网络类型的上下文中有意义，并且地址类型的任何注册必须指定已注册的网络类型，或者与网络类型注册一起提交。新地址类型注册必须引用RFC，该RFC提供了地址类型语法的详细信息。不希望经常注册地址类型。
IANA has registered the address types "IP4" and "IP6" with definitions as in Sections 5.2 and 5.7 of this memo (these definitions update those in RFC 2327).
IANA已使用本备忘录第5.2节和第5.7节中的定义注册了地址类型“IP4”和“IP6”（这些定义更新了RFC 2327中的定义）。
In the RFC documentation that registers SDP "media", "proto", "fmt", "bwtype", "nettype", and "addrtype" fields, the authors MUST include the following information for IANA to place in the appropriate registry:
在注册SDP“media”、“proto”、“fmt”、“bwtype”、“nettype”和“addrtype”字段的RFC文档中，作者必须包含以下信息，以便IANA将其放入相应的注册表中：
o contact name, email address, and telephone number
o 联系人姓名、电子邮件地址和电话号码
o name being registered (as it will appear in SDP)
o 正在注册的名称（将显示在SDP中）
o long-form name in English
o 英语中的长格式名称
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or "addrtype")
o 名称类型（“媒体”、“原型”、“fmt”、“bwtype”、“nettype”或“addrtype”）
o a one-paragraph explanation of the purpose of the registered name
o 关于注册名称用途的一段解释
o a reference to the specification for the registered name (this will typically be an RFC number)
o 对注册名称规范的引用（通常为RFC编号）
IANA may refer any registration to the IESG for review, and may request revisions to be made before a registration will be made.
IANA可将任何注册提交给IESG审查，并可要求在注册前进行修改。
The IANA previously maintained a table of SDP encryption key access method ("enckey") names. This table is obsolete, since the "k=" line is not extensible. New registrations MUST NOT be accepted.
IANA先前维护了SDP加密密钥访问方法（“enckey”）名称表。此表已过时，因为“k=”行不可扩展。不得接受新注册。
This section provides an Augmented BNF grammar for SDP. ABNF is defined in [4].
本节提供了SDP的扩充BNF语法。ABNF的定义见[4]。
; SDP Syntax session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions
; SDP Syntax session description=原始版本源字段会话名称字段信息字段uri字段电子邮件字段电话字段连接字段带宽字段时间字段关键字字段属性字段媒体描述
proto-version = %x76 "=" 1*DIGIT CRLF
;this memo describes version 0
proto-version = %x76 "=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %x73 "=" text CRLF
session-name-field = %x73 "=" text CRLF
information-field = [%x69 "=" text CRLF]
information-field = [%x69 "=" text CRLF]
uri-field = [%x75 "=" uri CRLF]
uri-field = [%x75 "=" uri CRLF]
email-fields = *(%x65 "=" email-address CRLF)
email-fields = *(%x65 "=" email-address CRLF)
phone-fields = *(%x70 "=" phone-number CRLF)
phone-fields = *(%x70 "=" phone-number CRLF)
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
time-fields = 1*( %x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
time-fields = 1*( %x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
key-field = [%x6b "=" key-type CRLF]
key-field = [%x6b "=" key-type CRLF]
attribute-fields = *(%x61 "=" attribute CRLF)
attribute-fields = *(%x61 "=" attribute CRLF)
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
; sub-rules of 'o='
username = non-ws-string
;pretty wide definition, but doesn't
;include space
; sub-rules of 'o='
username = non-ws-string
;pretty wide definition, but doesn't
;include space
sess-id = 1*DIGIT
;should be unique for this username/host
sess-id = 1*DIGIT
;should be unique for this username/host
sess-version = 1*DIGIT
sess-version = 1*DIGIT
nettype = token ;typically "IN"
nettype=token；通常是“在”
addrtype = token ;typically "IP4" or "IP6"
addrtype=token；通常为“IP4”或“IP6”
; sub-rules of 'u=' uri = URI-reference ; see RFC 3986
; “u=”uri=uri引用的子规则；见RFC 3986
; sub-rules of 'e=', see RFC 2822 for definitions
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; sub-rules of 'e=', see RFC 2822 for definitions
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of 'c='
connection-address = multicast-address / unicast-address
; sub-rules of 'c='
connection-address = multicast-address / unicast-address
; sub-rules of 'b=' bwtype = token
; “b=”bwtype=令牌的子规则
bandwidth = 1*DIGIT
bandwidth = 1*DIGIT
; sub-rules of 't='
start-time = time / "0"
; sub-rules of 't='
start-time = time / "0"
stop-time = time / "0"
停止时间=时间/“0”
time = POS-DIGIT 9*DIGIT
; Decimal representation of NTP time in
; seconds since 1900. The representation
; of NTP time is an unbounded length field
; containing at least 10 digits. Unlike the
; 64-bit representation used elsewhere, time
; in SDP does not wrap in the year 2036.
time = POS-DIGIT 9*DIGIT
; Decimal representation of NTP time in
; seconds since 1900. The representation
; of NTP time is an unbounded length field
; containing at least 10 digits. Unlike the
; 64-bit representation used elsewhere, time
; in SDP does not wrap in the year 2036.
; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %x64 / %x68 / %x6d / %x73
fixed-len-time-unit = %x64 / %x68 / %x6d / %x73
; sub-rules of 'k='
key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt"
%x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
%x62 %x61 %x73 %x65 "64:" base64 / ; "base64:"
%x75 %x72 %x69 ":" uri ; "uri:"
; sub-rules of 'k='
key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt"
%x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
%x62 %x61 %x73 %x65 "64:" base64 / ; "base64:"
%x75 %x72 %x69 ":" uri ; "uri:"
base64 = *base64-unit [base64-pad]
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a='
attribute = (att-field ":" att-value) / att-field
; sub-rules of 'a='
attribute = (att-field ":" att-value) / att-field
att-field = token
att-field = token
att-value = byte-string
att-value = byte-string
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", or
;"application"
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", or
;"application"
fmt = token ;typically an RTP payload type for audio ;and video media
fmt=令牌；通常为音频的RTP有效负载类型；和视频媒体
proto = token *("/" token)
;typically "RTP/AVP" or "udp"
proto = token *("/" token)
;typically "RTP/AVP" or "udp"
port = 1*DIGIT
port = 1*DIGIT
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
IP6-multicast = hexpart [ "/" integer ] ; IPv6 address starting with FF
IP6多播=十六进制[“/”整数]；以FF开头的IPv6地址
ttl = (POS-DIGIT *2DIGIT) / "0"
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
IP4-address = b1 3("." decimal-uchar)
IP4地址=b1 3（“.”十进制uchar）
b1 = decimal-uchar ; less than "224"
b1=十进制uchar；小于“224”
; The following is consistent with RFC 2373 [30], Appendix B. IP6-address = hexpart [ ":" IP4-address ]
; 以下内容与RFC 2373[30]附录B一致。IP6地址=十六进制部分[“：”IP4地址]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
hex4 = 1*4HEXDIG
; Generic for other address families extn-addr = non-ws-string
; 其他地址族的通用extn addr=非ws-string
; generic sub-rules: datatypes
text = byte-string
;default is to interpret this as UTF8 text.
;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used
; generic sub-rules: datatypes
text = byte-string
;default is to interpret this as UTF8 text.
;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
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
token = 1*(token-char)
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
integer = POS-DIGIT *DIGIT
整数=位位数*位数
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references:
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234
; URI-reference: from RFC 3986
; addr-spec: from RFC 2822
; external references:
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234
; URI-reference: from RFC 3986
; addr-spec: from RFC 2822
The memo has been significantly restructured, incorporating a large number of clarifications to the specification in light of use. With the exception of those items noted below, the changes to the memo are intended to be backward-compatible clarifications. However, due to inconsistencies and unclear definitions in RFC 2327 it is likely that some implementations interpreted that memo in ways that differ from this version of SDP.
备忘录已进行了重大重组，根据使用情况对规范进行了大量澄清。除以下所述项目外，备忘录的变更旨在向后兼容澄清。然而，由于RFC 2327中的不一致和定义不明确，一些实现可能以不同于此版本SDP的方式解释该备忘录。
The ABNF grammar in Section 9 has been extensively revised and updated, correcting a number of mistakes and incorporating the RFC 3266 IPv6 extensions. Known inconsistencies between the grammar and the specification text have been resolved.
第9节中的ABNF语法经过了广泛的修订和更新，纠正了一些错误，并加入了RFC3266 IPv6扩展。语法和规范文本之间的已知不一致已得到解决。
A media type registration for SDP is included. Requirements for the registration of attributes and other parameters with IANA have been clarified and tightened (Section 8). It is noted that "text" and "message" are valid media types for use with SDP, but that "control" and "data" are under-specified and deprecated.
包括SDP的媒体类型注册。已澄清并加强了向IANA注册属性和其他参数的要求（第8节）。请注意，“文本”和“消息”是用于SDP的有效媒体类型，但“控件”和“数据”未指定且已弃用。
RFC 2119 terms are now used throughout to specify requirements levels. Certain of those requirements, in particular in relation to parameter registration, are stricter than those in RFC 2327.
RFC 2119术语现在通篇用于指定需求级别。某些要求，特别是与参数注册有关的要求，比RFC 2327中的要求更为严格。
The "RTP/SAVP" RTP profile and its "fmt" namespace are registered.
注册“RTP/SAVP”RTP配置文件及其“fmt”命名空间。
The attributes "a=inactive" and "a=maxptime" have been added.
添加了属性“a=inactive”和“a=maxptime”。
RFC 2327 mandated that either "e=" or "p=" was required. Both are now optional, to reflect actual usage.
RFC 2327强制要求“e=”或“p=”是必需的。现在两者都是可选的，以反映实际使用情况。
The significant limitations of the "k=" field are noted, and its use is deprecated.
注意到“k=”字段的重大限制，不推荐使用它。
Most uses of the "x-" prefix notation for experimental parameters are disallowed and the other uses are deprecated.
实验参数的“x-”前缀符号的大多数用法是不允许的，其他用法是不推荐的。
Many people in the IETF Multiparty Multimedia Session Control (MMUSIC) working group have made comments and suggestions contributing to this document. In particular, we would like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, and Spencer Dawkins.
IETF多方多媒体会话控制（MMUSIC）工作组中的许多人对本文件提出了意见和建议。特别是，我们要感谢Eve Schooler、Steve Casner、Bill Fenner、Allison Mankin、Ross Finlayson、Peter Parnes、Joerg Ott、Carsten Bormann、Steve Hanna、Jonathan Lennox、Keith Drage、Sean Olson、Bernie Hoenesen、Jonathan Rosenberg、John Elwell、Fleming Andreasen、Jon Peterson和Spencer Dawkins。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[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] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[4] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[5] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[9] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002.
[10] Olson，S.，Camarillo，G.，和A.Roach，“对IPv6会话描述协议（SDP）的支持”，RFC 3266，2002年6月。
[11] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[11] Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[12] Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[13] Mills，D.，“网络时间协议（版本3）规范，实施”，RFC13051992年3月。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[15] 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.
[15] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[17] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[18] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[19] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[20] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[21] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[21] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[22] “实时控制协议（RTCP），2003年10月的SDC协议描述”。
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[23] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[24] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[25] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[25] Westerlund，M.“会话描述协议（SDP）的独立于传输的带宽修改器”，RFC 38902004年9月。
[26] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998.
[26] 国际电信联盟，“为松散耦合会议扩展的H.323”，国际电联建议H.332，1998年9月。
[27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[27] Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[28] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[28] Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[29] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[29] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[30] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[30] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[31] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[31] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
Authors' Addresses
作者地址
Mark Handley University College London Department of Computer Science Gower Street London WC1E 6BT UK
马克·汉德利大学学院伦敦计算机科学系伦敦高尔街WC1E 6BT英国
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 USA
美国加利福尼亚州山景城莱瑟姆街2465号Van Jacobson包装设计公司，邮编94040
EMail: van@packetdesign.com
EMail: van@packetdesign.com
Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ UK
柯林帕金斯格拉斯哥大学计算科学系17 LIYBANK花园格拉斯哥G128QQ英国
EMail: csp@csperkins.org
EMail: csp@csperkins.org
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）提供。