[要約] RFC 7904は、RELOADプロトコルのためのSIPの使用方法について説明しています。このRFCの目的は、SIPを使用してRELOADネットワークでリソースの場所と検出を行う方法を提供することです。
Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 7904 Cisco
Category: Standards Track B. Lowekamp
ISSN: 2070-1721 Skype
E. Rescorla
RTFM, Inc.
S. Baset
IBM
H. Schulzrinne
Columbia University
T. Schmidt, Ed.
HAW Hamburg
October 2016
A SIP Usage for REsource LOcation And Discovery (RELOAD)
リソースの取得と検出（RELOAD）を再利用するためのSIPの使用法
Abstract
概要
This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.
このドキュメントでは、リソースの再配置と検出（RELOAD）のSIP使用法を定義します。 SIP Usageは、完全に分散されたシステムでのSIPプロキシまたはレジストラの機能を提供し、オーバーレイに格納されたレコードのアドレス（AOR）の検索サービスを含みます。また、登録でAORをオーバーレイを介して到達可能な特定のノードにマップできるようにする、グローバルにルーティング可能なユーザーエージェントURI（GRUU）も定義します。ピアのこのような最初の接続後、RELOAD AppAttachメソッドを使用して、SIPメッセージが交換されるノード間に直接接続を確立します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7904.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7904で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 7
3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 9
3.4. Overlay Configuration Document Extension . . . . . . . . 10
4. Looking Up an AOR . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11
4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 12
5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 12
5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 12
5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 13
6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14
8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 15
8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 15
8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15
8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15
8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
9.2. XML Namespace Registration . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Third-Party Registration . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions without the requirement for a permanent proxy or registration servers, e.g., a fully distributed telephony service. This service transparently supports SIP addressing including telephone numbers. In such a network, the RELOAD overlay itself performs the registration and rendezvous functions ordinarily associated with such servers.
位置情報探索と発見の再資源化（RELOAD）[RFC6940]は、インターネットで一般的に使用されるピアツーピア（P2P）シグナリングプロトコルを指定します。このドキュメントでは、SIP [RFC3261]ユーザーエージェント（UA）が、完全に分散されたテレフォニーサービスなど、永続的なプロキシサーバーや登録サーバーを必要とせずにピアツーピアSIP（またはSIPS）セッションを確立できるようにするRELOADのSIP使用法を定義します。 。このサービスは、電話番号を含むSIPアドレッシングを透過的にサポートします。そのようなネットワークでは、RELOADオーバーレイ自体が、そのようなサーバーに通常関連付けられている登録機能とランデブー機能を実行します。
The SIP Usage involves two basic functions:
SIPの使用には、2つの基本的な機能が含まれます。
Registration: SIP UAs can use the RELOAD data storage functionality to store a mapping from their Address of Record (AOR) to their Node-ID in the overlay and to retrieve the Node-ID of other UAs.
登録：SIP UAはRELOADデータストレージ機能を使用して、レコードのアドレス（AOR）からノードIDへのマッピングをオーバーレイに保存し、他のUAのノードIDを取得できます。
Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it wishes to call, it can use the RELOAD message routing system to set up a direct connection for exchanging SIP messages.
ランデブー：SIP UAは、呼び出したいAORのノードIDを特定すると、RELOADメッセージルーティングシステムを使用して、SIPメッセージを交換するための直接接続をセットアップできます。
Mappings are stored in the SipRegistration Resource Record defined in this document. All operations required to perform a SIP registration or rendezvous are standard RELOAD protocol methods.
マッピングは、このドキュメントで定義されているSipRegistrationリソースレコードに格納されます。 SIP登録またはランデブーを実行するために必要なすべての操作は、標準のRELOADプロトコルメソッドです。
For example, Bob registers his AOR, "bob@dht.example.com", for his Node-ID "1234". When Alice wants to call Bob, she queries the overlay for "bob@dht.example.com" and receives Node-ID "1234" in return. She then uses the overlay routing to establish a direct connection with Bob and can directly transmit a standard SIP INVITE. In detail, this works along the following steps:
たとえば、ボブはノードID「1234」のAOR「bob@dht.example.com」を登録します。アリスがボブに電話をかけたい場合、彼女は「bob@dht.example.com」のオーバーレイをクエリし、代わりにノードID「1234」を受け取ります。その後、オーバーレイルーティングを使用してボブとの直接接続を確立し、標準のSIP INVITEを直接送信できます。詳細には、これは次の手順で機能します。
1. Bob, operating Node-ID "1234", stores a mapping from his AOR to his Node-ID in the overlay by applying a Store request for "bob@dht.example.com -> 1234".
1. Node-ID "1234"を操作するBobは、 "bob@dht.example.com-> 1234"のStoreリクエストを適用して、AORからNode-IDへのマッピングをオーバーレイに保存します。
2. Alice, operating Node-ID "5678", decides to call Bob. She retrieves Node-ID "1234" by performing a Fetch request on "bob@dht.example.com".
2. ノードID「5678」を操作しているアリスは、ボブに電話することにしました。彼女は、「bob@dht.example.com」に対してフェッチ要求を実行することにより、ノードID「1234」を取得します。
3. Alice uses the overlay to route an AppAttach message to Bob's Peer (ID "1234"). Bob responds with his own AppAttach and they set up a direct connection, as shown in Figure 1. Note that mutual Interactive Connectivity Establishment (ICE) checks are invoked automatically from the AppAttach message exchange.
3. アリスはオーバーレイを使用して、AppAttachメッセージをボブのピア（ID "1234"）にルーティングします。ボブは自分のAppAttachで応答し、図1に示すように直接接続を設定します。相互接続性の確立（ICE）チェックは、AppAttachメッセージ交換から自動的に呼び出されることに注意してください。
Overlay
Alice Peer1 ... PeerN Bob
(5678) (1234)
-------------------------------------------------
AppAttach ->
AppAttach ->
AppAttach ->
AppAttach ->
<- AppAttach
<- AppAttach
<- AppAttach
<- AppAttach
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
Figure 1: Connection Setup in P2P SIP Using the RELOAD Overlay
図1：RELOADオーバーレイを使用したP2P SIPの接続設定
It is important to note that the only role of RELOAD in this example is to set up the direct SIP connection between Alice and Bob. As soon as the ICE checks complete and the connection is established, ordinary SIP or SIPS is used. In particular, the establishment of the media channel for a phone call happens via the usual SIP mechanisms, and RELOAD is not involved. Media never traverses the overlay. After the successful exchange of SIP messages, communicating Peers run ICE connectivity checks for media.
この例でのRELOADの唯一の役割は、アリスとボブの間に直接SIP接続をセットアップすることであることに注意することが重要です。 ICEチェックが完了して接続が確立されるとすぐに、通常のSIPまたはSIPSが使用されます。特に、通話用のメディアチャネルの確立は通常のSIPメカニズムを介して行われ、RELOADは関与しません。メディアがオーバーレイを通過することはありません。 SIPメッセージの交換が成功した後、通信しているピアはメディアのICE接続チェックを実行します。
In addition to mappings from AORs to Node-IDs, the SIP Usage also allows mappings from AORs to other AORs. This enables an indirection useful for call forwarding. For instance, if Bob wants his phone calls temporarily forwarded to Charlie, he can store the mapping "bob@dht.example.com -> charlie@dht.example.com". When Alice wants to call Bob, she retrieves this mapping and can then fetch Charlie's AOR to retrieve his Node-ID. These mechanisms are described in Section 3.
AORからノードIDへのマッピングに加えて、SIPの使用により、AORから他のAORへのマッピングも可能になります。これにより、コール転送に役立つ間接化が可能になります。たとえば、ボブが自分の電話を一時的にチャーリーに転送したい場合は、マッピング「bob@dht.example.com-> charlie@dht.example.com」を保存できます。アリスがボブを呼び出したい場合、彼女はこのマッピングを取得し、チャーリーのAORをフェッチして自分のノードIDを取得できます。これらのメカニズムについては、セクション3で説明します。
Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627] can be used for directly accessing Peers. They are handled via a separate mechanism, as described in Section 6.
または、グローバルにルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]を使用して、ピアに直接アクセスできます。セクション6で説明するように、これらは別のメカニズムで処理されます。
Concepts used in this document can be extended to include tel URIs [RFC3966], but this will require further specifications to ensure semantic interoperability of implementations.
このドキュメントで使用されている概念は、tel URI [RFC3966]を含めるように拡張できますが、実装のセマンティックな相互運用性を保証するには、さらに仕様が必要になります。
The SIP Usage for RELOAD addresses a fully distributed deployment of session-based services among overlay Peers. This RELOAD Usage may be relevant in a variety of environments, including a tightly controlled environment of a single provider that admits parties using AORs with domains from controlled namespace(s) only, or an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace. It is noteworthy in this context that -- in contrast to regular SIP -- domain names play no role in routing to a proxy server. Once connectivity to an overlay is given, the technology allows any name registration, possibly constrained by overlay domain restrictions.
RELOADのSIP Usageは、オーバーレイピア間でのセッションベースのサービスの完全に分散された展開に対応します。このRELOADの使用法は、制御された名前空間のみのドメインでAORを使用する当事者を許可する単一プロバイダーの厳しく制御された環境、または自由に登録を許可するオープンなマルチパーティインフラストラクチャなど、さまざまな環境に関連する可能性があります。さまざまなドメイン名前空間のランデブー。このコンテキストでは、通常のSIPとは対照的に、ドメイン名がプロキシサーバーへのルーティングに関与しないことに注意してください。オーバーレイへの接続が与えられると、テクノロジーは名前の登録を許可し、オーバーレイドメインの制限によって制約を受ける可能性があります。
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]で説明されているように解釈されます。
We use the terminology and definitions from "Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)" [RFC7890] and the RELOAD Base Protocol [RFC6940] extensively in this document.
このドキュメントでは、「ピアツーピアSIP（P2PSIP）の概念と用語」[RFC7890]とRELOADベースプロトコル[RFC6940]の用語と定義を広く使用しています。
In addition, terms defined by SIP [RFC3261] apply to this memo. The term AOR is the SIP "Address of Record" used to identify a user in SIP. For example, "alice@example.com" could be the AOR for Alice. For the purposes of this specification, an AOR is considered not to include the scheme (e.g., sip:), as the AOR needs to match the rfc822Name in the X.509 v3 certificates [RFC5280]. It is worth noting that SIP and SIPS are distinguished in P2PSIP by the Application-ID.
さらに、SIP [RFC3261]で定義された用語がこのメモに適用されます。 AORという用語は、SIPでユーザーを識別するために使用されるSIPの「Address of Record」です。たとえば、「alice@example.com」はアリスのAORになります。 AORはX.509 v3証明書のrfc822Nameと一致する必要があるため、この仕様の目的では、AORはスキーム（sip：など）を含まないと見なされます[RFC5280]。 SIPとSIPSは、P2PSIPではアプリケーションIDによって区別されることに注意してください。
In ordinary SIP, a UA registers the user's AOR and its network location with a registrar. In RELOAD, this registrar function is provided by the overlay as a whole. To register its location, a RELOAD peer stores a SipRegistration Resource Record under its own AOR using the SIP-REGISTRATION Kind, which is formally defined in Section 7. Note that the registration lifetime known from the regular SIP REGISTER method is inherited from the lifetime attribute of the basic RELOAD StoredData structure (see Section 7 in [RFC6940]).
通常のSIPでは、UAはユーザーのAORとそのネットワークロケーションをレジストラに登録します。 RELOADでは、このレジストラ機能はオーバーレイ全体として提供されます。その位置を登録するために、RELOADピアは、セクション7で正式に定義されているSIP-REGISTRATION Kindを使用して、SipRegistrationリソースレコードを独自のAORの下に格納します。通常のSIP REGISTERメソッドで認識される登録ライフタイムは、lifetime属性から継承されることに注意してください。基本的なRELOAD StoredData構造の概要（[RFC6940]のセクション7を参照）。
A RELOAD overlay MAY restrict the storage of AORs. Namespaces (i.e., the right-hand side of the AOR) that are supported for registration and lookup can be configured for each RELOAD deployment as described in Section 3.4.
RELOADオーバーレイは、AORのストレージを制限する場合があります。登録とルックアップでサポートされている名前空間（つまり、AORの右側）は、セクション3.4で説明されているように、RELOADデプロイメントごとに構成できます。
As a simple example, consider Alice with an AOR "alice@dht.example.org" at Node-ID "1234". She might store the mapping "alice@dht.example.org -> 1234" telling anyone who wants to call her to contact node "1234".
簡単な例として、ノードID "1234"にAOR "alice@dht.example.org"を持つAliceを考えます。彼女は、「alice@dht.example.org-> 1234」というマッピングを保存して、彼女に電話してノード「1234」に連絡することを望んでいる人全員に知らせることができます。
RELOAD peers can store two kinds of SIP mappings,
RELOADピアは2種類のSIPマッピングを保存できます。
o from an AOR to a destination list (a single Node-ID is just a trivial destination list), or
o AORから宛先リストへ（単一のノードIDは単純な宛先リストです）、または
o from one AOR to another.
o あるAORから別のAORへ。
The meaning of the first kind of mapping is "in order to contact me, form a connection with this Peer." The meaning of the second kind of mapping is "in order to contact me, dereference this AOR". The latter allows for forwarding. For instance, if Alice wants her calls to be forwarded to her secretary, Sam, she might insert the following mapping, "alice@dht.example.org -> sam@dht.example.org".
最初の種類のマッピングの意味は、「私に連絡するために、このピアとの接続を形成する」です。 2番目の種類のマッピングの意味は、「私に連絡するために、このAORを逆参照する」です。後者は転送を可能にします。たとえば、アリスが自分の電話を秘書であるサムに転送することを希望している場合、アリスは「alice@dht.example.org-> sam@dht.example.org」というマッピングを挿入できます。
This section defines the SipRegistration Resource Record as follows:
このセクションでは、SipRegistrationリソースレコードを次のように定義します。
enum {
sip_registration_uri(1),
sip_registration_route(2),
(255)
} SipRegistrationType;
select (SipRegistration.type) {
case sip_registration_uri:
opaque uri<0..2^16-1>;
case sip_registration_route:
opaque contact_prefs<0..2^16-1>;
Destination destination_list<3..2^16-1>;
/* This type can be extended */
} SipRegistrationData;
} SipRegistrationData;
struct {
SipRegistrationType type;
uint16 length;
SipRegistrationData data;
} SipRegistration;
The contents of the SipRegistration Resource Record are:
SipRegistrationリソースレコードの内容は次のとおりです。
type
タイプ
the type of the registration
登録のタイプ
length
長さ
the length of the rest of the PDU
残りのPDUの長さ
data
データ
the registration data
登録データ
o If the registration is of type "sip_registration_uri", then the contents are an opaque string containing the AOR.
o 登録のタイプが「sip_registration_uri」の場合、コンテンツはAORを含む不透明な文字列です。
o If the registration is of type "sip_registration_route", then the contents are an opaque string containing the registrant's contact preferences and a destination list for the Peer.
o 登録のタイプが「sip_registration_route」の場合、内容は、登録者の連絡先設定とピアの宛先リストを含む不透明な文字列です。
The callee expresses its capabilities within the contact preferences as specified in [RFC3840]. It encodes a media feature set comprised of its capabilities as a contact predicate, i.e., a string of feature parameters that appear as part of the Contact header field. Feature parameters are derived from the media feature set syntax of [RFC2533] (see also [RFC2738]) as described in [RFC3840].
呼び出し先は、[RFC3840]で指定されている連絡先設定内でその機能を表現します。これは、その機能で構成されるメディア機能セットを連絡先述語、つまり、連絡先ヘッダーフィールドの一部として表示される機能パラメータの文字列としてエンコードします。機能パラメータは、[RFC3840]で説明されている[RFC2533]（[RFC2738]も参照）のメディア機能セット構文から導出されます。
This encoding covers all SIP User Agent capabilities, as defined in [RFC3840] and registered in the SIP feature tag registration tree. In particular, a callee can indicate that it prefers contact via a particular SIP scheme -- SIP or SIPS -- by using one of the following contact_prefs attributes:
このエンコーディングは、[RFC3840]で定義され、SIP機能タグ登録ツリーに登録されているすべてのSIPユーザーエージェント機能をカバーしています。特に、呼び出し先は、次のいずれかのcontact_prefs属性を使用して、特定のSIPスキーム（SIPまたはSIPS）経由の連絡を優先することを示すことができます。
(sip.schemes=SIP) (sip.schemes=SIPS)
（sip.schemes = SIP）（sip.schemes = SIPS）
RELOAD explicitly supports multiple registrations for a single AOR. The registrations are stored in a dictionary with Node-IDs as the dictionary keys. Consider, for instance, the case where Alice has two Peers:
RELOADは、単一のAORに対して複数の登録を明示的にサポートします。登録は、ノードIDを辞書キーとして持つ辞書に保存されます。たとえば、アリスに2つのピアがある場合を考えてみます。
o her desk phone (1234)
o 彼女のデスクフォン（1234）
o her cell phone (5678)
o 彼女の携帯電話（5678）
Alice might store the following in the overlay at resource "alice@dht.example.com":
アリスは、リソース「alice@dht.example.com」のオーバーレイに次のものを保存する場合があります。
o a SipRegistration of type "sip_registration_route" with dictionary key "1234" and value "1234", both referring to Node-IDs
o タイプが「sip_registration_route」で、辞書キーが「1234」と値が「1234」のSipRegistration。どちらもノードIDを参照します。
o a SipRegistration of type "sip_registration_route" with dictionary key "5678" and value "5678"
o タイプ「sip_registration_route」のSipRegistration、辞書キーは「5678」、値は「5678」
Note that this structure explicitly allows one Node-ID to forward to another Node-ID. For instance, Alice could set calls to her desk phone to ring at her cell phone by storing a SipRegistration of type "sip_registration_route" with a dictionary key "1234" and a value "5678".
この構造では、1つのノードIDを別のノードIDに明示的に転送できることに注意してください。たとえば、アリスは、タイプ "sip_registration_route"のSipRegistrationをディクショナリキー "1234"と値 "5678"で保存することにより、自分のデスクの電話への通話を携帯電話で鳴らすように設定できます。
In order to prevent hijacking or other misuse, registrations are subject to access control rules. Two kinds of restrictions apply:
ハイジャックやその他の誤用を防ぐために、登録にはアクセス制御ルールが適用されます。 2種類の制限が適用されます。
o A Store is permitted only for AORs with domain names that fall into the namespaces supported by the RELOAD Overlay Instance.
o ストアは、RELOADオーバーレイインスタンスでサポートされる名前空間に該当するドメイン名を持つAORに対してのみ許可されます。
o Storing requests are performed according to the USER-NODE-MATCH access control policy of RELOAD.
o 要求の格納は、RELOADのUSER-NODE-MATCHアクセス制御ポリシーに従って実行されます。
Before issuing a Store request to the overlay, any Peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the namespaces defined in the overlay configuration document (see Section 3.4).
オーバーレイにストアリクエストを発行する前に、ピアは、リクエストのAORが、そのドメイン名とオーバーレイ構成ドキュメントで定義されているネームスペース（セクション3.4を参照）に関して有効なリソース名であることを確認する必要があります（SHOULD）。
Before a Store is permitted, the Storing Peer MUST check that:
ストアが許可される前に、ストアピアは次のことを確認する必要があります。
o The AOR of the request is a valid Resource Name with respect to the namespaces defined in the overlay configuration document.
o 要求のAORは、オーバーレイ構成文書で定義されている名前空間に関して有効なリソース名です。
o The certificate contains a username that is a SIP AOR that hashes to the Resource-ID it is being stored at.
o 証明書には、格納先のResource-IDにハッシュするSIP AORであるユーザー名が含まれています。
o The certificate contains a Node-ID that is the same as the dictionary key it is being stored at.
o 証明書には、保存先のディクショナリキーと同じノードIDが含まれています。
If any of these checks fail, the request MUST be rejected with an Error_Forbidden error.
これらのチェックのいずれかが失敗した場合、リクエストはError_Forbiddenエラーで拒否される必要があります。
Note that these rules permit Alice to forward calls to Bob without his permission. However, they do not permit Alice to forward Bob's calls to her. See Section 8.2.2 for additional details.
これらのルールにより、アリスはボブに許可なく通話を転送することができます。しかし、彼らはアリスがボブの呼び出しを彼女に転送することを許可していません。詳細については、セクション8.2.2を参照してください。
The use of a SIP-enabled overlay MAY be restricted to users with AORs from specific domains. When deploying an overlay service, providers can implement such restrictions by defining a set of namespaces for admissible domain names. This section extends the overlay configuration document by defining new elements for patterns that describe a corresponding domain name syntax.
SIP対応オーバーレイの使用は、特定のドメインからのAORを持つユーザーに制限される場合があります。プロバイダーは、オーバーレイサービスをデプロイするときに、許可されるドメイン名の名前空間のセットを定義することにより、このような制限を実装できます。このセクションでは、対応するドメイン名構文を記述するパターンの新しい要素を定義することにより、オーバーレイ構成ドキュメントを拡張します。
A RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions. To apply restrictions, the overlay configuration document needs to contain a <domain-restrictions> element. The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements. A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true. Each <pattern> element defines a pattern for constructing admissible resource names. It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). Encoding of the domain name adheres to the restricted ASCII character set without character escaping as defined in Section 19.1 of [RFC3261].
RELOADオーバーレイは、任意のAORのストア要求を受け入れるように、またはドメイン名の制限を適用するように構成できます。制限を適用するには、オーバーレイ構成ドキュメントに<domain-restrictions>要素を含める必要があります。 <domain-restrictions>要素は、ゼロから複数の<pattern>サブ要素のコンテナとして機能します。 <pattern>要素は、その親要素の「enable」属性がtrueに設定されている場合に存在する場合があります。各<pattern>要素は、許容されるリソース名を作成するためのパターンを定義します。タイプはxsd：stringであり、「POSIX拡張正規表現」に従って正規表現として解釈されます（[IEEE-Posix]の仕様を参照）。ドメイン名のエンコードは、[RFC3261]のセクション19.1で定義されているように、文字がエスケープされない制限付きのASCII文字セットに準拠しています。
Inclusion of a <domain-restrictions> element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the "enable" attribute is not set or set to false, the overlay MUST only accept AORs that match the domain name of the overlay. If the element is included and the "enable" attribute is set to true, the overlay MUST only accept AORs that match patterns specified in the <domain-restrictions> element.
オーバーレイ構成文書に<domain-restrictions>要素を含めることはオプションです。要素が含まれていない場合、デフォルトの動作では、すべてのAORが受け入れられます。要素が含まれ、「enable」属性が設定されていないかfalseに設定されている場合、オーバーレイは、オーバーレイのドメイン名と一致するAORのみを受け入れる必要があります。要素が含まれ、「enable」属性がtrueに設定されている場合、オーバーレイは<domain-restrictions>要素で指定されたパターンに一致するAORのみを受け入れる必要があります。
Example of Domain Patterns: dht\.example\.com .*\.my\.example
ドメインパターンの例：dht \ .example \ .com。* \。my \ .example
In this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.example".
この例では、<user> @ dht.example.comの形式、またはドメイン "my.example"で終わるすべてのAORが受け入れられます。
The RELAX NG grammar for the AOR Domain Restriction reads:
AORドメイン制限のRELAX NG文法は次のとおりです。
# AOR DOMAIN RESTRICTION URN SUB-NAMESPACE
＃AORドメイン制限URNサブネームスペース
namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip"
# AOR DOMAIN RESTRICTION ELEMENT
＃AORドメイン制限要素
Kind-parameter &= element sip:domain-restriction {
attribute enable { xsd:boolean }
# PATTERN ELEMENT
＃パターン要素
element sip:pattern { xsd:string }*
}?
A RELOAD user, member of an overlay, who wishes to call another user with a given AOR SHALL proceed in the following way:
オーバーレイのメンバーであるRELOADユーザーが、特定のAORを使用して別のユーザーを呼び出したい場合は、次のように処理する必要があります。
AOR is a GRUU? If the AOR is a GRUU for this overlay, the callee can be contacted directly as described in Section 6.
AORはGRUUですか？ AORがこのオーバーレイのGRUUである場合、セクション6で説明されているように、呼び出し先に直接連絡することができます。
AOR domain is hosted in overlay? If the domain part of the AOR matches a domain pattern configured in the overlay, the user can continue to resolve the AOR in this overlay. The user MAY choose to query the DNS service records to search for additional support of this domain name.
AORドメインはオーバーレイでホストされていますか？ AORのドメイン部分がオーバーレイで構成されたドメインパターンと一致する場合、ユーザーはこのオーバーレイでAORを解決し続けることができます。ユーザーは、DNSサービスレコードをクエリして、このドメイン名の追加サポートを検索することを選択できます（MAY）。
AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user might query the DNS (or other discovery services at hand) to search for an alternative overlay that services the AOR under request. Alternatively, standard SIP procedures for contacting the callee might be used.
AORドメインはオーバーレイでサポートされていませんか？ AORのドメイン部分が現在のオーバーレイでサポートされていない場合、ユーザーはDNS（または他の検出サービス）に照会して、要求に応じてAORを提供する代替オーバーレイを検索できます。または、着信側に連絡するための標準のSIP手順を使用することもできます。
AOR inaccessible? If all of the above contact attempts fail, the call fails.
AORにアクセスできませんか？上記のすべてのコンタクト試行が失敗した場合、コールは失敗します。
The procedures described above likewise apply when nodes are simultaneously connected to several overlays.
上記の手順は、ノードが複数のオーバーレイに同時に接続されている場合にも同様に適用されます。
A RELOAD user that has discovered a route to an AOR in the current overlay SHALL execute the following steps:
現在のオーバーレイでAORへのルートを発見したRELOADユーザーは、次の手順を実行する必要があります。
1. Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID corresponding to the AOR. This Fetch SHOULD NOT indicate any dictionary keys, so that it will fetch all the stored values.
1. AORに対応するResource-IDで、Find for Kind SIP-REGISTRATIONを実行します。このフェッチは、格納されているすべての値をフェッチするように、ディクショナリキーを示すべきではありません（SHOULD NOT）。
2. If any of the results of the Fetch are non-GRUU AORs, then repeat step 1 for that AOR.
2. フェッチの結果のいずれかがGRUU以外のAORである場合は、そのAORについてステップ1を繰り返します。
3. Once only GRUUs and destination lists remain, the Peer removes duplicate destination lists and GRUUs from the list and initiates SIP or SIPS connections to the appropriate Peers as described in the following sections. If there are also external AORs, the Peer follows the appropriate procedure for contacting them as well.
3. GRUUと宛先リストのみが残ると、ピアはリストから重複した宛先リストとGRUUを削除し、次のセクションで説明するように、適切なピアへのSIPまたはSIPS接続を開始します。外部AORもある場合、ピアはそれらに接続するための適切な手順に従います。
Once the Peer has translated the AOR into a set of destination lists, it then uses the overlay to route AppAttach messages to each of those Peers. The "application" field MUST be either 5060 to indicate SIP or 5061 to indicate SIPS. If certificate-based authentication is in use, the responding Peer MUST present a certificate with a Node-ID matching the terminal entry in the destination list. Otherwise, the connection MUST NOT be used and MUST be closed. Note that it is possible that the Peers already have a RELOAD connection mutually established. This MUST NOT be used for SIP messages unless it is a SIP connection. A previously established SIP connection MAY be used for a new call.
ピアがAORを一連の宛先リストに変換すると、オーバーレイを使用して、AppAttachメッセージをそれらの各ピアにルーティングします。 「アプリケーション」フィールドは、SIPを示す5060またはSIPSを示す5061でなければなりません。証明書ベースの認証が使用されている場合、応答するピアは、宛先リストの端末エントリと一致するノードIDを含む証明書を提示する必要があります。それ以外の場合は、接続を使用してはならず（MUST NOT）、閉じる必要があります。ピアがすでに相互に確立されたRELOAD接続を持っている可能性があることに注意してください。これは、SIP接続でない限り、SIPメッセージに使用してはなりません。以前に確立されたSIP接続は、新しいコールに使用される場合があります。
Once the AppAttach succeeds, the Peer sends plain or (D)TLS-encrypted SIP messages over the connection as in normal SIP. A caller MAY choose to contact the callee using SIP or SIPS, but SHOULD follow a preference indicated by the callee in its contact_prefs attribute (see Section 3.2). A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP scheme, or select a single one. However, a callee that decides to accept SIPS calls only, SHOULD indicate its choice by setting the corresponding attribute in its contact_prefs. It is noteworthy that, according to [RFC6940], all overlay links are built on (D)TLS-secured transport.
AppAttachが成功すると、ピアは通常のSIPの場合と同様に、接続を介してプレーンメッセージまたは（D）TLS暗号化SIPメッセージを送信します。発信者は、SIPまたはSIPSを使用して着信者に連絡することを選択できます（MAY）が、そのcontact_prefs属性で着信者によって示される設定に従う必要があります（セクション3.2を参照）。呼び出し先は、SIPポートとSIPSポートの両方でリッスンして、いずれかのSIPスキームからの呼び出しを受け入れるか、1つ選択するかを選択できます（MAY）。ただし、SIPS呼び出しのみを受け入れることを決定する呼び出し先は、そのcontact_prefsで対応する属性を設定することにより、その選択を示す必要があります（SHOULD）。 [RFC6940]によると、すべてのオーバーレイリンクが（D）TLSで保護されたトランスポート上に構築されていることは注目に値します。
SIP messages carry the SIP URIs of actual overlay endpoints (e.g., "sip:alice@dht.example.com") in the Via and Contact headers, while the communication continues via the RELOAD connection. However, a UA can redirect its communication path by setting an alternate Contact header field like in ordinary SIP.
SIPメッセージは、ViaおよびContactヘッダーで実際のオーバーレイエンドポイント（「sip：alice@dht.example.com」など）のSIP URIを伝送しますが、通信はRELOAD接続を介して続行されます。ただし、UAは、通常のSIPのように代替の連絡先ヘッダーフィールドを設定することで、通信パスをリダイレクトできます。
In many cases, RELOAD connections established from ICE [RFC5245] negotiations will traverse stateful NATs and firewalls. It is the responsibility of the Peers to send messages with a frequency sufficient to maintain the necessary state in these NATs and firewalls and thus keep the connection alive. Keepalives are a mandatory component of ICE (see Section 10 of [RFC5245]) and no further operations are required. Applications that want to assure maintenance of sessions individually need to follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-alive techniques in agreement with its transport binding as defined in Section 3.5 of [RFC5626].
多くの場合、ICE [RFC5245]ネゴシエーションから確立されたRELOAD接続は、ステートフルNATおよびファイアウォールを通過します。これらのNATとファイアウォールで必要な状態を維持し、接続を維持するのに十分な頻度でメッセージを送信するのは、ピアの責任です。キープアライブはICEの必須コンポーネントであり（[RFC5245]のセクション10を参照）、それ以上の操作は必要ありません。セッションのメンテナンスを個別に保証したいアプリケーションは、通常のSIPの手段に従う必要があります。したがって、SIPピアは、[RFC5626]のセクション3.5で定義されているトランスポートバインディングと一致するキープアライブ技術を適用してもよい（MAY）。
Globally Routable User Agent URIs (GRUUs) [RFC5627] have been designed to allow direct routing to a specific UA instance without the need for dereferencing by a domain-specific SIP proxy function. The concept is transferred to RELOAD overlays as follows. GRUUs in RELOAD are constructed by embedding a base64-encoded destination list in the "gr" URI parameter of the GRUU. The base64 encoding is done with the alphabet specified in Table 1 of [RFC4648] with the exception that "~" is used in place of "=".
グローバルにルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]は、ドメイン固有のSIPプロキシ機能による逆参照を必要とせずに、特定のUAインスタンスに直接ルーティングできるように設計されています。コンセプトは、次のようにRELOADオーバーレイに転送されます。 RELOADのGRUUは、GRUUの「gr」URIパラメータにbase64でエンコードされた宛先リストを埋め込むことによって構築されます。 base64エンコーディングは、「=」の代わりに「〜」が使用されることを除いて、[RFC4648]の表1で指定されたアルファベットで行われます。
Example of a RELOAD GRUU:
alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
GRUUs do not require storing data in the Overlay Instance. Rather, when a Peer needs to route a message to a GRUU in the same P2P overlay, it simply uses the destination list and connects to that Peer. Because a GRUU contains a destination list, it can have the same contents as a destination list stored elsewhere in the resource dictionary.
GRUUは、オーバーレイインスタンスにデータを保存する必要はありません。むしろ、ピアが同じP2PオーバーレイのGRUUにメッセージをルーティングする必要がある場合、宛先リストを使用してそのピアに接続するだけです。 GRUUには宛先リストが含まれているため、リソースディクショナリの他の場所に格納されている宛先リストと同じ内容を持つことができます。
Anonymous GRUUs [RFC5767] are constructed analogously, but require either that the enrollment server issues a different Node-ID for each anonymous GRUU required, or that a destination list be used that includes a Peer that compresses the destination list to stop the Node-ID from being revealed.
匿名GRUU [RFC5767]は同様に構築されますが、登録サーバーが必要な匿名GRUUごとに異なるノードIDを発行するか、宛先リストを圧縮してノードIDを停止するピアを含む宛先リストを使用する必要があります明らかにされてから。
This section defines the SIP-REGISTRATION Kind.
このセクションでは、SIP-REGISTRATIONの種類を定義します。
Name: SIP-REGISTRATION
名前：SIP-REGISTRATION
Kind IDs: The Resource Name for the SIP-REGISTRATION Kind-ID is the AOR of the user as specified in Section 2. The data stored is a SipRegistration, which can contain either another URI or a destination list to the Peer that is acting for the user.
Kind ID：SIP-REGISTRATION Kind-IDのリソース名は、セクション2で指定されたユーザーのAORです。格納されているデータはSipRegistrationであり、SipRegistrationに別のURIまたは対象となるピアへの宛先リストを含めることができますユーザー。
Data Model: The data model for the SIP-REGISTRATION Kind-ID is a dictionary. The dictionary key is the Node-ID of the Storing Peer. This allows each Peer (presumably corresponding to a single device) to store a single route mapping.
データモデル：SIP-REGISTRATION Kind-IDのデータモデルは辞書です。ディクショナリキーは、Storing PeerのノードIDです。これにより、各ピア（おそらく単一のデバイスに対応する）が単一のルートマッピングを保存できるようになります。
Access Control: USER-NODE-MATCH. Note that this matches the SIP AOR against the rfc822Name in the X.509 v3 certificate. The rfc822Name does not include the scheme so that the "sip:" prefix needs to be removed from the SIP AOR before matching. Escaped characters ('%' encoding) in the SIP AOR also need to be decoded prior to matching (see [RFC3986]).
アクセス制御：USER-NODE-MATCH。これは、X.509 v3証明書のrfc822Nameに対してSIP AORを照合することに注意してください。 rfc822Nameにはスキームが含まれていないため、「sip：」プレフィックスを照合前にSIP AORから削除する必要があります。 SIP AORのエスケープ文字（ '％'エンコード）も、マッチングの前にデコードする必要があります（[RFC3986]を参照）。
Data stored under the SIP-REGISTRATION Kind is of type SipRegistration, containing one of two data types:
SIP-REGISTRATION Kindの下に格納されているデータは、SipRegistrationタイプであり、次の2つのデータタイプのいずれかを含みます。
sip_registration_uri
しｐ＿れぎｓｔらちおん＿うり
A URI that the user can be reached at.
ユーザーが到達できるURI。
sip_registration_route
sip_registration_route
A destination list that can be used to reach the user's Peer.
ユーザーのピアに到達するために使用できる宛先リスト。
This Usage for RELOAD does not define new protocol elements or operations. Hence, no new threats arrive from message exchanges in RELOAD.
このRELOADの使用法では、新しいプロトコル要素や操作は定義されていません。したがって、RELOADのメッセージ交換から新しい脅威が到着することはありません。
This document introduces an AOR domain restriction function that must be compared against the registration attempt by the Storing Peer. A misconfigured or malicious Peer could cause frequent rejects of illegitimate storing requests. However, domain name control relies on a lightweight pattern matching and can be processed prior to validating certificates. Hence, no extra burden is introduced for RELOAD peers beyond loads already present in the base protocol.
このドキュメントでは、Storing Peerによる登録試行と比較する必要があるAORドメイン制限機能を紹介します。誤って設定された、または悪意のあるピアは、不正な保存要求を頻繁に拒否する可能性があります。ただし、ドメイン名制御は軽量のパターンマッチングに依存しており、証明書を検証する前に処理できます。したがって、基本プロトコルにすでに存在する負荷以外に、RELOADピアに余計な負担がかかることはありません。
Because SIP includes a forking capability (the ability to retarget to multiple recipients), fork bombs (i.e., attacks using SIP forking to amplify the effect on the intended victims) are a potential DoS concern. However, in the SIP Usage of RELOAD, fork bombs are a much lower concern than in a conventional SIP Proxy infrastructure, because the calling party is involved in each retargeting event. It can therefore directly measure the number of forks and throttle at some reasonable number.
SIPにはフォーキング機能（複数の受信者をリターゲットする機能）が含まれているため、フォーク爆弾（つまり、SIPフォークを使用した攻撃が対象の被害者への影響を増幅する）は、潜在的なDoSの懸念事項です。ただし、RELOADのSIPの使用では、発呼者が各再ターゲットイベントに関与するため、フォーク爆弾は従来のSIPプロキシインフラストラクチャよりもはるかに低い懸念事項です。したがって、フォークの数を直接測定し、適切な数でスロットルすることができます。
To launch a DoS attack, the owner of a popular AOR could retarget all calls to the victim. This attack is common to SIP and is difficult to ameliorate without requiring the target of a SIP registration to authorize all stores. The overhead of that requirement would be excessive and, in addition, there are good use cases for retargeting to a Peer without its explicit cooperation.
DoS攻撃を開始するために、人気のあるAORの所有者は、被害者へのすべての通話をリターゲットできます。この攻撃はSIPに共通であり、SIP登録のターゲットがすべてのストアを承認することを要求せずに改善することは困難です。その要件のオーバーヘッドは過度になり、さらに、明示的な協力なしにピアに再ターゲットするための良いユースケースがあります。
A RELOAD overlay and enrollment service that liberally accepts registrations for AORs of domain names unrelated to the overlay instance and without further authorization could store presence state for AORs without the consent of the owner of the AOR. An attacker could hijack names, register a bogus presence, and attract calls dedicated to a victim that resides within or outside the Overlay Instance.
オーバーレイインスタンスに関係のないドメイン名のAORの登録を自由に受け入れるRELOADオーバーレイおよび登録サービスは、それ以上の承認なしに、AORの所有者の同意なしにAORのプレゼンス状態を保存できます。攻撃者は名前を乗っ取り、偽のプレゼンスを登録し、オーバーレイインスタンスの内部または外部に存在する被害者への専用の呼び出しを誘引する可能性があります。
A hijacking of AORs can be mitigated by restricting the name spaces admissible in the Overlay Instance, or by additional verification actions of the enrollment service. To prevent an (exclusive) routing to a bogus registration, a caller can in addition query the DNS (or other discovery services at hand), search for an alternative presence of the callee in another overlay or a SIP infrastructure using [RFC3263] for name resolution.
AORのハイジャックは、オーバーレイインスタンスで許可される名前空間を制限するか、登録サービスの追加の検証アクションによって軽減できます。偽の登録への（排他的な）ルーティングを防ぐために、発信者はさらにDNS（または手元にある他のディスカバリーサービス）をクエリし、名前に[RFC3263]を使用して、別のオーバーレイまたはSIPインフラストラクチャで着信者の代替の存在を検索できます。解決。
All RELOAD SIP registration data is visible to all nodes in the overlay. Location privacy can be gained from using anonymous GRUUs. Methods of providing anonymity or deploying pseudonyms exist, but are beyond the scope of this document.
すべてのRELOAD SIP登録データは、オーバーレイのすべてのノードに表示されます。位置情報のプライバシーは、匿名のGRUUを使用することで得られます。匿名性を提供する方法または仮名を展開する方法は存在しますが、このドキュメントの範囲を超えています。
IANA has registered the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION Kind, as described in Section 7.
セクション7で説明されているように、IANAは「RELOAD Data Kind-ID」レジストリ（cf.、[RFC6940]）に次のコードポイントを登録して、SIP-REGISTRATION Kindを表します。
+---------------------+------------+-----------+
| Kind | Kind-ID | Reference |
+---------------------+------------+-----------+
| SIP-REGISTRATION | 0x1 | RFC 7904 |
+---------------------+------------+-----------+
This document registers the following URI for the config XML namespace in the IETF XML registry defined in [RFC3688]:
このドキュメントは、[RFC3688]で定義されているIETF XMLレジストリのconfig XML名前空間に次のURIを登録します。
URI: urn:ietf:params:xml:ns:p2p:config-base:sip
Registrant Contact: The IESG
登録者の連絡先：IESG
XML: N/A; the requested URI is an XML namespace
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC6940] Jennings、C.、Lowekamp、B.、Ed。、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、RFC 6940、DOI 10.17487 / RFC6940 、2014年1月、<http://www.rfc-editor.org/info/rfc6940>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, DOI 10.17487/RFC2533, March 1999, <http://www.rfc-editor.org/info/rfc2533>.
[RFC2533] Klyne、G。、「A Feature for Describing Media Feature Sets」、RFC 2533、DOI 10.17487 / RFC2533、1999年3月、<http://www.rfc-editor.org/info/rfc2533>。
[RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, DOI 10.17487/RFC2738, December 1999, <http://www.rfc-editor.org/info/rfc2738>.
[RFC2738] Klyne、G。、「「メディア機能セットを記述するための構文」への修正」、RFC 2738、DOI 10.17487 / RFC2738、1999年12月、<http://www.rfc-editor.org/info/rfc2738> 。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）でのユーザーエージェント機能の表示」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<http：// www .rfc-editor.org / info / rfc3840>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <http://www.rfc-editor.org/info/rfc5626>.
[RFC5626] Jennings、C.、Ed。、Mahy、R.、Ed。、and F. Audet、Ed。、 "Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）"、RFC 5626、DOI 10.17487 / RFC5626 、2009年10月、<http://www.rfc-editor.org/info/rfc5626>。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.
[RFC5627] Rosenberg、J。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、DOI 10.17487 / RFC5627、2009年10月、<http：//www.rfc- editor.org/info/rfc5627>。
[IEEE-Posix] IEEE, "International Standard - Information technology Portable Operating System Interface (POSIX) Base Specifications, Issue 7", ISO/IEC/IEEE 9945:2009, DOI 10.1109/IEEESTD.2009.5393893, September 2009.
[IEEE-Posix] IEEE、「International Standard-Information technology Portable Operating System Interface（POSIX）Base Specifications、Issue 7」、ISO / IEC / IEEE 9945：2009、DOI 10.1109 / IEEESTD.2009.5393893、2009年9月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <http://www.rfc-editor.org/info/rfc3263>.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、DOI 10.17487 / RFC3263、2002年6月、<http://www.rfc-editor.org/info / rfc3263>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H.、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。
[RFC7890] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016, <http://www.rfc-editor.org/info/rfc7890>.
[RFC7890]ブライアン、D。、マシューズ、P。、シム、E。、ウィリス、D。、およびS.ドーキンス、「ピアツーピアSIP（P2PSIP）の概念と用語」、RFC 7890、DOI 10.17487 / RFC7890、2016年6月、<http://www.rfc-editor.org/info/rfc7890>。
[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, DOI 10.17487/RFC5767, April 2010, <http://www.rfc-editor.org/info/rfc5767>.
[RFC5767] Munakata、M.、Schubert、S。、およびT. Ohba、「SIPのユーザーエージェント駆動プライバシーメカニズム」、RFC 5767、DOI 10.17487 / RFC5767、2010年4月、<http：//www.rfc- editor.org/info/rfc5767>。
[SHARE] Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Usage for Shared Resources in RELOAD (ShaRe)", Work in Progress, draft-ietf-p2psip-share-08, March 2016.
[共有]クナウフ、A。、シュミット、T。、ヘーゲ、G。、およびM.ヴェーリッシュ、「A RELOAD（ShaRe）での共有リソースの使用法」、作業中、draft-ietf-p2psip-share-08、 2016年3月。
Non-peer-to-peer SIP defines third-party registration (e.g., an assistant acting for a manager or a changing set of users registering under a role-based AOR) in Section 10.2 of [RFC3261]. This is a REGISTER that uses the URI of the third party in its From header and cannot be translated directly into a P2PSIP registration because only the owner of the certificate can store a SIP-REGISTRATION in a RELOAD overlay.
非ピアツーピアSIPは、[RFC3261]のセクション10.2で、サードパーティの登録（例：マネージャーの代理を務めるアシスタント、またはロールベースのAORで登録する一連のユーザーの変更）を定義します。これは、FromヘッダーでサードパーティのURIを使用するREGISTERであり、証明書の所有者しかRELOADオーバーレイにSIP-REGISTRATIONを格納できないため、直接P2PSIP登録に変換できません。
Third-party registration can be implemented by using the extended access control mechanism USER-CHAIN-ACL defined in [SHARE]. Creating a new Kind "SIP-3P-REGISTRATION" that is ruled by USER-CHAIN-ACL allows the owner of the certificate to delegate the right for registration to individual third parties. This way, the SIP third-party registration functionality can be regained without weakening the security controls of RELOAD.
[SHARE]で定義されている拡張アクセス制御メカニズムUSER-CHAIN-ACLを使用して、サードパーティの登録を実装できます。 USER-CHAIN-ACLによって支配される新しい種類の「SIP-3P-REGISTRATION」を作成すると、証明書の所有者は、登録の権利を個々のサードパーティに委任できます。これにより、RELOADのセキュリティ制御を弱めることなく、SIPサードパーティの登録機能を回復できます。
Acknowledgments
謝辞
This document was generated in parts from initial drafts and discussions in the early specification phase of the P2PSIP base protocol. We gratefully acknowledge the significant contributions made by (in alphabetical order) David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan Rosenberg, and Marcia Zangrilli.
このドキュメントは、P2PSIP基本プロトコルの初期仕様フェーズでの初期のドラフトと議論から部分的に生成されました。 David A. Bryan、James Deverick、Marcin Matuszewski、Jonathan Rosenberg、Marcia Zangrilliの多大な貢献に感謝いたします。
Additional thanks go to all those who helped with ideas, discussions, and reviews, in particular (in alphabetical order) Roland Bless, Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral Shirazipour, and Matthias Waehlisch.
特に、アルファベット順で、アイデア、ディスカッション、レビューを手伝ってくれたすべての人に感謝します。RolandBless、Michael Chen、Alissa Cooper、Marc Petit-Huguenin、Brian Rosen、Meral Shirazipour、Matthias Waehlisch。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 United States of America Phone: +1 408 421-9990 Email: fluffy@cisco.com
カレンジェニングスCisco 170 West Tasman Drive MS：SJC-21 / 2 San Jose、CA 95134 United States of America電話：+1 408 421-9990メール：fluffy@cisco.com
Bruce B. Lowekamp Skype Palo Alto, CA United States of America Email: bbl@lowekamp.net
Bruce B. Lowekamp Skype Palo Alto、CAアメリカ合衆国メール：bbl@lowekamp.net
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 United States of America Phone: +1 650 678 2350 Email: ekr@rtfm.com
Eric Rescorla RTFM、Inc. 2064 Edgewood Drive Palo Alto、CA 94303 United States of America電話：+1 650 678 2350メール：ekr@rtfm.com
Salman A. Baset IBM T. J. Watson Research Center 1101 Kitchawan Road Yorktown Heights, NY 10598 United States of America Email: sabaset@us.ibm.com
Salman A. Baset IBM T. J. Watson Research Center 1101 Kitchawan Road Yorktown Heights、NY 10598 United States of Email Email：sabaset@us.ibm.com
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States of America Email: hgs@cs.columbia.edu
ヘニングシュルズリンネコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027アメリカ合衆国メール：hgs@cs.columbia.edu
Thomas C. Schmidt (editor) HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany Email: t.schmidt@haw-hamburg.de
Thomas C. Schmidt（編集者）HAW Hamburg Berliner Tor 7ハンブルク20099ドイツメール：t.schmidt@haw-hamburg.de