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
マルチメディアInterconnectのピアリングセッション（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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).
この文書は、マルチメディア相互接続（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.
「IPピアリングボイスオーバー」（VoIPのピアリング）は歴史的に、サービスプロバイダのネットワークの相互接続にし、セッション開始プロトコルの配信に関する慣行の幅広いを記述するために使用されている用語は、（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通話など）のセッションを識別して、ルートリアルタイム方法に焦点を当て、それが（必ずしも）パケット・ルーティングデータやメディアセッションの交換をカバーしていません。 IP層での配線とは対照的に、特に、「層5ネットワーク」は、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を参照）は、非音声または準ためインスタントメッセージングなどの-real時間通信。
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などの既存のIETF定義のプロトコルのビルディングブロックを活用ピアリングフレームワークを提供する[2]及びENUM [4]。 SPEERMINTワーキンググループピアリングにおけるこれらのプロトコルの使用を記載しているが、それはこれらのプロトコルは、セッション確立データ（SED）、またはこのデータがピアプロセスの間に使用された方法を作成するために必要な入力変数または出力変数を使用してどのように再定義しません。そのようなユニフォームリソース識別子（URIの）としてSEDおよびその主要変数に関する追加の詳細については、セクション3.3を参照してください[3]、E.164番号の電話番号[5]。 SPEERMINTワーキンググループは、電話番号の使用に限定されないが、例えば、E.164番号は、ENUMを使用して、E.164対URIマッピングでキーとして使用することができます。このマッピングは、権限ポインタ（NAPTR）DNSのレコード、およびSIP URIで結果を命名調べる必要とします。この情報を導出するためのプロセスは、すでに[4]で定義されているが、後続の呼ルーティングが基づくSPEERMINT SED、のためのビルディングブロックとして使用されます。コールルーティングステップは、E.164番号の存在に依存しないことに留意されたいです。確かに、ENUMクエリーの結果URIは、もはやでも任意のタイプの番号を含まなくてもよいです。具体的には、SIP URIは、ウェブページのような様々な他の方法で広告することができます。
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に）、同一性およびトポロジー隠蔽、およびドメインのセッションのアドミッションコントロールとしてシグナリング機能を提供します。
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の分解能に起因[1] DNSレコード（NAPTR、SRV、またはレコード）の様々な種類に由来する場所であるかもしれません。
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:
INVITEを送信するSIPプロキシまたは侵入SBEは、O、を含みます：
- 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.
この文書は、単一の管理ドメインに関連付けられており、いくつかのIP経路を介して到達できる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.
この文書では、以下に記載されるピアリング、層3ピアリング及び層5ピアリングの2種類を区別する。
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ペイロードに一般にとらわれないで、そしてしばしば[6]に必要なルーティング情報を交換するためにそのようなボーダーゲートウェイプロトコル（BGP）などのルーティングプロトコルを使用して達成されます。
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.
直接ピアリングは、二つのSSPは、介在層5ネットワークを使用することなく、ピアているような場合を記載しています。
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は、DBESとユーザエージェントとしての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の例は、[4]またはSIPピアの応答をリダイレクト提供SIPプロキシにINVITE要求をアップルックENUMあります。
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のいずれか一例にも適用することができます。 ENUM応答または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アドレス解決メカニズム（例えば、SIP URIに電話番号を解決するためのENUMを使用しなければならないすべてのピア）
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に関する詳細な議論から収集し、メーリングリストを飲みました。スコット・ブリム、ジョンエルウェル、マイク・ハマー、イーライ・カッツ、のGaurav Kulshreshtha、オトマールレンドル、ジェイソンLivingood、アレクサンダーMayrhofer、ジャン=フランソワラバ、ジョナサン・ローゼンバーグ、デビッド・シュワルツ、リチャードショッキー、ヘンリーSinnreich、リチャードStastny、ハンネスTschofenig、アダムUzelac、そしてダン・ウィングはすべて、このドキュメントの初期バージョンに貴重な貢献をしました。パトリック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のSRV）サービスの位置を特定するためのDNS RR"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[3] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。
[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.及び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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[8]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[9] Postel, J., "DoD standard Transmission Control Protocol", RFC 761, January 1980.
[9]ポステル、J.、 "国防総省標準伝送制御プロトコル"、RFC 761、1980年1月。
[10] ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) of voice frequencies.
音声周波数のパルス符号変調（PCM） - [10] ITU勧告G.711（88分の11）。
Authors' Addresses
著者のアドレス
Daryl Malas (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: d.malas@cablelabs.com
ダリル・マラス（エディタ）CableLabsの858コールクリークサークルルイビル、CO 80027 USA Eメール：d.malas@cablelabs.com
David Meyer (editor) EMail: dmm@1-4-5.net
デビッド・マイヤー（エディタ）メール：dmm@1-4-5.net