CN102549966A - 使用全球注册表来设立呼叫的系统和方法 - Google Patents

Abstract

本发明引入了新颖系统和新颖方法，用于在呼叫者对被呼叫的个人的IP能力没有任何了解的情况下允许使用IP通信装置的个人使用诸如电话号码的单个标识符来联系外部组织中的个人。这被用于与例如全球地址数据库(GAD)的注册表装置进行通信。GAD包含对于注册的号码的诸如IP能力的联系信息。当试图对给定号码进行呼叫时，在呼叫方场点的呼叫服务器或类似设施从GAD请求与该号码相关的联系信息，然后基于从GAD接收的信息来建立呼叫。

Description

使用全球注册表来设立呼叫的系统和方法

技术领域

本发明涉及管理通信装置的联系信息的全球注册表和一种使用该联系信息的全球注册表来设立呼叫的方法。

背景技术

过去几十年来，实时的长距离通信的标准手段一直是电话，在组织内的每一个个人几乎都具有电话号码，该电话号码是全球唯一的，并且通过世界上任何电话可以根据电话号码到达那些个人。

在更近的几年中，经由IP的呼叫已经获得重视，因为它们具有多个优点，它们通常在使用方面免费，可以使用高质量音频编解码器提供较好的音频保真，允许视频和数据共享以及仅仅语音等。当电路交换和分组交换系统都可用时，一般优先于电路交换(电话)呼叫而进行分组交换(IP)呼叫。

当前，个人一般以电话号码的形式来提供他们的联系方式，电话号码是短的、全球唯一的和容易使用的，并且在之前未曾联系过的组织之间可行。然而，这仅提供了进行语音呼叫的设施且质量较低。

在网络内，许多IP设置支持减轻进行IP媒体呼叫的复杂度的方式，例如，在端点上的预先配置的地址簿使得用户通过从列表选择它们来呼叫个人。在其他更复杂的设置中，端点向中央服务器注册它们的可用性，中央服务器然后可以路由呼叫，并且向端点推出用户的列表。

US-2002/0136222描述了一种在网际协议(IP)通信网络中处理呼叫的系统。这个系统包括轻量级目录访问协议(LDAP)数据库、LDAP服务器和重定向服务器。LDAP数据库存储一组IP通信服务属性。LDAP服务器接收对于数据库更新的请求，从LDAP数据库提取这组IP通信服务属性，并且将所提取的IP通信服务属性传送到重定向服务器。重定向服务器存储所提取的IP通信服务属性，并且使用所存储的IP通信服务属性来处理呼叫。

现有技术的解决方案通常仅工作在组织内，因为它们依赖于已经具有对它们可用的信息的端点和服务器，同样，它们仅允许个人呼叫那些详情已经在系统内的用户。

当个人希望呼叫不同组织的其详情尚未被配置在端点和服务器上的用户时，这变得成问题。在该情况下，个人需要知道呼叫协议和要呼叫的组织的路由信息以及使得呼叫被路由到组织内的正确个人的标识符。呼叫者也必须对于配置他的端点进行这样的呼叫具有足够的技术知识，并且在呼叫的两端的服务器必须被配置为通过诸如因特网的公共网络来建立和接收呼叫。

如果因为某些原因导致不能成功建立IP呼叫，则呼叫者必须退回到标准的电话呼叫，这要求使用不同的联系信息(电话号码)并且经常完全在不同的装置(电话而不是视频端点)上来进行新的呼叫尝试。

因此，在本领域中需要将使用外部组织中的个人的电话号码联系该个人的熟悉性和可用性与全IP呼叫的质量结合，适当时包括视频和补充协议。

电话号码是建立已久的进行电话呼叫的方法。它们以分级的方式来布置，第一个数字是世界区域，随后是国家代码、在该国家内的地区的国家直拨代码等等至越来越具体的等级。图1示出由一些国家采用的H.323全球拨号方案(GDS)，该方案重新使用电话呼叫的分级系统。GDS利用网守的分级系统，其中，前缀指示在分级中的网守等级，即，00指示世界网守，0044指示英国网守等等。

呼叫协议(例如，SIP、H.323)具有标准端口(5060用于SIPUDP/TCP，5061用于SIP TLS，1720用于H.323)——只要待呼叫的组织已经使用这些，不必指定端口。

一些端点(Tandberg MXP、Lifesize)使用来自同一地址的不同呼叫协议来进行多个连接尝试，例如，首先尝试SIP，然后如果没有成功地应答，则尝试H.323。因为呼叫尝试是按顺序进行的，并且仅当先前的协议已被拒绝或超时才尝试以后的协议时，这种方法具有缺点，它连接缓慢或者会失败。该方法也可能不适用于所有的地址，因为不同的协议使用不同形式的地址(SIP使用usernamehostname形式的URI，H323使用具有选用的E164号码的主机名称等等)。

TANDBERG IP网关是外部IP呼叫的单个进入点，可向这些IP呼叫提供自动产生的选项输入屏幕，并且/或者使用拨号规则来路由它们。该网关被设计来理解尽可能多的协议，使得用户仅须公布他的可从外部联系的主机名称。

DNS是建立已久的系统，用于在全球唯一的人可读域名和可以用于联系在因特网上提供的服务的IP地址之间的转译。

诸如Cisco Call Manager的PBX系统具有相当大的商业组织的普及率。它们提供用于从它们的内部呼叫协议向用于外部呼叫的标准电话呼叫转译的设施，并且能够在给定正确的配置的情况下，通过向电话拨打号码来使用诸如SIP的协议进行IP呼叫。

发明内容

本发明的目的是提供方法、计算机程序和系统，用于在呼叫者对于被呼叫的个人的IP能力没有任何了解的情况下允许使用IP通信装置的个人使用诸如电话号码的单个标识符来联系外部组织中的个人。

与这种新的系统兼容的呼叫服务器注册如下范围的电话号码：通过这些电话号码，可以使用经由因特网可全球访问的地址注册表或注册表集合来达到它们的用户。

当用户意欲对外部组织中的个人进行呼叫时，他们录入该个人的电话号码，就像进行标准电话呼叫那样。然后呼叫客户机或代表客户机的呼叫服务器的用户联系地址注册表，以查询联系信息是否可用于那个号码。如果可用，则注册表返回用于进行向组织的IP媒体呼叫所需的联系信息，包括该组织支持的呼叫协议、地址、端口等。

如果呼叫系统支持在使用中的协议的至少一种，则它可以使用联系信息来无缝地向用户试图联系的个人建立IP呼叫，其中具有IP的所有固有优点。然而，如果地址注册表未提供被支持的协议或地址注册表不包含与那个电话号码相关联的联系信息，则呼叫系统可以(在没有用户介入的情况下)退回到向原始输入的号码进行标准电话呼叫。

尽管提供了呼叫者的系统支持的通过IP呼叫的方法，如果因为缺少网络可用性而失败，则呼叫者具有作为最后手段的退回到电话呼叫的选择。

在所包含的独立权利要求中限定的特征表征所述方法、所述计算机程序和所述系统。

附图说明

为了使得本发明能够更容易理解，下面的讨论将参考附图，其中：

图1示出现有技术的分级H.323全球拨号方案；

图2图示根据本发明的示例性通信系统；

图3图示根据本发明的注册表的示例性结构；

图4图示被上传到运行客户机应用电话簿列表屏幕的移动通信装置的根据本发明的注册表的示例性注册分组；以及

图5是示出根据本发明的示例性通信会话的流程图。

具体实施方式

下面，将通过描述优选实施例并且通过参考附图来讨论本发明。然而，本领域内的技术人员可以实现在如所包含的独立权利要求中限定的本发明的范围内的其他应用和修改。

本发明引入了新颖系统和新颖方法，用于在呼叫者对于被呼叫的个人的IP能力没有任何了解的情况下允许使用IP通信装置的个人使用诸如电话号码的单个标识符来联系外部组织中的个人。这被用于与例如全球地址数据库(GAD)的注册表装置进行通信。GAD包含对于注册的号码的联系信息，诸如IP能力。当试图进行至给定号码的呼叫时，在呼叫方的场点的呼叫服务器或类似设施物从GAD请求与该号码相关的联系信息，然后基于从GAD接收的信息来建立呼叫。

图2是示出根据本发明的系统的典型配置的框图。

所述系统包括至少一个GAD 21、呼叫服务器31、通信网络41与两个通信装置11和12。通信网络41通常是采用诸如H.323、SIP、Jingle等协议的分组交换网络，但是也可以是诸如PSTN的电话交换网络。类似地，通信装置11和12通常是在诸如H.323、SIP、Jingle等的至少一个协议上支持呼叫的通信装置，但是也可以是常规的电话机。呼叫服务器31可以是任何种类的呼叫服务器，诸如PBX、网关、网守或具有集成的呼叫服务器功能的端点。

在一个示例性实施例中，例如GAD的单个注册表可以存储和在全世界范围内分发所有的联系信息，如图3的示例1。

然而，随着增长的需求，采用多个注册表以减少在任何给定注册表上的负荷可能更有益。图3的示例3的部署多个注册表的一个示例性实施例用于具有单个联系点的任何给定呼叫装置，在大多数情况下，在地理上最近的注册表具有降低查询的延迟、限制越洋流量等优点。在这个实施例中，或者通过本地高速缓存，或者当需要时通过将呼叫者重定向到另一个注册表，每一个注册表能够提供对完整的记录集合的访问。已经对于DNS开发了用于实现这样的系统的成熟策略，包括故障备援和在注册表之间的联系信息传播。

如GDS那样，电话号码的特性也允许实现其他策略。在如图3的示例3的另一个示例性实施例中，电话号码的前几个数字用于确定目的地的世界区域、目的地的国家和更细的划分区域。因此，建立了注册表集合，呼叫系统联系与它们寻求识别的电话号码表示的地理区域对应的注册表。虽然这意味着呼叫者可能必须联系多个注册表而不是单个最近的注册表以检索多个国际呼叫的联系信息，但是这也意味着每一个注册表仅需要存储用于其地理区域的联系信息，而不是联系详情的全球总体。

显然，许多其他策略也是可能的。不论是否使用单个全球注册表或多个注册表，查询的句法和联系信息的上传将保持不变，以允许在注册表的部署上的灵活性，并且给出从一个策略向另一个策略迁移的可能，如果这样做看起来有益的话。

全球地址数据库(GAD)包含把下面称为电话号码的单个标识符与IP联系信息彼此关联的信息。这样的信息被从上传实体上传到GAD。上传实体可以是组织的网守，但是也可以是普通的网络连接的计算机。电话号码作为单个号码或号码范围被提供到GAD。注册号码范围通常用于注册前缀(例如，+47 67 833 000至+47 67 833 999对应于注册前缀+47 67 833)，但是在已经向组织分配电话号码的范围而不是简单前缀的情况下，则注册所分配的范围(例如，注册在+47 67 833 200至+4767 833 700范围中的号码)。

上传实体和从GAD接收信息的任何呼叫装置需要理解联系信息，然而，GAD本身不必理解它包含的信息。这具有几个优点，一个是GAD不必对联系信息做句法分析，因此导致加速请求处理。另一个优点是可以向注册表添加新的协议，而不必更新注册表本身。

在本发明的一个示例性实施例中，GAD区分各个协议，使得GAD提供只用请求实体能够使用的协议请求的联系信息，并且也允许上传实体重写单个协议数据集合，而不必修改所有的其他的协议数据集合。因此，协议数据与用于标识协议的协议名称字段(例如，SIP、H323、Jingle等)配对。按照GAD不必理解协议，不需要在所允许协议名称上的预先批准的列表。

各个协议数据字段的格式通常经由中央的安全管理机构或通过诸如RFC的系统被建立为某个标准。这样的数据通常具有键/值对的形式，因此良好地适合于RFC 822或XML的使用。在图4中示出向GAD上传的联系信息分组的示例性实施例。示例1示出了注册具有对应的国家代码86的号码范围1085199700至1085199799的联系信息分组。该信息分组的联系信息部分包括关于使用TLS协议在端口5060、5061上以具有IP号码10.2.133.149的SIP装置来服务所注册范围的号码的信息。

示例2示出注册单个号码的联系信息分组，其中，有两种不同的可用联系的可能性，Jingle和H.323。如图4中所示，协议数据集合可以取决于上层协议而包含不同值，例如，SIP可以经由UDP、TCP和TLS来进行通信，因此可能需要向其交流下层协议的哪个被支持。

如上所述，数据字段对于GAD没有客观含义，可以使用不同的格式来注册数据，例如，在图4中，使用RFC 822来编码SIP数据，XMPP/Jingle数据是用于描述在注册消息的XML内嵌入的tar端的能力的XML节，并且以键/值对的列表来表达H.323协议数据。

虽然联系信息是在外部请求下提供的公共记录的事项，但是显然，上传联系信息非常敏感，并且应当采取措施来最小化恶意的或错误配置的第三方上传信息的能力。因此，虽然可以使用包括诸如HTTP、FTP、SMTP、NNTP和XMPP的基于因特网的协议的任何适当协议来向GAD上传联系信息分组，但是有益的是，使用具有数字签名的或身份认证和加密的方法。

在本发明的一个示例性实施例中，可以设想三层安全措施。

1)身份的确认。上传实体在向GAD上传联系信息时可能需要提供用户名和密码。这通常包括使用与由根安全管理机构(在该情况下，为GAD的安全管理机构)提供的带有签名的子证书耦合的诸如TLS的加密传输协议或通过因特网连接提供实体的其他这样的成熟方法。

2)对于记录改变的限制。在上面未提供保护的情况下(例如，有效但是错误配置的呼叫服务器)，重要的是，限制上传实体可以做的改变。合理的限制是对于可注册的前缀的短小程度设置下限(例如，不允许一实体注册诸如+44的整个国家代码)，不允许涵盖已存在范围的任何范围，限制单个实体可注册范围的数量等等。

3)对于访问的限制。相对于对联系信息的请求的数量，记录上传的数量较小并且不那么严格要求时间，因此，可能对大量用户施加未很好调整的额外约束。一种示例性选择是对白名单实体的注册表的安全管理机构允许向注册表上载联系信息。另一种示例性选择是安全管理机构在应用联系信息之前验证联系信息中的改变(例如，通过经由电话或电子邮件来联系组织)。可以甚至决定，仅安全管理机构可以上传联系信息，并且要求进行上传的组织必须以书面、通过电话或通过某种其他方法来申请。

根据本发明的示例性呼叫装置通常知道其自身的位置，因此当查询GAD时，它可以提供包括地区和国家代码的完整电话号码。这使得呼叫装置不使用地区代码和/或国家代码来拨打本地号码。

在一个替代实施例中，呼叫装置连接到位置专有的GAD，即，呼叫者装置联系国家地址注册表，而无需包括国家代码。在该情况下，国家地址注册表知道产生完整的查询电话号码所需的信息。

而且，除了被呼叫的号码，联系信息请求还可以包括呼叫者装置支持的协议；这使得地址注册表针对呼叫装置理解的协议来筛选它要返回的协议，从而在联系信息包括大量被支持协议的情况下显著地减小返回分组的规模。

尽管任何协议/传输机制可以用于这样的请求，但是UDP是非常适合的，因为仅返回结果的单一集合，并且在任何一个方向上丢失的分组可以通过下述方式简单地处理：如果在特定时间段后还未接收到响应则呼叫装置重发请求。

与诸如DNS的系统一样，客户机实现可以高速缓存外部地址的联系信息，使得不用联系地址注册表而进行对同一号码范围的以后的呼叫。在本领域中已知的各种策略可用于平衡由于过期的联系信息导致的呼叫失败和使用每一个呼叫来轮询地址注册表之间的折中(例如，在呼叫失败后更新信息，如果自最后的成功呼叫起已经过去了超过固定时间段则更新关于呼叫的信息，如果自随后一次更新信息起已经过去了超过固定时间段则更新关于呼叫的信息等等)。

下面参考图5来描述根据本发明的从呼叫装置向外部组织中的装置建立呼叫的示例性方法。方法在步骤51开始，其中，第一呼叫装置的用户录入外部电话号码，并且呼叫装置建立与通常位于内部网络的边界处的呼叫服务器的连接。如果用户未录入完整的电话号码，则呼叫服务器可以向录入的电话号码添加地区和/或国家代码。

然后，在步骤52中，呼叫服务器从与该号码相关的GAD请求联系信息。GAD可以是单个服务器，但是也可以包括如上所述的多个在地理上分布的服务器。然后在步骤53呼叫服务器等待来自GAD的有效响应。

来自GAD的有效响应或者是一个或多个协议名称-数据对的集合，或者是没有任何适当的联系协议数据可用的消息(或者是因为所请求的号码在地址注册表中没有相关联的联系信息，或者数据存在但是该请求指定了它支持的协议集合而这些不匹配为那个条目存储的协议的任何一种)。地址注册表也可以返回联系信息有效的电话号码范围，以允许呼叫装置和/或呼叫服务器更有效地高速缓存信息。如果在步骤54中在特定时间后未接收到有效响应，或GAD响应不包含联系信息，则在步骤60，呼叫服务器建立至所请求的号码的标准电话呼叫。

在步骤55中，呼叫服务器对从GAD接收的联系信息做句法分析，以查看呼叫服务器是否支持在联系信息中列出的协议的任何一种。如果呼叫服务器不支持所接收的协议的任何一个，则呼叫服务器在步骤60建立中所请求的号码的标准电话呼叫。

如果存在超过一个的有效协议，则呼叫服务器选择哪个协议最适合；在联系信息中的参数可以帮助进行这种选择(例如，一个协议数据集合可能声明它仅可以接受经由TLS的连接，而呼叫服务器不支持经由TLS的连接，则允许立即丢弃它，而另一种协议数据可能声明它仅支持用于外部呼叫的384k较低带宽的呼叫，使得这比没有这种带宽限制的第三协议不那么有吸引力等等)。在一个示例性实施例中，呼叫服务器将建立在当前支持的协议上的排出优先级的列表。

已经选择了优选协议后，呼叫服务器然后在步骤56尝试使用该协议数据建立至外部位置的呼叫。这个呼叫的精确的格式将是协议相关的，并且连同协议数据的格式被一起定义；协议数据通常包括地址、端口和其他联系信息。如果需要，该定义还可以包括用于识别呼叫应当被路由到哪个个人的远程服务器的方法：最简单的方法是使用完整的电话号码作为用户名、e164或其他协议用户标识符。然而，更复杂的方法也是可能的，诸如应用到电话号码使得仅发送其一部分的掩码。

如果在步骤58呼叫由于非网络或非协议错误而失败(例如，在远端的个人选择拒绝呼叫，远程服务器报告没有具有那个号码的用户等等)，则在步骤62，呼叫应当失败，并且不应当尝试其他协议/电话，并且应当向用户通知呼叫失败和原因。

然后，在步骤59，如果由于网络或协议错误而不能建立呼叫，则呼叫服务器在步骤57从优选协议列表去除协议，并且在步骤60尝试在列表的下一个最优选的协议上建立呼叫等，直到没有剩余协议，此时，呼叫服务器建立至所请求的号码的电话呼叫。

如果呼叫成功，则用户在步骤61已经成功地与IP呼叫连接，并且具有IP呼叫的所有优点。

参考图2，在下面描述了示例性呼叫情况。考虑已经访问了呼叫装置E5的用户A，用户A希望建立至不同组织内的用户B的例如视频呼叫的IP呼叫。用户A不知道用户B是否能够接受视频呼叫或任何其他IP呼叫，用户A仅具有带有用户B的电话号码的名片。为了讨论方便，假设用户B在图4的示例2的GAD 21中注册。

用户A在呼叫装置E5上录入用户B的电话号码+44 2079012400，呼叫装置E5然后连接到用户A的组织的呼叫服务器31。呼叫服务器然后向GAD 21发送请求，请求与用户B的电话号码相关的联系信息数据。在这个示例中，呼叫服务器仅支持H.323和SIP，并且仅请求接收支持这种协议的联系信息。在该情况下用户B支持XMPP-Jingle和H.323，但是由于未请求XMPP-Jingle信息，GAD向呼叫服务器发送H.323信息，即，可以使用扩展1719在网守montague.lit 32上通过H.323达到用户B。

呼叫服务器31然后使用H.323协议通过IP网络41连接到网关32，并且呼叫服务器32将呼叫连接到用户B的通信装置E6，并且建立IP呼叫。然而，如果呼叫服务器在试图联系网关时接收到网络协议错误，则呼叫服务器将丢弃H.323呼叫，并且试图建立至用户B的电话呼叫。

在另一种示例性呼叫情况中，呼叫服务器31支持H.323和XMPP-Jingle，在该情况下，GAD返回H.323和XMPP-Jingle联系信息数据。呼叫服务器可能优选协议之一并且建立排出优先级的协议呼叫列表，或者仅随机地列出要呼叫的协议。在任何一种情况下，呼叫服务器首先尝试协议之一，例如，H.323。呼叫服务器然后使用H.323协议通过IP网络41连接到呼叫服务器或网关32。如果呼叫服务器在试图连接到网关时接收到网络协议错误，则呼叫服务器将丢弃H.323呼叫，并且试图使用在列表中的下一个协议——在该情况下为XMPP-Jingle——来建立呼叫。再一次，如果呼叫服务器接收到网络错误，则呼叫服务器丢弃该呼叫，并且试图建立至用户B的电话呼叫，否则，建立使用Jingle的IP连接。

在又一个示例性情况下，用户B未被列在GAD中，GAD向呼叫服务器通知未对该号码注册联系信息数据，在该情况下，呼叫服务器试图使用请求的电话号码来建立至用户B的电话呼叫。

虽然所说明的本发明与电话号码相关，但是本领域内的技术人员能够容易地认识到，仅需适度的调整，该系统可以设想用于进行呼叫的标识符的替代手段(电子邮件地址、社会保险号码、国家ID号码等)。

Claims (26)

1.一种使用单个标识符来建立呼叫的系统，所述系统包括注册表装置、呼叫服务器和与通信网络连接的两个或更多的通信装置，

所述系统的特征在于，

所述注册表装置被配置用于：

从上传装置接收与单个标识符或标识符范围相关的联系信息，所述联系信息包括联系与所述标识符相关联的通信装置的至少一个呼叫协议，

存储从所述上传装置接收的所述联系信息，

当从呼叫服务器请求与标识符相关的联系信息时，检索所存储的联系信息，并且发送包括所述联系信息的消息，

所述呼叫服务器被配置用于：

从第一通信装置接收建立至与所述单个标识符相关联的第二通信装置的呼叫的请求，

向所述注册表装置请求与所述单个标识符相关的联系信息，

从所述注册表装置接收与所述单个标识符相关的所述联系信息，并且

使用联系所述第二通信装置的所述至少一个呼叫协议之一建立所述第一通信装置和与所述标识符相关联的所述第二通信装置之间的呼叫。

2.根据权利要求1所述的系统，其中，如果未能使用联系所述第二通信装置的所述至少一个呼叫协议之一建立所述第一通信装置和与所述标识符相关联的所述第二通信装置之间的呼叫，则所述呼叫服务器被配置为使用联系所述第二通信装置的所述至少一个呼叫协议的第二个来建立所述呼叫。

3.根据权利要求1所述的系统，其中，所述联系信息包括与所述标识符相关联的通信装置所支持的至少一个IP协议。

4.根据前述权利要求之一所述的系统，其中，当向所述注册表装置请求与所述单个标识符相关的联系信息时，所述呼叫服务器被配置为在所述请求中包括所述呼叫服务器所支持的至少一个协议。

5.根据权利要求4所述的系统，其中，在发送包括所述联系信息的消息时，所述注册表装置被配置为仅包括所述呼叫服务器所支持的所述至少一个协议。

6.根据前述权利要求之一所述的系统，其中，在检索与标识符相关的所存储的联系信息并且在所述注册表中不存在合适的协议或在所述注册表中不存在联系信息时，所述注册表装置被配置为发送指示没有合适的联系信息可用的消息。

7.根据权利要求1、2或6所述的系统，其中，在接收到没有合适的联系信息可用的消息时或在所述呼叫服务器已经根据联系所述第二通信装置的所有可用呼叫协议尝试了建立呼叫，所述呼叫服务器被进一步配置为使用作为电话号码的所述标识符来建立电话呼叫。

8.根据前述权利要求之一所述的系统，其中，所述单个标识符是电话号码。

9.根据权利要求1-7之一所述的系统，其中，所述单个标识符是电子邮件地址。

10.根据权利要求1-7之一所述的系统，其中，所述单个标识符是社会保险号码。

11.根据权利要求1-7之一所述的系统，其中，所述单个标识符是国家ID号码。

12.根据前述权利要求之一所述的系统，其中，所述呼叫服务器功能被包含在通信装置中。

13.根据前述权利要求之一所述的系统，其中，联系与所述标识符相关联的通信装置的所述至少一个呼叫协议是SIP、H.323和Jingle的至少一个。

14.一种在系统中使用单个标识符来建立呼叫的方法，所述系统包括注册表装置、呼叫服务器和与通信网络连接的两个或更多的通信装置，

所述方法的特征在于包括步骤：

使用所述注册表装置从上传装置接收与单个标识符或标识符范围相关的联系信息，所述联系信息包括联系与所述标识符相关联的通信装置的至少一个呼叫协议，

在所述注册表装置中存储从所述上传装置接收的所述联系信息，

当从呼叫服务器请求与标识符相关的联系信息时，在所述注册表中检索所存储的联系信息，并且发送包括所述联系信息的消息，

用所述呼叫服务器从第一通信装置接收建立到与所述单个标识符相关联的第二通信装置的呼叫的请求，

用所述呼叫服务器向所述注册表装置请求与所述单个标识符相关的联系信息，

用所述呼叫服务器从所述注册表装置接收与所述单个标识符相关的所述联系信息，并且

用所述呼叫服务器使用联系所述第二通信装置的所述至少一个呼叫协议之一建立所述第一通信装置和与所述标识符相关联的所述第二通信装置之间的呼叫。

15.根据权利要求14所述的方法，其中，如果未能使用联系所述第二通信装置的所述至少一个呼叫协议之一建立所述第一通信装置和与所述标识符相关联的所述第二通信装置之间的呼叫，则所述呼叫服务器使用联系所述第二通信装置的所述至少一个呼叫协议的第二个来建立所述呼叫。

16.根据权利要求14所述的方法，其中，所述联系信息包括与所述标识符相关联的通信装置所支持的至少一个IP协议。

17.根据权利要求14-16之一所述的方法，其中，当向所述注册表装置请求与所述单个标识符相关的联系信息时，所述呼叫服务器在所述请求中包括所述呼叫服务器所支持的至少一个协议。

18.根据权利要求17所述的方法，其中，在发送包括所述联系信息的消息时，所述注册表装置包括由所述呼叫服务器支持的所述至少一个协议。

19.根据权利要求14-18之一所述的方法，其中，在检索与标识符相关的所存储的联系信息并且在所述注册表中不存在合适的协议或在所述注册表中不存在联系信息时，所述注册表装置发送用于指示没有合适的联系信息可用的消息。

20.根据权利要求14、15或19所述的方法，其中，在接收到没有合适的联系信息可用的消息时或在所述呼叫服务器已经根据联系所述第二通信装置的所有可用呼叫协议尝试了建立呼叫，所述呼叫服务器使用作为电话号码的所述标识符来建立电话呼叫。

21.根据权利要求14-20之一所述的方法，其中，所述单个标识符是电话号码。

22.根据权利要求14-20之一所述的方法，其中，所述单个标识符是电子邮件地址。

23.根据权利要求14-20之一所述的方法，其中，所述单个标识符是社会保险号码。

24.根据权利要求14-20之一所述的方法，其中，所述单个标识符是国家ID号码。

25.根据权利要求14-24之一所述的方法，其中，所述呼叫服务器功能被包含在通信装置中。

26.根据权利要求14-25之一所述的方法，其中，联系与所述标识符相关联的通信装置的所述至少一个呼叫协议是SIP、H.323和Jingle的至少一个。

Images