Network Working Group J. Lim
Request for Comments: 5346 W. Kim
Category: Informational C. Park
NIDA
L. Conroy
RMRL
October 2008
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.
本文件描述了在2006年韩国国家互联网发展局（NIDA）主持的ENUM预商业试验期间获得的有关两个韩国IP语音（VoIP）运营商之间呼叫路由的基于ENUM的软交换机的操作要求经验和若干注意事项。
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.
这些经验表明，临时解决方案可以在ENUM服务的初始阶段保持正在进行的商业软交换系统操作的稳定性，其中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
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[RFC1034][RFC1035]的映射系统，它使用命名机构指针（NAPTR）[RFC3403]资源记录类型将E.164[E164]号转换为域名。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规范[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年与两家韩国VoIP服务提供商合作进行了基础设施ENUM试验。NIDA是一家非营利组织，其任务是管理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（公共交换电话网）中，基于硬件的交换机占主导地位。软交换提供类似的功能，但通过软件在计算机系统上实现。它通常必须支持各种信令协议（如SIP[RFC3261]、H.323[H323]、媒体网关控制协议（MGCP）[RFC3435]和其他），以便为VoIP服务建立呼叫连接，通常在电路和分组网络之间的边界点上。
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和两个VoIP服务提供商将枚举处理模块构建到他们的软交换机中，通过IP网络将这些模块互连，并将他们的试用用户号码配置到由NIDA操作的集中式枚举DNS系统中。运营商使用可扩展供应协议（EPP）[RFC4114]向集中注册服务器（也由NIDA运营）供应其E.164号码。使用DNS动态更新[RFC2136]实现对枚举数据的更改并立即更新到枚举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)
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:Infrastructure 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的查询。此枚举模块使用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找到它所需的所有呼叫路由信息。为了解决这个问题，基于枚举的软交换必须遵循一组一致的规则。
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.
因此，如果可以通过PSTN“到达”该号码，则不需要将数据（根本）供应到该号码的相关联的ENUM域中，除非还存在服务于该号码的基于IP的互连点并且服务运营商选择使该选项可用。
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，则枚举处理的标准操作可能需要额外的DNS查找，然后才能评估电话号码的NAPTR集。这将带来的延误和不确定性被认为是不可接受的。
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).
第4.1.2节（规则2A，第二点）介绍了存在有效URI的情况。第4.1.2节（规则2b）涵盖了没有为具有活动PSTN互连点的号码设置枚举条目的情况。
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始终提供到相关联的枚举域中。第4.1.2节（规则2A，第二点）对此进行了说明。
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。这确保了对给定（服务中断，“仅枚举”范围）域中的NAPTRs的查询将成功（即，返回0的RCODE），但回答数也将为零。第4.1.2节（规则2A，第一点）对此进行了说明。请注意，这一点还包括这样一种情况，即在这样一个区域中，只有不能用于发起调用的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.
对于“仅枚举”范围，还有一个进一步的政策要求，即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. 软交换的ENUM模块将来自VoIP订户的E.164号码转换为ENUM域名（如RFC 3761中所定义）。
2. The ENUM module, acting as a DNS stub resolver, sends a query to a recursive name server.
2. 枚举模块充当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. 如果枚举模块接收到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.
由确实存在但不包括任何受支持（可路由）NAPTR的枚举域指示。接收到此响应的软交换机将其解释为指示呼叫可以立即断开——如果传递到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.
还必须强调的是，枚举DNS服务器必须响应从软交换机接收到的所有查询。如果软交换机中的枚举模块没有收到响应，它最终将超时，并且枚举模块将把这视为DNS错误。然而，就正常呼叫建立时间而言，所涉及的延迟很长，应该避免。可以修改每个软交换机中的DNS代码，使其超时时间比正常情况更短，以覆盖DNS服务器的错误配置，但在试验中未考虑此选择。除“纯”枚举查找外，软交换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响应具有有效URI，例如SIP或H.323，则软交换可以通过搜索两个不同的源来解析该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.
原则上，这两种方法可以并行使用，但在实践中，如果可以使用基于DNS的方法，就没有必要保留昂贵而复杂的“脱机”基础设施来交换和安装用于域路由的表。在这项试验中，基于枚举的处理的性能和可靠性的不确定性意味着软件标题的配置使得它们可以立即在两种方法之间切换。这只是暂时的权宜之计，从长远来看不是一个合理的办法。
These two types of domain routing are also affected by the Rcode=0 case described in Section 4.1.
这两种类型的域路由也受第4.1节中描述的Rcode=0情况的影响。
There are two choices for routing. These are described and compared here:
路由有两种选择。这里对这些进行了描述和比较：
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的域名部分，软交换可以使用它。
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的域名部分可以通过递归名称服务器解析，则软交换可以使用它。
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）似乎效率低下，因为管理员维护两个数字管理点：枚举DNS和软交换本身。然而，这种配置可以在ENUM的过渡期间（当有相对较少的配置的ENUM条目和如此少的基于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.
有了这些选择，两家运营商可以使用ENUM DNS进行呼叫路由，而不会对其正在进行的商业VoIP服务造成任何影响。
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].
为了提供稳定的商业服务，基于枚举的软交换必须具有定义的性能，就像任何非基于枚举的软交换一样。这两种软交换机之间的唯一区别是呼叫路由信息的搜索机制，它可以存储在软交换机本身或DNS中。因此，呼叫路由的相似延迟时间对于保证服务质量非常重要。在试验期间，各运营商在使用SIP协议时测量了该延迟时间。这是基于“应答延迟时间”，定义为请求呼叫（“邀请”消息）和接收响应（“200确定”消息）之间的经过时间[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 |
+------------------------+------+----------+
+------------------------+------+----------+
| 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在商业基础上肯定能与软交换机配合使用。
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服务时，验证基于ENUM的软交换和基于非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 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.
此外，运营商还质疑基础设施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.
本文档继承了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.
感谢Richard Shockey、Jason Livingood、Karsten Fleischhauer、Jim Reid和Otmar Lendl帮助指导本文件的方向，感谢Suresh Krishnan，他的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）第三部分：域名系统（DNS）数据库”，RFC34032002年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，“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]Hoenesen，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 21361997年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：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，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，“媒体网关控制协议（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）应用程序（ENUM）”，正在进行的工作，2008年2月。
[RFC4114] Hollenbeck, S., "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4114, June 2005.
[RFC4114]Hollenbeck，S.，“可扩展供应协议（EPP）的E.164数字映射”，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
韩国国家互联网发展局（NIDA）3F。韩国首尔Seocho gu Seocho dong KTF B/D 1321-11
Phone: +82-2-2186-4548
EMail: jhlim@nida.or.kr
URI: http://www.nida.or.kr
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
韩国国家互联网发展局（NIDA）3F。韩国首尔Seocho gu Seocho dong KTF B/D 1321-11
Phone: +82-2-2186-4502
EMail: wkim@nida.or.kr
URI: http://www.nida.or.kr
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韩国国家互联网发展局（NIDA）3F。韩国首尔Seocho gu Seocho dong KTF B/D 1321-11
Phone: +82-2-2186-4504
EMail: ckp@nida.or.kr
URI: http://www.nida.or.kr
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
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）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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.