[要約] RFC 6011は、SIPユーザーエージェントの設定に関するガイドラインです。このRFCの目的は、SIPユーザーエージェントの設定に関する一貫性と互換性を確保することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）を取得します。ハードウェアデバイスまたはソフトウェアかもしれません。一部のユーザーエージェントには、ユーザー名、パスワード、ドメイン名を受け入れることができるユーザーインターフェイスがあります。アナログテレフォニーアダプター（ATAS）のような他のデバイスには、添付のアナログ電話が提供するもの以外のユーザーインターフェイスはありません。非技術的なユーザーは、それが開始されたときに何か有用なことが起こるように、どのように最小限に設定しますか？
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
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].
この文書のキーワード "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）（ユーザー「John Smith」を追加）でユーザーIDをプロビジョニングし、ユーザーに電話番号を割り当てることから始まります。その番号は、特定のUAの行に割り当てる必要があります。これは通常、UAを選択し、シリアル番号（通常はメディアアクセスコントロール（MAC）アドレス）でPBXにプロビジョニングし、PBX構成のUAの「ライン」にIDまたは電話番号を割り当てることによって行われます。システム。
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には、ローカルユーザーインタラクションなしでユーザーID、電話番号、およびその他の構成データが提供されます。ネットワークに接続するだけで、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アドレス（ES）
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 (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.
o ユーザーエージェントが、動的ホスト構成プロトコルバージョン6（DHCPV6）[RFC3315]が定義されているネットワークテクノロジーでIPバージョン6を使用している場合、UAは標準のIPv6メカニズムを使用してIPネットワークパラメーターを決定できますが、DHCPV66666666オプション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「ローカルネットワークドメイン」で指定されているように、構成サービスドメインの候補値が取得されます。、「マニュアルドメイン名エントリ」。
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、「ネットワークレイヤープロビジョニング」を参照）を参照してください（セクション2.1.2「ネットワークレイヤープロビジョニング」を参照）を使用しようと試みる必要があります。DHCPおよび/またはDHCPV6によって複数の名前が提供されている場合（両方が使用されている場合、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、「構成サービスベース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].
構成サービスドメインは、「URISを使用したドメインベースのアプリケーションサービス」で定義されているURI対応命名機関ポインター（U-NAPTR）DDDSアプリケーションを使用して、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」である構成サービスドメイン名のNAPTRレコードは、「u」、空の置換フィールド、および次の構文の正規表現フィールド値に設定されたフラグフィールドで構成する必要があります（つまり、ドメイン名をhttps 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を代替として扱う必要があります。。
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.
Configuration Serviceドメイン名を要求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に1つ以上のパラメーターを追加して、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)".
[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」連絡ヘッダーフィールドパラメーターを含む場合、構成を要求する場合、SFUA-idパラメーターに同じ値を使用する必要があります。
sfua-user
sfua-user
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サイトのアカウントのログイン名である可能性があります。このパラメーターの構文は、「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-VENDOR
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-model
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-revision
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はDNSレコードを返す「embles.net」のDNS NAPTR要求を構築します。
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 "s" "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.
Service-Fieldの「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：11：22：33：44：55のリンクレイヤーMACアドレスがあります。構成を要求するユーザー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
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の構築」ユーザーエージェントは、UAが使用できる構成が返されるまで、各URLに対してHTTPS Get Requestを実行する必要があります。リクエスト。
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キャッシュ制御メタデータ（任意のキャッシュコントロールヘッダーからの最大時代の指令値、および構成データを提供する応答で返される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]「Transport Layer Security（TLS）拡張機能」で定義されているTLSクライアントのHelloメッセージにServer_Name拡張機能を提供する必要があります。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証明書チェーンを接続できる信頼できるルート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.
1つがある場合、UAはクライアント証明書を提供する必要があります。CSは、提供されている場合、UAクライアントの証明書を検証する必要があります。CSがUAから提供された証明書を認証できない場合（たとえば、UAが自己署名証明書を使用している）、CSはHTTP認証を使用して正常に認証する場合、CSは証明書のキャッシュを選択できます（次を参照してください段落）。これにより、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ユーザー値と同じ値でなければなりません。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 Request 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にリクエストを試みることができますが、同じホストへのリクエストは、要求の間で待機する必要があります。セクション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が検証できる場合）が含まれます。この構成サービスドメイン。
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「再試行手順」で定義されている手順に従う必要があります）。セクション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 構成データの変更の通知のために、UAによるCSへのSIPサブスクリプション。
o HTTP polling by the UA of the configuration data URL at the CS.
o CSでの構成データURLのUAによる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".
「モニター」関係を指定するリンクヘッダーを使用して成功した構成データ応答を受信する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のHTTPモニターイベントパッケージのUAからの適切に認証されたサブスクライブリクエストを受け入れる必要があります。サブスクライブリクエストの認証は、構成データで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を返された各構成データ要求に関連付ける必要があり、そのサブスクリプションのステータスの通知またはその他の変更は、関連するすべての構成データの有効性に影響します。
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が返された異なる構成データリソースのいずれかに変更がある場合、構成変更サブスクリプションに関する通知メッセージを送信する必要があります。
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.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.
構成変更サブスクライブリクエスト（初期リクエストまたはサブスクリプションの更新の試みのいずれか）が永続的に拒否される以外に失敗した場合、UAは関連する構成データを未知の有効性であると考える必要があり、で指定されたサブスクライブリクエストを再試行する必要がありますセクション2.7、「バックオフ手順の再試行」。RETRIES間の最大時間は30分を超えてはならず、構成が使用されている限りRETRIESを継続する必要があります。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-Monitor）サブスクリプションを明示的に終了する場合、UAは構成データを未知の有効性であると考える必要があります。[RFC3265]のセクション3.2.4で指定されている「理由」コードパラメーターを解釈および行動するためのルールが許可されている場合、UAはサブスクリプションの再確立を試みなければなりません。これらのルールで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".
UAに構成データの変更を通知するには、CSは、セクション2.5.1「構成変更サブスクリプション」で詳述されているように、UAによって確立された構成変更サブスクリプションのUAに通知メッセージを送信する必要があります。
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-Monitorイベントパッケージの通知メッセージの本文は、HTTPヘッドリクエストに応じて返されたHTTPヘッダーです（ヘッドリクエストは、ヘッドリクエストが返されるヘッダーを返します。同じ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.
Configuration Change SubscriptionでUAによって通知メッセージが受信されると、UAは、通知メッセージ本文の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".
このHTTPSが以前に構成データを提供したURLにリクエストする場合、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構成データ応答にリレーション「モニター」にリンクヘッダーを含めてはなりません。また、MAX-AGEディレクティブを指定するキャッシュコントロールヘッダーを含める必要があります。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がサブスクリプションメカニズムを使用して変更通知を提供することを選択し、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ポーリング方法を使用することを選択し、構成データ応答が受信されてから秒数がその応答でキャッシュコントロール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 Requestを繰り返す必要があります。設定データ。これにより、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応答には最大年齢のディレクティブを含むキャッシュ制御ヘッダーを含める必要があり、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は前の障害の数（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).
たとえば、最初の障害の後、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].
Resord-of-Record（AOR）は、[RFC3261]で指定されているように、デバイスのユーザーを識別するSIPまたはSIPS URIです。
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.
Remalは、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].
定義された場合のアウトバウンドプロキシには、明示的にルーティングされない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)".
上記の図では、SearchStringは検索リストを指定する文字列です。検索リストの長さが単一のオプション（255オクテット）内で最大許容値を超える場合、[RFC3396]で説明されているように、複数のオプションを使用できます。
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構成サービスドメインオプションが存在する場合、すべての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、「ダイナミックホスト構成プロトコル（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を定義します。IANAレジストリ「IPv6（DHCPV6）の動的ホスト構成プロトコル、RFC 3315で定義された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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIP_UA_CS_LIST (58)
Option-Code option_sip_ua_cs_list（58）
option-len Length of the 'searchlist' field in octets
オクテットの「検索リスト」フィールドのオプションレン長
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.
「検索リスト」のドメイン名のリストは、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]で定義されたレジストリの次の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".
このタグは、セクション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フォーラムユーザーエージェント構成パラメーター」のレジストリを確立しました。このレジストリは、セクション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]で説明されている「First Come First Servent」ポリシーを使用して、他のパラメーターエントリをこのレジストリに追加することができます。
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、「ネットワークレイヤープロビジョニング」）構成サービスドメイン名のデフォルトの選択肢であるローカルネットワークドメインを含みます。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 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.
構成サービスへの接続はTLSを介して行われます。TLSサーバーとして、CSはTLSの握手中に常にサーバー証明書を提供します。可能であれば、UAはその証明書を検証し、件名として構成サービスドメイン名、または少なくとも構成サービスベースURLのホスト名が含まれていることを確認する必要があります（[RFC2818]を参照）。最初の構成の前に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は不明なデバイスからの要求を拒否したり、特定のデバイスからの初期構成要求を受け入れる時間ウィンドウを制限するなどの他の測定値を実装できます。より安全なアプローチは、ユーザーにパスワードを提供することです。おそらく、初期アクセスに対してのみ有効な1回限りのパスワードです。高いセキュリティ環境では、構成サービスがユーザーエージェントが、構成データ要求のTLS接続で認証用のクライアント証明書を提供することを要求する場合があります。これにより、ユーザーエージェントの以前の手動構成、およびおそらく構成サービスが必要になり、その構成には、CS証明書を完全に検証するためのUAに十分な情報も含める必要があります。
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.
Configurationデータの初期リクエストでUAによって送信された要求パラメーターの一部またはすべての値（セクション2.3.2、「構成要求パラメーターの追加」を参照）は、機密情報です。構成データ要求はTLS接続に対して行われるため、その情報の機密性はネットワーク上で保護されています。Configuration Serviceの実装は、要求パラメーターデータが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 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.
TLSの実装は通常、Transport Layer Security Protocolの複数のバージョンと古いSecure Socketsレイヤー（SSL）プロトコルをサポートします。既知のセキュリティの脆弱性のため、SIP 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、Nortel Networks、Inc。
Eric Burger, SIP Forum
エリック・バーガー、SIPフォーラム
Sumanth Channabasappa, Cable Television Laboratories, Inc. (CableLabs)
Sumanth Channabasappa、Cable Television Laboratories、Inc。（CableLabs）
Martin Dolly, AT&T Labs
Martin Dolly、AT＆T Labs
John Elwell, Siemens Enterprise Communications
ジョン・エルウェル、シーメンスエンタープライズコミュニケーションズ
Marek Dutkiewicz, Polycom, Inc.
Marek Dutkiewicz、Polycom、Inc。
Andy Hutton, Siemens Enterprise Communications
Andy Hutton、Siemens Enterprise Communications
Lincoln Lavoie, University of New Hampshire
ニューハンプシャー大学リンカーン・ラヴォイ
Scott Lawrence, Avaya, Inc.
スコット・ローレンス、アヴァイア社
Paul Mossman, Avaya, Inc.
Paul Mossman、Avaya、Inc。
Michael Procter, VoIP.co.uk
マイケル・プロクター、voip.co.uk
Marc Robins, SIP Forum
マークロビンズ、SIPフォーラム
Henning Schulzrinne, Columbia University
ヘニングシュルツリン、コロンビア大学
Rifaat Shekh-Yusef, Avaya, Inc.
Rifaat Shekh-Yusef、Avaya、Inc。
Robert Sparks, Tekelec
ロバート・スパークス、テケレック
Simo Veikkolainen, Nokia
ノキア、シモ・ヴェイクコレイネン
The Editor would like to also acknowledge valuable contributions by Leslie Daigle and 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。、「動的ホスト構成プロトコル」、RFC 2131、1997年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 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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、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。、「新しい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：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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. 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およびThe Dynamic Deligation Discovery Service（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、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「Transport Layer Security（TLS）Extensions」、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。、「URISを使用したドメインベースのアプリケーションサービスの場所と動的委任ディスカバリーサービス（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] 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、「The Transport Layer Security（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] American National Standards Institute、「Media Endpoint Devices用のTelecommunications IP Telephony Infrastructure Link Leay Discovery Protocol」、1993年4月。
Authors' Addresses
著者のアドレス
Scott Lawrence (editor) Linden Research, Inc.
スコット・ローレンス（編集者）リンデン・リサーチ社
EMail: scott-ietf@skrb.org
John Elwell Siemens Enterprise Communications
John Elwell Siemens Enterprise Communications
Phone: +44 1908 817801
EMail: john.elwell@siemens-enterprise.com