Network Working Group J. Rosenberg
Request for Comments: 3841 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Network Working Group J. Rosenberg
Request for Comments: 3841 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Caller Preferences 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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences.
本文档描述了会话启动协议（SIP）的一组扩展，这些扩展允许调用者表达关于服务器中请求处理的首选项。这些首选项包括选择请求路由到哪个统一资源标识符（URI）的能力，以及在代理和重定向服务器中指定某些请求处理指令的能力。它通过定义三个新的请求头字段，接受联系人、拒绝联系人和请求处置来实现，这些字段指定了调用方的首选项。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Request Handling Preferences . . . . . . . . . . . . . . 6
5.2. Feature Set Preferences . . . . . . . . . . . . . . . . 6
6. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Request-Disposition Processing . . . . . . . . . . . . . 9
7.2. Preference and Capability Matching . . . . . . . . . . . 9
7.2.1. Extracting Explicit Preferences . . . . . . . . . 10
7.2.2. Extracting Implicit Preferences . . . . . . . . . 10
7.2.2.1. Methods. . . . . . . . . . . . . . . . . 10
7.2.2.2. Event Packages . . . . . . . . . . . . . 11
7.2.3. Constructing Contact Predicates . . . . . . . . . 11
7.2.4. Matching. . . . . . . . . . . . . . . . . . . . . 12
7.2.5. Example . . . . . . . . . . . . . . . . . . . . . 16
8. Mapping Feature Parameters to a Predicate. . . . . . . . . . . 17
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
9.1. Request Disposition . . . . . . . . . . . . . . . . . . 20
9.2. Accept-Contact and Reject-Contact Header Fields . . . . 21
10. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 24
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
16. Full Copyright Statements. . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Request Handling Preferences . . . . . . . . . . . . . . 6
5.2. Feature Set Preferences . . . . . . . . . . . . . . . . 6
6. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Request-Disposition Processing . . . . . . . . . . . . . 9
7.2. Preference and Capability Matching . . . . . . . . . . . 9
7.2.1. Extracting Explicit Preferences . . . . . . . . . 10
7.2.2. Extracting Implicit Preferences . . . . . . . . . 10
7.2.2.1. Methods. . . . . . . . . . . . . . . . . 10
7.2.2.2. Event Packages . . . . . . . . . . . . . 11
7.2.3. Constructing Contact Predicates . . . . . . . . . 11
7.2.4. Matching. . . . . . . . . . . . . . . . . . . . . 12
7.2.5. Example . . . . . . . . . . . . . . . . . . . . . 16
8. Mapping Feature Parameters to a Predicate. . . . . . . . . . . 17
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
9.1. Request Disposition . . . . . . . . . . . . . . . . . . 20
9.2. Accept-Contact and Reject-Contact Header Fields . . . . 21
10. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 24
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
16. Full Copyright Statements. . . . . . . . . . . . . . . . . . . 26
When a Session Initiation Protocol (SIP) [1] server receives a request, there are a number of decisions it can make regarding the processing of the request. These include:
当会话启动协议（SIP）[1]服务器接收到请求时，它可以做出许多关于请求处理的决定。这些措施包括：
o whether to proxy or redirect the request
o 是代理请求还是重定向请求
o which URIs to proxy or redirect to
o 代理或重定向到哪个URI
o whether to fork or not
o 是否用叉子叉
o whether to search recursively or not
o 是否递归搜索
o whether to search in parallel or sequentially
o 是并行搜索还是顺序搜索
The server can base these decisions on any local policy. This policy can be statically configured, or can be based on execution of a program or database access.
服务器可以根据任何本地策略做出这些决定。此策略可以静态配置，也可以基于程序的执行或数据库访问。
However, the administrator of the server is the not the only entity with an interest in request processing. There are at least three parties which have an interest: (1) the administrator of the server, (2) the user that sent the request, and (3) the user to whom the request is directed. The directives of the administrator are embedded in the policy of the server. The preferences of the user to whom the request is directed (referred to as the callee, even though the request method may not be INVITE) can be expressed most easily through a script written in some type of scripting language, such as the Call Processing Language (CPL) [11]. However, no mechanism exists to incorporate the preferences of the user that sent the request (also referred to as the caller, even though the request method may not be INVITE). For example, the caller might want to speak to a specific user, but wants to reach them only at work, because the call is a business call. As another example, the caller might want to reach a user, but not their voicemail, since it is important that the caller talk to the called party. In both of these examples, the caller's preference amounts to having a proxy make a particular routing choice based on the preferences of the caller.
但是，服务器管理员并不是唯一对请求处理感兴趣的实体。至少有三方对此感兴趣：（1）服务器管理员，（2）发送请求的用户，以及（3）请求指向的用户。管理员的指令嵌入到服务器的策略中。请求所指向的用户（称为被调用方，即使请求方法可能不是INVITE）的首选项可以最容易地通过用某种类型的脚本语言（例如调用处理语言（CPL））编写的脚本来表示[11]。但是，不存在合并发送请求的用户的首选项的机制（也称为调用者，即使请求方法可能不是INVITE）。例如，呼叫方可能希望与特定用户通话，但只希望在工作时与他们联系，因为该呼叫是业务呼叫。作为另一个例子，呼叫者可能想要联系用户，但不是他们的语音邮件，因为呼叫者与被叫方交谈很重要。在这两个示例中，调用方的首选项相当于让代理根据调用方的首选项做出特定的路由选择。
This extension allows the caller to have these preferences met. It does so by specifying mechanisms by which a caller can provide preferences on processing of a request. There are two types of preferences. One of them, called request handling preferences, are encapsulated in the Request-Disposition header field. They provide specific request handling directives for a server. The other, called feature preferences, is present in the Accept-Contact and Reject-Contact header fields. They allow the caller to provide a feature set [2] that expresses its preferences on the characteristics of the UA that is to be reached. These are matched with a feature set provided by a UA to its registrar [3]. The extension is very general purpose, and not tied to a particular service. Rather, it is a tool that can be used in the development of many services.
此扩展允许调用方满足这些首选项。它通过指定调用方可以在处理请求时提供首选项的机制来实现。有两种类型的首选项。其中一个称为请求处理首选项，封装在请求处置标头字段中。它们为服务器提供特定的请求处理指令。另一个称为功能首选项，出现在接受联系人和拒绝联系人标题字段中。它们允许调用者提供一个特性集[2]，该特性集表达了其对要访问的UA特性的偏好。这些特征与UA向其注册者提供的特征集相匹配[3]。扩展是非常通用的，并且与特定的服务无关。相反，它是一种可用于开发许多服务的工具。
One example of a service enabled by caller preferences is a "one number" service. A user can have a single identity (their SIP URI) for all of their devices - their cell phone, PDA, work phone, home phone, and so on. If the caller wants to reach the user at their business phone, they simply select "business phone" from a pull-down menu of options when calling that URI. Users would no longer need to maintain and distribute separate identities for each device.
调用方首选项启用的服务的一个示例是“一个号码”服务。用户可以为其所有设备（手机、PDA、工作电话、家庭电话等）拥有一个单一标识（SIPURI）。如果呼叫者希望通过他们的商务电话与用户取得联系，那么在调用该URI时，他们只需从选项下拉菜单中选择“商务电话”。用户不再需要为每个设备维护和分发单独的身份。
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 [4] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[4]中的描述进行解释，并指出合规实施的要求级别。
Much of the terminology used in this specification is presented in [3]. This specification defines the following additional terms:
本规范中使用的许多术语见[3]。本规范定义了以下附加条款：
Caller: Within the context of this specification, a caller refers to the user on whose behalf a UAC is operating. It is not limited to a user whose UAC sends an INVITE request.
调用者：在本规范的上下文中，调用者是指UAC代表其操作的用户。它不限于UAC发送INVITE请求的用户。
Feature Preferences: Caller preferences that describe desired properties of a UA to which the request is to be routed. Feature preferences can be made explicit with the Accept-Contact and Reject-Contact header fields.
功能首选项：呼叫方首选项，描述请求将路由到的UA的所需属性。功能首选项可以通过“接受联系人”和“拒绝联系人”标题字段显式设置。
Request Handling Preferences: Caller preferences that describe desired request treatment at a server. These preferences are carried in the Request-Disposition header field.
请求处理首选项：描述服务器上所需请求处理的调用方首选项。这些首选项包含在请求处置标头字段中。
Target Set: A target set is a set of candidate URIs to which a proxy or redirect server can send or redirect a request. Frequently, target sets are obtained from a registration, but they need not be.
目标集：目标集是代理或重定向服务器可以向其发送或重定向请求的一组候选URI。通常，目标集是从注册中获得的，但不需要。
Explicit Preference: A caller preference indicated explicitly in the Accept-Contact or Reject-Contact header fields.
显式首选项：在接受联系人或拒绝联系人标题字段中显式指示的呼叫方首选项。
Implicit Preference: A caller preference that is implied through the presence of other aspects of a request. For example, if the request method is INVITE, it represents an implicit caller preference to route the request to a UA that supports the INVITE method.
隐式偏好：通过存在请求的其他方面而隐含的调用方偏好。例如，如果请求方法是INVITE，则它表示将请求路由到支持INVITE方法的UA的隐式调用方首选项。
When a caller sends a request, it can optionally include new header fields which request certain handling at a server. These preferences fall into two categories. The first category, called request handling preferences, is carried in the Request-Disposition header field. It describes specific behavior that is desired at a server. Request handling preferences include whether the caller wishes the
当调用方发送请求时，它可以选择性地包含新的头字段，这些头字段请求服务器上的某些处理。这些偏好分为两类。第一个类别称为请求处理首选项，在请求处置标头字段中携带。它描述了服务器上需要的特定行为。请求处理首选项包括调用方是否希望
server to proxy or redirect, and whether sequential or parallel search is desired. These preferences can be applied at every proxy or redirect server on the call signaling path.
服务器到代理或重定向，以及是否需要顺序或并行搜索。这些首选项可以应用于呼叫信令路径上的每个代理或重定向服务器。
The second category of preferences, called feature preferences, is carried in the Accept-Contact and Reject-Contact header fields. These header fields contain feature sets, represented by the same feature parameters that are used to indicate capabilities [3]. Here, the feature parameters represent the caller's preferences. The Accept-Contact header field contains feature sets that describe UAs that the caller would like to reach. The Reject-Contact header field contains feature sets which, if matched by a UA, imply that the request should not be routed to that UA.
第二类首选项称为功能首选项，包含在接受联系人和拒绝联系人标题字段中。这些标题字段包含功能集，由用于指示功能的相同功能参数表示[3]。这里，特性参数表示调用方的首选项。Accept Contact header字段包含描述调用方希望访问的UAs的功能集。拒绝联系人标头字段包含功能集，如果与UA匹配，则意味着不应将请求路由到该UA。
Proxies use the information in the Accept-Contact and Reject-Contact header fields to select amongst contacts in their target set. When neither of those header fields are present, the proxy computes implicit preferences from the request. These are caller preferences that are not explicitly placed into the request, but can be inferred from the presence of other message components. As an example, if the request method is INVITE, this is an implicit preference to route the call to a UA that supports the INVITE method.
代理使用“接受联系人”和“拒绝联系人”标题字段中的信息在其目标集中的联系人中进行选择。当这两个头字段都不存在时，代理将根据请求计算隐式首选项。这些是未显式放置到请求中的调用方首选项，但可以从其他消息组件的存在中推断出来。例如，如果请求方法是INVITE，则这是将调用路由到支持INVITE方法的UA的隐式首选项。
Both request handling and feature preferences can appear in any request, not just INVITE. However, they are only useful in requests where proxies need to determine a request target. If the domain in the request URI is not owned by any proxies along the request path, those proxies will never access a location service, and therefore, never have the opportunity to apply the caller preferences. This makes sense because typically, the request URI will identify a UAS for mid-dialog requests. In those cases, the routing decisions were already made on the initial request, and it makes no sense to redo them for subsequent requests in the dialog.
请求处理和功能首选项都可以出现在任何请求中，而不仅仅是邀请。但是，它们仅在代理需要确定请求目标的请求中有用。如果请求URI中的域不属于请求路径上的任何代理，那么这些代理将永远不会访问位置服务，因此永远没有机会应用调用方首选项。这是有意义的，因为请求URI通常会为mid对话请求标识UAS。在这些情况下，路由决定已经在初始请求上做出，因此在对话框中为后续请求重做路由决定是没有意义的。
A caller wishing to express preferences for a request includes Accept-Contact, Reject-Contact, or Request-Disposition header fields in the request, depending on their particular preferences. No additional behavior is required after the request is sent.
希望表示请求首选项的调用方根据其特定首选项，在请求中包括Accept Contact、Reject Contact或request Disposition标头字段。发送请求后不需要其他行为。
The Accept-Contact, Reject-Contact, and Request-Disposition header fields in an ACK for a non-2xx final response, or in a CANCEL request, MUST be equal to the values in the original request being acknowledged or cancelled. This is to ensure proper operation through stateless proxies.
非2xx最终响应或取消请求的ACK中的接受联系人、拒绝联系人和请求处置标头字段必须等于被确认或取消的原始请求中的值。这是为了确保通过无状态代理进行正确操作。
If the UAC wants to determine whether servers along the path understand the header fields described in this specification, it includes a Proxy-Require header field with a value of "pref" [3] in its request. If the request should fail with a 420 response code, the UAC knows that the extension is not supported. In that case, it SHOULD retry, and may decide whether or not to use caller preferences. A UA should only use Proxy-Require if knowledge about support is essential for handling of the request. Note that, in any case, caller preferences can only be considered preferences - there is no guarantee that the requested service will be executed. As such, inclusion of a Proxy-Require header field does not mean that the preferences will be executed, just that the caller preferences extension is understood by the proxies.
如果UAC想要确定路径上的服务器是否理解本规范中描述的头字段，它会在其请求中包含一个值为“pref”[3]的代理请求头字段。如果请求以420响应代码失败，UAC知道扩展不受支持。在这种情况下，它应该重试，并可能决定是否使用调用方首选项。UA应仅在有关支持的知识对于处理请求至关重要的情况下使用Proxy Require。请注意，在任何情况下，调用方首选项只能被视为首选项-不能保证将执行请求的服务。因此，包含Proxy Require头字段并不意味着将执行首选项，只是代理可以理解调用者首选项扩展。
The Request-Disposition header field specifies caller preferences for how a server should process a request. Its value is a list of tokens, each of which specifies a particular processing directive.
Request Disposition header字段指定服务器应如何处理请求的调用方首选项。它的值是一个令牌列表，每个令牌指定一个特定的处理指令。
The syntax of the header field can be found in Section 10, and the semantics of the directives are described in Section 9.1.
标题字段的语法见第10节，指令的语义见第9.1节。
A UAC can indicate caller preferences for the capabilities of a UA that should be reached or not reached as a result of sending a SIP request. To do that, it adds one or more Accept-Contact and Reject-Contact header field values. Each header field value contains a set of feature parameters that define a feature set. The syntax of the header field can be found in Section 10, and a discussion of their usage in Section 9.2.
UAC可以指示呼叫方对UA的功能的偏好，这些功能应该作为发送SIP请求的结果达到或不达到。为此，它添加一个或多个接受联系人和拒绝联系人标题字段值。每个标题字段值都包含一组定义要素集的要素参数。标题字段的语法可在第10节中找到，并在第9.2节中讨论其用法。
Each feature set is constructed as described in Section 5 of [3]. The feature sets placed into these header fields MAY overlap; that is, a UA MAY indicate preferences for feature sets that match according to the matching algorithm of RFC 2533 [2].
每个特征集的构造如[3]第5节所述。放置在这些标题字段中的要素集可能重叠；即，UA可指示根据RFC 2533[2]的匹配算法匹配的特征集的偏好。
A UAC can express explicit preferences for the methods and event packages supported by a UA. It is RECOMMENDED that a UA include a term in an Accept-Contact feature set with the "sip.methods" feature tag (note, however, that even though the name of this feature tag is sip.methods, it would be encoded into the Accept-Contact header field as just "methods"), whose value includes the method of the request. When a UA sends a SUBSCRIBE request, it is RECOMMENDED that a UA include a term in an Accept-Contact feature set with the "sip.events" feature tag, whose value includes the event package of the request. Whether these terms are placed into a new feature set, or whether
UAC可以为UA支持的方法和事件包表达明确的首选项。建议UA在带有“sip.methods”功能标签的Accept Contact功能集中包含一个术语（但是，请注意，即使该功能标签的名称是sip.methods，它也会被编码到Accept Contact header字段中，仅作为“methods”），其值包括请求的方法。当UA发送订阅请求时，建议UA在带有“sip.events”功能标签的接受联系人功能集中包含一个术语，其值包括请求的事件包。是否将这些术语放入新功能集中，或者
they are included in each feature set, is at the discretion of the implementor. In most cases, the right effect is achieved by including a term in each feature set.
它们包含在每个功能集中，由实现者自行决定。在大多数情况下，正确的效果是通过在每个特征集中包含一个术语来实现的。
As an example, the following Accept-Contact header field expresses a desire to route a call to a mobile device, using feature parameters taken from [3]:
例如，下面的Accept Contact header字段表示希望使用[3]中的功能参数将呼叫路由到移动设备：
Accept-Contact: *;mobility="mobile";methods="INVITE"
Accept-Contact: *;mobility="mobile";methods="INVITE"
The Reject-Contact header field allows the UAC to specify that a UA should not be contacted if it matches any of the values of the header field. Each value of the Reject-Contact header field contains a "*", purely to align the syntax with guidelines for SIP extensions [12], and is parameterized by a set of feature parameters. Any UA whose capabilities match the feature set described by the feature parameters matches the value.
拒绝联系人标头字段允许UAC指定如果UA与标头字段的任何值匹配，则不应联系UA。Reject Contact header字段的每个值都包含一个“*”，纯粹是为了使语法与SIP扩展指南[12]保持一致，并通过一组功能参数进行参数化。其能力与特征参数描述的特征集相匹配的任何UA都与该值相匹配。
The Accept-Contact header field allows the UAC to specify that a UA should be contacted if it matches some or all of the values of the header field. Each value of the Accept-Contact header field contains a "*", and is parameterized by a set of feature parameters. Any UA whose capabilities match the feature set described by the feature parameters matches the value. The precise behavior depends heavily on whether the "require" and "explicit" parameters are present. When both of them are present, a proxy will only forward the request to contacts which have explicitly indicated that they support the desired feature set. Any others are discarded. As such, a UAC should only use "require" and "explicit" together when it wishes the call to fail unless a contact definitively matches. It's possible that a UA supports a desired feature, but did not indicate it in its registration. When a UAC uses both "explicit" and "require", such a contact would not be reached. As a result, this combination is often not the one a UAC will want.
Accept Contact标头字段允许UAC指定，如果UA与标头字段的部分或全部值匹配，则应联系UA。Accept Contact header字段的每个值都包含一个“*”，并由一组功能参数参数化。其能力与特征参数描述的特征集相匹配的任何UA都与该值相匹配。精确的行为在很大程度上取决于是否存在“require”和“explicit”参数。当两者都存在时，代理仅将请求转发给明确表示支持所需功能集的联系人。任何其他的都会被丢弃。因此，UAC只有在希望呼叫失败时才应同时使用“require”和“explicit”，除非某个联系人确定匹配。UA可能支持所需的功能，但在注册时没有指明。当UAC同时使用“明确”和“要求”时，将无法联系到此类联系人。因此，这种组合通常不是UAC想要的组合。
When only "require" is present, it means that a contact will not be used if it doesn't match. If it does match, or if it's not known whether it's a complete match, the contact is still used. A UAC would use "require" alone when a non-matching contact is useless. This is common for services where the request simply can't be serviced without the necessary features. An example is support for specific methods or event packages. When only "require" is present, the proxy will also preferentially route the request to the UA which represents the "best" match. Here, "best" means that the UA has explicitly indicated it supports more of the desired features than any other. Note, however, that this preferential routing will never override an ordering provided by the called party. The preferential routing will only choose amongst contacts of equal q-value.
当只存在“require”时，表示如果触点不匹配，则不会使用该触点。如果确实匹配，或者不知道是否完全匹配，则仍使用该联系人。当不匹配的联系人无效时，UAC将单独使用“require”。这对于没有必要的功能就无法处理请求的服务来说是很常见的。一个例子是对特定方法或事件包的支持。当仅存在“require”时，代理还将优先将请求路由到表示“最佳”匹配的UA。这里，“最佳”意味着UA明确表示它支持比任何其他功能更多的所需功能。但是，请注意，此优先路由决不会覆盖被叫方提供的订购。优先布线将仅在q值相等的触点之间进行选择。
When only "explicit" is present, it means that all contacts provided by the callee will be used. However, if the contact isn't an explicit match, it is tried last amongst all other contacts with the same q-value. The principle difference, therefore, between this configuration and the usage of both "require" and "explicit" is the fallback behavior for contacts that don't match explicitly. Here, they are tried as a last resort. If "require" is also present, they are never tried.
只有“显式”时，表示将使用被叫方提供的所有联系人。但是，如果该联系人不是显式匹配，则在具有相同q值的所有其他联系人中最后尝试该联系人。因此，这种配置与“require”和“explicit”的用法之间的主要区别在于，对于不显式匹配的联系人，其回退行为。在这里，他们是作为最后手段进行审判的。如果“require”也存在，则从未尝试过。
Finally, if neither "require" nor "explicit" are present, it means that all contacts provided by the callee will be used. However, if the contact doesn't match, it is tried last amongst all other contacts with the same q-value. If it does match, the request is routed preferentially to the "best" match. This is a common configuration for preferences that, if not honored, will still allow for a successful call, and the greater the match, the better.
最后，如果既不存在“require”也不存在“explicit”，则表示将使用被叫方提供的所有联系人。但是，如果该触点不匹配，则在具有相同q值的所有其他触点中最后尝试该触点。如果确实匹配，则优先将请求路由到“最佳”匹配。这是首选项的常见配置，如果不遵守此配置，仍将允许成功调用，匹配越大越好。
When a UAS compliant to this specification receives a request whose request-URI corresponds to one of its registered contacts, it SHOULD apply the behavior described in Section 7.2 as if it were a proxy for the domain in the request-URI. The UAS acts as if its location database contains a single request target for the request-URI. That target is associated with a feature set. The feature set is the same as the one placed in the registration of the URI in the request-URI. If a UA had registered against multiple separate addresses-of-record, and the contacts registered for each had different capabilities, it will have used a different URI in each registration, so it can determine which feature set to use.
当符合本规范的UAS收到其请求URI对应于其注册联系人之一的请求时，它应该应用第7.2节中描述的行为，就像它是请求URI中域的代理一样。UAS的行为就像其位置数据库包含请求URI的单个请求目标一样。该目标与要素集相关联。该功能集与请求URI中的URI注册中放置的功能集相同。如果UA已针对多个单独的记录地址进行了注册，并且为每个地址注册的联系人具有不同的功能，那么它将在每次注册中使用不同的URI，以便确定要使用的功能集。
This processing occurs after the client authenticates and authorizes the request, but before the remainder of the general UAS processing described in Section 8.2.1 of RFC 3261.
此处理发生在客户端验证和授权请求之后，但在RFC 3261第8.2.1节所述的一般UAS处理的剩余部分之前。
If, after performing this processing, there are no URI left in the target set, the UA SHOULD reject the request with a 480 response. If there is a URI remaining (there was only one to begin with), the UA proceeds with request processing as per RFC 3261.
如果在执行此处理后，目标集中没有剩余URI，UA应以480响应拒绝该请求。如果还剩下一个URI（开始时只有一个），UA将按照RFC 3261进行请求处理。
Having a UAS perform the matching operations as if it were a proxy allows certain caller preferences to be honored, even if the proxy doesn't support the extension.
让UAS像代理一样执行匹配操作，即使代理不支持扩展，也可以满足某些调用方偏好。
A UAS SHOULD process any queue directive present in a Request-Disposition header field in the request. All other directives MUST be ignored.
UAS应处理请求中请求处置头字段中存在的任何队列指令。必须忽略所有其他指令。
Proxy behavior consists of two orthogonal sets of rules - one for processing the Request-Disposition header field, and one for processing the URI and feature set preferences in the Accept-Contact and Reject-Contact header fields.
代理行为由两组正交的规则组成——一组用于处理请求处置头字段，另一组用于处理接受联系人和拒绝联系人头字段中的URI和功能集首选项。
In addition to processing these headers, a proxy MAY add one if not present, or add a value to an existing header field, as if it were a UAC. This is useful for a proxy to request processing in downstream proxies in the implementation of a feature. However, a proxy MUST NOT modify or remove an existing header field value. This is particularly important when S/MIME is used. The message signature could include the caller preferences header fields, allowing the UAS to verify that, even though proxies may have added header fields, the original caller preferences were still present.
除了处理这些头，代理还可以在不存在时添加一个头，或者向现有头字段添加一个值，就像它是UAC一样。这对于代理在功能实现中请求下游代理中的处理非常有用。但是，代理不能修改或删除现有的标头字段值。这在使用S/MIME时尤为重要。消息签名可以包括呼叫者首选项标头字段，从而允许UAS验证，即使代理可能添加了标头字段，原始呼叫者首选项仍然存在。
If the request contains a Request-Disposition header field and it is the owner of the domain in the Request URI, the server SHOULD execute the directives as described in Section 9.1, unless it has local policy configured to direct it otherwise.
如果请求包含请求处置标头字段，并且它是请求URI中域的所有者，则服务器应执行第9.1节中所述的指令，除非已配置本地策略以指示它。
A proxy compliant to this specification MUST NOT apply the preferences matching operation described here to a request unless it is the owner of the domain in the request URI, and accessing a location service that has capabilities associated with request targets. However, if it is the owner of the domain, and accessing a location service that has capabilities associated with request targets, it SHOULD apply the processing described in this section. Typically, this is a proxy that is using a registration database to determine the request targets. However, if a proxy knows about capabilities through some other means, it SHOULD apply the processing defined here as well. If it does perform the processing, it MUST do so as described below.
符合此规范的代理不得将此处描述的首选项匹配操作应用于请求，除非它是请求URI中域的所有者，并访问具有与请求目标关联的功能的位置服务。但是，如果它是域的所有者，并且正在访问具有与请求目标关联的功能的位置服务，那么它应该应用本节中描述的处理。通常，这是一个使用注册数据库来确定请求目标的代理。但是，如果代理通过其他方式了解功能，那么它也应该应用此处定义的处理。如果它确实执行处理，则必须按照以下说明执行。
The processing is described through a conversion from the syntax described in this specification to RFC 2533 [2] syntax, followed by a matching operation and a sorting of resulting contact values. The usage of RFC 2533 syntax as an intermediate step is not required; it only serves as a useful tool to describe the behavior required of the proxy. A proxy can use any steps it likes, so long as the results are identical to the ones that would be achieved with the processing described here.
通过将本规范中描述的语法转换为RFC 2533[2]语法，然后进行匹配操作并对结果触点值进行排序来描述处理。不需要使用RFC2533语法作为中间步骤；它只是描述代理所需行为的有用工具。代理可以使用它喜欢的任何步骤，只要结果与使用本文描述的处理将实现的结果相同。
The first step in proxy processing is to extract explicit preferences. To do that, it looks for the Accept-Contact and Reject-Contact header fields.
代理处理的第一步是提取显式首选项。为此，它将查找接受联系人和拒绝联系人标题字段。
For each value of those header fields, it extracts the feature parameters. These are the header field parameters whose name is "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "extensions", "schemes", "application", "video", "language", "type", "isfocus", "actor", or "text", or whose name begins with a plus (+) [3]. The proxy converts all of those parameters to the syntax of RFC 2533, based on the rules in Section 8.
对于这些标题字段的每个值，它提取特征参数。这些是标题字段参数，其名称为“音频”、“自动机”、“类”、“双工”、“数据”、“控制”、“移动性”、“描述”、“事件”、“优先级”、“方法”、“扩展”、“方案”、“应用程序”、“视频”、“语言”、“类型”、“isfocus”、“参与者”或“文本”，或其名称以加号（+）[3]开头。根据第8节中的规则，代理将所有这些参数转换为RFC2533的语法。
The result will be a set of feature set predicates in conjunctive normal form, each of which is associated with one of the two preference header fields. If there was a req-parameter associated with a header field value in the Accept-Contact header field, the feature set predicate derived from that header field value is said to have its require flag set. Similarly, if there was an explicit-param associated with a header field value in the Accept-Contact header field, the feature set predicate derived from that header field value is said to have its explicit flag set.
结果将是一组合取范式的功能集谓词，每个谓词都与两个首选项头字段中的一个相关联。如果在Accept Contact标头字段中存在与标头字段值关联的req参数，则从该标头字段值派生的功能集谓词被称为设置了其require标志。类似地，如果在Accept Contact header字段中有一个与header字段值关联的显式参数，则从该header字段值派生的功能集谓词被称为设置了显式标志。
If, and only if, the proxy did not find any explicit preferences in the request (because there was no Accept-Contact or Reject-Contact header field), the proxy extracts implicit preferences. These preferences are ones implied by the presence of other information in the request.
如果且仅当代理在请求中未找到任何显式首选项（因为没有Accept Contact或Reject Contact标头字段），代理将提取隐式首选项。这些首选项是请求中存在其他信息所隐含的首选项。
First, the proxy creates a conjunction with no terms. This conjunction represents a feature set that will be associated with the Accept-Contact header field, as if it were included there. Note that there is no modification of the message implied - only an association for the purposes of processing. Furthermore, this feature set has its require flag set, but not its explicit flag.
首先，代理创建一个没有术语的连接词。此连词表示将与Accept Contact标头字段关联的功能集，就好像它包含在其中一样。请注意，没有对隐含的消息进行任何修改—只有用于处理的关联。此外，此功能集有其require标志集，但没有其显式标志。
The proxy then adds terms to the conjunction for the two implicit preference types below.
然后，代理将以下两种隐式首选项类型的术语添加到连接词中。
One implicit preference is the method. When a UAC sends a request with a specific method, it is an implicit preference to have the request routed only to UAs that support that method. To support this
一个隐含的偏好是方法。当UAC使用特定方法发送请求时，隐式偏好是将请求仅路由到支持该方法的UAs。支持这一点
implicit preference, the proxy adds a term to the conjunction of the following form:
隐式首选项，代理向以下形式的连词添加一个术语：
(sip.methods=[method of request])
（sip.methods=[请求方法]）
For requests that establish a subscription [5], the Event header field is another expression of an implicit preference. It expresses a desire for the request to be routed only to a server that supports the given event package. To support this implicit preference, the proxy adds a term to the conjunction of the following form:
对于建立订阅[5]的请求，事件头字段是隐式首选项的另一个表达式。它表达了只将请求路由到支持给定事件包的服务器的愿望。为了支持此隐式首选项，代理向以下形式的连词添加了一个术语：
(sip.events=[value of the Event header field])
（sip.events=[事件头字段的值]）
The proxy then takes each URI in the target set (the set of URI it is going to proxy or redirect to), and obtains its capabilities as an RFC 2533 formatted feature set predicate. This is called a contact predicate. If the target URI was obtained through a registration, the proxy computes the contact predicate by extracting the feature parameters from the Contact header field [3] and then converting them to a feature predicate. To extract the feature parameters, the proxy follows these steps:
然后，代理获取目标集中的每个URI（它将代理或重定向到的URI集），并获得其作为RFC2533格式的功能集谓词的功能。这称为接触谓词。如果目标URI是通过注册获得的，则代理通过从contact header字段[3]提取特征参数，然后将其转换为特征谓词来计算contact谓词。要提取特征参数，代理将执行以下步骤：
1. Create an initial, empty list of feature parameters.
1. 创建特征参数的初始空列表。
2. If the Contact URI parameters included the "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "schemes", "application", "video", "actor", "language", "isfocus", "type", "extensions", or "text" parameters, those are copied into the list.
2. 如果联系人URI参数包括“音频”、“自动机”、“类”、“双工”、“数据”、“控制”、“移动性”、“描述”、“事件”、“优先级”、“方法”、“方案”、“应用程序”、“视频”、“演员”、“语言”、“isfocus”、“类型”、“扩展名”或“文本”参数，则这些参数将复制到列表中。
3. If any Contact URI parameter name begins with a "+", it is copied into the list if the list does not already contain that name with the plus removed. In other words, if the "video" feature parameter is in the list, the "+video" parameter would not be placed into the list. This conflict should never arise if the client were compliant to [3], since it is illegal to use the + form for encoding of a feature tag in the base set.
3. 如果任何联系人URI参数名称以“+”开头，则如果列表中尚未包含该名称且加号已删除，则会将其复制到列表中。换句话说，如果“视频”功能参数在列表中，“+视频”参数将不会被放入列表中。如果客户机符合[3]，则永远不会出现此冲突，因为使用+形式对基集中的特征标记进行编码是非法的。
If the URI in the target set had no feature parameters, it is said to be immune to caller preference processing. This means that the URI is removed from the target set temporarily, the caller preferences processing described below is executed, and then the URI is added back in.
如果目标集中的URI没有特征参数，则称其不受调用方偏好处理的影响。这意味着从目标集中临时删除URI，执行下面描述的调用方首选项处理，然后将URI添加回目标集中。
Assuming the URI has feature parameters, they are converted to RFC 2533 syntax using the rules of Section 8.
假设URI具有特性参数，则使用第8节的规则将其转换为RFC2533语法。
The resulting predicate is associated with a q-value. If the contact predicate was learned through a REGISTER request, the q-value is equal to the q-value in the Contact header field parameter, else "1.0" if not specified.
结果谓词与q值关联。如果联系人谓词是通过寄存器请求读入的，则q值等于联系人标头字段参数中的q值，如果未指定，则为“1.0”。
As an example, consider the following registered Contact header field:
例如，考虑以下已注册的联系人头字段：
Contact: <sip:user@example.com>;audio;video;mobility="fixed";
+sip.message="TRUE";other-param=66372;
methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http"
Contact: <sip:user@example.com>;audio;video;mobility="fixed";
+sip.message="TRUE";other-param=66372;
methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http"
This would be converted into the following predicate:
这将转换为以下谓词：
(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.mobility=fixed)
(sip.message=TRUE)
(| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
(sip.methods=CANCEL) (sip.methods=ACK))
(| (sip.schemes=sip) (sip.schemes=http)))
(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.mobility=fixed)
(sip.message=TRUE)
(| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
(sip.methods=CANCEL) (sip.methods=ACK))
(| (sip.schemes=sip) (sip.schemes=http)))
Note that "other-param" was not considered a feature parameter, since it is neither a base tag nor did it begin with a leading +.
请注意，“other param”不被视为特征参数，因为它既不是基标记，也不是以前导+开头的。
It is important to note that the proxy does not have to know anything about the meaning of the feature tags that it is comparing in order to perform the matching operation. The rules for performing the comparison depend on syntactic hints present in the values of each feature tag. For example, a predicate such as:
需要注意的是，为了执行匹配操作，代理不必知道它正在比较的特征标记的任何含义。执行比较的规则取决于每个特征标记的值中存在的语法提示。例如，谓词，例如：
(foo>=4)
（foo>=4）
implies that the feature tag "foo" is a numeric value. The matching rules in RFC 2533 only require an implementation to know whether the feature tag is a numeric, token, or quoted string (booleans can be treated as tokens). Quoted strings are always matched using a case-sensitive matching operation. Tokens are matched using case-insensitive matching. These two cases are differentiated by the presence of angle brackets around the feature tag value. When these brackets are present (i.e., ;+sip.foo="<value>"), it implies case
表示功能标记“foo”是一个数值。RFC2533中的匹配规则只要求实现知道特征标记是数字、标记还是带引号的字符串（布尔值可以视为标记）。带引号的字符串始终使用区分大小写的匹配操作进行匹配。令牌使用不区分大小写的匹配进行匹配。这两种情况的区别在于特征标记值周围存在尖括号。当这些括号出现时（即；+sip.foo=“<value>”），表示大小写
sensitive string comparison. When they are not present, (i.e., (;+sip.bar="val"), it implies case insensitivity. Numerics are matched using normal mathematical comparisons.
敏感字符串比较。当它们不存在时，（即，（；+sip.bar=“val”），这意味着不区分大小写。使用正常的数学比较匹配数字。
First, the proxy applies the predicates associated with the Reject-Contact header field.
首先，代理应用与拒绝联系人头字段关联的谓词。
For each contact predicate, each Reject-Contact predicate (that is, each predicate associated with the Reject-Contact header field) is examined. If that Reject-Contact predicate contains a filter for a feature tag, and that feature tag is not present anywhere in the contact predicate, that Reject-Contact predicate is discarded for the processing of that contact predicate. If the Reject-Contact predicate is not discarded, it is matched with the contact predicate using the matching operation of RFC 2533 [2]. If the result is a match, the URI corresponding to that contact predicate is discarded from the target set.
对于每个联系人谓词，将检查每个拒绝联系人谓词（即，与拒绝联系人标题字段关联的每个谓词）。如果拒绝接触谓词包含功能标记的筛选器，并且该功能标记不存在于接触谓词中的任何位置，则拒绝接触谓词将被丢弃以处理该接触谓词。如果拒绝接触谓词未被丢弃，则使用RFC 2533[2]的匹配操作将其与接触谓词匹配。如果结果是匹配的，则从目标集中丢弃与该联系人谓词对应的URI。
The result is that Reject-Contact will only discard URIs where the UA has explicitly indicated support for the features that are not wanted.
结果是，Reject Contact只会丢弃UA明确表示支持不需要的功能的URI。
Next, the proxy applies the predicates associated with the Accept-Contact header field. For each contact that remains in the target set, the proxy constructs a matching set, Ms. Initially, this set contains all of the Accept-Contact predicates. Each of those predicates is examined. It is matched with the contact predicate using the matching operation of RFC 2533 [2]. If the result is not a match, and the Accept-Contact predicate had its require flag set, the URI corresponding to that contact predicate is discarded from the target set. If the result is not a match, but the Accept-Contact predicate did not have its require flag set, that contact URI is not discarded from the target set, however, the Accept-Contact predicate is removed from the matching set for that contact.
接下来，代理应用与Accept Contact头字段关联的谓词。对于保留在目标集中的每个联系人，代理将构造一个匹配集Ms。最初，该集包含所有Accept contact谓词。每个谓词都会被检查。使用RFC 2533[2]的匹配操作将其与接触谓词匹配。如果结果不匹配，并且Accept Contact谓词设置了其require标志，则与该Contact谓词对应的URI将从目标集中丢弃。如果结果不匹配，但Accept Contact谓词未设置其require标志，则不会从目标集中丢弃该联系人URI，但会从该联系人的匹配集中删除Accept Contact谓词。
For each contact that remains in the target set, the proxy computes a score for that contact against each predicate in the contact's matching set. Let the number of terms in the Accept-Contact predicate conjunction be equal to N. Each term in that predicate contains a single feature tag. If the contact predicate has a term containing that same feature tag, the score is incremented by 1/N. If the feature tag was not present in the contact predicate, the score remains unchanged. Based on these rules, the score can range between zero and one.
对于保留在目标集中的每个联系人，代理根据联系人匹配集中的每个谓词计算该联系人的分数。让Accept Contact谓词连接中的词条数等于N。该谓词中的每个词条都包含一个功能标记。如果联系人谓词有一个包含相同特征标记的术语，则分数将增加1/N。如果联系人谓词中不存在特征标记，则分数保持不变。根据这些规则，分数可以在0到1之间。
T
+----------> DROP Contact
|
|
/ \
/ \
T / \ F
+---->/require\------> Set score=0
| \ /
| \ /
/ \ \ /
/ \ \/
score<1 / \
+-------> /explicit----> Score unchanged
| \ / F
| \ /
/ \ \ /
/ \ \/
+--------+ / \
-->|Compute |--> /Score \ --------> Score unchanged
| Score | \ / score=1
+--------+ \ /
\ /
\/
T
+----------> DROP Contact
|
|
/ \
/ \
T / \ F
+---->/require\------> Set score=0
| \ /
| \ /
/ \ \ /
/ \ \/
score<1 / \
+-------> /explicit----> Score unchanged
| \ / F
| \ /
/ \ \ /
/ \ \/
+--------+ / \
-->|Compute |--> /Score \ --------> Score unchanged
| Score | \ / score=1
+--------+ \ /
\ /
\/
Figure 1: Applying the Score
图1：应用分数
The require and explicit tags are then applied, resulting in potential modification of the score and the target set. This process is summarized in Figure 1. If the score for the contact predicate against that Accept-Contact predicate was less than one, the Accept-Contact predicate had an explicit tag, and if the predicate also had a require tag, the Contact URI corresponding to that contact predicate is dropped. If, however, the predicate did not have a require tag, the score is set to zero. If there was no explicit tag, the score is unchanged.
然后应用require和explicit标记，从而可能修改分数和目标集。图1总结了这一过程。如果联系人谓词相对于该Accept contact谓词的得分小于1，则Accept contact谓词有一个显式标记，如果谓词也有一个require标记，则会删除与该联系人谓词对应的联系人URI。但是，如果谓词没有require标记，则分数设置为零。如果没有显式标记，则分数保持不变。
The next step is to combine the scores and the q-values associated with the predicates in the matching set, to arrive at an overall caller preference, Qa. For those URIs in the target set which remain, there will be a score which indicates its match against each Accept-Contact predicate in the matching set. If there are M Accept-Contact predicates in the matching set, there will be M scores S1 through SM, for each contact. The overall caller preference, Qa, is the arithmetic average of S1 through SM.
下一步是将分数和与匹配集中的谓词相关联的q值结合起来，以得到整体调用方偏好Qa。对于目标集中保留的那些URI，将有一个分数指示其与匹配集中的每个Accept Contact谓词的匹配。如果匹配集中有M个Accept Contact谓词，则每个联系人将有M个得分S1到SM。整体呼叫偏好Qa是S1到SM的算术平均值。
At this point, any URIs that were removed from the target set because they were immune from caller preferences are added back in, and Qa for that URI is set to 1.0.
此时，由于不受调用方首选项的影响而从目标集中删除的任何URI都会重新添加，并且该URI的Qa设置为1.0。
The purpose of the caller preference Qa is to provide an ordering for any contacts remaining in the target set, if the callee has not provided an ordering. To do this, the contacts remaining in the target set are sorted by the q-value provided by the callee. Once sorted, they are grouped into equivalence classes, such that all contacts with the same q-value are in the same equivalence class. Within each equivalence class, the contacts are then ordered based on their values of Qa. The result is an ordered list of contacts that is used by the proxy.
呼叫者首选项Qa的目的是在被呼叫者未提供排序的情况下，为目标集中剩余的任何联系人提供排序。为此，将根据被调用方提供的q值对目标集中剩余的联系人进行排序。排序后，将其分组为等效类，以便具有相同q值的所有触点都位于相同的等效类中。在每个等价类中，触点根据其Qa值进行排序。结果是代理使用的联系人的有序列表。
If there were no URIs in the target set after the application of the processing in this section, and the caller preferences were based on implicit preferences (Section 7.2.2), the processing in this section is discarded, and the original target set, ordered by their original q-values, is used.
如果在应用本节中的处理后，目标集中没有URI，并且调用方首选项基于隐式首选项（第7.2.2节），则丢弃本节中的处理，并使用按原始q值排序的原始目标集。
This handles the case where implicit preferences for the method or event packages resulted in the elimination of all potential targets. By going back to the original target set, those URIs will be tried, and result in the generation of a 405 or 489 response. The UAC can then use this information to try again, or report the error to the user. Without reverting to the original target set, the UAC would see a 480 response, and have no knowledge of why their request failed. Of course, the target set can also be empty after the application of explicit preferences. This will result in the generation of a 480 by the proxy. This behavior is acceptable, and indeed, desirable in the case of explicit preferences. When the caller makes an explicit preference, it is agreeing that its request might fail because of a preference mismatch. One might try to return an error indicating the capabilities of the callee, so that the caller could perhaps try again. However, doing so results in the leaking of potentially sensitive information to the caller without authorization from the callee, and therefore this specification does not provide a means for it.
这将处理方法或事件包的隐式首选项导致消除所有潜在目标的情况。通过返回原始目标集，将尝试这些URI，并生成405或489响应。然后UAC可以使用此信息重试，或向用户报告错误。如果不恢复到原始目标集，UAC将看到480响应，并且不知道其请求失败的原因。当然，在应用显式首选项后，目标集也可以为空。这将导致代理生成480。这种行为是可以接受的，事实上，在明确偏好的情况下是可取的。当调用方做出显式首选项时，它同意其请求可能由于首选项不匹配而失败。您可能会尝试返回一个指示被调用方功能的错误，以便调用方可以重试。但是，这样做会导致在未经被调用方授权的情况下将潜在的敏感信息泄漏给调用方，因此本规范不提供泄漏的方法。
If a proxy server is recursing, it adds the Contact header fields returned in the redirect responses to the target set, and re-applies the caller preferences algorithm.
如果代理服务器正在递归，它会将重定向响应中返回的联系人头字段添加到目标集，并重新应用调用方首选项算法。
If the server is redirecting, it returns all entries in the target set. It assigns q-values to those entries so that the ordering is identical to the ordering determined by the processing above. However, it MUST NOT include the feature parameters for the entries
如果服务器正在重定向，它将返回目标集中的所有条目。它为这些条目分配q值，以便排序与通过上述处理确定的排序相同。但是，它不得包括条目的特征参数
in the target set. If it did, the upstream proxy server would apply the same caller preferences once more, resulting in a double application of those preferences. If the redirect server does wish to include the feature parameters in the Contact header field, it MUST redirect using the original target set and original q-values, before the application of caller preferences.
在目标集中。如果这样做，上游代理服务器将再次应用相同的调用方首选项，从而导致双重应用这些首选项。如果重定向服务器确实希望在Contact header字段中包含功能参数，则在应用调用方首选项之前，它必须使用原始目标集和原始q值进行重定向。
Consider the following example, which is contrived but illustrative of the various components of the matching process. There are five registered Contacts for sip:user@example.com. They are:
考虑下面的例子，这是设计的，但说明了匹配过程的各个组件。sip有五个注册联系人：user@example.com. 他们是：
Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2
Contact: sip:u2@h.example.com;audio="FALSE";
methods="INVITE";actor="msg-taker";q=0.2
Contact: sip:u3@h.example.com;audio;actor="msg-taker";
methods="INVITE";video;q=0.3
Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2
Contact: sip:u5@h.example.com;q=0.5
Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2
Contact: sip:u2@h.example.com;audio="FALSE";
methods="INVITE";actor="msg-taker";q=0.2
Contact: sip:u3@h.example.com;audio;actor="msg-taker";
methods="INVITE";video;q=0.3
Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2
Contact: sip:u5@h.example.com;q=0.5
An INVITE sent to sip:user@example.com contained the following caller preferences header fields:
发送到sip的邀请：user@example.com包含以下调用方首选项标题字段：
Reject-Contact: *;actor="msg-taker";video
Accept-Contact: *;audio;require
Accept-Contact: *;video;explicit
Accept-Contact: *;methods="BYE";class="business";q=1.0
Reject-Contact: *;actor="msg-taker";video
Accept-Contact: *;audio;require
Accept-Contact: *;video;explicit
Accept-Contact: *;methods="BYE";class="business";q=1.0
There are no implicit preferences in this example, because explicit preferences are provided.
本例中没有隐式首选项，因为提供了显式首选项。
The proxy first removes u5 from the target set, since it is immune from caller preferences processing.
代理首先从目标集中删除u5，因为它不受调用方首选项处理的影响。
Next, the proxy processes the Reject-Contact header field. It is a match for all four remaining contacts, but only an explicit match for u3. That is because u3 is the only one that explicitly indicated support for video, and explicitly indicated it is a message taker. So, u3 gets discarded, and the others remain.
接下来，代理处理拒绝联系人标题字段。它与其余四个联系人都匹配，但仅与u3显式匹配。这是因为u3是唯一一个明确表示支持视频的，并且明确表示它是一个消息接收者。因此，u3被丢弃，其他的保留下来。
Next, each of the remaining three contacts is compared against each of the three Accept-Contact predicates. u1 is a match to all three, earning a score of 1.0 for the first two predicates, and 0.5 for the third (the methods feature tag was present in the contact predicate, but the class tag was not). u2 doesn't match the first predicate. Because that predicate has a require tag, u2 is discarded. u4 matches the first predicate, earning a score of 1.0. u4 matches the
接下来，将其余三个联系人中的每一个与三个Accept Contact谓词中的每一个进行比较。u1与所有三个谓词都匹配，前两个谓词的得分为1.0，第三个谓词的得分为0.5（contact谓词中存在methods功能标记，但class标记不存在）。u2与第一个谓词不匹配。因为该谓词有一个require标记，所以u2被丢弃。u4匹配第一个谓词，得到1.0分。u4与
second predicate, but since the match is not explicit (the score is 0.0, in fact), the score is set to zero (it was already zero, so nothing changes). u4 does not match the third predicate.
第二个谓词，但由于匹配不是显式的（事实上，分数是0.0），所以分数被设置为零（它已经是零了，所以没有任何变化）。u4与第三个谓词不匹配。
At this point, u1 and u4 remain. u1 matched all three Accept-Contact predicates, so its matching set contains all three, with scores of 1, 1, and 0.5. u4 matches the first two predicates, with scores of 1.0 and 0.0. Qa for u1 is 0.83 and Qa for u4 is 0.5. u5 is added back in with a Qa of 1.0.
此时，u1和u4保持不变。u1匹配了所有三个Accept-Contact谓词，因此其匹配集包含所有三个，分数分别为1、1和0.5。u4匹配前两个谓词，得分分别为1.0和0.0。u1的Qa为0.83，u4的Qa为0.5。u5以1.0的Qa重新添加。
Next, the remaining contacts in the target set are sorted by q-value. u5 has a value of 0.5, u1 has a q-value of 0.2 and so does u4. There are two equivalence classes. The first has a q-value of 0.5, and consists of just u5. Since there is only one member of the class, sorting within the class has no impact. The second equivalence class has a q-value of 0.2. Within that class, the two contacts, u1 and u4, are ordered based on their values of Qa. u1 has a Qa of 0.83, and u4, a Qa of 0.5. Thus, u1 comes first, followed by u4. The resulting overall ordered set of contacts in the target set is u5, u1, and then u4.
接下来，目标集中的其余触点按q值排序。u5的值为0.5，u1的q值为0.2，u4也是。有两个等价类。第一个值的q值为0.5，仅由u5组成。因为类只有一个成员，所以类内的排序没有影响。第二个等价类的q值为0.2。在该类别中，两个触点u1和u4根据其Qa值进行订购。u1的质量保证值为0.83，u4的质量保证值为0.5。因此，u1排在第一位，然后是u4。目标集中的触点的最终整体有序集是u5、u1，然后是u4。
Mapping between feature parameters and a feature set predicate, formatted according to the syntax of RFC 2533 [2], is trivial. It is just the opposite of the process described in Section 5 of [3].
根据RFC2533[2]的语法格式化的特征参数和特征集谓词之间的映射非常简单。这与[3]第5节中描述的过程正好相反。
Starting from a set of feature-param, the procedure is as follows. Construct a conjunction. Each term in the conjunction derives from one feature-param. If the feature-param has no value, it is equivalent, in terms of the processing which follows, as if it had a value of "TRUE".
从一组特征参数开始，步骤如下。构造一个连词。连词中的每个术语都源自一个特征参数。如果feature param没有值，则在随后的处理中，它是等效的，就好像它有一个值“TRUE”。
If the feature-param value is a tag-value-list, the element of the conjunction is a disjunction. There is one term in the disjunction for each tag-value in the tag-value-list.
如果特征参数值是标记值列表，则连接的元素是析取。对于标记值列表中的每个标记值，在析取中有一个术语。
Consider now the construction of a filter from a tag-value. If the tag-value starts with an exclamation mark (!), the filter is of the form:
现在考虑从标签值构造过滤器。如果标记值以感叹号（！）开头，则过滤器的形式为：
(! <filter from remainder>)
(! <filter from remainder>)
where "<filter from remainder>" refers to the filter that would be constructed from the tag-value if the exclamation mark had not been present.
其中“<filter from Requires>”指的是在感叹号不存在的情况下根据标记值构造的过滤器。
If the tag-value starts with an octothorpe (#), the filter is a numeric comparison. The comparator is either =, >=, <=, or a range based on the next characters in the phrase. If the next characters are =, >=, or <=, the filter is of the form:
如果标记值以八进制（#）开头，则过滤器是数字比较。比较器可以是=、>=、<=，也可以是基于短语中下一个字符的范围。如果下一个字符为=、>=、或<=，则过滤器的形式为：
(name comparator compare-value)
（名称比较器比较值）
where name is the name of the feature parameter after it has been decoded (see below), and the comparator is either =, >=, or <= depending of the initial characters in the phrase. If the remainder of the text in the tag-value after the equal contains a decimal point (implying a rational number), the decimal point is shifted right N times until it is an integer, I. Compare-value above is then set to "I / 10**N", where 10**N is the result of computing the number 10 to the Nth power.
其中name是特征参数解码后的名称（见下文），比较器为=、>=或<=取决于短语中的初始字符。如果标记值中等号后的剩余文本包含小数点（表示有理数），则小数点将右移N次，直到成为整数，I。然后将上面的比较值设置为“I/10**N”，其中10**N是计算数字10到N次方的结果。
If the value after the octothorpe is a number, the filter is a range. The format of the filter is:
如果octothorpe后面的值是一个数字，则过滤器是一个范围。过滤器的格式为：
(name=<remainder>)
(name=<remainder>)
where "name" is the feature-tag after it has been decoded (see below), and "<remainder>" is the remainder of the text in the tag-value after the #, with any decimal numbers converted to a rational form, and the colon replaced by a double dot (..).
其中，“name”是解码后的特征标记（见下文），“<rements>”是标记值中#之后的剩余文本，任何十进制数转换为有理形式，冒号替换为双点（..）。
If the tag-value does not begin with an octothorpe (it is a token-nobang or boolean), the filter is of the form:
如果标记值不是以octothorpe开头（它是标记nobang或boolean），则过滤器的形式为：
(name=tag-value)
（名称=标记值）
where name is the feature-tag after it has been decoded (see below).
其中name是解码后的功能标签（见下文）。
If the feature-param contains a string-value (based on the fact that it begins with a left angle bracket ("<") and ends with a right angle bracket (">")), the filter is of the form:
如果feature param包含字符串值（基于它以左尖括号（“<”）开始，以右尖括号（“>”）结束的事实），则过滤器的形式为：
(name="qdtext")
（name=“qdtext”）
Note the explicit usage of quotes around the qdtext, which indicate that the value is a string. In RFC 2533, strings are compared using case sensitive rules, and tokens are compared using case insensitive rules.
请注意，qdtext周围显式使用了引号，表示该值是一个字符串。在RFC2533中，字符串使用区分大小写的规则进行比较，令牌使用不区分大小写的规则进行比较。
Feature tags, as specified in RFC 2506 [13], cannot be directly represented as header field parameters in the Contact, Accept-Contact, and Reject-Contact header fields. This is due to an inconsistency in the grammars, and in the need to differentiate
RFC 2506[13]中规定的特征标记不能直接表示为联系人、接受联系人和拒绝联系人标题字段中的标题字段参数。这是因为语法不一致，需要区分
feature parameters from parameters used by other extensions. As such, feature tag values are encoded from RFC 2506 format to yield an enc-feature-tag, and then are decoded into RFC 2506 format. The decoding process is simple. If there is a leading plus (+) sign, it is removed. Any exclamation point (!) is converted to a colon (:) and any single quote (') is converted to a forward slash (/). If there was no leading plus sign, and the remainder of the encoded name was "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "schemes", "application", "video", "actor", "isfocus", "extensions" or "text", the prefix "sip." is added to the remainder of the encoded name to compute the feature tag name.
其他扩展使用的参数中的特征参数。同样地，从RFC 2506格式对特征标签值进行编码以产生enc特征标签，然后解码为RFC 2506格式。解码过程很简单。如果有前导加号（+），则将其删除。任何感叹号（！）都将转换为冒号（：），任何单引号（'）都将转换为正斜杠（/）。如果没有前导加号，编码名称的其余部分是“音频”、“自动机”、“类”、“双工”、“数据”、“控制”、“移动性”、“描述”、“事件”、“优先级”、“方法”、“方案”、“应用程序”、“视频”、“演员”、“isfocus”、“扩展”或“文本”，则前缀为“sip”添加到编码名称的其余部分以计算要素标记名称。
As an example, the Accept-Contact header field:
例如，接受联系人标题字段：
Accept-Contact:*;mobility="fixed"
;events="!presence,message-summary"
;language="en,de";description="<PC>";+sip.newparam
;+rangeparam="#-4:+5.125"
Accept-Contact:*;mobility="fixed"
;events="!presence,message-summary"
;language="en,de";description="<PC>";+sip.newparam
;+rangeparam="#-4:+5.125"
would be converted to the following feature predicate:
将转换为以下功能谓词：
(& (sip.mobility=fixed)
(| (! (sip.events=presence)) (sip.events=message-summary))
(| (language=en) (language=de))
(sip.description="PC")
(sip.newparam=TRUE)
(rangeparam=-4..5125/1000))
(& (sip.mobility=fixed)
(| (! (sip.events=presence)) (sip.events=message-summary))
(| (language=en) (language=de))
(sip.description="PC")
(sip.newparam=TRUE)
(rangeparam=-4..5125/1000))
This specification defines three new header fields - Accept-Contact, Reject-Contact, and Request-Disposition.
该规范定义了三个新的头字段-接受联系人、拒绝联系人和请求处理。
Figure 2 and Figure 3 are an extension of Tables 2 and 3 in RFC 3261 [1] for the Accept-Contact, Reject-Contact, and Request-Disposition header fields. The column "INF" is for the INFO method [6], "PRA" is for the PRACK method [7], "UPD" is for the UPDATE method [8], "SUB" is for the SUBSCRIBE method [5], "NOT" is for the NOTIFY method [5], "MSG" is for the MESSAGE method [9], and "REF" is for the REFER method [10].
图2和图3是RFC 3261[1]中表2和表3的扩展，用于Accept Contact、Reject Contact和Request Disposition header字段。列“INF”表示INFO方法[6]，“PRA”表示PRACK方法[7]，“UPD”表示UPDATE方法[8]，“SUB”表示SUBSCRIBE方法[5]，“NOT”表示NOTIFY方法[5]，“MSG”表示MESSAGE方法[9]，“REF”表示REFER方法[10]。
Header field where proxy ACK BYE CAN INV OPT REG
代理确认BYE可以进行INV OPT REG的标头字段
Accept-Contact R ar o o o o o - Reject-Contact R ar o o o o o - Request-Disposition R ar o o o o o o
接受联系人R ar o o o-拒绝联系人R ar o o o-请求处理R ar o o o o
Figure 2: Accept-Contact, Reject-Contact, and Request-Disposition header fields
图2：接受联系人、拒绝联系人和请求处理头字段
Header field where proxy PRA UPD SUB NOT INF MSG REF
头字段，其中代理PRA UPD SUB不是INF MSG REF
Accept-Contact R ar o o o o o o o Reject-Contact R ar o o o o o o o Request-Disposition R ar o o o o o o o
接受联系人R ar o o o o o拒绝联系人R ar o o o o o o o请求处理R ar o o o o o o o o
Figure 3: Accept-Contact, Reject-Contact, and Request-Disposition header fields
图3：接受联系人、拒绝联系人和请求处理头字段
The Request-Disposition header field specifies caller preferences for how a server should process a request. Its value is a list of tokens, each of which specifies a particular directive. Its syntax is specified in Section 10. Note that a compact form, using the letter d, has been defined. The directives are grouped into types. There can only be one directive of each type per request (e.g., you cannot have both "proxy" and "redirect" in the same Request-Disposition header field).
Request Disposition header字段指定服务器应如何处理请求的调用方首选项。它的值是一个令牌列表，每个令牌指定一个特定的指令。第10节规定了其语法。注意，已经定义了使用字母d的紧凑形式。指令被分组为不同的类型。每个请求的每种类型只能有一个指令（例如，在同一请求处置头字段中不能同时有“proxy”和“redirect”）。
When the caller specifies a directive, the server SHOULD honor that directive.
当调用方指定指令时，服务器应遵守该指令。
The following types of directives are defined:
定义了以下类型的指令：
proxy-directive: This type of directive indicates whether the caller would like each server to proxy ("proxy") or redirect ("redirect").
代理指令：这类指令指示调用者是希望每个服务器代理（“代理”）还是重定向（“重定向”）。
cancel-directive: This type of directive indicates whether the caller would like each proxy server to send a CANCEL request downstream ("cancel") in response to a 200 OK from the downstream server (which is the normal mode of operation, making it redundant), or whether this function should be left to the caller ("no-cancel"). If a proxy receives a request with this parameter set to "no-cancel", it SHOULD NOT CANCEL any outstanding branches upon receipt of a 2xx. However, it would still send CANCEL on any outstanding branches upon receipt of a 6xx.
cancel指令：此类指令指示调用方是否希望每个代理服务器向下游发送取消请求（“取消”），以响应来自下游服务器的200 OK（这是正常操作模式，使其成为冗余），或者该功能是否应留给调用方（“无取消”）。如果代理收到此参数设置为“no cancel”的请求，则在收到2xx请求后不应取消任何未完成的分支。然而，在收到6xx后，它仍将发送取消任何未结分行的通知。
fork-directive: This type of directive indicates whether a proxy should fork a request ("fork"), or proxy to only a single address ("no-fork"). If the server is requested not to fork, the server SHOULD proxy the request to the "best" address (generally the one with the highest q-value). If there are multiple addresses with the highest q-value, the server chooses one based on its local policy. The directive is ignored if "redirect" has been requested.
fork指令：这种类型的指令指示代理是应该将请求（“fork”）分叉，还是只将代理分叉到单个地址（“no fork”）。如果服务器被请求不分叉，服务器应该将请求代理到“最佳”地址（通常是q值最高的地址）。如果有多个具有最高q值的地址，服务器将根据其本地策略选择一个。如果已请求“重定向”，则忽略该指令。
recurse-directive: This type of directive indicates whether a proxy server receiving a 3xx response should send requests to the addresses listed in the response ("recurse"), or forward the list of addresses upstream towards the caller ("no-recurse"). The directive is ignored if "redirect" has been requested.
recurse指令：这类指令指示接收3xx响应的代理服务器是否应向响应中列出的地址发送请求（“recurse”），或向调用方转发上游地址列表（“no recurse”）。如果已请求“重定向”，则忽略该指令。
parallel-directive: For a forking proxy server, this type of directive indicates whether the caller would like the proxy server to proxy the request to all known addresses at once ("parallel"), or go through them sequentially, contacting the next address only after it has received a non-2xx or non-6xx final response for the previous one ("sequential"). The directive is ignored if "redirect" has been requested.
parallel指令：对于分叉代理服务器，此类指令指示调用方是否希望代理服务器将请求一次代理到所有已知地址（“parallel”），或按顺序处理请求，仅在收到前一个地址的非2xx或非6xx最终响应后才与下一个地址联系(“顺序”）。如果已请求“重定向”，则忽略该指令。
queue-directive: If the called party is temporarily unreachable, e.g., because it is in another call, the caller can indicate that it wants to have its call queued ("queue") or rejected immediately ("no-queue"). If the call is queued, the server returns "182 Queued". A queued call can be terminated as described in [1].
队列指令：如果被叫方暂时无法访问，例如，因为它在另一个呼叫中，则调用者可以指示它希望将其呼叫排队（“队列”）或立即拒绝（“无队列”）。如果呼叫已排队，服务器将返回“182排队”。排队呼叫可以按[1]中所述终止。
Example:
例子：
Request-Disposition: proxy, recurse, parallel
请求处理：代理、递归、并行
The set of request disposition directives is not extensible on purpose. This is to avoid a proliferation of new extensions to SIP that are "tunneled" through this header field.
请求处置指令集不可扩展。这是为了避免通过此标头字段“隧道化”的SIP新扩展的激增。
The syntax for these header fields is described in Section 10. A compact form, with the letter a, has been defined for the Accept-Contact header field, and with the letter j for the Reject-Contact header field.
第10节介绍了这些标题字段的语法。已为Accept Contact header字段定义了字母A的压缩表单，并为Reject Contact header字段定义了字母j。
The BNF for the Request-Disposition header field is:
请求处置标头字段的BNF为：
Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON
directive *(COMMA directive)
directive = proxy-directive / cancel-directive /
fork-directive / recurse-directive /
parallel-directive / queue-directive
proxy-directive = "proxy" / "redirect"
cancel-directive = "cancel" / "no-cancel"
fork-directive = "fork" / "no-fork"
recurse-directive = "recurse" / "no-recurse"
parallel-directive = "parallel" / "sequential"
queue-directive = "queue" / "no-queue"
Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON
directive *(COMMA directive)
directive = proxy-directive / cancel-directive /
fork-directive / recurse-directive /
parallel-directive / queue-directive
proxy-directive = "proxy" / "redirect"
cancel-directive = "cancel" / "no-cancel"
fork-directive = "fork" / "no-fork"
recurse-directive = "recurse" / "no-recurse"
parallel-directive = "parallel" / "sequential"
queue-directive = "queue" / "no-queue"
The BNF for the Accept-Contact and Reject-Contact header fields is:
接受联系人和拒绝联系人标题字段的BNF为：
Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value
*(COMMA ac-value)
Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value
*(COMMA rc-value)
ac-value = "*" *(SEMI ac-params)
rc-value = "*" *(SEMI rc-params)
ac-params = feature-param / req-param
/ explicit-param / generic-param
;;feature param from RFC 3840
;;generic-param from RFC 3261
rc-params = feature-param / generic-param
req-param = "require"
explicit-param = "explicit"
Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value
*(COMMA ac-value)
Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value
*(COMMA rc-value)
ac-value = "*" *(SEMI ac-params)
rc-value = "*" *(SEMI rc-params)
ac-params = feature-param / req-param
/ explicit-param / generic-param
;;feature param from RFC 3840
;;generic-param from RFC 3261
rc-params = feature-param / generic-param
req-param = "require"
explicit-param = "explicit"
Despite the BNF, there MUST NOT be more than one req-param or explicit-param in an ac-params. Furthermore, there can only be one instance of any feature tag in feature-param.
尽管有BNF，但ac参数中不能有多个req参数或显式参数。此外，在feature param中，任何feature标记只能有一个实例。
The presence of caller preferences in a request has an effect on the ways in which the request is handled at a server. As a result, requests with caller preferences SHOULD be integrity-protected with the sips mechanism specified in RFC 3261, Section 26.
请求中是否存在调用方首选项会影响服务器处理请求的方式。因此，具有调用者首选项的请求应使用RFC 3261第26节中指定的sips机制进行完整性保护。
Processing of caller preferences requires set operations and searches which can require some amount of computation. This enables a DOS attack whereby a user can send requests with substantial numbers of
处理调用方首选项需要设置操作和搜索，这可能需要一些计算量。这使得DOS攻击成为可能，用户可以通过此攻击发送大量请求
caller preferences, in the hopes of overloading the server. To counter this, servers SHOULD reject requests with too many rules. A reasonable number is around 20.
调用方首选项，希望服务器过载。为了解决这个问题，服务器应该拒绝规则太多的请求。一个合理的数字大约是20。
This specification registers three new SIP header fields, according to the process of RFC 3261 [1].
根据RFC 3261[1]的过程，本规范注册了三个新的SIP头字段。
The following is the registration for the Accept-Contact header field:
以下是接受联系人标题字段的注册：
RFC Number: RFC 3841
RFC编号：RFC 3841
Header Field Name: Accept-Contact
标题字段名称：接受联系人
Compact Form: a
紧凑型：a
The following is the registration for the Reject-Contact header field:
以下是拒绝联系人标题字段的注册：
RFC Number: RFC 3841
RFC编号：RFC 3841
Header Field Name: Reject-Contact
标题字段名称：拒绝联系人
Compact Form: j
紧凑型：j
The following is the registration for the Request-Disposition header field:
以下是请求处置标头字段的注册：
RFC Number: RFC 3841
RFC编号：RFC 3841
Header Field Name: Request-Disposition
标题字段名称：请求处置
Compact Form: d
紧凑表格：d
The initial set of media feature tags used by this specification were influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty provided helpful comments. Graham Klyne provided assistance on the usage of RFC 2533.
本规范使用的媒体功能标签的初始集受Scott Petrack的CMA设计的影响。Jonathan Lennox、Bob Penfield、Ben Campbell、Mary Barnes、Rohan Mahy和John Hearty提供了有益的评论。Graham Klyne就RFC 2533的使用提供了帮助。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[2] Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[3] Rosenberg, J., Schulzrinne, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[3] Rosenberg，J.，Schulzrinne，J.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[8] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[9] Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[10] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[10] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[11] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[11] Lennox，J.和H.Schulzrinne，“呼叫处理语言框架和需求”，RFC 28242000年5月。
[12] Rosenberg, J., "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Work in Progress, November 2002.
[12] Rosenberg，J.，“会话启动协议（SIP）扩展作者指南”，正在进行的工作，2002年11月。
[13] Holtman, K., Muntz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[13] Holtman，K.，Muntz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年3月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg dynamicsoft 600美国新泽西州帕西帕尼拉尼德斯广场07054
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
Henning Schulzrinne哥伦比亚大学M/S 0401 1214美国纽约州阿姆斯特丹大道10027号
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US
Paul Kyzivat Cisco Systems 1414马萨诸塞大道BXB500 C2-2美国马萨诸塞州Boxboro 01719
EMail: pkyzivat@cisco.com
EMail: pkyzivat@cisco.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。