Network Working Group G. Camarillo, Ed.
Request for Comments: 3312 Ericsson
Category: Standards Track W. Marshall, Ed.
AT&T
J. Rosenberg
dynamicsoft
October 2002
Network Working Group G. Camarillo, Ed.
Request for Comments: 3312 Ericsson
Category: Standards Track W. Marshall, Ed.
AT&T
J. Rosenberg
dynamicsoft
October 2002
Integration of Resource Management and Session Initiation Protocol (SIP)
集成资源管理和会话启动协议（SIP）
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 generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.
本文档为前提条件定义了一个通用框架，可通过IANA注册进行扩展。本文档还讨论了如何将网络服务质量作为建立会话启动协议（SIP）启动的会话的先决条件。这些先决条件要求参与者在继续会话之前保留网络资源。我们没有定义新的服务质量保留机制；这些先决条件只要求参与者在开始会话之前使用现有的资源保留机制。
Table of Contents
目录
1 Introduction ................................................... 2
2 Terminology .................................................... 3
3 Overview ....................................................... 3
4 SDP parameters ................................................. 4
5 Usage of preconditions with offer/answer ....................... 7
5.1 Generating an offer .......................................... 8
5.1.1 SDP encoding ............................................... 9
5.2 Generating an Answer ......................................... 10
6 Suspending and Resuming Session Establishment .................. 11
7 Status Confirmation ............................................ 12
8 Refusing an offer .............................................. 13
8.1 Rejecting a Media Stream ..................................... 14
9 Unknown Precondition Type ...................................... 15
10 Multiple Preconditions per Media Stream ....................... 15
11 Option Tag for Preconditions .................................. 16
12 Indicating Capabilities ....................................... 16
13 Examples ...................................................... 16
13.1 End-to-end Status Type ...................................... 17
13.2 Segmented Status Type ....................................... 21
13.3 Offer in a SIP response ..................................... 23
14 Security Considerations ....................................... 26
15 IANA Considerations ........................................... 26
16 Notice Regarding Intellectual Property Rights ................. 27
17 References .................................................... 27
18 Contributors .................................................. 28
19 Acknowledgments ............................................... 28
20 Authors' Addresses ............................................ 29
21 Full Copyright Statement ...................................... 30
1 Introduction ................................................... 2
2 Terminology .................................................... 3
3 Overview ....................................................... 3
4 SDP parameters ................................................. 4
5 Usage of preconditions with offer/answer ....................... 7
5.1 Generating an offer .......................................... 8
5.1.1 SDP encoding ............................................... 9
5.2 Generating an Answer ......................................... 10
6 Suspending and Resuming Session Establishment .................. 11
7 Status Confirmation ............................................ 12
8 Refusing an offer .............................................. 13
8.1 Rejecting a Media Stream ..................................... 14
9 Unknown Precondition Type ...................................... 15
10 Multiple Preconditions per Media Stream ....................... 15
11 Option Tag for Preconditions .................................. 16
12 Indicating Capabilities ....................................... 16
13 Examples ...................................................... 16
13.1 End-to-end Status Type ...................................... 17
13.2 Segmented Status Type ....................................... 21
13.3 Offer in a SIP response ..................................... 23
14 Security Considerations ....................................... 26
15 IANA Considerations ........................................... 26
16 Notice Regarding Intellectual Property Rights ................. 27
17 References .................................................... 27
18 Contributors .................................................. 28
19 Acknowledgments ............................................... 28
20 Authors' Addresses ............................................ 29
21 Full Copyright Statement ...................................... 30
1 Introduction
1导言
Some architectures require that at session establishment time, once the callee has been alerted, the chances of a session establishment failure are minimum. One source of failure is the inability to reserve network resources for a session. In order to minimize "ghost rings", it is necessary to reserve network resources for the session before the callee is alerted. However, the reservation of network resources frequently requires learning the IP address, port, and session parameters from the callee. This information is obtained as a result of the initial offer/answer exchange carried in SIP. This exchange normally causes the "phone to ring", thus introducing a chicken-and-egg problem: resources cannot be reserved without performing an initial offer/answer exchange, and the initial offer/answer exchange can't be done without performing resource reservation.
一些体系结构要求在会话建立时，一旦被调用方收到警报，会话建立失败的可能性最小。失败的一个原因是无法为会话保留网络资源。为了最小化“重影环”，有必要在被呼叫方收到警报之前为会话保留网络资源。然而，保留网络资源通常需要从被叫方了解IP地址、端口和会话参数。该信息是通过SIP中进行的初始报价/应答交换获得的。这种交换通常会导致“电话铃响”，从而带来鸡和蛋的问题：如果不执行初始报价/应答交换，就不能保留资源，如果不执行资源保留，就不能进行初始报价/应答交换。
The solution is to introduce the concept of a precondition. A precondition is a set of constraints about the session which are introduced in the offer. The recipient of the offer generates an answer, but does not alert the user or otherwise proceed with session establishment. That only occurs when the preconditions are met. This can be known through a local event (such as a confirmation of a resource reservation), or through a new offer sent by the caller.
解决办法是引入先决条件的概念。先决条件是在报价中引入的有关会话的一组约束。要约的接收者会生成一个答案，但不会提醒用户或以其他方式继续建立会话。这只有在满足前提条件时才会发生。这可以通过本地事件（如资源保留的确认）或调用方发送的新要约来了解。
This document deals with sessions that use SIP [1] as a signalling protocol and SDP [2] to describe the parameters of the session.
本文档介绍使用SIP[1]作为信令协议，使用SDP[2]描述会话参数的会话。
We have chosen to include the quality of service preconditions in the SDP description rather than in the SIP header because preconditions are stream specific.
我们选择在SDP描述中包含服务质量前提条件，而不是在SIP头中，因为前提条件是特定于流的。
2 Terminology
2术语
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 BCP 14, RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。
3 Overview
3概述
In order to ensure that session establishment does not take place until certain preconditions are met, we distinguish between two different state variables that affect a particular media stream: current status and desired status. This document defines the quality of service status.
为了确保在满足某些先决条件之前不会建立会话，我们区分了影响特定媒体流的两个不同状态变量：当前状态和期望状态。本文件定义了服务质量状态。
The desired status consists of a threshold for the current status. Session establishment stops until the current status reaches or surpasses this threshold. Once this threshold is reached or surpassed, session establishment resumes.
所需状态由当前状态的阈值组成。会话建立将停止，直到当前状态达到或超过此阈值。一旦达到或超过此阈值，会话建立将恢复。
For example, the following values for current and desired status would not allow session establishment to resume:
例如，当前和所需状态的以下值将不允许恢复会话建立：
current status = resources reserved in the send direction desired status = resources reserved in both (sendrecv) directions
当前状态=在发送方向保留的资源所需状态=在两个（sendrecv）方向保留的资源
On the other hand, the values of the example below would make session establishment resume:
另一方面，以下示例的值将使会话建立恢复：
current status = resources reserved in both (sendrecv) directions desired status = resources reserved in the send direction
当前状态=在两个（sendrecv）方向保留的资源所需状态=在发送方向保留的资源
These two state variables define a certain piece of state of a media stream the same way the direction attribute or the codecs in use define other pieces of state. Consequently, we treat these two new variables in the same way as other SDP media attributes are treated in the offer/answer model used by SIP [4]: they are exchanged between two user agents using an offer and an answer in order to have a shared view of the status of the session.
这两个状态变量定义媒体流的某个状态，定义方式与使用的方向属性或编解码器定义其他状态相同。因此，我们对待这两个新变量的方式与SIP使用的提供/应答模型中对待其他SDP媒体属性的方式相同[4]：它们在两个用户代理之间使用提供和应答进行交换，以便共享会话状态视图。
Figure 1 shows a typical message exchange between two SIP user agents using preconditions. A includes quality of service preconditions in the SDP of the initial INVITE. A does not want B to be alerted until there are network resources reserved in both directions (sendrecv) end-to-end. B agrees to reserve network resources for this session before alerting the callee. B will handle resource reservation in the B->A direction, but needs A to handle the A->B direction. To indicate so, B returns a 183 (Session Progress) response to A asking A to start resource reservation and to confirm to B as soon as the A->B direction is ready for the session. A and B both start resource reservation. B finishes reserving resources in the B->A direction, but does not alert the user yet, because network resources in both directions are needed. When A finishes reserving resources in the A->B direction, it sends an UPDATE [5] to B. B returns a 200 (OK) response for the UPDATE, indicating that all the preconditions for the session have been met. At this point in time, B starts alerting the user, and session establishment completes normally.
图1显示了两个SIP用户代理之间使用先决条件的典型消息交换。A在初始邀请的SDP中包括服务质量先决条件。A不希望在双向（sendrecv）端到端保留网络资源之前向B发出警报。B同意在通知被叫方之前为该会话保留网络资源。B将处理B->A方向的资源预留，但需要A处理A->B方向的资源预留。为了表明这一点，B向a返回183（会话进度）响应，要求a启动资源保留，并在a->B方向准备好会话后立即向B确认。A和B都启动资源预留。B完成了B->A方向的资源保留，但尚未提醒用户，因为两个方向都需要网络资源。当A在A->B方向上完成资源保留后，它向B发送更新[5]。B返回200（确定）的更新响应，指示会话的所有先决条件都已满足。此时，B开始提醒用户，会话建立正常完成。
4 SDP parameters
4 SDP参数
We define the following media level SDP attributes:
我们定义了以下媒体级SDP属性：
current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
SP direction-tag
confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
SP direction-tag
confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
Current status: The current status attribute carries the current status of network resources for a particular media stream.
当前状态：当前状态属性携带特定媒体流的网络资源的当前状态。
Desired status: The desired status attribute carries the preconditions for a particular media stream. When the direction-tag of the current status attribute, with a given precondition-type/status-type for a particular stream is equal to (or better than) the direction-tag of the desired status attribute with the same precondition-type/status-type, for that stream, then the preconditions are considered to be met for that stream.
所需状态：所需状态属性包含特定媒体流的先决条件。当特定流的当前状态属性（具有给定的前提条件类型/状态类型）的方向标记等于（或优于）该流的所需状态属性（具有相同的前提条件类型/状态类型）的方向标记时，则认为该流满足前提条件。
Confirmation status: The confirmation status attribute carries threshold conditions for a media stream. When the status of network resources reach these conditions, the peer user agent will send an update of the session description containing an updated current status attribute for this particular media stream.
确认状态：确认状态属性包含媒体流的阈值条件。当网络资源的状态达到这些条件时，对等用户代理将发送会话描述的更新，其中包含该特定媒体流的更新的当前状态属性。
Precondition type: This document defines quality of service preconditions. Extensions may define other types of preconditions.
前提条件类型：本文档定义了服务质量前提条件。扩展可以定义其他类型的前提条件。
Strength tag: The strength-tag indicates whether or not the callee can be alerted, in case the network fails to meet the preconditions.
强度标签：强度标签表示如果网络无法满足前提条件，是否可以向被叫方发出警报。
Status type: We define two types of status: end-to-end and segmented. The end-to-end status reflects the status of the end-to-end reservation of resources. The segmented status reflects the status of the access network reservations of both user agents. The end-to-end status corresponds to the tag "e2e", defined above and the segmented status to the tags "local" and "remote". End-to-end status is useful when end-to-end resource reservation mechanisms are available. The segmented status is useful when one or both UAs perform resource reservations on their respective access networks.
状态类型：我们定义了两种状态：端到端和分段。端到端状态反映了资源的端到端保留状态。分段状态反映了两个用户代理的接入网络预留的状态。端到端状态对应于上面定义的标签“e2e”，分段状态对应于标签“本地”和“远程”。当端到端资源保留机制可用时，端到端状态非常有用。当一个或两个ua在各自的接入网络上执行资源预留时，分段状态非常有用。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 1: Basic session establishment using preconditions
图1：使用先决条件建立基本会话
Direction tag: The direction-tag indicates the direction in which a particular attribute (current, desired or confirmation status) is applicable to.
方向标记：方向标记指示特定属性（当前、所需或确认状态）适用的方向。
The values of the tags "send", "recv", "local" and "remote" represent the point of view of the entity generating the SDP description. In an offer, "send" is the direction offerer->answerer and "local" is the offerer's access network. In an answer, "send" is the direction answerer->offerer and "local" is the answerer's access network.
标记“send”、“recv”、“local”和“remote”的值表示生成SDP描述的实体的视角。在报价中，“发送”是报价人->应答人的方向，“本地”是报价人的接入网络。在回答中，“发送”是应答者->报价者的方向，“本地”是应答者的接入网络。
The following example shows these new SDP attributes in two media lines of a session description:
以下示例在会话描述的两个媒体行中显示了这些新SDP属性：
m=audio 20000 RTP/AVP 0
a=curr:qos e2e send
a=des:qos optional e2e send
a=des:qos mandatory e2e recv
m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv
m=audio 20000 RTP/AVP 0
a=curr:qos e2e send
a=des:qos optional e2e send
a=des:qos mandatory e2e recv
m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv
5 Usage of preconditions with offer/answer
5先决条件与要约/答复的使用
Parameter negotiation in SIP is carried out using the offer/answer model described in [4]. The idea behind this model is to provide a shared view of the session parameters for both user agents once the answer has been received by the offerer. This section describes which values our new SDP attributes can take in an answer, depending on their value in the offer.
SIP中的参数协商使用[4]中描述的提供/应答模型进行。该模型背后的思想是，一旦报价人收到答案，就为两个用户代理提供会话参数的共享视图。本节描述了我们的新SDP属性在回答中可以接受哪些值，具体取决于它们在报价中的价值。
To achieve a shared view of the status of a media stream, we define a model that consists of three tables: both user agents implement a local status table, and each offer/answer exchange has a transaction status table associated to it. The offerer generates a transaction status table, identical to its local status table, and sends it to the answerer in the offer. The answerer uses the information of this transaction status table to update its local status table. The answerer also updates the transaction status table fields that were out of date and returns this table to the offerer in the answer. The offerer can then update its local status table with the information received in the answer. After this offer/answer exchange, the local status tables of both user agents are synchronised. They now have a common view of the status of the media stream. Sessions that involve several media streams implement these tables per media stream. Note, however, that this is a model of user agent behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines.
为了实现媒体流状态的共享视图，我们定义了一个由三个表组成的模型：两个用户代理都实现了一个本地状态表，每个提供/应答交换都有一个与之关联的事务状态表。报价人生成与本地状态表相同的交易状态表，并将其发送给报价中的应答人。应答者使用此事务状态表的信息更新其本地状态表。应答者还更新过期的交易状态表字段，并在应答中将该表返回给报价人。然后，报价人可以使用在应答中收到的信息更新其本地状态表。在本次提供/应答交换之后，两个用户代理的本地状态表将同步。他们现在对媒体流的状态有了共同的看法。涉及多个媒体流的会话在每个媒体流中实现这些表。但是，请注意，这是用户代理行为的模型，而不是软件的模型。实现可以自由地采取任何复制该模型定义的外部行为的方法。
Both user agents MUST maintain a local precondition status, which is referred to as a "local status table". Tables 1 and 2 show the format of these tables for both the end-to-end and the segmented status types. For the end-to-end status type, the table contains two rows; one for each direction (i.e., send and recv). A value of "yes" in the "Current" field indicates the successful reservation of that resource in the corresponding direction. "No" indicates that resources have not been reserved yet. The "Desired Strength" field indicates the strength of the preconditions in the corresponding direction. The table for the segmented status type contains four rows: both directions in the local access network and in the peer's access network. The meaning of the fields is the same as in the end-to-end case.
两个用户代理都必须维护本地前提条件状态，即“本地状态表”。表1和表2显示了端到端和分段状态类型的这些表的格式。对于端到端状态类型，该表包含两行；每个方向一个（即发送和接收）。“当前”字段中的值“是”表示在相应方向上成功保留了该资源。“否”表示尚未保留资源。“期望强度”字段表示相应方向上的预条件强度。分段状态类型的表包含四行：本地接入网络和对等方接入网络中的两个方向。字段的含义与端到端的情况相同。
Before generating an offer, the offerer MUST build a transaction status table with the current and the desired status, for each media stream. The different values of the strength-tag for the desired status attribute have the following semantics:
在生成报价之前，报价人必须为每个媒体流构建一个包含当前和所需状态的事务状态表。所需状态属性的强度标记的不同值具有以下语义：
o None: no resource reservation is needed.
o 无：不需要资源预留。
o Optional: the user agents SHOULD try to provide resource reservation, but the session can continue regardless of whether or not this provision is possible.
o 可选：用户代理应尝试提供资源保留，但会话可以继续，无论是否可以进行此保留。
o Mandatory: the user agents MUST provide resource reservation. Otherwise, session establishment MUST NOT continue.
o 必需：用户代理必须提供资源保留。否则，会话建立不能继续。
The offerer then decides whether it is going to use the end-to-end status type or the segmented status type. If the status type of the media line will be end-to-end, the user agent generates records with the desired status and the current status for each direction (send and recv) independently, as shown in table 1:
然后，报价人决定是使用端到端状态类型还是分段状态类型。如果媒体线路的状态类型为端到端，则用户代理会独立地为每个方向（发送和接收）生成具有所需状态和当前状态的记录，如表1所示：
Direction Current Desired Strength
____________________________________
send no mandatory
recv no mandatory
Direction Current Desired Strength
____________________________________
send no mandatory
recv no mandatory
Table 1: Table for the end-to-end status type
表1：端到端状态类型的表
If the status type of the media line will be segmented, the user agent generates records with the desired status and the current status for each direction (send and recv) and each segment (local and remote) independently, as shown in table 2:
如果将对媒体线路的状态类型进行分段，则用户代理将为每个方向（发送和接收）和每个分段（本地和远程）分别生成具有所需状态和当前状态的记录，如表2所示：
Direction Current Desired Strength
______________________________________
local send no none
local recv no none
remote send no optional
remote recv no none
Direction Current Desired Strength
______________________________________
local send no none
local recv no none
remote send no optional
remote recv no none
Table 2: Table for the segmented status type
表2：分段状态类型表
At the time of sending the offer, the offerer's local status table and the transaction status table contain the same values.
发送报价时，报价人的本地状态表和交易状态表包含相同的值。
With the transaction status table, the user agent MUST generate the current-status and the desired status lines, following the syntax of Section 4 and the rules described below in Section 5.1.1.
对于事务状态表，用户代理必须按照第4节的语法和第5.1.1节中描述的规则生成当前状态和所需的状态行。
For the end-to-end status type, the user agent MUST generate one current status line with the tag "e2e" for the media stream. If the strength-tags for both directions are equal (e.g., both "mandatory") in the transaction status table, the user agent MUST add one desired status line with the tag "sendrecv". If both tags are different, the user agent MUST include two desired status lines, one with the tag "send" and the other with the tag "recv".
对于端到端状态类型，用户代理必须为媒体流生成一个带有标记“e2e”的当前状态行。如果事务状态表中两个方向的强度标记相等（例如，两个“强制”），则用户代理必须添加一个带有标记“sendrecv”的所需状态行。如果两个标记不同，用户代理必须包括两个所需的状态行，一个带有标记“send”，另一个带有标记“recv”。
The semantics of two lines with the same strength-tag, one with a "send" tag and the other with a "recv" tag, is the same as one "sendrecv" line. However, in order to achieve a more compact encoding, we have chosen to make the latter format mandatory.
具有相同强度标记的两行（一行带有“send”标记，另一行带有“recv”标记）的语义与一行“sendrecv”的语义相同。但是，为了实现更紧凑的编码，我们选择强制使用后一种格式。
For the segmented status type, the user agent MUST generate two current status lines: one with the tag "local" and the other with the tag "remote". The user agent MUST add one or two desired status lines per segment (i.e., local and remote). If, for a particular segment (local or remote), the tags for both directions in the transaction status table are equal (e.g., both "mandatory"), the user agent MUST add one desired status line with the tag "sendrecv". If both tags are different, the user agent MUST include two desired status lines, one with the tag "send" and the other with the tag "recv".
对于分段状态类型，用户代理必须生成两个当前状态行：一个标记为“本地”，另一个标记为“远程”。用户代理必须为每个段（即本地和远程）添加一个或两个所需的状态行。如果对于特定段（本地或远程），事务状态表中两个方向的标记相等（例如，都是“必需的”），则用户代理必须使用标记“sendrecv”添加一个所需的状态行。如果两个标记不同，用户代理必须包括两个所需的状态行，一个带有标记“send”，另一个带有标记“recv”。
Note that the rules above apply to the desired strength-tag "none" as well. This way, a user agent that supports quality of service but does not intend to use them, adds desired status lines with the strength-tag "none". Since this tag can be upgraded in the answer, as described in Section 5.2, the answerer can request quality of service reservation without a need of another offer/answer exchange.
请注意，上述规则也适用于所需的强度标记“无”。这样，支持服务质量但不打算使用服务质量的用户代理将添加所需的状态行，并带有强度标记“无”。如第5.2节所述，由于该标签可在应答中升级，应答者无需另一次报价/应答交换即可请求服务质量保留。
The example below shows the SDP corresponding to tables 1 and 2.
下面的示例显示了与表1和表2对应的SDP。
m=audio 20000 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional remote send
a=des:qos none remote recv
a=des:qos none local sendrecv
m=audio 20000 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional remote send
a=des:qos none remote recv
a=des:qos none local sendrecv
When the answerer receives the offer, it recreates the transaction status table using the SDP attributes contained in the offer. The answerer updates both its local status and the transaction status table following the rules below:
当应答者收到报价时，它使用报价中包含的SDP属性重新创建事务状态表。应答者按照以下规则更新其本地状态和事务状态表：
Desired Strength: We define an absolute ordering for the strength-tags: "none", "optional" and "mandatory". "Mandatory" is the tag with the highest grade and "none" the tag with the lowest grade. An answerer MAY upgrade the desired strength in any entry of the transaction status table, but it MUST NOT downgrade it. Therefore, it is OK to upgrade a row from "none" to "optional", from "none" to "mandatory", or from "optional" to "mandatory", but not the other way around.
所需强度：我们为强度标签定义了绝对顺序：“无”、“可选”和“强制性”。“强制性”是最高等级的标签，“无”是最低等级的标签。应答者可以在事务状态表的任何条目中升级所需的强度，但不得降级。因此，可以将行从“无”升级为“可选”，从“无”升级为“强制性”，或从“可选”升级为“强制性”，但反过来不行。
Current Status: For every row, the value of the "Current" field in the transaction status table, and in the local status table of the answerer, have to be compared. Table 3 shows the four possible combinations. If both fields have the same value (two first rows of table 3), nothing needs to be updated. If the "Current" field of the transaction status table is "Yes", and the field of the local status table is "No" (third row of table 3), the latter MUST be set to "Yes". If the "Current" field of the transaction status table is "No", and the field of the local status table is "Yes" (forth row of table 3), the answerer needs to check if it has local information (e.g., a confirmation of a resource reservation has been received) about that particular current status. If it does, the "Current" field of the transaction status table is set to "Yes". If the answerer does not have local information about that current status, the "Current" field of the local status table MUST be set to "No".
当前状态：对于每一行，必须比较事务状态表和应答者本地状态表中“当前”字段的值。表3显示了四种可能的组合。如果两个字段具有相同的值（表3的前两行），则无需更新任何内容。如果交易状态表的“当前”字段为“是”，而本地状态表的字段为“否”（表3的第三行），则后者必须设置为“是”。如果事务状态表的“当前”字段为“否”，而本地状态表的字段为“是”（表3的第四行），则应答者需要检查其是否具有关于特定当前状态的本地信息（例如，已收到资源保留的确认）。如果是，则事务状态表的“当前”字段设置为“是”。如果应答者没有关于当前状态的本地信息，则必须将本地状态表的“当前”字段设置为“否”。
Transac. status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no yes/yes
no yes depends on local info
Transac. status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no yes/yes
no yes depends on local info
Table 3: Possible values for the "Current" fields
表3：“当前”字段的可能值
Once both tables have been updated, an answer MUST be generated following the rules described in Section 5.1.1, taking into account that "send", "recv", "local" and "remote" tags have to be inverted in the answer, as shown in table 4.
两个表更新后，必须按照第5.1.1节所述规则生成答案，同时考虑到答案中的“发送”、“接收”、“本地”和“远程”标签必须颠倒，如表4所示。
Offer Answer
______________
send recv
recv send
local remote
remote local
Offer Answer
______________
send recv
recv send
local remote
remote local
Table 4: Values of tags in offers and answers
表4：报价和答案中的标签值
At the time the answer is sent, the transaction status table and the answerer's local status table contain the same values. Therefore, this answer contains the shared view of the status of the media line in the current-status attribute and the negotiated strength and direction-tags in the desired-status attribute.
在发送应答时，事务状态表和应答者的本地状态表包含相同的值。因此，此答案包含当前状态属性中媒体线路状态的共享视图以及所需状态属性中协商的强度和方向标记。
If the resource reservation mechanism used requires participation of both user agents, the answerer SHOULD start resource reservation after having sent the answer and the offerer SHOULD start resource reservation as soon as the answer is received. If participation of the peer user agent is not needed (e.g., segmented status type), the offerer MAY start resource reservation before sending the offer and the answerer MAY start it before sending the answer.
如果使用的资源保留机制需要两个用户代理的参与，则应答者应在发送应答后启动资源保留，而报价者应在收到应答后立即启动资源保留。如果不需要对等用户代理的参与（例如，分段状态类型），报价人可以在发送报价之前开始资源预留，应答人可以在发送应答之前开始资源预留。
The status of the resource reservation of a media line can change between two consecutive offer/answer exchanges. Therefore, both user agents MUST keep their local status tables up to date, using local information throughout the duration of the session.
媒体线路的资源预留状态可以在两次连续的提供/应答交换之间更改。因此，两个用户代理必须在整个会话期间使用本地信息，使其本地状态表保持最新。
6 Suspending and Resuming Session Establishment
6暂停和恢复会议的建立
A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; session establishment is suspended until that moment (e.g., a PSTN gateway reserves resources without sending signalling to the PSTN.)
收到带有先决条件的要约的用户代理服务器在满足所有强制性先决条件之前不应通知用户；会话建立暂停，直到该时刻（例如，PSTN网关保留资源而不向PSTN发送信令。）
A user agent server may receive an INVITE request with no offer in it. In this case, following normal procedures defined in [1] and [5], the user agent server will provide an offer in a reliable 1xx response. The user agent client will send the answer in another SIP request (i.e., the PRACK for the 1xx). If the offer and the answer contain preconditions, the user agent server SHOULD NOT alert the user until all the mandatory preconditions in the answer are met.
用户代理服务器可能接收到邀请请求，但其中没有提供。在这种情况下，按照[1]和[5]中定义的正常过程，用户代理服务器将在可靠的1xx响应中提供报价。用户代理客户端将在另一个SIP请求（即1xx的PRACK）中发送应答。如果报价和答案包含先决条件，则在答案中的所有强制性先决条件都满足之前，用户代理服务器不应通知用户。
Note that in this case, a user agent server providing an initial offer with preconditions, a 180 (Ringing) response with preconditions will never be sent, since the user agent server cannot alert the user until all the preconditions are met.
请注意，在这种情况下，如果用户代理服务器提供带先决条件的初始报价，则将永远不会发送带先决条件的180（振铃）响应，因为在满足所有先决条件之前，用户代理服务器无法通知用户。
A UAS that is not capable of unilaterally meeting all of the mandatory preconditions MUST include a confirm-status attribute in the SDP (offer or answer) that it sends (see Section 7). Further, the SDP (offer or answer) that contains this confirm-status attribute MUST be sent as soon as allowed by the SIP offer/answer rules.
无法单方面满足所有强制性先决条件的UAS必须在其发送的SDP（报价或应答）中包含确认状态属性（见第7节）。此外，包含此确认状态属性的SDP（提供或应答）必须在SIP提供/应答规则允许的情况下尽快发送。
While session establishment is suspended, user agents SHOULD not send any data over any media stream. In the case of RTP [6], neither RTP nor RTCP packets are sent.
会话建立挂起时，用户代理不应通过任何媒体流发送任何数据。在RTP[6]的情况下，既不发送RTP数据包，也不发送RTCP数据包。
A user agent server knows that all the preconditions are met for a media line when its local status table has a value of "yes" in all the rows whose strength-tag is "mandatory". When the preconditions of all the media lines of the session are met, session establishment SHOULD resume.
当用户代理服务器的本地状态表在强度标记为“强制”的所有行中的值为“是”时，用户代理服务器知道媒体线路满足所有先决条件。当满足会话所有媒体线路的先决条件时，会话建立应恢复。
For an initial INVITE, suspending and resuming session establishment is very intuitive. The callee will not be alerted until all the mandatory preconditions are met. However, offers containing preconditions sent in the middle of an ongoing session need further explanation. Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters. Section 13 contains an example of this situation.
对于初始邀请，暂停和恢复会话建立非常直观。在满足所有强制先决条件之前，不会向被叫方发出警报。然而，包含在正在进行的会话中间发送的前提条件的请求需要进一步解释。两个用户代理都应继续使用旧的会话参数，直到满足所有必需的先决条件。此时，用户代理可以开始使用新的会话参数。第13节包含了这种情况的一个例子。
7 Status Confirmation
7状态确认
The confirm-status attribute MAY be used in both offers and answers. This attribute represents a threshold for the resource reservation. When this threshold is reached or surpassed, the user agent MUST send an offer to the peer user agent, reflecting the new current status of the media line as soon as allowed by the SIP offer/answer rules. If this threshold is crossed again (e.g., the network stops providing resources for the media stream), the user agent MUST send a new offer as well, as soon as allowed by the SIP offer/answer rules.
确认状态属性可用于报价和应答。此属性表示资源保留的阈值。当达到或超过此阈值时，用户代理必须向对等用户代理发送要约，反映SIP要约/应答规则允许的媒体线路的新当前状态。如果再次超过此阈值（例如，网络停止为媒体流提供资源），则用户代理也必须在SIP提供/应答规则允许的情况下尽快发送新的提供。
If a peer has requested confirmation on a particular stream, an agent MUST mark that stream with a flag in its local status table. When all the rows with this flag have a "Current" value of "yes", the user agent MUST send a new offer to the peer. This offer will contain the current status of resource reservation in the current-status attributes. Later, if any of the rows with this flag transition to "No", a new offer MUST be sent as well.
如果对等方请求对特定流进行确认，则代理必须在其本地状态表中使用标志标记该流。当具有此标志的所有行的“当前”值为“是”时，用户代理必须向对等方发送新的报价。此报价将在“当前状态”属性中包含资源保留的当前状态。稍后，如果带有此标志的任何行转换为“否”，则还必须发送新的报价。
Confirmation attributes are not negotiated. The answerer uses the value of the confirm-status attribute in the offer, and the offerer uses the value of this attribute in the answer.
不协商确认属性。回答者在报价中使用确认状态属性的值，而报价者在回答中使用此属性的值。
For example, if a user agent receives an SDP description with the following attributes:
例如，如果用户代理接收到具有以下属性的SDP描述：
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
It will send an offer as soon as it reserves resources in its access network ("remote" tag in the received message) for both directions (sendrecv).
一旦在其接入网络中为两个方向（sendrecv）保留资源（接收到的消息中的“remote”标记），它将立即发送要约。
8 Refusing an offer
8拒绝要约
We define a new SIP status code:
我们定义了一个新的SIP状态代码：
Server-Error = "580" ;Precondition Failure
服务器错误=“580”；先决条件失败
When a UAS, acting as an answerer, cannot or is not willing to meet the preconditions in the offer, it SHOULD reject the offer by returning a 580 (Precondition-Failure) response.
当作为应答者的UAS不能或不愿意满足报价中的先决条件时，应通过返回580（先决条件失败）响应拒绝报价。
Using the 580 (Precondition Failure) status code to refuse an offer is useful when the offer comes in an INVITE or in an UPDATE request. However, SIP does not provide a means to refuse offers that arrive in a response (1xx or 2xx) to an INVITE. If a UAC generates an initial INVITE without an offer and receives an offer in a 1xx or 2xx response which is not acceptable, it SHOULD respond to this offer with a correctly formed answer and immediately send a CANCEL or a BYE.
在邀请或更新请求中提供服务时，使用580（前提条件失败）状态代码拒绝提供服务非常有用。但是，SIP不提供拒绝响应邀请（1xx或2xx）的报价的方法。如果UAC在没有报价的情况下生成初始邀请，并在1x或2xx响应中收到不可接受的报价，则UAC应以正确格式的回复回复此报价，并立即发送取消或再见。
If the offer comes in a 1xx or 2xx response to a re-INVITE, A would not have a way to reject it without terminating the session at the same time. The same recommendation given in Section 15.2 of [1] applies here:
如果该提议是对重新邀请的1x或2xx响应，则在不同时终止会话的情况下，a将无法拒绝该提议。[1]第15.2节中给出的相同建议适用于以下情况：
"The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to A, A SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session."
“UAS必须确保会话描述在媒体格式、传输、需要对等方支持的其他参数方面与其以前的会话描述重叠。这是为了避免对等方拒绝会话描述。但是，如果A不能接受，A应使用有效的会话描述生成回答然后发送“再见”以终止会话。“
580 (Precondition Failure) responses and BYE and CANCEL requests, indicating failure to meet certain preconditions, SHOULD contain an SDP description, indicating which desired status triggered the failure. Note that this SDP description is not an offer or an answer, since it does not lead to the establishment of a session. The format of such a description is based on the last SDP (an offer or an answer) received from the remote UA.
580（先决条件失败）响应以及BYE和CANCEL请求（指示未能满足某些先决条件）应包含SDP描述，指示触发失败的期望状态。请注意，此SDP描述不是提议或回答，因为它不会导致会话的建立。此类描述的格式基于从远程UA接收的最后一个SDP（报价或应答）。
For each "m=" line in the last SDP description received, there MUST be a corresponding "m=" line in the SDP description indicating failure. This SDP description MUST contain exactly the same number of "m=" lines as the last SDP description received. The port number of every "m=" line MUST be set to zero, but the connection address is arbitrary.
对于上次收到的SDP说明中的每一行，SDP说明中必须有一行对应的“m=”表示故障。此SDP说明必须包含与上次收到的SDP说明完全相同的“m=”行数。每个“m=”行的端口号必须设置为零，但连接地址是任意的。
The desired status line corresponding to the precondition that triggered the failure MUST use the "failure" strength-tag, as shown in the example below:
与触发故障的前提条件相对应的所需状态行必须使用“故障”强度标签，如下例所示：
m=audio 20000 RTP/AVP 0
a=des:qos failure e2e send
m=audio 20000 RTP/AVP 0
a=des:qos failure e2e send
In the offer/answer model, when an answerer wishes to reject a media stream, it sets its port to zero. The presence of preconditions does not change this behaviour; streams are still rejected by setting their port to zero.
在提供/应答模型中，当应答者希望拒绝媒体流时，它将其端口设置为零。前提条件的存在不会改变这种行为；通过将其端口设置为零，流仍然被拒绝。
Both the offerer and the answerer MUST ignore all the preconditions that affect a stream with its port set to zero. They are not taken into consideration to decide whether or not session establishment can resume.
提供方和应答方都必须忽略影响端口设置为零的流的所有先决条件。在决定是否可以恢复会话建立时，不考虑它们。
9 Unknown Precondition Type
9未知的前提条件类型
This document defines the "qos" tag for quality of service preconditions. New precondition-types defined in the future will have new associated tags. A UA that receives an unknown precondition-type, with a "mandatory" strength-tag in an offer, MUST refuse the offer unless the only unknown mandatory preconditions have the "local" tag. In this case, the UA does not need to be involved in order to meet the preconditions. The UA will ask for confirmation of the preconditions and, when the confirmation arrives, it will resume session establishment.
本文档定义了服务质量前提条件的“qos”标签。将来定义的新前置条件类型将具有新的关联标记。收到未知前提条件类型且报价中带有“强制”强度标签的UA必须拒绝报价，除非唯一未知的强制前提条件具有“本地”标签。在这种情况下，UA无需参与以满足先决条件。UA将要求确认先决条件，并在确认到达时恢复会话建立。
A UA refusing an offer follows the rules described in section 8, but instead of the tag "failure", it uses the tag "unknown", as shown in the example below:
UA拒绝要约遵循第8节中描述的规则，但它使用“未知”标记代替“失败”，如下例所示：
m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send
m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send
10 Multiple Preconditions per Media Stream
每个媒体流有10个先决条件
A media stream MAY contain multiple preconditions. Different preconditions MAY have the same precondition-type and different status-types (e.g., end to end and segmented quality of service preconditions) or different precondition-types (this document only defines the "qos" precondition type, but extensions may define more precondition-types in the future).
媒体流可以包含多个先决条件。不同的先决条件可能具有相同的先决条件类型和不同的状态类型（例如，端到端和分段服务质量先决条件）或不同的先决条件类型（本文档仅定义“qos”先决条件类型，但扩展可能会在将来定义更多的先决条件类型）。
All the preconditions for a media stream MUST be met in order to resume session establishment. The following example shows a session description that uses both end-to-end and segmented status-types for a media stream.
为了恢复会话建立，必须满足媒体流的所有先决条件。以下示例显示了对媒体流同时使用端到端和分段状态类型的会话描述。
m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv
m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv
11 Option Tag for Preconditions
11先决条件的选项标签
We define the option tag "precondition" for use in the Require and Supported header fields. An offerer MUST include this tag in the Require header field if the offer contains one or more "mandatory" strength-tags. If all the strength-tags in the description are "optional" or "none", the offerer MUST include this tag in either a Supported header field or in a Require header field. It is, however, RECOMMENDED that the Supported header field be used in this case. The lack of preconditions in the answer would indicate that the answerer did not support this extension.
我们定义了选项标记“Premission”，以便在Require和Supported头字段中使用。如果报价包含一个或多个“强制”强度标签，则报价人必须在“要求标题”字段中包含此标签。如果描述中的所有强度标签均为“可选”或“无”，则报价人必须将该标签包含在支持的标题字段或要求的标题字段中。但是，建议在这种情况下使用受支持的标题字段。答复中缺少先决条件表明答复者不支持这一延长。
The mapping of offers and answers to SIP requests and responses is performed following the rules given in [5]. Therefore, a user agent including preconditions in the SDP MUST support the PRACK and UPDATE methods. Consequently, it MUST include the "100rel" [7] tag in the Supported header field and SHOULD include an Allow header field with the "UPDATE" tag [5].
根据[5]中给出的规则，对SIP请求和响应的提供和应答进行映射。因此，在SDP中包含前提条件的用户代理必须支持PRACK和UPDATE方法。因此，它必须在受支持的标题字段中包含“100rel”[7]标记，并应包含带有“UPDATE”标记的允许标题字段[5]。
12 Indicating Capabilities
12指示能力
The offer/answer model [4] describes the format of a session description to indicate capabilities. This format is used in responses to OPTIONS requests. A UA that supports preconditions SHOULD add desired status lines indicating the precondition-types supported for each media stream. These lines MUST have the "none" strength-tag, as shown in the example below:
提供/应答模型[4]描述了用于指示功能的会话描述的格式。此格式用于响应选项请求。支持前置条件的UA应添加所需的状态行，指示每个媒体流支持的前置条件类型。这些线必须有“无”强度标签，如下例所示：
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=des:foo none e2e sendrecv
a=des:qos none local sendrecv
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=des:foo none e2e sendrecv
a=des:qos none local sendrecv
Note that when this document was published, the precondition-type "foo" has not been registered. It is used here in the session description above to provide an example with multiple precondition-types.
请注意，在发布此文档时，前提条件类型“foo”尚未注册。在上面的会话描述中，这里使用它来提供一个具有多个前提条件类型的示例。
A UA that supports this framework SHOULD add a "precondition" tag to the Supported header field of its responses to OPTIONS requests.
支持此框架的UA应在其对选项请求的响应的受支持标题字段中添加一个“前置条件”标记。
13 Examples
13个例子
The following examples cover both status types; end-to-end and segmented.
以下示例涵盖这两种状态类型；端到端和分段。
The call flow of Figure 2 shows a basic session establishment using the end-to-end status type. The SDP descriptions of this example are shown below:
图2的调用流显示了使用端到端状态类型的基本会话建立。此示例的SDP描述如下所示：
SDP1: A includes end-to-end quality of service preconditions in the initial offer.
SDP1:A在初始报价中包括端到端服务质量先决条件。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: Since B uses RSVP, it can know when resources in its "send" direction are available, because it will receive RESV messages from the network. However, it does not know the status of the reservations in the other direction. B requests confirmation for resource reservations in its "recv" direction to the peer user agent A in its answer.
SDP2：由于B使用RSVP，它可以知道“发送”方向的资源何时可用，因为它将从网络接收RESV消息。但是，它不知道另一方面保留的状况。B在其应答中向对等用户代理A请求在其“recv”方向上的资源保留的确认。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
After having sent the answer, B starts reserving network resources for the media stream. When A receives this answer (2), it starts performing resource reservation as well. Both UAs use RSVP, so A sends PATH messages towards B and B sends PATH messages towards A.
发送应答后，B开始为媒体流保留网络资源。当A收到这个答案（2）时，它也开始执行资源预留。两个UAs都使用RSVP，因此A向B发送路径消息，B向A发送路径消息。
As time passes, B receives RESV messages confirming the reservation. However, B waits until resources in the other direction are reserved as well, since it did not receive any confirmation and the preconditions still have not been met.
随着时间的推移，B接收确认预订的RESV消息。但是，B也会等待另一个方向的资源被保留，因为它没有收到任何确认，并且前提条件仍然没有得到满足。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3：当A收到RESV消息时，它会向B发送更新的报价（5）：
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status of the resource reservation (i.e., sendrecv):
SDP4:B以包含资源保留（即sendrecv）当前状态的答案（6）进行响应：
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
At this point in time, session establishment resumes and B returns a 180 (Ringing) response (7).
此时，会话建立恢复，B返回180（振铃）响应（7）。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 2: Example using the end-to-end status type
图2：使用端到端状态类型的示例
Let's assume, that in the middle of the session, A wishes to change the IP address where it is receiving media. Figure 3 shows this scenario.
让我们假设，在会话的中间，希望改变它接收媒体的IP地址。图3显示了这个场景。
SDP1: A includes an offer in a re-INVITE (1). A continues to receive media on the old IP address (192.0.2.1), but is ready to receive media on the new one as well (192.0.2.2):
SDP1:A在重新邀请中包含报价（1）。A继续在旧IP地址（192.0.2.1）上接收媒体，但也准备在新IP地址（192.0.2.2）上接收媒体：
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: B includes a "conf" attribute in its answer. B continues sending media to the old remote IP address (192.0.2.1)
SDP2:B在其答案中包含一个“conf”属性。B继续将媒体发送到旧的远程IP地址（192.0.2.1）
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP3: When A receives RESV messages it sends an updated offer (5) to B:
SDP3：当A收到RESV消息时，它向B发送更新的报价（5）：
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6), indicating that the preconditions have been met (current status "sendrecv). It is now that B begins sending media to the new remote IP address (192.0.2.2).
SDP4:B以回答（6）进行响应，表明满足了前提条件（当前状态为“sendrecv”）。现在B开始向新的远程IP地址（192.0.2.2）发送媒体。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| |
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| |
| |
Figure 3: Session modification with preconditions
图3：带先决条件的会话修改
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
The call flow of Figure 4 shows a basic session establishment using the segmented status type. The SDP descriptions of this example are shown below:
图4的调用流显示了使用分段状态类型的基本会话建立。此示例的SDP描述如下所示：
SDP1: A includes local and remote QoS preconditions in the initial offer. Before sending the initial offer, A reserves resources in its access network. This is indicated in the local current status of the SDP below:
SDP1:A在初始报价中包括本地和远程QoS先决条件。在发送初始报价之前，A在其接入网络中保留资源。这在以下SDP的本地当前状态中显示：
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
SDP2: B reserves resources in its access network and, since all the preconditions are met, returns an answer in a 180 (Ringing) response (3).
SDP2:B在其接入网络中保留资源，并且由于满足所有先决条件，因此在180（响铃）响应（3）中返回答案。
m=audio 30000 RTP/AVP 0 8
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
m=audio 30000 RTP/AVP 0 8
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
Let's assume that after receiving this response, A decides that it wants to use only PCM u-law (payload 0), as opposed to both PCM u-law and A-law (payload 8). It would send an UPDATE to B, possibly before receiving the 200 (OK) for the INVITE (5). The SDP would look like:
假设在收到此响应后，A决定只使用PCM u-law（有效载荷0），而不是PCM u-law和A-law（有效载荷8）。它可能会在收到邀请（5）的200（OK）之前向B发送更新。SDP看起来像：
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
B would generate an answer for this offer and place it in the 200 (OK) for the UPDATE.
B将生成此报价的答案，并将其放入200（确定）中进行更新。
Note that this last offer/answer to reduce the number of supported codecs may arrive to the user agent server after the 200 (OK) response has been generated. This would mean that the session is established before A has reduced the number of supported codecs. To avoid this situation, the user agent client could wait for the first answer from the user agent before setting its local current status to "sendrecv".
请注意，在生成200（确定）响应后，用于减少支持的编解码器数量的最后一个提议/答复可能会到达用户代理服务器。这意味着会话是在A减少支持的编解码器数量之前建立的。为了避免这种情况，用户代理客户端可以在将其本地当前状态设置为“sendrecv”之前等待用户代理的第一个应答。
The call flow of Figure 5 shows a basic session establishment where the initial offer appears in a reliable 1xx response. This example uses the end-to-end status type. The SDP descriptions of this example are shown below:
图5的调用流显示了一个基本会话建立，其中初始报价出现在可靠的1xx响应中。本例使用端到端状态类型。此示例的SDP描述如下所示：
The first INVITE (1) does not contain a session description. Therefore, the initial offer is sent by B in a reliable 183 (Session Progress) response.
第一个邀请（1）不包含会话描述。因此，B以可靠的183（会话进度）响应发送初始报价。
SDP1: B includes end-to-end quality of service preconditions in the initial offer. Since B uses RSVP, it can know when resources in its "send" direction are available, because it will receive RESV messages from the network. However, it does not know the status of the reservations in the other direction. B requests confirmation for resource reservations in its "recv" direction, to the peer user agent A, in its answer.
SDP1:B在初始报价中包括端到端服务质量先决条件。由于B使用RSVP，它可以知道其“发送”方向的资源何时可用，因为它将从网络接收RESV消息。但是，它不知道另一方面保留的状况。B在其应答中向对等用户代理A请求在其“recv”方向上确认资源预留。
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP2: A includes its answer in the PRACK for the 183 (Session Progress) response.
SDP2:A将其答案包含在183（会话进度）响应的PRACK中。
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
A B
A B
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|-------------(1) INVITE SDP1--------------->|
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|<----------(2) 180 Ringing SDP2-------------|
| |
|----------------(3) PRACK------------------>|
| |
|<-----------(4) 200 OK (PRACK)--------------|
| |
| |
|<-----------(5) 200 OK (INVITE)-------------|
| |
|------------------(6) ACK------------------>|
| |
| |
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|-------------(1) INVITE SDP1--------------->|
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|<----------(2) 180 Ringing SDP2-------------|
| |
|----------------(3) PRACK------------------>|
| |
|<-----------(4) 200 OK (PRACK)--------------|
| |
| |
|<-----------(5) 200 OK (INVITE)-------------|
| |
|------------------(6) ACK------------------>|
| |
| |
Figure 4: Example using the segmented status type
图4：使用分段状态类型的示例
A B
A B
| |
|----------------(1) INVITE----------------->|
| |
|<------(2) 183 Session Progress SDP1--------|
| |
|---------------(3) PRACK SDP2-------------->|
| *** *** |
|<-*R*--------(4) 200 OK (PRACK)-------*R*---|
| *E* *E* |
| *S* *S* |
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
|-------------(5) UPDATE SDP3----------***-->|
| *** |
|<--------(6) 200 OK (UPDATE) SDP4-----***---|
| *** |
| *** |
| *** |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
|----------------(1) INVITE----------------->|
| |
|<------(2) 183 Session Progress SDP1--------|
| |
|---------------(3) PRACK SDP2-------------->|
| *** *** |
|<-*R*--------(4) 200 OK (PRACK)-------*R*---|
| *E* *E* |
| *S* *S* |
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
|-------------(5) UPDATE SDP3----------***-->|
| *** |
|<--------(6) 200 OK (UPDATE) SDP4-----***---|
| *** |
| *** |
| *** |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
Figure 5: Example of an initial offer in a 1xx response
图5:1xx响应中的初始报价示例
After having sent the answer, A starts reserving network resources for the media stream. When B receives this answer (3), it starts performing resource reservation as well. Both UAs use RSVP, so A sends PATH messages towards B and B sends PATH messages towards A.
发送应答后，A开始为媒体流保留网络资源。当B收到这个答案（3）时，它也开始执行资源预留。两个UAs都使用RSVP，因此A向B发送路径消息，B向A发送路径消息。
SDP3: When A receives RESV messages, it sends an updated offer (5) to B:
SDP3：当A收到RESV消息时，它会向B发送更新的报价（5）：
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status of the resource reservation (i.e., recv):
SDP4:B以包含资源保留（即recv）当前状态的答案（6）进行响应：
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e recv
a=des:qos mandatory e2e sendrecv
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e recv
a=des:qos mandatory e2e sendrecv
As time passes, B receives RESV messages confirming the reservation. At this point in time, session establishment resumes and B returns a 180 (Ringing) response (7).
随着时间的推移，B接收确认预订的RESV消息。此时，会话建立恢复，B返回180（振铃）响应（7）。
14 Security Considerations
14安全考虑
An entity in the middle of two user agents establishing a session may add desired-status attributes making session establishment impossible. It could also modify the content of the current-status parameters so that the session is established without meeting the preconditions. Integrity protection can be used to avoid these attacks.
在建立会话的两个用户代理中间的实体可以添加使得会话建立不可能的期望状态属性。它还可以修改当前状态参数的内容，以便在不满足先决条件的情况下建立会话。完整性保护可用于避免这些攻击。
An entity performing resource reservations upon reception of unauthenticated requests carrying preconditions can be an easy target for a denial of service attack. Requests with preconditions SHOULD be authenticated.
在接收到带有前提条件的未经验证的请求时执行资源保留的实体很容易成为拒绝服务攻击的目标。应验证具有先决条件的请求。
15 IANA Considerations
15 IANA考虑因素
This document defines three media level SDP attributes: desired-status, current-status and conf-status. Their format is defined in Section 4.
本文档定义了三个媒体级SDP属性：所需状态、当前状态和配置状态。其格式见第4节。
This document defines a framework for using preconditions with SIP. Precondition-types to be used with this framework are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
本文档定义了在SIP中使用前置条件的框架。与此框架一起使用的前提条件类型在标准跟踪RFC中发布时由IANA注册。RFC的IANA注意事项部分必须包括以下信息，这些信息与出版物的RFC编号一起出现在IANA注册表中。
o Name of the precondition-type. The name MAY be of any length, but SHOULD be no more than ten characters long.
o 前提条件类型的名称。名称可以是任意长度，但长度不得超过十个字符。
o Descriptive text that describes the extension.
o 描述扩展名的描述性文本。
The only entry in the registry for the time being is:
目前注册表中唯一的条目是：
Pecondition-Type Reference Description
---------------- --------- -----------
qos RFC 3312 Quality of Service preconditions
Pecondition-Type Reference Description
---------------- --------- -----------
qos RFC 3312 Quality of Service preconditions
This document also defines a new SIP status code (580). Its default reason phrase (Precondition Failure) is defined in section 8.
本文档还定义了一个新的SIP状态代码（580）。其默认原因短语（前提条件失败）在第8节中定义。
This document defines a SIP option tag (precondition) in section 11.
本文件在第11节中定义了SIP选项标签（前提条件）。
16 Notice Regarding Intellectual Property Rights
16关于知识产权的通知
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
17 References
17参考文献
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002.
[5] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年9月。
[6] Schulzrinne, S., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne，S.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. Ramakrishnan, "DOSA: an architecture for providing robust IP telephony service," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000.
[8] C.Kalmanek，W.Marshall，P.Mishra，D.Nortz和K.K.Ramakrishnan，“DOSA：提供可靠IP电话服务的体系结构”，《计算机通信会议记录》（IEEE Infocom）（以色列特拉维夫），2000年3月。
18 Contributors
18个贡献者
The following persons contributed and were co-authors on earlier versions of this spec:
以下人员参与了本规范早期版本的撰写并共同撰写了本规范：
K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia University).
K.K.罗摩克里希南（Terapologic Networks）、埃德·米勒（Terayon）、格伦·拉塞尔（CableLabs）、伯卡克·贝瑟（Pacific Broadband Communications）、迈克·曼内特（3Com）、库尔特·斯坦布雷纳（3Com）、戴夫·奥兰（Cisco）、弗莱明·安德里森（Cisco）、迈克尔·拉马霍（Cisco）、约翰·皮肯斯（Com21）、普尔尼玛·拉尔瓦尼（诺基亚）、乔恩·费罗斯（铜山网络），埃文斯博士（D.R.埃文斯咨询公司）、凯斯·凯利（网语）、亚当·罗奇（dynamicsoft）、迪安·威利斯（dynamicsoft）、史蒂夫·多诺万（dynamicsoft）、亨宁·舒尔兹林内（哥伦比亚大学）。
This "manyfolks" document is the culmination of over two years of work by many individuals, most are listed here and in the following acknowledgements section. A special note is due to Flemming Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek, Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach, Jonathan Rosenberg, and Henning Schulzrinne for spearheading the initial "single INVITE" quality of service preconditions work from previous, non-SIP compatible, "two-stage Invite" proposals. These "two-stage INVITE" proposals had their origins from Distributed Call Signaling work in PacketCable, which, in turn, had architectural elements from AT&T's Distributed Open Systems Architecture (DOSA) work [8].
这份“manyfolks”文件是许多个人两年多工作的成果，其中大部分在这里和下面的致谢部分列出。弗莱明·安德烈森、伯卡克·贝塞、戴夫·博德曼、比尔·古克尔、恰克·卡尔马内克、基思·凯利、普尔尼玛·拉尔瓦尼、约翰·劳泽、比尔·马歇尔、迈克·曼内特、戴夫·奥兰、K.K.罗马克里希南、迈克尔·拉马约、亚当·罗奇、乔纳森·罗森伯格和亨宁·舒尔兹林内率先发起了最初的“单一邀请”服务质量先决条件工作来自以前的、与SIP不兼容的“两阶段邀请”提案。这些“两阶段邀请”提案源于PacketCable中的分布式呼叫信令工作，而PacketCable又具有AT&T分布式开放系统架构（DOSA）工作中的架构元素[8]。
19 Acknowledgments
19致谢
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications.
PacketCable项目中的分布式呼叫信令工作是代表许多不同公司的大量人员的工作。作者要感谢并感谢以下人员的帮助：摩托罗拉的John Wheeler；大卫·博德曼、丹尼尔·保罗、阿里斯互动；比尔·布卢姆、杰伊·斯特拉特、杰夫·奥利斯、克莱夫·霍尔博罗、通用仪器；Doug Newlin，Guido Schuster，Ikhlaq Sidhu，3Com；海湾网络公司Jiri Matousek；法尔齐·哈扎伊，北电；约翰·查普曼、比尔·古克尔、思科；Chuck Kalmanek，Doug Nortz，John Lawser，James Cheng，Tong Hai Xiao，Partho Mishra，AT&T；Telcordia技术公司；和朗讯有线通讯。
Miguel Angel Garcia-Martin, Rohan Mahy and Mark Watson provided helpful comments and suggestions.
Miguel Angel Garcia Martin、Rohan Mahy和Mark Watson提供了有益的意见和建议。
20 Authors' Addresses
20作者地址
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson高级信号研究实验室FIN-02420 Jorvas芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Bill Marshall AT&T Florham Park, NJ 07932 USA
美国新泽西州弗罗勒姆公园比尔·马歇尔AT&T公司，邮编：07932
EMail: wtm@research.att.com
EMail: wtm@research.att.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover，NJ 07936美国
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
21 Full Copyright Statement
21版权声明全文
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编辑功能的资金目前由互联网协会提供。