Internet Engineering Task Force (IETF) S. Lawrence, Ed.
Request for Comments: 6011 Linden Research, Inc.
Category: Informational J. Elwell
ISSN: 2070-1721 Siemens Enterprise Communications
October 2010
Internet Engineering Task Force (IETF) S. Lawrence, Ed.
Request for Comments: 6011 Linden Research, Inc.
Category: Informational J. Elwell
ISSN: 2070-1721 Siemens Enterprise Communications
October 2010
Session Initiation Protocol (SIP) User Agent Configuration
会话启动协议（SIP）用户代理配置
Abstract
摘要
This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service.
本文档定义了SIP用户代理如何从配置服务中查找、检索和维护当前配置信息的过程。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6011.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6011.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. User Agent Installation Examples ...........................4
1.3.1. Hosted IP Service Provider Example ..................5
1.3.2. IP-PBX Example ......................................5
1.3.3. Special Considerations for High Security
Deployments .........................................6
2. Obtaining User Agent Configuration ..............................6
2.1. Network Discovery ..........................................6
2.1.1. Link Layer Provisioning .............................7
2.1.2. Network Layer Provisioning ..........................7
2.2. Obtaining the Configuration Service Domain .................8
2.2.1. The Local Network Domain ............................8
2.2.2. Manual Domain Name Entry ............................8
2.3. Constructing the Configuration Request URL .................8
2.3.1. Obtaining a Configuration Service Base URL ..........9
2.3.2. Adding Configuration Request Parameters ............10
2.3.3. Configuration Request URI Example ..................12
2.4. Obtaining Configuration from the Configuration Service ....13
2.4.1. Configuration Data Request Authentication ..........13
2.4.2. Configuration Data Request Failure .................14
2.5. Configuration Changes .....................................15
2.5.1. Configuration Change Subscriptions .................16
2.5.2. Configuration Change Polling .......................18
2.6. Validity of Stored Configuration Data .....................19
2.6.1. Re-Validating Configuration Data ...................19
2.7. Retry Backoff Procedure ...................................20
3. Configuration Data .............................................20
3.1. Configuration Data Items ..................................20
3.1.1. Address-of-Record ..................................21
3.1.2. Realm ..............................................21
3.1.3. Username ...........................................21
3.1.4. Digest .............................................21
3.1.5. OutboundProxy ......................................21
3.2. Reset User Agent to Default Configuration .................21
4. IANA Considerations ............................................21
4.1. DHCP SIP User Agent Configuration Service Domains Option ..21
4.2. DHCPv6 SIP User Agent Configuration Service
Domains Option ............................................22
4.3. U-NAPTR Registration ......................................23
4.4. SIP Forum User Agent Configuration Parameter Registry .....23
5. Security Considerations ........................................24
6. Acknowledgements ...............................................26
7. Normative References ...........................................27
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. User Agent Installation Examples ...........................4
1.3.1. Hosted IP Service Provider Example ..................5
1.3.2. IP-PBX Example ......................................5
1.3.3. Special Considerations for High Security
Deployments .........................................6
2. Obtaining User Agent Configuration ..............................6
2.1. Network Discovery ..........................................6
2.1.1. Link Layer Provisioning .............................7
2.1.2. Network Layer Provisioning ..........................7
2.2. Obtaining the Configuration Service Domain .................8
2.2.1. The Local Network Domain ............................8
2.2.2. Manual Domain Name Entry ............................8
2.3. Constructing the Configuration Request URL .................8
2.3.1. Obtaining a Configuration Service Base URL ..........9
2.3.2. Adding Configuration Request Parameters ............10
2.3.3. Configuration Request URI Example ..................12
2.4. Obtaining Configuration from the Configuration Service ....13
2.4.1. Configuration Data Request Authentication ..........13
2.4.2. Configuration Data Request Failure .................14
2.5. Configuration Changes .....................................15
2.5.1. Configuration Change Subscriptions .................16
2.5.2. Configuration Change Polling .......................18
2.6. Validity of Stored Configuration Data .....................19
2.6.1. Re-Validating Configuration Data ...................19
2.7. Retry Backoff Procedure ...................................20
3. Configuration Data .............................................20
3.1. Configuration Data Items ..................................20
3.1.1. Address-of-Record ..................................21
3.1.2. Realm ..............................................21
3.1.3. Username ...........................................21
3.1.4. Digest .............................................21
3.1.5. OutboundProxy ......................................21
3.2. Reset User Agent to Default Configuration .................21
4. IANA Considerations ............................................21
4.1. DHCP SIP User Agent Configuration Service Domains Option ..21
4.2. DHCPv6 SIP User Agent Configuration Service
Domains Option ............................................22
4.3. U-NAPTR Registration ......................................23
4.4. SIP Forum User Agent Configuration Parameter Registry .....23
5. Security Considerations ........................................24
6. Acknowledgements ...............................................26
7. Normative References ...........................................27
A user gets a new SIP User Agent (UA); it may be a hardware device or software. Some User Agents have a user interface that can accept a username, password, and domain name. Other devices, like Analog Telephony Adapters (ATAs), have no user interface other than that provided by an attached analog phone. How does a non-technical user minimally configure it so that when it is started, something useful happens?
用户获得新的SIP用户代理（UA）；它可能是硬件设备或软件。某些用户代理具有可接受用户名、密码和域名的用户界面。其他设备，如模拟电话适配器（ATA），除了由连接的模拟电话提供的用户界面外，没有其他用户界面。非技术用户如何最低限度地配置它，以便在启动时发生有用的事情？
This document specifies a procedure for how a SIP User Agent locates, retrieves, and maintains current configuration information for a given SIP Service Provider. As such, it specifies requirements to be met by both the User Agent, the Configuration Service at the SIP Service Provider, and the network infrastructure services that allow them to communicate.
本文档指定了SIP用户代理如何查找、检索和维护给定SIP服务提供商的当前配置信息的过程。因此，它指定了用户代理、SIP服务提供商的配置服务以及允许它们通信的网络基础设施服务都要满足的要求。
Nothing in this specification prohibits a User Agent from obtaining configuration information by any means in addition to the mechanisms specified herein.
本规范中的任何内容均不禁止用户代理通过本文规定的机制之外的任何方式获取配置信息。
The intent of this specification is to provide mechanisms sufficient for User Agents to discover an appropriate source of configuration and maintain the currency of that configuration. A User Agent implementation compliant with this specification MAY also implement additional mechanisms necessary in particular environments or when the services specified here are not available.
本规范旨在为用户代理提供足够的机制，以发现适当的配置源并保持该配置的通用性。符合本规范的用户代理实现还可以实现特定环境中或此处指定的服务不可用时所需的其他机制。
The form and content of configuration data to be downloaded are outside the scope of this specification, although Section 3.1, "Configuration Data Items" suggests a minimum set of data items likely to be required by all types of UAs.
要下载的配置数据的形式和内容不在本规范的范围内，尽管第3.1节“配置数据项”建议了所有类型的UAs可能需要的最小数据项集。
The following terms are used in this document:
本文件中使用了以下术语：
User Agent, UA
用户代理
As defined in RFC 3261 [RFC3261]. Note that this includes any implementation of a User Agent. A SIP phone is a User Agent, but the term also encompasses any other entity that uses SIP (for example, for a text chat, for sharing a whiteboard, or for a fax).
如RFC 3261[RFC3261]中所定义。注意，这包括用户代理的任何实现。SIP电话是一种用户代理，但该术语还包括使用SIP的任何其他实体（例如，用于文本聊天、共享白板或传真）。
Soft User Agent, Soft UA
软用户代理
A User Agent that runs as an application within some larger system that has responsibility for some of the steps described in this specification. In those cases, the Soft UA must be able to obtain the information from the platform. In all cases, the term User Agent also encompasses a Soft User Agent.
一种用户代理，在某个较大系统中作为应用程序运行，负责本规范中描述的某些步骤。在这些情况下，软UA必须能够从平台获取信息。在所有情况下，术语用户代理还包括软用户代理。
SIP Service Provider, Service Provider
SIP服务提供商，服务提供商
An entity that provides services to User Agents using the SIP protocol. This specification requires that a Service Provider make configuration data and certain other information available in order to configure User Agents.
使用SIP协议向用户代理提供服务的实体。本规范要求服务提供商提供配置数据和某些其他信息，以便配置用户代理。
Configuration
配置
The set of information that establishes operational parameters for a particular User Agent.
为特定用户代理建立操作参数的一组信息。
Configuration Service, CS
配置服务
The source of Configuration for User Agents.
用户代理的配置源。
Configuration Service Domain
配置服务域
The DNS name for the service from which a Configuration is requested.
请求配置的服务的DNS名称。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section is non-normative; it is a set of "user stories" -- narrative descriptions of the user experience in different environments. These are "black box" descriptions meant to include the actions to be taken by the human participants (including administrators and system operators as well as the "user" of the UA), but not how the network elements communicate or operate internally. The intent is that these narratives provide context for the subsequent technical specifications.
本节不规范；它是一组“用户故事”——不同环境中用户体验的叙述性描述。这些是“黑盒”描述，旨在包括人类参与者（包括管理员和系统操作员以及UA的“用户”）将采取的行动，但不包括网元内部通信或操作的方式。目的是这些叙述为后续技术规范提供背景。
Configuring a new UA to use a hosted IP telephony service will typically proceed as follows: the customer makes a request to their Service Provider to add one or more new users to their service. The customer may supply further details such as a preferred username, type of endpoint and any requests for specific functionality, depending on what information the Service Provider considers useful, but no additional information is required from the customer.
配置新UA以使用托管IP电话服务通常将按如下方式进行：客户向其服务提供商发出请求，向其服务添加一个或多个新用户。根据服务提供商认为有用的信息，客户可以提供进一步的详细信息，如首选用户名、端点类型和对特定功能的任何请求，但不需要客户提供其他信息。
The Service Provider performs any necessary provisioning actions on their equipment, and returns to the customer provisioning information, which may include a domain name or a numeric domain identifier for the provider, a user identifier, and a password. Typically, a Service Provider will supply provisioning information for each device to be provisioned, but may choose to supply information that can be used with multiple devices, or for a limited duration or with other benefits and restrictions.
服务提供商在其设备上执行任何必要的配置操作，并向客户返回配置信息，该信息可以包括提供商的域名或数字域标识符、用户标识符和密码。通常，服务提供商将为每个要供应的设备提供供应信息，但可以选择提供可用于多个设备、有限持续时间或其他好处和限制的信息。
The customer enters the provisioning information into the UA to be configured, whereupon the UA uses this information to locate the configuration service, securely fetch the configuration information, and configure itself for operation.
客户将配置信息输入要配置的UA，UA随后使用此信息定位配置服务，安全地获取配置信息，并配置自身以进行操作。
Configuring a new UA in a typical business begins by provisioning a user identity in the Private Branch Exchange (PBX) (add user "John Smith"), and assigning a phone number to the user. That number must then be assigned to a line on a specific UA; this is usually done by selecting a UA and provisioning it in the PBX by its serial number (usually a Media Access Control (MAC) address), and then assigning the identity or phone number to a 'line' on that UA in the PBX configuration system.
在典型业务中配置新的UA首先在专用交换机（PBX）中提供用户身份（添加用户“John Smith”），并为用户分配电话号码。然后必须将该号码分配给特定UA上的一条线路；这通常是通过选择UA并通过其序列号（通常是媒体访问控制（MAC）地址）在PBX中设置它，然后在PBX配置系统中将标识或电话号码分配给该UA上的“线路”来完成的。
Once provisioning in the PBX is complete, the new user goes to his or her workplace and connects the UA to the network. When connected and powered up, the UA is provided with the user identity, phone number, and any other configuration data with no local user interaction -- just connecting it to the network loads the configuration from the PBX and the UA is operational.
PBX中的资源调配完成后，新用户将前往其工作场所并将UA连接到网络。连接并通电后，UA将获得用户身份、电话号码和任何其他配置数据，而无需本地用户交互——仅将其连接到网络即可从PBX加载配置，UA即可运行。
To deploy a new UA in a high security scenario requires some special consideration. A security-conscious deployment will most likely require that the SIP and other management interfaces, including the interface to the configuration service, be secured before the device is put into service.
在高安全性场景中部署新UA需要一些特殊考虑。有安全意识的部署很可能需要在设备投入使用之前保护SIP和其他管理接口，包括配置服务的接口。
In order to achieve any level of security, the device will need to be pre-configured with some security-related information in the form of certificates. This may be achieved in a number of ways. Some examples include:
为了实现任何级别的安全性，设备需要预先配置一些证书形式的安全相关信息。这可以通过多种方式实现。一些例子包括：
1. An administrator who configures the device in a secure environment before making the device available to the user.
1. 在向用户提供设备之前，在安全环境中配置设备的管理员。
2. Some certificates may be built into the device during the manufacturing process enabling the configuration service to certify information such as the manufacturer, UA type, and MAC address. The configuration service may then be used to provision the device with other certificates as required.
2. 一些证书可以在制造过程中内置到设备中，使得配置服务能够认证诸如制造商、UA类型和MAC地址之类的信息。然后，配置服务可用于根据需要向设备提供其他证书。
3. The device may have a facility for the user to provide the security information in the form of a security card or dongle.
3. 该设备可以具有用于用户以安全卡或加密狗的形式提供安全信息的设施。
All these mechanism are likely to restrict the user to a limited set of devices approved for use in a particular deployment.
所有这些机制都可能会将用户限制在一组经批准可用于特定部署的有限设备上。
This section specifies how a User Agent connects to the network, determines for which domain to request configuration, obtains configuration from that domain, and is notified by that domain when the configuration changes.
本节指定用户代理如何连接到网络，确定要请求配置的域，从该域获取配置，并在配置更改时由该域通知。
The User Agent MAY obtain configuration information by any means in addition to those specified here, and MAY use such information in preference to any of the steps specified below, but MUST be capable of using these procedures alone in order to be compliant with this specification.
用户代理可以通过除此处指定的方式之外的任何方式获得配置信息，并且可以优先于下面指定的任何步骤使用此类信息，但必须能够单独使用这些过程，以符合本规范。
A UA needs a minimum set of parameters to allow it to communicate on the network. Some networks allow the UA to automatically discover these parameters, while other networks require some or all of these parameters to be manually provisioned on the UA.
UA需要一组最小的参数，以允许其在网络上通信。一些网络允许UA自动发现这些参数，而其他网络则要求在UA上手动设置部分或全部这些参数。
The UA SHOULD attempt to use Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED; see [ANSI.TIA-1057-2006]) for automatic provisioning of link layer parameters.
UA应尝试使用链路层发现协议-媒体端点发现（LLDP-MED；见[ANSI.TIA-1057-2006]）来自动设置链路层参数。
In some deployments, failure to properly provision the link layer may result in the UA having incorrect Layer 2 priority, degrading the quality of service, or being on the wrong virtual LAN (VLAN), possibly resulting in complete loss of service.
在某些部署中，未能正确配置链路层可能导致UA具有不正确的第2层优先级，降低服务质量，或位于错误的虚拟LAN（VLAN）上，可能导致服务完全丢失。
In order to communicate using IP, the UA needs the following minimal IP configuration parameters:
为了使用IP进行通信，UA需要以下最低限度的IP配置参数：
IP Network Parameters
IP网络参数
o UA IP Address
o UA IP地址
o Subnet Mask
o 子网掩码
o Gateway IP address
o 网关IP地址
o DNS Server IP address(es)
o DNS服务器IP地址
With the exception of a Soft UA that relies on its platform to obtain the IP Network Parameters:
除依赖其平台获取IP网络参数的软UA外：
o If the User Agent is using IP version 4 on a network technology for which the Dynamic Host Configuration Protocol (DHCP) [RFC2131] is defined, the UA MUST attempt to obtain the IP Network Parameters using DHCP and MUST request DHCP options 141 (see Section 4.1) and 15 [RFC2132]. If the DHCP service provides a value for option 141, the domain name(s) it provides MUST be saved as candidates for use as the Local Network Domain (see Section 2.2, "Obtaining the Configuration Service Domain"). If and only if no values are returned for option 141, the UA MUST save any values returned for option 15 for use as the Local Network Domain.
o 如果用户代理在定义了动态主机配置协议（DHCP）[RFC2131]的网络技术上使用IP版本4，UA必须尝试使用DHCP获取IP网络参数，并且必须请求DHCP选项141（参见第4.1节）和15[RFC2132]。如果DHCP服务为选项141提供值，则必须将其提供的域名保存为候选域名，以用作本地网络域（请参阅第2.2节“获取配置服务域”）。如果且仅当没有为选项141返回值时，UA必须保存为选项15返回的任何值，以用作本地网络域。
o If the User Agent is using IP version 6 on a network technology for which the Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315] is defined, the UA MAY use any standard IPv6 mechanism to determine the IP Network Parameters, but MUST request DHCPv6 options 58 (see Section 4.2) and 21 [RFC3319]. If the DHCPv6 service provides a value for option 58, those domain names MUST be saved as candidates for use as the Local Network Domain
o 如果用户代理在定义了动态主机配置协议版本6（DHCPv6）[RFC3315]的网络技术上使用IP版本6，UA可以使用任何标准IPv6机制来确定IP网络参数，但必须请求DHCPv6选项58（参见第4.2节）和21[RFC3319]。如果DHCPv6服务为选项58提供值，则必须将这些域名保存为候选域名，以用作本地网络域
(see Section 2.2, "Obtaining the Configuration Service Domain"). If and only if no values are returned for option 58, the UA MUST save any values returned for option 21 for use as the Local Network Domain.
（参见第2.2节“获取配置服务域”）。如果且仅当没有为选项58返回值时，UA必须保存为选项21返回的任何值，以用作本地网络域。
To obtain a configuration, the UA needs to know what domain to request it from. This domain is the Configuration Service Domain; its value is a DNS name (see [RFC1034]).
要获得配置，UA需要知道从哪个域请求配置。该域是配置服务域；其值是DNS名称（请参见[RFC1034]）。
User control or prior configuration MAY establish a value for the Configuration Service Domain that takes precedence over the discovery procedure defined below. In the absence of user control or prior configuration, candidate values for the Configuration Service Domain are obtained as specified in Section 2.2.1, "The Local Network Domain", or if that is unsuccessful, by the manual mechanism specified in Section 2.2.2, "Manual Domain Name Entry".
用户控制或先前的配置可能会为配置服务域建立一个优先于下面定义的发现过程的值。在没有用户控制或先前配置的情况下，根据第2.2.1节“本地网络域”中的规定获取配置服务域的候选值，或者如果未成功，则通过第2.2.2节“手动域名输入”中规定的手动机制获取。
The UA MUST attempt to use each value obtained for the Local Network Domain name (see Section 2.1.2, "Network Layer Provisioning") as the Configuration Service Domain. If multiple names are provided by DHCP and/or DHCPv6 (multiple names may be returned by these services if both are in use, if the UA has multiple network interfaces, or if the option responses have multiple values), the UA MUST attempt to use each of the names provided until a configuration is successfully obtained. The order in which values obtained in different responses are used is not defined by this specification -- the UA MAY use any order; multiple values returned within a single response MUST be tried in the order they were provided in that response.
UA必须尝试使用为本地网络域名获得的每个值（参见第2.1.2节“网络层配置”）作为配置服务域。如果DHCP和/或DHCPv6提供了多个名称（如果两者都在使用，如果UA有多个网络接口，或者如果选项响应有多个值，则这些服务可能会返回多个名称），UA必须尝试使用提供的每个名称，直到成功获得配置。本规范未定义在不同响应中获得的值的使用顺序——UA可以使用任何顺序；必须按照响应中提供的顺序尝试在单个响应中返回的多个值。
If the DHCP service does not provide any local domain name values, the UA SHOULD use the manual mechanism defined in Section 2.2.2, "Manual Domain Name Entry".
如果DHCP服务不提供任何本地域名值，UA应使用第2.2.2节“手动域名输入”中定义的手动机制。
A UA MAY provide an interface by which a DNS name is supplied directly by the user for the Configuration Service Name.
UA可以提供一个接口，用户通过该接口直接为配置服务名称提供DNS名称。
Using the Configuration Service Domain name obtained in Section 2.2, "Obtaining the Configuration Service Domain", the UA MUST construct an HTTPS URL [RFC2818] with which to request configuration. Constructing this URL consists of two parts:
UA必须使用第2.2节“获取配置服务域”中获得的配置服务域名构建HTTPS URL[RFC2818]，以请求配置。构建此URL由两部分组成：
o Section 2.3.1, "Obtaining a Configuration Service Base URL"
o 第2.3.1节，“获取配置服务基本URL”
o Section 2.3.2, "Adding Configuration Request Parameters"
o 第2.3.2节，“添加配置请求参数”
The Configuration Service Domain is resolved to one or more URLs using the URI-enabled Naming Authority Pointer (U-NAPTR) DDDS application defined in "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)" [RFC4848].
配置服务域使用“使用URI和动态委派发现服务（DDDS）”中定义的启用URI的命名机构指针（U-NAPTR）DDDS应用程序解析为一个或多个URL[RFC4848]。
The lookup key for the U-NAPTR request is the Configuration Service Domain name determined in Section 2.2, "Obtaining the Configuration Service Domain". The UA MUST make a DNS request for NAPTR records for that domain name. From the returned records, the UA MUST select those whose Service field value is "SFUA.CFG"; from those records, the UA MUST extract the HTTPS URL of the Configuration Service from the Regular Expression field (see next paragraph for the construction of that field value).
U-NAPTR请求的查找键是第2.2节“获取配置服务域”中确定的配置服务域名。UA必须为该域名的NAPTR记录发出DNS请求。UA必须从返回的记录中选择服务字段值为“SFUA.CFG”的记录；从这些记录中，UA必须从正则表达式字段中提取配置服务的HTTPS URL（该字段值的构造见下一段）。
The NAPTR records for the Configuration Service Domain name whose Service field value is "SFUA.CFG" MUST be configured with the Flag field set to "U", an empty Substitution field, and a Regular Expression field value of the following syntax (i.e., a regular expression to replace the domain name with an https URI):
服务字段值为“SFUA.CFG”的配置服务域名的NAPTR记录必须使用设置为“U”的标志字段、空替换字段和以下语法的正则表达式字段值（即用https URI替换域名的正则表达式）进行配置：
u-naptr-regexp = "!.*!" <URI> "!"
u-naptr-regexp = "!.*!" <URI> "!"
where <URI> is as defined in STD 66 [RFC3986], the URI syntax specification, and where the scheme of the URI is "https".
其中<URI>如STD 66[RFC3986]中所定义，URI语法规范，其中URI的方案为“https”。
Note that the UA does not need to implement a general regular expression evaluator in order to process the record above correctly. The URI value can be extracted by stripping the fixed value "!^.*!" from the beginning of the value, and "!" from the end of the value to obtain the base URL. See Section 2.3.3, "Configuration Request URI Example".
请注意，UA不需要实现通用正则表达式计算器来正确处理上述记录。可以通过从值的开头剥离固定值“！^.*！”，从值的结尾剥离固定值“！”来提取URI值，以获得基本URL。请参阅第2.3.3节“配置请求URI示例”。
Multiple Configuration Servers can be used to provide redundancy and additional capacity for provisioning User Agents. If the DNS NAPTR request for the Configuration Service Domain name returns multiple records with the 'SFUA.CFG' service tag, then the UA should treat the resulting URLs as alternatives, ordered according to the rules for the priority and weight as specified for NAPTR records.
可以使用多个配置服务器为配置用户代理提供冗余和额外容量。如果配置服务域名的DNS NAPTR请求返回多个带有“SFUA.CFG”服务标签的记录，则UA应将生成的URL视为备选URL，并根据为NAPTR记录指定的优先级和权重规则进行排序。
In addition to redundancy provided by multiple NAPTR records, resolution of the host part of the HTTPS URL can produce multiple results.
除了多条NAPTR记录提供的冗余之外，解析HTTPS URL的主机部分还可以产生多个结果。
If the DNS request to resolve the Configuration Service Domain name to a request URL does not receive any response, the UA should follow standard DNS retry procedures.
如果将配置服务域名解析为请求URL的DNS请求未收到任何响应，UA应遵循标准DNS重试程序。
If the DNS request to resolve the Configuration Service Domain name to a host name returns a response that indicates that no matching result is available (NXDOMAIN), the UA SHOULD attempt to obtain another Configuration Service Domain name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain".
如果将配置服务域名解析为主机名的DNS请求返回的响应表明没有可用的匹配结果（NXDOMAIN），UA应尝试使用第2.2节“获取配置服务域名”中的程序获取另一个配置服务域名。
To construct the full configuration request URL, the UA adds one or more parameters to the base URLs to specify what configuration the UA is requesting.
为了构造完整的配置请求URL，UA向基本URL添加一个或多个参数，以指定UA请求的配置。
1. The UA MUST add all parameters from those defined in the Configuration Request Parameters list below for which the UA has a value. Any parameter from that set for which the UA does not have a value MUST be omitted.
1. UA必须添加以下配置请求参数列表中定义的UA有值的所有参数。必须忽略UA没有值的该集合中的任何参数。
2. The query parameter names defined by this specification all begin with the prefix 'sfua-'. All names beginning with the prefix 'sfua-' are reserved for this specification and future revisions. The UA MUST NOT include any request parameter whose name begins with the prefix 'sfua-' that is not defined by this specification (including any future revisions).
2. 此规范定义的查询参数名称都以前缀“sfua-”开头。以前缀“sfua-”开头的所有名称保留用于本规范和未来版本。UA不得包含任何名称以前缀“sfua-”开头的请求参数，该前缀未在本规范中定义（包括任何未来版本）。
3. Any parameter not defined by the specification is allowed, but MUST be ignored by any Configuration Service that does not recognize it.
3. 允许使用规范未定义的任何参数，但任何不识别该参数的配置服务都必须忽略该参数。
The following parameters are defined for the configuration request. Section 4.4 creates an IANA registry for these and any parameters defined in the future.
为配置请求定义了以下参数。第4.4节为这些参数和将来定义的任何参数创建IANA注册表。
sfua-id
sfua id
The URN identifying the User Agent, constructed as specified in Section 4.1 of [RFC5626] "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)".
标识用户代理的URN，按照[RFC5626]“在会话启动协议（SIP）中管理客户端启动的连接”第4.1节的规定构造。
Since the procedure defined by [RFC5626] allows any UA to construct a value for this parameter, the sfua-id parameter MUST always be included.
由于[RFC5626]定义的程序允许任何UA为此参数构造一个值，因此必须始终包括sfua id参数。
If the UA implements [RFC5626], and includes the '+sip.instance' Contact header field parameter in any request, when requesting configuration it MUST use the same value for the sfua-id parameter.
如果UA实现[RFC5626]，并在任何请求中包含“+sip.instance”联系人标头字段参数，则在请求配置时，必须对sfua id参数使用相同的值。
sfua-user
sfua用户
An identifier for a user associated with the configuration. Note that this might be different than any SIP 'user' in the UA configuration: it could, for example, be the login name of an account on the service provider web site. The syntax of this parameter is that of the 'userid' [RFC2617].
与配置关联的用户的标识符。请注意，这可能不同于UA配置中的任何SIP“用户”：例如，它可能是服务提供商网站上帐户的登录名。此参数的语法为“userid”[RFC2617]的语法。
See Section 2.4.1, "Configuration Data Request Authentication" for how this parameter relates to authentication of the configuration data request.
请参阅第2.4.1节“配置数据请求验证”，了解此参数与配置数据请求验证的关系。
sfua-vendor
sfua供应商
An identifier that specifies the vendor of the User Agent. The syntax of the value of this parameter is that of a DNS domain. The domain value MUST be that of a domain owned by the vendor.
指定用户代理的供应商的标识符。此参数值的语法为DNS域的语法。域值必须是供应商拥有的域的值。
sfua-model
sfua模型
An identifier that further specifies the User Agent from among those produced by the vendor. The syntax of the value of this parameter is the same as the 'token' [RFC3261]. Values for this parameter are selected by the vendor.
一种标识符，用于从供应商生产的代理中进一步指定用户代理。此参数值的语法与“令牌”[RFC3261]相同。此参数的值由供应商选择。
sfua-revision
sfua修订版
An identifier that further specifies the User Agent from among those produced by the vendor. The syntax of the value of this parameter is the same as the 'token' [RFC3261]. Values for this parameter are selected by the vendor.
一种标识符，用于从供应商生产的代理中进一步指定用户代理。此参数值的语法与“令牌”[RFC3261]相同。此参数的值由供应商选择。
Using the rules in Section 2.2, "Obtaining the Configuration Service Domain", the UA has determined that the Configuration Service Domain value is "example.net". To obtain the base URL, the UA constructs the DNS NAPTR request for "example.net.", which returns the DNS records:
使用第2.2节“获取配置服务域”中的规则，UA已确定配置服务域值为“example.net”。为了获得基本URL，UA为“example.net.”构造DNS NAPTR请求，该请求返回DNS记录：
NAPTR 10 10 "u" "SFUA.CFG" "!^.*$!https://p1.example.net/cfg!" "" NAPTR 100 10 "u" "SFUA.CFG" "!^.*$!https://p2.example.net/cfg!" "" NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.net. NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.net.
NAPTR 10 10“u”“SFUA.CFG”！^.*$！https://p1.example.net/cfg！“NAPTR 100 10”u“SFUA.CFG”！^.*$！https://p2.example.net/cfg！“NAPTR 90 50”s“SIP+D2T”\u SIP.\u tcp.example.net。NAPTR 100 50“s”SIP+D2U“\u SIP.\u udp.example.net。
Figure 1: Example Configuration Service NAPTR Query Results
图1：示例配置服务NAPTR查询结果
The records with the service-field "SFUA.CFG" each provide a base URL value for SIP UA configuration requests.
服务字段为“SFUA.CFG”的记录都为SIP UA配置请求提供一个基本URL值。
Our hypothetical example communications device is a 'HypoComm' version 2.1, made by ExampleCorp, and has the link layer MAC address of 00:11:22:33:44:55. It does not have any prior knowledge of a user identity for which to request configuration, so it constructs query parameters using the values it does have, combining each with the base URL to create these request URLs (lines wrapped for readability):
我们假设的示例通信设备是由ExampleCorp制造的“次通信”版本2.1，其链路层MAC地址为00:11:22:33:44:55。它对要请求配置的用户标识没有任何先验知识，因此它使用它确实具有的值构造查询参数，将每个值与基本URL组合以创建这些请求URL（为可读性而包装的行）：
https://p1.example.net/cfg
?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455
&sfua-vendor=examplecorp.com
&sfua-model=HypoComm
&sfua-revision=2.1
https://p2.example.net/cfg
?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455
&sfua-vendor=examplecorp.com
&sfua-model=HypoComm
&sfua-revision=2.1
https://p1.example.net/cfg
?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455
&sfua-vendor=examplecorp.com
&sfua-model=HypoComm
&sfua-revision=2.1
https://p2.example.net/cfg
?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455
&sfua-vendor=examplecorp.com
&sfua-model=HypoComm
&sfua-revision=2.1
Figure 2: Example Configuration Request URLs
图2：配置请求URL示例
To request configuration using a URL constructed as specified in Section 2.3, "Constructing the Configuration Request URL" the User Agent MUST do an HTTPS GET request to each of the URLs until a configuration that the UA can use is returned in response to one of the requests.
要使用第2.3节“构造配置请求URL”中指定的URL请求配置，用户代理必须对每个URL执行HTTPS GET请求，直到UA可以使用的配置返回以响应其中一个请求。
A successful final response from the Configuration Service to a GET request for configuration data MUST contain configuration data for the UA in the HTTP response body. Note that the full capabilities of HTTP as specified in [RFC2616] are available to the CS, so responses such as redirection can be used by the CS as a part of the process of providing configuration data.
配置服务对配置数据GET请求的成功最终响应必须在HTTP响应正文中包含UA的配置数据。请注意，[RFC2616]中规定的HTTP的全部功能可供CS使用，因此CS可以使用重定向等响应作为提供配置数据过程的一部分。
Configuration data returned in a successful response is subject to change by the CS. The HTTP cache control metadata (the max-age directive value from any Cache-Control header, and the Etag and Last-Modified header values) returned in the response that provides configuration data is used to determine when a configuration change has occurred (Section 2.5.1.3, "Configuration Change Notices") and to validate any stored configuration data (Section 2.6, "Validity of Stored Configuration Data").
成功响应中返回的配置数据可能会被CS更改。在提供配置数据的响应中返回的HTTP缓存控制元数据（来自任何缓存控制标头的max age指令值，以及Etag和上次修改的标头值）用于确定何时发生配置更改（第2.5.1.3节，“配置更改通知”）以及验证任何存储的配置数据（第2.6节，“存储的配置数据的有效性”）。
o An HTTP response from the CS that provides configuration data MUST include cache control metadata sufficient to ensure that when a new configuration is available, the cache control information for that new data is different.
o 来自提供配置数据的CS的HTTP响应必须包含足够的缓存控制元数据，以确保当新配置可用时，该新数据的缓存控制信息不同。
o The UA MUST retain all of the HTTP cache control metadata from any response that provides configuration data.
o UA必须保留提供配置数据的任何响应中的所有HTTP缓存控制元数据。
Since the Configuration Request URL scheme is HTTPS, the UA MUST always use Transport Layer Security (TLS) [RFC5246] to establish a connection with the Configuration Service.
由于配置请求URL方案是HTTPS，UA必须始终使用传输层安全性（TLS）[RFC5246]与配置服务建立连接。
The UA MUST provide a server_name extension in the TLS Client Hello message as defined in [RFC4366] "Transport Layer Security (TLS) Extensions", whose value is the Configuration Service Domain name (note that this might not be the same as the host part of the CS base URL). This allows the CS to identify and provide a server certificate containing the desired identity (allowing for a single server to serve multiple domain names).
UA必须按照[RFC4366]“传输层安全（TLS）扩展”中的定义，在TLS客户端Hello消息中提供服务器名称扩展，其值为配置服务域名（请注意，这可能与CS基本URL的主机部分不同）。这允许CS识别并提供包含所需标识的服务器证书（允许单个服务器提供多个域名）。
A UA MUST attempt to validate the server certificate provided by the CS, in accordance with the rules defined in Section 3.1 of [RFC2818]. Unfortunately, the validation attempt might fail (e.g., because the UA might not have in firmware a trusted root CA cert to which the CS certificate chain can be connected or because the root CA cert has expired since the UA firmware was last updated). If the UA is unable to validate the server certificate provided by the CS, the UA SHOULD store the server certificate and alert the user if that CS host provides a different certificate in the future. Although this 'trust on first use' model is not as secure as certificate validation, it does give some protection against man-in-the-middle (MITM) attacks in the future.
UA必须根据[RFC2818]第3.1节中定义的规则，尝试验证CS提供的服务器证书。不幸的是，验证尝试可能会失败（例如，因为UA固件中可能没有CS证书链可以连接到的受信任根CA证书，或者因为自UA固件上次更新以来根CA证书已过期）。如果UA无法验证CS提供的服务器证书，UA应存储服务器证书，并在CS主机将来提供不同证书时提醒用户。尽管这种“首次使用时信任”模型不如证书验证安全，但它确实为将来的中间人（MITM）攻击提供了一些保护。
If it has one, the UA MUST provide a client certificate. The CS MUST validate the UA client's certificate, if one is provided. If the CS is unable to authenticate the certificate provided by the UA (for example, the UA is using a self-signed certificate), then the CS MAY choose to cache the certificate, provided that the UA successfully authenticates using HTTP authentication (see next paragraph). This allows a CS to treat the digest authentication credentials as a single-use password to authenticate the client certificate. This 'trust on first use' model provides protection against future MITM attacks, provided that the initial communication is not compromised.
如果有，UA必须提供客户端证书。CS必须验证UA客户的证书（如果提供）。如果CS无法对UA提供的证书进行身份验证（例如，UA正在使用自签名证书），则CS可以选择缓存该证书，前提是UA使用HTTP身份验证成功进行身份验证（参见下一段）。这允许CS将摘要身份验证凭据视为一次性密码来验证客户端证书。这种“首次使用时信任”模式提供了针对未来MITM攻击的保护，前提是初始通信不受损害。
If the CS requires HTTP authentication of the configuration data request, the HTTP 'username' parameter used MUST be the same value as the sfua-user value provided in the configuration data request parameters. The UA MUST implement both Basic and Digest authentication as specified by [RFC2617].
如果CS要求对配置数据请求进行HTTP身份验证，则使用的HTTP“username”参数必须与配置数据请求参数中提供的sfua用户值相同。UA必须按照[RFC2617]的规定实施基本认证和摘要认证。
The HTTP configuration data request can fail in a number of ways; the error handling for each is defined below:
HTTP配置数据请求可能以多种方式失败；以下定义了每种方法的错误处理：
o If a DNS request to resolve the host name in the request URL returns a response that indicates that no matching result is available (NXDOMAIN), the UA MUST remove that request URL from the list of alternatives for the Configuration Service Domain.
o 如果解析请求URL中主机名的DNS请求返回的响应表明没有可用的匹配结果（NXDOMAIN），UA必须从配置服务域的备选方案列表中删除该请求URL。
o If the attempt to open a TCP connection to the host in the request URL fails, the UA MAY attempt requests to any alternative URLs for the same configuration service without waiting between alternatives, but any requests to the same host MUST wait between requests according to the procedure defined in Section 2.7, "Retry Backoff Procedure".
o 如果在请求URL中尝试打开与主机的TCP连接失败，UA可以尝试请求相同配置服务的任何备选URL，而无需在备选URL之间等待，但根据第2.7节“重试退避过程”中定义的过程，对同一主机的任何请求必须在请求之间等待。
o If the TCP connection succeeds but the TLS handshake fails, including failure of the UA to validate the certificate provided by the Configuration Service host (if the UA is capable of validation), the UA MUST remove the failed URL from the list of alternative URLs for this Configuration Service Domain.
o 如果TCP连接成功，但TLS握手失败，包括UA未能验证配置服务主机提供的证书（如果UA能够验证），UA必须从该配置服务域的备选URL列表中删除失败的URL。
o If the request returns a permanent HTTP failure response (response code >= 400, and does not contain a Retry-After header field), the UA MUST remove the failed URL from the list of alternatives for this Configuration Service Domain.
o 如果请求返回永久HTTP失败响应（响应代码>=400，并且不包含重试后标头字段），UA必须从此配置服务域的备选方案列表中删除失败的URL。
o If the list of alternatives for this Configuration Service Domain becomes empty, the UA MUST attempt to obtain another Configuration Service Domain name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain".
o 如果此配置服务域的备选方案列表变为空，UA必须尝试使用第2.2节“获取配置服务域”中的程序获取另一个配置服务域名。
o If the UA has reached its chosen maximum number of retries (this specification does not specify a maximum number of retries, but any retries to the same host MUST follow the procedure defined in Section 2.7, "Retry Backoff Procedure"), the UA MAY attempt to obtain another Configuration Domain name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain".
o 如果UA已达到其选择的最大重试次数（本规范未规定最大重试次数，但对同一主机的任何重试必须遵循第2.7节“重试退避程序”中定义的程序），UA可尝试使用第2.2节中的程序获取另一个配置域名，“获取配置服务域”。
The configuration data provided by the CS is subject to change. This specification provides for two mechanisms by which the UA discovers that a configuration change is available:
CS提供的配置数据可能会发生变化。本规范提供了两种机制，UA通过这两种机制发现配置更改可用：
o SIP subscription by the UA to the CS for notification of changes to the configuration data.
o UA向CS订阅SIP，以通知配置数据的更改。
o HTTP polling by the UA of the configuration data URL at the CS.
o UA在CS上对配置数据URL进行HTTP轮询。
The choice of mechanism is made by the Configuration Service and signaled to the UA in each HTTP response that provides configuration data. In such a response, the CS MUST either:
机制的选择由配置服务进行，并在提供配置数据的每个HTTP响应中通知UA。在此类响应中，CS必须：
o Indicate that the UA is to subscribe for change notifications by including a Link header in the response with the link relation 'monitor' and SIP URI. This choice is specified in Section 2.5.1, "Configuration Change Subscriptions".
o 指示UA将通过在带有链接关系“monitor”和SIP URI的响应中包含链接头来订阅更改通知。第2.5.1节“配置更改订阅”中规定了此选项。
o Indicate that the UA is to poll for updates using HTTP by not including a Link header with the link relation 'monitor'. This choice is specified in Section 2.5.2, "Configuration Change Polling".
o 通过不包括链接关系为“monitor”的链接头，指示UA将使用HTTP轮询更新。第2.5.2节“配置更改轮询”中规定了此选项。
A User Agent MUST support both mechanisms, and use the mechanism indicated by the Configuration Service.
用户代理必须支持这两种机制，并使用配置服务指示的机制。
If the CS chooses to use the SIP subscription mechanism, it MUST include a Link header in the HTTP configuration data response as specified by [RFC5989]; the URI value in the Link header MUST be a SIP URI, and the link relation ('rel' attribute) value MUST be 'monitor'. The 'monitor-group' relation MUST NOT be used -- see below for rules regarding monitoring of multiple configuration data resources. The SIP URI returned in the Link header is the 'configuration change subscription URI'.
如果CS选择使用SIP订阅机制，则它必须按照[RFC5989]的规定在HTTP配置数据响应中包含链接头；链接头中的URI值必须是SIP URI，链接关系（“rel”属性）值必须是“monitor”。不得使用“监控组”关系——有关监控多个配置数据资源的规则，请参阅下文。链接头中返回的SIP URI是“配置更改订阅URI”。
A UA that receives a successful configuration data response with a Link header that specifies a 'monitor' relation MUST attempt to maintain a subscription to the SIP URI from the Link header in that response for the http-monitor event package. This subscription is referred to herein as a "configuration change subscription".
接收到带有指定“监视器”关系的链接头的成功配置数据响应的UA必须尝试从http监视器事件包的该响应中的链接头维护对SIP URI的订阅。此订阅在本文中称为“配置更改订阅”。
The CS MUST accept properly authenticated SUBSCRIBE requests from the UA for the http-monitor event package at the URI it provided in the Link header of a configuration data response. Authentication of the SUBSCRIBE request uses any standard SIP authentication mechanism with credentials supplied to the UA in the configuration data.
CS必须在配置数据响应的链接头中提供的URI处接受来自UA的http monitor事件包的经过正确身份验证的订阅请求。订阅请求的认证使用任何标准SIP认证机制，并在配置数据中向UA提供凭据。
Configuration data MAY include references in the form of additional URLs at the CS that the UA MUST use to obtain additional data. Any response to requests for these additional URLs that provide configuration data MUST provide cache control data and a configuration change subscription URI. The CS MAY return a unique configuration change subscription URI for each configuration data request, or MAY return the same SIP URI for different requests, so long as a change to the configuration data returned in any of these request results in notification on all subscriptions to the associated subscription URI.
配置数据可以包括以附加URL的形式在CS处的引用，UA必须使用这些URL来获取附加数据。对这些提供配置数据的附加URL请求的任何响应都必须提供缓存控制数据和配置更改订阅URI。CS可以为每个配置数据请求返回唯一的配置更改订阅URI，或者可以为不同的请求返回相同的SIP URI，只要对这些请求中任何一个中返回的配置数据的更改导致对关联订阅URI的所有订阅的通知。
If the CS returns a unique configuration change subscription URI in the Link header of different configuration data requests:
如果CS在不同配置数据请求的链接头中返回唯一的配置更改订阅URI：
o The UA MUST maintain multiple subscriptions; one to each URI associated with configuration data the UA is using.
o UA必须维护多个订阅；与UA正在使用的配置数据关联的每个URI一对一。
If the CS returns the same configuration change subscription URI in the Link header of different configuration data requests:
如果CS在不同配置数据请求的链接头中返回相同的配置更改订阅URI：
o The UA is not required to create multiple subscriptions to the same URI.
o UA不需要创建对同一URI的多个订阅。
o The UA MUST associate the URI with each of the configuration data requests for which it was returned, and any NOTIFY or other change in the status of that subscription affects the validity of all of the associated configuration data.
o UA必须将URI与返回的每个配置数据请求相关联，该订阅状态的任何通知或其他更改都会影响所有关联配置数据的有效性。
o The CS MUST send a NOTIFY message on the configuration change subscription when there is a change to any of the different configuration data resources for which the subscription URI was returned.
o 当返回订阅URI的任何不同配置数据资源发生更改时，CS必须在配置更改订阅上发送通知消息。
If a configuration change SUBSCRIBE request (either the initial request or any attempt to refresh the subscription) is permanently rejected by the Configuration Service (the CS returns a failure response that is not an authentication challenge or redirection and does not specify a Retry-After header), the UA MUST consider the associated configuration data to be not valid and attempt to revalidate it as specified in Section 2.6.1, "Re-Validating Configuration Data". Since the CS is not allowed to reject a properly authenticated request, this indicates a problem either with the configuration data or the CS.
如果配置更改订阅请求（初始请求或刷新订阅的任何尝试）被配置服务永久拒绝（CS返回一个失败响应，该响应不是身份验证质询或重定向，并且没有指定头后重试），UA必须考虑关联的配置数据无效，并尝试在第2.6节“重新验证配置数据”中指定的重新验证它。由于不允许CS拒绝经过正确身份验证的请求，这表明配置数据或CS存在问题。
If a configuration change SUBSCRIBE request (either the initial request or any attempt to refresh the subscription) fails other than by being permanently rejected, the UA MUST consider the associated configuration data to be of unknown validity, and MUST retry the SUBSCRIBE request as specified in Section 2.7, "Retry Backoff Procedure"; the maximum time between retries MUST NOT be more than 30 minutes, and the retries MUST continue as long as the configuration is used. The UA MAY at any time return to any earlier step in the process of obtaining configuration data.
如果配置更改订阅请求（初始请求或刷新订阅的任何尝试）失败，而不是被永久拒绝，则UA必须考虑关联的配置数据是未知的有效性，并且必须重试订阅请求，如第2.7节中所述的“重试退避过程”；重试之间的最长时间不得超过30分钟，并且只要使用配置，重试就必须继续。UA可随时返回到获取配置数据过程中的任何较早步骤。
If the CS explicitly terminates the configuration change (http-monitor) subscription by sending a NOTIFY message with a Subscription-State header value of 'terminated', the UA MUST consider the configuration data to be of unknown validity. If the rules for interpreting and acting on the 'reason' code parameter as specified in Section 3.2.4 of [RFC3265] allow, the UA MUST attempt to re-establish the subscription. If those rules do not allow the UA to re-subscribe, then the UA MUST consider the data to be not valid and attempt to revalidate it as specified in Section 2.6.1, "Re-Validating Configuration Data". The UA MAY at any time return to any earlier step in the process of obtaining configuration data.
如果CS通过发送具有终止状态的订阅状态报头值的通知消息来明确地终止配置更改（HTTP监视器）订阅，则UA必须考虑配置数据的未知有效性。如果[RFC3265]第3.2.4节规定的解释和处理“原因”代码参数的规则允许，UA必须尝试重新建立订阅。如果这些规则不允许UA重新订阅，那么UA必须考虑数据无效，并尝试重新验证它，如第2.6节中的“重新验证配置数据”所指定的。UA可随时返回到获取配置数据过程中的任何较早步骤。
To inform the UA of a configuration data change, the CS MUST send a NOTIFY message to the UA in the configuration change subscription established by the UA as detailed in Section 2.5.1, "Configuration Change Subscriptions".
要将配置数据更改通知UA，CS必须在UA建立的配置更改订阅中向UA发送通知消息，详见第2.5.1节“配置更改订阅”。
The CS MUST NOT send unsolicited (out-of-dialog) NOTIFY messages.
CS不得发送未经请求的（对话框外）通知消息。
As specified in [RFC5989], the body of a NOTIFY message in the http-monitor event package is the HTTP headers that would have been returned in response to an HTTP HEAD request (a HEAD request returns the headers that would have been returned for a GET request to the same URI, but with no body).
如[RFC5989]中所述，http监视器事件包中的NOTIFY消息体是响应http HEAD请求而返回的http头（HEAD请求将GET请求返回的头返回到相同的URI，但没有正文）。
When a NOTIFY message is received by the UA in the configuration change subscription, the UA MUST compare the cache control data it retained when the configuration data was received with the HTTP header values in the NOTIFY message body. If any of the cache control data in the HTTP header values differs from those in the original configuration data response, the UA MUST consider the stored configuration data to be no longer valid. As soon as reasonably possible after the UA discovers that configuration data is no longer valid, the UA MUST attempt a GET request to the HTTPS configuration request URL which provided the configuration data to obtain the changed configuration data.
当UA在配置更改订阅中收到通知消息时，UA必须将收到配置数据时保留的缓存控制数据与通知消息正文中的HTTP头值进行比较。如果HTTP报头值中的任何高速缓存控制数据与原始配置数据响应中的缓存数据不同，则UA必须考虑所存储的配置数据不再有效。UA发现配置数据不再有效后，必须尽快尝试向提供配置数据的HTTPS配置请求URL发出GET请求，以获取更改的配置数据。
If this HTTPS request to the URL that previously provided the configuration data fails, the UA MUST attempt to obtain a new URL as specified in Section 2.3, "Constructing the Configuration Request URL".
如果对先前提供配置数据的URL的HTTPS请求失败，UA必须按照第2.3节“构造配置请求URL”的规定尝试获取新URL。
If the CS chooses to use the HTTP polling mechanism, it MUST NOT include a Link header with the relation 'monitor' in the HTTP configuration data response, and MUST include a Cache-Control header that specifies the max-age directive. The max-age cache control directive in HTTP specifies the maximum number of seconds for which the returned data may be cached; this specification defines this time as being the maximum time the configuration data is considered valid.
如果CS选择使用HTTP轮询机制，则它不得在HTTP配置数据响应中包含具有关系“monitor”的链接标头，并且必须包含指定max age指令的缓存控制标头。HTTP中的max age cache control指令指定可缓存返回数据的最大秒数；本规范将此时间定义为配置数据被视为有效的最长时间。
A short time before the validity time has passed, the UA SHOULD poll to revalidate the configuration data as described in Section 2.6.1, "Re-Validating Configuration Data".
在有效期结束前的短时间内，UA应轮询以重新验证第2.6.1节“重新验证配置数据”中所述的配置数据。
Configuration data stored by a UA is considered valid:
UA存储的配置数据被视为有效：
o If the CS chose to use the subscription mechanism to deliver change notices, and the UA has a subscription to the CS as described in Section 2.5.1, "Configuration Change Subscriptions" on which no NOTIFY message from the CS indicating that the configuration data has changed has been received.
o 如果CS选择使用订阅机制发送更改通知，且UA拥有第2.5.1节“配置更改订阅”中所述的CS订阅，且没有收到来自CS的通知消息，表明配置数据已更改。
o If the CS chose to use the HTTP polling method, and the number of seconds since the configuration data response was received is less than the time specified by the Cache-Control max-age directive in that response.
o 如果CS选择使用HTTP轮询方法，并且自收到配置数据响应后的秒数小于该响应中的Cache Control max age指令指定的时间。
When a UA initializes itself at any time other than immediately after receiving new configuration data, it MUST consider any stored configuration data to be of unknown validity.
当UA在接收新的配置数据之后立即在任何时间初始化自身时，它必须考虑任何存储的配置数据是未知的有效性。
The UA MAY use configuration data that is of unknown validity, or configuration data that is known to be no longer valid, while attempting to revalidate that data or obtain new data. There is no assurance that such configuration data is still useful, but the UA MAY choose to retain the data and to continue to use it.
UA可使用有效性未知的配置数据，或已知不再有效的配置数据，同时尝试重新验证该数据或获取新数据。无法保证此类配置数据仍然有用，但UA可以选择保留数据并继续使用。
To revalidate stored configuration data of unknown validity, the UA MUST repeat the HTTPS GET request it used to obtain the stored configuration data, with the appropriate HTTP headers to make the request a conditional request using the cache control data returned in the response that provided the configuration data. This allows the CS to respond either with a new configuration data response or a 304 (Not Modified) response to indicate that the configuration data has not changed.
要重新验证未知有效性的存储配置数据，UA必须使用适当的HTTP头重复用于获取存储配置数据的HTTPS GET请求，以使用提供配置数据的响应中返回的缓存控制数据使请求成为条件请求。这允许CS响应新的配置数据响应或304（未修改）响应，以指示配置数据未更改。
If the CS responds with a 304 response, and the original response included a Link header with the 'monitor' relation, the SIP UA MUST assume that the value of that Link header is also still correct (in effect, the HTTP cache control values and the subscription URL are a part of the configuration data), and so the UA MUST attempt to create and maintain a subscription to that URL as when the configuration data was first obtained (Section 2.5.1, "Configuration Change Subscriptions").
如果CS以304响应响应，并且原始响应包括具有“监视器”关系的链路头，则SIP UA必须假定该链路头的值仍然正确（实际上，HTTP缓存控制值和订阅URL是配置数据的一部分），因此UA必须尝试创建和维护对该URL的订阅，就像首次获得配置数据时一样（第2.5.1节，“配置更改订阅”）。
If the CS chooses to use the HTTP polling method, then any 304 response MUST include a Cache-Control header containing a max-age directive, and the UA MUST use this new value as the maximum validity time for the associated configuration data.
如果CS选择使用HTTP轮询方法，则任何304响应必须包括包含max age指令的缓存控制头，UA必须使用此新值作为相关配置数据的最大有效时间。
If the HTTP request to revalidate the configuration fails, the UA MUST follow the procedures defined for a failure of the initial HTTP configuration data request as specified in Section 2.4.2, "Configuration Data Request Failure".
如果重新验证配置的HTTP请求失败，UA必须按照第2.4.2节“配置数据请求失败”中为初始HTTP配置数据请求失败定义的程序进行操作。
In case of certain possible failures as described above, the appropriate response is to retry the failed operation. In all of these retry cases, the following rules apply:
如果出现上述某些可能的故障，相应的响应是重试失败的操作。在所有这些重试情况下，以下规则适用：
o The UA SHOULD retry at least 5 times before abandoning the failed step (except as allowed for in specific error handling rules above).
o UA应在放弃失败步骤之前重试至少5次（上述特定错误处理规则中允许的情况除外）。
o Following the first instance of a given failure, the UA MUST select an initial backoff timer value randomly between 2 and 8, inclusive, and wait this number of seconds before retrying the failed request.
o 在给定故障的第一个实例之后，UA必须随机选择一个初始退避计时器值，该值介于2和8之间（包括2和8），并等待该秒数，然后重试失败的请求。
o Following any subsequent instance of a given failure, the UA MUST increase the backoff timer value by 2 raised to the power of the number of preceding failures (2^N where N is the number of previous failures), and wait this increased number of seconds or the maximum interval specified by specific error handling procedures, whichever is less, before retrying the failed request.
o 在给定故障的任何后续实例之后，UA必须将退避计时器值增加2，并将其提高到先前故障数的幂次方（2^N，其中N为先前故障数），然后等待增加的秒数或特定错误处理程序指定的最大间隔，以较小者为准，在重试失败的请求之前。
For example, after an initial failure, the UA randomly chooses an initial backoff timer value of 4 seconds, followed by retries at the following times: 6 seconds (4 + 2^1), 10 seconds (6 + 2^2), 18 seconds (10 + 2^3), 34 seconds (18 + 2^4), and 66 seconds (34 + 2^5).
例如，在初始故障后，UA随机选择4秒的初始退避计时器值，然后在以下时间重试：6秒（4+2^1）、10秒（6+2^2）、18秒（10+2^3）、34秒（18+2^4）和66秒（34+2^5）。
This document does not specify the form or content of configuration data. As such, the contents of this section are non-normative.
本文档未指定配置数据的形式或内容。因此，本节的内容是非规范性的。
The configuration data for a SIP UA should, at minimum, include items with the following semantics.
SIP UA的配置数据至少应包括具有以下语义的项。
The Address-of-Record (AOR) is a SIP or SIPS URI that identifies the user of the device as specified in [RFC3261].
记录地址（AOR）是标识设备用户的SIP或SIPS URI，如[RFC3261]所述。
The realm is used to populate the realm parameter in the SIP Proxy-Authorization header as specified in [RFC3261] when the UA receives an authentication challenge.
当UA收到认证质询时，领域用于填充[RFC3261]中指定的SIP代理授权标头中的领域参数。
The username is used to populate the username parameter in the SIP Proxy-Authorization header as specified in [RFC3261] when the UA receives an authentication challenge.
当UA收到认证质询时，用户名用于填充[RFC3261]中指定的SIP代理授权标头中的用户名参数。
The digest is a string containing the digest of the username, realm, and password as specified in [RFC2617] and is used to generate a response to an authentication challenge as specified in [RFC3261].
摘要是一个字符串，包含[RFC2617]中指定的用户名、域和密码摘要，用于生成对[RFC3261]中指定的身份验证质询的响应。
The OutboundProxy if defined contains the default outbound proxy through which SIP requests, not explicitly routed, are routed as specified in [RFC3261].
OutboundProxy（如果已定义）包含默认出站代理，未显式路由的SIP请求通过该出站代理进行路由，如[RFC3261]中所述。
The earlier sections of this document define methods by which the UA can be automatically provisioned. Some User Agents allow certain user specific settings (e.g., Contact Directory, specialized ring-tones, etc.) to be set by a user, and possibly stored locally in the User Agent. Since it may be necessary to later re-assign a UA, designers of configuration data formats may want to provide for explicit controls for any such locally configured settings, including the ability to explicitly delete them to return the UA to a completely unconfigured state.
本文档前面的章节定义了可以自动配置UA的方法。一些用户代理允许用户设置特定于用户的设置（例如，联系人目录、专用铃声等），并且可能存储在用户代理的本地中。由于以后可能需要重新分配UA，配置数据格式的设计者可能希望为任何此类本地配置的设置提供显式控制，包括显式删除这些设置以将UA返回到完全未配置状态的能力。
This specification defines DHCP option code 141, the "SIP UA Configuration Service Domains" for inclusion in the IANA registry "BOOTP Vendor Extensions and DHCP Options" defined by [RFC2939].
本规范定义了DHCP选项代码141，即[RFC2939]定义的IANA注册表“BOOTP供应商扩展和DHCP选项”中包含的“SIP UA配置服务域”。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 141 | Len | Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 141 | Len | Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram, Searchstring is a string specifying the searchlist. If the length of the searchlist exceeds the maximum permissible within a single option (255 octets), then multiple options MAY be used, as described in [RFC3396] "Encoding Long DHCP Options in the Dynamic Host Configuration Protocol (DHCPv4)".
在上图中，Searchstring是一个指定searchlist的字符串。如果搜索列表的长度超过单个选项（255个八位字节）内允许的最大值，则可以使用多个选项，如[RFC3396]“动态主机配置协议（DHCPv4）中的编码长DHCP选项”中所述。
To enable the searchlist to be encoded compactly, searchstrings in the searchlist MUST be concatenated and encoded using the technique described in Section 4.1.4 of [RFC1035], "Domain Names - Implementation and Specification". In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name. Despite its complexity, this technique is valuable since the space available for encoding DHCP options is limited, and it is likely that a domain searchstring will contain repeated instances of the same domain name. Thus, the DNS name compression is both useful and likely to be effective.
为了使搜索列表能够紧凑地编码，必须使用[RFC1035]“域名-实现和规范”第4.1.4节中描述的技术连接和编码搜索列表中的搜索字符串。在该方案中，整个域名或域名末尾的标签列表被替换为指向先前出现的相同名称的指针。尽管它很复杂，但这种技术很有价值，因为可用于编码DHCP选项的空间有限，而且域搜索字符串很可能包含相同域名的重复实例。因此，DNS名称压缩既有用又可能有效。
For use in this specification, the pointer refers to the offset within the data portion of the DHCP option (not including the preceding DHCP option code byte or DHCP option length byte).
在本规范中使用时，指针指DHCP选项数据部分内的偏移量（不包括前面的DHCP选项代码字节或DHCP选项长度字节）。
If multiple SIP UA Configuration Service Domains options are present, then the data portions of all the SIP UA Configuration Service Domains options are concatenated together as specified in RFC 3396, and the pointer indicates an offset within the complete aggregate block of data.
如果存在多个SIP UA配置服务域选项，则按照RFC 3396中的规定将所有SIP UA配置服务域选项的数据部分连接在一起，并且指针指示完整聚合数据块内的偏移量。
For examples of encoding this option, see Section 3 of [RFC3397], "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", which uses the same encoding for option 119.
有关编码此选项的示例，请参阅[RFC3397]“动态主机配置协议（DHCP）域搜索选项”的第3节，该节使用与选项119相同的编码。
This specification defines DHCPv6 option code 58, OPTION_SIP_UA_CS_LIST, for inclusion in the IANA registry "Dynamic Host Configuration Protocol for IPv6 (DHCPv6), DHCP Option Codes" defined by RFC 3315.
本规范定义了DHCPv6选项代码58，选项SIP\U UA\U CS\U列表，以包含在由RFC 3315定义的IANA注册表“IPv6动态主机配置协议（DHCPv6），DHCP选项代码”中。
The format of the SIP User Agent Configuration Service Domains option is:
SIP用户代理配置服务域选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIP_UA_CS_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIP_UA_CS_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIP_UA_CS_LIST (58)
选项代码选项SIP\U UA\U CS\U列表（58）
option-len Length of the 'searchlist' field in octets
选项len“searchlist”字段的长度（以八位字节为单位）
searchlist The specification of the list of domain names in the SIP User Agent Configuration Service Domains
searchlist指定SIP用户代理配置服务域中的域名列表
The list of domain names in the 'searchlist' MUST be encoded as specified in Section 8, "Representation and Use of Domain Names" of RFC 3315.
“搜索列表”中的域名列表必须按照RFC 3315第8节“域名的表示和使用”的规定进行编码。
This document registers the following U-NAPTR application service tag in the registry defined by [RFC3958], "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)":
本文档在[RFC3958]“使用SRV RRs和动态委派发现服务（DDDS）”定义的注册表中注册以下U-NAPTR应用程序服务标签：
+-------------------------+----------+
| Application Service Tag | SFUA.CFG |
+-------------------------+----------+
+-------------------------+----------+
| Application Service Tag | SFUA.CFG |
+-------------------------+----------+
This tag is used to obtain the base URL of the Configuration Service from the DNS name of a SIP domain as specified in Section 2.3.1, "Obtaining a Configuration Service Base URL".
此标记用于从第2.3.1节“获取配置服务基本URL”中指定的SIP域的DNS名称获取配置服务的基本URL。
IANA has established a registry for "SIP Forum User Agent Configuration Parameters". This registry records the HTTPS request parameters for the initial configuration data request sent by a User Agent to a Configuration Service as described in Section 2.3.2, "Adding Configuration Request Parameters".
IANA已经为“SIP论坛用户代理配置参数”建立了一个注册表。此注册表记录用户代理向配置服务发送的初始配置数据请求的HTTPS请求参数，如第2.3.2节“添加配置请求参数”所述。
Each entry in the registry must include the Parameter Name and a Description that specifies the value syntax and usage of the parameter:
注册表中的每个条目必须包括参数名称和说明，说明参数的值语法和用法：
Parameter Name The name of the parameter, which MUST match the ABNF production for 'token' from [RFC3261].
参数名称参数的名称，必须与[RFC3261]中“令牌”的ABNF产品相匹配。
Value Syntax The syntax of the value, if any (a parameter may just be a name with no associated value).
值语法值的语法，如果有的话（参数可能只是一个没有关联值的名称）。
Usage The purpose served by the parameter, including any default method the UA should use to construct it if applicable.
用法参数所服务的目的，包括UA应使用的任何默认方法（如适用）。
The initial values for the registry are the parameters described in Section 2.3.2.1, "Configuration Request Parameters". The policy for future additions to this registry depends on the parameter name value:
注册表的初始值为第2.3.2.1节“配置请求参数”中描述的参数。将来添加到此注册表的策略取决于参数名称值：
If the name of the parameter begins with the characters 'sfua-' in any case, then the policy for addition to this registry is "RFC Required" as described by [RFC5226].
如果参数名称在任何情况下都以字符“sfua-”开头，则添加到此注册表的策略为[RFC5226]所述的“需要RFC”。
Any other parameter entry may be added to this registry using a "First Come First Served" policy as described by [RFC5226].
可使用[RFC5226]所述的“先到先得”策略将任何其他参数项添加到此注册表。
Initial discovery of the Configuration Service Domain name relies on a number of operations that are normally unsecured: a DHCP response could be provided by an attacker to replace the values of any of the IP Network Parameters (Section 2.1.2, "Network Layer Provisioning") including the Local Network Domain which is the default choice for the Configuration Service Domain name. Confirmation by the human user of the Configuration Service Domain name, especially when it differs from a previously used value, could be used to mitigate this (perhaps unintentional) potential reconfiguration. Note that previously loaded configuration MAY constrain which parts of the discovery and location procedures are used: for example, the Configuration Service Domain name might be fixed so that it cannot be modified by discovery.
配置服务域名的初始发现依赖于许多通常不安全的操作：攻击者可以提供DHCP响应来替换任何IP网络参数的值（第2.1.2节，“网络层配置”）包括本地网络域，这是配置服务域名的默认选择。人类用户对配置服务域名的确认，特别是当它与以前使用的值不同时，可用于减轻这种（可能是无意的）潜在重新配置。请注意，以前加载的配置可能会限制使用查找和定位过程的哪些部分：例如，配置服务域名可能是固定的，因此无法通过查找进行修改。
The connection to the Configuration Service is made over TLS. As the TLS server, the CS always provides a server certificate during the TLS handshake; if possible, the UA should validate that certificate and confirm that it contains as a subject the Configuration Service Domain name or at least the host name from the Configuration Service Base URL (see [RFC2818]). While it may not be possible to have the
到配置服务的连接是通过TLS建立的。作为TLS服务器，CS在TLS握手过程中始终提供服务器证书；如果可能，UA应验证该证书，并确认其包含配置服务域名或至少包含配置服务基本URL中的主机名（请参见[RFC2818]）。虽然可能不可能有
information needed to perform a full validation of the CS server certificate prior to the first configuration (for example, the UA may not have a current CA certificate for the CA that signs the CS server certificate), implementors are advised to provide that information in configuration data so that it can be used for subsequent reconfigurations; this narrows the window of vulnerability to the first configuration attempt.
在第一次配置之前执行CS服务器证书完全验证所需的信息（例如，UA可能没有签署CS服务器证书的CA的当前CA证书），建议实施者在配置数据中提供该信息，以便用于后续的重新配置；这将缩小首次配置尝试的漏洞窗口。
To secure initial configuration attempts, the CS can deny requests from unknown devices and/or could implement other measures such as restricting the time window during which it will accept an initial configuration request from a given device. A more secure approach would be to provide the user with a password, perhaps a one-time password valid only for the initial access. In high security environments, the Configuration Service could require that the User Agent provide a client certificate for authentication in the TLS connection for configuration data requests. This would necessitate some prior manual configuration of the User Agent, and possibly the Configuration Service, and that configuration should also include sufficient information for the UA to fully validate the CS certificate.
为了确保初始配置尝试的安全，CS可以拒绝来自未知设备的请求和/或可以实施其他措施，例如限制其将接受来自给定设备的初始配置请求的时间窗口。更安全的方法是向用户提供一个密码，可能是一个仅对初始访问有效的一次性密码。在高安全性环境中，配置服务可能要求用户代理在TLS连接中为配置数据请求的身份验证提供客户端证书。这将需要事先对用户代理和可能的配置服务进行一些手动配置，并且该配置还应包括足够的信息，以便UA完全验证CS证书。
The values of some or all of the request parameters sent by the UA on the initial request for configuration data (see Section 2.3.2, "Adding Configuration Request Parameters") may be sensitive information. Since the configuration data request is made over a TLS connection, the confidentiality of that information is protected on the network. Configuration Service implementations should take all necessary measures to ensure that the request parameter data is appropriately protected within the CS itself.
UA在初始配置数据请求中发送的部分或全部请求参数的值（见第2.3.2节“添加配置请求参数”）可能是敏感信息。由于配置数据请求是通过TLS连接发出的，因此该信息的机密性在网络上受到保护。配置服务实现应该采取所有必要的措施，以确保请求参数数据在CS本身中得到适当的保护。
The Configuration Change Request Subscription (Section 2.5.1, "Configuration Change Subscriptions") is established only after the configuration data has been loaded by the User Agent, so all security mechanisms available in SIP (including request digest authentication and the use of TLS) can be configured and required by either the CS or the UA. Note that a configuration change notice does not actually provide any new configuration data, nor can it change where the UA sends a request for the new configuration data. This means that an attacker cannot reconfigure a UA by subverting only the change notice subscription; the most the attacker can do is trigger checks for new data. In order to actually modify the configuration data itself, the attacker must subvert the CS or the steps leading to the CS discovery (subject to the checks described above).
配置更改请求订阅（第2.5.1节，“配置更改订阅”）仅在用户代理加载配置数据后建立，因此，可以配置SIP中可用的所有安全机制（包括请求摘要身份验证和TLS的使用），并且CS或UA都需要这些机制。请注意，配置更改通知实际上并不提供任何新的配置数据，也不能更改UA发送新配置数据请求的位置。这意味着攻击者无法通过仅破坏更改通知订阅来重新配置UA；攻击者最多只能触发新数据的检查。为了实际修改配置数据本身，攻击者必须破坏CS或导致CS发现的步骤（根据上述检查）。
Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, SIP
TLS的实现通常支持传输层安全协议的多个版本以及较旧的安全套接字层（SSL）协议。由于已知的安全漏洞，SIP
UAs, SIP Service Provider, and the Configuration Service Host MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details.
UAs、SIP服务提供商和配置服务主机不得请求、提供或使用SSL 2.0。有关更多详细信息，请参见[RFC5246]的附录E.2。
Contributing Members of the SIP Forum User Agent Configuration Working Group:
SIP论坛用户代理配置工作组的贡献成员：
Francois Audet, Nortel Networks, Inc.
Francois Audet，北电网络公司。
Eric Burger, SIP Forum
埃里克·伯格，SIP论坛
Sumanth Channabasappa, Cable Television Laboratories, Inc. (CableLabs)
Sumanth Channabasapa，有线电视实验室有限公司（CableLabs）
Martin Dolly, AT&T Labs
马丁·多利，美国电话电报公司实验室
John Elwell, Siemens Enterprise Communications
John Elwell，西门子企业通信公司
Marek Dutkiewicz, Polycom, Inc.
Marek Dutkiewicz，Polycom公司。
Andy Hutton, Siemens Enterprise Communications
Andy Hutton，西门子企业通信公司
Lincoln Lavoie, University of New Hampshire
Lincoln Lavoie，新罕布什尔大学
Scott Lawrence, Avaya, Inc.
斯科特·劳伦斯，阿瓦亚公司。
Paul Mossman, Avaya, Inc.
保罗·莫斯曼，阿瓦亚公司。
Michael Procter, VoIP.co.uk
Michael Procter，VoIP.co.uk
Marc Robins, SIP Forum
马克·罗宾斯，SIP论坛
Henning Schulzrinne, Columbia University
Henning Schulzrinne，哥伦比亚大学
Rifaat Shekh-Yusef, Avaya, Inc.
Rifaat Shekh Yusef，Avaya公司。
Robert Sparks, Tekelec
罗伯特·斯帕克斯，泰克莱克
Simo Veikkolainen, Nokia
诺基亚Simo Veikkolainen
The Editor would like to also acknowledge valuable contributions by Leslie Daigle and Margaret Wasserman.
编辑还要感谢Leslie Daigle和Margaret Wasserman的宝贵贡献。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC2939]Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319]Schulzrinne，H.和B.Volz，“会话启动协议（SIP）服务器的动态主机配置协议（DHCPv6）选项”，RFC 3319，2003年7月。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396]Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397]Aboba，B.和S.Cheshire，“动态主机配置协议（DHCP）域搜索选项”，RFC 3397，2002年11月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[RFC4848]Daigle，L.，“使用URI和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 48482007年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes to an HTTP Resource", October 2010.
[RFC5989]Roach，A.，“用于订阅HTTP资源更改的SIP事件包”，2010年10月。
[ANSI.TIA-1057-2006] American National Standards Institute, "Telecommunications IP Telephony Infrastructure Link Layer Discovery Protocol for Media Endpoint Devices", April 1993.
[ANSI.TIA-1057-2006]美国国家标准协会，“媒体终端设备的电信IP电话基础设施链路层发现协议”，1993年4月。
Authors' Addresses
作者地址
Scott Lawrence (editor) Linden Research, Inc.
斯科特·劳伦斯（编辑）林登研究公司。
EMail: scott-ietf@skrb.org
EMail: scott-ietf@skrb.org
John Elwell Siemens Enterprise Communications
西门子企业通信公司
Phone: +44 1908 817801
EMail: john.elwell@siemens-enterprise.com
Phone: +44 1908 817801
EMail: john.elwell@siemens-enterprise.com