增强enum安全性的制作方法

专利名称：增强enum安全性的制作方法
技术领域：
本发明一般涉及通信系统。具体而言，本发明涉及ENUM(电话号码映射)的安全 性增强。
背景技术：
当今，电话网络正在开始从旧式公共交换电话网(PSTN)转移到基于IP(因特网协 议)的电话网络。技术平台交换机产生了新的挑战。这些挑战中的一个是，例如，如何以从客户的接 受角度来看不需承担改变传统方式进行电话呼叫的方式，提供基于因特网的服务，如因特 网上语音(VoIP)电话服务；实际上，通常使用电话的方式已经变得如此平常，以至于变化 将不受人们欢迎。因此，需要简单地使用当拨打电话时由用户输入的传统电话号码来定位因特网上 的被叫方电话的技术，不管它将被当做VoIP呼叫这一事实。解决这些问题的一种方法以ENUM为代表。ENUM是允许在国际电信联盟(ITU)认可的用于电话编号的国际标准E. 164，以及 诸如因特网之类的基于IP的网络之间融合的协议的名称。ENUM通过使用基于因特网的域 名系统(DNS)的技术来实现此融合。如已知的，DNS是现代因特网的基本组件，它将各种信 息与所谓的“域名，，相关联，并通过将人可读的计算机主机名，例如，网站地址，转换为网络 设备传递信息所需的对应的IP地址，来充当因特网的“电话簿”。DNS允许用户计算机使用 易于记忆的网址而不是复杂的数值网址来在因特网上查找网站服务器。在因特网工程任务组(IETF)文件RFC 3761中描述了 ENUM的细节，该文件是IETF 批准的协议文件，讨论了使用DNS来存储电话号码和连接到电话号码的可用服务。使用符合E. 164的电话号码和DNS来实现ENUM是适当的，因为一方面，E. 164是 在全世界范围内被接受和使用的电话号码的标准，而另一方面，DNS包括将字母数字信息与 IP地址相关的能力。E. 164号码，如网站名称那样，时间上保持相对静态，需要相对不太频 繁的更新(限于例如单个服务订户更改他们的电话号码的情况)。符合E. 164的电话号码通常包括国家代码、地区或城市代码，以及电话号码。 ITU给主权国家分配了唯一国家代码，例如，美国具有国家代码“1”，意大利具有国家代码 “39”。地区或城市代码和电话号码由主权国家通过本地电信管理机构来进行管理。例如，在美国的华盛顿特区(地区码202)的假设的电话号码555-1234的完全符 合E. 164的号码将是+1-202-555-1234。符号“ + ”表示该号码是完全符合E. 164的号码。ENUM涉及了上文所讨论的关于VoIP及其他服务的挑战，而同时给电话客户提供 了多个好处。当用户只知道电话号码或只能使用简单的电话小键盘时，ENUM允许有线的、 移动的、融合的电信网运营商、ISP(因特网服务提供商)、OLO(其他许可的运营商)、虚拟 移动或固定电话运营商提供范围广泛的基于IP的服务，以用于与另一个人进行通信。用户 可以，例如，使用因特网感知(VoIP)电话(这些电话，例如，是连接到因特网网关或代理服务器的普通电话，和/或输入功能限于数字的耦合到因特网的其他设备)来访问这些基于 IP的服务和资源。例如，用户通过预订由例如ISP或电信运营商所提供的特定服务，可以 在ENUM系统(具体而言，在其一种实现中，叫做“全球ENUM”，如下文所讨论的)中指定偏 好以用于接收传入的通信；这可以使用户对通信有较大的控制。例如，用户可以设置语音邮 件偏好，或者可以输入呼叫转移服务中的目的地电话号码。ENUM有许多潜在的应用。然而，ENUM的主要应用迄今为止集中于两个领域VoIP 和因特网邮件的语音协议(VPIM)。VoIP行业的一个目标是像拨打普通的旧式PSTN电话那 样容易地并且以相同质量地通过因特网拨打电话。如果一般的电话客户要使用例如支持因 特网的电话向另一支持因特网的电话进行电话呼叫，则之间的所有步骤都应该保持对用户 透明。对主叫方和被叫方来说，此电话呼叫应该显得与通过PSTN进行的呼叫相同。由于ENUM可以提供许多不同种类的服务，因此，ENUM具有范围广泛的潜在客户， 包括单个的住宅电话用户、公司、政府机构、军队，以及一大批其他非个人用户。用户有资格 享用的服务列表存储在ENUM数据库中，并可以响应于通过电话小键盘输入代码的操作而 被访问。当用户希望使用特定服务时，他们可以例如通过在电话小键盘上输入相关联的代 码来标识他们希望使用的ENUM服务。本质上，如IETF文件RFC 3761所定义的ENUM协议按下列方式工作。一旦输入 了电话号码，它就被转换成域名；将输入的电话号码转换成域名涉及首先通过添加城市或 地区以及国家代码，将输入的号码转换成完全符合E. 164的号码；然后，颠倒该完全符合 E. 164的号码的数字顺序，并在每一个数字之间插入点；最后，在末尾附加域“el64. arpa”。然后，ENUM对所产生的域名发出DNS查询。一旦找到权威的域名服务器，ENUM就 从ENUM数据库中检索相关的NAPTR(名称权威指针)资源记录，并根据该电话号码的用户 注册的服务来执行。ENUM可以具有各种实现方式；两个可能的ENUM实现方式被称为“公共ENUM”或 “全球ENUM”以及“运营商ENUM”或“基础架构ENUM”。全球ENUM是全球的，类似于公共目录的数据库，在el64. arpa域中的国家代码级 别带有用户决定参加(opt-in)功能和委托。全球ENUM向其他运营商和服务提供商提供路 由信息(与由给定运营商管理的E. 164号码相关的IP地址)。在全球ENUM中，最终用户被 允许通过提供和读取路由信息来“决定参加”。具体而言，全球ENUM定义了域“el64. arpa", 该域可以被用作用于将E. 164号码存储在DNS中的基础(符合IETF文件RFC 3761)。对全 球ENUM的管理是国家的或地区性的事件，并由不同国家的电信管理机构来进行管理。由于 是公共的，并对每个人开放的，全球ENUM可能会受到垃圾邮件问题及其他形式的欺诈行为 的影响，如稍后所讨论的。相反，基础架构ENUM是只能在数量有限的选定的受信任运营商内使用的ENUM实 现。基础架构ENUM不可被最终用户访问，其旨在受信任运营商圈内部使用。这确保了服务 安全性和用户隐私。基础架构ENUM有助于出于在运营商网络内的路由目的而发现用户和 他们的相关服务，查找连接到其他运营商或到PSTN网络的网关的边界元素，将用户和基础 架构隐藏在边界元素之后，并给外面的运营商访问仅这些边界元素的权限。共享的基础架 构ENUM旨在被运营商使用，以达到可信网络的边界元素；它不旨在被不受信任的网络的订 户或最终用户直接使用。因此，公共“el64. arpa”域名空间不适合于基础架构ENUM服务，而应该采纳专用域名。尽管具有毫无疑问的优点，但是，ENUM的潜在风险也已经被认识到。例如，在标题 为“ENUM Administration in Europe”的文件 ETSI TS 102 051 中，预报了 ENUM 存在肆无 忌惮地使用其NAPTR记录中所包含的信息的巨大风险。对存在ENUM记录的E. 164号码进行 的任何通信尝试都将允许发出请求的ENUM客户端应用程序访问有关某一订户的NAPTR记 录中所包含的所有服务特定的通信标识符(电话号码、电子邮件地址、即时消息地址等等) 的信息。此信息可以用来确定与随机地输入的E. 164号码相关联的人的身份(例如，通过查 看他/她的电子邮件地址中的姓名，或通过查看他/她的NAPTR记录中给出订户姓名的线 索的任何其他条目)。ENUM的这种潜在的滥用可以被用来辅助“身份盗窃”或帮助希望构建 标识列表以用于在范围广泛的不同的通信服务之间传播“垃圾邮件”通信的组织(例如，当 今通过拨打电话号码列表联络其他人的人们也可以通过滥用ENUM，生成与那些号码相关联 的电子邮件地址以及即时消息标识符的列表)。NAPTR记录中所包含的信息可透露ENUM最 终用户所使用的通信应用和服务的类型，以及潜在地，也可透露这些应用和服务的提供商。 此信息可以被第三方用于商业目的，例如，向ENUM最终用户提供涉及该订户所使用的那些 应用和服务竞争的应用和服务，或开发和出售示出了 ENUM最终用户所使用的通信应用程 序和服务的市场概况。ENUM,与将多个服务映射到单一标识符(订户的E. 164号码)的任何系统一样，对 多服务拒绝服务(DoS)攻击很脆弱。例如，在DNS NAPTR记录上安装“淹没攻击”的任何人 都可以防止从被攻击的NAPTR记录中检索任何通信地址。这样的攻击将使得查询NAPTR记 录的任何人都不可能获得对他们的查询的响应。这样的攻击的结果可能是，没有人能够使 用任何一个可能的与其相关联的通信服务与该ENUM最终用户进行通信，如此，彻底地禁止 订户的传入通信(可能，唯一例外是通过PSTN进行电话呼叫)。可能由存在监控或控制不严格问题的ENUM的私有的实现而产生额外的风险。对于完整性和安全性方面，其中两个主要威胁是仿冒(passingoff)和劫持 (hijacking)。仿冒是一个实体将其本身表现为它不是的某人或某事，通常获得商业好处或用于 犯罪目的。在ENUM的背景下，当一个实体在DNS中提供其他人(另一个人或公司)164 号码时，在对应于另一个人的或公司的号码的NAPTR记录中插入其自己的细节，就可发生 仿冒。仿冒被视为有害的，因为它破坏了个人和组织在使用ENUM功能的通信中应该具有的 信任。劫持是在没有最终用户的许可的情况下在通信路径中插入了通信应用和服务的 提供商。在ENUM的背景下，当通信应用或服务的提供商在没有得到同意的情况下安排最终 用户的E. 164号码在DNS中提供时，以及当使用这些号码的ENUM功能的通信被通过最终用 户没有选择的网络、应用或服务重定向时，可发生劫持。劫持被视为有害的，因为它可能允 许通信应用或服务的提供商不适当地收取转接或其它收入，并与最终用户的关于其传入通 信的传送的判断相抵触。由于可能建立不同于el64. arpa ENUM的多个可能竞争的专用ENUM系统(如，例 如，el64. com, el64. org等等)，存在不同的ENUM系统数据库的NAPTR记录中存储的数据之 间的一致性问题。
这两种风险都指向对适当机制的需求，以确保在DNS中提供号码的请求是从号码 的合法的受让人发出的。—个可能的方法可能涉及通过验证实体来进行鉴定。无论开发了什么解决方案， 任何有效的方法都可能涉及某种程度的验证。尽管此方法克服了 “仿冒”问题，但是，它可 能不能彻底地解决“劫持”问题，因为验证实体可能试图劫持号码。在修改和撤回号码的情 况下，会发生类似的问题。挑战是如何确保进程满足要求以便保持ENUM域名和E. 164号码 之间的一致性，而不会对任何涉及的实体带来过量的管理负担。由于坏的管理模式可能允许实体滥用过大的市场权力地位的可能性，会出现额外 的风险。ENUM数据库具有三级分层结构最高的分级层次叫做“层0注册表”，或，简单地， “层0”，可通过顶级域(TLD)DNS名称(如“el64. arpa")达到；层0下面的分级层次叫做 “层1注册表”或“层1”;存在多个层1，每个与相应的国家代码相关联；底部分级层次叫做 “层2注册表”或“层2”，并对应于相应的电话号码。对市场权力地位的滥用主要在层1附 近产生。通常，对层1的管理是层1的国家代码所对应的国家的职责。然而，如果一个国 家委托了管理其层1的职责而没有进行适当的控制，而被指派的层1管理者可能潜在地滥 用其唯一的地位，例如，对向其数据库中输入E. 164号码收取不相称的费用；另一方面，将 管理某一国家的层1的任务指派给两个或更多相互竞争的主体，会导致许多附加的复杂情 况，包括复杂而困难的相互协作要求。对单一国家或地区的管理者托管ENUM的域的控制，还可能给该国家或地区提供 对融合的因特网电话网络的操作的不正当的影响。类似地，如果ENUM机制所依赖的DNS服 务器的位置主要位于单一国家或地区，则这可能导致欧洲内部或欧洲及其他地区之间的通 信过度依赖欧洲之外的基础架构。还有将整块号码注册到ENUM中的可能性。因此，重要的是确保这些号码处于所有 者的控制之下，具有改变有关何时应该进行解析以及是否给谁授权的策略的可能性。US 6，968，050公开了一种系统，该系统提供了用于鉴定并授权人们在基于 AIN(高级智能网)的方法和设备的背景下(例如，在ENUM数据库中)注册对应于电话号 码的信息的ENUM安全性。这些方法可以用来鉴定寻求向ENUM注册电话号码相关信息的 一方。在ENUM注册线上设置了触发器。对ENUM注册线的呼叫激活触发器，导致对应于主 叫方号码的LIDB(线路信息数据库)信息被检索。检索到的信息，例如，名称、地址和/或 电话号码，被提供给ENUM注册服务，该服务返回一个密码以供在更新或提供对应于电话号 码(将来某个时间，例如，通过因特网，从该电话号码发出注册呼叫)的ENUM注册信息时使 用。当忘记密码时，通过从注册的或相关联的电话号码向注册服务发出呼叫，可以获得分配 的ENUM密码。Security Introduction and Requirements"^ IETFRFC 4033 f 牛 阐述了 DNS的扩展，该扩展通过使用加密数字签名来提供对安全性感知解析器和应用的数 据完整性和鉴定。这些数字签名作为资源记录包括在安全的区域中。在某些情况下，也可以 通过非安全性感知的DNS服务器来提供安全性。扩展用于将已鉴定的公共密钥存储在DNS 中。密钥的这种存储可以支持普通公共密钥分发服务以及DNS安全性。存储的密钥允许安 全性感知解析器除了它们最初配置的那些之外还了解区域的鉴定密钥。可以检索与DNS名 称相关联的密钥，以支持其他协议。此外，安全性扩展提供对DNS协议事务和请求的可选鉴
7定。G. Kambourakis 等人所著的标题为"Security and privacy issuestowards ENUM protocol”的发表在2005年12月18-21日在Samos(希腊)召开的2005 IEEE International Symposium on SignalProcessing and Information Technology白勺H文 集中(478-483页)的论文描述了涉及ENUM技术的使用的安全性问题，并提供了确保那些 问题的潜在的原则的列表。

发明内容
从以上的讨论可以看出，如当前实现的ENUM系统可能会受到潜在的安全性威胁。 事实上，当信息全球可用或被适当地控制时，ENUM系统可能会遭到垃圾邮件(重复使用有 关攻击目标的联络方式的信息，生成未经请求的通信)、黑客(使用ENUM系统中所包含的信 息来进行细节VoIP附加)或被不受信任的操作员错用(可能，例如，使用该信息来进行市 场营销分析，而不受信息的所有者的任何控制)。与被PSTN/ISDN网络保护的客户/服务的 路由和联络方式相关的信息似乎丢失或者说不易管理，具有操作员的业务和客户的安全性 的潜在丢失。许多问题是由ENUM是分组网络服务(即，基于因特网和TCP/IP协议套件)这一 事实所引起的，依赖于DNS协议和基础架构，而DNS协议和基础架构是在对处理过的信息不 需要任何控制的情况下设计出来的。关于US 6，968，050中所公开的解决方案，申请人相信它具有下列缺点它适于鉴定并授权对存储到ENUM系统中的信息(即，电话号码和URI-统一资源 标识符之间的关联)的修改；它局限于旧式的PSTN和IN(智能网)系统，并且它基于PSTNCLI (主叫线路识别， 主叫者的电话号码)鉴定机制。US 6，968，050中所公开的解决方案提出了一种向ENUM服务器提供信息的自我提 供机制，直接从由希望通过VoIP呼叫可被联络到的PSTN用户生成的数据开始。该解决方 案不适合于保护已经在ENUM系统中发布的信息，并且没有解决由因特网和分组网络连接 所产生的各种问题。关于IETF RFC 4033文件，申请人相信，DNSsec解决方案具有下列缺点它关注于DNS数据库中所包含的数据的完整性和真实性，以便防范某些特定攻击 (即，DNS毒害)；它不能用于/适于保护用户数据的隐私和ENUM通信内的信息交换保密性；当ENUM是基于DNSsec机制时，它仍不保护操作员业务(例如，一些受保护的信 息，一旦在ENUM系统上可用，也对不能受所有者控制的其他各方可用)。另一方面，G. Kambourakis等人所著的论文提供了对识别ENUM基础架构的缺点有 用的一般概述，但是，它没有提供针对所识别的问题的比DNSec更好的任何具体解决方案。申请人:已经解决了使ENUM服务更安全并能够保证用户隐私的问题。申请人:已经发现，此问题的解决方案可以这样来获得使用假想的用户的联系信 息隐藏通常存储在ENUM系统数据库中的用户的联系信息(即，SIP URI)，假想的用户的联 系信息适于存储在ENUM数据库中，但是本身不能用于联络用户，并且向ENUM系统中添加安全策略管理平台，以便为了揭示真实的用户联系信息而使对假想的联系信息的解析满足预 定的规则。本发明的一个方面涉及提供电信服务的方法，包括-生成单义地与分配给订户的电话号码相关联的假想的联系信息；-将所述假想的联系信息存储在数据库中；-响应于从请求者接收到的请求，令所述数据库提供所述假想的联系信息，其中所 述请求是对于对应于所述电话号码并允许通过因特网联系所述电话号码的订户受让人的 联系信息的请求；-使为了提供联系信息而对假想的联系信息的解析满足至少一个安全规则，所述 至少一个安全规则适于评估所述请求者和所述请求之中至少一个的属性，以及-在来自请求者的请求满足所述至少一个安全规则的情况下，解析所述假想的联 系信息并向请求者提供联系信息。具体而言，所述数据库可以是ENUM数据库。所述联系信息可以包括单义地标识所述用户的SIP URI。所述假想的联系信息可以包括单义地与所述订户的所述SIPURI相关联的假想的 URL·具体而言，所述假想的URI可以包括随机地生成的信息。更具体而言，所述假想的URI 可以包括包括域名，该域名单义地标识适于解析满足至少一个安全规则的所述假想的联系 信息的解析器系统。所述至少一个安全规则可以定义下列各项中的一项或多项有资格解析所述假想 的联系信息的电话网络操作员，有资格解析所述假想的联系信息的请求者，请求者有资格 用来通过因特网联系所述电话号码的订户受让人的连接服务的类型，关于请求者被允许联 系所述电话号码的订户受让人的日期和时间的指示。该方法还可以进一步包括使得所述电话号码的所述订户受让人或者所述订户预 订了的电话操作员能够定义所述至少一个安全规则。所述生成单义地与分配给所述订户的所述电话号码相关联的假想的联系信息包 括在所述解析假想的联系信息之后，生成新的假想的信息。本发明的另一方面涉及用于提供电信服务的系统，包括-适于生成单义地与分配给订户的电话号码相关联的假想的联系信息，并使该假 想的联系信息作为所述订户的联系信息存储在数据库中的生成器；-适于执行下列操作的安全策略规则执行器-从请求者接收解析所述假想的联系信息以便获得对应于所述电话号码的联系信 息的请求，所述联系信息适于允许通过因特网联系具有所述电话号码的订户；以及-使对假想的联系信息的解析和向请求者提供联系信息满足至少一个安全规则， 所述至少一个安全规则适于评估所述请求者和所述请求之中至少一个的属性。数据库可以具体是ENUM数据库。所述联系信息可以包括单义地标识所述订户的SIP URI。所述假想的联系信息可以包括单义地与所述订户的所述SIPURI相关联的假想的 URL·具体而言，所述假想的URI可以包括随机地生成的信息。更具体而言，所述假想的URI 可以包括单义地标识所述安全策略规则执行器的域名。
所述至少一个安全规则可以定义下列各项中的一项或多项有资格解析所述假想 的联系信息的电话操作员，有资格解析所述假想的联系信息的请求者，请求者有资格用来 通过因特网联系所述电话号码的订户受让人的连接服务的类型，关于请求者被允许联系所 述电话号码的订户受让人的日期和时间的指示。所述至少一个安全规则可以是用XML语言写的。系统还可以进一步包括安全规则管理器，其适于允许所述电话号码的所述订户受 让人或者所述订户预订了的电话操作员定义所述至少一个安全规则。优选情况下，在所述解析所述假想的联系信息之后，生成单义地与分配给所述订 户的所述电话号码相关联的新假想的联系信息。


通过下面的对本发明的某些实施例的详细描述，将更好地理解本发明的特点和优 点，实施例只作为非限制性的示例，描述将参考附图来进行，其中图1示意性地示出了本发明的实施例的应用场景；图2仍示意性地但是比较详细地描绘了根据本发明的实施例的用于保护ENUM服 务的安全的安全平台；图3是根据本发明的实施例的包括安全策略定义阶段的向安全平台预订电话号 码阶段的示意流程图；图4A和4B示出了根据本发明的实施例的安全策略实施阶段的示意流程图；图5示意性地示出了本发明的实施例的另一种应用场景；以及图6A和6B示出了根据本发明的另一个实施例的安全策略实施阶段的示意流程 图。
具体实施例方式参考图1，该图示意性地示出了本发明的实施例的应用场景。在该图中，附图标记100表示一般性的、第一电话操作员A的网络(如图所表示 的，“网络A” )；电话操作员A是例如在世界的某一国家，例如意大利，提供电话服务的其中 一个电话操作员。电话操作员A具有相应的订户，其中的一般性订户用附图标记105来表 示。电话操作员A的一般性订户被分配了相应的电话号码。附图标记110表示另一个一般性的、第二电话操作员B的网络(如图所表示的， “网络B”)；电话操作员B是，在此处所考虑的示例中，在不同于电话操作员A的国家的 世界上的某一国家，例如美国，提供电话服务的其中一个电话操作员。附图标记115表示 电话操作员B的一般性订户；订户115被分配了相应的电话号码，例如，假设的电话号码 202-555-1234，该电话号码标识了具有华盛顿特区的电话号码555_1234(区号202)的订 户。应该指出，本发明还适用于两个电话操作员A和B在同一国家操作，或者甚至重合的情 况；还应该指出，本发明不仅限于两个电话操作员的情况，也可以适用于不管电话操作员的 数量是多少的情况。图中的附图标记120表示电话操作员A的核心网络设备，包括例如，交换中心和呼 叫服务器设备；类似地，附图标记125表示电话操作员B的核心网络设备。
电话操作员A和B的网络100和110连接到因特网130。电话操作员A的核心网络设备120实现适于将电话操作员A的网络100连接到 ENUM系统的ENUM客户端功能135。ENUM系统包括数据库的分层结构，也被称为“金树”，该分层结构包括位于分层结 构的顶部的顶级的ENUM数据库140，被称为层0，位于层0之下的第一次级的多个数据库， 被称为层1，如图中所示出的两个数据库145-1和145-2，以及每一个层1数据库之下的被 称为层2的多个底层数据库，如图中所示出的两个数据库150-1和150-2。层0数据库140被分配了顶级ENUM域名，如根据IETF文件RFC 3761的规定的 "el64. arpa”，并可以通过该域名访问到，并存储了托管了层1数据库的因特网服务器的网 络地址。每一个层1数据库都与相应的国家代码相关联，即，与世界上的相应的国家相关 联；在此处所考虑的示例中，层1数据库145-1与对应于意大利的国家代码“+39”相关联， 并且层1数据库145-2与对应于美国的国家代码“+1”相关联。每一个层1数据库都存储 托管了各自国家的电话号码的层2数据库的因特网服务器的网络地址。每个层2数据库通 常都存储各个电话号码的NAPTR(名称权威指针)记录。在此处所考虑的示例中，层2数据 库150-1旨在存储电话操作员A的订户的电话号码的NAPTR记录，而层2数据库150-2旨 在存储电话操作员B的订户的电话号码的NAPTR记录；某一电话号码的一般性NAPTR记录 存储用于路由向该电话号码发出的呼叫的信息，以及订户的呼叫转移/结束偏好。应该指出，本发明不仅限适于应用于公共的全球ENUM“el64. arpa”，而且也适用于 专用的ENUM系统。在ENUM系统的常规实现中，层2数据库中的一般性NAPTR记录包含被分配给电话 网络的某一订户的URI (统一资源标识符)；URI是具有由IETF文件RFC 3866所定义的句法 的一串字符，其用于标识诸如因特网之类的网络中的资源。URI使得能够使用DNS(域名服 务器)或DNS的系统155的服务来定位订户。具体而言，存储在ENUM系统的NAPTR记录中 的 URI 是“TEL URI”，其格式如 IETF 文件 RFC 3966(标题为“The tel URI for Telephone Numbers")所规定；一般性TEL URI描述了由电话号码所标识的资源。如本说明书的引言部分所讨论的，常规ENUM系统实现方式存在多种风险。申请 人已经注意到，ENUM系统所存在的许多风险是由TEL URI可被自由地访问这一事实所引起 的。根据本发明的实施例，为了克服这些问题并使ENUM系统更安全，为ENUM系统提供 了安全策略平台。具体而言，根据本发明的实施例，在图1中由附图标记160全局性地标识并在图2 中更加详细地描述的安全策略平台基本上包括允许定义和管理的安全策略规则的安全策 略仿形系统(PPS)。安全策略规则是定义当尝试对存储在ENUM系统中的信息进行访问时系统的期望 行为的规则，具体而言，就可以被访问的信息而言，它们定义哪些请求应该被允许以及哪些 请求应该被拒绝(例如，判别谁可以检索信息以及何时可以检索信息)。根据本发明的实施例的PPS包括适于允许定义和注册安全策略规则的策略管理 子系统(策略管理器)165，以及策略执行子系统(策略执行器)170，其适于执行通过策略 管理器165定义的并在其中注册的安全策略规则。
11
安全策略规则可以直接由安全策略平台用户来定义和注册，该用户可以是最终用 户、是电话操作员的订户并被分配了电话号码，或希望对于一个或多个并可能是其所有订 户，建立用于调整对ENUM服务进行访问的安全策略规则的电话操作员；例如，参考图1，可 以由订户115，或由订户115的电话操作员B，或由他们两者，在策略管理器165中定义和注 册安全策略规则。策略管理器165与策略执行器170进行交互。具体而言，策略管理器165向策略执行器170提供要对于电话操作员的特定订户， 或/和对于订户组(可能是所有订户)执行的安全策略规则；在图1所示出的示例中，安全 策略规则是要对于电话操作员B的订户115，或/和对于订户组(可能是所有订户)执行的 规则。策略管理器165还通过合适的通信接口 205和210与ENUM系统交互，并可能与 DNS系统交互，ENUM系统和DNS系统在图2中分别全局性地表示为215和220 ；稍后，当描 述安全策略平台160的操作时，将详细描述策略管理器165与ENUM系统215和与DNS系统 220的交互。安全策略平台160可以由订户/电话操作员通过允许PPS软件客户端235与策略 管理器165交互的前端230，如，例如，HTTP (超文本传输协议)服务器或Web服务器来访 问，以便允许插入/修改/撤回安全策略规则。策略管理器165可以基于标准的VoIP注册器系统，即，它可以是SIP-会话启动协 议-注册器，它是如在IETF RFC 3261文件中所定义的，用于管理用户注册的基于SIP的体 系结构的标准元件。如本领域的技术人员所知道的，SIP是在多个不同的传输协议的顶部 运行并基于TCP/IP协议套件、并可以被用来创建、修改，以及结束与一个或多个参与者的 会话的应用层控制(信令)协议。这些会话包括因特网(VoIP)电话呼叫、多媒体分发，以 及多媒体会议。SIP利用叫做代理服务器的元件以帮助将请求路由到用户的当前位置，鉴定 用户并授权用户以服务，实现提供商呼叫_路由策略，以及向用户提供特征。SIP提供允许 用户上传他们的当前位置以供代理服务器使用的注册功能。策略管理器165包括其中存储了由客户端所定义的安全策略规则的数据库240。策略管理器165还包括可以操作以生成单义地与真实SIP URI相关联的哑的、假 想的URI的哑URI生成器，用于隐藏真实SIP URI，如稍后所比较详细地讨论的。下面将详细描述根据本发明的实施例的安全策略平台的操作。为了使用户，例如电话操作员B的订户115，或直接地电话操作员B本身，受益于安 全策略平台160的服务，请求向安全策略平台进行初步预订。在图3的示意流程图中描述 了用户向安全策略平台预订的过程的主要步骤。用户(例如，用户115，或电话操作员B)访问(例如，通过安全策略平台的网站的 网页)安全策略平台160，特别是策略管理器165 (动作305)。用户(订户115，或电话操作员B)向策略管理器165提供各自的电话号码(例如， 图1中的订户115的电话号码+1-202-555-1234)，以及对应的SIP URI (例如，订户115的 SIP URI 可以是 subscriber-X@domain-B. com)和 TEL URI。例如，用户可以使用 SIP 协议， 特别是SIP REGISTER消息提交这些数据，如在IETF RFC3261文件中所定义的，通过SIP REGISTER消息来传送注册信息。电话号码可以以E. 164格式提供，或者，也可以通过策略管
12理器165将其转换成E. 164格式。在流程图中，这些动作被全局性地表示为动作310。策略管理器165接收用户注册数据，并存储在，例如，策略数据库240中；然后，策 略管理器165调用哑URI生成器245，要求生成与从用户接收到的SIP-URI相关联的单义哑 URI (动作 315)。一种可能的哑URI是哑的、本质上无意义的ASCII串，S卩，以ASCII码表示的字符、 数字和符号的序列；可以使用任意字符，但是符号除外，该符号是预留的，通常被用作 用户名和因特网域名之间的分隔符。可以通过串接随机地生成的ASCII字符(例如，通过 适于生成数字/字符的随机序列的算法或硬件生成器来生成)来生成哑ASCII字符串。一 个示例性哑 URI 可以如下所示asfjwegoSJDHASD0ksdaoql2313asdaqe。另一种可能的哑URI是哑的、本质上无意义的ASCII字符串的串 接，如在上面的示例中，跟着符号“@”，然后是因特网域名，即，它可以具有格 式<dumb-ASCII-string>@<domain>。在此情况下，一个示例性哑URI可以是 fthftydfrtyer456drftddJHJIidomain-C. com。“域”单义地标识特定安全策略平台，例如， "domain" “domain-C”可以标识安全策略平台160。以此方式，可以建立安全策略平台的系 统，每个安全策略平台由对应的域名来标识，这有实现了将负担分配到一个以上的安全策 略平台的优点。然后，用户定义优选的安全策略规则(动作320)。出于此目的，用户可以使用诸 如XML (可扩展标记语言)之类的形式语言，例如，由OASIS (结构化信息标准推动组织，因 特网站点http://WWW. oasis-open, org)，特别是，XACML语言(可扩展访问控制标记语言) (有关此语 目白勺细节可以在网址 http //www. oasis_open. org/committees/tc—home, php ？ wg abbrev = xacml 找到)。用户可以定义的示例性安全策略规则如下<Rule><NAME> "Time Policy XYZ”</NAME><From><NUMBER>202-555-1234</NUMBER><INCOMING) “Operator-A”〈/INCOMING〉</From><To> * </To><Service>VoIP, MMS</Service>〈RANGE DATE>M0N_FRI〈/RANGE DATE〉〈ACT10N>Di sc1ο se-URI〈/ACT10N></Rule>在上面的示例中，标记<NAME>，</NAME>之间的字符串〃 Time Policy XYZ"定义 了规则的名称(名称可以由用户指定)；标记<From>，</From>和<To>，</Το>定界规则的 一部分，在该部分中可以指定安全规则要应用于的订户的电话号码、以及电话操作员的电 话号码或电话号码的范围或电话操作员的标识符；标记〈Service〉，〈/Service〉定界规则 的一部分，在该部分中可以指定规则要应用于的服务；标记〈RANGE DATE〉，〈/RANGE DATE) 定界规则的可以指定时间范围的一部分；标记〈ACTION〉，〈/ACTION〉定界规则的一部分，在该部分中可以指定满足规则的一个或多个动作。上面的名为“Time Policy XYZ”的示例性规则表明，与Ε. 164号码202-555-1234 相关联的URI可以由所有ENUM客户端查询(对其公开)，这些客户端是“操作员Α”(图1 的示例中的电话操作员Α)的订户，并希望从星期一到星期五建立VoIP呼叫或发送MMS (多 媒体消息服务)消息。其他示例性安全策略规则可以定义(使用类似于用于定义前一示例性规则的语 言的语言)下列条件“订户A始终被允许解析订户B的电话号码”，“仅对于MMS服夯，订 户A被允许解析订户B的电话号码”，“不在订户B的社区里的订户不被允许解析订户B的 电话号码”，其中，“社区”可以被定义为由订户Β(例如，图1中的订户115)所定义的受信任 的电话号码的地址簿，或电话操作员B认为可信的电话号码的范围。在上面的示例中，“解 析电话号码”是指，基于ENUM服务和DNS，从被叫方的电话号码推导用于经由因特网联络被 叫方的相应IP地址的动作。用户可以定义一个或多个安全策略规则；用户可以通过安全策略平台160的网站 在线编辑安全策略规则，或在他/她的房屋中离线编辑安全策略规则，然后将预先编辑的 规则上传到安全策略平台160。策略管理器165从用户接收安全策略规则，并将它们存储到安全策略数据库240 中(动作325)。安全策略规则单义地与先前生成并分配给用户的哑URI相关联。一旦用户完成了所希望的安全策略规则的定义，则用户关闭与策略管理器165的 会话(动作330)。然后，策略管理器165将由用户所定义的安全策略规则传送到策略执行器170。 策略管理器165还将由用户接收到的电话号码以及为该电话号码生成的单义地相关联的 哑URI传送到ENUM系统215 (动作335)；如此，电话号码以及相关联的、本质上无意义的哑 URI (不是如在普通的ENUM服务实现中的真实的SIP URI)存储在ENUM数据库中。具体而 言，考虑图1的示例，这些数据存储在层2数据库150-2中。可选地，策略管理器165可以将用户的电信终端或操作员的核心网络设备传送到 安全策略管理器165的用户的域和IP地址传送到DNS系统220 (动作340)。这在预订了安 全策略平台的用户已经被分配了静态IP地址，但没有动态地从一个因特网会话变为另一 个因特网会话的那些情况下可能有用。甚至在已经初步预订安全策略平台160之后，用户就可以访问安全策略平台160， 例如，用于修改先前所定义的安全策略规则、添加新规则、删除规则。每当安全策略规则发 生变化时，都向策略执行器170传送新安全策略规则。每当用户110开启其终端(如支持IP的电话，例如VOIP电话)并连接到电话操作 员B的核心网络设备110时，为连接到因特网130，用户终端被分配IP地址(例如，在115 的情况下，假设IP地址为11.22.33.44)。SIP注册阶段进行(如在IETF RFC 3261文件所 说明的)，通过该阶段，用户终端注册到注册器SIP服务器(在图形中未示出，因为本身是 已知的)。用户终端将分配给它的IP地址以及相应的SIP URI传送到注册器SIP服务器。 在成功地完成用户终端注册之后，用户被视为“存在”，并能够接收传入呼叫(可联系到分 配的IP地址)。注册器SIP服务器将用户的“存在”信息传送到安全策略平台160。在用 户110没有支持因特网的终端的情况下，如普通的旧式电话，用户的SIP注册是由电话操作员B的核心网络设备来执行的。图4A和4B的示意流程图示出了当某人，如图1中的电话操作员A的订户105试 图通过因特网与电话操作员B的订户115联络时，由根据本发明的实施例的安全策略平台 所执行的主要动作。具体而言，在现在所考虑的场景下，假设订户105希望使用普通电话，S卩，不是像 VoIP电话那样的支持因特网的电话，向用户115发出电话呼叫。用户105如往常那样在他的/她的电话上拨订户115的电话号码，以及国家代码 和区号。当电话操作员A的网络设备120从订户105接收到与订户115建立连接的请求 时，网络设备120，特别是，ENUM客户端功能135联络ENUM系统215，向其提供被叫订户的 E. 164电话号码(动作405)。ENUM系统215浏览其数据库，搜索指定的E. 164号码(动作410)。具体而言，在 图1的示例中，从层2数据库150-1沿着ENUM金树，即数据库的分层结构，向上爬到层0数 据库140，然后，再向下到层2数据库150-2。存储了搜索到的E. 164号码的NAPTR记录的ENUM数据库150-2向电话操作员A 的ENUM客户端功能135提供发现的NAPTR记录(动作415)。返回到ENUM客户端功能135 的NAPTR记录包含与指定的电话号码相关联的哑URI。ENUM客户端功能135，假设其能够识别URI是哑URI而不是真实SIP URI，查询安 全策略平台160，特别是策略执行器170，请求被叫方的对应于URI的真实SIP URI (动作 420)。当联络策略执行器170时，ENUM客户端功能135向策略执行器170提供其证明，例如 使用由TLS (传输层安全性)协议所提供的类型的相互验证机制，基于IETF RFC 2246文件 中所定义的数字证书(或其他类似的安全机制，例如IETF RFC 2401文件中所定义的IPSec 机制)。ENUM客户端功能135向策略执行器170提供的证书可以包括有关主叫方，即订户 105的标识(例如，其电话号码)的信息；此信息可以是策略执行器170对请求进行处理所 必需的。策略执行器170处理来自ENUM客户端功能135的请求，并使用从ENUM客户端功 能135接收到的 URI作为关键词在它存储的安全策略中进行搜索，获取与该 URI相关 联的安全策略规则(动作425)。然后，策略执行器170处理与指定的哑URI相关联的安全策略规则(动作430)。 取决于安全策略规则处理的结果，策略执行器170向ENUM客户端功能135返回答案。如果， 如在此处所考虑的示例中那样，策略执行器170评估主叫方(S卩，订户105)有资格解析该 哑URI以便检索被叫方(即，订户115)的IP地址，则策略执行器170将被叫方的SIP URI 返回到ENUM客户端功能135 (动作435)；如果相反，对安全策略规则的处理给出主叫方没 有资格检索被叫方的真实SIP URI(通过该真实的SIP URI，它可以解析IP地址)的结果， 则该 URI不被解析，并向ENUM客户端功能135发回否定响应。安全策略规则还可以定义 被叫用户不“存在”，即，其通信终端没有向注册器SIP服务器注册的那些情况下的特定行 为；例如，安全策略规则可以规定，在被叫用户不“存在”的情况下，即，他/她目前不能被联 络到，则简单丢弃主叫者的请求，或者，它们可以规定，如果主叫者有资格解析该哑URI，但 是被叫用户不“存在”，即，他/她目前不能被联络到，则向主叫者发送礼貌的信息消息。
为增强安全性，策略管理器165可以为该电话号码生成新的哑URI，并将该新的哑 URI存储在适当的ENUM数据库中，替换前一个。ENUM客户端功能135接收被叫方的SIP URI (动作440)，然后它使用检索到的SIP URI来查询DNS系统215，以便发现被叫方(S卩，订户115)的IP地址，或被叫订户115的电 话操作员B的网络110 (例如，主叫服务器)的IP地址(动作445)。DNS系统215使用SIP URI来定位搜索到的IP地址(动作450)，并将被叫订户 115的电话操作员B的网络110(的呼叫服务器)的IP地址返回到电话操作员A的网络设 备120中的呼叫服务器(动作455)。电话操作员A的网络设备120中的主叫服务器使用检索到的IP地址来尝试与被 叫方(订户115)建立呼叫。具体而言，假设SIP被用作电话网络100和110之间的信令协 议，电话操作员A的网络设备120中的呼叫服务器可以发送SIP INVITE消息(允许建立电 话呼叫的标准消息)，该消息包含客户“B”的SIP URI ；电话操作员B的网络设备125中的 呼叫服务器将被叫订户115的SIP URI解析为被叫订户115的本地(S卩，网络110内部的) IP地址(例如，由电话操作员B分配给被叫订户115的通信终端，例如VoIP电话，或个人计 算机的动态IP地址)，而订户105和115之间的交谈可以通过电话操作员A和B的网络基 础架构进行。应该指出，上文所描述的过程也可以适用于用户105和115属于同一个网络的情 况(例如，网络A，在这种情况下，网络设备120和125和层-2数据库150-1和150-2重 合)；在这样的情况下，被叫订户115的TEL URI的解析被简化，因为只涉及ENUM层-2数 据库150-1。在图5中，概要地示出了本发明的实施例的应用的另一种可能的情形。使用相同 的附图标记来表示与图1中所示出的那些元件相同或相似的元件。在此另一种场景下，假设订户105是所考虑的示例中的主叫方，具有支持因特网 的电话，如VoIP电话，并带有适于执行在图1的场景下由电话操作员A的网络设备120的 ENUM客户端功能135替代性执行的动作的ENUM客户端功能535。图6A和6B的示意流程图示出了当某人，例如图5中的电话操作员A的订户105 试图通过因特网与电话操作员B的订户115联络时，由根据本发明的实施例的安全策略平 台所执行的主要动作。假设订户115(或他/她的电话操作员B)向安全策略平台160进行 了注册，并定义了他/她的安全策略规则。订户105如往常那样在他的/她的电话上拨被叫订户115的电话号码，完整的国 家代码和区号。订户105的电话的ENUM客户端功能535联络ENUM系统215，并向其提供被叫订户 的E. 164电话号码(动作605)。ENUM系统215浏览其数据库，搜索指定的E. 164号码(动作610)。具体而言，在 图1的示例中，从层2数据库150-1沿着ENUM金树，即，数据库的分层结构，向上爬到层0 数据库140，再向下到层2数据库150-2。存储了搜索到的E. 164号码的NAPTR记录的ENUM数据库150-2向订户105的电 话的ENUM客户端功能535提供所找到的NAPTR记录(动作615)。返回到ENUM客户端功能 535的NAPTR记录包含与指定的电话号码相关联的哑URI。
16
ENUM客户端功能535，假设其能够识别URI是哑URI，查询安全策略平台160，特别 是策略执行器170，请求被叫方的对应于该哑URI的真实SIP URI (动作620)。当联络策略 执行器170时，ENUM客户端功能535向策略执行器170提供其证明，例如，使用由TLS (传输 层安全性)协议所提供的类型的相互验证机制，基于IETF RFC2246文件中所定义的数字证 书(或其他类似的安全机制，例如，IETFRFC 2401文件中所定义的IPSec机制)。ENUM客 户端功能535向策略执行器170提供的证明可以包括有关主叫方，S卩，订户105的标识(例 如，其电话号码)的信息；此信息对于策略执行器170处理请求来说是必需的。策略执行器170处理来自ENUM客户端功能535的请求，并使用该 URI作为关键 词，获取与其相关联的安全策略规则(动作625)。然后，策略执行器170处理与指定的哑URI相关联的安全策略规则(动作630)。 取决于安全策略规则处理的结果，策略执行器170向ENUM客户端功能535发送答案。如果， 如在此处所考虑的示例中那样，策略执行器170评估主叫方(S卩，订户105)有资格解析该 哑URI以便检索被叫方(即，订户115)的SIP URI (通过该SIP URI，它可以解析其IP地 址)，则策略执行器170将被叫方的SIP URI返回到ENUM客户端功能535 (动作635)；如 果相反，对安全策略规则的处理给出主叫方没有资格检索被叫方的SIP URI的结果，则该 URI不被解析，并向ENUM客户端功能535发回否定应答。ENUM客户端功能535接收被叫方的SIP URI (动作640)，然后它查询DNS系统215， 以便找到被叫方(S卩，订户115)的IP地址，或被叫订户115的电话操作员B的网络110的 IP地址(动作645)。DNS系统215使用SIP URI来定位搜索到的IP地址(动作650)，并将被叫方(即， 订户115)的IP地址，或被叫订户115的电话操作员B的网络110的IP地址返回到订户 105的电话(动作655)。订户105的电话使用检索到的IP地址来尝试与被叫方(订户115)建立呼叫。具 体而言，订户105的电话可以向订户115的电话，或向电话操作员B的网络设备125中的呼 叫服务器发送SIP INVITE消息，该消息包含客户“B”的SIP URI ；电话操作员B的网络设 备125中的呼叫服务器将被叫订户115的SIP URI解析为被叫订户115的本地(S卩，网络 110内部的)IP地址(例如，由电话操作员B分配给被叫订户115的通信终端，例如VoIP电 话，或个人计算机的动态IP地址)，而用户105和115之间的谈话得以进行。如在先前所描述的场景下，刚刚所描述的过程也可以适用于订户105和115属于 同一个网络的情况(例如，网络A，在这种情况下，网络设备120和125和层-2数据库150-1 和150-2重合)；在这样的情况下，被叫订户115的TEL URI的解析被简化，因为只涉及ENUM 层-2数据库150-1。为了进一步提高安全程度，每当哑URI被解析且检索到对应的SIP-URI时，安全策 略平台160可以生成新的哑URI (并将它传送到其他实体)；以此方式，确保了一旦通过解 析相应的哑URI而获得了关于SIP URI的信息之后，不会被可能不希望的主体重复使用。从上文对其某些示例性实施例的描述可以看出，可以理解，本发明通过使用于联 络最终用户的信息隐藏，并使对所述联系信息的检索满足可以由最终用户进行定义或他们 的电话操作员进行定义的安全规则，来使得ENUM服务更安全。如此，只允许被视为“受信任 的”选定用户/用户类别检索从他/她的普通的电话号码获得的通过因特网联络某人所必需的联系信息，这可以保证，例如，避免垃圾邮件，以及一般而言来自不希望的人/实体的 呼叫。安全策略平台可以通过连接到因特网的一个或多个服务器来实现，并向电话操作 员提供服务。这里参考本发明的某些示例性实施例公开了本发明，然而，本领域的技术人员将 容易地识别到，在不偏离所附权利要求书的范围的情况下，对所描述的实施例进行修改以 及其他实施例都是可以的。例如，生成要与电话号码相关联的哑URI并将该电话号码和该哑URI传送到ENUM 系统的动作可以只在用户第一次预订到安全策略平台时执行，如前面所描述的，或周期性 地，或在某人试图联络该电话号码的订户受让人的任何时间执行。更一般而言，本发明可以适用于ENUM之外的、其中提供了用于存储用户的联系信 息的数据库的系统。
权利要求
一种提供电信服务的方法，包括 生成单义地与分配给订户的电话号码相关联的假想的联系信息； 将所述假想的联系信息存储在数据库中； 响应于从请求者接收到的请求，令所述数据库提供所述假想的联系信息，其中所述请求是对于对应于所述电话号码并允许通过因特网联系所述电话号码的订户受让人的联系信息的请求； 使为了提供联系信息而对假想的联系信息的解析满足至少一个安全规则，所述至少一个安全规则适于评估所述请求者和所述请求之中至少一个的属性，以及 在来自请求者的请求满足所述至少一个安全规则的情况下，解析所述假想的联系信息并向请求者提供联系信息。
2.如权利要求1所述的方法，其中，所述数据库是ENUM数据库。
3.如权利要求1或2所述的方法，其中，所述联系信息包括单义地标识所述订户的SIPURI。
4.如权利要求3所述的方法，其中，所述假想的联系信息包括单义地与所述订户的所 述SIP URI相关联的假想的URI。
5.如权利要求4所述的方法，其中，所述假想的URI包括随机地生成的信息。
6.如权利要求5所述的方法，其中，所述假想的URI包括单义地标识解析器系统的域 名，该解析器系统适于解析满足至少一个安全规则的所述假想的联系信息。
7.如前面的权利要求中任一权利要求所述的方法，其中，所述至少一个安全规则定义 下列各项中的一项或多项有资格解析所述假想的联系信息的电话网络操作员，有资格解 析所述假想的联系信息的请求者，请求者有资格用来通过因特网联系所述电话号码的订户 受让人的连接服务的类型，关于请求者被允许联系所述电话号码的订户受让人的日期和时 间的指示。
8.如前面的任何一个权利要求所述的方法，包括使得所述电话号码的所述订户受让人或者所述订户预订了的电话操作员能够定义所 述至少一个安全规则。
9.如前面的权利要求中任一权利要求所述的方法，其中，所述生成单义地与分配给所 述订户的所述电话号码相关联的假想的联系信息包括在所述解析假想的联系信息之后， 生成新的假想的信息。
10.一种用于提供电信服务的系统，包括-适于生成单义地与分配给订户的电话号码相关联的假想的联系信息，并使该假想的 联系信息作为所述订户的联系信息存储在数据库中的生成器；-适于执行下列操作的安全策略规则执行器_从请求者接收解析所述假想的联系信息以便获得对应于所述电话号码的联系信息的 请求，所述联系信息适于允许通过因特网联系具有所述电话号码的订户；以及_使对假想的联系信息的解析和向请求者提供联系信息满足至少一个安全规则，所述 至少一个安全规则适于评估所述请求者和所述请求之中至少一个的属性。
11.如权利要求10所述的系统，其中，所述数据库是ENUM数据库。
12.如权利要求10或11所述的系统，其中，所述联系信息包括单义地标识所述订户的SIP URI。
13.如权利要求12所述的系统，其中，所述假想的联系信息包括单义地与所述订户的 所述SIP URI相关联的假想的URI。
14.如权利要求13所述的系统，其中，所述假想的URI包括随机地生成的信息。
15.如权利要求14所述的系统，其中，所述假想的URI包括单义地标识所述安全策略规 则执行器的域名。
16.如权利要求10到15中的任何一个权利要求所述的系统，其中，所述至少一个安全 规则定义下列各项中的一项或多项有资格解析所述假想的联系信息的电话操作员，有资 格解析所述假想的联系信息的请求者，请求者有资格用来通过因特网联系所述电话号码的 订户受让人的连接服务的类型，关于请求者被允许联系所述电话号码的订户受让人的日期 和时间的指示。
17.如权利要求16所述的系统，其中，所述至少一个安全规则是用XML语言写的。
18.如权利要求10到17中的任何一个权利要求所述的系统，包括安全规则管理器，其 适于允许所述电话号码的所述订户受让人或者所述订户预订了的电话操作员定义所述至 少一个安全规则。
19.如权利要求10到18中的任何一个权利要求所述的系统，其中，在所述解析所述假 想的联系信息之后，生成单义地与分配给所述订户的所述电话号码相关联的新假想的联系信息ο
全文摘要
一种提供电信服务的方法，包括生成单义地与分配给订户的电话号码相关联的假想的联系信息；将所述假想的联系信息存储在数据库中，比如ENUM数据库；响应于从请求者接收到的请求，令所述数据库提供所述假想的联系信息，其中所述请求是对于对应于所述电话号码并使得能够通过因特网联系所述电话号码的订户受让人的联系信息的请求；使为了提供联系信息而对假想的联系信息的解析满足至少一个安全规则，所述至少一个安全规则适于评估所述请求者和所述请求之中至少一个的属性，以及在来自请求者的请求满足所述至少一个安全规则的情况下，解析所述假想的联系信息并向请求者提供联系信息。
文档编号H04M3/493GK101911652SQ200780102162
公开日2010年12月8日 申请日期2007年11月30日 优先权日2007年11月30日
发明者F·西勒塔, P·德卢蒂斯 申请人:意大利电信股份公司