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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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項「構成データの項目は、」UAは、すべての種類によって必要とされる可能性が高いデータ項目の最小セットを示唆しているが。
The following terms are used in this document:
次の用語はこの文書で使用されています。
User Agent, UA
ユーザーエージェント、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
ソフトユーザーエージェント、ソフト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
コンフィギュレーションサービス、CS
The source of Configuration for User Agents.
ユーザーエージェントの設定のソース。
Configuration Service Domain
Configuration Serviceのドメイン
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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.
次のようにホストされているIP電話サービスを利用するための新しいUAを設定すると、一般的に進行します：顧客はサービスに1つ以上の新しいユーザーを追加するには、そのサービスプロバイダへの要求を行います。顧客はサービスプロバイダが有用と考えるが、追加の情報が顧客から要求されないものを情報に応じて、このような好ましいユーザ名、エンドポイントの種類や特定の機能のための任意の要求などの詳細を供給することができます。
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）（ユーザー「ジョン・スミス」を追加します）でユーザーIDをプロビジョニングし、ユーザーに電話番号を割り当てることによって開始されます。その数は、特定の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を接続しています。単にネットワークに接続PBXからコンフィギュレーションをロードし、UAは正常に動作して - 接続され、パワーアップするとき、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.
前記デバイスは、セキュリティカードまたはドングルの形でセキュリティ情報を提供するために、ユーザの設備を有していてもよいです。
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.
リンクレイヤパラメータの自動プロビジョニングのために、メディアエンドポイント発見（[ANSI.TIA-1057から2006]を参照してくださいLLDP-MED） - UAは、リンク層検出プロトコルを使用しようとすべきです。
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は、おそらくサービスの完全な喪失をもたらし、サービスの品質を低下させる、または間違った仮想LAN（VLAN）上にある、間違ったレイヤ2優先順位を持つになることがあります。
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.
ユーザーエージェントは、動的ホスト構成プロトコル（DHCP）[RFC2131]が定義されているネットワーク技術上のIPバージョン4を使用している場合は、O、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 (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.
ユーザーエージェントは、動的ホスト構成プロトコルバージョン6（DHCPv6の）[RFC3315]が定義されているネットワーク技術上のIPバージョン6を使用している場合は、O、UAは、IPネットワークパラメータを決定するために、任意の標準のIPv6メカニズムを使用することができるが、要求しなければなりません。 DHCPv6オプション58（4.2節を参照）、21 [RFC3319]。 DHCPv6サービスは、オプション58の値を提供する場合、これらのドメイン名は、（「コンフィギュレーションサービスドメインの取得」、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: o Section 2.3.1, "Obtaining a Configuration Service Base URL"
「コンフィギュレーションサービスドメインの取得」、2.2節で得られたコンフィギュレーションサービスドメイン名を使用して、UAは、設定を要求するとのHTTPS URL [RFC2818]を構築しなければなりません。このURLを構築することの2つの部分から構成：O部2.3.1、「Configuration Serviceのベース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が有効なネーミングオーソリティポインタ（U-NAPTR）DDDSアプリケーション「URIを使用したドメインベースのアプリケーションサービスロケーションおよび動的委任ディスカバリサービス（DDDS）」[RFC4848]を使用して、1つまたは複数のURLに解決され。
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」を「U」に設定フラグフィールド、空の置換フィールド、および次の構文の正規表現のフィールド値で設定する必要があります設定サービスドメイン名のNAPTRレコード（すなわち、 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.
複数の設定サーバーは、ユーザーエージェントをプロビジョニングするために、冗長性と追加の容量を提供するために使用することができます。 Configuration Serviceのドメイン名のDNS NAPTR要求が「SFUA.CFG」サービスタグで複数のレコードを返す場合NAPTRレコードに指定され、その後、UAは、優先度と重みのための規則に従って順序付け、代替案として、結果のURLを扱う必要があります。
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は、UAが要求しているものをコンフィギュレーションを指定するためにベースURLに1つ以上のパラメータを追加します。
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.
sfua-id
sfua手
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)".
[RFC5626]のセクション4.1で指定されるように構成されたユーザエージェントを識別するURNは、「セッション開始プロトコル（SIP）のクライアントが開始した接続を管理します」。
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」Contactヘッダーフィールドパラメータを含むコンフィギュレーションを要求するとき、それは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「ユーザー」とは異なる可能性があります：それは、例えば、サービスプロバイダのWebサイトでアカウントのログイン名である可能性があります。このパラメータの構文は、「ユーザーID」[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」であると判断しました。 「example.net」のベースURLを取得するには、UAはのための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" "" _sip._tcp.example.net。 NAPTR 100 50 "秒" "SIP + D2U" "" _sip._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製、 'HypoComm' バージョン2.1であり、00のリンク層のMACアドレスを持っている：11：22：33：55：44。 （読みやすいように改行ライン）これは、設定を要求するためのユーザーIDのいずれかの予備知識を持っていないので、それはそれは持っているん値を使用してクエリパラメータを構築し、これらの要求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ベンダー= examplecorp.com＆sfuaモデル= HypoComm＆sfua-改正= 2.1のhttps：// ？p2.example.net/cfg sfua-ID = URN：UUID：00000000-0000-1000-8000-001122334455＆sfuaベンダー= examplecorp.com＆sfuaモデル= HypoComm＆sfua-改正= 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.
UAが使用できる設定はの一つに応答して返されるまで、ユーザエージェントは、URLのそれぞれにHTTPS GETリクエストを行う必要がある「構成要求URLを構築」、2.3節で指定されるように構築されたURLを使用して設定を要求するにはリクエスト。
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の構成データを含まなければなりません。そのようなリダイレクションとして応答は、構成データを提供するプロセスの一部としてCSによって使用できるように[RFC2616]で指定されるようにHTTPのすべての機能は、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キャッシュ制御メタデータ（任意のCache-Controlヘッダーからの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を特定し、（複数のドメイン名を提供する単一のサーバーを可能にする）希望のIDを含むサーバ証明書を提供することができます。
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の証明書チェーンを接続することができるか、UAのファームウェアが最後に更新されたため、ルートCA証明書の有効期限が切れているので、これに信頼されたルートCA証明書を持っていない可能性があるため、例えば）残念ながら、検証の試みは失敗する可能性があります。 UAは、CSが提供するサーバー証明書を検証することができない場合、UAは、サーバー証明書を格納する必要があり、そのCSホストが将来的に別の証明書を提供する場合、ユーザーに警告します。モデルこの「最初の使用上の信頼は」証明書の検証ほど安全ではありませんが、それは将来的にはのman-in-the-middle（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.
それが1つを持っている場合、UAは、クライアント証明書を提供しなければなりません。 1が提供されている場合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「ユーザ名」パラメータは、設定データ要求パラメータに設けsfuaユーザーの値と同じ値でなければなりません。 [RFC2617]で指定されたUAは、基本認証とダイジェスト認証の両方を実装しなければなりません。
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.
リクエストURLにホスト名を解決するDNS要求が一致する結果が（NXDOMAIN）利用できないことを示す応答を返した場合、O、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".
URLが失敗したリクエスト内のホストへのTCP接続を開こうとすると、O、UAは選択肢の間待つことなく、同じコンフィギュレーション・サービスのための任意の代替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.
構成サービスのホストによって提供される証明書を検証するために、UAの失敗（UAが検証できる場合）を含め、TCP接続は成功しますが、TLSハンドシェイクに失敗した場合は、O、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、および再試行-Afterヘッダーフィールドが含まれていない）場合は、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 MAY 「コンフィギュレーションサービスドメインの取得」、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は、構成変更が可能であることを発見したことにより、2つのメカニズムを提供します。
o SIP subscription by the UA to the CS for notification of changes to the configuration data.
Oコンフィギュレーション・データへの変更の通知のためにCSにUAによってサブスクリプションをSIP。
o HTTP polling by the UA of the configuration data URL at the CS.
CSでの構成データのURLのUAによるO 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はリンク関係「モニター」と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は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」属性）の値が「モニタ」でなければなりませんリンク関係でなければなりません。 「モニター・グループの関係を使用してはいけません - 複数のコンフィギュレーション・データ・リソースの監視に関する規則については、以下を参照してください。 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".
「モニターの関係は、HTTPモニタイベントパッケージのためにその応答にリンクヘッダからSIP URIへのサブスクリプションを維持しようとしなければならない指定リンクヘッダーで成功したコンフィギュレーション・データ応答を受け取るUA。このサブスクリプションは、「構成変更サブスクリプション」と呼びます。
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にHTTPモニタイベントパッケージのためのUAから適切SUBSCRIBE認証要求を受け入れなければなりません。 SUBSCRIBEリクエストの認証は、コンフィギュレーションデータにUAに供給される資格情報を使用して任意の標準的なSIP認証メカニズムを使用します。
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.
コンフィギュレーション・データは、UAは、追加のデータを取得するために使用しなければならないCSでの追加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に1。
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を関連付ける必要があり、そして任意のは、NOTIFYまたはそのサブスクリプションの状態の他の変化は、関連する構成データのすべての妥当性に影響を与えます。
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 CSは、サブスクリプションURIが返されたために別の構成データリソースのいずれかに変更があった場合、設定変更サブスクリプションにNOTIFYメッセージを送らなければなりません。
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.
構成変更が恒久的に設定サービスによって拒否された（最初のリクエストまたはサブスクリプションをリフレッシュする試みのいずれか）SUBSCRIBEリクエストをした場合（CSは認証チャレンジやリダイレクトではなく、再試行-Afterヘッダを指定していない失敗応答を返します。 ）、UAは、「再検証設定データを」関連する構成データが有効でないことを考えると、セクション2.6.1に指定されていることを再確認しようとしなければなりません。 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.
構成変更が（最初の要求またはサブスクリプションをリフレッシュする試みのいずれか）が恒久的に拒否されることによって以外に失敗したSUBSCRIBEリクエストをした場合、UAは、未知の妥当性があると関連する構成データを考慮しなければならない、として指定されたSUBSCRIBEリクエストを再試行しなければなりませんセクション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が明示的に「終了」のサブスクリプションのステートヘッダ値を持つNOTIFYメッセージを送信することにより、設定変更（HTTPモニタ）サブスクリプションを終了した場合、UAは、構成データが未知の妥当性があると考えなければなりません。もし[RFC3265]を許可し、UAは、サブスクリプションを再確立しようとしなければならないのセクション3.2.4で指定されるように解釈すると「理由」コードパラメータに作用するためのルール。これらのルールは、UAが再サブスクライブすることができない場合は、UAは、データが有効でないことと、セクション2.6.1、「再検証設定データ」に指定されていることを再確認しようとして検討する必要があります。コンフィギュレーションデータを取得するプロセスの任意の以前のステップにいつでも復帰時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".
セクション2.5.1、「構成サブスクリプションの変更」で説明するように、構成データの変更のUAに通知するために、CSはUAによって確立された構成変更サブスクリプションにUAにNOTIFYメッセージを送らなければなりません。
The CS MUST NOT send unsolicited (out-of-dialog) NOTIFY messages.
CSは、迷惑（アウト・オブ・ダイアログ）NOTIFYメッセージを送ってはいけません。
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要求がために戻されていたヘッダを返します）しかし、誰ボディと、同じURIにリクエストをGET。
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.
NOTIFYメッセージは、構成変更サブスクリプションにUAによって受信されると、UAは、構成データがNOTIFYメッセージの本体内のHTTPヘッダ値と受信されたときに保持され、キャッシュ制御データを比較しなければなりません。 HTTPヘッダ値のキャッシュ制御データのいずれかが、元のコンフィギュレーションデータ応答中のものと異なる場合、UAは、もはや有効でないように記憶された設定データを考慮しなければなりません。 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は、「構成要求URLを構築」、2.3節で指定された新しい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構成データ応答の関係「モニター」でリンクヘッダを含んではいけません、とmax-ageディレクティブを指定するのCache-Controlヘッダを含まなければなりません。 HTTPでの最大エージングキャッシュ制御ディレクティブは、返されたデータをキャッシュすることができる最大秒数を指定します。この仕様は、構成データが有効であると考えられる最大時間であるとして、この時間を定義します。
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は、変更通知を提供するために、サブスクリプション・メカニズムを使用することを選択した場合、ノーCSからのメッセージをNOTIFYれている第2.5.1項で説明したようにUAが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は繰り返す必要がありHTTPS GETが提供された応答で返さキャッシュ制御データを使用して要求条件付きリクエストを作るために適切なHTTPヘッダと、記憶された設定データを取得するために使用される要求構成データ。これは、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は、構成データが最初に（2.5.1項、「構成変更サブスクリプション」）を得たときのように、そのURLへのサブスクリプションを作成し、維持しようとしなければなりません。
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の間の初期バックオフタイマ値を選択する包括的、および再試行する前に失敗した要求をこの秒数を待たなければなりません。
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は、先行する障害（Nは、前の失敗の数は2 ^ N）の数の累乗した2によりバックオフ・タイマ値を増加させ、この増加した数を待たなければなりません秒または再試行失敗した要求の前に、いずれか小さい方特定のエラー処理手順によって指定された最大間隔。
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).
6秒（4 + 2 ^ 1）、10秒（6 + 2 ^ 2）、18：例えば、最初の失敗の後、UAは、ランダムに以下の時間に再試行が続く4秒の初期バックオフタイマ値を選択します秒（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であるか、または[RFC3261]で指定されるように、デバイスのユーザを識別するURIをSIPS。
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.
レルムは、[RFC3261]で指定されるようにUAが認証チャレンジを受信するとき、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.
ユーザ名は[RFC3261]で指定されるようにUAが認証チャレンジを受信するとき、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].
この仕様は、[RFC2939]で定義されたIANAレジストリ「BOOTPベンダー拡張機能とDHCPオプション」に含めるのDHCPオプションコード141、「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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)".
上記の図では、検索文字列は、検索リストを指定する文字列です。 SEARCHLISTの長さは1つのオプション（255オクテット）内の許容最大値を超えた場合は、[RFC3396]「エンコーディングロングDHCPオプションの動的ホスト構成プロトコル（DHCPv4の）中」で説明したように、その後、複数のオプションを使用することができます。
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.
コンパクトに符号化される検索リストを可能にするために、SEARCHLISTでsearchstringsが連結され、[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構成サービスドメインオプションが存在している場合は、すべてのSIP UA構成サービスドメインオプションのデータ部分は、RFC 3396で指定されるように一緒に連結され、ポインタは、データの完全な集合体ブロック内のオフセットを示しています。
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]のセクション3、オプション119のために同じエンコーディングを使用しています「動的ホスト構成プロトコル（DHCP）ドメイン検索オプション」を参照してください。
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.
この仕様は、IANAレジストリに含めるため、DHCPv6のオプションコード58、OPTION_SIP_UA_CS_LISTを定義する「IPv6の動的ホスト構成プロトコル（DHCPv6）、DHCPオプションコードは、」RFC 3315で定義されます。
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIP_UA_CS_LIST (58)
オプションコードOPTION_SIP_UA_CS_LIST（58）
option-len Length of the 'searchlist' field in octets
オクテットの「検索リスト」フィールドのオプション-LEN長
searchlist The specification of the list of domain names in the SIP User Agent Configuration Service Domains
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.
「SEARCHLIST」内のドメイン名のリストは、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)":
この文書では、「SRV用のRRおよび動的委任ディスカバリサービス（DDDS）を使用してドメインベースのアプリケーションサービスロケーション」[RFC3958]で定義されたレジストリの次のU-NAPTRアプリケーション・サービス・タグを登録します。
+-------------------------+----------+
| 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".
このタグは、「Configuration ServiceのベースURLを取得」、2.3.1項に指定されている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フォーラムのユーザエージェント構成パラメータ」のレジストリを確立しています。このレジストリは、「構成要求のパラメータの追加」、セクション2.3.2で説明したように構成サービスへのユーザエージェントによって送信された初期設定データ要求に対してHTTPSリクエストパラメータを記録します。
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.
Configuration Serviceのドメイン名は、通常、無担保で操作の数に依存しているの最初の発見：DHCP応答がIPネットワークパラメータのいずれかの値を置き換えるために、攻撃者によって提供されることができる（2.1.2、「ネットワーク層のプロビジョニング」 ）コンフィギュレーションサービスドメイン名のデフォルトの選択肢であるローカルネットワークドメインを含みます。それは以前に使用した値とは異なり、特に設定サービスドメイン名の人間のユーザによる確認は、この（おそらく意図的でない）可能性のある再構成を緩和するために使用することができます。それが発見により変更することができないように、例えば、Configuration Serviceのドメイン名が固定されることがあります。以前にロードされたコンフィギュレーションが発見し、場所手順の一部が使用されている制約するかもしれないことに注意してください。
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.
情報は、（例えば、UAは、CSサーバ証明書に署名したCAの現在のCA証明書を有していなくてもよい）第一のコンフィギュレーションの前にCSサーバ証明書の完全な検証を実行するために必要な、実装は、設定にその情報を提供することをお勧めしますデータは、後続の再構成のために使用することができるように。これは、第1の構成の試みに対する脆弱性の窓を狭めます。
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項では、「構成変更サブスクリプション」）は、（要求が認証およびTLSの使用をダイジェストを含む）SIPで利用可能なので、すべてのセキュリティ・メカニズムを確立しています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の実装は通常、複数のトランスポート層セキュリティプロトコルのバージョンと同様に古いのSecure Sockets Layer（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.
UAは、SIPサービスプロバイダ、および構成サービスホストは、提供を要求し、またはSSL 2.0を使用してはなりません。詳細は[RFC5246]の付録E.2を参照してください。
Contributing Members of the SIP Forum User Agent Configuration Working Group:
SIPフォーラムのユーザーエージェント設定作業部会の貢献メンバー：
Francois Audet, Nortel Networks, Inc.
フランソワAudet、ノーテルネットワークス株式会社
Eric Burger, SIP Forum
エリック・バーガー、SIPフォーラム
Sumanth Channabasappa, Cable Television Laboratories, Inc. (CableLabs)
スーマンスChannabasappa、ケーブルテレビラボラトリーズ社（CableLabsの）
Martin Dolly, AT&T Labs
マーティン・ドリー、AT＆T Labs社
John Elwell, Siemens Enterprise Communications
ジョンエルウェル、シーメンスエンタープライズコミュニケーションズ
Marek Dutkiewicz, Polycom, Inc.
マレクDutkiewicz、ポリコム社
Andy Hutton, Siemens Enterprise Communications
アンディ・ハットン、シーメンスエンタープライズコミュニケーションズ
Lincoln Lavoie, University of New Hampshire
リンカーンLavoie、ニューハンプシャー大学
Scott Lawrence, Avaya, Inc.
スコット・ローレンス、アバイア株式会社
Paul Mossman, Avaya, Inc.
ポール・モスマン、アバイア株式会社
Michael Procter, VoIP.co.uk
マイケル・プロクター、VoIP.co.uk
Marc Robins, SIP Forum
マルク・ロビンス、SIPフォーラム
Henning Schulzrinne, Columbia University
ヘニングSchulzrinneと、コロンビア大学
Rifaat Shekh-Yusef, Avaya, Inc.
リファットシェイクユセフ、Avyでは、これ。
Robert Sparks, Tekelec
ロバート・スパークス、Tekelec
Simo Veikkolainen, Nokia
シモVeikkolainen、ノキア
The Editor would like to also acknowledge valuable contributions by Leslie Daigle and Margaret Wasserman.
エディタはまた、レスリーDaigle氏とマーガレットワッサーマンによって貴重な貢献を認めるしたいと思います。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年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.、Frystyk、H.、Masinter、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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、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.、BCP 43、RFC 2939、2000年9月 "新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン"。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、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.フォルツ、RFC 3319、2003年7月 "セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション"。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396]レモン、T.とS.チェシャー、 "動的ホスト構成プロトコル（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.チェシャー、 "動的ホスト構成プロトコル（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.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（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 4848、2007年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]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ローチ、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
メールアドレス：scott-ietf@skrb.org
John Elwell Siemens Enterprise Communications
ジョンエルウェルシーメンスエンタープライズコミュニケーションズ
Phone: +44 1908 817801 EMail: john.elwell@siemens-enterprise.com
電話：+44 1908 817801 Eメール：john.elwell@siemens-enterprise.com