Network Working Group M. Handley
Request for Comments: 2327 V. Jacobson
Category: Standards Track ISI/LBNL
April 1998
Network Working Group M. Handley
Request for Comments: 2327 V. Jacobson
Category: Standards Track ISI/LBNL
April 1998
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document 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用于描述多媒体会话，用于会话公告、会话邀请和其他形式的多媒体会话启动。
This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors.
本文件是互联网工程任务组多方多媒体会话控制（MMUSIC）工作组的产品。征求意见，并应发送至工作组的邮件列表：confctrl@isi.edu和/或作者。
On the Internet multicast backbone (Mbone), a session directory tool is used to advertise multimedia conferences and communicate the conference addresses and conference tool-specific information necessary for participation. This document defines a session description protocol for this purpose, and for general real-time multimedia session description purposes. This memo does not describe multicast address allocation or the distribution of SDP messages in detail. These are described in accompanying memos. SDP is not intended for negotiation of media encodings.
在Internet多播主干网（Mbone）上，会话目录工具用于宣传多媒体会议，并传达参加会议所需的会议地址和会议工具特定信息。本文档定义了用于此目的的会话描述协议，以及用于一般实时多媒体会话描述目的的会话描述协议。本备忘录未详细描述多播地址分配或SDP消息的分发。这些在随附的备忘录中进行了描述。SDP不用于协商媒体编码。
The Mbone is the part of the internet that supports IP multicast, and thus permits efficient many-to-many communication. It is used extensively for multimedia conferencing. Such conferences usually have the property that tight coordination of conference membership is not necessary; to receive a conference, a user at an Mbone site only has to know the conference's multicast group address and the UDP ports for the conference data streams.
Mbone是支持IP多播的internet的一部分，因此允许高效的多对多通信。它广泛用于多媒体会议。这类会议通常具有这样的性质，即不需要紧密协调会议成员；要接收会议，Mbone站点的用户只需知道会议的多播组地址和会议数据流的UDP端口。
Session directories assist the advertisement of conference sessions and communicate the relevant conference setup information to prospective participants. SDP is designed to convey such information to recipients. SDP is purely a format for session description - it does not incorporate a transport protocol, and is intended to use different transport protocols as appropriate including the Session Announcement Protocol [4], Session Initiation Protocol [11], Real-Time Streaming Protocol [12], electronic mail using the MIME extensions, and the Hypertext Transport Protocol.
会议目录有助于宣传会议会议，并将相关会议设置信息传达给潜在与会者。SDP旨在向接收者传达此类信息。SDP纯粹是一种用于会话描述的格式-它不包含传输协议，并打算酌情使用不同的传输协议，包括会话公告协议[4]、会话启动协议[11]、实时流协议[12]、使用MIME扩展的电子邮件、，以及超文本传输协议。
SDP is intended to be general purpose so that it can be used for a wider range of network environments and applications than just multicast session directories. 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是通用的，因此它可以用于更广泛的网络环境和应用程序，而不仅仅是多播会话目录。但是，它不支持会话内容或媒体编码的协商-这被视为超出了会话描述的范围。
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 Advertisement See session announcement.
会话公告见会话公告。
Session Announcement A session announcement is a mechanism by which a session description is conveyed to users in a proactive fashion, i.e., the session description was not explicitly requested by the user.
会话公告会话公告是一种机制，通过该机制，会话描述以主动方式传达给用户，即，用户未明确请求会话描述。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
SDP is a session description protocol for multimedia sessions. A common mode of usage is for a client to announce a conference session by periodically multicasting an announcement packet to a well known multicast address and port using the Session Announcement Protocol (SAP).
SDP是一种用于多媒体会话的会话描述协议。一种常见的使用模式是，客户机通过使用会话公告协议（SAP）定期将公告数据包多播到已知的多播地址和端口来公告会议会话。
SAP packets are UDP packets with the following format:
SAP数据包是具有以下格式的UDP数据包：
|--------------------|
| SAP header |
|--------------------|
| text payload |
|//////////
|--------------------|
| SAP header |
|--------------------|
| text payload |
|//////////
The header is the Session Announcement Protocol header. SAP is described in more detail in a companion memo [4]
标头是会话公告协议标头。SAP在附带备忘录中有更详细的描述[4]
The text payload is an SDP session description, as described in this memo. The text payload should be no greater than 1 Kbyte in length. If announced by SAP, only one session announcement is permitted in a single packet.
文本有效负载是SDP会话描述，如本备忘录所述。文本有效负载的长度不应大于1 KB。如果由SAP发布，则单个数据包中只允许发布一次会话。
Alternative means of conveying session descriptions include electronic mail and the World Wide Web. For both email and WWW distribution, the use of the MIME content type "application/sdp" should be 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分发，应使用MIME内容类型“application/sdp”。这使得能够以标准方式从WWW客户端或邮件阅读器自动启动参与会话的应用程序。
Note that announcements of multicast sessions made only via email or the World Wide Web (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. SAP announcements do not suffer from this mismatch.
请注意，仅通过电子邮件或万维网（WWW）进行的多播会话的通知不具有会话通知的接收者必须能够接收会话的属性，因为多播会话可能在范围内受到限制，并且可以在此范围之外访问WWW服务器或接收电子邮件。SAP发布不会受到这种不匹配的影响。
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.
SDP的目的是在多媒体会话中传送关于媒体流的信息，以允许会话描述的接收者参与会话。SDP主要用于互联网，尽管它具有足够的通用性，可以描述其他网络环境中的会议。
A multimedia session, for these purposes, is defined as a set of media streams that exist for some duration of time. Media streams can be many-to-many. The times during which the session is active need not be continuous.
出于这些目的，多媒体会话被定义为存在一段时间的一组媒体流。媒体流可以是多对多。会话处于活动状态的时间不需要连续。
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 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有两个主要目的。它是一种传达会话存在性的手段，也是一种传达足够信息以加入和参与会话的手段。在单播环境中，只有后一个目的可能是相关的。
Thus SDP includes:
因此，可持续发展计划包括：
o Session name and purpose
o 会话名称和目的
o Time(s) the session is active
o 会话处于活动状态的时间
o The media comprising the session
o 组成会议的媒体
o Information to receive those media (addresses, ports, formats and so on)
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 conference
o 有关会议将使用的带宽的信息
o Contact information for the person responsible for the session
o 会议负责人的联系信息
In general, SDP must convey sufficient information to be able to join a session (with the possible exception of encryption keys) and to announce the resources to be used to non-participants that may need to know.
通常，SDP必须传递足够的信息，以便能够加入会话（加密密钥可能除外），并向可能需要知道的非参与者宣布要使用的资源。
SDP includes:
可持续发展计划包括：
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视频等）
For an IP multicast session, the following are also conveyed:
对于IP多播会话，还传递以下信息：
o Multicast address for media
o 媒体的多播地址
o 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 an IP unicast session, the following are conveyed:
对于IP单播会话，传达以下信息：
o Remote address for media
o 媒体的远程地址
o Transport port for contact address
o 联系人地址的传输端口
The semantics of this address and port depend on the media and transport protocol defined. By default, this is the remote address and remote port to which data is sent, and the remote address and local port on which to receive data. However, some media may define to use these to establish a control channel for the actual media flow.
此地址和端口的语义取决于定义的媒体和传输协议。默认情况下，这是数据发送到的远程地址和远程端口，以及接收数据的远程地址和本地端口。然而，一些介质可能定义为使用这些来建立实际介质流的控制通道。
Sessions may either be 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.
无论本地时区或夏令时如何，此计时信息都是全局一致的。
It is possible to create both public sessions and private sessions. Private sessions will typically be conveyed by encrypting the session description to distribute it. The details of how encryption is performed are dependent on the mechanism used to convey SDP - see [4] for how this is done for session announcements.
可以创建公共会话和私有会话。私有会话通常通过加密会话描述来分发。如何执行加密的详细信息取决于用于传递SDP的机制-有关会话通知的加密方式，请参见[4]。
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 Universal Resources 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 announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated.
当许多会话描述由SAP或任何其他广告机制分发时，可能需要从不感兴趣的公告中筛选感兴趣的公告。SDP支持会话的分类机制，该机制能够实现自动化。
The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding (RFC 2044) 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. Internationalization only applies to free-text fields (session name and background information), and not to SDP as a whole.
SDP规范建议在UTF-8编码（RFC 2044）中使用ISO10646字符集，以允许表示多种不同的语言。然而，为了有助于紧凑表示，SDP还允许在需要时使用其他字符集，如ISO 8859-1。国际化仅适用于自由文本字段（会话名称和背景信息），而不适用于整个SDP。
SDP session descriptions are entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attributes names use only the US-ASCII subset of UTF-8, but textual fields and attribute values may use the full ISO 10646 character set. The textual form, as opposed to a binary encoding such as ASN/1 or XDR,
SDP会话描述完全是使用UTF-8编码的ISO10646字符集的文本。SDP字段名和属性名仅使用UTF-8的US-ASCII子集，但文本字段和属性值可能使用完整的ISO 10646字符集。文本形式，与二进制编码（如ASN/1或XDR）相反，
was chosen to enhance portability, to enable a variety of transports to be used (e.g, session description in a MIME email message) and to allow flexible, text-based toolkits (e.g., Tcl/Tk ) to be used to generate and to process session descriptions. However, since the total bandwidth allocated to all SAP announcements is strictly limited, the encoding is deliberately compact. Also, since announcements may be transported via very unreliable means (e.g., email) 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 announcements which could be detected easily and discarded. This also allows rapid discarding of encrypted announcements for which a receiver does not have the correct key.
选择它是为了增强可移植性，允许使用各种传输（例如，MIME电子邮件中的会话描述），并允许使用灵活的基于文本的工具包（例如，Tcl/Tk）来生成和处理会话描述。但是，由于分配给所有SAP公告的总带宽受到严格限制，因此编码特意紧凑。此外，由于公告可能通过非常不可靠的方式（如电子邮件）传输或被中间缓存服务器损坏，因此编码设计有严格的顺序和格式规则，因此大多数错误都会导致格式错误的公告，很容易被检测到并丢弃。这还允许快速丢弃接收方没有正确密钥的加密公告。
An SDP session description consists of a number of lines of text of the form <type>=<value> <type> is always exactly one character and is case-significant. <value> is a structured text string whose format depends on <type>. It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the `=' sign. In general <value> is either a number of fields delimited by a single space character or a free format string.
SDP会话描述由许多行文本组成，其形式为<type>=<value><type>始终是一个字符，且大小写重要<value>是一个结构化文本字符串，其格式取决于<type>。除非特定字段另有定义，否则它也具有大小写重要性。“=”符号两边都不允许有空格。通常，<value>是由单个空格字符或自由格式字符串分隔的多个字段。
A session description consists of a session-level description (details that apply to the whole session and all media streams) and optionally several media-level descriptions (details that apply onto to a single media stream).
会话描述包括会话级别描述（适用于整个会话和所有媒体流的详细信息）和可选的多个媒体级别描述（适用于单个媒体流的详细信息）。
An announcement 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. The media description starts with an `m=' line and continues to the next media description 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.
公告由会话级部分和零个或多个媒体级部分组成。会话级部分以“v=”行开始，然后继续到第一个媒体级部分。媒体描述以“m=”行开始，然后继续到下一个媒体描述或整个会话描述的结尾。通常，会话级别值是所有介质的默认值，除非被等效介质级别值覆盖。
When SDP is conveyed by SAP, only one session description is allowed per packet. When SDP is conveyed by other means, many SDP session descriptions may be concatenated together (the `v=' line indicating the start of a session description terminates the previous description). 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 `*'.
当SDP由SAP传输时，每个数据包只允许一个会话描述。当通过其他方式传输SDP时，许多SDP会话描述可以连接在一起（表示会话描述开始的“v=”行终止先前的描述）。每个描述中的一些行是必需的，一些是可选的，但所有行都必须完全按照此处给出的顺序出现（固定顺序大大增强了错误检测，并允许使用简单的解析器）。可选项用“*”标记。
Session description
v= (protocol version)
o= (owner/creator and session identifier).
s= (session name)
i=* (session information)
Session description
v= (protocol version)
o= (owner/creator 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=* (bandwidth information)
One or more time descriptions (see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions (see below)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information - not required if included in all media)
b=* (bandwidth information)
One or more time descriptions (see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions (see below)
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
m= (media name and transport address)
i=* (media title)
c=* (connection information - optional if included at session-level)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)
Media description
m= (media name and transport address)
i=* (media title)
c=* (connection information - optional if included at session-level)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)
The set of `type' letters is deliberately small and not intended to be extensible -- SDP parsers must completely ignore any announcement 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 this document) have a defined meaning but others may be added on an application-, media- or session-specific basis. A session directory must ignore any attribute it doesn't understand.
“type”字母的集合故意很小，不可扩展——SDP解析器必须完全忽略任何包含它不理解的“type”字母的公告。“属性”机制（“a=”如下所述）是扩展SDP并使其适应特定应用程序或媒体的主要手段。某些属性（本文档中列出的属性）具有定义的含义，但其他属性可以根据应用程序、媒体或会话的具体情况添加。会话目录必须忽略它不理解的任何属性。
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=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
Text records such as the session name and information are bytes strings which may contain any byte 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. By default these byte strings contain ISO-10646 characters in UTF-8 encoding, but this default may be changed using the `charset' attribute.
会话名称和信息等文本记录是字节字符串，可以包含除0x00（Nul）、0x0a（ASCII换行符）和0x0d（ASCII回车符）之外的任何字节。序列CRLF（0x0d0a）用于结束记录，尽管解析器应该是宽容的，并且也接受以单个换行符终止的记录。默认情况下，这些字节字符串包含UTF-8编码的ISO-10646字符，但可以使用“字符集”属性更改此默认值。
Protocol Version
协议版本
v=0
v=0
The "v=" field gives the version of the Session Description Protocol. There is no minor version number.
“v=”字段给出会话描述协议的版本。没有次要版本号。
Origin
起源
o=<username> <session id> <version> <network type> <address type>
<address>
o=<username> <session id> <version> <network type> <address type>
<address>
The "o=" field gives the originator of the session (their username and the address of the user's host) plus a session id and session version number.
“o=”字段提供会话发起人（其用户名和用户主机地址）以及会话id和会话版本号。
<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. <username> must not contain spaces. <session id> is a numeric string such that the tuple of <username>, <session id>, <network type>, <address type> and <address> form a globally unique identifier for the session.
<username>是用户在发起主机上的登录名，如果发起主机不支持用户ID的概念，则为“-”<用户名>不能包含空格<会话id>是一个数字字符串，因此<username>、<session id>、<network type>、<address type>和<address>的元组构成会话的全局唯一标识符。
The method of <session id> allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) timestamp be used to ensure uniqueness [1].
<session id>分配的方法由创建工具决定，但有人建议使用网络时间协议（NTP）时间戳来确保唯一性[1]。
<version> is a version number for this announcement. It is needed for proxy announcements to detect which of several announcements for the same session is the most recent. Again its usage is up to the
<version>是本次发布的版本号。代理公告需要检测同一会话的几个公告中哪一个是最近的。同样，它的用途取决于用户
creating tool, so long as <version> is increased when a modification is made to the session data. Again, it is recommended (but not mandatory) that an NTP timestamp is used.
创建工具，只要在修改会话数据时增加<version>。同样，建议（但不是强制性的）使用NTP时间戳。
<network type> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet". <address type> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined. <address> is the globally unique 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.
<network type>是给出网络类型的文本字符串。最初，“IN”的定义是指“Internet”<address type>是一个文本字符串，给出后面的地址类型。最初定义为“IP4”和“IP6”<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=”字段用作此会话描述版本的全局唯一标识符，并且除一起使用的版本外的子字段标识会话，而不考虑任何修改。
Session Name
会话名称
s=<session name>
s=<session name>
The "s=" field is the session name. There must be one and only one "s=" field per session description, and it must contain ISO 10646 characters (but see also the `charset' attribute below).
“s=”字段是会话名称。每个会话描述必须只有一个“s=”字段，并且必须包含ISO10646字符（但也请参见下面的“字符集”属性）。
Session and Media Information
会议和媒体信息
i=<session description>
i=<session description>
The "i=" field is information about the session. There may be at most one session-level "i=" field per session description, and at most one "i=" field per media. Although it may be omitted, this is discouraged for session announcements, and user interfaces for composing sessions should require text to be entered. If it is present it must contain ISO 10646 characters (but see also the `charset' attribute below).
“i=”字段是有关会话的信息。每个会话描述最多只能有一个会话级别“i=”字段，每个媒体最多只能有一个“i=”字段。虽然可以省略，但对于会话公告不鼓励这样做，并且用于编写会话的用户界面应该要求输入文本。如果存在，则必须包含ISO10646字符（但也请参见下面的“字符集”属性）。
A single "i=" field can also be used for each media definition. In media definitions, "i=" fields are primarily intended for labeling media streams. As such, they are most likely to be useful when a
每个媒体定义也可以使用一个“i=”字段。在媒体定义中，“i=”字段主要用于标记媒体流。因此，它们最有可能在以下情况下有用：
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.
单个会话具有多个相同媒体类型的不同媒体流。一个例子是两个不同的白板，一个用于幻灯片，一个用于反馈和问题。
URI
URI
u=<URI>
u=<URI>
o A URI is a Universal Resource Identifier as used by WWW clients
o URI是WWW客户端使用的通用资源标识符
o The URI should be a pointer to additional information about the conference
o URI应该是指向有关会议的其他信息的指针
o This field is optional, but if it is present it should be specified before the first media field
o 此字段是可选的，但如果存在，则应在第一个媒体字段之前指定
o No more than one URI field is allowed per session description
o 每个会话描述不允许超过一个URI字段
Email Address and Phone Number
电子邮件地址和电话号码
e=<email address>
p=<phone number>
e=<email address>
p=<phone number>
o These specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement.
o 这些文件指定了会议负责人的联系信息。这不一定是创建会议公告的同一个人。
o Either an email field or a phone field must be specified. Additional email and phone fields are allowed.
o 必须指定电子邮件字段或电话字段。允许使用其他电子邮件和电话字段。
o If these are present, they should be specified before the first media field.
o 如果存在这些字段，则应在第一个媒体字段之前指定它们。
o More than one email or phone field can be given for a session description.
o 可以为会话描述提供多个电子邮件或电话字段。
o Phone numbers should be given in the conventional international
o 电话号码应以传统的国际标准给出
format - preceded by a "+ and the international country code. There must be a space or a hyphen ("-") between the country code and the rest of the phone number. Spaces and hyphens may be used to split up a phone field to aid readability if desired. For example:
格式-前面加“+和国际国家/地区代码。国家/地区代码和电话号码的其余部分之间必须有空格或连字符（“-”）。如果需要，可以使用空格和连字符分隔电话字段以帮助可读性。例如：
p=+44-171-380-7777 or p=+1 617 253 6011
p=+44-171-380-7777 or p=+1 617 253 6011
o 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 should be enclosed in parenthesis if it is present. For example:
o 电子邮件地址和电话号码都可以有一个可选的自由文本字符串与之关联，通常给出可能联系的人的姓名。如果存在，则应将其括在括号中。例如：
e=mjh@isi.edu (Mark Handley)
e=mjh@isi.edu（马克·汉德利）
The alternative RFC822 name quoting convention is also allowed for both email addresses and phone numbers. For example,
电子邮件地址和电话号码也允许使用RFC822名称引用约定。例如
e=Mark Handley <mjh@isi.edu>
e=Mark Handley <mjh@isi.edu>
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 charset session-level attribute is set.
自由文本字符串应采用UTF-8编码的ISO-10646字符集，或者，如果设置了适当的字符集会话级别属性，则应采用ISO-8859-1或其他编码。
Connection Data
连接数据
c=<network type> <address type> <connection address>
c=<network type> <address type> <connection address>
The "c=" field contains connection data.
“c=”字段包含连接数据。
A session announcement must contain one "c=" field in each media description (see below) or a "c=" field at the session-level. It may contain a session-level "c=" field and one additional "c=" field per media description, in which case the per-media values override the session-level settings for the relevant media.
会话公告必须在每个媒体描述（见下文）中包含一个“c=”字段，或在会话级别包含一个“c=”字段。它可能包含一个会话级别“c=”字段和一个附加的“c=”字段（每个媒体描述），在这种情况下，每媒体值将覆盖相关媒体的会话级别设置。
The first sub-field is the network type, which is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet".
第一个子字段是网络类型，它是给出网络类型的文本字符串。最初，“IN”的定义是指“Internet”。
The second sub-field is the address type. This allows SDP to be used for sessions that are not IP based. Currently only IP4 is defined.
第二个子字段是地址类型。这允许SDP用于非基于IP的会话。目前只定义了IP4。
The third sub-field is the connection address. Optional extra subfields may be added after the connection address depending on the value of the <address type> field.
第三个子字段是连接地址。根据<address type>字段的值，可以在连接地址之后添加可选的额外子字段。
For IP4 addresses, the connection address is defined as follows:
对于IP4地址，连接地址定义如下：
o Typically the connection address will be a class-D IP multicast
o 通常，连接地址为D类IP多播
group address. If the session is not multicast, then the connection address contains the fully-qualified domain name or 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 fully-qualified domain names or unicast addresses
组地址。如果会话不是多播，则连接地址包含由其他属性字段确定的预期数据源或数据中继或数据接收器的完全限定域名或单播IP地址。不希望完全限定的域名或单播地址
will be given in a session description that is communicated by a multicast announcement, though this is not prohibited. If a unicast data stream is to pass through a network address translator, the use of a fully-qualified domain name rather than an unicast IP address is RECOMMENDED. In other cases, the use of an IP address to specify a particular interface on a multi-homed host might be required. Thus this specification leaves the decision as to which to use up to the individual application, but all applications MUST be able to cope with receiving both formats.
将在通过多播公告进行通信的会话描述中给出，但这并不是禁止的。如果单播数据流要通过网络地址转换器，建议使用完全限定的域名，而不是单播IP地址。在其他情况下，可能需要使用IP地址在多宿主主机上指定特定接口。因此，本规范将决定使用哪种格式留给单个应用程序，但所有应用程序都必须能够处理接收这两种格式。
o Conferences using an IP 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.
o 使用IP多播连接地址的会议除多播地址外，还必须具有生存时间（TTL）值。TTL和地址一起定义了在此会议中发送的多播数据包的范围。TTL值必须在0-255范围内。
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.1.1/127
c=在IP4224.2.1.1/127中
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
Multiple addresses or "c=" lines can only be specified on a per-media basis, and not for a session-level "c=" field.
只能在每种介质上指定多个地址或“c=”行，而不能为会话级别“c=”字段指定多个地址或“c=”行。
It is illegal for the slash notation described above to be used for IP unicast addresses.
上述斜杠符号用于IP单播地址是非法的。
Bandwidth
带宽
b=<modifier>:<bandwidth-value>
b=<modifier>:<bandwidth-value>
o This specifies the proposed bandwidth to be used by the session or media, and is optional.
o 这指定会话或媒体使用的建议带宽，并且是可选的。
o <bandwidth-value> is in kilobits per second
o <bandwidth value>的单位为每秒千位
o <modifier> is a single alphanumeric word giving the meaning of the bandwidth figure.
o <modifier>是一个字母数字单词，表示带宽数字的含义。
o Two modifiers are initially defined:
o 最初定义了两个修改器：
CT Conference Total: An implicit maximum bandwidth is associated with each TTL on the Mbone or within a particular multicast administrative scope region (the Mbone bandwidth vs. TTL limits are given in the MBone FAQ). 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 primary purpose of this is to give an approximate idea as to whether two or more conferences can co-exist simultaneously.
CT会议总计：Mbone上或特定多播管理范围区域内的每个TTL都有一个隐含的最大带宽（Mbone带宽与TTL限制在Mbone FAQ中给出）。如果会话或会话中媒体的带宽与作用域中隐含的带宽不同，则应为会话提供“b=CT:…”行，给出所用带宽的建议上限。其主要目的是给出两个或多个会议是否可以同时共存的大致想法。
AS Application-Specific Maximum: The bandwidth is interpreted to be application-specific, i.e., 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.
作为应用程序特定的最大值：带宽被解释为应用程序特定的，即，将是应用程序的最大带宽概念。通常，如果适用，这将与应用程序的“最大带宽”控件上设置的内容一致。
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给出了单个站点上单个媒体的带宽数字，尽管可能有多个站点同时发送。
o Extension Mechanism: Tool writers can define experimental bandwidth modifiers by prefixing their modifier with "X-". For example:
o 扩展机制：工具编写者可以通过在它们的修饰符前面加上“X-”来定义实验带宽修饰符。例如：
b=X-YZ:128
b=X-YZ:128
SDP parsers should ignore bandwidth fields with unknown modifiers. Modifiers should be alpha-numeric and, although no length limit is given, they are recommended to be short.
SDP解析器应该忽略具有未知修饰符的带宽字段。修饰符应为字母数字，虽然没有给出长度限制，但建议缩短。
Times, Repeat Times and Time Zones
时间、重复时间和时区
t=<start time> <stop time>
t=<start time> <stop time>
o "t=" fields specify the start and stop times for a conference session. Multiple "t=" fields may be used if a session is active at multiple irregularly spaced times; each additional "t=" field specifies an additional period of time for which the session will be active. If the session is active at regular times, an "r=" field (see below) should be used in addition to and following a "t=" field - in which case the "t=" field specifies the start and stop times of the repeat sequence.
o “t=”字段指定会议会话的开始和停止时间。如果会话在多个不规则间隔的时间处于活动状态，则可以使用多个“t=”字段；每个附加“t=”字段指定会话活动的附加时间段。如果会话在正常时间处于活动状态，则除了“t=”字段之外，还应使用一个“r=”字段（见下文）——在这种情况下，“t=”字段指定重复序列的开始和停止时间。
o The first and second sub-fields give the start and stop times for the conference respectively. These values are the decimal representation of Network Time Protocol (NTP) time values in seconds [1]. To convert these values to UNIX time, subtract decimal 2208988800.
o 第一和第二个子字段分别给出会议的开始和停止时间。这些值是以秒为单位的网络时间协议（NTP）时间值的十进制表示[1]。要将这些值转换为UNIX时间，请减去十进制2208988800。
o 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.
o 如果“停止时间”设置为零，则会话不受限制，尽管它在开始时间之后才会变为活动状态。如果开始时间也为零，则会话被视为永久会话。
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 which state precisely when the session will be active. In general, permanent sessions should not be created for any session expected to have a duration of less than 2 months, and should be discouraged for sessions expected to have a duration of less than 6 months.
永久会话可以向用户显示为从未处于活动状态，除非存在相关的重复时间，该重复时间精确地表示会话将处于活动状态的时间。一般来说，不应为预期会期少于2个月的任何届会设立常设届会，并且不应鼓励为预期会期少于6个月的届会设立常设届会。
r=<repeat interval> <active duration> <list of offsets from start-
time>
r=<repeat interval> <active duration> <list of offsets from start-
time>
o "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
o “r=”字段指定会话的重复时间。例如，如果一个会话在周一上午10点和周二上午11点处于活动状态
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:
三个月内每周工作一小时，则相应“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 announcements 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 - minutes (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness but not recommended)
d-天（86400秒）h-分（3600秒）m-分（60秒）s-秒（允许完整，但不推荐）
Thus, the above announcement could also have been written:
因此，上述公告也可以写成：
r=7d 1h 0 25h
r=7d 1h 0 25h
Monthly and yearly repeats cannot currently 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> ....
o To schedule a repeated session which spans a change from daylight-saving time to standard time or vice-versa, it is necessary to specify offsets from the base repeat times. This is required because different time zones change time at different times of day, different countries change to or from daylight time on different dates, and some countries do not have daylight saving time at all.
o 要计划从夏令时更改为标准时间或从夏令时更改为标准时间的重复会话，必须指定与基本重复时间的偏移。这是必需的，因为不同的时区在一天中的不同时间更改时间，不同的国家在不同的日期更改为夏令时或从夏令时更改为夏令时，而有些国家根本没有夏令时。
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:
例如：
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.
这指定在时间288284526，计算会话重复时间的时基向后移动1小时，并在时间2898848070，恢复会话的原始时基。调整总是相对于指定的开始时间-它们不是累积的。
o 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 announcement.
o 如果一次会议可能持续几年，预计会议公告将定期修改，而不是在一次公告中传递几年的调整。
Encryption Keys
加密密钥
k=<method>
k=<method>:<encryption key>
k=<method>
k=<method>:<encryption key>
o The session description protocol may be used to convey encryption keys. 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.
o 会话描述协议可用于传送加密密钥。在第一个媒体条目之前（在这种情况下，它适用于会话中的所有媒体），或根据需要为每个媒体条目指定一个键字段。
o The format of keys and their usage is outside the scope of this document, but see [3].
o 密钥的格式及其用法不在本文档的范围内，但请参见[3]。
o The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given.
o 该方法指示用于通过外部手段或从给定的编码加密密钥获得可用密钥的机制。
The following methods are defined:
定义了以下方法：
k=clear:<encryption key> The encryption key (as described in [3] for RTP media streams under the AV profile) is included untransformed in this key field.
k=清除：<encryption key>加密密钥（如AV配置文件下RTP媒体流的[3]中所述）未经转换包含在此密钥字段中。
k=base64:<encoded encryption key> The encryption key (as described in [3] for RTP media streams under the AV profile) is included in this key field but has been base64 encoded because it includes characters that are prohibited in SDP.
k=base64:<encoded encryption key>加密密钥（如AV配置文件下RTP媒体流的[3]中所述）包含在此密钥字段中，但已进行base64编码，因为它包含SDP中禁止的字符。
k=uri:<URI to obtain key> A Universal Resource Identifier as used by WWW clients is included in this key field. The URI refers to the data containing the key, and may require additional authentication
k=uri:<uri to Acquire key>此密钥字段中包含WWW客户端使用的通用资源标识符。URI指的是包含密钥的数据，可能需要额外的身份验证
before the key can be returned. When a request is made to the given URI, the MIME content-type of the reply specifies the encoding for the key in the reply. The key should not be obtained until the user wishes to join the session to reduce synchronisation of requests to the WWW server(s).
在返回密钥之前。当对给定URI发出请求时，应答的MIME内容类型指定应答中密钥的编码。在用户希望加入会话以减少对WWW服务器的请求同步之前，不应获取密钥。
k=prompt 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 decrypt the media streams.
k=提示此SDP描述中不包括密钥，但此密钥字段引用的会话或媒体流已加密。尝试加入会话时，应提示用户输入密钥，然后应使用此用户提供的密钥对媒体流进行解密。
Attributes
属性
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) which 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; an example might be the conference's floor control policy.
媒体描述可以具有任意数量的特定于媒体的属性（“A=”字段）。这些属性称为“媒体级别”属性，并添加有关媒体流的信息。属性字段也可以添加到第一个媒体字段之前；这些“会议级别”属性传达了适用于整个会议而非个别媒体的附加信息；会议的发言权控制政策就是一个例子。
Attribute fields may be of two forms:
属性字段可以有两种形式：
o property attributes. 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 value attributes. A value attribute is of the form "a=<attribute>:<value>". An example might be that a whiteboard could have the value attribute "a=orient:landscape"
o 值属性。值属性的形式为“A=<attribute>：<value>”。例如，白板可能具有值属性“a=orient:横向”
Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of announcements in general and of attributes in particular.
属性解释取决于所调用的媒体工具。因此，会话描述的接收者在解释一般公告和特定属性时应该是可配置的。
Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8.
属性名称必须在ISO-10646/UTF-8的US-ASCII子集中。
Attribute values are byte strings, and MAY use any byte 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 it's 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 that will be commonly used can be registered with IANA (see Appendix B). Unregistered attributes should begin with "X-" to prevent inadvertent collision with registered attributes. In either case, if an attribute is received that is not understood, it should simply be ignored by the receiver.
通常使用的属性可以向IANA注册（见附录B）。未注册的属性应以“X-”开头，以防止与已注册的属性发生意外冲突。在任何一种情况下，如果接收到一个不被理解的属性，那么接收者都应该忽略它。
Media Announcements
媒体公告
m=<media> <port> <transport> <fmt list>
m=<media> <port> <transport> <fmt list>
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 also has several sub-fields:
会话描述可以包含许多媒体描述。每个媒体描述以一个“m=”字段开始，并由下一个“m=”字段或会话描述结束时终止。媒体字段也有几个子字段：
o The first sub-field is the media type. Currently defined media are "audio", "video", "application", "data" and "control", though this list may be extended as new communication modalities emerge (e.g., telepresense). The difference between "application" and "data" is that the former is a media flow such as whiteboard information, and the latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user. "control" is used to specify an additional conference control channel for the session.
o 第一个子字段是媒体类型。目前定义的媒体有“音频”、“视频”、“应用”、“数据”和“控制”，但随着新的通信方式的出现（如远程呈现），该列表可能会扩展。“应用程序”和“数据”之间的区别在于前者是诸如白板信息之类的媒体流，而后者是诸如通常不会向用户显示的程序可执行文件的多播之类的批量数据传输。“控制”用于指定会话的附加会议控制通道。
o The second sub-field is the transport port to which the media stream will be 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 third sub-field. Other ports used by the media application (such as the RTCP port, see [2]) should be derived algorithmically from the base media port.
o 第二个子字段是媒体流将发送到的传输端口。传输端口的含义取决于相关“c”字段中指定的正在使用的网络以及第三个子字段中定义的传输协议。媒体应用程序使用的其他端口（如RTCP端口，请参见[2]）应通过算法从基本媒体端口派生。
Note: For transports based on UDP, the value should be in the range 1024 to 65535 inclusive. For RTP compliance it should be an even number.
注意：对于基于UDP的传输，该值应在1024到65535（含）的范围内。对于RTP合规性，它应该是偶数。
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> <transport> <fmt list>
m=<media> <port>/<number of ports> <transport> <fmt list>
In such a case, the ports used depend on the transport protocol. For RTP, only the even ports are used for data and the corresponding one-higher odd port is used for RTCP. For example:
在这种情况下，使用的端口取决于传输协议。对于RTP，只有偶数端口用于数据，相应的一个较高的奇数端口用于RTCP。例如：
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).
将指定端口49170和49171形成一个RTP/RTCP对，49172和49173形成第二个RTP/RTCP对。RTP/AVP是传输协议，31是格式（见下文）。
It is illegal for both multiple addresses to be specified in the "c=" field and for multiple ports to be specified in the "m=" field in the same session description.
在同一会话描述中，在“c=”字段中指定多个地址和在“m=”字段中指定多个端口都是非法的。
o The third sub-field is the transport protocol. The transport protocol values are dependent on the address-type field in the "c=" fields. Thus a "c=" field of IP4 defines that the transport protocol runs over IP4. For IP4, it is normally expected that most media traffic will be carried as RTP over UDP. The following transport protocols are preliminarily defined, but may be extended through registration of new protocols with IANA:
o 第三个子字段是传输协议。传输协议值取决于“c=”字段中的地址类型字段。因此，IP4的“c=”字段定义传输协议在IP4上运行。对于IP4，通常预期大多数媒体流量将通过UDP以RTP方式传输。以下传输协议已初步定义，但可通过向IANA注册新协议进行扩展：
- RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP.
- RTP/AVP——IETF的实时传输协议，使用通过UDP传输的音频/视频配置文件。
- udp - User Datagram Protocol
- 用户数据报协议
If an application uses a single combined proprietary media format and transport protocol over UDP, then simply specifying the transport protocol as udp and using the format field to distinguish the combined protocol is recommended. If a transport protocol is used over UDP to carry several distinct media types that need to be distinguished by a session directory, then specifying the transport protocol and media format separately is necessary. RTP is an example of a transport-protocol that carries multiple payload formats that must be distinguished by the session directory for it to know how to start appropriate tools, relays, mixers or recorders.
如果应用程序通过UDP使用单一组合的专有媒体格式和传输协议，则建议只需将传输协议指定为UDP并使用format字段来区分组合协议。如果通过UDP使用传输协议来承载需要通过会话目录区分的几种不同媒体类型，则需要分别指定传输协议和媒体格式。RTP是传输协议的一个示例，它承载多个有效负载格式，必须通过会话目录进行区分，以便知道如何启动适当的工具、继电器、混合器或记录器。
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 PCM audio and RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible.
除媒体格式外，指定传输协议的主要原因是，即使网络协议相同，相同的标准媒体格式也可能通过不同的传输协议传输-历史示例为vat PCM audio和RTP PCM audio。此外，还可以使用特定于传输协议但与格式无关的继电器和监视工具。
For RTP media streams operating under the RTP Audio/Video Profile [3], the protocol field is "RTP/AVP". Should other RTP profiles be defined in the future, their profiles will be specified in the same way. For example, the protocol field "RTP/XYZ" would specify RTP operating under a profile whose short name is "XYZ".
对于在RTP音频/视频配置文件[3]下运行的RTP媒体流，协议字段为“RTP/AVP”。如果将来定义其他RTP配置文件，将以相同的方式指定它们的配置文件。例如，协议字段“RTP/XYZ”将指定在短名称为“XYZ”的概要文件下运行的RTP。
o The fourth and subsequent sub-fields are media formats. For audio and video, these will normally be a media payload type as defined in the RTP Audio/Video Profile.
o 第四个和后续子字段是媒体格式。对于音频和视频，它们通常是RTP音频/视频配置文件中定义的媒体有效负载类型。
When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session.
当给出有效负载格式列表时，这意味着所有这些格式都可以在会话中使用，但这些格式中的第一种是会话的默认格式。
For media whose transport protocol is not RTP or UDP the format field is protocol specific. Such formats should be defined in an additional specification document.
对于传输协议不是RTP或UDP的媒体，格式字段是特定于协议的。此类格式应在附加规范文件中定义。
For media whose transport protocol is RTP, SDP can be used to provide a dynamic binding of media encoding to RTP payload type. The encoding names in the RTP AV Profile do not specify unique audio encodings (in terms of clock rate and number of audio channels), and so they are not used directly in SDP format fields. Instead, the payload type number should be used to specify the format for static payload types and the payload type number along with additional encoding information should be used for dynamically allocated payload types.
对于传输协议为RTP的媒体，SDP可用于提供媒体编码到RTP有效负载类型的动态绑定。RTP AV配置文件中的编码名称没有指定唯一的音频编码（在时钟频率和音频通道数量方面），因此它们不直接用于SDP格式字段。相反，应使用有效负载类型编号来指定静态有效负载类型的格式，并且应将有效负载类型编号以及其他编码信息用于动态分配的有效负载类型。
An example of a static payload type is u-law PCM coded single channel audio sampled at 8KHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so the media field for such a stream sent to UDP port 49232 is:
静态有效负载类型的一个示例是以8KHz采样的u律PCM编码单声道音频。这在RTP音频/视频配置文件中完全定义为有效负载类型0，因此发送到UDP端口49232的此类流的媒体字段为：
m=video 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 16KHz. If we wish to use dynamic RTP/AVP payload type 98 for such a stream, additional information is required to decode it:
动态有效负载类型的一个示例是以16KHz采样的16位线性编码立体声音频。如果我们希望对此类流使用动态RTP/AVP有效负载类型98，则需要额外的信息对其进行解码：
m=video 49232 RTP/AVP 98
m=视频49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
a=rtpmap:98 L16/16000/2
The general form of an rtpmap attribute is:
rtpmap属性的一般形式为：
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]
For audio streams, <encoding parameters> may specify the number of audio channels. This parameter may be omitted if the number of channels is one provided no additional parameters are needed. For video streams, no encoding parameters are currently specified.
对于音频流，<encoding parameters>可以指定音频通道的数量。如果通道数为1，则可以省略此参数，前提是不需要其他参数。对于视频流，当前未指定编码参数。
Additional parameters may be defined in the future, but codecspecific parameters should not be added. Parameters added to an rtpmap attribute should only be those required for a session directory to make the choice of appropriate media too to participate in a session. Codec-specific parameters should be added in other attributes.
以后可能会定义其他参数，但不应添加特定于编解码器的参数。添加到rtpmap属性的参数应仅为会话目录选择适当介质以参与会话所需的参数。应在其他属性中添加特定于编解码器的参数。
Up to one rtpmap attribute can be defined for each media format specified. Thus we might have:
对于指定的每种媒体格式，最多可以定义一个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.
指定使用动态有效负载类型的RTP配置文件必须定义一组有效的编码名称和/或注册编码名称的方法（如果该配置文件要与SDP一起使用）。
Experimental encoding formats can also be specified using rtpmap. RTP formats that are not registered as standard format names must be preceded by "X-". Thus a new experimental redundant audio stream called GSMLPC using dynamic payload type 99 could be specified as:
还可以使用rtpmap指定实验编码格式。未注册为标准格式名称的RTP格式必须以“X-”开头。因此，使用动态有效负载类型99的称为GSMLPC的新实验冗余音频流可以指定为：
m=video 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000
m=video 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000
Such an experimental encoding requires that any site wishing to receive the media stream has relevant configured state in its session directory to know which tools are appropriate.
这种实验性编码要求希望接收媒体流的任何站点在其会话目录中具有相关的配置状态，以知道哪些工具是合适的。
Note that 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 below.
请注意，RTP音频格式通常不包括有关每个数据包的采样数的信息。如果需要非默认（如RTP音频/视频配置文件中所定义）打包，则使用“ptime”属性，如下所示。
For more details on RTP audio and video formats, see [3].
有关RTP音频和视频格式的更多详细信息，请参阅[3]。
o Formats for non-RTP media should be registered as MIME content types as described in Appendix B. For example, the LBL whiteboard application might be registered as MIME content-type application/wb with encoding considerations specifying that it operates over UDP, with no appropriate file format. In SDP this would then be expressed using a combination of the "media" field and the "fmt" field, as follows:
o 非RTP媒体的格式应注册为MIME内容类型，如附录B所述。例如，LBL白板应用程序可能注册为MIME内容类型应用程序/wb，编码注意事项指定它在UDP上运行，没有适当的文件格式。在SDP中，这将使用“媒体”字段和“fmt”字段的组合表示，如下所示：
m=application 32416 udp wb
m=应用程序32416 udp wb
Suggested Attributes
建议属性
The following attributes are suggested. Since application writers may add new attributes as they are required, this list is not exhaustive.
建议使用以下属性。由于应用程序编写器可以根据需要添加新属性，因此此列表并不详尽。
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. It would probably have been a compulsory separate field, except for its experimental nature at this time. It is a session-level attribute, and is not dependent on charset.
a=cat:<category>此属性提供会话的点分隔层次类别。这是为了使接收器能够按类别过滤不需要的会话。这可能是一个强制性的独立领域，但此时的实验性质除外。它是会话级属性，不依赖于字符集。
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. 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.
a=keywds:<keywords>与cat属性类似，这有助于识别接收方想要的会话。这允许接收者根据描述会话目的的关键字选择感兴趣的会话。它是会话级属性。它是一个依赖于字符集的属性，这意味着如果指定了一个字符集，则应在为会话描述指定的字符集中解释它的值，或者默认情况下在ISO 10646/UTF-8中解释它的值。
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 is not dependent on charset.
a=tool:<name and version of tool>这给出了用于创建会话描述的工具的名称和版本号。它是会话级属性，不依赖于字符集。
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. 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 attribute, and is not dependent on charset.
a=ptime:<packet time>这给出了数据包中媒体表示的时间长度（毫秒）。这可能仅对音频数据有意义。无需知道解码RTP或vat音频的ptime，其目的是作为音频编码/打包的建议。它是媒体属性，不依赖于字符集。
a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session or media attribute, and is not dependent on charset.
a=recvonly这指定工具应在适用的情况下以仅接收模式启动。它可以是会话或媒体属性，并且不依赖于字符集。
a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools such as wb which defaults to receive only mode. It can be either a session or media attribute, and is not dependent on charset.
a=sendrecv这指定工具应在发送和接收模式下启动。这对于使用wb等工具（默认为仅接收模式）的交互式会议是必要的。它可以是会话或媒体属性，并且不依赖于字符集。
a=sendonly 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 use, one sendonly and one recvonly. It can be either a session or media attribute, but would normally only be used as a media attribute, and is not dependent on charset.
a=sendonly此选项指定应在仅发送模式下启动工具。一个示例可能是，将对业务目的地使用不同于对业务源使用的单播地址。在这种情况下，可以使用两种媒体描述，一种仅发送，另一种仅接收。它可以是会话或媒体属性，但通常仅用作媒体属性，不依赖于字符集。
a=orient:<whiteboard orientation> Normally this is only used in a whiteboard media specification. It specifies the orientation of a the whiteboard on the screen. It is a media attribute. Permitted values are `portrait', `landscape' and `seascape' (upside down landscape). It is not dependent on charset
a=方向：<whiteboard orientation>通常仅在白板介质规范中使用。它指定白板在屏幕上的方向。这是一种媒体属性。允许的值为“纵向”、“横向”和“海景”（倒置横向）。它不依赖于字符集
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.
a=类型：<conference type>指定会议的类型。建议值为“广播”、“会议”、“主持人”、“测试”和“H332”`“recvonly”应为“type:broadcast”会话的默认值，“type:meeting”应表示“sendrecv”，而“type:moderated”应表示使用了楼层控制工具，并且媒体工具已启动，以便“静音”加入会议的新站点。
Specifying the attribute type:H332 indicates that this loosely coupled session is part of a H.332 session as defined in the ITU H.332 specification [10]. Media tools should be started `recvonly'.
指定属性类型：H332表示此松散耦合会话是ITU H.332规范[10]中定义的H.332会话的一部分。媒体工具应“仅可重新启动”。
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 is not dependent on charset.
type属性是会话级属性，不依赖于字符集。
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 such as ISO-8859-1 for Northern European languages. In particular, the ISO 8859-1 is specified with the following SDP attribute:
a=charset:<character set>指定用于显示会话名称和信息数据的字符集。默认情况下，使用UTF-8编码的ISO-10646字符集。如果需要更紧凑的表示，可以使用其他字符集，如北欧语言的ISO-8859-1。具体而言，ISO 8859-1具有以下SDP属性：
a=charset:ISO-8859-1
a=字符集：ISO-8859-1
This is a session-level attribute; if this attribute is present, it must be before the first media field. 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 byte 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 appearing within text fields.
请注意，指定的字符集仍然必须禁止使用字节0x00（Nul）、0x0A（LF）和0x0d（CR）。需要使用这些字符的字符集必须定义一种引用机制，以防止这些字节出现在文本字段中。
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.
a=sdplang:<language tag>这可以是会话级属性或媒体级属性。作为会话级别属性，它指定会话描述的语言。作为媒体级别属性，它指定与该媒体关联的任何媒体级别SDP信息字段的语言。如果会话描述或媒体中的多种语言使用多种语言，则可以在会话或媒体级别提供多个sdplang属性，在这种情况下，属性的顺序表示会话或媒体中各种语言的重要性从最重要到最不重要的顺序。
In general, sending session descriptions consisting of multiple languages should be 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属性，尽管不推荐使用。
The sdplang attribute value must be a single RFC 1766 language tag in US-ASCII. It is not dependent on the charset attribute. An sdplang attribute SHOULD be specified when a session is of
sdplang属性值必须是US-ASCII格式的单个RFC 1766语言标记。它不依赖于charset属性。当会话为时，应指定sdplang属性
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.
在无法假定收件人的语言或会话使用与当地假定规范不同的语言的情况下，有足够的范围跨越地理边界。
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 multiple languages 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.
a=lang:<language tag>这可以是会话级属性或媒体级属性。作为会话级别属性，它指定所描述会话的默认语言。作为媒体级别属性，它指定该媒体的语言，覆盖指定的任何会话级别语言。如果会话描述或媒体使用多种语言，则可以在会话或媒体级别提供多种语言属性，在这种情况下，属性的顺序表示会话或媒体中各种语言的重要性从最重要到最不重要的顺序。
The lang attribute value must be a single RFC 1766 language tag in US-ASCII. 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 1766语言标记。它不依赖于charset属性。当会话的范围足以跨越无法假定收件人语言的地理边界时，或者会话使用与本地假定规范不同的语言时，应指定lang属性。
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 attribute, is only defined for video media, and is not dependent on charset.
a=帧速率：<frame rate>这给出了最大视频帧速率（以帧数/秒为单位）。其目的是作为视频数据编码的建议。允许使用符号“<integer><fraction>”对分数值进行十进制表示。它是一个媒体属性，仅为视频媒体定义，不依赖于字符集。
a=quality:<quality> This gives a suggestion for the quality of the encoding as an integer value.
a=quality:<quality>这为整数值编码的质量提供了建议。
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 in the range 0 to 10, with the following suggested meaning:
视频质量属性的目的是指定帧速率和静态图像质量之间的非默认权衡。对于视频，值的范围为0到10，建议含义如下：
10 - the best still-image quality the compression scheme can give.
10-压缩方案所能提供的最佳静态图像质量。
5 - the default behaviour given no quality suggestion.
5-未给出质量建议的默认行为。
0 - the worst still-image quality the codec designer thinks is still usable.
0-编解码器设计师认为仍然可用的最差静态图像质量。
It is a media attribute, and is not dependent on charset.
它是媒体属性，不依赖于字符集。
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 doesn't 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 unchanged to the media tool that will use this format.
a=fmtp:<format><format specific parameters>此属性允许以SDP不必理解的方式传递特定于特定格式的参数。格式必须是为媒体指定的格式之一。特定于格式的参数可以是SDP需要传递的任何一组参数，这些参数将不变地提供给将使用此格式的媒体工具。
It is a media attribute, and is not dependent on charset.
它是媒体属性，不依赖于字符集。
There is some debate over the way conference control policy should be communicated. In general, the authors believe that an implicit declarative style of specifying conference control is desirable where possible.
关于会议控制政策的沟通方式存在一些争论。总的来说，作者认为在可能的情况下，指定会议控制的隐式声明风格是可取的。
A simple declarative style uses a single conference attribute field before the first media field, possibly supplemented by properties such as `recvonly' for some of the media tools. This conference attribute conveys the conference control policy. An example might be:
简单的声明性样式在第一个媒体字段之前使用一个会议属性字段，对于某些媒体工具，可能会使用诸如“recvonly”之类的属性进行补充。此会议属性传递会议控制策略。例如：
a=type:moderated
a=类型：中度
In some cases, however, it is possible that this may be insufficient to communicate the details of an unusual conference control policy. If this is the case, then a conference attribute specifying external control might be set, and then one or more "media" fields might be used to specify the conference control tools and configuration data for those tools. An example is an ITU H.332 session:
但是，在某些情况下，这可能不足以传达异常会议控制策略的详细信息。如果是这种情况，则可以设置指定外部控制的会议属性，然后可以使用一个或多个“媒体”字段指定这些工具的会议控制工具和配置数据。例如，ITU H.332会议：
c=IN IP4 224.5.6.7
a=type:H332
m=audio 49230 RTP/AVP 0
m=video 49232 RTP/AVP 31
m=application 12349 udp wb
m=control 49234 H323 mc
c=IN IP4 134.134.157.81
c=IN IP4 224.5.6.7
a=type:H332
m=audio 49230 RTP/AVP 0
m=video 49232 RTP/AVP 31
m=application 12349 udp wb
m=control 49234 H323 mc
c=IN IP4 134.134.157.81
In this example, a general conference attribute (type:H332) is specified stating that conference control will be provided by an external H.332 tool, and a contact addresses for the H.323 session multipoint controller is given.
在此示例中，指定了一个通用会议属性（类型：H332），表示会议控制将由外部H.332工具提供，并给出了H.323会话多点控制器的联系地址。
In this document, only the declarative style of conference control declaration is specified. Other forms of conference control should specify an appropriate type attribute, and should define the implications this has for control media.
在本文档中，仅指定了会议控制声明的声明样式。其他形式的会议控制应指定适当的类型属性，并应定义这对控制媒体的影响。
SDP is a session description format that describes multimedia sessions. A session description should not be trusted unless it has been obtained by an authenticated transport protocol from a 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.
SDP是一种描述多媒体会话的会话描述格式。除非会话描述是由经过身份验证的传输协议从可信源获取的，否则不应信任会话描述。许多不同的传输协议可用于分发会话描述，不同传输的身份验证的性质也不同。
One transport that will frequently 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 they are 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 description contain information required to start software on the receivers 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 their consent. Thus a session description arriving by session announcement, email, session invitation, or WWW page SHOULD not deliver the user into an {it interactive} multimedia session without the user being aware that this will happen. As it is not always simple to tell whether a session is interactive or not, applications that are unsure should assume sessions are interactive.
在通过未经验证的传输机制或从不受信任的一方接收会话描述时，解析会话的软件应采取一些预防措施。会话描述包含在接收器系统上启动软件所需的信息。解析会话描述的软件必须不能启动其他软件，除非专门配置为参与多媒体会话的适当软件。通常认为，解析会话描述的软件在用户系统上启动适合参与多媒体会话的软件，而不首先通知用户将启动此类软件并给予其同意，是不合适的。因此，通过会话公告、电子邮件、会话邀请或WWW页面到达的会话描述不应在用户不知道会发生这种情况的情况下将用户交付到{it interactive}多媒体会话中。由于判断会话是否是交互式的并不总是那么简单，因此不确定的应用程序应该假定会话是交互式的。
In this specification, there are no attributes which 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.
在本规范中，没有允许会话描述的接收者被通知以默认传输模式启动多媒体工具的属性。在某些情况下，定义这些属性可能是合适的。如果完成此操作，则解析包含此类属性的会话描述的应用程序应忽略这些属性，或通知用户加入此会话将导致多媒体数据的自动传输。未知属性的默认行为是忽略它。
Session descriptions may be parsed at intermediate systems such as firewalls for the purposes of opening a hole in the firewall to allow the participation in multimedia sessions. It is considered INAPPROPRIATE for a firewall to open such holes for unicast data streams unless the session description comes in a request from inside the firewall.
会话描述可以在诸如防火墙之类的中间系统上进行解析，以便在防火墙上打开一个洞以允许参与多媒体会话。防火墙为单播数据流打开这样的漏洞被认为是不合适的，除非会话描述来自防火墙内部的请求。
For multicast sessions, it is likely that local administrators will apply their own policies, but the exclusive use of "local" or "site-local" administrative scope within the firewall and the refusal of the firewall to open a hole for such scopes will provide separation of global multicast sessions from local ones.
对于多播会话，本地管理员可能会应用他们自己的策略，但在防火墙内独占使用“本地”或“站点本地”管理范围，以及防火墙拒绝为这些范围打开漏洞，将提供全局多播会话与本地多播会话的分离。
Appendix A: SDP Grammar
附录A：SDP语法
This appendix provides an Augmented BNF grammar for SDP. ABNF is defined in RFC 2234.
本附录提供了SDP的扩充BNF语法。ABNF在RFC 2234中定义。
announcement = 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
announcement=原始版本源字段会话名称字段信息字段uri字段电子邮件字段电话字段连接字段带宽字段时间字段关键字字段属性字段媒体描述
proto-version = "v=" 1*DIGIT CRLF
;this memo describes version 0
proto-version = "v=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = "o=" username space sess-id space sess-version space nettype space addrtype space addr CRLF
origin field=“o=”用户名空间sess id空间sess版本空间nettype空间addr空间addr CRLF
session-name-field = "s=" text CRLF
会话名称field=“s=”文本CRLF
information-field = ["i=" text CRLF]
information-field = ["i=" text CRLF]
uri-field = ["u=" uri CRLF]
uri-field = ["u=" uri CRLF]
email-fields = *("e=" email-address CRLF)
email-fields = *("e=" email-address CRLF)
phone-fields = *("p=" phone-number CRLF)
phone-fields = *("p=" phone-number CRLF)
connection-field = ["c=" nettype space addrtype space
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
connection-field = ["c=" nettype space addrtype space
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF)
bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF)
time-fields = 1*( "t=" start-time space stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
time-fields = 1*( "t=" start-time space stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = "r=" repeat-interval space typed-time 1*(space typed-time)
repeat fields=“r=”重复间隔空间类型时间1*（空间类型时间）
zone-adjustments = time space ["-"] typed-time *(space time space ["-"] typed-time)
区域调整=时间空间[“-”]键入的时间*（空间时间空间[“-”]键入的时间）
key-field = ["k=" key-type CRLF]
key-field = ["k=" key-type CRLF]
key-type = "prompt" | "clear:" key-data | "base64:" key-data | "uri:" uri
key type=“prompt”|“clear:“key data |”base64:“key data |”uri:“uri”
key-data = email-safe | "~" | "
key-data = email-safe | "~" | "
attribute-fields = *("a=" attribute CRLF)
attribute-fields = *("a=" 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 = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
media = 1*(alpha-numeric)
;typically "audio", "video", "application"
;or "data"
media = 1*(alpha-numeric)
;typically "audio", "video", "application"
;or "data"
fmt = 1*(alpha-numeric)
;typically an RTP payload type for audio
;and video media
fmt = 1*(alpha-numeric)
;typically an RTP payload type for audio
;and video media
proto = 1*(alpha-numeric)
;typically "RTP/AVP" or "udp" for IP4
proto = 1*(alpha-numeric)
;typically "RTP/AVP" or "udp" for IP4
port = 1*(DIGIT)
;should in the range "1024" to "65535" inclusive
;for UDP based media
port = 1*(DIGIT)
;should in the range "1024" to "65535" inclusive
;for UDP based media
attribute = (att-field ":" att-value) | att-field
attribute = (att-field ":" att-value) | att-field
att-field = 1*(alpha-numeric)
att-field = 1*(alpha-numeric)
att-value = byte-string
att-value = byte-string
sess-id = 1*(DIGIT)
;should be unique for this originating username/host
sess-id = 1*(DIGIT)
;should be unique for this originating username/host
sess-version = 1*(DIGIT)
;0 is a new session
sess-version = 1*(DIGIT)
;0 is a new session
connection-address = multicast-address | addr
连接地址=多播地址| addr
multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl
[ "/" integer ]
;multicast addresses may be in the range
;224.0.0.0 to 239.255.255.255
multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl
[ "/" integer ]
;multicast addresses may be in the range
;224.0.0.0 to 239.255.255.255
ttl = decimal-uchar
ttl = decimal-uchar
start-time = time | "0"
开始时间=时间|“0”
stop-time = time | "0"
停止时间=时间|“0”
time = POS-DIGIT 9*(DIGIT) ;sufficient for 2 more centuries
时间=位置数字9*（数字）；足够再过两个世纪了
repeat-interval = typed-time
repeat-interval = typed-time
typed-time = 1*(DIGIT) [fixed-len-time-unit]
typed-time = 1*(DIGIT) [fixed-len-time-unit]
fixed-len-time-unit = "d" | "h" | "m" | "s"
fixed-len-time-unit = "d" | "h" | "m" | "s"
bwtype = 1*(alpha-numeric)
bwtype = 1*(alpha-numeric)
bandwidth = 1*(DIGIT)
bandwidth = 1*(DIGIT)
username = safe ;pretty wide definition, but doesn't include space
用户名=安全；定义相当宽泛，但不包括空间
email-address = email | email "(" email-safe ")" |
email-safe "<" email ">"
email-address = email | email "(" email-safe ")" |
email-safe "<" email ">"
email = ;defined in RFC822
电邮=；在RFC822中定义
uri= ;defined in RFC1630
uri=；在RFC1630中定义
phone-number = phone | phone "(" email-safe ")" |
email-safe "<" phone ">"
phone-number = phone | phone "(" email-safe ")" |
email-safe "<" phone ">"
phone = "+" POS-DIGIT 1*(space | "-" | DIGIT) ;there must be a space or hyphen between the ;international code and the rest of the number.
phone=“+”位置数字1*（空格|“-”|数字）；之间必须有空格或连字符；国际代码和其他数字。
nettype = "IN" ;list to be extended
nettype=“IN”；待扩展的列表
addrtype = "IP4" | "IP6"
;list to be extended
addrtype = "IP4" | "IP6"
;list to be extended
addr = FQDN | unicast-address
addr=FQDN |单播地址
FQDN = 4*(alpha-numeric|"-"|".") ;fully qualified domain name as specified in RFC1035
FQDN=4*（字母数字|“-“|”）；RFC1035中规定的完全限定域名
unicast-address = IP4-address | IP6-address
单播地址=IP4地址| IP6地址
IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 b1 = decimal-uchar ;less than "224"; not "0" or "127" b4 = decimal-uchar ;not "0"
IP4地址=b1.“十进制uchar”。“十进制uchar”。“b4 b1=十进制uchar”；少于“224”；非“0”或“127”b4=十进制uchar；不是“0”
IP6-address = ;to be defined
IP6地址=；待定义
text = byte-string
;default is to interpret this as IS0-10646 UTF8
;ISO 8859-1 requires a "a=charset:ISO-8859-1"
;session-level attribute to be used
text = byte-string
;default is to interpret this as IS0-10646 UTF8
;ISO 8859-1 requires a "a=charset:ISO-8859-1"
;session-level attribute to be used
byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
;any byte except NUL, CR or LF
byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
;any byte except NUL, CR or LF
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"))
integer = POS-DIGIT *(DIGIT)
整数=位位数*（位数）
alpha-numeric = ALPHA | DIGIT
字母数字=字母数字
DIGIT = "0" | POS-DIGIT
DIGIT=“0”| POS-DIGIT
POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
POS-DIGIT=“1”|“2”|“3”|“4”|“5”|“6”|“7”|“8”|“9”
ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"| "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"| "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"| "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
“a”方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方方|“g”|“h”|“i”|“j”|“k”|“l”|“m”|“n”|“o”|“p”|“q”|“r”|“t”|“u”|“v”|“w”|“x”|“y”|“z”
email-safe = safe | space | tab
电子邮件安全=安全|空间|选项卡
safe = alpha-numeric |
"'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
"#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
"]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
"~" | "
safe = alpha-numeric |
"'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
"#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
"]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
"~" | "
space = %d32
tab = %d9
CRLF = %d13.10
space = %d32
tab = %d9
CRLF = %d13.10
Appendix B: Guidelines for registering SDP names with IANA
附录B：向IANA注册SDP名称的指南
There are seven field names that may be registered with IANA. Using the terminology in the SDP specification BNF, they are "media", "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
IANA可以注册七个字段名。使用SDP规范BNF中的术语，它们是“媒体”、“原型”、“fmt”、“att字段”、“bwtype”、“nettype”和“addrtype”。
"media" (eg, audio, video, application, data).
“媒体”（如音频、视频、应用程序、数据）。
Packetized media types, such as those used by RTP, share the namespace used by media types registry [RFC 2048] (i.e. "MIME types"). The list of valid media names is the set of top-level MIME content types. The set of media is intended to be small and not to be extended except under rare circumstances. (The MIME subtype corresponds to the "fmt" parameter below).
打包的媒体类型（如RTP使用的媒体类型）共享媒体类型注册表[RFC 2048]（即“MIME类型”）使用的命名空间。有效媒体名称列表是顶级MIME内容类型的集合。介质集应较小，除非在极少数情况下，否则不得扩展。（MIME子类型对应于下面的“fmt”参数）。
"proto"
“原型”
In general this should be an IETF standards-track transport protocol identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).
通常，这应该是IETF标准轨道传输协议标识符，如RTP/AVP（RFC1890配置文件下的RFC1889）。
However, people will want to invent their own proprietary transport protocols. Some of these should be registered as a "fmt" using "udp" as the protocol and some of which probably can't be.
然而，人们希望发明自己的专有传输协议。其中一些应该使用“udp”作为协议注册为“fmt”，而其中一些可能无法注册。
Where the protocol and the application are intimately linked, such as with the LBL whiteboard wb which used a proprietary and special purpose protocol over UDP, the protocol name should be "udp" and the format name that should be registered is "wb". The rules for formats (see below) apply to such registrations.
当协议和应用程序紧密相连时，如LBL白板wb在UDP上使用专有和专用协议，协议名称应为“UDP”，应注册的格式名称为“wb”。格式规则（见下文）适用于此类注册。
Where the proprietary transport protocol really carries many different data formats, it is possible to register a new protocol name with IANA. In such a case, an RFC MUST be produced describing the protocol and referenced in the registration. Such an RFC MAY be informational, although it is preferable if it is standards-track.
如果专有传输协议确实包含许多不同的数据格式，则可以向IANA注册新的协议名称。在这种情况下，必须生成RFC来描述协议，并在注册中引用。这样的RFC可能是信息性的，但如果是标准跟踪则更好。
"fmt"
“fmt”
The format namespace is dependent on the context of the "proto" field, so a format cannot be registered without specifying one or more transport protocols that it applies to.
格式名称空间依赖于“proto”字段的上下文，因此如果不指定一个或多个应用于该格式的传输协议，则无法注册该格式。
Formats cover all the possible encodings that might want to be transported in a multimedia session.
格式包括可能希望在多媒体会话中传输的所有可能的编码。
For RTP formats that have been assigned static payload types, the payload type number is used. For RTP formats using a dynamic payload type number, the dynamic payload type number is given as the format and an additional "rtpmap" attribute specifies the format and parameters.
对于已分配静态有效负载类型的RTP格式，使用有效负载类型编号。对于使用动态有效负载类型编号的RTP格式，动态有效负载类型编号作为格式提供，并且附加的“rtpmap”属性指定格式和参数。
For non-RTP formats, any unregistered format name may be registered through the MIME-type registration process [RFC 2048]. The type given here is the MIME subtype only (the top-level MIME content type is specified by the media parameter). The MIME type registration SHOULD reference a standards-track RFC which describes the transport protocol for this media type. If there is an existing MIME type for this format, the MIME registration should be augmented to reference the transport specification for this media type. If there is not an existing MIME type for this format, and there exists no appropriate file format, this should be noted in the encoding considerations as "no appropriate file format".
对于非RTP格式，任何未注册的格式名称都可以通过MIME类型注册过程[RFC 2048]进行注册。此处给出的类型仅为MIME子类型（顶级MIME内容类型由媒体参数指定）。MIME类型注册应引用描述此媒体类型的传输协议的标准跟踪RFC。如果存在此格式的现有MIME类型，则应扩充MIME注册以引用此媒体类型的传输规范。如果此格式不存在MIME类型，并且不存在适当的文件格式，则应在编码注意事项中注明“无适当的文件格式”。
"att-field" (Attribute names)
“att字段”（属性名称）
Attribute field names MAY be registered with IANA, although this is not compulsory, and unknown attributes are simply ignored.
属性字段名可以向IANA注册，尽管这不是强制性的，未知属性将被忽略。
When an attribute is registered, it must be accompanied by a brief specification stating the following:
注册属性时，必须随附简要说明，说明以下内容：
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 此属性的适当属性值的规范。
IANA will not sanity check such attribute registrations except to ensure that they do not clash with existing registrations.
IANA不会检查此类属性注册，除非确保它们不会与现有注册冲突。
Although the above is the minimum that IANA will accept, if the attribute is expected to see widespread use and interoperability is an issue, authors are encouraged to produce 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属性的精神，最值得注意的是，该属性是平台独立的，因为它不对操作系统进行隐含假设，也不会以可能抑制互操作性的方式命名特定软件。
"bwtype" (bandwidth specifiers)
“bwtype”（带宽说明符）
A proliferation of bandwidth specifiers is strongly discouraged.
强烈反对带宽说明符的激增。
New bandwidth specifiers may 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注册新的带宽说明符。提交必须引用一个标准跟踪RFC，精确地指定带宽说明符的语义，并指明何时应该使用它，以及现有注册带宽说明符不够用的原因。
"nettype" (Network Type)
“nettype”（网络类型）
New network types may be registered with IANA if SDP needs to be used in the context of non-internet environments. Whilst 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 telephony call into the 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 type. A new network type registration MUST reference an RFC which gives details of the network type and address type and specifies how and when they would be used. Such an RFC MAY be Informational.
如果SDP需要在非互联网环境中使用，则可以向IANA注册新的网络类型。虽然这些通常不属于IANA的范围，但在某些情况下，互联网应用程序可能需要与非互联网应用程序进行互操作，例如将互联网电话呼叫接入PSTN。网络类型的数量应该很少，并且应该很少扩展。如果未注册至少一个要与该网络类型一起使用的地址类型，则无法注册新网络类型。新的网络类型注册必须引用RFC，RFC提供网络类型和地址类型的详细信息，并指定如何以及何时使用它们。这样的RFC可能是信息性的。
"addrtype" (Address Type)
“addrtype”（地址类型）
New address types 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. Such an RFC MAY be Informational. Address types are not expected to be registered frequently.
新的地址类型可以向IANA注册。地址类型仅在网络类型的上下文中有意义，并且地址类型的任何注册必须指定已注册的网络类型，或者与网络类型注册一起提交。新地址类型注册必须引用RFC，该RFC提供了地址类型语法的详细信息。这样的RFC可能是信息性的。不希望经常注册地址类型。
Registration Procedure
登记程序
To register a name the above guidelines should be followed regarding the required level of documentation that is required. The registration itself should be sent to IANA. Attribute registrations should include the information given above. Other registrations should include the following additional information:
要注册一个名称，应遵循上述关于所需文件级别的指南。注册本身应发送给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 (eg RFC number) of the registered name.
o 对注册名称规范（如RFC编号）的参考。
IANA may refer any registration to the IESG or to any appropriate IETF working group for review, and may request revisions to be made before a registration will be made.
IANA可将任何注册提交给IESG或任何适当的IETF工作组审查，并可要求在注册前进行修订。
Appendix C: Authors' Addresses
附录C：作者地址
Mark Handley Information Sciences Institute c/o MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 United States electronic mail: mjh@isi.edu
马克·汉德利信息科学研究所c/o麻省理工学院计算机科学实验室545技术广场剑桥，马萨诸塞州02139美国电子邮件：mjh@isi.edu
Van Jacobson MS 46a-1121 Lawrence Berkeley Laboratory Berkeley, CA 94720 United States electronic mail: van@ee.lbl.gov
Van Jacobson MS 46a-1121美国加利福尼亚州伯克利劳伦斯伯克利实验室94720电子邮件：van@ee.lbl.gov
Acknowledgments
致谢
Many people in the IETF 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, Rob Lanphier and Steve Hanna.
IETF MMUSIC工作组中的许多人对本文件提出了意见和建议。特别是，我们要感谢Eve Schooler、Steve Casner、Bill Fenner、Allison Mankin、Ross Finlayson、Peter Parnes、Joerg Ott、Carsten Bormann、Rob Lanphier和Steve Hanna。
References
工具书类
[1] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992.
[1] Mills，D.，“网络时间协议（第3版）规范和实施”，RFC13051992年3月。
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996
[3] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月
[4] Handley, M., "SAP - Session Announcement Protocol", Work in Progress.
[4] 汉德利，M.，“SAP-会话公告协议”，正在进行中。
[5] V. Jacobson, S. McCanne, "vat - X11-based audio teleconferencing tool" vat manual page, Lawrence Berkeley Laboratory, 1994.
[5] V.Jacobson，S.McCanne，“基于vat-X11的音频电话会议工具”，vat手册页，劳伦斯伯克利实验室，1994年。
[6] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[6] Unicode联盟，“Unicode标准——2.0版”，Addison Wesley，1996年。
[7] ISO/IEC 10646-1:1993. International Standard -- Information technol- ogy -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Five amendments and a techn- ical corrigendum have been published up to now. UTF-8 is described in Annex R, published as Amendment 2.
[7] ISO/IEC 10646-1:1993。国际标准信息技术通用多八位编码字符集（UCS）第1部分：体系结构和基本多语言平面。到目前为止，已经发布了五个修正案和一个技术勘误表。UTF-8如附录R所述，作为修改件2发布。
[8] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641, July 1994.
[8] Goldsmith，D.和M.Davis，“将Unicode与MIME结合使用”，RFC 16411994年7月。
[9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[9] “UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Receiving Internet-based H.323 Conferences", ITU, Geneva.
[10] ITU-T建议H.332（1998）：“用于接收基于互联网的H.323会议的多媒体终端”，ITU，日内瓦。
[11] Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation Protocol (SIP)", Work in Progress.
[11] Handley，M.，Schooler，E.，和H.Schulzrinne，“会话启动协议（SIP）”，正在进行中。
[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[12] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。