CN101569143A - 用于在ip电话网络中代理信令操作的系统和方法 - Google Patents

Abstract

提供了一种用于改进基于互联网协议的语音(“VOIP”)呼叫的质量和效率的呼叫业务管理器和方法。在实施例中，提供了一种方法来改进关于需要使用中心业务平台的呼叫的通信链路使用。提供了一种附加方法来验证在IP语音网络中的始发与终接通信设备之间交换的主叫识别信息。在本发明的另一方面中，提供了一种使用呼叫业务管理器的方法，以基于服务质量考虑，从一个呼叫路由动态交换到另一呼叫路由。此外，提供了呼叫业务管理器。所述呼叫业务管理器为可以位于任何类型的网络单元中的软件代理。所述呼叫业务管理器包括实施以上用于改进VOIP质量的方法的软件模块，且可包括其他呼叫业务和质量改进模块。

Description

用于在IP电话网络中代理信令操作的系统和方法

技术领域

本发明涉及通信，尤其涉及基于互联网协议的语音传输(“VOIP”)。

背景技术

基于互联网协议的语音传输(“VOIP”)正迅速取代现有各种形式的语音通信。由于VOIP不断为日益增长的客户提供服务，因此需要各种方法来改进VOIP业务的质量和效率。

发明内容

提供了一种用于改进基于互联网协议的语音传输(“VOIP”)质量的呼叫业务管理器和方法。在实施例中，提供了一种方法来改进关于需要使用中心业务平台的呼叫的通信链路使用。所述方法包括，当已经在始发通信设备与所述中心业务平台之间建立呼叫连接，并已经在终接通信设备与所述中心业务平台之间建立呼叫连接时，无源监控关于所述呼叫的信令数据。在实施例中，使用位于所述始发通信设备与所述中心业务平台之间的网络单元中的呼叫业务管理器。在监控信令时，所述呼叫业务管理器允许所述中心业务平台提供增强呼叫业务。

一旦所述呼叫业务管理器认识到所述中心业务平台已提供所述增强呼叫业务，所述呼叫业务管理器即在所述始发通信设备与终接通信设备之间建立将所述中心业务平台排除在外的呼叫连接。然后，所述呼叫业务管理器发送断线所述始发通信设备与所述中心业务平台之间的呼叫连接，以及所述终接通信设备与所述中心业务平台之间的呼叫连接的指令。这样，可以改进通信链路的使用，因为在所述中心业务平台已提供其初始增强呼叫业务之后，在呼叫期间不必使用指向所述中心业务平台的链路。

本发明的这一方面涉及已建立呼叫的转移，而并非仅是呼叫转移机制。已建立呼叫的转移与呼叫转移机制相比更加难以实现，其支持呼叫业务，例如在从所述呼叫中移走中心业务平台之前，使终接用户与中心业务平台相互作用以验证身份，使终接用户接受、拒绝或指定备选呼叫处理等。

在本发明的另一方面中，提供了一种用于在IP语音网络中，验证在始发与终接通信设备之间交换的主叫识别信息的方法。在本发明的这个方面中，位于终接网络中的呼叫业务管理器监控与建立IP语音呼叫到终接通信设备相关的数据分组。所述呼叫业务管理器存取识别鉴权数据库，以得到设置呼叫的始发通信设备的主叫识别信息。所述呼叫业务管理器通过将在所述呼叫建立消息中接收的主叫识别信息与从所述识别鉴权数据库接收的信息相比较，验证所述主叫识别信息的真实性。所述呼叫业务管理器提供将数据分组传送至所述终接通信设备的指令，其中所述数据分组提供主叫识别信息，和/或所述主叫识别信息的真实性指示。

在本发明的又一方面中，提供了一种用于基于服务质量考虑，从一个呼叫路由动态交换到另一呼叫路由的方法。在本发明的这一方面中，呼叫业务管理器监控所使用的呼叫路由的性能，并监控另一可用呼叫路由的性能。所述呼叫业务管理器基于服务质量考虑，发送交换呼叫路由的指令。

在本发明的又一方面中，提供了一种呼叫业务管理器。所述呼叫业务管理器是可能位于任何类型网络单元中的软件代理。所述呼叫业务管理器包括实施以上方法来改进VOIP质量的软件模块，还可能包括其他呼叫业务和质量改进模块。

以下将参照附图来详细描述本发明的其他实施例、特征和优点，以及本发明各个实施例的结构和操作。

附图说明

在此所包含的附图构成说明书的一部分，用于结合描述图解示意了本发明，并用以描述解释了本发明原理，使本领域技术人员能够实现并利用本发明。

图1是根据本发明实施例的呼叫业务管理器的框图。

图2A是电话网络的一部分的框图，其图解示意了使用“发夹”方法将呼叫路由到业务平台。

图2B是电话网络的一部分的框图，其图解示意了使用双B信道转移方法(2BCT)将呼叫路由到业务平台。

图2C是电话网络的一部分的框图，其图解示意了使用释放-链路-中继(“RLT”)方法将呼叫路由到业务平台。

图3是根据本发明实施例的电话网络的一部分的框图，其图解示意了利用指向业务平台的呼叫，其中使用呼叫业务管理器来优化链路使用。

图4是根据本发明实施例的方法的流程图，所述方法改进了关于需要业务平台的呼叫的链路使用。

图5A是根据本发明实施例的电话网络的一部分的框图，其图解示意了涉及中心业务平台的呼叫建立的初始阶段。

图5B是根据本发明实施例的电话网络的一部分的框图，其图解示意了涉及中心业务平台的呼叫建立的后续阶段。

图6A是根据本发明实施例的方法的流程图，所述方法用于验证在始发与终接通信设备之间交换的主叫识别信息。

图6B是根据本发明实施例的方法的流程图，所述方法用于得到主叫识别信息以在始发和终接通信设备之间交换。

图7是根据本发明实施例的电话网络的一部分的框图，其示意了使用呼叫业务管理器来提供主叫识别验证和介入。

图8是根据本发明实施例的动态路由IP语音呼叫的方法的流程图。

图9是根据本发明实施例的电话网络的一部分的框图，其图解示意了如何基于图8的方法动态路由IP语音呼叫。

以下将参照附图描述本发明。在附图中，相同的附图标记指示相同或功能类似的单元。此外，附图标记的最左数字标识所述附图标记首次出现的图。

具体实施方式

尽管在此参照特定应用的示例性实施例描述了本发明，但应当理解的是，本发明并不仅限于此。本领域技术人员借助于在此提供的教导，将会了解本发明范围的其他修改、应用和实施例，以及本发明具有重要意义的其他技术领域。

呼叫业务管理器

本发明一个方面涉及基于软件的管理器，称作呼叫业务管理器。所述呼叫业务管理器可被称为代理，其是无源监控呼叫信息，而并不像物理交换机那样控制呼叫的软件应用。所述呼叫业务管理器充当呼叫中不同组件的代理。图1是呼叫业务管理器100的框图。呼叫业务管理器100包括输入/输出协议栈110、呼叫控制管理器130、应用逻辑管理器140、路由管理器150和接口管理器160。

输入/输出协议栈110编码并解码所述网络中的消息，并区分呼叫中的信令数据和语音组分。前者由呼叫业务管理器100监控，而后者被忽略，并被传递到其他网络单元。

呼叫控制管理器130从输入/输出协议栈110接收已解码的消息流，并执行监控包括关于呼叫的管理信息的数据组分的功能。下一个功能块是应用逻辑管理器140，其执行特定呼叫处理功能，例如带宽优化和呼叫路由。

接口管理器160被用于连接到外部组件，例如用于存取处理所述呼叫所必需的信息的数据库。路由管理器150控制所述接口管理器，并选择所存取的外部组件，例如数据库170A或170B。

网络优化

在如今的电话网络中，网络链路使用带来重要的成本问题，尤其对于集中业务的业务提供商而言，所述集中业务例如是公司语音邮件和联系中心。当向公司网络中的终接电话发出呼叫时，所述呼叫在由中心业务平台(“CSP”)路由到终接电话之前，首先路由到所述业务平台。CSP例如是语音邮件平台、综合语音响应(“IVR”)或增强型智能网络智能外围设备(“AIN-IP”)。在公共交换电话网(“PSTN”)中，路由到业务平台通常是通过“发夹”所述呼叫来实现的，即CSP建立、连接和保持两个独立的呼叫分支-一个从始发电话到所述CSP，一个从所述CSP到所述目的地电话的过程。

例如，参照图2A，始发电话210的用户通过始发交换机220发出呼叫。在接收到所述呼叫时，始发交换机确认所述呼叫应当被路由到CSP，并将所述呼叫路由到CSP 230。CSP 230例如可能是IVR系统，其为始发电话210的用户提供确定如何处理所述呼叫的各种尝试。通过与始发电话220的用户相互作用，CSP 230确定所述呼叫应当被路由到终接交换机240，以完成路由到终接电话250。如此，CSP 230绑住两个中继线端口——一个用于来自始发电话210的呼入呼叫，一个用于指向终接电话230的呼出呼叫连接。如此，在整个始发电话210与终接电话240之间的呼叫连接期间，CSP 230占用两个中继线端口，而相关链路占线，尽管呼叫处理不再需要CSP 230。

备选路由方法已得到实施来避免使用每个端口的价格都很高的平台的端口，所述平台例如是CSP。所述备选方法包括2B信道转移(“2BCT”)和释放-链路-中继(“RLT”)路由。

如图2B所示，在所述2BCT方案中，中间交换机中价格更低的端口被用于链接/发夹所述两个呼叫，而非CSP自身。换言之，所述呼叫分支由所述交换机而非CSP保持，从而避免使用CSP的较昂贵的端口来路由呼叫。驻留在所述始发和终接电话与CSP之间的中间交换机经由ISDN PRI链路与CSP通信。

因此，在2BCT方案下，为了将呼叫从始发电话210连接到终接电话250，使用两个独立的网络执行四个独立的呼叫连接。所述呼叫连接包括，一个呼叫连接使用SS7、ISDN、CAS或其他电话中继线从始发交换机220到中间交换机260，一个呼叫使用B信道ISDN链路从交换机260到CSP 230，一个呼叫使用B信道ISDN链路从CSP230到交换机260，以及使用SS7、ISDN、CAS或其他电话中继线，从中间交换机260到支持终接电话250的终接交换机240的最终呼叫。

在一个示例网络配置中，始发交换机220和终接交换机240可能是中心局交换机，而中间交换机260可能是接入汇接交换机。在另一实例中，始发交换机220和终接交换机240可以是专用小交换机(PBX)，而中间交换机260可以是中心局交换机。其他网络配置也是可能的。

如图2C所示，在RLT方案中，从始发电话210指向终接电话250的呼叫由CSP 230接收。与始发电话210相关的始发交换机220与CSP 230相互作用，并获取与终接电话250相关的信息。一旦所述信息由始发交换机220接收，始发交换机220即终止呼叫到CSP 230，从而将CSP 230从呼叫路径中移走。然后，独立、直接呼叫由始发交换机220通过终接交换机240在始发电话220与终接电话250之间建立。与所述CSP的连接的终止，以及与所述终接电话的新连接的建立对于所述始发电话上的用户都是看不见的。

直到现在，IP语音网络中的网络链路使用和优化尚未引起关注，因为IP带宽很少得到使用，且其较PSTN网络中的传统时分多址带宽便宜得多。然而，随着IP网络的日益增长，且各种基于IP的语音业务由所述网络上的电话载波提供，这种情况已发生改变。

本发明一个方面涉及通过使用诸如呼叫业务管理器110的基于软件的管理器，IP电话网络中基于SIP的转移呼叫。在本发明的这个方面中，呼叫业务管理器100代替CSP执行呼叫处理和后续路由的功能。如图3所示，呼叫业务管理器100位于中间交换机260中，或其他任何位于始发电话与CSP之间的路径上的网络组件中。在这种情况下，呼叫业务管理器100能够无源监控关于始发电话与CSP之间的呼叫的信令数据，所述始发电话例如是电话210，所述CSP例如是CSP230。所述呼叫的语音组分绕过呼叫业务管理器100，并由CSP 230接收。CSP 230建立另一呼叫到终接电话，例如终接电话250。

然而，重要的是，与上述先前网络布置不同，CSP 230并不发夹所述呼叫。换言之，CSP 230并不连接两个所建立的呼叫。相反，呼叫业务管理器100在始发电话210与终接电话250之间建立所述语音组分的直接连接。同时，所述呼叫的信令组分继续通过呼叫业务管理器100，所述呼叫业务管理器实际上发夹所述信令组分。然后，CSP 230终止其与始发电话210和终接电话250的连接，从而不再处于呼叫路径上。

图4是根据本发明实施例的方法400的流程图，其改进了关于需要业务平台的呼叫的链路使用，所述业务平台依赖于代理。参照图5A，从始发电话210发出呼叫。通过始发交换机220路由所述呼叫。始发交换机220识别所述呼叫需要CSP 230的业务，并将所述呼叫路由到中间交换机260，而所述中间交换机将所述呼叫路由到CSP 230。然后，CSP 230通过中间交换机260，并通过终接交换机240建立到终接电话250的第二呼叫连接。在实施例中，中间交换机260包括呼叫业务管理器，例如呼叫业务管理器100。在备选实施例中，呼叫业务管理器100可能与始发交换机220，或其他任何中间交换机，或存在于始发电话210与业务平台230之间的网络单元设置在一起。

图5A示出了此时在所述呼叫中存在的由线510表示的语音连接，以及由线路520表示的信令连接。如图5A所示，语音连接510并不经过呼叫业务管理器100，而信令连接520并不经过呼叫业务管理器100。

方法400开始于网络处于图5A所示的状态中。方法400开始于步骤410。在步骤410中，诸如呼叫业务管理器100的呼叫业务管理器无源监控关于始发电话210与CSP 230之间的呼叫的信令数据。在步骤420中，CSP 230被容许提供所需要的任何一种增强型呼叫业务。例如，CSP 230可提供语音响应提示。在步骤430中，呼叫业务管理器100在始发电话210与终接电话250之间建立将CSP 230排除在外的呼叫连接。在步骤440中，CSP 230断线涉及CSP 230的呼叫连接，所述CSP 230实际上将已建立呼叫从始发电话210转移到终接电话250。这种情况在图5B中示出。在通过将CSP 230从所述呼叫路由中移走来转移已建立呼叫之前，本发明的一个方面使得所述终接电话250能够与CSP 230相互作用。例如，这些相互作用可能包括验证始发电话210的身份，或是所述终接电话250能够接受呼叫、拒绝呼叫或指定呼叫的备选处理，但并不仅限于此。

图5B示出了线路530所示的语音连接现已将CSP 230排除在外，并被经由IP传输层从始发交换机220直接路由到终接交换机240。在备选实施例中，语音连接530可被经由IP传输层路由通过中间交换机260。图5B还示出了由线路540示出的信令连接将CSP 230排除在外，并被从始发交换机220路由到中间交换机260，再通过呼叫业务管理器100到终接交换机240。

在步骤450中，呼叫业务管理器100可选地持续性监控信令。所述持续性信令监控允许呼叫业务管理器100响应于呼叫特征的改变，并提供如上所述的附加功能。方法400在步骤460结束。

如上所述，呼叫业务管理器100是用于无源监控信息，且并不如物理交换机那样控制呼叫的软件应用。所述电话和CSP都未意识到在所述呼叫中涉及呼叫业务管理器100。呼叫业务管理器100实际上充当呼叫的不同组件的代理。例如，对于CSP而言，所述呼叫业务管理器100如同始发或终接电话。对于始发电话210和终接电话250而言，所述呼叫业务管理器100如同CSP。呼叫业务管理器100可位于任何在始发电话210与CSP 230之间的通信路径上出现的网络单元中。例如，在以上实例中，呼叫业务管理器100可能还位于始发交换机220中。网络单元可以包括始发中心局电话交换机、接入汇接电话交换机、IP专用小交换机、软交换机、网关和路由器，但并不仅限于此。始发和终接电话可包括传统电话、IP电话和提供语音通信的计算机，但并不仅限于此。

主叫ID/目录服务注入

基于IP的语音网络与传统PSTN网络具有显著不同，因为所述语音网络实施诸如主叫ID和呼叫名称传递的用户信息业务。在PSTN网络中，终接载波负责解析主叫的识别，并将其提供给所述终接电话用户，这将会受到各种私密性的限制。这是通过存取由所述始发载波保持的官方数据库得到实现的。例如，参见Bellcore Notes on thenetworks，Special Report 2275，第3次发行，1997年12月，14.78-14.79。通过对比，在IP网络中，所述主叫的识别信息随着呼叫从所述始发电话传递到终接电话。这至少说明两个问题，包括IP网络中的安全性和/或私密性。

首先，终接电话无法验证其从所述始发电话接收的主叫识别信息，这说明在所述主叫的真实身份方面，所述终接电话的用户将会有机会受到欺骗。这尤其得到证实，因为诸如SIP的基于文本的IP协议使得主叫轻易伪造他或她的识别信息进行欺骗。使用SIP，所述始发电话的主叫可能会将不真实的识别信息(所述主叫方可扮作其他人)发送到所述终接电话。

其次，从呼叫路由开始到所述呼叫路由的结束，将主叫信息与呼叫一起发送，这向未得到授权的用户提供了多个得到所述信息的机会。在到达所述终接电话之前，任何给定呼叫路由中的每个呼叫都可能通过若干基于载波的网络，所述网络连接并控制所述呼叫。每个所述交换点都为第三方提供了接入所述主叫信息的机会。因为与每个呼叫一起传递的主叫信息通常并未受到保护，因此未得到授权的用户即可在所述呼叫继续发往所述终接电话时，接入关于所述主叫的信息。

为了解决这些问题，本发明的一个方面提供了一种在IP语音网络中验证和鉴权主叫识别信息的方法。诸如呼叫业务管理器100的代理可能与终接载波网络中的网络单元相关联，以确定所述主叫的识别，并提供诸如所述主叫姓名和/或电话号码的信息的准确显示。

根据本发明，诸如呼叫业务管理器100的呼叫业务管理器监控由终接电话接收的呼叫，并存取可靠的数据库(例如由所述始发载波所维持的)，以得到关于所述呼叫和主叫的信息。通过此信息，所述呼叫业务管理器可确定所述主叫的真实身份，并将此身份通信给所述终接电话的用户。此外，通过存取存储在安全位置的可靠主叫识别信息，本发明不再需要将主叫识别信息与每个呼叫一起传递，从而降低了带宽要求，并减少了不适当存取私人信息的机会。此外，使用这种机制将会容许在网络中显示所述主叫识别信息，而如今在所述网络中却无法实现——例如在包括H.233、SIP、SS7、ISDN等的不同环境中，在不使用所述机制的情况下，这些转接网络的某些组合使得所述信息的端到端传输不可靠，或根本不可能。

图6A示出了与验证主叫识别信息相关的本发明实施例。具体而言，图6A提供了根据本发明实施例的方法600的流程图，其验证在始发与终接通信设备之间交换的主叫识别信息。以下将参照图7解释方法600，图7示出了通信网络700的一部分。通信网络700的各部分并非旨在限制本发明。本领域技术人员将会基于本文的教导，了解其中可使用本发明的其他网络配置。

方法600从步骤605开始。在步骤605中，在支持终接通信设备的网络内的IP语音呼叫中的相关数据分组被监控。例如，参照图7，呼叫业务管理器100对于在始发电话710与终接电话770之间正在建立的呼叫，监控由终接载波网络740接收的信令信息。呼叫业务管理器100位于支持终接电话770的终接载波网络740的网络单元中。在此实例中，始发电话710由始发载波网络720支持。始发载波网络720和终接载波网络740通过一个或多个转接网络，例如转接网络730耦合。此外，始发载波网络720和终接载波网络740可直接耦合，或仅一个网络可以充当始发和终接载波网络两者。始发载波网络720具有与其相关的用户数据库760，其中保持用户身份信息。

在步骤610中，在确认始发电话710与终接电话770之间的呼叫建立尝试时，呼叫业务管理器100发送消息来评估用户数据库760，所述数据库包括与所述始发载波所支持的用户相关的信息的识别鉴权数据库。

用户数据库760提供了包括将用于验证所述始发载波身份的信息的返回消息。在接收到所述信息时，在步骤615中，呼叫业务管理器100验证始发主叫识别信息的真实性，所述主叫识别信息已由呼叫业务管理器100在其正监控的原始信令消息中接收。在步骤620中，呼叫业务管理器100将验证确认附在将被发送到终接电话770的数据分组中。在步骤625中，呼叫业务管理器100将所述始发主叫识别信息发送到所述终接电话770。

在备选实施例中，所述呼叫得以完成，但并无验证确认信息被发送到终接电话770。在另一实施例中，如果呼叫方身份未得到验证，换言之，从用户数据库760接收的信息与包括在原始信令消息中的信息不同，则所述呼叫被拒绝，呼叫建立被否定。在本发明的又一方面中，可将请求适当识别的提示返回所述始发主叫。

图6B提供了方法650的流程图，所述方法用于得到互联网协议(IP)语音网络中的识别信息，以在始发与终接通信设备之间进行交换。同样参照图7解释方法650。方法650开始于步骤655。在步骤655中，在支持终接通信设备的网络内的IP语音呼叫中的相关数据分组被监控。例如，参照图7，呼叫业务管理器100对于在始发电话710与终接电话770之间正在建立的呼叫，监控由终接载波网络740接收的信令信息。

在确认始发电话710与终接电话770之间的呼叫建立尝试时，在步骤660中，识别出并不存在始发主叫识别信息的事实。例如，呼叫业务管理器100识别出始发电话710识别信息并不存在于呼叫建立消息中。

在步骤665中，存取识别鉴权数据库。例如，呼叫业务管理器100发送消息来评估用户数据库760，所述数据库包括与所述始发载波所支持的用户相关的信息的识别鉴权数据库。

用户数据库760提供了包括始发主叫710的用户识别信息的返回消息。在接收到所述信息时，在步骤670中，所述主叫识别信息被插入预定用于所述终接电话的数据分组。例如，呼叫业务管理器100将始发电话710的主叫识别信息插入预定用于终接电话770的数据分组。

在步骤675中，所述始发主叫识别信息被发送到所述终接电话。例如，呼叫业务管理器100将始发主叫识别信息发送到终接电话770。作为选择，识别验证确认可被发送到终接电话770。

网络路由器/QoS优化

基于IP的语音通信的服务质量是一个值得关注的问题。与基于TDM的PSTN网络不同，对于每个呼叫其都可提供有保证的最低服务质量水平，而IP网络处于“突发性”环境，并无实际的可操作分类方案来区分文件传送和语音通信。因此，语音和数据分组共享相同带宽，且被IP网络以相同方式对待。无法区分语音与数据分组将会导致语音通信的服务质量不佳。与文件传输应用不同，其在接收数据分组中可容忍合理的延迟(只要它们以适当顺序到达)，而语音通信应用需要及时接收语音分组，否则应用的服务质量将会受到严重影响。

一种已经建议用于解决与IP网络中的语音通信相关的QoS问题的方案是对网络和呼叫路由执行当前环境的实时探测。基于所述探测，所述载波可选择建立呼叫的最佳可用路由。然而，IP网络的突发性会严重限制所述最佳可用路由技术方案的实用性。因为网络环境处于固定的流动状态，所以基于这种所监控的环境做出的路由判定也处于固定的流动状态。换言之，基于曾经存在的环境为呼叫选择的“最佳可用”路由，仅几秒之后即会因为网络改变而成为不良路由。因此，已建立呼叫的所需业务水平无法得到保证，且很可能仅保持极短时间，从而导致用户经历不良体验。

本发明的一个方面针对影响IP网络中的语音通信的QoS问题提供了一种技术方案。具体而言，诸如呼叫业务管理器100的代理可实时动态地将一个路由上的已建立呼叫转移到另一路由，只要环境保证。呼叫业务管理器监控已建立呼叫的至少两个可用备选呼叫路由。具体而言，呼叫业务管理器100始终监控和分析所述呼叫的信令组分。当所述代理确定当前呼叫路由不再能够提供某一业务水平时(例如基于载波向其提供的一组规则或准则)，所述代理向交换机发送将所述呼叫的语音组分转移到备选可用路由的指令。在特定呼叫会话的长度期间，所述代理鉴于所监控的环境，认为为了提供业务的可能最佳水平，可将所述呼叫在可用路由之间多次往返转移。所述可用呼叫路由之间的动态转移对于呼叫的用户是不可见的。

除了无源监控呼叫以得到其确定是否转移呼叫所需的呼叫条件信息之外，呼叫业务管理器100还可向各个呼叫路径上的网络组件有效询问执行所述转移确定所需的呼叫条件信息。可在监控或并不监控当前呼叫的信令组分的情况下，使用所述询问来做出交换呼叫路由的确定。

图8提供了根据本发明实施例的方法800的流程图，所述方法800用于基于路由的性能比较，将IP语音呼叫从一个呼叫路由转移到另一呼叫路由。参照图9解释图8。

图9示出了电信网络的一部分，其中始发电话910已与终接电话940建立呼叫。图9示出了两个潜在的呼叫路由。呼叫路由1包括始发交换机915、中间交换机920和终接交换机930。呼叫路由2包括始发交换机915、中间交换机925和终接交换机930。始发交换机915支持始发电话910，而终接交换机930支持终接电话940。呼叫业务管理器100位于始发交换机915中。如本领域技术人员所知的，可能存在更多连接始发电话910与终接电话940的路由。此外，在任何给定路由中，可能存在多个中间网络单元。

在诸如始发电话910与终接电话940的两个电话之间建立呼叫之后，调用方法800。方法800开始于步骤810。在步骤810中，为已建立的IP语音呼叫监控备选路由的性能。例如，参照图9，如果经由路由1已建立呼叫，则呼叫业务管理器100可监控路由1和路由2的性能。可监控更广范围的性能参数，例如带宽、拥塞、业务策略和/或成形策略、呼叫优先级(例如911优先呼叫)、误码率、延迟和抖动。

在步骤820中，分析呼叫的信令组分。可在呼叫业务管理器100中设置性能水平为足够性能的门限，从而在一个实施例中，如果那些性能门限在当前路由上无法得到满足的话，呼叫业务管理器100将仅监控关于另一路由的性能。此外，可连续分析和盥控备选路由的性能水平，从而可始终选择具有最佳性能水平的路由。

在步骤830中，确定当前呼叫路由是否保持在某一业务水平。例如，呼叫业务管理器100可确定路由1不再支持某一业务水平。

在步骤840中，如果已确定在特定路由上无法满足所需的业务水平，则可发送交换路由的指令。例如，呼叫业务管理器100可将从路由1改变为路由2的指令提供给始发交换机915。在步骤850中，方法800结束。

在本发明的又一方面中，呼叫业务管理器100可询问网络单元，以得到关于备选路由的性能信息。例如，假定路由1正用于呼叫。呼叫业务管理器100可询问中间交换机925，以请求关于路由2的性能数据。

结论

尽管以上已描述了本发明各个实施例，但应当理解的是，仅是借助实例示出本发明，而非具有限制意义。对于本领域技术人员而言，显然可在并不背离本发明精神和范围的情况下，以各种形式和细节做出各种改变。因此，本发明的广度和范围并不会受到上述示例实施例的限制，而是仅根据以下权利要求书及其等同物定义。

Claims (29)

1、一种在互联网协议(IP)语音网络中用于改进关于需要使用中心业务平台的呼叫的通信链路使用的方法，其中已经在始发通信设备与所述中心业务平台之间建立呼叫连接，并已经在终接通信设备与所述中心业务平台之间建立呼叫连接，所述方法包括：

(a)无源监控关于所述始发通信设备与所述中心业务平台之间的呼叫的信令数据；

(b)允许所述中心业务平台提供增强呼叫业务；

(c)在所述始发通信设备与终接通信设备之间建立排除所述中心业务平台的呼叫连接；以及

(d)断线所述始发通信设备与所述中心业务平台之间的呼叫连接，以及所述终接通信设备与所述中心业务平台之间的呼叫连接。

2、根据权利要求1的方法，还包括持续性监控所述始发通信设备与所述终接通信设备之间的信令。

3、根据权利要求1的方法，其中步骤(a)包括借助呼叫业务管理器，无源监控关于所述始发通信设备与所述中心业务平台之间的呼叫的信令数据，其中所述呼叫业务管理器位于直接或间接连接到所述始发通信设备的网络单元中。

4、根据权利要求3的方法，其中所述网络单元为始发中心局电话交换机、始发接入汇接电话交换机、IP专用小交换机、网关交换机或路由器。

5、根据权利要求1的方法，其中所述始发通信设备为电话、IP电话或用于提供语音通信的个人计算机。

6、一种在互联网协议(IP)语音网络中用于验证在始发与终接通信设备之间交换的主叫识别信息的方法，所述方法包括：

(a)监控与在支持所述终接通信设备的网络中建立IP语音呼叫相关的数据分组；

(b)存取识别鉴权数据库，其中所述识别鉴权数据库包括所述始发通信设备的身份信息；

(c)验证所述主叫识别信息的真实性；以及

(d)将数据分组传送给所述终接通信设备，其中所述数据分组提供主叫识别信息。

7、根据权利要求6的方法，还包括将识别验证识别符附在提供主叫识别信息的数据分组中，其中所述识别验证识别符指示所述主叫识别信息是否已得到验证。

8、根据权利要求6的方法，其中步骤(a)包括由呼叫业务管理器无源监控信令数据，其中所述呼叫业务管理器位于直接或间接连接到所述终接通信设备的网络单元中。

9、根据权利要求8的方法，其中所述网络单元为始发中心局电话交换机、始发接入汇接电话交换机、IP专用小交换机、网关交换机或路由器。

10、根据权利要求6的方法，其中所述始发通信设备和终接通信设备为电话、IP电话或用于提供语音通信的个人计算机。

11、一种在互联网协议(IP)语音网络中得到主叫识别信息以在始发和终接通信设备之间建立呼叫的方法，所述方法包括：

(a)在支持与IP语音呼叫相关的所述终接通信设备的网络中，无源监控与IP语音呼叫相关的数据分组；

(b)确定始发主叫识别信息并不存在于预定用于所述终接通信设备的数据分组中；

(c)存取识别鉴权数据库，其中所述识别鉴权数据库包括所述始发通信设备的身份信息；

(d)得到所述始发主叫识别信息；以及

(d)将数据分组转移到所述终接通信设备，其中所述数据分组提供所述始发主叫识别信息。

12、根据权利要求11的方法，还包括将识别验证识别符附在提供主叫识别信息的数据分组中，其中所述识别验证识别符指示所述主叫识别信息是否已得到验证。

13、根据权利要求11的方法，其中步骤(a)包括由呼叫业务管理器无源监控信令数据，其中所述呼叫业务管理器位于直接或间接连接到所述终接通信设备的网络单元中。

14、根据权利要求13的方法，其中所述网络单元为始发中心局电话交换机、始发接入汇接电话交换机、IP专用小交换机、网关交换机或路由器。

15、根据权利要求11的方法，其中所述始发通信设备和终接通信设备为电话、IP电话或用于提供语音通信的个人计算机。

16、一种用于将IP语音呼叫从一个呼叫路由动态转移到另一呼叫路由的方法，所述方法包括：

(a)监控所述IP语音呼叫的备选路由；

(b)分析所述IP语音呼叫的信令组分；

(c)确定所述IP语音呼叫的当前呼叫路由无法保持预定业务水平；以及

(d)发送用于交换到所述IP语音呼叫的备选呼叫路由的指令。

17、根据权利要求16的方法，其中步骤(b)分析所述IP语音呼叫的信令组分包括：

评估与所述IP语音呼叫相关的带宽、拥塞、业务策略和/或成形策略、呼叫优先级、误码率、延迟和抖动。

18、根据权利要求16的方法，其中步骤(c)还包括：

比较一个或多个备选呼叫路由的性能水平，并选择具有最高业务水平的呼叫路由来路由所述呼叫。

19、根据权利要求16的方法，其中步骤(a)还包括：

询问备选呼叫路由中的网络组件，以收集呼叫条件信息。

20、一种用于将IP语音呼叫从一个呼叫路由动态转移到另一呼叫路由的方法，包括：

(a)询问备选呼叫路由中的网络组件，以收集备选呼叫路由的呼叫条件信息；

(b)基于步骤(a)的所述询问，确定所需性能水平存在于备选呼叫路由上；以及

(c)发送用于交换到所述IP语音呼叫的备选呼叫路由的指令。

21、一种用于处理数据分组的呼叫业务管理器，所述数据分组包括与两个或更多用户之间的连接相关的语音数据和管理信息，所述呼叫业务管理器包括：

输入协议栈，其解码数据分组，并区分语音数据和管理信息；

输出协议栈，其编码数据分组，并区分语音数据和管理信息；

呼叫控制管理器，其监控数据分组中的语音内容；

应用逻辑管理器，其基于所述管理信息执行呼叫处理功能；

接口管理器，其支持到外部部件的接口，以收集呼叫业务并处理信息；以及

路由管理器，其控制所述接口管理器。

22、根据权利要求21的呼叫业务管理器，其中所述应用逻辑管理器优化关于用以交换数据分组的通信链路的带宽使用。

23、根据权利要求21的呼叫业务管理器，其中所述应用逻辑管理器对于用以交换数据分组的通信链路执行呼叫路由。

24、一种IP电话网络，其包括：

多个网络单元，其处理呼叫信令信息，以在始发和终接通信设备之间建立电话呼叫；

至少一个呼叫业务管理器，其位于所述多个网络单元中的至少一个网络单元中，其中所述至少一个呼叫业务管理器无源监控关于在所述IP电话网络上设置的呼叫的信令数据。

25、根据权利要求24的IP电话网络，还包括提供增强呼叫业务的中心业务平台，其中所述至少一个呼叫业务管理器监控所述始发通信设备与所述中心业务平台之间的呼叫信令，其中所述至少一个呼叫业务管理器在所述始发通信设备与所述中心业务平台之间传送已建立的呼叫，并且在所述始发与终接通信设备之间建立绕过所述中心业务平台的直接连接。

26、根据权利要求24的IP电话网络，还包括识别鉴权数据库，其中所述至少一个呼叫业务管理器监控在所述始发通信设备与所述终接通信设备之间的呼叫信令，其中所述至少一个呼叫业务管理器存取所述识别鉴权数据库，以得到与所述始发通信设备相关的主叫识别信息。

27、根据权利要求24的IP电话网络，其中所述至少一个呼叫业务管理器监控备选呼叫路由，以在所述始发与终接通信设备之间建立呼叫连接，其中所述至少一个呼叫业务管理器向网络单元提供用于将呼叫连接重新路由到备选路由的指令。

28、根据权利要求24的IP电话网络，其中所述网络单元包括始发中心局电话交换机、始发接入汇接电话交换机、IP专用小交换机、网关交换机或路由器中的一个或多个。

29、根据权利要求24的IP电话网络，其中所述始发通信设备和终接通信设备为电话、IP电话或用于提供语音通信的个人计算机。

Images