具体实施方式
尽管在此参照特定应用的示例性实施例描述了本发明,但应当理解的是,本发明并不仅限于此。本领域技术人员借助于在此提供的教导,将会了解本发明范围的其他修改、应用和实施例,以及本发明具有重要意义的其他技术领域。
呼叫业务管理器
本发明一个方面涉及基于软件的管理器,称作呼叫业务管理器。所述呼叫业务管理器可被称为代理,其是无源监控呼叫信息,而并不像物理交换机那样控制呼叫的软件应用。所述呼叫业务管理器充当呼叫中不同组件的代理。图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的性能数据。
结论
尽管以上已描述了本发明各个实施例,但应当理解的是,仅是借助实例示出本发明,而非具有限制意义。对于本领域技术人员而言,显然可在并不背离本发明精神和范围的情况下,以各种形式和细节做出各种改变。因此,本发明的广度和范围并不会受到上述示例实施例的限制,而是仅根据以下权利要求书及其等同物定义。