[要約] RFC 6405は、VoIP SIPピアリングの使用例に関するガイドラインであり、異なるVoIPネットワーク間での相互接続を促進することを目的としています。
Internet Engineering Task Force (IETF) A. Uzelac, Ed.
Request for Comments: 6405 Global Crossing
Category: Informational Y. Lee, Ed.
ISSN: 2070-1721 Comcast Cable
November 2011
Voice over IP (VoIP) SIP Peering Use Cases
Voice over IP（VoIP）SIPピアリングユースケース
Abstract
概要
This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub-categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today.
このドキュメントは、セッション開始プロトコル（SIP）ピアリングのための多くの一般的な音声（VOIP）ユースケースを示しています。これらのユースケースは、静的およびオンデマンドに分類され、さらにサブカテゴリ化されて直接および間接に分類されます。これらのユースケースは網羅的なセットではなく、今日展開されている最も一般的なユースケースです。
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/rfc6405.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6405で取得できます。
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. Reference Architecture ..........................................3
4. Contexts of Use Cases ...........................................4
5. Use Cases .......................................................4
5.1. Static Peering Use Cases ...................................5
5.2. Static Direct Peering Use Case .............................5
5.2.1. Administrative Characteristics .....................10
5.2.2. Options and Nuances ................................10
5.3. Static Direct Peering Use Case - Assisting LUF and LRF ....11
5.3.1. Administrative Characteristics .....................12
5.3.2. Options and Nuances ................................12
5.4. Static Indirect Peering Use Case - Assisting LUF and LRF ..12
5.4.1. Administrative Characteristics .....................19
5.4.2. Options and Nuances ................................19
5.5. Static Indirect Peering Use Case ..........................19
5.5.1. Administrative Characteristics .....................20
5.5.2. Options and Nuances ................................21
5.6. On-Demand Peering Use Case ................................21
5.6.1. Administrative Characteristics .....................21
5.6.2. Options and Nuances ................................21
6. Acknowledgments ................................................22
7. Security Considerations ........................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
This document describes important Voice over IP (VoIP) use cases for SIP-based [RFC3261] peering. These use cases are determined by the Session PEERing for Multimedia INTerconnect (SPEERMINT) working group and will assist in identifying requirements and other issues to be considered for future resolution by the working group.
このドキュメントでは、SIPベースの[RFC3261]ピアリングの重要な音声（VOIP）ユースケースについて説明しています。これらのユースケースは、マルチメディアインターコネクト（Speermint）ワーキンググループのセッションピアリングによって決定され、ワーキンググループによる将来の解決のために考慮される要件やその他の問題を特定するのに役立ちます。
Only use cases related to VoIP are considered in this document. Other real-time SIP communications use cases, like Instant Messaging (IM), video chat, and presence are out of scope for this document.
このドキュメントでは、VOIPに関連するユースケースのみが考慮されます。インスタントメッセージング（IM）、ビデオチャット、存在感など、その他のリアルタイムSIP通信ユースケースは、このドキュメントの範囲外です。
The use cases contained in this document are described as comprehensive as possible, but should not be considered the exclusive set of use cases.
このドキュメントに含まれるユースケースは、可能な限り包括的であると説明されていますが、排他的なユースケースと見なされるべきではありません。
This document uses terms defined in [RFC5486]. Please refer to it for definitions.
このドキュメントでは、[RFC5486]で定義された用語を使用します。定義については、それを参照してください。
The diagram below provides the reader with a context for the VoIP use cases in this document. Terms such as SIP Service Provider (SSP), Lookup Function (LUF), Location Routing Function (LRF), Signaling Path Border Element (SBE), and Data Path Border Element (DBE) are defined in [RFC5486].
以下の図は、このドキュメントのVoIPユースケースのコンテキストを読者に提供します。SIPサービスプロバイダー（SSP）、ルックアップ関数（LUF）、ロケーションルーティング関数（LRF）、シグナリングパス境界要素（SBE）、データパス境界要素（DBE）などの用語は、[RFC5486]で定義されています。
The Originating SSP (O-SSP) is the SSP originating a SIP request. The Terminating SSP (T-SSP) is the SSP terminating the SIP request originating from the O-SSP. The assisting LUF and LRF Provider offer LUF and LRF services to the O-SSP. The Indirect SSP (I-SSP) is the SSP providing indirect peering service(s) to the O-SSP to connect to the T-SSP.
発生するSSP（O-SSP）は、SIPリクエストを発信するSSPです。終了SSP（T-SSP）は、O-SSPから発生するSIPリクエストを終了するSSPです。ASSISTING LUFおよびLRFプロバイダーは、O-SSPにLUFおよびLRFサービスを提供します。間接SSP（I-SSP）は、T-SSPに接続するためにO-SSPに間接的なピアリングサービスを提供するSSPです。
+--------------------+------------------------+--------------------+
| Originating SSP | Assisting LUF and LRF | Terminating SSP |
| Domain | Provider Domain | Domain |
| | | |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| |O-LUF| |O-LRF| | |A-LUF | | A-LRF| | |T-LUF| |T-LRF| |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| | | |
| +-------+ +-----+ +------------------------+ +-----+ +-------+ |
| |O-Proxy| |O-SBE| | Indirect SSP Domain | |T-SBE| |T-Proxy| |
| +-------+ +-----+ | | +-----+ +-------+ |
| | +-----+ +-----+ | |
| +---+ +-----+ | |O-SBE| |O-DBE| | +-----+ +---+ |
| |UAC| |O-DBE| | +-----+ +-----+ | |T-DBE| |UAS| |
| +---+ +-----+ | | +-----+ +---+ |
| | | |
+--------------------+------------------------+--------------------+
General Overview
総括
Figure 1
図1
Note that some elements included in Figure 1 are optional.
図1に含まれるいくつかの要素はオプションであることに注意してください。
Use cases are sorted into two general groups: static and on-demand peering [RFC5486]. Each group can be further sub-divided into Direct Peering and Indirect Peering [RFC5486]. Although there may be some overlap among the use cases in these categories, there are different requirements between the scenarios. Each use case must specify a basic set of required operations to be performed by each SSP when peering.
ユースケースは、静的およびオンデマンドピアリング[RFC5486]の2つの一般的なグループに分類されます。各グループは、さらに直接ピアリングおよび間接的なピアリング[RFC5486]に細分化できます。これらのカテゴリのユースケースの間にはある程度の重複があるかもしれませんが、シナリオ間に異なる要件があります。各ユースケースは、ピアリング時に各SSPが実行するために必要な操作の基本セットを指定する必要があります。
These can include:
これらには次のものが含まれます。
o Peer Discovery - Peer discovery via a Lookup Function (LUF) to determine the Session Establishment Data (SED) [RFC5486] of the request. In VoIP use cases, a request normally contains a phone number. The O-SSP will input the phone number to the LUF and the LUF will normally return a SIP address of record (AOR) [RFC3261] that contains a domain name.
o ピアディスカバリー - リクエストのセッション確立データ（SED）[RFC5486]を決定するためのルックアップ関数（LUF）を介したピアディスカバリー。VoIPユースケースでは、通常、リクエストに電話番号が含まれています。O-SSPは電話番号をLUFに入力し、LUFは通常、ドメイン名を含むSIPレコード（AOR）[RFC3261]を返します。
o Next-Hop Routing Determination - Resolving the SED information is necessary to route the request to the T-SSP. The LRF is used for this determination. After obtaining the SED, the O-SSP may use the standard procedure defined in [RFC3263] to discover the next-hop address.
o Next-Hopルーティングの決定 - リクエストをT-SSPにルーティングするには、SED情報の解決が必要です。LRFは、この決定に使用されます。SEDを取得した後、O-SSPは[RFC3263]で定義された標準手順を使用して、次のホップアドレスを発見できます。
o Call setup - SSPs that are interconnecting to one another may also define specifics on what peering policies need to be used when contacting the next hop in order to a) reach the next hop at all and b) prove that the sender is a legitimate peering partner. Examples: hard-code transport (TCP/UDP/TLS), non-standard port number, specific source IP address (e.g., in a private Layer 3 network), which TLS client certificate [RFC5246] to use, and other authentication schemes.
o コールセットアップ -相互接続を互いに相互接続しているSSPは、次のホップに連絡するときに使用する必要があるピアリングポリシーの詳細を定義することもできます。。例：ハードコードトランスポート（TCP/UDP/TLS）、非標準ポート番号、特定のソースIPアドレス（例：プライベートレイヤー3ネットワーク）、TLSクライアント証明書[RFC5246]、およびその他の認証スキーム。
o Call reception - This step ensures that the type of relationship (static or on-demand, indirect or direct) is understood and acceptable. For example, the receiving SBE needs to determine whether the INVITE it received really came from a trusted member.
o コールレセプション - このステップにより、関係のタイプ（静的またはオンデマンド、間接または直接）が理解され、許容できることが保証されます。たとえば、受信SBEは、受け取った招待が本当に信頼できるメンバーから来たかどうかを判断する必要があります。
Please note there are intra-domain message flows within the use cases to serve as supporting background information. Only inter-domain communications are germane to this document.
サポートする背景情報として機能するために、ユースケース内にドメイン内のメッセージフローがあることに注意してください。このドキュメントには、ドメイン間通信のみが密接に関係しています。
Static peering [RFC5486] describes the use case when two SSPs form a peering relationship with some form of association established prior to the exchange of traffic. Pre-association is a prerequisite to static peering. Static peering is used in cases when two peers want a consistent and tightly controlled approach to peering. In this scenario, a number of variables, such as an identification method (remote proxy IP address) and Quality-of-Service (QoS) parameters, can be defined upfront and known by each SSP prior to peering.
静的ピアリング[RFC5486]は、トラフィックの交換前に確立された何らかの形の関連性と2つのSSPがピアリング関係を形成する場合のユースケースを説明します。前協会は静的ピアリングの前提条件です。静的ピアリングは、2人のピアがピアリングに対する一貫した緊密に制御されたアプローチを望んでいる場合に使用されます。このシナリオでは、識別方法（リモートプロキシIPアドレス）やサービス品質（QOS）パラメーターなどの多くの変数を前もって定義し、ピアリング前に各SSPで既知で定義できます。
This is the simplest form of a peering use case. Two SSPs negotiate and agree to establish a SIP peering relationship. The peer connection is statically configured and the peer SSPs are directly connected. The peers may exchange interconnection parameters such as Differentiated Service Code Point (DSCP) [RFC2474] policies, the maximum number of requests per second, and proxy location prior to establishing the interconnection. Typically, the T-SSP only accepts traffic originating directly from the trusted peer.
これは、ピアリングユースケースの最も単純な形式です。2人のSSPが交渉し、SIPピアリング関係を確立することに同意します。ピア接続が静的に構成され、ピアSSPが直接接続されます。ピアは、差別化されたサービスコードポイント（DSCP）[RFC2474]ポリシー、1秒あたりの最大リクエスト数、および相互接続を確立する前のプロキシロケーションなどの相互接続パラメーターを交換できます。通常、T-SSPは、信頼できるピアから直接発信されるトラフィックのみを受け入れます。
+--------------------+ +---------------------+
| O-SSP | | T-SSP |
| +-----+ | | +-----+ |
| |O-LUF| | | |T-LUF| |
| |O-LRF| | | /|T-LRF| |
| /+-----+\ | | / +-----+ |
| (2) (4,5,6) | | / |
| / \ | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=====(12)====+T-DBE|=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering Use Case
静的な直接ピアリングユースケース
Figure 2
図2
The following is a high-level depiction of the use case:
以下は、ユースケースの高レベルの描写です。
1. The User Agent Client (UAC) initiates a call via SIP INVITE to O-Proxy. O-Proxy is the home proxy for UAC.
1. ユーザーエージェントクライアント（UAC）は、SIP招待状を介してO-Proxyへの通話を開始します。O-ProxyはUACのホームプロキシです。
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
Note that UAC inserted its Fully Qualified Domain Name (FQDN) in the VIA and CONTACT headers. This example assumes that UAC has its own FQDN.
UACは、VIAおよび連絡先ヘッダーに完全に適格なドメイン名（FQDN）を挿入したことに注意してください。この例は、UACに独自のFQDNがあることを前提としています。
2. UAC knows the User Agent Server's (UAS's) TN, but does not know UAS's domain. It appends its own domain to generate the SIP URI in the Request-URI and TO header. O-Proxy checks the Request-URI and discovers that the Request-URI contains the user parameter "user=phone". This parameter signifies that the Request-URI is a phone number. So O-Proxy will extract the TN from the Request-URI and query the LUF for SED information from a routing database. In this example, the LUF is an ENUM [RFC6116] database. The ENUM entry looks similar to this:
2. UACは、ユーザーエージェントサーバー（UAS）TNを知っていますが、UASのドメインを知りません。それは独自のドメインを追加して、リクエスト-URIでSIP URIを生成し、ヘッダーにします。O-ProxyはリクエストURIをチェックし、リクエスト-URIにユーザーパラメーター「ユーザー=電話」が含まれていることを発見します。このパラメーターは、リクエスト-URIが電話番号であることを意味します。したがって、O-Proxyはリクエスト-URIからTNを抽出し、ルーティングデータベースからSED情報をlufに照会します。この例では、LUFは列挙[RFC6116]データベースです。列挙エントリはこれに似ています。
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@example.net!" . )
$ origin 0.0.1.0.5.5.5.5.7.1.9.1.e164.arpa。in naptr（10 100 "u" "e2u sip" "！^。*$！sip：19175550100@example.net！"）
This SED data can be provisioned by O-SSP or populated by the T-SSP.
このSEDデータは、O-SSPがプロビジョニングするか、T-SSPが入力することもできます。
3. O-Proxy examines the SED and discovers the domain is external. Given the O-Proxy's internal routing policy, O-Proxy decides to use O-SBE to reach T-SBE. O-Proxy routes the INVITE request to O-SBE and adds a Route header that contains O-SBE.
3. O-ProxyはSEDを調べ、ドメインが外部であることを発見します。O-Proxyの内部ルーティングポリシーを考えると、O-ProxyはO-SBEを使用してT-SBEに到達することにしました。O-Proxyは招待リクエストをO-SBEにルーティングし、O-SBEを含むルートヘッダーを追加します。
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
4. O-SBE receives the requests and pops the top entry of the Route header that contains "o-sbe1.example.com". O-SBE examines the Request-URI and does an LRF for "example.net". In this example, the LRF is a Naming Authority Pointer (NAPTR) DNS query [RFC3403] of the domain name. O-SBE receives a NAPTR response from the LRF. The response looks similar to this:
4. o-sbeはリクエストを受け取り、「o-sbe1.example.com」を含むルートヘッダーのトップエントリをポップします。o-sbeはリクエスト-URIを調べ、「embler.net」のLRFを実行します。この例では、LRFはドメイン名の命名権限ポインター（NAPTR）DNSクエリ[RFC3403]です。o-sbeは、LRFからNAPTR応答を受け取ります。応答はこれに似ています：
IN NAPTR ( 50 50 "S" "SIP+D2T" "" _sip._tcp.t-sbe.example.net. )
in naptr（50 50 "s" "sip d2t" "" _sip._tcp.t-sbe.example.net。）
IN NAPTR ( 90 50 "S" "SIP+D2U" "" _sip._udp.t-sbe.example.net. )
in naptr（90 50 "s" "sip d2u" "" _sip._udp.t-sbe.example.net。）
5. Given the lower order for TCP in the NAPTR response, O-SBE decides to use TCP as the transport protocol, so it sends an SRV DNS query for the SRV record [RFC2782] for "_sip._tcp.t-sbe.example.net." to O-LRF.
5. NAPTR応答におけるTCPの低次を考えると、O-SBEはTCPを輸送プロトコルとして使用することを決定するため、「_sip._tcp.t-sbe.example.net」のSRVレコード[RFC2782]のSRV DNSクエリを送信します。。」o-lrfへ。
;; priority weight port target IN SRV 0 2 5060 t-sbe1.example.net. IN SRV 0 1 5060 t-sbe2.example.net.
;;SRV 0 2 5060 T-sbe1.example.netの優先ウェイトポートターゲット。in srv 0 1 5060 t-sbe2.example.net。
6. Given the higher weight for "t-sbe1.example.net", O-SBE sends an A record DNS query for "t-sbe1.example.net." to get the A record:
6. 「t-sbe1.example.net」の重みが高いと、o-sbeは「t-sbe1.example.net」のレコードDNSクエリを送信します。レコードを取得するには：
;; DNS ANSWER t-sbe1.example.net. IN A 192.0.2.100 t-sbe1.example.net. IN A 192.0.2.101
;;dnsはt-sbe1.example.netに回答します。192.0.2.100 t-sbe1.example.net。192.0.2.101で
7. O-SBE sends the INVITE to T-SBE. O-SBE is the egress point to the O-SSP domain, so it should ensure subsequent mid-dialog requests traverse via itself. If O-SBE chooses to act as a back-to-back user agent (B2BUA) [RFC3261], it will generate a new INVITE request in next step. If O-SBE chooses to act as a proxy, it should record-route to stay in the call path. In this example, O-SBE is a B2BUA.
7. o-sbeは招待をt-sbeに送ります。o-sbeは、o-sspドメインの出力ポイントであるため、それ自体を介して後続の中間要求を横断することを保証する必要があります。O-Sbeが連続したユーザーエージェント（B2BUA）[RFC3261]として機能することを選択した場合、次のステップで新しい招待リクエストが生成されます。o-sbeがプロキシとして機能することを選択した場合、コールパスにとどまることを記録する必要があります。この例では、o-sbeはB2BUAです。
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
Note that O-SBE may re-write the Request-URI with the target domain in the SIP URI. Some proxy implementations will only accept the request if the Request-URI contains their own domains.
o-sbeは、SIP URIのターゲットドメインを使用してリクエスト-URIを書き直すことができることに注意してください。一部のプロキシ実装は、リクエスト-URIに独自のドメインが含まれている場合にのみリクエストを受け入れます。
8. T-SBE determines the called party home proxy and directs the call to the called party. T-SBE may use ENUM lookup or other internal mechanism to locate the home proxy. If T-SSP uses ENUM lookup, this internal ENUM entry is different from the external ENUM entry populated for O-SSP. In this example, the internal ENUM query returns the UAS's home proxy.
8. T-sbeは、呼び出されたパーティーのホームプロキシを決定し、呼び出されたパーティーに電話をかけます。T-sbeは、列挙ルックアップまたはその他の内部メカニズムを使用して、ホームプロキシを見つけます。T-sspが列挙ルックアップを使用する場合、この内部列挙エントリは、O-SSPに入力された外部の列挙エントリとは異なります。この例では、内部列挙クエリはUASのホームプロキシを返します。
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@t-proxy.example.net!" . )
$ origin 0.0.1.0.5.5.5.5.7.1.9.1.e164.arpa。in naptr（10 100 "u" "e2u sip" "！^。*$！sip：19175550100@t-proxy.example.net！"。）
9. T-SBE receives the NAPTR record, and following the requirements in [RFC3263], queries DNS for the SRV records indicated by the NAPTR result. Not finding any, the T-SBE then queries DNS for the A record of domain "t-proxy.example.net.".
9. T-sbeはNAPTRレコードを受信し、[RFC3263]の要件に従って、NAPTRの結果で示されたSRVレコードのDNSのクエリです。T-sbeは何も見つかりませんでした。その後、ドメイン「t-proxy.example.net」のレコードのDNSをクエリします。
;; DNS ANSWER t-proxy.example.net. IN A 192.0.2.2
;;DNS Answer t-proxy.example.net。192.0.2.2で
10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to UAS's home proxy:
10. T-sbeはB2BUAなので、新しい招待状を生成し、UASのホームプロキシに送信します。
INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 7
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>
11. Finally, UAS's home proxy forwards the INVITE request to the UAS.
11. 最後に、UASのHome Proxyは、招待リクエストをUASに転送します。
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 6
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>
12. RTP is established between the UAC and UAS. Note that the media shown in Figure 2 passes through O-DBE and T-DBE, but the use of DBE is optional.
12. RTPはUACとUASの間に確立されます。図2に示されているメディアはO-dbeとt-dbeを通過しますが、DBEの使用はオプションであることに注意してください。
The static direct peering use case is typically implemented in a scenario where there is a strong degree of trust between the two administrative domains. Both administrative domains typically sign a peering agreement that states clearly the policies and terms.
静的直接ピアリングユースケースは、通常、2つの管理ドメイン間に強い信頼があるシナリオに実装されます。両方の管理ドメインは、通常、ポリシーと用語を明確に述べるピアリング契約に署名します。
In Figure 2, O-SSP and T-SSP peer via SBEs. Normally, the operator will deploy the SBE at the edge of its administrative domain. The signaling traffic will pass between two networks through the SBEs. The operator has many reasons to deploy an SBE. For example, the O-SSP may use [RFC1918] addresses for their UA and proxies. These addresses are not routable in the target network. The SBE can perform a NAT function. Also, the SBE eases the operation cost for deploying or removing Layer 5 network elements. Consider the deployment architecture where multiple proxies connect to a single SBE. An operator can add or remove a proxy without coordinating with the peer operator. The peer operator "sees" only the SBE. As long as the SBE is maintained in the path, the peer operator does not need to be notified.
図2では、SBEを介したO-SSPおよびT-SSPピア。通常、オペレーターは、管理ドメインの端にSBEを展開します。信号トラフィックは、SBEを介して2つのネットワーク間を通過します。オペレーターには、SBEを展開する多くの理由があります。たとえば、O-SSPはUAおよびプロキシに[RFC1918]アドレスを使用する場合があります。これらのアドレスは、ターゲットネットワークでルーティングできません。SBEはNAT関数を実行できます。また、SBEは、レイヤー5ネットワーク要素を展開または削除するための操作コストを緩和します。複数のプロキシが単一のSBEに接続する展開アーキテクチャを検討してください。オペレーターは、ピアオペレーターと調整せずにプロキシを追加または削除できます。ピアオペレーターはSBEのみを「見る」。SBEがパスに維持されている限り、ピアオペレーターに通知する必要はありません。
When an operator deploys SBEs, the operator is required to advertise the SBE to the peer LRF so that the peer operator can locate the SBE and route the traffic to the SBE accordingly.
オペレーターがSBEを展開する場合、オペレーターはSBEをピアLRFに宣伝する必要があり、ピアオペレーターがSBEを見つけて、それに応じてトラフィックをSBEにルーティングできるようにします。
SBE deployment is a decision within an administrative domain. Either one or both administrative domains can decide to deploy SBE(s). To the peer network, most important is to identify the next-hop address. This decision does not affect the network's ability to identify the next-hop address.
SBE展開は、管理ドメイン内の決定です。1つまたは両方の管理ドメインがSBEを展開することを決定できます。ピアネットワークにとって、最も重要なのは、Next-Hopアドレスを特定することです。この決定は、ネットホップアドレスを識別するネットワークの能力に影響しません。
This use case shares many properties with the Static Direct Peering Use Case Section 5.2. There must exist a pre-association between the O-SSP and T-SSP. The difference is O-SSP will use the Assisting LUF/ LRF Provider for LUF and LRF. The LUF/LRF Provider stores the SED to reach T-SSP and provides it to O-SSP when O-SSP requests it.
このユースケースは、静的な直接ピアリングユースケースセクション5.2と多くのプロパティを共有しています。O-SSPとT-SSPの間には事前分類が存在する必要があります。違いは、O-SSPがLUFおよびLRFにASSISTING LUF/ LRFプロバイダーを使用することです。LUF/LRFプロバイダーは、SEDを保存してT-SSPに到達し、O-SSPが要求したときにO-SSPに提供します。
+-----------------+
|LUF/LRF Provider |
| |
| +-------+ |
| +-+ A-LUF | |
| / | A-LRF | |
+--------------------+ / ++-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +------------/(4,5,6) | +-----+ |
| / | / | |T-LUF| |
| (2) +-+/ | +-|T-LRF| |
| / / | | / +-----+ |
| / / | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=======(12)======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering with Assisting LUF and LRF
LUFとLRFを支援する静的直接ピアリング
Figure 3
図3
The call flow looks almost identical to Static Direct Peering Use Case except that Steps 2, 4, 5, and 6 involve the LUF/LRF Provider instead of happening in O-SSP domain.
コールフローは、ステップ2、4、5、および6がO-SSPドメインで発生するのではなく、LUF/LRFプロバイダーに関与することを除いて、静的な直接ピアリングユースケースとほぼ同じに見えます。
Similar to Static Direct Peering Use Case, the O-DBE and T-DBE in Figure 3 are optional.
静的な直接ピアリングユースケースと同様に、図3のO-DBEとT-DBEはオプションです。
The LUF/LRF Provider supplies the LUF and LRF services for the O-SSP. Taken together, the LUF/LRF Provider, O-SSP, and T-SSP form a trusted administrative domain. To reach the T-SSP, the O-SSP must still require pre-arranged agreements for the peer relationship with the T-SSP. The Layer 5 policy is maintained in the O-SSP and T-SSP domains, and the LUF/LRF Provider may not be aware of any Layer 5 policy between the O-SSP and T-SSP.
LUF/LRFプロバイダーは、O-SSPのLUFおよびLRFサービスを提供します。まとめると、LUF/LRFプロバイダー、O-SSP、およびT-SSPが信頼できる管理ドメインを形成します。T-SSPに到達するには、O-SSPには、T-SSPとのピア関係のために事前に配置された契約を必要とする必要があります。レイヤー5ポリシーはO-SSPおよびT-SSPドメインで維持されており、LUF/LRFプロバイダーは、O-SSPとT-SSPの間のレイヤー5ポリシーを認識していない場合があります。
A LUF/LRF Provider can serve multiple administrative domains. The LUF/LRF Provider typically does not share SED from one administrative domain to another administrative domain without appropriate permission.
LUF/LRFプロバイダーは、複数の管理ドメインにサービスを提供できます。LUF/LRFプロバイダーは通常、適切な許可なしに、ある管理ドメインから別の管理ドメインにSEDを共有しません。
The LUF/LRF Provider can use multiple methods to provide SED to the O-SSP. The most commonly used are an ENUM lookup and a SIP Redirect. The O-SSP should negotiate with the LUF/LRF Provider regarding which query method it will use prior to sending a request to the LUF/LRF Provider.
LUF/LRFプロバイダーは、複数の方法を使用してO-SSPにSEDを提供できます。最も一般的に使用されるのは、列挙ルックアップとSIPリダイレクトです。O-SSPは、LUF/LRFプロバイダーにリクエストを送信する前に、どのクエリメソッドを使用するかについて、LUF/LRFプロバイダーと交渉する必要があります。
The LUF/LRF Providers must be populated with the T-SSP's AORs and SED. Currently, this procedure is non-standardized and labor intensive. A more detailed description of this problem has been documented in the work in progress [DRINKS].
LUF/LRFプロバイダーには、T-SSPのAORとSEDを入力する必要があります。現在、この手順は標準化されておらず、労働集約的です。この問題のより詳細な説明は、進行中の作業[飲み物]に文書化されています。
The difference between a Static Direct Use Case and a Static Indirect Use Case lies within the Layer 5 relationship maintained by the O-SSP and T-SSP. In the Indirect use case, the O-SSP and T-SSP do not have direct Layer 5 connectivity. They require one or multiple Indirect Domains to assist with routing the SIP messages and possibly the associated media.
静的な直接ユースケースと静的間接ユースケースの違いは、O-SSPとT-SSPによって維持されるレイヤー5関係内にあります。間接的なユースケースでは、O-SSPとT-SSPには直接レイヤー5接続がありません。SIPメッセージと関連するメディアのルーティングを支援するために、1つまたは複数の間接ドメインが必要です。
In this use case, the O-SSP and T-SSP want to form a peer relationship. For some reason, the O-SSP and T-SSP do not have direct Layer 5 connectivity. The reasons may vary, for example,
このユースケースでは、O-SSPとT-SSPはピア関係を形成したいと考えています。何らかの理由で、O-SSPとT-SSPには直接レイヤー5接続がありません。たとえば、理由は異なる場合があります
business demands and/or domain policy controls. Due to this indirect relationship, the signaling will traverse from the O-SSP through one or multiple I-SSPs to reach the T-SSP.
ビジネスの要求および/またはドメインポリシー管理。この間接的な関係により、シグナリングはO-SSPから1つまたは複数のI-SSPを介してT-SSPに到達します。
In addition, the O-SSP is using a LUF/LRF Provider. This LUF/LRF Provider stores the T-SSP's SED pre-populated by the T-SSP. One important motivation to use the LUF/LRF Provider is that the T-SSP only needs to populate its SED once to the provider. Using an LUF/ LRF Provider allows the T-SSP to populate its SED once, while any O-SSP T-SSP's SED can use this LUF/LRF Provider. Current practice has shown that it is rather difficult for the T-SSP to populate its SED to every O-SSP who must reach the T-SSP's subscribers. This is especially true in the Enterprise environment.
さらに、O-SSPはLUF/LRFプロバイダーを使用しています。このLUF/LRFプロバイダーは、T-SSPによって事前に入力されたT-SSPのSEDを保存します。LUF/LRFプロバイダーを使用する重要な動機の1つは、T-SSPがSEDをプロバイダーに1回だけ入力する必要があることです。LUF/ LRFプロバイダーを使用すると、T-SSPがSEDを1回設定できますが、O-SSP T-SSPのSEDはこのLUF/ LRFプロバイダーを使用できます。現在の慣行により、T-SSPがT-SSPの加入者に到達しなければならないすべてのO-SSPにSEDを入力することはかなり困難であることが示されています。これは、エンタープライズ環境で特に当てはまります。
Note that the LUF/LRF Provider and the I-SSP can be the same provider or different providers.
LUF/LRFプロバイダーとI-SSPは、同じプロバイダーまたは異なるプロバイダーになることができることに注意してください。
+------------------+
| LUF/LRF Provider |
| I-SSP |
| +-------+ |
| ---+ A-LUF | |
| / | A-LRF | |
+--------------------+ / +-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +-------------/ / | +-----+ |
| / |(4,5,6) | |T-LUF| |
| / | / | +----+T-LRF| |
| (2) + +--- | / +-----+ |
| / / | | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=|O-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+-------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via an LUF/LRF Provider and I-SSP (SIP and Media)
LUF/LRFプロバイダーとI-SSP（SIPおよびメディア）を介した間接的なピアリング
Figure 4
図4
The following is a high-level depiction of the use case:
以下は、ユースケースの高レベルの描写です。
1. The UAC initiates a call via SIP INVITE to the O-Proxy. The O-Proxy is the home proxy for the UAC.
1. UACは、o-ProxyへのSIP Inviteを介して通話を開始します。O-ProxyはUACのホームプロキシです。
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
2. The UAC knows the UAS's TN, but does not know the UAS's domain. It appends its own domain to generate the SIP URI in the Request-URI and TO header. The O-Proxy checks the Request-URI and discovers that the Request-URI contains the user parameter "user=phone". This parameter indicates that the Request-URI is a phone number. So, the O-Proxy will extract the TN from the Request-URI and query the LUF for SED information from a routing database. In this example, the LUF is an ENUM database. The ENUM entry looks similar to this:
2. UACはUASのTNを知っていますが、UASのドメインを知りません。それは独自のドメインを追加して、リクエスト-URIでSIP URIを生成し、ヘッダーにします。O-ProxyはRequest-URIをチェックし、Request-URIにユーザーパラメーター「ユーザー=電話」が含まれていることを発見します。このパラメーターは、リクエスト-URIが電話番号であることを示しています。したがって、O-Proxyはリクエスト-URIからTNを抽出し、ルーティングデータベースからのSED情報をLUFに照会します。この例では、LUFは列挙データベースです。列挙エントリはこれに似ています。
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@example.org!" . )
$ origin 0.0.1.0.5.5.5.5.7.1.9.1.e164.arpa。in naptr（10 100 "u" "e2u sip" "！^。*$！sip：19175550100@example.org！"）
Note that the response shows the next-hop is the SBE in I-SSP. Alternatively, the O-SSP may have a pre-association with the I-SSP. As such, the O-SSP will forward all requests that contain an external domain in the Request-URI or an unknown TN to the I-SSP. The O-SSP will rely on the I-SSP to determine the T-SSP and route the request correctly. In this configuration, the O-SSP can skip Steps 2, 4, 5, and 6 and forward the request directly to the I-SBE. This configuration is commonly used in the Enterprise environment.
応答は、次のホップがi-sspのSBEであることを示していることに注意してください。あるいは、O-SSPにはI-SSPとの事前関連付けがある場合があります。そのため、O-SSPは、リクエスト-URIの外部ドメインまたは未知のTNをI-SSPに含むすべてのリクエストを転送します。O-SSPは、I-SSPに依存してT-SSPを決定し、リクエストを正しくルーティングします。この構成では、O-SSPは手順2、4、5、および6をスキップして、リクエストをi-sbeに直接転送できます。この構成は、一般的にエンタープライズ環境で使用されます。
3. Given the O-Proxy's internal routing policy, the O-Proxy decides to use the O-SBE to reach the I-SBE. The O-Proxy routes the INVITE request to the O-SBE and adds a Route header that contains the O-SBE.
3. O-Proxyの内部ルーティングポリシーを考えると、O-ProxyはO-SBEを使用してI-SBEに到達することにしました。O-Proxyは招待要求をO-SBEにルーティングし、O-SBEを含むルートヘッダーを追加します。
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
4. The O-SBE receives the requests and pops the top entry of the Route header that contains "sip:o-sbe1.example.com". The O-SBE examines the Request-URI and does an LRF for "example.org". In this example, the LRF is a NAPTR DNS query of the domain. The O-SBE receives a response similar to this:
4. o-sbeはリクエストを受信し、「sip：o-sbe1.example.com」を含むルートヘッダーのトップエントリをポップします。o-sbeはリクエスト-URIを調べ、「embler.org」のLRFを実行します。この例では、LRFはドメインのNAPTR DNSクエリです。o-sbeは、これに似た応答を受け取ります。
IN NAPTR ( 50 50 "S" "SIP+D2T" "" _sip._tcp.i-sbe.example.org. )
in naptr（50 50 "s" "sip d2t" "" _sip._tcp.i-sbe.example.org。）
IN NAPTR ( 90 50 "S" "SIP+D2U" "" _sip._udp.i-sbe.example.org. )
in naptr（90 50 "s" "sip d2u" "" _sip._udp.i-sbe.example.org。）
5. Given the lower order for TCP in the NAPTR response, the O-SBE decides to use TCP for transport protocol, so it sends an SRV DNS query for the SRV record for "_sip._tcp.i-sbe.example.org." to the O-LRF.
5. NAPTR応答におけるTCPの低次を考えると、O-SBEはTCPを輸送プロトコルに使用することを決定するため、「_sip._tcp.i-sbe.example.org」のSRVレコードのSRV DNSクエリを送信します。o-lrfへ。
;; priority weight port target IN SRV 0 2 5060 i-sbe1.example.org. IN SRV 0 1 5060 i-sbe2.example.org.
;;SRV 0 2 5060 I-sbe1.example.orgの優先ウェイトポートターゲット。in srv 0 1 5060 i-sbe2.example.org。
6. Given the higher weight for "i-sbe1.example.org", the O-SBE sends a DNS query for an A record of "i-sbe1.example.org." to get the A record:
6. 「i-sbe1.example.org」の重みが高いことを考えると、o-sbeは「i-sbe1.example.org」のレコードのDNSクエリを送信します。レコードを取得するには：
;; DNS ANSWER i-sbe1.example.org. IN A 192.0.2.200 i-sbe1.example.org. IN A 192.0.2.201
;;DNS Answer I-Sbe1.example.org。192.0.2.200 I-sbe1.example.org。192.0.2.201
7. The O-SBE sends the INVITE to the I-SBE. The O-SBE is the entry point to the O-SSP domain, so it should ensure subsequent mid-dialog requests traverse via itself. If the O-SBE chooses to act as a B2BUA, it will generate a new back-to-back INVITE request in the next step. If the O-SBE chooses to act as proxy, it should record-route to stay in the call path. In this example, the O-SBE is a B2BUA.
7. o-sbeは招待をi-sbeに送ります。o-sbeはO-SSPドメインへのエントリポイントであるため、それ自体を介して後続のミッドダイアログリクエストが横断されることを保証する必要があります。o-sbeがB2BUAとして機能することを選択した場合、次のステップで新しい背中合わせの招待リクエストが生成されます。o-sbeがプロキシとして機能することを選択した場合、コールパスにとどまることを記録する必要があります。この例では、o-sbeはB2BUAです。
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
Route: <sip:i-sbe1.example.org;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
8. The I-SBE receives the request and queries its internal routing database on the TN. It determines that the target belongs to the T-SSP. Since the I-SBE is a B2BUA, the I-SBE generates a new INVITE request to the T-SSP.
8. I-SBEはリクエストを受信し、TNの内部ルーティングデータベースを照会します。ターゲットがT-SSPに属していると判断します。i-sbeはb2buaであるため、i-sbeはt-sspへの新しい招待リクエストを生成します。
INVITE sip:+19175550100@.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP i-sbe1.example.org:5060
;branch= z9hG4bK2d4777
Max-Forwards: 7
Route: <sip:t-sbe1.example.net;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-isbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@i-sbe1.example.org;user=phone;
transport=tcp>
</allOneLine>
Note that if the I-SSP wants the media to traverse through the I-DBE, the I-SBE must modify the Session Description Protocol (SDP) in the Offer to point to its DBE.
I-SSPがメディアにI-DBEを通過することを望んでいる場合、I-SBEはDBEを指すオファーでセッション説明プロトコル（SDP）を変更する必要があることに注意してください。
9. The T-SBE determines the called party home proxy and directs the call to the called party. The T-SBE may use ENUM lookup or another internal mechanism to locate the home proxy. If the T-SSP uses ENUM lookup, this internal ENUM entry is different from the external ENUM entry populated for O-SSP. This internal ENUM entry will contain the information to identify the next hop to reach the called party. In this example, the internal ENUM query returns the UAS's home proxy.
9. T-sbeは、呼び出されたパーティーのホームプロキシを決定し、呼び出されたパーティーに電話をかけます。T-sbeは、列挙ルックアップまたは別の内部メカニズムを使用して、ホームプロキシを見つけることができます。T-sspが列挙ルックアップを使用する場合、この内部の列挙エントリは、O-SSPに入力された外部の列挙エントリとは異なります。この内部列挙エントリには、次のホップを特定するための情報が含まれ、呼び出されたパーティーに到達します。この例では、内部列挙クエリはUASのホームプロキシを返します。
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@t-proxy.example.net!" . )
$ origin 0.0.1.0.5.5.5.5.7.1.9.1.e164.arpa。in naptr（10 100 "u" "e2u sip" "！^。*$！sip：19175550100@t-proxy.example.net！"。）
Note that this step is optional. If the T-SBE has other ways to locate the UAS home proxy, the T-SBE can skip this step and send the request to the UAS's home proxy. We show this step to illustrate one of the many possible ways to locate UAS's home proxy.
このステップはオプションであることに注意してください。T-sbeにUASホームプロキシを見つける他の方法がある場合、T-sbeはこの手順をスキップしてUASのホームプロキシにリクエストを送信できます。UASのホームプロキシを見つける多くの可能な方法の1つを説明するために、このステップを示します。
10. The T-SBE receives the NAPTR record and, following the requirements in [RFC3263], queries the DNS for the SRV records indicated by the NAPTR result. Not finding any, the T-SBE then queries DNS for the A record of domain "t-proxy.example.net.".
10. T-SBEはNAPTRレコードを受信し、[RFC3263]の要件に従って、NAPTR結果で示されるSRVレコードのDNSを照会します。T-sbeは何も見つかりませんでした。その後、ドメイン「t-proxy.example.net」のレコードのDNSをクエリします。
;; DNS ANSWER t-proxy.example.net. IN A 192.0.2.2
;;DNS Answer t-proxy.example.net。192.0.2.2で
11. T-SBE sends the INVITE to UAS's home proxy:
11. t-sbeは招待状をUASのホームプロキシに送信します。
INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 6
Record-Route: <sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
12. Finally, the UAS's home proxy forwards the INVITE request to the UAS.
12. 最後に、UASのホームプロキシは、招待リクエストをUASに転送します。
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 5
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
13. In Figure 4, RTP is established between the UAC and UAS via the O-DBE, I-DBE and T-DBE. The use of DBE is optional.
13. 図4では、o-dbe、i-dbe、t-dbeを介してUACとUASの間にRTPが確立されています。DBEの使用はオプションです。
This use case looks very similar to the Static Direct Peering Use Case with Assisting LUF and LRF. The major difference is the O-SSP and T-SSP do not have direct Layer 5 connectivity. Instead, O-SSP connects to the T-SSP indirectly via the I-SSP.
このユースケースは、LUFとLRFを支援することで、静的な直接ピアリングユースケースに非常によく似ています。主な違いは、O-SSPとT-SSPには直接レイヤー5接続がないことです。代わりに、O-SSPはI-SSPを介して間接的にT-SSPに接続します。
Typically, an LUF/LRF Provider serves multiple O-SSPs. Two O-SSPs may use different I-SSPs to reach the same T-SSP. For example, O-SSP1 may use I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to reach T-SSP. Given the O-SSP and T-SSP pair as input, the LUF/LRF Provider will return the SED of I-SSP that is trusted by O-SSP to forward the request to T-SSP.
通常、LUF/LRFプロバイダーは複数のO-SSPを提供します。2つのO-SSPは、異なるI-SSPを使用して同じT-SSPに達する場合があります。たとえば、O-SSP1はI-SSP1を使用してT-SSPに到達する場合がありますが、O-SSP2はI-SSP2を使用してT-SSPに到達する場合があります。O-SSPとT-SSPペアを入力として考えると、LUF/LRFプロバイダーは、O-SSPによって信頼されているI-SSPのSEDを返して、リクエストをT-SSPに転送します。
In this use case, there are two levels of trust relationship. The first trust relationship is between the O-SSP and the LUF/LRF Provider. The O-SSP trusts the LUF/LRF to provide the T-SSP's SED. The second trust relationship is between the O-SSP and I-SSP. The O-SSP trusts the I-SSP to provide Layer 5 connectivity to assist the O-SSP in reaching the T-SSP. The O-SSP and I-SSP have a pre-arranged agreement for policy. Note that Figure 4 shows a single provider to supply both LUF/LRF and I-SSP, but O-SSP can choose two different providers.
このユースケースでは、2つのレベルの信頼関係があります。最初の信頼関係は、O-SSPとLUF/LRFプロバイダーの間です。O-SSPは、LUF/LRFを信頼して、T-SSPのSEDを提供します。2番目の信頼関係は、O-SSPとI-SSPの間です。O-SSPは、I-SSPを信頼して、レイヤー5接続を提供し、O-SSPがT-SSPに到達するのを支援します。O-SSPとI-SSPには、ポリシーに関する事前に整理された合意があります。図4は、LUF/LRFとI-SSPの両方を提供する単一のプロバイダーを示していますが、O-SSPは2つの異なるプロバイダーを選択できます。
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP may deploy SBE and DBE for NAT traversal, security, transcoding, etc. The I-SSP can also deploy the SBE and DBE for similar reasons (as depicted in Figure 4).
静的な直接ピアリングユースケースと同様に、O-SSPおよびT-SSPは、NATトラバーサル、セキュリティ、トランスコーディングなどのSBEとDBEを展開できます。I-SSPは、同様の理由でSBEとDBEを展開することもできます（図4）。
This use case shares many properties with the Static Indirect Use Case with Assisting LUF and LRF. The difference is that the O-SSP uses its internal LUF/LRF to control the routing database. By controlling the database, the O-SSP can apply different routing rules and policies to different T-SSPs. For example, the O-SSP can use I-SSP1 and Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach T-SSP2. Note that there could be multiple I-SSPs and multiple SIP routes to reach the same T-SSP; the selection process is out of scope of this document.
このユースケースは、LUFとLRFを支援する静的間接ユースケースと多くのプロパティを共有しています。違いは、O-SSPが内部LUF/LRFを使用してルーティングデータベースを制御することです。データベースを制御することにより、O-SSPは異なるルーティングルールとポリシーを異なるT-SSPに適用できます。たとえば、O-SSPはI-SSP1とポリシー1を使用してT-SSP1に到達し、I-SSP2とポリシー2を使用してT-SSP2に到達できます。同じT-SSPに到達するために複数のI-SSPと複数のSIPルートがある可能性があることに注意してください。選択プロセスは、このドキュメントの範囲外です。
+--------------------+-------------------+---------------------+
| O-SSP | I-SSP | T-SSP |
| +-----+ | | +-----+ |
| -+O-LUF| | | |T-LUF| |
| / |O-LRF+\ | | +----+T-LRF| |
| / +-----+ \ | | / +-----+ |
| /(2) \(4,5,6) | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=+O-DBE+======+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+--------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via I-SSP (SIP and Media)
I-ssp（SIPおよびメディア）を介した間接的なピアリング
Figure 5
図5
The Static Indirect Peering Use Case is implemented in cases where no direct interconnection exists between the originating and terminating domains due to either business or physical constraints.
静的な間接的なピアリングユースケースは、ビジネスまたは物理的制約のいずれかのために発信ドメインと終端ドメインの間に直接的な相互接続が存在しない場合に実装されます。
O-SSP <---> I-SSP = Relationship O-I
In the O-I relationship, typical policies, features, or functions that deem this relationship necessary are number portability, ubiquity of termination options, security certificate management, and masquerading of originating VoIP network gear.
O-I関係では、この関係を必要とする典型的なポリシー、特徴、または機能は、数の携帯性、終了オプションの普及、セキュリティ証明書管理、および発信されるVoIPネットワークギアの仮定です。
T-SSP <---> I-SSP = Relationship T-I
In the T-I relationship, typical policies, features, or functions observed consist of codec "scrubbing", anonymizing, and transcoding. The I-SSP must record-route and stay in the signaling path. The T-SSP will not accept any message sent directly from the O-SSP.
T-I関係では、観察された典型的なポリシー、機能、または関数がコーデックの「スクラブ」、匿名化、およびトランスコーディングで構成されています。I-SSPは、記録され、シグナリングパスにとどまる必要があります。T-SSPは、O-SSPから直接送信されたメッセージを受け入れません。
In Figure 5, we show an I-DBE. Using an I-DBE is optional. For example, the I-DBE can be used when the O-SSP and T-SSP do not have a common codec. To involve an I-DBE, the I-SSP should know the list of codecs supported by the O-SSP and T-SSP. When the I-SBE receives the INVITE request, it will make a decision to invoke the I-DBE. An I-DBE may also be used if the O-SSP uses Secure Real-time Transport Protocol (SRTP) [RFC3711] for media and T-SSP does not support SRTP.
図5には、i-dbeを示しています。i-dbeの使用はオプションです。たとえば、O-SSPとT-SSPに共通のコーデックがない場合、i-dbeを使用できます。i-dbeを巻き込むには、i-sspはo-sspとt-sspによってサポートされているコーデックのリストを知る必要があります。i-sbeが招待リクエストを受け取ると、i-dbeを呼び出すことが決定されます。O-SSPがメディアに安全なリアルタイムトランスポートプロトコル（SRTP）[RFC3711]を使用し、T-SSPがSRTPをサポートしていない場合、I-DBEも使用できます。
On-demand peering [RFC5486] describes how two SSPs form the peering relationship without a pre-arranged agreement.
オンデマンドピアリング[RFC5486]は、事前にアレンジされた合意なしに2つのSSPがピアリング関係をどのように形成するかを説明しています。
The basis of this use case is built on the fact that there is no pre-established relationship between the O-SSP and T-SSP. The O-SSP and T-SSP do not share any information prior to the dialog initiation request. When the O-Proxy invokes the LUF and LRF on the Request-URI, the terminating user information must be publicly available. When the O-Proxy routes the request to the T-Proxy, the T-Proxy must accept the request without any pre-arranged agreement with the O-SSP.
このユースケースの基礎は、O-SSPとT-SSPの間に事前に確立された関係がないという事実に基づいて構築されています。O-SSPとT-SSPは、ダイアログ開始リクエストの前に情報を共有しません。O-ProxyがリクエストURIでLUFとLRFを呼び出す場合、終了するユーザー情報を公開する必要があります。O-ProxyがリクエストをT-Proxyにルーティングする場合、T-ProxyはO-SSPとの事前に配置された合意なしにリクエストを受け入れる必要があります。
The On-demand Peering Use Case is uncommon in production. In this memo, we capture only the high-level descriptions. Further analysis is expected when this use case becomes more popular.
オンデマンドピアリングユースケースは、生産がまれです。このメモでは、高レベルの説明のみをキャプチャします。このユースケースがより一般的になると、さらなる分析が期待されます。
The On-demand Direct Peering Use Case is typically implemented in a scenario where the T-SSP allows any O-SSP to reach its serving subscribers. The T-SSP administrative domain does not require any pre-arranged agreement to accept the call. The T-SSP makes its subscribers information publicly available. This model mimics the Internet email model. The sender does not need an pre-arranged agreement to send email to the receiver.
通常、オンデマンドの直接ピアリングユースケースは、T-SSPがO-SSPがサービスを提供する加入者にリーチできるようにするシナリオに実装されます。T-SSP管理ドメインは、コールを受け入れるために事前に配置された契約を必要としません。T-SSPは、加入者情報を公開されています。このモデルは、インターネットメールモデルを模倣しています。送信者は、レシーバーに電子メールを送信するために事前に整理された契約を必要としません。
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP can decide to deploy the SBE. Since the T-SSP is open to the public, the T-SSP is considered to be a higher security risk than static model because there is no trusted relationship between the O-SSP and T-SSP. The T-SSP should protect itself from any attack launched by an untrusted O-SSP.
静的な直接ピアリングユースケースと同様に、O-SSPとT-SSPはSBEを展開することを決定できます。T-SSPは一般に公開されているため、T-SSPは、O-SSPとT-SSPの間に信頼できる関係がないため、静的モデルよりも高いセキュリティリスクであると考えられています。T-sspは、信頼されていないO-SSPによって発売された攻撃から身を守る必要があります。
Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David Schwartz, Eli Katz and Jeremy Barkan are the authors of the early individual documents. Their use cases are captured in this document. Also, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan, John Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon Peterson, Alexander Mayrhofer, and Jean-Francois Mule made many valuable comments related to this document. The editors would also like to extend a special thank you to Spencer Dawkins for his detailed review of this document.
マイケル・ハーバーラー、マイク・ママー、オトマル・レンドル、ローハン・マヒー、デビッド・シュワルツ、エリ・カッツ、ジェレミー・バーカンは、初期の個々の文書の著者です。彼らのユースケースはこのドキュメントでキャプチャされています。また、ジェイソン・リビングッド、ダリル・マラス、デビッド・マイヤー、ハドリエル・カプラン、ジョン・エルウェル、レイナルド・ペンノ、ソヘル・カーン、ジェームズ・マッカーン、ジョン・ピーターソン、アレクサンダー・メイロファー、ジャン・フランソワ・ラ・ラ・ラ・ラ・ラ・ラ・ラ・マ・ラ・マ・ラ・マ・ラ・マ・ラ・マ・ラ・マ・ラ・マ・ラ・マ・ラ・ラ・編集者はまた、このドキュメントの詳細なレビューについて、スペンサー・ドーキンスに特別な感謝を拡大したいと思います。
Session interconnect for VoIP, as described in this document, has a wide variety of security issues that should be considered. For example, if the O-SSP and T-SSP peer through public Internet, the O-SSP must protect the signaling channel and accept messages only from an authorized T-SSP. This document does not analyze the threats in detail. [RFC6404] discusses the different security threats and countermeasures related to VoIP peering.
このドキュメントで説明されているように、VoIPのセッションインターコネクトには、考慮すべき幅広いセキュリティの問題があります。たとえば、O-SSPおよびT-SSPがパブリックインターネットを介してピアをピアする場合、O-SSPは信号チャネルを保護し、認定されたT-SSPからのみメッセージを受け入れる必要があります。このドキュメントでは、脅威を詳細に分析しません。[RFC6404]は、VoIPピアリングに関連するさまざまなセキュリティの脅威と対策について説明しています。
[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月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年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月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[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月。
[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月。
[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月。
[DRINKS] Channabasappa, S., "Data for Reachability of Inter/ tra-NetworK SIP (DRINKS) Use cases and Protocol Requirements", Work in Progress, August 2011.
[飲み物] Channabasappa、S。、「インター/ TRAネットワークSIP（ドリンク）ユースケースとプロトコル要件の到達可能性のデータ」、2011年8月、進行中の作業。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[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月。
[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月。
Authors' Addresses
著者のアドレス
Adam Uzelac (editor) Global Crossing U.S.A.
Adam Uzelac（編集者）Global Crossing U.S.A.
EMail: adam.uzelac@globalcrossing.com
URI: http://www.globalcrossing.com
Yiu L.Lee (editor) Comcast Cable U.S.A.
Yiu L.Lee（編集者）Comcast Cable U.S.A.
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com