[要約] RFC 5923は、SIPにおける接続再利用の方法を提案している。目的は、SIPセッションの効率を向上させ、ネットワークリソースの使用を最適化することである。
Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 5923 Bell Laboratories, Alcatel-Lucent
Category: Standards Track R. Mahy
ISSN: 2070-1721 Unaffiliated
B. Tate
BroadSoft
June 2010
Connection Reuse in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）での接続再利用
Abstract
概要
This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP.
このドキュメントにより、通信プロキシのペアが、フォワード方向と後方方向にリクエストを送信するために、自分自身との間の輻輳制御接続を再利用することができます。接続は基本的に後方方向に進む要求に対してエイリアスされるため、再利用は、トランスポートレイヤーセキュリティ（TLS）を介してX.509証明書を使用して自分自身を認証する通信エンドポイントの両方に基づいています。このため、TCPおよびTLSを介したTLSの接続再利用と、ストリーム制御伝送プロトコル（SCTP）のみを考慮します。このドキュメントは、接続の再利用と仮想SIPサーバーに関するガイドライン、およびSIPでの接続再利用とDNS SRVルックアップの相互作用も提供します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5923.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5923で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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 ...................................................3
2. Terminology ....................................................4
3. Applicability Statement ........................................5
4. Benefits of TLS Connection Reuse ...............................5
5. Overview of Operation ..........................................6
6. Requirements ..................................................10
7. Formal Syntax .................................................11
8. Normative Behavior ............................................11
8.1. Client Behavior ...........................................11
8.2. Server Behavior ...........................................13
8.3. Closing a TLS Connection ..................................14
9. Security Considerations .......................................14
9.1. Authenticating TLS Connections: Client View ...............14
9.2. Authenticating TLS Connections: Server View ...............15
9.3. Connection Reuse and Virtual Servers ......................15
10. Connection Reuse and SRV Interaction ..........................17
11. IANA Considerations ...........................................17
12. Acknowledgments ...............................................17
13. References ....................................................18
13.1. Normative References ......................................18
13.2. Informative References ....................................18
SIP entities can communicate using either unreliable/connectionless (e.g., UDP) or reliable/connection-oriented (e.g., TCP, SCTP [RFC4960]) transport protocols. When SIP entities use a connection-oriented protocol (such as TCP or SCTP) to send a request, they typically originate their connections from an ephemeral port.
SIPエンティティは、信頼できない/コネクションレス（UDPなど）または信頼性/接続指向（TCP、SCTP [RFC4960]）輸送プロトコルのいずれかを使用して通信できます。SIPエンティティが接続指向のプロトコル（TCPやSCTPなど）を使用してリクエストを送信する場合、通常は一時的なポートから接続を発信します。
In the following example, A listens for SIP requests over TLS on TCP port 5061 (the default port for SIP over TLS over TCP), but uses an ephemeral port (port 49160) for a new connection to B. These entities could be SIP user agents or SIP proxy servers.
次の例では、TCPポート5061のTLSを介したSIPリクエストのリスト（TCPを介したTLSを超えるSIPのデフォルトポート）のリッティングを使用しますが、Bへの新しい接続には、はかないポート（ポート49160）を使用します。エージェントまたはSIPプロキシサーバー。
+-----------+ 49160 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
Figure 1: Uni-directional connection for requests from A to B
図1：AからBへのリクエストの単方方向接続
The SIP protocol includes the notion of a persistent connection (defined in Section 2), which is a mechanisms to insure that responses to a request reuse the existing connection that is typically still available, as well as reusing the existing connections for other requests sent by the originator of the connection. However, new requests sent in the backwards direction -- in the example above, requests from B destined to A -- are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, as shown below.
SIPプロトコルには、永続的な接続（セクション2で定義されている）の概念が含まれています。これは、通常利用可能な既存の接続を再利用するリクエストへの応答を保証するメカニズムです。接続の創始者。ただし、上記の例では、Aに運命づけられたBからのリクエストは、既存の接続を再利用する可能性は低い新しい要求が後方方向に送信されます。これにより、以下に示すように、各方向に送信されたリクエストに対して、一対のSIPエンティティが1つの接続を使用します。
+-----------+ 49160 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 49170 | B |
| |<-----------------------| |
+-----------+ +-----------+
Figure 2: Two connections for requests between A and B
図2：AとBの間のリクエストの2つの接続
Unlike TCP, TLS connections can be reused to send requests in the backwards direction since each end can be authenticated when the connection is initially set up. Once the authentication step has been performed, the situation can thought to resemble the picture in Figure 1 except that A and B both use a single shared connection, for example, between port 49160 on A and port 5061 on B. When A wants to send a request to B, it will reuse this connection, and when B wants to send a request to A, it will reuse the same connection.
TCPとは異なり、TLS接続を再利用して、接続が最初に設定されたときに各端を認証できるため、後方方向にリクエストを送信できます。認証ステップが実行されると、AとBの両方がBのポート49160とBのポート5061の間で、AとBの両方が単一の共有接続を使用することを除いて、図1の写真に似ていると考えることができます。Bへのリクエスト、この接続が再利用され、BがAにリクエストを送信したい場合、同じ接続を再利用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Additional terminology used in this document:
このドキュメントで使用される追加の用語：
Advertised address: The address that occurs in the Via header field's sent-by production rule, including the port number and transport.
広告アドレス：ポート番号と輸送を含む、Via Headerフィールドのセントごとの生産ルールで発生するアドレス。
Alias: Reusing an existing connection to send requests in the backwards direction; i.e., A opens a connection to B to send a request, and B uses that connection to send requests in the backwards direction to A.
エイリアス：既存の接続を再利用して、リクエストを後方方向に送信します。つまり、AはBへの接続を開き、リクエストを送信し、Bはその接続を使用してリクエストを後方方向にAを送信します。
Connection reuse: See "Alias".
接続の再利用：「エイリアス」を参照してください。
Persistent connection: The process of sending multiple, possibly unrelated requests on the same connection, and receiving responses on that connection as well. More succinctly, A opens a connection to B to send a request, and later reuses the same connection to send other requests, possibly unrelated to the dialog established by the first request. Responses will arrive over the same connection. Persistent connection behavior is specified in Section 18 of RFC 3261 [RFC3261]. Persistent connections do not imply connection reuse.
永続的な接続：同じ接続で複数の、おそらく無関係なリクエストを送信し、その接続で応答を受信するプロセス。さらに簡潔に言えば、AはBへの接続を開き、リクエストを送信し、後で同じ接続を再利用して、最初のリクエストによって確立されたダイアログとは無関係である可能性がある他のリクエストを送信します。応答は同じ接続に到着します。永続的な接続挙動は、RFC 3261 [RFC3261]のセクション18で指定されています。永続的な接続は、接続の再利用を意味するものではありません。
Resolved address: The network identifiers (IP address, port, transport) associated with a user agent as a result of executing RFC 3263 [RFC3263] on a Uniform Resource Identifier (URI).
解決済みアドレス：ユニフォームリソース識別子（URI）でRFC 3263 [RFC3263]を実行した結果として、ユーザーエージェントに関連付けられたネットワーク識別子（IPアドレス、ポート、トランスポート）。
Shared connection: See "Persistent connection".
共有接続：「永続的な接続」を参照してください。
The applicability of the mechanism described in this document is for two adjacent SIP entities to reuse connections when they are agnostic about the direction of the connection, i.e., either end can initiate the connection. SIP entities that can only open a connection in a specific direction -- perhaps because of Network Address Translation (NAT) and firewalls -- reuse their connections using the mechanism described in the outbound document [RFC5626].
このドキュメントで説明されているメカニズムの適用性は、2つの隣接するSIPエンティティが接続の方向について不可知論されている場合、つまり、いずれかの端が接続を開始できる場合に接続を再利用するためです。おそらくネットワークアドレス変換（NAT）とファイアウォールのために、特定の方向に接続を開くことができるSIPエンティティは、アウトバウンドドキュメント[RFC5626]に記載されているメカニズムを使用して接続を再利用します。
This memo concerns connection reuse, not persistent connections (see definitions of these in Section 2). Behavior for persistent connections is specified in Section 18 of RFC 3261 [RFC3261] and is not altered by this memo.
このメモは、持続的な接続ではなく、接続の再利用に関するものです（セクション2のこれらの定義を参照）。永続的な接続の動作は、RFC 3261 [RFC3261]のセクション18で指定されており、このメモでは変更されていません。
This memo documents that it is good practice to only reuse those connections where the identity of the sender can be verified by the receiver. Thus, TLS (RFC 5246 [RFC5246]) connections (over any connection-oriented transport) formed by exchanging X.509 certificates can be reused because they authoritatively establish identities of the communicating parties (see Section 5).
このメモは、送信者の身元が受信者によって検証できる場合にのみ再利用することが良い習慣であると文書化しています。したがって、X.509証明書を交換することによって形成されたTLS（RFC 5246 [RFC5246]）接続（接続指向のトランスポートを介して）は、通信当事者のアイデンティティを信頼できるように確立するため、再利用できます（セクション5を参照）。
Opening an extra connection where an existing one is sufficient can result in potential scaling and performance problems. Each new connection using TLS requires a TCP three-way handshake, a handful of round trips to establish TLS, typically expensive asymmetric authentication and key generation algorithms, and certificate verification. This can lead to a build up of considerable queues as the server CPU saturates by the TLS handshakes it is already performing (Section 6.19 of Rescorla [Book-Rescorla-TLS]).
既存のものが十分である場合に追加の接続を開くと、潜在的なスケーリングやパフォーマンスの問題が発生する可能性があります。TLSを使用した新しい接続には、TCPの3方向握手、TLSを確立するための少数の往復、通常は高価な非対称認証と主要生成アルゴリズム、および証明書の確認が必要です。これにより、サーバーCPUが既に実行されているTLSハンドシェイクによって飽和するため、かなりのキューが蓄積されます（Rescorla [Book-Rescorla-TLS]のセクション6.19）。
Consider the call flow shown below where Proxy A and Proxy B use the Record-Route mechanism to stay involved in a dialog. Proxy B will establish a new TLS connection just to send a BYE request.
プロキシAとプロキシBが記録的なメカニズムを使用してダイアログに関与し続ける場合、以下に示すコールフローを考慮してください。Proxy Bは、さようならリクエストを送信するためだけに新しいTLS接続を確立します。
Proxy A Proxy B
| |
Create connection 1 +---INV--->|
| |
|<---200---+ Response over connection 1
| |
Reuse connection 1 +---ACK--->|
| |
= =
| |
|<---BYE---+ Create connection 2
| |
Response over +---200--->|
connection 2
Figure 3: Multiple connections for requests
図3：リクエストの複数の接続
Setting up a second connection (from B to A above) for subsequent requests, even requests in the context of an existing dialog (e.g., re-INVITE request or BYE request after an initial INVITE request, or a NOTIFY request after a SUBSCRIBE request or a REFER request), can also cause excessive delay (especially in networks with long round-trip times). Thus, it is advantageous to reuse connections whenever possible.
後続のリクエストのために2番目の接続（Bから上記の）を設定し、既存のダイアログのコンテキストでのリクエスト（例：最初の招待リクエスト後の再入札要求またはByeリクエスト、または購読要求後の通知要求または参照要求）、また、過度の遅延を引き起こす可能性があります（特に往復時間が長いネットワークで）。したがって、可能な限り接続を再利用することが有利です。
From the user expectation point of view, it is advantageous if the re-INVITE requests or UPDATE requests are handled automatically and rapidly in order to avoid media and session state from being out of step. If a re-INVITE request requires a new TLS connection, the re-INVITE request could be delayed by several extra round-trip times. Depending on the round-trip time, this combined delay could be perceptible or even annoying to a human user. This is especially problematic for some common SIP call flows (for example, the recommended example flow in Figure 4 in RFC 3725 [RFC3725] uses many re-INVITE requests).
ユーザーの期待の観点からは、メディアやセッションの状態が一歩離れないようにするために、再入手要求または更新リクエストが自動的かつ迅速に処理される場合、有利です。再入手要求に新しいTLS接続が必要な場合、再インバイト要求はいくつかの追加の往復時間によって遅延する可能性があります。往復時間に応じて、この組み合わせた遅延は、人間のユーザーにとって知覚可能または迷惑になる可能性があります。これは、いくつかの一般的なSIPコールフローで特に問題があります（たとえば、RFC 3725 [RFC3725]の図4の推奨される例は、多くの再入力要求を使用しています）。
The mechanism described in this document can mitigate the delays associated with subsequent requests.
このドキュメントで説明されているメカニズムは、後続の要求に関連する遅延を軽減できます。
This section is tutorial in nature, and does not specify any normative behavior.
このセクションは本質的なチュートリアルであり、規範的な動作を指定していません。
We now explain this working in more detail in the context of communication between two adjacent proxies. Without any loss of generality, the same technique can be used for connection reuse between a User Agent Client (UAC) and an edge proxy, or between an edge proxy and a UAS, or between an UAC and an UAS.
ここで、2つの隣接するプロキシ間のコミュニケーションのコンテキストで、これをより詳細に説明します。一般性を失うことなく、ユーザーエージェントクライアント（UAC）とエッジプロキシ、エッジプロキシとUAS間、またはUACとUAS間の接続の再利用に同じ手法を使用できます。
P1 and P2 are proxies responsible for routing SIP requests to user agents that use them as edge proxies (see Figure 4).
P1とP2は、それらをエッジプロキシとして使用するユーザーエージェントにSIP要求をルーティングするプロキシです（図4を参照）。
P1 <===================> P2
p1.example.com p2.example.net
(192.0.2.1) (192.0.2.128)
+---+ +---+
| | 0---0 0---0 | |
|___| /-\ /-\ |___|
/ / +---+ +---+ / /
+----+ +----+
User Agents User Agents
example.com domain example.net domain
Figure 4: Proxy setup
図4：プロキシセットアップ
For illustration purpose the discussion below uses TCP as a transport for TLS operations. Another streaming transport -- such as SCTP -- can be used as well.
イラストの目的のために、以下の議論では、TCPをTLS操作の輸送として使用しています。SCTPなどの別のストリーミングトランスポートも使用できます。
The act of reusing a connection is initiated by P1 when it adds an "alias" header field parameter (defined later) to the Via header field. When P2 receives the request, it examines the topmost Via header field. If the Via header contained an "alias" header field parameter, P2 establishes a binding such that subsequent requests going to P1 will reuse the connection; i.e., requests are sent over the established connection.
接続を再利用する行為は、「エイリアス」ヘッダーフィールドパラメーター（後で定義）をViaヘッダーフィールドに追加すると、P1によって開始されます。P2がリクエストを受信すると、ヘッダーフィールドを介して最上部を調べます。Viaヘッダーに「エイリアス」ヘッダーフィールドパラメーターが含まれている場合、P2はバインディングを確立し、その後のP1に移動するリクエストが接続を再利用するようにします。つまり、確立された接続を介してリクエストが送信されます。
With reference to Figure 4, in order for P2 to reuse a connection for requests in the backwards direction, it is important that the validation model for requests sent in this direction (i.e., P2 to P1) is equivalent to the normal "connection in each direction" model, wherein P2 acting as client would open up a new connection in the backwards direction and validate the connection by examining the X.509 certificate presented. The act of reusing a connection needs the desired property that requests get delivered in the backwards direction only if they would have been delivered to the same destination had connection reuse not been employed. To guarantee this property, the X.509 certificate presented by P1 to P2 when a TLS connection is first authenticated are cached for later use.
図4を参照すると、P2が後方方向にリクエストの接続を再利用するためには、この方向に送信された要求の検証モデル（つまり、P2からP1）がそれぞれの通常の「接続」に相当することが重要です。Direction "モデル。クライアントとして機能するP2は、提示されたX.509証明書を調べて接続を検証し、接続を検証します。接続を再利用する行為には、同じ宛先に配信された場合にのみ、要求が後方方向に配信されるという目的のプロパティが必要です。このプロパティを保証するために、TLS接続が最初に認証されたときにP1からP2への提示されたX.509証明書が後で使用するためにキャッシュされます。
To aid the discussion of connection reuse, this document defines a data structure called the connection alias table (or simply, alias table), which is used to store aliased addresses and is used by user agents to search for an existing connection before a new one is opened up to a destination. It is not the intent of this memo to standardize the implementation of an alias table; rather, we use it as a convenience to aid subsequent discussions.
接続の再利用の議論を支援するために、このドキュメントは、エイリアスアドレスを保存するために使用され、新しい接続の前に既存の接続を検索するためにユーザーエージェントが使用する接続エイリアステーブル（または単純にエイリアステーブル）と呼ばれるデータ構造を定義します。目的地まで開かれています。エイリアステーブルの実装を標準化することは、このメモの意図ではありません。むしろ、私たちはそれをその後の議論を支援するための利便性として使用します。
P1 gets a request from one of its upstream user agents, and after performing RFC3263 [RFC3263] server selection, arrives at a resolved address of P2. P1 maintains an alias table, and it populates the alias table with the IP address, port number, and transport of P2 as determined through RFC3263 server selection. P1 adds an "alias" header field parameter to the topmost Via header field (inserted by it) before sending the request to P2. The value in the sent-by production rule of the Via header field (including the port number), and the transport over which the request was sent becomes the advertised address of P1:
P1は、上流のユーザーエージェントの1つからリクエストを受け取り、RFC3263 [RFC3263]サーバーの選択を実行した後、P2の解決されたアドレスに到着します。P1はエイリアステーブルを維持し、RFC3263サーバーの選択を通じて決定されたP2のIPアドレス、ポート番号、および輸送にエイリアステーブルに入力されます。P1は、リクエストをP2に送信する前に、「エイリアス」ヘッダーフィールドパラメーターを最上部にヘッダーフィールド（ITで挿入）を最上部に追加します。Via Headerフィールド（ポート番号を含む）のセントごとの生産ルールの値、およびリクエストが送信された輸送は、P1の広告アドレスになります。
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias
Assuming that P1 does not already have an existing aliased connection with P2, P1 now opens a connection with P2. P2 presents its X.509 certificate to P1 for validation (see Section 9.1). Upon connection authentication and acceptance, P1 adds P2 to its alias table. P1's alias table now looks like:
P1がP2との既存のエイリアス接続をまだ持っていないと仮定すると、P1はP2との接続を開きます。P2は、検証のためにX.509証明書をP1に提示します（セクション9.1を参照）。接続認証と受け入れにより、P1はエイリアステーブルにP2を追加します。P1のエイリアステーブルは次のようになりました。
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.128 5061 TLS sip:example.net 25 sip:p2.example.net
宛先宛先宛先宛先エイリアスIPアドレスポートトランスポートアイデンティティ記述子... 192.0.2.128 5061 TLS SIP：Example.Net 25 SIP：P2.example.net
Subsequent requests that traverse from P1 to P2 will reuse this connection; i.e., the requests will be sent over the descriptor 25.
その後のリクエストは、P1からP2へのトラバースがこの接続を再利用します。つまり、リクエストは記述子25を介して送信されます。
The following columns in the alias table created at the client warrant an explanation:
クライアントで作成されたエイリアステーブルの次の列には、説明が必要です。
1. The IP address, port, and transport are a result of executing the RFC3263 server resolution process on a next-hop URI.
1. IPアドレス、ポート、およびトランスポートは、Next-HOP URIでRFC3263サーバー解像度プロセスを実行した結果です。
2. The entries in the fourth column consists of the identities of the server as asserted in the X.509 certificate presented by the server. These identities are cached by the client after the server has been duly authenticated (see Section 9.1).
2. 4番目の列のエントリは、サーバーが提示したX.509証明書で主張されているサーバーのIDで構成されています。これらのアイデンティティは、サーバーが適切に認証された後、クライアントによってキャッシュされます（セクション9.1を参照）。
3. The entry in the last column is the socket descriptor over which P1, acting as a client, actively opened a TLS connection. At some later time, when P1 gets a request from one of the user agents in its domain, it will reuse the aliased connection accessible through socket descriptor 25 if and only if all of the following conditions hold:
3. 最後の列のエントリは、クライアントとして機能するP1がTLS接続を積極的に開くソケット記述子です。後で、P1がドメイン内のユーザーエージェントの1つからリクエストを取得すると、次のすべての条件が保持されている場合にのみ、ソケット記述子を介してアクセス可能なエイリアス接続を再利用します。
A. P1 determines through the RFC3263 server resolution process that the {transport, IP-address, port} tuple of P2 to be {TLS, 192.0.2.128, 5061}, and
A. P1は、RFC3263サーバーの解像度プロセスを通じて、{TLANSTREST、IP-ADDRESS、PORT} P2のタプルが{TLS、192.0.2.128、5061}、および、、および5061}であると判断します。
B. The URI used for the RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).
B. RFC3263サーバー解像度に使用されるURIは、キャッシュされた証明書（4列目）に保存されているIDの1つと一致します。
When P2 receives the request, it examines the topmost Via header field to determine whether P1 is willing to use this connection as an aliased connection (i.e., accept requests from P2 towards P1). The Via header field at P2 now looks like the following (the "received" header field parameter is added by P2):
P2がリクエストを受信すると、ヘッダーフィールドを介して最上部を調べて、P1がこの接続をエイリアス接続として使用する意思があるかどうかを判断します（つまり、P2からP1へのリクエストを受け入れます）。P2のViaヘッダーフィールドは、次のように見えます（「受信」ヘッダーフィールドパラメーターはP2によって追加されます）：
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.2.1
The presence of the "alias" Via header field parameter indicates that P1 supports aliasing on this connection. P2 now authenticates the connection (see Section 9.2) and if the authentication was successful, P2 creates an alias to P1 using the advertised address in the topmost Via header field. P2's alias table looks like the following:
ヘッダーフィールドパラメーターを介した「エイリアス」の存在は、P1がこの接続でのエイリアシングをサポートしていることを示しています。P2は接続を認証し（セクション9.2を参照）、認証が成功した場合、P2はヘッダーフィールドを介して最上部の広告アドレスを使用してP1のエイリアスを作成します。P2のエイリアステーブルは次のようになります。
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.1 5061 TLS sip:example.com 18 sip:p1.example.com
宛先宛先宛先宛先エイリアスIPアドレスポートトランスポートアイデンティティ記述子... 192.0.2.1 5061 TLS SIP：Example.com 18 SIP：P1.example.com
There are a few items of interest here:
ここにはいくつかの関心のあるアイテムがあります：
1. The IP address field is populated with the source address of the client.
1. IPアドレスフィールドには、クライアントのソースアドレスが入力されています。
2. The port field is populated from the advertised address (topmost Via header field), if a port is present in it, or 5061 if it is not.
2. ポートフィールドは、ポートが存在する場合は、広告されたアドレス（最上部のヘッダーフィールド）、またはそうでない場合は5061から入力されます。
3. The transport field is populated from the advertised address (topmost Via header field).
3. 輸送フィールドは、広告されたアドレス（ヘッダーフィールドを介して最上部）から入力されています。
4. The entries in the fourth column consist of the identities of the client as asserted in the X.509 certificate presented by the client. These identities are cached by the server after the client has been duly authenticated (see Section 9.2).
4. 4番目の列のエントリは、クライアントが提示したX.509証明書で主張されているクライアントのアイデンティティで構成されています。これらのアイデンティティは、クライアントが適切に認証された後、サーバーによってキャッシュされます（セクション9.2を参照）。
5. The entry in the last column is the socket descriptor over which the connection was passively accepted. At some later time, when P2 gets a request from one of the user agents in its domain, it will reuse the aliased connection accessible through socket descriptor 18 if and only if all of the following conditions hold:
5. 最後の列のエントリは、接続が受動的に受け入れられたソケット記述子です。後で、P2がドメイン内のユーザーエージェントの1つからリクエストを取得すると、次のすべての条件が保持されている場合にのみ、ソケット記述子18からアクセス可能なエイリアス接続を再利用します。
A. P2 determines through RFC3263 server resolution process that the {transport, IP-address, port} tuple of P1 to be {TLS, 192.0.2.1, 5061}, and
A. P2は、{TLS、192.0.2.1、5061}、および{TLS、IP-ADDRESS、PORT} Tupleが{Transport、IP-Address、Port}のタプルが{Transport、IP-Address、Port}を介して決定します。
B. The URI used for RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).
B. RFC3263サーバー解像度に使用されるURIは、キャッシュされた証明書（4列目）に保存されているIDの1つと一致します。
6. The network address inserted in the "Destination IP Address" column is the source address as seen by P2 (i.e., the "received" header field parameter). It could be the case that the host name of P1 resolves to different IP addresses due to round-robin DNS. However, the aliased connection is to be established with the original sender of the request.
6. 「宛先IPアドレス」列に挿入されたネットワークアドレスは、P2（つまり、「受信」ヘッダーフィールドパラメーター）で見られるソースアドレスです。P1のホスト名は、ラウンドロビンDNSのために異なるIPアドレスに解決する場合があります。ただし、エイリアス接続は、リクエストの元の送信者で確立されます。
The following are the requirements that motivated this specification:
以下は、この仕様を動機付けた要件です。
1. A connection sharing mechanism should allow SIP entities to reuse existing connections for requests and responses originated from either peer in the connection.
1. 接続共有メカニズムにより、SIPエンティティは、接続中のどちらかのピアから発生するリクエストと応答の既存の接続を再利用できるようにする必要があります。
2. A connection sharing mechanism must not require clients to send all traffic from well-know SIP ports.
2. 接続共有メカニズムは、クライアントがよく知られているSIPポートからすべてのトラフィックを送信することを必要としてはなりません。
3. A connection sharing mechanism must not require configuring ephemeral port numbers in DNS.
3. 接続共有メカニズムは、DNSではかないポート番号の構成を必要としないはずです。
4. A connection sharing mechanism must prevent unauthorized hijacking of other connections.
4. 接続共有メカニズムは、他の接続の不正なハイジャックを防ぐ必要があります。
5. Connection sharing should persist across SIP transactions and dialogs.
5. 接続共有は、SIPトランザクションとダイアログ全体で持続する必要があります。
6. Connection sharing must work across name-based virtual SIP servers.
6. 接続共有は、名前ベースの仮想SIPサーバーで動作する必要があります。
7. There is no requirement to share a complete path for ordinary connection reuse. Hop-by-hop connection sharing is more appropriate.
7. 通常の接続の再利用のための完全なパスを共有する要件はありません。ホップバイホップ接続共有がより適切です。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234]. This document extends the via-params to include a new via-alias defined below.
次の構文仕様では、RFC 5234 [RFC5234]に記載されているように、増強されたバックナウル形式（BNF）を使用しています。このドキュメントは、Via-Paramsを拡張して、以下に定義する新しいVia-Aliasを含めます。
via-params =/ via-alias via-alias = "alias"
via-params =/ via-alias via-alias = "alias"
Clients SHOULD keep connections up as long as they are needed. Connection reuse works best when the client and the server maintain their connections for long periods of time. Clients, therefore, SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.
クライアントは、必要な限り接続を維持する必要があります。接続の再利用は、クライアントとサーバーが長期間接続を維持する場合に最適に機能します。したがって、クライアントは、トランザクションまたはダイアログの終了時に接続を自動的にドロップしてはなりません。
The mechanism for connection reuse uses a new Via header field parameter. The "alias" header field parameter is included in a Via header field value to indicate that the client wants to create a transport layer alias. The client places its advertised address in the Via header field value (in the sent-by production).
接続再利用のメカニズムは、ヘッダーフィールドパラメーターを使用して新しいものを使用します。「エイリアス」ヘッダーフィールドパラメーターは、クライアントがトランスポートレイヤーエイリアスを作成することを望んでいることを示して、ヘッダーフィールド値のVIAに含まれています。クライアントは、広告されたアドレスをViaヘッダーフィールド値（セントごとの生産）に配置します。
If the client places an "alias" header field parameter in the topmost Via header of the request, the client SHOULD keep the connection open for as long as the resources on the host operating system allow it to, and that the client MUST accept requests over this connection -- in addition to the default listening port -- from its downstream peer. And furthermore, the client SHOULD reuse the connection when subsequent requests in the same or different transactions are destined to the same resolved address.
クライアントがリクエストのヘッダーを介して「エイリアス」ヘッダーフィールドパラメーターを最上部に配置する場合、ホストオペレーティングシステムのリソースが許可され、クライアントがリクエストを受け入れる必要がある限り、クライアントは接続を開いたままにしておく必要があります。この接続は、デフォルトのリスニングポートに加えて、下流のピアから。さらに、同じまたは異なるトランザクションで後続の要求が同じ解決されたアドレスに運命づけられている場合、クライアントは接続を再利用する必要があります。
Note that RFC 3261 states that a response arrives over the same connection that was opened for a request.
RFC 3261は、リクエストのために開かれたのと同じ接続に応答が到着することに注意してください。
Whether or not to allow an aliased connection ultimately depends on the recipient of the request; i.e., the client does not get any confirmation that its downstream peer created the alias, or indeed that it even supports this specification. Thus, clients MUST NOT assume that the acceptance of a request by a server automatically enables connection aliasing. Clients MUST continue receiving requests on their default port.
エイリアス接続を許可するかどうかは、最終的にリクエストの受信者に依存するかどうか。つまり、クライアントは、その下流のピアがエイリアスを作成したこと、または実際にこの仕様をサポートしていることを確認していません。したがって、クライアントは、サーバーによる要求を受け入れると、接続エイリアシングが自動的に有効になると想定してはなりません。クライアントは、デフォルトのポートでリクエストを継続する必要があります。
Clients MUST authenticate the connection before forming an alias; Section 9.1 discusses the authentication steps in more detail. Once the server has been authenticated, the client MUST cache, in the alias table, the identity (or identities) of the server as determined in Section 7.1 of RFC 5922 [RFC5922]. The client MUST also populate the destination IP address, port, and transport of the server in the alias table; these fields are retrieved from executing RFC3263 server resolution process on the next-hop URI. And finally, the client MUST populate the alias descriptor field with the connection handle (or identifier) used to connect to the server.
クライアントは、エイリアスを形成する前に接続を認証する必要があります。セクション9.1では、認証の手順をより詳細に説明します。サーバーが認証されると、クライアントは、RFC 5922 [RFC5922]のセクション7.1で決定されたサーバーのアイデンティティ（またはアイデンティティ）をエイリアステーブルにキャッシュする必要があります。また、クライアントは、エイリアステーブルのサーバーの宛先IPアドレス、ポート、およびトランスポートを設置する必要があります。これらのフィールドは、Next-Hop URIでRFC3263サーバー解像度プロセスの実行から取得されます。そして最後に、クライアントは、サーバーへの接続に使用される接続ハンドル（または識別子）を使用して、エイリアス記述子フィールドを入力する必要があります。
Once the alias table has been updated with a resolved address, and the client wants to send a new request in the direction of the server, the client reuses the connection only if all of the following conditions hold:
エイリアステーブルが解決されたアドレスで更新され、クライアントがサーバーの方向に新しいリクエストを送信したい場合、クライアントは次のすべての条件が保持された場合にのみ接続を再利用します。
1. The client uses the RFC3263 resolution on a URI and arrives at a resolved address contained in the alias table, and
1. クライアントは、URIでRFC3263解像度を使用し、エイリアステーブルに含まれる解決されたアドレスに到着します。
2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.
2. RFC3263サーバー解像度に使用されるURIは、その解決されたアドレスに対応するエイリアステーブル行に保存されているアイデンティティの1つと一致します。
Clients MUST be prepared for the case that the connection no longer exists when they are ready to send a subsequent request over it. In such a case, a new connection MUST be opened to the resolved address and the alias table updated accordingly.
クライアントは、その後のリクエストを送信する準備ができたときに接続が存在しなくなった場合に備えなければなりません。そのような場合、解決されたアドレスに新しい接続を開く必要があり、それに応じてエイリアステーブルが更新されます。
This behavior has an adverse side effect when a CANCEL request or an ACK request for a non-2xx response is sent downstream. Normally, these would be sent over the same connection over which the INVITE request was sent. However, if between the sending of the INVITE request and subsequent sending of the CANCEL request or ACK request to a non-2xx response, the connection was closed, then the client SHOULD open a new connection to the resolved address and send the CANCEL request or ACK request there instead. The client MAY insert the newly opened connection into the alias table.
この動作には、キャンセル要求または非2XX応答のACKリクエストが下流に送信されると、副作用が有害です。通常、これらは招待リクエストが送信されたのと同じ接続の上に送信されます。ただし、招待リクエストの送信と、その後のキャンセルリクエストまたはACKリクエストが非2XX応答に送信された場合、接続は閉じられた場合、クライアントは解決されたアドレスへの新しい接続を開き、キャンセルリクエストまたはキャンセルリクエストを送信する必要があります。代わりにACKリクエスト。クライアントは、新しく開いた接続をエイリアステーブルに挿入できます。
Servers SHOULD keep connections up unless they need to reclaim resources. Connection reuse works best when the client and the server maintain their connections for long periods of time. Servers, therefore, SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.
サーバーは、リソースを取り戻す必要がない限り、接続を維持する必要があります。接続の再利用は、クライアントとサーバーが長期間接続を維持する場合に最適に機能します。したがって、サーバーは、ダイアログのトランザクションまたは終了の完了時に接続を自動的にドロップしてはなりません。
When a server receives a request over TLS whose topmost Via header field contains an "alias" header field parameter, it signifies that the upstream client will leave the connection open beyond the transaction and dialog lifetime, and that subsequent transactions and dialogs that are destined to a resolved address that matches the identifiers in the advertised address in the topmost Via header field can reuse this connection.
ヘッダーフィールドを介して最上部のTLSを介したリクエストを受信すると、「エイリアス」ヘッダーフィールドパラメーターが含まれているTLSを受信すると、上流のクライアントがトランザクションとダイアログの寿命を超えて接続を開いたままにし、その後のトランザクションとダイアログがヘッダーフィールドを介して最上部の広告アドレスの識別子に一致する解決されたアドレスは、この接続を再利用できます。
Whether or not to use in the reverse direction a connection marked with the "alias" Via header field parameter ultimately depends on the policies of the server. It can choose to honor it, and thereby send subsequent requests over the aliased connection. If the server chooses not to honor an aliased connection, the server MUST allow the request to proceed as though the "alias" header field parameter was not present in the topmost Via header.
逆方向に使用するかどうかにかかわらず、ヘッダーフィールドパラメーターを介して「エイリアス」とマークされた接続が最終的にサーバーのポリシーに依存します。それはそれを尊重することを選択し、それによってエイリアス接続を介してその後のリクエストを送信できます。サーバーがエイリアス接続を尊重しないことを選択した場合、サーバーは、「エイリアス」ヘッダーフィールドパラメーターがヘッダーを介して最上部に存在しないかのようにリクエストを続行することを許可する必要があります。
This assures interoperability with RFC3261 server behavior. Clients can include the "alias" header field parameter without fear that the server will reject the SIP request because of its presence.
これにより、RFC3261サーバーの動作との相互運用性が保証されます。クライアントは、サーバーがその存在のためにSIP要求を拒否することを恐れることなく、「エイリアス」ヘッダーフィールドパラメーターを含めることができます。
Servers MUST be prepared to deal with the case that the aliased connection no longer exist when they are ready to send a subsequent request over it. This can happen if the peer ran out of operating system resources and had to close the connection. In such a case, the server MUST open a new connection to the resolved address and the alias table updated accordingly.
サーバーは、その後のリクエストを送信する準備ができたときにエイリアス接続が存在しなくなったケースに対処するために準備する必要があります。これは、ピアがオペレーティングシステムのリソースを使い果たし、接続を閉じる必要がある場合に発生する可能性があります。そのような場合、サーバーは解決されたアドレスへの新しい接続を開く必要があり、それに応じてエイリアステーブルが更新されました。
If the sent-by production of the Via header field contains a port, the server MUST use it as a destination port. Otherwise, the default port is the destination port.
Viaヘッダーフィールドのセントごとの生産にポートが含まれている場合、サーバーは宛先ポートとして使用する必要があります。それ以外の場合、デフォルトのポートは宛先ポートです。
Servers MUST follow the authentication steps outlined in Section 9.2 to authenticate the connection before forming an alias.
サーバーは、セクション9.2で概説されている認証手順に従って、エイリアスを形成する前に接続を認証する必要があります。
The server, if it decides to reuse the connection, MUST cache in the alias table the identity (or identities) of the client as they appear in the X.509 certificate subjectAlternativeName extension field. The server also populates the destination IP address, port, and transport in the alias table from the topmost Via header field (using the
サーバーは、接続を再利用することを決定した場合、X.509証明書SubjectAlternativename拡張フィールドに表示されるクライアントのアイデンティティ（またはID）をエイリアステーブルにキャッシュする必要があります。サーバーはまた、ヘッダーフィールドを介して最上部からエイリアステーブルの宛先IPアドレス、ポート、およびトランスポートを承認します（を使用して
";received" parameter for the destination IP address). If the port number is omitted, a default port number of 5061 is to be used. And finally, the server populates the alias descriptor field with the connection handle (or identifier) used to accept the connection from the client (see Section 5 for the contents of the alias table).
「;宛先IPアドレスの受信」パラメーター）。ポート番号が省略されている場合、5061のデフォルトのポート番号を使用します。最後に、サーバーは、クライアントからの接続を受け入れるために使用される接続ハンドル（または識別子）を使用して、エイリアス記述子フィールドを入力します（エイリアステーブルの内容についてはセクション5を参照）。
Once the alias table has been updated, and the server wants to send a request in the direction of the client, it reuses the connection only if all of the following conditions hold:
エイリアステーブルが更新され、サーバーがクライアントの方向にリクエストを送信したい場合、次のすべての条件が保持された場合にのみ接続を再利用します。
1. The server, which acts as a client for this transaction, uses the RFC3263 resolution process on a URI and arrives at a resolved address contained in the alias table, and
1. このトランザクションのクライアントとして機能するサーバーは、URIでRFC3263解像度プロセスを使用し、エイリアステーブルに含まれる解決されたアドレスに到着し、
2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.
2. RFC3263サーバー解像度に使用されるURIは、その解決されたアドレスに対応するエイリアステーブル行に保存されているアイデンティティの1つと一致します。
Either the client or the server may terminate a TLS session by sending a TLS closure alert. Before closing a TLS connection, the initiator of the closure MUST either wait for any outstanding SIP transactions to complete, or explicitly abandon them.
クライアントまたはサーバーのいずれかが、TLSクロージャーアラートを送信することにより、TLSセッションを終了する場合があります。TLS接続を閉じる前に、閉鎖のイニシエーターは、未解決のSIPトランザクションが完了するのを待つか、明示的に放棄する必要があります。
After the initiator of the close has sent a closure alert, it MUST discard any TLS messages until it has received a similar alert from its peer. The receiver of the closure alert MUST NOT start any new SIP transactions after the receipt of the closure alert.
終了のイニシエーターがクロージャーアラートを送信した後、ピアから同様のアラートを受け取るまで、TLSメッセージを破棄する必要があります。閉鎖アラートの受信者は、閉鎖アラートを受け取った後、新しいSIPトランザクションを開始してはなりません。
This document presents requirements and a mechanism for reusing existing connections easily. Unauthenticated connection reuse would present many opportunities for rampant abuse and hijacking. Authenticating connection aliases is essential to prevent connection hijacking. For example, a program run by a malicious user of a multiuser system could attempt to hijack SIP requests destined for the well-known SIP port from a large relay proxy.
このドキュメントは、既存の接続を簡単に再利用するための要件とメカニズムを示しています。無慈悲な接続の再利用は、ramp延する虐待とハイジャックの多くの機会を提示するでしょう。接続エイリアスを認証することは、接続のハイジャックを防ぐために不可欠です。たとえば、Multiuserシステムの悪意のあるユーザーが実行するプログラムは、大規模なリレープロキシから有名なSIPポートに向けられたSIPリクエストをハイジャックしようとする可能性があります。
When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 7.3 ("Client behavior") of RFC 5922 [RFC5922].
TLSクライアントがサーバーとの接続を確立すると、サーバーのX.509証明書が表示されます。認証は、RFC 5922 [RFC5922]のセクション7.3（「クライアントの行動」）で説明されています。
A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 ("Server behavior") of RFC 5922 [RFC5922].
この仕様に準拠したTLSサーバーは、クライアント証明書を要求する必要があります。クライアントが証明書を所有している場合、相互認証のためにサーバーに提示され、認証はRFC 5922 [RFC5922]のセクション7.4（「サーバーの動作」）で説明されています。
If the client does not present a certificate, the server MUST proceed as if the "alias" header field parameter was not present in the topmost Via header. In this case, the server MUST NOT update the alias table.
クライアントが証明書を提示しない場合、サーバーはヘッダーを介して最上部に「エイリアス」ヘッダーフィールドパラメーターが存在しないかのように進む必要があります。この場合、サーバーはエイリアステーブルを更新してはなりません。
Virtual servers present special considerations for connection reuse. Under the name-based virtual server scheme, one SIP proxy can host many virtual domains using one IP address and port number. If adequate defenses are not put in place, a connection opened to a downstream server on behalf of one domain can be reused to send requests in the backwards direction to a different domain. The "Destination Identity" column in the alias table has been added to aid in such defenses.
仮想サーバーは、接続の再利用に関する特別な考慮事項を提示します。名前ベースの仮想サーバースキームでは、1つのIPアドレスとポート番号を使用して、1つのSIPプロキシが多くの仮想ドメインをホストできます。適切な防御が導入されていない場合、1つのドメインに代わって下流サーバーに開かれた接続を再利用して、逆方向のリクエストを別のドメインに送信できます。エイリアステーブルの「宛先ID」列が追加され、そのような防御を支援しています。
Virtual servers MUST only perform connection reuse for TLS connections; virtual servers MUST NOT perform connection reuse for other connection-oriented transports. To understand why this is the case, note that the alias table caches not only which connections go to which destination addresses, but also which connections have authenticated themselves as responsible for which domains. If a message is to be sent in the backwards direction to a new SIP domain that resolves to an address with a cached connection, the cached connection cannot be used because it is not authenticated for the new domain.
仮想サーバーは、TLS接続の接続再利用のみを実行する必要があります。仮想サーバーは、他の接続指向のトランスポートに対して接続の再利用を実行してはなりません。なぜこれが事実であるのかを理解するために、エイリアステーブルはどの接続がどの宛先アドレスに行くかだけでなく、どの接続がどのドメインに対して責任を負っているかを認証していることに注意してください。メッセージが、キャッシュされた接続でアドレスに解決する新しいSIPドメインに逆方向に送信される場合、新しいドメインに対して認証されていないため、キャッシュされた接続を使用できません。
As an example, consider a proxy P1 that hosts two virtual domains -- example.com and example.net -- on the same IP address and port. RFC3263 server resolution is set up such that a DNS lookup of example.com and example.net both resolve to an {IP-address, port, transport} tuple of {192.0.2.1, 5061, TLS}. A user agent in the example.com domain sends a request to P1 causing it to make a downstream connection to its peering proxy, P2, and authenticating itself as a proxy in the example.com domain by sending it a X.509 certificate asserting such an identity. P2's alias table now looks like the following: Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.1 5061 TLS sip:example.com 18
例として、同じIPアドレスとポートに2つの仮想ドメイン（example.comとExample.net）をホストするプロキシP1を検討してください。RFC3263サーバー解像度は、example.comとexample.netのDNSルックアップが{192.0.2.1、5061、TLS}のタプルの両方を解決するように設定されています。example.comドメインのユーザーエージェントは、P1にリクエストを送信して、Pearing Proxy、P2にダウンストリーム接続を行い、X.509証明書をそのような主張するX.509証明書のプロキシとして認証することを行います。アイデンティティ。P2のエイリアステーブルは次のようになりました。
At some later point in time, a user agent in P2's domain wants to send a request to a user agent in the example.net domain. P2 performs an RFC3263 server resolution process on sips:example.net to derive a resolved address tuple {192.0.2.1, 5061, TLS}. It appears that a connection to this network address is already cached in the alias table; however, P2 cannot reuse this connection because the destination identity (sip:example.com) does not match the server identity used for RFC3261 resolution (sips:example.net). Hence, P2 will open up a new connection to the example.net virtual domain hosted on P1. P2's alias table will now look like:
後の時点で、P2のドメインのユーザーエージェントは、example.netドメインのユーザーエージェントにリクエストを送信したいと考えています。P2は、SIPSでRFC3263サーバー解像度プロセスを実行します：example.netは、解決されたアドレスTuple {192.0.2.1、5061、TLS}を導出します。このネットワークアドレスへの接続は、エイリアステーブルですでにキャッシュされているようです。ただし、宛先ID（SIP：Example.com）がRFC3261解像度（SIPS：Example.NET）に使用されるサーバーIDと一致しないため、P2はこの接続を再利用できません。したがって、P2はP1でホストされているExample.NET仮想ドメインへの新しい接続を開きます。P2のエイリアステーブルは次のようになります。
Destination Destination Destination Destination Alias
IP Address Port Transport Identity Descriptor
...
192.0.2.1 5061 TLS sip:example.com 18
192.0.2.1 5061 TLS sip:example.net 54
The identities conveyed in an X.509 certificate are associated with a specific TLS connection. Absent such a guarantee of an identity tied to a specific connection, a normal TCP or SCTP connection cannot be used to send requests in the backwards direction without a significant risk of inadvertent (or otherwise) connection hijacking.
X.509証明書で伝えられるアイデンティティは、特定のTLS接続に関連付けられています。特定の接続に結び付けられたアイデンティティのそのような保証がなければ、通常のTCPまたはSCTP接続を使用して、不注意（またはその他の）接続ハイジャックの重大なリスクなしに後方方向にリクエストを送信することはできません。
The above discussion details the impact on P2 when connection reuse is desired for virtual servers. There is a subtle, but important impact on P1 as well.
上記の説明では、仮想サーバーに接続の再利用が望まれる場合のP2への影響について詳しく説明しています。P1にも微妙ですが重要な影響があります。
P1 should keep separate alias tables for the requests served from the UAs in the example.com domain from those served by the UAs in the example.net domain. This is so that the boundary between the two domains is preserved; P1 MUST NOT open a connection on behalf of one domain and reuse it to send a new request on behalf of another domain.
P1は、example.netドメインのUASが提供するものから、Example.comドメインのUASから提供されるリクエストの個別のエイリアステーブルを保持する必要があります。これは、2つのドメイン間の境界が保存されるようにするためです。P1は、1つのドメインに代わって接続を開き、再利用して別のドメインに代わって新しいリクエストを送信してはなりません。
Connection reuse has an interaction with the DNS SRV load balancing mechanism. To understand the interaction, consider the following figure:
接続の再利用には、DNS SRVロードバランスメカニズムとの相互作用があります。相互作用を理解するには、次の図を検討してください。
/+---- S1
+-------+/
| Proxy |------- S2
+-------+\
\+---- S3
Figure 5: Load balancing
図5：バランシングを積み込みます
Here, the proxy uses the DNS SRV to load balance across the three servers, S1, S2, and S3. Using the connect reuse mechanism specified in this document, over time the proxy will maintain a distinct aliased connection to each of the servers. However, once this is done, subsequent traffic is load balanced across the three downstream servers in the normal manner.
ここでは、プロキシはDNS SRVを使用して、3つのサーバー、S1、S2、およびS3のバランスをロードします。このドキュメントで指定された接続再利用メカニズムを使用して、プロキシは時間の経過とともに、各サーバーへの明確なエイリアス接続を維持します。ただし、これが完了すると、その後のトラフィックは、通常の方法で3つのダウンストリームサーバー全体で負荷のバランスが取れます。
This specification defines a new Via header field parameter called "alias" in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by RFC 3968 [RFC3968]. The required information is:
この仕様は、RFC 3968 [RFC3968]によって作成されたレジストリに従って、「ヘッダーフィールドパラメーターとパラメーター値」の「エイリアス」と呼ばれる新しいviaヘッダーフィールドパラメーターを「エイリアス」と定義します。必要な情報は次のとおりです。
Header Field Parameter Name Predefined Values Reference
___________________________________________________________________
Via alias No RFC5923
Thanks to Jon Peterson for helpful answers about certificate behavior with SIP, Jonathan Rosenberg for his initial support of this concept, and Cullen Jennings for providing a sounding board for this idea. Other members of the SIP WG that contributed to this document include Jeroen van Bemmel, Keith Drage, Matthew Gardiner, Rajnish Jain, Benny Prijono, and Rocky Wang.
SIPでの証明書の動作についての有益な回答、ジョナサンローゼンバーグがこのコンセプトを最初にサポートしてくれたこと、およびこのアイデアのサウンドボードを提供してくれたカレンジェニングスについては、Jon Petersonに感謝します。この文書に貢献したSIP WGの他のメンバーには、Jeroen Van Bemmel、Keith Drage、Matthew Gardiner、Rajnish Jain、Benny Prijono、Rocky Wangが含まれます。
Dale Worley and Hadriel Kaplan graciously performed a WGLC review of the document. The resulting revision has benefited tremendously from their feedback.
Dale WorleyとHadriel Kaplanは、ドキュメントのWGLCレビューを丁寧に実行しました。結果として生じる改訂は、彼らのフィードバックから大きな恩恵を受けました。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 5234、2008年1月。
[RFC5922] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、Lawrence、S。、およびB. Laboratories、「セッション開始プロトコル（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の番号が割り当てられたヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[Book-Rescorla-TLS] Rescorla, E., "SSL and TLS: Designing and Building Secure Systems", Addison-Wesley Publishing, 2001.
[Book-Rescorla-Tls] Rescorla、E。、「SSLおよびTLS：Secure Systemsの設計と構築」、Addison-Wesley Publishing、2001。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
Authors' Addresses
著者のアドレス
Vijay K. Gurbani (editor) Bell Laboratories, Alcatel-Lucent
Vijay K. Gurbani（編集者）Bell Laboratories、Alcatel-Lucent
EMail: vkg@alcatel-lucent.com
Rohan Mahy Unaffiliated
Rohan Mahyは関係ありません
EMail: rohan@ekabal.com
Brett Tate BroadSoft
Brett Tate Broadsoft
EMail: brett@broadsoft.com