[要約] RFC 6271は、SIPベースのセッションピアリングの要件を定義しており、セッションピアリングのためのプロトコルや機能の要件を提供しています。目的は、異なるSIPネットワーク間でのセッションピアリングの実装を容易にすることです。
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
SIPベースのセッションピアリングの要件
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................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サービスプロバイダー（SSP）間のセッションを確立するためにセッション開始プロトコル（SIP）を使用していると想定しています。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]）に精通していることが期待されています。
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.
このドキュメントでは、最初に一般的な要件について説明します。ユースケースは、ユースケースを達成するために満たさなければならない関連するプロトコル要件を抽出する精神で分析されます。これらの要件は、Voice over 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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 ID [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.
このドキュメントの主な焦点は、レイヤー5 SIPネットワークの境界に適用される要件にあります。SIPエンティティ、シグナリングパス境界要素（SBE）、およびセッション確立データのルックアップとロケーションルーティングの関連するプロトコル要件です。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).
セッションピアリングの取り決めに関する他の多くの考慮事項は、成功した合意に達するために重要ですが、それらはこの文書の範囲外であると見なされます。それらには、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応答がクエリ（ピア依存SBES）を送信する人によって異なる場合に、以下の要件＃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.
SIPサービスプロバイダーがサービスドメインの出力SBEを通信できるようにするには、プロトコルメカニズムを提供する必要があります。
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を受け入れるコールは、SIPコールがどこから発生するかを知りたいと思うかもしれません（この情報は通常、終了SSPで使用されます）。
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がユーザーにメディアストリームを提供する場合、SSPSが該当する場合は出力パス境界要素（DBE）を宣伝し、侵入して侵入することを許可するメカニズムが存在する必要があります。一部のSSPにはオープンポリシーがあり、ネットワークの外側のどこからでもネットワーク内のどこからでもメディアトラフィックを受け入れる場合がありますが、一部のSSPは、トラフィックが送信される前にメディア配信を最適化し、ピア間のメディアパスを特定したい場合があります（レイヤー5からレイヤー3サービスの品質レイヤー3（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サービスプロバイダーがDBEを仲間に通信できるようにするために、プロトコルメカニズムを提供する必要があります。
Notes: Some SSPs engaged in SIP interconnects do exchange this type of DBE information in a static manner. Some SSPs do not.
注：SIP相互接続に従事する一部のSSPは、このタイプのDBE情報を静的な方法で交換します。一部の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とDBEを宣伝することが一般的です。これは、特定のピアの特定の目標を満たすためにSSPによって行われます。シグナルとメディアの交換のルーティング最適化、「ベスト」SBEとDBEの組み合わせに基づくレイテンシまたはスループットの最適化、およびその他のサービスプロバイダーポリシーパラメーター。これらは、SBEとDBEの広告がピアに依存している理由の一部です。
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 URISがユーザーによって伝播される可能性があるため、いくつかの実際的な制限があります。オリジネーターに基づいて、さまざまなイングレスSBEで着信セッションシグナリングを受けたいというSIPサービスプロバイダーの欲求に基づいて、ユーザーに異なるターゲットURIを実装するように依頼することは非現実的です。したがって、[RFC3263]で説明され、DNSに基づいてSBEを宣伝するソリューションは、この要件について指定されています。
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応答をDNSクエリの発信元に基づいて異なるようにするために広く使用されています（[RFC3466]、[RFC3568]、[RFC3570]を参照）。セッションピアリングのためのこのようなソリューションの適用性は、さらなる分析が必要です。
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.
最後に、Anycast Services（[RFC4786]）などの他の手法は、この要件の解決策を提供するために、レイヤー5よりも下層層で採用される場合があります。たとえば、ANYCASTノードはSIPサービスプロバイダーによって定義されてSBEの共通アドレスをDNSに公開し、ANYCASTノードアドレスの解像度を適切なピア依存サービスアドレスに分解し、ルーティングトポロジまたは結合されたものから収集されたその他の基準に基づいて、Anycastおよび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エンティティを使用しなければならない出力を定義できるはずです。
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.
たとえば、静的な直接ピアリングシナリオ（[VoIP]のセクション5.2の図2）の場合、発信ネットワーク（O-Proxy）のSIPプロキシ（O-Proxy）が適切な出力SBE（O（O）を選択できるようにする必要があります。-sbe）ルックアップ関数（O-LUF）からプロキシが受け取る情報に基づいてSIPターゲットに到達するために、および/またはロケーションルーティング関数（O-LRF） - （2）というラベル付けされたメッセージ応答。この例は、サービスプロバイダーに複数のサービスエリアがあり、各サービスエリアに複数の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.
ピア間で使用されるユーザーのアイデンティティは、さまざまな形式で表現できます。セッション確立データは、VoIPトラフィックのセッションピアリングのために、URIS（ユニフォームリソース識別子、[RFC3986]）に依存する必要があり、SIP URIをTelURIS（[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がピアのドメイン内でどの個々のユーザーIDが有効であるかを認識する必要はありません。
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がピアのドメイン内でどの個々のユーザーIDが有効であるかを認識する必要はありません。
o Notes on the solution space for Requirements #7 and #8:
o 要件のためのソリューションスペースに関するメモ＃7および＃8：
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プロトコルによってよくサポートされています。電話番号がテル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：uris）に基づいて、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がSIPリクエストを開始する必要なく、SIP URIが直接的な相互接続のために開いているかどうかを判断できる必要があります。さらに、各コールのセットアップは提案されたアルゴリズムの実行を意味するため、ピアリングを介した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.
セッションピアリングのメカニズムは、URIタイプとターゲットSSPドメイン名を考慮して、SBEがピア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.
2つのSSPは、IMおよびプレゼンスユーザーが他のSSPネットワークでユーザーと協力できるようにするためのピアリング関係を作成します。ドメイン間サブスクリプションの要件を、存在情報、メッセージの交換とプライバシー設定、およびドメイン全体で標準の存在ドキュメント形式の使用に焦点を当てます。
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.
存在感とインスタントメッセージングのピアリングのいくつかのユースケースは、A。Houri、E。Aoki、およびS. Parameswarが執筆した文書である[RFC5344]で説明されています。このセクションの要件にこれらのユースケースからキャプチャされた元のコンテンツのクレジットは、それらに移動する必要があります。
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間のインスタントメッセージング交換に推奨されるメカニズムは、1つのSSPのコミュニティのユーザーが、さまざまな方法を使用して地域コミュニティを介して他のSSPコミュニティのユーザーと通信できるようにする必要があります。一部のSSPは、サービスポリシーに基づいて許可されている方法をある程度制御する場合があることに注意してください。このような方法には、1回限りのIMメッセージの送信、メッセージのセッションを輸送するためのSIPセッションの開始、ピアSSPのユーザーとのチャットルームを使用してN-Wayチャットに参加するなどがあります。
Notes: see Sections 2.4, 2.5, and 2.6 of [RFC5344].
注：[RFC5344]のセクション2.4、2.5、および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間で共有されず、SSP間の1つのプレゼンテーションの変更に対して複数の通知を送信します。
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コミュニティのウォッチャーのリストにプレゼンスドキュメントを関連付けて、ピアウォッチャーがプレゼンスドキュメント通知を受け取ることができるようにすることが可能です。これにより、コミュニティ間でより少ないプレゼンスドキュメント通知を送信しながら、あるコミュニティから別のコミュニティにプレゼンテーションのプライバシー情報を共有する必要性を回避できます。
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]）で定義されている要素とプロパティの異なる命名スキームまたは名前の値を使用するレガシー専有システムの前で行われました。たとえば、ある存在サービスでの値「邪魔しない」は、ステータス要素の別のシステムで「ビジー」にマッピングされる場合があります。ステータス値のこの例を超えて、存在情報の意味が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ドキュメントを使用し、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）を介した宛先ターゲットに基づくセッション確立データ（SED）の取得（LUFおよびLRF）、SIP間のSIPシグナルはサービスプロバイダー、および関連するメディア交換。
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]）の追加ガイダンスを提供します。
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 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およびLRFによって返される応答の内容は、リクエスターの身元に依存する可能性があります。したがって、LUFおよびLRFリクエストの認証は望ましいプロパティです。相互認証も望ましいです。リクエスタは、これらの応答で返されたデータの性質を考慮して、LUFおよびLRF応答を提供するシステムのIDを検証する場合があります。認証は、LUFとLRFの可用性を、LUFのリクエストを送信してLUFがルックアップを実行し、リソースを消費することにより、攻撃者（DOS）攻撃を開始しようとする攻撃者に対するある程度の保護を提供します。
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.).
LUFおよびLRF関数と交換されたセッション確立データの繊細な性質を考えると、ルックアップとロケーションルーティングに選択されたプロトコルメカニズムは、データの機密性と整合性保護を提供する必要があります（SEDデータにはユーザーアドレス、SIP URI、SIPの場所が含まれます。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.
通常、これらの関数にアクセスするために、列挙、SIP、および独自のプロトコルが通常使用されています。SSPSは、これらのセキュリティプロパティの一部を保証するために低層セキュリティメカニズムを使用する場合がありますが、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.
o ピアのSBE間でSIPメッセージの輸送を確保します。SIP通信の認証は、特にSIP仲介者が関与するセッションピアリングのコンテキストでは望ましいです。SIPメッセージ本文のデータの機密性と整合性は、セッションピアリング間接のレベル（間接/補助ピアリング）のレベルの一部を考えると望ましい場合がありますが、中間SSPがSBE/DBEを「挿入」するのを防ぐことができるため、有害である可能性があります。シグナリングとデータパス。
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).
o SIPサービスプロバイダードメイン（SIPリクエストと応答の両方）に基づいて、接続されたユーザーのIDを認証するための認証サービスを提供します。
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を保護するための基本的なメカニズムは、ドメイン内と干渉間でセッションのピアリングに適用されます。TLSを使用したSIPメッセージの輸送層セキュリティについては、[RFC3261]のセクション26.2 [RFC5923]を参照してください。ドメインコンテキスト、および[RFC4916] SIP応答の送信者のIDを確認するための[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）を搭載したメディアは、Secure RTP（SRTP [RFC3711]）を使用して保護できます。データグラムTLS（DTLS）[RFC4347]を使用してSRTPセキュリティを確立するためのフレームワークは、[RFC5763]で説明されています。
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メッセージメソッド）、MSRP（メッセージセッションリレープロトコル、[RFC4975]、XMPP（拡張可能なメッセージと存在プロトコル、[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エンティティがエンドツーエンドのメディアセキュリティ交渉に透明性を持つことです。SIPエンティティは、エンドツーエンドのメディアセキュリティのセッション説明プロトコル（SDP）交換に介入すべきではありません。
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のメディアセキュリティ属性の交換を妨害してはなりません。SBESによって理解されていないメディア属性行は無視され、シグナリングパスに沿って渡される必要があります。
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.
この文書は、バーナード・アボバ、エドウィン・アオキ、スコット・ブリム、ジョン・エルウェル、パトリック・ファルトストローム、マイク・ハンマー、アヴシャロム・ホイ、オトマル・レンドル、ジェイソン・リビングウッド、ダリル・マラス、デイブ・マイヤーを含む多くの人々が行った入力と貢献に基づいています。、ボブ・ナタール、スリラム・パラメスワール、ジョン・ピーターソン、ベニー・ロドリグ、ブライアン・ローゼン、エリック・ローゼンフェルド、ピーター・サン・アンドレ、デビッド・シュワルツ、リチャード・ショック、ヘンリー・シン・レイヒ、リチャード・スタストニー、アダム・ウゼラック。
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.
スペシャルに感謝しますRohan Mahy、Brian Rosen、およびJohn Elwellに、さまざまな環境でのガイドラインまたは最新の慣行を説明している最初の文書、Avshalom Houri、Edwin Aoki、およびSriram Parameswarに、存在感と即時メッセージ要件を執筆し、ダンウィングセキュリティ対価セクションに関する詳細なフィードバックを提供するため。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ARCHITECTURE] Malas, D. and J. Livingood, "Session PEERing for Multimedia INTerconnect Architecture", Work in Progress, February 2011.
[アーキテクチャ] Malas、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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、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] Garcia-Martin、M.、Henrikson、E。、およびD. Mills、「Private Header（P-Header）セッション開始プロトコル（SIP）の第3世代パートナーシッププロジェクト（3GPP）の拡張」、RFC3455、2003年1月。
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
[RFC3466] Day、M.、Cain、B.、Tomlinson、G。、およびP. Rzewski、「コンテンツインターネットワークのモデル（CDI）」、RFC 3466、2003年2月。
[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.、Frederick、R。、およびV. Jacobson、「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.、Cain、B.、Nair、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.、Day、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] Friedman、T.、Caceres、R。、およびA. Clark、「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。and G. Camarillo、「セッション開始プロトコル（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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（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] Peterson、J.、Liu、H.、Yu、J。、およびB. Campbell、「セッション開始プロトコル（SIP）でE.164番号を使用」、RFC 3824、2004年6月。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[RFC3863] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Lazzaro、J。、「接続指向の輸送上のリアルタイム輸送プロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットのフレーミング」、RFC 4571、2006年7月。
[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] Lennox、J。、「セッション説明プロトコル（SDP）の輸送層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Eabley、J。およびK. Lindqvist、「Anycast Servicesの運用」、BCP 126、RFC 4786、2006年12月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、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] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（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] Houri、A.、Aoki、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] Rosenberg、J。、「セッション開始プロトコル（SIP）のヒッチハイカーガイド」、RFC 5411、2009年2月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486] Malas、D。およびD. Meyer、「Multimedia Interconnect（Speermint）用語のセッションピアリング」、RFC 5486、2009年3月。
[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] Andreasen、F.、McKibben、B。、およびB. Marshall、「プライベートセッション開始プロトコル（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。、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、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. Rescorla、「データグラム輸送層セキュリティ（DTLS）を使用した安全なリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、2010年5月。
[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] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
[RFC5923] Gurbani、V.、Mahy、R。、およびB. Tate、「セッション開始プロトコル（SIP）での接続再利用」、RFC 5923、2010年6月。
[RFC6076] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Performance Metrics", RFC 6076, January 2011.
[RFC6076] Malas、D。およびA. Morton、「基本テレフォニーSIPエンドツーエンドパフォーマンスメトリック」、RFC 6076、2011年1月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、2011年3月。
[VOIP] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Work in Progress, April 2010.
[Voip] Uzelac、A。およびY. Lee、「Voip Sip Pearing Use Case」、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] Seedorf、J.、Niccolini、S.、Chen、E。、およびH. Scholz、「マルチメディアインターコネクト（Speermint）セキュリティの脅威と提案された対策のセッションピアリング」、2011年3月の進行中。
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は、そのサービスの説明、展開されたサーバーまたはデバイス構成、およびピア関係に基づいてこれらの構成のバリエーションに基づいて、テンプレートを完成させ、コンテンツを適応させます。
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:
o 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とDBEの間の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]）、T.38 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のリスト、サポートされた、必要なSIPメソッド（該当する場合はプライベートPヘッダーを含む）、エラー応答コード、一部のヘッダーフィールド値のサポートまたは推奨形式などを含める必要があります。
* 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セッションの会計に関する用語と基本要件を定義します。[RFC3455]のp-charing*ヘッダー、[RFC5503]などのP-DCS-BILLING INFOヘッダーなどのSSPドメイン間のコールアカウンティングを有効にするために、長年にわたっていくつかのプライベートSIP拡張機能も定義および使用されています。
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パフォーマンスメトリックの例には、ドメインごとのベースでの1秒あたりの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.
* コール入場要件：一部のプロバイダーの場合、セッションは特定の基準が満たされている場合にのみ入院できます。たとえば、一部のプロバイダーのネットワークでは、確立されたIPSECトンネルに合図された、またはよく知られているTLSポートに提示された着信SIPセッションのみが認められています。他の通話入学要件は、上記のようにいくつかのパフォーマンスメトリックに関連している場合があります。
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).
* 承認要件と検証を呼び出す：発信者またはユーザーIDの存在は、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接続の確立方法をカバーしています。
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)
* オーディオの通信モード（音声、FAX、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
* 該当する場合は、該当する場合に該当する場合、存在する場合はスタンリレーサーバーのリスト
o SIP
o 一口
* 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
Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville、Co 80027 USA
EMail: jf.mule@cablelabs.com