[要約] RFC 6406は、SPEERMINTアーキテクチャに関するものであり、マルチメディアの相互接続のためのセッションPEERingに焦点を当てています。その目的は、異なるネットワーク間でのセッションの確立と管理を効率的に行うことです。
Internet Engineering Task Force (IETF) D. Malas, Ed.
Request for Comments: 6406 CableLabs
Category: Informational J. Livingood, Ed.
ISSN: 2070-1721 Comcast
November 2011
Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture
マルチメディアインターコネクト（Speermint）アーキテクチャ用のセッションピアリング
Abstract
概要
This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains.
このドキュメントでは、セッション開始プロトコル（SIP）とその機能コンポーネントとインターフェイスのピアリングアーキテクチャを定義します。また、2つのSIPサービスプロバイダー（SSP）ピアリングドメイン間のセッションを確立するために必要なコンポーネントと手順についても説明します。
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/rfc6406.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6406で取得できます。
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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. New Terminology .................................................3
2.1. Session Border Controller (SBC) ............................3
2.2. Carrier-of-Record ..........................................4
3. Reference Architecture ..........................................4
4. Procedures of Inter-Domain SSP Session Establishment ............6
5. Relationships between Functions/Elements ........................7
6. Recommended SSP Procedures ......................................7
6.1. Originating or Indirect SSP Procedures .....................7
6.1.1. The Lookup Function (LUF) ...........................8
6.1.1.1. Target Address Analysis ....................8
6.1.1.2. ENUM Lookup ................................8
6.1.2. Location Routing Function (LRF) .....................9
6.1.2.1. DNS Resolution .............................9
6.1.2.2. Routing Table ..............................9
6.1.2.3. LRF to LRF Routing ........................10
6.1.3. The Signaling Path Border Element (SBE) ............10
6.1.3.1. Establishing a Trusted Relationship .......10
6.1.3.2. IPsec .....................................10
6.1.3.3. Co-Location ...............................11
6.1.3.4. Sending the SIP Request ...................11
6.2. Target SSP Procedures .....................................11
6.2.1. TLS ................................................11
6.2.2. Receive SIP Requests ...............................11
6.3. Data Path Border Element (DBE) ............................12
7. Address Space Considerations ...................................12
8. Acknowledgments ................................................12
9. Security Considerations ........................................12
10. Contributors ..................................................13
11. References ....................................................14
11.1. Normative References .....................................14
11.2. Informative References ...................................15
This document defines a reference peering architecture for the Session Initiation Protocol (SIP) [RFC3261], it's functional components and interfaces in the context of session peering for multimedia interconnects. In this process, we define the peering reference architecture and its functional components, and peering interface functions from the perspective of a SIP Service Provider's (SSP's) [RFC5486] network. Thus, it also describes the components and the steps necessary to establish a session between two SSP peering domains.
このドキュメントでは、セッション開始プロトコル（SIP）[RFC3261]の参照ピアリングアーキテクチャを定義します。これは、マルチメディアインターコネクトのセッションピアリングのコンテキストで機能的なコンポーネントとインターフェイスです。このプロセスでは、SIPサービスプロバイダー（SSP）[RFC5486]ネットワークの観点から、ピアリングリファレンスアーキテクチャとその機能コンポーネント、およびピアリングインターフェイス機能を定義します。したがって、2つのSSPピアリングドメイン間のセッションを確立するために必要なコンポーネントと手順についても説明します。
An SSP may also be referred to as an Internet Telephony Service Provider (ITSP). While the terms ITSP and SSP are frequently used interchangeably, this document and other subsequent SIP peering-related documents should use the term SSP. SSP more accurately depicts the use of SIP as the underlying Layer 5 signaling protocol.
SSPは、インターネットテレフォニーサービスプロバイダー（ITSP）と呼ばれることもあります。ITSPとSSPという用語は頻繁に交換可能に使用されますが、このドキュメントやその後のSIPピアリング関連ドキュメントは、SSPという用語を使用する必要があります。SSPは、基礎となるレイヤー5シグナル伝達プロトコルとしてのSIPの使用をより正確に示しています。
This architecture enables the interconnection of two SSPs in Layer 5 peering, as defined in the SIP-based session peering requirements [RFC6271].
このアーキテクチャにより、SIPベースのセッションピアリング要件[RFC6271]で定義されているように、レイヤー5ピアリングの2つのSSPの相互接続が可能になります。
Layer 3 peering is outside the scope of this document. Hence, the figures in this document do not show routers so that the focus is on Layer 5 protocol aspects.
レイヤー3ピアリングは、このドキュメントの範囲外です。したがって、このドキュメントの数値にはルーターが表示されないため、レイヤー5プロトコルの側面に焦点が当てられます。
This document uses terminology defined in "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology" [RFC5486]. In addition to normative references included herein, readers may also find [RFC6405] informative.
このドキュメントでは、「マルチメディアインターコネクト（Speermint）用語のセッションピアリング（Speermint）用語」[RFC5486]で定義された用語を使用しています。本明細書に含まれる規範的な参照に加えて、読者は[RFC6405]に有益であることがあることもあります。
[RFC5486] is a key reference for the majority of the SPEERMINT-related terminology used in this document. However, some additional new terms are used here as follows in this section.
[RFC5486]は、このドキュメントで使用されているSpeermint関連の用語の大部分の重要な参照です。ただし、このセクションでは、次のように追加の新しい用語を使用しています。
A Session Border Controller (SBC) is referred to in Section 5. An SBC can contain a Signaling Function (SF), Signaling Path Border Element (SBE) and Data Path Border Element (DBE), and may perform the Lookup Function (LUF) and Location Routing Function (LRF), as described in Section 3. Whether the SBC performs one or more of these functions is, generally speaking, dependent upon how a SIP Service Provider (SSP) configures such a network element. In addition, requirements for an SBC can be found in [RFC5853].
セッションボーダーコントローラー（SBC）はセクション5で言及されています。SBCには、シグナリング関数（SF）、シグナリングパス境界要素（SBE）、およびデータパス境界要素（DBE）を含めることができ、ルックアップ関数（LUF）を実行できます。セクション3で説明されているように、ロケーションルーティング関数（LRF）。SBCがこれらの機能の1つ以上を実行するかどうかは、一般的に、SIPサービスプロバイダー（SSP）がそのようなネットワーク要素を構成する方法に依存します。さらに、SBCの要件は[RFC5853]に記載されています。
A carrier-of-record, as used in Section 6.1.2.2, is defined in [RFC5067]. That document describes the term as referring to the entity having discretion over the domain and zone content and acting as the registrant for a telephone number, as represented in ENUM. This can be as follows:
セクション6.1.2.2で使用されているキャリアの記録は、[RFC5067]で定義されています。その文書は、列挙に表されているように、ドメインとゾーンのコンテンツに対して裁量権を持ち、電話番号の登録者として行動しているエンティティを参照するという用語を説明しています。これは次のとおりです。
o the service provider to which the E.164 number was allocated for end user assignment, whether by the National Regulatory Authority (NRA) or the International Telecommunication Union (ITU), for instance, a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878), or
o E.164番号がエンドユーザーの割り当てに割り当てられたサービスプロバイダーは、国家規制当局（NRA）または国際通信連合（ITU）によって、「国際ネットワーク」（882）または「882）または「882）または」ユニバーサルパーソナルテレコミュニケーション（UPT） "（878）、または
o if the number is ported, the service provider to which the number was ported, or
o 番号が移植されている場合、番号が移植されたサービスプロバイダー、または
o where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network / Public Land Mobile Network (PSTN/PLMN) point-of-interconnect for the number.
o 番号がエンドユーザーに直接割り当てられている場合、エンドユーザー番号の譲受人が公開された電話ネットワーク /パブリックランドモバイルネットワーク（PSTN / PLMN）のポイントオブインターコネクトを提供することを選択したサービスプロバイダー。
It is understood that the definition of "carrier-of-record" within a given jurisdiction is subject to modification by national authorities.
特定の管轄区域内の「記録の運送業者」の定義は、国家当局による修正の対象となることが理解されています。
The following figure depicts the architecture and logical functions that form peering between two SSPs.
次の図は、2つのSSPの間でピアリングを形成するアーキテクチャと論理機能を示しています。
For further details on the elements and functions described in this figure, please refer to [RFC5486]. The following terms, which appear in Figure 1 and are documented in [RFC5486], are reproduced here for simplicity.
この図で説明する要素と機能の詳細については、[RFC5486]を参照してください。図1に表示され、[RFC5486]に文書化されている次の用語は、簡単にするためにここで再現されています。
o Data Path Border Element (DBE): A data path border element (DBE) is located on the administrative border of a domain through which the media associated with an inter-domain session flows. Typically, it provides media-related functions such as deep packet inspection and modification, media relay, and firewall-traversal support. The DBE may be controlled by the SBE.
o データパス境界要素（DBE）：データパス境界要素（DBE）は、ドメイン間セッションに関連するメディアが流れるドメインの管理境界にあります。通常、ディープパケットの検査と変更、メディアリレー、ファイアウォールトラバーサルサポートなど、メディア関連の機能を提供します。DBEはSBEによって制御される場合があります。
o E.164 Number Mapping (ENUM): See [RFC6116].
o E.164番号マッピング（列挙）：[RFC6116]を参照してください。
o Fully Qualified Domain Name (FQDN): See [RFC1035].
o 完全資格のドメイン名（FQDN）：[RFC1035]を参照してください。
o Location Routing Function (LRF): The Location Routing Function (LRF) determines, for the target domain of a given request, the location of the SF in that domain, and optionally develops other Session Establishment Data (SED) required to route the request to that domain. An example of the LRF may be applied to either example in Section 4.3.3 of [RFC5486]. Once the ENUM response or SIP 302 redirect is received with the destination's SIP URI, the LRF must derive the destination peer's SF from the FQDN in the domain portion of the URI. In some cases, some entity (usually a third party or federation) provides peering assistance to the Originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) peering as necessary.
o 位置ルーティング関数（LRF）：位置ルーティング関数（LRF）は、特定の要求のターゲットドメインについて、そのドメイン内のSFの位置を決定し、オプションでリクエストをにルーティングするために必要な他のセッション確立データ（SED）を開発しますそのドメイン。LRFの例は、[RFC5486]のセクション4.3.3のいずれかの例に適用できます。Enum ResponseまたはSIP 302リダイレクトが目的地のSIP URIで受信されたら、LRFはURIのドメイン部分のFQDNから宛先ピアのSFを導出する必要があります。場合によっては、一部のエンティティ（通常は第三者またはフェデレーション）がこの機能を提供することにより、発生するSSPに覗き見を提供します。支援エンティティは、必要に応じてピアリングを求める直接（[RFC5486]のセクション4.2.1）または間接（[RFC5486]のセクション4.2.2）に関連する情報を提供する場合があります。
o Lookup Function (LUF): The Lookup Function (LUF) determines, for a given request, the target domain to which the request should be routed. An example of an LUF is an ENUM [4] look-up or a SIP INVITE request to a SIP proxy providing redirect responses for peers. In some cases, some entity (usually a third party or federation) provides peering assistance to the Originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) peering as necessary.
o ルックアップ関数（LUF）：ルックアップ関数（LUF）は、特定の要求に対して、要求をルーティングするターゲットドメインを決定します。LUFの例は、ピアのリダイレクト応答を提供するSIPプロキシへの列挙[4]ルックアップまたはSIP招待リクエストです。場合によっては、一部のエンティティ（通常は第三者またはフェデレーション）がこの機能を提供することにより、発生するSSPに覗き見を提供します。支援エンティティは、必要に応じてピアリングを求める直接（[RFC5486]のセクション4.2.1）または間接（[RFC5486]のセクション4.2.2）に関連する情報を提供する場合があります。
o Real-time Transport Protocol (RTP): See [RFC3550].
o リアルタイムトランスポートプロトコル（RTP）：[RFC3550]を参照してください。
o Session Initiation Protocol (SIP): See [RFC3261].
o セッション開始プロトコル（SIP）：[RFC3261]を参照してください。
o Signaling Path Border Element (SBE): A signaling path border element (SBE) is located on the administrative border of a domain through which inter-domain session-layer messages will flow. Typically, it provides Signaling Functions such as protocol inter-working (for example, H.323 to SIP), identity and topology hiding, and Session Admission Control for a domain.
o シグナリングパス境界要素（SBE）：シグナリングパス境界要素（SBE）は、ドメイン間セッション層メッセージが流れるドメインの管理境界にあります。通常、プロトコルの相互作用（たとえば、H.323からSIPへのH.323）、アイデンティティとトポロジーの隠れ、およびドメインのセッション入場制御などのシグナリング機能を提供します。
o Signaling Function (SF): The Signaling Function (SF) performs routing of SIP requests for establishing and maintaining calls and in order to assist in the discovery or exchange of parameters to be used by the Media Function (MF). The SF is a capability of SIP processing elements such as SIP proxies, SBEs, and User Agents.
o シグナル伝達関数（SF）：シグナリング関数（SF）は、メディア関数（MF）で使用されるパラメーターの発見または交換を支援するために、通話を確立および維持するためのSIP要求のルーティングを実行します。SFは、SIPプロキシ、SBE、ユーザーエージェントなどのSIP処理要素の機能です。
o SIP Service Provider (SSP): A SIP Service Provider (SSP) is an entity that provides session services utilizing SIP signaling to its customers. In the event that the SSP is also a function of the SP, it may also provide media streams to its customers. Such an SSP may additionally be peered with other SSPs. An SSP may also interconnect with the PSTN.
o SIPサービスプロバイダー（SSP）：SIPサービスプロバイダー（SSP）は、SIPシグナリングを顧客に利用したセッションサービスを提供するエンティティです。SSPもSPの関数である場合、顧客にメディアストリームを提供することもあります。このようなSSPは、他のSSPでさらに覗くことがあります。SSPは、PSTNと相互接続することもできます。
+=============++ ++=============+
|| ||
+-----------+ +-----------+
| SBE | +-----+ | SBE |
| +-----+ | SIP |Proxy| | +-----+ |
| | LUF |<-|------>|ENUM | | | LUF | |
| +-----+ | ENUM |TN DB| | +-----+ |
SIP | | +-----+ | |
------>| +-----+ | DNS +-----+ | +-----+ |
| | LRF |<-|------>|FQDN | | | LRF | |
| +-----+ | |IP | | +-----+ |
| +-----+ | SIP +-----+ | +-----+ |
| | SF |<-|----------------|->| SF | |
| +-----+ | | +-----+ |
+-----------+ +-----------+
|| ||
+-----------+ +-----------+
RTP | DBE | RTP | DBE |
------>| |--------------->| |
+-----------+ +-----------+
|| ||
SSP1 Network || || SSP2 Network
+=============++ ++=============+
Reference Architecture
参照アーキテクチャ
Figure 1
図1
This document assumes that in order for a session to be established from a User Agent (UA) in the Originating (or Indirect) SSP's network to a UA in the Target SSP's network the following steps are taken:
このドキュメントは、セッションが発信（または間接）SSPのネットワークのユーザーエージェント（UA）からターゲットSSPのネットワーク内のUAに確立されるために、次の手順が取られることを前提としています。
1. Determine the Target or Indirect SSP via the LUF. (Note: If the target address represents an intra-SSP resource, the behavior is out of scope with respect to this document.)
1. LUFを介してターゲットまたは間接SSPを決定します。（注：ターゲットアドレスがSSP内リソースを表す場合、このドキュメントに関して動作は範囲外です。）
2. Determine the address of the SF of the Target SSP via the LRF.
2. LRFを介してターゲットSSPのSFのアドレスを決定します。
3. Establish the session.
3. セッションを確立します。
4. Exchange the media, which could include voice, video, text, etc.
4. 音声、ビデオ、テキストなどを含めることができるメディアを交換します。
5. End the session (BYE)
5. セッションを終了する（さようなら）
The Originating or Indirect SSP would perform steps 1-4, the Target SSP would perform step 4, and either one can perform step 5.
発信元または間接SSPはステップ1-4を実行し、ターゲットSSPはステップ4を実行し、どちらかがステップ5を実行できます。
In the case that the Target SSP changes, steps 1-4 would be repeated. This is reflected in Figure 1, which shows the Target SSP with its own peering functions.
ターゲットSSPが変更された場合、ステップ1〜4が繰り返されます。これは図1に反映されており、ターゲットSSPが独自のピアリング機能を備えたものを示しています。
Please also refer to Figure 1.
図1も参照してください。
o An SBE can contain a Signaling Function (SF).
o SBEには、シグナル伝達関数（SF）を含めることができます。
o An SF can perform a Lookup Function (LUF) and Location Routing Function (LRF).
o SFは、ルックアップ関数（LUF）とロケーションルーティング関数（LRF）を実行できます。
o As an additional consideration, a Session Border Controller, can contain an SF, SBE and DBE, and may act as both an LUF and LRF.
o 追加の考慮事項として、セッションボーダーコントローラーには、SF、SBE、およびDBEを含めることができ、LUFとLRFの両方として機能する場合があります。
o The following functions may communicate as follows in an example SSP network, depending upon various real-world implementations:
o 以下の機能は、さまざまな実際の実装に応じて、SSPネットワークの例で次のように通信する場合があります。
* SF may communicate with the LUF, LRF, SBE, and SF
* SFはLUF、LRF、SBE、およびSFと通信する場合があります
* LUF may communicate with the SF and SBE
* LUFはSFおよびSBEと通信する場合があります
* LRF may communicate with the SF and SBE
* LRFは、SFおよびSBEと通信する場合があります
This section describes the functions in more detail and provides some recommendations on the role they would play in a SIP call in a Layer 5 peering scenario.
このセクションでは、機能について詳しく説明し、レイヤー5ピアリングシナリオのSIPコールで演じる役割に関するいくつかの推奨事項を提供します。
Some of the information in this section is taken from [RFC6271] and is included here for continuity purposes. It is also important to refer to Section 3.2 of [RFC6404], particularly with respect to the use of IPsec and TLS.
このセクションの情報の一部は[RFC6271]から取得されており、継続性の目的でここに含まれています。また、特にIPSECおよびTLSの使用に関して、[RFC6404]のセクション3.2を参照することも重要です。
This section describes the procedures of the Originating or indirect SSP.
このセクションでは、発信または間接SSPの手順について説明します。
The purpose of the LUF is to determine the SF of the target domain of a given request and optionally to develop Session Establishment Data. It is important to note that the LUF may utilize the public e164.arpa ENUM root, as well as one or more private roots. When private roots are used, specialized routing rules may be implemented; these rules may vary depending upon whether an Originating or Indirect SSP is querying the LUF.
LUFの目的は、特定の要求のターゲットドメインのSFを決定し、オプションでセッション確立データを開発することです。LUFは、パブリックE164.ARPA enumルートと1つ以上の私的なルーツを利用できることに注意することが重要です。プライベートルーツを使用すると、専門的なルーティングルールが実装される場合があります。これらのルールは、発信元または間接的なSSPがLUFを照会しているかによって異なる場合があります。
When the Originating (or Indirect) SSP receives a request to communicate, it analyzes the target URI to determine whether the call needs to be routed internally or externally to its network. The analysis method is internal to the SSP; thus, outside the scope of SPEERMINT.
発信（または間接）SSPが通信の要求を受信すると、ターゲットURIを分析して、コールをそのネットワークに内部的にルーティングする必要があるかどうかを判断します。分析方法はSSPの内部です。したがって、Speermintの範囲外。
If the target address does not represent a resource inside the Originating (or Indirect) SSP's administrative domain or federation of domains, then the Originating (or Indirect) SSP performs a Lookup Function (LUF) to determine a target address, and then it resolves the call routing data by using the Location Routing Function (LRF).
ターゲットアドレスが発信（または間接）SSPの管理ドメインまたはドメインの連合内のリソースを表していない場合、発信元（または間接）SSPはルックアップ関数（LUF）を実行してターゲットアドレスを決定し、次に解決します。ロケーションルーティング関数（LRF）を使用して、ルーティングデータを呼び出します。
For example, if the request to communicate is for an im: or pres: URI type [RFC3861] [RFC3953], the Originating (or Indirect) SSP follows the procedures in [RFC3861]. If the highest priority supported URI scheme is sip: or sips:, the Originating (or Indirect) SSP skips to SIP DNS resolution in Section 5.1.3. Likewise, if the target address is already a sip: or sips: URI in an external domain, the Originating (or Indirect) SSP skips to SIP DNS resolution in Section 6.1.2.1. This may be the case, to use one example, with "sips:bob@biloxi.example.com".
たとえば、通信のリクエストがIM：またはpres：uri type [rfc3861] [rfc3953]の場合、[RFC3861]のプロシージャに従って発信（または間接）SSPが従います。サポートされている最優先のURIスキームがSIP：またはSIP：またはSIPである場合、セクション5.1.3でDNS解像度をSIPするために発信（または間接）SSPがスキップします。同様に、ターゲットアドレスが既にSIP：またはSIPS：URIが外部ドメインである場合、セクション6.1.2.1でDNS解像度をSIPするために発信（または間接）SSPがスキップします。これは、「sips：bob@biloxi.example.com」という1つの例を使用する場合があります。
If the target address corresponds to a specific E.164 address, the SSP may need to perform some form of number plan mapping according to local policy. For example, in the United States, a dial string beginning "011 44" could be converted to "+44"; in the United Kingdom, "00 1" could be converted to "+1". Once the SSP has an E.164 address, it can use ENUM.
ターゲットアドレスが特定のE.164アドレスに対応する場合、SSPはローカルポリシーに従って何らかの形式の計画マッピングを実行する必要がある場合があります。たとえば、米国では、「011 44」を開始するダイヤル文字列を「44」に変換できます。英国では、「00 1」は「1」に変換できます。SSPにE.164アドレスがあると、列挙を使用できます。
If an external E.164 address is the target, the Originating (or Indirect) SSP consults the public "User ENUM" rooted at e164.arpa, according to the procedures described in [RFC6116]. The SSP must query for the "E2U+sip" enumservice as described in [RFC3764], but may check for other enumservices. The Originating (or Indirect) SSP
外部E.164アドレスがターゲットである場合、[RFC6116]に記載されている手順に従って、発信（または間接）SSPがE164.ARPAに根付いた公開「ユーザー列挙」に相談します。[RFC3764]で説明されているように、SSPは「E2U SIP」Enumserviceをクエリする必要がありますが、他のEnumservicesをチェックする場合があります。発生（または間接）SSP
may consult a cache or alternate representation of the ENUM data rather than actual DNS queries. Also, the SSP may skip actual DNS queries if the Originating (or Indirect) SSP is sure that the target address country code is not represented in e164.arpa.
実際のDNSクエリではなく、列挙データのキャッシュまたは代替表現を参照することができます。また、SSPは、ターゲットアドレス国コードがE164.ARPAで表されていないことを確認している場合、実際のDNSクエリをスキップする場合があります。
If an im: or pres: URI is chosen based on an "E2U+im" [RFC3861] or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures for resolving these URIs to URIs for specific protocols such as SIP or Extensible Messaging and Presence Protocol (XMPP) as described in the previous section.
IM：またはpres：URIが「E2U IM」[RFC3861]または「E2U PRES」[RFC3953] Enumserverに基づいて選択されている場合、SSPは、SIPや拡張可能なメッセージングなどの特定のプロトコルのためにこれらのURIをURISに解決する手順に従います。前のセクションで説明されているように、存在プロトコル（XMPP）。
The Naming Authority Pointer (NAPTR) response to the ENUM lookup may be a SIP address of record (AOR) (such as "sips:bob@example.com") or SIP URI (such as "sips:bob@sbe1.biloxi.example.com"). In the case when a SIP URI is returned, the Originating (or Indirect) SSP has sufficient routing information to locate the Target SSP. In the case of when a SIP AoR is returned, the SF then uses the LRF to determine the URI for more explicitly locating the Target SSP.
Enum Lookupへの命名権限ポインター（NAPTR）の応答は、記録のSIPアドレス（aor）（「sips：bob@example.com」など）またはsip uri（「sips：bob@sbe1.biloxiなど）です。example.com "）。SIP URIが返された場合、ターゲットSSPを見つけるのに十分なルーティング情報が発生する（または間接的な）SSPがあります。SIP AORが返される場合、SFはLRFを使用してURIを決定し、ターゲットSSPをより明示的に検索します。
The LRF of an Originating (or Indirect) SSP analyzes target address and target domain identified by the LUF, and discovers the next-hop Signaling Function (SF) in a peering relationship. The resource to determine the SF of the target domain might be provided by a third party as in the assisted-peering case. The following sections define mechanisms that may be used by the LRF. These are not in any particular order and, importantly, not all of them have to be used.
起源の（または間接）SSPのLRFは、LUFによって識別されたターゲットアドレスとターゲットドメインを分析し、ピアーリング関係でネクストホップシグナル伝達関数（SF）を発見します。ターゲットドメインのSFを決定するためのリソースは、支援するケースのように第三者によって提供される場合があります。次のセクションでは、LRFが使用できるメカニズムを定義します。これらは特定の順序ではなく、重要なことに、すべてを使用する必要がないわけではありません。
The Originating (or Indirect) SSP uses the procedures in Section 4 of [RFC3263] to determine how to contact the receiving SSP. To summarize the [RFC3263] procedure: unless these are explicitly encoded in the target URI, a transport is chosen using NAPTR records, a port is chosen using SRV records, and an address is chosen using A or AAAA records.
発信（または間接）SSPは、[RFC3263]のセクション4の手順を使用して、受信SSPに接触する方法を決定します。[RFC3263]手順を要約するには：これらがターゲットURIで明示的にエンコードされていない限り、NAPTRレコードを使用してトランスポートが選択され、SRVレコードを使用してポートが選択され、AまたはAAAAレコードを使用して住所が選択されます。
When communicating with another SSP, entities compliant to this document should select a TLS-protected transport for communication from the Originating (or Indirect) SSP to the receiving SSP if available, as described further in Section 6.2.1.
別のSSPと通信する場合、このドキュメントに準拠したエンティティは、セクション6.2.1でさらに説明されているように、利用可能な場合、発信（または間接）SSPから受信SSPへの通信のためにTLS保護されたトランスポートを選択する必要があります。
If there are no End User ENUM records and the Originating (or Indirect) SSP cannot discover the carrier-of-record or if the Originating (or Indirect) SSP cannot reach the carrier-of-record via
エンドユーザーの列挙レコードがなく、発信元（または間接）SSPがキャリアの記録を発見できない場合、または発信元（または間接）SSPがキャリアの記録に到達できない場合
SIP peering, the Originating (or Indirect) SSP may deliver the call to the PSTN or reject it. Note that the Originating (or Indirect) SSP may forward the call to another SSP for PSTN gateway termination by prior arrangement using the local SIP proxy routing table.
SIP Peering、起源の（または間接）SSPは、PSTNへの呼び出しを配信するか、拒否する場合があります。発信（または間接）SSPは、ローカルSIPプロキシルーティングテーブルを使用して、事前の配置によりPSTNゲートウェイ終了の別のSSPにコールを転送できることに注意してください。
If so, the Originating (or Indirect) SSP rewrites the Request-URI to address the gateway resource in the Target SSP's domain and may forward the request on to that SSP using the procedures described in the remainder of these steps.
その場合、発信（または間接）SSPは、ターゲットSSPのドメインのゲートウェイリソースに対処するためにリクエスト-URIを書き換え、これらのステップの残りの手順で説明されている手順を使用してそのSSPにリクエストを転送することができます。
Communications between the LRF of two interconnecting SSPs may use DNS or statically provisioned IP addresses for reachability. Other inputs to determine the path may be code-based routing, method-based routing, time of day, least cost and/or source-based routing.
2つの相互接続SSPのLRF間の通信は、到達可能性のためにDNSまたは静的プロビジョニングIPアドレスを使用する場合があります。パスを決定する他の入力は、コードベースのルーティング、メソッドベースのルーティング、時刻、最小コスト、および/またはソースベースのルーティングなどです。
The purpose of the Signaling Function is to perform routing of SIP messages as well as optionally implement security and policies on SIP messages and to assist in discovery/exchange of parameters to be used by the Media Function (MF). The Signaling Function performs the routing of SIP messages. The SBE may be a back-to-back user agent (B2BUA) or it may act as a SIP proxy. Optionally, an SF may perform additional functions such as Session Admission Control, SIP Denial-of-Service protection, SIP Topology Hiding, SIP header normalization, SIP security, privacy, and encryption. The SF of an SBE can also process SDP payloads for media information such as media type, bandwidth, and type of codec; then, communicate this information to the media function.
シグナリング関数の目的は、SIPメッセージのルーティングを実行し、SIPメッセージにセキュリティとポリシーをオプションで実装し、メディア関数（MF）で使用するパラメーターの発見/交換を支援することです。信号関数は、SIPメッセージのルーティングを実行します。SBEは、連続したユーザーエージェント（B2BUA）であるか、SIPプロキシとして機能する場合があります。オプションで、SFは、セッション入場制御、SIPサービス拒否保護、SIPトポロジの隠れ、SIPヘッダー正規化、SIPセキュリティ、プライバシー、暗号化などの追加機能を実行する場合があります。SBEのSFは、メディアタイプ、帯域幅、コーデックの種類などのメディア情報のSDPペイロードを処理することもできます。次に、この情報をメディア機能に伝えます。
Depending on the security needs and trust relationships between SSPs, different security mechanisms can be used to establish SIP calls. These are discussed in the following subsections.
SSP間のセキュリティのニーズと信頼関係に応じて、さまざまなセキュリティメカニズムを使用してSIPコールを確立できます。これらについては、以下のサブセクションで説明します。
In certain deployments, the use of IPsec between the Signaling Functions of the originating and terminating domains can be used as a security mechanism instead of TLS. However, such IPsec use should be the subject of a future document as additional specification is necessary to use IPsec properly and effectively.
特定の展開では、発信ドメインと終端ドメインの信号関数間のIPSECの使用は、TLSの代わりにセキュリティメカニズムとして使用できます。ただし、IPSECを適切かつ効果的に使用するには追加の仕様が必要であるため、このようなIPSECの使用は将来のドキュメントの主題である必要があります。
In this scenario, the SFs are co-located in a physically secure location and/or are members of a segregated network. In this case, messages between the Originating and Terminating SSPs could be sent as clear text (unencrypted). However, even in these semi-trusted co-location facilities, other security or access control mechanisms may be appropriate, such as IP access control lists or other mechanisms.
このシナリオでは、SFSは物理的に安全な場所や隔離されたネットワークのメンバーであるために共同住宅されています。この場合、発信元と終了SSPの間のメッセージは、明確なテキスト（暗号化されていない）として送信できます。ただし、これらのセミトラストされたコロケーション施設でさえ、IPアクセス制御リストやその他のメカニズムなど、その他のセキュリティまたはアクセス制御メカニズムが適切な場合があります。
Once a trust relationship between the peers is established, the Originating (or Indirect) SSP sends the request.
ピア間の信頼関係が確立されると、発信（または間接）SSPがリクエストを送信します。
This section describes the Target SSP Procedures.
このセクションでは、ターゲットSSP手順について説明します。
The section defines the usage of TLS between two SSPs [RFC5246] [RFC5746] [RFC5878]. When the receiving SSP receives a TLS client hello, it responds with its certificate. The Target SSP certificate should be valid and rooted in a well-known certificate authority. The procedures to authenticate the SSP's originating domain are specified in [RFC5922].
このセクションでは、2つのSSP [RFC5246] [RFC5746] [RFC5878]の間のTLSの使用を定義します。受信SSPがTLSクライアントのHelloを受信すると、証明書で応答します。ターゲットSSP証明書は有効であり、よく知られている証明書当局に根ざしている必要があります。SSPの発信ドメインを認証する手順は、[RFC5922]で指定されています。
The SF of the Target SSP verifies that the Identity header is valid, corresponds to the message, corresponds to the Identity-Info header, and that the domain in the From header corresponds to one of the domains in the TLS client certificate.
ターゲットSSPのSFは、IDヘッダーが有効であり、メッセージに対応し、ID-INFOヘッダーに対応し、From HeaderのドメインがTLSクライアント証明書のドメインの1つに対応することを確認します。
As noted above in Section 6.1.3.2, some deployments may utilize IPsec rather than TLS.
上記のセクション6.1.3.2で述べたように、一部の展開はTLSではなくIPSECを利用する場合があります。
Once a trust relationship is established, the Target SSP is prepared to receive incoming SIP requests. For new requests (dialog forming or not), the receiving SSP verifies if the target (Request-URI) is a domain for which it is responsible. For these requests, there should be no remaining Route header field values. For in-dialog requests, the receiving SSP can verify that it corresponds to the top-most Route header field value.
信頼関係が確立されると、ターゲットSSPは着信SIPリクエストを受信する準備ができています。新しいリクエスト（ダイアログ形成のかどうか）の場合、ターゲット（リクエスト-URI）が責任を負うドメインである場合、受信SSPは検証されます。これらのリクエストでは、残りのルートヘッダーフィールド値はないはずです。ダイアログ内のリクエストの場合、受信SSPは、それが最上位ルートヘッダーフィールド値に対応することを確認できます。
The receiving SSP may reject incoming requests due to local policy. When a request is rejected because the Originating (or Indirect) SSP is not authorized to peer, the receiving SSP should respond with a 403 response with the reason phrase "Unsupported Peer".
受信SSPは、ローカルポリシーのために着信要求を拒否する場合があります。発信（または間接）SSPがピアを許可されていないために要求が拒否された場合、受信SSPは「サポートされていないピア」という理由で403の応答で応答する必要があります。
The purpose of the DBE [RFC5486] is to perform media-related functions such as media transcoding and media security implementation between two SSPs.
DBE [RFC5486]の目的は、2つのSSP間のメディアトランスコーディングやメディアセキュリティの実装などのメディア関連機能を実行することです。
An example of this is to transform a voice payload from one codec (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may perform media relaying, media security [RFC3711], privacy, and encryption.
この例は、音声ペイロードを1つのコーデック（G.711など）から別のコーデック（EVRCなど）に変換することです。さらに、MFは、メディアリレー、メディアセキュリティ[RFC3711]、プライバシー、および暗号化を実行する場合があります。
Peering must occur in a common IP address space, which is defined by the federation, which may be entirely on the public Internet, or some private address space [RFC1918]. The origination or termination networks may or may not entirely be in the same address space. If they are not, then a Network Address Translation (NAT) or similar may be needed before the signaling or media is presented correctly to the federation. The only requirement is that all associated entities across the peering interface are reachable.
ピアリングは、完全にパブリックインターネットまたは一部のプライベートアドレススペース[RFC1918]にある場合がある連邦によって定義される一般的なIPアドレススペースで発生する必要があります。オリジネーションまたは終了ネットワークは、完全に同じアドレス空間にある場合とそうでない場合があります。そうでない場合は、信号またはメディアが連邦に正しく提示される前に、ネットワークアドレス変換（NAT）などが必要になる場合があります。唯一の要件は、ピアリングインターフェイス全体のすべての関連エンティティが到達可能であることです。
The working group would like to thank John Elwell, Otmar Lendl, Rohan Mahy, Alexander Mayrhofer, Jim McEachern, Jean-Francois Mule, Jonathan Rosenberg, and Dan Wing for their valuable contributions to various versions of this document.
ワーキンググループは、ジョン・エルウェル、オトマル・レンドル、ローハン・マヒー、アレクサンダー・メールホーファー、ジム・マクチャン、ジャン・フランソワ・ミュール、ジョナサン・ローゼンバーグ、ダン・ウィングに感謝します。
The level (or types) of security mechanisms implemented between peering providers is, in practice, dependent upon on the underlying physical security of SSP connections. This means, as noted in Section 6.1.3.3, whether peering equipment is in a secure facility or not may bear on other types of security mechanisms that may be appropriate. Thus, if two SSPs peered across public Internet links, they are likely to use IPsec or TLS since the link between the two domains should be considered untrusted.
ピアリングプロバイダー間で実装されるセキュリティメカニズムのレベル（またはタイプ）は、実際には、SSP接続の基礎となる物理的セキュリティに依存しています。これは、セクション6.1.3.3で述べたように、ピアリング機器が安全な施設にあるかどうかは、適切な他のタイプのセキュリティメカニズムに耐えることができることを意味します。したがって、2つのSSPがパブリックインターネットリンクを覗き込んだ場合、2つのドメイン間のリンクは信頼されていないと見なされるため、IPSECまたはTLSを使用する可能性があります。
Many detailed and highly relevant security requirements for SPEERMINT have been documented in Section 5 of [RFC6271]. As a result, that document should be considered required reading.
Speermintの多くの詳細で非常に関連性の高いセキュリティ要件は、[RFC6271]のセクション5に記録されています。その結果、そのドキュメントは読みが必要であると見なされるべきです。
Additional and important security considerations have been documented separately in [RFC6404]. This document describes the many relevant security threats to SPEERMINT, as well the relevant countermeasures and security protections that are recommended to combat any potential threats or other risks. This includes a wide range of detailed threats in Section 2 of [RFC6404]. It also includes key requirements in Section 3.1 of [RFC6404], such as the requirement for the LUF and LRF to support mutual authentication for queries, among other requirements which are related to [RFC6271]. Section 3.2 of [RFC6404] explains how to meet these security requirements, and then Section 4 explores a wide range of suggested countermeasures.
追加の重要なセキュリティ上の考慮事項は、[RFC6404]に個別に文書化されています。このドキュメントでは、Speermintに対する多くの関連するセキュリティの脅威と、潜在的な脅威やその他のリスクと闘うために推奨される関連する対策とセキュリティ保護について説明しています。これには、[RFC6404]のセクション2に幅広い詳細な脅威が含まれます。また、[RFC6271]に関連する要件の中でも、クエリの相互認証をサポートするためのLUFやLRFの要件など、[RFC6404]のセクション3.1の主要な要件も含まれています。[RFC6404]のセクション3.2では、これらのセキュリティ要件を満たす方法について説明し、セクション4では、幅広い推奨対策を調査します。
Mike Hammer Cisco Systems Herndon, VA US EMail: mhammer@cisco.com
Mike Hammer Cisco Systems Herndon、VA US Eメール：mhammer@cisco.com
Hadriel Kaplan Acme Packet Burlington, MA US EMail: hkaplan@acmepacket.com
ハドリエルカプランACMEパケットバーリントン、マサチューセッツ州米国のメール：hkaplan@acmepacket.com
Sohel Khan, Ph.D. Comcast Cable Philadelphia, PA US EMail: sohel_khan@cable.comcast.com
ソヘル・カーン博士Comcastケーブルフィラデルフィア、ペンシルベニア州電子メール：sohel_khan@cable.comcast.com
Reinaldo Penno Juniper Networks Sunnyvale, CA US EMail: rpenno@juniper.net
Reinaldo Penno Juniper Networks Sunnyvale、CA US Eメール：rpenno@juniper.net
David Schwartz XConnect Global Networks Jerusalem Israel EMail: dschwartz@xconnnect.net
David Schwartz Xconnect Global Networks Erusalem Israel Email：dschwartz@xconnnect.net
Rich Shockey Shockey Consulting US EMail: Richard@shockey.us
Rich Shockey Shockey Consulting Us Email：richard@shockey.us
Adam Uzelac Global Crossing Rochester, NY US EMail: adam.uzelac@globalcrossing.com
Adam Uzelac Global Crossing Rochester、Ny US Eメール：adam.uzelac@globalcrossing.com
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[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月。
[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月。
[RFC3764] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[RFC3764] Peterson、J。、「セッション開始プロトコル（SIP）アドレスの登録登録」、RFC 3764、2004年4月。
[RFC3861] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[RFC3861]ピーターソン、J。、「インスタントメッセージングと存在のアドレス解決」、RFC 3861、2004年8月。
[RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for Presence Services", RFC 3953, January 2005.
[RFC3953] Peterson、J。、「プレゼンスサービスの電話番号マッピング（列挙）サービス登録」、RFC 3953、2005年1月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067] Lind、S。およびP. Pfautz、「インフラストラクチャ列要件」、RFC 5067、2007年11月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[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月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「輸送層のセキュリティ（TLS）再交渉表示拡張」、RFC 5746、2010年2月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「セッション開始プロトコル（SIP）セッション国境管理（SBC）の要件」、RFC 5853、4月2010年。
[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, May 2010.
[RFC5878] Brown、M。およびR. Housley、「輸送層セキュリティ（TLS）認証拡張」、RFC 5878、2010年5月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、Lawrence、S。、およびA. Jeffrey、「セッション開始プロトコル（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011.
[RFC6116] Bradner、S.、Conroy、L。、およびK. Fujiwara、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）（ENUM）」、RFC 6116、2011年3月。
[RFC6271] Mule, J-F., "Requirements for SIP-Based Session Peering", RFC 6271, June 2011.
[RFC6271]ラバ、J-F。、「SIPベースのセッションピアリングの要件」、RFC 6271、2011年6月。
[RFC6404] Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, "Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures", RFC 6404, November 2011.
[RFC6404] Seedorf、J.、Niccolini、S.、Chen、E。、およびH. Scholz、「マルチメディアインターコネクト（Speermint）セキュリティの脅威と提案された対策のセッションピアリング」、RFC 6404、2011年11月。
[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月。
[RFC6405] Uzelac, A., Ed. and Y. Lee, Ed., "Voice over IP (VoIP) SIP Peering Use Cases", RFC 6405, November 2011.
[RFC6405] Uzelac、A.、ed。Y. Lee、ed。、「Voice over IP（VoIP）SIP Pearing Use Case」、RFC 6405、2011年11月。
Authors' Addresses
著者のアドレス
Daryl Malas (editor) CableLabs Louisville, CO US
ダリル・マラス（編集者）ケーブルラブスルイビル、コロラド
EMail: d.malas@cablelabs.com
Jason Livingood (editor) Comcast Philadelphia, PA US
Jason Livingood（編集者）Comcastフィラデルフィア、ペンシルベニア州米国
EMail: Jason_Livingood@cable.comcast.com