Network Working Group F. Andreasen
Request for Comments: 3407 Cisco Systems
Category: Standards Track October 2002
Network Working Group F. Andreasen
Request for Comments: 3407 Cisco Systems
Category: Standards Track October 2002
Session Description Protocol (SDP) Simple Capability Declaration
会话描述协议（SDP）简单功能声明
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng.
本文档定义了一组会话描述协议（SDP）属性，使SDP能够提供最小的向后兼容的能力声明机制。此类能力声明可作为后续会话协商的输入，该协商在本文件范围外进行。这为下一代SDP（也称为SDPng）正在解决的一般能力协商问题提供了一个简单而有限的解决方案。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[2]中所述进行解释。
The Session Description Protocol (SDP) [3] describes multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability negotiation. However, as the need for this has become increasingly important, work has begun on a "next generation SDP" (SDPng) [4,5] that supports both session description and capability negotiation. SDPng is not anticipated to be backwards compatible with SDP and work on SDPng is currently in the early stages. However, several other protocols, e.g. SIP [6] and Media Gateway Control Protocol (MGCP) [7], use SDP and are likely to
会话描述协议（SDP）[3]描述多媒体会话，用于会话公告、会话邀请和其他形式的多媒体会话启动。SDP无意提供能力协商。然而，随着这一需求变得越来越重要，支持会话描述和能力协商的“下一代SDP”（SDPng）[4,5]的工作已经开始。SDPng预计不会向后兼容SDP，SDPng的工作目前处于早期阶段。然而，一些其他协议，例如SIP[6]和媒体网关控制协议（MGCP）[7]使用SDP，并且可能
continue doing so for the foreseeable future. Nevertheless, in many cases these signaling protocols have an urgent need for some limited form of capability negotiation.
在可预见的未来继续这样做。然而，在许多情况下，这些信令协议迫切需要某种有限形式的能力协商。
For example, an endpoint may support G.711 audio (over RTP) as well as T.38 fax relay (over UDP or TCP). Unless the endpoint is willing to support two media streams at the same time, this cannot currently be expressed in SDP. Another example involves support for multiple codecs. An endpoint indicates this by including all the codecs in the "m=" line in the session description. However, the endpoint thereby also commits to simultaneous support for each of these codecs. In practice, Digital Signal Processor (DSP) memory and processing power limitations may not make this feasible.
例如，端点可以支持G.711音频（通过RTP）以及T.38传真中继（通过UDP或TCP）。除非端点愿意同时支持两个媒体流，否则这目前不能用SDP表示。另一个例子涉及对多个编解码器的支持。端点通过在会话描述的“m=”行中包含所有编解码器来表明这一点。然而，端点因此也承诺同时支持这些编解码器中的每一个。实际上，数字信号处理器（DSP）内存和处理能力的限制可能无法实现这一点。
As noted in [4], the problem with SDP is that media descriptions are used to describe session parameters as well as capabilities without a clear distinction between the two.
如[4]中所述，SDP的问题在于，媒体描述用于描述会话参数以及功能，而没有明确区分两者。
In this document, we define a minimal and backwards compatible capability declaration feature in SDP by defining a set of new SDP attributes. Together, these attributes define a capability set, which consists of a capability set sequence number followed by one or more capability descriptions. Each capability description in the set contains information about supported media formats, but the endpoint is not committing to use any of these. In order to actually use a declared capability, session negotiation will have to be done by means outside the scope of this document, e.g., using the offer/answer model [8].
在本文档中，我们通过定义一组新的SDP属性，在SDP中定义了一个最小且向后兼容的功能声明特性。这些属性共同定义了一个能力集，该能力集由一个能力集序列号和一个或多个能力描述组成。集合中的每个功能描述都包含有关支持的媒体格式的信息，但端点未承诺使用这些格式中的任何一种。为了实际使用声明的能力，会话协商必须通过本文件范围之外的方式进行，例如，使用要约/应答模型[8]。
It should be noted that the mechanism is not intended to solve the general capability negotiation problem targeted by SDPng. It is merely intended as a simple and limited solution to the most urgent problems facing current users of SDP.
需要注意的是，该机制并非旨在解决SDPng针对的一般能力协商问题。它只是针对SDP当前用户所面临的最紧迫问题的一个简单而有限的解决方案。
The SDP Simple Capability Declaration (simcap) is defined by a set of SDP attributes. Together, these attributes form a capability set which describes the complete media capabilities of the endpoint. Any previous capability sets issued by the endpoint for the session in question no longer apply. The capability set consists of a sequence number and one or more capability descriptions. Each such capability description describes the media type and media formats supported and may include one or more capability parameters to further define the capability. A session description MUST NOT contain more than one capability set, however the capability set can describe capabilities at both the session and media level. Capability descriptions provided at the session level apply to all media streams of the media
SDP简单能力声明（simcap）由一组SDP属性定义。这些属性共同构成一个功能集，描述端点的完整媒体功能。终结点为相关会话发布的任何以前的功能集都不再适用。能力集由序列号和一个或多个能力描述组成。每个这样的能力描述描述描述所支持的媒体类型和媒体格式，并且可以包括一个或多个能力参数以进一步定义该能力。会话描述不能包含多个功能集，但是功能集可以描述会话和媒体级别的功能。在会话级别提供的功能描述适用于媒体的所有媒体流
type indicated, whereas capability descriptions provided at the media level apply to that particular media stream only. We refer to these respectively as session capabilities and media stream capabilities. A media stream capability may or may not be of the same media type as the media stream to which it applies.
指示的类型，而在媒体级别提供的功能描述仅适用于该特定媒体流。我们将其分别称为会话功能和媒体流功能。媒体流功能可能与它所应用的媒体流的媒体类型相同，也可能不同。
The capability set MUST begin with a single sequence number followed by one or more capability descriptions listing all media formats the endpoint is currently able and willing to support. More specifically, if a media format is included in a media ("m=") line, then by definition the media format MUST be included in either a session capability or a media stream capability for that media line. The endpoint MAY include additional media formats in a capability if it is capable of supporting those media formats in a session with its peer. An endpoint MUST NOT include capabilities it knows it cannot use in a particular session. An endpoint receiving a capability set from another endpoint MAY use any of the media formats included in that capability set in a later attempt to negotiate media streams with the other endpoint, e.g., using the offer/answer model [8]. If a new capability set is received from the other endpoint, the old capability set MUST NOT be used any longer. Session capabilities can be used for any media streams of the indicated media type, whereas media stream capabilities can only be used for their associated media line. However, an endpoint receiving a capability set with a given media format MUST NOT assume that a subsequent attempt to negotiate a media stream using just this media format will succeed.
功能集必须以单个序列号开头，后跟一个或多个功能描述，列出端点当前能够并愿意支持的所有媒体格式。更具体地说，如果媒体（“m=”）行中包含媒体格式，则根据定义，该媒体格式必须包含在该媒体行的会话功能或媒体流功能中。如果端点能够在与其对等方的会话中支持这些媒体格式，则端点可以在功能中包括附加媒体格式。端点不得包含其知道无法在特定会话中使用的功能。从另一个端点接收能力集的端点可以在稍后尝试与另一个端点协商媒体流时使用该能力集中包括的任何媒体格式，例如，使用提供/应答模型[8]。如果从另一个端点接收到新的功能集，则不能再使用旧的功能集。会话功能可用于指示媒体类型的任何媒体流，而媒体流功能只能用于其关联的媒体线路。但是，接收具有给定媒体格式的功能集的端点不得假定仅使用该媒体格式协商媒体流的后续尝试将成功。
The individual capability descriptions in a capability set can be provided contiguously or they can be scattered throughout the session description. The first capability description MUST, however, follow immediately after the sequence number.
功能集中的单个功能描述可以连续提供，也可以分散在整个会话描述中。但是，第一个功能描述必须紧跟在序列号之后。
The sequence number is on the form:
序列号在以下表格中：
a=sqn: <sqn-num>
a=sqn: <sqn-num>
where <sqn-num> is an integer between 0 and 255 (both included). The initial sequence number MUST be 0 (zero) and it MUST be incremented by 1 modulo 256 with each new capability set issued by the endpoint. Receivers may not necessarily see all capability sets issued and hence MUST NOT reject a capability set due to gaps in sequence numbers. The sequence number MUST either be provided as a session-level or media-level attribute, however there MUST NOT be more than one occurrence of the sequence number attribute in the session description (since there cannot be more than one capability set).
其中<sqn num>是一个介于0和255之间的整数（均包括在内）。初始序列号必须为0（零），并且必须随端点发出的每个新功能集以1模256递增。接收者不一定能看到发布的所有能力集，因此不得因序列号中的间隙而拒绝能力集。序列号必须作为会话级别或媒体级别属性提供，但是在会话描述中序列号属性不得出现一次以上（因为不能有多个功能集）。
Each capability description in the capability set is on the form:
功能集中的每个功能描述都在以下表格中：
a=cdsc: <cap-num> <media> <transport> <fmt list>
a=cdsc: <cap-num> <media> <transport> <fmt list>
where <cap-num> is an integer between 1 and 255 (both included) used to number the capabilities, and <media>, <transport>, and <fmt list> are defined as in the SDP "m=" line. The capability description refers to a send and receive capability by default. When generating a capability set, the capability number MUST start with 1 in the first capability description, and be incremented by the number of media formats in the <fmt list> for each subsequent capability description. The media formats in the <fmt list> are numbered from left to right. Receivers of a capability set MUST NOT, however, reject capability descriptions due to gaps in the capability numbers. The capability number provides a convenient handle within the context of the capability set (as referenced by the sequence number) which may be used to reference a particular capability by means outside of this specification.
其中，<cap num>是一个介于1和255之间的整数（均包括在内），用于对功能进行编号，<media>、<transport>和<fmt list>定义为SDP“m=”行。默认情况下，功能描述是指发送和接收功能。生成功能集时，功能编号必须在第一个功能描述中以1开头，并在后续的每个功能描述中以<fmt list>中的媒体格式编号递增。<fmt list>中的媒体格式从左到右编号。但是，能力集的接收者不得因能力数量的差距而拒绝能力描述。能力编号在能力集（由序列号引用）的上下文中提供了一个方便的句柄，可用于通过本规范之外的方式引用特定能力。
A capability description can include one or more capability parameter lines on the form:
能力描述可以包括表单上的一个或多个能力参数行：
a=cpar: <cap-par>
a=cparmin: <cap-par>
a=cparmax: <cap-par>
a=cpar: <cap-par>
a=cparmin: <cap-par>
a=cparmax: <cap-par>
where <cap-par> is either bandwidth information ("b=") or an attribute ("a=") in its full '<type>=<value>' form (see [3]). A capability parameter line provides additional parameters for the preceding "cdsc" attribute line. Capability parameter lines for a capability description SHOULD immediately follow the "cdsc" line they refer to. Nevertheless, the capability description includes all capability parameter lines until the next capability description ("cdsc") or media ("m=") line in the session description.
其中<cap par>是带宽信息（“b=”）或完整形式的属性（“a=”）<type>=<value>（参见[3]）。能力参数行为前面的“cdsc”属性行提供附加参数。能力描述的能力参数行应紧跟其所指的“cdsc”行。然而，功能描述包括所有功能参数行，直到会话描述中的下一个功能描述（“cdsc”）或媒体（“m=”）行。
The "cpar" attribute should normally be used when capability parameter values are to be specified. When provided, it means that the endpoint is declaring that it supports the media formats in the preceding "cdsc" line in accordance with the <cap-par> value specified. This can, for example, be used to specify "fmtp" parameters. If a session negotiation is attempted without considering the <cap-par> value, it may fail due to lack of endpoint support. A capability description may contain zero, one, or more "cpar" attribute lines describing either the same or different parameters. Describing the same parameter more than once can be used to specify alternatives.
在指定能力参数值时，通常应使用“cpar”属性。如果提供，则表示端点根据指定的<cap par>值声明它支持前面“cdsc”行中的媒体格式。例如，这可用于指定“fmtp”参数。如果在未考虑<cap par>值的情况下尝试会话协商，可能会由于缺少端点支持而失败。能力描述可以包含零行、一行或多行描述相同或不同参数的“cpar”属性行。多次描述同一参数可用于指定备选方案。
Where a minimum numerical value is to be specified, the "cparmin" attribute should be used. There may be zero, one, or more "cparmin" attribute lines in a capability description, however a given parameter MUST NOT be described by a "cparmin" attribute more than once.
如果要指定最小数值，则应使用“cparmin”属性。功能描述中可能有零行、一行或多行“cparmin”属性，但给定参数不能由“cparmin”属性描述多次。
Where a maximum numerical value is to be specified, the "cparmax" attribute should be used. There may be zero, one, or more "cparmax" attribute lines in a capability description, however a given parameter MUST NOT be described by a "cparmax" attribute more than once.
如果要指定最大数值，则应使用“cparmax”属性。能力描述中可能有零行、一行或多行“cparmax”属性，但给定参数不能由“cparmax”属性描述多次。
Ranges of numerical values can be expressed by using a "cparmin" and a "cparmax" attribute for a given parameter. It follows from the previous rules, that only a single range can be specified for a given parameter.
数值范围可以通过使用给定参数的“cparmin”和“cparmax”属性来表示。根据前面的规则，只能为给定参数指定单个范围。
Capability descriptions may be provided at both the session-level and media-level. A capability description provided at the session-level applies to all the media streams of the indicated media type in the session description. A capability description provided at the media-level only applies to that particular media stream (regardless of media type). If a capability description with media type X is provided at the session-level, and there are no media streams of type X in the session description, then it is undefined which of the media streams the capability description applies to (except if there is only one media stream). It is therefore RECOMMENDED, that such capabilities are provided at the media-level instead.
可以在会话级别和媒体级别提供功能描述。在会话级别提供的能力描述适用于会话描述中指示的媒体类型的所有媒体流。在媒体级别提供的功能描述仅适用于该特定媒体流（无论媒体类型如何）。如果在会话级别提供了媒体类型为X的功能描述，并且会话描述中没有类型为X的媒体流，则未定义该功能描述适用于哪些媒体流（只有一个媒体流的情况除外）。因此，建议改为在媒体级别提供此类功能。
Below we show an example session description using the above simple capability declaration mechanism:
下面我们展示了使用上述简单功能声明机制的示例会话描述：
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38
The sender of this session description is currently prepared to send and receive G.729 audio as well as telephone-events 0-15 and 32-35. The sender is furthermore capable of supporting:
此会话描述的发送方目前准备发送和接收G.729音频以及电话事件0-15和32-35。发送方还能够支持：
* PCMU encoding for the audio media stream, * telephone events 0-16 and 32-35, * T.38 fax relay using udp or tcp (see [9]).
* 音频媒体流的PCMU编码，*电话事件0-16和32-35，*使用udp或tcp的T.38传真中继（见[9]）。
Note, that the first capability number specified is 1, whereas the next is 4 since three media formats were included in the first capability description. Also note that the rtpmap for payload type 96 was not included in the capability description, as it was already specified for the media ("m=") line. Conversely, it would of course not have been valid to provide the rtpmap in the capability description and then omit the "a=rtpmap" line.
请注意，指定的第一个功能编号是1，而下一个是4，因为第一个功能描述中包括三种媒体格式。还请注意，有效负载类型96的rtpmap未包含在功能描述中，因为它已为介质（“m=”）行指定。相反，在功能描述中提供rtpmap，然后省略“a=rtpmap”行当然是无效的。
Below, we show another example of the simple capability declaration mechanism, this time with multiple media streams:
下面，我们展示了简单功能声明机制的另一个示例，这次是多个媒体流：
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
m=video 3458 RTP/AVP 31
a=cdsc: 3 video RTP/AVP 31 34
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
m=video 3458 RTP/AVP 31
a=cdsc: 3 video RTP/AVP 31 34
The sender of this session description is currently prepared to send and receive G.729 audio and H.261 video. The sender is furthermore capable of supporting:
此会话描述的发送方目前准备发送和接收G.729音频和H.261视频。发送方还能够支持：
* PCMU encoding for the audio media stream, * H.263 for the video media stream.
* 音频媒体流采用PCMU编码，视频媒体流采用*H.263编码。
Note that the first capability number specified is 1, whereas the next is 3, since two media formats were included in the first capability description. Also note that the sequence number applies to the entire capability set, i.e. both audio and video, and hence is only supplied once. Finally, note that the media formats 18 and 31 are listed in both the media lines and the capability set as required. The above session description could have equally been supplied as follows:
请注意，指定的第一个功能编号是1，而下一个是3，因为第一个功能描述中包含两种媒体格式。还要注意，序列号适用于整个功能集，即音频和视频，因此仅提供一次。最后，请注意，媒体格式18和31根据需要列在媒体行和能力集中。上述会话描述同样可以如下提供：
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 video RTP/AVP 31 34
m=audio 3456 RTP/AVP 18
m=video 3458 RTP/AVP 31
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 video RTP/AVP 31 34
m=audio 3456 RTP/AVP 18
m=video 3458 RTP/AVP 31
i.e., with the capability set provided at the session-level.
i、 例如，使用会话级别提供的功能集。
Capability negotiation of security-sensitive parameters is a delicate process, and should not be done without careful evaluation of the design, including the possible susceptibility to downgrade attacks. Use of capability re-negotiation may make the session susceptible to denial of service, without design care as to authentication.
安全敏感参数的能力协商是一个微妙的过程，在没有仔细评估设计（包括对降级攻击的可能敏感性）的情况下，不应进行协商。使用功能重新协商可能会使会话易受拒绝服务的影响，而不考虑身份验证的设计。
This document defines the following new SDP parameters of type "att-field" (attribute names):
本文件定义了以下类型为“att field”（属性名称）的新SDP参数：
Attribute name: sqn Long form name: Sequence number. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Capability set numbering. Appropriate values: See Section 3.
属性名称：sqn长格式名称：序列号。属性类型：会话级别和媒体级别。以字符集为准：编号。用途：功能集编号。适当值：见第3节。
Attribute name: cdsc Long form name: Capability description. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Describe capabilities in a capability set. Appropriate values: See Section 3.
属性名称：cdsc长格式名称：功能描述。属性类型：会话级别和媒体级别。受限于字符集：否。目的：描述功能集中的功能。适当值：见第3节。
Attribute name: cpar Long form name: Capability parameter line. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Provide capability description parameters. Appropriate values: See Section 3.
属性名称：cpar长格式名称：能力参数行。属性类型：会话级别和媒体级别。以字符集为准：编号。目的：提供能力描述参数。适当值：见第3节。
Attribute name: cparmin Long form name: Minimum capability parameter line. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Provide minimum capability description parameters. Appropriate values: See Section 3.
属性名称：cparmin长格式名称：最小能力参数行。属性类型：会话级别和媒体级别。以字符集为准：编号。目的：提供最小能力描述参数。适当值：见第3节。
Attribute name: cparmax Long form name: Maximum capability parameter line. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Provide maximum capability description parameters. Appropriate values: See Section 3.
属性名称：cparmax长格式名称：最大能力参数行。属性类型：会话级别和媒体级别。根据字符集：编号。目的：提供最大能力描述参数。适当值：见第3节。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Handley, M. and V. Jacobson, "SDP: session description protocol", Request for Comments 2327, April 1998.
[3] Handley，M.和V.Jacobson，“SDP：会话描述协议”，征求意见2327，1998年4月。
[4] Kutscher, Ott, Bormann and Curcio, "Requirements for Session Description and Capability Negotiation", Work in Progress.
[4] Kutscher、Ott、Bormann和Curcio，“会话描述和能力协商要求”，正在进行中。
[5] Kutscher, Ott and Borman, "Session Description and Capability Negotiation", Work in Progress.
[5] Kutscher、Ott和Borman，“会话描述和能力协商”，正在进行中。
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: session initiation protocol", RFC 2543, March 1999.
[6] Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[7] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
[7] Arango，M.，Dugan，A.，Elliott，I.，Huitema，C.和S.Pickett，“媒体网关控制协议（MGCP）1.0版”，RFC 27052999年10月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", Work in Progress.
[8] Rosenberg，J.和H.Schulzrinne，“SDP提供/回答模型”，正在进行中。
[9] ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment Procedures".
[9] ITU-T建议T.38附录D，“SIP/SDP呼叫建立程序”。
This work draws upon the ongoing work on SDPng in the IETF MMUSIC Working Group; in particular [4]. Furthermore this work was inspired by the CableLabs PacketCable project. The author would like to recognize and thank Joerg Ott and Jonathan Rosenberg who provided many detailed comments and suggestions to improve this specification. Colin Perkins, Orit Levin and Tom Taylor provided valuable feedback as well.
这项工作借鉴了IETF MMUSIC工作组正在进行的SDPng工作；特别是[4]。此外，这项工作的灵感来自CableLabs PacketCable项目。作者要感谢Joerg Ott和Jonathan Rosenberg，他们为改进本规范提供了许多详细的意见和建议。科林·帕金斯、奥利特·莱文和汤姆·泰勒也提供了宝贵的反馈。
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th floor Edison, NJ EMail: fandreas@cisco.com
Flemming Andreasen Cisco Systems 499 Thornall Street，新泽西州爱迪生市8楼电子邮件：fandreas@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。