[要約] RFC 5346は、ENUMベースのソフトスイッチの運用要件に関するものであり、ENUMを使用した通信の効率的な管理と制御を目的としています。
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）がホストする列挙前の営利試験で得られた2つの韓国音声（VOIP）キャリア間のコールルーティングに関する列挙ベースのソフトスイッチに関するいくつかの考慮事項について説明します。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が大部分の呼び出しに対して十分なデータを持っていない列挙サービスの初期段階で進行中の商用ソフトスイッチシステム操作の安定性を維持できることを示しています。
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]は、命名権限ポインター（NAPTR）[RFC3403]リソースレコードタイプを使用して、E.164 [E164]数値からドメイン名に変換するDNS [RFC1034] [RFC1035]に基づくマッピングシステムです。Enumは、すべてのE.164番号に対して、さまざまなサービスタイプ（FAX、電子メール、ホームページ、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を更新する必要性についての議論は、標準が「インフラストラクチャエインム」シナリオでも機能することを保証し始めました。これにより、2つのドキュメント、更新された列挙仕様[RFC3761BIS]とEnumserviceガイド[Enumservice-Guide]が2つになりました。
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キャリアは、通常、SoftSwitchを使用します。ただし、各ソフトスイッチにはすべてのキャリアの完全なエンドツーエンドルーティング情報がないため、このようなシステムは相互接続、数の移植性、および共有プロトコルサポート情報に対して依然として非効率的です。この情報は、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).
これらの利点を確認し、列挙対応のソフトスイッチのパフォーマンスを検証するために、NIDAは2006年にインフラストラクチャエインムトライアルのために2つの韓国VoIPサービスプロバイダーと協力しました。NIDAは2.8.E164.ARPAを管理する義務を負う非営利組織です。（韓国の82カントリーコードを表す）。NIDAは、パートナー間の全国規模での技術的協力を促進し、促進します。これには列挙が含まれます。裁判中、NIDAは、コールルーティングのために各VOIPサービスプロバイダーに集中列挙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（公開された電話ネットワーク）では、ハードウェアベースのスイッチが支配的です。SoftSwitchは同様の機能を提供しますが、ソフトウェアごとにコンピューターシステムに実装されています。通常、さまざまなシグナル伝達プロトコル（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番号を処理する必要があります。目標は、コールをCalleeに向かってルーティングする方法を判断することです。これにより、コールをSoftSwitchを介して処理できるか、発信者がCalleeに直接接続できます。
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スイッチだけでなく、ソフトスイッチにも非常に広く使用されています。したがって、SoftSwitchがコールルーティングにEnum DNSのみを使用している場合、最初は、列挙されたキャリアの小さなグループのみがenumにデータをプロビジョニングする場合、enum DNSに照会されたほとんどの呼び出しが故障します。ただし、ソフトスイッチは、キャリアの数が増加するにつれて列挙DNSでより高い成功率を持ち、列挙でプロビジョニングされた数値の全体的な割合が増加します。要するに、長期的なソリューションとしての列挙には明らかな利点がありますが、問題は、その長期的な列挙ベースのソリューションへの今日のプレフィックスベースのルーティングから移行することにあります。
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サービスプロバイダーは、列挙プロセスモジュールをソフトスイッチに組み込み、IPネットワークを介してこれらを相互接続し、NIDAが運営する集中酵素DNSシステムにトライアルユーザーの番号をプロビジョニングしました。キャリアは、拡張可能なプロビジョニングプロトコル（EPP）[RFC4114]を使用して、e.164番号を集中登録サーバー（NIDAによって運営）にプロビジョニングしました。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
Figure 1: Infrastructure ENUM Trial System Topology
図1：インフラストラクチャエインムトライアルシステムトポロジ
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を使用するには、各ソフトスイッチには、e.164数からenumドメイン名（RFC 3761で定義されている）に変換され、enum DNSへのクエリを処理するenumモジュールが必要です。この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は限られた数のキャリアからルーティング情報を呼び出します。SoftSwitchが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.
このトライアルのポリシーの問題として、「列挙のみ」の範囲内で使用されているすべての電話番号（つまり、エンドポイントは、この範囲の電話番号の列挙ルックアップ中に見つかったURIを介してのみ到達できたもので、この範囲の電話番号の列挙の検索中に到達できます。また、相互接続の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.
したがって、その数とその数とその数を提供するIPベースのポイントもある場合を除き、PSTNを介してその数値に「到達」することが可能であれば、そのような数に関連する列挙ドメインにプロビジョニングする必要はありませんでした。サービングキャリアは、このオプションを利用可能にすることを選択しました。
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.
列挙処理用のNAPTRがプロビジョニングされたドメインでは、これらのNAPTRは常に「末端」ルールでした - 非末端NAPTRは使用されませんでした。非末端NAPTRをプロビジョニングする場合、電話番号のNAPTRのセットを評価する前に、列挙処理の標準操作に追加の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、2番目のポイント）でカバーされています。インターコネクトのアクティブな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).
その範囲の特定の数値が使用されている（つまり、キャリアへのIPベースの相互接続ポイントがありました）範囲の場合、有効なSIPまたはH.323 URIが常に関連するenumドメインにプロビジョニングされました。これは、セクション4.1.2（規則2 A、2番目のポイント）で説明されています。
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.
このような「列挙のみ」範囲では、数値が使用されていない場合、TXTレコードがプロビジョニングされましたが、有効なNAPTRは存在しません。これにより、特定の（使用不能、「enumのみ」範囲）ドメインでのNAPTRのクエリが成功することが保証されます（つまり、0のRcodeを返す）が、回答の数もゼロになることがあります。これは、セクション4.1.2（規則2 A、最初のポイント）で説明されています。この点は、そのようなゾーンに呼び出しを開始するために使用できないNAPTRのみが存在する場合もカバーしていることに注意してください。
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がプロビジョニングされた場合、さらに処理するためにその値を返すことにより、列挙ルックアップが完了します。このさらなる処理については、セクション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のみ」の範囲の場合、NAPTR内で指定されたIPベースの相互接続ポイント（有効なURIのドメインパートとして）がすべての潜在的なキャリアにアクセスできることをさらにポリシー要件がありました。サーバーは、その後の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. SoftSwitchの列挙モジュールは、VoIPサブスクライバーからenumドメイン名（RFC 3761で定義されている）に登場するE.164数を変換します。
2. The ENUM module, acting as a DNS stub resolver, sends a query to a recursive name server.
2. DNS Stub Resolverとして機能するEnumモジュールは、再帰名サーバーにクエリを送信します。
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:
A. rcode = 0（エラー条件なし）対応するクエリに対する回答が潜在的にあります。通常のコールルーティングプロセスでは、次の条件を区別する必要があります。
+ 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:
+ 応答には、呼び出しの開始に使用できるURI（SIPやH.323など）が含まれません。コールはすぐに失敗します。注：試験では、電話番号が条件：
- 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.
存在するが、サポートされている（ルーティング可能な）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.
+ 少なくとも1つの使用可能なURI（SIPやH.323 URIなど）があります - SoftSwitchは、NAPTRリソースレコードセットの好みと順序のフィールド値に基づいて1つを選択し、セクションで説明した方法を使用してコールをルーティングします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（拒否）クエリに対して有効な回答はありません。SoftSwitchは、ベンダー固有の方法（プレフィックスベースの方法など）を使用して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.
また、Enum DNSサーバーがソフトスイッチから受け取ったすべてのクエリに応答する必要があることを強調することも重要です。SoftSwitch内のenumモジュールが応答を受信しない場合、最終的にタイムアウトし、EnumモジュールはこれをDNSエラーとして扱います。ただし、関係する遅延は通常のコールセットアップ時間の点で長く、避ける必要があります。各ソフトスイッチのDNSコードを変更して、DNSサーバーの誤った構成をカバーするために通常よりも短いタイムアウトを持つように変更することは可能でしたが、この選択は試験では考慮されませんでした。SoftSwitch DNSスタックは、「純粋な」列挙ルックアップ以外のいくつかの目的に使用されました。非不満のある方法で構成することは、安全に実装される前に、他のDNS操作に対するその選択の影響を徹底的に分析する必要があるため、受け入れられないと見なされました。
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がある場合、SoftSwitchはそのURIのドメイン名部分を解決して、2つの異なるソースを検索して呼び出しをルーティングできます。1つは再帰的な名前サーバーで、もう1つはソフトスイッチに保持されている固定ルーティングテーブルで、ドメイン名から対応するゲートウェイのホスト名と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ベースのアプローチを使用できれば、高価で精巧な「オフライン」インフラストラクチャを保持して、ドメインルーティングのテーブルを交換およびインストールすることは意味がありません。。この試験では、列挙ベースの処理のパフォーマンスと信頼性に対する不確実性により、Softswtitchesが2つのアプローチを直ちに切り替えることができるように構成されました。これは一時的な手段のみであり、長期的には合理的なアプローチではありません。
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つの選択肢があります。これらについては、ここで説明されています。
1. Case when using a fixed routing table:
1. 固定ルーティングテーブルを使用する場合：
A. If the domain name part of the URI is found in the internal fixed routing table, the softswitch can use it.
A. URIのドメイン名部分が内部固定ルーティングテーブルにある場合、SoftSwitchはそれを使用できます。
B. If the domain name part of the URI does not exist in the fixed routing table, the call is forwarded to the PSTN.
B. URIのドメイン名部分が固定ルーティングテーブルに存在しない場合、コールはPSTNに転送されます。
2. Case when using a recursive nameserver:
2. 再帰名を使用する場合：
A. If the domain name part of the URI can be resolved via the recursive nameserver, the softswitch can use it.
A. URIのドメイン名部分を再帰的な名前サーバーを介して解決できる場合、SoftSwitchはそれを使用できます。
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.
B.何らかの理由でURIのドメイン名部分を再帰名サーバーで解決できない場合（[RFC3263]および[RFC3261]、またはrcode = 1、2、3の使用可能なリソース記録がない場合など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.
ケース（1）は、管理者が数字の2つの管理ポイントを維持しているため、非効率的と思われます。列挙DNSとSoftSwitch自体です。ただし、この構成は、列挙の移行期間中のコールルーティング障害比を最小化できます（プロビジョニングされた列挙エントリが比較的少なく、IPベースのインターコネクションのポイントが少ない場合）。したがって、ケース（1）は、試行段階でソフトスイッチに合理的に実装される可能性があり、その後、列挙エントリが入力されるため、ケース（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].
安定した商業サービスを提供するには、列挙ベースのソフトスイッチは、非エナムベースのソフトスイッチと同じように、定義されたパフォーマンスを持たなければなりません。これら2つのタイプのソフトスイッチの唯一の違いは、コールルーティング情報の検索メカニズムであり、ソフトスイッチ自体またはDNSに保存できます。したがって、コールルーティングの同様の遅延時間は、サービスの品質を保証するために重要です。試験中、各キャリアはSIPプロトコルを使用するときにこの遅延時間を測定しました。これは、「回答遅延時間」に基づいており、コール（「招待」メッセージ）と応答（「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：平均回答遅延時間（SEC）
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が商業ベースでSoftSwitchesで間違いなくうまく機能することを意味します。
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.
トライアルをより現実的にするために、これらの列挙ベースのソフトスイッチで使用されたリゾルバーは、公にアクセスできる再帰的な名前サーバーでした。これは、列挙ベースのソフトスイッチが商業的なVoIPサービスを提供する際に非エナムベースのソフトスイッチが機能するという事実を検証するのが難しいと感じられたために行われました。
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ゾーンに展開されたインフラストラクチャの列挙に（公開）インターネットを介してアクセスできます。この状況では、各キャリアは、列挙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.
別の問題は、ルーティングエラーに対する責任に関するものです。すべてのキャリアは、共有列挙データを使用して呼び出しをルーティングできます。ただし、ルーティングエラーがある場合（データが誤ってプロビジョニングされているため）、これらのエラーに対して誰が責任を負い、誰がデータを修正できるかは必ずしも明確ではありません。エラーは、コールを配置するキャリアのネットワークで発生します。この電話番号にサービスを提供する責任者の担当者の身元が知られていない限り、これらの問題を知らされるべき人が誰が通知されるべきかは明らかではありません。これは、数字の移植性が導入された場合の特定の問題です。
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.
さらに、キャリアは、インフラストラクチャの列挙に公開される必要があるかどうかも疑問視しています。電話番号の開示を防ぐために、彼らは列挙DNSに個人的にアクセスすることを好みます。したがって、一般的なポリシーと合意が築かれる前に、列挙の暫定期間中にこれらの考慮事項を採用するために、ソフトスイッチに埋め込まれた列挙モジュールは柔軟である必要があります。
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.
このドキュメントは、RFC 3761および[RFC5067]に記載されているセキュリティ上の考慮事項を継承します。この試験でソフトスイッチで使用されている列挙DNSには公開される可能性があるためです。
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.
さらに、攻撃者が攻撃者に侵害されることを、攻撃者が攻撃者を侵害することになった場合、再帰的なリゾルバーの導入装置を処理する場合、攻撃者はコールを強制的に失敗させるか、コールの遅延を引き起こすことができます。したがって、使用される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.
リチャード・ショッケー、ジェイソン・リビングッド、カルステン・フライシュハウアー、ジム・リード、およびオトマル・レンドルのおかげで、この文書の指示を導いたのを手伝い、そしてジェンアートのレビューが非常に役立ったSuresh Krishnanに感謝します。
[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。、「Dynamic Delogation Discovery System（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。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システム（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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、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] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（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] Bradner、S.、Conroy、L。、およびK. Fujiwara、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション」、2008年2月の作業。
[RFC4114] Hollenbeck, S., "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4114, June 2005.
[RFC4114] Hollenbeck、S。、「E.164拡張プロビジョニングプロトコル（EPP）の数値マッピング」、RFC 4114、2005年6月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067] Lind、S。およびP. Pfautz、「インフラストラクチャ列要件」、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 Lim National Internet Development Agency of Korea（NIDA）3F。KTF B/D 1321-11、Seocho-Dong、Seocho-Gu Seoul韓国
Phone: +82-2-2186-4548
EMail: 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
Weon Kim National Internet Development Agency of Korea（NIDA）3F。KTF B/D 1321-11、Seocho-Dong、Seocho-Gu Seoul韓国
Phone: +82-2-2186-4502
EMail: wkim@nida.or.kr
URI: 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 Park National Internet Development Agency of Korea（NIDA）3F。KTF B/D 1321-11、Seocho-Dong、Seocho-Gu Seoul韓国
Phone: +82-2-2186-4504
EMail: ckp@nida.or.kr
URI: http://www.nida.or.kr
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
ローレンスコンロイロークマナーリサーチロークマナーオールドソールズベリーレーンロムジーイギリス
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://www.sienum.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。