[要約] RFC 5486は、SPEERMINT（Session Peering for Multimedia Interconnect）用語の定義と目的を提供しています。このRFCは、SPEERMINTプロトコルの開発と実装に関与する人々にとって重要な情報源です。
Network Working Group D. Malas, Ed.
Request for Comments: 5486 CableLabs
Category: Informational D. Meyer, Ed.
March 2009
Session Peering for Multimedia Interconnect (SPEERMINT) Terminology
マルチメディアインターコネクト（Speermint）の用語のセッションピアリング
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).
Table of Contents
目次
1. Introduction ....................................................2
2. SPEERMINT Context ...............................................3
3. General Definitions .............................................4
3.1. Signaling Path Border Element ..............................4
3.2. Data Path Border Element ...................................4
3.3. Session Establishment Data .................................4
3.4. Call Routing ...............................................5
3.5. PSTN .......................................................5
3.6. IP Path ....................................................5
3.7. Peer Network ...............................................5
3.8. Service Provider ...........................................5
3.9. SIP Service Provider .......................................6
4. Peering .........................................................6
4.1. Layer 3 Peering ............................................6
4.2. Layer 5 Peering ............................................6
4.2.1. Direct Peering ......................................7
4.2.2. Indirect Peering ....................................7
4.2.3. On-Demand Peering ...................................7
4.2.4. Static Peering ......................................7
4.3. Functions ..................................................7
4.3.1. Signaling Function ..................................7
4.3.2. Media Function ......................................8
4.3.3. Look-Up Function ....................................8
4.3.4. Location Routing Function ...........................8
5. Federations .....................................................8
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. Informative References .........................................10
The term "Voice over IP Peering" (VoIP Peering) has historically been used to describe a wide variety of practices pertaining to the interconnection of service provider networks and to the delivery of Session Initiation Protocol (SIP [2]) call termination over those interconnections.
「Voice over IP Peering」（VoIP Peering）という用語は、サービスプロバイダーネットワークの相互接続とセッション開始プロトコル（SIP [2]）の配信に関するさまざまなプラクティスを説明するために歴史的に使用されてきました。。
The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to describe interconnection at different levels in a protocol stack. Session Peering for Multimedia Interconnect focuses on how to identify and route real-time sessions (such as VoIP calls) at the session layer, and it does not (necessarily) cover the exchange of packet-routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). The term "peering" will be used throughout the remainder of the document for the purpose of indicating a layer 5 interconnection.
これらの相互接続の議論は、「ピアリング」という用語がさまざまなコンテキストで使用され、プロトコルスタックの異なるレベルでの相互接続を記述するという事実によって時々混乱しています。マルチメディアインターコネクトのセッションピアリングは、セッションレイヤーでリアルタイムセッション（VoIPコールなど）を識別およびルーティングする方法に焦点を当てており、パケットルーティングデータまたはメディアセッションの交換を（必ずしも）カバーしていません。特に、「レイヤー5ネットワーク」は、IPレイヤーでの相互接続とは対照的に、SIPサーバー間の相互接続を参照するために使用されます（「レイヤー3」）。「ピアリング」という用語は、レイヤー5の相互接続を示す目的で、文書の残りの部分で使用されます。
This document introduces standard terminology for use in characterizing real-time session peering. Note however, that while this document is primarily targeted at the VoIP peering case, the terminology described here is applicable to those cases in which service providers peer using SIP signaling (defined as SIP Service Providers; see Section 3.9) for non-voice or quasi-real-time communications like instant messaging.
このドキュメントでは、リアルタイムセッションピアリングの特性評価に使用する標準用語を紹介します。ただし、このドキュメントは主にVoIPピアリングケースを対象としていますが、ここで説明する用語は、SIPシグナル伝達（SIPサービスプロバイダーとして定義されている、セクション3.9を参照）を使用してサービスプロバイダーがピアをピアに使用している場合に適用できることに注意してください。 - インスタントメッセージングのような現実の時間通信。
The remainder of this document is organized as follows: Section 2 provides the general context for the Session PEERing for Multimedia INTerconnect working group (SPEERMINT). Section 3 provides the general definitions for real-time, SIP-based communication, with initial focus on the VoIP peering case, and Section 4 defines the terminology describing the various forms of peering. Finally, Section 5 introduces the concept of federations.
このドキュメントの残りの部分は、次のように構成されています。セクション2は、マルチメディアインターコネクトワーキンググループ（Speermint）のセッションピアリングの一般的なコンテキストを提供します。セクション3では、VoIPピアリングケースに最初に焦点を当てたリアルタイムのSIPベースの通信の一般的な定義を説明し、セクション4では、さまざまな形式のピアリングを説明する用語を定義します。最後に、セクション5では、連合の概念を紹介します。
SPEERMINT provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP [2] and ENUM [4]. While the SPEERMINT working group describes the use of these protocols in peering, it does not redefine how these protocols use input or output variables necessary for creating Session Establishment Data (SED) or the methods in which this data will be used during the peering process. See Section 3.3 for additional detail on SED and its principal variables such as Uniform Resource Identifiers (URIs) [3] and telephone numbers of E.164 numbers [5]. For example, while the SPEERMINT working group is not limited to the use of telephone numbers, an E.164 number may be used as a key in an E.164-to-URI mapping using ENUM. This mapping involves looking up Naming Authority Pointer (NAPTR) records in the DNS, and results in a SIP URI. The process for deriving this information has already been defined in [4], but is used as a building block for SPEERMINT SED, on which the subsequent call routing is based. Note that the call-routing step does not depend on the presence of an E.164 number. Indeed, the URI resulting from an ENUM query may no longer even contain numbers of any type. In particular, the SIP URI can be advertised in various other ways, such as on a web page.
Speermintは、SIP [2]やEnum [4]などの既存のIETF定義プロトコルの構成要素を活用するピアリングフレームワークを提供します。Speermintワーキンググループは、これらのプロトコルの使用をピアリングに使用することを説明していますが、これらのプロトコルがセッション確立データの作成に必要な入力変数または出力変数（SED）またはピアリングプロセス中にこのデータが使用される方法を再定義することはありません。SEDおよび均一なリソース識別子（URIS）[3]やE.164番号[5]の電話番号などの主要な変数の追加の詳細については、セクション3.3を参照してください。たとえば、Speermintのワーキンググループは電話番号の使用に限定されませんが、E.164番号は、列挙を使用したE.164からURIへのマッピングのキーとして使用できます。このマッピングには、DNSの命名権限ポインター（NAPTR）レコードを検索し、SIP URIになります。この情報を導き出すプロセスは[4]ですでに定義されていますが、Speermint SEDの構成要素として使用されており、その後のコールルーティングの基礎となっています。コールルーティングステップは、E.164番号の存在に依存しないことに注意してください。実際、列挙クエリから生じるURIには、いかなるタイプの数も含まれていない場合があります。特に、SIP URIは、Webページなど、他のさまざまな方法で宣伝できます。
Finally, note that the term "call" is being used here in the most general sense, i.e., call routing and session routing are used interchangeably.
最後に、「呼び出し」という用語は、最も一般的な意味でここで使用されていることに注意してください。つまり、コールルーティングとセッションルーティングが同じ意味で使用されることに注意してください。
A signaling path border element (SBE) is located on the administrative border of a domain through which inter-domain session layer messages will flow. It typically provides signaling functions such as protocol inter-working (for example, H.323 to SIP), identity and topology hiding, and Session Admission Control for a domain.
信号パスの境界要素（SBE）は、ドメイン間セッションレイヤーメッセージが流れるドメインの管理境界にあります。通常、プロトコルの相互作用（たとえば、H.323からSIPへのH.323）、アイデンティティとトポロジの隠れ、およびドメインのセッション入場制御などのシグナル機能を提供します。
A data path border element (DBE) is located on the administrative border of a domain through which flows the media associated with an inter-domain session. It typically provides media-related functions such as deep packet inspection and modification, media relay, and firewall-traversal support. The DBE may be controlled by the SBE.
データパスの境界要素（DBE）は、ドメイン間セッションに関連するメディアが流れるドメインの管理境界にあります。通常、ディープパケットの検査と変更、メディアリレー、ファイアウォールトラバーサルサポートなどのメディア関連機能を提供します。DBEはSBEによって制御される場合があります。
Session Establishment Data, or SED, is the data used to route a call to the next hop associated with the called domain's ingress point. A domain's ingress point might, for example, be the location derived from various types of DNS records (NAPTR, SRV, or A record) [1] that resulted from the resolution of the SIP URI.
セッション確立データ（SED）は、呼び出されたドメインのイングレスポイントに関連付けられた次のホップへの呼び出しをルーティングするために使用されるデータです。ドメインの入り口は、たとえば、SIP URIの解像度から生じるさまざまなタイプのDNSレコード（NAPTR、SRV、またはレコード）[1]から派生した場所である場合があります。
More specifically, the SED is the set of parameters that the outgoing SBEs need to complete the call, and may include:
より具体的には、SEDは、発信SBEがコールを完了するために必要なパラメーターのセットであり、以下を含めることができます。
o A destination SIP URI
o 目的地のsip uri
o A SIP proxy or ingress SBE to send the INVITE to, including:
o 招待状を送信するためのSIPプロキシまたはイングレスSBEを含む：
- Fully Qualified Domain Name (FQDN)
- 完全資格のドメイン名（FQDN）
- Port
- ポート
- Transport Protocol (UDP [8], TCP [9], and TLS [7])
- 輸送プロトコル（UDP [8]、TCP [9]、およびTLS [7]）
o Security parameters, including:
o 以下を含むセキュリティパラメーター
- TLS certificate to use
- 使用するTLS証明書
- TLS certificate to expect
- 予想されるTLS証明書
- TLS certificate verification setting
- TLS証明書確認設定
o Optional resource control parameters such as:
o 次のようなオプションのリソース制御パラメーター
- Limits on the total number of call initiations to a peer
- ピアへの通話開始の総数の制限
- Limits on SIP transactions per second
- SIPトランザクションの制限あたり
Call routing is the set of processes and rules used to route a call and any subsequent mid-dialog SIP requests to their proper (SIP) destination. More generally, call routing can be thought of as the set of processes and rules that are used to route a real-time session to its termination point.
通話ルーティングは、コールをルーティングするために使用される一連のプロセスとルールと、その後のミッドダイアログSIPリクエストを適切な（SIP）宛先にルーティングするために使用されます。より一般的には、コールルーティングは、リアルタイムセッションを終了ポイントにルーティングするために使用されるプロセスとルールのセットと考えることができます。
The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected, circuit-switched, voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers; however, various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers.
「PSTN」という用語は、公開された電話ネットワークを指します。特に、PSTNは、商業および政府所有の両方で、相互接続された回路が切り替えられた音声指向の公衆電話ネットワークのコレクションを指します。一般に、PSTN端子はE.164番号を使用してアドレス指定されます。ただし、さまざまなダイヤルプラン（緊急サービスダイヤルプランなど）は、E.164番号を直接使用しない場合があります。
For the purposes of this document, an IP path is defined to be a sequence of zero or more IP router hops.
このドキュメントの目的のために、IPパスはゼロ以上のIPルーターホップのシーケンスであると定義されています。
This document defines a peer network as the set of SIP user agents (UAs) (customers) that are associated with a single administrative domain and can be reached via some IP path. Note that such a peer network may also contain end-users who are located on the PSTN (and hence may also be interconnected with the PSTN) as long as they are also reachable via some IP path.
このドキュメントでは、ピアネットワークをSIPユーザーエージェント（UAS）（顧客）のセットとして定義します。これは、単一の管理ドメインに関連付けられ、何らかのIPパスを介して到達できます。このようなピアネットワークには、PSTNに位置するエンドユーザーも含まれている可能性があることに注意してください（したがって、PSTNと相互接続されている可能性があります）。
A Service Provider (SP) is defined to be an entity that provides layer 3 (IP) transport of SIP signaling and media packets. Example services may include, but are not limited to, Ethernet Private Line (EPL), Frame Relay, and IP Virtual Private Network (VPN). An example of this may be an Internet Service Provider (ISP).
サービスプロバイダー（SP）は、SIPシグナリングとメディアパケットのレイヤー3（IP）輸送を提供するエンティティであると定義されています。サンプルサービスには、イーサネットプライベートライン（EPL）、フレームリレー、およびIP仮想プライベートネットワーク（VPN）が含まれますが、これらに限定されません。この例は、インターネットサービスプロバイダー（ISP）です。
A SIP Service Provider (SSP) is an entity that provides session services utilizing SIP signaling to its customers. In the event that the SSP is also a function of the SP, it may also provide media streams to its customers. Such an SSP may additionally be peered with other SSPs. An SSP may also interconnect with the PSTN. An SSP may also be referred to as an Internet Telephony Service Provider (ITSP). While the terms ITSP and SSP are frequently used interchangeably, this document and other subsequent SIP peering-related documents should use the term SSP. SSP more accurately depicts the use of SIP as the underlying layer 5 signaling protocol.
SIPサービスプロバイダー（SSP）は、SIPシグナリングを顧客に利用したセッションサービスを提供するエンティティです。SSPもSPの機能である場合、顧客にメディアストリームを提供することもあります。このようなSSPは、他のSSPでさらに覗き込んでいる可能性があります。SSPは、PSTNと相互接続することもできます。SSPは、インターネットテレフォニーサービスプロバイダー（ITSP）と呼ばれることもあります。ITSPとSSPという用語は頻繁に交換可能に使用されますが、このドキュメントやその後のSIPピアリング関連ドキュメントは、SSPという用語を使用する必要があります。SSPは、基礎となるレイヤー5シグナル伝達プロトコルとしてのSIPの使用をより正確に描写しています。
While the precise definition of the term "peering" is the subject of considerable debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers.
「ピアリング」という用語の正確な定義はかなりの議論の対象ですが、一般的には、オペレーションに独立したサービスプロバイダー間の和解相互接続の取り決めの交渉を指します。
This document distinguishes two types of peering, layer 3 peering and layer 5 peering, which are described below.
このドキュメントでは、以下に説明する2種類のピアリング、レイヤー3ピアリングとレイヤー5ピアリングを区別します。
Layer 3 peering refers to interconnection of two service providers' networks for the purposes of exchanging IP packets that are destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as the Border Gateway Protocol (BGP) [6] to exchange the required routing information.
レイヤー3ピアリングとは、ピアのネットワークの1つ（またはその両方）に運命づけられているIPパケットを交換する目的で、2つのサービスプロバイダーのネットワークの相互接続を指します。レイヤー3ピアリングは一般にIPペイロードに対して不可知論され、境界ゲートウェイプロトコル（BGP）[6]などのルーティングプロトコルを使用して、必要なルーティング情報を交換することが多いことがよくあります。
An alternate, perhaps more operational, definition of layer 3 peering is that two peers exchange only customer routes, and hence any traffic between peers terminates on one of the peers' networks or the peer's customer's network.
レイヤー3ピアリングの代替、おそらくより運用可能な定義は、2つのピアが顧客ルートのみを交換するため、ピア間のトラフィックがピアのネットワークまたはピアの顧客ネットワークで終了することです。
Layer 5 (session) peering refers to interconnection of two SSPs for the purposes of routing real-time (or quasi-real-time) call signaling between their respective customers using SIP methods. Such peering may be direct or indirect (see Section 4.2.1 and Section 4.2.2 below). Note that media streams associated with this signaling (if any) are not constrained to follow the same set of IP paths.
レイヤー5（セッション）ピアリングとは、SIPメソッドを使用して、それぞれの顧客間でリアルタイム（または準リアルタイム）コールシグナリングをルーティングする目的で、2つのSSPの相互接続を指します。このようなピアリングは、直接的または間接的である場合があります（以下のセクション4.2.1およびセクション4.2.2を参照）。このシグナル伝達に関連付けられたメディアストリーム（もしあれば）は、同じIPパスのセットに従うように制限されていないことに注意してください。
Direct peering describes those cases in which two SSPs peer without using an intervening layer 5 network.
Direct Peeringは、介入レイヤー5ネットワークを使用せずに2つのSSPSがピアをするケースを説明しています。
Indirect, or transit, peering refers to the establishment of either a signaling and media path or a signaling path alone via one (or more) layer 5 transit network(s). In this case, it is generally required that a trust relationship is established between the originating SSP and the transit SSP on one side, and between the transit SSP and the termination SSP on the other side.
間接、または輸送するピアリングとは、1つ（またはそれ以上）のレイヤー5トランジットネットワークを介して、信号およびメディアパスまたは信号パスのみの確立を指します。この場合、一般に、片側の発生SSPとトランジットSSPの間に、および反対側のトランジットSSPと終端SSPの間に信頼関係が確立されることが必要です。
SSPs are said to peer on-demand when they are able to exchange SIP traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains. Any information that needs to be exchanged between domains in support of peering can be learned through a dynamic protocol mechanism. On-demand peering can occur as direct or indirect.
SSPは、ドメイン間のリアルタイムトランザクション（SIPメッセージなど）のオリジネーションの前に、SIPトラフィックを事前協会なしで交換できる場合、オンデマンドをピアにすると言われています。ピアリングをサポートするためにドメイン間で交換する必要がある情報は、動的プロトコルメカニズムを介して学習できます。オンデマンドピアリングは、直接的または間接的に発生する可能性があります。
SSPs are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct or indirect. An example of static peering is a federation. Each of the peers within the federation must first agree on a common set of rules and guidelines for peering, thus pre-associating with each other prior to initiating session requests.
SSPは、リアルタイムトランザクション（SIPメッセージなど）の開始にはプロバイダー間の事前関連が必要な場合、静的にピアと言われています。静的ピアリングは、直接的または間接的に発生する可能性があります。静的ピアリングの例はフェデレーションです。連邦内の各ピアは、まず、共通のルールセットとピアリングのガイドラインに同意する必要があります。
The following are terms associated with the functions required for peering.
以下は、ピアリングに必要な機能に関連する用語です。
The Signaling Function (SF) performs routing of SIP requests for establishing and maintaining calls, and to assist in the discovery or exchange of parameters to be used by the Media Function (MF). The SF is a capability of SIP processing elements such as SIP proxies, SBEs, and user agents.
シグナリング関数（SF）は、呼び出しを確立および維持するためのSIP要求のルーティングを実行し、メディア関数（MF）で使用するパラメーターの発見または交換を支援します。SFは、SIPプロキシ、SBE、ユーザーエージェントなどのSIP処理要素の機能です。
The Media Function (MF) performs media-related functions such as media transcoding and media security implementation between two SSPs. The MF is a capability of SIP-session-associated media end-points such as DBEs and user agents.
メディア機能（MF）は、2つのSSP間のメディアトランスコーディングやメディアセキュリティの実装などのメディア関連機能を実行します。MFは、DBEやユーザーエージェントなどのSIPセッション関連メディアエンドポイントの機能です。
The Look-Up Function (LUF) determines for a given request the target domain to which the request should be routed. An example of an LUF is an ENUM [4] look-up or a SIP INVITE request to a SIP proxy providing redirect responses for peers.
ルックアップ関数（LUF）は、特定の要求に対して、要求をルーティングするターゲットドメインを決定します。LUFの例は、ピアのリダイレクト応答を提供するSIPプロキシへの列挙[4]ルックアップまたはSIP招待リクエストです。
In some cases, some entity (usually a 3rd party or federation) provides peering assistance to the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary.
場合によっては、一部のエンティティ（通常はサードパーティまたはフェデレーション）がこの機能を提供することにより、発生するSSPに覗き見を提供します。支援エンティティは、必要に応じて、直接（セクション4.2.1）または間接的な覗き見（セクション4.2.2）に関連する情報を提供する場合があります。
The Location Routing Function (LRF) determines for the target domain of a given request the location of the SF in that domain, and optionally develops other SED required to route the request to that domain. An example of the LRF may be applied to either example in Section 4.3.3. Once the ENUM response or SIP 302 redirect is received with the destination's SIP URI, the LRF must derive the destination peer's SF from the FQDN in the domain portion of the URI.
位置ルーティング関数（LRF）は、特定の要求のターゲットドメインを決定し、そのドメイン内のSFの位置を決定し、オプションで要求をそのドメインにルーティングするために必要な他のSEDを開発します。LRFの例は、セクション4.3.3のいずれの例にも適用できます。列挙の応答またはSIP 302リダイレクトが目的地のSIP URIで受信されると、LRFはURIのドメイン部分のFQDNから宛先ピアのSFを導出する必要があります。
In some cases, some entity (usually a 3rd party or federation) provides peering assistance to the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary.
場合によっては、一部のエンティティ（通常はサードパーティまたはフェデレーション）がこの機能を提供することにより、発生するSSPに覗き見を提供します。支援エンティティは、必要に応じて、直接（セクション4.2.1）または間接的な覗き見（セクション4.2.2）に関連する情報を提供する場合があります。
A federation is a group of SSPs that agree to exchange calls with each other via SIP and who agree on a set of administrative rules for such calls (settlement, abuse-handling, etc.) and specific rules for the technical details of the peering.
連邦は、SIPを介して互いに通話を交換することに同意し、そのようなコール（決済、虐待処理など）の一連の管理ルールとピアリングの技術的詳細に関する特定のルールに同意するSSPのグループです。
The following provides examples of rules that the peers of a federation may agree to and enforce upon all participants:
以下は、連邦のピアがすべての参加者に同意し、執行することができる規則の例を提供します。
o Common domain for all federation peers (e.g., bob@peer1.federation.example.com)
o すべてのフェデレーションピアの共通ドメイン（例：bob@peer1.federation.example.com）
o Codec rules (e.g., all peers must use the ITU-T G.711 codec [10])
o コーデックルール（たとえば、すべてのピアがITU-T G.711コーデック[10]を使用する必要があります）
o Authentication preference (e.g., all peers must use TLS when requesting to establish sessions with other peers)
o 認証の好み（たとえば、すべてのピアは、他のピアとのセッションを確立するように要求するときにTLSを使用する必要があります）
o Transport protocol (e.g., all peers must use TCP)
o 輸送プロトコル（例：すべてのピアがTCPを使用する必要があります）
o SIP address resolution mechanisms (e.g., all peers must use ENUM for resolving telephone numbers to SIP URIs)
o SIPアドレス解像度メカニズム（たとえば、すべてのピアは、URIをSIPするために電話番号を解決するために列挙を使用する必要があります）
Finally, note that an SSP can be a member of:
最後に、SSPは次のメンバーになることができることに注意してください。
- No federation (e.g., the SSP has only bilateral peering agreements)
- 連邦はありません（例えば、SSPには二国間ピアリング契約しかありません）
- A single federation
- 単一の連合
- Multiple federations
- 複数の連合
Also, an SSP can have any combination of bilateral and multilateral (i.e., federated) peers.
また、SSPは、二国間および多国間（つまり、フェデレート）ピアの任意の組み合わせを持つことができます。
This document introduces no new security considerations. However, it is important to note that session peering, as described in this document, has a wide variety of security issues that should be considered in documents addressing both protocol and use-case analysis.
このドキュメントでは、新しいセキュリティ上の考慮事項は紹介されていません。ただし、このドキュメントに記載されているように、セッションピアリングには、プロトコルとユースケース分析の両方に対処するドキュメントで考慮すべきさまざまなセキュリティ問題があることに注意することが重要です。
Many of the definitions were gleaned from detailed discussions on the SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, John Elwell, Mike Hammer, Eli Katz, Gaurav Kulshreshtha, Otmar Lendl, Jason Livingood, Alexander Mayrhofer, Jean-Francois Mule, Jonathan Rosenberg, David Schwartz, Richard Shockey, Henry Sinnreich, Richard Stastny, Hannes Tschofenig, Adam Uzelac, and Dan Wing all made valuable contributions to early versions of this document. Patrik Faltstrom also made many insightful comments to early versions of this document.
定義の多くは、Speermint、Enum、Sippe Mailingリストに関する詳細な議論から収集されました。スコット・ブリム、ジョン・エルウェル、マイク・ハンマー、エリ・カッツ、ガウラフ・クルシュレシュタ、オトマー・レンドル、ジェイソン・リビングウッド、アレクサンダー・マイロファー、ジャン・フランソワ・ルール、ジョナサン・ローゼンバーグ、デビッド・シュワルツ、リチャード・ショッキー、ヘンリー・シンリーッチ、リチャード・スタストゥニー、ハンナス・タスチェンそして、ダン・ウィングはすべて、このドキュメントの初期バージョンに貴重な貢献をしました。Patrik Faltstromは、このドキュメントの初期バージョンに対して多くの洞察に富んだコメントをしました。
[1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[1] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[2] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[3]
[4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[4] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[5] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, February 2005.
[5] 国際電気通信連合、「国際公開通信番号計画」、ITU-T勧告E.164、2005年2月。
[6] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[6] Rekhter、Y.、ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[7] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[8] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[9] Postel, J., "DoD standard Transmission Control Protocol", RFC 761, January 1980.
[9] Postel、J。、「DOD標準伝送制御プロトコル」、RFC 761、1980年1月。
[10] ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) of voice frequencies.
[10] ITU推奨G.711（11/88） - 音声周波数のパルスコード変調（PCM）。
Authors' Addresses
著者のアドレス
Daryl Malas (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: d.malas@cablelabs.com
Daryl Malas（編集者）CableLabs 858 Coal Creek Circle Louisville、Co 80027 USAメール：d.malas@cablelabs.com
David Meyer (editor) EMail: dmm@1-4-5.net
David Meyer（編集者）メール：dmm@1-4-5.net