基于关于pstn呼叫的知识的节点声誉的制作方法

专利名称：：基于关于pstn呼叫的知识的节点声誉的制作方法
技术领域：
：本公开总地涉及互联网协议语音(VoiceoverInternetProtocol，VoIP)，具体而言涉及VoIP地址发现。
背景技术：
：互联网协议语音(VoIP)系统管理在互联网上对语音信息的递送。VoIP涉及用离散的分组以数字形式发送语音信息，而不是使用公共交换电话网(PSTN)的传统的基于电路的协议。VoIP也被称为IP电话、互联网电话、宽带电话以及宽带语音。使用VoIP的一个主要优点在于VoIP避免了普通电话服务提供商所收取的费用。这样，VoIP系统在企业内正变得越来越常见。VoIP呼叫可涉及信令会话和媒体会话。信令可以利用诸如会话发起协议(SIP)、H.323协议或任何其他适当的信令协议之类的各种协议来实现。SIP是用于创建、修改和终止与一个或多个参与者之间的媒体会话的应用层控制(信令)协议。这些媒体会话可包括互联网电话呼叫、多媒体分发和多媒体会议。通常，呼叫代理为VoIP客户端处理VoIP呼叫路由。呼叫代理通常利用目的地电话号码来发出VoIP呼叫。这个号码可能与同一呼叫代理上的客户端相关联，在此情况下呼叫被直接发送到该客户端。作为替换或附加，该号码可能与和同一企业内的另一代理相关联的客户端相关联。在此情况下，呼叫代理可以利用所配置的定义如何路由呼叫的规则来向该代理发送呼叫。当企业内的用户与企业外的用户通信时，呼叫可在PSTN网关上被端接并被路由到PSTN。然而，这样就消除了VoIP的许多益处。在企业或企业群组之间，两个呼叫代理可以通过IP直接与彼此连接，而不需要PSTN。这两个呼叫代理中的一个或两个可以被配置以另一呼叫代理的地址，以便发起这些呼叫代理之间的信令会话。然而，获得呼叫代理的地址可能是麻烦的。组件和附图不一定是按比例的，而重点在于图示出示例。另外，在附图中，相似的标号在所有不同的视图中标示对应的部件。图1示出了互联网协议语音(VoIP)和公共交换电话网(PSTN)系统中的示例性组件；图2出于教导目的示出了一硬件系统，其可用于实现互联网协议专用交换分机(IP-PBX)或呼叫代理或呼叫管理器功能的其他主机；图3示出了在发源呼叫代理处实现的与在VoIP呼叫路由信息的注册表中查找地址块相关联的示例性过程流程；图4示出了在发源呼叫代理处实现的响应于呼叫发起消息而判定是发出PSTN还是VoIP呼叫的示例性过程流程；图5示出了在目的地呼叫代理处响应于接收到PSTN呼叫而实现的示例性过程流程；图6示出了在发源呼叫代理处实现的与核实目的地呼叫代理相关联的示例性过程流程；图7A和7B示出了在发源呼叫代理处实现的与在PSTN呼叫期间核实目的地呼叫代理相关联的示例性过程流程；图8是在目的地呼叫代理处实现的与核实呼叫发起消息中的主叫者ID相关联的一个实施例的操作的流程图；图9示出了将确证服务与呼叫代理的服务分离的系统的示例；图10示出了基于节点之间的信任关系来确证呼叫代理的系统的示例；图11示出了存储在注册表中的信任关系信息的示例性结构；并且图12示出了确定从进行确证的节点到目标节点的信任关系的方法的一个实施例。具体实施例方式概述作为介绍，以下描述的示例性实施例包括用于基于信任关系信息来确定与目标节点的目标信任关系的系统，编码在计算机可读介质中的用于确定与目标节点的目标信任关系的逻辑，以及用于基于目标信任关系来确证(确认证实)目标节点针对一电话号码的身份的方法。根据第一方面，该系统可提供针对一电话号码的信任关系信息，其中该信任关系信息指示出是否至少一个节点认为目标节点包括用于该电话号码的VoIP呼叫代理或者与用于该电话号码的VoIP呼叫代理相关联。该至少一个节点可以基于所展示的关于至少一个PSTN呼叫的知识来认为目标节点是上述那样的。系统基于信任关系信息来确定与目标节点的目标信任关系。目标信任关系可以指示出进行确证的节点对目标节点与用于该电话号码的VoIP呼叫代理相关联或者包括用于该电话号码的VoIP呼叫代理这一事项所具有的信任的级别，其中进行确证的节点和该至少一个节点分别在网络的不同管理域中。在第二方面中，编码在计算机可读介质中的逻辑可生成针对一电话号码的信任关系信息，其中该信任关系信息包括对如下情况的指示即，至少一个节点认为目标节点包括用于该电话号码的VoIP呼叫代理或者与用于该电话号码的VoIP呼叫代理相关联。该至少一个节点可以基于所展示的关于至少一个PSTN呼叫的知识来认为目标节点是上述那样的。该逻辑可以根据信任关系信息来确定与目标节点的目标信任关系。目标信任关系可以指示出进行确证的节点信任目标节点与用于该电话号码的VoIP呼叫代理相关联或者包括用于该电话号码的VoIP呼叫代理的程度，其中进行确证的节点和该至少一个节点在不同管理域中。在第三方面中，提供了一种方法。可以提供针对一电话号码的信任关系信息的至少一部分，其中该信任关系信息指示出至少一个节点基于关于至少一个PSTN呼叫的知识而认为目标节点包括用于该电话号码的VoIP呼叫代理或者与用于该电话号码的VoIP呼叫代理相关联。可以基于目标信任关系来确证目标节点针对该电话号码的身份，其中目标信任关系是根据信任关系信息来确定的。目标信任关系可以指示出进行确证的节点对目标节点与用于该电话号码的VoIP呼叫代理相关联或者包括用于该电话号码的VoIP呼叫代理这一事项所具有的信任的级别，其中进行确证的节点和该至少一个节点分别在第一管理域和第二管理域中。示例性实施例在PSTN系统中协助实现呼叫代理之间的经由公共的基于分组的通信网络的VoIP呼叫的交换和安全性。呼叫代理可以使用PSTN系统来核实另一呼叫代理对一电话号码的拥有权。PSTN系统可以协助形成呼叫代理的声誉。呼叫代理可使用另一呼叫代理的声誉来核实该另一呼叫代理拥有该电话号码。如下文中更详细描述的，在一种实现方式中，声称拥有一个或多个电话号码的呼叫代理可以利用包含与呼叫代理的网络地址相关联的电话号码和/或前缀的地址块来修改VoIP呼叫路由信息的注册表。此注册表可以被多个呼叫代理通过网络访问。注册表可以被维护在中央仓库中或分布式系统中，例如对等(P2P)网络中，其中每个呼叫代理是可操作来与其他对端交换VoIP呼叫路由信息的对端。注册表可包括基于哈希的访问机制，以针对对VoIP呼叫路由信息的不受约束的访问进行保护。基于哈希的访问机制可以基于加密哈希函数。加密哈希函数可以是一个确定性的过程，其取得任意一块数据并且返回固定长度的比特串，即(加密)哈希值，以使得对数据的意外或故意改变将会改变该哈希值。加密哈希函数的一个属性在于根据该哈希值来计算该任意一块数据在计算上是昂贵或不可行的。用于针对对VoIP呼叫路由信息的不受约束的访问进行保护的基于哈希的访问机制可以利用加密哈希函数的这个属性。例如，不是注册表的每个条目包括在不加密的情况下存储的电话号码或前缀(或电话号码块)，而是该条目可包括每个电话号码或前缀的经哈希的值。为了在注册表中创建条目，呼叫代理可以对每一个其声称的电话号码和前缀进行哈希操作并将每一个放入注册表中。类似地，发源(主叫)呼叫代理响应于标识出目的地电话号码的呼叫发起消息，可以通过对目的地电话号码进行哈希操作并且在注册表中查找目的地电话号码来确定目的地呼叫代理的IP地址。在一种实现方式中，发源呼叫代理搜索注册表以寻找匹配条目，其中匹配条目将包含与目的地呼叫代理相对应的IP地址。如下文中更详细描述的，发源呼叫代理可以有目的地电话号码，而注册表中的哈希可以是覆盖该目的地电话号码的前缀。从而，在一种实现方式中，如果对于哈希的目的地电话号码没有匹配的条目，则发源呼叫代理可以剥除该号码的最末数字，对剥除后的号码进行哈希，并且执行另一搜索。发源呼叫代理可以重复此过程，直到找到匹配为止或者直到剩余数字的数目达到预定的阈值数目为止。然而，仅仅使用注册表可能对于系统的安全操作是不够的。要解决的主要挑战是要确信注册表中的条目是正确的。特别地，应当核实将一个条目或一系列条目写入注册表中的呼叫代理确实是这些号码的“拥有者”。这里，“拥有权”意味着这样一个属性，即，如果呼叫实际通过PSTN被路由，则呼叫将到达那个代理或者同一企业内的代理。如下文中更详细描述的，在一种实现方式中，发源呼叫代理可以通过对声称拥有一电话号码的目的地呼叫代理发出PSTN呼叫，来确证该电话号码的拥有权。两个呼叫代理都记录该PSTN呼叫的属性。PSTN呼叫属性例如可包括开始时间、结束时间(如果有的话)、呼叫长度、主叫者ID以及呼叫的其他属性。在呼叫期间或在呼叫之后，发源呼叫代理通过IP向目的地呼叫代理发送对PSTN呼叫属性的请求。如果目的地呼叫代理未接收到该PSTN呼叫，则目的地呼叫代理将不能访问这些属性。因此，如果目的地呼叫代理能够向发源呼叫代理提供这些属性，则目的地呼叫代理可以展示对目的地号码的拥有权。取决于目的地呼叫代理是否成功响应，发源呼叫代理可以应用适当的策略(例如，将与经核实的呼叫代理相关联的数据存储在缓存中以便例如将来的呼叫可以立即通过VoIP连接，继续PSTN呼叫，等等)。如下文中更详细描述的，在一种实现方式中，目的地呼叫代理可以通过对照缓存或对照注册表确证发源呼叫代理，来核实在由发源呼叫代理发送的VoIP呼叫信令消息中提供的主叫者标识(ID)。在一种实现方式中，目的地呼叫代理还可以通过向发源呼叫代理所提供的主叫者ID中提供的号码发出PSTN呼叫来核实该主叫者ID，其中两个呼叫代理都记录PSTN呼叫属性。在呼叫期间或在呼叫之后，目的地呼叫代理可以通过IP向发源呼叫代理发送对PSTN呼叫属性的请求。取决于发源呼叫代理是否成功响应该请求，发源呼叫代理可以应用适当的策略。例如，对于经核实的呼叫代理，发源呼叫代理可以显示该主叫者ID或者允许呼叫继续进行。如下文中还将更详细描述的，在一种实现方式中，可以使对VoIP路由的确证与呼叫代理分离。作为对呼叫代理的取代或附加，确证服务器可以确证电话号码的拥有权或以其他方式与注册表通信。确证服务器和呼叫代理可以利用确证访问协议(VAP)来通信。利用VAP，呼叫代理可以向确证服务器发送PSTN呼叫属性。在确证VoIP路由之后，确证服务器可以利用VAP将经确证的VoIP路由发送给呼叫代理以便存储在缓存中。当判定是通过VoIP网络还是通过PSTN向目的地电话号码发起呼叫时，呼叫代理可以搜索缓存以寻找与目的地电话号码相匹配的相应的经确证的路由。如果呼叫代理找到相应的经确证的路由，则呼叫代理可以通过VoIP网络发起呼叫。如果呼叫代理未能找到相应的经确证的路由，则呼叫代理可以通过PSTN来发起呼叫。如下文中还将更详细描述的，可以基于节点的声誉来核实该节点对电话号码的拥有权，其中节点包括呼叫代理和/或确证服务器。节点的声誉可以基于是否一个或多个其他节点基于所展示的关于至少一个PSTN呼叫的知识而针对该电话号码确证了该节点。节点的声誉还可以基于进行确证的节点和确证了节点拥有该电话号码的一个或多个其他节点之间的至少一个信任关系或信任关系链。例如，域b.com中的呼叫代理可能需要确证域c.com中的呼叫代理。如果域b.com中的呼叫代理信任域a.com中的呼叫代理并且域a.com中的呼叫代理已经确证了域c.com中的呼叫代理，则域b.com中的呼叫代理可以将域c.com中的呼叫代理视为已确证的，而无需域b.com中的呼叫代理向域c.com中的呼叫代理发出PSTN呼叫。PSTN确证图1示出了一种示例性网络环境，其包括支持互联网协议语音(VoIP)网络的分组交换通信网络和公共交换电话网(PSTN)系统。在一个实施例中，该系统包括企业网络20a、20b、20c和20d，它们可操作地耦合到公共互联网22。企业网络20a、20b、20c和20d包括各8自的呼叫代理24a、24b、24c和24d，这些呼叫代理还可操作地耦合到PSTN网络26。企业网络20a、20b、20c和20d中的每一个还通过各个企业网络可操作地耦合到一个或多个客户端28a-28h。呼叫代理24可以是任何被配置为接收呼叫控制协议消息的组件。作为替换或附力口，呼叫代理24可以是任何被配置为发送呼叫控制协议消息的组件。VoIP呼叫代理可以是任何被配置为接收VoIP呼叫控制协议消息的呼叫代理24。作为替换或附加，VoIP呼叫代理可以是任何被配置为发送VoIP呼叫控制协议消息的呼叫代理24。VoIP呼叫控制协议的示例包括会话发起协议(SIP)、H.323协议或任何其他适当的信令协议。在一种实现方式中，呼叫代理24可以是容宿着呼叫管理器应用(例如CiscoCallManager(CCM))的IP-PBX或者任何容宿着VoIP呼叫管理器功能的节点。在另一实现方式中，呼叫代理24可以是IP到IP网关，例如连接到现有的TDMPBX、IPPBX或其他语音或IP语音设备的会话边界控制器(SBC)或背靠背用户代理(B2BUA)。在另一实现方式中，呼叫代理24可以是在IP网络20的边缘处或边缘附近的防火墙或边界路由器。在另一实现方式中，呼叫代理24可以是软交换机。在一种实现方式中，呼叫代理24可以执行以下描述的处理，包括针对访问VoIP呼叫路由信息的注册表、发出和接收PSTN和VoIP呼叫以及核实其他呼叫代理的功能。在特定的实现方式中，呼叫代理24可能具有媒体网关功能。在一种实现方式中，客户端28可以是可操作地连接到网络或直接连接到呼叫代理24的电话。作为替换或附加，客户端28可以是VoIP客户端。当在IP-PBX上实现时，呼叫代理24可以在本地线路上在VoIP客户端28之间交换呼叫，同时允许所有VoIP客户端28共享一定数目的外部PSTN网络电话线路。呼叫代理24还可以在VoIP用户和传统的电话用户之间交换呼叫，或者就像传统的PBX那样在两个传统的电话用户之间交换呼叫。在特定的实现方式中，呼叫代理24可操作来通过公共互联网22连接，以形成P2P网络，以便维护VoIP呼叫路由信息的分布式注册表。在另一实现方式中，呼叫代理24都访问集中式或层次结构化的共同存储库，例如数据库域名系统(DNS)服务器，以便存储和访问VoIP呼叫路由信息的注册表。在一种实现方式中，每个呼叫代理24可操作以维护和访问缓存，其中该缓存可以是存在于呼叫代理24中的本地缓存，或者可以在P2P网络的呼叫代理24外部，但可以被其访问。如下所述，本地缓存包含经确证的VoIP呼叫路由信息。每个呼叫代理24还可操作以访问VoIP呼叫路由信息的注册表。给定的呼叫代理24可以访问其缓存或注册表以存储或查找其他呼叫代理的VoIP呼叫路由信息以便发出VoIP呼叫，以及核实其他呼叫代理。PSTN26是电路交换网络，包括全世界的公共电路交换电话网络的全部或一个子集。PSTN可包括部分固定线路模拟电话系统，以及部分数字电话系统，以及移动电话系统。利用PSTN26的一个优点在于PSTN26可以操作地连接世界上的许多企业，这些企业具有PSTN连通性并且可能具有主叫者ID和连接方ID。图2出于教导目的示出了硬件系统200，其可用于实现呼叫代理主机，例如互联网协议专用交换分机(IP-PBX)。在一种实现方式中，硬件系统200包括处理器202、缓存存储器204以及针对这里描述的功能的一个或多个软件应用和驱动器。此外，硬件系统200包括高性能输入/输出(I/O)总线206和标准I/O总线208。主机桥210将处理器202耦合到高性能I/O总线206，而I/O总线桥212将两条总线206和208相互耦合。系统存储器214和一个或多个网络/通信接口216耦合到总线206。硬件系统200还可包括视频存储器(未示出)以及耦合到视频存储器的显示设备。大容量存储装置218和I/O端口220耦合到总线208。硬件系统200可以可选地包括耦合到总线208的键盘和点选设备(未示出)。总地来说，这些元件意欲代表广泛的一类计算机硬件系统，包括但不限于基于由加州SantaClara的英特尔公司制造的Pentium处理器以及任何其他适当的处理器的通用计算机系统。下面更详细描述硬件系统200的元件。具体地，网络接口216提供硬件系统200与诸如以太网(例如IEEE802.3)网络等等之类的许多种网络中的任何一种之间的通信。大容量存储装置218为数据和编程指令提供持久存储以执行在系统控制器中实现的上述功能，而系统存储器214(例如DRAM)在数据和程序指令被处理器202执行时对其提供临时存储。I/O端口220是提供可耦合到硬件系统200的额外外围设备之间的通信的一个或多个串行和/或并行通信端口。硬件系统200可包括多种系统体系结构，并且硬件系统200的各种组件可被重新布置。例如，缓存204可以与处理器202—起在片上。或者，缓存204和处理器202可以被封装在一起作为“处理器模块”，其中处理器202被称为“处理器核”。另外，某些实现方式可能不需要也不包括上述组件的全部。例如，被示为耦合到标准I/O总线208的外围设备可以耦合到高性能I/O总线206。此外，在一些实现方式中，可存在单条总线，其中硬件系统200的组件耦合到该单条总线。另外，硬件系统200可包括额外的组件，例如额外的处理器、存储设备或存储器。如上所述，在一个实施例中，这里描述的网关或呼叫管理器的操作被实现为由硬件系统200运行的一系列软件例程。这些软件例程包括要被硬件系统中的处理器(例如处理器202)执行的多个或一系列指令。最初，该一系列指令被存储在诸如大容量存储装置218之类的存储设备上。然而，该一系列指令可被存储在诸如盘、⑶_R0M、R0M等等之类的任何适当的存储介质上。另外，该一系列指令不需要被存储在本地，而可以是经由网络/通信接口216从诸如网络上的服务器之类的远程存储设备接收的。这些指令被从诸如大容量存储装置218之类的存储设备拷贝到存储器214中并且被处理器202所访问和执行。操作系统管理和控制硬件系统200的操作，包括向软件应用(未示出)输入数据以及从其输出数据。操作系统提供在系统上执行的软件应用与系统的硬件组件之间的接口。根据一个实施例，操作系统是可从华盛顿州的Redmond的微软公司获得的Windows95/98/NT/XP操作系统。然而，其他实施例也可结合诸如可从加州Cupertino的苹果电脑公司获得的AppleMacintosh操作系统、UNIX操作系统、LINUX操作系统等等之类的其他适当的操作系统使用。在一个实施例中，在一个或多个呼叫代理24可访问的注册表中维护VοIP呼叫路由信息。在一种实现方式中，注册表可以是可发现的并且公共可访问的。在一个实施例中，VoIP呼叫路由信息可包括一组条目，其中每个条目包括一电话号码或代表某一范围的电话号码的前缀(或一组电话号码或前缀)。例如，给定的企业可拥有电话号码+1-408-876-5432以及电话号码+1-973-952-5000至+1-973-952-5999的地址块。这样，该企业的呼叫代理24可以创建两个条目并且将为每个条目注册一映射，该映射将其身份与号码或前缀关联起来。在一种实现方式中，映射的关键字是号码或号码的前缀，仅包括数字。在以上示例中，一个关键字将是14088765432，另一个将是19739525。这样，在一种实现方式中，每个呼叫代理可以通过将前缀视为号码并将前缀输入在注册表中，来注册每个呼叫代理拥有的电话号码块。身份信息可包括网络地址(例如，IP地址、端口号码、主机名等等)或标识呼叫代理的任何其他类型的信息。在一个实施例中，参与P2P网络可能要求呼叫代理具有与网络中的其他节点的预定最小数目的(例如，数十个)TCP连接。这些连接可以是动态建立的，其中通过P2P协议来获知对端。在一种实现方式中，注册到P2P网络中可包括运行一算法来选择如下的对端对于该对端，应当发生写入操作。该对端进而又将该写入传递到另一对端，依此类推。这使得数据被存储并分布在参与P2P网络的呼叫代理上。如上所述，VoIP呼叫路由信息的注册表可包括进行保护以对抗对注册表的不受约束的访问的基于哈希的机制。即，注册表条目中的电话号码或前缀是经哈希的值。为了将一条目存储在注册表中，呼叫代理可以首先对其相关联的电话号码或前缀进行哈希操作，然后将经哈希的值与其身份相关联地存储在注册表中。呼叫代理可以利用诸如MDA和SHAl之类的任何适当的哈希算法来对电话号码或前缀进行哈希操作。一般来说，应当使用强哈希函数来确保经哈希的值对于给定的电话号码或前缀是唯一的。通过对前缀或电话号码进行哈希操作，给定的呼叫代理可以以安全的方式来宣告号码块。例如，对经哈希的电话号码或前缀的使用防止了电话推销者、垃圾发送者和垃圾网络电话发送者(垃圾VoIP电话发送者)从注册表中简单地收集电话号码。用户将需要首先知道正确的电话号码，然后才能尝试成功地搜索注册表以寻找VoIP呼叫路由信息。否则，如果要通过反复地选择电话号码或前缀、计算哈希值并且对照注册表查找该哈希值来尝试获知注册表中维护的大量VoIP呼叫路由信息，则在计算上将是昂贵的(因为计算哈希所需的计算资源)。从拓扑上来说，可以以多种方式来维护VoIP呼叫路由信息的注册表。在一种实现方式中，可以利用P2P网络来维护注册表。P2P网络可以由系统中的所有或某些呼叫代理构成，或者可以在另一不同的P2P网络中维护注册表，该另一不同P2P网络被系统中的所有呼叫代理所访问。当利用P2P网络时，取决于所使用的P2P协议，P2P网络中的每个节点(其可以是呼叫代理)结果将维护注册表中的信息的子集。可以使用任何适当的P2P协议或技术，包括Chord、CAN、Bamboo、Kademlia，等等。在利用集中式注册表系统的一些实施例中，中央服务器可以维护注册表，其中注册表可以是一个或多个呼叫代理可访问的中央仓库。在一个实施例中，给定的呼叫代理可以发送电话号码或前缀到中央数据存储库，并且中央数据存储库将存储该电话号码或前缀。其他呼叫代理可以查询该中央数据存储库并且检索从电话号码到呼叫代理的身份的映射。在另一实现方式中，中央注册表可以对电话号码或前缀进行哈希操作并且将经哈希的电话号码或前缀存储在注册表中。在利用诸如域名系统(DNS)之类的层次化注册表系统的一些实施例中，给定的呼叫代理可以例如通过利用电话号码映射协议来将电话号码或前缀变换成层次化标识符，所述电话号码映射协议例如是由IETF在RFC2916中定义的电子编号(ENUM)协议。呼叫代理随后可使用此标识符来将VoIP呼叫路由信息写入到层次化系统中的适当位置处。该层次体系中的服务器可以与呼叫代理相同或者不同。如果DNS被用作该层次化系统，则这可以是公共DNS或私有DNS。在一些实施例中，给定的呼叫代理可以在来自发源客户端或发源呼叫代理的呼叫发起消息中接收电话号码，然后使用该电话号码来在注册表中查找VoIP呼叫路由信息。在一个实施例中，该呼叫代理可以搜索注册表以寻找N位目的地号码的N-I个前缀中的每一个。搜索可以基于精确匹配，而不是层次化匹配。换言之，应当找到一个地址块，并且如果找到不止一个地址块，则使用最特定的那一个。假定在注册表中存在匹配条目，则所找到的该号码或号码块的端接呼叫代理的身份(包括目的地呼叫代理的IP地址和端口号码)可以被缓存，以避免将来查询。在注册表存储经哈希的电话号码或前缀的特定实施例中，在呼叫代理上实现的查找过程可执行以下操作以查找VoIP呼叫路由信息。图3示出了在呼叫代理处实现的用于在注册表中查找VoIP呼叫路由信息的示例性过程流程。响应于某个事件(例如接收到标识电话号码的呼叫发起消息)，查找过程计算所标识的电话号码的哈希(302)。查找过程随后访问注册表以判定是否存在匹配条目，或者具体而言，经哈希的电话号码是否与注册表中的任何经哈希的号码相匹配(基于精确串匹配)(304)。如果是，则与匹配条目相对应的VoIP呼叫路由信息被返回(306)并且可能被用于呼叫代理所实现的某个其他过程中。例如，在一个实施例中，与该电话号码相对应的目的地呼叫代理的IP地址可用于路由VoIP呼叫。如果没有匹配条目，则查找过程判定该电话号码是否被剥除到了最小阈值数目的数字(308)。在一个实施例中，该最小阈值可以是数字的预定数目。例如，最小阈值数目可以是1个数字(例如，可能的最小的国家代码)。如果电话号码被剥除到了最小阈值数目的数字，则查找过程返回“未找到”消息(310)。取决于情境，呼叫代理24可以以多种方式来响应此消息。例如，在一种实现方式中，发源呼叫代理可以尝试发出PSTN呼叫或者可以拒绝呼叫，可选地把呼叫拒绝通知给发源客户端并且可选地提供拒绝呼叫的原因。如果目的地电话号码未被剥除到最小阈值数目，则查找过程剥除电话号码的最末数字(312)。发源呼叫代理随后重新计算经修改的电话号码的哈希(314)并且判定重新计算出的经哈希的电话号码是否匹配注册表中的任何经哈希的电话号码(304)。呼叫代理可以继续此过程，直到找到匹配条目为止或者直到目的地电话号码已被剥除到最小阈值数目为止。此过程向系统提供了安全性，因为如果没有合法的电话号码，则该过程要获取电话号码将是计算上昂贵的。在一个实施例中，可以应用策略来检测在滑动时间窗口期间发送了导致大于阈值次数的失败的查询的可疑节点。如下文中更详细描述的，给定的呼叫代理可以使用PSTN的设施来确证注册表中的VoIP呼叫路由信息。例如，呼叫代理可以核实另一呼叫代理可以合法地声称对该呼叫代理写入到注册表中的电话号码的拥有权。这里，“拥有权”可以意味着这样一个属性如果呼叫通过PSTN被发出，则呼叫将被路由到将该条目写入到注册表中的呼叫代理，或者如果未被路由到该呼叫代理，则被路由到受相同管理控制的另一呼叫代理。例如，响应于所标识的电话号码，呼叫代理可以通过PSTN26对该电话号码发出PSTN呼叫。一般地，如果声称对目的地电话号码的拥有权的呼叫代理是真实的，则该呼叫代理将通过PSTN26接收到该PSTN呼叫并从而将有机会记录该PSTN呼叫的一个或多个属性，例如开始时间、结束时间、主叫方标识符等等。PSTN呼叫属性信息可被用作共享的秘密，以使得第一呼叫代理可以确证另一呼叫代理。如下文中更详细描述的，对呼叫代理的核实可以发生在PSTN呼叫期间或之后。在下文中描述的实现方式中，给定的呼叫代理可以把经核实的VoIP呼叫路由信息存储在本地缓存中。响应于标识出目的地电话号码的呼叫发起消息，呼叫代理可以依据在缓存中是否存在与该目的地电话号码相对应的经确证的VoIP呼叫路由信息，来选择性地向给定的目的地电话号码发出PSTN或VoIP呼叫。匹配缓存中的经确证的路由信息一般意味着端接呼叫代理已被核实。发源呼叫代理随后可通过向端接呼叫代理发送呼叫发起消息来发出VoIP呼叫。如果在缓存中没有找到经确证的匹配，但该号码因为对注册表的先前查询而存在于缓存中，则呼叫代理可以发出PSTN呼叫并且确证呼叫代理。如果在缓存中完全没有找到匹配，则呼叫代理除了发出PSTN呼叫以外还可以如上所述在注册表中查询该号码。图4示出了在发源呼叫代理处实现的用于响应于来自主叫节点的呼叫发起消息而选择性地发出PSTN或VoIP呼叫的示例性过程流程。如图4所示，该过程开始于发源呼叫代理(例如，呼叫代理24a)从发源(主叫)节点(例如，客户端28a)接收到诸如SIP邀请之类的呼叫发起消息时(402)。在一个实施例中，呼叫发起消息包括目的地电话号码。发源呼叫代理访问其缓存以判定是否存在匹配的经确证的缓存条目，从而缓存的地址块与该目的地号码相关联，并且目的地号码先前已被确证(404)。如果在缓存中存在匹配的经确证的条目，则发源呼叫代理发出VoIP呼叫，向与本地缓存中的匹配地址块相关联的端接呼叫代理发送信令消息(406)。此信令消息可被直接发送到目的地呼叫代理，或者可通过中间服务器或提供商来发送。如果在缓存中不存在匹配的经确证的地址块，则发源呼叫代理向目的地电话号码发出PSTN呼叫(408)。如图4所示，如果目的地号码完全不在缓存中，则发源呼叫代理还可以利用该电话号码在注册表中查找端接呼叫代理(408)。更具体而言，在一个实施例中，发源呼叫代理可以使用目的地电话号码来在注册表中查找目的地呼叫代理的VoIP呼叫路由信息(参见以上的第C小节)。如果找到匹配条目(412)，则发源呼叫代理可以记录PSTN呼叫的一个或多个属性以用于随后的核实过程中。在所示出的实现方式中，发源呼叫代理在PSTN呼叫结束(416)之后将一个或多个PSTN呼叫属性记录在数据存储库(例如呼出数据库)中(418)，并且将端接呼叫代理添加到核实任务列表(420)。在一种实现方式中，该数据存储库可以是将信息存储一段时间的临时数据存储库，或者该数据存储库可以是具有持久存储的数据库。在另一实现方式中，可以为每个呼叫记录PSTN呼叫属性，然后作为在执行核实任务列表时遵循的过程的一部分可以查询注册表。可以存储多种PSTN呼叫属性。在一种实现方式中，PSTN呼叫属性可包括PSTN呼叫开始时间、PSTN呼叫停止时间、呼叫长度(例如，呼叫持续了多久)、主叫客户端的主叫者ID以及发源VoIP网络可用于核实目的地接收到了PSTN呼叫的任何其他信息。其他PSTN呼叫属性可包括由发源和端接网关计算出的语音数据的签名。例如，呼叫代理可以计算呼叫期间的静默时段的量和开始时间，或者呼叫期间的语音数据的谱签名。其他PSTN呼叫属性可包括发源网关可在呼叫中的某一点期间(例如，就在呼叫即将终止之前)发送的DTMF音调序列。这里描述的实现方式的一个优点在于它们可以结合电话号码使用。另一个优点在于这里描述的实现方式是服务提供商检测不到的。因为企业仍可发出PSTN呼叫，所以这里描述的实现方式可以减少这种PSTN呼叫的量。另外，其他实现方式也是可能的。例如，即使在缓存中找到匹配的VoIP呼叫路由信息，发源呼叫代理(根据某种随机化的或其他的过程)仍可以选择该条目来进行重确证，从而使得呼叫代理发出PSTN呼叫并且将呼叫代理添加到核实列表。此外，呼叫代理可向其缓存应用老化算法以冲刷掉旧的条目。图5示出了在目的地或端接呼叫代理处实现的、用于记录与接收到的PSTN呼叫相关联的一个或多个属性的示例性过程流程。为了允许核实，端接网关可以记录PSTN呼叫的一个或多个属性以便成功地应答来自发源呼叫代理的查询。如图5所示，目的地呼叫代理接收PSTN呼叫(502)，然后将该PSTN呼叫转发到目的地客户端(504)。在呼叫结束后(506)，目的地呼叫代理将PSTN呼叫属性记录在数据存储库(例如呼入数据库)中(508)。在一种实现方式中，该数据存储库可以是将信息存储一段时间的临时数据存储库。前述章节给出了端接呼叫代理可记录的示例性PSTN呼叫属性。如果发源呼叫代理在PSTN呼叫之后执行核实，则取决于具体实现方式发源呼叫代理可在各种时间执行核实。例如，发源呼叫代理可以在PSTN呼叫之后立即执行核实。在其他实现方式中，发源呼叫代理可以在非高峰时段运行的批处理中核实多个目的地呼叫代理。在一种实现方式中，发源呼叫代理可以在呼叫完成之后的随机时间核实目的地呼叫代理。发源呼叫代理可以在发生触发事件时，例如当接收到新的呼叫发起消息时，执行一个或多个核实操作。如下文中更详细描述的，核实可以是基于知识的核实，其中发源呼叫代理就与一个或多个先前的PSTN呼叫相对应的PSTN呼叫属性查询目的地呼叫代理。这些PSTN呼叫属性可以被概念化为只有这两个呼叫代理知道的“共享秘密”。图6示出了在发源呼叫代理处实现的与核实目的地呼叫代理相关联的示例性过程流程。如图6所示，对于核实列表中的每个目的地呼叫代理，发源呼叫代理向该目的地呼叫代理发送对PSTN呼叫属性的查询(602)。该查询可利用从注册表中获知的目的地呼叫代理的IP地址和端口、通过基于分组的通信网络来发送。呼叫代理可以根据多种不同的协议来通信。例如，在一种实现方式中，进行核实的呼叫代理可通过使用目录访问来访问目的地呼叫代理所维护的“呼入”数据库。发源呼叫代理可利用目的地电话号码作为关键字来发送查询，并且端接代理将返回为具有该目的地电话号码的呼叫记录的PSTN属性。为了此目的可以使用任意数目的协议，包括标准数据库和目录协议，例如LDAP和SQL，或者HTTP查询，SOAP查询，或者任何其他适当的用于查询一条数据并获得响应的技术。在替换实现方式中，实际认证协议可用于提高安全性。在此实现方式中，PSTN呼叫属性被映射到用户名和口令，然后传统的认证或登录协议可用于核实数据。例如，用户名可以是PSTN呼叫的目的地号码和开始时间，并且口令可以是PSTN呼叫的停止时间。又例如，用户名可以是呼叫的目的地号码和呼叫中的随机时间，并且口令可以是呼叫的开始和停止时间。又例如，用户名可以是目的地号码和主叫者ID，并且口令可以是呼叫的开始时间和停止时间。在一种实现方式中，PSTN呼叫属性可包括与PSTN呼叫的内容相关联的信息。例如，在给定的PSTN呼叫期间，发源呼叫代理和目的地呼叫代理都可执行静默检测算法来检测静默和说话。VoIP随后可基于检测到的静默和说话模式来生成PSTN呼叫签名或指纹。此指纹或签名可被用作用户名和/或口令的一部分。例如，用户名可以是呼叫的目的地号码和开始时间，并且口令将是该指纹。或者，用户名可以是呼叫的目的地号码和呼叫的前半部分中的签名，而口令将是后半部分中的签名。在一种实现方式中，PSTN呼叫属性可包括呼叫签名或指纹。在一种实现方式中，发源呼叫代理可执行频谱分析或话音识别算法来生成呼叫签名或指纹。在一种实现方式中，发源呼叫代理可在PSTN呼叫结束之前利用两个呼叫代理都记录的双音多频(DTMF)值来发送随机串。呼叫签名或指纹于是可以包括这些DTMF比特。在一种实现方式中，查询可以向目的地呼叫代理提供最低限度信息，例如呼叫开始时间。基于有限的信息，目的地呼叫代理可以确定要提供的适当信息。当发源呼叫代理接收到对PSTN呼叫属性查询的响应时(604)，发源呼叫代理判定PSTN呼叫属性是否得到确认(606)。在一种实现方式中，如果来自目的地呼叫代理的响应中的PSTN呼叫属性与发源呼叫代理存储在“呼出”数据库中的PSTN呼叫属性相匹配，则PSTN呼叫属性得到了确认。在一种实现方式中，当利用认证或登录协议时，如果登录或认证协议成功，则PSTN呼叫属性得到了确认。在一种实现方式中，无需在认证期间从任一呼叫代理发送PSTN呼叫属性，认证协议就可以工作。例如，认证协议可以基于提供零知识口令证明的加密密钥交换(EKE)协议。在一种实现方式中，确证可能由于给定的PSTN呼叫被转发到非法呼叫代理而失败。如果PSTN呼叫属性得到确认，则发源呼叫代理应用针对经核实的目的地呼叫代理的适当策略(608)。例如，发源呼叫代理可以将缓存中针对此号码的条目标记为经确证的，从而随后将对该呼叫代理发出将来的VoIP呼叫，如上所述。即，如果第一次确证了VoIP路由信息，则发源呼叫代理下次将在缓存中找到匹配条目，从而将能够对现在已经核实的呼叫代理发出VoIP呼叫。这样，以后不再需要搜索注册表。另外，进行核实的呼叫代理可以建立与被核实的呼叫代理的连接，以用于VoIP呼叫发起消息的路由。在一种实现方式中，一旦传输控制协议(TCP)/传输层安全性(TLS)连接被建立，发源呼叫代理就可以直接向目的地呼叫代理发送SIP邀请。在一种实现方式中，给定的呼叫代理可以维护最多达预定数目的多个TCP/TLS连接(例如，1000个连接)，在此之后呼叫代理将终止不活动或活动性最低的连接。如果PSTN呼叫属性未得到确认，则发源呼叫代理应用针对未经核实的目的地呼叫代理的适当策略(610)。例如，发源呼叫代理可以将核实失败记录在缓存中，生成警告消息，将该呼叫代理添加到黑名单之类，等等。可以以多种方式来优化核实过程的实现方式。在一种实现方式中，即使在缓存中存储/确证了给定的电话号码或前缀，也可以增强核实以使得发生重核实。例如，在一种实现方式中，发源呼叫代理可以随机选择一些呼叫来重核实目的地呼叫代理仍拥有该特定的电话号码或电话号码块。在一种实现方式中，发源呼叫代理可以重核实预定百分比的呼叫(例如，5%)或者随机数目的呼叫。在另一实现方式中，呼叫代理可以在所配置的一段时间比如一个月之后使确证超时，使得重核实被每月执行一次。在另一种优化中，当块中的特定号码已被核实时，同一块中的其他号码也被认为是经核实的。例如，如果块内的号码A和号码B已被核实，则呼叫代理可以认为该块内的A与B之间的所有号码也被核实了。在一种实现方式中，这个自动的核实可以仅在号码A和B彼此接近时例如在1000个号码以内时才发生。在另一实现方式中，可以基于最近的N个PSTN呼叫来定义共享秘密，从而提高该机制的安全性。在一个实施例中，不是使PSTN呼叫属性基于给定块中的任何两个电话号码之间的最近N个呼叫，而是可以使PSTN呼叫属性基于特定电话号码之间的最近N个呼叫。在一种实现方式中，如果发源呼叫代理可以确证给定地址块的预定数目或预定百分化的电话号码(例如，50个电话号码中的2个，或者4%)，则发源呼叫代理对于将来的呼叫可以接受该地址块的其余电话号码。在一种实现方式中，如果目的地呼叫代理在PSTN呼叫结束之前被核实，则发源呼叫代理可以可选地即使在成功核实的情况下仍允许PSTN呼叫继续。这样，VoIP呼叫可用于呼叫的语音部分(例如，PSTN呼叫)之上的增强特征。例如，发源呼叫代理可以将PSTN呼叫用于语音，并且将VoIP呼叫用于增强的特征，例如视频、声音、存在性、即时消息传递(IM)和/或数据应用。从而，实现方式提供了防止呼叫代理声称对其实际不拥有的电话号码的拥有权的优点。另外，实现方式不要求任何特殊的PSTN配置。图7A和7B示出了在发源呼叫代理处实现的用于在PSTN呼叫期间核实目的地呼叫代理的示例性过程流程。如图7A所示，该过程开始于发源呼叫代理从发源客户端接收到诸如SIP邀请之类的呼叫发起消息时(702)。在一个实施例中，呼叫发起消息包括目的地电话号码。发源呼叫代理访问其缓存以判定是否存在具有与该目的地号码相关联的地址块的经确证的匹配条目(704)。如果是，则发源呼叫代理发出VoIP呼叫(706)。如果在缓存中不存在匹配的经确证的条目，则发源呼叫代理在注册表中查找目的地呼叫代理(708)。如果未找到匹配(710)，则发源呼叫代理发出PSTN呼叫(712)。如果找到匹配(710)，则发源呼叫代理仍发出PSTN呼叫(714)并且还执行以下步骤。发源呼叫代理将PSTN呼叫属性记录在数据存储库(例如呼出数据库)中(716)。如上所述，在一种实现方式中，该数据存储库可以是将信息存储一段时间的临时数据存储库。在一种实现方式中，PSTN呼叫属性可包括PSTN呼叫开始时间、目的地客户端的主叫者ID、语音签名信息(例如谱分析或静默/活动时段)、DTMF、以及发源呼叫代理可用来核实目的地呼叫代理在该PSTN呼叫期间被连接的任何其他信息。参考图7A，在PSTN呼叫仍在进行的同时，发源呼叫代理向目的地VoIP发送对PSTN呼叫属性的查询(718)。在特定的实现方式中，该查询可以请求目的地呼叫代理提供与以上联系图6的步骤602描述的查询类似的信息，只不过PSTN呼叫属性将不包括呼叫停止时间或呼叫长度，因为PSTN呼叫仍在进行中。在一种实现方式中，当目的地呼叫代理接收到PSTN呼叫时，目的地呼叫代理将PSTN呼叫转发到目的地客户端，并且将PSTN呼叫属性记录在数据存储库(例如呼入数据库)中。在接收到对PSTN呼叫属性的查询后，目的地呼叫代理发送响应。当发源呼叫代理接收到对PSTN呼叫属性查询的响应时(720)，发源呼叫代理判定PSTN呼叫属性是否得到确认(722)。如果PSTN呼叫属性得到确认，则发源呼叫代理应用针对经核实的目的地呼叫代理的适当策略(724)。例如，发源呼叫代理可以缓存VoIP呼叫路由信息，从而将来的呼叫可以通过VoIP进行。或者，发源呼叫代理可以将正在进行的PSTN呼叫转移到VoIP呼叫。如果PSTN呼叫属性未得到确认，则发源呼叫代理应用针对未经核实的目的地呼叫代理应用的适当策略(726)。例如，发源呼叫代理可以将核实失败记录在缓存中，生成警告消息，结束呼叫，等等。在一个实施例中，如果攻击者声称其实际不拥有的电话号码，则永远不会有呼叫通过VoIP被发出到该攻击者，因为攻击者的端接呼叫代理将不能够成功地对PSTN呼叫属性查询做出响应，因为PSTN呼叫去到了该电话号码的实际拥有者。在一个实施例中，如果攻击者声称对比其实际拥有的前缀更大的前缀的拥有权，则攻击者最初可能不被检测到，但很可能将被检测到。这是因为可以预期一些呼叫会通过PSTN发出，从而确保了伪造的号码最终会被尝试和检测到。在一种实现方式中，企业可以要求对于任何特定的目的地电话号码发出PSTN呼叫至少一次。虽然这可能导致发出更多PSTN呼叫，但这将消除这种攻击。因为在初始呼叫建立时没有使用注册表，所以任何等待时间对于呼叫建立延迟都没有影响。实际上，使用这里公开的实现方式的呼叫建立时间甚至将比通过PSTN更快，因为发源呼叫代理直接与目的地呼叫代理通信。在许多情况下，甚至不要求传输控制协议(TCP)连接建立，因为这种连接可能已经由于到该端接呼叫代理的先前呼叫而被建立并维持。然而，在另一实现方式中，当PSTN呼叫到达端接呼叫代理时，端接呼叫代理保留该呼叫，而不将该呼叫递送到端接客户端。反而，端接呼叫代理检查来自PSTN呼叫建立消息的主叫者ID，并且就此号码查询注册表。如果找到匹配，则端接呼叫代理进一步保留该呼叫，以期接收到对核实PSTN呼叫属性的请求。一旦此确证成功，发源呼叫代理就可以发出VoIP呼叫，并且端接呼叫代理可以拒绝该PSTN呼叫，而继续进行该VoIP呼叫。这样就无需实际完成PSTN呼叫，但后果是增大了呼叫建立延迟。另外，这里公开的实现方式是能自动防故障的，因为即使当对照缓存或对照注册表核实了目的地呼叫代理时，发源呼叫代理也可以发出PSTN呼叫。换言之，即使给定的发源呼叫代理崩溃并恢复，从而丢失了其缓存，或者注册表以某种方式被损害，或者若干种问题中的任何一种发生，最坏情况也只是仍通过PSTN来路由呼叫。这样，端用户不会遭遇到服务中断。一些P2PVoIP覆盖网络提供商需要提供分发其网络内的用户名和分发证书的集中式服务器。因为这里描述的实现方式利用了已经发给企业的电话号码，所以不需要这种中央服务。如下文中更详细描述的，呼叫代理所维护的缓存以及注册表可用于核实接收到的VoIP呼叫中的主叫者ID信息。例如，当给定的目的地呼叫代理通过基于分组的通信网络接收到具有相关联的包含电话号码的主叫者ID的呼叫发起消息(例如SIP邀请)时，目的地VoIP可以对照呼叫代理的缓存和/或对照公共的注册表来核实该主叫者ID。这提供了两级确证。图8是在目的地呼叫代理处实现的与核实接收到的呼叫建立消息中的主叫者ID相关联的流程图。如图8所示，目的地呼叫代理接收到来自发源呼叫代理的诸如SIP邀请之类的呼叫发起消息(802)。在一种实现方式中，该呼叫发起消息包含主叫者ID。目的地呼叫代理搜索其缓存以寻找匹配条目以判定主叫者ID是否与缓存中的电话号码相匹配以及该号码是否已被核实。如果该号码已被核实，则呼叫代理检查发送呼叫建立请求的实体的身份是否与核实了的呼叫代理的身份相匹配(基于匹配在TLS过程中使用的证书，或者基于匹配IP地址，或者任何其他适当的比较手段)(804)。如果是，则目的地呼叫代理应用针对对照缓存确证的发源呼叫代理的一个或多个策略(806)。例如，在一种实现方式中，目的地呼叫代理可以向目的地客户端的用户指示出发送者(发源呼叫代理)被核实。在一种实现方式中，目的地呼叫代理可以选择性地示出主叫者ID，或者添加指示出有效主叫者ID的符号或字符。在一种实现方式中，目的地呼叫代理可以许可呼叫，等等。如果主叫者ID未被核实，但与缓存中的一号码相匹配，或者主叫者ID不与缓存中的任何号码相匹配，则目的地呼叫代理可以在注册表中寻找匹配条目(808、810)。如果在注册表或缓存中有匹配条目，并且注册表条目中的呼叫代理的身份(可能已被缓存)与发送了呼叫建立请求的代理的身份相匹配(基于匹配在TLS过程中使用的证书，或者基于匹配IP地址，或者任何其他适当的比较手段)，则目的地呼叫代理应用针对被注册表确证的发源呼叫代理的一个或多个策略(812)。与在步骤806中可应用的一个或多个策略类似，在特定的实现方式中，目的地呼叫代理可以向目的地客户端的用户指示出发送者(发源呼叫代理)被核实(并且可选地指示出第二级确证)，可以示出主叫者ID，可以许可呼叫，等等。如果主叫者ID不与注册表中的电话号码相匹配，则目的地呼叫代理应用针对未经确证的发源呼叫代理的一个或多个策略(814)。例如，在一个实施例中，目的地呼叫代理可以向目的地客户端的用户指示出发送者未经核实，或者可以不示出主叫者ID，或者可以拒绝呼叫，等等。因为恶意的呼叫代理可能提供虚假的主叫者ID，所以此过程使得给定的呼叫代理能够向两级核实提供主叫者ID信息。如上所述，VoIP可利用缓存或注册表来对照先前的核实或对照IP地址和端口号码核实主叫者ID，其中的前者是无法伪造的。从而，这里描述的实现方式具有防止主叫者ID欺骗的优点。例如，如果一企业的发源呼叫代理发起与假造的主叫者ID的SIP呼叫，则该假造的主叫者ID可匹配与另一不同企业的呼叫代理相对应的条目。在一种实现方式中，除了对照缓存或对照注册表核实主叫者ID以外，目的地呼叫代理还可以根据以上联系图4、6、7A和7B描述的核实过程来核实发源呼叫代理。这样，使用假造ID的发源呼叫代理将不能够成功地响应于对PSTN呼叫属性的请求。在一个实施例中，发源呼叫代理和目的地呼叫代理可以基于同一呼叫来核实彼此。例如，在一种实现方式中，发源呼叫代理可以向目的地呼叫代理既发出PSTN呼叫也发出VoIP呼叫。当接收到PSTN呼叫时，如果目的地呼叫代理判定主叫者ID对应于网络中的另一呼叫代理，则目的地呼叫代理将该PSTN呼叫保留预定的时间段(例如，几秒钟)。当VoIP呼叫到达时，执行相互认证。换言之，发源呼叫代理和目的地呼叫代理如上所述地核实彼此。如果相互认证成功，则PSTN呼叫被拒绝并且VoIP呼叫继续进行。此方案提供了对P2P网络中宣告的号码块的非常可靠的确证，并且提供了VoIP防垃圾功能。在一种实现方式中，如果发源呼叫代理发出了太多的VoIP呼叫，那么即使发源呼叫代理已被确证，端接呼叫代理也可拒绝来自该呼叫代理的进入VoIP呼叫，并且重定向进入VoIP呼叫以改为利用PSTN。这样就把成本传递给了发源呼叫代理，因此帮助了减轻VoIP垃圾。另外，因为此技术使用电话号码，所以该技术可以使得垃圾发送者难以改变标识符。在电子邮件中改变标识符是便宜且容易的，因为域和域内的用户ID几乎是免费且无限供应的。对于电话号码则不是如此，电话号码更昂贵并且是有限的资源。另外，因为使用电话号码，所以可以通过发送垃圾的企业的服务提供商来回追到这种企业。黑名单也变得有效得多，因为电话号码的名称空间有限。在一种实现方式中，可以使对VoIP路由的确证与呼叫代理分离。确证服务器-取代呼叫代理-可以确证电话号码的拥有权或者以其他方式与注册表通信。该分离可导致(1)不再使用呼叫代理连接到P2P网络；(2)将呼叫代理与关于如何获知VoIP路由的细节隔离开来；(3)消除了在外出呼叫的建立期间对确证服务器的使用；并且(4)确证服务器可以为多个呼叫代理获知VoIP路由。不再需要呼叫代理连接到P2P网络这一点可能是可取的。管理员在一些情况下可能不愿意允许呼叫代理连接到P2P网络。呼叫代理可能被管理员认为是关键基础设施。连接到P2P网络可能会要求呼叫代理处理后台P2P流量。此外，在P2P网络上发送和接收的流量可能被加密。与VoIP流量不同，防火墙和/或会话边界控制器可能不能监视经加密的P2P网络流量。确证服务器的分离图9示出了将确证服务与呼叫代理24的服务分离的系统100的示例。系统100可包括确证服务器102、呼叫代理24、防火墙104以及呼叫代理24的客户端28。系统100可包括不同的、更少的或更多的组件。例如，系统100可不包括防火墙104。在一个示例中，系统100可以只包括确证服务器102。在第二示例中，系统100可包括多个呼叫代理24。在第三示例中，注册表108可被存储在P2P网络中，该注册表108可以被维护在确证服务器102中、其他确证服务器中、其他呼叫代理中或其任何组合中。或者，系统100可包括作为集中式仓库的注册表108，例如电话号码映射(ENUM)服务器。确证服务器102可包括一个或多个进程，用于确证VoIP路由和与注册表108通信。在一个示例中，确证服务器102可包括处理器110和存储器112。在另一不同的示例中，确证服务器102可以是软件，而没有硬件。存储器112可以是任何现在已知的或者以后开发出的数据存储设备。存储器112可以是非易失性和/或易失性存储器，例如随机访问存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)或者闪存。存储器112可包括光的、磁的(硬盘驱动器)或任何其他形式的数据存储设备。处理器110可以与存储器112通信。处理器110也可以与诸如显示器之类的另外的组件通信。处理器Iio可以是通用处理器、中央处理单元、服务器、专用集成电路(ASIC)、数字信号处理器、现场可编程门阵列(FPGA)、数字电路、模拟电路、或其组合。处理器110可以是可操作以执行包含在存储器112或其他存储器中的计算机可执行指令或计算机代码以确证VoIP路由的一个或多个设备。呼叫代理24可以与确证服务器102通信。呼叫代理24还可以与PSTN26和互联网22通信。此外，呼叫代理24可以与客户端28通信。除了确证服务器102与呼叫代理24通信以外，确证服务器102还可以通过互联网22与注册表108通信。防火墙104可以在互联网22与确证服务器102之间和/或在互联网22与呼叫代理24之间。在系统100的操作期间，确证服务器102可以执行确证服务并与注册表108通信。例如，确证服务器102可以利用P2P协议或任何其他用于与注册表108通信的适当协议来与注册表108通信。确证服务器102还可以利用认证协议与VoIP代理通信，以针对某一电话号码或针对某一范围的电话号码来确证VoIP代理。当注册表108被实现为P2P网络时，确证服务器102可以执行P2P功能。例如，确证服务器可以基于确证服务器102中包括的P2P注册表数据118的一部分中包括的指针表(fingertable)来路由P2P消息。确证服务器102和呼叫代理24可以利用确证访问协议(VAP)来通信。VAP可以是任何用于在确证服务器102和呼叫代理24之间传达信息以协助将确证服务与呼叫代理24的服务分离的协议。例如，呼叫代理24可以使用VAP来把呼叫代理24对其声称拥有权的电话号码告知确证服务器102。在一个示例中，呼叫代理24可以以包括直接拨入(DID)信息的XML文档的形式把所拥有的电话号码114发送给确证服务器102。确证服务器102可以将所拥有的电话号码114的至少一部分存储在存储器112中。例如，所拥有的电话号码114的该部分可包括由前缀标识的某一范围的电话号码。作为替换或附加，呼叫代理24可以要求确证服务器102把所拥有的电话号码114的一部分放入注册表108中，而不将它们存储在确证服务器102中。作为替换或附加，可以由用户输入而不是从呼叫代理24接收被存储在确证服务器102的存储器112中的所拥有的电话号码114。确证服务器102还可以将所拥有的电话号码114或所拥有的电话号码114的一部分存储在注册表108中。当注册表108被实现为P2P网络时，P2P注册表数据118的该部分可以被存储在确证服务器102的存储器112中。通过将所拥有的电话号码存储在注册表108中，确证服务器102可以宣告呼叫代理24拥有这些电话号码。通过将所拥有的电话号码114发送给确证服务器102，呼叫代理24无需直接连接到P2P网络就可以控制哪些电话号码被存储在注册表108中。此外，确证服务器102可以为不止一个呼叫代理24宣告所拥有的电话号码114。呼叫代理24可以使用VAP来告知确证服务器其何时发出和/或接收PSTN呼叫。例如，呼叫代理24可以针对外出和进入的PSTN呼叫将呼叫属性发送给确证服务器102。呼叫代理24可以指示出该呼叫是外出PSTN呼叫还是进入PSTN呼叫。确证服务器102可以把从呼叫代理24接收的呼叫属性116存储在确证服务器102的存储器112中。确证服务器102可以使用PSTN呼叫的呼叫属性116来核实呼叫代理对于某些电话号码或某些范围的电话号码是有效的呼叫代理。针对电话核实呼叫代理的过程可以是以上描述的用于核实呼叫代理的过程中的任何一个。为了针对电话号码核实呼叫代理是有效呼叫代理，确证服务器102可以与注册表108和呼叫代理通信。为了与注册表108通信，确证服务器102可以使用任何适当的注册表协议，例如P2P协议。例如，确证服务器102可以利用基于哈希的前缀匹配来就一目的地呼叫代理查询注册表108。确证服务器102可以利用以上所述的认证协议之一来与呼叫代理通信。例如，确证服务器102可以向作为查询注册表108的结果而找到的呼叫代理发起TLS连接。确证服务器102可以生成、交换和存储在认证期间使用的口令，以针对目的地电话核实呼叫代理。在一个示例中，确证服务器102可以与要核实的呼叫代理所使用的另一不同的确证服务器通信，而不是直接与呼叫代理通信。在一个示例中，确证服务器102可以在从呼叫代理24接收到针对目的地电话号码的呼叫属性之后立即针对该目的地电话号码发现和核实呼叫代理。在另一不同的示例中，确证服务器102在接收到呼叫属性之后可以等待随机量的时间，然后才针对目的地电话号码发现和核实呼叫代理。在一个示例中，确证服务器102可以周期性地核实目的地号码。在确证服务器102基于呼叫属性116针对电话号码核实呼叫代理之一后，确证服务器102获知了新的VoIP路由。VoIP路由可以将目的地电话号码映射到呼叫代理。作为替换或附加，VoIP路由可以将诸如目的地电话号码的一部分之类的前缀映射到呼叫代理。在一个示例中，VoIP路由可包括目的地电话号码和该目的地电话号码所映射到的呼叫代理的网络地址。确证服务器102可以将新的VoIP路由通过VAP发送给呼叫代理24。呼叫代理24可存储新的VoIP路由以用于随后发起到目的地电话号码的VoIP呼叫。确证服务器102、呼叫代理24或者两者可以存储在发起到呼叫代理的新呼叫时使用的确证信息，例如用户名和口令。在一个示例中，确证服务器102在向呼叫代理24发送新VoIP路由时可以将确证信息发送给呼叫代理24。作为替换或附加，作为发起到新VoIP路由中标识的呼叫代理的新呼叫的一部分，呼叫代理24可以向确证服务器102发送对确证信息的请求。在一个示例中，确证信息可包括由新VoIP路由中标识的呼叫代理发出的票证。在接收到有效VoIP路由后，呼叫代理24可以将该路由存储在有效VoIP路由120的缓存中。有效VoIP路由120的缓存可以被包括在呼叫代理24中或被存储在与呼叫代理24分离的数据库中。多个呼叫代理24可以访问存储在该数据库中的有效VoIP路由120的缓存。在一个示例中，多个呼叫代理24可以共享共同的确证服务器102。作为替换或附加，确证服务器102可以将有效VoIP路由120存储在数据库中，而不是利用VAP将有效VoIP路由120发送给呼叫代理24。在一个示例中，呼叫代理24可以周期性地向确证服务器102发送对有效VoIP路由120的请求。作为替换或附加，如果存在多个呼叫代理24，则确证服务器102可以将VoIP路由发送给所有呼叫代理24。呼叫代理24可以接收来自客户端28之一的呼叫发起消息，其中该呼叫发起消息标识目的地电话号码。当呼叫代理24接收到呼叫发起消息时，呼叫代理24可以搜索有效VoIP路由120以寻找与该目的地电话号码匹配的VoIP路由。如果呼叫代理24找到匹配的VoIP路由，则呼叫代理24可以基于匹配的VoIP路由来发起VoIP呼叫，而不是发起PSTN呼叫。然而，如果呼叫代理24没有找到匹配的VoIP路由，则呼叫代理24可以发起PSTN呼口H。在一个示例中，在接收到来自客户端28之一的呼叫发起消息后，呼叫代理24可以向确证服务器102发送对与目的地电话号码相对应的有效VoIP路由的请求。如果确证服务器102返回有效VoIP路由，则呼叫代理24可以向有效VoIP路由中标识的呼叫代理发起呼叫。否则，确证服务器102可以通过PSTN26发起呼叫。在一种实现方式中，呼叫代理24可以判定目的地电话号码是与呼叫代理24相关联的企业内部的电话号码还是该企业外部的电话号码。企业外部的电话号码可通过PSTN26和/或互联网22来到达。如果目的地电话号码是企业内部的，则呼叫代理24可以相应的路由呼叫，而避免向确证服务器102发出请求。呼叫代理24可以接收来自互联网22上的发源呼叫代理的呼叫发起消息。在一种实现方式中，呼叫代理24可以向确证服务器102发送对确证该呼叫发起消息的请求。例如，呼叫代理24可以将该呼叫发起消息中包括的口令和呼叫信息发送给确证服务器102以便确证。确证服务器102可以向呼叫代理24发回响应，指示出呼叫发起消息是否有效。确证服务器102可以在呼叫发起消息无效的情况下拒绝呼叫，并在其他情况下接受呼叫发起消息。在一种实现方式中，呼叫代理24可以在没有确证服务器102的情况下确证呼叫发起消息。在一种实现方式中，呼叫代理24可以在没有呼叫确证的情况下接受该消息。呼叫代理24可以周期性地冲刷或去除有效VoIP路由120。例如，从确证服务器102接收的VoIP路由120中的每一个可具有到期日期。呼叫代理24可以从有效VoIP路由的缓存中去除或不使用任何到期的VoIP路由120。在一个示例中，防火墙104可以向确证服务器102发送对确证从互联网22上的发源呼叫代理接收的呼叫发起消息的请求。如果确证服务器102指示出该消息无效，则防火墙104可被配置为不将该消息转发到呼叫代理24。作为替换或附加，呼叫代理24可在不向确证服务器102发送请求的情况下确证呼叫发起消息。VAP可以基于互联网协议或任何其他适当的协议。在一个示例中，VAP可以基于传输控制协议/互联网协议(TCP/IP)或TCP/TLS。VAP可包括编程式接口，用于以下事项中的至少一种(1)传达呼叫代理24的所拥有的电话号码114，(2)传达呼叫属性116，(3)传达有效VoIP路由120，以及(4)核实呼叫发起消息中包括的口令。作为替换或附加，VAP可以基于进程间通信(IPC)协议，例如具名管道、匿名管道、公共对象请求代理体系结构(CORBA)、简单对象访问协议(SOAP)、分布式组件对象模型(DCOM)、或者任何其他远程过程调用(RPC)协议。VAP可包括连接池、连接保活和/或用于维护和/或优化确证服务器102与呼叫代理24之间的连通性的其他特征。确证服务器102和呼叫代理24之间功能的分离可以使得在建立新呼叫时不需要确证服务器102。反而，确证服务器102可用于获知新的有效VoIP路由并且将有效VoIP路由发送给呼叫代理24供以后使用。声誉系统如下所述，确证服务器102和/或呼叫代理24可以避免向一电话号码发出任何PSTN呼叫，而仍核实宣称对该电话号码的拥有权的节点的身份。确证服务器102和/或呼叫代理24可以基于确证服务器102和/或呼叫代理24信任声称已核实了该电话号码的宣称拥有者的身份的一个或多个节点的程度，来核实该电话号码的宣称拥有者的身份。例如，确证服务器102和/或呼叫代理24可以基于声誉系统来确定确证服务器102和/或呼叫代理24信任该一个或多个节点的程度。图10示出了基于节点1010、1020、1030和1040之间的信任关系1050、1052、1054、1060、1062、1070和1072来确证呼叫代理24的系统1000的示例。系统1000可包括节点1010,1020,1030和1040以及节点之间的信任关系1050、1052、1054、1060、1062、1070和1072。系统1000可包括额外的、更少的或不同的组件。例如，系统1000可包括注册表108，其中节点1010、1020、1030和1040与注册表108通信。节点1010、1020、1030和1040中的每一个可以是可确证另一节点的身份的设备、在设备上执行的进程、或者其任何组合。节点1010、1020、1030和1040的示例包括确证服务器102、呼叫代理24、一管理域中的多个确证服务器、一管理域中的多个呼叫代理、及其任何组合。在一个示例中，节点1010、1020、1030和1040中的任何一个可包括对等网络的成员。在第二示例中，节点1010、1020、1030和1040中的任何一个可以通过集中式的基于服务器的网络来与呼叫代理24通信，其中注册表108是集中式服务器。在图10中，节点1010、1020、1030和1040分别是单独标示的节点A、节点B、节点C和节点D。节点A1010、节点C1030和节点D1040分别拥有电话号码Y、X和Z。管理域指的是管理性自治、权力和/或控制的领域。例如，在互联网中，域名可以标识特定的管理域。节点1010、1020、1030和1040中的任何两个或更多个之间的信任关系1050、1052、1054、1060、1062、1070和1072中的每一个指示出节点1010、1020、1030和1040中的一个节点信任其他节点1010、1020、1030和1040中的至少一个节点的程度。信任关系1050、1052、1054、1060、1062、1070和1072中的任何一个可以是从第一节点到第二节点的。在额外的示例中，信任关系中的任何一个可以是从第一节点到多个节点的、是第一节点与第二节点之间双向的、或者第一节点与多个节点之间双向的。信任关系1050、1052、1054、1060、1062、1070和1072中的每一个可以包括量化信任水平的信任级别。例如，信任关系1050、1052、1054、1060、1062、1070和1072中的每一个可包括至少两个信任级别之一“信任_确证”和“不信任_确证”。“信任_确证”表明作为关于先前PSTN呼叫的知识的证明的结果，节点1010、1020、1030和1040中的一个已确证了其他节点1010、1020、1030和1040中的一个确实拥有特定的电话号码。相反，“不信任-确证”表明节点1010、1020、1030和1040之一基于与处于信任关系的节点1010、1020、1030和1040之一的先前PSTN呼叫而在对照电话号码的确证中失败。因此，“信任-确证”和“不信任_确证”关系可针对个体电话号码或电话号码前缀而存在。在一对节点之间，可能存在具有不同级别的多个信任关系。例如，节点A针对电话号码X可“信任_确证”节点C，但节点A针对电话号码Y则可认为节点C是“不信任_确证”的。作为替换或附加，信任关系1050、1052、1054、1060、1062、1070和1072的每一个中的信任水平可被量化成多于两个不同的信任级别。节点1010、1020、1030和1040可将信任关系1050、1052、1054、1060、1062、1070和1072存储在注册表108中。作为替换或附加，节点1010、1020、1030和1040可将信任关系1050、1052、1054、1060、1062、1070和1072存储在相应的节点1010、1020、1030和1040中。例如，节点1010、1020、1030和1040可以将信任关系1050、1052、1054、1060、1062、1070和1072的一部分存储在注册表108中，并且将信任关系1050、1052、1054、1060、1062、1070和1072中的其余部分存储在节点1010、1020、1030和1040之中的建立了信任关系1050、1052、1054、1060、1062、1070和1072之中的相应信任关系的相应节点中。节点A1010可以将表明节点A1010由于PSTN确证而信任节点C1030的信任关系存储在注册表108中。PSTN确证可以是基于所展示的关于至少一个PSTN呼叫的知识而对电话号码的拥有者的身份的确证。所存储的关于信任关系的信息可包括电话号码X的加密哈希值、节点A1010的身份、以及节点C1030的身份。节点1010、1020、1030和1040之一的身份的示例包括网络地址、域名、对等节点标识符、节点所拥有的电话号码、任何其他类型的标识符、及其加密哈希。在操作期间，节点1010、1020、1030和1040可以利用任意数目的机制来建立信任关系1050、1052、1054、1060、1062、1070和1072。一个这种机制可包括以上所述的PSTN确证机制中的任何一种。例如，节点A1010可能先前已通过PSTN呼叫了节点C1030所拥有的电话号码X。从而，节点A1010可以基于节点C1030提供关于被发起到电话号码X的PSTN呼叫的知识的证明，来针对电话号码X确证节点C1030的身份。在接收到关于PSTN呼叫的知识的证明之后，节点A1010现在可以信任节点C1030为电话号码X的拥有者。这个关系被称为针对电话号码X的“信任-确证”。从而，节点A1010基于PSTN确证，针对电话号码X建立了从节点A1010到节点C1030的信任关系1060。或者，节点A1010可以基于确证的失败而针对电话号码X不信任节点C1030。在一个示例中，注册表108中或别处的信任关系信息可以表明节点1010、1020、1030和1040中的哪一个信任特定的节点是特定的电话号码的拥有者。当这些节点中的任何一个利用PSTN确证针对特定电话号码确证了目标节点时，该节点可将相应的信任关系存储在注册表108中。从而，进行确证的节点，例如节点B1020，可以搜索注册表108中的信任关系信息以判定其他节点1020、1030和1040中的任何一个是否针对特定电话号码确证了特定节点。例如，节点B1020可能尚未针对电话号码X确证节点C1030。节点B1020可能尚未通过PSTN来呼叫电话号码X。然而，节点B1020可以查询注册表108以判定其他节点1020,1030和1040中的任何一个是否已针对电话号码X确证了节点C1030。在以上示例中，对注册表108的查询将返回表明节点A1010因为PSTN确证而针对电话号码X信任节点C1030的信任关系信息。除了“信任-确证”关系以外，节点可能与另一节点有“信任-包揽”(trust-blanket)关系。在此关系中，一个节点(例如节点A)信任如果另一节点(例如节点B)针对电话号码X与第三节点(例如节点C)有“信任-确证”关系，则节点A将认为节点C是电话号码X的合法拥有者。这进而又创建了节点A与节点C之间的另一信任关系，“信任_代理确证”。与“信任_确证”关系一样，这个信任关系是针对特定电话号码的，并且该信任关系表明一个节点信任另一节点是该电话号码的合法拥有者。然而，“信任-代理确证”关系不是基于对号码的直接确证来构建此信任的，而是因为该节点通过包揽信任关系或通过其他机制(例如以下所述的声誉机制)而确定了另一节点是该电话号码的合法拥有者。在一个示例中，“信任_包揽”关系可以基于管理性配设，因为“信任_包揽”关系基于这样一个信念即，信任的对象在操作一个合法的、未受损害的系统。例如，节点A的管理者可能认识节点D的管理员，并且认为可以信任节点D的管理员能够适当地操作节点D。在该情况下，节点A的管理者可以创建节点A与节点D之间的“信任-包揽”关系1062。作为替换或附加，节点1010、1020、1030和1040可以在某种其他基础上形成“信任-包揽”关系。例如，节点B1020可以通过基于节点A1010提供关于从节点B1020发起到电话号码Y的PSTN呼叫的知识的证明来针对电话号码Y确证节点A1010的身份，从而来创建与节点A1010的“信任-包揽”关系1050。节点B1020对节点A1010的PSTN确证可以提供对节点A1010的高到足以创建“信任-包揽”关系的信任级别。如果节点B1020与节点A有“信任-包揽”关系1050，则节点B1020可以基于两个信任关系1050和1060来认为节点C1030是电话号码X的拥有者，而无需节点B1020通过PSTN来呼叫电话号码X。从而，确证服务器102可以针对电话号码X在节点B1020与节点C1030之间创建“信任-代理确证”关系。作为替换或附加，从进行确证的节点到一个节点的信任_确证关系以及从该一个节点到目标节点的信任-确证关系，可能就足以创建从进行确证的节点到目标节点的信任-代理确证关系。例如，节点B1020可能已经通过基于节点A1010提供关于从节点B1020发起到电话号码Y的PSTN呼叫的知识的证明来针对电话号码Y确证节点A1010的身份，从而创建了与节点A1010的信任-确证关系1050。节点B1020对节点A1010的PSTN确证可以提供对节点A1010的信任，该信任的级别高到足以信任节点B1020对节点C1030拥有电话号码X的断言。因为对目标节点的信任的级别可以取决于其他节点关于目标节点断言了什么，所以基于信任关系1050、1052、1054、1060、1062、1070和1072来确证呼叫代理24的系统1000还可包括基于各种信任关系1050、1052、1054、1060、1062、1070和1072来确定节点1010、1020,1030和1040中的任何一个的声誉的系统。从而，建立信任关系1050、1052、1054、1060、1062、1070和1072中的任何一个的一种机制可以基于节点1010、1020、1030和1040中的任何一个的声誉。目标节点的声誉可以基于来自多个节点的断言。例如，节点B1020可以等待，直到不同管理域中的所确定数目的节点1010、1020、1030和1040断言了节点C是电话号码X的拥有者为止。断言了节点C是电话号码X的拥有者的节点可以被称为断言节点。在图10所示的示例中，节点A1010和节点D1040是断言了节点C是电话号码X的拥有者的节点。节点B1020可能没有与断言了节点C是电话号码X的拥有者的断言节点的任何个体信任关系，例如“信任_包揽”关系。然而，仅仅许多节点都与节点C1030有“信任-确证”关系这个事实就可以使得节点B1020信任节点C1030确实是电话号码X的拥有者。换言之-由与节点C1030有“信任-确证”关系的其他节点的数目来衡量的节点C1030针对电话号码X的声誉可以被另一节点例如节点B1020用于针对电话号码X创建与节点C1030的“信任-代理确证”关系。节点C的声誉可以随着群组中断言了信任节点C是电话号码X的拥有者的节点的数目增大而增大。作为替换或附加，可以组合各种信任关系，以做出关于某一节点针对特定电话号码与另一节点是否有“信任-代理确证”关系的判定。例如，节点B1020可以与节点A1010有“信任-包揽”关系1050。节点A1010可能与节点C1030有“信任-确证”关系1060。然而，节点B不是与节点C创建“信任-代理确证”关系，而是可以基于节点C针对特定电话号码是否有最低声誉来创建该关系。在一个示例中，此最低值可以低于当节点B与断言节点中的任何一个都没有“信任_包揽”关系时节点B为了与节点C建立“信任_代理确证”关系而要求节点C有的声誉。作为替换或附加，现在已知的或以后开发的用于确定网络中的节点的声誉的任何其他基于声誉的机制可用于确定信任关系1050、1052、1054、1060、1062、1070和1072中的至少一个。例如，节点的声誉可以基于与该节点的“信任_确证”和“不信任_确证”关系的更复杂组合。在一个示例中，“不信任-确证”关系的权重可以更重，以使得发生了一些确证失败的节点必须付出更多的努力来提高其声誉。在第二示例中，可以使用在确证过程的外部形成的声誉。如果特定节点的域名已知，则可以从追踪互联网垃圾发送者的服务(例如Spamhaus)获得该域名作为垃圾邮件发送者的声誉。节点的域名的声誉可用于访问节点在系统中的声誉以基于各种信任关系1050、1052、1054、1060、1062、1070和1072来确定节点1010、1020、1030和1040中任何一个的声誉。作为另一示例，节点针对电话号码X的声誉可以基于该节点针对一个或多个其他电话号码的声誉。例如，如果节点C1030被节点A1010和节点D1040两者针对十个电话号码“信任_确证”，并且节点C1030未被任何节点针对这十个电话号码“不信任_确证”，则节点B1020可以基于节点C1030已针对其他号码被信任这一事实来针对新的第11个号码与节点C1030创建“信任-代理确证”关系。“信任-代理确证”关系的创建还可取决于新号码与已经确证的其他十个号码的邻近度。例如，针对新的电话号码的“信任_代理确证”关系的创建可以限于与先前确证的号码在同一地理区域中的新号码，或者与先前确证的号码在数值上邻近或在数值上接近的新号码。任何节点所拥有的电话号码可包括完全限定的电话号码或者前缀。如上所述，前缀指示出某一范围的电话号码。在一个示例中，信任关系1050、1052、1054、1060、1062、1070和1072中的任何一个可以限于相应的单个电话号码或某一范围的电话号码。在第二示例中，信任关系1050、1052、1054、1060、1062、1070和1072中的任何一个可以对任何电话号码有效。在一个示例中，节点A1010与节点C1030之间的“信任-确证”关系1060可以限于电话号码X或者如果电话号码X是前缀则限于某一范围的电话号码。然而，节点B1020与节点A1010之间的“信任-包揽”关系1050可以表明节点B1020针对节点B1020所做的另一节点拥有特定电话号码(可能基于一组前缀)的断言的子集而信任节点A1010。作为替换或附加，节点B1020与节点A1010之间的“信任-包揽”关系1050可以将节点B对节点A的关于节点A拥有什么号码的任何断言的信任限于与对电话号码Y的拥有权有关的断言的信任。图11示出了存储在注册表108中的信任关系信息1110的存储结构1100的示例。存储结构1100可包括一组主关键字-值对，主关键字-值对的每一个包括主关键字(key)1120和对应主值(value)1130。在一个示例中，主关键字1120可以是进行确证的节点针对其确证了目标节点的那个电话号码。在第二示例中，主关键字1120可以是进行确证的节点针对其确证了目标节点的那个电话号码的加密哈希。在一个示例中，对应主值1130可包括与系统100中的不同节点1010、1020、1030和1040进行的确证相对应的一组关键字-值对。每个关键字_值对可包括关键字1140和值1150。关键字1140可包括进行确证的节点的标识符。值1150可包括被确证了的目标节点的标识符。在第二示例中，对应主值1130可包括标识进行确证的节点的节点标识符的列表。进行确证的节点或目标节点的标识符例如可包括网络域名、网络地址、通用资源定位符(URL)、对端标识符、或者分布式系统中的任何其他类型的标识符。在操作期间，当进行确证的节点针对特定电话号码确证目标节点时，进行确证的节点可以将相应的信任关系信息1110发送到注册表108以便存储。例如，当节点A1010针对电话号码X确证了节点C1030时，节点A1010可将相应的信任关系信息1110发送到注册表108。例如，进行确证的节点可以执行在注册表108中实现的命令write(number，vnode,tnode)，其中number是所确证的电话号码，vnode是进行确证的节点的身份，并且tnode是目标节点的身份。当进行确证的节点发送针对目标节点和特定电话号码的信任关系信息1110时，注册表108可以搜索注册表108以判定在注册表108中是否已经存在一主关键字-值对，其中该主关键字-值对具有与该特定电话号码相匹配的主关键字1120。如果不存在这样的主关键字-值对，则注册表108可以为该电话号码创建主关键字-值对。注册表108可以将针对由进行确证的节点执行的确证的信任关系信息1110添加到主值1130中已经包括的信任关系信息1110中的任何一个中。例如，当节点A1010针对电话号码X确证节点C1030时，注册表108可以将节点A1010的标识符和节点C的标识符分别添加作为关键字1140和值1150。当进行确证的节点要基于现有的信任关系来针对特定电话号码确证目标节点时，进行确证的节点可以检索出注册表108中针对该特定电话号码的所有信任关系信息1110。例如，当节点B1020针对电话号码X确证节点C1030时，节点B1020可以检索出注册表108中针对电话号码X的所有信任关系信息1110。在图10所示的示例中，针对电话号码X的信任关系信息1110可包括由节点A1010和节点D1040添加的信任关系信息1110。在一个示例中，进行确证的节点可以执行在注册表108中实现的命令read(number)，其中number是要确证的特定电话号码。命令read(number)可以返回针对该号码的所有信任关系信息1110。在一个示例中，进行确证的节点可以仅在其执行PSTN确证时才将信任关系信息1110存储在注册表108中。换言之，只有“不信任-确证”和/或“信任-确证”关系才被存储在注册表中。在第二示例中，进行确证的节点可以在对目标节点的任何确证被执行时将信任关系信息1110存储在注册表108中。换言之，“信任代理-确证”信息也可被存储在注册表中。例如，每当进行确证的节点基于PSTN确证来确证了目标节点或者每当进行确证的节点基于信任关系1050、1052、1054、1060、1062、1070和1072中现有的一个而确证了目标节点时，进行确证的节点就可以将信任关系信息1110存储在注册表108中。例如，当节点B1020基于节点C与节点A1010的信任关系1050和节点A与节点C1030的信任关系1060而针对电话号码X确证了节点C1030时，节点B1020可以将信任关系信息1110发送到注册表108。注册表108可以阻止对从进行存储的节点接收的信任关系信息1110的存储。例如，注册表108可以在将进行存储的节点的身份存储在关键字1140之前，要求进行存储的节点给出有效公钥证书，作为对进行存储的节点的身份的证明。如果进行存储的节点未能给出针对进行存储的节点的有效公钥，则注册表108可以阻止存储表明进行存储的节点断言目标节点拥有特定号码的信任关系信息1110。如果新的进行确证的节点针对特定号码可获得在信任关系信息1110中标识的目标节点的身份，则系统100可提供的匿名性很低。然而，系统100可以提供额外程度的匿名性。例如，不是将进行确证的节点和目标节点的标识符存储在信任关系信息1110中，而是进行确证的节点可以存储进行确证的节点的标识符，而不存储目标节点的标识符。作为替换或附加，即使两者都被存储在注册表中，呼叫代理24也可以在被要求提供信任关系信息1110时返回进行确证的节点的标识符而不返回目标节点的标识符。在一个示例中，为了使新的进行确证的节点确定进行确证的节点针对特定电话号码确证的目标节点的身份，进行确证的节点必须与新的进行确证的节点有信任关系并且该信任关系必须足够强。例如，为了使得新的进行确证的节点确定由进行确证的节点确证的目标节点的身份，新的进行确证的节点可与存储了信任关系信息1110的注册表108和/或进行确证的节点通信以便检索出由进行确证的节点确证的目标节点的身份。进行确证的节点在与新的进行确证的节点的信任关系足够强的情况下可以将目标节点的身份发送给新的进行确证的节点。例如，进行确证的节点可以要求新的进行确证的节点展示关于到进行确证的节点拥有的电话号码的PSTN呼叫的知识的证明。作为替换或附加，进行确证的节点可以要求新的进行确证的节点被包括在进行确证的节点所信任的一组节点中。注册表108可以周期性地去除针对特定电话号码的信任关系信息1110。在一个示例中，注册表108可以删除已被存储了长于阈值长度的时间的信任关系信息1110。在第二示例中，如果足够数目的节点1010、1020、1030和1040指示出针对特定电话号码的信任关系信息1110无效，则该信任关系信息1110可被去除。节点1010、1020、1030和1040之一可因为执行对目标节点的后续PSTN确证并且该后续PSTN确证失败，而确定“信任-确证”关系信息1110无效。如果节点数目超过了阈值，则可确定节点数目充足。多个目标节点可以针对一个电话号码被合法确证并被包括在信任关系信息1110中。例如，如果各自位于不同的地理区域中的两个不同的进行确证的节点通过PSTN拨叫同一号码，则这些进行确证的节点中的每一个可到达不同的呼叫代理。例如，从美国拨叫2563470和从德国拨叫2563470可能到达不同的目的地。出于相同的原因，注册表108中的VoIP呼叫路由信息也可合法地标识多个呼叫代理拥有同一电话号码。在一个示例中，为了解决多地理区域问题，进行确证的节点可以以包括国家代码的完全限定的E.164格式来发送要存储在信任关系信息1110中的电话号码。此外，存储在注册表108中的用于VoIP呼叫路由信息的电话号码可以以包括国家代码的完全限定的格式来存储。在第二示例中，进行确证的节点可以将对信任关系1050、1052、1054、1060、1062、1070和1072的考虑限制到与在同一主叫区域中的节点1010、1020、1030和1040的信任关系。信任关系信息1110的存储结构1100可以是不同于图11所示的示例的任何适当的结构。例如，信任关系信息1110可以在关系数据库中跨表格存储。图12示出了确定从进行确证的节点到目标节点的信任关系的方法的一个实施例。可以执行额外的、不同的或更少的动作。可以按与图12所示不同的顺序来执行这些动作。在图12所示的实施例的动作1210中，操作可通过提供针对一电话号码的信任关系信息1110的至少一部分而开始。信任关系信息1110可以表明至少一个节点基于关于至少一个PSTN呼叫的知识而认为目标节点包括用于该电话号码的呼叫代理24或与用于该电话号码的呼叫代理24相关联。在一个示例中，信任关系信息1110的该部分可不包括目标节点的身份。操作可通过基于目标信任关系针对电话号码确证目标节点的身份而在动作1220中继续。例如，目标信任关系可以是信任-确证关系。目标信任关系是从信任关系信息1110的至少一部分确定的。目标信任关系可以指示出进行确证的节点对于目标节点与用于该电话号码的呼叫代理24相关联或者包括用于该电话号码的呼叫代理24这一事项所具有的信任级别，其中进行确证的节点和该至少一个节点分别在第一管理域和第二管理域中。在一个示例中，操作可以通过将目标信任关系存储在注册表中而结束。在第二示例中，操作可包括基于进行确证的节点对目标节点所具有的信任的级别超过了阈值级别而将VoIP呼叫路由到VoIP呼叫代理。到目标节点的第一呼叫可以通过PSTN。然而，到目标节点的后续呼叫，即使是来自不同节点的，也可以被作为VoIP呼叫来路由。尽管如此，到目标节点的第一呼叫仍然可以确保仍执行了对电话号码的拥有权的某种确证。以上所述的实施例是示例，因此其他实施例是可能的。例如，虽然以上所述的实施例已被描述为结合P2P网络和PSTN网络工作，但是其他实施例也可结合任何适当的网络环境使用。不同的组件提供用于实现各种实施例的功能的不同功能。用于实现以上所述的过程、方法和/或技术的各个逻辑、软件或指令是在计算机可读存储介质或存储器或其他有形介质上提供的，所述其他有形介质例如是缓存、缓冲器、RAM、可移除介质、硬盘驱动器、其他计算机可读存储介质、或者任何其他有形介质或其任何组合。有形介质包括各种类型的易失性和非易失性存储介质。附图中示出或这里描述的功能、动作或任务是响应于存储在计算机可读存储介质中或上的一组或多组逻辑或指令而被执行的。这些功能、动作或任务独立于特定类型的指令集、存储介质、处理器或处理策略，并且可以由单独或组合操作的软件、硬件、集成电路、固件、微代码等等来执行。类似地，处理策略可包括多处理、多任务、并行处理等等。在一个实施例中，指令被存储在可移除介质设备上，供本地或远程系统读取。在其他实施例中，逻辑或指令被存储在远程位置，以便通过计算机网络或经由电话线路传送。在其他实施例中，逻辑或指令被存储在给定的计算机、中央处理单元(“CPU”)、图形处理单元(“GPU”)或系统内。编码在一个或多个有形介质中以供执行的逻辑被定义为可由处理器执行并且在计算机可读存储介质、存储器或其组合上提供的指令。所描述的任何设备、特征、方法和/或技术可以被混合和匹配以创建不同的系统和方法。权利要求1.一种系统，包括存储器；以及与所述存储器通信的处理器，所述存储器包括可利用所述处理器执行的计算机代码，其中所述计算机代码被配置为提供针对一电话号码的信任关系信息，该信任关系信息指示出是否至少一个节点基于所展示的关于至少一个公共交换电话网(PSTN)呼叫的知识而认为目标节点包括用于所述电话号码的互联网协议语音(VoIP)呼叫代理或者与用于所述电话号码的VoIP呼叫代理相关联；以及基于所述信任关系信息来确定与所述目标节点的目标信任关系，其中所述目标信任关系指示出进行确证的节点对所述目标节点与用于所述电话号码的所述VoIP呼叫代理相关联或者包括用于所述电话号码的所述VoIP呼叫代理这一事项所具有的信任的级别，其中所述进行确证的节点和所述至少一个节点分别在网络的不同管理域中。2.如权利要求1所述的系统，其中，被配置为确定所述目标信任关系的计算机代码还被配置为基于所述目标的声誉来确定所述目标信任关系。3.如权利要求2所述的系统，其中，所述至少一个节点包括多个节点，并且被配置为确定所述目标节点的声誉的计算机代码还被配置为基于所述多个节点的数目来确定所述目标节点的声誉。4.如权利要求1所述的系统，其中，被配置为确定所述目标信任关系的计算机代码还被配置为基于所述信任关系信息和与所述至少一个节点的至少一个信任关系来确定所述目标信任关系，所述至少一个信任关系不被包括在所述信任关系信息中。5.如权利要求4所述的系统，其中，所述至少一个信任关系包括与所述至少一个节点中的任何一个的信任-包揽关系。6.如权利要求2所述的系统，其中，所述电话号码是第一电话号码，所述至少一个PSTN呼叫是至少一个第一PSTN呼叫，并且所述计算机代码还被配置为基于有多少节点认为所述目标节点包括用于第二电话号码的VoIP呼叫代理或者与用于第二电话号码的VoIP呼叫代理相关联来确定所述目标节点的声誉，其中所述第二电话号码与所述第一电话号码适用于相同的地理区域。7.如权利要求1所述的系统，其中，所述计算机代码还被配置为基于所述目标信任关系来确证用于所述电话号码的所述VoIP呼叫代理的身份。8.一个或多个有形介质，其中编码了利用处理器来执行的逻辑，所述逻辑在被执行时可操作来生成针对一电话号码的信任关系信息，其中该信任关系信息包括对以下情况的指示至少一个节点基于所展示的关于至少一个公共交换电话网(PSTN)呼叫的知识而认为目标节点包括用于所述电话号码的互联网协议语音(VoIP)呼叫代理或者与用于所述电话号码的VoIP呼叫代理相关联；以及根据所述信任关系信息来确定与所述目标节点的目标信任关系，其中所述目标信任关系指示出进行确证的节点信任所述目标节点与用于所述电话号码的VoIP呼叫代理相关联或者包括用于所述电话号码的VoIP呼叫代理的程度，其中所述进行确证的节点和所述至少一个节点在不同的管理域中。9.如权利要求8所述的一个或多个有形介质，其中，可操作来确定所述目标信任关系的逻辑可操作来确定所述目标节点的声誉并且根据所述目标节点的声誉来确定所述目标信任关系。10.如权利要求9所述的一个或多个有形计算机可读介质，其中，所述至少一个节点包括多个节点，并且可操作来确定所述目标节点的声誉的逻辑还可操作来基于所述多个节点之中有多少个节点在不同的管理域中来确定所述目标节点的声誉。11.如权利要求8所述的一个或多个有形计算机可读介质，其中，可操作来确定所述目标信任关系的逻辑还可操作来基于所述进行确证的节点是否与所述至少一个节点中的任何一个有包揽-信任关系来确定所述目标信任关系。12.如权利要求8所述的一个或多个有形计算机可读介质，其中，可操作来确定所述目标信任关系的逻辑还可操作来基于从所述进行确证的节点到所述至少一个节点的信任关系的链来确定所述目标信任关系。13.如权利要求8所述的一个或多个有形计算机可读介质，其中，所述逻辑还可操作来基于所述目标信任关系来判定是否接受来自包括所述目标节点的管理域的至少一个VoIP呼叫。14.一种方法，包括提供针对一电话号码的信任关系信息的至少一部分，所述信任关系信息指示出至少一个节点基于关于至少一个公共交换电话网(PSTN)呼叫的知识而认为目标节点包括用于所述电话号码的互联网协议语音(VoIP)呼叫代理或者与用于所述电话号码的VoIP呼叫代理相关联；以及基于目标信任关系来确证所述目标节点针对所述电话号码的身份，所述目标信任关系是根据所述信任关系信息的所述至少一部分来确定的，所述目标信任关系指示出进行确证的节点对所述目标节点与用于所述电话号码的VoIP呼叫代理相关联或者包括用于所述电话号码的VoIP呼叫代理这一事项所具有的信任的级别，其中所述进行确证的节点和所述至少一个节点分别在第一管理域和第二管理域中。15.如权利要求14所述的方法，还包括基于所述目标节点的声誉来确定所述目标信任关系。16.如权利要求15所述的方法，还包括基于所述至少一个节点中包括的节点的数目来确定所述目标节点的声誉。17.如权利要求16所述的方法，其中，所述信任关系信息还指示出有多少节点认为所述目标节点未能包括用于所述电话号码的VoIP呼叫代理或者与用于所述电话号码的VoIP呼叫代理相关联，并且确定所述目标节点的声誉还包括判定所述至少一个节点中包括的节点的数目这一事项是否比有多少节点认为所述目标节点未能包括用于所述电话号码的VoIP呼叫代理或者与用于所述电话号码的VoIP呼叫代理相关联这一事项更重要。18.如权利要求15所述的方法，还包括基于包括所述至少一个节点的管理域的数目来确定所述目标节点的声誉。19.如权利要求14所述的方法，还包括基于所述进行确证的节点是否被配置为包揽信任所述至少一个节点而确定所述目标信任关系。20.如权利要求14所述的方法，还包括在所述进行确证的节点处，在没有所述目标节点的身份的情况下，通过由于在所述进行确证的节点与所述至少一个节点之间存在配置的信任关系而从所述至少一个节点接收所述目标节点的身份，来根据所述信任关系信息的所述至少一部分确定所述目标信任关系。全文摘要一种系统可提供针对一电话号码的信任关系信息，其中该信任关系信息可指示出是否一个或多个节点基于所展示的关于PSTN呼叫的知识而认为目标节点包括用于该电话号码的VoIP呼叫代理或者与这样的VoIP呼叫代理相关联。系统可基于信任关系信息来确定与目标节点的目标信任关系，其中目标信任关系指示出进行确证的节点对目标节点与用于该电话号码的VoIP呼叫代理相关联或者包括这样的VoIP呼叫代理这一事项所具有的信任的级别，并且其中进行确证的节点和所述至少一个节点可以分别在网络的不同管理域中。文档编号H04L29/06GK102160361SQ201080001899公开日2011年8月17日申请日期2010年10月7日优先权日2009年10月29日发明者乔纳森·D·洛瑟博格,卡伦·F·詹宁斯申请人:思科技术公司