CN101491071A

CN101491071A - 使用目录服务方案来管理电话呼叫路由

Info

Publication number: CN101491071A
Application number: CNA2007800273539A
Authority: CN
Inventors: R·Y·马克西莫; D·A·克努森; V·艾戴尔曼; M·塞卡莱
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2006-07-20
Filing date: 2007-07-18
Publication date: 2009-07-22
Anticipated expiration: 2027-07-18
Also published as: EP2044760A4; JP5081912B2; JP2009545208A; WO2008011082A3; KR20090032079A; IL195967A0; US7831034B2; EP2044760A2; WO2008011082A2; US20080043976A1; CN101491071B

Abstract

用于电话呼叫管理的目录服务方案。该方案便于将呼叫路由规则开发成一个或多个类的一个或多个实例。一旦创建了规则，规则即可被传播给所有其他目录服务服务器，且任何后继的更新和系统改变可被容易地传播以维护最佳的呼叫系统管理。规则可被存储在路由表中，这允许管理员为各种场景定义电话路线。系统硬件/软件改变可使用标识名管理，并被自动传播(或复制到)企业网络上的其他目录服务服务器。该体系结构包括用于生成目录服务方案的方案组件，以及根据由目录服务方案定义的呼叫路由规则路由电话呼叫的呼叫路由组件。可结合使用属性的策略和电话号码模式/范围来处理规则以管理呼叫路由。

Description

使用目录服务方案来管理电话呼叫路由

背景

公司在多个地理位置的本地的、区域性的、全国性的甚至国际的扩张对信息管理资源施加了额外的负担。企业网络提供互连这些位置以支持基于IP和基于电话的通信的手段。IP和电话系统管理在维持公司在行业内的竞争姿态方面担当重要角色。

众多公司采用PBX(专用小交换机)电话系统来管理雇员、顾客和/或供应商之间的大量呼叫。一般，PBX可要求个别的系统级上的配置。因此，在每一公司PBX位置处都需要电话系统管理员，或者即使不是这样，也向区域中的各系统分派电话系统管理员，使得配置和故障排除可用相对方便的方式进行。该限制不仅需要额外的资源来掌管多个单独的系统管理，而且在公司具有可包括多个PBX以处理公司电话通信的企业网络时增加了技术管理的成本。而且，当公司是国际公司(这是扩张的全球经济中日益增长的趋势)时，维护电话通信系统的完整性可能极其重要。设备故障、硬件/软件更新过程和/或离线功能均可能影响公司的底线。从而，在大型公司环境甚至外包这种管理责任的较小的公司中，可能需要人员24小时监督管理以解决系统问题。

而且，当公司位置在不同国家时，例如当VoIP(IP上的语音)呼叫可穿越诸如因特网等全球通信网络达到本地或公共交换电话网络(即PSTN)时，每个国家可能具有不同的规章制度。VoIP电话系统是由多个互相依赖的部分组成的动态系统。当网关停机或从系统中移除时，必须动态更新电话路由规则以防止丢失呼叫。而且，为了在这些国家中出售VoIP产品和解决方案，必须紧密监控和遵循对国家规章的遵守。另外，不断变化的规章可能是难以适应且适应起来是复杂的，更不用说预期驱动电话系统和网络的硬件和/或软件的设计了。因此，高效地管理电话系统操作的能力可能对公司的成败具有显著影响。

概述

以下呈现了本发明的简化概述，以提供对所公开的本发明的某些方面的基本理解。该概述不是详尽的概观，它不旨在标识关键/重要的元素，也不旨在描绘其范围。其唯一的目的是以简化的形式来介绍一些概念，作为稍后提出的更为详细的描述的序言。

所公开的体系结构提供了在多个电话系统(例如，与企业系统相关联)处高效地处理电话管理硬件和/或软件的机制。这是由用于呼叫管理的目录服务方案的实现完成的。目录服务允许用户通过查询目录以获得匹配一个或多个对象属性的列表来基于属性找到任何对象(例如，用户、系统、资源和服务)。可修改该方案以实现新类型的对象或对象特性。

对所公开的体系结构的利用意味着不再需要管理员对每一个别的电话系统(例如，PBX—专用小交换机)指定路由规则。而且，代替使用由字段和记录组成的数据库表来表示规则，规则被表示为类的实例。通过使用管理员可定义的使用表，给予管理员为各种场景创建电话路由的灵活性。例如，当管理员从系统中移除网关或删除使用策略时，使用标识名(DN)，可自动更新电话路由规则。换言之，在一个服务器(运行目录服务)处改变的规则被自动传播(或复制)到网络上其他目录服务服务器。因此，电话路由的完整性得以维持，从而防止呼叫进入“死”网关。

为对此支持，此处所公开和要求保护的是便于呼叫管理的计算机实现的系统。该系统包括用于生成目录服务方案的方案组件，以及根据由目录服务方案定义的呼叫路由规则来路由电话呼叫的呼叫路由组件。处理各个规则以使得路由组件在电话通信框架(例如，PSTN—公共交换电话网络、蜂窝网络)上路由呼叫。在又一示例中，呼叫路由组件在电话通信框架上路由呼叫，这包括接口到VoIP(IP上的语音)通信系统。

在又一替换实现中，采用一机器学习和推断组件，该组件使用基于概率和/或基于统计的分析以预测或推断用户希望自动执行的动作。

为了实现前述及相关目的，在这里结合下列描述及附图来描述所公开的本发明的某些说明性方面。然而，这些方面仅指示了其中可利用此处公开的原理的各种方法中的少数几种，且旨在包括所有这些方面及其等效方面。结合附图阅读下面的详细描述，则其他优点和新颖特征将变得清楚。

附图简述

图1示出了便于呼叫管理的计算机实现的系统。

图2示出了根据所公开的体系结构的管理呼叫的方法。

图3示出了用于管理呼叫的企业呼叫管理系统。

图4示出了可在目录服务中采用的一组示例性API的表。

图5示出了使用较短的用户友好名字串来定义使用属性的示例性属性表。

图6示出了用于使一个或多个用户与在图5中定义的使用属性的策略相关联的示例性用户表。

图7示出了示例性路由表。

图8示出了使用路由规则的呼叫处理和路由的方法。

图9示出了结合用户策略使用路由规则的呼叫处理和路由的替换方法。

图10示出了在路由规则中采用呼叫目的地号码范围和/或模式的方法。

图11示出了利用策略来进行呼叫路由的方法。

图12示出了在目录服务呼叫管理系统中更新类改变的方法。

图13示出了采用便于自动化一个或多个特征的机器学习和推理组件的替换系统。

图14示出了采用调停网关来管理网关通信的替换系统。

图15示出了根据所公开的呼叫路由体系结构的分布式目录服务和规则类/属性定义的一个示例性方案。

图16示出了用于向管理员(或用户)交互提供所公开的呼叫目录服务的各个特征的示例性通信程序UI。

图17示出了用于配置媒体网关的中间向导窗口。

图18示出了预备向导的附加预备窗口。

图19示出了便于管理员对条目(或规则)的控制的一系列窗口。

图20示出了当选择图19的窗口的电话选项卡时演示的UI。

图21示出了当选择图19的窗口的网关选项卡时演示的UI。

图22示出了可用于执行根据所公开的体系结构的目录服务和呼叫路由规则的计算机(或服务器)的框图。

图23示出了支持根据所公开的体系结构的用于呼叫管理的目录服务的示例性计算环境的示意性框图。

详细描述

现在参照附图描述本发明，其中相同的附图标记用于指代全文中相同的元素。在以下描述中，为解释起见，描绘了众多具体细节以提供对本发明的全面理解。然而，显然，本发明可以在没有这些具体细节的情况下实现。在其它情况下，以框图形式示出了公知的结构和设备以便于描述它们。

所公开的体系结构提供了在多个电话系统(例如，与企业系统相关联)处高效地处理电话管理硬件和/或软件的机制。这是由用于呼叫管理的目录服务方案的实现完成的。目录服务允许用户通过查询目录以获得匹配一个或多个对象属性的列表来基于属性找到任何对象(例如，用户、系统、资源和服务)。在一个实现中，目录服务采用由一方案定义的规则。该方案是单个、可修改且可扩展的方案。该方案是提供关于目录服务对象的结构要求的一组对象和规则。可修改该方案以实现新类型的对象或对象特性。示例对象可以是具有标识其名字、位置、端口和其他所需信息的属性(或特性)的网络网关。

利用方案来彼此区分对象类(例如，用户和网关)。方案信息允许管理员向对象类添加属性，并使类跨网络分发给其他服务器而无需重启任何域控制器(在其他位置处运行目录服务的服务器)。每一对象用被称为标识名(DN)的LDAP(轻量目录访问协议)属性来唯一地标识。

通过利用分布式目录系统，可一次创建路由规则(例如，最小成本路由(LCR)规则)并一律应用于受到影响的所有系统。LCR规则例如允许企业经由最为成本有效的路径智能地路由呼叫而不会影响经营过程。例如，可实现语音服务平台以基于例如涉及用户概况、费率、网络可用性、线路质量、地理差异、消息大小和信号质量等特性使用可用于路由呼叫的任何类型的媒体和技术。

对所公开的体系结构的利用意味着不再需要管理员对每一个别的电话系统(例如，PBX—专用小交换机)指定路由规则。而且，代替使用由字段和记录组成的数据库表来表示规则，规则被表示为类的实例。通过使用管理员可定义的使用表，给予管理员为各种场景创建电话路由的灵活性。例如，当管理员从系统中移除网关或删除使用策略时，使用DN，可自动更新电话路由规则。换言之，在一个服务器(运行目录服务)处改变的规则被自动传播(或复制)到网络上其他目录服务服务器。因此，电话路由的完整性得以维持，从而防止呼叫进入“死”网关。

一开始参考附图，图1示出了便于呼叫管理的计算机实现的系统100。系统100包括用于提供分布式目录服务104的服务组件102，以及根据呼叫路由规则110路由电话呼叫108(例如，陆线呼叫、手机呼叫、VoIP呼叫...)的呼叫路由组件106。规则110由目录服务方案113定义，该方案可使用方案组件112生成。处理规则110以使得路由组件106在电话通信框架114(例如，PSTN公共交换电话网络、蜂窝网络)上路由呼叫108。在又一示例中，呼叫路由组件106在电话通信框架114上路由呼叫108，这包括接口到IP网络(例如，因特网)以进行VoIP(IP上的语音)通信。

呼叫路由规则110可例如包括最小成本路由(LCR)处理，使得(企业的)发起呼叫被处理成经由更好的路线(可以是VoIP)路由的传出呼叫。其他规则可包括但不限于：一天中的时间、一周中的日子、所要求的服务质量等。从而，规则110中的一个或多个将标识用于呼叫路由的网关(未示出，例如提供IP网络和诸如PSTN和本地PSTN基础架构的电话网络之间的接口)。

在方案113中例如用对象、对象类和类实例来定义规则110。另外，可为每一用户或每一组用户创建一个或多个使用策略116。在一个实现中，可组合处理规则110和策略116以确定应如何路由呼叫(例如，VoIP对比PSTN)以及根本上是否应路由该呼叫。例如，如果使用策略指示不允许该用户进行VoIP呼叫路由，则该用户的呼叫将不被路由用于VoIP，即使网络在那时能够处理该呼叫用于VoIP。在替换实现中，独立于策略116来处理规则110用于呼叫路由。

给定所采用的目录服务，服务组件102(例如，目录服务服务器)通过服务器通信框架118(例如，诸如因特网等IP框架)接口至其他兼容的目录服务组件。而且，可以理解，当采用VoIP时，电话通信框架114的各方面可直接接口至服务器通信网络118以便于完成该呼叫。而且，也可采用电缆和/或卫星电视系统用于经由电话和服务器通信框架(114和118)的呼叫通信。

在一个示例性实现中，尽管不是必需的，但是系统100采用诸如微软公司的产品现用目录(Active Directory^TM)等的分布式目录系统。现用目录是服从LDAP的且构建在因特网的域名系统(DNS)上的高级分层目录服务。例如，可对工作组分派如网站等的域名，且任何服从LDAP的客户机都能够获取对其的访问权。另外，目录服务可用作不同种类的企业网络，且涵盖其他第三方目录服务。

所公开的体系结构可使用DN来维护自动同步的策略、使用定义、网关和路线之间的依赖性。例如，如果管理员使一网络设备(例如，VoIP网关)从系统中退役，则该信息将被自动传播给路由规则。然后可更新引用该网络实体(例如，网关)的规则以反映其状态。如果管理员对现有使用定义重命名，则规则和策略会自动引用该新使用名，因此可在无需管理员的任何额外努力的情况下维持系统(例如，VoIP)的完整性。规则可由类和类实例来表示。

硬件可能会掉线并重新上线。例如，网关可从路线引用或不从路线引用。然而，因为网关由路线引用并不意味着它在线。从而，可提供处理静态设备状态(设备在线还是离线)以及动态改变(工作设备状态的活动改变)的逻辑。静态状态可包括设备是如何在目录服务中表示的。动态状态是基于对设备做某些事情的请求从工作设备中接收的实时反馈。

例如，在VoIP系统中，由于构建该系统可能涉及多个服务器，因此每个服务器应用同样的路由逻辑统一配置。通过利用所公开的目录服务来发布电话路由规则，订阅该服务的每个服务器自动获得对这些规则的更新(这可由管理员来作出)。通过使用可配置使用表，管理员具有配置可满足其业务需求而不会使其系统的设计逻辑过度复杂化的路由规则的灵活性。

图2示出了根据所公开的体系结构的管理呼叫的方法。尽管出于解释简明的目的，此处例如以流程图形式示出的一个或多个方法被示出并描述为一系列动作，但是可以理解和明白，本发明不受动作的次序的限制，因为根据本发明，某些动作可以按不同次序和/或与此处所示并描述的其它动作同时发生。例如，本领域技术人员将会明白并理解，方法可被替换地表示为一系列相互关联的状态或事件，诸如以状态图的形式。而且，并非所有示出的动作都是实施根据本发明的方法所必需的。

在200处，呼叫路由系统的电话路由数据被表示为由类实例组成的一个或多个规则。在202，这一个或多个规则被存储在呼叫路由系统的呼叫路由表中。在204，基于发起呼叫展示这一个或多个规则以便处理。在206，基于写到这一个或多个规则内的路由数据在呼叫网络上路由该呼叫。

现在参考图3，示出了用于管理呼叫的企业呼叫管理系统300。在该特定实现中，系统300包括被配置为用于目录服务的多个服务器(表示为服务器₁、服务器₂...服务器_N，其中N为正整数)。例如，第一服务器302与路由呼叫组件106(用于处理呼叫108)和本地电话通信框架114相关联。第一服务器302包括目录服务104、至少存储路由规则的路由表304、方案113和使用策略116。类似地，第二服务器306与呼叫路由组件308(用于处理呼叫310)和本地电话通信框架312相关联。第二服务器306包括目录服务104、至少存储路由规则的路由表304、方案113(可任选)和使用策略116。最后，第N个服务器314与呼叫路由组件316(用于处理呼叫318)和本地电话通信框架320相关联。第N个服务器314包括目录服务104、至少存储路由规则的路由表304、方案113(可任选)和使用策略116。

如所指示的，提供服务器(302、306...314)以支持公司企业的呼叫路由管理。服务器(302、306...314)通过IP网络322(例如，LAN、MAN—城域网、WAN—广域网、因特网)通信，使得可执行服务、规则、规则表和策略的同步。可以理解，对每一服务器(302、306...314)处的服务、规则、策略和方案的每一个的图示旨在表示其每一个都可根据目录服务体系结构从任何服务器访问。例如，包括第一服务器302的公司总部位置处的管理员可开发该位置的方案113、规则的路由表304和使用策略116。之后，该信息作为数据同步的一部分被传播给其他企业服务器(306...314)，使得例如如果公司服务器302发生故障，则其余的服务器(306...314)可基于路由表和策略的最近数据来维护呼叫管理。在替换实现中，规则表304和/或策略116可被存储在相关联的路由组件106中。

目录服务104可包括逻辑上表示对象类(例如，两个)并被定义来便于呼叫路由过程的管理的一个或多个API(应用程序编程接口)324。API 324将在以下更详细描述。

代替使用数据库表(由字段和记录组成)来表示路由表304中的路由规则(例如，LCR(最小成本路由)规则)，规则被表示为类的实例，在该情况中被表示为目录服务的类对象。例如，对于常规的PBX系统，必须在每一个别PBX系统上指定路由规则。相反，通过利用所公开的体系结构的分布式目录服务104，可一次创建路由规则，并一律应用于所有其他兼容的且类似配置的服务器以便呼叫管理。

分布式目录服务(例如，服务104)便于方便地考虑并解决网络改变或故障。规则对所有企业服务器系统而言是全局的。规则可被存储在一个地方，对其的访问权由所有其他企业系统提供。例如，当网络管理员从系统中移除网关或删除使用数据时，通过使用DN，可自动和/或动态地更新电话路由规则。因此，通过防止呼叫被路由到停用或退役的网关而维持呼叫管理系统300的完整性。而且，通过使用管理员可以定义的使用表，这向管理员给予为各种替换路由连接创建电话路线(或路由规则)的灵活的能力。

为了电话呼叫能到达其目的地，呼叫应被路由到最适当的网络实体(例如，网关)。用于确定如何最佳地路由呼叫(例如，按照LCR)的逻辑可在规则路由表304中定义，该表可由管理员手动配置。代替将这些规则展示为数据库记录，规则被展示为一个或多个类的实例。

在一个实现中，规则包括目的地电话号码的范围或/或模式。当进行电话呼叫时，服务(或服务器)302确定哪一(哪些)规则匹配目的地号码。如果存在一个以上的匹配，则服务器302基于策略116之一的使用字段确定允许该呼叫方使用哪一(哪些)规则。在另一实现中，策略处理可根据对策略信息的模式匹配。如果用户的策略匹配分派给一电话路由规则的使用，则在该路线上引导呼叫。

这也落入路由和/或策略处理包括采用布尔逻辑的规则的本体系结构的构想内。例如，可开发“该策略仅在每天5AM-5PM之间处理”的规则。另一示例组合了路由规则和策略：“用户A在周四6PM到午夜之间在路线F上路由”。换言之，逻辑上执行“规则F AND策略C”。可采用各种逻辑来考虑用户的身份、用户位置、一天中的时间、QoS(服务质量)、用户偏好、优先级、系统特性的成本对收益分析等。这样的能力促进了例如厂商和顾客可定制其自己的系统配置的更直观的实现。

另一实现便于呼叫阻塞。因此，可开发阻塞对某些电话号码(例如，号码1-900)的访问的策略。另一示例仅在给定路线上路由某些类型的信息。例如，如果如分析所获知和推理得到的，随着时间的流逝，一个路线证实比另一路线更为可靠，且传输的信息(例如，最高行政长官)被认为比其他信息更为重要，则可采用使该连接对该用户可用的策略。这些仅是目录服务方案开发和实现所提供的灵活性的一些示例。

图4示出了可在目录服务中采用的一组示例性API的表。API(例如，WMI(windows管理规范))被定义来便于所公开的呼叫管理系统的管理。这些API在逻辑上表示两个类。例如，MSFT_SIPPhoneRouteSetting类的实例将路由规则表示为面向对象的类。在另一示例中，MSFT_SIPPhoneRouteUsageData类的实例将使用属性表示为面向对象的类。

第一特性(由设置号C1标识)是路由规则实例ID(例如MSFT_SIPPhoneRouteSetting::InstanceID)。既没有规定有效值也没有规定默认值。对于经由用户界面向用户展示，在一个实现中，它是从不可用的。在替换场景中，该特性可被展示。第二特性(用设置号C2标识)是提供给路由规则实例ID的一个或多个网关(例如，SIP—会话发起协议网关)的电话号码范围或模式(例如，MSFT_SIPPhoneRouteSetting::TargetPhoneNumbers)。在一个示例中，有效值可包括至多1024个字符的统一字符编码(Unicode)串。该特性的默认值为空。对于经由用户界面向用户展示，在一个实现中，该特性可被展示。目标电话号码可被链在一起，由正则表达式或运算符“丨”作为单个正则表达式来定界。

第三特性(由设置号C3标识)是要路由的网关的列表(例如MSFT_SIPPhoneRouteSetting::GatewayList)。在一个示例中，有效值可包括至多256个字符的完全合格的域名和端口信息(FQDN:PORT)的统一字符编码串数组。该特性的默认值为空。对于经由用户界面向用户展示，该特性可被展示。

第四特性(由设置号C4标识)是电话路线使用数据(例如MSFT_SIPPhoneRouteSetting::PhoneUsage)。在一个示例中，有效值可包括数组(MSFT_SIPPhoneRouteUsageDatsa::UsageDNs)。对于经由用户界面向用户展示，该特性可被展示。

第五特性(由设置号C5标识)是电话路线描述(例如MSFT_SIPPhoneRouteSetting::Description)。在一个示例中，有效值可包括至多1024个字符的统一字符编码串。该特性的默认值为空。对于经由用户界面向用户展示，该特性可被展示。

第六特性(由设置号C6标识)是电话路线友好名字(例如MSFT_SIPPhoneRouteSetting::Name)。在一个示例中，有效值可包括至多1024个字符的统一字符编码串。该特性的默认值为空。对于经由用户界面向用户展示，在一个实现中，它是从不可用的。在替换场景中，该特性可被展示。该值应是唯一的。

第七特性(由设置号C7标识)是用于将所匹配的电话号码转换成不同的号码以便载波码插入、转换成可拨格式等的电话路线设置转换(例如MSFT_SIPPhoneRouteSetting::Translation)。在一个示例中，有效值可包括至多1024个字符的统一字符编码串。对于经由用户界面向用户展示，在一个实现中，它可能总是可用的。

第八特性(由设置号C8标识)是电话使用实例ID(例如MSFT_SIPPhoneRouteUsageData::InstanceID)。对于经由用户界面向用户展示，在一个实现中，它是从不可用的。在替换场景中，该特性可被展示。

第九特性(由设置号C9标识)是对象的标识名(例如MSFT_SIPPhoneRouteUsageData::UsageDN)。有效值包括标识名。对于经由用户界面向用户展示，在一个实现中，它是从不可用的。在替换场景中，该特性可被展示。

第十特性(由设置号C10标识)是使用属性名(例如MSFT_SIPPhoneRouteUsageData::Attribute)。在一个示例中，有效值可包括至多256个字符的统一字符编码串。该特性的默认值为空。对于经由用户界面向用户展示，该特性可被展示。

第十一特性(由设置号C11标识)是使用描述(例如MSFT_SIPPhoneRouteUsageData::Description)。在一个示例中，有效值可包括至多1024个字符的统一字符编码串。该特性的默认值为空。对于经由用户界面向用户展示，该特性可被展示。

第十二特性(使用设置号C12标识)是用于将自定义业务逻辑附加到使用上(例如，一天中的时间、服务质量...)的使用附件(例如，MSFT_SIPPhoneRouteUsageData::Attach)。在一个示例中，有效值可包括至多1024个字符的统一字符编码串。该特性的默认值为空。对于经由用户界面向用户展示，该特性可被展示。

注意，该表仅是可定义的特性的类型的一个示例，而不是详尽的列表。另外，注意，也可为大小写敏感格式开发有效值。

图5示出了使用较短的用户友好名字串来定义使用属性的示例性属性表。此处，定义了公司企业的三个城市(城市1、城市2和城市3)，以及相关联的全日制雇员(FTE)和兼职或临时雇员属性描述。另外，本地和长途成本被表示为指示与之相关联的相对成本的一个或多个美元符号“$”。

注意，在一个实现中，定序并定义了一个或多个使用属性以形成被分派给用户类别的策略，该用户类别可以是单个用户或多个用户。在另一实现中，可向每一用户直接分派一组有序的使用属性(其中使用了多个属性)。可以理解，可任凭管理员在所公开的目录服务体系结构中采用任一实现。

图6示出了用于使一个或多个用户与在图5中定义的使用属性的策略相关联的示例性用户表。该表包括两列：列出可以是单个用户和/或用户组的用户类别的用户列，以及将策略列为单个使用属性或多个有序使用属性的策略列。单个属性可以定义策略，多个有序属性也可以定义策略。环境的每个用户和/或用户组可与表示如根据一个或多个使用属性定义的使用容许的策略(例如，MSFT_SIPGlobalUCPolicyData::PhoneUsage)相关联。策略包含按照预定方式定序的一个或多个使用属性。因此，管理员可配置用户策略来便于按所需次序的呼叫路由。

例如，城市1\域用户组中的城市1域用户与具有用于将该组用户的所有呼叫本地路由至城市1的本地载波的单个城市1使用属性的策略相关联。如为第二组所示，第二城市，城市2的用户组，城市2\域用户组中的用户可与具有为执行优先级定序(例如从左向右)的一个以上使用属性的策略相关联。例如，策略的第一使用属性(被表示为本地)用于首先尝试使用目的地电话号码在城市(城市2)内本地电话路由。如果呼叫不能根据本地使用属性本地路由，则将执行策略的第二较低优先级使用属性(表示为长途)来将呼叫路由为长途。而且，如果呼叫不能根据第二使用属性长途路由，则执行策略的更低优先级的第三使用属性(表示为城市2)以将呼叫路由到标识为城市2的路线(实际上是默认路线，对呼叫方而言是的本地的)。因此，可对多个使用属性定优先级以便在用户策略中执行或处理。

类似地，第二城市(表示为城市2)中的所有执行可被归组成执行组，并分派给多个定优先级的使用属性的策略：本地、长途、城市2和城市3。如图所示，可为其他城市分派其他单个或多个使用属性策略。

图7示出了示例性路由表。在该示例中，该表包括用于路线、电话号码模式(或范围)、使用属性和下一中继段的列。例如，使用通配符(*)用于对目的地电话号码的所有串字符执行匹配运算，第一路线(城市1-所有)与第一城市(城市1)相关联。使用属性采用城市1，如图5的属性表中所定义。网关的下一中继段信息(Cityl(城市1)-gw.corp.123.com：Port)定义了下一网关设备的地址和端口，该设备可通过当前路由器或网关的传出端口(PORT)到达。示出了其他示例。

在操作中，接收呼叫方的目的地电话并针对路由表中所列出的模式(或范围)对其处理以找出一个或多个匹配的路由规则。在所匹配的规则中，接下来将所匹配的规则的使用属性与分派给用户或用户组的策略的使用属性进行比较，其中呼叫方是这些用户或用户组的成员。例如，如果将呼叫方定义为城市1\域用户组的成员，则所匹配的规则使用属性将同与该组相关联的策略的单个使用属性城市1进行比较。如可见，如果呼叫方目的地电话号码匹配路由表的第一规则(城市1-所有)，则该规则的使用属性匹配呼叫方是其中成员的组的策略的使用属性。因此，在目的地号码和用户策略中均存在匹配。从而，该呼叫将被路由给该路由规则的下一中继段列中所列出的网关。因此，最佳路线可如管理员所定义地选择。该呼叫然后通过通信框架(例如，PSTN—公共交换电话网络、蜂窝网络、VoIP(IP上的语音)网络...)路由给呼叫目的地系统。

在另一示例中，考虑使用匹配标为城市2-本地的第二规则的号码模式的目的地电话号码进行呼叫的同一呼叫方。由于该呼叫方是具有仅允许根据城市1使用属性进行呼叫的策略的城市1\域用户组的成员，因而在该规则使用属性与呼叫方策略属性之间不存在匹配。从而，阻止该呼叫方进行该呼叫。

图8示出了使用路由规则的呼叫处理和路由的方法。在800，将路由规则表存储在服务器上。如上所示，规则在目录服务方案中被定义为一个或多个类的一个或多个实例。在802，接收具有目的地电话号码的呼叫。在804，针对规则表来处理呼叫目的地号码以找出具有匹配的目的地号码的规则(如在号码的范围或模式中找到)。在806，处理具有匹配的目的地号码的匹配规则。在808，基于匹配规则，将呼叫路由到相应的网关(或呼叫网络接口设备)。

现在参考图9，示出了结合用户使用策略使用路由规则的呼叫处理和路由的替换方法。在900，将路由规则存储在目录服务服务器上的路由表中。规则由类和这些类的实例组成。在902，接收具有相关联的呼叫目的地号码的呼叫以便处理。在904，通过针对路由表规则处理呼叫以找出匹配的目的地号码来启动呼叫处理。如果没有找到匹配，则呼叫失败。在906，然后针对与该用户(或用户是其中成员的呼叫组)相关联的一个或多个策略处理匹配。在908，将由该组的一个或多个策略所定义的使用容许与匹配的电话路由规则的使用属性进行比较。在910，基于规则和策略的属性之间的匹配选择所得的路线(或多条路线)并对其处理以将呼叫路由到相应的呼叫网关系统。

本体系结构构想了可能会发生多个规则和策略的匹配，导致系统要对于要在哪一路线上路由呼叫作出判断。例如，在其中存在电话号码匹配和使用属性匹配的一个实现中，所选路线可根据其中所选路线是按字母次序的第一条路线的字母顺序排序的路线名。该问题的另一解决方案可以是分析在匹配过程中所使用的数据，并基于更为具体的数据来选择路线。这可使用例如解析所需信息以供分析和判断处理的表达式解析器来完成。

也可理解，可对一路线采用多个网关。因此，对网关的选择可根据诸如循环等任何数目的方法。在另一多网关选择实现中，可对网关应用加权值。例如，一个网关可同时支持十个呼叫，而较大容量的网关同时支持四十个呼叫。因此，向较大容量的网关给予权重4/5，使得与较小容量的网关(给予权重1/5)相比，更多的呼叫将被路由给该较大网关。

图10示出了在路由规则中采用呼叫目的地号码范围和/或模式的方法。在1000，使用用于基于一个或多个使用属性将路由规则生成为类的一个或多个实例的目录服务方案启动电话规则生成过程。在1002，为各种类型的使用定义和描述使用属性。在1004，定义用户类别，并将公司用户分派给用户类别。在1006，使用一个或多个使用属性来生成用户策略，并将其分派给每一用户类别(用户和/或用户组)。在1008，规则中所包括的是电话号码的范围和/或模式。在1010，将一个或多个网关分派给电话规则。在1012，规则生成然后完成，且规则被存储在路由表中。

图11示出了利用策略来进行呼叫路由的方法。在1100，使用用于基于一个或多个使用属性将路由规则生成为类的一个或多个实例的目录服务方案启动电话规则生成过程。在1102，为各种类型的使用定义和描述使用属性。在1104，定义用户类别，并将用户分派给用户类别。在1106，使用一个或多个使用属性来生成用户策略，且一个或多个策略被分派给每一用户类别(用户和/或用户组)。在1108，用户策略生成过程完成，且生成包括路线名、路线描述、由使用属性定义的一个或多个使用、一个或多个网关、以及一个或多个目标(或目的地)电话号码的路由规则。在1110，接收电话号码，并针对路由规则对其处理以找出一个或多个匹配的规则。然后针对呼叫方是其中成员的用户类别的策略处理匹配的规则。在1112，如果获得使用属性中的匹配，则流向1114，在那里呼叫被连接至该规则的网关。如果没有匹配的使用属性，则从1112流向1116，在那里呼叫失败，且流程返回以处理下一电话号码。

图12示出了在目录服务呼叫管理系统中更新类改变的方法。在1200，接收并实现分布式目录电话系统(或服务器)以进行电话呼叫路由。在1202，生成使用数据(属性)并将其与用户类别相关联。在1204，生成策略并将其分派给每一用户类别。在1206，基于电话号码模式/范围和一个或多个使用属性将路线和路由规则生成为类的一个或多个实例。在1208，采用DN来自动维护接口至传统呼叫系统的呼叫管理系统的类上的改变。

例如，分散在不同地理位置上的大公司可能会实现为该公司处理呼叫的类似设计和能力或甚至不同设计、模型等的若干呼叫管理系统。在每一位置，可实现本文所描述的采用规则(作为类实例)的目录服务来接口至本地呼叫管理系统。因此，目录服务可分布在众多公司位置上，且互相通信以维护最近的规则、使用容许、策略、表等。从而，一个系统实体(例如，发生故障的网关)中的改变可被表示为新的规则，并通过使用DN被传播给所有服务位置。

在更广泛的实现中，所公开的分布式目录服务和规则可用国际设置实现。假定每一国家可能具有不同的规章要求，且这些规章会改变，遵守规章通常导致在新规章生效时可能要求对软件的更新的复杂路由逻辑。通过使用例如由MSFT_SIPPhoneRouteUsageData类表示的使用表，管理员可通过创建或用新使用更新现有路线来遵循这些改变。

图13示出了采用便于自动化一个或多个特征的机器学习和推理组件(MLR)1302的替换系统1300。所公开的体系结构(例如，结合选择)可采用各种基于MLR的方案来实现其各个方面。例如，用于判断选择多个规则中的哪一规则的过程可以经由自动分类器系统和过程来促进。而且，采用分布在若干位置中的目录服务104，且每一位置具有相关联的路由规则110的表，可采用分类器来确定例如在其他位置之前将选择哪一位置来重新生成或更新。

分类器是将输入属性向量x＝(x1，x2，x3，x4，xn)映射到类标签class(x)的函数。分类器也输出该输入属于一个类的置信度，即f(x)＝confidence(class)。这样的分类可采用概率和/或其它统计分析(例如，分解成分析效用和成本以最大化对一人或多人的期望价值)来预测或推断用户期望自动执行的动作。

如此处所使用的，术语“推断”和“推论”通常是指从经由事件和/或数据捕捉的一组观测推理或推断系统、环境和/或用户的状态的过程。例如，推断可用于标识特定的上下文或动作，或可生成状态的概率分布。推断可以是概率性的，即，基于对数据和事件的考虑计算所关注状态的概率分布。推断也可以指用于从一组事件和/或数据合成更高级事件的技术。这类推断导致从一组观察到的事件和/或储存的事件数据中构造新的事件或动作，而无论事件是否在相邻时间上相关，也无论事件和数据是来自一个还是若干个事件和数据源。

支持矢量机(SVM)是可采用的分类器的一个示例。SVM通过在可能的输入空间中查找以最佳方式将触发输入事件和非触发事件分离开来的超曲面进行操作。直观上，这使得分类对于接近但不等同于训练数据的测试数据正确。可采用其它定向和非定向模型分类方法，包括，例如，各种形式的统计回归、朴素贝叶斯、贝叶斯网络、决策树、神经网络、模糊逻辑模型以及表示不同独立性模式的其他统计分类模型。如此处所使用的分类也包括用于分派排序和/或优先级的方法。

如从本说明书中可以容易地理解的，本体系结构可以使用显式训练(例如，经由一般训练数据)以及隐式训练(例如，经由观察用户行为、接收外来信息)的分类器。例如，SVM经由分类器构造器和特征选择模块内的学习或训练阶段来配置。因此，可采用分类器来根据预定准则自动学习和执行多个功能。

在该实现中，MLR组件1302可接口至服务组件102以监控管理员和/或其他硬件/软件系统进行的目录服务活动。例如，可监控、学习和推理方案活动以及对路由规则110、规则表活动和策略116的处理。

MLR组件1302也可接口至路由组件106以监控和分析例如涉及对API324的使用、对规则表的改变和更新、与路由规则(实例和类)的交互、目录服务的活动、以及路由组件106的一般和总体活动和过程的路由过程。

另外，MLR组件1302可接口至服务器通信框架118以监控、学习和推理框架活动和过程(例如，中继段、带宽、网络状态、其他DS服务器状态...)以及网关系统。

图14示出了采用调停网关(mediation gateway)1402来管理网关通信的替换系统1400。调停网关是例如可提供SIP规范化、安全控制和数据通道、改进的编译码器以及增值组件的抽象。调停网关1402的存在可允许顾客利用其现有硬件投资而同时升级至所公开的分布式服务体系结构。调停网关1402便于通过允许在一个类型的网关(例如，批准的网关)上路由但拒绝在其操作可能不可靠的另一类型的网关(例如，传统网关)上路由来控制呼叫路由。从而，可采用方案113来生成用于基于所采用的网关类型进行路由管理的规则。另外，可采用MLR组件1302来进一步监控调停网关活动，以及学习并推理调停网关活动。

图15示出了根据所公开的呼叫路由体系结构的分布式目录服务和规则类/属性定义的一个示例性方案。如所示的，提供了四个对象：使用、路线、策略和调停网关。使用对象(表示为msRTCSIP-RouteUsages)与类msRTPSIP-RouteUsage和属性定义msRTPSIP-RouteUsageAttribute和msRTPSIP-Description相关联。

路线对象(表示为msRTCSIP-PhoneRoutes)与类msRTPSIP-PhoneRoute和定义msRTPSIP-PhoneRouteName、msRTPSIP-TargetPhoneNumbers、msRTPSIP-Gateways、msRTPSIP-PhoneUsage、msRTPSIP-Description和msRTPSIP-PhoneRouteData相关联。

策略对象(表示为msRTCSIP-Policies)与类msRTPSIP-GlobalUserPolicy和定义msRTPSIP-PolicyType、msRTPSIP-PolicyContent以及msRTPSIP-PolicyData相关联。

网关对象(表示为msRTCSIP-TrustedMediationGateways)与类msRTPSIP-TrustedMediationGateway和定义msRTPSIP-TrustedMediationGatewayFQDN、msRTPSIP-TrustedMediationGatewayType、msRTPSIP-TrustedServerVersion以及msRTPSIP-TrustedMediationGatewayData相关联。

在一个实现中，方案是固定的，使得本地公司管理员不能以任何方式改变方案。在另一实现中，方案可由厂商为购买或订阅公司定制，公司具有有限的访问权和管理权。在又一实现中，向购买或订阅公司的管理员给予全部访问权以创建其自己的方案和/或修改厂商所提供的默认方案。

图16-21是示出根据所公开的体系结构的用于与目录服务交互以及管理呼叫路由的用户界面(UI)的一系列屏幕截图。尽管参考如屏幕截图的各个附图示出并描述了向用户显示信息的一些方式，但相关领域的技术人员可以认识到，可采用各种其他替换方案。术语“屏幕”、“屏幕截图”、“窗口”、“子窗口”和“页面”在本文中一般可互换使用。页面或屏幕作为显示描述、作为图形用户界面或通过描绘屏幕(例如，无论是个人计算机、PDA、移动电话还是其他合适的设备)上的信息的其他方法被存储和/或传输，其中要显示在页面上的布局和信息或内容被存储在存储器、数据库或另一存储设施中。

图16示出了用于向管理员(或用户)交互提供所公开的呼叫目录服务的各个特征的示例性通信程序UI 1600。例如，管理员可通过展示(例如，通过右击选择经由UI演示的电话路线对象)用于配置呼叫路由规则的浮动菜单1602来访问用于预备呼叫路由的向导。通过选择添加选择，向导运行且演示欢迎窗口1604。UI 1600也允许对之前输入的条目1606的管理以及对新电话路由条目的创建。为了管理现有条目，可通过使另一浮动菜单1608为条目1606之一演示而访问配置窗口(在图19中所示)。例如，通过突出显示苏黎世拨号条目并右击，菜单1608演示用于管理该条目的选择。条目1606可按任何一个可用字段(例如，名字、目标电话号码、网关...)排序。与图19相关联的描述提供了关于条目管理的更多细节。

现在转向图17，从向导欢迎窗口1604，打开允许管理员配置媒体网关的中间向导窗口1700。管理员可通过输入FQDN数据和相关联的端口来配置到网关的出站连接。完全合格的域名是指定节点在域名系统(DNS)树分层结构中的位置的无歧义的域名。为了将FQDN与常规域名区分，添加后缀段。FQDN因其绝对性而不同于常规域名。

图18示出了预备向导的附加预备窗口。例如，第二中间窗口1800便于配置通信服务器以路由至图16的窗口1600中所选的网关。管理员可作出上部的选择，这允许选择一网关(例如，网关1)来分派电话号码范围和/或模式。在进行了分派之后，退出向导。

或者，如果管理员作出了定义新号码范围的下部的选择，则打开第三中间向导窗口1802。通过选择添加功能，打开第四窗口1804以允许管理员直接输入范围数据、模式数据和加权数据。

图19示出了便于管理员对条目(或规则)的控制的一系列窗口。当管理员从浮动菜单1608选择了删除选项时，打开提示管理员确认删除功能的提示窗口1900。

如果管理员从菜单1608选择了特性选项，则打开允许进行选项卡选择(例如，常规、电话和网关)来创建新路由条目的窗口1902。常规选项卡展示了包括用于输入名字、描述和使用信息的域的输入和/或选择子窗口1904。注意，管理员可在创建电话路线条目时指定至少一个或多个属性。通过选择子窗口1904的添加按钮，演示允许管理员选择一个或多个电话属性以便为该电话路线条目指定的电话属性窗口1906。属性可以是在使用表中定义的那些。

图20示出了当选择图19的窗口1902的电话选项卡时演示的UI。电话选项卡展示了便于为电话路线指定目标电话号码的输入和/或选择子窗口2000。通过选择子窗口2000的添加按钮或编辑按钮，打开允许管理员通过输入例如定义电话号码的范围的正则表达式来管理目标电话号码的添加/编辑窗口2002。

图21示出了当选择图19的窗口1902的网关选项卡时演示的UI。网关选项卡展示了便于为电话路线指定目标电话号码的输入和/或选择子窗口2100。管理员可在创建电话路线时指定一个或多个网关。通过选择子窗口2100的添加按钮或编辑按钮，打开例如允许管理员管理网关的添加/编辑窗口2102。窗口2102允许管理员从下拉式菜单2104指定网关FQDN数据和端口数据。下拉式菜单2104是可从目录服务访问的可信调停网关对象的预填充列表。一旦管理员从下拉式菜单2104选择了网关FQDN，端口域可用属于在调停服务器中创建的每一实例的监听端口的列表预填充。

本体系结构构想了可通过允许顾客(或厂商)为其自己的用途或应用定制UI而在UI中提供灵活性。具体地，可允许厂商开发和采用它们自己的对话框、显示规则和使用策略。另外，可为自动化功能或过程编写和执行脚本(以及可执行文件)以支持例如呼叫管理和UI定制。而且，例如可向用户提供在策略背后采用其自己的逻辑的能力。可开发并采用DLL(动态链接库)来执行用于呼叫管理的其自己的谓词逻辑。

如在本申请中所使用的，术语“组件”和“系统”旨在表示计算机相关的实体，其可以是硬件、硬件和软件的组合、软件、或者执行中的软件。例如，组件可以是但不限于：在处理器上运行的进程、处理器、硬盘驱动器、(光和/或磁存储介质的)多个存储驱动器、对象、可执行代码、执行的线程、程序、和/或计算机。作为说明，运行在服务器上的应用程序和服务器都可以是组件。一个或多个组件可以驻留在进程和/或执行的线程内，且组件可以位于一台计算机内上/或分布在两台或更多的计算机之间。对于服务器、服务以及电话管理系统(例如，PBX、VoIP)和网络，组件可以是所提供的用于存储对象、接收、处理和路由电话呼叫和呼叫相关信息的软件和/或硬件，以及便于跨网络(例如，蜂窝、PSTN)的呼叫路由的呼叫网络和网络实体。

现在参考图22，示出了根据所公开的体系结构可用于执行目录服务和呼叫路由规则的计算机(或服务器)的框图。为了提供用于其各方面的附加上下文，图22及以下讨论旨在提供对其中可实现本发明的各方面的合适的计算环境2200的简要概括描述。尽管以上描述是在可在一个或多个计算机上运行的计算机可执行指令的一般上下文中进行，但是本领域的技术人员将认识到，本发明也可结合其它程序模块和/或作为硬件和软件的组合来实现。

一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构等等。此外，本领域的技术人员可以理解，本发明的方法可用其它计算机系统配置来实施，包括单处理器或多处理器计算机系统、小型机、大型计算机、以及个人计算机、手持式计算设备、基于微处理器的或可编程消费电子产品等，其每一个都可操作上耦合到一个或多个相关联的设备。

所示的本发明的各方面也可在其中某些任务由通过通信网络链接的远程处理设备来执行的分布式计算环境中实施。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备中。

计算机通常包括各种计算机可读介质。计算机可读介质可以是可由计算机访问的任何可用介质，且包括易失性和非易失性介质、可移动和不可移动介质。作为示例，而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据之类的信息的任意方法或技术实现的易失性和非易失性、可移动和不可移动介质计算机存储介质包括但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字视频盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储设备、或可以用来储存所期望的信息并可由计算机访问的任一其它介质。

再次参考图22，用于实现各方面的示例性环境2200包括计算机2202，计算机2202包括处理单元2204、系统存储器2206和系统总线2208。系统总线2208将包括但不限于系统存储器2206的系统组件耦合到处理单元2204。处理单元2204可以是各种市场上可购买到的处理器中的任意一种。双微处理器和其它多处理器体系结构也可用作处理单元2204。

系统总线2208可以是若干种总线结构中的任一种，这些总线结构还可互连到存储器总线(带有或没有存储器控制器)、外围总线、以及使用各类市场上可购买到的总线体系结构中的任一种的局部总线。系统存储器2206包括只读存储器(ROM)2210和随机存取存储器(RAM)2212。基本输入/输出系统(BIOS)储存在诸如ROM、EPROM、EEPROM等非易失性存储器2210中，其中BIOS包含帮助诸如在启动期间在计算机2202内的元件之间传输信息的基本例程。RAM 2212还可包括诸如静态RAM等高速RAM用于高速缓存数据。

计算机2202还包括内置硬盘驱动器(HDD)2214(例如，EIDE、SATA)，该内置硬盘驱动器2214还可被配置成在合适的机壳(未示出)中外部使用；磁软盘驱动器(FDD)2216(例如，从可移动磁盘2218中读取或向其写入)；以及光盘驱动器2220(例如，从CD-ROM盘2222中读取，或从诸如DVD等其它高容量光学介质中读取或向其写入)。硬盘驱动器2214、磁盘驱动器2216和光盘驱动器2220可分别通过硬盘驱动器接口2224、磁盘驱动器接口2226和光盘驱动器接口2228连接到系统总线2208。用于外置驱动器实现的接口2224包括通用串行总线(USB)和IEEE 1394接口技术中的至少一种或两者。其它外部驱动器连接技术在本发明所考虑的范围之内。

驱动器及其相关联的计算机可读介质提供了对数据、数据结构、计算机可执行指令等的非易失性存储。对于计算机2202，驱动器和介质容纳适当的数字格式的任何数据的存储。尽管以上对计算机可读介质的描述涉及HDD、可移动磁盘以及诸如CD或DVD等可移动光学介质，但是本领域的技术人员应当理解，示例性操作环境中也可使用可由计算机读取的任何其它类型的介质，诸如zip驱动器、磁带盒、闪存卡、盒式磁带等等，并且任何这样的介质可包含用于执行所公开的发明的方法的计算机可执行指令。

多个程序模块可储存在驱动器和RAM 2212中，包括操作系统2230、一个或多个应用程序2232、其它程序模块2234和程序数据2236。所有或部分操作系统、应用程序、模块和/或数据也可被高速缓存在RAM 2212中。应该明白，本发明可以用各种市场上可购得的操作系统或操作系统的组合来实施。

用户可以通过一个或多个有线/无线输入设备，例如键盘2238和诸如鼠标2240等定点设备将命令和信息输入到计算机2202中。其它输入设备(未示出)可包括话筒、IR遥控器、操纵杆、游戏手柄、指示笔、触摸屏等等。这些和其它输入设备通常通过耦合到系统总线2208的输入设备接口2242连接到处理单元2204，但也可通过其它接口连接，如并行端口、IEEE 1394串行端口、游戏端口、USB端口、IR接口等等。

监视器2244或其它类型的显示设备也经由接口，诸如视频适配器2246连接至系统总线2208。除了监视器2244之外，计算机通常包括诸如扬声器和打印机等的其它外围输出设备(未示出)。

计算机2202可使用经由有线和/或无线通信至一个或多个远程计算机，诸如远程计算机2248的逻辑连接在网络化环境中操作。远程计算机2248可以是工作站、服务器计算机、路由器、个人计算机、便携式计算机、基于微处理器的娱乐设备、对等设备或其它常见的网络节点，并且通常包括以上相对于计算机2202描述的许多或所有元件，尽管为简明起见仅示出了存储器/存储设备2250。所描绘的逻辑连接包括到局域网(LAN)2252和/或例如广域网(WAN)2254等更大的网络的有线/无线连接。这一LAN和WAN联网环境常见于办公室和公司，并且方便了诸如内联网等企业范围计算机网络，所有这些都可连接到例如因特网等全球通信网络。

当在LAN网络环境中使用时，计算机2202通过有线和/或无线通信网络接口或适配器2256连接到局域网2252。适配器2256可以方便到LAN 2252的有线或无线通信，并且还可包括其上设置的用于与无线适配器2256通信的无线接入点。

当在WAN网络环境中使用时，计算机2202可包括调制解调器2258，或连接到WAN 2254上的通信服务器，或具有用于通过WAN 2254，诸如通过因特网建立通信的其它装置。或为内置或为外置以及有线或无线设备的调制解调器2258经由串行端口接口2242连接到系统总线2208。在网络化环境中，相对于计算机2202所描述的程序模块或其部分可以存储在远程存储器/存储设备2250中。应该理解，所示网络连接是示例性的，并且可以使用在计算机之间建立通信链路的其它手段。

计算机2202可用于与操作上设置在无线通信中的任何无线设备或实体通信，这些设备或实体例如有打印机、扫描仪、台式和/或便携式计算机、便携式数据助理、通信卫星、与无线可检测标签相关联的任何一个设备或位置(例如，公用电话亭、报亭、休息室)以及电话。这至少包括Wi-Fi和蓝牙TM无线技术。由此，通信可以如对于常规网络那样是预定义结构，或者仅仅是至少两个设备之间的自组织(ad hoc)通信。

Wi-Fi，即无线保真，允许从家里沙发、酒店房间的床上或工作的会议室连接到因特网而不需要线缆。Wi-Fi是一种类似蜂窝电话中使用的无线技术，它使得诸如计算机等设备能够在室内和室外，在基站范围内的任何地方发送和接收数据。Wi-Fi网络使用称为IEEE 802.11x(a、b、g等等)的无线电技术来提供安全、可靠、快速的无线连接。Wi-Fi网络可用于将计算机彼此连接、连接到因特网以及连接到有线网络(使用IEEE 802.3或以太网)。

现在参考图23，示出了根据所公开的体系结构支持用于呼叫管理的目录服务的示例性计算环境2300的示意性框图。系统2300包括一个或多个客户机2302。客户机2302可以是硬件和/或软件(例如，线程、进程、计算设备)。客户机2302可例如使用通过本发明而容纳cookie和/或相关联的上下文信息。

系统2300还包括一个或多个服务器2304。服务器2304也可以是硬件和/或软件(例如，线程、进程、计算设备)。服务器2304可以例如通过使用本体系结构来容纳线程以执行变换。在客户机2302和服务器2304之间的一种可能的通信能够以适合在两个或多个计算机进程之间传输的数据分组的形式进行。数据分组可包括例如cookie和/或相关联的上下文信息。系统2300包括可以用来使客户机2302和服务器2304之间通信更容易的通信框架2306(例如，诸如因特网等全球通信网络)。

通信可经由有线(包括光纤)和/或无线技术来促进。客户机2302操作上被连接到可以用来存储对客户机2302本地的信息(例如，cookie和/或相关联的上下文信息)的一个或多个客户机数据存储2308。同样地，服务器2304可在操作上连接到可以用来存储对服务器2304本地的信息的一个或多个服务器数据存储2310。

上面描述的包括所公开的本发明的示例。当然，描述每一个可以想到的组件和/或方法的组合是不可能的，但本领域内的普通技术人员应该认识到，许多其他组合和排列都是可能的。因此，本发明旨在涵盖所有这些落入所附权利要求书的精神和范围内的更改、修改和变化。此外，就在说明书或权利要求书中使用术语“包括”而言，这一术语旨在以与术语“包含”在被用作权利要求书中的过渡词时所解释的相似的方式为包含性的。

Claims

1.一种便于呼叫管理的计算机实现的系统(100)，包括：

用于生成目录服务方案的方案组件(112)；以及

根据由所述方案定义的呼叫路由规则路由电话呼叫的呼叫路由组件(106)。

2.如权利要求1所述的系统，其特征在于，所述呼叫路由组件基于所述规则路由所述呼叫，所述规则在所述方案中被定义为类的实例。

3.如权利要求1所述的系统，其特征在于，所述方案定义的路由规则是最小成本路由规则。

4.如权利要求1所述的系统，其特征在于，所述方案便于基于包括在所述规则中的电话号码的范围或模式搜索所述路由规则的表。

5.如权利要求1所述的系统，其特征在于，所述方案便于基于串匹配来匹配所述路由规则。

6.如权利要求1所述的系统，其特征在于，所述方案组件便于生成由所述方案定义的一个或多个使用属性的策略。

7.如权利要求6所述的系统，其特征在于，所述呼叫路由组件基于对路由规则和所述策略的处理来路由所述呼叫。

8.如权利要求1所述的系统，其特征在于，所述方案定义路线使用、呼叫路线、策略、和调停网关中的至少一个。

9.如权利要求1所述的系统，其特征在于，还包括展示与呼叫管理有关的目录服务功能的用户界面。

10.如权利要求1所述的系统，其特征在于，还包括采用基于概率和/或基于统计的分析来预测或推断用户期望自动执行的动作的机器学习和推理组件。

11.如权利要求1所述的系统，其特征在于，还包括用于控制要在其上路由所述呼叫的路线的调停组件。

12.一种管理呼叫的计算机实现的方法，包括：

生成将呼叫路由数据表示为一个或多个路由规则的目录服务方案(200)；

在路由表中存储所述一个或多个规则，所述一个或多个规则包括针对其处理呼叫的号码模式、用于策略处理的使用属性、以及网关地址(202)；

基于所述呼叫展示所述一个或多个规则(204)；以及

基于所述一个或多个规则在呼叫网络上路由所述呼叫(206)。

13.如权利要求12所述的方法，其特征在于，还包括当所述一个或多个规则的使用属性匹配所述策略的使用属性时连接所述呼叫，并当所述一个或多个规则的使用属性不匹配所述策略的使用属性时使所述呼叫失败。

14.如权利要求12所述的方法，其特征在于，还包括基于所述一个或多个路由规则中的改变将所述一个或多个路由规则从第一目录服务组件传播到第二目录服务组件。

15.如权利要求12所述的方法，其特征在于，还包括将策略数据表示为在所述目录服务方案中定义的一个或多个使用属性。

16.如权利要求15所述的方法，其特征在于，还包括将所述呼叫路由规则和使用数据定义为所述方案中的类和类实例。

17.如权利要求12所述的方法，其特征在于，还包括利用标识名来自动维持跨所述方案中定义的类的链接的完整性。

18.如权利要求12所述的方法，其特征在于，还包括提供用于定制所述一个或多个路由规则的使用表。

19.如权利要求12所述的方法，其特征在于，还包括将所述呼叫路由至由所述方案中的类指定的网关。

20.一种用于呼叫管理的计算机可执行系统，包括：

用于生成将呼叫路由数据表示为一个或多个规则的目录服务方案的计算机实现的装置(112)；

用于将所述呼叫路由数据表示为类实例的计算机实现的装置(104)；

用于在路由表中存储所述一个或多个规则的计算机实现的装置(110)；

用于基于呼叫号码展示所述一个或多个规则的计算机实现的装置(102)；以及

用于基于所述呼叫号码和所述一个或多个规则的匹配的使用数据在呼叫网络上路由所述呼叫的计算机实现的装置(106)。