Network Working Group J. Lim
Request for Comments: 5346 W. Kim
Category: Informational C. Park
NIDA
L. Conroy
RMRL
October 2008
Operational Requirements for ENUM-Based Softswitch Use
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.
この文書は、韓国の国家インターネット開発庁（NIDA）が主催ENUM事前商用試験中に得た、2韓国ボイスオーバーIP（VoIP）のキャリア間のコールルーティングに関するENUMベースのソフトスイッチの運用要件と、いくつかの考慮事項の経験を記述する2006。
These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls.
これらの経験は、暫定的な解決策は、DNSは、呼び出しの大多数のための十分なデータを持っていないENUMサービスの初期段階での継続的な商用ソフトスイッチシステム運用の安定性を維持することができることを示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Call Routing on Softswitch . . . . . . . . . . . . . . . . . . 2
3. Infrastructure ENUM Trial in Korea . . . . . . . . . . . . . . 3
4. Operational Requirements for ENUM-Based Softswitches . . . . . 4
4.1. Call Routing Cases for DNS Response Codes . . . . . . . . 4
4.1.1. Trial Policies . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Trial ENUM Lookup Rules . . . . . . . . . . . . . . . 6
4.2. Call Routing Cases for Domainparts . . . . . . . . . . . . 7
5. Trial Results . . . . . . . . . . . . . . . . . . . . . . . . 9
6. 'e164.arpa' Considerations . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035] that converts from an E.164 [E164] number to a domain name using the Naming Authority Pointer (NAPTR) [RFC3403] resource record type. ENUM is able to store different service types (such as fax, email, homepage, SIP, H.323 and so on) for every E.164 number. It originally focused on how end-users could gain access to other end-users' communication contact information through the Internet.
ENUM [RFC3761]はDNSネーミング・オーソリティ・ポインタ（NAPTR）[RFC3403]リソースレコードタイプを使用してドメイン名のE.164 [E164]数から変換[RFC1034]、[RFC1035]に基づいて、マッピング・システムです。 ENUMは、すべてのE.164番号のために（例えば、ファックス、電子メール、ホームページ、SIP、H.323などのように）異なるサービスの種類を記憶することが可能です。もともとは、エンドユーザーがインターネットを介して他のエンドユーザーの通信連絡先情報へのアクセスを得ることができるかに焦点を当てました。
Recently, discussion on the need to update RFC 3761 has begun to ensure that the standard also works in the "Infrastructure ENUM" scenario, where ENUM provides routing information between carriers. This resulted in two documents, the updated ENUM specification [RFC3761bis] and an Enumservice guide [ENUMSERVICE-GUIDE].
最近では、RFC 3761を更新する必要性についての議論は、標準的にもENUMは、キャリア間のルーティング情報を提供し、「インフラストラクチャENUM」のシナリオで動作することを確認するために始めています。これには二つの文書、更新ENUM仕様[RFC3761bis]とEnumserviceガイド[ENUMSERVICE-GUIDE]になりました。
When providing VoIP service, a VoIP carrier that wants to integrate various protocols typically uses a softswitch. However, such a system is still inefficient for interconnection, number portability, and sharing protocol support information among carriers, because each softswitch does not have complete end-to-end routing information for all carriers. This information can be stored in DNS, using ENUM. Therefore, carriers can expect to gain many advantages if they use ENUM within the call routing functions of their softswitches.
VoIPサービスを提供する場合、さまざまなプロトコルを統合したいのVoIPキャリアは、一般的にソフトスイッチを使用しています。各ソフトスイッチは、すべてのキャリアのための完全なエンドツーエンドルーティング情報を持っていないためしかし、そのようなシステムは、依然として相互接続、番号ポータビリティ、およびキャリア間のプロトコルサポート情報を共有するため非効率的です。この情報は、ENUMを使用して、DNSに格納することができます。そのため、キャリアは彼らのソフトスイッチの機能をコールルーティング内ENUMを使用する場合は、多くの利点を得ることを期待することができます。
To confirm these benefits and to verify the performance of ENUM-enabled softswitches, NIDA cooperated with two Korean VoIP service providers for an Infrastructure ENUM trial in 2006. NIDA is a non-profit organization with a mandate to manage 2.8.e164.arpa. (representing the +82 country code of Korea). NIDA promotes and facilitates technical cooperation on a national scale between partners, and this includes ENUM. During the trial, NIDA provided a centralized ENUM DNS to each VoIP service provider for call routing. The data used in this Infrastructure trial was also accessible to the public (i.e., it was an Internet-based system, rather than a closed scheme).
これらの利点を確認し、ENUM対応のソフトスイッチの性能を検証するために、NIDAは、2006年NIDAにおけるインフラENUMトライアル用の2つの韓国のVoIPサービスプロバイダと協力2.8.e164.arpaを管理する権限を持つ非営利団体です。 （韓国の82の国コードを表します）。 NIDAは促進し、パートナーとの間に全国規模での技術協力を促進し、これがENUMを含んでいます。裁判中は、NIDAは、コールルーティングのための各VoIPサービスプロバイダへの集中ENUMのDNSを提供します。このインフラストラクチャの試験で使用されるデータは、公開（すなわち、それは、インターネットベースのシステムではなく、閉じたスキーム）にアクセス可能でした。
In the PSTN (Public Switched Telephone Network), hardware-based switches predominate. A softswitch provides similar functionality, but is implemented on a computer system by software. It typically has to support various signalling protocols (such as SIP [RFC3261], H.323 [H323], Media Gateway Control Protocol (MGCP) [RFC3435], and others) to make call connections for VoIP service, often on the boundary point between the circuit and packet network.
PSTN（公衆交換電話網）では、ハードウェアベースのスイッチが優勢。ソフトスイッチは、同様の機能を提供しますが、ソフトウェアによるコンピュータシステム上に実装されています。それは、典型的には、多くの場合、境界点で、VoIPサービスのための呼接続をするために（たとえば、SIP [RFC3261]、H.323 [H323]、メディアゲートウェイコントロールプロトコル（MGCP）[RFC3435]、および他のような）様々なシグナリングプロトコルをサポートする必要があります回路およびパケットネットワークの間。
To make a call, first of all a softswitch must discover routing information. It has to process the E.164 number that comes from a caller through its own routing table. The goal is to determine how the call can be routed towards the callee, so that either the call can be processed through the softswitch or the caller can connect to the callee directly.
電話をかけるには、すべてのソフトスイッチの最初は、ルーティング情報を検出する必要があります。これは、独自のルーティングテーブルを介して、発信者から来ているE.164番号を処理しなければなりません。目標は、呼び出しのどちらかを直接呼び出し先に接続することができ、ソフトスイッチまたは発信者を通じて処理することができるように呼び出しが、呼び出し先に向けてルーティングすることができる方法を決定することです。
Today, call routing is often based on a prefix of the dialled number. This is used very widely not only for legacy PSTN switches, but also for softswitches. So, if a softswitch exclusively uses ENUM DNS for call routing, then, in the beginning most of the calls queried to ENUM DNS would fail if there are only a small group of carriers provisioning data into ENUM. However, a softswitch will have a higher success rate with ENUM DNS as the number of carriers grows, and so the overall percentage of numbers provisioned in ENUM increases. In short, ENUM as a long-term solution has obvious benefits, but the problem lies in migrating from today's prefix-based routing towards that long-term ENUM-based solution.
今日では、コールルーティングは、多くの場合、ダイヤルされた番号のプレフィックスに基づいています。これは、従来のPSTNスイッチの、だけでなく、ソフトスイッチのためだけでなく、非常に広く使用されています。ソフトスイッチは、専用のコールルーティングのためのENUM DNSを使用する場合ENUMにデータをプロビジョニングキャリアの唯一の小さなグループがあるのであれば、その後、初めにENUM DNSに照会の呼び出しのほとんどは失敗します。しかし、ソフトスイッチは、キャリアの数が増えるとENUM DNSと高い成功率を持っており、そのENUM増加にプロビジョニングされた数の全体的な割合ます。要するに、長期的な解決策として、ENUMは明らかな利点がありますが、問題は、長期的なENUMベースのソリューションに向けて、今日のプレフィックスベースのルーティングからの移行です。
As described in Section 1, NIDA and two VoIP service providers built ENUM-processing modules into their softswitches, interconnected these via the IP network, and provisioned their trial users' numbers into a centralized ENUM DNS system operated by NIDA. The carriers provisioned their E.164 numbers using Extensible Provisioning Protocol (EPP) [RFC4114] to a centralized Registration Server (also operated by NIDA). Changes to the ENUM data were implemented and updated to the ENUM DNS instantly, using DNS Dynamic Update [RFC2136].
第1節で述べたように、NIDAと2つのVoIPサービスプロバイダーがソフトスイッチにENUM-処理モジュールを内蔵し、IPネットワークを介してこれらを相互に接続し、NIDAが運営する集中型のENUMのDNSシステムに彼らのトライアルユーザーの番号をプロビジョニング。キャリアは、拡張プロビジョニングプロトコル（EPP）（また、NIDAによって操作）集中登録サーバに[RFC4114]を使用してE.164番号をプロビジョニング。 ENUMデータへの変更は、DNS動的更新[RFC2136]を使用して、瞬時にENUM DNSに実装され、更新されました。
In the trial, the EPP-based provisioning sub-system was developed and operated separately from the carriers' main customer provisioning systems and protocols. It was not integrated, as the carriers already operated their own customer provisioning systems that were totally different from the EPP-based model, and (as mission-critical components) those were not open to modification.
試験では、EPPベースのプロビジョニングサブシステムが開発され、キャリアの主顧客プロビジョニングシステム及びプロトコルは別に操作します。キャリアはすでにこれらの変更に開いていなかったEPPベースのモデルとは全く異なっていた自分の顧客のプロビジョニングシステムを操作し、かつ（ミッションクリティカルなコンポーネントとして）としてそれは、統合されていませんでした。
Call routing
+---------------------------------------------+
| |
| |
+-----+------+ +-----------------+ +------+-----+
|Softswitch A|------| ENUM DNS(+82) |------|Softswitch B|
+-----+------+ | (Tier1,2) | +------+-----+
| +--------+--------+ |
+-----+------+ | +------+-----+
| IP Phone A | |Dynamic Update | IP Phone B |
+------------+ |(RFC 2136) +------------+
|
+------------+ +--------+--------+ +------------+
| EPP Client | | Registration | | EPP Client |
| |------| Server |------| |
+------------+ +-----------------+ +------------+
Provisioning E.164 Numbers(RFC 4114)
Carrier A NIDA Carrier B
キャリアA NIDAキャリアB
Figure 1: Infrastructure ENUM Trial System Topology
図1：インフラストラクチャENUM試作システムトポロジ
To use ENUM DNS, each softswitch needs to have an ENUM module that converts from an E.164 number to the ENUM domain name (as defined in RFC 3761) and processes a query to ENUM DNS. This ENUM module uses the algorithm specified in RFC 3761.
ENUM DNSを使用するように、各ソフトスイッチは、ENUMドメイン名にE.164番号から変換ENUMモジュールを有する必要がある（RFC 3761で定義されるように）とENUM DNSにクエリーを処理します。このENUMモジュールは、RFC 3761で指定されたアルゴリズムを使用しています。
However, in the initial stage of ENUM DNS roll-out, ENUM shares call routing information from a limited number of carriers. There is the problem that a softswitch can't find all of the call routing information it needs just using ENUM. To solve this problem, ENUM-based softswitches have to follow a consistent set of rules.
しかしながら、ENUMのDNSロールアウトの初期段階では、ENUM株はキャリアの限られた数からのルーティング情報を呼び出します。ソフトスイッチは、それだけでENUMを使用して必要とコールルーティング情報のすべてを見つけることができないという問題があります。この問題を解決するために、ENUMベースのソフトスイッチは、ルールの一貫したセットに従わなければなりません。
As a matter of policy in this trial, all telephone numbers in use within an "ENUM only" number range (i.e., ones in which an endpoint could only be reached via a URI found during an ENUM lookup of a telephone number in this range, and for which there was no PSTN Point of Interconnect) were arranged to return a NAPTR response. For ranges in which there was a PSTN Point of Interconnect, this was not required.
この裁判での方針として、「ENUMのみ」の数の範囲内で使用されているすべての電話番号は（つまり、エンドポイントのみURIを介して到達することができたでものは、この範囲内の電話番号のENUM検索中に見つかりましたそしてそのためにそこに）相互接続のないPSTNポイントなかったNAPTR応答を返すように配置しました。範囲についてはここで、これは必要ではなかった、インターコネクトのPSTNポイントがありました。
Thus, no data (at all) needed to be provisioned into an associated ENUM domain for such a number if it were possible to "reach" that number via the PSTN, unless there were also an IP-based Point of Interconnect serving that number and the serving carrier chose to make this option available.
それはPSTNを介してその数を「到達」することが可能であればその数にサービスを提供する相互接続のIPベースポイントも存在しない限り、このように、（すべてで）データは、そのような数の関連ENUMドメインにプロビジョニングする必要がなく、サービス提供キャリアは、このオプションを利用可能にすることを選びました。
In those domains in which NAPTRs for ENUM processing were provisioned, these NAPTRs were always 'terminal' rules -- non-terminal NAPTRs were not used. If non-terminal NAPTRs were to be provisioned, then the standard operation of ENUM processing might have required extra DNS lookups before the set of NAPTRs for a telephone number could be evaluated. The delay and indeterminacy this would introduce was not considered acceptable.
非末端NAPTRs使用しなかった - ENUM処理のNAPTRsがプロビジョニングされたこれらのドメインでは、これらNAPTRsは常に「末端」ルールがありました。非終端NAPTRsをプロビジョニングするとしたら、電話番号のNAPTRsのセットが評価される前に、その後、ENUM処理の標準操作は、余分なDNSルックアップを必要としていたかもしれません。これが導入する遅延や不確定性を許容できると考えられていませんでした。
The case where a valid URI was present is covered in Section 4.1.2 (rule 2 A, second point). The case where an ENUM entry was not provisioned for a number that had an active PSTN Point of Interconnect is covered in Section 4.1.2 (rule 2 B).
有効なURIが存在していた場合は、セクション4.1.2（ルール2 A、第二の点）で覆われています。 ENUMエントリがインターコネクトのアクティブPSTNポイントを持っていた数にプロビジョニングされなかった場合は、セクション4.1.2（ルール2 B）で覆われています。
For "ENUM only" ranges, where a given number in that range was in service (i.e., there was an IP-based Point of Interconnect to a carrier), a valid SIP or H.323 URI was always provisioned into the associated ENUM domain. This is covered in Section 4.1.2 (rule 2 A, second point).
その範囲内の指定された数はサービスにあった「ENUMのみ」の範囲については、有効なSIPやH.323 URIは、常に関連するENUMドメインにプロビジョニングされた、（すなわち、キャリアへの相互接続のIPベースのポイントがありました） 。これは、4.1.2（ルール2 A、第二の点）で覆われています。
In such an "ENUM only" range, if the number was not in service, a TXT record was provisioned but no valid NAPTRs would be present. This ensured that a query for NAPTRs in a given (out of service, "ENUM only" range) domain would succeed (i.e., return a RCODE of 0), but that the number of answers would also be zero. This is covered in Section 4.1.2 (rule 2 A, first point). Note that this point also covers the case where only NAPTRs that cannot be used to initiate a call exist in such a zone.
数がサービスしていなかった場合、このような「ENUMのみ」の範囲では、TXTレコードは、プロビジョニングされたが、有効なNAPTRsは存在しないでしょう。これは、与えられた（サービスのうち、「ENUMのみ」の範囲）ドメインのNAPTRsためのクエリは（すなわち、0のRCODEを返す）成功することが、回答数がゼロになることを確実にしました。これは、4.1.2（ルール2 A、最初の点）で覆われています。この点は、呼を開始するために使用することができないだけNAPTRsは、ゾーン内に存在するケースをカバーすることに留意されたいです。
Where a valid URI was provisioned, the ENUM lookup would complete by returning that value for further processing. This further processing is covered in Section 4.2.
有効なURIがプロビジョニングされた場合は、ENUMの検索は、さらなる処理のためにその値を返すことで完了します。このさらなる処理は、4.2節で覆われています。
For "ENUM only" ranges, there was a further policy requirement that an IP-based Point of Interconnect specified inside a NAPTR (as the domainpart of a valid URI) must be accessible for all potential carriers. The server could reject a subsequent SIP Invitation, but its machine address had to resolve. This was intended to avoid the condition where the domain name did not resolve, the softswitch logic would attempt to place the call via the PSTN, and this would fail and/or loop.
「唯一のENUM」の範囲については、（有効なURIのdomainpartとして）NAPTR内の指定したインターコネクトのIPベースのポイントは、すべての潜在的なキャリアのためにアクセス可能である必要があり、さらに政策の必要がありました。サーバーは、後続のSIP招待を拒否することができますが、そのマシンのアドレスが解決しなければなりませんでした。これは、ドメイン名が解決できなかった、ソフトスイッチロジックは、PSTN経由で電話をかけしようと、これは失敗および/またはループしまう状態を避けるために意図されていました。
This "must resolve" requirement was not needed for numbers that had an active PSTN Point of Interconnect (i.e., the vast majority of assigned numbers). If the domain name did not resolve, the call would "drop back" to PSTN processing.
この「解決しなければならない」要件は、インターコネクトのアクティブPSTNポイントを持っていた数字のために必要ではなかった（すなわち、割り当てられた番号の大半）。ドメイン名が解決しなかった場合、コールはPSTN処理に「バックドロップ」でしょう。
In the Korean trial, the rules were:
韓国語の試験では、ルールは以下の通りでした。
1. The ENUM module of the softswitch converts an E.164 number coming from the VoIP subscriber to an ENUM domain name (as defined in RFC 3761).
1.ソフトスイッチのENUMモジュールは、（RFC 3761で定義されるように）ENUMドメイン名へのVoIP加入者からのE.164番号を変換します。
2. The ENUM module, acting as a DNS stub resolver, sends a query to a recursive name server.
2. ENUMモジュールは、DNSスタブリゾルバとして動作する、再帰ネームサーバにクエリを送信します。
3. If the ENUM module receives a DNS answer, the call routing process may branch off in several ways, depending on the Rcode value in the DNS response message, as shown below.
3. ENUMモジュールは、DNS応答を受信した場合、以下に示すように、コールルーティング処理は、DNS応答メッセージにRCODE値に応じて、いくつかの方法で分岐してもよいです。
A. Rcode=0 (No error condition)
There is, potentially, an answer to the corresponding query.
The normal call routing process needs to differentiate
between the following conditions:
+ The response includes no URI (such as SIP or H.323) that
can be used to initiate a call --
The call fails immediately.
Note: In the trial, the condition in which a telephone
number:
- is valid,
- 有効であり、
- can only be reached via the Internet, but
- のみ、インターネットを介して到達することができますが、
- is not currently in service
- 現在サービス中ではありません
is indicated by an ENUM domain that DOES exist but DOES NOT include any supported (routable) NAPTRs. A softswitch receiving this response interprets it as indicating that the call can be dropped immediately -- it would fail if passed to the PSTN.
存在するENUMドメインで示されているが、任意のサポートされている（ルーティング可能な）NAPTRsを含みません。この応答を受信したソフトスイッチは、呼が直ちにドロップされることを示すと解釈 - PSTNに渡される場合、それは失敗します。
+ There is at least one usable URI (such as SIP and/or H.323 URIs) -- The softswitch picks one based on the preference and order field values in the NAPTR Resource Record Set, and routes the call using the method described in Section 4.2.
+少なくとも一つの利用可能なURIがある（例えば、SIPおよび/またはH.323のURIなど） - ソフトスイッチは、NAPTRリソースレコードセット内の優先順位とフィールド値に基づくもの、及びルートに記載の方法を使用してコールピック4.2節。
B. Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4 (Not Implemented), or 5 (Refused) There is no valid answer for the query. The softswitch has no choice but to route the call using the E.164 number with its vendor-specific method (such as a prefix-based method). In this case, it means that the call has to be delivered through the PSTN for onward call routing.
B. RCODE = 3（名前・エラー）、1（フォーマットエラー）、2（サーバ障害）、4（未実装）、または5（拒否）クエリに対して有効な答えはありません。ソフトスイッチは、（例えば、プレフィックスベースの方法など）は、そのベンダー固有の方法とE.164番号を用いて呼を選択の余地を有していないが、ルーティングします。この場合には、呼が以降コールルーティングのためにPSTNを介して配信されなければならないことを意味します。
It is also important to stress that the ENUM DNS servers must
respond to all queries they receive from the softswitches.
If the ENUM module in a softswitch does not receive a
response, it will eventually time out, and the ENUM module
will treat this as a DNS error. However, the delay involved
is long in terms of the normal call setup time, and should be
avoided.
It would have been possible to modify the DNS code in each
softswitch to have shorter time-outs than normal to cover
misconfiguration of a DNS server, but this choice was not
considered in the trial. The softswitch DNS stack was used
for several purposes other than "pure" ENUM lookups.
Configuring it in a non-complaint manner was considered
unacceptable, due to the need to analyze the impact of that
choice on other DNS operations thoroughly before it could be
implemented safely.
If the DNS response has a valid URI, such as SIP or H.323, the softswitch can resolve the domain name part of that URI to route a call by searching two different sources. One is a recursive nameserver, and the other is a fixed routing table held in the softswitch, mapping from the domain name to the corresponding gateway's host name and IP address.
DNS応答は、SIPやH.323など、有効なURIを、持っている場合は、ソフトスイッチは、2つの異なるソースを検索することにより、コールのルーティングにそのURIのドメイン名の部分を解決することができます。一つは、再帰的なネームサーバであり、他方はソフトスイッチに保持固定されたルーティングテーブルであり、対応するゲートウェイのホスト名とIPアドレスのドメイン名からマッピング。
If there are many points of interconnection, using a recursive nameserver is useful for resolving a domain name, but if there are just a few known carriers and they do not change this interconnection information frequently, a fixed (internal) routing table mapping from domain name to the corresponding gateway hostname and IP address is more efficient (rather than querying the recursive nameserver every time). In addition, carriers would like to charge an interconnection fee for all received calls, so they tend to make interconnection only with trusted carriers based on some sort of bilateral agreement between these carriers. They may agree on a specific gateway for this purpose, so the interconnection information is often private to the parties of this particular agreement.
相互接続の多くのポイントがある場合は、再帰的なネームサーバを使用すると、ドメイン名を解決するのに便利ですが、ちょうど少数の知らキャリアが存在する場合、彼らは、頻繁にドメイン名からの固定（内部）ルーティングテーブルのマッピングをこの相互接続情報を変更しないでください対応するゲートウェイのホスト名とIPアドレスに（むしろ再帰ネームサーバ毎に問い合わせるよりも）より効率的です。また、キャリアは、受信したすべてのコールのための相互接続料金を請求したいと思いますので、彼らはこれらのキャリア間の二国間協定のいくつかの並べ替えに基づいて、信頼できるキャリアとの相互接続をする傾向があります。彼らは、この目的のために特定のゲートウェイに同意することができるので、相互接続情報は、多くの場合、この特定の契約の関係者にプライベートです。
In principle, these two approaches could be used in parallel, but in practice, if the DNS-based approach could be used, there would be no point in retaining the expensive and elaborate "offline" infrastructure to exchange and install the tables for domain routing. In this trial, uncertainty over the performance and reliability of ENUM-based processing meant that the softswtitches were configured so that they could be switched between the two approaches immediately. This was a temporary expedient only, and would not be a reasonable approach in the long term.
原則として、これら2つのアプローチが並列に使用することができますが、DNSベースのアプローチを使用することができれば実際には、そこに高価を保持するのにはポイントになることはありませおよびドメインルーティングのためのテーブルを交換してインストールする「オフライン」のインフラを精巧う。この試験では、ENUMベースの処理の性能および信頼性上の不確実性は、それらが直ちに二つのアプローチの間で切り替えることができるようにsoftswtitchesが設定されたことを意味します。これは一時的な方便だった、そして長期的に合理的なアプローチではないでしょう。
These two types of domain routing are also affected by the Rcode=0 case described in Section 4.1.
ドメインルーティングのこれらの2つのタイプはまた、セクション4.1で説明RCODE = 0の場合に影響されます。
There are two choices for routing. These are described and compared here:
ルーティングのための2つの選択肢があります。これらは説明し、ここで比較されています。
A. If the domain name part of the URI is found in the internal
fixed routing table, the softswitch can use it.
B. If the domain name part of the URI does not exist in the fixed routing table, the call is forwarded to the PSTN.
URIのドメイン名部分が固定ルーティングテーブルに存在しない場合、Bは、コールがPSTNに転送されます。
A. If the domain name part of the URI can be resolved via the
recursive nameserver, the softswitch can use it.
B. If the domain name part of the URI cannot be resolved on the recursive nameserver for any reason (such as a response with no usable resource records according to [RFC3263] and [RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be forwarded to the PSTN.
URIのドメイン名部分が、又はRCODE = 1、2、3と[RFC3263]及び[RFC3261]にかかるない使用可能なリソースレコードを応答として（何らかの理由で再帰ネームサーバに解決できないB.場合、 4、または5）、呼がPSTNに転送されなければなりません。
Case (1) seems inefficient because the administrator maintains two management points for numbers: the ENUM DNS and the softswitch itself. However, this configuration can minimize the call routing failure ratio during the transition period of ENUM (when there are relatively few provisioned ENUM entries and so few IP-based Points Of Interconnection). Thus, case (1) could reasonably be implemented on the softswitches during the trial phase, and thereafter, as ENUM entries are populated, case (2) would be a reasonable choice.
ENUMのDNSおよびソフトスイッチ自体：管理者は番号の2つの管理ポイントを維持するので、（1）の場合は非効率です。しかしながら、この構成は、（比較的少ないプロビジョニングENUMエントリと配線で非常に少ないIPベースポイントがある）ENUMの移行期間中に不良率をコールルーティングを最小限に抑えることができます。したがって、ケース（1）は、合理的に試験段階の間ソフトスイッチ上に実装することができ、ENUMエントリが取り込まれるように、その後、ケース（2）合理的な選択であろう。
With these choices, the two carriers could use ENUM DNS for call routing without any impact on their ongoing commercial VoIP service.
これらの選択肢では、2つのキャリアは彼らの継続的な商用VoIPサービスに影響を与えることなくコールルーティングのためのENUMのDNSを使用することができます。
To provide a stable commercial service, an ENUM-based softswitch must have a defined performance, in the same way as must any non-ENUM-based softswitch. The only difference between these two types of softswitches is the searching mechanism for call routing information, which can be stored in the softswitch itself or in the DNS. Therefore, a similar delay time for call routing is important to guarantee quality of service. During the trial, each carrier measured this delay time when using the SIP protocol. This was based on the "Answer Delay time", defined as the elapsed time between requesting a call ('INVITE' message) and receiving a response ('200 OK' message) [RFC3261].
安定した商用サービスを提供するために、ENUMベースのソフトスイッチを行う必要があり、任意の非ENUMベースのソフトスイッチと同じように、定義された性能を持っている必要があります。ソフトスイッチのこれらの2つのタイプの唯一の違いは、ソフトスイッチ自体に、またはDNSに格納することができるコールルーティング情報、の探索機構です。そのため、コールルーティングのための同様の遅延時間は、サービスの品質を保証することが重要です。 SIPプロトコルを使用する場合に試験中、各キャリアは、この遅延時間を測定しました。これは、呼び出し（「INVITE」メッセージ）を要求し、応答（「200 OK」メッセージ）[RFC3261]を受信する間の経過時間として定義され、「遅延時間を回答」に基づいていました。
+------------------------+------+----------+
| Call Type | ENUM | Non-ENUM |
+------------------------+------+----------+
| Carrier A->A | 2.33 | 2.28 |
| Carrier A->B | 2.23 | 2.25 |
| Carrier A->other(PSTN) | 4.11 | 3.79 |
| Carrier B->B | 2.18 | 2.05 |
| Carrier B->A | 2.19 | 2.19 |
| Carrier B->other(PSTN) | 3.95 | 3.41 |
+------------------------+------+----------+
Table 1: Average Answer Delay Time (Sec)
表1：平均回答遅延時間（秒）
As shown in Table 1, there is little difference in time (under a second) between the ENUM and non-ENUM cases. Therefore, it is difficult for a caller with either carrier to detect the choice (ENUM or non-ENUM) as an aspect of quality when a call initiates. This means that ENUM definitely works well with softswitches on a commercial basis.
表1に示すように、ENUMと非ENUMケースとの間（第2の下の）時間にほとんど差があります。従って、呼が開始したときに品質の側面として選択（ENUMまたは非ENUM）を検出するための担体のいずれかを用いて、発信者のために困難です。これは、ENUMは間違いなく、商業ベースでソフトスイッチとうまく動作することを意味します。
To make the trial more realistic, the resolver that was used by these ENUM-based softswitches was a recursive nameserver that could be accessed publicly. This was done as it was felt that a tough condition would be better to verify the fact that an ENUM-based softswitch works as well as a non-ENUM-based softswitch in providing a commercial VoIP service.
裁判がより現実的にするために、これらのENUMベースのソフトスイッチで使用されたリゾルバは、公的にアクセスすることができ、再帰的なネームサーバでした。それは厳しい条件がENUMベースのソフトスイッチは、商用VoIPサービスを提供する非ENUMベースのソフトスイッチと同様に動作していることを確認した方がよいだろうと感じられたように行われました。
During the trial, the Infrastructure ENUM deployed in the 2.8.e164.arpa zone could be accessed via the (public) Internet. In this situation, each carrier questioned whether or not the centralized number management under the ENUM DNS was realistic.
裁判中、2.8.e164.arpaゾーンで展開インフラストラクチャENUMは、（パブリック）は、インターネットを介してアクセスすることができます。このような状況では、各キャリアは、ENUM DNSの下に一元化さ数管理が現実的だったかどうかを疑問視。
Another issue concerned responsibility for routing errors. All carriers can use the shared ENUM data to route their calls. However, if there are routing errors (due to the data being provisioned incorrectly), it is not always clear who has responsibility for these errors and who can correct the data. The errors occur in the networks of the carriers placing the calls. Unless the identity of the carrier responsible for delivering service to this telephone number is known, it is not obvious (to the carrier handling the error) who should be informed of these problems. This is a particular issue when number portability is introduced.
もう一つの問題は、エラーをルーティングする責任を懸念します。すべてのキャリアは、ルートへの呼び出しを共有ENUMデータを使用することができます。 （起因する誤っプロビジョニングされているデータへの）ルーティングエラーがある場合は、これらのエラーのために責任を持っており、誰がデータを修正することができます誰が必ずしも明確ではありません。エラーが電話をかけキャリアのネットワークで発生します。この電話番号にサービスを提供する責任キャリアの身元が知られていない限り、それはこれらの問題について通知しなければならない（エラーハンドリングキャリアに）明らかにされていません。これは、番号ポータビリティが導入された特定の問題です。
In addition, the carriers also question whether or not Infrastructure ENUM needs to be accessible publicly. To prevent disclosure of telephone numbers, they would prefer to access the ENUM DNS privately. Therefore, any ENUM module embedded in a softswitch needs to be flexible to adopt these considerations during the interim period of ENUM, before common policies and agreements have been forged.
また、キャリアはまた、インフラストラクチャENUMは、公的にアクセスする必要があるかどうかを疑問視。電話番号の開示を防ぐために、彼らは個人的ENUM DNSにアクセスすることを好むだろう。したがって、ソフトスイッチに埋め込まれた任意のENUMモジュールは、共通のポリシーおよび契約が偽造されている前に、ENUMの暫定期間中、これらの考慮事項を採用する柔軟である必要があります。
This document inherits the security considerations described in RFC 3761 and [RFC5067], as the ENUM DNS used with softswitches in this trial could be accessed publicly.
この試験でソフトスイッチとともに使用するENUMのDNSは、公にアクセスできるようにこの文書は、RFC 3761及び[RFC5067]に記載されたセキュリティ上の考慮事項を継承します。
In addition, if the recursive resolvers handling ENUM queries coming from a softswitch were to be compromised by an attacker, that attacker would be able to force calls to fail or cause delay to calls. Therefore, the DNS resolvers used should allow access from the local network to which the softswitch is connected, whilst restricting access from outside, using a proper access-list policy.
ソフトスイッチからENUMクエリーを処理する再帰リゾルバが攻撃者によって危険にさらされるした場合また、その攻撃は失敗したり、呼び出しに遅延が発生するための呼び出しを強制することができるだろう。したがって、使用されるDNSリゾルバは、適切なアクセス・リスト・ポリシーを使用して、外部からのアクセスを制限しながら、ソフトスイッチが接続されるローカルネットワークからのアクセスを可能にすべきです。
Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim Reid, and Otmar Lendl who helped guide the direction of this document, and to Suresh Krishnan, whose GEN-ART review was very helpful.
このドキュメントの方向を導く助けたリチャードショッキー、ジェイソンLivingood、カルステンFleischhauer、ジム・リード、およびオトマールレンドルに、そしてGEN-ARTレビューとても役に立ちましたスレシュクリシュナン、に感謝します。
[E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E164] ITU-T、 "国際公共通信番号プラン"、勧告E.164、2005年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761] Faltstrom、P.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。
[ENUMSERVICE-GUIDE] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", Work in Progress, September 2008.
[ENUMSERVICE-GUIDE] Hoeneisen、B.、Mayrhofer、A.、およびJ. Livingood、 "EnumservicesのIANA登録：ガイド、テンプレート、およびIANAの考慮事項"、進歩、2008年9月の作業。
[H323] ITU-T, "Packet-based multimedia communications systems", Recommendation H.323, 2003.
[H323] ITU-T、 "パケットベースのマルチメディア通信システム"、勧告H.323、2003年。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（MGCP）バージョン1.0"、RFC 3435、2003年1月。
[RFC3761bis] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Work in Progress, February 2008.
[RFC3761bis]ブラドナーの、S.、コンロイ、L.、およびK.藤原、 "統一資源識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、進歩、2008年2月に作業。
[RFC4114] Hollenbeck, S., "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4114, June 2005.
[RFC4114]ホレンベック、S.、RFC 4114、2005年6月 "E.164番号マッピング拡張プロビジョニングプロトコル（EPP）のための"。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067]リンド、S.とP. Pfautz、 "インフラストラクチャENUM要件"、RFC 5067、2007年11月。
Authors' Addresses
著者のアドレス
JoonHyung Lim National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul Korea
韓国のJoonHyungリム国立インターネット開発庁（ニダ）3F。 .MEHAMEHA B / D 1321から1311、瑞草洞、瑞草区ソウル、韓国
Phone: +82-2-2186-4548 EMail: jhlim@nida.or.kr URI: http://www.nida.or.kr
電話：+ 82-2-2186-4548 Eメール：jhlim@nida.or.kr URI：http://www.nida.or.kr
Weon Kim National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul Korea
キムは韓国の国家インターネット開発庁（ニダ）3Fをshors。 .MEHAMEHA B / D 1321から1311、瑞草洞、瑞草区ソウル、韓国
Phone: +82-2-2186-4502 EMail: wkim@nida.or.kr URI: http://www.nida.or.kr
電話：+ 82-2-2186-4502 Eメール：URI wkim@nida.or.kr：http://www.nida.or.kr
ChanKi Park National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul Korea
韓国のChanKi公園国立インターネット開発庁（ニダ）3F。 .MEHAMEHA B / D 1321から1311、瑞草洞、瑞草区ソウル、韓国
Phone: +82-2-2186-4504 EMail: ckp@nida.or.kr URI: http://www.nida.or.kr
電話：+ 82-2-2186-4504 Eメール：ckp@nida.or.kr URI：http://www.nida.or.kr
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
ローレンスコンロイRokeマナー研究Rokeマナーオールド・ソールズベリーレーンロムジーイギリス
Phone: +44-1794-833666 EMail: lconroy@insensate.co.uk URI: http://www.sienum.co.uk
電話：+ 44-1794-833666電子メール：lconroy@insensate.co.uk URI：http://www.sienum.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。