电话系统的下一个行动

从电路交换网络迁移到互联网将成为电话系统有史以来面临的最大挑战。

电话系统现状

世界上大约共有10亿条固定电话线和20亿部移动电话。 大多数电话呼叫仍然通过基于专有软硬件的传统系统来

传送。不过，它们很快将迁移到基于开放协议的网络——这种协议名为基于IP的语音（VoIP）。

去年冬季，英国电信集团公司的首席技术官在伦敦声称，在今后的三到五年间，英国电信要“关掉公共交换电话网络”。

如果这一幕一夜之间在全世界上演，所有这些电话改而连接到互联网上，那么接入连接众多网络的互联网的设备数量就会翻一番，或者增加至三倍，这会给互联网的某些部分带来严重影响。

互联网和电话系统相互融合必须解决信号传送问题: 跟踪记录所有潜在的通信方、设备及服务，并且为每个联系人选择合理的组合。现在有两个技术问题。首先，我们必须通过VoIP把电话系统和互联网合并起来，这股趋势已经出现在许多公司。然后，我们必须加强网络中负责处理跨全世界和互联网传送信号这项任务的那部分，以便它能够承受随之而来的负荷。

传统电话网络和互联网处理信号传送的方式大不相同。语音用户使用传统的电话号码，而互联网则基于域名以及采用数字形式的互联网地址（如81.200.68.193）。即使电话呼叫改为在互联网上传送，语音拨叫方也会希望可以保留电话号码。同时，互联网用户希望只要点击浏览器链接就可以拨打电话。他们还希望能像打电话那样进行通话和互联网聊天会话，并且可以在便携式电脑和PDA上使用视频会话软件。如此一来，VoIP就要同时支持电子邮件和互联网地址。

从许多方面来看，合并这两个不同的庞大系统归结为合并各自的数据库，也就是说可搜索的数据记录集合。几年前，互联网标准机构批准了一种新的数据记录: 电子号码（ENUM），它能够兼顾电话和互联网的原有信息。电子号码将成为架起两种全球性通信网络的桥梁。除了其他优点外，电子号码还能提供一种简单的方法把电话号码转变成互联网地址。

电子号码提供了以一种根本的方式重访互联网设计的机会，从而为我们识别网络设备及使用这些设备的人员提供了基于标准的开放方案。

原理介绍

不过，为了明白电子号码如何把这两个截然不同的世界合为一体，我们需要了解如今的传统电话和互联网是如何处理信号传送的。

传统电话系统被人戏称为POTS（即普通电话服务），它是有着100多年发展历史的产物。在过去的几年间，国际、商业和国家标准方面的共同工作促成了七号信令系统（SS7），它用电子交换节点取代了机电开关。

今天，我们期望电话系统的功能绝不仅仅限于电话呼叫。它还必须提供: 免费电话号码; 可以在紧急情况下确定拨叫方位置的服务（如美国和加拿大的911服务和英国的999服务）; 来电显示服务; 受话人付费电话的自动付费; 阻止电话营销人员的谢绝来电电话目录; 外出时可随身携带号码的功能等等。要支持这些服务，系统就需要数据库节点来管理谁在使用电话、向谁收取电话费等方面的信息。这些数据库由电话运营商拥有，或者由专业公司替运营商维护。

其中一个基本概念就是完全符合标准的电话号码，譬如+1 650 381 6115或者+41 22 730 5111。这是由国际定电信联盟（ITU）的一项标准E.164所定义的。所有的 ITU-T E.164号码长度都不超过15位数字，开头是国家代码，再由各国相应机构根据本国的具体政策进行进一步分配。“+”表示完整的电话号码。

另一方面，互联网使用好几种标识符。最基本的也许就是域名了，提供支持的是域名系统（DNS）的一种高度分布的网络。譬如说，如果你把浏览器指向域名: maps.yahoo.com，你的电脑就会查询你的本地DNS服务器，查找与该域名相关的所有IP地址记录——数字代码表示雅虎网络中的一台台物理机器。另外如果你发电子邮件到本人的信箱，比如 x@x.com，邮件服务器就会索要与发往域名x.com的邮件相关的相应代码（名为MX记录，即邮件交换记录）。

我们比较详细地分析一下后面这种情况。如果你的查询是很常见的查询，那么贵公司的本地网络服务器可能缓存有该查询的答复结果，这样就用不着转发到外面进行查询。另一方面，如果查询结果没有缓存起来，你的服务器就要通过互联网把查询转发到的域名服务器，提示服务器给予答复。用文本表示的这个答复格式如下:

x.com. 3600 IN MX 500 mx1 －above.x.net [Page]

x.com. 3600 IN MX 5 mx2.x.com

x.com. 3600 IN MX 10 mx1.x.com

这三条纪录识别三个不同的邮件服务器; 系统维护两套服务器来提供冗余性，以防主要邮件服务器有可能出故障。每条MX记录含有邮件服务器的域名和优先值，优先值则明确了使用服务器的次序，从优先值最低的（这里是5）开始。

域名服务器是如何找到x的域名呢? 互联网域名从右到左来解释，从域名的后缀: .com、.org、.arpa、.uk等开始解释。如果本地服务器在寻找有关maps.yahoo.com的信息，要是没有缓存信息，就会查询遍布全球的13台根服务器当中的一台，查找拥有关于.com地址信息的域名服务器的身份和地址。然后，服务器会把查询重定向至yahoo.com 域名服务器，最后返回maps.yahoo.com数字形式的正确地址。

互联网使用域名来创建容易记住的统一资源定位符（URL）和统一资源标识符（URI），譬如http://www.x.com和ftp://x.com。第一个是网页所用的常见的超文本传输协议; 第二种是众所周知的文件传输协议。会话初始化协议（SIP）可以设置其功能与电话呼叫一样的音频流。

电子号码的作用

那么，电子号码有什么用武之地呢？它的基本工作原理就是，拿来电话号码，在数字之间插入点号，把随后得到的数字串进行翻转，以便符合域名的全球特有（即从右到左）的格式。随之得到的号码进入DNS里面的单一全球电话号码目录，在e164.arpa下面。.arpa顶级域被限制于数据库查询。

譬如说，全球惟一的电话号码: +1 650 381 6115成为全球惟一的域名: 5.1.1.6.1.8.3.0.5.6.1.e164.arpa。

电子号码标准明确规定使用这种资源记录: 名称权威指针资源纪录（NAPTR），这种记录可以对比32位值多得多的信息进行编码。它借助算法规则来做到这一点，返回给请求者后，算法规则可以用来计算定制的答复。

电子号码是一种国际标准带代码。下面以英国的电话号码+44 1632960083为例，数据来自域名3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa:

NAPTR 10 101 "u" "E2.U+email:mailto ""!^.*$! mailto:info@example.com!" .

NAPTR 10 102 "u" "E2.U+sms:tel""!^.*$!tel:+441632960083!" .

NAPTR 10 100 "u" "E2.U+sip" "!^.*$!sip@example.com!" .

这里的关键变量在于mailto、tel和sip所占的空间。这些元素分别指电子邮件应用软件、POTS和互联网工程任务组的信令协议: SIP。所以这些数据库语句可以告诉任何查询网络: 可以通过SIP、通过发送电子邮件到info@example.com，或者通过传统电话，联系上拥有上述电话号码的客户。

与一个号码有关的多条NAPTR 纪录可以为使用众多设备（包括移动电话、PDA、传真机和语音消息传送系统）以及使用单一设备联系用户提供复杂的优先级。譬如说，单单移动电话可用于语音、语音邮件、即时消息传送、文本消息传送和电子邮件，而每种通信方式对于电话何时打开或者关闭都有不同规则。有人可能甚至希望同时传送采用几种格式的多份消息。

当然，电子号码纪录本身具有的灵活性恰恰也会让它成为容易被人滥用的对象，如电子邮件形式的垃圾邮件、即时消息形式的垃圾邮件甚至乌七八糟的垃圾电话，随着语音电话向互联网迁移，这种滥用现象势必会司空见惯。与这种侵入有很大不同的是这种威胁: 外面的人可能试图获得专有信息，譬如某家公司的客户或者厂商的联系号码。

由于这些原因，通信提供商可能会决定把NAPTR资源纪录放在e164.arpa域以外的安全域，这样一来，只有拥有权限的设备才能访问专有的电子号码。如果运营商希望能彼此之间交换电子号码数据，还可以为它们在这两个域之间提供一定的访问功能，从而利用成本最低的方法通过互联网转发电话呼叫。我们把这种电子号码称为对等基础设施电子号码（Peered Infrastructure ENUM）。

DNS的软肋

那么，互联网能够处理这一负荷吗？答案是肯定的。首先，“管道”（即互联网骨干网当中的光缆）本身足够宽; 让这些管道更宽的新技术也总是在层出不穷。不过有一个地方值得注意。

系统的另一个部分: DNS并不如许多人想象得那么健壮。首先，融合世界需要比如今的DNS系统大得多的存储量。与如今存储IP地址的4个字节相比，NAPTR 纪录会更庞大，通常需要几十个字节。另外，有些服务器需要跟踪数亿个域名，而如今跟踪的条目一般只有几千个。就连最庞大的.com数据库现在也只有4000万个域名。 [Page]

其次，答复DNS查询需要时间，而迄今为止，这种所谓的延迟被人忽视，这是因为它对电子邮件来说关系不大，网页显示过程中一般也可以忍受。长达几十秒钟的延迟并不罕见。然而，电话拨叫方却希望延迟在半秒钟以内。

尤其是在公开的电子号码试验项目中，用户希望浏览及更改自己的联系信息，并希望这种更改能即刻进行。譬如说，电话进入Wi-Fi接入点的覆盖范围后，通常会自动进行这种更改。如今的DNS服务器有许多需要更新复杂、冗长的内容。它们根本无法满足这些要求。此外，DNS服务器需要在进行更新的同时，不断答复查询。的确，配置和提供往往需要互联网服务提供商让DNS服务器处于离线状态，至少暂时处于离线状态。人们不会容忍电话服务出现这种停用。简而言之，如今的DNS服务器无法解决电子号码会带来的难题。

碰到的问题

为了评估电子号码的作用，需要研究电话公司通常使用的多个DNS服务器实现版本: 来自互联网系统协会的BIND版本9.3.0、Daniel J. Bernstein 的DJBDNS、PowerDNS 的PowerDNS以及Nominum的权威域名服务器（ANS）。

其中的两个——PowerDNS 和DJBDNS不支持DNS的最新安全协议，也不能动态更新，因而不管在什么情况下，都不适合使用电子号码。在对其他DNS服务器进行最初测试时，试图把2亿条NAPTR记录加载到32位服务器上，每个服务器配备了2GB的主内存，这是它们所能使用的最大内存的一半。只有ANS能够装载这么庞大的数据，于是减少到5000万条记录，然后减少到1000万条，以获得多个软件程序的测试结果。这种规模下，最流行的DNS 软件——BIND每秒只能答复143次查询。DJBDNS每秒可答复6992次查询; ANS每秒可以答复45135次查询。虽然没有衡量成功的绝对标准，但显而易见，如果我们想看到VoIP方面有同样的结果，就需要不断降低DNS操作的成本。

为什么BIND表现如此之差呢？原因主要在于，虽然它在处理有三个标号（label）的域名如www.ieee.org方面表现不俗，但在处理电子号码域名时却束手无策。由于域名中的每个数字都用点号分隔开来，电子号码域名至少有几十个标号。同样，说到动态更新，BIND每秒只能更新69次，而ANS每秒可以更新467次。

测试表明，电子号码部署需要作一些必要的改进: 如果每个号码的电子号码数据增加到10条或者20条NAPTR记录，而不是测试当中的每个域名一条NAPTR记录;或者如果使用新的安全协议——DNSSEC，给查询增加大笔开销，部署的电子号码可能无法胜任。使用现有的DNS服务器，电子号码的配置及管理很麻烦。用另一种协议替换DNS协议不是问题，问题在于重新设计协议在网络中的实现方式。如果继续使用内存中的数据库、采用内存方面有限制的32位处理器，有2亿条记录的服务提供商需要安装数量多达20倍的服务器。就算使用64位机器，也面临其他难题，譬如更新速度和查询速度的合理平衡。

如果不正视这些问题，互联网用户可能会面临成本更高、服务质量降低、呼叫连接延迟、呼叫丢失。用户都希望能够拨打电话号码，不用操心受话方拥有哪种服务。需要用经受了电子号码大容量、不断变化的负荷考验的软件来对域名系统进行升级。只有增强了这些DNS功能，我们才能满足电子号码及其他新的网络技术的要求。