Network Working Group J. Rosenberg
Request for Comments: 4596 P. Kyzivat
Category: Informational Cisco Systems
July 2006
Network Working Group J. Rosenberg
Request for Comments: 4596 P. Kyzivat
Category: Informational Cisco Systems
July 2006
Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension
会话启动协议（SIP）呼叫方首选项扩展的使用指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.
本文档包含会话启动协议（SIP）的调用方首选项扩展的使用指南。它通过具体的示例应用程序演示了调用方首选项的好处，提供了显示正确操作的用例，提供了注册特征标记适用性的指导，并描述了RFC 3841第7.2节中规定的首选项和功能匹配算法的简单实现。
Table of Contents
目录
1. Introduction ....................................................4
2. Motivations for Caller Preferences ..............................5
2.1. One-Number .................................................7
2.2. Direct-to-Voicemail ........................................7
3. Caller Preference Use Cases .....................................8
3.1. Routing of INVITE and MESSAGE to Different UA ..............8
3.1.1. Desired Behavior ....................................8
3.1.2. Solution ............................................9
3.2. Single Contact Not Matching Implicit Preferences ..........10
3.2.1. Desired Behavior ...................................10
3.2.2. Solution ...........................................10
3.3. Package-Based Routing .....................................11
3.3.1. Desired Behavior ...................................11
3.3.2. Solution ...........................................11
3.4. Package Routing II ........................................12
3.4.1. Desired Behavior ...................................12
3.4.2. Solution ...........................................13
3.5. Audio/Video vs. Audio Only ................................13
3.5.1. Desired Behavior ...................................13
3.5.2. Solution ...........................................14
3.6. Forcing Audio/Video .......................................15
3.6.1. Desired Behavior ...................................15
3.6.2. Solution ...........................................15
3.7. Third-Party Call Control: Forcing Media ...................16
3.7.1. Desired Behavior ...................................16
3.7.2. Solution ...........................................16
3.8. Maximizing Media Overlaps .................................17
3.8.1. Desired Behavior ...................................17
3.8.2. Solution ...........................................17
3.9. Multilingual Lines ........................................18
3.9.1. Desired Behavior ...................................18
3.9.2. Solution ...........................................19
3.10. I Hate Voicemail! ........................................20
3.10.1. Desired Behavior ..................................20
3.10.2. Solution ..........................................20
3.11. I Hate People! ...........................................21
3.11.1. Desired Behavior ..................................21
3.11.2. Solution ..........................................21
3.12. Prefer Voicemail .........................................22
3.12.1. Desired Behavior ..................................22
3.12.2. Solution ..........................................22
3.13. Routing to an Executive ..................................22
3.13.1. Desired Behavior ..................................22
3.13.2. Solution ..........................................22
1. Introduction ....................................................4
2. Motivations for Caller Preferences ..............................5
2.1. One-Number .................................................7
2.2. Direct-to-Voicemail ........................................7
3. Caller Preference Use Cases .....................................8
3.1. Routing of INVITE and MESSAGE to Different UA ..............8
3.1.1. Desired Behavior ....................................8
3.1.2. Solution ............................................9
3.2. Single Contact Not Matching Implicit Preferences ..........10
3.2.1. Desired Behavior ...................................10
3.2.2. Solution ...........................................10
3.3. Package-Based Routing .....................................11
3.3.1. Desired Behavior ...................................11
3.3.2. Solution ...........................................11
3.4. Package Routing II ........................................12
3.4.1. Desired Behavior ...................................12
3.4.2. Solution ...........................................13
3.5. Audio/Video vs. Audio Only ................................13
3.5.1. Desired Behavior ...................................13
3.5.2. Solution ...........................................14
3.6. Forcing Audio/Video .......................................15
3.6.1. Desired Behavior ...................................15
3.6.2. Solution ...........................................15
3.7. Third-Party Call Control: Forcing Media ...................16
3.7.1. Desired Behavior ...................................16
3.7.2. Solution ...........................................16
3.8. Maximizing Media Overlaps .................................17
3.8.1. Desired Behavior ...................................17
3.8.2. Solution ...........................................17
3.9. Multilingual Lines ........................................18
3.9.1. Desired Behavior ...................................18
3.9.2. Solution ...........................................19
3.10. I Hate Voicemail! ........................................20
3.10.1. Desired Behavior ..................................20
3.10.2. Solution ..........................................20
3.11. I Hate People! ...........................................21
3.11.1. Desired Behavior ..................................21
3.11.2. Solution ..........................................21
3.12. Prefer Voicemail .........................................22
3.12.1. Desired Behavior ..................................22
3.12.2. Solution ..........................................22
3.13. Routing to an Executive ..................................22
3.13.1. Desired Behavior ..................................22
3.13.2. Solution ..........................................22
3.14. Speak to the Executive ...................................23
3.14.1. Desired Behavior ..................................23
3.14.2. Solution ..........................................24
3.15. Mobile Phone Only ........................................24
3.15.1. Desired Behavior ..................................24
3.15.2. Solution ..........................................24
3.16. Simultaneous Languages ...................................25
3.16.1. Desired Behavior ..................................25
3.16.2. Solution ..........................................25
3.17. The Number You Have Called... ............................26
3.17.1. Desired Behavior ..................................26
3.17.2. Solution ..........................................26
3.18. The Number You Have Called, Take Two .....................27
3.18.1. Desired Behavior ..................................27
3.18.2. Solution ..........................................27
3.19. Forwarding to a Colleague ................................28
3.19.1. Desired Behavior ..................................28
3.19.2. Solution ..........................................28
4. Capability Use Cases ...........................................30
4.1. Web Redirect ..............................................30
4.2. Voicemail Icon ............................................30
5. Usage of the Feature Tags ......................................31
5.1. Traditional Cell Phone ....................................31
5.2. Traditional Work Phone ....................................32
5.3. PC Messaging Application ..................................32
5.4. Standalone Videophone .....................................33
6. Example of Implementation of Preference and Capability
Matching .......................................................33
6.1. Extracting a Feature Set from a Header ....................34
6.2. Extracting Values from a Feature Parameter ................35
6.3. Comparing Two Value-Ranges ................................36
6.4. Feature Set to Feature Set Matching .......................36
6.5. Selecting and Ordering Contacts Based on Caller
Preferences ...............................................37
6.5.1. Reject-Contact Processing ..........................37
6.5.2. Accept-Contact Processing ..........................37
7. Security Considerations ........................................38
8. Acknowledgements ...............................................38
9. Informative References .........................................38
3.14. Speak to the Executive ...................................23
3.14.1. Desired Behavior ..................................23
3.14.2. Solution ..........................................24
3.15. Mobile Phone Only ........................................24
3.15.1. Desired Behavior ..................................24
3.15.2. Solution ..........................................24
3.16. Simultaneous Languages ...................................25
3.16.1. Desired Behavior ..................................25
3.16.2. Solution ..........................................25
3.17. The Number You Have Called... ............................26
3.17.1. Desired Behavior ..................................26
3.17.2. Solution ..........................................26
3.18. The Number You Have Called, Take Two .....................27
3.18.1. Desired Behavior ..................................27
3.18.2. Solution ..........................................27
3.19. Forwarding to a Colleague ................................28
3.19.1. Desired Behavior ..................................28
3.19.2. Solution ..........................................28
4. Capability Use Cases ...........................................30
4.1. Web Redirect ..............................................30
4.2. Voicemail Icon ............................................30
5. Usage of the Feature Tags ......................................31
5.1. Traditional Cell Phone ....................................31
5.2. Traditional Work Phone ....................................32
5.3. PC Messaging Application ..................................32
5.4. Standalone Videophone .....................................33
6. Example of Implementation of Preference and Capability
Matching .......................................................33
6.1. Extracting a Feature Set from a Header ....................34
6.2. Extracting Values from a Feature Parameter ................35
6.3. Comparing Two Value-Ranges ................................36
6.4. Feature Set to Feature Set Matching .......................36
6.5. Selecting and Ordering Contacts Based on Caller
Preferences ...............................................37
6.5.1. Reject-Contact Processing ..........................37
6.5.2. Accept-Contact Processing ..........................37
7. Security Considerations ........................................38
8. Acknowledgements ...............................................38
9. Informative References .........................................38
The Session Initiation Protocol (SIP) [1] extension for Callee Capabilities [2] describes mechanisms that allow a UA (User Agent) to register its capabilities in a REGISTER request. A caller can express preferences, either explicitly or implicitly, about how that request is to be handled. This is accomplished with the Accept-Contact and Reject-Contact header fields described in Caller Preferences for the Session Initiation Protocol[3].
被呼叫方能力的会话启动协议（SIP）[1]扩展[2]描述了允许UA（用户代理）在注册请求中注册其能力的机制。调用方可以显式或隐式地表示有关如何处理该请求的首选项。这是通过会话启动协议[3]的调用者首选项中描述的接受联系人和拒绝联系人头字段实现的。
The caller preferences extension can serve as a useful tool for supporting many applications. However, its generality makes it difficult to use correctly and effectively in any one situation. To remedy that, this document serves as a compendium of examples of the usage of the caller preferences extension.
调用方首选项扩展可以作为支持许多应用程序的有用工具。然而，它的通用性使得它难以在任何一种情况下正确有效地使用。为了弥补这一点，本文将作为调用方首选项扩展使用示例的概要。
NOTE: This document is intended to assist the reader in understanding RFCs 3840 and 3841. It is not intended to serve as a substitute for reading those documents. The examples presented in this document cannot be fully understood without awareness of the mechanisms defined in RFCs 3840 and 3841.
注：本文件旨在帮助读者理解RFCs 3840和3841。其目的不是代替阅读这些文件。如果不了解RFCs 3840和3841中定义的机制，则无法完全理解本文件中的示例。
First, Section 2 demonstrates the benefits of using caller preferences by describing several concrete applications that are enabled by the extension. Section 3 describes a set of detailed use cases for expressing caller preferences. Each use case presents a situation, describes how caller preferences can be used to handle the requirements for the situation, and verifies that the desired behavior occurs by showing the results of the matching operation. These use cases validate that the caller preferences specification is complete and capable of meeting a specific set of requirements. Since the caller preferences specification predates the SIP change process [4], no requirements document was ever published for it. To some degree, this document "backfills" requirements. However, this is not an academic exercise only, since the use cases described here did result in changes in the caller preferences document as it evolved. These use cases also help implementors figure out how to use caller preferences in their own applications.
首先，第2节通过描述扩展所支持的几个具体应用程序来演示使用调用方首选项的好处。第3节描述了一组用于表示调用方偏好的详细用例。每个用例表示一种情况，描述如何使用调用方首选项来处理该情况的需求，并通过显示匹配操作的结果来验证所需的行为是否发生。这些用例验证调用方首选项规范是否完整，是否能够满足一组特定的需求。由于调用方首选项规范早于SIP更改过程[4]，因此从未发布过针对它的需求文档。在某种程度上，本文件“回填”了要求。然而，这不仅仅是一个学术练习，因为这里描述的用例确实导致了调用方首选项文档的变化。这些用例还帮助实现者弄清楚如何在自己的应用程序中使用调用方首选项。
Section 4 discusses applications for the callee capabilities specification. Section 5 discusses the example registrations of the feature tags described in [2]. Proper usage of the caller preferences extension depends on proper interpretation of the semantics of these tags. More detail is provided on the tags, and example registrations are included that show typical usage.
第4节讨论被调用方能力规范的应用程序。第5节讨论了[2]中描述的特征标签的注册示例。调用方首选项扩展的正确使用取决于对这些标记的语义的正确解释。标签上提供了更多详细信息，并包含了显示典型用法的示例注册。
Section 6 outlines an implementation approach to the matching algorithm that doesn't require RFC 2533 [6] to be implemented in all its generality.
第6节概述了匹配算法的一种实现方法，该方法不需要在所有通用性方面实现RFC 2533[6]。
At its core, SIP is a protocol that facilitates rendezvous of users. The caller and callee need to meet up in order to exchange session information, so that they may communicate. The rendezvous process is complicated by the fact that a user has multiple points of attachment to the network. A called user (callee) can have a cell phone, a PDA, a work phone, a home phone, and one of several PC-based communications applications. When someone calls that user, to which of these devices is the call routed?
SIP的核心是一种便于用户会合的协议。调用者和被调用者需要会面，以便交换会话信息，以便进行通信。由于用户在网络上有多个连接点，因此会合过程非常复杂。被叫用户（被叫方）可以有一部手机、一部PDA、一部工作电话、一部家庭电话和几种基于PC的通信应用程序之一。当有人呼叫该用户时，呼叫路由到这些设备中的哪一个？
Certainly, the call can be routed to all of them at the same time, a process known as parallel forking. However, that is not always the desired behavior. Users may prefer that their registered devices be tried in a particular order. As an example, a user might prefer that his cell phone ring first, and if no one answers, that his work phone ring next. Another user might prefer that her cell phone ring first, and then her home and work phones ring at the same time, and then, if no one answers either of those, that the call be forwarded to voicemail. These variations are all referred to as find-me/ follow-me features.
当然，可以同时将调用路由到所有这些节点，这一过程称为并行分叉。然而，这并不总是理想的行为。用户可能更希望按特定顺序试用其注册的设备。例如，用户可能希望他的手机先响，如果没有人接听，那么他的工作电话接着响。另一个用户可能希望她的手机先响，然后她的家庭和工作电话同时响，然后，如果没有人接听这两个电话中的任何一个，则将呼叫转接到语音信箱。这些变体都称为“查找我/跟随我”功能。
SIP supports find-me/follow-me features in many ways. The most basic is through the SIP registration process. Each device at which a user can be contacted registers to the network. This registration associates the device with the canonical name of the user, called the address-of-record (AOR), which is a SIP URI. Each registration can include a preference value, indicating the relative preference for receiving calls at that device, compared to other devices. When someone makes a call to the AOR, proxies compliant to RFC 3261 will try the registered devices in order of preference, unless administrative policy overrides user preferences.
SIP以多种方式支持查找我/跟踪我功能。最基本的是通过SIP注册过程。每个可以联系用户的设备都注册到网络。此注册将设备与用户的规范名称关联，称为记录地址（AOR），这是一个SIPURI。每个注册可以包括一个偏好值，指示与其他设备相比，在该设备上接收呼叫的相对偏好。当有人呼叫AOR时，符合RFC 3261的代理将按照首选顺序尝试注册的设备，除非管理策略覆盖用户首选项。
Preference values in SIP registrations can only provide basic find-me/follow-me features. To support more complex features, the Call Processing Language (CPL) [5] has been specified. It is an XML script that provides specific call routing instructions. Users can upload these scripts to the network, instructing the servers how calls should be routed. As an example, a CPL script can instruct a proxy to route a call to the work phone during work hours (9 am - 5 pm) and then to the cell phone after hours, unless the call is from a family member, in which case it always goes to the cell phone.
SIP注册中的首选项值只能提供基本的查找/跟踪功能。为了支持更复杂的功能，指定了调用处理语言（CPL）[5]。它是一个XML脚本，提供特定的呼叫路由指令。用户可以将这些脚本上传到网络，指示服务器如何路由呼叫。例如，CPL脚本可以指示代理在工作时间（上午9点到下午5点）将呼叫路由到工作电话，然后在工作时间之后再路由到手机，除非呼叫来自家庭成员，在这种情况下，呼叫总是转到手机。
It is important to note that both CPL scripts and preference values in registrations describe operation of a service from the perspective of the called party. That is, they describe how a call made to the called party should be routed by the network. However, the called party is not the only one with preferences. A caller will also have preferences for how they want their call to be routed. As an example, a caller will often want to reach a user on their cell phone. In the current telephone network, this is accomplished by requiring a user to have a separate number for each device. This way, when a caller wishes to reach the cell phone, they dial the number for the cell phone. This requires users to maintain lists of potential reach numbers for a user, and then select the appropriate one. A far better approach is for a user to maintain a single address-of-record. When someone wishes to reach them on their cell phone, they call the AOR, but indicate a preference for the call to be routed to the cell phone.
需要注意的是，CPL脚本和注册中的首选项值都从被叫方的角度描述了服务的操作。也就是说，它们描述了向被叫方发出的呼叫应如何通过网络路由。然而，被叫方并不是唯一有偏好的一方。呼叫者也会有他们想要如何路由呼叫的首选项。例如，打电话的人通常希望通过手机与用户取得联系。在当前的电话网络中，这是通过要求用户为每个设备拥有一个单独的号码来实现的。这样，当打电话的人想要打到手机时，他们就会拨手机号码。这要求用户维护用户的潜在到达号码列表，然后选择适当的号码。更好的方法是让用户维护一个记录地址。当有人希望通过手机与他们取得联系时，他们会拨打AOR，但会表示优先选择将呼叫路由到手机。
A caller may actually have a wide variety of preferences for how a call should be routed. They may prefer to go right to voicemail. They may prefer never to reach voicemail. The may prefer to reach the user on a device that supports video (because a video-conference is desired). They may wish to reach a device that has an attendant who can answer if the user is not there.
实际上，对于如何路由呼叫，呼叫方可能有各种各样的首选项。他们可能更喜欢直接使用语音信箱。他们可能更愿意永远不联系语音信箱。用户可能更希望通过支持视频的设备联系用户（因为需要视频会议）。他们可能希望接触到一个有服务员的设备，如果用户不在，服务员可以接听。
The SIP caller preferences extension allows a caller to express these preferences for the way in which their calls are handled. These preferences are expressed in terms of properties of the desired device. These properties are name-value pairs that convey some kind of information about a device. One example is the property "mobility", which can have the values "mobile" or "fixed". When a caller wishes to reach a cell phone, they include information in their call setup request (the INVITE method) which indicates that the call should be routed to a device that has the property "mobility" set to "mobile". When devices register to the network, they include their properties (also known as callee capabilities) as part of the registration. In this way, a proxy can match the caller's preferences against the capabilities of the various devices registered to the user and route the call appropriately.
SIP caller preferences扩展允许调用者表达其呼叫处理方式的这些首选项。这些首选项以所需设备的属性表示。这些属性是名称-值对，用于传递有关设备的某种信息。一个例子是财产“流动性”，其值可以是“流动的”或“固定的”。当呼叫者希望接通手机时，他们会在其呼叫设置请求（INVITE方法）中包含信息，指示呼叫应路由到属性“mobility”设置为“mobile”的设备。当设备注册到网络时，它们将其属性（也称为被叫方功能）作为注册的一部分。通过这种方式，代理可以将调用方的首选项与注册给用户的各种设备的功能相匹配，并适当地路由调用。
While this document addresses the preferences of a caller, it does so from the perspective of a SIP User Agent representing the caller. Caller preferences are herein represented via syntactic elements placed in a SIP request. This document does not attempt to address how preferences might be conveyed by a human user to the User Agent. Thus this document is likely to be of most value to the developer of a User Agent.
虽然本文档介绍了调用者的首选项，但它是从代表调用者的SIP用户代理的角度进行的。在此，呼叫者偏好通过放置在SIP请求中的语法元素来表示。本文档不试图说明人类用户如何将偏好传达给用户代理。因此，本文档可能对用户代理的开发人员最有价值。
The caller preferences extension can support a wide variety of call routing applications and features. Two particularly important examples are "one-number" and "direct-to-voicemail".
呼叫者首选项扩展可以支持多种呼叫路由应用程序和功能。两个特别重要的例子是“一个号码”和“直接到语音信箱”。
In today's circuit-switched telephony networks, users have multiple devices, and each device is associated with its own phone number. A user will typically list all of these numbers on a business card: cell phone, work phone, home office phone, and so on. Other users need to store and manage all of these numbers. It is difficult to keep these numbers complete and up-to-date. Worse, when you want to call someone, you need to pick a number to try. Sometimes, you want a specific device (the cell phone); and other times, you just want to reach them wherever they are. In the latter case, a user is forced to try each number, one at a time. This is inefficient, and difficult to do while driving, for example.
在今天的电路交换电话网络中，用户有多个设备，每个设备都与自己的电话号码相关联。用户通常会在名片上列出所有这些号码：手机、工作电话、家庭办公室电话等等。其他用户需要存储和管理所有这些号码。很难保持这些数字的完整性和最新性。更糟糕的是，当你想打电话给某人时，你需要选择一个号码来尝试。有时候，你想要一个特定的设备（手机）；而其他时候，你只想联系他们，不管他们在哪里。在后一种情况下，用户被迫尝试每个号码，一次一个。例如，这样做效率低，而且在开车时很难做到。
As an alternative, a user can have a single address. This is the one and only address they give out to other users on their business cards. If a caller wishes to reach that user on their cell phone, they select that one address, and then access a pull-down menu of device types. This menu would include home phone, work phone, and cell phone. The caller can select cell-phone, and then the call is placed to the cell phone. There is no need to manage or maintain more than one number for the user -- a single number will suffice.
作为替代方案，用户可以有一个地址。这是他们在名片上发给其他用户的唯一地址。如果来电者希望通过手机联系到该用户，他们会选择该地址，然后访问设备类型的下拉菜单。此菜单将包括家庭电话、工作电话和手机。呼叫者可以选择手机，然后将呼叫转到手机。不需要为用户管理或维护多个号码——一个号码就足够了。
If, on the other hand, the caller wishes to reach the user wherever they are, they make a call to that one number without a selection of a preferred device. The network will ring all devices at the same time, and therefore reach the user as fast as possible.
另一方面，如果呼叫者希望在任何地方联系到用户，则他们在不选择首选设备的情况下拨打该号码。网络将同时响铃所有设备，因此尽可能快地到达用户。
This one-number service makes use of caller preferences. To express a preference for the cell phone, the caller's device would include a header in the SIP INVITE request, indicating a desire to reach a device with "mobility" equal to "mobile".
这个单号服务利用呼叫者偏好。为了表示对移动电话的偏好，呼叫者的设备将在SIP INVITE请求中包括报头，指示到达具有等于“mobility”的“mobility”的设备的愿望。
Frequently, a busy executive on the road wants to quickly pass a message to a colleague by voice. As an example, a boss might want to instruct an employee to call a specific customer and resolve a pending issue. In such a case, the user doesn't actually want to talk to the person; they just want to leave a voice message. Having a phone conversation may require too much time, whereas a voice message can be quick and to the point. The voice message can also serve as a record of exactly what is desired, whereas a fleeting voice conversation can be forgotten or misremembered.
经常，一位忙碌的主管在路上想要通过语音快速地向同事传递信息。例如，老板可能希望指示员工给特定客户打电话，解决未决问题。在这种情况下，用户实际上不想与此人交谈；他们只想留个语音留言。进行电话交谈可能需要太多时间，而语音信息可能会很快且切中要害。语音信息还可以作为所需内容的准确记录，而短暂的语音对话可能会被遗忘或错误记忆。
In today's circuit-switched telephone networks, there is often no way to go directly to someone's voicemail and leave a message. Sometimes, you can dial the main number for the voicemail system, enter in the extension of the desired party, and leave a message by entering a specific prompt. This is time consuming, and requires the caller to know the main voicemail number.
在今天的电路交换电话网络中，通常无法直接转到某人的语音信箱并留言。有时，您可以拨打语音邮件系统的主号码，输入所需用户的分机号码，并通过输入特定提示来留言。这很费时，而且要求呼叫者知道主语音信箱号码。
Instead, an address book in a cell phone can have an option called "leave voice message", available for each entry in the address book. When this option is selected, a call is made directly to the voicemail for that user, which immediately picks up and prompts for a message. In fact, a rapid greeting is played, so that the caller can go directly to the recording procedure.
相反，手机中的通讯簿可以有一个名为“留言”的选项，可用于通讯簿中的每个条目。选择此选项后，会直接呼叫该用户的语音信箱，语音信箱会立即接听并提示输入信息。事实上，会播放快速问候语，以便来电者可以直接进入录音过程。
This saves time for the caller, making it very easy to quickly leave recorded messages for a large number of people.
这为打电话的人节省了时间，使得为大量的人快速留下录音信息变得非常容易。
This feature is possible using the caller preferences extension. When the user selects the "leave voice message" option, the phone sends a SIP INVITE request, and includes a caller preferences header field that indicates a preference for devices whose "msgserver" attribute has a value of "true". This will cause the proxy to route the call directly to a registered voicemail service. Furthermore, the voicemail server will see that the caller asked to go directly to voicemail, and can therefore play an abbreviated greeting explicitly designed for this case.
使用呼叫者首选项扩展可以实现此功能。当用户选择“离开语音消息”选项时，手机会发送SIP INVITE请求，并包括一个呼叫者首选项标题字段，该字段指示其“msgserver”属性值为“true”的设备的首选项。这将导致代理将呼叫直接路由到注册语音邮件服务。此外，语音邮件服务器将看到呼叫者请求直接转到语音邮件，因此可以播放为这种情况明确设计的简短问候语。
Each use case is described as a situation along with a desired behavior. Then, it demonstrates how the various caller preferences headers and the proxy processing logic would result in the appropriate decision.
每个用例都被描述为一个场景和一个期望的行为。然后，它演示了各种调用者首选项头和代理处理逻辑将如何产生适当的决策。
Address of Record (AOR) Y has two contacts, Y1 and Y2. Y1 is a phone and supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE, whereas Y2 is a pager and supports only OPTIONS and MESSAGE. Caller X wants to send pages to Y. There is a lot of traffic in the network of both calls and pages, so there is a goal not to unnecessarily fork messages to devices that can't support them. So, this is done by ensuring that INVITEs of Y are delivered only to Y1, while MESSAGEs to Y are delivered only to Y2.
记录地址（AOR）Y有两个联系人，Y1和Y2。Y1是一款手机，支持标准操作INVITE、ACK、OPTIONS、BYE和CANCEL，但不支持MESSAGE，而Y2是一款寻呼机，只支持OPTIONS和MESSAGE。呼叫方X希望向Y发送页面。在呼叫和页面的网络中都存在大量流量，因此目标是不要不必要地将消息转发给不支持它们的设备。因此，这是通过确保Y的邀请只发送给Y1，而发送给Y的消息只发送给Y2来实现的。
Y1 will create a registration that looks like, in part:
Y1将创建一个注册，该注册部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact:<sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="mobile"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact:<sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="mobile"
Y2 will create a registration that looks like, in part:
Y2将创建一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="OPTIONS,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;+sip.message
;schemes="sip,im"
;mobility="mobile"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="OPTIONS,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;+sip.message
;schemes="sip,im"
;mobility="mobile"
When a UAC (User Agent Client) sends an INVITE, it will arrive at the proxy for example.com. There are no caller preferences in the request. However, per Section 7.2.2 of [3], the proxy will construct an implicit require-flagged Accept-Contact preference that looks like:
当UAC（用户代理客户端）发送邀请时，它将到达代理，例如.com。请求中没有呼叫者首选项。然而，根据[3]第7.2.2节，代理将构造一个隐式的需要标记的接受联系人首选项，如下所示：
(& (sip.methods="INVITE"))
（&（sip.methods=“INVITE”））
Applying the matching algorithm of RFC 2533 [6] to this feature set and those registered by Y1 and Y2, the feature set of Y1 alone matches. Because the Accept-Contact predicate has its require flag set, Y2 is discarded, and the INVITE is routed to Y1.
将RFC 2533[6]的匹配算法应用于该特征集以及Y1和Y2注册的特征集，仅Y1的特征集匹配。因为Accept Contact谓词设置了require标志，所以Y2被丢弃，INVITE被路由到Y1。
If the request was MESSAGE, the proxy constructs an implicit Accept-Contact preference with its require flag set (require-flagged) that looks like:
如果请求是消息，则代理使用其require标志集（require-flagged）构造一个隐式接受联系人首选项，如下所示：
(& (sip.methods="MESSAGE"))
（&（sip.methods=“MESSAGE”））
which matches the feature set of Y2, but not Y1. Thus, Y1 is discarded, and the request is routed to Y2.
它与Y2的功能集匹配，但与Y1的功能集不匹配。因此，Y1被丢弃，请求被路由到Y2。
AOR Y has a single contact, Y1. It's a phone, and therefore supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE. A caller X sends a MESSAGE request. The desired behavior is that the request is still routed to the solitary contact so that it can generate a 405 response.
AOR Y有一个触点Y1。它是一部手机，因此支持标准操作INVITE、ACK、OPTIONS、BYE和CANCEL，但不支持MESSAGE。调用方X发送消息请求。期望的行为是请求仍然被路由到单独联系人，以便它可以生成405响应。
The single contact Y1 will generate a registration that looks like, in part:
单个联系人Y1将生成一个注册，该注册部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
X sends a MESSAGE request. There are no explicit caller preferences. This results in an implicit require-flagged Accept-Contact preference:
X发送一个消息请求。没有明确的调用方首选项。这将导致隐式require标记的接受联系人首选项：
(& (sip.methods="MESSAGE"))
（&（sip.methods=“MESSAGE”））
Since Y1 doesn't match and the Accept-Contact predicate is require-flagged, it is discarded. However, according to section 7.2.4 of RFC 3841, if there are no matching targets, the original target set is used. Thus, the request is sent to the one original target, Y1, as desired. Y1 then responds with a 405.
由于Y1不匹配，并且Accept Contact谓词被标记为require，因此将丢弃它。但是，根据RFC 3841第7.2.4节，如果没有匹配目标，则使用原始目标集。因此，根据需要将请求发送到一个原始目标Y1。Y1然后以405响应。
If there were multiple contacts, and none of them matched the Accept-Contact predicate, then the original target set including all of the contacts would be restored. Then all the contacts would be processed according to Section 16.6 of RFC 3261.
如果有多个联系人，并且没有一个与Accept Contact谓词匹配，则将恢复包含所有联系人的原始目标集。然后根据RFC 3261第16.6节处理所有触点。
AOR Y has a number of contacts, Y1, Y2, ..., Yn, that can each support the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL and can also support SUBSCRIBE for the "dialog" event package [7]. Y also has another contact, Yp, that is a presence agent (PA) [8]: it can accept only SUBSCRIBE requests for the "presence" event package. The goal is for SUBSCRIBE requests for presence to be routed to Yp while INVITEs and SUBSCRIBEs for the dialog package are forked to Y1...Yn.
AOR Y有许多联系人，Y1、Y2、…、Yn，每个联系人都可以支持标准操作INVITE、ACK、OPTIONS、BYE和CANCEL，还可以支持订阅“对话”事件包[7]。Y还有另一个联系人Yp，即状态代理（PA）[8]：它只能接受“状态”事件包的订阅请求。目标是将状态的订阅请求路由到Yp，而对话框包的邀请和订阅被分叉到Y1…Yn。
Y1..Yn will generate REGISTER requests that look like, in part:
Y1..Yn将生成部分如下所示的寄存器请求：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;events="dialog"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;events="dialog"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
and Yp will generate a REGISTER request that looks like, in part:
Yp将生成一个注册请求，该请求部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE"
;events="presence"
;uri-user="<Yp>"
;uri-domain="example.com"
;schemes="sip,pres"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE"
;events="presence"
;uri-user="<Yp>"
;uri-domain="example.com"
;schemes="sip,pres"
;mobility="fixed"
;class="business"
A SUBSCRIBE request for presence will arrive at the proxy for example.com. Since there are no explicit preferences, it constructs an implicit require-flagged Accept-Contact preference from the request:
订阅状态请求将到达proxy for example.com。由于没有显式首选项，因此它从请求构造隐式的带有require标记的Accept Contact首选项：
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
（&（sip.methods=“SUBSCRIBE”）（sip.events=“presence”））
Following Section 7.2.4 of RFC 3841, this feature set only matches the one registered by Yp. Because the require flag is set, the contacts which do not match are removed from the target set. Therefore, Y1..Yn are discarded. The request is sent to the remaining contact, Yp, representing the PA.
根据RFC 3841第7.2.4节，此功能集仅与Yp注册的功能集匹配。由于设置了require标志，因此将从目标集中删除不匹配的触点。因此，Y1..Yn被丢弃。请求被发送到代表PA的剩余联系人Yp。
An INVITE request without explicit preferences results in an implicit require-flagged Accept-Contact preference:
没有显式首选项的INVITE请求会导致隐式require标记的Accept Contact首选项：
(& (sip.methods="INVITE"))
（&（sip.methods=“INVITE”））
The implicit Accept-Contact feature set matches Y1..Yn, but does not match Yp. Using the scoring algorithm from Section 7.2.4 of RFC 3841, the score for Y1..Yn against this predicate is 1.0. As a result, the caller preference Qa for each contact is 1.0. The registrations did not contain q-values, so the default q-value of 1.0 is applied to each Contact URI. Since the caller and callee preferences are the same and all equal to 1.0, there is no reordering of contacts. The result is that the proxy will consider Y1..Yn each as equally good targets for the request and possibly fork the request to each.
隐式接受联系人功能集与Y1..Yn匹配，但与Yp不匹配。使用RFC 3841第7.2.4节中的评分算法，Y1..Yn对该谓词的评分为1.0。因此，每个联系人的呼叫方首选项Qa为1.0。注册不包含q值，因此默认q值1.0应用于每个联系人URI。由于呼叫者和被呼叫者的首选项相同且均等于1.0，因此不会对联系人进行重新排序。结果是，代理将考虑Y1…YN作为每个请求的同样好的目标，并可能将请求叉到每个。
A SUBSCRIBE request for the dialog event package without explicit preferences will result in an implicit require-flagged Accept-Contact preference:
没有显式首选项的对话框事件包订阅请求将导致隐式require标记的Accept Contact首选项：
(& (sip.methods="SUBSCRIBE") (sip.events="dialog"))
（&（sip.methods=“SUBSCRIBE”）（sip.events=“dialog”））
This only matches Y1..Yn, so Yp is discarded, and the request is routed to the remaining contacts just as the INVITE was.
这只匹配Y1..Yn，因此Yp被丢弃，请求被路由到其余联系人，就像邀请一样。
This case is nearly identical to that of Section 3.3. However, Y1..Yn omit the "events" feature tag from their registration. Yp registers as in Section 3.3. A SUBSCRIBE for the presence event package should still preferentially route to Yp.
这种情况与第3.3节的情况几乎相同。但是，Y1..Yn从其注册中省略“事件”功能标记。Yp寄存器如第3.3节所述。对状态事件包的订阅仍应优先路由到Yp。
The registration from Y1..Yn will look like:
来自Y1..Yn的注册将如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
When the caller sends a SUBSCRIBE for the presence event package (without explicit preferences), the proxy computes an implicit preference:
当调用者发送状态事件包的订阅（无显式首选项）时，代理计算隐式首选项：
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
（&（sip.methods=“SUBSCRIBE”）（sip.events=“presence”））
This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn against this predicate is 0.5, and the score of Yp is 1.0. The result is a caller preference Qa of 0.5 for Y1..Yn, and a caller preference Qa of 1.0 for Yp. Since the callee provided no q-values, the proxy will assume a default of 1.0. Thus, all contacts are in the same equivalence class. They are then sorted by Qa, so that Yp is first, followed by Y1 through Yn. It will therefore route the request first to Yp, and if that should fail, to Y1..Yn.
此谓词匹配Y1..Yn和Yp。然而，Y1..Yn相对于该谓词的得分为0.5，Yp的得分为1.0。结果是，对于Y1..Yn，调用方首选项Qa为0.5，对于Yp，调用方首选项Qa为1.0。由于被调用方未提供q值，代理将假定默认值为1.0。因此，所有触点都在同一等效类中。然后按照Qa对它们进行排序，因此Yp是第一位的，然后是Y1到Yn。因此，它将首先将请求路由到Yp，如果失败，则路由到Y1..Yn。
X sends an invitation to Y to initiate an audio/video call, including both m=audio and m=video lines in the SDP. AOR Y has two contacts, Y1 and Y2. Y1 represents a normal audio phone, where Y prefers to receive their calls. It will answer an audio/video call, refusing the video. Y2 represents an audio/video phone that should only used when needed. The caller really wants the call answered by a device that supports video, but will accept an audio-only call as a second choice.
X向Y发送发起音频/视频呼叫的邀请，包括SDP中的m=音频和m=视频线路。AOR Y有两个触点，Y1和Y2。Y1代表普通的音频电话，Y更喜欢接听他们的电话。它将接听音频/视频电话，拒绝视频。Y2表示只应在需要时使用的音频/视频电话。呼叫者确实希望呼叫由支持视频的设备应答，但会接受仅音频呼叫作为第二选择。
Y1 will generate a registration that looks like, in part:
Y1将生成一个注册，该注册部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2 will generate a registration that looks like, in part:
Y2将生成一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Note the different q-values, allowing Y2 to be selected as a device of "last resort".
注意不同的q值，允许选择Y2作为“最后手段”设备。
To have the call preferentially routed to a device that supports video, the caller X sends an INVITE that looks like, in part:
为了使呼叫优先路由到支持视频的设备，呼叫者X发送一个邀请，部分如下所示：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
The proxy will convert this to a feature set. This feature set matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1. The two contacts are then ordered by q-value and broken into equivalence classes. There are two equivalence classes, each with one contact. As a result, the caller preference values have no impact on the ordering. The call will first try the higher priority Y1, which will answer the call and reject the video stream. Thus, the desired behavior is not achieved.
代理将此转换为功能集。此功能集与Y2和Y1匹配。然而，Y2的分数是1.0，Y1的分数是0.5。然后按q值对两个触点进行排序，并将其分为等效类。有两个等价类，每个类有一个触点。因此，调用方首选项值对排序没有影响。呼叫将首先尝试更高优先级的Y1，它将应答呼叫并拒绝视频流。因此，无法实现期望的行为。
The desired behavior could be achieved by adding the "explicit" and "require" tags to the Accept-Contact header field in the INVITE, as is done in Section 3.6. However, doing so may result in calls failing when they could occur, but without video. As discussed in [3], both the "require" and "explicit" tags are generally used only when the request cannot be serviced in any way unless the preferences are met. That is not the case here.
如第3.6节所述，可以通过向邀请中的Accept Contact header字段添加“explicit”和“require”标记来实现所需的行为。但是，这样做可能会导致在可能发生呼叫但没有视频的情况下呼叫失败。如[3]中所述，“require”和“explicit”标记通常仅在请求无法以任何方式服务时使用，除非满足首选项。这里的情况并非如此。
This case is similar to that of Section 3.5. However, X requires an audio/video call and would like the call to fail if this is not possible, rather than succeed with audio only.
这种情况与第3.5节类似。但是，X需要音频/视频呼叫，如果不可能，则希望呼叫失败，而不是仅通过音频成功。
The solution is similar to that of Section 3.5; however, the Accept-Contact header field now includes the "explicit" and "require" tags, guaranteeing that the call is never established to any UA that had not explicitly indicated support for video:
该解决方案与第3.5节类似；但是，Accept Contact header字段现在包括“explicit”和“require”标记，以确保从未向任何未明确表示支持视频的UA建立呼叫：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
This arrives at the example.com proxy. This explicit feature set matches the feature set for Y2 and Y1. However, the match for Y1 did not have a score of 1. Since the "explicit" and "require" tags are present, the contact is discarded. That leaves Y2 only. The call will therefore get routed to the videophone, and if the user is not there, the audio phone will never ring.
这将到达example.com代理。此显式功能集与Y2和Y1的功能集匹配。然而，Y1的比赛没有1分。由于存在“explicit”和“require”标记，因此将丢弃该联系人。这只剩下Y2了。因此，通话将被转接到可视电话，如果用户不在，音频电话将永远不会响。
Because both the "require" and "explicit" flags are present, a contact will also be discarded if it does not include a feature tag indicating support for video. Thus, a UA that can do video, but neglected to indicate it, would not be reached in this case. This is why it is important for a UA to indicate all of its capabilities. Note that this is only true for a contact that indicated some capabilities but not the video capability. Contacts that don't indicate any capabilities are "immune" from caller preferences filtering and would not be discarded.
因为“require”和“explicit”标志都存在，所以如果联系人不包含表示支持视频的功能标签，那么它也将被丢弃。因此，在这种情况下，无法联系到能够进行视频但忽略了指示的UA。这就是为什么UA必须指出其所有能力的原因。请注意，这仅适用于指示某些功能但不指示视频功能的联系人。未指明任何功能的联系人“不受”来电者首选项筛选的影响，不会被丢弃。
Z is a third-party call control controller (3pcc) [9] trying to establish an audio/video call from X to Y. X has contacts X1 and X2, and Y has contacts Y1 and Y2. X1 and X2 have capabilities identical to Y1 and Y2, respectively. Z needs to send an offerless invite to X and use the offer proposed by X to send an invite to Y. When sending the offerless invite to X, the 3pcc controller must ensure that an audio/video contact (X2) is chosen over an audio only contact (X1).
Z是试图建立从X到Y的音频/视频呼叫的第三方呼叫控制控制器（3pcc）[9]。X有触点X1和X2，Y有触点Y1和Y2。X1和X2的性能分别与Y1和Y2相同。Z需要向X发送无要约邀请，并使用X提出的要约向Y发送邀请。向X发送无要约邀请时，3pcc控制器必须确保选择音频/视频联系人（X2）而不是仅音频联系人（X1）。
X1 will generate a registration that looks like, in part:
X1将生成一个注册，该注册部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
X2 will generate a registration that looks like, in part:
X2将生成一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Z would include, in its INVITE, an Accept-Contact header field:
Z将在其INVITE中包含一个Accept Contact头字段：
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
This caller preference matches both X1 and X2. However, it matches X1 with a score of .5 and X2 with a score of 1. Because of the "require" and "explicit" tags, X1 is discarded despite X's preference for it. Thus, the call is routed to X2.
此调用方首选项与X1和X2都匹配。但是，它与X1的分数为.5，与X2的分数为1相匹配。由于“require”和“explicit”标记，X1被丢弃，尽管X更喜欢它。因此，呼叫被路由到X2。
The same caveats apply here as do in Section 3.6. Generally, it is not advisable to mandate support for features (such as video) that are not strictly necessary for the request to proceed.
此处的注意事项与第3.6节中的相同。一般来说，不建议强制要求对请求进行时不严格需要的功能（如视频）提供支持。
AOR Y has two contacts: Y1, which is a regular audio phone, and Y2, which is a PC capable of supporting both audio and session-oriented IM [10]. X is a PC with capability to support audio, video, and session-oriented IM. X calls Y for the purpose of establishing a voice call. However, X wishes to connect to the device that has the maximal overlap with its media capabilities, in order to maximize the functionality available to the caller.
AOR Y有两个联系人：Y1，它是一个普通的音频电话；Y2，它是一台能够支持音频和面向会话的IM的PC[10]。X是一台能够支持音频、视频和面向会话的IM的PC。X呼叫Y以建立语音呼叫。但是，X希望连接到与其媒体功能最大重叠的设备，以便最大限度地提高调用者可用的功能。
Y1 will generate a registration that looks like, in part:
Y1将生成一个注册，该注册部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@phone.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@phone.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2 will generate a registration that looks like, in part:
Y2将生成一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;+sip.message
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;+sip.message
;schemes="sip,tel"
;mobility="fixed"
;class="business"
The solution requires the caller to support caller preferences. The caller would include, in their INVITE, an Accept-Contact header field that lists all the media types they support. In this case:
解决方案要求调用者支持调用者首选项。调用者将在其邀请中包含一个Accept Contact标头字段，其中列出了他们支持的所有媒体类型。在这种情况下：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+sip.message
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+sip.message
Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33, and Y2 matches with a score of 0.66. Since there is only one Accept-Contact predicate, the Qa for each contact is equal to the score. The registered contacts are then sorted by q-value and broken into equivalence classes. There is a single equivalence class with q-value of 1.0. The two contacts in that class are then re-ordered based on the values of Qa. Y2 has a higher Qa, so it is used first, followed by Y1. The result is that the call is routed to the device with the maximum overlap in media capabilities, as desired.
Y1和Y2都匹配谓词。Y1的得分为0.33，Y2的得分为0.66。因为只有一个接受联系人谓词，所以每个联系人的Qa等于分数。然后按q值对登记的触点进行排序，并将其分为等效类。存在一个q值为1.0的等效类。然后根据Qa的值对该类中的两个触点进行重新排序。Y2的Qa较高，因此首先使用它，然后是Y1。结果是，根据需要，呼叫被路由到媒体功能重叠最大的设备。
Note that neither "require" nor "explicit" tags are used because there is no intent to exclude contacts, only to order them.
请注意，既不使用“require”也不使用“explicit”标记，因为不打算排除联系人，只想订购联系人。
AOR Y represents a shared line in an office. Several employees in the office have phones registered for Y. Some of the employees speak only English, some speak Spanish fluently and have some limited capability for English, and some speak both English and Spanish fluently. Calls from callers that speak only English should be parallel forked to all office workers that speak fluent English. If the call isn't picked up, then the phones of workers that speak English marginally should be rung. Calls from callers that speak only Spanish should be forked only to workers that speak Spanish.
AOR Y表示办公室中的共享行。办公室的几名员工的电话已注册为Y。一些员工只会说英语，一些员工会说流利的西班牙语，英语能力有限，一些员工会说流利的英语和西班牙语。只说英语的来电者的电话应平行转接给所有说流利英语的办公室工作人员。如果电话没有接听，那么英语水平不高的员工的电话应该被挂断。来自只讲西班牙语的呼叫者的电话应该只转接给讲西班牙语的工人。
A user at phone Y1 that speaks English only would generate a REGISTER that looks like, in part:
手机Y1上只会说英语的用户将生成一个寄存器，部分类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;languages="en"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;languages="en"
A user at a phone Y2 that speaks Spanish and a little bit of English would generate a REGISTER that looks like, in part:
一个说西班牙语和一点英语的Y2手机用户会生成一个寄存器，部分看起来像：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2-es@pc2.example.com>;languages="es"
Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2-es@pc2.example.com>;languages="es"
Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
Y2 has registered two contacts. Both of them route to the same device (pc2.example.com), but they differ in their language support and relative q-values. Multiple contacts are needed whenever a UA wishes to express differing preferences for being reached for different feature collections.
Y2登记了两个联系人。它们都路由到同一个设备（pc2.example.com），但它们的语言支持和相对q值不同。当UA希望表达不同特征集合的不同偏好时，需要多个联系人。
A user at phone Y3 that speaks English and Spanish fluently would generate a REGISTER that looks like, in part:
如果Y3手机上的用户能流利地说英语和西班牙语，则会生成一个寄存器，该寄存器部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;languages="es,en"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;languages="es,en"
Notice that only a single contact is needed because the same q-value is applied across all feature collections.
请注意，只需要一个触点，因为相同的q值应用于所有要素集合。
For the language-based routing to occur, the caller must indicate its language preferences explicitly:
要进行基于语言的路由，调用方必须明确指出其语言首选项：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
The predicate derived from this looks like:
由此派生的谓词如下所示：
(& (languages="en"))
（&（languages=“en”））
This matches the one contact for Y1, the second contact registered for Y2, and the one contact for Y3, all with a score of 1.0. The first contact registered by Y2 does not match, and because of the "require" flag, is discarded. The remaining contacts are sorted by q-value and divided into equivalence classes. There are two
这与Y1的一个联系人、Y2的第二个联系人和Y3的一个联系人相匹配，所有联系人的得分均为1.0。Y2注册的第一个联系人不匹配，并且由于“require”标志而被丢弃。其余触点按q值排序，并划分为等效类。有两个
equivalence classes. The first contains Y1 and Y3 with a q-value of 1.0, and the second contains Y2-en with a q-value of 0.2. The contacts in the first class are ordered by Qa. However, since all contacts have the same value of Qa (1.0), there is no change in ordering. Thus, Y1 and Y3 are tried first, followed by Y2-en. This is the desired behavior.
等价类。第一个包含q值为1.0的Y1和Y3，第二个包含q值为0.2的Y2 en。一级触点由Qa订购。但是，由于所有触点都具有相同的Qa值（1.0），因此顺序没有变化。因此，首先尝试Y1和Y3，然后尝试Y2 en。这是理想的行为。
An "explicit" tag is not used because that would cause the exclusion of a contact that does not mention language.
不使用“显式”标记，因为这将导致排除不涉及语言的联系人。
A caller that speaks Spanish only would specify their preference thusly:
只会说西班牙语的来电者会指定他们的偏好：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
This matches the first contact of Y2 phones, and Y3 phones, all with a score of 1.0. The English contact of Y2, Y2-en, doesn't match and is discarded because of the "require" flag. The remaining contacts are sorted by q-values (Y3, Y2-es) and broken into a single equivalence class containing both contacts. Since the Qa for both contacts is the same (1.0) there is no reordering. The result is that the call is routed to either Y3 or Y2-es.
这与Y2手机和Y3手机的第一次接触相匹配，所有手机的得分均为1.0。Y2的英文联系人Y2 en不匹配，由于带有“require”标志而被丢弃。其余触点按q值（Y3，Y2 es）排序，并分为一个包含两个触点的等效类。由于两个联系人的Qa相同（1.0），因此没有重新排序。结果是呼叫被路由到Y3或Y2 es。
AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X wishes to call Y and talk in person. X does not want to be sent to voicemail under any circumstances.
AOR Y有两个联系人，一个电话Y1和一个语音信箱服务Y2。X想打电话给Y，亲自谈谈。X在任何情况下都不希望被发送到语音信箱。
The phone would register with a Contact that looks like, in part:
手机将注册一个联系人，该联系人在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;audio
;mobility="fixed"
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;audio
;mobility="fixed"
and the voicemail server would register with a Contact that looks like, in part:
语音邮件服务器将注册一个联系人，该联系人部分如下：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;msgserver
;automata
;attendant
;audio
;q=0.2
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;msgserver
;automata
;attendant
;audio
;q=0.2
The voicemail server registers with a lower q-value so that it is used only after the phone itself is rung. Note that the voicemail server need not actually register. There can be a configured contact and feature set defined for it instead.
语音邮件服务器以较低的q值注册，以便仅在电话本身响起后使用。请注意，语音邮件服务器实际上不需要注册。可以为其定义配置的联系人和功能集。
A caller that wishes to avoid voicemail can include an explicit preference to avoid it. A caller would do this with the Reject-Contact header field:
希望避免语音邮件的呼叫者可以包含一个明确的首选项来避免语音邮件。调用者将使用拒绝联系人标题字段执行此操作：
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
Since this feature set contains a feature tag that is not contained in the registration for Y1, the feature set is discarded when examining Y1. However, the registration for Y2 contains all feature tags listed in the feature set, and so the rule is considered. There is a match, and therefore, Y2 is discarded. The result is that the user is never routed to voicemail.
由于此功能集包含Y1注册中未包含的功能标记，因此在检查Y1时将丢弃该功能集。但是，Y2的注册包含要素集中列出的所有要素标记，因此将考虑该规则。存在匹配项，因此Y2被丢弃。结果是用户永远不会被路由到语音邮件。
The situation is similar to Section 3.10, except the caller wishes only to leave a message, not actually speak to the person.
这种情况与第3.10节类似，不同的是打电话的人只想留言，而不是实际与对方交谈。
The caller would send an INVITE that looks like, in part:
调用方将发送一个邀请，该邀请的部分内容如下：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
This caller preference matches both Y1 and Y2. Y1 matches, but with a score of zero. Y2 matches with a score of 1. Since both the
此调用方首选项与Y1和Y2都匹配。Y1匹配，但分数为零。Y2以1分匹配。既然
"require" and "explicit" flags are set, Y1 is discarded. Therefore, the call is routed to Y2, the voicemail server, as desired.
设置了“require”和“explicit”标志，Y1被丢弃。因此，根据需要，呼叫被路由到Y2语音邮件服务器。
Because of the presence of the "require" and "explicit" tags, if these preferences are used with a user that doesn't have voicemail or that fails to indicate it with a msgserver capability, the call will fail completely with a 480 Temporarily Unavailable error, rather than connect to the user.
由于存在“require”和“explicit”标记，如果这些首选项用于没有语音邮件或无法使用msgserver功能指示语音邮件的用户，则呼叫将完全失败，并出现暂时不可用的错误，而不是连接到用户。
The situation is similar to that of Section 3.10. However, the caller prefers to leave a message. If voicemail is not available, they are willing to talk to a person.
情况与第3.10节类似。但是，打电话的人更喜欢留言。如果没有语音信箱，他们愿意与人交谈。
It had been hoped that RFC 3841 could provide a solution for this case, but it does not, because doing so would require a re-ordering of the callee contacts, which is not done. The caller may achieve the intended effect by making two call attempts:
人们曾希望RFC 3841能够为这种情况提供解决方案，但事实并非如此，因为这样做需要对被叫人联系人进行重新排序，而这一点并没有做到。呼叫者可通过两次呼叫尝试达到预期效果：
o First, make an attempt requiring voicemail, as described in Section 3.11.
o 首先，尝试使用语音邮件，如第3.11节所述。
o If that fails with a 480 error, send an invitation with no Accept-Contact or Reject-Contact headers.
o 如果失败并出现480错误，则发送不带接受联系人或拒绝联系人标题的邀请。
Y is the AOR of an executive. It has three contacts. Y1 is the phone on the executive's desk. Y2 is the phone on the desk of the executive's assistant. Y3 is the address of an auto-attendant system that can answer general questions, route calls to other parties, etc. By default, calls to Y should be directed to Y2, and if that fails, to Y3. If Y3 doesn't answer, then Y1 should ring.
Y是高管的AOR。它有三个联系人。Y1是高管办公桌上的电话。Y2是行政助理办公桌上的电话。Y3是自动助理系统的地址，可以回答一般问题，将呼叫路由到其他方等。默认情况下，对Y的呼叫应定向到Y2，如果失败，则应定向到Y3。如果Y3没有应答，那么Y1应该会响。
This is primarily a called party feature and is best accomplished with a CPL (Call Processing Language) script [5]. However, it can be accomplished with caller preferences alone by properly setting the q-values across the three devices. Assuming this coordination is possible, here are the settings that would be made:
这主要是被叫方特性，最好使用CPL（呼叫处理语言）脚本来实现[5]。但是，仅通过在三个设备上正确设置q值，就可以通过调用方首选项来实现。假设这种协调是可能的，以下是将要进行的设置：
Y1 would generate a REGISTER that looks like, in part:
Y1将生成一个寄存器，部分类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=0.1
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=0.1
Y2 would generate a REGISTER that looks like, in part:
Y2将生成一个寄存器，该寄存器在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
Y3 would generate a REGISTER that looks like, in part:
Y3将生成一个寄存器，部分类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
Note that, in reality, the automated attendant would probably not use REGISTER. Since the attendant would be used for every employee in the company, a static contact would probably be added administratively for each user in the enterprise. However, the information in that static contact would be identical to the information in the registration above.
请注意，实际上，自动助理可能不会使用寄存器。由于attendant将用于公司中的每个员工，因此可能会在管理上为企业中的每个用户添加一个静态联系人。但是，该静态联系人中的信息将与上述注册中的信息相同。
When X makes a call to the executive, Y, and expresses no preference, the proxy computes an implicit preference to support INVITE. All three contacts match such a preference, even though they have not indicated explicit support for INVITE. Thus, no contacts are discarded. Since each contact has a different q-value, the caller preferences do not cause any reordering. The result is that the call is first routed to Y2, then Y3, then Y1, all as a result of the proper setting of the q-values.
当X向执行人员Y发出呼叫且未表示偏好时，代理将计算一个隐式偏好以支持INVITE。这三个联系人都符合这样的偏好，即使他们没有明确表示支持INVITE。因此，不会丢弃任何触点。由于每个联系人都有不同的q值，因此调用方首选项不会导致任何重新排序。结果是呼叫首先被路由到Y2，然后是Y3，然后是Y1，所有这些都是正确设置q值的结果。
This case is similar to that of Section 3.13, but this time the caller, X, has a preference. X calls Y, but wants to speak directly to the executive. X doesn't want the call to ring either the assistant or the auto attendant (automaton).
这种情况类似于第3.13节的情况，但这次调用方X有一个首选项。X打电话给Y，但想直接与主管交谈。X不想让电话打给助手或自动助理（自动机）。
X's INVITE would look like, in part:
X的邀请在某种程度上类似于：
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
Note that the caller uses two separate Reject-Contact header field values, rather than a single one with two separate feature parameters. The distinction is important. If X had to use a single value with two parameters, a matching UA would need to declare that it was BOTH an attendant and an automaton. If it only declared that it was one of these, based on the matching rules in the caller preferences specification, it would not be rejected.
请注意，调用者使用两个单独的拒绝联系人标头字段值，而不是一个具有两个单独特性参数的值。区别很重要。如果X必须使用带有两个参数的单个值，那么匹配的UA将需要声明它既是一个助理又是一个自动机。如果它只声明它是其中之一，根据调用方首选项规范中的匹配规则，它不会被拒绝。
The above request would result in the elimination of both Y2 and Y3 as contacts. The call would then be routed to Y1, as desired.
上述请求将导致消除Y2和Y3作为联系人。然后根据需要将呼叫路由到Y1。
This case indicates why a CPL script, or some other programmed version of the feature, is preferable. With caller preferences, a caller can override the desired ring sequence and disturb the executive without any kind of authorization. A proper version of this service would simply not permit caller preferences to force the call to go directly to the executive.
这种情况说明了为什么CPL脚本或该功能的其他编程版本更可取。通过调用方首选项，调用方可以覆盖所需的响铃序列并在没有任何授权的情况下干扰执行人员。这项服务的一个正确版本就是不允许呼叫者偏好强制呼叫直接转到执行者。
The situation is similar to that in Section 3.13. However, the executive also has a mobile phone that they have registered. Caller X knows that the owner of Y is traveling, and that an assistant is covering the office phone. X wants to call Y and ring only the mobile phone.
情况类似于第3.13节。不过，这位高管也有一部他们注册的手机。打电话的X知道Y的主人正在旅行，一名助手正在接听办公室电话。X想打电话给Y，只打手机。
The mobile phone would generate a registration that looks like, in part:
移动电话将生成一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
The caller would express their preference by generating an INVITE that looks like, in part:
调用者将通过生成一个邀请来表达他们的偏好，该邀请部分如下所示：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
All four contacts match. However, Y1 through Y3 match with a score of zero. Y4 matches with a score of 1. Because of the "require" and "explicit" tags, Y1 through Y3 are discarded, and only Y4 is used, as desired.
所有四个联系人都匹配。但是，Y1到Y3的分数为零。Y4以1分匹配。由于“require”和“explicit”标记，Y1到Y3被丢弃，并且根据需要仅使用Y4。
Note that this only works if the mobile phone specifies the mobility feature in its registration.
请注意，这仅在移动电话在其注册中指定移动功能时有效。
AOR Y is as in Section 3.9. Caller X, fluent in both English and Spanish, has discovered that the company's Spanish language documentation is inconsistent with the English language documentation and wants to discuss the differences between the two. So X wants to speak with one of the workers that is fluent in both English and Spanish.
AOR Y如第3.9节所示。打电话的X精通英语和西班牙语，发现公司的西班牙语文档与英语文档不一致，希望讨论两者之间的差异。所以X想和一个英语和西班牙语都很流利的工人交谈。
The caller would generate an INVITE that looks like, in part:
调用方将生成一个邀请，该邀请的部分内容如下：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
This will require a Contact URI to match both constraints. That means it needs to support English and Spanish. This will achieve the desired property.
这将需要一个联系人URI来匹配这两个约束。这意味着它需要支持英语和西班牙语。这将达到预期的性能。
Note that there are two separate Accept-Contact header fields. If the caller had instead used this INVITE:
请注意，有两个单独的Accept Contact标头字段。如果调用方使用了此邀请：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
It would have connected them to a UA that speaks either English or Spanish, which is not what is desired here.
它会将他们连接到一个说英语或西班牙语的UA，这不是这里所希望的。
An "explicit" option is not used, because it would bypass contacts that do not include a language tag.
不使用“显式”选项，因为它将绕过不包含语言标记的联系人。
3.17. The Number You Have Called...
3.17. 你打过的电话号码。。。
Consider once more the case of the executive, where the caller wishes to reach only their mobile phone (Section 3.15). However, there is a twist. The callee Y has moved to new address YY, and all the configuration described for the callee now applies to YY. The old address Y remains with a pair of statically assigned contacts. One contact is YY. The other is M, referencing an automaton that generates a voice message reporting that the number has been changed. The caller is unaware of the move and calls Y, requesting to reach the mobile phone in exactly the same way they did in Section 3.15. The call should connect to the mobile.
再次考虑行政人员的情况，在那里，呼叫者希望只到达他们的移动电话（第3.15节）。然而，有一个转折点。被调用者Y已经移动到新地址YY，并且为被调用者描述的所有配置现在都适用于YY。旧地址Y保留一对静态分配的联系人。一个联系人是YY。另一个是M，它引用了一个自动机，该自动机生成一条语音消息，报告号码已更改。呼叫者不知道该移动并呼叫Y，请求以与第3.15节中完全相同的方式联系移动电话。呼叫应连接到手机。
There would be four registrations against YY:
YY将有四次注册：
YY1, the executive, would generate a REGISTER that looks like, in part:
执行官YY1将生成一个寄存器，该寄存器部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY1@pc.example.com>;q=0.1
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY1@pc.example.com>;q=0.1
YY2, the attendant, would generate a REGISTER that looks like, in part:
助理YY2将生成一个寄存器，部分类似于：
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
YY3, the answering service, would generate a REGISTER that looks like, in part:
YY3，即应答服务，将生成一个寄存器，该寄存器部分如下所示：
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
YY4, the mobile, would generate a REGISTER that looks like, in part:
移动设备YY4将生成一个寄存器，部分类似于：
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
Although it would be configured administratively, there are two registered contacts for Y. The first is for the forwarding:
虽然将以管理方式进行配置，但Y有两个已注册联系人。第一个用于转发：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:YY@example.com>;q=1.0
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:YY@example.com>;q=1.0
and the second for the automated answering service:
第二个用于自动应答服务：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:machine@example.com>;automata;q=0.5
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:machine@example.com>;automata;q=0.5
The caller, not knowing that Y has moved, calls Y and asks for their mobile phone:
打电话的人不知道Y搬家了，打电话给Y，要他们的手机：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
This reaches the example.com proxy, which finds two registrations. Only one of these (the automaton) is associated with feature parameters. The other has no feature parameters and is therefore immune to caller preferences processing. The caller preferences are applied to the automaton's contact. The feature sets match, but have a score of zero. Since the "require" and "explicit" tags are present, the contact for the automaton is dropped. The other contact, YY@example.com, is then added back in as the sole contact. The proxy therefore sends the call to sip:YY@example.com. There, there are four registrations, all of which are associated with feature parameters. The caller preferences are applied. Only YY4 matches explicitly, however. Because of the presence of the "require" and "explicit" flags, all other contacts are dropped. As such, the call is forwarded to YY4, and the mobile phone rings.
这会到达example.com代理，它会找到两个注册。其中只有一个（自动机）与特征参数相关联。另一个没有特征参数，因此不受调用方首选项处理的影响。呼叫者首选项应用于自动机的联系人。功能集匹配，但得分为零。由于存在“require”和“explicit”标记，因此自动装置的触点将断开。另一个联系人，YY@example.com，然后添加回作为唯一联系人。因此，代理向sip发送调用：YY@example.com. 其中有四个注册，所有注册都与特征参数相关。将应用调用方首选项。但是，只有YY4明确匹配。由于“require”和“explicit”标志的存在，所有其他触点都会断开。因此，呼叫被转发到YY4，移动电话响了。
This use case is nearly identical to that of Section 3.17. However, this time, the caller wishes to contact the personal phone of Y. They don't feel strongly about it, and will accept other devices.
该用例与第3.17节的用例几乎相同。然而，这一次，来电者希望联系Y的个人电话。他们对此没有强烈的感觉，并且会接受其他设备。
The INVITE generated by the caller in this case will look like:
在这种情况下，调用方生成的INVITE如下所示：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
This reaches the example.com proxy. Once more, the first registration (which forwards to the address-of-record for YY) is unaffected by the caller preferences computation. The other contact, for the automaton, is a match, but its score is zero. Its caller preference Qa equals zero. The other contact is added back in with a Qa of 1.0. The contacts are sorted based on q-value, resulting in YY (q=1.0) followed by machine (q=0.5). These are broken into equivalence classes. There are two classes, one for each contact. As a result, the caller's preferences have no impact on the ordering, and the call is routed to YY.
这将到达example.com代理。同样，第一次注册（转发到YY的记录地址）不受调用方首选项计算的影响。自动装置的另一个联系人是匹配项，但其得分为零。它的调用方首选项Qa等于零。另一个联系人的Qa值为1.0。触点根据q值排序，结果是YY（q=1.0），后面是机器（q=0.5）。它们被分成等价类。有两个类，每个联系人一个。因此，呼叫者的首选项对订购没有影响，呼叫被路由到YY。
When the request for YY@example.com is processed, all four contacts match. However, the score for all of them is zero (none are the personal phone). As such, the contacts are ordered based on q-value. Each contact has a different q-value, so no reordering based on caller preference is possible (not that the caller preference would cause a reordering; all contacts have a Qa of 0.0). Thus, the highest q-value contact is tried, which is the executive assistant.
当请求YY@example.com处理后，所有四个联系人都匹配。然而，他们的分数都是零（没有一个是个人电话）。因此，触点是根据q值排序的。每个联系人都有不同的q值，因此不可能基于呼叫者首选项进行重新排序（并非呼叫者首选项会导致重新排序；所有联系人的Qa都为0.0）。因此，尝试最高q值的联系人，即行政助理。
Alice wants to forward her phone to Bob, but doesn't want folks calling her to get Bob's voicemail if he doesn't answer. She wants her callers to get her voicemail.
爱丽丝想把她的电话转给鲍勃，但如果鲍勃不接电话，她不想让打电话给她的人收到他的语音信箱。她想让打电话的人收到她的语音信箱。
Alice would create three registrations. The first, Y1, represents Alice's phone. The second is Bob's AOR. The third is a voicemail server. The three contacts have decreasing q-values. The registration for Bob's AOR contains an embedded Reject-Contact header field, which rejects message servers.
Alice将创建三个注册。第一个是Y1，代表Alice的手机。第二个是Bob的AOR。第三个是语音邮件服务器。三个触点的q值逐渐减小。Bob的AOR注册包含一个嵌入的拒绝联系人头字段，该字段拒绝消息服务器。
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
Meanwhile, Bob is registered as follows:
同时，北京银行注册如下：
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob-drop@msgcenter.example.com>
;msgserver
;automata
;attendant
;q=0.2
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob-drop@msgcenter.example.com>
;msgserver
;automata
;attendant
;q=0.2
Carol calls Alice and doesn't include any caller preference parameters. As such, the example.com proxy constructs an implicit preference for INVITE. This preference matches all three registered contacts, with a score of zero. Because each contact has a different q-value, there is no reordering of contacts. So, the proxy tries the highest q-value Contact, Alice's desk phone (Y1). The proxy cancels after a few seconds (no answer). The proxy then tries the next Contact, which is Bob's AOR. When constructing the request for this Contact, the proxy includes the embedded Reject-Contact header field in the INVITE. This INVITE undergoes caller preferences processing based on Bob's registered Contacts.
Carol调用Alice，不包含任何调用方首选参数。因此，example.com代理为INVITE构造了一个隐式首选项。此首选项匹配所有三个已注册联系人，得分为零。由于每个触点具有不同的q值，因此不会对触点进行重新排序。因此，代理尝试q值最高的联系人，Alice的台式电话（Y1）。代理在几秒钟后取消（无应答）。代理然后尝试下一个联系人，即Bob的AOR。构造此联系人的请求时，代理在INVITE中包含嵌入的Reject Contact头字段。此邀请将根据Bob的注册联系人进行呼叫方首选项处理。
Bob has two registered Contacts. The second is a message server, and it matches the Reject-Contact in the INVITE. Thus, this contact is discarded. The other remaining Contact, Bob's phone, is tried. Bob is not around, so his phone rings for a while. Upon timeout, the proxy determines it is unable to reach Bob's AOR. So, the proxy handling Alice tries the final remaining contact, which is Alice's message server.
鲍勃登记了两个联系人。第二个是消息服务器，它匹配邀请中的拒绝联系人。因此，该接触被丢弃。另一个剩余的联系人，鲍勃的电话，正在尝试。鲍勃不在，所以他的电话响了一会儿。超时后，代理确定它无法到达Bob的AOR。因此，处理Alice的代理尝试最后剩下的联系人，即Alice的消息服务器。
The callee capabilities spec [2] allows the Contact header field in OPTIONS responses and dialog initiating messages to contain capabilities of the UA. These capabilities can be very useful for developing new applications. In the subsections below, several usages are outlined.
被调用方能力规范[2]允许选项响应和对话框启动消息中的联系人标题字段包含UA的能力。这些功能对于开发新的应用程序非常有用。在下面的小节中，概述了几种用法。
A caller sends an INVITE to the called party. However, the called party is not present. The proxy server representing the called party would like to redirect the caller to a web page, where they can find out more information on how to reach the called party. However, the proxy needs to know whether or not the caller supports redirects to web pages. If it doesn't, the proxy would connect the user to an interactive voice response (IVR) device, which would execute an answering machine application.
呼叫者向被叫方发送邀请。但是，被叫方不在场。代表被叫方的代理服务器希望将调用者重定向到一个网页，在那里他们可以找到关于如何到达被叫方的更多信息。但是，代理需要知道调用方是否支持重定向到网页。如果没有，代理将用户连接到交互式语音应答（IVR）设备，该设备将执行应答机应用程序。
The proxy could make such a determination if the caller included the "schemes" feature tag in the Contact header field of its INVITE:
如果调用方在其INVITE的Contact header字段中包含“schemes”功能标记，则代理可以做出这样的判断：
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
This tells the proxy that the UAC can be redirected to an http URI. The INVITE from a normal "black phone" that lacked this capability would look like:
这告诉代理可以将UAC重定向到http URI。来自缺少此功能的普通“黑色电话”的邀请如下所示：
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
This indicates that it needs to be connected to the IVR.
这表明它需要连接到IVR。
On the circuit network, when a user makes a call, and an answering machine picks up, the caller usually requires several seconds to determine that they are speaking to an answering machine. It would be helpful if a phone could display an icon immediately on call completion that indicated that an answering machine was reached.
在电路网络中，当用户拨打电话，应答机接听时，呼叫者通常需要几秒钟来确定他们正在与应答机通话。如果一部电话在通话结束后立即显示一个图标，表示已接通电话答录机，这将非常有帮助。
This indication can be provided by the "msgserver" feature parameter. When the answering machine picks up, its 200 OK looks like, in part:
此指示可由“msgserver”功能参数提供。当答录机启动时，其200 OK部分看起来像：
SIP/2.0 200 OK
Contact: <sip:server33.example.com>;msgserver;automata;attendant
SIP/2.0 200 OK
Contact: <sip:server33.example.com>;msgserver;automata;attendant
This tells the caller that it's an answering machine.
这会告诉打电话的人这是电话答录机。
The caller preferences extension briefly enumerates a list of media feature tags that can be registered by a device and included in the Accept-Contact and Reject-Contact header fields in a request. Proper operation of caller preferences depends strongly on consistent interpretation of these feature tags by the caller and the callee. In this section, we provide some guidelines on the usage of these feature tags.
caller preferences extension简要列举可由设备注册并包含在请求中的Accept Contact和Reject Contact标头字段中的媒体功能标签列表。调用者首选项的正确操作在很大程度上取决于调用者和被调用者对这些功能标记的一致解释。在本节中，我们将提供一些有关这些功能标签的使用指南。
Generally speaking, the more information a device provides when it registers, the more effective the caller preferences extension is. This is why the callee capabilities extension recommends that a device register as much information as it can. This point cannot be overstated.
一般来说，设备注册时提供的信息越多，调用者首选项扩展就越有效。这就是被调用方功能扩展建议设备注册尽可能多的信息的原因。这一点怎么强调也不过分。
If devices explicitly registered features that they don't support, such as 'video="false"', the operation of RFC 3841 would be improved. However, given the open-ended nature of capabilities, it will never be possible to ensure the registration of negative values for all capabilities of interest to a caller. Furthermore, attempting to do so would significantly bloat registrations. Instead, it is recommended that all "unusual" capabilities be explicitly registered.
如果设备明确注册了它们不支持的功能，例如“video=”false“，RFC 3841的操作将得到改进。但是，鉴于功能的开放性，永远不可能确保为调用方感兴趣的所有功能注册负值。此外，试图这样做会大大增加注册数量。相反，建议明确注册所有“异常”功能。
The subsections below show example registrations from typical devices.
下面的小节显示了典型设备的注册示例。
A VoIP cell phone capable of making voice calls would generate a registration that looks like, in part:
能够进行语音通话的VoIP手机将生成一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:cell-phone@example.com>
;audio
;class="business"
;duplex="full"
;+sip.extensions="100rel,path"
;mobility="mobile"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<cell-phone>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:cell-phone@example.com>
;audio
;class="business"
;duplex="full"
;+sip.extensions="100rel,path"
;mobility="mobile"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<cell-phone>"
;uri-domain="example.com"
A traditional landline IP PBX phone would generate a registration that looks like:
传统的固定线路IP PBX电话将生成如下注册：
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:ippbx-phone@example.com>
;audio
;class="business"
;duplex="full"
;events="dialog"
;+sip.extensions="100rel,privacy"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE"
;schemes="sip,sips,tel"
;uri-user="<ippbx-phone>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:ippbx-phone@example.com>
;audio
;class="business"
;duplex="full"
;events="dialog"
;+sip.extensions="100rel,privacy"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE"
;schemes="sip,sips,tel"
;uri-user="<ippbx-phone>"
;uri-domain="example.com"
This device also supports the dialog event package and several SIP extensions that would be typical in an IP PBX phone.
该设备还支持对话事件包和IP PBX电话中典型的几个SIP扩展。
A PC messenger client, capable of just doing presence and IM (no voice) would generate a registration that looks like:
PC messenger客户端只需进行状态和IM（无语音）即可生成如下注册：
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:pc-msgr@example.com>
;class="personal"
;mobility="fixed"
;methods="OPTIONS,MESSAGE,NOTIFY"
;schemes="sip,sips,im,pres"
;uri-user="<pc-msgr>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:pc-msgr@example.com>
;class="personal"
;mobility="fixed"
;methods="OPTIONS,MESSAGE,NOTIFY"
;schemes="sip,sips,im,pres"
;uri-user="<pc-msgr>"
;uri-domain="example.com"
A standalone IP videophone, capable of audio and video, would generate a registration that looks like, in part
一个独立的IP可视电话，能够播放音频和视频，将生成一个注册，部分看起来像
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:vp@example.com>
;audio
;video
;class="business"
;duplex="full"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<vp>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:vp@example.com>
;audio
;video
;class="business"
;duplex="full"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<vp>"
;uri-domain="example.com"
RFC 3841 [3] utilizes the definitions and feature matching algorithm defined in RFC 2533 [6]. This provides a precise normative specification of the algorithm. However, that specification isn't ideal as a guideline for implementation because it is more complex than is required for the restricted use employed by RFC 3841. (The simplification is primarily because a particular feature tag may only appear once in each Contact, Accept-Contact, or Reject-Contact header.)
RFC 3841[3]使用RFC 2533[6]中定义的定义和特征匹配算法。这为算法提供了精确的规范性规范。然而，该规范并不是理想的实现指南，因为它比RFC3841所采用的受限使用要求更复杂。（简化的主要原因是特定的功能标记在每个联系人、接受联系人或拒绝联系人标题中只能出现一次。）
This section provides a sample approach to implementing the matching of caller preferences to callee capabilities; it does not require the use of the notation and techniques of RFC 2533. It is not normative, but is believed to be consistent with that definition. It may be considered an alternative for that portion of RFC 3841 beginning with Section 7.2.3 and extending to the end of page 13 in the middle of Section 7.2.4.
本节提供了一种示例方法，用于实现呼叫者首选项与被呼叫者功能的匹配；它不需要使用RFC2533的符号和技术。它不是规范性的，但被认为与该定义一致。它可以被认为是从第7.2.3节开始的RFC 3841的一部分的替代，并且在7.2.4节的中间延伸到第13页的末尾。
In this section, there are frequent references to syntactic elements defined by ABNF in RFC 3840, Section 9, and RFC 3841, Section 10. Here, ABNF elements are enclosed to single quotes -- for example, 'feature-param'. Such a reference identifies a sequence of octets within a SIP request that match the corresponding ABNF element when the sip request is parsed according to RFCs 3261, 3840, and 3841.
在本节中，经常提到RFC3840第9节和RFC3841第10节中ABNF定义的语法元素。这里，ABNF元素用单引号括起来——例如，“feature param”。当根据RFCs 3261、3840和3841解析SIP请求时，这样的引用标识SIP请求内匹配相应ABNF元素的八位字节序列。
Contact header fields, Accept-Contact header fields, and Reject-Contact header fields each contain zero or more 'feature-param's, each in turn may contain one or more 'tag-value's, or a 'string-value'. The first step is to extract from each header field a more useful representation as a feature set, herein called an FS. (This FS representation of a feature set representation differs from that in RFC 2533.) This process is the same for each type of header.
联系人标题字段、接受联系人标题字段和拒绝联系人标题字段均包含零个或多个“功能参数”，每个字段依次可能包含一个或多个“标记值”或“字符串值”。第一步是从每个标题字段中提取一个更有用的表示，作为一个特征集，这里称为FS。（特征集表示的FS表示不同于RFC 2533中的表示。）对于每种类型的标头，此过程是相同的。
An FS consists of a set of one or more feature params denoted by FP. Each FP has a name, denoted FP.NAME, and a set of one or more value ranges denoted by VR. Each VR consists of:
FS由一组由FP表示的一个或多个特征参数组成。每个FP都有一个名称，表示为FP.name，以及一组由VR表示的一个或多个值范围。每个虚拟现实包括：
o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE), or number-range (RANGE-TYPE)
o 类型（VR.type）：令牌（token-type）、字符串（string-type）或数字范围（range-type）
o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED
o 否定标志（VR.negation）：否定或非否定
o The actual value, differing by type:
o 实际值，按类型不同：
* For TOKEN-TYPE and STRING-TYPE, a sequence of octets (VR.OCTETS)
* 对于TOKEN-TYPE和STRING-TYPE，八位字节序列（VR.octets）
* For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB) representing the lower and upper bounds on the range, inclusive.
* 对于RANGE-TYPE，一对有符号实数（VR.LB和VR.UB），表示范围的上下限（包括在内）。
A single FS is created to represent the features of one header. (Contact, Accept-Contact, Reject-Contact.) Within the FS, an FP is created for each 'feature-param' in the header. To create an FP, a 'feature-param' is examined as follows:
创建一个FS来表示一个标头的功能。（联系人、接受联系人、拒绝联系人。）在FS中，为标头中的每个“功能参数”创建FP。要创建FP，请检查“功能参数”，如下所示：
o If the 'feature-param' contains an instance of 'other-tags', then FP.NAME is the value matched by 'ftag-name'.
o 如果“功能参数”包含“其他标记”的实例，则FP.NAME是与“ftag NAME”匹配的值。
o Otherwise, the 'feature-param' contains an instance of 'base-tags'. If the value matched by 'base-tags' is "language" or "type", then FP.NAME is just the value matched by 'base-tags'. If not, then FP.NAME is the value matched by 'base-tags' and prefixed with "sip.".
o 否则，“功能参数”包含“基本标记”的实例。如果“基本标记”匹配的值是“语言”或“类型”，那么FP.NAME就是“基本标记”匹配的值。如果不是，则FP.NAME是与“基本标记”匹配并以“sip”为前缀的值。
o The value of the 'feature-param', if any, is processed (according to the rules in the next section) to extract a set of one or more VRs that are associated with the FP.
o 处理“feature param”（如果有）的值（根据下一节中的规则），以提取一组与FP关联的一个或多个VRs。
The value of a 'feature-param' is an encoded representation (as specified in RFC 3840) of one or more value ranges of the corresponding feature. There are several data types that these values may take on: boolean, token, string, number, or numeric range. The type is determined by the encoded form of the value. (These types and their representations are specific to this implementation.)
“特征参数”的值是对应特征的一个或多个值范围的编码表示（如RFC 3840中所规定）。这些值可能采用几种数据类型：布尔值、标记、字符串、数字或数字范围。类型由值的编码形式确定。（这些类型及其表示形式特定于此实现。）
(Note: numeric values can explicitly represent a range of values. The other types only represent single value: a degenerate range. The term value range is used to encompass all of these.)
（注意：数值可以显式表示一个值范围。其他类型仅表示单个值：退化范围。术语值范围用于包含所有这些值。）
The value of the 'feature-param' ('string-value', 'tag-value-list', or none) is converted to VR form as follows:
“功能参数”（“字符串值”、“标记值列表”或“无”）的值转换为VR格式，如下所示：
o If there is no value, then a single new VR is created with VR.TYPE = TOKEN-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS set to "true".
o 如果没有值，则创建一个新的VR，其中VR.TYPE=TOKEN-TYPE、VR.NERGISION=NON-NERGISED和VR.OCTETS设置为“true”。
o If the 'feature-param' contains a 'string-value', then a single new VR is created with VR.TYPE = STRING-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS is set to the octets matching 'qdtext'.
o 如果“功能参数”包含一个“字符串值”，则创建一个新的VR，其中VR.TYPE=string-TYPE，VR.NERGISION=NON-NERGISED，VR.OCTETS设置为与“qdtext”匹配的八位字节。
o Otherwise the 'feature-param' contains a 'tag-value-list', and a new VR is created for each 'tag-value' in the 'tag-value-list', as follows:
o 否则，“功能参数”包含一个“标签值列表”，并为“标签值列表”中的每个“标签值”创建一个新的VR，如下所示：
o If the 'tag-value' begins with "!", VR.NEGATION = NEGATED; otherwise, VR.NEGATION = NON-NEGATED.
o 如果“标记值”以“！”开头，则VR.NEGATION=NEGATED；否则，VR.NEGATION=非否定。
o If the 'tag-value' contains a 'boolean' or 'token-nobang', then VR.TYPE = TOKEN-TYPE, and VR.OCTETS is set to the octets matched by 'boolean' or 'token-nobang'.
o 如果“tag value”包含“boolean”或“token nobang”，则VR.TYPE=token-TYPE，且VR.OCTETS设置为与“boolean”或“token nobang”匹配的八位字节。
o If the 'tag-value' contains a 'numeric', VR.TYPE = RANGE-TYPE and:
o 如果“标记值”包含“数值”，则VR.TYPE=范围类型，并且：
* If 'numeric-relation' is "<=", VR.UB is set to the numeric value matching 'number'. VR.LB is set to MIN-REAL (a negative number with the largest expressible magnitude.)
* 如果“数值关系”为“<=”，则VR.UB设置为与“数字”匹配的数值。VR.LB设置为MIN-REAL（具有最大可表达幅值的负数）
* If 'numeric-relation' is "=", both VR.LB and VR.UB are set to the numeric value matching 'number'.
* 如果“数值关系”为“=”，则VR.LB和VR.UB均设置为与“数字”匹配的数值。
* If 'numeric-relation' is ">=", VR.LB is set to the numeric value matching 'number' plus a small epsilon. VR.UB is set to MAX-REAL (a positive number with the largest expressible magnitude).
* 如果“数值关系”为“>=”，则VR.LB设置为与“数字”匹配的数值加上一个小ε。VR.UB被设置为MAX-REAL（具有最大可表达大小的正数）。
* Else the 'numeric-relation' consists of two 'number's separated by a colon. In this case, VR.LB is set to the numeric value of the smaller of the two numbers, and VR.UB is set to the numeric value of the larger of the two numbers.
* 否则，“数字关系”由两个由冒号分隔的“数字”组成。在这种情况下，VR.LB设置为两个数字中较小者的数值，而VR.UB设置为两个数字中较大者的数值。
Two VRs match if their ranges overlap. The comparison is done according to type, and only comparisons between like types are defined. When two VRs of differing types are compared, they are considered not to overlap. Either or both of the VRs may be NEGATED. Comparison proceeds as follows:
如果两个VRs的范围重叠，则两个VRs匹配。比较是根据类型进行的，并且只定义相似类型之间的比较。当比较两个不同类型的VRs时，认为它们不重叠。两个VRs中的一个或两个可能被否定。比较如下：
o If the VRs are of different types, the match is false.
o 如果VRs的类型不同，则匹配为false。
o Otherwise:
o 否则：
* Two VRs with VR.TYPE = RANGE-TYPE match if max(VR1.LB, VR2.LB) <= min(VR1.UB, VR2.UB).
* 如果最大值（VR1.LB，VR2.LB）<=最小值（VR1.UB，VR2.UB），则两个VR与VR.TYPE=范围类型匹配。
* Two VRs with VR.TYPE = TOKEN-TYPE match if their respective VR.OCTETS values compare equal by case-insensitive comparison.
* 如果通过不区分大小写的比较，两个VR.TYPE=TOKEN-TYPE的VRs各自的VR.OCTETS值相等，则匹配。
* Two VRs with VR.TYPE = STRING-TYPE match if their respective VR.OCTETS values compare equal by case-sensitive comparison.
* 如果通过区分大小写的比较，两个VR.TYPE=STRING-TYPE的VR各自的VR.OCTETS值相等，则匹配。
o The result (true/false) is then negated if VR1.NEGATION = NEGATED, and negated again if VR2.NEGATION = NEGATED.
o 如果VR1.NEGATION=否定，则结果（真/假）为否定，如果VR2.NEGATION=否定，则再次否定。
In RFC 2533, the matching of two feature sets is commutative, but as applied to caller preferences matching it is not. In this application, one feature set comes from an Accept-Contact or Reject-Contact header, and the other comes from a Contact header. For purposes of this description, these will be termed the preferred-features (FSp) and the capability-features (FSc), respectively. Non-commutativity arises from explicit tests for the presence among capability-params of feature param names used in preferred-features.
在RFC2533中，两个特征集的匹配是可交换的，但当应用于呼叫者偏好匹配时，则不是。在此应用程序中，一个功能集来自接受联系人或拒绝联系人标题，另一个来自联系人标题。在本说明中，这些将分别被称为首选特性（FSp）和能力特性（FSc）。非交换性源于对首选功能中使用的功能参数名称的功能参数之间存在性的显式测试。
A preferred-features feature set FSp may be matched to one capability-features feature set FSc, and this yields the following metrics:
首选功能特性集FSp可与一个功能特性特性集FSc相匹配，这将产生以下指标：
o NPF - The number of preferred-features.
o NPF-首选功能的数量。
o NCF - The number of preferred-features for which there is a capability-feature of the same name.
o NCF-具有相同名称的功能特性的首选特性的数量。
o NVM - The number of value matches between corresponding features of the two feature sets.
o NVM-两个功能集的相应功能之间的值匹配数。
For a particular pair of FPp and FPc, these metrics are computed as follows:
对于特定的FPp和FPc对，这些指标的计算如下：
o All the metrics are set to zero.
o 所有指标都设置为零。
o The following steps are applied for each feature param (FPp) of the FSp:
o 以下步骤适用于FSp的每个特性参数（FPp）：
* NPF is incremented.
* NPF是递增的。
* A corresponding FP with the same name is sought (using case-insensitive comparison) in the FSc.
* 在FSc中查找具有相同名称的对应FP（使用不区分大小写的比较）。
* If a corresponding feature param (FPc) is found:
* 如果找到相应的功能参数（FPc）：
+ NCF is incremented.
+ NCF是递增的。
+ Every VR of FPp is matched to every VR of FPc.
+ FPp的每个VR与FPc的每个VR匹配。
+ If any of those matches succeed, NVM is incremented.
+ 如果其中任何一个匹配成功，NVM将递增。
The reject processing specified in Section 7.4.2 of RFC 3841 may be performed as follows:
RFC 3841第7.4.2节中规定的拒收处理可按如下方式进行：
o For each candidate Contact in the target set, match the feature set of each Reject-Contact to it.
o 对于目标集中的每个候选联系人，将每个拒绝联系人的特征集与其匹配。
o If (NVM == NPF) & (NCF == NPF), remove the contact URI from the target set.
o 如果（NVM==NPF）&（NCF==NPF），则从目标集中删除联系人URI。
The matching of an Accept-Contact against a Contact and subsequent scoring of the match specified in Section 7.4.2 of RFC 3841 may be performed as follows:
接受触点与RFC 3841第7.4.2节中规定的触点的匹配以及随后的匹配计分可按如下方式进行：
o Match the feature set of the Accept-Contact to that of the Contact as specified in Section 6.4.
o 按照第6.4节的规定，将接受触点的功能集与触点的功能集相匹配。
o If (NVM < NCF), then the match failed. If the Accept-Contact had its "require" flag set, then discard the corresponding contact URI from the target set.
o 如果（NVM<NCF），则匹配失败。如果Accept联系人设置了其“require”标志，则从目标集中丢弃相应的联系人URI。
o Compute the score as NVM/NPF.
o 将分数计算为NVM/NPF。
o Apply the "require" and "explicit" flags as specified in the text and Figure 7 of RFC 3841.
o 应用RFC 3841文本和图7中规定的“require”和“explicit”标志。
This document provides explanation and examples of the use and implementation of RFCs 3840 and 3841. The security considerations sections of those documents apply to the material presented here.
本文件提供了RFCs 3840和3841的使用和实施说明和示例。这些文件的安全注意事项部分适用于此处提供的材料。
The authors would like to thank Rohan Mahy for his input in this specification.
作者要感谢Rohan Mahy在本规范中的投入。
[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] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[2] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[3] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[4] 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.
[4] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[5] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[5] Lennox，J.和H.Schulzrinne，“呼叫处理语言框架和需求”，RFC 28242000年5月。
[6] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[6] Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[7] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[7] Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[9] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[10] Campbell, B., "The Message Session Relay Protocol", Work in Progress, July 2006.
[10] Campbell，B.，“消息会话中继协议”，正在进行的工作，2006年7月。
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 US
Paul Kyzivat思科系统1414马萨诸塞大道Boxborough，马萨诸塞州，美国01719
Phone: +1 978 936-1881
EMail: pkyzivat@cisco.com
Phone: +1 978 936-1881
EMail: pkyzivat@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）提供。