[要約] RFC 3581は、SIPの対称応答ルーティングのための拡張であり、SIPプロキシが対称的な応答ルーティングをサポートするための方法を提供します。目的は、SIPセッションの効率的なルーティングと信頼性の向上です。
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
対称応答ルーティングのセッション開始プロトコル（SIP）の拡張
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.
Copyright（c）The Internet Society（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で使用すると、リクエストへの応答がソースアドレスに返されます。リクエストは、リクエストのヘッダーフィールド値を介して最上部に書かれたポートに送信されます。この動作は、多くの場合、特にクライアントがネットワークアドレス翻訳者（NAT）の背後にいるときに望ましくありません。この拡張機能は、「rport」と呼ばれるviaヘッダーフィールドの新しいパラメーターを定義します。これにより、クライアントは、リクエストが発生したソースIPアドレスとポートにサーバーを送信することをクライアントに要求できます。
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で使用すると、リクエストへの応答がソースアドレスに返されます。リクエストは、リクエストのヘッダーフィールド値を介して最上部に書かれたポートに送信されます。これにより、応答の宛先を計算する「ハイブリッド」方法が生じます。情報の半分（具体的には、IPアドレス）はIPパケットヘッダーから、残りの半分（具体的にはポート）がSIPメッセージヘッダーから取得されます。SIPはこの方法で動作し、サーバーが単一のIPアドレスとポートで、リクエストと応答の両方のすべてのメッセージをリッスンできるようにします。これは、スケーラビリティを改善するのに役立ちます。ただし、多くの場合、特にクライアントが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アドレスは、応答のヘッダーフィールド値を介して最上部の「受信」パラメーターで伝えられます。この情報は、基本的な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.
この拡張機能は、「rport」と呼ばれるviaヘッダーフィールドの新しいパラメーターを定義します。これにより、クライアントはサーバーが応答をソースIPアドレスとリクエストの発生したポートに送信するように要求できます。「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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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（RFC 3261）のセクション18.1で定義されている輸送処理に影響します[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 [1]のセクション18.1.1で指定されているように、ヘッダーフィールド値を介して最上部のセントバイフィールドに示されているポートで応答を受信する準備をする必要があります。
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分であるように見えます。これは、非インバイトトランザクションの期間を超えています。したがって、拘束力がまだ存在している間、非インバイトの要求への応答が受信されます。招待トランザクションは、完了するのに任意に長い時間がかかる場合があります。その結果、最終的な応答が受信される前に、拘束力が期限切れになる場合があります。バインディングを新鮮に保つために、クライアントは20秒ごとに招待状を再送信する必要があります。これらの再送信は、暫定的な応答を受け取った後でも行う必要があります。
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]のセクション10.2で結合寿命発見アルゴリズムを実行して、NATの実際の結合寿命を決定できます。1分以上である場合、クライアントは、発見された寿命の半分までのリクエスト再送信の間隔を増やす必要があります。1分より短い場合は、リクエストの再送信の間隔が発見された寿命の半分に減少するはずです。結合寿命の発見は信頼できない可能性があることに注意してください。RFC 3489 [4]のセクション14.3を参照してください。
The server behavior specified here affects the transport processing defined in Section 18.2 of SIP [1].
ここで指定されているサーバーの動作は、SIP [1]のセクション18.2で定義されている輸送処理に影響します。
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ヘッダーフィールド値に値のない「rport」パラメーターが含まれている場合、パラメーターの値をリクエストのソースポートに設定する必要があります。これは、サーバーがヘッダーフィールド値を介して「受信」パラメーターを最上部に挿入する方法に類似しています。実際、サーバーは、「sent-by」コンポーネントの値と同一であっても、リクエストのソース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].
サーバーが応答を送信しようとすると、その応答のヘッダーフィールド値を介して最上部を調べます。「送信プロトコル」コンポーネントは、UDPなどの信頼性の低いユニキャスト輸送プロトコルを示し、「MADDR」パラメーターはありませんが、「受信」パラメーターと「rport」パラメーターの両方があります。「受信」パラメーターにリストされているIPアドレス、および「rport」パラメーターのポート。応答は、対応するリクエストが受信された同じアドレスとポートから送信する必要があります。これにより、SIP [1]のセクション18.2.2で、弾丸2と3の間に新しい処理ステップが効果的に追加されます。
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]
Response-port = "rport" [等しい1*桁]
This extends the existing definition of the Via header field parameters, so that its BNF now looks like:
これにより、VIAヘッダーフィールドパラメーターの既存の定義が拡張されるため、BNFは次のようになります。
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension
A client sends an INVITE to a proxy server which looks like, in part:
クライアントは、招待状をプロキシサーバーに送信します。
INVITE sip:user@example.com SIP/2.0
Via: 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:
この招待状は、4540のソースポートと10.1.1.1のソースIPアドレスで送信されます。プロキシは192.0.2.2（proxy.example.com）で、ポート5060と5070の両方で聴きます。クライアントはポート5060にリクエストを送信します。リクエストはプロキシに向かう途中のNATを通過して、ソース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
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
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:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=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はこのパケットの宛先アドレスを10.1.1.1に戻し、宛先ポートを4540に書き戻します。この応答をクライアントに転送します。クライアントは、そのアドレスとポートの応答を聞いています。クライアントは適切に応答を受け取ります。
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を介してSIPを使用してリクエストを保護する必要があります[1]。そのような場合、この仕様では、応答ルーティング関数を提供しません（これらは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.
攻撃者は、クライアントから送信されたリクエストでヘッダーの「rport」パラメーターを変更して、中間の男として行動することにより、クライアントへのサービスを混乱させようとする可能性があります。このパラメーターを削除すると、クライアントがNATがサービスを受信するのを防ぎます。パラメーターの追加には一般的に影響はありません。もちろん、攻撃者が中間の攻撃を開始できる場合、単にリクエストを廃棄するなど、サービスを拒否する他の多くの方法があります。したがって、この攻撃は重要ではないようです。
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プロトコルとして使用できます。「rport」パラメーター（ここで定義）と「受信」パラメーター（RFC 3261 [1]で定義されている[1]で定義）を使用して、応答のヘッダーフィールド値を介して最上部に、リクエストを送信するクライアントは、そのアドレスを学習できます。応答を送信したサーバー。
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つの用途があります。1つ目は登録用です。NATの反対側にプロキシ/レジストラに登録したいと考えているNATの背後にあるクライアントを検討してください。クライアントは、登録中に、プロキシから着信するSIPリクエストを受信する必要があるアドレスを提供する必要があります。ただし、クライアントはNATの後ろにあるため、そのインターフェイスのいずれのアドレスのいずれもプロキシから到達できません。クライアントがプロキシに到達できるアドレスをプロキシに提供できる場合、クライアントは着信リクエストを受信できます。この仕様を使用して、NATの背後にあるクライアントは、レジスタリクエストを受信するプロキシで見られるように、そのアドレスとポートを学習できます。クライアントは、連絡先ヘッダーにこのアドレスを使用して、追加の登録を実行できます。これにより、クライアントは、送信した登録のソースIPアドレスとポートを入力するために使用されるIPアドレスとポートで、招待などの着信リクエストを受信することができます。このアプローチは、サーバーがレジスタ自体が受信された同じアドレスとポートから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の背後にあるプロキシは、たとえばそのサーバーで見られるアドレスを学習するためにオプションを使用できます。このアドレスは、そのサーバーに送信されたリクエストのレコードルートヘッダーフィールドに配置できます。これにより、プロキシは、同じ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プロトコルとして使用できます。その使用において、それは2つの問題に対処します。
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の背後にあるときにレジスタリクエストの連絡先ヘッダーで使用できるアドレスを提供します。
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の後ろにあるときに、リクエストでレコードルートヘッダーで使用できるアドレスをプロキシを提供します。
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.
o UDP登録に使用される場合、NATバインディングを新鮮に保つために、クライアントは頻繁に再登録する必要があります。多くの場合、これらの登録は、登録の典型的な更新間隔のほぼ100倍の頻度で行われる必要があります。これにより、システムに負荷が導入され、スケーラビリティが妨げられます。
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の結合寿命を正確に決定することはできません。したがって、拘束力のある登録またはオプションの更新が送信されるまでの間に、到達不能の期間があります。これにより、不在着信、メッセージ、またはその他の情報が生じる場合があります。
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.
o NATが対称品種[4]の場合、クライアントはそのアドレスを使用して、リクエストを送信したサーバーからリクエストを受信することのみができます。そのサーバーがクラスター内の多くのサーバーの1つである場合、クライアントはクラスター内の他のサーバーからリクエストを受信できない場合があります。これにより、不在着信、メッセージ、またはその他の情報が生じる場合があります。
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.
o NATが対称品種[4]の場合、クライアントは、サーバーが同じアドレスからクライアントにリクエストを送信し、サーバーが登録を受け取った場合にクライアントにリクエストを送信した場合にのみアドレスを使用してリクエストを受信できます。このサーバーの動作は、RFC 3261 [1]によって義務付けられていませんが、実際には一般的であると思われます。
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.
o クライアントがレジスタリクエストを送信したレジストラとサーバーが同じではない場合、サーバーがパスヘッダーフィールドを使用する場合にのみアプローチが機能します[3]。サーバーがパスヘッダーを登録に使用する必要があることを決定する簡単で信頼できる方法はありません。ヘッダーフィールドを介して最上部のアドレスがプライベートアドレスである場合にパスを使用すると、通常は機能しますが、実際には必要ない場合にパスの使用が発生する可能性があります。
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およびExperience Reportsに関する有名な実用的な問題の影響についての議論。
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.
著者は、この仕事へのコメントと貢献について、Rohan MahyとAllison Mankinに感謝したいと思います。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3] Willis、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] Rosenberg、J.、Weinberger、J.、Huitema、C。and R. Mahy、「Stun-ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、2003年3月、RFC 3489。
[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.、ed。、およびIab、「ネットワークアドレス変換全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[6] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress.
[6] Mahy、R。、「セッション開始プロトコル（SIP）における接続再利用の要件」、進行中の作業。
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
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054 US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。