[要約] RFC 3263は、SIPサーバーの場所を特定するための仕様です。その目的は、SIPクライアントが正しいサーバーに接続できるようにすることです。
Network Working Group J. Rosenberg
Request for Comments: 3263 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
Session Initiation Protocol (SIP): Locating SIP Servers
セッション開始プロトコル（SIP）：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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.
セッション開始プロトコル（SIP）は、DNS手順を使用して、クライアントがSIPユニフォームリソース識別子（URI）をIPアドレス、ポート、および次のホップの輸送プロトコルに解決できるようにします。また、DNSを使用して、プライマリクライアントが失敗した場合、サーバーがバックアップクライアントに応答を送信できるようにします。このドキュメントでは、これらのDNS手順について詳しく説明しています。
Table of Contents
目次
1 Introduction ........................................ 2
2 Problems DNS is Needed to Solve ..................... 2
3 Terminology ......................................... 5
4 Client Usage ........................................ 5
4.1 Selecting a Transport Protocol ...................... 6
4.2 Determining Port and IP Address ..................... 8
4.3 Details of RFC 2782 Process ......................... 9
4.4 Consideration for Stateless Proxies ................. 10
5 Server Usage ........................................ 11
6 Constructing SIP URIs ............................... 12
7 Security Considerations ............................. 12
8 The Transport Determination Application ............. 13
9 IANA Considerations ................................. 14
10 Acknowledgements .................................... 14
11 Normative References ................................ 15
12 Informative References .............................. 15
13 Authors' Addresses .................................. 16
14 Full Copyright Statement ............................ 17
1 Introduction
1はじめに
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a client-server protocol used for the initiation and management of communications sessions between users. SIP end systems are called user agents, and intermediate elements are known as proxy servers. A typical SIP configuration, referred to as the SIP "trapezoid", is shown in Figure 1. In this diagram, a caller in domain A (UA1) wishes to call Joe in domain B (joe@B). To do so, it communicates with proxy 1 in its domain (domain A). Proxy 1 forwards the request to the proxy for the domain of the called party (domain B), which is proxy 2. Proxy 2 forwards the call to the called party, UA 2.
セッション開始プロトコル（SIP）（RFC 3261 [1]）は、ユーザー間の通信セッションの開始と管理に使用されるクライアントサーバープロトコルです。SIPエンドシステムはユーザーエージェントと呼ばれ、中間要素はプロキシサーバーとして知られています。SIP「台形」と呼ばれる典型的なSIP構成を図1に示します。この図では、ドメインA（UA1）の発信者がドメインB（Joe@B）でJoeを呼び出したいと考えています。そうするために、それはそのドメインのプロキシ1と通信します（ドメインA）。Proxy 1は、コールパーティーのドメイン（ドメインB）のプロキシにリクエストを転送します。これはプロキシ2です。
As part of this call flow, proxy 1 needs to determine a SIP server for domain B. To do this, proxy 1 makes use of DNS procedures, using both SRV [2] and NAPTR [3] records. This document describes the specific problems that SIP uses DNS to help solve, and provides a solution.
このコールフローの一部として、プロキシ1はドメインBのSIPサーバーを決定する必要があります。これを行うには、SRV [2]とNAPTR [3]レコードの両方を使用して、DNS手順を使用します。このドキュメントでは、SIPがDNSを使用して解決に役立つ特定の問題について説明し、ソリューションを提供します。
2 Problems DNS is Needed to Solve
2つの問題DNSが解決する必要があります
DNS is needed to help solve two aspects of the general call flow described in the Introduction. The first is for proxy 1 to discover the SIP server in domain B, in order to forward the call for joe@B. The second is for proxy 2 to identify a backup for proxy 1 in the event it fails after forwarding the request.
DNSは、はじめに説明されている一般的なコールフローの2つの側面を解決するために必要です。1つ目は、joe@bの呼び出しを転送するために、プロキシ1がドメインBでSIPサーバーを発見することです。2つ目は、プロキシ2がリクエストを転送した後に失敗した場合にプロキシ1のバックアップを特定することです。
For the first aspect, proxy 1 specifically needs to determine the IP address, port, and transport protocol for the server in domain B. The choice of transport protocol is particularly noteworthy. Unlike many other protocols, SIP can run over a variety of transport protocols, including TCP, UDP, and SCTP. SIP can also use TLS. Currently, use of TLS is defined for TCP only. Thus, clients need to be able to automatically determine which transport protocols are available. The proxy sending the request has a particular set of transport protocols it supports and a preference for using those transport protocols. Proxy 2 has its own set of transport protocols it supports, and relative preferences for those transport protocols. All proxies must implement both UDP and TCP, along with TLS over TCP, so that there is always an intersection of capabilities. Some form of DNS procedures are needed for proxy 1 to discover the available transport protocols for SIP services at domain B, and the relative preferences of those transport protocols. Proxy 1 intersects its list of supported transport protocols with those of proxy 2 and then chooses the protocol preferred by proxy 2.
最初の側面では、プロキシ1は、ドメインBのサーバーのIPアドレス、ポート、および輸送プロトコルを特に決定する必要があります。トランスポートプロトコルの選択は特に注目に値します。他の多くのプロトコルとは異なり、SIPはTCP、UDP、SCTPなど、さまざまな輸送プロトコルを実行できます。SIPはTLSを使用することもできます。現在、TLSの使用はTCPに対してのみ定義されています。したがって、クライアントは、どの輸送プロトコルが利用可能かを自動的に決定できる必要があります。リクエストを送信するプロキシには、サポートする特定の一連のトランスポートプロトコルと、それらの輸送プロトコルを使用する方が優先されます。Proxy 2には、サポートする独自の輸送プロトコルのセットと、それらの輸送プロトコルに対する相対的な好みがあります。すべてのプロキシは、TCPを介したTLSとともにUDPとTCPの両方を実装する必要があります。そのため、機能の交差点が常にあります。プロキシ1には、ドメインBでのSIPサービスの利用可能な輸送プロトコルと、それらの輸送プロトコルの相対的な好みを発見するには、何らかの形式のDNS手順が必要です。Proxy 1は、サポートされているトランスポートプロトコルのリストとProxy 2のリストと交差し、Proxy 2で推奨されるプロトコルを選択します。
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |------------- | Proxy | .
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 1: The SIP trapezoid
図1：SIP台形
It is important to note that DNS lookups can be used multiple times throughout the processing of a call. In general, an element that wishes to send a request (called a client) may need to perform DNS processing to determine the IP address, port, and transport protocol of a next hop element, called a server (it can be a proxy or a user agent). Such processing could, in principle, occur at every hop between elements.
DNSルックアップは、コールの処理を通して複数回使用できることに注意することが重要です。一般に、リクエスト（クライアントと呼ばれる）を送信したい要素は、DNS処理を実行して、サーバーと呼ばれる次のホップ要素のIPアドレス、ポート、およびトランスポートプロトコルを決定する必要がある場合があります（プロキシまたはAにすることができます。ユーザーエージェント）。このような処理は、原則として、要素間のすべてのホップで発生する可能性があります。
Since SIP is used for the establishment of interactive communications services, the time it takes to complete a transaction between a caller and called party is important. Typically, the time from when the caller initiates a call until the time the called party is alerted should be no more than a few seconds. Given that there can be multiple hops, each of which is doing DNS lookups in addition to other potentially time-intensive operations, the amount of time available for DNS lookups at each hop is limited.
SIPはインタラクティブコミュニケーションサービスの確立に使用されるため、発信者と呼び出した当事者間の取引を完了するのにかかる時間が重要です。通常、発信者が電話を開始する時から、呼び出されたパーティーが警告されるまで、数秒以内になるはずです。複数のホップが存在する可能性があることを考えると、それぞれが他の潜在的な時間集約型操作に加えてDNSルックアップを行っています。各ホップでのDNSルックアップで利用可能な時間は限られています。
Scalability and high availability are important in SIP. SIP services scale up through clustering techniques. Typically, in a realistic version of the network in Figure 1, proxy 2 would be a cluster of homogeneously configured proxies. DNS needs to provide the ability for domain B to configure a set of servers, along with prioritization and weights, in order to provide a crude level of capacity-based load balancing.
SIPでは、スケーラビリティと高可用性が重要です。SIPサービスは、クラスタリングテクニックを通じてスケールアップします。通常、図1のネットワークの現実的なバージョンでは、プロキシ2は均一に構成されたプロキシのクラスターになります。DNSは、容量レベルの容量ベースの負荷分散を提供するために、ドメインBが優先順位付けと重みとともに、サーバーのセットを構成する機能を提供する必要があります。
SIP assures high availability by having upstream elements detect failures. For example, assume that proxy 2 is implemented as a cluster of two proxies, proxy 2.1 and proxy 2.2. If proxy 1 sends a request to proxy 2.1 and the request fails, it retries the request by sending it to proxy 2.2. In many cases, proxy 1 will not know which domains it will ultimately communicate with. That information would be known when a user actually makes a call to another user in that domain. Proxy 1 may never communicate with that domain again after the call completes. Proxy 1 may communicate with thousands of different domains within a few minutes, and proxy 2 could receive requests from thousands of different domains within a few minutes. Because of this "many-to-many" relationship, and the possibly long intervals between communications between a pair of domains, it is not generally possible for an element to maintain dynamic availability state for the proxies it will communicate with. When a proxy gets its first call with a particular domain, it will try the servers in that domain in some order until it finds one that is available. The identity of the available server would ideally be cached for some amount of time in order to reduce call setup delays of subsequent calls. The client cannot query a failed server continuously to determine when it becomes available again, since this does not scale. Furthermore, the availability state must eventually be flushed in order to redistribute load to recovered elements when they come back online.
SIPは、上流の要素に障害を検出することにより、高可用性を保証します。たとえば、Proxy 2が2つのプロキシ2.1およびProxy 2.2のクラスターとして実装されていると仮定します。Proxy 1がプロキシ2.1にリクエストを送信し、リクエストが失敗した場合、リクエストをProxy 2.2に送信して再び取得します。多くの場合、プロキシ1は、最終的にどのドメインと通信するかを知りません。その情報は、ユーザーが実際にそのドメイン内の別のユーザーに電話をかけたときに知られています。プロキシ1は、通話が完了した後、そのドメインと再び通信することはできません。プロキシ1は数分以内に数千の異なるドメインと通信する可能性があり、Proxy 2は数分以内に数千の異なるドメインからリクエストを受信できます。この「多くの」関係と、ドメインのペア間の通信間のおそらく長い間隔のため、一般的に、要素が通信するプロキシの動的可用性状態を維持することはできません。プロキシが特定のドメインで最初の呼び出しを取得すると、利用可能なものが見つかるまで、そのドメイン内のサーバーをある程度順番に試します。利用可能なサーバーのIDは、後続の呼び出しのコールセットアップの遅延を減らすために、ある程度の時間にわたってキャッシュされます。クライアントは、故障したサーバーを継続的に照会して、いつ再び利用可能になるかを決定することができません。これはスケーリングされないためです。さらに、オンラインで戻ってきたときに、回収された要素に負荷を再配布するために、可用性状態を最終的にフラッシュする必要があります。
It is possible for elements to fail in the middle of a transaction. For example, after proxy 2 forwards the request to UA 2, proxy 1 fails. UA 2 sends its response to proxy 2, which tries to forward it to proxy 1, which is no longer available. The second aspect of the flow in the introduction for which DNS is needed, is for proxy 2 to identify a backup for proxy 1 that it can send the response to. This problem is more realistic in SIP than it is in other transactional protocols. The reason is that some SIP responses can take a long time to be generated, because a human user frequently needs to be consulted in order to generate that response. As such, it is not uncommon for tens of seconds to elapse between a call request and its acceptance.
トランザクションの途中で要素が失敗する可能性があります。たとえば、プロキシ2がリクエストをUA 2に転送した後、プロキシ1は失敗します。UA 2は、プロキシ2に応答を送信します。これは、プロキシ1に転送しようとしますが、これは利用できなくなりました。DNSが必要とする導入のフローの2番目の側面は、プロキシ2が応答を送信できるプロキシ1のバックアップを特定することです。この問題は、SIPで他のトランザクションプロトコルよりも現実的です。その理由は、人間のユーザーがその応答を生成するために頻繁に相談する必要があるため、いくつかのSIP応答を生成するのに長い時間がかかる可能性があるためです。そのため、コールリクエストとその受け入れの間で数十秒秒が経過することは珍しくありません。
3 Terminology
3用語
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 RFC 2119 [4] and indicate requirement levels for compliant SIP implementations.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [4]で説明されているように解釈され、準拠したSIP実装の要件レベルを示します。
4 Client Usage
4クライアントの使用
Usage of DNS differs for clients and for servers. This section discusses client usage. We assume that the client is stateful (either a User Agent Client (UAC) or a stateful proxy). Stateless proxies are discussed in Section 4.4.
DNSの使用は、クライアントとサーバーで異なります。このセクションでは、クライアントの使用について説明します。クライアントはステートフル（ユーザーエージェントクライアント（UAC）またはステートフルプロキシ）であると仮定します。ステートレスプロキシについては、セクション4.4で説明します。
The procedures here are invoked when a client needs to send a request to a resource identified by a SIP or SIPS (secure SIP) URI. This URI can identify the desired resource to which the request is targeted (in which case, the URI is found in the Request-URI), or it can identify an intermediate hop towards that resource (in which case, the URI is found in the Route header). The procedures defined here in no way affect this URI (i.e., the URI is not rewritten with the result of the DNS lookup), they only result in an IP address, port and transport protocol where the request can be sent. RFC 3261 [1] provides guidelines on determining which URI needs to be resolved in DNS to determine the host that the request needs to be sent to. In some cases, also documented in [1], the request can be sent to a specific intermediate proxy not identified by a SIP URI, but rather, by a hostname or numeric IP address. In that case, a temporary URI, used for purposes of this specification, is constructed. That URI is of the form sip:<proxy>, where <proxy> is the FQDN or numeric IP address of the next-hop proxy. As a result, in all cases, the problem boils down to resolution of a SIP or SIPS URI in DNS to determine the IP address, port, and transport of the host to which the request is to be sent.
ここでの手順は、クライアントがSIPまたはSIP（SECURE SIP）URIによって識別されたリソースにリクエストを送信する必要がある場合に呼び出されます。このURIは、リクエストがターゲットにされている目的のリソース（この場合、URIはリクエスト-URIにあります）を識別するか、そのリソースに対する中間ホップを識別することができます（その場合、URIはルートヘッダー）。ここで定義されている手順は、このURIに決して影響しません（つまり、URIはDNSルックアップの結果で書き換えられません）、リクエストを送信できるIPアドレス、ポート、トランスポートプロトコルのみになります。RFC 3261 [1]は、リクエストを送信する必要があるホストを決定するために、DNSでどのURIを解決する必要があるかを決定するためのガイドラインを提供します。[1]に文書化されている場合も、リクエストは、SIP URIによって識別されない特定の中間プロキシに送信できますが、ホスト名または数値IPアドレスによって識別されます。その場合、この仕様の目的に使用される一時的なURIが構築されます。そのuriはsip：<proxy>、<proxy>は次のホッププロキシのfqdnまたは数値IPアドレスです。その結果、すべての場合、問題はDNSのSIPまたはSIPS URIの解像度に要約され、リクエストが送信されるホストのIPアドレス、ポート、および輸送を決定します。
The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. That is, once a SIP server has successfully been contacted (success is defined below), all retransmissions of the SIP request and the ACK for non-2xx SIP responses to INVITE MUST be sent to the same host. Furthermore, a CANCEL for a particular SIP request MUST be sent to the same SIP server that the SIP request was delivered to.
ここでの手順は、トランザクションごとに正確に1回行う必要があります。この場合、トランザクションは[1]で定義されています。つまり、SIPサーバーに正常に連絡すると（成功は以下に定義されます）、SIPリクエストのすべての再送信と、招待への非2XX SIP応答のACKは同じホストに送信する必要があります。さらに、特定のSIP要求のキャンセルは、SIPリクエストが配信されたのと同じSIPサーバーに送信する必要があります。
Because the ACK request for 2xx responses to INVITE constitutes a different transaction, there is no requirement that it be delivered to the same server that received the original request (indeed, if that server did not record-route, it will not get the ACK).
招待への2XX応答のACK要求は異なるトランザクションを構成するため、元のリクエストを受信したのと同じサーバーに配信されるという要件はありません（実際、そのサーバーが記録されていない場合、ACKは取得されません）。
We define TARGET as the value of the maddr parameter of the URI, if present, otherwise, the host value of the hostport component of the URI. It identifies the domain to be contacted. A description of the SIP and SIPS URIs and a definition of these parameters can be found in [1].
ターゲットを、存在する場合は、URIのHostportコンポーネントのホスト値をURIのMADDRパラメーターの値として定義します。接触するドメインを識別します。SIPおよびSIPのURIの説明とこれらのパラメーターの定義は、[1]にあります。
We determine the transport protocol, port and IP address of a suitable instance of TARGET in Sections 4.1 and 4.2.
セクション4.1および4.2のターゲットの適切なインスタンスの輸送プロトコル、ポート、およびIPアドレスを決定します。
First, the client selects a transport protocol.
最初に、クライアントはトランスポートプロトコルを選択します。
If the URI specifies a transport protocol in the transport parameter, that transport protocol SHOULD be used.
URIがトランスポートパラメーターの輸送プロトコルを指定する場合、その輸送プロトコルを使用する必要があります。
Otherwise, if no transport protocol is specified, but the TARGET is a numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. Similarly, if no transport protocol is specified, and the TARGET is not numeric, but an explicit port is provided, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is because UDP is the only mandatory transport in RFC 2543 [6], and thus the only one guaranteed to be interoperable for a SIP URI. It was also specified as the default transport in RFC 2543 when no transport was present in the SIP URI. However, another transport, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU.
それ以外の場合、輸送プロトコルが指定されていないが、ターゲットが数値IPアドレスである場合、クライアントはSIP URIにUDPを使用し、SIPS URIにはTCPを使用する必要があります。同様に、輸送プロトコルが指定されておらず、ターゲットが数値ではないが、明示的なポートが提供されている場合、クライアントはSIP URIにUDPを使用し、SIPS URIにはTCPを使用する必要があります。これは、UDPがRFC 2543 [6]で唯一の必須輸送であり、したがって、SIP URIに相互運用可能であることが保証されている唯一の1つであるためです。また、SIP URIに輸送が存在しなかった場合、RFC 2543のデフォルトの輸送として指定されました。ただし、SIPのガイドラインがこの特定のリクエストに対してそれを義務付けている場合、TCPなどの別のトランスポートを使用できます。たとえば、Path MTUを超えるリクエストについてはそうです。
Otherwise, if no transport protocol or port is specified, and the target is not a numeric IP address, the client SHOULD perform a NAPTR query for the domain in the URI. The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "SIP+D2X" and "SIPS+D2X", where X is a letter that corresponds to a transport protocol supported by the domain. This specification defines D2U for UDP, D2T for TCP, and D2S for SCTP. We also establish an IANA registry for NAPTR service name to transport protocol mappings.
それ以外の場合、トランスポートプロトコルまたはポートが指定されておらず、ターゲットが数値IPアドレスではない場合、クライアントはURIのドメインのNAPTRクエリを実行する必要があります。輸送プロトコル選択のタスクに関連するサービスは、値「SIP D2X」と「SIPS D2X」を持つNAPTRサービスフィールドを持つものです。ここで、Xはドメインでサポートされている輸送プロトコルに対応する文字です。この仕様では、UDPのD2U、TCPのD2T、およびSCTPのD2Uを定義します。また、NAPTRサービス名のIANAレジストリを確立して、プロトコルマッピングを輸送します。
These NAPTR records provide a mapping from a domain to the SRV record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per RFC 2915 [3], the client discards any records whose services fields are not applicable. For the purposes of this specification, several rules are defined.
これらのNAPTRレコードは、NAPTRサービスフィールドの特定のトランスポートプロトコルとサーバーに連絡するために、ドメインからSRVレコードへのマッピングを提供します。リソースレコードには、空の正規表現と交換値が含まれます。これは、その特定の輸送プロトコルのSRVレコードです。サーバーが複数のトランスポートプロトコルをサポートしている場合、それぞれが異なるサービス値を持つ複数のNAPTRレコードがあります。RFC 2915 [3]によると、クライアントはサービスフィールドが適用されないレコードを破棄します。この仕様の目的のために、いくつかのルールが定義されています。
First, a client resolving a SIPS URI MUST discard any services that do not contain "SIPS" as the protocol in the service field. The converse is not true, however. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS. Second, a client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 2915 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. It will also allow the client to discover if TLS is available and its preference for its usage.
まず、SIPS URIを解決するクライアントは、「SIPS」をサービスフィールドのプロトコルとして含まないサービスを破棄する必要があります。ただし、逆は真実ではありません。SIP URIを解決するクライアントは、クライアントがTLSをサポートしている場合、「SIP」をプロトコルとして「SIP」で保持する必要があります。第二に、クライアントは、クライアントがサポートする輸送プロトコルを示すXの値に対して、値が「D2x」ではない解像度サービスを識別するサービスフィールドを廃棄する必要があります。RFC 2915で説明されているNAPTR処理により、クライアントがサポートされているサーバーの最も優先されるトランスポートプロトコルと、サーバーのSRVレコードが発見されます。また、TLSが利用可能かどうか、およびその使用に対する好みをクライアントが発見することができます。
As an example, consider a client that wishes to resolve sip:user@example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
例として、sip：user@example.comを解決したいクライアントを検討してください。クライアントは、そのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.
;NAPTR 50 "S" "SIPS D2T" "" _SIPS._TCP.EXAMPLE.COMでのPREFフラグサービスRegexp交換の交換。in naptr 90 50 "s" "sip d2t" "" _sip._tcp.example.com in naptr 100 50 "s" "sip d2u" "" _sip._udp.example.com。
This indicates that the server supports TLS over TCP, TCP, and UDP, in that order of preference. Since the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of _sip._tcp.example.com. That lookup would return:
これは、その選好の順にサーバーがTCP、TCP、およびUDPを介してTLSをサポートしていることを示しています。クライアントはTCPとUDPをサポートしているため、_sip._tcp.example.comのSRV検索によって決定されるホストをターゲットにするTCPが使用されます。その検索は戻ります：
;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com
;;SRV 0 1 5060 Server1.example.comの優先ウェイトポートターゲット0 2 5060 SERVER2.EXAMPLE.COM
If a SIP proxy, redirect server, or registrar is to be contacted through the lookup of NAPTR records, there MUST be at least three records - one with a "SIP+D2T" service field, one with a "SIP+D2U" service field, and one with a "SIPS+D2T" service field. The records with SIPS as the protocol in the service field SHOULD be preferred (i.e., have a lower value of the order field) above records with SIP as the protocol in the service field. A record with a "SIPS+D2U" service field SHOULD NOT be placed into the DNS, since it is not possible to use TLS over UDP.
SIPプロキシ、リダイレクトサーバー、またはレジストラがNAPTRレコードの検索を介して連絡する場合、少なくとも3つのレコードが必要な場合があります。1つは「SIP D2U」サービスフィールド、1つは「SIP D2U」サービスフィールド、1つは、1つは、「SIPS D2T」サービスフィールドを備えたもの。サービスフィールドのプロトコルとしてのSIPSを含むレコードを優先する必要があります（つまり、注文フィールドの値が低い）、SIPがサービスフィールドのプロトコルとしてSIPを使用しています。UDPを介してTLSを使用することはできないため、「SIPS D2U」サービスフィールドを備えたレコードをDNSに配置する必要はありません。
It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query (i.e., example.com above). However, for backwards compatibility with RFC 2543, a domain MUST maintain SRV records for the domain of the original query, even if the NAPTR record is in a different domain. As an example, even though the SRV record for TCP is _sip._tcp.school.edu, there MUST also be an SRV record at _sip._tcp.example.com.
NAPTR置換フィールドのドメイン接尾辞が、元のクエリのドメイン（つまり、上記のExample.com）に一致するようにする必要はありません。ただし、RFC 2543との逆方向の互換性の場合、NAPTRレコードが異なるドメインにある場合でも、ドメインは元のクエリのドメインのSRVレコードを維持する必要があります。例として、TCPのSRVレコードは_sip._tcp.school.eduですが、_sip._tcp.example.comにもSRVレコードが必要です。
RFC 2543 will look up the SRV records for the domain directly. If these do not exist because the NAPTR replacement points to a different domain, the client will fail.
RFC 2543は、ドメインのSRVレコードを直接検索します。これらが存在しない場合、NAPTRの交換が異なるドメインを指しているため、クライアントは失敗します。
For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack.
SIPSプロトコルフィールドを備えたNAPTRレコードの場合（サーバーがサイト証明書を使用している場合）、クエリのドメイン名と交換フィールドのドメイン名は両方ともTLSのサーバーが配布したサイト証明書に基づいて有効でなければなりません交換。同様に、SRVクエリのドメイン名とSRVレコードのターゲットのドメイン名は、両方とも同じサイト証明書に基づいて有効でなければなりません。それ以外の場合、攻撃者はDNSレコードを変更して別のドメインに交換値を含めることができ、クライアントはこれが望ましい動作または攻撃の結果であることを検証できませんでした。
If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_sip" for SIP URIs and "_sips" for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server.
NAPTRレコードが見つからない場合、クライアントはサポートするトランスポートプロトコルのSRVクエリを構築し、それぞれに対してクエリを行います。クエリは、SIP URIのサービス識別子「_SIP」、SIP URIの「_SIP」を使用して行われます。クエリが成功した場合、特定のトランスポートがサポートされています。クライアントは、サーバーによってサポートされている任意のトランスポートプロトコルを使用する場合があります。
This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record.
これはRFC 2543からの変更です。クライアントがサポートするすべてのトランスポートのSRVレコードを検索し、それらのレコード全体で優先度の値をマージすることを指定しました。次に、最も優先されるレコードを選択します。
If no SRV records are found, the client SHOULD use TCP for a SIPS URI, and UDP for a SIP URI. However, another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU.
SRVレコードが見つからない場合、クライアントはSIPS URIにTCPを使用し、SIP URIにUDPを使用する必要があります。ただし、SIPのガイドラインがこの特定のリクエストに対してそれを義務付けている場合、TCPなどの別の輸送プロトコルを使用できます。たとえば、Path MTUを超えるリクエストについてはそうです。
Once the transport protocol has been determined, the next step is to determine the IP address and port.
トランスポートプロトコルが決定されたら、次のステップはIPアドレスとポートを決定することです。
If TARGET is a numeric IP address, the client uses that address. If the URI also contains a port, it uses that port. If no port is specified, it uses the default port for the particular transport protocol.
ターゲットが数値IPアドレスの場合、クライアントはそのアドレスを使用します。URIにポートも含まれている場合、そのポートを使用します。ポートが指定されていない場合、特定の輸送プロトコルにデフォルトポートを使用します。
If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously. The client SHOULD try the first record. If an attempt should fail, based on the definition of failure in Section 4.3, the next SHOULD be tried, and if that should fail, the next SHOULD be tried, and so on.
ターゲットが数値IPアドレスではなく、URIにポートが存在する場合、クライアントはドメイン名のAまたはAAAAレコードの検索を実行します。結果は、IPアドレスのリストになり、それぞれがURIおよび以前に決定された輸送プロトコルの特定のポートで連絡することができます。クライアントは最初のレコードを試す必要があります。セクション4.3の障害の定義に基づいて試行が失敗する場合、次の障害を試してみる必要があり、それが失敗する場合は、次の障害を試してみる必要があります。
This is a change from RFC 2543. Previously, if the port was explicit, but with a value of 5060, SRV records were used. Now, A or AAAA records will be used.
これはRFC 2543からの変更です。以前は、ポートが明示的であるが5060の値がある場合、SRVレコードが使用されました。現在、AまたはAAAAレコードが使用されます。
If the TARGET was not a numeric IP address, and no port was present in the URI, the client performs an SRV query on the record returned from the NAPTR processing of Section 4.1, if such processing was performed. If it was not, because a transport was specified explicitly, the client performs an SRV query for that specific transport, using the service identifier "_sips" for SIPS URIs. For a SIP URI, if the client wishes to use TLS, it also uses the service identifier "_sips" for that specific transport, otherwise, it uses "_sip". If the NAPTR processing was not done because no NAPTR records were found, but an SRV query for a supported transport protocol was successful, those SRV records are selected. Irregardless of how the SRV records were determined, the procedures of RFC 2782, as described in the section titled "Usage rules" are followed, augmented by the additional procedures of Section 4.3 of this document.
ターゲットが数値IPアドレスではなく、URIにポートが存在しなかった場合、クライアントは、そのような処理が実行された場合、セクション4.1のNAPTR処理から返されたレコードでSRVクエリを実行します。そうでない場合、トランスポートが明示的に指定されているため、クライアントはSIPS URIのサービス識別子「_SIP」を使用して、その特定のトランスポートのSRVクエリを実行します。SIP URIの場合、クライアントがTLSを使用したい場合、その特定のトランスポートにサービス識別子「_SIP」も使用します。そうでなければ、「_SIP」を使用します。NAPTRレコードが見つからなかったためにNAPTR処理が行われなかったが、サポートされている輸送プロトコルのSRVクエリが成功した場合、これらのSRVレコードが選択されます。SRVレコードがどのように決定されたかに関係なく、「使用規則」というタイトルのセクションで説明されているRFC 2782の手順に従って、このドキュメントのセクション4.3の追加手順が補強されています。
If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport. Processing then proceeds as described above for an explicit port once the A or AAAA records have been looked up.
SRVレコードが見つからなかった場合、クライアントはドメイン名のAまたはAAAAレコードの検索を実行します。結果は、IPアドレスのリストになり、それぞれがそのトランスポートのデフォルトポートで、以前に決定されたトランスポートプロトコルを使用して連絡できます。AまたはAAAAレコードが検索されたら、上記の明示的なポートの上記のように処理が進行します。
RFC 2782 spells out the details of how a set of SRV records are sorted and then tried. However, it only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. Those details are described here for SIP.
RFC 2782は、SRVレコードのセットがどのように並べ替えられ、その後試行されるかの詳細を説明しています。ただし、クライアントは、失敗の場合に何が起こるかについて詳細を示すことなく、クライアントが「（プロトコル、アドレス、サービス）に接続しようとする」だけであると述べています。これらの詳細については、SIPについて説明します。
For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction layer times out without ever having received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782.
SIPリクエストの場合、トランザクションレイヤーが503エラー応答または何らかの輸送障害を報告した場合に障害が発生します（通常、UDPの致命的なICMPエラーまたはTCPの接続障害により）。また、暫定または最終を受け取ったことなくトランザクションレイヤーがタイムアウトする場合にも障害が発生します（つまり、RFC 3261 [1]火災のタイマーBまたはタイマーF）。障害が発生した場合、クライアントは以前と同一の新しいリクエストを作成する必要がありますが、以前とはviaブランチIDの値が異なります（したがって、新しいSIPトランザクションを構成します）。その要求は、RFC 2782で指定されているように、リストの次の要素に送信されます。
The process of the previous sections is highly stateful. When a server is contacted successfully, all retransmissions of the request for the transaction, as well as ACK for a non-2xx final response, and CANCEL requests for that transaction, MUST go to the same server.
前のセクションのプロセスは非常にステートフルです。サーバーに正常に連絡されると、トランザクションの要求のすべての再送信、および非2XX最終応答のACK、およびそのトランザクションのリクエストをキャンセルする必要があります。
The identity of the successfully contacted server is a form of transaction state. This presents a challenge for stateless proxies, which still need to meet the requirement for sending all requests in the transaction to the same server.
正常に連絡されたサーバーの身元は、トランザクション状態の形式です。これは、ステートレスプロキシの課題を提示します。これは、トランザクション内のすべてのリクエストを同じサーバーに送信するための要件を満たす必要があります。
The problem is similar, but different, to the problem of HTTP transactions within a cookie session getting routed to different servers based on DNS randomization. There, such distribution is not a problem. Farms of servers generally have common back-end data stores, where the session data is stored. Whenever a server in the farm receives an HTTP request, it takes the session identifier, if present, and extracts the needed state to process the request. A request without a session identifier creates a new one. The problem with stateless proxies is at a lower layer; it is retransmitted requests within a transaction that are being potentially spread across servers. Since none of these retransmissions carries a "session identifier" (a complete dialog identifier in SIP terms), a new dialog would be created identically at each server. This could, for example result in multiple phone calls to be made to the same phone. Therefore, it is critical to prevent such a thing from happening in the first place.
この問題は、DNSのランダム化に基づいて異なるサーバーにルーティングされるCookieセッション内のHTTPトランザクションの問題に似ていますが、異なります。そこでは、そのような分布は問題ではありません。サーバーのファームには、一般に、セッションデータが保存されている一般的なバックエンドデータストアがあります。ファーム内のサーバーがHTTP要求を受信するたびに、存在する場合はセッション識別子を取り、必要な状態を抽出してリクエストを処理します。セッション識別子のないリクエストは、新しいものを作成します。ステートレスプロキシの問題は下層層にあります。これは、サーバー全体に広がる可能性があるトランザクション内で再送信されたリクエストです。これらの再送信のいずれにも「セッション識別子」（完全なダイアログ識別子がSIPの用語で）が含まれていないため、各サーバーで新しいダイアログが同じように作成されます。これにより、たとえば、同じ電話に複数の電話がかかる可能性があります。したがって、そもそもそのようなことが起こらないようにすることが重要です。
The requirement is not difficult to meet in the simple case where there were no failures when attempting to contact a server. Whenever the stateless proxy receives the request, it performs the appropriate DNS queries as described above. However, the procedures of RFC 2782 are not guaranteed to be deterministic. This is because records that contain the same priority have no specified order. The stateless proxy MUST define a deterministic order to the records in that case, using any algorithm at its disposal. One suggestion is to alphabetize them, or, more generally, sort them by ASCII-compatible encoding. To make processing easier for stateless proxies, it is RECOMMENDED that domain administrators make the weights of SRV records with equal priority different (for example, using weights of 1000 and 1001 if two servers are equivalent, rather than assigning both a weight of 1000), and similarly for NAPTR records. If the first server is contacted successfully, the proxy can remain stateless. However, if the first server is not contacted successfully, and a subsequent server is, the proxy cannot remain stateless for this transaction. If it were stateless, a retransmission could very well go to a different server if the failed one recovers between retransmissions. As such, whenever a proxy does not successfully contact the first server, it SHOULD act as a stateful proxy.
この要件は、サーバーに連絡しようとする際に障害がなかった単純なケースで満たすことは難しくありません。ステートレスプロキシがリクエストを受信するたびに、上記のように適切なDNSクエリを実行します。ただし、RFC 2782の手順は決定論的であることは保証されていません。これは、同じ優先度を含むレコードに指定された順序がないためです。ステートレスプロキシは、その場合のレコードに対して決定論的順序を定義する必要があります。1つの提案は、それらをアルファベット化するか、より一般的には、ASCII互換のエンコードで並べ替えることです。ステートレスプロキシの処理を容易にするには、ドメイン管理者がSRVレコードの重みを同等の優先順位で異なるものにすることをお勧めします（たとえば、2つのサーバーが1000の重量を割り当てるのではなく、2つのサーバーが同等である場合、1000と1001の重みを使用して）同様にNAPTRレコードについて。最初のサーバーに正常に連絡された場合、プロキシはステートレスのままになります。ただし、最初のサーバーが正常に連絡されず、後続のサーバーがそうである場合、このトランザクションのプロキシはステートレスのままではありません。ステートレスの場合、再送信が再送信の間に回復した場合、再送信が別のサーバーに非常にうまく行く可能性があります。そのため、プロキシが最初のサーバーに正常に連絡しない場合は、ステートフルプロキシとして機能する必要があります。
Unfortunately, it is still possible for a stateless proxy to deliver retransmissions to different servers, even if it follows the recommendations above. This can happen if the DNS TTLs expire in the middle of a transaction, and the entries had changed. This is unavoidable. Network implementors should be aware of this limitation, and not use stateless proxies that access DNS if this error is deemed critical.
残念ながら、上記の推奨事項に従っていても、ステートレスプロキシが異なるサーバーに再送信を提供することは依然として可能です。これは、DNS TTLがトランザクションの途中で期限切れになり、エントリが変更された場合に発生する可能性があります。これは避けられません。ネットワークの実装者は、この制限を認識し、このエラーが重要であると見なされる場合、DNSにアクセスするステートレスプロキシを使用しないでください。
5 Server Usage
5サーバーの使用
RFC 3261 [1] defines procedures for sending responses from a server back to the client. Typically, for unicast UDP requests, the response is sent back to the source IP address where the request came from, using the port contained in the Via header. For reliable transport protocols, the response is sent over the connection the request arrived on. However, it is important to provide failover support when the client element fails between sending the request and receiving the response.
RFC 3261 [1]は、サーバーからクライアントに回答を送信する手順を定義します。通常、Unicast UDPリクエストの場合、Reponseは、Viaヘッダーに含まれるポートを使用して、リクエストが生じたソースIPアドレスに送信されます。信頼できる輸送プロトコルの場合、リクエストが届いた接続を介して応答が送信されます。ただし、クライアント要素がリクエストの送信と応答の受信の間に失敗した場合、フェールオーバーサポートを提供することが重要です。
A server, according to RFC 3261 [1], will send a response on the connection it arrived on (in the case of reliable transport protocols), and for unreliable transport protocols, to the source address of the request, and the port in the Via header field. The procedures here are invoked when a server attempts to send to that location and that response fails (the specific conditions are detailed in RFC 3261). "Fails" is defined as any closure of the transport connection the request came in on before the response can be sent, or communication of a fatal error from the transport layer.
RFC 3261 [1]によると、サーバーは、到着した接続（信頼できる輸送プロトコルの場合）、および信頼できない輸送プロトコルの場合、リクエストのソースアドレス、およびヘッダーフィールド経由。ここでの手順は、サーバーがその場所に送信しようとし、その応答が失敗したときに呼び出されます（特定の条件はRFC 3261で詳しく説明されています）。「失敗」は、応答を送信する前にリクエストが発生した輸送接続の閉鎖、または輸送層からの致命的なエラーの通信として定義されます。
In these cases, the server examines the value of the sent-by construction in the topmost Via header. If it contains a numeric IP address, the server attempts to send the response to that address, using the transport protocol from the Via header, and the port from sent-by, if present, else the default for that transport protocol. The transport protocol in the Via header can indicate "TLS", which refers to TLS over TCP. When this value is present, the server MUST use TLS over TCP to send the response.
これらの場合、サーバーはヘッダーを介して最上部のセントごとの構造の値を調べます。数値IPアドレスが含まれている場合、サーバーはそのアドレスに応答を送信しようとします。VIAヘッダーからのトランスポートプロトコルと、存在する場合はセントバイからポートを使用して、そのトランスポートプロトコルのデフォルトです。Viaヘッダーのトランスポートプロトコルは、TCPを介したTLSを指す「TLS」を示すことができます。この値が存在する場合、サーバーはTCPを介してTLSを使用して応答を送信する必要があります。
If, however, the sent-by field contained a domain name and a port number, the server queries for A or AAAA records with that name. It tries to send the response to each element on the resulting list of IP addresses, using the port from the Via, and the transport protocol from the Via (again, a value of TLS refers to TLS over TCP). As in the client processing, the next entry in the list is tried if the one before it results in a failure.
ただし、Sent-Byフィールドにドメイン名とポート番号が含まれている場合、サーバーはその名前のAまたはAAAAレコードをクエリします。VIAからのポートを使用して、IPアドレスの結果のリストの各要素に応答を送信しようとします。クライアントの処理のように、リストの次のエントリが障害になった場合に試行されます。
If, however, the sent-by field contained a domain name and no port, the server queries for SRV records at that domain name using the service identifier "_sips" if the Via transport is "TLS", "_sip" otherwise, and the transport from the topmost Via header ("TLS" implies that the transport protocol in the SRV query is TCP). The resulting list is sorted as described in [2], and the response is sent to the topmost element on the new list described there. If that results in a failure, the next entry on the list is tried.
ただし、セントバイフィールドにドメイン名とポートなしが含まれていた場合、via輸送が「tls」、「_sip」である場合、サービス識別子「_SIP」を使用してそのドメイン名でSRVレコードのサーバーがクエリをクエリし、ヘッダー経由で最上部からの輸送（「TLS」は、SRVクエリの輸送プロトコルがTCPであることを意味します）。結果のリストは[2]で説明されているようにソートされ、応答はそこで説明されている新しいリストの最上部要素に送信されます。その結果、障害が発生した場合、リストの次のエントリが試されます。
6 Constructing SIP URIs
6 SIP URIの構築
In many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have the property that they resolve to the specific element that inserted them. However, if they are constructed with just an IP address, for example:
多くの場合、要素は、レジスタのコンタクトヘッダー、または招待状のレコードルートヘッダーに含めるためにSIP URIを構築する必要があります。RFC 3261 [1]によると、これらのURIは、それらを挿入した特定の要素に解決する特性を持たなければなりません。ただし、たとえば、IPアドレスのみで構築されている場合：
sip:1.2.3.4
SIP：1.2.3.4
then should the element fail, there is no way to route the request or response through a backup.
その後、要素が失敗した場合、バックアップを介してリクエストまたは応答をルーティングする方法はありません。
SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used:
SRVはこれを修正する方法を提供します。IPアドレスを使用する代わりに、SRVレコードに解決するドメイン名を使用できます。
sip:server23.provider.com
SIP：server23.provider.com
The SRV records for a particular target can be set up so that there is a single record with a low value for the priority field (indicating the preferred choice), and this record points to the specific element that constructed the URI. However, there are additional records with higher values of the priority field that point to backup elements that would be used in the event of failure. This allows the constraint of RFC 3261 [1] to be met while allowing for robust operation.
特定のターゲットのSRVレコードをセットアップして、優先フィールドに値が低い単一のレコード（優先選択を示す）があり、このレコードはURIを構築した特定の要素を指します。ただし、障害が発生した場合に使用されるバックアップ要素を指す優先フィールドのより高い値を持つ追加のレコードがあります。これにより、RFC 3261 [1]の制約を満たすことができ、堅牢な操作を可能にします。
7 Security Considerations
7つのセキュリティ上の考慮事項
DNS NAPTR records are used to allow a client to discover that the server supports TLS. An attacker could potentially modify these records, resulting in a client using a non-secure transport when TLS is in fact available and preferred.
DNS NAPTRレコードは、クライアントがサーバーがTLSをサポートしていることを発見できるようにするために使用されます。攻撃者は、これらのレコードを潜在的に変更する可能性があり、TLSが実際に利用可能で優先される場合、クライアントが安全でないトランスポートを使用することになります。
This is partially mitigated by the presence of the sips URI scheme, which is always sent only over TLS. An attacker cannot force a bid down through deletion or modification of DNS records. In the worst case, they can prevent communication from occurring by deleting all records. A sips URI itself is generally exchanged within a secure context, frequently on a business card or secure web page, or within a SIP message which has already been secured with TLS. See RFC 3261 [1] for details. The sips URI is therefore preferred when security is truly needed, but we allow TLS to be used for requests resolved by a SIP URI to allow security that is better than no TLS at all.
これは、SIPS URIスキームの存在によって部分的に軽減されます。これは、常にTLSを介してのみ送信されます。攻撃者は、DNSレコードの削除または変更を通じて入札を強制することはできません。最悪の場合、すべてのレコードを削除することにより、通信が発生しないようにすることができます。SIPS URI自体は、通常、安全なコンテキスト内で、頻繁に名刺や安全なWebページで、または既にTLSで保護されているSIPメッセージ内で交換されます。詳細については、RFC 3261 [1]を参照してください。したがって、SIPS URIは、セキュリティが本当に必要な場合に好まれますが、TLSを使用して、TLSがまったくないよりも優れたセキュリティを可能にするために、SIP URIによって解決されたリクエストにTLSを使用することを許可します。
The bid down attack can also be mitigated through caching. A client which frequently contacts the same domain SHOULD cache whether or not its NAPTR records contain SIPS in the services field. If such records were present, but in later queries cease to appear, it is a sign of a potential attack. In this case, the client SHOULD generate some kind of alert or alarm, and MAY reject the request.
入札攻撃は、キャッシュによって軽減することもできます。同じドメインに頻繁に連絡するクライアントは、NAPTRレコードにサービスフィールドにSIPが含まれているかどうかにかかわらず、キャッシュする必要があります。そのようなレコードが存在しているが、後のクエリには現れなくなった場合、それは潜在的な攻撃の兆候です。この場合、クライアントは何らかのアラートまたはアラームを生成する必要があり、リクエストを拒否する場合があります。
An additional problem is that proxies, which are intermediaries between the users of the system, are frequently the clients that perform the NAPTR queries. It is therefore possible for a proxy to ignore SIPS entries even though they are present, resulting in downgraded security. There is very little that can be done to prevent such attacks. Clients are simply dependent on proxy servers for call completion, and must trust that they implement the protocol properly in order for security to be provided. Falsifying DNS records can be done by tampering with wire traffic (in the absence of DNSSEC), whereas compromising and commandeering a proxy server requires a break-in, and is seen as the considerably less likely downgrade threat.
追加の問題は、システムのユーザー間の仲介者であるプロキシが、頻繁にNAPTRクエリを実行するクライアントであることです。したがって、プロキシがSIPSエントリが存在していても無視し、セキュリティが格下げされる可能性があります。そのような攻撃を防ぐためにできることはほとんどありません。クライアントは、通話完了のために単にプロキシサーバーに依存しており、セキュリティを提供するためにプロトコルを適切に実装することを信頼する必要があります。DNSレコードの偽造は、（DNSSECの存在下で）ワイヤートラフィックを改ざんすることで実行できますが、プロキシサーバーを妥協して指揮するには侵入が必要であり、格下げの脅威がかなり低いと見なされます。
8 The Transport Determination Application
8輸送決定アプリケーション
This section more formally defines the NAPTR usage of this specification, using the Dynamic Delegation Discovery System (DDDS) framework as a guide [7]. DDDS represents the evolution of the NAPTR resource record. DDDS defines applications, which can make use of the NAPTR record for specific resolution services. This application is called the Transport Determination Application, and its goal is to map an incoming SIP or SIPS URI to a set of SRV records for the various servers that can handle the URI.
このセクションでは、動的委任ディスカバリーシステム（DDDS）フレームワークをガイドとして使用して、この仕様のNAPTR使用を正式に定義します[7]。DDDは、NAPTRリソースレコードの進化を表します。DDDSは、特定の解像度サービスにNAPTRレコードを利用できるアプリケーションを定義します。このアプリケーションは輸送決定アプリケーションと呼ばれ、その目標は、URIを処理できるさまざまなサーバーのSRVレコードのセットに、着信SIPまたはSIPS URIをマッピングすることです。
The following is the information that DDDS requests an application to provide:
以下は、DDDSが提供するアプリケーションを要求する情報です。
Application Unique String: The Application Unique String (AUS) is the input to the resolution service. For this application, it is the URI to resolve.
アプリケーション一意の文字列：アプリケーション一意の文字列（AUS）は、解像度サービスへの入力です。このアプリケーションでは、解決するのはURIです。
First Well Known Rule: The first well known rule extracts a key from the AUS. For this application, the first well known rule extracts the host portion of the SIP or SIPS URI.
最初によく知られているルール：最初によく知られているルールは、AUSからキーを抽出します。このアプリケーションでは、最初によく知られているルールは、SIPまたはSIPS URIのホスト部分を抽出します。
Valid Databases: The key resulting from the first well known rule is looked up in a single database, the DNS [8].
有効なデータベース：最初によく知られているルールから生じるキーは、単一のデータベースであるDNS [8]で検索されます。
Expected Output: The result of the application is an SRV record for the server to contact.
予想される出力：アプリケーションの結果は、サーバーが連絡するためのSRVレコードです。
9 IANA Considerations
9 IANAの考慮事項
The usage of NAPTR records described here requires well known values for the service fields for each transport supported by SIP. The table of mappings from service field values to transport protocols is to be maintained by IANA. New entries in the table MAY be added through the publication of standards track RFCs, as described in RFC 2434 [5].
ここで説明するNAPTRレコードの使用には、SIPがサポートする各輸送のサービスフィールドのよく知られている値が必要です。サービスフィールド値から輸送プロトコルへのマッピングの表は、IANAによって維持されます。RFC 2434 [5]に記載されているように、テーブル内の新しいエントリは、RFCを追跡する標準トラックの公開を通じて追加される場合があります。
The registration in the RFC MUST include the following information:
RFCへの登録には、次の情報を含める必要があります。
Service Field: The service field being registered. An example for a new fictitious transport protocol called NCTP might be "SIP+D2N".
サービスフィールド：登録されているサービスフィールド。NCTPと呼ばれる新しい架空の輸送プロトコルの例は、「SIP D2N」です。
Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol. For example - "New Connectionless Transport Protocol (NCTP), RFC 5766".
プロトコル：そのサービスフィールドに関連付けられた特定の輸送プロトコル。これには、プロトコルの名前と頭字語が含まれ、トランスポートプロトコルを説明するドキュメントを参照する必要があります。たとえば、「新しいConnectionless Transport Protocol（NCTP）、RFC 5766」。
Name and Contact Information: The name, address, email address and telephone number for the person performing the registration.
名前と連絡先情報：登録を実行している人の名前、住所、メールアドレス、電話番号。
The following values have been placed into the registry:
次の値がレジストリに配置されています。
Services Field Protocol
SIP+D2T TCP
SIPS+D2T TCP
SIP+D2U UDP
SIP+D2S SCTP (RFC 2960)
10 Acknowledgements
10の謝辞
The authors would like to thank Randy Bush, Leslie Daigle, Patrik Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling, Thomas Narten, and Jon Peterson for their useful comments.
著者は、ランディ・ブッシュ、レスリー・デイグル、パトリック・ファルトストローム、ジョー・ホーンズビー、ロハン・マヒー、アリソン・マンキン、マイケル・ミーリング、トーマス・ナルテン、ジョン・ピーターソンに有用なコメントに感謝したいと思います。
11 Normative References
11の規範的参照
[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] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for Specifying the Location of Services (DNS SRV)", RFC 2782, February 2000.
[2] Gulbrandsen、A.、Vixie、P。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、RFC 2782、2000年2月。
[3] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[3] Mealling、M。and R. Daniel、「The Naming Authority Pointer（NAPTR）DNSリソースレコード」、RFC 2915、2000年9月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
12 Informative References
12の有益な参照
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[6] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", Work in Progress.
[7] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS標準」、進行中の作業。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", Work in Progress.
[8] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：DNSデータベース」、進行中の作業。
13 Authors' Addresses
13著者の住所
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
14 Full Copyright Statement
14完全な著作権ステートメント
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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 assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。