Network Working Group H. Schulzrinne
Request for Comments: 4412 Columbia U.
Category: Standards Track J. Polk
Cisco Systems
February 2006
Network Working Group H. Schulzrinne
Request for Comments: 4412 Columbia U.
Category: Standards Track J. Polk
Cisco Systems
February 2006
Communications Resource Priority for the 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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers.
本文档定义了两个用于通信资源优先级的新会话发起协议（SIP）头字段，即“资源优先级”和“接受资源优先级”。“Resource Priority”头字段可以影响SIP用户代理（如电话网关和IP电话）和SIP代理的行为。它不会直接影响IP路由器的转发行为。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................6
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields ...................................................6
3.1. The 'Resource-Priority' Header Field .......................6
3.2. The 'Accept-Resource-Priority' Header Field ................8
3.3. Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' .................................8
3.4. The 'resource-priority' Option Tag .........................9
4. Behavior of SIP Elements That Receive Prioritized Requests ......9
4.1. Introduction ...............................................9
4.2. General Rules ..............................................9
4.3. Usage of Require Header with Resource-Priority ............10
4.4. OPTIONS Request with Resource-Priority ....................10
1. Introduction ....................................................3
2. Terminology .....................................................6
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields ...................................................6
3.1. The 'Resource-Priority' Header Field .......................6
3.2. The 'Accept-Resource-Priority' Header Field ................8
3.3. Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' .................................8
3.4. The 'resource-priority' Option Tag .........................9
4. Behavior of SIP Elements That Receive Prioritized Requests ......9
4.1. Introduction ...............................................9
4.2. General Rules ..............................................9
4.3. Usage of Require Header with Resource-Priority ............10
4.4. OPTIONS Request with Resource-Priority ....................10
4.5. Approaches for Preferential Treatment of Requests .........11
4.5.1. Preemption .........................................11
4.5.2. Priority Queueing ..................................12
4.6. Error Conditions ..........................................12
4.6.1. Introduction .......................................12
4.6.2. No Known Namespace or Priority Value ...............13
4.6.3. Authentication Failure .............................13
4.6.4. Authorization Failure ..............................14
4.6.5. Insufficient Resources .............................14
4.6.6. Busy ...............................................14
4.7. Element-Specific Behaviors ................................15
4.7.1. User Agent Client Behavior .........................15
4.7.2. User Agent Server Behavior .........................15
4.7.3. Proxy Behavior .....................................16
5. Third-Party Authentication .....................................17
6. Backwards Compatibility ........................................17
7. Examples .......................................................17
7.1. Simple Call ...............................................18
7.2. Receiver Does Not Understand Namespace ....................19
8. Handling Multiple Concurrent Namespaces ........................21
8.1. General Rules .............................................21
8.2. Examples of Valid Orderings ...............................21
8.3. Examples of Invalid Orderings .............................22
9. Registering Namespaces .........................................23
10. Namespace Definitions .........................................24
10.1. Introduction .............................................24
10.2. The "DSN" Namespace ......................................24
10.3. The "DRSN" Namespace .....................................25
10.4. The "Q735" Namespace .....................................25
10.5. The "ETS" Namespace ......................................26
10.6. The "WPS" Namespace ......................................26
11. Security Considerations .......................................27
11.1. General Remarks ..........................................27
11.2. Authentication and Authorization .........................27
11.3. Confidentiality and Integrity ............................28
11.4. Anonymity ................................................29
11.5. Denial-of-Service Attacks ................................29
12. IANA Considerations ...........................................30
12.1. Introduction .............................................30
12.2. IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields .................30
12.3. IANA Registration for Option Tag resource-priority .......31
12.4. IANA Registration for Response Code 417 ..................31
12.5. IANA Resource-Priority Namespace Registration ............31
12.6. IANA Priority-Value Registrations ........................32
13. Acknowledgements ..............................................32
14. References ....................................................33
4.5. Approaches for Preferential Treatment of Requests .........11
4.5.1. Preemption .........................................11
4.5.2. Priority Queueing ..................................12
4.6. Error Conditions ..........................................12
4.6.1. Introduction .......................................12
4.6.2. No Known Namespace or Priority Value ...............13
4.6.3. Authentication Failure .............................13
4.6.4. Authorization Failure ..............................14
4.6.5. Insufficient Resources .............................14
4.6.6. Busy ...............................................14
4.7. Element-Specific Behaviors ................................15
4.7.1. User Agent Client Behavior .........................15
4.7.2. User Agent Server Behavior .........................15
4.7.3. Proxy Behavior .....................................16
5. Third-Party Authentication .....................................17
6. Backwards Compatibility ........................................17
7. Examples .......................................................17
7.1. Simple Call ...............................................18
7.2. Receiver Does Not Understand Namespace ....................19
8. Handling Multiple Concurrent Namespaces ........................21
8.1. General Rules .............................................21
8.2. Examples of Valid Orderings ...............................21
8.3. Examples of Invalid Orderings .............................22
9. Registering Namespaces .........................................23
10. Namespace Definitions .........................................24
10.1. Introduction .............................................24
10.2. The "DSN" Namespace ......................................24
10.3. The "DRSN" Namespace .....................................25
10.4. The "Q735" Namespace .....................................25
10.5. The "ETS" Namespace ......................................26
10.6. The "WPS" Namespace ......................................26
11. Security Considerations .......................................27
11.1. General Remarks ..........................................27
11.2. Authentication and Authorization .........................27
11.3. Confidentiality and Integrity ............................28
11.4. Anonymity ................................................29
11.5. Denial-of-Service Attacks ................................29
12. IANA Considerations ...........................................30
12.1. Introduction .............................................30
12.2. IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields .................30
12.3. IANA Registration for Option Tag resource-priority .......31
12.4. IANA Registration for Response Code 417 ..................31
12.5. IANA Resource-Priority Namespace Registration ............31
12.6. IANA Priority-Value Registrations ........................32
13. Acknowledgements ..............................................32
14. References ....................................................33
During emergencies, communications resources (including telephone circuits, IP bandwidth, and gateways between the circuit-switched and IP networks) may become congested. Congestion can occur due to heavy usage, loss of resources caused by the natural or man-made disaster, and attacks on the network during man-made emergencies. This congestion may make it difficult for persons charged with emergency assistance, recovery, or law enforcement to coordinate their efforts. As IP networks become part of converged or hybrid networks, along with public and private circuit-switched (telephone) networks, it becomes necessary to ensure that these networks can assist during such emergencies.
在紧急情况下，通信资源（包括电话电路、IP带宽以及电路交换网络和IP网络之间的网关）可能会变得拥挤。拥塞可能是由于大量使用、自然或人为灾难造成的资源损失以及人为紧急情况下对网络的攻击造成的。这种拥挤可能使负责紧急援助、恢复或执法的人员难以协调工作。随着IP网络与公共和专用电路交换（电话）网络一起成为融合或混合网络的一部分，有必要确保这些网络在此类紧急情况下能够提供帮助。
Also, users may want to interrupt their lower-priority communications activities and dedicate their end-system resources to the high-priority communications attempt if a high-priority communications request arrives at their end system.
此外，如果高优先级通信请求到达其终端系统，用户可能希望中断其低优先级通信活动，并将其终端系统资源专用于高优先级通信尝试。
There are many IP-based services that can assist during emergencies. This memo only covers real-time communications applications involving the Session Initiation Protocol (SIP) [RFC3261], including voice-over-IP, multimedia conferencing, instant messaging, and presence.
有许多基于IP的服务可以在紧急情况下提供帮助。本备忘录仅涵盖涉及会话启动协议（SIP）[RFC3261]的实时通信应用，包括IP语音、多媒体会议、即时消息和状态。
SIP applications may involve at least five different resources that may become scarce and congested during emergencies. These resources include gateway resources, circuit-switched network resources, IP network resources, receiving end-system resources, and SIP proxy resources. IP network resources are beyond the scope of SIP signaling and are therefore not considered here.
SIP应用程序可能涉及至少五种不同的资源，这些资源在紧急情况下可能变得稀缺和拥挤。这些资源包括网关资源、电路交换网络资源、IP网络资源、接收端系统资源和SIP代理资源。IP网络资源超出SIP信令的范围，因此此处不考虑。
Even if the resources at the SIP element itself are not scarce, a SIP gateway may mark outgoing calls with an indication of priority, e.g., on an ISUP (ISDN User Part) IAM (Initial Address Message) originated by a SIP gateway with the Public Switched Telephone Network (PSTN).
即使SIP元素本身的资源不是稀缺的，SIP网关也可以用优先级指示标记传出呼叫，例如，在SIP网关通过公共交换电话网（PSTN）发起的ISUP（ISDN用户部分）IAM（初始地址消息）上。
In order to improve emergency response, it may become necessary to prioritize access to SIP-signaled resources during periods of emergency-induced resource scarcity. We call this "resource prioritization". The mechanism itself may well be in place at all times, but may only materially affect call handling during times of resource scarcity.
为了改进应急响应，可能有必要在紧急情况引起的资源短缺期间优先访问SIP信号资源。我们称之为“资源优先化”。该机制本身可能在任何时候都存在，但可能只会在资源短缺时对呼叫处理产生实质性影响。
Currently, SIP does not include a mechanism that allows a request originator to indicate to a SIP element that it wishes the request to invoke such resource prioritization. To address this need, this document adds a SIP protocol element that labels certain SIP requests.
目前，SIP不包括允许请求发起人向SIP元素指示其希望请求调用此类资源优先级的机制。为了满足这一需求，本文添加了一个SIP协议元素，用于标记某些SIP请求。
This document defines (Section 3) two new SIP header fields for communications resource priority, called 'Resource-Priority' and 'Accept-Resource-Priority'. The 'Resource-Priority' header field MAY be used by SIP user agents, including Public Switched Telephone Network (PSTN) gateways and terminals, and SIP proxy servers to influence their treatment of SIP requests, including the priority afforded to PSTN calls. For PSTN gateways, the behavior translates into analogous schemes in the PSTN, for example, the ITU Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both the PSTN-to-IP and IP-to-PSTN directions. ITU Recommendation I.255.3 [I.255.3] is another example.
本文档为通信资源优先级定义了两个新的SIP头字段（第3节），称为“资源优先级”和“接受资源优先级”。SIP用户代理（包括公共交换电话网络（PSTN）网关和终端）以及SIP代理服务器可以使用“资源优先级”报头字段来影响其对SIP请求的处理，包括向PSTN呼叫提供的优先级。对于PSTN网关，在PSTN-to-IP和IP-to-PSTN两个方向上，该行为转化为PSTN中的类似方案，例如ITU建议Q.735.3[Q.735.3]优先级机制。另一个例子是[ITU]255.3.I.建议。
A SIP request with a 'Resource-Priority' indication can be treated differently in these situations:
在以下情况下，具有“资源优先级”指示的SIP请求可以得到不同的处理：
1. The request can be given elevated priority for access to PSTN gateway resources, such as trunk circuits.
1. 该请求可以被赋予访问PSTN网关资源（如中继电路）的更高优先级。
2. The request can interrupt lower-priority requests at a user terminal, such as an IP phone.
2. 该请求可以中断用户终端（例如IP电话）上的低优先级请求。
3. The request can carry information from one multi-level priority domain in the telephone network (e.g., using the facilities of Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves inspecting or modifying the header field.
3. 在不修改SIP-735中的一个域[Q.3]或另一个域[Q.735]的优先级的情况下，使用SIP-735.3]可以将信息从一个域传送到另一个域。
4. In SIP proxies and back-to-back user agents, requests of higher priorities may displace existing signaling requests or bypass PSTN gateway capacity limits in effect for lower priorities.
4. 在SIP代理和背对背用户代理中，高优先级的请求可能会取代现有的信令请求，或者绕过PSTN网关容量限制，从而降低优先级。
This header field is related to, but differs in semantics from, the 'Priority' header field ([RFC3261], Section 20.26). The 'Priority' header field describes the importance that the SIP request should have for the receiving human or its agent. For example, that header may be factored into decisions about call routing to mobile devices and assistants and about call acceptance when the call destination is busy. The 'Priority' header field does not affect the usage of PSTN gateway or proxy resources, for example. In addition, any User Agent Client (UAC) can assert any 'Priority' value, and usage of 'Resource-Priority' header field values is subject to authorization.
该标题字段与“优先级”标题字段相关，但在语义上有所不同（[RFC3261]，第20.26节）。“优先级”头字段描述SIP请求对接收人员或其代理的重要性。例如，当呼叫目的地忙时，该报头可被考虑到关于到移动设备和助理的呼叫路由以及关于呼叫接受的决策中。例如，“优先级”标头字段不影响PSTN网关或代理资源的使用。此外，任何用户代理客户端（UAC）都可以断言任何“优先级”值，“资源优先级”头字段值的使用受授权的约束。
While the 'Resource-Priority' header field does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header field to cause such influence may be defined in other documents.
虽然“资源优先级”报头字段不会直接影响IP路由器的转发行为或通信资源的使用，例如数据包转发优先级，但使用该报头字段产生此类影响的过程可在其他文档中定义。
Existing implementations of RFC 3261 that do not participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message". Thus, the use of this mechanism is wholly invisible to existing implementations unless the request includes the Require header field with the resource-priority option tag.
不参与资源优先级机制的现有RFC 3261实现遵循RFC 3261第8.2.2节的正常规则：“如果UAS不理解请求中的头字段（即，本规范或任何支持的扩展中未定义头字段），服务器必须忽略该标头字段并继续处理该消息”。因此，该机制的使用对于现有实现来说是完全不可见的，除非请求包含带有资源优先级选项标记的requireheader字段。
The mechanism described here can be used for emergency preparedness in emergency telecommunications systems, but is only a small part of an emergency preparedness network and is not restricted to such use.
此处描述的机制可用于应急电信系统中的应急准备，但仅是应急准备网络的一小部分，不限于此类用途。
The mechanism aims to satisfy the requirements in [RFC3487]. It is structured so that it works in all SIP and Real-Time Transport Protocol (RTP) [RFC3550] transparent networks, defined in [RFC3487]. In such networks, all network elements and SIP proxies let valid SIP requests pass through unchanged. This is important since it is likely that this mechanism will often be deployed in networks where the edge networks are unaware of the resource priority mechanism and provide no special privileges to such requests. The request then reaches a PSTN gateway or set of SIP elements that are aware of the mechanism.
该机制旨在满足[RFC3487]中的要求。它的结构使其能够在[RFC3487]中定义的所有SIP和实时传输协议（RTP）[RFC3550]透明网络中工作。在这样的网络中，所有网络元素和SIP代理都允许有效的SIP请求不加更改地通过。这一点很重要，因为该机制可能经常部署在边缘网络不知道资源优先级机制并且不向此类请求提供特权的网络中。然后，请求到达PSTN网关或一组知道该机制的SIP元素。
For conciseness, we refer to SIP proxies and user agents (UAs) that act on the 'Resource-Priority' header field as RP actors.
为了简洁起见，我们将作用于“资源优先级”头字段的SIP代理和用户代理（UAs）称为RP参与者。
It is likely to be common that the same SIP element will handle requests that bear the 'Resource-Priority' header fields and those that do not.
同一个SIP元素将处理带有“资源优先级”头字段的请求和不带有“资源优先级”头字段的请求可能很常见。
Government entities and standardization bodies have developed several different priority schemes for their networks. Users would like to be able to obtain authorized priority handling in several of these networks, without changing SIP clients. Also, a single call may traverse SIP elements that are run by different administrations and subject to different priority mechanisms. Since there is no global ordering among those priorities, we allow each request to contain more than one priority value drawn from these different priority lists, called a namespace in this document. Typically, each SIP element only supports one such namespace, but we discuss what happens if an element needs to support multiple namespaces in Section 8.
政府实体和标准化机构为其网络制定了若干不同的优先计划。用户希望能够在其中几个网络中获得授权的优先级处理，而无需更改SIP客户端。此外，单个呼叫可能会遍历由不同管理机构运行并受不同优先级机制约束的SIP元素。由于这些优先级之间没有全局排序，因此我们允许每个请求包含从这些不同优先级列表中提取的多个优先级值，在本文档中称为名称空间。通常，每个SIP元素只支持一个这样的名称空间，但我们将在第8节讨论如果一个元素需要支持多个名称空间会发生什么。
Since gaining prioritized access to resources offers opportunities to deny service to others, it is expected that all such prioritized calls are subject to authentication and authorization, using standard SIP security (Section 11) or other appropriate mechanisms.
由于获得对资源的优先访问权提供了拒绝向其他人提供服务的机会，因此预期所有此类优先呼叫都要使用标准SIP安全（第11节）或其他适当机制进行身份验证和授权。
The remainder of this document is structured as follows. After defining terminology in Section 2, we define the syntax for the two new SIP header fields in Section 3 and then describe protocol behavior in Section 4. The two principal mechanisms for differentiated treatment of SIP requests (namely, preemption and queueing) are described in Section 4.5. Error conditions are covered in Section 4.6. Sections 4.7.1 through 4.7.3 detail the behavior of specific SIP elements. Third-party authentication is briefly summarized in Section 5. Section 6 describes how this feature affects existing systems that do not support it.
本文件其余部分的结构如下。在第2节中定义了术语之后，我们在第3节中定义了两个新SIP头字段的语法，然后在第4节中描述了协议行为。第4.5节描述了区分处理SIP请求的两种主要机制（即抢占和排队）。错误条件见第4.6节。第4.7.1节至第4.7.3节详细说明了特定SIP元件的行为。第5节简要概述了第三方认证。第6节描述了此功能如何影响不支持它的现有系统。
Since calls may traverse multiple administrative domains with different namespaces or multiple elements with the same namespace, it is strongly suggested that all such domains and elements apply the same algorithms for the same namespace, as otherwise the end-to-end experience of privileged users may be compromised.
由于调用可能会遍历具有不同名称空间的多个管理域或具有相同名称空间的多个元素，因此强烈建议所有此类域和元素对相同名称空间应用相同的算法，否则可能会损害特权用户的端到端体验。
Protocol examples are given in Section 7. Section 8 discusses what happens if a request contains multiple namespaces or an element can handle more than one namespace. Section 9 enumerates the information that namespace registrations need to provide. Section 10 defines the properties of five namespaces that are registered through this document. Security issues are considered in Section 11, but this document does not define new security mechanisms. Section 12 discusses IANA considerations and registers parameters related to this document.
协议示例见第7节。第8节讨论了如果一个请求包含多个名称空间或者一个元素可以处理多个名称空间，会发生什么情况。第9节列举了名称空间注册需要提供的信息。第10节定义了通过本文档注册的五个名称空间的属性。第11节考虑了安全问题，但本文件未定义新的安全机制。第12节讨论了IANA注意事项，并登记了与本文件相关的参数。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
This section defines the 'Resource-Priority' and 'Accept-Resource-Priority' SIP header field syntax. Behavior is described in Section 4.
本节定义“资源优先级”和“接受资源优先级”SIP头字段语法。行为在第4节中描述。
The 'Resource-Priority' request header field marks a SIP request as desiring prioritized access to resources, as described in the introduction.
“资源优先级”请求标头字段将SIP请求标记为希望优先访问资源，如引言中所述。
There is no protocol requirement that all requests within a SIP dialog or session use the 'Resource-Priority' header field. Local administrative policy MAY mandate the inclusion of the 'Resource-Priority' header field in all requests. Implementations of this specification MUST allow inclusion to be either by explicit user request or automatic for all requests.
没有协议要求SIP对话框或会话中的所有请求都使用“资源优先级”头字段。本地管理策略可能要求在所有请求中包含“资源优先级”标题字段。此规范的实现必须允许通过显式用户请求或自动包含所有请求。
The syntax of the 'Resource-Priority' header field is described below. The "token-nodot" production is copied from [RFC3265].
“资源优先级”标题字段的语法如下所述。“令牌节点”生产从[RFC3265]复制。
Resource-Priority = "Resource-Priority" HCOLON
r-value *(COMMA r-value)
r-value = namespace "." r-priority
namespace = token-nodot
r-priority = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
Resource-Priority = "Resource-Priority" HCOLON
r-value *(COMMA r-value)
r-value = namespace "." r-priority
namespace = token-nodot
r-priority = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
An example 'Resource-Priority' header field is shown below:
“资源优先级”标题字段示例如下所示：
Resource-Priority: dsn.flash
资源优先级：dsn.flash
The 'r-value' parameter in the 'Resource-Priority' header field indicates the resource priority desired by the request originator. Each resource value (r-value) is formatted as 'namespace' '.' 'priority value'. The value is drawn from the namespace identified by the 'namespace' token. Namespaces and priorities are case-insensitive ASCII tokens that do not contain periods. Thus, "dsn.flash" and "DSN.Flash", for example, are equivalent. Each namespace has at least one priority value. Namespaces and priority values within each namespace MUST be registered with IANA (Section 12). Initial namespace registrations are described in Section 12.5.
“资源优先级”标题字段中的“r值”参数表示请求发起人所需的资源优先级。每个资源值（r值）的格式为“命名空间”“优先级值”。该值是从“namespace”标记标识的命名空间中提取的。名称空间和优先级是不区分大小写的ASCII标记，不包含句点。因此，例如，“dsn.flash”和“dsn.flash”是等效的。每个命名空间至少有一个优先级值。每个名称空间中的名称空间和优先级值必须向IANA注册（第12节）。第12.5节描述了初始名称空间注册。
Since a request may traverse multiple administrative domains with multiple different namespaces, it is necessary to be able to enumerate several different namespaces within the same message. However, a particular namespace MUST NOT appear more than once in the same SIP message. These may be expressed equivalently as either comma-separated lists within a single header field, as multiple header fields, or as some combination. The ordering of 'r-values' within the header field has no significance. Thus, for example, the following three header snippets are equivalent:
由于一个请求可能会使用多个不同的名称空间穿越多个管理域，因此必须能够在同一消息中枚举多个不同的名称空间。但是，特定命名空间在同一SIP消息中不得出现多次。这些字段可以等效地表示为单个标题字段中的逗号分隔列表、多个标题字段或某些组合。标题字段中“r值”的顺序没有意义。因此，例如，以下三个标题片段是等效的：
Resource-Priority: dsn.flash, wps.3
资源优先级：dsn.flash，wps.3
Resource-Priority: wps.3, dsn.flash
资源优先级：wps.3，dsn.flash
Resource-Priority: wps.3 Resource-Priority: dsn.flash
资源优先级：wps.3资源优先级：dsn.flash
The 'Accept-Resource-Priority' response header field enumerates the resource values (r-values) a SIP user agent server is willing to process. (This does not imply that a call with such values will find sufficient resources and succeed.) The syntax of the 'Accept-Resource-Priority' header field is as follows:
“Accept Resource Priority”响应头字段枚举SIP用户代理服务器愿意处理的资源值（r值）。（这并不意味着使用此类值的调用将找到足够的资源并成功。）“Accept Resource Priority”标头字段的语法如下所示：
Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON [r-value *(COMMA r-value)]
Accept Resource Priority=“Accept Resource Priority”HCOLON[r-value*（逗号r-value）]
An example is given below:
下面给出了一个例子：
Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine
接受资源优先级：dsn.flash-override、dsn.flash、dsn.immediate、dsn.Priority、dsn.routine
Some administrative domains MAY choose to disable the use of the 'Accept-Resource-Priority' header for revealing too much information about that domain in responses. However, this behavior is NOT RECOMMENDED, as this header field aids in troubleshooting.
一些管理域可能会选择禁用“Accept Resource Priority”（接受资源优先级）头的使用，因为在响应中显示了有关该域的太多信息。但是，不建议使用此行为，因为此标题字段有助于进行故障排除。
3.3. Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields
3.3. “资源优先级”和“接受资源优先级”标题字段的使用
The following table extends the values in Table 2 of RFC 3261
[RFC3261]. (The PRACK method, labeled as PRA, is defined in
[RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT)
methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the
MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in
[RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB)
method in [RFC3903].)
The following table extends the values in Table 2 of RFC 3261
[RFC3261]. (The PRACK method, labeled as PRA, is defined in
[RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT)
methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the
MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in
[RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB)
method in [RFC3903].)
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o - o o o o o
Accept-Resource-Priority 417 amdr o - o o o o o
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o - o o o o o
Accept-Resource-Priority 417 amdr o - o o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o o o o o o o
Accept-Resource-Priority 417 amdr o o o o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o o o o o o o
Accept-Resource-Priority 417 amdr o o o o o o o
Other request methods MAY define their own handling rules; unless otherwise specified, recipients MAY ignore these header fields.
其他请求方法可以定义自己的处理规则；除非另有规定，否则收件人可以忽略这些标题字段。
This document also defines the "resource-priority" option tag. The behavior is described in Section 4.3, and the IANA registration is in Section 12.3.
本文档还定义了“资源优先级”选项标签。第4.3节描述了该行为，第12.3节描述了IANA注册。
All SIP user agents and proxy servers that support this specification share certain common behavior, which we describe below in Section 4.2. The behavior when a 'resource-priority' option tag is encountered in a 'Require' header field is described in Section 4.3. Section 4.4 describes the treatment of OPTIONS requests. The two fundamental resource contention resolution mechanisms, preemption and queueing, are described in Section 4.5. Section 4.6 explains what happens when requests fail. Behavior specific to user agent clients, servers, and proxy servers is covered in Section 4.7.
所有支持此规范的SIP用户代理和代理服务器都具有某些共同的行为，我们将在下面的第4.2节中描述这些行为。第4.3节描述了在“Require”标题字段中遇到“resource priority”选项标记时的行为。第4.4节描述了期权请求的处理。第4.5节介绍了两种基本的资源争用解决机制：抢占和排队。第4.6节解释了当请求失败时会发生什么。第4.7节介绍了特定于用户代理客户端、服务器和代理服务器的行为。
The 'Resource-Priority' header field is potentially applicable to all SIP request messages. At a minimum, implementations of the following request types MUST support the Resource-Priority header to be in compliance with this specification:
“资源优先级”标头字段可能适用于所有SIP请求消息。至少，以下请求类型的实现必须支持资源优先级标头以符合本规范：
o INVITE [RFC3261]
o 邀请[RFC3261]
o ACK [RFC3261]
o 确认[RFC3261]
o PRACK [RFC3262]
o 普拉克[RFC3262]
o UPDATE [RFC3311]
o 更新[RFC3311]
o REFER [RFC3515]
o 参考[RFC3515]
Implementations SHOULD support the 'Resource-Priority' header field in the following request types:
实施应支持以下请求类型中的“资源优先级”标头字段：
o MESSAGE [RFC3428]
o 信息[RFC3428]
o SUBSCRIBE [RFC3265]
o 订阅[RFC3265]
o NOTIFY [RFC3265]
o 通知[RFC3265]
Note that this does not imply that all implementations have to support all request methods listed.
请注意，这并不意味着所有实现都必须支持列出的所有请求方法。
If a SIP element receives the 'Resource-Priority' header field in a request other than those listed above, the header MAY be ignored, according to the rules of [RFC3261].
根据[RFC3261]的规则，如果SIP元素在上述请求以外的请求中接收到“资源优先级”报头字段，则可以忽略该报头。
In short, an RP actor performs the following steps when receiving a prioritized request. Error behavior is described in Section 4.6.
简言之，RP参与者在接收优先请求时执行以下步骤。第4.6节描述了错误行为。
1. If the RP actor recognizes none of the name spaces, it treats the request as if it had no 'Resource-Priority' header field.
1. 如果RP参与者不识别任何名称空间，则会将请求视为没有“Resource Priority”头字段。
2. It ascertains that the request is authorized according to local policy to use the priority levels indicated. If the request is not authorized, it rejects it. Examples of authorization policies are discussed in Security Considerations (Section 11).
2. 它确定根据本地策略授权请求使用指定的优先级。如果请求未经授权，它将拒绝该请求。授权策略的示例在安全注意事项（第11节）中讨论。
3. If the request is authorized and resources are available (no congestion), it serves the request as usual. If the request is authorized but resources are not available (congestion), it either preempts other current sessions or inserts the request into a priority queue, as described in Section 4.5.
3. 如果请求已授权且资源可用（无拥塞），它将照常处理请求。如果请求已授权，但资源不可用（拥塞），则会抢占其他当前会话或将请求插入优先级队列，如第4.5节所述。
Following standard SIP behavior, if a SIP request contains the 'Require' header field with the 'resource-priority' option tag, a SIP user agent MUST respond with a 420 (Bad Extension) if it does not support the SIP extensions described in this document. It then lists "resource-priority" in the 'Unsupported' header field included in the response.
按照标准SIP行为，如果SIP请求包含带有“资源优先级”选项标记的“Require”头字段，SIP用户代理必须使用420（坏扩展）响应，如果它不支持本文档中描述的SIP扩展。然后，它在响应中包含的“Unsupported”头字段中列出“resource priority”。
The use of the 'resource-priority' option tag in 'Proxy-Require' header field is NOT RECOMMENDED.
不建议在“代理要求”标题字段中使用“资源优先级”选项标记。
An OPTIONS request can be used to determine if an element supports the mechanism. A compliant implementation SHOULD return an 'Accept-Resource-Priority' header field in OPTIONS responses enumerating all valid resource values, but an RP actor MAY be configured not to return such values or only to return them to authorized requestors.
选项请求可用于确定元素是否支持该机制。兼容实现应在选项响应中返回“Accept Resource Priority”（接受资源优先级）头字段，列举所有有效资源值，但RP参与者可能被配置为不返回此类值或仅将其返回给授权请求者。
Following standard SIP behavior, OPTIONS responses MUST include the 'Supported' header field that includes the 'resource-priority' option tag.
按照标准SIP行为，选项响应必须包含包含“资源优先级”选项标记的“受支持”标题字段。
According to RFC 3261, Section 11, proxies that receive a request with a 'Max-Forwards' header field value of zero MAY answer the OPTIONS request, allowing a UAC to discover the capabilities of both proxy and user agent servers.
根据RFC 3261第11节，接收“Max Forwards”头字段值为零的请求的代理可以响应选项请求，从而允许UAC发现代理服务器和用户代理服务器的功能。
SIP elements may use the resource priority mechanism to modify a variety of behaviors, such as routing requests, authentication requirements, override of network capacity controls, or logging. The resource priority mechanism may influence the treatment of the request itself, the marking of outbound PSTN calls at a gateway, or of the session created by the request. (Here, we use the terms session and call interchangeably, both implying a continuous data stream between two or more parties. Sessions are established by SIP dialogs.)
SIP元素可以使用资源优先级机制来修改各种行为，例如路由请求、身份验证要求、覆盖网络容量控制或日志记录。资源优先级机制可能会影响对请求本身的处理、在网关上标记出站PSTN呼叫或由请求创建的会话。（这里，我们交替使用术语session和call，两者都意味着两方或多方之间的连续数据流。session由SIP对话框建立。）
Below, we define two common algorithms, namely, preemption and priority queueing. Preemption applies only to sessions created by SIP requests, while both sessions and request handling can be subject to priority queueing. Both algorithms can sometimes be combined in the same element, although none of the namespaces described in this document do this. Algorithms can be defined for each namespace or, in some cases, can be specific to an administrative domain. Other behavior, such as request routing or network management controls, is not defined by this specification.
下面，我们定义了两种常见的算法，即抢占和优先级排队。抢占仅适用于由SIP请求创建的会话，而会话和请求处理都可能受到优先级排队的影响。这两种算法有时可以组合在同一个元素中，尽管本文档中描述的名称空间都不能这样做。可以为每个命名空间定义算法，或者在某些情况下，可以特定于管理域。本规范未定义其他行为，如请求路由或网络管理控制。
Naturally, only SIP elements that understand this mechanism and the namespace and resource value perform these algorithms. Section 4.6.2 discusses what happens if an RP actor does not understand priority values contained in a request.
当然，只有理解这种机制以及名称空间和资源值的SIP元素才能执行这些算法。第4.6.2节讨论了如果RP参与者不理解请求中包含的优先级值会发生什么情况。
An RP actor following a preemption policy may disrupt an existing session to make room for a higher-priority incoming session. Since sessions may require different amounts of bandwidth or a different number of circuits, a single higher-priority session may displace more than one lower-priority session. Unless otherwise noted, requests do not preempt other requests of equal priority. As noted above, the processing of SIP requests itself is not preempted. Thus, since proxies do not manage sessions, they do not perform preemption.
遵循抢占策略的RP参与者可能会中断现有会话，为更高优先级的传入会话腾出空间。由于会话可能需要不同数量的带宽或不同数量的电路，单个高优先级会话可能会取代多个低优先级会话。除非另有说明，否则请求不会优先于具有同等优先级的其他请求。如上所述，SIP请求本身的处理不会被抢占。因此，由于代理不管理会话，因此它们不执行抢占。
[RFC4411] contains more details and examples of this behavior.
[RFC4411]包含此行为的更多详细信息和示例。
UAS behavior for preemption is discussed in Section 4.7.2.1.
第4.7.2.1节讨论了UAS抢占行为。
In a priority queueing policy, requests that find no available resources are queued to the queue assigned to the priority value. Unless otherwise specified, requests are queued in first-come, first-served order. Each priority value may have its own queue, or several priority values may share a single queue. If a resource becomes available, the RP actor selects the request from the highest-priority non-empty queue according to the queue service policy. For first-come, first-served policies, the request from that queue that has been waiting the longest is served. Each queue can hold a finite number of pending requests. If the per-priority-value queue for a newly arriving request is full, the request is rejected immediately, with the status codes specified in Section 4.6.5 and Section 4.6.6. In addition, a priority queueing policy MAY impose a waiting time limit for each priority class, whereby requests that exceed a specified waiting time are ejected from the queue and a 408 (Request Timeout) failure response is returned to the requestor.
在优先级排队策略中，找不到可用资源的请求将排队到分配给优先级值的队列。除非另有规定，否则请求将按先到先得的顺序排队。每个优先级值可以有自己的队列，或者多个优先级值可以共享一个队列。如果资源可用，RP参与者将根据队列服务策略从最高优先级的非空队列中选择请求。对于先到先服务的策略，来自等待时间最长的队列的请求将得到服务。每个队列可以容纳有限数量的挂起请求。如果新到达请求的每个优先级值队列已满，则该请求立即被拒绝，状态代码见第4.6.5节和第4.6.6节。此外，优先级排队策略可以对每个优先级类别施加等待时间限制，由此，超过指定等待时间的请求从队列中弹出，并且408（请求超时）失败响应返回给请求者。
Finally, an RP actor MAY impose a global queue size limit summed across all queues and drop waiting lower-priority requests with a 408 (Request Timeout) failure response. This does not imply preemption, since the session has not been established yet.
最后，RP参与者可以施加在所有队列上求和的全局队列大小限制，并使用408（请求超时）故障响应丢弃等待的低优先级请求。这并不意味着抢占，因为会话尚未建立。
UAS behavior for queueing is discussed in Section 4.7.2.2.
第4.7.2.2节讨论了排队的UAS行为。
In this section, we describe the error behavior that is shared among multiple types of RP actors (including various instances of UAS such as trunk gateways, line gateways, and IP phones) and proxies.
在本节中，我们将描述多种类型的RP参与者（包括各种UAS实例，如中继网关、线路网关和IP电话）和代理之间共享的错误行为。
A request containing a resource priority indication can fail for four reasons:
包含资源优先级指示的请求可能会失败，原因有四：
o the RP actor does not understand the priority value (Section 4.6.2),
o RP参与者不了解优先级值（第4.6.2节），
o the requestor is not authenticated (Section 4.6.3),
o 请求人未经认证（第4.6.3节），
o an authenticated requestor is not authorized to make such a request (Section 4.6.4), or
o 经认证的请求人无权提出此类请求（第4.6.4节），或
o there are insufficient resources for an authorized request (Section 4.6.5).
o 资源不足，无法满足授权请求（第4.6.5节）。
We treat these error cases in the order that they typically arise in the processing of requests with Resource-Priority headers. However, this order is not mandated. For example, an RP actor that knows that a particular resource value cannot be served or queued MAY, as a matter of local policy, forgo authorization, since it would only add processing load without changing the outcome.
我们按照处理具有资源优先级头的请求时通常出现的顺序来处理这些错误情况。然而，这项命令不是强制性的。例如，知道特定资源值不能被服务或排队的RP参与者可以根据本地策略放弃授权，因为它只会增加处理负载而不会改变结果。
If an RP actor does not understand any of the resource values in the request, the treatment depends on the presence of the 'Require' 'resource-priority' option tag:
如果RP参与者不理解请求中的任何资源值，则处理取决于是否存在“Require”“resource priority”选项标记：
1. Without the option tag, the RP actor treats the request as if it contained no 'Resource-Priority' header field and processes it with default priority. Resource values that are not understood MUST NOT be modified or deleted.
1. 如果没有选项标记，RP参与者将请求视为不包含“Resource Priority”头字段，并使用默认优先级处理它。不能修改或删除未理解的资源值。
2. With the option tag, it MUST reject the request with a 417 (Unknown Resource-Priority) response code.
2. 对于选项标记，它必须使用417（未知资源优先级）响应代码拒绝请求。
Making case (1) the default is necessary since otherwise there would be no way to successfully complete any calls in the case where a proxy on the way to the UAS shares no common namespaces with the UAC, but the UAC and UAS do have such a namespace in common.
将case（1）设为默认值是必要的，因为如果前往UAS的代理与UAC不共享公共名称空间，但UAC和UAS确实具有相同的名称空间，则无法成功完成任何调用。
In general, as noted, a SIP request can contain more than one 'Resource-Priority' header field. This is necessary if a request needs to traverse different administrative domains, each with its own set of valid resource values. For example, the ETS namespace might be enabled for United States government networks that also support the DSN and/or DRSN namespaces for most individuals in those domains.
通常，如前所述，SIP请求可以包含多个“资源优先级”头字段。如果请求需要遍历不同的管理域，每个域都有自己的一组有效资源值，那么这是必需的。例如，美国政府网络可能启用ETS名称空间，这些网络也支持这些域中大多数个人的DSN和/或DRSN名称空间。
A 417 (Unknown Resource-Priority) response MAY, according to local policy, include an 'Accept-Resource-Priority' header field enumerating the acceptable resource values.
根据本地策略，417（未知资源优先级）响应可以包括枚举可接受资源值的“接受资源优先级”报头字段。
If the request is not authenticated, a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is returned in order to allow the requestor to insert appropriate credentials.
如果请求未经身份验证，将返回401（未经授权）或407（需要代理身份验证）响应，以允许请求者插入适当的凭据。
If the RP actor receives an authenticated request with a namespace and priority value it recognizes but the originator is not authorized for that level of service, the element MUST return a 403 (Forbidden) response.
如果RP参与者接收到具有其识别的名称空间和优先级值的经过身份验证的请求，但发起人未获得该服务级别的授权，则元素必须返回403（禁止）响应。
Insufficient resource conditions can occur on proxy servers and user agent servers, typically trunk gateways, if an RP actor receives an authorized request, has insufficient resources, and the request neither preempts another session nor is queued. A request can fail because the RP actor has either insufficient processing capacity to handle the SIP request or insufficient bandwidth or trunk capacity to establish the requested session for session-creating SIP requests.
如果RP参与者收到授权请求，且资源不足，且请求既不抢占另一个会话，也不排队，则代理服务器和用户代理服务器（通常为中继网关）上可能会出现资源不足的情况。请求可能会失败，因为RP参与者的处理能力不足，无法处理SIP请求，或者带宽或中继容量不足，无法为会话创建SIP请求建立请求的会话。
If the request fails because the RP actor cannot handle the signaling load, the RP actor responds with 503 (Service Unavailable).
如果请求失败是因为RP-actor无法处理信令负载，则RP-actor响应503（服务不可用）。
If there is not enough bandwidth, or if there is an insufficient number of trunks, a 488 (Not Acceptable Here) response indicates that the RP actor is rejecting the request due to media path availability, such as insufficient gateway resources. In that case, [RFC3261] advises that a 488 response SHOULD include a 'Warning' header field with a reason for the rejection; warning code 370 (Insufficient Bandwidth) is typical.
如果带宽不足，或者中继数量不足，则488（此处不可接受）响应表示RP参与者由于媒体路径可用性（例如网关资源不足）而拒绝请求。在这种情况下，[RFC3261]建议488响应应包括带有拒绝原因的“警告”标题字段；警告代码370（带宽不足）是典型的。
For systems implementing queueing, if the request is queued, the UAS will return 408 (Request Timeout) if the request exceeds the maximum configured waiting time in the queue.
对于实现排队的系统，如果请求已排队，则如果请求超过队列中配置的最大等待时间，UAS将返回408（请求超时）。
Resource contention also occurs when a call request arrives at a UAS that is unable to accept another call, because the UAS either has just one line appearance or has active calls on all line appearances. If the call request indicates an equal or lower priority value when compared to all active calls present on the UAS, the UAS returns a 486 (Busy here) response.
当呼叫请求到达无法接受另一个呼叫的UAS时，也会发生资源争用，因为UAS要么只有一个线路外观，要么在所有线路外观上都有活动呼叫。如果与UAS上存在的所有活动呼叫相比，呼叫请求指示相等或更低的优先级值，则UAS返回486（此处忙）响应。
If the request is queued instead, the UAS will return a 408 (Request Timeout) if the request exceeds the maximum configured waiting time in the device queue.
如果请求排队，则如果请求超过设备队列中配置的最大等待时间，UAS将返回408（请求超时）。
If a proxy gets 486 (Busy Here) responses on all branches, it can then return a 600 (Busy Everywhere) response to the caller.
如果代理在所有分支上都得到486（此处忙）响应，那么它可以向调用者返回600（处处忙）响应。
SIP UACs supporting this specification MUST be able to generate the 'Resource-Priority' header field for requests that require elevated resource access priority. As stated previously, the UAC SHOULD be able to generate more than one resource value in a single SIP request.
支持此规范的SIP UAC必须能够为需要提升资源访问优先级的请求生成“资源优先级”头字段。如前所述，UAC应该能够在单个SIP请求中生成多个资源值。
Upon receiving a 417 (Unknown Resource-Priority) response, the UAC MAY attempt a subsequent request with the same or different resource value. If available, it SHOULD choose authorized resource values from the set of values returned in the 'Accept-Resource-Priority' header field.
在接收到417（未知资源优先级）响应时，UAC可尝试具有相同或不同资源值的后续请求。如果可用，它应该从“接受资源优先级”标题字段中返回的一组值中选择授权资源值。
A UAC that requests a priority value that may cause preemption MUST understand a Reason header field in the BYE request explaining why the session was terminated, as discussed in [RFC4411].
请求可能导致抢占的优先级值的UAC必须理解BYE请求中解释会话终止原因的原因标头字段，如[RFC4411]中所述。
By standard SIP protocol rules, a UAC MUST be prepared to receive a 182 (Queued) response from an RP actor that is currently at capacity, but that has put the original request into a queue. A UAC MAY indicate this queued status to the user by some audio or visual indication to prevent the user from interpreting the call as having failed.
根据标准SIP协议规则，UAC必须准备好接收来自RP参与者的182（排队）响应，该RP参与者当前已满负荷，但已将原始请求放入队列。UAC可以通过某种音频或视频指示向用户指示该排队状态，以防止用户将呼叫解释为失败。
The precise effect of the 'Resource-Priority' indication depends on the type of UAS, the namespace, and local policy.
“资源优先级”指示的确切效果取决于UAS的类型、命名空间和本地策略。
A UAS compliant with this specification MUST terminate a session established with a valid namespace and lower-priority value in favor of a new session set up with a valid namespace and higher relative priority value, unless local policy has some form of call-waiting capability enabled. If a session is terminated, the BYE method is used with a 'Reason' header field indicating why and where the preemption took place.
符合此规范的UAS必须终止使用有效命名空间和较低优先级值建立的会话，以支持使用有效命名空间和较高相对优先级值建立的新会话，除非本地策略启用了某种形式的呼叫等待功能。如果会话终止，则使用BYE方法和“Reason”头字段，指示抢占发生的原因和位置。
Implementors have a number of choices in how to implement preemption at IP phones with multiple line presences, i.e., with devices that
在如何在具有多条线路存在的IP电话上实现抢占方面，实现者有很多选择，例如，使用
can handle multiple simultaneous sessions. Naturally, if that device has exhausted the number of simultaneous sessions, one of the sessions needs to be replaced. If the device has spare sessions, an implementation MAY choose to alert the callee to the arrival of a higher-priority call. Details may also be set by local or namespace policy.
可以同时处理多个会话。当然，如果该设备耗尽了同时会话的数量，则需要更换其中一个会话。如果设备具有备用会话，则实现可以选择在较高优先级呼叫到达时提醒被叫方。详细信息也可以由本地或命名空间策略设置。
[RFC4411] provides additional information in the case of purposeful or administrative termination of a session by including the Reason header in the BYE message that states why the BYE was sent (in this case, a preemption event). The mechanisms in that document allow indication of where the termination occurred ('at the UA', 'within a reservation', 'at a IP/PSTN gateway') and include call flow examples of each reason.
[RFC4411]通过在BYE消息中包含原因头，说明发送BYE的原因（在本例中为抢占事件），提供会话有意或管理性终止情况下的附加信息。该文件中的机制允许指示终止发生的位置（“在UA”、“在预订内”、“在IP/PSTN网关”），并包括每个原因的呼叫流示例。
A UAS compliant with this specification SHOULD generate a 182 (Queued) response if that element's resources are busy, until it is able to handle the request and provide a final response. The frequency of such provisional messages is governed by [RFC3261].
如果元素的资源繁忙，则符合此规范的UAS应生成182（排队）响应，直到它能够处理请求并提供最终响应为止。此类临时消息的频率由[RFC3261]控制。
SIP proxies MAY ignore the 'Resource-Priority' header field. SIP proxies MAY reject any unauthenticated request bearing that header field.
SIP代理可以忽略“资源优先级”头字段。SIP代理可以拒绝包含该头字段的任何未经验证的请求。
When the 'Require' header field is included in a message, it ensures that in parallel forking, only branches that support the resource-priority mechanism succeed.
当“Require”头字段包含在消息中时，它确保在并行分叉中，只有支持资源优先级机制的分支成功。
If S/MIME encapsulation is used according to Section 23 of RFC 3261, special considerations apply. As tabulated in Section 3.3, the 'Resource-Priority' header field can be modified by proxies and thus is exempted from the integrity checking described in Section 23.4.1.1 of RFC 3261. Since it may need to be inspected or modified by proxies, the header field MUST also be placed in the "outer" message if the UAC would like proxy servers to be able to act on the header information. Similar considerations apply if parts of the message are integrity protected or encrypted as described in [RFC3420].
如果根据RFC 3261第23节使用S/MIME封装，则需要特别考虑。如第3.3节中的表格所示，“资源优先级”标题字段可由代理修改，因此不必进行RFC 3261第23.4.1.1节中所述的完整性检查。由于可能需要代理对其进行检查或修改，因此如果UAC希望代理服务器能够对头信息进行操作，则头字段也必须放在“外部”消息中。如果消息的某些部分如[RFC3420]中所述受到完整性保护或加密，则应考虑类似的因素。
If S/MIME is not used, or if the 'Resource-Priority' header field is in the "outer" header, SIP proxies MAY downgrade or upgrade the 'Resource-Priority' of a request or insert a new 'Resource-Priority' header if allowed by local policy.
如果未使用S/MIME，或者“资源优先级”标头字段位于“外部”标头中，SIP代理可以降级或升级请求的“资源优先级”，或者在本地策略允许的情况下插入新的“资源优先级”标头。
If a stateful proxy has authorized a particular resource priority level, and if it offers differentiated treatment to responses containing resource priority levels, the proxy SHOULD ignore any higher value contained in responses, to prevent colluding user agents from artificially raising the priority level.
如果有状态代理已授权特定的资源优先级，并且如果它对包含资源优先级的响应提供区别对待，则代理应忽略响应中包含的任何较高值，以防止串通用户代理人为提高优先级。
A SIP proxy MAY use the 'Resource-Priority' indication in its routing decisions, e.g., to retarget to a SIP node or SIP URI that is reserved for a particular resource priority.
SIP代理可以在其路由决策中使用“资源优先级”指示，例如，重新定位到为特定资源优先级保留的SIP节点或SIP URI。
There are no special considerations for proxies when forking requests containing a resource priority indication.
当分叉包含资源优先级指示的请求时，代理没有特殊的注意事项。
Otherwise, the proxy behavior is the same as for user agent servers described in Section 4.7.2.
否则，代理行为与第4.7.2节中描述的用户代理服务器相同。
In some cases, the RP actor may not be able to authenticate the requestor or determine whether an authenticated user is authorized to make such a request. In these circumstances, the SIP entity may avail itself of general SIP mechanisms that are not specific to this application. The authenticated identity management mechanism [RFC3893] allows a third party to verify the identity of the requestor and to certify this towards an RP actor. In networks with mutual trust, the SIP-asserted identity mechanism [RFC3325] can help the RP actor determine the identity of the requestor.
在某些情况下，RP参与者可能无法对请求者进行身份验证，或者无法确定经过身份验证的用户是否有权发出此类请求。在这些情况下，SIP实体可以利用不特定于该应用的一般SIP机制。认证身份管理机制[RFC3893]允许第三方验证请求者的身份，并向RP参与者证明这一点。在相互信任的网络中，SIP断言身份机制[RFC3325]可以帮助RP参与者确定请求者的身份。
The resource priority mechanism described in this document is fully backwards compatible with SIP systems following [RFC3261]. Systems that do not understand the mechanism can only deliver standard, not elevated, service priority. User agent servers and proxies can ignore any 'Resource-Priority' header field just like any other unknown header field and then treat the request like any other request. Naturally, the request may still succeed.
本文档中描述的资源优先级机制与[RFC3261]之后的SIP系统完全向后兼容。不了解该机制的系统只能提供标准而不是提升的服务优先级。用户代理服务器和代理可以像任何其他未知头字段一样忽略任何“资源优先级”头字段，然后像处理任何其他请求一样处理该请求。当然，这个请求可能仍然会成功。
The SDP message body and the BYE and ACK exchanges are the same as in RFC 3665 [RFC3665] and are omitted for brevity.
SDP消息正文以及BYE和ACK交换与RFC 3665[RFC3665]中的相同，为简洁起见，省略了这些内容。
User A User B
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |
User A User B
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |
In this scenario, User A completes a call to User B directly. The call from A to B is marked with a resource priority indication.
在此场景中，用户A直接完成对用户B的调用。从A到B的呼叫标有资源优先级指示。
F1 INVITE User A -> User B
F1邀请用户A->用户B
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...
...
F2 180 Ringing User B -> User A
F2 180振铃用户B->用户A
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Length: 0
F3 200 OK User B -> User A
F3 200正常用户B->用户A
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...
...
In this example, the receiving UA does not understand the "dsn" namespace and thus returns a 417 (Unknown Resource-Priority) status code. We omit the message details for messages F5 through F7, since they are essentially the same as in the first example.
在此示例中，接收UA不理解“dsn”命名空间，因此返回417（未知资源优先级）状态代码。我们省略了消息F5到F7的消息细节，因为它们基本上与第一个示例中的相同。
User A User B
| |
| INVITE F1 |
|----------------------->|
| 417 R-P failed F2 |
|<-----------------------|
| ACK F3 |
|----------------------->|
| |
| INVITE F4 |
|----------------------->|
| 180 Ringing F5 |
|<-----------------------|
| 200 OK F6 |
|<-----------------------|
| ACK F7 |
|----------------------->|
| |
| Both Way RTP Media |
|<======================>|
User A User B
| |
| INVITE F1 |
|----------------------->|
| 417 R-P failed F2 |
|<-----------------------|
| ACK F3 |
|----------------------->|
| |
| INVITE F4 |
|----------------------->|
| 180 Ringing F5 |
|<-----------------------|
| 200 OK F6 |
|<-----------------------|
| ACK F7 |
|----------------------->|
| |
| Both Way RTP Media |
|<======================>|
F1 INVITE User A -> User B
F1邀请用户A->用户B
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Require: resource-priority
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Require: resource-priority
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
Content-Type: application/sdp
Content-Length: ...
...
...
F2 417 Resource-Priority failed User B -> User A
F2 417资源优先级失败用户B->用户A
SIP/2.0 417 Unknown Resource-Priority
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 0
SIP/2.0 417 Unknown Resource-Priority
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 0
F3 ACK User A -> User B
F3确认用户A->用户B
ACK sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
ACK sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
F4 INVITE User A -> User B
F4邀请用户A->用户B
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Require: resource-priority
Resource-Priority: q735.3
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Require: resource-priority
Resource-Priority: q735.3
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...
Content-Type: application/sdp
Content-Length: ...
...
A single SIP request MAY contain resource values from multiple namespaces. As noted earlier, an RP actor disregards all namespaces it does not recognize. This specification only addresses the case where an RP actor then selects one of the remaining resource values for processing, usually choosing the one with the highest relative priority.
一个SIP资源请求可能包含多个名称空间的值。如前所述，RP参与者忽略它不识别的所有名称空间。本规范仅解决RP参与者随后选择剩余资源值之一进行处理的情况，通常选择具有最高相对优先级的资源值。
If an RP actor understands multiple namespaces, it MUST create a local total ordering across all resource values from these namespaces, maintaining the relative ordering within each namespace. It is RECOMMENDED that the same ordering be used across an administrative domain. However, there is no requirement that such ordering be the same across all administrative domains.
如果RP参与者理解多个名称空间，那么它必须跨这些名称空间中的所有资源值创建一个本地总排序，并在每个名称空间中保持相对排序。建议在管理域中使用相同的排序。但是，不要求所有管理域的排序都相同。
Below are a set of examples of an RP actor that supports two namespaces, foo and bar. Foo's priority-values are 3 (highest), then 2, and then 1 (lowest), and bar's priority-values are C (highest), then B, and then A (lowest).
下面是一组支持两个名称空间foo和bar的RP-actor示例。Foo的优先级值是3（最高），然后是2，然后是1（最低），bar的优先级值是C（最高），然后是B，然后是A（最低）。
Below are five lists of acceptable priority orders the SIP element may use:
以下是SIP要素可能使用的可接受优先级顺序的五个列表：
Foo.3 Foo.3 Bar.C (highest priority) Foo.2 Bar.C Foo.3 Foo.1 or Foo.2 or Foo.2 Bar.C Bar.B Foo.1 Bar.B Foo.1 Bar.B Bar.A Bar.A Bar.A (lowest priority)
Foo.3 Foo.3 Bar.C（最高优先级）Foo.2 Bar.C Foo.3 Foo.1或Foo.2或Foo.2 Bar.C Bar.B Foo.1 Bar.B Foo.1 Bar.B Bar.A Bar.A Bar.A（最低优先级）
Bar.C (highest priority) Foo.3 Bar.B (both treated with equal priority (FIFO)) or Foo.2 Bar.A (both treated with equal priority (FIFO)) Foo.1 (lowest priority)
C小节（最高优先级）Foo.3小节B小节（均采用同等优先级（FIFO））或Foo.2小节A小节（均采用同等优先级（FIFO））Foo.1小节（最低优先级）
Bar.C (highest priority) Foo.3 or Foo.2 Foo.1 (lowest priority)
Bar.C（最高优先级）Foo.3或Foo.2 Foo.1（最低优先级）
In the last example above, Bar.A and Bar.B are ignored.
在上面的最后一个示例中，Bar.A和Bar.B被忽略。
Based on the priority order of the namespaces above, the following combinations are examples of orderings that are NOT acceptable and MUST NOT be configurable:
根据上述名称空间的优先级顺序，以下组合是不可接受且不可配置的排序示例：
Example 1 Example 2 Example 3
--------- --------- ---------
Foo.3 Foo.3 Bar.C
Foo.2 Bar.A Foo.1
Foo.1 or Foo.2 or Foo.3
Bar.C Bar.B Foo.2
Bar.A Foo.1 Bar.A
Bar.B Bar.C Bar.B
Example 1 Example 2 Example 3
--------- --------- ---------
Foo.3 Foo.3 Bar.C
Foo.2 Bar.A Foo.1
Foo.1 or Foo.2 or Foo.3
Bar.C Bar.B Foo.2
Bar.A Foo.1 Bar.A
Bar.B Bar.C Bar.B
Example 4
---------
Bar.C
Foo.1 Bar.B
or Foo.3 Bar.A
Foo.2
Example 4
---------
Bar.C
Foo.1 Bar.B
or Foo.3 Bar.A
Foo.2
These examples are invalid since the following global orderings are not consistent with the namespace-internal order:
这些示例无效，因为以下全局顺序与命名空间内部顺序不一致：
o In Example 1, Bar.A is ordered higher than Bar.B.
o 在示例1中，Bar.A的顺序高于Bar.B。
o In Example 2, Bar.A is ordered higher than Bar.B and Bar.C.
o 在示例2中，Bar.A的顺序高于Bar.B和Bar.C。
o In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3.
o 在示例3中，Foo.1的顺序高于Foo.2和Foo.3。
o In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2.
o 在示例4中，Foo.1的顺序高于Foo.3和Foo.2。
Organizations considering the use of the Resource-Priority header field should investigate whether an existing combination of namespace and priority-values meets their needs. For example, emergency first responders around the world are discussing utilizing this mechanism for preferential treatment in future networks. Jurisdictions SHOULD attempt to reuse existing IANA registered namespaces where possible, as a goal of this document is not to have unique namespaces per jurisdiction serving the same purpose, with the same usage of priority levels. This will greatly increase interoperability and reduce development time, and probably reduce future confusion if there is ever a need to map one namespace to another in an interworking function.
考虑使用Resource Priority header字段的组织应调查名称空间和优先级值的现有组合是否满足其需要。例如，世界各地的应急第一响应者正在讨论在未来的网络中利用这一机制提供优惠待遇。辖区应尽可能重复使用现有的IANA注册名称空间，因为本文档的目标不是每个辖区都有唯一的名称空间，用于相同的目的，并使用相同的优先级。这将大大提高互操作性并缩短开发时间，如果需要在交互功能中将一个名称空间映射到另一个名称空间，则可能会减少将来的混淆。
Below, we describe the steps necessary to register a new namespace.
下面，我们描述注册新名称空间所需的步骤。
A new namespace MUST be defined in a Standards Track RFC, following the 'Standards Action' policy in [RFC2434], and MUST include the following facets:
新名称空间必须按照[RFC2434]中的“标准操作”策略在标准跟踪RFC中定义，并且必须包括以下方面：
o It must define the namespace label, a unique namespace label within the IANA registry for the SIP Resource-Priority header field.
o 它必须定义名称空间标签，这是IANA注册表中SIP资源优先级头字段的唯一名称空间标签。
o It must enumerate the priority levels (i.e., 'r-priority' values) the namespace is using. Note that only finite lists are permissible, not unconstrained integers or tokens, for example.
o 它必须枚举名称空间正在使用的优先级（即“r-priority”值）。请注意，仅允许使用有限列表，例如，不允许使用无约束整数或标记。
o The priority algorithm (Section 4.5), identifying whether the namespace is to be used with priority queueing ("queue") or preemption ("preemption"). If queueing is used, the namespace MAY indicate whether normal-priority requests are queued. If there is a new "intended algorithm" other than preemption or priority queueing, the algorithm must be described, taking into account all RP actors (UAC, UAS, proxies).
o 优先级算法（第4.5节），确定命名空间是与优先级排队（“队列”）还是抢占（“抢占”）一起使用。如果使用排队，则名称空间可能指示正常优先级请求是否排队。如果存在抢占或优先级排队以外的新“预期算法”，则必须描述该算法，并考虑所有RP参与者（UAC、UAS、代理）。
o A namespace may either reference an existing list of priority values or define a new finite list of priority values in relative priority order for IANA registration within the sip-parameters Resource-Priority priority-values registry. New priority-values SHOULD NOT be added to a previously IANA-registered list associated with a particular namespace, as this may cause interoperability problems. Unless otherwise specified, it is assumed that all priority values confer higher priority than requests without a priority value.
o 命名空间可以引用现有优先级值列表，也可以在sip参数资源优先级值注册表中为IANA注册以相对优先级顺序定义新的有限优先级值列表。不应将新的优先级值添加到以前与特定命名空间关联的IANA注册列表中，因为这可能会导致互操作性问题。除非另有规定，否则假定所有优先级值都赋予比没有优先级值的请求更高的优先级。
o Any new SIP response codes unique to this new namespace need to be explained and registered.
o 需要解释和注册此新名称空间特有的任何新SIP响应代码。
o The reference document must specify and describe any new Warning header field warn-codes (RFC 3261, Section 27.2).
o 参考文件必须规定和描述任何新的警告标题字段警告代码（RFC 3261，第27.2节）。
o The document needs to specify a new row for the following table that summarizes the features of the namespace and is included into IANA Resource-Priority Namespace registration:
o 文档需要为下表指定一个新行，该表总结了命名空间的功能，并包含在IANA资源优先级命名空间注册中：
Intended New New resp.
Namespace Levels algorithm warn-code code Reference
--------- ------ ---------------- --------- -------- ---------
<label> <# of <preemption <new warn <new resp. <RFC>
levels> or queue> code> code>
Intended New New resp.
Namespace Levels algorithm warn-code code Reference
--------- ------ ---------------- --------- -------- ---------
<label> <# of <preemption <new warn <new resp. <RFC>
levels> or queue> code> code>
If information on new response codes, rejection codes, or error behaviors is omitted, it is to be assumed that the namespace defines no new parameters or behaviors.
如果省略了有关新响应代码、拒绝代码或错误行为的信息，则假定命名空间未定义新参数或行为。
This specification defines five unique namespaces below: DSN, DRSN, Q735, ETS, and WPS, constituting their registration with IANA. Each IANA registration contains the facets defined in Section 9. For recognizability, we label the namespaces in capital letters, but note that namespace names are case insensitive and are customarily rendered as lowercase in protocol requests.
本规范定义了以下五个唯一的名称空间：DSN、DRSN、Q735、ETS和WPS，它们构成了IANA的注册。每个IANA注册都包含第9节中定义的方面。为了便于识别，我们用大写字母标记名称空间，但请注意名称空间名称不区分大小写，并且在协议请求中通常呈现为小写。
The DSN namespace comes from the name of a US government network called "The Defense Switched Network".
DSN名称空间来自一个名为“国防交换网络”的美国政府网络的名称。
The DSN namespace has a finite list of relative priority-values, listed below from lowest priority to highest priority:
从下面列出的有限优先级列表中，从DSN到DSN的最低优先级值为相对优先级：
(lowest) dsn.routine dsn.priority dsn.immediate dsn.flash (highest) dsn.flash-override
（最低）dsn.例行dsn.优先级dsn.立即dsn.闪存（最高）dsn.闪存覆盖
The DSN namespace uses the preemption algorithm (Section 4.5.1).
DSN名称空间使用抢占算法（第4.5.1节）。
The DRSN namespace comes from the name of a US government network, called "The Defense RED Switched Network".
DRSN名称空间来自美国政府网络的名称，称为“国防红色交换网络”。
The DRSN namespace defines the following resource values, listed from lowest priority to highest priority:
DRSN命名空间定义以下资源值，从最低优先级到最高优先级列出：
(lowest) drsn.routine drsn.priority drsn.immediate drsn.flash drsn.flash-override (highest) drsn.flash-override-override
（最低）drsn.常规drsn.优先级drsn.立即drsn.闪烁drsn.闪烁覆盖（最高）drsn.闪烁覆盖
The DRSN namespace uses the preemption algorithm (Section 4.5.1).
DRSN名称空间使用抢占算法（第4.5.1节）。
The DRSN namespace differs in one algorithmic aspect from the DSN and Q735 namespaces. The behavior for the 'flash-override-override' priority value differs from the other values. Normally, requests do not preempt those of equal priority, but a newly arriving 'flash-override-override' request will displace another one of equal priority if there are insufficient resources. This can also be expressed as saying that 'flash-override-override' requests defend themselves as 'flash-override' only.
DRSN名称空间在一个算法方面与DSN和Q735名称空间不同。“闪存覆盖”优先级值的行为与其他值不同。通常，请求不会抢占同等优先级的请求，但如果资源不足，新到达的“闪存覆盖”请求将替换另一个同等优先级的请求。这也可以表示为“闪存覆盖”请求仅为“闪存覆盖”辩护。
Q.735.3 [Q.735.3] was created to be a commercial version of the operationally equivalent DSN specification for Multi-Level Precedence and Preemption (MLPP). The Q735 namespace is defined here in the same manner.
Q.735.3[Q.735.3]被创建为多级优先和抢占（MLPP）操作等效DSN规范的商业版本。Q735名称空间在这里以相同的方式定义。
The Q735 namespace defines the following resource values, listed from lowest priority to highest priority:
Q735命名空间定义以下资源值，从最低优先级到最高优先级列出：
(lowest) q735.4 q735.3 q735.2 q735.1 (highest) q735.0
（最低）q735.4 q735.3 q735.2 q735.1（最高）q735.0
The Q735 namespace operates according to the preemption (Section 4.5.1) algorithm.
Q735命名空间根据抢占（第4.5.1节）算法运行。
The ETS namespace derives its name indirectly from the name of the US government telecommunications service, called "Government Emergency Telecommunications Service" (or GETS), though the organization responsible for the GETS service chose the acronym "ETS" for its GETS over IP service, which stands for "Emergency Telecommunications Service".
ETS名称空间间接源于美国政府电信服务的名称，称为“政府紧急电信服务”（GETS），尽管负责GETS服务的组织为其GETS over IP服务选择了首字母缩写“ETS”，即“紧急电信服务”。
The ETS namespace defines the following resource values, listed from lowest priority to highest priority:
ETS命名空间定义以下资源值，从最低优先级到最高优先级列出：
(lowest) ets.4 ets.3 ets.2 ets.1 (highest) ets.0
（最低）ets.4 ets.3 ets.2 ets.1（最高）ets.0
The ETS namespace operates according to the priority queueing algorithm (Section 4.5.2).
ETS命名空间根据优先级排队算法（第4.5.2节）运行。
The WPS namespace derives its name from the "Wireless Priority Service", defined in GSM and other wireless technologies.
WPS名称空间源于GSM和其他无线技术中定义的“无线优先服务”。
The WPS namespace defines the following resource values, listed from lowest priority to highest priority:
WPS命名空间定义以下资源值，从最低优先级到最高优先级列出：
(lowest) wps.4 wps.3 wps.2 wps.1 (highest) wps.0
（最低）wps.4 wps.3 wps.2 wps.1（最高）wps.0
The WPS namespace operates according to the priority queueing algorithm (Section 4.5.2).
WPS命名空间根据优先级排队算法（第4.5.2节）运行。
Any resource priority mechanism can be abused to obtain resources and thus deny service to other users. An adversary may be able to take over a particular PSTN gateway, cause additional congestion during emergencies affecting the PSTN, or deny service to legitimate users. In SIP end systems, such as IP phones, this mechanism could inappropriately terminate existing sessions and calls.
任何资源优先级机制都可能被滥用以获取资源，从而拒绝向其他用户提供服务。对手可以接管特定的PSTN网关，在影响PSTN的紧急情况下造成额外的拥塞，或者拒绝向合法用户提供服务。在SIP终端系统（如IP电话）中，此机制可能会不适当地终止现有会话和呼叫。
Thus, while the indication itself does not have to provide separate authentication, SIP requests containing this header are very likely to have higher authentication requirements than those without.
因此，尽管指示本身不必提供单独的身份验证，但包含该报头的SIP请求很可能比不包含该报头的SIP请求具有更高的身份验证要求。
These authentication and authorization requirements extend to users within the administrative domain, as later interconnection with other administrative domains may invalidate earlier assumptions on the trustworthiness of users.
这些认证和授权要求扩展到管理域内的用户，因为以后与其他管理域的互连可能会使先前对用户可信度的假设失效。
Below, we describe authentication and authorization aspects, confidentiality and privacy requirements, protection against denial-of-service attacks, and anonymity requirements. Naturally, the general discussion in RFC 3261 [RFC3261] applies.
下面，我们将介绍身份验证和授权方面、机密性和隐私要求、针对拒绝服务攻击的保护以及匿名性要求。当然，RFC 3261[RFC3261]中的一般性讨论适用。
All user agents and proxy servers that support this extension MUST implement SIP over TLS [RFC3546], the 'sips' URI scheme as described in Section 26.2 of RFC 3261, and Digest Authentication [RFC2617] as described in Section 22 of RFC 3261. In addition, user agents that support this extension SHOULD also implement S/MIME [RFC3851] as described in Section 23 of RFC 3261 to allow for signing and verification of signatures over requests that use this extension.
支持此扩展的所有用户代理和代理服务器必须通过TLS实现SIP[RFC3546]、RFC 3261第26.2节所述的“sips”URI方案以及RFC 3261第22节所述的摘要身份验证[RFC2617]。此外，支持此扩展的用户代理还应实现RFC 3261第23节中所述的S/MIME[RFC3851]，以允许在使用此扩展的请求上签名和验证签名。
Prioritized access to network and end-system resources imposes particularly stringent requirements on authentication and authorization mechanisms, since access to prioritized resources may impact overall system stability and performance and not just result in theft of, say, a single phone call.
对网络和终端系统资源的优先访问对身份验证和授权机制提出了特别严格的要求，因为对优先资源的访问可能会影响整个系统的稳定性和性能，而不仅仅会导致（比如）一个电话被盗。
Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack.
在某些紧急情况下，网络基础设施，包括其身份验证和授权机制，可能会受到攻击。
Given the urgency during emergency events, normal statistical fraud detection may be less effective, thus placing a premium on reliable authentication.
考虑到紧急事件期间的紧迫性，正常的统计欺诈检测可能不太有效，因此需要重视可靠的身份验证。
Common requirements for authentication mechanisms apply, such as resistance to replay, cut-and-paste, and bid-down attacks.
身份验证机制的常见要求适用，例如抵抗重播、剪切粘贴和出价下降攻击。
Authentication MAY be SIP based or use other mechanisms. Use of Digest authentication and/or S/MIME is RECOMMENDED for UAS authentication. Digest authentication requires that the parties share a common secret, thus limiting its use across administrative domains. SIP systems employing resource priority SHOULD implement S/MIME at least for integrity, as described in Section 23 of [RFC3261]. However, in some environments, receipt of asserted identity [RFC3325] from a trusted entity may be sufficient authorization. Section 5 describes third-party authentication.
身份验证可以是基于SIP的，也可以使用其他机制。建议对UAS身份验证使用摘要身份验证和/或S/MIME。摘要身份验证要求各方共享一个公共机密，从而限制其在管理域中的使用。如[RFC3261]第23节所述，采用资源优先级的SIP系统应至少为完整性实现S/MIME。然而，在某些环境中，从受信任实体接收断言的标识[RFC3325]可能就足够了。第5节描述了第三方身份验证。
Trait-based authorization [TRAIT] "entails an assertion by a authorization service of attributes associated with an identity" and may be appropriate for this application. With trait-based authorization, a network element can directly determine, by inspecting the certificate, that a request is authorized to obtain a particular type of service, without having to consult a mapping mechanism that converts user identities to authorizations.
基于特征的授权[特征]“需要授权服务对与身份相关的属性进行断言”，并且可能适用于此应用程序。通过基于特征的授权，网元可以通过检查证书直接确定请求被授权获得特定类型的服务，而无需咨询将用户身份转换为授权的映射机制。
Authorization may be based on factors besides the identity of the caller, such as the requested destination. Namespaces MAY also impose particular authentication or authorization considerations that are stricter than the baseline described here.
授权可以基于除呼叫者的身份之外的因素，例如请求的目的地。名称空间还可能施加比此处描述的基线更严格的特定身份验证或授权注意事项。
Calls that use elevated resource priority levels provided by the 'Resource-Priority' header field are likely to be sensitive and often need to be protected from intercept and alteration. In particular, requirements for protecting the confidentiality of communications relationships may be higher than those for normal commercial service. For SIP, the 'To', 'From', 'Organization', and 'Subject' header fields are examples of particularly sensitive information. Systems MUST implement encryption at the transport level using TLS and MAY implement other transport-layer or network-layer security mechanisms. UACs SHOULD use the "sips" URI to request a secure transport association to the destination.
“优先权”字段和“优先权”字段中的“优先权”字段可能会被拦截。特别是，保护通信关系机密性的要求可能高于正常商业服务的要求。对于SIP，“收件人”、“发件人”、“组织”和“主题”标题字段是特别敏感信息的示例。系统必须使用TLS在传输级别实现加密，并且可以实现其他传输层或网络层安全机制。UACs应使用“sips”URI请求到目的地的安全传输关联。
The 'Resource-Priority' header field can be carried in the SIP message header or can be encapsulated in a message fragment carried in the SIP message body [RFC3420]. To be considered valid authentication for the purposes of this specification, S/MIME-signed
“资源优先级”报头字段可以在SIP消息报头中携带，也可以封装在SIP消息正文中携带的消息片段中[RFC3420]。为了在本规范中被视为有效身份验证，S/MIME已签名
SIP messages or fragments MUST contain, at a minimum, the Date, To, From, Call-ID, and Resource-Priority header fields. Encapsulation in S/MIME body parts allows the user to protect this header field against inspection or modification by proxies. However, in many cases, proxies will need to authenticate and authorize the request, so encapsulation would be undesirable.
SIP消息或片段必须至少包含日期、收件人、发件人、呼叫ID和资源优先级标头字段。S/MIME主体部分中的封装允许用户保护此标头字段，以防代理检查或修改。然而，在许多情况下，代理需要对请求进行身份验证和授权，因此封装是不可取的。
Removal of a Resource-Priority header field or downgrading its priority value affords no additional opportunities to an adversary, since that man-in-the-middle could simply drop or otherwise invalidate the SIP request and thus prevent call completion.
删除资源优先级报头字段或降低其优先级值不会给对手带来额外的机会，因为中间的人可能会简单地放弃或以其他方式使SIP请求无效，从而阻止呼叫完成。
Only SIP elements within the same administrative trust domain employing a secure channel between their SIP elements will trust a Resource-Priority header field that is not appropriately signed. Others will need to authenticate the request independently. Thus, insertion of a Resource-Priority header field or upgrading the priority value has no further security implications except causing a request to fail (see discussion in the previous paragraph).
只有同一管理信任域中的SIP元素在其SIP元素之间使用安全通道，才会信任未正确签名的资源优先级标头字段。其他人将需要独立验证请求。因此，插入资源优先级头字段或升级优先级值除了导致请求失败外，没有其他安全影响（请参阅上一段中的讨论）。
Some users may wish to remain anonymous to the request destination. Anonymity for requests with resource priority is no different from that for any other authenticated SIP request. For the reasons noted earlier, users have to authenticate themselves towards the SIP elements carrying the request where they desire resource priority treatment. The authentication may be based on capabilities and noms, not necessarily their civil name. Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanism described in [RFC3323].
一些用户可能希望对请求目的地保持匿名。具有资源优先级的请求的匿名性与任何其他经过身份验证的SIP请求的匿名性没有区别。出于前面提到的原因，用户必须对承载请求的SIP元素进行身份验证，因为他们需要资源优先级处理。认证可以基于功能和名称，而不一定基于其民用名称。显然，他们可以使用[RFC3323]中描述的网络断言身份和一般隐私机制，对请求目的地保持匿名。
As noted, systems described here are likely to be subject to deliberate denial-of-service (DoS) attacks during certain types of emergencies. DoS attacks may be launched on the network itself as well as on its authentication and authorization mechanism. As noted, systems should minimize the amount of state, computation, and network resources that an unauthorized user can command. The system must not amplify attacks by causing the transmission of more than one packet to a network address whose reachability has not been verified.
如前所述，在某些类型的紧急情况下，此处描述的系统可能会受到故意拒绝服务（DoS）攻击。DoS攻击可能在网络本身及其身份验证和授权机制上发起。如前所述，系统应尽量减少未经授权用户可以命令的状态、计算和网络资源量。系统不得通过将多个数据包传输到未验证其可达性的网络地址来放大攻击。
This section defines two new SIP headers (Section 12.2), one SIP option tag (Section 12.3), one new 4xx error code (Section 12.4), a new registry within the sip-parameters section of IANA for Resource-Priority namespaces (Section 12.5), and a new registry within the sip-parameters section of IANA for Resource-Priority and priority-values (Section 12.6).
本节定义了两个新的SIP头（第12.2节）、一个SIP选项标记（第12.3节）、一个新的4xx错误代码（第12.4节）、IANA的SIP参数部分中用于资源优先级名称空间的新注册表（第12.5节），以及IANA的SIP参数部分中用于资源优先级和优先级值的新注册表（第12.6节）。
Additional namespaces and priority values MUST be registered with IANA, as described in Section 9.
如第9节所述，必须向IANA注册其他名称空间和优先级值。
The SIP Change Process [RFC3427] establishes a policy for the registration of new SIP extension headers. Resource priority namespaces and priority values have similar interoperability requirements to those of SIP extension headers. Consequently, registration of new resource priority namespaces and priority values requires documentation in an RFC using the extension header approval process specified in RFC 3427.
SIP更改过程[RFC3427]为注册新的SIP扩展头建立策略。资源优先级名称空间和优先级值具有与SIP扩展头相似的互操作性要求。因此，注册新的资源优先级名称空间和优先级值需要使用RFC 3427中指定的扩展标头批准流程在RFC中记录。
Registration policies for new namespaces are defined in Section 9.
第9节定义了新名称空间的注册策略。
12.2. IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields
12.2. IANA注册“资源优先级”和“接受资源优先级”标题字段
The following is the registration for the 'Resource-Priority' header field:
以下是“资源优先级”标题字段的注册：
RFC number: 4412 Header name: 'Resource-Priority' Compact form: none
RFC编号：4412标题名称：“资源优先级”压缩格式：无
The following is the registration for the 'Accept-Resource-Priority' header field:
以下是“接受资源优先级”标题字段的注册：
RFC number: 4412 Header name: Accept-Resource-Priority Compact form: none
RFC编号：4412标头名称：接受资源优先级压缩格式：无
RFC number: 4412 Name of option tag: 'resource-priority' Descriptive text: Indicates or requests support for the resource priority mechanism.
RFC编号：4412选项标记名称：“资源优先级”描述性文本：表示或请求支持资源优先级机制。
RFC number: 4412 Response code: 417 Default reason phrase: Unknown Resource-Priority
RFC编号：4412响应代码：417默认原因短语：未知资源优先级
A new registry ("Resource-Priority Namespaces") in the sip-parameters section of IANA has been created, taking a form similar to this table below:
已在IANA的sip参数部分创建了一个新的注册表（“资源优先级名称空间”），其形式类似于下表：
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
drsn 6 preemption no no [RFC4412]
drsn 6抢占编号[RFC4412]
q735 5 preemption no no [RFC4412]
q735 5抢占权编号[RFC4412]
ets 5 queue no no [RFC4412]
ets 5队列编号[RFC4412]
wps 5 queue no no [RFC4412]
wps 5队列编号[RFC4412]
Legend
------
Namespace The unique string identifying the namespace.
Levels The number of priority-values within the namespace.
Algorithm Intended operational behavior of SIP elements
implementing this namespace.
New Warn code New Warning Codes (warn-codes) introduced by
this namespace.
New Resp. code New SIP response codes introduced by this namespace.
Reference IETF document reference for this namespace.
Legend
------
Namespace The unique string identifying the namespace.
Levels The number of priority-values within the namespace.
Algorithm Intended operational behavior of SIP elements
implementing this namespace.
New Warn code New Warning Codes (warn-codes) introduced by
this namespace.
New Resp. code New SIP response codes introduced by this namespace.
Reference IETF document reference for this namespace.
A new registry ("Resource-Priority Priority-values") in the sip-parameters section of IANA has been created, taking a form similar to this table below:
已在IANA的sip参数部分创建了一个新的注册表（“资源优先级值”），其形式与下表类似：
Namespace: drsn Reference: RFC 4412 Priority-Values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override", "flash-override-override"
名称空间：drsn参考：RFC 4412优先级值（从最小到最大）：“例程”、“优先级”、“立即”、“闪存”、“闪存覆盖”、“闪存覆盖”
Namespace: dsn Reference: RFC 4412 Priority-Values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override"
名称空间：dsn参考：RFC 4412优先级值（从最小到最大）：“例程”、“优先级”、“立即”、“闪存”、“闪存覆盖”
Namespace: q735 Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
命名空间：q735引用：RFC 4412优先级值（从最小到最大）：“4”、“3”、“2”、“1”、“0”
Namespace: ets Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
命名空间：ets参考：RFC 4412优先级值（从最小到最大）：“4”、“3”、“2”、“1”、“0”
Namespace: wps Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
命名空间：wps引用：RFC 4412优先级值（从最小到最大）：“4”、“3”、“2”、“1”、“0”
Ben Campbell, Ken Carlberg, Paul Kyzivat, Rohan Mahy, Allison Mankin, Xavier Marjou, Piers O'Hanlon, Mike Pierce, Samir Srivastava, and Dale Worley provided helpful comments.
本·坎贝尔、肯·卡尔伯格、保罗·基齐瓦特、罗汉·马伊、埃里森·曼金、泽维尔·马约、皮尔斯·奥汉隆、迈克·皮尔斯、萨米尔·斯利瓦斯塔瓦和戴尔·沃利提供了有益的评论。
Dean Willis provided much help with this effort.
迪安·威利斯在这方面提供了很多帮助。
Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS and WPS namespaces.
阮人Martin Dolly和Niranjan Sandesara协助使用ETS和WPS名称空间。
Janet Gunn helped improve the text on queueing-based priority.
Janet Gunn帮助改进了基于排队优先级的文本。
[I.255.3] International Telecommunications Union, "Integrated Services Digital Network (ISDN) - General Structure and Service Capabilities - Multi-Level Precedence and Preemption", Recommendation I.255.3, July 1990.
[I.255.3]国际电信联盟，“综合业务数字网（ISDN）-一般结构和服务能力-多级优先和抢占”，建议I.255.3，1990年7月。
[Q.735.3] International Telecommunications Union, "Stage 3 description for community of interest supplementary services using Signalling System No. 7: Multi-level precedence and preemption", Recommendation Q.735.3, March 1993.
[Q.735.3]国际电信联盟，“使用第7号信令系统的利益共同体补充业务的第3阶段说明：多级优先和抢占”，建议Q.735.3，1993年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[RFC3420]Sparks，R.，“互联网媒体类型消息/sipfrag”，RFC 3420，2002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
[RFC4411]Polk，J.“扩展抢占事件的会话启动协议（SIP）原因头”，RFC 4411，2006年2月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3427]Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的更改过程”，BCP 67，RFC 3427，2002年12月。
[RFC3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[RFC3487]Schulzrinne，H.，“会话启动协议（SIP）的资源优先级机制要求”，RFC 3487，2003年2月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[RFC3546]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3665]Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）基本呼叫流示例”，BCP 75，RFC 36652003年12月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893]Peterson，J.，“会话启动协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。事件状态出版物”，RFC 3903，2004年10月。
[TRAIT] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
[TRAIT]Peterson，J.，Polk，J.，Sicker，D.，和H.Tschofenig，“会话启动协议（SIP）基于特征的授权要求”，正在进行的工作，2005年2月。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 US
詹姆斯·波尔克思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。