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)
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証明書を使用して自分自身を認証する通信エンドポイントの両方に前提としています。このような理由から、我々は唯一のストリーム制御伝送プロトコル（SCTP）の上にTCPおよびTLS上でTLSの接続の再利用を検討してください。また、このドキュメントでは、接続の再利用および仮想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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ...................................................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.
次の例では、Aは、TCPポート5061（TCP上のTLS経由のSIPのデフォルトポート）上のTLS経由のSIP要求をリッスンしますが、これらのエンティティは、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：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で定義される）永続的な接続の概念、ならびにによって送信された他の要求のための既存の接続を再利用を含みます接続の発信元。しかし、後方方向に送られる新しい要求は、 - 上記の例では、宛てBからの要求 - は、既存の接続を再利用する可能性は低いです。これはしばしば、以下に示すように、各方向に送信されたリクエストに対して1つの接続を使用するSIPエンティティの対を引き起こします。
+-----------+ 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以外は図1の画像に似ていると考えられることができ、Aが送信したいときBの両方は、B上のポートAに49160とポート5061との間に、例えば、単一の共有接続を使用します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ヘッダーフィールドの送信されたバイプロダクションルールで発生したアドレス。
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）とファイアウォールおそらく - - アウトバウンド文書[RFC5626]で説明されたメカニズムを使用して接続を再利用し、特定の方向に接続を開くことができSIPエンティティ。
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、一般的に高価な非対称認証及び鍵生成アルゴリズム、および証明書の検証を確立するために、ラウンドトリップの一握りが必要です。 TLSハンドシェイクにより、サーバーのCPUが飽和が、それはすでに（レスコラ[ブックレスコラ-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は、ダイアログに関与滞在にRecord-Routeメカニズムを使用する場合について示したコールフローを考えてみましょう。プロキシBは、ちょうどBYE要求を送信するために、新たな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.
初期INVITE要求の後に既存のダイアログ（例えば、再INVITE要求またはBYE要求の文脈においても要求、後続の要求のための（Bから上へ）は、第2の接続をセットアップする、またはSUBSCRIBEリクエストの後にリクエストを通知したりREFERリクエスト）、また、特に長い往復時間とネットワークの過度の遅延を（）引き起こす可能性があります。したがって、可能な限り接続を再利用することが有利です。
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).
再INVITE要求またはUPDATE要求がステップ外であることから、メディアセッション状態を回避するために、自動的にかつ迅速に処理される場合、ビューのユーザの期待の観点から、それが有利です。再INVITEリクエストが新しいTLS接続を必要とする場合、再INVITEリクエストは、いくつかの余分なラウンドトリップ時間遅れで表示することができます。ラウンドトリップ時間に応じて、この合成遅延は、知覚や人間のユーザにも、迷惑である可能性があります。これはいくつかの一般的なSIPコールフローのために特に問題である（例えば、RFC 3725 [RFC3725]で図4の推奨例のフローは、要求を再INVITE多くを使用します）。
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.
私たちは今、二つの隣接するプロキシ間の通信の文脈でより詳細にこの作業を説明します。一般性を失うことなく、同一の技術は、ユーザエージェントクライアント（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は、エッジプロキシ（図4参照）としてそれらを使用するユーザエージェントにSIP要求をルーティングする責任プロキシです。
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.
説明の目的のために以下の議論は、TLS操作のためのトランスポートとしてTCPを使用しています。別のストリーミング輸送 - など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ヘッダーフィールドを検査します。 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.
P2が後方方向に要求するための接続を再利用するために、図4を参照して、この方向に送信されたリクエストの検証モデル（P1へすなわち、P2）のそれぞれに通常「接続と等価であることが重要です方向」モデル、P2が後方方向で新しい接続を開くと発表X.509証明書を調べて、接続を検証しますクライアントとして動作することを特徴とします。接続を再利用するという行為は、接続の再利用が採用されていなかった、彼らは同じ宛先に配信されていた場合にのみ、後方方向に届けます要求する所望の特性を必要とします。このプロパティを保証するために、TLS接続が最初に認証されたときにP2へのP1が提示した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は、その上流側ユーザエージェントのいずれかから要求を取得し、RFC3263 [RFC3263]サーバ選択を行った後、P2の解決されたアドレスに到達します。 P1は、エイリアステーブルを維持し、RFC3263サーバ選択を介して決定されるように、それは、IPアドレス、ポート番号、及びP2の輸送にエイリアステーブルを移入します。 P1はP2にリクエストを送信する前に（それによって挿入）最上位のViaヘッダフィールドの「エイリアス」ヘッダフィールドパラメータを追加します。要求が送信された上（ポート番号を含む）、Viaヘッダフィールドの送信ごとに生成規則における値、およびトランスポートは、P1のアドバタイズされたアドレスとなります。
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias
ビア：SIP / 2.0 / TLS p1.example.com;ブランチ= z9hG4bKa7c8dze;別名
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（9.1節を参照）検証のためP1へのX.509証明書を提示します。接続認証と受け入れの際に、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アドレス、ポート、およびトランスポートは、次のホップ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).
サーバーが提示したX.509証明書で主張2. 4列目のエントリは、サーバのアイデンティティで構成されています。サーバが正式に認証された後にこれらのアイデンティティがクライアントによってキャッシュされている（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は、そのドメイン内のユーザーエージェントのいずれかからの要求を取得したときに、次の条件がすべて保持している場合にのみ場合は、いくつかの後の時点で、それはソケットディスクリプタ25を介してアクセス可能なエイリアスの接続を再利用します。
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
B. The URI used for the RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).
RFC3263サーバ解像度がキャッシュされた証明書（第4列）に格納された識別情報のいずれかと一致するためB. URIを用います。
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は、エイリアス接続（即ち、P1に向かってP2からの要求を受け入れる）としてこの接続を使用する意思があるかどうかを決定するためにViaヘッダーフィールド最上部を調べます。 P2におけるViaヘッダーフィールドは以下のように見える（ヘッダフィールドパラメータがP2によって追加された「受信」）。
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias; received=192.0.2.1
ビア：SIP / 2.0 / TLS p1.example.com;ブランチ= z9hG4bKa7c8dze;別名。受信= 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は、最上位のViaヘッダーフィールドにアドバタイズアドレスを使用して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.
そうでない場合、ポートが、または5061に存在する場合、2ポートフィールドは、アドバタイズされたアドレス（最上位Viaヘッダーフィールド）から取り込まれます。
3. The transport field is populated from the advertised address (topmost Via header field).
3.トランスポートフィールドはアドバタイズアドレス（最上位Viaヘッダーフィールド）から取り込まれます。
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).
クライアントが提示したX.509証明書にアサート4.第四列のエントリは、クライアントのアイデンティティで構成されています。クライアントが正式に認証された後にこれらのアイデンティティは、サーバによってキャッシュされている（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は、そのドメイン内のユーザーエージェントのいずれかからの要求を取得したときに、次の条件がすべて保持している場合にのみ場合は、いくつかの後の時点で、それはソケットディスクリプタ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
B. The URI used for RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).
RFC3263サーバ解像度がキャッシュされた証明書（第4列）に格納された識別情報のいずれかと一致するためB. URIを用います。
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.
P2によって見られるように6.「宛先IPアドレス」欄に挿入されたネットワークアドレスは、送信元アドレス（すなわち、ヘッダフィールドパラメータを「受信」）。これは、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.
SIPエンティティは、要求と応答のための既存の接続を再利用できるようにする必要があります。1.接続の共有メカニズムは、接続のピアのいずれかに由来しました。
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）を使用します。この文書では、ビアのparamsを経由して、エイリアス以下に定義する新しいを含めるように拡張します。
via-params =/ via-alias via-alias = "alias"
ビアのparams = /ビア・ビア・エイリアスエイリアス=「エイリアス」
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ヘッダーフィールド値に含まれています。クライアントは、（送信された-で生産中）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アドレス、ポート、およびエイリアステーブル内のサーバーの輸送を移入しなければなりません。これらのフィールドはネクストホップ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.
RFC3263サーバ解像度がその解決されたアドレスに対応するエイリアステーブルの行に記憶された識別情報のいずれかと一致2. URIを用います。
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.
この動作は、CANCEL要求または非2xxの応答のためのACK要求が下流送られる有害な副作用を持っています。通常、これらは、INVITEリクエストを送信した上で、同じ接続を介して送信されることになります。接続が閉じられましたが、INVITE要求とそれに続く2xx以外の応答にCANCEL要求やACKリクエストの送信の送信間の場合、クライアントが解決されたアドレスへの新しい接続を開き、CANCELリクエストを送るべきか代わりに、そこに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.
サーバーは、Viaヘッダーフィールドの最上位TLSオーバー要求を受信すると、「エイリアス」ヘッダフィールドのパラメータが含まれている、それが上流のクライアントがトランザクションとダイアログ寿命を超えた接続を開いたままにして、その後のトランザクションとダイアログが宛てされることになることを意味し最上位のViaヘッダーフィールドでアドバタイズアドレスに識別子と一致する解決されたアドレスは、この接続を再利用することができます。
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.
ヘッダフィールドパラメータによって逆方向に「エイリアス」でマークされた接続を使用するかどうかは、最終的には、サーバーのポリシーに依存します。それはそれを尊重することを選択し、それによってエイリアス接続を介して後続の要求を送信することができます。サーバーがエイリアス接続を尊重しないことを選択した場合、サーバーは、「エイリアス」ヘッダフィールドのパラメータは、最上位のViaヘッダには存在しなかったかのように、要求の続行を許可しなければなりません。
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の拡張フィールドに表示されるサーバーは、エイリアステーブルにクライアントのアイデンティティ（またはアイデンティティ）をキャッシュしなければなりません。サーバは、また、使用して最上位のViaヘッダフィールドからエイリアステーブル内の宛先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.
RFC3263サーバ解像度がその解決されたアドレスに対応するエイリアステーブルの行に記憶された識別情報のいずれかと一致2. URIを用います。
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.
この文書では、要件と簡単に既存の接続を再利用するためのメカニズムを提供します。認証されていない接続の再利用が横行虐待や乗っ取りのための多くの機会を提示します。接続エイリアスを認証すると、接続ハイジャックを防ぐために不可欠です。例えば、マルチユーザシステムの悪意あるユーザが実行するプログラムは、大規模なリレープロキシからよく知られている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（「Serverの動作」）で説明したように、それは、相互認証のためにサーバーに提示され、認証が進行されます。
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.
クライアントが証明書を提示していない場合は、「エイリアス」ヘッダフィールドのパラメータは、最上位のViaヘッダには存在しなかったかのように、サーバは続行しなければなりません。この場合、サーバーは、エイリアステーブルをアップデートしてはいけません。
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つのSIPプロキシは、1つのIPアドレスとポート番号を使用して多くの仮想ドメインをホストすることができます。十分な防御が所定の位置に置かれていない場合は、1つのドメインに代わって下流サーバーに開かれた接続は、別のドメインに後方方向にリクエストを送信するために再利用することができます。エイリアステーブルの「デスティネーション・アイデンティティ」の欄には、このような防御を支援するために追加されました。
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:
example.comおよびexample.net - - 同じIPアドレスとポートの例として、2つの仮想ドメインをホストするプロキシP1を考えます。 RFC3263サーバ解像度が設定されexample.comとexample.netのDNSルックアップの両方{192.0.2.1、5061、TLS}の{IPアドレス、ポート、トランスポート}タプルに解決されるようになっています。 example.comドメイン内のユーザエージェントは、それがそのピアプロキシ下流接続を確立させるP1に要求を送信P2、およびそれにかかるアサートX.509証明書を送信することによって、example.comドメイン内のプロキシとしてそれ自体を認証しますアイデンティティ。 P2のエイリアステーブルは現在、次のようになります。
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.1 5061 TLS sip:example.com 18
先先先先エイリアスIPアドレスポート交通アイデンティティ記述... 192.0.2.1 5061 TLSのSIP：example.com 18
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は、SIPでRFC3263サーバ解像度処理を行う：example.netが解決されたアドレスタプル{192.0.2.1、5061、TLS}を導出します。このネットワークアドレスへの接続がすでにエイリアステーブルにキャッシュされていることが表示されます。 （：example.com SIP）RFC3261解像度（：example.net SIPS）に使用されるサーバIDと一致しない送信先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
先先先先エイリアスIPアドレスポート交通アイデンティティ記述... 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ドメイン内のUAが提供するものとはexample.comドメインでのUAから提供要求に対して別々のエイリアステーブルを維持する必要があります。二つのドメイン間の境界が保存されるようです。 P1は、一つのドメインに代わって接続を開き、別のドメインに代わって新しい要求を送信するためにそれを再利用してはいけません。
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.
ここでは、プロキシは、3台のサーバ、S1、S2、およびS3間で負荷を分散するためのDNS SRVを使用しています。この文書で指定された接続の再利用メカニズムを使用して、時間をかけてプロキシはサーバのそれぞれに個別のエイリアスの接続を維持します。これが行われた後しかし、後続のトラフィックは通常の方法で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、この概念の彼の初期のサポートのためのジョナサン・ローゼンバーグ、およびカレンジェニングスと証明書の挙動に関する有用な答えのためのジョン・ピーターソンに感謝します。この文書に貢献したSIP WGの他のメンバーはイェルーンバンBemmel、キース糖剤、マシュー・ガーディナー、Rajnishジャイナ教、ベニープリジョノ、ロッキー王が含まれます。
Dale Worley and Hadriel Kaplan graciously performed a WGLC review of the document. The resulting revision has benefited tremendously from their feedback.
デールウォーリーとHadrielカプランは、優雅に、文書の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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ローゼンバーグ、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]クロッカー、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.、ローレンス、S.、およびB.研究所、 "セッション開始プロトコル（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]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "インターネットは、セッション開始プロトコル（SIP）のための番号機関（IANA）ヘッダーフィールドパラメータレジストリを割り当てられました"。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[Book-Rescorla-TLS] Rescorla, E., "SSL and TLS: Designing and Building Secure Systems", Addison-Wesley Publishing, 2001.
[ブックレスコラ-TLS]レスコラ、E.、 "SSLおよびTLS：設計と安全性の高いシステムの構築"、アディソン・ウェズリー出版、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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
Authors' Addresses
著者のアドレス
Vijay K. Gurbani (editor) Bell Laboratories, Alcatel-Lucent
ビジェイK. Gurbani（エディタ）ベル研究所、アルカテル・ルーセント
EMail: vkg@alcatel-lucent.com
メールアドレス：vkg@alcatel-lucent.com
Rohan Mahy Unaffiliated
ロハンマーイ無所属
EMail: rohan@ekabal.com
メールアドレス：rohan@ekabal.com
Brett Tate BroadSoft
ブレット・テイトBroadSoftに
EMail: brett@broadsoft.com
メールアドレス：brett@broadsoft.com