Network Working Group J. Rosenberg
Request for Comments: 3581 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
August 2003
An Extension to the Session Initiation Protocol (SIP) for
Symmetric Response Routing
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.
セッション開始プロトコル（SIP）は、とりわけ、UDPおよびTCP上で動作します。 UDPで使用する場合、要求への応答が送信元アドレスに返される要求がから、要求の最上位Viaヘッダーフィールド値に書き込まれたポートに来ました。クライアントがネットワークアドレス変換（NAT）の背後にあるとき、この動作は、最も顕著なのは、多くの場合、望ましいことではありません。この拡張は、クライアントがサーバが要求の発信元のソースIPアドレスとポートに応答を送信することを要求することを可能にする「RPORT」と呼ばれるViaヘッダーフィールド、のための新しいパラメータを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . 8
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 8
9.3. Brittleness Introduced by this Specification . . . . . . 9
9.4. Requirements for a Long Term Solution . . . . . . . . . 10
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
12. Intellectual Property and Copyright Statements . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
The Session Initiation Protocol (SIP) [1] operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This results in a "hybrid" way of computing the destination of the response. Half of the information (specifically, the IP address) is taken from the IP packet headers, and the other half (specifically, the port) from the SIP message headers. SIP operates in this manner so that a server can listen for all messages, both requests and responses, on a single IP address and port. This helps improve scalability. However, this behavior is not desirable in many cases, most notably, when the client is behind a NAT. In that case, the response will not properly traverse the NAT, since it will not match the binding established with the request.
セッション開始プロトコル（SIP）[1]はUDPおよびTCP上で動作します。 UDPで使用する場合、要求への応答が送信元アドレスに返される要求がから、要求の最上位Viaヘッダーフィールド値に書き込まれたポートに来ました。これは、応答の宛先を計算する「ハイブリッド」ようになります。情報（具体的には、IPアドレス）の半分は、SIPメッセージヘッダからIPパケットヘッダから取られ、そして他の半分（具体的には、ポート）されています。サーバーが単一のIPアドレスとポート上のすべてのメッセージ、リクエストとレスポンスの両方のために聞くことができるようにSIPは、このように動作します。これは、スケーラビリティを向上させることができます。クライアントがNATの背後にある場合ただし、この動作は、最も顕著なのは、多くの場合、望ましいことではありません。それは結合要求と確立と一致しないので、その場合には、応答は、適切に、NATを通過しないであろう。
Furthermore, there is currently no way for a client to examine a response and determine the source port that the server saw in the corresponding request. Currently, SIP provides the client with the source IP address that the server saw in the request, but not the port. The source IP address is conveyed in the "received" parameter in the topmost Via header field value of the response. This information has proved useful for basic NAT traversal, debugging purposes, and support of multi-homed hosts. However, it is incomplete without the port information.
さらに、現在の応答を調べて、サーバーが対応する要求で見たソースポートを決定するために、クライアントのための方法はありません。現在、SIPリクエストでサーバーソー元IPアドレスをクライアントに提供ではなく、ポート。送信元IPアドレスが応答の最上位のViaヘッダフィールド値のパラメータを「受信」に搬送されます。この情報は、基本的なNATトラバーサル、デバッグ目的、およびマルチホームホストのサポートのために有用であることが判明しました。しかし、それはポート情報なしで不完全です。
This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port where the request came from. The "rport" parameter is analogous to the "received" parameter, except "rport" contains a port number, not the IP address.
この拡張は、クライアントは、サーバーがバック要求が来たソースIPアドレスとポートに応答を送信することを要求することを可能にする「RPORT」と呼ばれるViaヘッダーフィールド、のための新しいパラメータを定義します。 「RPORT」パラメータは「RPORTは、」ポート番号ではなく、IPアドレスが含まれている以外、「受信」パラメータに似ています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されているように[2]に解釈されるべきであり、対応する実装の要求レベルを示します。
The client behavior specified here affects the transport processing defined in Section 18.1 of SIP (RFC 3261) [1].
ここで指定したクライアントの動作は、SIPのセクション18.1（RFC 3261）で定義されたトランスポート処理に影響を与える[1]。
A client, compliant to this specification (clients include UACs and proxies), MAY include an "rport" parameter in the top Via header field value of requests it generates. This parameter MUST have no value; it serves as a flag to indicate to the server that this extension is supported and requested for the transaction.
この仕様に準拠したクライアントは、（クライアントが求めるUACとプロキシが含まれる）、それが生成するリクエストのヘッダフィールド値を経てトップに「RPORT」パラメータを含むかもしれません。このパラメータには価値がないしなければなりません。それは、この拡張は、トランザクションのためにサポートされ、要求されたサーバに示すためのフラグとして機能します。
When the client sends the request, if the request is sent using UDP, the client MUST be prepared to receive the response on the same IP address and port it used to populate the source IP address and source port of the request. For backwards compatibility, the client MUST still be prepared to receive a response on the port indicated in the sent-by field of the topmost Via header field value, as specified in Section 18.1.1 of SIP [1].
クライアントが要求を送信すると、要求はUDPを使用して送信された場合、クライアントは、要求の送信元IPアドレスと送信元ポートを設定するために使用したのと同じIPアドレスとポートで応答を受け取るために準備しなければなりません。下位互換性のために、クライアントはポート上の応答を受信するために用意されなければならないSIPのセクション18.1.1に指定されている[1]、送信-によって最上のViaヘッダフィールド値のフィールドに示されています。
When there is a NAT between the client and server, the request will create (or refresh) a binding in the NAT. This binding must remain in existence for the duration of the transaction in order for the client to receive the response. Most UDP NAT bindings appear to have a timeout of about one minute. This exceeds the duration of non-INVITE transactions. Therefore, responses to a non-INVITE request will be received while the binding is still in existence. INVITE transactions can take an arbitrarily long amount of time to complete. As a result, the binding may expire before a final response is received. To keep the binding fresh, the client SHOULD retransmit its INVITE every 20 seconds or so. These retransmissions will need to take place even after receiving a provisional response.
クライアントとサーバ間のNATがある場合、要求はNATにバインディングを作成（またはリフレッシュ）します。これは、バインディング、クライアントが応答を受信するためにトランザクションの間存在していなければなりません。ほとんどのUDP NATバインディングは、約1分のタイムアウトを持っているように見えます。これは、非INVITEトランザクションの継続時間を超えています。結合が存在してある間したがって、非INVITE要求への応答が受信されます。 INVITEトランザクションが完了するまでの時間の任意の長さ量を取ることができます。最終応答が受信される前に、結果として、結合が期限切れにしてもよいです。結合新鮮に保つために、クライアントは、そのは、すべて20秒程度をINVITE再送すべきです。これらの再送信も、暫定応答を受け取った後に場所を取る必要があります。
A UA MAY execute the binding lifetime discovery algorithm in Section 10.2 of RFC 3489 [4] to determine the actual binding lifetime in the NAT. If it is longer than 1 minute, the client SHOULD increase the interval for request retransmissions up to half of the discovered lifetime. If it is shorter than one minute, it SHOULD decrease the interval for request retransmissions to half of the discovered lifetime. Note that discovery of binding lifetimes can be unreliable. See Section 14.3 of RFC 3489 [4].
UAは、RFC 3489 [4] NATの実際の結合寿命を決定するために、セクション10.2に結合寿命発見アルゴリズムを実行することができます。それは1分以上であれば、クライアントは、発見された寿命の半分まで要求再送信する間隔を増やす必要があります。それが1分より短い場合は、それが発見された寿命の半分に要求再送信する間隔を減少させるはずです。結合寿命の発見は信頼できないことに注意してください。 RFC 3489のセクション14.3 [4]を参照してください。
The server behavior specified here affects the transport processing defined in Section 18.2 of SIP [1].
ここで指定したサーバの動作は、SIPのセクション18.2で定義されたトランスポート処理に影響を与える[1]。
When a server compliant to this specification (which can be a proxy or UAS) receives a request, it examines the topmost Via header field value. If this Via header field value contains an "rport" parameter with no value, it MUST set the value of the parameter to the source port of the request. This is analogous to the way in which a server will insert the "received" parameter into the topmost Via header field value. In fact, the server MUST insert a "received" parameter containing the source IP address that the request came from, even if it is identical to the value of the "sent-by" component. Note that this processing takes place independent of the transport protocol.
（プロキシまたはUASであることができる）この仕様に準拠したサーバが要求を受信すると、最上位のViaヘッダーフィールド値を調べます。このViaヘッダーフィールド値は、値のない「RPORT」パラメータが含まれている場合、それは、要求の送信元ポートにパラメータの値を設定しなければなりません。これは、サーバーがヘッダーフィールド値を介して最上位に「受信」パラメータが挿入されている方法に類似しています。実際には、サーバーは、それが「送られた - で、」コンポーネントの値と同じであっても、要求が来たソースIPアドレス含む「受信」のパラメータを挿入しなければなりません。この処理は、トランスポートプロトコルとは無関係に行われることに注意してください。
When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter. The response MUST be sent from the same address and port that the corresponding request was received on. This effectively adds a new processing step between bullets two and three in Section 18.2.2 of SIP [1].
サーバが応答を送信しようとすると、その応答の最上位のViaヘッダフィールド値を調べます。 「送信プロトコル」成分は、UDPのような信頼性のないユニキャストトランスポートプロトコルを示し、およびNO「MADDR」パラメータが存在しないが、「受信」パラメータと「RPORT」パラメータの両方が存在する場合、応答はに送信されなければなりません「RPORT」パラメータで、パラメータ、およびポートを「受信」に記載されているIPアドレス。応答は、対応する要求が受信された同じアドレスとポートから送信されなければなりません。これは、効果的にSIPのセクション18.2.2に弾丸2と3の間に新たな処理ステップを追加した[1]。
The response must be sent from the same address and port that the request was received on in order to traverse symmetric NATs. When a server is listening for requests on multiple ports or interfaces, it will need to remember the one on which the request was received. For a stateful proxy, storing this information for the duration of the transaction is not an issue. However, a stateless proxy does not store state between a request and its response, and therefore cannot remember the address and port on which a request was received. To properly implement this specification, a stateless proxy can encode the destination address and port of a request into the Via header field value that it inserts. When the response arrives, it can extract this information and use it to forward the response.
応答は、要求は、対称のNATをトラバースするために受信された同じアドレスとポートから送信されなければなりません。サーバは複数のポートまたはインターフェイス上の要求をリッスンしている場合は、要求を受信したものを覚えておく必要があります。ステートフルプロキシのために、トランザクションの期間中に、この情報を保存することは問題ではありません。しかし、ステートレスプロキシは、要求とその応答の間の状態を保存しないため、要求を受信したアドレスとポートを思い出すことができません。適切にこの仕様を実装する、ステートレスプロキシは、それが挿入Viaヘッダフィールド値にリクエストの送信先アドレスとポートをコードすることができます。応答が到着すると、それがこの情報を抽出し、応答を転送するためにそれを使用することができます。
The syntax for the "rport" parameter is:
「RPORT」パラメータの構文は次のとおりです。
response-port = "rport" [EQUAL 1*DIGIT]
応答ポート= "RPORT" [EQUAL 1 * DIGIT]
This extends the existing definition of the Via header field parameters, so that its BNF now looks like:
そのBNFは今のように見えるように、これは、Viaヘッダーフィールドパラメータの既存の定義を拡張します。
via-params = via-ttl / via-maddr / via-received / via-branch / response-port / via-extension
ビアのparams =介し-TTL /ビアMADDR /受信ビア/ビア分岐/応答ポート/ビア拡張
A client sends an INVITE to a proxy server which looks like, in part:
クライアントは、部分的に、のように見えるプロキシサーバにINVITEを送信します。
INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
INVITE SIP：user@example.com SIP / 2.0経由：SIP / 2.0 / UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
This INVITE is sent with a source port of 4540 and a source IP address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com), listening on both port 5060 and 5070. The client sends the request to port 5060. The request passes through a NAT on the way to the proxy, so that the source IP address appears as 192.0.2.1 and the source port as 9988. The proxy forwards the request, but not before appending a value to the "rport" parameter in the proxied request:
このINVITEは、4540のソースポートと10.1.1.1の送信元IPアドレスで送信されます。プロキシは、クライアントが要求がプロキシへの道上のNATを通過するポート5060に要求を送信し5060と5070の両方のポートでリッスンし、192.0.2.2（proxy.example.com）になるように送信元IPアドレスは192.0.2.1とプロキシが要求を転送9988.として、送信元ポートとして表示されますが、ないプロキシ要求で「RPORT」パラメータに値を追加する前に：
INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff
user@example.com SIP / 2.0経由：SIPのINVITE SIP / 2.0 / UDP proxy.example.com;ブランチ= z9hG4bKkjsh77経由：SIP / 2.0 / UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988。ブランチ= z9hG4bKkjshdyff
This request generates a response which arrives at the proxy:
この要求は、プロキシに到着した応答を生成します。
SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP proxy.example.com;ブランチ= z9hG4bKkjsh77経由：SIP / 2.0 / UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988;ブランチ= z9hG4bKkjshdyff
The proxy strips its top Via header field value, and then examines the next one. It contains both a "received" parameter and an "rport" parameter. The server follows the rules specified in Section 4 and sends the response to IP address 192.0.2.1, port 9988, and sends it from port 5060 on 192.0.2.2:
プロキシはヘッダーフィールド値を介してその上部を取り除き、その後、次のいずれかを調べます。これは、「受信」パラメータと「RPORT」パラメータの両方が含まれています。サーバは、第4節で指定されたルールに従うと、IPアドレス192.0.2.1、ポート9988への応答を送信し、192.0.2.2のポート5060からそれを送信します。
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988;ブランチ= z9hG4bKkjshdyff
This packet matches the binding created by the initial request. Therefore, the NAT rewrites the destination address of this packet back to 10.1.1.1, and the destination port back to 4540. It forwards this response to the client, which is listening for the response on that address and port. The client properly receives the response.
このパケットは、最初の要求によって作成されたバインディングと一致しました。そのため、NATは、それがそのアドレスとポート上の応答を待機しているクライアントにこのレスポンスを転送するバック4540に戻っ10.1.1.1に、このパケットの宛先アドレス、および宛先ポートを書き換えます。クライアントは、適切な応答を受け取ります。
When a server uses this specification, responses that it sends will now include the source port where the request came from. In some instances, the source address and port of a request are sensitive information. If they are sensitive, requests SHOULD be protected by using SIP over TLS [1]. In such a case, this specification does not provide any response routing functions (as these only work with TCP); it merely provides the client with information about the source port as seen by the server.
サーバはこの仕様を使用すると、要求がどこから来たのか、それが送信する応答は今ソースポートが含まれます。いくつかの例では、リクエストの送信元アドレスとポートは機密情報です。彼らは敏感である場合、要求はTLS [1]上にSIPを使用することによって保護されるべきです。このような場合に、本明細書は、（TCPでこれらのみ作業など）の任意の応答ルーティング機能を提供しません。それは単に、サーバによって見られるようにソースポートに関する情報をクライアントに提供します。
It is possible that an attacker might try to disrupt service to a client by acting as a man-in-the-middle, modifying the "rport" parameter in a Via header in a request sent by a client. Removal of this parameter will prevent clients from behind NATs from receiving service. The addition of the parameter will generally have no impact. Of course, if an attacker is capable of launching a man-in-the-middle attack, there are many other ways of denying service, such as merely discarding the request. Therefore, this attack does not seem significant.
攻撃者がクライアントから送信されたリクエストのViaヘッダに「RPORT」パラメータを変更、のman-in-the-middleとして作用することにより、クライアントにサービスを中断しようとする可能性があります。このパラメータの除去は、サービスを受けてから、NATの背後からクライアントを防ぐことができます。パラメータの追加は、一般的に影響はありません。攻撃者は、man-in-the-middle攻撃を開始することのできる場合はもちろん、このような単なる要求を破棄するなどのサービスを拒否する他の多くの方法が、あります。したがって、この攻撃は重大ないないようです。
There are no IANA considerations associated with this specification.
この仕様に関連付けられたIANAの考慮事項はありません。
The IAB has studied a class of protocols referred to as Unilateral Self Address Fixing (UNSAF) protocols [5]. These protocols allow a client behind a NAT to learn the IP address and port that a NAT will allocate for a particular request, in order to use this information in application layer protocols. An example of an UNSAF protocol is the Simple Traversal of UDP Through NATs (STUN) [4].
IABは片側自己アドレス固定（UNSAF）プロトコルと呼ばれるプロトコルのクラスを検討している[5]。これらのプロトコルは、NATの背後にあるクライアントは、NATは、アプリケーション層のプロトコルでこの情報を利用するためには、特定の要求のために割り当てるIPアドレスとポートを学ぶことができます。 UNSAFプロトコルの例は、のNAT（STUN）を介してUDPの単純トラバーサルである[4]。
Any protocol is an UNSAF protocol if it reveals, to a client, the source IP address and port of a packet sent through that NAT. Although not designed for that purpose, this specification can be used as an UNSAF protocol. Using the "rport" parameter (defined here) and the "received" parameter (defined in RFC 3261 [1]) in the topmost Via header field value of a response, a client sending a request can learn its address as it was seen by the server which sent the response.
それは、クライアントに、そのNATを介して送信されるパケットの送信元IPアドレスとポートを明らかにしている場合、任意のプロトコルがUNSAFプロトコルです。その目的のために設計されていないが、この仕様はUNSAFプロトコルとして使用することができます。それによって見られたように、応答の最上位のViaヘッダフィールド値に（[1] RFC 3261で定義された）（ここで定義された）「RPORT」パラメータを使用して、パラメータを「受信」、リクエストを送信するクライアントは、そのアドレスを学習することができ応答を送信し、サーバー。
There are two uses of this information. The first is for registrations. Consider a client behind a NAT wishing to register with a proxy/registrar on the other side of the NAT. The client must provide, in its registration, the address at which it should receive incoming SIP requests from the proxy. However, since the client is located behind a NAT, none of the addresses on any of its interfaces will be reachable from the proxy. If the client can provide the proxy with an address that the proxy can reach, the client can receive incoming requests. Using this specification, a client behind a NAT can learn its address and port as seen by the proxy which receives a REGISTER request. The client can then perform an additional registration, using this address in a Contact header. This would allow a client to receive incoming requests, such as INVITE, on the IP address and port it used to populate the source IP address and port of the registration it sent. This approach will only work when servers send requests to a UA from the same address and port on which the REGISTER itself was received.
この情報の2つの用途があります。最初は、登録のためです。 NATの反対側のプロキシ/レジストラに登録を希望するNATの背後にあるクライアントを考えてみましょう。クライアントは、その登録で、それはプロキシからの着信SIP要求を受信しなければならないアドレスを提供する必要があります。クライアントがNATの背後に配置されているので、そのインターフェイスのいずれかのアドレスのいずれもが、プロキシから到達できなくなります。クライアントがプロキシが到達できるアドレスでプロキシを提供することができた場合、クライアントは、着信要求を受け取ることができます。 REGISTER要求を受信したプロキシによって見られるように、この仕様を使用して、NATの背後にあるクライアントは、そのアドレスとポートを学ぶことができます。次に、クライアントはContactヘッダーにこのアドレスを使用して、追加登録を行うことができます。これにより、クライアントは、そのようなことは、それが送信され、登録の送信元IPアドレスとポートを設定するために使用されるIPアドレスとポートに、INVITEとして着信要求を受信できるようになります。サーバはREGISTER自身が受けたのと同じアドレスとポートからUAに要求を送信する場合、このアプローチは、のみ動作します。
In many cases, the server to whom the registration is sent won't be the registrar itself, but rather a proxy which then sends the request to the registrar. In such a case, any incoming requests for the client must traverse the proxy to whom the registration was directly sent. The Path header extension to SIP [3] allows the proxy to indicate that it must be on the path of such requests.
多くの場合、登録が送信され、誰に、サーバは、レジストラ自体ではなく、その後、レジストラにリクエストを送信し、プロキシではありません。そのような場合には、クライアントのための任意の着信要求は、登録が直接送信された人にプロキシを通過しなければなりません。 SIPへのパスヘッダ拡張[3]プロキシはそのような要求の経路上になければならないことを示すことを可能にします。
The second usage is for record routing, to address the same problem as above, but between two proxies. A proxy behind a NAT which forwards a request to a server can use OPTIONS, for example, to learn its address as seen by that server. This address can be placed into the Record-Route header field of requests sent to that server. This would allow the proxy to receive requests from that server on the same IP address and port it used to populate the source IP address and port of the OPTIONS request.
第2の使用は、しかし、2つのプロキシの間で、上記と同様の問題に対処するために、レコードルーティングのためのものです。サーバに要求を転送NATの背後にあるプロキシは、そのサーバによって見られるようにそのアドレスを学習するために、例えば、OPTIONSを使用することができます。このアドレスは、サーバーに送信されたリクエストのRecord-Routeヘッダフィールドに配置することができます。これは、プロキシが、それはOPTIONS要求の送信元IPアドレスとポートを設定するために使用したのと同じIPアドレスとポート上のサーバーからの要求を受信できるようになります。
Because of this potential usage, this document must consider the issues raised in [5].
このため、潜在的な使用法のために、この文書では、[5]で提起された問題を考慮する必要があります。
From [5], any UNSAF proposal must provide:
[5]から、任意のUNSAF提案を提供する必要があります。
Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't".
UNSAF提案で解決されるべき特定の、限定されたスコープの問題の正確な定義。短期的な修正は、他の問題を解決するために一般化すべきではありません。 「短期の修正は通常はない」理由です。
This specification is primarily aimed at allowing SIP responses to be received when a request is sent through a NAT. In this primary application, this specification is not an UNSAF proposal. However, as a side effect of this capability, this specification can be used as an UNSAF protocol. In that usage, it would address two issues:
この仕様は、主にリクエストがNATを介して送信されたときにSIP応答が受信できるようにすることを目指しています。この主な用途では、この仕様はUNSAF提案ではありません。しかしながら、この機能の副作用として、本明細書はUNSAFプロトコルとして使用することができます。その使用法では、二つの問題に対処します：
o Provide a client with an address that it could use in the Contact header of a REGISTER request when it is behind a NAT.
OそれはNATの背後にある場合、それはREGISTER要求のContactヘッダに使用できるアドレスをクライアントに提供します。
o Provide a proxy with an address that it could use in a Record-Route header in a request, when it is behind a NAT.
OそれはNATの背後にある場合、それは、リクエストにRecord-Routeヘッダで使用できるアドレスをプロキシを提供します。
From [5], any UNSAF proposal must provide:
[5]から、任意のUNSAF提案を提供する必要があります。
Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
出口戦略/移行計画の説明。より良い短期間フィックスは、適切な技術が展開されると自然に減って使用が表示されますものです。
The SIP working group has recognized that the usage of this specification to support registrations and record-routing through NATs is not appropriate. It has a number of known problems which are documented below. The way to eliminate potential usage of this specification for address fixing is to provide a proper solution to the problems that might motivate the usage of this specification for address fixing. Specifically, appropriate solutions for registrations and record-routing in the presence of NATs need to be developed. These solutions would not rely on address fixing.
SIPワーキンググループは、NATを介して登録及びレコードルーティングをサポートするために、本明細書の使用が適切でないことを認識しています。なお、以下に文書化されている既知の多数の問題があります。アドレス固定のために、この仕様の潜在的な使用を排除するための方法は、アドレス固定のために、この仕様の利用をやる気可能性のある問題への適切な解決策を提供することです。具体的には、NATの存在下での登録とレコードルーティングのための適切なソリューションを開発する必要があります。これらのソリューションは、アドレス固定に依存しないでしょう。
Requirements for such solutions are already under development [6].
このようなソリューションのための要件は、開発中で既にある[6]。
Implementors of this specification are encouraged to follow this work for better solutions for registrations and record-routing through NAT.
この仕様の実装者が登録し、レコードルーティングNAT通過のためのよりよい解決策のためにこの仕事に従うことを奨励されています。
From [5], any UNSAF proposal must provide:
[5]から、任意のUNSAF提案を提供する必要があります。
Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
システムより「脆い」レンダリングすることがあり、特定の問題の議論。たとえば、複数のネットワーク層でデータを使用することを含むアプローチは、デバッグの課題を高め、移行することが難しく、より多くの依存関係を作成します。
This specification, if used for address fixing, introduces several points of brittleness into a SIP system:
この仕様は、アドレス固定のために使用される場合、SIPシステムへ脆さのいくつかのポイントが導入されています。
o If used for UDP registrations, a client will need to frequently re-register in order to keep the NAT bindings fresh. In many cases, these registrations will need to take place nearly one hundred times more frequently than the typical refresh interval of a registration. This introduces load into the system and hampers scalability.
UDPの登録に使用した場合は、O、クライアントが頻繁に新鮮なNATバインディングを維持するために、再登録する必要があります。多くの場合、これらの登録は、ほぼ百倍より頻繁に登録の典型的なリフレッシュ間隔よりも場所を取る必要があります。これは、システムへの負荷を導入し、拡張性を妨げ。
o A client cannot accurately determine the binding lifetime of a NAT it is registering (or record-routing) through. Therefore, there may be periods of unreachability that occur between the time a binding expires and the next registration or OPTIONS refresh is sent. This may result in missed calls, messages, or other information.
Oクライアントを正確介して、それが登録されているNAT（またはレコード・ルーティング）の結合寿命を決定することができません。したがって、結合が満了すると、次の登録またはOPTIONSリフレッシュが送信される時間の間に発生する不到達の期間があってもよいです。これは、不在着信、メッセージ、または他の情報をもたらすことができます。
o If the NAT is of the symmetric variety [4], a client will only be able to use its address to receive requests from the server it has sent the request to. If that server is one of many servers in a cluster, the client may not be able to receive requests from other servers in the cluster. This may result in missed calls, messages, or other information.
NATが対称多様である場合O [4]、クライアントは、それがにリクエストを送信したサーバからの要求を受信するためにそのアドレスを使用することができます。そのサーバーは、クラスタ内の多くのサーバーのいずれかである場合、クライアントは、クラスタ内の他のサーバーからの要求を受信することはできないかもしれません。これは、不在着信、メッセージ、または他の情報をもたらすことができます。
o If the NAT is of the symmetric variety [4], a client will only be able to use its address to receive requests if the server sends requests to the client from the same address and port the server received the registrations on. This server behavior is not mandated by RFC 3261 [1], although it appears to be common in practice.
NATが対称多様である場合O [4]、クライアントは、サーバがサーバが上の登録を受けた同じアドレスとポートからクライアントにリクエストを送信した場合の要求を受信するためにそのアドレスを使用することができます。実際には一般的なように見えますが、このサーバーの動作は、[1] RFC 3261で定められていません。
o If the registrar and the server to whom the client sent its REGISTER request are not the same, the approach will only work if the server uses the Path header field [3]. There is not an easy and reliable way for the server to determine that the Path header should be used for a registration. Using Path when the address in the topmost Via header field is a private address will usually work, but may result in usage of Path when it is not actually needed.
クライアントがREGISTERリクエストを送信し、誰にレジストラとサーバが同じでない場合は、サーバーがPathヘッダーフィールドを使用している場合は、O、アプローチのみ動作します[3]。サーバがPathヘッダは、登録のために使用されるべきであることを決定するための簡単かつ信頼性の高い方法はありません。最上位のViaヘッダーフィールドのアドレスがプライベートアドレスの場合にパスを使用すると、通常動作しますが、それが実際に必要されていない場合にパスの使用をもたらすことができます。
From [5], any UNSAF proposal must provide:
[5]から、任意のUNSAF提案を提供する必要があります。
Identify requirements for longer term, sound technical solutions -- contribute to the process of finding the right longer term solution.
技術的な解決策を鳴らし、長期の要件を特定する - 右の長期的な解決策を見つけるプロセスに貢献します。
The brittleness described in Section 9.3 has led us to the following requirements for a long term solution:
セクション9.3で説明した脆性は、長期的な解決のために、次の要件に私たちをリードしてきました：
The client should not need to specify its address. Registrations and record routing require the client to specify the address at which it should receive requests. A sound technical solution should allow a client to explicitly specify that it wants to receive incoming requests on the connection over which the outgoing request was sent. In this way, the client does not need to specify its address.
クライアントは、そのアドレスを指定する必要はありません。登録とレコードルーティングは、それが要求を受信しなければならないアドレスを指定するには、クライアントが必要です。音の技術的な解決策は、クライアントが明示的に発信要求を送信した上で、接続の着信要求を受信したいことを指定できるようにする必要があります。このように、クライアントがそのアドレスを指定する必要はありません。
The solution must deal with clusters of servers. In many commercially deployed SIP systems, there will be multiple servers, each at different addresses and ports, handling incoming requests for a client. The solution must explicitly consider this case.
ソリューションは、サーバーのクラスタに対処しなければなりません。多くの商業展開SIPシステムでは、クライアントの着信要求を処理し、複数のサーバ、別のアドレスとポートのそれぞれがあるでしょう。解決策は、明示的にこのケースを考慮する必要があります。
The solution must not require increases in network load. There cannot be a penalty for a sound technical solution.
ソリューションは、ネットワークの負荷の増加を要求してはなりません。サウンド技術的な解決策のためのペナルティが存在することはできません。
From [5], any UNSAF proposal must provide:
[5]から、任意のUNSAF提案を提供する必要があります。
Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
既存と述べた実用的な問題の影響の議論は、NA [P] Tsと体験レポートを展開しました。
To our knowledge, at the time of writing, there is only very limited usage of this specification for address fixing. Therefore, no specific practical issues have been raised.
私たちの知る限りでは、執筆時点では、アドレス固定のためのこの仕様のごく限られた使用方法があります。したがって、具体的な実用的な問題が提起されていません。
The authors would like to thank Rohan Mahy and Allison Mankin for their comments and contributions to this work.
作者は彼らのコメントとこの仕事への貢献のためローハンマーイとアリソンマンキンに感謝したいと思います。
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3]ウィリス、D.およびB. Hoeneisenを、 "セッション開始プロトコル（SIP）拡張ヘッダフィールドは非隣接コンタクトを登録するための"、RFC 3327、2002年12月。
[4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[4]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.とR.マーイ、 "STUN - ネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサル翻訳者（NATのを）アドレス"、RFC 3489、2003年3月。
[5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[5] Daigle氏、L.、エド。、およびIAB、RFC 3424 "一方的な自己アドレス固定ネットワークアドレス変換アクロス（UNSAF）のためのIABの考慮事項"、2002年11月。
[6] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress.
[6]マーイ、R.、 "セッション開始プロトコル（SIP）における接続の再利用のための要件"、ProgressのWork。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグdynamicsoft 600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@dynamicsoft.com URI：http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
電子メール：schulzrinne@cs.columbia.edu URI：http://www.cs.columbia.edu/~hgs
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。