Internet Engineering Task Force (IETF) J-F. Mule
Request for Comments: 6271 CableLabs
Category: Informational June 2011
ISSN: 2070-1721
Requirements for SIP-Based Session Peering
Abstract
抽象
This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions.
このメモは、音声、プレゼンス、インスタントメッセージング、およびマルチメディアトラフィックの他の種類のセッションピアリングを有効にするには、プロトコル要件をキャプチャします。この情報のドキュメントは、プロトコル・ソリューションへのピアリングセッションのために説明された様々なユースケースをリンクすることを意図しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6271.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6271で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. General Requirements ............................................3
3.1. Scope ......................................................4
3.2. Border Elements ............................................4
3.3. Session Establishment Data .................................8
3.3.1. User Identities and SIP URIs ........................8
3.3.2. URI Reachability ....................................9
4. Requirements for Session Peering of Presence and
Instant Messaging ..............................................10
5. Security Considerations ........................................12
5.1. Security Properties for the Acquisition of Session
Establishment Data ........................................12
5.2. Security Properties for the SIP Signaling Exchanges .......13
5.3. End-to-End Media Security .................................14
6. Acknowledgments ................................................15
7. References .....................................................15
7.1. Normative References ......................................15
7.2. Informative References ....................................15
Appendix A. Policy Parameters for Session Peering .................19
A.1. Categories of Parameters for VoIP Session Peering and
Justifications .............................................19
A.2. Summary of Parameters for Consideration in Session
Peering Policies ...........................................22
Peering at the session level represents an agreement between parties to exchange multimedia traffic. In this document, we assume that the Session Initiation Protocol (SIP) is used to establish sessions between SIP Service Providers (SSPs). SIP Service Providers are referred to as peers, and they are typically represented by users, user groups, enterprises, real-time collaboration service communities, or other service providers offering voice or multimedia services using SIP.
セッション・レベルでのピアリングは、マルチメディアトラフィックを交換するために、当事者間の合意を表しています。この文書では、我々は、セッション開始プロトコル（SIP）はSIPサービスプロバイダ（SSP）間のセッションを確立するために使用されていることを前提としています。 SIPサービスプロバイダは、ピアと呼ばれ、それらは通常、ユーザー、ユーザーグループ、企業、リアルタイムコラボレーションサービスのコミュニティ、またはSIPを使用して、音声やマルチメディアサービスを提供する他のサービスプロバイダーで表現されています。
A number of documents have been developed to provide background information about SIP session peering. It is expected that the reader is familiar with the reference architecture described in [ARCHITECTURE], use cases for voice ([VOIP]), and instant messaging and presence ([RFC5344]).
文書の数は、SIPセッションピアリングについての背景情報を提供するために開発されました。音声（[VOIP]）、及びインスタントメッセージングとプレゼンス（[RFC5344]）のためのユースケースは、読者が[ARCHITECTURE]に記載の参照アーキテクチャに精通していることが予想されます。
Peering at the session layer can be achieved on a bilateral basis (direct peering established directly between two SSPs), or on an indirect basis via a session intermediary (indirect peering via a third-party SSP that has a trust relationship with the SSPs) -- see the terminology document [RFC5486] for more details.
（直接ピアリングは、2つのSSPの間で直接確立された）両側に基づいて達成することができ、セッション層でピアリング、または間接的に基づいて、セッション仲介（のSSPとの信頼関係を持っているサードパーティのSSPを介した間接的なピアリング）を介して - - 詳細については、用語の文書[RFC5486]を参照してください。
This document first describes general requirements. The use cases are then analyzed in the spirit of extracting relevant protocol requirements that must be met to accomplish the use cases. These requirements are intended to be independent of the type of media exchanged such as Voice over IP (VoIP), video telephony, and instant messaging (IM). Requirements specific to presence and instant messaging are defined in Section 4.
この文書では、最初の一般的な要件について説明します。ユースケースは、その後の使用例を達成するために満たされなければならない、関連するプロトコル要件を抽出するの精神で分析されています。これらの要件は、メディアの種類に依存しないように意図されているようにボイスオーバーIP（VoIP）の、ビデオテレフォニー、およびインスタントメッセージング（IM）と交換しました。プレゼンスとインスタントメッセージングに固有の要件は、第4節で定義されています。
It is not the goal of this document to mandate any particular use of IETF protocols other than SIP by SIP Service Providers in order to establish session peering. Instead, the document highlights what requirements should be met and what protocols might be used to define the solution space.
セッションのピアリングを確立するために、SIPサービスプロバイダによってSIP以外のIETFプロトコルのいずれかの特定の使用を強制するには、このドキュメントの目的ではありません。代わりに、文書は要件が満たされるべきで、何のプロトコルは、解空間を定義するために使用されるかもしれないものを強調しています。
Finally, we conclude with a list of parameters for the definition of a session peering policy, provided in an informative appendix. It should be considered as an example of the information SIP Service Providers may have to discuss or agree on to exchange SIP traffic.
最後に、我々は有益な付録で提供されるポリシーを、ピアリングセッションを定義するためのパラメータのリストと結論付けています。議論したりSIPトラフィックを交換することに同意する必要があり、情報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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document also reuses the terminology defined in [RFC5486].
この文書はまた、[RFC5486]で定義された用語を再利用します。
It is assumed that the reader is familiar with the Session Description Protocol (SDP) [RFC4566] and the Session Initiation Protocol (SIP) [RFC3261]. Finally, when used with capital letters, the term 'Authentication Service' is to be understood as defined by SIP Identity [RFC4474].
読者がセッション記述プロトコル（SDP）[RFC4566]及びセッション開始プロトコル（SIP）[RFC3261]に精通しているものとします。大文字で使用される場合、最終的に、用語「認証サービスは、」SIPアイデンティティ[RFC4474]で定義されるように理解されるべきです。
The following sub-sections contain general requirements applicable to multiple use cases for multimedia session peering.
以下のサブセクションでは、マルチメディアセッションのピアリングのための複数のユースケースに適用される一般的な要件が含まれています。
The primary focus of this document is on the requirements applicable to the boundaries of Layer 5 SIP networks: SIP entities, signaling path border elements (SBEs), and the associated protocol requirements for the look-up and location routing of the session establishment data. The requirements applicable to SIP User Agents or related to the provisioning of the session data are considered out of scope.
SIPエンティティ、パスの境界要素（残りのSBEの）シグナリング、セッション確立データのルックアップおよび位置ルーティングのための関連するプロトコル要件：この文書の主な焦点は、レイヤ5つのSIPネットワークの境界に適用される要件です。 SIPユーザエージェントに適用されるか、セッションデータのプロビジョニングに関連する要件は適用範囲外と考えられています。
SIP Service Providers have to reach an agreement on numerous points when establishing session peering relationships.
SIPサービスプロバイダは、セッションピアリング関係を確立するときに、多数の点で合意に達することがあります。
This document highlights only certain aspects of a session peering agreement. It describes the requirements relevant to protocols in four areas: the declaration, advertisement and management of ingress and egress border elements for session signaling and media (Section 3.2), the information exchange related to the Session Establishment Data (SED, Section 3.3), specific requirements for presence and instant message (Section 4), and the security properties that may be desirable to secure session exchanges (Section 5).
この文書では、セッションピアリング契約の唯一の特定の側面を強調しています。 、特定のセッションシグナリングとメディア（3.2節）、セッション確立データに関連する情報交換（SED、3.3節）のための入力および出力境界要素の宣言、広告と管理：それは、以下の4つの領域でのプロトコルに関連する要件について説明しますプレゼンスおよびインスタントメッセージ（第4）の要件、およびセッション交換（セクション5）を確保することが望ましいかもしれないセキュリティプロパティ。
Numerous other considerations of session peering arrangements are critical to reach a successful agreement, but they are considered out of scope of this document. They include information about SIP protocol support (e.g., SIP extensions and field conventions), media (e.g., type of media traffic to be exchanged, compatible media codecs and transport protocols, mechanisms to ensure differentiated quality of service for media), Layer 3 IP connectivity between the signaling and data path border elements, and accounting and traffic capacity control (e.g., the maximum number of SIP sessions at each ingress point, or the maximum number of concurrent IM or VoIP sessions).
セッションピアリングアレンジメントの多数の他の考慮事項が成功した合意に達することが不可欠であるが、それらはこの文書の範囲外と考えられています。彼らは、レイヤ3のIP（メディアのためのサービスの差別化品質を保証するために、例えば、メディアトラフィックの種類を交換するための、互換性のあるメディアコーデックおよびトランスポートプロトコル、メカニズム）SIPプロトコルのサポート（例えば、SIPの拡張とフィールドの規則）、メディアに関する情報が含まれますシグナリングおよびデータパスの境界要素、およびアカウンティングおよびトラフィック容量制御との間の接続（例えば、各入口点におけるSIPセッションの最大数、または同時IMまたはVoIPセッションの最大数）。
The informative Appendix A lists parameters that may be considered when discussing the technical parameters of SIP session peering. The purpose of this list is to capture the parameters that are considered outside the scope of the protocol requirements.
有益な付録Aは、SIPセッションピアリングの技術的なパラメータを議論する際に考慮することができるパラメータを示します。このリストの目的は、プロトコル要件の範囲外と見なされるパラメータを捕獲することです。
For border elements to be operationally manageable, maximum flexibility should be given for how they are declared or dynamically advertised. Indeed, in any session peering environment, there is a need for a SIP Service Provider to declare or dynamically advertise the SIP entities that will face the peer's network. The data path border elements are typically signaled dynamically in the session description.
境界要素が運用管理しやすいものにするため、最大限の柔軟性は、彼らが宣言された、または動的に宣伝されている方法のために与えられるべきです。確かに、任意のセッションピアリング環境の中で、宣言するか、動的ピアのネットワークに直面するSIPエンティティを宣伝するためにSIPサービスプロバイダの必要性があります。データパスの境界要素は、典型的には、セッション記述に動的にシグナリングされます。
The use cases defined in [VOIP] catalog the various border elements between SIP Service Providers; they include signaling path border elements (SBEs) and SIP proxies (or any SIP entity at the boundary of the Layer 5 network).
【VOIP]で定義されたユースケースは、SIPサービスプロバイダの間の様々な境界要素をカタログ。彼らは、シグナリング経路の境界要素（残りのSBE）とSIPプロキシ（またはレイヤ5のネットワークの境界で任意のSIPエンティティ）が挙げられます。
o Requirement #1:
O要件＃1：
Protocol mechanisms MUST be provided to enable a SIP Service Provider to communicate the ingress signaling path border elements of its service domain.
プロトコルメカニズムは、そのサービスドメインの入口シグナリング経路の境界要素を通信するSIPサービスプロバイダを可能にするために提供されなければなりません。
Notes on solution space:
解空間上の注意：
The SBEs may be advertised to session peers using static mechanisms, or they may be dynamically advertised. There is general agreement that [RFC3263] provides a solution for dynamically advertising ingress SBEs in most cases of direct or indirect peering. We discuss the DNS-based solution space further in Requirement #4 below, especially in cases where the DNS response varies based on who sends the query (peer-dependent SBEs).
残りのSBEは、静的メカニズムを使用してセッションピアにアドバタイズすることができる、またはそれらは、動的に広告されてもよいです。 [RFC3263]は動的に直接または間接的なピアリングのほとんどの場合、入口のSBEを宣伝するためのソリューションを提供し、一般的な合意があります。我々は、特にDNS応答がクエリ（ピア依存残りのSBEの）送信者によって異なります例では、以下の要件＃4でさらにDNSベースの解空間を議論します。
o Requirement #2:
O要件＃2：
Protocol mechanisms MUST be provided to enable a SIP Service Provider to communicate the egress SBEs of its service domain.
プロトコルメカニズムは、サービスドメインの出口残りのSBEの通信にSIPサービスプロバイダを可能にするために提供されなければなりません。
Notes on motivations for this requirement:
この要件のための動機上の注意：
For the purposes of capacity planning, traffic engineering, and call admission control, a SIP Service Provider may be asked from where it will generate SIP calls. The SSP accepting calls from a peer may wish to know from where SIP calls will originate (this information is typically used by the terminating SSP).
キャパシティプランニング、トラフィックエンジニアリング、およびコールアドミッション制御の目的のために、SIPサービスプロバイダは、それがSIPコールを生成する場所から求められることがあります。ピアからSSP受付コールは（この情報は、典型的には、終端SSPによって使用される）SIPコールが発信される場所から知ることを望むかもしれません。
While provisioning requirements are out of scope, some SSPs may find use for a mechanism to dynamically advertise or discover the egress SBEs of a peer.
プロビジョニング要件は適用範囲外であるが、一部のSSPは、動的に広告を掲載またはピアの出口のSBEを発見するためのメカニズムのための用途を見出すことができます。
If the SSP also provides media streams to its users as shown in the use cases for "originating" and "terminating" SSPs, a mechanism must exist to allow SSPs to advertise their egress and ingress data path border elements (DBEs), if applicable. While some SSPs may have open policies and accept media traffic from anywhere outside their network to anywhere inside their network, some SSPs may want to optimize media delivery and identify media paths between peers prior to traffic being sent (Layer 5 to Layer 3 Quality of Service (QoS) mapping).
「発信」とのSSPを「終了」のユースケースに示すように、SSPは、そのユーザにメディアストリームを提供する場合、機構は、該当する場合のSSPは、それらの出入りのデータパスの境界要素（DBES）を宣伝することを可能にするために存在しなければなりません。いくつかのSSPがオープンポリシーを持っているし、どこからでも自分のネットワークの内部に自分のネットワーク外のどこからでもメディアトラフィックを受け入れるかもしれないが、いくつかのSSPは、メディア配信を最適化し、トラフィックの前にピア間のメディアパスを特定することができますサービスのレイヤ3の品質に（レイヤ5を送られています（QoS）のマッピング）。
o Requirement #3:
O要件＃3：
Protocol mechanisms MUST be provided to allow a SIP Service Provider to communicate its DBEs to its peers.
プロトコルメカニズムは、SIPサービスプロバイダがそのピアにそのDBESを通信することを可能にするために提供されなければなりません。
Notes: Some SSPs engaged in SIP interconnects do exchange this type of DBE information in a static manner. Some SSPs do not.
注：一部のSSPは、静的な方法で、DBEのこのタイプの情報を交換しないSIP相互接続に従事しました。いくつかのSSPにはありません。
In some SIP networks, SSPs may expose the same border elements to all peers. In other environments, it is common for SSPs to advertise specific SBEs and DBEs to certain peers. This is done by SSPs to meet specific objectives for a given peer: routing optimization of the signaling and media exchanges, optimization of the latency or throughput based on the 'best' SBE and DBE combination, and other service provider policy parameters. These are some of the reasons why advertisement of SBEs and DBEs may be peer dependent.
いくつかのSIPネットワークでは、SSPがすべてのピアに同じ境界要素を露出させることができます。 SSPのは、特定のピアに特定のSBEとDBESを宣伝するために他の環境では、それが一般的です。シグナリングおよびメディア交換の経路最適化、「最良の」SBEおよびDBEの組み合わせ、及び他のサービスプロバイダーのポリシーパラメータに基づいて、待ち時間やスループットの最適化：これは、所与のピアのための特定の目標を達成するためのSSPによって行われます。これらは、残りのSBEとDBESの広告は、ピア依存する可能性がある理由の一部です。
o Requirement #4:
Oの必要条件＃4：
The mechanisms recommended for the declaration or advertisement of SBE and DBE entities MUST allow for peer variability.
SBEとDBEエンティティの宣言や広告にお勧めのメカニズムは、ピアの変動を考慮しなければなりません。
Notes on solution space:
解空間上の注意：
A simple solution is to advertise SBE entities using DNS and [RFC3263] by providing different DNS names to different peers. This approach has some practical limitations because the SIP URIs containing the DNS names used to resolve the SBEs may be propagated by users, for example, in the form of sip:user@domain. It is impractical to ask users to implement different target URIs based upon their SIP Service Provider's desire to receive incoming session signaling at different ingress SBEs based upon the originator. The solution described in [RFC3263] and based on DNS to advertise SBEs is therefore under specified for this requirement.
簡単な解決策は、別のピアに異なるDNS名を提供することにより、DNSおよび[RFC3263]を使用して、SBEエンティティを宣伝することです。ユーザー@ドメイン：残りのSBEを解決するために使用するDNS名を含むSIP URIはSIPの形で、例えば、ユーザによって増殖させることができるので、このアプローチは、いくつかの実用的な制限があります。発信に基づいて異なる入口のSBEで、着信セッションシグナリングを受信するために彼らのSIPサービスプロバイダの要望に基づいて異なるターゲットURIを実装するために、ユーザーに依頼することは非現実的です。溶液[RFC3263]に記載され、残りのSBEのアドバタイズするDNSに基づいて、この要求に指定された下ことです。
Other DNS mechanisms have been used extensively in other areas of the Internet, in particular in Content Distribution Internetworking to make the DNS responses vary based on the originator of the DNS query (see [RFC3466], [RFC3568], and [RFC3570]). The applicability of such solutions for session peering needs further analysis.
他のDNSの仕組みは、DNS応答は（[RFC3466]、[RFC3568]、および[RFC3570]を参照）DNSクエリーの発信元によって異なり作るためにコンテンツ配信インターネットワーキングでは特に、インターネットの他の分野で広く使用されてきました。セッションピアリングのため、このようなソリューションの適用は、さらなる分析が必要です。
Finally, other techniques such as Anycast services ([RFC4786]) may be employed at lower layers than Layer 5 to provide a solution to this requirement. For example, anycast nodes could be defined by SIP service providers to expose a common address for SBEs into DNS, allowing the resolution of the anycast node address to the appropriate peer-dependent service address based on the routing topology or other criteria gathered from the combined use of anycast and DNS techniques.
最後に、このようなエニーキャストサービス（[RFC4786]）のような他の技術は、この要件に対する解決策を提供するために、レイヤ5より低い層で使用することができます。例えば、エニーキャストノードを合わせから収集ルーティングトポロジまたは他の基準に基づいて、適切なピア依存サービスアドレスにエニーキャスト・ノード・アドレスの解決を可能にする、DNSに残りのSBEのための共通アドレスを露出させるためにSIPサービスプロバイダによって定義することができますエニーキャストとDNS技術の使用。
Notes on variability of the SBE advertisements based on the media capabilities:
メディア機能に基づいてSBE広告の変動についての注意：
Some SSPs may have some restrictions on the type of media traffic their SBEs can accept. For SIP sessions however, it is not possible to communicate those restrictions in advance of the session initiation: a SIP target may support voice-only media, voice and video, or voice and instant messaging communications. While the inability to find out whether a particular type of SIP session can be terminated by a certain SBE can cause session attempts to fail, there is consensus to not add a new requirement in this document. These aspects are essentially covered by SSPs when discussing traffic exchange policies and are deemed out of scope of this document.
いくつかのSSPは、彼らのSBEが受け入れることのできるメディアトラフィックの種類にはいくつかの制限を有することができます。 SIPセッションの場合しかし、セッション開始の前に、これらの制約を通信することはできません：SIPのターゲットは、音声のみのメディア、音声、ビデオ、または音声およびインスタントメッセージング通信をサポートすることができます。 SIPセッションの特定のタイプは、特定のSBEで終了させることができるかどうかを調べることができないことは、セッションの試みが失敗する可能性がありますが、この文書の新しい要件を追加しないためのコンセンサスが存在します。トラフィック交換の方針を議論し、この文書の範囲外と判断されるとき、これらの態様は、本質的のSSPによって覆われています。
In the use cases provided as part of direct and indirect peering scenarios, an SSP deals with multiple SIP entities and multiple SBEs in its own domain. There is often a many-to-many relationship between the SIP proxies considered inside the trusted network boundary of the SSP and its signaling path border elements at the network boundaries.
直接的および間接的ピアリングシナリオの一部として提供されるユースケースでは、SSPは、複数のSIPエンティティと自身のドメイン内に複数のSBEを扱っています。信頼されたSSPのネットワーク境界とネットワークの境界でそのシグナリングパスの境界要素の内側と見なさSIPプロキシ間の多対多の関係がしばしばあります。
It should be possible for an SSP to define which egress SBE a SIP entity must use based on a given peer destination.
SSPは、SIPエンティティは、所与のピア宛先に基づいて使用しなければならないSBEを発信さを定義することが可能であるべきです。
For example, in the case of a static direct peering scenario (Figure 2 in Section 5.2. of [VOIP]), it should be possible for the SIP proxy in the originating network (O-Proxy) to select the appropriate egress SBE (O-SBE) to reach the SIP target based on the information the proxy receives from the Look-Up Function (O-LUF), and/or Location Routing Function (O-LRF) -- message response labeled (2). Note that this example also applies to the case of indirect peering when a service provider has multiple service areas and each service area involves multiple SIP proxies and a few SBEs.
例えば、静的直接ピアリングシナリオの場合には（セクション5.2の図2の[VOIP]）、それは（適切な出口SBEを選択するために、発信側ネットワーク（O-プロキシ）でSIPプロキシ可能であるべきであるO標識されたメッセージの応答（2） - プロキシがルックアップ機能（O-LUF）から受信した情報に基づいて、SIPターゲットに到達し、および/または位置ルーティング機能（O-LRF）する-SBE）。この例では、サービスプロバイダが複数のサービスエリアを有する間接ピアリングの場合に適用され、各サービスエリアは、複数のSIPプロキシ及び少数残りのSBEを含むことに留意されたいです。
o Requirement #5:
O要件＃5：
The mechanisms recommended for the Look-Up Function (LUF) and the Location Routing Functions (LRF) MUST be capable of returning both a target URI destination and a value providing the next SIP hop(s).
ルックアップ機能（LUF）及びロケーションルーティング機能（LRF）に推奨メカニズムは、ターゲットURI先と次のSIPホップ（複数可）を提供値の両方を返すことができなければなりません。
Notes: solutions may exist depending on the choice of the protocol used between the Proxy and its LUF/LRF. The idea is for the O-Proxy to be provided with the next SIP hop and the equivalent of one or more SIP Route header values. If ENUM is used as a protocol for the LUF, the solution space is undefined.
注：溶液がプロキシとLUF / LRFとの間に使用されるプロトコルの選択に依存して存在してもよいです。 O-Proxyは次のSIPホップおよび1つまたは複数のSIPルートヘッダ値と同等で提供するためのアイデアがあります。 ENUMはLUFのためのプロトコルとして使用される場合、解空間が定義されていません。
It is desirable for an SSP to be able to communicate how authentication of a peer's SBEs will occur (see the security requirements for more details).
SSPは、ピアの残りのSBEの認証が発生します（詳細については、セキュリティ要件を参照してください）する方法で通信できるようにすることが望ましいです。
o Requirement #6:
O要件＃6：
The mechanisms recommended for locating a peer's SBE MUST be able to convey how a peer should initiate secure session establishment.
ピアのSBEを配置するための推奨メカニズムは、ピアがセキュア・セッション確立を開始する方法を伝えることができなければなりません。
Notes: some mechanisms exist. For example, the required use of SIP over TLS may be discovered via [RFC3263], and guidelines concerning the use of the SIPS URI scheme in SIP have been documented in [RFC5630].
注：いくつかのメカニズムが存在します。例えば、TLS上のSIPの必要な使用は、[RFC3263]を介して発見することができ、SIPにSIPS URIスキームの使用に関するガイドラインは、[RFC5630]に記載されています。
The Session Establishment Data (SED) is defined in [RFC5486] as the data used to route a call to the next hop associated with the called domain's ingress point. The following paragraphs capture some general requirements on the SED data.
セッション確立データ（SED）は、ルートと呼ばれるドメインの入口ポイントに関連付けられている次のホップへのコールに使用されるデータとして、[RFC5486]で定義されています。次の段落では、SEDデータに関するいくつかの一般的な要件をキャプチャします。
User identities used between peers can be represented in many different formats. Session Establishment Data should rely on URIs (Uniform Resource Identifiers, [RFC3986]) and SIP URIs should be preferred over tel URIs ([RFC3966]) for session peering of VoIP traffic.
ピア間で使用されるユーザーIDは、多くの異なる形式で表現することができます。セッション確立データのURI（統一資源識別子、[RFC3986]）とSIP URIのに頼るべきでVoIPトラフィックのセッションピアリングのためのTEL URIを（[RFC3966]）よりも優先されなければなりません。
The use of DNS domain names and hostnames is recommended in SIP URIs and they should be resolvable on the public Internet. As for the user part of the SIP URIs, the mechanisms for session peering should not require an SSP to be aware of which individual user identities are valid within its peer's domain.
DNSドメイン名とホスト名の使用は、SIP URIの中で推奨されており、彼らは公共のインターネット上で解決する必要があります。 SIP URIのユーザー部分については、セッションピアリングのためのメカニズムは、個々の利用者識別情報が、そのピアのドメイン内で有効であるのに注意するSSPを必要とすべきではありません。
o Requirement #7:
O要件＃7：
The protocols used for session peering MUST accommodate the use of different types of URIs. URIs with the same domain-part SHOULD share the same set of peering policies; thus, the domain of the SIP URI may be used as the primary key to any information regarding the reachability of that SIP URI. The host part of SIP URIs SHOULD contain a fully qualified domain name instead of a numeric IPv4 or IPv6 address.
セッションピアリングに使用されるプロトコルは、URIの異なる種類の使用に対応しなければなりません。同じドメインの部分とのURIはピアリング政策の同じセットを共有する必要があります。従って、SIP URIのドメインは、SIPのURIの到達可能性に関するいかなる情報を主キーとして使用することができます。 SIP URIのホスト部分ではなく、数値のIPv4またはIPv6アドレスの完全修飾ドメイン名を含むべきです。
o Requirement #8:
O要件＃8：
The mechanisms for session peering should not require an SSP to be aware of which individual user identities are valid within its peer's domain.
セッションピアリングのためのメカニズムは、個々の利用者識別情報が、そのピアのドメイン内で有効であるのに注意するSSPを必要とすべきではありません。
o Notes on the solution space for Requirements #7 and #8:
要件＃7、＃8のための解空間上のO注意事項：
This is generally well supported by IETF protocols. When telephone numbers are in tel URIs, SIP requests cannot be routed in accordance with the traditional DNS resolution procedures standardized for SIP as indicated in [RFC3824]. This means that the solutions built for session peering must not solely use Public Switched Telephone Network (PSTN) identifiers such as Service Provider IDs (SPIDs) or Trunk Group IDs (they should not be precluded but solutions should not be limited to these).
これは、一般的によくIETFプロトコルによってサポートされています。電話番号は、TEL URIの中にあるとき、SIPリクエストは、[RFC3824]に示されるようにSIPのために標準化伝統的なDNS解決の手順に従ってルーティングすることができません。これは、単に公開を使用してはならないセッションピアリングのために構築されたソリューションは、（彼らは排除されるべきではなく、ソリューションはこれらに限定されるものではない）、このようなサービスプロバイダのID（SPIDの）またはトランクグループIDとして電話網（PSTN）の識別子を交換することを意味します。
Motivations:
動機：
Although SED data may be based on E.164-based SIP URIs for voice interconnects, a generic peering methodology should not rely on such E.164 numbers.
SEDのデータは、音声の相互接続のためのE.164ベースのSIP URIに基づいてすることができるが、一般的なピアリングの方法論は、このようなE.164番号に頼るべきではありません。
Based on a well-known URI type (e.g., sip:, pres:, or im: URIs), it must be possible to determine whether the SSP domain servicing the URI allows for session peering, and if it does, it should be possible to locate and retrieve the domain's policy and SBE entities.
よく知られたURIタイプ（例えば、SIP :, PRES :,またはIM：のURI）に基づいて、URIにサービスを提供するSSPドメインはセッションピアリングを可能にし、それがない場合は、それが可能にするかどうかを決定することが可能でなければなりませんドメインのポリシーとSBEエンティティを見つけて取得します。
For example, an originating service provider must be able to determine whether a SIP URI is open for direct interconnection without requiring an SBE to initiate a SIP request. Furthermore, since each call setup implies the execution of any proposed algorithm, the establishment of a SIP session via peering should incur minimal overhead and delay, and employ caching wherever possible to avoid extra protocol round trips.
例えば、元のサービスプロバイダは、SIP URIをSIP要求を開始するようにSBEを必要とせずに直接相互接続のための開かれているか否かを決定することができなければなりません。さらに、各コールセットアップは、任意の提案アルゴリズムの実行、追加のプロトコル・ラウンドトリップを避けるために、可能な限りキャッシュを最小限のオーバーヘッドと遅延が発生し、採用すべきピアリングを経由してSIPセッションの確立を意味するので。
o Requirement #9:
O要件＃9：
The mechanisms for session peering MUST allow an SBE to locate its peer SBE given a URI type and the target SSP domain name.
セッションピアリングのためのメカニズムは、SBEは、URIタイプとターゲットSSPドメイン名を指定されたピアSBEを探すことができなければなりません。
This section describes requirements for presence and instant messaging session peering.
このセクションでは、プレゼンスとインスタントメッセージングセッションピアリングのための要件について説明します。
Two SSPs create a peering relationship to enable their IM and presence users to collaborate with users on the other SSP network. We focus the requirements on inter-domain subscriptions to presence information, the exchange of messages and privacy settings, and the use of standard presence document formats across domains.
二つのSSPは、他のSSPネットワーク上のユーザーと協力して彼らのIMとプレゼンスのユーザーを有効にするには、ピアリング関係を作成します。私たちは、プレゼンス情報、メッセージやプライバシー設定の交換、およびドメイン間の標準的なプレゼンス文書フォーマットの使用にドメイン間のサブスクリプションの要件を集中します。
Several use cases for presence and instant messaging peering are described in [RFC5344], a document authored by A. Houri, E. Aoki, and S. Parameswar. Credits for the original content captured from these use cases into requirements in this section must go to them.
プレゼンスおよびインスタント・メッセージング・ピアリングのためのいくつかのユースケースは、[RFC5344]にA.フーリー、E.青木、及びS. Parameswar著文書に記載されています。このセクションの要件にこれらのユースケースから撮影したオリジナルコンテンツのためのクレジットはそれらに行かなければなりません。
o Requirement #10:
O要件＃10：
The mechanisms recommended for the exchange of presence information between SSPs SHOULD allow a user of one presence community to send a presence subscription request to presentities served by another SSP via its local community, including subscriptions to a single presentity, a personal, public or ad hoc group list of presentities.
SSPの間でプレゼンス情報の交換のために推奨されるメカニズムは、1つのプレゼンスコミュニティのユーザーは、単一プレゼンへのサブスクリプションを含め、その地域社会を介して他のSSPによって提供プレゼンに個人、公共またはアドホックをプレゼンスサブスクリプション要求を送信できるようにする必要がありますプレゼンのグループリスト。
Notes: see Sections 2.1 and 2.2 of [RFC5344].
注：[RFC5344]のセクション2.1および2.2を参照。
o Requirement #11:
O要件＃11：
The mechanisms recommended for instant messaging exchanges between SSPs SHOULD allow a user of one SSP's community to communicate with users of the other SSP community via their local community using the various methods. Note that some SSPs may exercise some control over which methods are allowed based on service policies. Such methods include sending a one-time IM message, initiating a SIP session for transporting sessions of messages, participating in n-way chats using chat rooms with users from the peer SSPs, etc.
SSPの間のインスタントメッセージ交換のために推奨されるメカニズムは、一つのSSPのコミュニティのユーザは、様々な方法を用いて、それらの地域を経由して他のSSPコミュニティのユーザと通信することを可能にすべきです。いくつかのSSPは、メソッドがサービスポリシーに基づいて許可される上で、いくつかのコントロールを行使することができることに注意してください。このような方法は、など、1回のIMメッセージを送信したメッセージのセッションを輸送するためのSIPセッションを開始し、ピアのSSPからのユーザーとチャットルームを使用してNウェイチャットに参加含めます
Notes: see Sections 2.4, 2.5, and 2.6 of [RFC5344].
注：セクション2.4、2.5を参照してください、そして、[RFC5344]の2.6。
o Requirement #12:
O要件＃12：
In some presence communities, users can define the list of watchers that receive presence notifications for a given presentity. Such privacy settings for watcher notifications per presentity are typically not shared across SSPs causing multiple notifications to be sent for one presentity change between SSPs.
いくつかのプレゼンスのコミュニティでは、ユーザーが指定したプレゼン用のプレゼンス通知を受け取るウォッチャーのリストを定義することができます。プレゼンあたりウォッチャー通知のようなプライバシー設定は、典型的には、SSPの間に1つのプレゼンティティの変更を送信する複数の通知を引き起こすのSSP間で共有されていません。
The sharing of those privacy settings per presentity between SSPs would allow fewer notifications: a single notification would be sent per presentity and the terminating SSP would send notifications to the appropriate watchers according to the presentity's privacy information.
SSPの間のプレゼンあたり、それらのプライバシー設定の共有は、少数の通知を可能にする：単一の通知は、プレゼンティティごとに送信されるだろうと終端SSPは、プレゼンティティのプライバシー情報に応じて適切なウォッチャーに通知を送信します。
The mechanisms recommended for presence information exchanges between SSPs SHOULD allow the sharing of some user privacy settings in order for users to convey the list of watchers that can receive notification of presence information changes on a per-presentity basis.
SSPの間でプレゼンス情報の交換のために推奨されるメカニズムは、ユーザーごとのプレゼン基づいてプレゼンス情報の変更の通知を受け取ることができウォッチャーのリストを伝えるために、一部のユーザーのプライバシー設定の共有を可能にしなければなりません。
The privacy sharing mechanism must be done with the express consent of the user whose privacy settings will be shared with the other community. Because of the privacy-sensitive information exchanged between SSPs, the protocols used for the exchange of presence information must follow the security recommendations defined in Section 6 of [RFC3863].
プライバシー共有するメカニズムは、プライバシー設定、他のコミュニティと共有するユーザーの明示的同意を得て行われなければなりません。ためのSSPとの間で交換プライバシーに敏感な情報を、プレゼンス情報の交換に使用されるプロトコルは、[RFC3863]のセクション6で定義されたセキュリティ勧告に従わなければなりません。
Notes: see Section 2.3 of [RFC5344].
注：[RFC5344]のセクション2.3を参照してください。
o Requirement #13:
O要件＃13：
It should be possible for an SSP to associate a presence document with a list of watchers in the peer SSP community so that the peer watchers can receive the presence document notifications. This will enable sending less presence document notifications between the communities while avoiding the need to share privacy information of presentities from one community to the other.
ピア・ウォッチャーは、プレゼンス文書通知を受け取ることができるようにSSPがピアSSPコミュニティのウォッチャーのリストに存在する文書を関連付けることが可能でなければなりません。これは、他の1つのコミュニティからのプレゼンのプライバシー情報を共有する必要性を回避しながら、地域社会とのより少ないプレゼンス文書通知を送信できるようになります。
The systems used to exchange presence documents between SSPs SHOULD allow a presence document to be delivered to one or more watchers.
SSPの間のプレゼンス文書を交換するために使用されるシステムは、プレゼンス文書は、1つまたは複数のウォッチャーに配信することを可能にするべきです。
Note: The presence document and the list of authorized watchers in the peer SSP may be sent separately. Also, the privacy-sharing mechanisms defined in Requirement #12 also apply to this requirement.
注：プレゼンス文書とピアSSPに許可ウォッチャーのリストを別々に送信することができます。また、要件＃12で定義されたプライバシー・共有の仕組みも、この要件に適用されます。
o Requirement #14:
O要件＃14：
Early deployments of SIP-based presence and instant messaging gateways have been done in front of legacy proprietary systems that use different naming schemes or name values for the elements and properties defined in a Presence Information Data Format (PIDF) document ([RFC3863]). For example, the value "Do Not Disturb" in one presence service may be mapped to "Busy" in another system for the status element. Beyond this example of status values, it is important to ensure that the meaning of the presence information is preserved between SSPs.
SIPベースのプレゼンスとインスタントメッセージングゲートウェイの初期の展開は、プレゼンス情報データフォーマット（PIDF）文書で定義された要素とプロパティ（[RFC3863]）のために異なる命名スキームや名前の値を使用するレガシー独自システムの前で行われています。例えば、1つのプレゼンスサービスに「着信拒否」の値は、ステータス要素のための別のシステムに「ビジー」にマッピングすることができます。ステータス値のこの例以外にも、プレゼンス情報の意味はSSPの間で保存されていることを確認することが重要です。
The systems used to exchange presence documents between SSPs SHOULD use standard PIDF documents and translate any non-standard value of a PIDF element to a standard one.
SSPの間のプレゼンス文書を交換するために使用されるシステムは、標準のPIDF文書を使用して、標準の1にPIDF要素のいずれかの非標準的な値を変換すべきです。
This section describes the security properties that are desirable for the protocol exchanges in scope of session peering. Three types of information flows are described in the architecture and use case documents: the acquisition of the Session Establishment Data (SED) based on a destination target via the Look-Up and Location Routing Functions (LUF and LRF), the SIP signaling between SIP Service Providers, and the associated media exchanges.
このセクションでは、セッション・ピアリングの範囲でプロトコル交換のために望ましいセキュリティプロパティを記述する。情報フローの3種類のアーキテクチャとユースケースの文献に記載されている：ルックアップと場所ルーティング機能（LUFとLRF）、SIP間のSIPシグナリングを介して宛先ターゲットに基づくセッション確立データ（SED）の買収サービスプロバイダ、および関連するメディアの交換。
This section is focused on three security services: authentication, data confidentiality, and data integrity as summarized in [RFC3365]. However, this text does not specify the mandatory-to-implement security mechanisms as required by [RFC3365]; this is left for future protocol solutions that meet the requirements.
[RFC3365]にまとめたように、認証、データの機密性、およびデータの整合性：このセクションでは、3つのセキュリティサービスに焦点を当てています。 [RFC3365]で必要に応じしかし、このテキストは強制的に実装セキュリティメカニズムを指定していません。これは、要件を満たし、将来のプロトコル・ソリューションのために残されています。
A security threat analysis provides additional guidance for session peering ([VOIPTHREATS]).
セキュリティ脅威分析は、セッションピアリング（[VOIPTHREATS]）のための追加的なガイダンスを提供します。
5.1. Security Properties for the Acquisition of Session Establishment Data
5.1. セッション確立データの取得のためのセキュリティプロパティ
The Look-Up Function (LUF) and Location Routing Function (LRF) are defined in [RFC5486]. They provide mechanisms for determining the SIP target address and domain the request should be sent to, and the associated SED to route the request to that domain.
ルックアップ機能（LUF）及び所在地ルーティング機能（LRF）は[RFC5486]で定義されています。彼らは、そのドメインにルーティングする要求を要求に送信されるべきSIPターゲットアドレスとドメインを決定するためのメカニズムを提供し、関連するSED。
o Requirement #15:
O要件＃15：
The protocols used to query the Look-Up and Location Routing Functions SHOULD support mutual authentication.
ルックアップと場所ルーティング機能を照会するために使用されるプロトコルは、相互認証をサポートする必要があります。
Motivations:
動機：
A mutual authentication service should be provided for the LUF and LRF protocol exchanges. The content of the response returned by the LUF and LRF may depend on the identity of the requestor: the authentication of the LUF and LRF requests is therefore a desirable property. Mutual authentication is also desirable: the requestor may verify the identity of the systems that provided the
相互認証サービスはLUFとLRFプロトコル交換のために提供されるべきです。 LUFとLRFにより返された応答の内容は、要求者のアイデンティティに依存してもよい：LUFとLRF要求の認証は、従って、望ましい特性です。相互認証も望ましい：リクエスタは、提供システムの身元を確認することができます
LUF and LRF responses given the nature of the data returned in those responses. Authentication also provides some protection for the availability of the LUF and LRF against attackers that would attempt to launch Denial-of-Service (DoS) attacks by sending bogus requests causing the LUF to perform a lookup and consume resources.
LUFとLRF応答は、これらの応答で返されたデータの性質を与えられました。認証はまた、LUFは、ルックアップを実行し、リソースを消費させる偽のリクエストを送信することにより、サービス拒否（DoS）攻撃を開始しようと攻撃者に対してLUFとLRFの可用性のためのいくつかの保護を提供します。
o Requirement #16:
O要件＃16：
The protocols used to query the Look-Up and Location Routing Functions SHOULD provide support for data confidentiality and integrity.
ルックアップと場所ルーティング機能を照会するために使用されるプロトコルは、データの機密性と整合性のためのサポートを提供する必要があります。
Motivations:
動機：
Given the sensitive nature of the session establishment data exchanged with the LUF and LRF functions, the protocol mechanisms chosen for the look-up and location routing should offer data confidentiality and integrity protection (SED data may contain user addresses, SIP URI, location of SIP entities at the boundaries of SIP Service Provider domains, etc.).
SIP URI、SIPの位置は、（SEDのデータは、ユーザーのアドレスが含まれていてもよいセッション確立データの機密性がLUFとLRFの機能と交換、ルックアップと場所ルーティング用に選択されたプロトコルメカニズムは、データの機密性と完全性の保護を提供する必要があります考えますSIPサービスプロバイダのドメインなど）の境界でエンティティ。
o Notes on the solution space for Requirements #15 and #16:
O要件のための解空間上の注意＃15と＃16：
ENUM, SIP, and proprietary protocols are typically used today for accessing these functions. Even though SSPs may use lower-layer security mechanisms to guarantee some of those security properties, candidate protocols for the LUF and LRF should meet the above requirements.
ENUM、SIP、および独自のプロトコルは、一般的に、これらの機能にアクセスするために今日使用されています。 SSPは、これらのセキュリティプロパティの一部を保証するために、下位層のセキュリティメカニズムを使用する場合でも、LUFとLRFのための候補プロトコルは、上記の要件を満たす必要があります。
The SIP signaling exchanges are out of scope of this document. This section describes some of the security properties that are desirable in the context of SIP interconnects between SSPs without formulating any normative requirements.
SIPシグナリング交換は、本文書の範囲外です。このセクションでは、任意の規範的要件を策定することなく、SSPの間のSIP相互接続のコンテキストで望ましいセキュリティ特性のいくつかを記載しています。
In general, the security properties desirable for the SIP exchanges in an inter-domain context apply to session peering. These include:
一般に、ドメイン間コンテキストにおけるSIP交換のために望ましいセキュリティプロパティは、セッションピアに適用されます。これらは、次のとおりです。
o securing the transport of SIP messages between the peers' SBEs. Authentication of SIP communications is desirable, especially in the context of session peering involving SIP intermediaries. Data confidentiality and integrity of the SIP message body may be desirable as well given some of the levels of session peering indirection (indirect/assisted peering), but they could be harmful as they may prevent intermediary SSPs from "inserting" SBEs/DBEs along the signaling and data paths.
ピアの残りのSBEの間でSIPメッセージの輸送を確保するO。 SIP通信の認証は、特にSIP仲介に関与ピアリングセッションのコンテキスト内で、望ましいです。 SIPメッセージボディのデータの機密性と完全性は、同様に間接（アシスト/間接ピアリング）のピアリングセッションのレベルの一部を望ましい与えられてもよいが、それらに沿って「挿入」残りのSBE / DBESから中間のSSPを防止することができるように、それらは有害であり得ますシグナリングおよびデータパス。
o providing an Authentication Service to authenticate the identity of connected users based on the SIP Service Provider domains (for both the SIP requests and the responses).
（SIP要求と応答の両方のための）SIPサービスプロバイダのドメインに基づいて接続しているユーザーの身元を認証する認証サービスを提供し、O。
The fundamental mechanisms for securing SIP between proxy servers intra- and inter-domain are applicable to session peering; refer to Section 26.2 of [RFC3261] for transport-layer security of SIP messages using TLS, [RFC5923] for establishing TLS connections between proxies, [RFC4474] for the protocol mechanisms to verify the identity of the senders of SIP requests in an inter-domain context, and [RFC4916] for verifying the identity of the sender of SIP responses).
セッションピアリングに適用可能である内およびドメイン間のプロキシサーバ間のSIPを固定するための基本的なメカニズム。相互にSIPリクエストの送信者の身元を確認するためにプロトコルメカニズムのために[RFC4474]、プロキシとの間でTLS接続を確立するためのTLS、[RFC5923]を使用して、SIPメッセージのトランスポート・レイヤ・セキュリティのために[RFC3261]のセクション26.2を参照してくださいドメインコンテキスト、およびSIP応答の送信者の身元を確認するための[RFC4916]）。
Media security is critical to guarantee end-to-end confidentiality of the communication between the end-users' devices, independently of how many direct or indirect peers are present along the signaling path. A number of desirable security properties emerge from this goal.
メディアセキュリティは、独立してシグナリングパスに沿って存在しているどのように多くの直接または間接的なピアの、エンドユーザーのデバイス間の通信のエンドツーエンドの機密性を保証することが重要です。望ましいセキュリティプロパティの数は、この目標から出てきます。
The establishment of media security may be achieved along the media path and not over the signaling path given the indirect peering use cases.
メディアセキュリティの確立が媒体経路に沿ってではなく、間接的ピアリングユースケース所与のシグナリング経路を介して達成することができます。
For example, media carried over the Real-Time Protocol (RTP) can be secured using secure RTP (SRTP [RFC3711]). A framework for establishing SRTP security using Datagram TLS (DTLS) [RFC4347] is described in [RFC5763]: it allows for end-to-end media security establishment using extensions to DTLS ([RFC5764]).
例えば、リアルタイムプロトコル（RTP）を介して搬送される媒体は、セキュアRTP（SRTP [RFC3711]）を使用して固定することができます。 [RFC5763]に記載されているデータグラムTLS（DTLS）[RFC4347]を使用して、SRTPセキュリティを確立するためのフレームワーク：それはDTLSへの拡張を使用して、エンド・ツー・エンドのメディアセキュリティ確立を可能にする（[RFC5764]）。
It should also be noted that media can be carried in numerous protocols other than RTP such as SIP (SIP MESSAGE method), MSRP (the Message Session Relay Protocol, [RFC4975], XMPP (the Extensible Messaging and Presence Protocol, [RFC6120]), and many others. Media may also be carried over TCP ([RFC4571]), and it can be encrypted over secure connection-oriented transport sessions over TLS ([RFC4572]).
また、メディアは、例えばSIP（SIPのMESSAGEメソッド）、MSRP（メッセージセッションリレープロトコル、[RFC4975]、XMPPとしてRTP以外の多数のプロトコルで行うことができることに留意すべきである（拡張メッセージングおよびプレゼンスプロトコル、[RFC6120]） 、および多くの他。メディアはまた、TCP（[RFC4571]）上で実行することができる、それがTLS上での安全な接続指向のトランスポートセッションを介して暗号化することができます（[RFC4572]）。
A desirable security property for session peering is for SIP entities to be transparent to the end-to-end media security negotiations: SIP entities should not intervene in the Session Description Protocol (SDP) exchanges for end-to-end media security.
SIPエンティティは、セッション記述プロトコル（SDP）のエンドツーエンドメディアのセキュリティのための交換に介入してはならない：SIPエンティティは、エンドツーエンドのメディアセキュリティ交渉に透明にするためにセッションピアリングにとって望ましいセキュリティ特性があります。
o Requirement #17:
O要件＃17：
The protocols used to enable session peering MUST NOT interfere with the exchanges of media security attributes in SDP. Media attribute lines that are not understood by SBEs MUST be ignored and passed along the signaling path untouched.
セッションピアリングを有効にするために使用されるプロトコルは、SDP内のメディアのセキュリティ属性の交換を妨害してはなりません。残りのSBEによって理解されていないメディア属性行は無視され、そのまま信号経路に沿って通過しなければなりません。
This document is based on the input and contributions made by a large number of people including: Bernard Aboba, Edwin Aoki, Scott Brim, John Elwell, Patrik Faltstrom, Mike Hammer, Avshalom Houri, Otmar Lendl, Jason Livingood, Daryl Malas, Dave Meyer, Bob Natale, Sriram Parameswar, Jon Peterson, Benny Rodrig, Brian Rosen, Eric Rosenfeld, Peter Saint-Andre, David Schwartz, Richard Shocky, Henry Sinnreich, Richard Stastny, and Adam Uzelac.
バーナードAboba、エドウィン・青木、スコット・ブリム、ジョンエルウェル、パトリックFaltstrom、マイク・ハマー、Avshalomフーリー、オトマールレンドル、ジェイソンLivingood、ダリル・マラス、デイヴ・マイヤー：この文書は、以下を含む多くの人々によって作られた入力と貢献に基づいています、ボブ・ナターレ、スリラムParameswar、ジョンピーターソン、ベニーRodrig、ブライアン・ローゼン、エリック・ローゼンフェルド、ピーター・サン・アンドレ、デビッド・シュワルツ、リチャード・Shocky、ヘンリーSinnreich、リチャードStastny、そしてアダムUzelac。
Specials thanks go to Rohan Mahy, Brian Rosen, and John Elwell for their initial documents describing guidelines or best current practices in various environments, to Avshalom Houri, Edwin Aoki, and Sriram Parameswar for authoring the presence and instant messaging requirements, and to Dan Wing for providing detailed feedback on the Security Consideration sections.
おかげでプレゼンスとインスタントメッセージング要件をオーサリングするための、そしてダン・ウィングにAvshalomフーリー、エドウィン・青木、およびスリラムParameswarに、様々な環境でガイドラインや現在のベストプラクティスを説明彼らの初期の文書にロハンマーイ、ブライアン・ローゼン、ジョンエルウェルに行くスペシャルセキュリティの考慮事項のセクションに詳細なフィードバックを提供するため。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ARCHITECTURE] Malas, D. and J. Livingood, "Session PEERing for Multimedia INTerconnect Architecture", Work in Progress, February 2011.
[アーキテクチャ]マラス、D.とJ. Livingood、「セッションはマルチメディア相互接続アーキテクチャのためのピアリング」、進歩、2011年2月での作業。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365]シラー、J.、BCP 61、RFC 3365、2002年8月 "インターネットエンジニアリングタスクフォース標準プロトコルのための強力なセキュリティ要件"。
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003.
[RFC3455]ガルシア・マーチン、M.、Henrikson、E.、およびD.ミルズ、RFC "第三世代パートナーシッププロジェクト（3GPP）のためのセッション開始プロトコル（SIP）のプライベートヘッダ（P-ヘッダー）の拡張" 3455、2003年1月。
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
[RFC3466]日、M.、カイン、B.、トムリンソン、G.、およびP. Rzewski、RFC 3466、2003年2月 "コンテンツインターネットワーキング（CDI）のためのモデル"。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, July 2003.
[RFC3568] Barbir、A.、カイン、B.、ナイール、R.、およびO. Spatscheck、 "既知のコンテンツネットワーク（CN）リクエスト・ルーティングメカニズム"、RFC 3568、2003年7月。
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC3570] Rzewski、P.、日、M.、およびD. Gilletti、 "コンテンツインターネットワーキング（CDI）シナリオ"、RFC 3570、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T.、カセレス、R.、およびA.クラーク、 "RTP制御プロトコル拡張レポート（RTCP XR）"、RFC 3611、2003年11月。
[RFC3702] Loughney, J. and G. Camarillo, "Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)", RFC 3702, February 2004.
[RFC3702] Loughney、J.およびG.キャマリロ、 "認証、認可、およびセッション開始プロトコル（SIP）のための会計要件"、RFC 3702、2004年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[RFC3824]ピーターソン、J.、劉、H.、ユー、J.、およびB.キャンベル、RFC 3824、2004年6月 "セッション開始プロトコル（SIP）とE.164番号を使用します"。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[RFC3863]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]ラザロ、J.、RFC 4571、2006年7月 "リアルタイム転送プロトコル（RTP）およびRTP制御プロトコルコネクション型トランスポート・オーバー（RTCP）パケットをフレーミング"。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介してメディアトランスポート"、RFC 4572、2006年7月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Abley、J.およびK. Lindqvist、 "エニーキャストサービスの運用"、BCP 126、RFC 4786、2006年12月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]エルウェル、J.、 "セッション開始プロトコル（SIP）に接続アイデンティティ"、RFC 4916、2007年6月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and Instant Messaging Peering Use Cases", RFC 5344, October 2008.
[RFC5344]フーリー、A.、青木、E.、およびS. Parameswar、 "プレゼンスとインスタントメッセージングピアリングユースケース"、RFC 5344、2008年10月。
[RFC5411] Rosenberg, J., "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", RFC 5411, February 2009.
[RFC5411]ローゼンバーグ、J.、RFC 5411 "セッション開始プロトコル（SIP）ヒッチハイク・ガイド"、2009年2月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]マラス、D.とD.マイヤー、 "マルチメディアインターコネクトのためのセッションピアリング（SPEERMINT）用語"、RFC 5486、2009月。
[RFC5503] Andreasen, F., McKibben, B., and B. Marshall, "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", RFC 5503, March 2009.
[RFC5503]アンドレア、F.、マッキベン、B.、およびB.マーシャル、「プライベート・セッション開始プロトコル（SIP）プロキシ・ツー・プロキシ呼シグナリングアーキテクチャ分散のPacketCableサポートするための拡張機能」、RFC 5503、2009年3月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630] Audet、F.、RFC 5630 "セッション開始プロトコル（SIP）におけるSIPS URIスキームの使用"、2009年10月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763] Fischl、J.、Tschofenig、H.、およびE.レスコラ、RFC 5763、2010年5月 "セキュアリアルタイム転送プロトコル（SRTP）データグラムトランスポート層セキュリティ（DTLS）を使用して、セキュリティコンテキストを確立するためのフレームワーク"。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するための拡張」、RFC 5764、2010年5月。
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
[RFC5923] Gurbani、V.、マーイ、R.、およびB.テート、 "セッション開始プロトコル（SIP）における接続の再利用"、RFC 5923、2010年6月。
[RFC6076] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Performance Metrics", RFC 6076, January 2011.
[RFC6076]マラス、D.とA.モートン、 "基本的なテレフォニーSIPエンドツーエンドのパフォーマンス・メトリック"、RFC 6076、2011年1月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 6120、2011年3月。
[VOIP] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Work in Progress, April 2010.
[VOIP] Uzelac、A.、およびY.リー、 "VoIPのSIPピアリングユースケース"、進歩、2010年4月に作業。
[VOIPTHREATS] Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, "Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats and Suggested Countermeasures", Work in Progress, March 2011.
[VOIPTHREATS]セードルフ、J.、ニッコリーニ、S.、チェン、E.、およびH.ショルツ、進歩、2011年3月に、作業 "マルチメディアインターコネクト（SPEERMINT）セキュリティの脅威と推奨対策のためのセッションピアリング"。
Appendix A. Policy Parameters for Session Peering
セッションのピアリングのための付録A.ポリシーのパラメータ
This informative appendix lists various types of parameters that should be considered by implementers when deciding what configuration variables to expose to system administrators or management stations, as well as SSPs or federations of SSPs when discussing the technical part of a session peering policy.
この有益な付録では、セッションピアリング政策の技術的な部分を議論する際に、構成変数は、システム管理者または管理ステーションと同様に、SSPのかのSSPの連盟に公開するかを決定する際に実装により考慮すべき各種パラメータを示しています。
In the context of session peering, a policy can be defined as the set of parameters and other information needed by an SSP to exchange traffic with another peer. Some of the session policy parameters may be statically exchanged and set throughout the lifetime of the peering relationship. Other parameters may be discovered and updated dynamically using some explicit protocol mechanisms. These dynamic parameters may be session dependent, or they may apply over multiple sessions or peers.
セッションピアリングの文脈では、ポリシーは、別のピアとトラフィックを交換するSSPによって必要なパラメータやその他の情報の集合として定義することができます。セッションポリシーパラメータのいくつかは、静的に交換し、ピアリング関係の生涯を通じて設定することができます。他のパラメータは発見され、いくつかの明示的なプロトコルメカニズムを使用して動的に更新することができます。これらの動的パラメータは、セッション依存することができる、またはそれらを複数のセッションまたはピアの上に適用される場合があります。
Various types of policy information may need to be discovered or exchanged in order to establish session peering. At a minimum, a policy should specify information related to session establishment data in order to avoid session establishment failures. A policy may also include information related to QoS, billing and accounting, and Layer 3 related interconnect requirements, which are out of the scope of this document.
ポリシー情報の様々な種類が発見されたか、セッションのピアリングを確立するために交換する必要があるかもしれません。最低でも、ポリシーは、セッション確立の失敗を避けるために、セッション確立データに関連する情報を指定する必要があります。ポリシーものQoS、課金および会計、およびレイヤこの文書の範囲外である3つの関連の相互接続要件に関連する情報を含むことができます。
Some aspects of session peering policies must be agreed to and manually implemented; they are static and are typically documented as part of a business contract, technical document, or agreement between parties. For some parameters linked to protocol support and capabilities, standard ways of expressing those policy parameters may be defined among SSPs and exchanged dynamically. For example, templates could be created in various document formats so that it could be possible to dynamically discover some of the domain policy. Such templates could be initiated by implementers. For each software or hardware release, the template could list supported RFCs, and the associated RFC parameters implemented in the given release in a standard format. Each SSP would then complete the template and adapt its content based on its service description, the deployed server or device configurations and the variation of these configurations based on peer relationships.
セッションピアリング政策のいくつかの側面をすることに合意し、手動で実装する必要があります。彼らは静的であり、通常、ビジネス契約の一部、技術文書、または当事者間の合意として文書化されています。プロトコルのサポートおよび機能にリンクされたいくつかのパラメータについては、これらのポリシーパラメータを表現する標準的な方法は、SSPの間で定義され、動的に交換することができます。動的ドメインポリシーのいくつかを発見することも可能になるように例えば、テンプレートは、さまざまな文書フォーマットで作成することができます。このようなテンプレートは、実装によって開始することができます。各ソフトウェアまたはハードウェアの放出のために、テンプレートは、RFCをサポートされるリストことができ、および関連するRFCパラメータが標準フォーマットで指定されたリリースで実装します。各SSPは、テンプレートを完了し、そのサービスの説明、展開サーバーやデバイス構成とピアの関係に基づいて、これらの構成の変化に基づいて、その内容を適応させるでしょう。
A.1. Categories of Parameters for VoIP Session Peering and Justifications
A.1。 VoIPのセッションピアリングと正当化のためのパラメータのカテゴリー
The following list should be considered as an initial list of "discussion topics" to be addressed by peers when initiating a VoIP peering relationship.
VoIPのピアリング関係を開始するとき、「ディスカッショントピック」の最初のリストは、ピアによって対処されるよう以下のリストを検討すべきです。
o IP Network Connectivity:
IPネットワーク接続○：
Session peers should define the IP network connectivity between their respective SBEs and DBEs. While this is out of scope of session peering, SSPs must agree on a common mechanism for IP transport of session signaling and media. This may be accomplished via private (e.g., IPVPN, IPsec, etc.) or public IP networks.
セッションピアは、それぞれの残りのSBEとDBES間のIPネットワーク接続を定義する必要があります。これはセッションピアリングの範囲外ですが、SSPがセッションシグナリングおよびメディアのIP伝送のための共通のメカニズムに同意しなければなりません。これは、プライベート（例えば、IPVPN、IPsecの、など）又はパブリックIPネットワークを介して達成することができます。
o Media-related Parameters:
Oメディア関連のパラメータ：
* Media Codecs: list of supported media codecs for audio, real-time fax (version of T.38, if applicable), real-time text (RFC 4103), dual-tone multi-frequency (DTMF) transport voice band data communications (as applicable) along with the supported or recommended codec packetization rates, level of RTP payload redundancy, audio volume levels, etc.
*メディアコーデック：オーディオ用にサポートされているメディア・コーデックのリスト、リアルタイムファックス（T.38のバージョン、該当する場合）、リアルタイムテキスト（RFC 4103）、デュアルトーン多重周波数（DTMF）輸送音声帯域のデータ通信（該当する場合）サポートまたは推奨コーデックパケット化率、RTPペイロードの冗長性のレベル、音量レベルなどとともに
* Media Transport: level of support for RTP-RTCP [RFC3550], RTP Redundancy (RTP Payload for Redundant Audio Data [RFC2198]), T.38 transport over RTP, etc.
*メディアトランスポート：RTP-RTCP [RFC3550]、RTP冗長性のサポートレベル（RTPペイロードのための冗長オーディオデータ[RFC2198]）、RTPオーバーT.38輸送など
* Media variability at the signaling path border elements: list of media types supported by the various ingress points of a peer's network.
*シグナルパスの境界要素でメディアの多様性：ピアのネットワークの様々な侵入ポイントでサポートされるメディアタイプのリスト。
* Other: support of the VoIP metric block as defined in RTP Control Protocol Extended Reports [RFC3611], etc.
*その他：RTP制御プロトコル拡張レポート[RFC3611]などで定義されているVoIPのメトリックブロックのサポート
o SIP:
OのSIP：
* A session peering policy should include the list of supported and required SIP RFCs, supported and required SIP methods (including private p headers if applicable), error response codes, supported or recommended format of some header field values, etc.
*ポリシーピアリングセッションがサポートされているとSIPのRFC、（該当する場合プライベートPヘッダを含む）をサポートし、必要なSIPメソッド、エラー応答コードを必要なのリストを含むべきである、など、いくつかのヘッダフィールド値のフォーマットをサポートまたは推奨
* It should also be possible to describe the list of supported SIP RFCs by various functional groupings. A group of SIP RFCs may represent how a call feature is implemented (call hold, transfer, conferencing, etc.), or it may indicate a functional grouping as in [RFC5411].
*また、さまざまな機能グループでサポートされているSIPのRFCのリストを記述することが可能でなければなりません。 SIPのRFCのグループは、コール機能は（呼保留、転送、会議など）を実装する方法を表してもよく、またはそれは、[RFC5411]のように機能的グループ化を示すことができます。
o Accounting:
O会計：
Methods used for call or session accounting should be specified. An SSP may require a peer to track session usage. It is critical for peers to determine whether the support of any SIP extensions for accounting is a pre-requisite for SIP interoperability. In some cases, call accounting may feed data for billing purposes, but not always: some operators may decide to use accounting as a 'bill and keep' model to track session usage and monitor usage against service level agreements.
コールまたはセッションのアカウンティングのために使用される方法を指定する必要があります。 SSPは、セッションの使用状況を追跡するために、ピアが必要な場合があります。ピアは、会計のための任意のSIP拡張のサポートは、SIPの相互運用性のための前提条件であるかどうかを判断することが重要です。いくつかのケースでは、コール・アカウンティングは課金目的のためにデータを供給することができる、常にではない：一部の事業者は、セッションの使用状況を追跡し、サービスレベルアグリーメントに対する使用状況を監視するよう会計を使用して「法案と維持」モデルをするように決定することができます。
[RFC3702] defines the terminology and basic requirements for accounting of SIP sessions. A few private SIP extensions have also been defined and used over the years to enable call accounting between SSP domains such as the P-Charging* headers in [RFC3455], the P-DCS-Billing-Info header in [RFC5503], etc.
[RFC3702]はSIPセッションの会計処理のための用語と基本的な要件を定義します。いくつかの民間のSIP拡張もなど[RFC3455]でP-充電*ヘッダ、[RFC5503]でP-DCS-課金-Infoヘッダー、などSSPのドメイン間の会計処理の呼び出しを可能にするために、長年にわたって定義され、使用されています
o Performance Metrics:
パフォーマンス・メトリックO：
Layer 5 performance metrics should be defined and shared between peers. The performance metrics apply directly to signaling or media; they may be used proactively to help avoid congestion, call quality issues, or call signaling failures, and as part of monitoring techniques, they can be used to evaluate the performance of peering exchanges.
レイヤ5パフォーマンスメトリックを定義し、ピア間で共有されなければなりません。パフォーマンスメトリックは、シグナリングやメディアに直接適用されます。彼らは混雑、通話品質の問題、または故障コールシグナリングを避けるために積極的に使用することができ、モニタリング技術の一環として、彼らはピアリング交換の性能を評価するために使用することができます。
Examples of SIP performance metrics include the maximum number of SIP transactions per second on per-domain basis, Session Completion Rate (SCR), Session Establishment Rate (SER), etc. Some SIP end-to-end performance metrics are defined in [RFC6076]; a subset of these may be applicable to session peering and interconnects.
SIPのパフォーマンス・メトリックの例は、ドメインごとに秒当たりのSIPトランザクションの最大数を含む、セッション完了率（SCR）、セッション確立レート（SER）は、いくつかのSIPエンドツーエンドのパフォーマンス・メトリックは、[RFC6076で定義されている等];これらのサブセットは、セッションピアリングや相互接続にも適用することができます。
Some media-related metrics for monitoring VoIP calls have been defined in the VoIP Metrics Report Block, in Section 4.7 of [RFC3611].
VoIPコールを監視するためのいくつかのメディア関連のメトリックは、[RFC3611]の4.7節では、VoIPのメトリクスレポート・ブロックで定義されています。
o Security:
セキュリティO：
An SSP should describe the security requirements that other peers must meet in order to terminate calls to its network. While such a list of security-related policy parameters often depends on the security models pre-agreed to by peers, it is expected that these parameters will be discoverable or signaled in the future to allow session peering outside SSP clubs. The list of security parameters may be long and composed of high-level requirements (e.g., authentication, privacy, secure transport) and low-level protocol configuration elements like TLS parameters.
SSPは、他のピアがそのネットワークへの通話を終了するために満たさなければならないセキュリティ要件を記述する必要があります。セキュリティ関連のポリシーパラメータのようなリストは、多くの場合、ピアによって事前に合意されたセキュリティモデルに依存するが、これらのパラメータは、発見やSSPクラブの外にピアリングセッションを可能にし、将来的に合図となることが予想されます。セキュリティパラメータのリストは長く、高レベルの要件（例えば、認証、プライバシー、安全な輸送）とTLSパラメータのような低レベルプロトコルの構成要素から構成されてもよいです。
The following list is not intended to be complete, it provides a preliminary list in the form of examples:
以下のリストは完全であることを意図していない、それは例の形で予備的なリストを提供します。
* Call admission requirements: for some providers, sessions can only be admitted if certain criteria are met. For example, for some providers' networks, only incoming SIP sessions signaled over established IPsec tunnels or presented to the well-known TLS ports are admitted. Other call admission requirements may be related to some performance metrics as described above.
*入学要件をコール：特定の条件が満たされた場合、一部のプロバイダのために、セッションにのみ認められることができます。例えば、いくつかのプロバイダのネットワークのために、唯一の着信SIPセッションは、確立されたIPsecトンネル上をシグナリングまたは入院している周知のTLSポートに提示されます。上記のように、他の呼受付の要件は、いくつかのパフォーマンスメトリックに関連することができます。
Finally, it is possible that some requirements be imposed on lower layers, but these are considered out of scope of session peering.
最後に、いくつかの要件が下位層に課されるが、これらはセッションピアリングの適用範囲外と見なされることも可能です。
* Call authorization requirements and validation: the presence of a caller or user identity may be required by an SSP. Indeed, some SSPs may further authorize an incoming session request by validating the caller's identity against white/black lists maintained by the service provider or users (traditional caller ID screening applications or IM white lists).
*許可要件と検証を呼び出します。発信者またはユーザーのアイデンティティの存在は、SSPで必要になることがあります。実際、いくつかのSSPは、さらに、サービスプロバイダやユーザー（伝統的な発信者IDスクリーニングアプリケーションやIMホワイトリスト）によって維持白/黒のリストに対して、発信者の身元を検証することにより、着信セッション要求を許可することができます。
* Privacy requirements: an SSP may demand that its SIP messages be securely transported by its peers for privacy reasons so that the calling/called party information be protected. Media sessions may also require privacy, and some SSP policies may include requirements on the use of secure media transport protocols such as SRTP, along with some constraints on the minimum authentication/encryption options for use in SRTP.
*プライバシー要件：SSPは、呼び出し/着信側の情報が保護されるように、そのSIPメッセージが確実にプライバシー上の理由からそのピアによって輸送されることを要求することができます。メディアセッションはまた、プライバシーを必要とするかもしれない、といくつかのSSPポリシーがSRTPで使用するための最低限の認証/暗号化オプションにいくつかの制約に加えて、このようなSRTPなどのセキュアメディアトランスポートプロトコルの使用上の要件を含むことができます。
* Network-layer security parameters: this covers how IPsec security associations may be established, the IPsec key exchange mechanisms should be used, and any details on keying materials, the lifetime of timed security associations if applicable, etc.
*ネットワーク層のセキュリティパラメータは：これはIPsecセキュリティアソシエーションが確立されてもよい方法を説明し、IPsecの鍵交換メカニズムを使用する必要があり、およびキーイング材料上の任意の詳細については、時限式のセキュリティアソシエーションのライフタイム該当する場合など
* Transport-layer security parameters: this covers how TLS connections should be established, as described in Section 5.
*トランスポート・レイヤ・セキュリティパラメータ：これはセクション5で説明したようにTLS接続が確立されなければならない方法を説明します。
A.2. Summary of Parameters for Consideration in Session Peering Policies
A.2。セッションピアリング方針の検討のためのパラメータの概要
The following is a summary of the parameters mentioned in the previous section. They may be part of a session peering policy and appear with a level of requirement (mandatory, recommended, supported, etc.).
以下は、前のセクションで説明したパラメータの概要です。彼らは、セッションピアリングポリシーの一部であると（必須、推奨、サポートされている、など）要件のレベルが表示されてもよいです。
o IP Network Connectivity (assumed, requirements out of scope of this document)
O IPネットワーク接続（想定し、この文書の範囲外の要件）
o Media session parameters:
メディアセッションパラメータO：
* Codecs for audio, video, real time text, instant messaging media sessions
オーディオ、ビデオ、リアルタイムテキスト、インスタント・メッセージング・メディア・セッションのための*コーデック
* Modes of communications for audio (voice, fax, DTMF), IM (page mode, MSRP)
*オーディオ（音声、ファックス、DTMF）、IM用の通信のモード（ページモード、MSRP）
* Media transport and means to establish secure media sessions
*メディアトランスポートとセキュアなメディアセッションを確立することを意味します
* List of ingress and egress DBEs where applicable, including STUN Relay servers if present
入力および出力DBES該当の*リスト、存在する場合STUNリレーサーバーを含みます
o SIP
OのSIP
* SIP RFCs, methods and error responses
* SIPのRFCの、方法およびエラーレスポンス
* headers and header values
*ヘッダーとヘッダー値
* possibly, list of SIP RFCs supported by groups (e.g., by call feature)
*おそらく、（コール機能により、例えば、）基によってサポートSIP RFCのリスト
o Accounting
O会計
o Capacity Control and Performance Management: any limits on, or, means to measure and limit the maximum number of active calls to a peer or federation, maximum number of sessions and messages per specified unit time, maximum number of active users or subscribers per specified unit time, the aggregate media bandwidth per peer or for the federation, specified SIP signaling performance metrics to measure and report; media-level VoIP metrics if applicable.
O容量制御およびパフォーマンス管理：任意の制限、または、ピアまたはフェデレーションへのアクティブコールの最大数を測定し、制限することを意味し、指定された単位時間当たりのセッションおよびメッセージの最大数は、指定されたあたりのアクティブユーザ又は加入者の最大数単位時間、ピアごとまたはフェデレーションの集約メディア帯域幅は、測定及びレポートするSIPシグナリングパフォーマンスメトリックを指定しました。メディアレベルのVoIPメトリクス該当する場合。
o Security: Call admission control, call authorization, network and transport layer security parameters, media security parameters
Oセキュリティ：アドミッション制御、コールの承認、ネットワークおよびトランスポート層セキュリティパラメータ、メディアのセキュリティパラメータを呼び出し
Author's Address
著者のアドレス
Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA
ジャン=フランソワラバCableLabsの858コールクリークサークルルイビル、CO 80027 USA
EMail: jf.mule@cablelabs.com
メールアドレス：jf.mule@cablelabs.com