RFC3263 日本語訳
3263 Session Initiation Protocol (SIP): Locating SIP Servers. J.Rosenberg, H. Schulzrinne. June 2002. (Format: TXT=42310 bytes) (Obsoletes RFC2543) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 3263 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3263dynamicsoft Obsoletes: 2543時間Schulzrinneカテゴリ: 標準化過程コロンビアU.2002年6月
Session Initiation Protocol (SIP): Locating SIP Servers
セッション開始プロトコル(一口): 一口サーバの場所を見つけます。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
Session Initiationプロトコル(SIP)は、クライアントが連絡する次のホップのIPアドレス、ポート、およびトランスポート・プロトコルにSIP Uniform Resource Identifier(URI)に変えるのを許容するのにDNS手順を用います。 また、プライマリクライアントが失敗したなら、それは、サーバがバックアップクライアントに応答を送るのを許容するのに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
1つの序論… 2 2問題DNSがSolveに必要です… 2 3用語… 5 4クライアント用法… 5 輸送を選択する4.1が議定書を作ります… 6 4.2 ポートとIPアドレスを決定します… 8 RFC2782の4.3の細部が処理されます… 9 状態がないプロキシのための4.4の考慮… 10 5 サーバ用法… 11 6 一口URIを構成します… 12 7 セキュリティ問題… 12 8 輸送決断アプリケーション… 13 9 IANA問題… 14 10の承認… 14 11の引用規格… 15 12の有益な参照箇所… 15
Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[1ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
13 Authors' Addresses .................................. 16 14 Full Copyright Statement ............................ 17
13人の作者のアドレス… 16 14の完全な著作権宣言文… 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.
Session Initiationプロトコル、(SIP) (RFC3261[1])はユーザの間のコミュニケーションセッションの開始と管理に使用されるクライアントサーバプロトコルです。 SIPエンドシステムはユーザエージェントと呼ばれます、そして、中間的要素はプロキシサーバとして知られています。 SIP「台形」と呼ばれた典型的なSIP構成は図1に示されます。 このダイヤグラムで、ドメインA(UA1)の訪問者は、ドメインBのジョーを( joe@B )と呼びたがっています。 そうするために、それはドメイン(ドメインA)でプロキシ1とコミュニケートします。 プロキシ1は被呼者(ドメインB)のドメインへのプロキシに要求を転送します。(プロキシはプロキシ2です)。 プロキシ2は被呼者、UA2に呼び出しを送ります。
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は、ToがこれをするドメインB.にSIPサーバを決定する必要があって、プロキシ1はDNS手順を利用します、SRV[2]とNAPTR[3]記録の両方を使用して。 このドキュメントは、助けへのSIP用途DNSが解決する特定の問題について説明して、解決法を提供します。
2 Problems DNS is Needed to Solve
2問題DNSがSolveに必要です。
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が、Introductionで説明された一般通話流動の2つの局面を解決するのを助けるのが必要です。 1番目はプロキシ1がドメインBでSIPサーバを発見することです、 joe@B のために呼び出しを進めるために。 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.
ドメインB.のサーバのための最初の局面、1が明確にIPアドレスを決定する必要があるプロキシ、ポート、およびトランスポート・プロトコルにおいて、トランスポート・プロトコルの選択は特に注目に値します。 他の多くのプロトコルと異なって、TCP、UDP、およびSCTPを含んでいて、SIPはさまざまなトランスポート・プロトコルをひくことができます。 また、SIPはTLSを使用できます。 現在、TLSの使用はTCPだけのために定義されます。 したがって、クライアントは、どのトランスポート・プロトコルが利用可能であるかを自動的に決定できる必要があります。 要求を送るプロキシはそれがサポートするトランスポート・プロトコルの特定のセットとそれらのトランスポート・プロトコルを使用するための優先を持っています。 プロキシ2には、それ自身のそれがサポートするトランスポート・プロトコルのセット、およびそれらのトランスポート・プロトコルのための相対的選好があります。 すべてのプロキシがUDPとTCPの両方を実装しなければなりません、TCPの上のTLSと共に、能力の交差点がいつもあるように。 プロキシ1がドメインBでのSIPサービス、およびそれらのトランスポート・プロトコルの相対的選好に関して利用可能なトランスポート・プロトコルを発見するのに何らかのフォームのDNS手順が必要です。 1プロキシは交差しています。代理人を通して、2を好みましたプロキシ2とその時のものがあるサポートしているトランスポート・プロトコルのリストが、プロトコルを選ぶ。
Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[2ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |------------- | Proxy | .
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | プロキシ|------------- | プロキシ| . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | Ua1| . . | Ua2| . . | | . . | | . . +-------+ . . +-------+ . . ドメインAドメイン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ルックアップを使用できることに注意するのは重要です。 一般に、要求(クライアントと呼ばれる)を送りたがっている要素は、IPアドレス(ポート、および次のホップ要素のトランスポート・プロトコル)がサーバを呼んだことを(それは、プロキシかユーザエージェントであるかもしれません)決定するためにDNS処理を実行する必要があるかもしれません。 そのような処理は原則として要素の間のあらゆるホップに起こることができました。
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
スケーラビリティと高い有用性はSIPで重要です。 SIPサービスはクラスタリングのテクニックで拡大します。 通常、等質的に構成されたプロキシのクラスタが図1、プロキシ2のネットワークの現実的なバージョンに、あるでしょう。 DNSは、能力を提供する必要があります。
Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[3ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
ドメインBが粗雑なレベルの容量ベースのロードバランシングを提供するために優先順位づけと重りに伴う1セットのサーバを構成するように。
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は高い有用性を保証します。 例えば、プロキシ2が2つのプロキシ、プロキシ2.1、およびプロキシ2.2のクラスタとして実装されると仮定してください。 プロキシ1がプロキシ2.1に要求を送って、要求が失敗するなら、それは、プロキシ2.2にそれを送ることによって、要求を再試行します。 多くの場合、プロキシ1は、それが結局どのドメインで交信するかを知らないでしょう。 ユーザが実際にそのドメインで別のユーザに電話をかけると、その情報は知られているでしょう。 1が決してコミュニケートしないかもしれない再び呼び出しの後のドメインが完成するプロキシ。 プロキシ1は数分以内に異なったドメインの数千とコミュニケートするかもしれません、そして、プロキシ2は数分以内に何千もの異なったドメインから要求を受け取ることができました。 この「多くへの多く」関係、および1組のドメインのコミュニケーションのことによると長い間隔のために、一般に、要素がそれがコミュニケートするプロキシのためにダイナミックな有用性状態を維持するのは、可能ではありません。 プロキシが特定のドメインがある準備ラッパを得るとき、それは何らかのオーダーにおけるそのドメインで利用可能なものを見つけるまでサーバを試みるでしょう。 利用可能なサーバのアイデンティティは、その後の呼び出しの呼び出しセットアップ遅れを減少させるためにいつかの時間、理想的にキャッシュされるでしょう。 クライアントは、これが比例しないのでそれがいつ再び利用可能になるかを決定するために絶え間なく失敗したサーバについて質問できません。 その上、結局、彼らがオンラインで戻るとき、回復している要素に負荷を再配付するために有用性状態を洗い流さなければなりません。
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がUA2に要求を転送した後にプロキシ1は失敗します。 UA2はプロキシ2への応答を送ります。(それはプロキシ1にそれを送ろうとして、それはもう利用可能ではありません)。 プロキシ2がそれが応答を送ることができるプロキシ1のためのバックアップを特定するDNSが必要であり、ある序論における流れの第2の面。 SIPでは、他の取引のプロトコルではこの問題はそれより現実的です。 理由はいくつかのSIP応答が生成されるには長い時かかるかもしれないということです、人間のユーザが、頻繁にその応答を生成するために相談される必要があるので。 そういうものとして、何十秒も発呼要求とその承認の間で経過するのは、珍しくはありません。
Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[4ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[4]について説明して、対応する一口実装のために要件レベルを示すとき解釈されることであるべきですか?
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の使用法はクライアントとサーバのために異なります。 このセクションはクライアント用法を論じます。 私たちは、クライアントがstatefulであると(UserエージェントClient(UAC)かstatefulプロキシのどちらか)思います。 セクション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かSIPS(安全なSIP)URIによって特定されたリソースに要求を送る必要があるとき、ここの手順は呼び出されます。 このURIが要求が狙う必要なリソースを特定できますか(その場合、URIはRequest-URIで見つけられます)、またはそれはそのリソースに向かって中間的ホップを特定できます(その場合、URIはRouteヘッダーで見つけられます)。 ここで定義された手順はこのURIに決して影響しないで(すなわち、URIはDNSルックアップの結果で書き直されません)、彼らは要求を送ることができるIPアドレス、ポート、およびトランスポート・プロトコルをもたらすだけです。 RFC3261[1]はどのURIが、要求が送られる必要があるホストを決定するためにDNSで決議される必要であるかを決定することに関するガイドラインを提供します。 また、[1]に記録されたいくつかの場合では、SIP URIによってむしろ特定されなかった特定の中間的プロキシに要求を送ることができます、ホスト名か数値IPアドレスで。 その場合、この仕様の目的に使用される一時的なURIは構成されます。 そのURIはフォーム一口のものです: <プロキシ>。(そこでは、<プロキシ>は次のホッププロキシのFQDNか数値IPアドレスです)。 その結果、詰まるところ、すべての場合では、問題は送られる要求がことであるIPアドレスを決定するSIPかSIPS URIのDNSでの解決、ポート、およびホストの輸送になります。
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の「再-トランスミッション」が要求するすべてとACKになる後、INVITE MUSTへの非2xx SIP応答には、同じホストに送ってください。 その上、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).
INVITEへの2xx応答を求めるACK要求が異なったトランザクションを構成するので、それがオリジナルの要求を受け取ったのと同じサーバに提供されるという要件が全くありません(本当に、そのサーバが記録的なルートでなくしたなら、それはACKを手に入れないでしょう)。
Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[5ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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のmaddrパラメタの値とTARGETを定義します、存在しているなら、そうではありません、URIのhostportの部品のホスト値。 それは、連絡されるためにドメインを特定します。 [1]でこれらのパラメタのSIPの記述、SIPS URI、および定義を見つけることができます。
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でTARGETの適当なインスタンスのトランスポート・プロトコル、ポート、およびIPアドレスを決定します。
4.1 Selecting a Transport Protocol
4.1 トランスポート・プロトコルを選択すること。
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が、輸送が輸送パラメタで議定書を作って、トランスポート・プロトコルSHOULDが使用されると指定するなら。
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.
さもなければ、トランスポート・プロトコルが全く指定されませんが、TARGETが数値IPアドレスであるなら、クライアントSHOULDはSIP URIにUDPを使用して、SIPS URIにTCPを使用します。 同様に、トランスポート・プロトコルを全く指定しないで、TARGETが数値ではありませんが、明白なポートを提供するなら、クライアントSHOULDはSIP URIにUDPを使用して、SIPS URIにTCPを使用します。 これがUDPがRFC2543[6]で唯一の義務的な輸送であるからであるその結果、唯一無二は、SIP URIに共同利用できるのを保証しました。 また、それは輸送がないのがSIP URIに存在していたRFC2543年にデフォルト輸送として指定されました。 しかしながら、SIPのガイドラインがこの特定の要求のためにそれを強制するなら、TCPなどの別の輸送は使用されるかもしれません。 例えば、それは経路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アドレスでないなら、クライアントSHOULDはURIにおけるドメインのためのNAPTR質問を実行します。 トランスポート・プロトコル選択に関するタスクにおいて、関連しているサービスはXがドメインによってサポートされたトランスポート・プロトコルに一致している手紙である値の「一口+D2X」と「一口+D2X」でのNAPTRサービス分野があるそれらです。 この仕様はUDPのためのD2U、TCPのためのD2T、およびSCTPのためのD2Sを定義します。 また、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記録はドメインからSRV記録まで特定のトランスポート・プロトコルがNAPTRサービス分野にある状態でサーバに連絡するのにマッピングを提供します。 リソース記録は空の正規表現と再取得価額を含むでしょう。(それは、その特定のトランスポート・プロトコルのためのSRV記録です)。 サーバが、複数の輸送がプロトコルであるとサポートすると、それぞれ異なったサービス値がある複数のNAPTR記録があるでしょう。 RFC2915[3]に従って、クライアントはサービス分野が適切でないどんな記録も捨てます。 この仕様の目的のために、いくつかの規則が定義されます。
Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[6ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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を決議するクライアントはプロトコルとしてサービス分野に「一口」を保管していないどんなサービスも捨てなければなりません。 しかしながら、逆は本当ではありません。SHOULDが保有するSIP URIを決議するクライアントはプロトコルとして「一口」で記録します、クライアントがTLSをサポートするなら。 2番目に、クライアントは値が"D2X"でない解決サービスを特定するどんなサービス分野も捨てなければなりません、クライアントによってサポートされたトランスポート・プロトコルを示すXの値のために。 RFC2915で説明される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:
例と、一口を決議したがっているクライアントを考えてください: 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.
; オーダーprefがサービスregexp交換IN NAPTR50 50「s」「一口+D2T」に旗を揚げさせる、「「_一口_tcp.example.com。」 NAPTR90 50「s」「一口+D2T」、「「_一口_NAPTR100 50「s」「一口+D2U」のtcp.example.com、「「_一口_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をサポートするので、TCPは使用されるでしょう、_一口_tcp.example.comのSRVルックアップで断固としたホストに狙って。 そのルックアップは戻るでしょう:
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.example.com
IN SRV 0 2 5060 server2.example.com
;; 優先権Weight Port Target IN SRV0 1 5060server1.example.com IN SRV0 2 5060server2.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つの記録があるに違いありません--「一口+D2T」サービス分野があるもの、「一口+D2U」サービス分野があるもの、および「一口+D2T」をもっている人は分野を修理します。 サービスにおけるプロトコルとしてのSIPSがある記録は中にプロトコルとしてのSIPがある都合のよい(すなわち、オーダー分野の下側の値を持っている)上記の記録がサービス分野であったならSHOULDをさばきます。 「一口+D2U」サービス分野がある記録をDNSに置くべきではありません、UDPの上でTLSを使用するのが可能でないので。
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)のドメインに合うのは必要ではありません。 しかしながら、RFC2543との遅れている互換性のために、ドメインはオリジナルの質問のドメインのためのSRV記録を保守しなければなりません、NAPTR記録が異なったドメインにあっても。 例として、TCPのためのSRVレコードは_ですが、ちびちび飲んでください。_tcp.school.edu、また、SRV記録が_一口_tcp.example.comにあるに違いありません。
Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[7ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
RFC2543は直接ドメインのための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.
NAPTRに関しては、SIPSがある記録が分野について議定書の中で述べる、(サーバがサイト証明書を使用しているなら)、質問におけるドメイン名と交換分野のドメイン名は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と_一口において「質問は」 _がちびちび飲むサービス識別子を使用し終わっています」。」 SIPS URIのために。 質問がうまくいくなら、特定の輸送はサポートされます。 クライアントはそれが望んでいるサーバによってサポートされるどんなトランスポート・プロトコルも使用するかもしれません。
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.
これはRFC2543からの変化です。 それは、クライアントはすべての輸送のためのそれらの記録の向こう側に優先順位の値をサポートして、合併するというルックアップ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記録が全く見つけられないなら、クライアントSHOULDはSIPS URIにTCPを使用して、SIP URIにUDPを使用します。 しかしながら、SIPのガイドラインがこの特定の要求のためにそれを強制するなら、TCPなどの別のトランスポート・プロトコルは使用されるかもしれません。 例えば、それは経路MTUを超えている要求のためのそうです。
4.2 Determining Port and IP Address
4.2 ポートとIPアドレスを決定すること。
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.
TARGETが数値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
TARGETが数値IPアドレスではありませんでしたが、ポートがURIで存在しているなら、クライアントはドメイン名のAかAAAAの記録的なルックアップを実行します。 結果はIPアドレスのリストになるでしょう。URIとトランスポート・プロトコルから特定のポートへそれにそれぞれ連絡できます。
Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[8ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
以前に、決定します。 クライアントSHOULDは最初の記録を試みます。 試みがセクション4.3との失敗の定義に基づいて次のSHOULDに失敗するなら、試みられてください、そして、それがそうするなら、失敗してください、次SHOULD。試みられてください、など。
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.
これはRFC2543からの変化です。 明白でしたが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.
TARGETが数値IPアドレスでなく、またどんなポートもURIで存在していなかったなら、クライアントはセクション4.1のNAPTR処理から返された記録にSRV質問を実行します、そのような処理が実行されたなら。 SIPS URIのために「クライアントはそれが輸送が明らかに指定されたからであるその特定の輸送のためのSRV質問を実行します、」 _がちびちび飲むサービス識別子を使用して」。 それに関して「また、SIP URIのために、クライアントがTLSを使用したいと思うなら、」 _がちびちび飲むサービス識別子を使用する」という特定の輸送、さもなければ、」 _一口を使用する、」 NAPTR記録が全く見つけられなかったのでNAPTR処理をしませんでしたが、サポートしているトランスポート・プロトコルのためのSRV質問がうまくいったなら、それらのSRV記録は選択されます。 SRV記録がどう決定していたかにかかわらず、RFC2782の手順であり、題をつけられたセクションで説明されるように「用法は統治します」。このドキュメントのセクション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記録がいったん調べられると、処理は上で説明されるように明白なポートに進みます。
4.3 Details of RFC 2782 Process
RFC2782の4.3の細部が処理されます。
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.
RFC2782は1セットの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
SIP要求のために、トランザクション層がある種(一般にUDPの致命的なICMP誤りかTCPでの接続失敗への支払われるべきもの)の503誤り応答か輸送失敗を報告するなら、失敗は起こります。 また、失敗はトランザクション層の回数であるなら今までに暫定的であるか最終的などんな応答も受けたことがなくて起こります(すなわち、タイマBかタイマFがRFC3261[1]で撃たれます)。 失敗が起こるなら、クライアントSHOULDは新しい要求を作成します。(しかし、それは、前と同じです)。
Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[9ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
前であるよりViaブランチIDの異価(そして、したがって、新しいSIPトランザクションを構成する)を持っています。 指定されるとしてのRFC2782によるリストの次の要素にその要求を送ります。
4.4 Consideration for Stateless Proxies
4.4 状態がないプロキシのための考慮
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.
前項のプロセスは非常にstatefulです。 サーバが首尾よく連絡されるとき、トランザクションのための要求のすべての「再-トランスミッション」、および非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無作為化に基づく異なったサーバに発送されるクッキーセッション以内の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
要件はサーバに連絡するのを試みるとき失敗が全くなかった簡単な場合で会うのが難しくはありません。状態がないプロキシが要求を受け取るときはいつも、それは上で説明されるように適切なDNS質問を実行します。 しかしながら、RFC2782の手順は、決定論的になるように保証されません。 これは同じ優先権を含む記録が指定されたオーダーを全く持っていないからです。 自由にどんなアルゴリズムも使用して、状態がないプロキシはその場合決定論的なオーダーを記録と定義しなければなりません。 1つの提案は、より一般に、それらをアルファベット順にするか、またはASCIIコンパチブルコード化でそれらを分類することです。 ドメイン管理者がSRVの重りを記録に等しい優先権が異なっていた状態で(例えば、2つのサーバが1000年の重さを両方に割り当てるよりむしろ同等であるなら、1000と1001年の重りを使用します)して、NAPTRが記録するので同様にするのは、処理を状態がないプロキシには、より簡単にするためには、RECOMMENDEDです。 最初のサーバが首尾よく連絡されるなら、プロキシは残ることができます。
Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[10ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
状態がない。 しかしながら、最初のサーバが首尾よく連絡されないで、その後のサーバがそのように連絡されるなら、プロキシはこのトランザクションに状態がないままで残ることができません。 それが状態がないなら、失敗したものが「再-トランスミッション」の間で回復するなら、「再-トランスミッション」は非常にうまく異なったサーバに行くかもしれないでしょうに。 そういうものとして、プロキシが首尾よく最初のサーバに連絡しないで、それがSHOULDであるときはいつも、statefulプロキシとして務めてください。
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 TTLsがトランザクションの中央で期限が切れるなら、これは起こることができました、そして、エントリーは変化しました。 これは避けられません。 この誤りが重要であると考えられるなら、ネットワーク作成者は、この制限を意識していて、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.
RFC3261[1]はサーバからの応答をクライアントに送り返すための手順を定義します。 ユニキャストUDP要求において、通常、要求が来たソースIPアドレスは応答に送り返されます、Viaヘッダーに含まれたポートを使用して。 信頼できるトランスポート・プロトコルにおいて、要求が到着した接続の上に応答を送ります。 しかしながら、要求を送って、応答を受けるときクライアント要素が失敗するとき、フェイルオーバーサポートを提供するのは重要です。
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.
RFC3261[1]によると、サーバはそれが到着した接続(信頼できるトランスポート・プロトコルの場合における)、および頼り無いトランスポート・プロトコルのための応答を送るでしょう、要求のソースアドレス、およびViaヘッダーフィールドにおけるポートに。 サーバが、その位置に発信するのを試みると、ここの手順は呼び出されます、そして、その応答は失敗します(一定の条件はRFC3261で詳細です)。 「失敗」はトランスポート層から応答を送ることができる前に要求が参加した輸送接続のどんな閉鎖、または致命的な誤りに関するコミュニケーションとも定義されます。
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.
これらの場合では、サーバは発信していることの値を調べます。最上のViaヘッダーでの工事。 数値IPアドレスを含んでいるなら、サーバは、そのアドレスに応答を送るのを試みます、Viaヘッダー、およびポートから発信するのからトランスポート・プロトコルを使用して、存在しているならほかに、その輸送のためのデフォルトは議定書を作ります。 Viaヘッダーのトランスポート・プロトコルは「TLS」を示すことができます。(それは、TCPの上のTLSを示します)。 この値が存在しているとき、サーバは、応答を送るのにTCPの上でTLSを使用しなければなりません。
Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[11ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
しかしながら、発信している分野がドメイン名とポートナンバー、サーバ質問を含んだAかAAAAがその名前で記録するなら。 それはIPアドレスの結果として起こるリストの各要素への応答を送ろうとします、Via、およびトランスポート・プロトコルからViaからポートを使用して(一方、TLSの値はTCPの上のTLSについて言及します)。 クライアント処理のように、それの前のものが失敗をもたらすなら、リストにおける次のエントリーは試験済みです。
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.
「しかしながら、含まれたaドメイン名をさばきますが、発信しているのがどんなポートもさばかないなら、サーバはSRVのためにそのドメイン名で」 _がちびちび飲むサービス識別子を使用することで記録について質問する」、Via輸送が「TLS」である、」、_ちびちび飲んでください、」 そうでなければ、そして、ヘッダー(「TLS」は、SRV質問におけるトランスポート・プロトコルがTCPであることを含意する)を通した最上からの輸送。 [2]で説明されるように結果として起こるリストを分類します、そして、そこで説明された新しいリストの最上の要素に応答を送ります。 それが失敗をもたらすなら、リストの上の次のエントリーは試験済みです。
6 Constructing SIP URIs
6 一口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:
多くの場合、要素は、Contactヘッダーでの包含のためにREGISTER、またはINVITEのRecord-ルートヘッダーでSIP URIを組み立てる必要があります。 RFC3261[1]によると、これらのURIには、彼らがそれらを挿入した特定の要素に決議する特性がなければなりません。 しかしながら、例えば、それらが組み立てられるなら、まさしくIPと共に以下を扱ってください。
sip:1.2.3.4
一口: 1.2 .3、.4
then should the element fail, there is no way to route the request or response through a backup.
そして、ずっとaを通した要求か応答がバックアップをとるルートへの失敗して、ある要素はそうするべきです。
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
一口: 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を構成した特定の要素を示します。 しかしながら、失敗の場合、使用されるバックアップ要素を示す優先権分野の、より高い値がある追加記録があります。 これはRFC3261[1]が体力を要している操作を考慮している間に会われるという規制を許します。
Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[12ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
これは一口URI体系の存在によって部分的に緩和されます。(体系はいつもTLSだけの上に送られます)。 攻撃者はDNS記録の削除か変更で付け値を押し込むことができません。 最悪の場合には、彼らは、コミュニケーションが現れるのをすべての記録を削除することによって、防ぐことができます。 一般に、頻繁に安全な関係以内か名刺か安全なウェブ・ページの上、または、TLSと共に既に保証されたSIPメッセージの中で一口URI自体を交換します。 詳細のためのRFC3261[1]を見てください。 TLSより全く良いというわけではないセキュリティを許容するしたがってセキュリティが本当に必要ですが、私たちがSIP URIによって決議された要求にTLSを使用させるとURIが好ましい一口。
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記録がサービス分野にSIPSを保管しているか否かに関係なく、頻繁に同じドメインSHOULDキャッシュに連絡するクライアント。 そのような記録が、存在していましたが、後の質問で現れるのをやめるなら、それは起こり得るかもしれない攻撃のサインです。 この場合、クライアントSHOULDはある種の警戒かアラームを生成します、そして、要求を拒絶するかもしれません。
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エントリーを無視するのは、可能です。 そのような攻撃を防ぐためにすることができないほとんどがあります。 クライアントは、呼び出し完成においてプロキシサーバに単に依存していて、提供するためにセキュリティのために適切に整然としているプロトコルを実装すると信じなければなりません。 ワイヤトラフィック(DNSSECが不在のとき)をいじることによって、DNS記録を改竄できます、プロキシサーバに感染して、徴用するのは、不法侵入を必要として、かなりありそうでないダウングレードの脅威と考えられますが。
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.
このセクションは、より正式にこの仕様のNAPTR用法を定義します、ガイド[7]としてDynamic DelegationディスカバリーSystem(DDDS)フレームワークを使用して。 DDDSはNAPTRリソース記録の発展を表します。 DDDSはアプリケーションを定義します。(アプリケーションは特定の解決サービスのためのNAPTR記録を利用できます)。 このアプリケーションはTransport Determination Applicationと呼ばれます、そして、目標はURIを扱うことができる様々なサーバのための1セットのSRV記録に入って来るSIPかSIPS URIを写像することです。
Rosenberg & Schulzrinne Standards Track [Page 13] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[13ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
アプリケーションのユニークなストリング: Application Unique String(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によって維持されることになっています。 テーブルの新しいエントリーは標準化過程RFCsの公表を通して加えられるかもしれません、RFC2434[5]で説明されるように。
The registration in the RFC MUST include the following information:
RFC MUSTでの登録は以下の情報を含んでいます:
Service Field: The service field being registered. An example for
a new fictitious transport protocol called NCTP might be
"SIP+D2N".
分野を修理してください: 示されるサービス分野。 NCTPと呼ばれる新しい架空のトランスポート・プロトコルのための例は「一口+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".
プロトコル: そのサービス分野に関連している特定のトランスポート・プロトコル。 これはプロトコルのための名前と頭文字語を含まなければなりません、トランスポート・プロトコルについて説明するドキュメントの参照と共に。 例えば、「新しいコネクションレスな輸送は(NCTP)、RFC5766について議定書の中で述べます」。
Name and Contact Information: The name, address, email address and
telephone number for the person performing the registration.
名前と問い合わせ先: 登録を実行している人のための名前、アドレス、Eメールアドレス、および電話番号。
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)
サービス分野プロトコル一口+D2T TCP一口+D2T TCP一口+D2U UDP一口+D2S SCTP(RFC2960)
Rosenberg & Schulzrinne Standards Track [Page 14] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[14ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
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.
作者は彼らの役に立つコメントについてランディ・ブッシュ、レスリーDaigle、パトリクFaltstrom、ジョウ・ホーンスビー、Rohanマーイ、アリソン・マンキン、マイケルMealling、トーマスNarten、およびジョン・ピーターソンに感謝したがっています。
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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
[3] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[3] 食事とM.とR.ダニエル、「命名権威指針(NAPTR)DNSリソース記録」、RFC2915、2000年9月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", Work in Progress.
[7] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS規格」、進行中の仕事。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", Work in Progress.
[8] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「DNSデータベース」、進行中の仕事。
Rosenberg & Schulzrinne Standards Track [Page 15] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[15ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
13 Authors' Addresses
13人の作者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Rosenberg & Schulzrinne Standards Track [Page 16] RFC 3263 SIP: Locating SIP Servers June 2002
ローゼンバーグとSchulzrinne標準化過程[16ページ]RFC3263はちびちび飲みます: 2002年6月に一口サーバの場所を見つけます。
14 Full Copyright Statement
14 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg & Schulzrinne Standards Track [Page 17]
ローゼンバーグとSchulzrinne標準化過程[17ページ]
一覧
スポンサーリンク
