专利名称：可编程的呼叫处理系统和方法
技术领域：
本发明涉及电信领域。尤其是，本发明涉及可编程的呼叫处理系统及其方法。
背景技术：
购买交换系统的电信业务供应商常常想要对所购买的系统进行修改或扩展。扩展一般是指用户特性，这可给业务供应商提供了额外的收入。例如，业务供应商可能希望实行新的呼叫处理特性、开发用于特殊终端用户的定制特性、收集与特定呼叫有关的特殊信息以及收集与某些呼叫处理操作有关的特殊话务量计量和测量(TM&M)数据。
然而，已证明在过去难于把扩展加到交换系统，这是因为交换系统庞大而复杂。一般，只有交换系统制造商和卖主才具有实行所需改变的专门技术。因此，可能需要延长订货至交货时间(lead time)来实行这些改变。
发明内容
如上所述，可以理解需要一种便于提供定制的非标准呼叫处理逻辑而延迟交货时间不长的呼叫处理系统和方法。它还有利于使业务供应商有能力且知道如何足不出户就可以开发和实行扩展的订购业务。
因此，依据本发明，提供了一种基本上消除或减少了与常规呼叫处理系统和方法有关的缺点和问题的可编程呼叫处理系统和方法。
依据本发明的一个方面，可编程呼叫处理系统提供了依据工业标准呼叫模型进行呼叫处理的标准呼叫处理过程、至少一个数据库存储可由这套标准呼叫处理过程访问的呼叫处理数据以及至少一个定制的呼叫逻辑程序用于对电信交换系统实行扩展的用户特性。此外，应用程序接口提供了由至少一个定制的呼叫逻辑程序到至少一个呼叫处理数据库的入口，且暂停标准呼叫处理过程来执行定制的呼叫逻辑程序。
依据本发明的另一个方面，提供了用于电信交换系统的可编程呼叫处理的方法。该方法包括以下步骤提供至少一个定制的呼叫逻辑程序用于扩展标准呼叫处理过程所提供的用户服务、对标准呼叫处理过程进行初始化以及在发生指定事件时把控制从标准呼叫处理过程传送到至少一个定制的呼叫逻辑程序。
附图概述为了更好地理解本发明，可参考附图，其中
图1是先进的智能网络构造的简化方框图；图2是多业务平台的简化方框图；图3是依据本发明原理的业务单元软件分层构造的简化方框图；图4是依据本发明原理的某些呼叫处理元件的简化方框图；图5A-5H是依据本发明原理的标准呼叫处理、呼叫逻辑程序处理流及其间相互作用的简化流程图；图6是依据本发明原理的示例触发器(trigger)数据库和元件的简化方框图；图7A和7B是依据本发明原理的示例触发器处理的处理流的简化流程图；以及图8是涉及用户开发的呼叫逻辑程序的示例呼叫处理的处理流的简化流程图。
本发明的较佳实施方式图1-8中示出了本发明的较佳实施例，相同的标号指各图中相同和相应的部分。
I．分布式电信交换系统依据本发明原理的可编程呼叫处理系统和方法提供了灵活的接口，该接口使电信业务供应商可在如图1所示的分布式电信交换系统10(多业务平台)上实行和扩展自己的呼叫处理特性。在Self等入于1996年2月27日提交的5,495,484号美国专利中详细描述了分布式电信交换系统10，这里作为参考来引述。把分布式电信交换系统10耦合到如国际电信联盟(ITU)、美国国家标准化学会(ANSI)和贝尔通信研究所(Bellcore)所定义的先进的智能网络(AIN)12。
分布式电信交换系统10经由诸如X.25、SS7或C7等工业标准协议与几个先进的智能网络元件业务产生环境(SCE)14、业务管理系统(SMS)16、业务控制点(SCP)18和操作支持系统(OSS)20相连。分布式电信交换系统10进行所有的交换系统和呼叫操作功能。它进行由先进的智能网络12所定义的业务交换点(SSP)功能。
智能外围设备(IP)22还耦合到分布式电信交换系统10并且包含与先进的智能网络12的终端用户和元件交换信息所需的功能和资源。智能外围设备22可包含使它进行诸如收集来自用户的拨号数字、向用户播放所记录的公告、进行话音命令确认等功能的硬件。
电信业务供应商所使用的操作支持系统20用于安装、装备和管理其网络。为了给分布式电信交换系统10提供性能信息以及用于产生终端用户帐单的记费记录，系统10与操作支持系统20相连。系统10还响应于网络管理请求而进行由操作支持系统20所指定的配置操作。
业务控制点18是基于交易的处理系统，其任务是响应于来自需要利于先进的智能网络业务逻辑的SSP呼叫的队列。业务控制点18包含业务逻辑和用于提供基于业务的先进智能网络的数据。业务产生环境14用于产生在业务控制点18中所执行的程序。
业务管理系统16对网络提供网络信息、数据库管理和管理支持。它与业务控制点18相连，以进行准备、数据库管理、业务控制点应用程序管理以及收集话务量计量和测量(TM&M)数据。业务管理系统16主要负责更新业务控制点18中的数据库、使多个业务控制点中的数据库同步并检查数据库。
产生和传送业务逻辑程序是业务产生环境14的功能。业务产生环境14产生定义所需的先进智能网络业务处理的业务逻辑程序(SLP)。这些程序被下载到执行该程序的业务控制点18。SLP定义了这样一个处理，该处理是当SSP确定呼叫模型检测到触发器事件时的给定业务产生的，并且向用于辅助处理的SCP发送一队列报文。
把分布式电信交换系统10分成两个主要区域即硬件和软件，以下将对其进行简述。
A．硬件参考图2，分布式电信交换系统硬件30被分成两个子系统，即业务单元(SU)32和用于窄带34、宽带36和宽频带38的传送单元(DU)。业务单元32是可随意地基于容错硬件的通用计算平台。此外，可用单个计算单元或联网的几个计算单元来实现业务单元32。业务单元32的实现利用了与POSIX兼容的操作系统并提供了“类似于UNIX”的容错计算平台。
业务单元32提供先进的智能网络呼叫控制功能。本发明的可编程呼叫处理系统可位于业务单元32中。由电信业务供应商利用本发明的可编程呼叫处理系统所开发的呼叫逻辑程序也可位于业务单元32中。
传送单元34-38是与应用有关的装置，一般为分布式电信交换系统10提供结构模型、设备、接口和资源。传送单元34-38负责与终端用户话务源的接口。系统10可在同一平台上支持相同或不同类型的多个传送单元34-38。窄带传送单元34、宽带传送单元36和宽频带传送单元38是可连到控制业务单元32的传送单元类型的例子。
B．软件1．基本构造把分布式电信交换系统软件类似地分成两个区域业务单元软件和传送单元软件。业务单元软件对应于本发明的可编程呼叫处理系统和方法，以下将对其进行更详细地描述。业务单元软件最好以面向对象的方法来实现，它可用C++或其它适当的计算机语言来编写。
业务单元应用软件最好在提供“类似于UNIX”操作环境的适应POSIX的操作系统上运行。在独立单元呼叫过程时执行业务单元应用软件程序。这些过程提供了诸如呼叫控制/呼叫处理、业务交换以及操作、管理和维护功能(OA&M)。在这些软件中，呼叫处理软件对应于可编程呼叫处理系统和方法，将在以下对其进行简述。
可使用“类似于UNIX”的过程来实现业务单元呼叫处理软件，该软件最好以有限状态机概念为基础。标准呼叫处理软件提供几个不同的状态机。这些状态机可起到诸如先进智能网络基本呼叫模型等工业标准呼叫模型或特殊用户呼叫模型的作用。使用标准呼叫处理状态机来建立工业标准呼叫模型。
在图3中示出业务单元的内部软件组成。可看出，业务单元软件50由分层结构所构成。此分层结构把应用软件与下层平台功能隔离，并提供可被其它应用软件使用的清楚定义的接口。业务单元软件50包括组成可编程呼叫处理系统和方法52的要素。
从图3，呼叫逻辑程序54是由交换制造商来实现并提供给电信业务供应商的呼叫处理应用，或者是由业务供应商通过依据本发明构成的呼叫逻辑应用程序接口(API)56来实现的应用。从交换制造商处可得到诸如无线本地回路(WLL)、个人通信业务(PCS)和汇接等标准呼叫处理应用。以下可把由业务供应商利用本发明的可编程呼叫处理系统52来实现的呼叫逻辑程序作为用户开发的呼叫逻辑程序或应用。
下一层即呼叫逻辑业务层58通过呼叫逻辑应用程序接口56来实行在呼叫逻辑程序54中所提供的功能。呼叫逻辑业务层58最好提供以下示例操作和设备·操作呼叫即时数据·访问呼叫处理数据库·产生呼叫详细记录(CDR)数据·产生话务量计量和测量(TM&M)数据·控制访问信令·智能外围设备(IP)的控制·先进智能网络标准呼叫模型用法·呼叫模型控制·访问呼叫中的呼叫模型点(PIC)·可编程呼叫模型用法·可编程公共通道信令接口把电话产品和应用所共用的一组业务作为和指定为电信平台业务60。电信平台应用程序接口(API)62对这些业务60提供了一个接口。电信平台应用程序接口62使呼叫逻辑程序54容易使用编程接口。它还进行保证下层系统不受到无效软件请求破坏所必须的检错。呼叫逻辑业务层58还使用电信平台应用程序接口62把该层与电信平台功能的实行隔离开来。
电信平台业务层60最好提供以下可被呼叫逻辑程序54和呼叫逻辑业务58所使用的示例功能·事件报告和记录·基本数据库访问、读/写表和表登录·获取调试信息的跟踪业务·通信业务，包括来去传送单元的报文传送、来去外部系统的报文传送(即SS7、C7报文)·业务单元上过程之间的过程间通信·用于操作系统定时器业务(即，启动/停止/重新启动呼叫逻辑程序层定时器)的绕接器(wrapper)·用于操作系统过程业务(即，启动/停止软件过程)的绕接器·用于操作系统线程(thread)业务(即，启动/停止/重新启动呼叫逻辑程序线程)的绕接器·用于操作系统同步业务(即，mutexes和semaphores)的绕接器·用于系统硬件和软件配置的配置支持·检错和隔离处理·警报记录和公布·处理器启动和初始化把分布式电信交换系统10设计成具有独立和轻便的操作系统。这可由操作系统应用程序接口(API)层64来实现。操作系统应用程序接口层64保证了不必把呼叫逻辑程序54、呼叫逻辑业务58和电信平台业务60严格地链接到由任意特定操作系统所提供的能力。操作系统应用程序接口层64可提供被位于业务单元内的软件的上层54-60所使用的适合POSIX的接口。操作系统应用程序接口层64把该接口限定在操作系统业务层66。操作系统业务层66最好提供了以下的示例功能和能力·基本时序和定时器功能·资源管理·POSIX信号管理·文件和文件系统管理·计算机联网接口·图像用户接口(GUI)和视窗系统支持软件层次中的最下层是低层硬件接口层68。此软件层68负责盘片磁带和其它硬件装置的接口。它提供了被操作系统业务层66所使用的应用程序接口。低层的硬件接口层68也是用于与传送单元进行通信的接口。
2．可编程呼叫处理系统参考图4，方框图更详细地示出可编程呼叫处理系统和方法70的呼叫处理环境。回想以状态机过程80的形式来实行呼叫处理。作为标准系统呼叫处理过程82的一部分，状态机过程80访问呼叫处理静态数据库84来获得与分布式电信交换系统10中的每个硬件电路有关的信息，并访问呼叫处理数据库来完成对这些电路的通话呼叫。每个标准系统呼叫处理过程82还维护与被指定为呼叫块的每个电路的状态有关的呼叫处理瞬态数据库86。呼叫块包括诸如用户所拨的数字、呼叫路由数据等瞬态数据。
呼叫处理状态机过程80使用系统通讯功能88所提供的通信，在每个呼叫处理过程之间进行通信，包括用户开发的应用。它还用于与系统的其余部分相连来传递被诸如电信平台应用程序接口90(如图3所示)等系统软件的其余部分所处理的信息(诸如TM&M或记费数据)。
用户开发的呼叫逻辑程序92可经由系统通讯功能88所提供的报文和共享存储器与标准系统呼叫处理82进行通信。共享存储器最好被可编程呼叫处理系统库功能用来直接访问呼叫处理数据库84和86。如图4所示，可编程呼叫处理系统52还在业务供应商所开发的呼叫逻辑程序92和静态及动态数据库84和86之间提供一个应用程序接口94。用户开发的应用92最好是C++程序，或由业务产生环境(SCE)使用业务独立块(SIBs)所产生。可用有效的商用软件工具来编译用户开发的环境逻辑程序92，以使它包括与标准呼叫处理82和数据库84及86相连的应用程序接口文件。
图5A-5H中示出标准呼叫处理82和可编程呼叫处理系统52的全部示例操作。首先参考图5A，在块500开始标准呼叫处理过程。在块501开始软件的初始化，然后在块502读取配置文件和对内部数据结构进行初始化。在块503对触发器数据库的结构进行初始化，并从预定文件中读取任意固定入口并把它插入触发器数据库中的适当位置。接着，如块504所示，通过对电信平台的应用程序接口呼叫来产生形成状态机的软件过程。如块505所示，产生用于交换报文的邮箱。在块506完成标准呼叫处理的初始化，块506向系统指令现在可产生呼叫逻辑程序并可对其进行初始化。然后，进到图5B，如块507所示，标准呼叫处理过程等待将在其邮箱中接收的报文。这使操作系统在等待报文时暂停标准呼叫处理软件。
呼叫逻辑程序过程初始化550进行初始化逻辑，此逻辑非常类似于如块551中所示的标准呼叫处理过程所进行的逻辑。在标准呼叫处理过程已结束初始化并暂停后，由操作系统来控制呼叫逻辑程序初始化。在块552，由呼叫逻辑程序92来限定邮箱，该邮箱用于接收来自包括标准呼叫处理过程等其它过程的报文。该邮箱也用于把报文发送到其它过程。
接着，如块553所示，从触发器数据库554中读取所需的触发器。由技艺接口程序来定义这些触发器，或者它们也可由业务产生环境程序来产生。如块555所示，呼叫逻辑程序应用程序接口94用于在标准呼叫处理触发器数据库中设定所需的触发器。呼叫逻辑程序的本体是传递到用于建立呼叫触发器的应用程序接口的数据的一部分。以下更详细地描述触发器数据库及其功能。
最后，如块556所示，呼叫逻辑程序过程92执行对电信平台应用程序接口90的呼叫，以等待所需电路触发器上的报文。在等待报文时此过程暂停。
如图5B的块510所示，在邮箱中接收到报文使得标准呼叫处理过程恢复执行。在块511，检查接收到的报文以确定它是否为将传递到呼叫处理应用软件(包括呼叫逻辑程序)的报文或与报文有关电路的改变状态机控制的报文。如果接收到的报文表示将被传递到状态机且在块512确定对此电路的控制是返回标准呼叫处理，则在块513中除去与此电路有关的呼叫处理状态的通过标记(marking)。结果，由标准呼叫处理软件依次处理与此电路有关的所有未来报文。
如果在块512确定接收到的报文不属于对特定电路的处理操作的变化，则如514所示将要处理的状态机的报文，如返回块507的执行所示，标准呼叫处理软件重新开始等待要处理的另一个报文并在没有报文等待时暂停。
如块515所示，处理用于特定电路的报文，如果在块516中确定相关电路处于通过状态时把这些报文传送到呼叫逻辑程序。如块517所示，把用于由呼叫逻辑程序所控制电路所收到的报文放置在一报文中并经电信平台应用程序接口发送到呼叫逻辑程序。如块507所示，标准呼叫处理软件重新开始等待要处理的另一个报文，并在没有报文等待处理时暂停。
进到图5D，如块518所示，进行测试以确定电路的当前状态是否允许为该电路而设定触发器。如块519所示，如果此状态不允许触发器，则标准呼叫处理逻辑处理接收到的报文，如块507所示，标准呼叫处理逻辑重新等待要处理的另一个报文，并在没有报文等待处理时暂停。
在块518确定允许触发器的情况下，在块520中检查触发器数据库554并如块521所示确定是否存在用于此电路的触发器。如果不存在触发器，则把接收到的报文传送到标准呼叫处理软件加以处理，如块507所示，此标准呼叫处理软件等待要处理的另一个报文并在没有报文等待处理时暂停。
如块522所示，在块521中检测到有效的触发器导致使用标准呼叫处理软件接收到的报文，该报文被用于“触发”电路的呼叫逻辑程序的报文结构。然后，在块523中把该电路的状态标为“通过”状态。这意味着把标准呼叫处理过程接收到的用于此电路的所有未来报文传送到呼叫逻辑程序。呼叫逻辑程序可在不希望接收用于该电路的报文时通过到状态机的报文来指令标准呼叫处理。然后，如块524所示，经由电信平台应用程序接口把新格式化的报文发送到呼叫逻辑程序。然后，如块507所示，标准呼叫处理软件重新开始等待另一个要处理的报文并在没有报文等待处理时暂停。
如图5E的块560所示，呼叫逻辑程序过程暂停，直到它接收到另一个过程发送给它的一个报文。确切的处理与呼叫逻辑程序的设计和实行有关。待进行的所需操作是呼叫逻辑程序处理与使用呼叫逻辑程序应用程序接口的结合。呼叫逻辑程序在块561进行并完成所需的应用程序接口功能，然后返回块560以等待进一步的报文。如果没有报文等待处理则暂停。
块562-576提出了可在块561中进行的示例的呼叫逻辑应用程序接口功能。在块562中，读取特殊电路的呼叫处理动态数据库86(图4)。标准呼叫处理使用动态数据库86中的数据来完成基于标准呼叫处理模型的呼叫。这种数据的一个例子是在此电路上产生的呼叫所拨的号码。一些动态数据专用于标准呼叫处理状态机软件，可不通过呼叫逻辑程序应用程序接口94来提供这些数据。
在块563中，呼叫逻辑应用程序接口可用于更新与用于给定呼叫的特殊电路有关的动态数据库86。然而，不允许呼叫逻辑应用程序接口改变动态数据中的所有参数，且应用提供给应用程序接口的所有数据之前要验证这些数据。使用此功能的一个例子是把呼叫号码编译成不同的目的地号，并把新的呼叫号码写入该电路的动态数据库。指令标准呼叫处理继续该呼叫的发送，就象已由呼叫电路拨了这个新的呼叫一样。
在块564中使用呼叫逻辑应用程序接口使呼叫逻辑程序取得与给定电路或中继线群有关的呼叫处理静态数据库84。此数据库一般包含与电路或中继线群有关的以下类型的信息电路类型、信令类型信息、路由信息等。
块565中的呼叫逻辑应用程序接口功能允许选择性地访问标准呼叫处理记费记录或呼叫详细记录(CDR)中的某些字段，从而可由呼叫逻辑程序来改变这些字段。应用程序接口限制了对那些被定义为用户可更新的字段的访问，从而用户不可以改变所有的字段。
如块566所示，提供了编写完整的呼叫详细记录(CDR)的能力，从而呼叫逻辑程序可编写记费记录来替换通常要通过标准呼叫处理来编写的记录。这有利于呼叫逻辑程序产生它自己独有的呼叫详细记录。
块567是产生一个或多个用户话务量计量和测量(TM&M)计数器的能力。此功能使呼叫逻辑程序定义特定呼叫逻辑程序所独有的话务量计量和测量计数器。以对系统标准计数器所提供的相同的方式来收集和报告这些计数器。
呼叫逻辑程序使用块568中所示的功能来使话务量计量和测量计数器递增。这些计数器可以是标准呼叫测量所提供的计数器或由在块567呼叫逻辑程序所定义的用户计数器。
呼叫逻辑程序还可经由在块569中的功能与智能外围设备22(图1)相连。为了收集数字、播放所记录的公告等，智能外围设备提供了与终端用户相连的能力。此应用程序接口使呼叫逻辑程序可与智能外围设备相连并使其业务可用于呼叫逻辑程序。
分布式电信交换系统具有由标准呼叫处理软件所提供的许多可编程能力。块570中所示的应用程序接口功能使呼叫逻辑程序可在把对外部系统预定的报文发送到这些系统前接收这些报文以传送信令信息。呼叫逻辑程序可改变这些信令报文或在把这些报文传送到目的地前把定制字段加到这些报文。
在块571中，应用程序接口功能使呼叫逻辑程序使用作为电信平台一部分的时序设备。可设定一定时器来把软件所定义的报文发送到呼叫逻辑程序。还可由此接口来提供停止运行着的定时器或删除定时器的能力。
如块572所示，可由呼叫逻辑应用程序接口来设定特定电路的呼叫触发器。此触发器使得在标准呼叫处理软件状态机碰到所定义的触发器状态时给呼叫逻辑程序发送一报文(接收控制)。以下将更详细地描述触发器的机构。
类似地，如块573所示，可由呼叫逻辑应用程序接口来清除由呼叫逻辑程序预先设定的呼叫触发器。
在块574中，应用程序接口可把标准呼叫处理呼叫模型提高到呼叫中的特定点(PIC)，以影响由标准呼叫处理软件所提供的标准呼叫模型的操作。结果，呼叫逻辑程序可在必要时使标准呼叫模型处于“跳过”状态或重新执行状态。此功能给呼叫逻辑程序提供了定制标准呼叫模型的操作的能力。
如块575所示，另一个应用程序接口功能将把新的呼叫状态和对这些状态的处理加到呼叫模型中。新的状态和处理将变为标准呼叫模型的嵌套(embeded)部分，而且在实行此处理时不需要触发呼叫逻辑程序。
在块576中，应用程序接口功能还可指令标准呼叫处理状态机恢复对特定电路的标准处理。此能力使呼叫逻辑程序可对呼叫处理的几个步骤进行增益控制，然后把控制返回用于呼叫的其余部分的标准呼叫处理或直到碰到用于此呼叫逻辑程序的另一个触发器。
从以上描述中可看出，标准呼叫处理能检测标准呼叫处理期间的触发器状态并使用本发明的呼叫逻辑应用程序接口把队列报文发射到业务控制点应用或把呼叫处理控制传送到用户开发的呼叫逻辑程序。把触发机构设计成支持用于触发器处理的工业标准，但只讨论提供把呼叫处理控制传送到呼叫逻辑程序的机构。图6示出触发器数据库600的组成以及数据库内的成员或结构之间的关系。
参考图6，触发器数据库600包括触发器规则项目指针清单601，该清单是用于访问呼叫中给定点(PIC)的触发器规则项目判断树。由呼叫中点的数目来估计清单601的尺寸以及编索引。触发器规则项目指针清单601包含一触发器规则项目指针字段602，该字段是对呼叫中给定点的触发器规则项目判断树的第一触发器规则项目611的指针。
触发器规则项目611是具有将在触发器规则项目判断树中评估的独立判据(criteria)的数据结构。它包含用于确定如何进行估计以及根据该评估的结果采取什么动作的信息。用于呼叫中给定点的所有触发器包括一个或多个触发器规则项目。每个触发器规则项目611包含除外标志612、判据节点索引613、触发器数据索引614和两个下一触发器规则项目索引字段615和616。实际上，由触发器处理遍历(traverse)的触发器规则项目是触发器规则项目判断树中的节点。
除外标志字段612包含表示是否在估计匹配条件为真(TRUE)时停止遍历判断树的值。通过估计包含在以下详述的判据节点603中的信息来确定匹配条件。如果此标志为TRUE且估计匹配条件为TRUE，则在该点停止判断树的遍历而不触发。除外标志字段612使程序员在任意点处的将“短路”条件插入判断树中以防止不必要的遍历。
判据节点索引字段613是用于给定触发器规则项目的判据节点数据603的索引。触发器数据索引字段614是用于给定触发器规则项目的触发器数据621的索引。下一触发器规则项目索引615是在碰到匹配(MATCH)条件或接收到来自业务控制点队列报文的继续(CONTINUE)响应时下一触发器规则项目的索引。而另一个下一触发器规则项目索引字段616是在碰到不匹配(NO MATCH)条件时属于下一触发器规则项目。
如上所述，判据节点603包含用于确定对匹配进行检查的信息类型、要进行比较的类型、再检查的数据匹配结果以及在其上进行匹配特定呼叫的信息。每个判据节点结构603包含以下所述的多个字段。
判据节点603包括判据ID字段604。此字段规定了包含在匹配值清单617中的数据的类型。数据类型为数值或数字串。使用标准ID字段确定在哪里得到对匹配值清单入口进行比较的源数据的应用。判据节点603还包括操作ID字段605。操作ID字段605规定了要进行的操作的类型以指明匹配条件。它支持诸如=、≠、＜、＞、≤、≥等基本逻辑算符。对包含在匹配值清单617中的数据进行操作，该清单可以是数字、数字清单或由两个数字所规定的范围。以上所述的判据ID 604用于确定把什么数据库和要素与匹配值清单入口进行比较。
判据节点603还包括清单类型字段606，该字段规定了是否把匹配值清单617中的数据看作值的清单或值的范围。如果要把数据看作一个清单，则对于匹配扫描整个清单。如果清单类型是范围，则它包含表示所包含的上下值的两个值。
在判据节点603中还设有匹配值清单偏移字段607。该字段是从匹配值清单617开始的字节偏移，以获得用于当前判据节点的匹配值。判据节点603还包括入口的匹配值阵列数字段608，该字段包含在清单617中用于当前判据节点的匹配值入口的数目。
判据节点603中的匹配结果字段609还包含对给定呼叫遍历所进行的匹配比较的结果。它是真、假或不估计。该字段保证了在遍历中对给定呼叫和给定判断树只进行一次估计。在判据节点603中还包括呼叫ID字段510来识别在其上进行给定匹配的特定呼叫。
触发器数据库的另一个结构是匹配值清单617，该清单包含可在触发器状态的匹配比较中搜索到的诸如数值或数字串等值的清单。特殊情况的清单是一个表示值的范围的清单。为了进行范围比较，把清单617限于表示该范围上下限的两个值。此外，每个匹配值清单617包含入口的匹配值数目字段620，该字段提供了对清单617中匹配值数目的计数。
触发器数据521是触发器数据库600中的另一个要素。该数据结构包含用于建立队列报文并把它传送到业务控制点或呼叫逻辑程序的信息。每个触发器数据结构621包含以下字段。
触发器类型字段622是此特定触发器数据621映射到的工业标准触发器。触发器类型字段622中的值确定了发送到业务控制点应用的队列报文的类型。触发器数据结构621还包括触发器判据类型字段623。该字段包含如工业标准所定义的包含在发送到业务控制点的报文中的触发器数据。
触发器数据结构621还包括全局标题编译(GTT)字段624。该字段表示需要使用第7号信令系统(SS7)全局标题编译的业务控制点队列。全局标题编译值确定全局标题编译路由是否要使用被呼叫的号码或呼叫者号码。如果不需要使用全局标题编译路由的业务控制点队列，则该字段为空(NULL)。
触发器数据621中的点代码字段625包含表示需要使用SS7点代码和子系统号码路由的业务控制点队列的值。该值是必须处理从此触发器状态获得的队列报文的业务控制点的SS7点代码。如果不需要使用点代码和子系统号码路由的业务控制点队列，则该字段为NULL。
另一个字段即子系统号码626是位于必须处理从此触发器状态获得的的队列报文的业务控制点处的应用的SS7子系统号码。该子系统号码只在规定点代码时才有效。如果不需要使用点代码和子系统号码路由的业务控制点队列，则该字段为NULL。
触发器数据621还包括报文队列627，该队列包含用于把队列报文传送到适当的业务控制点应用或呼叫逻辑程序的报文队列的名称。
图7A和7B是示出示例的触发器处理过程的流程图。标准呼叫处理检查在呼叫中各点处的触发器状态。这是通过呼叫触发器处理701以及把呼叫中的该点作为一个参数来实现的。如块702所示，并参考用于触发器数据结构的图6，触发器处理701把呼叫中的该点编入索引成为触发器规则项目指针清单601，以访问使触发器规则项目611定位的触发器规则项目指针602。如块703所确定的，如果触发器规则项目指针602为NULL，则触发器处理如块716所示返还NULL触发器数据索引来表示未检测到触发器状态。
如果触发器规则项目指针602不为NULL，则如块704和705所示，使用由触发器规则项目611中的触发器规则项目指针602所定位的判据节点索引613来访问判据节点603。如上所述，判据节点603定义了匹配值清单617中数据的类型(即什么操作对此数据是有效的)，且包含对匹配值清单617的指针。如块706所示，判据节点603包含使当前判据节点的匹配值定位的匹配值清单偏移607，并搜索匹配的触发器值。在块707中返还是否检测到匹配状态的指示。
如果判据节点处理表示不存在匹配状态，则访问下一触发器规则项目索引(不匹配)615。如果在块703中确定该项目为NULL，则在块716中返还表示未检测到触发器状态的NULL触发器数据索引。否则，对字段615所指的下一触发器规则项目重复判据节点处理。
如果在块707中判据节点处理表示匹配状态，则如块709所示访问触发器数据索引。如果在块710中确定触发器数据索引为NULL值，则如块711所示触发器处理访问下一触发器规则项目索引(匹配或继续)字段616。如果在块712中确定字段616为NULL，则在块716中返还表示未检测到触发器状态的NULL触发器数据索引。如果在块710中确定触发器数据索引不为NULL值，则在块713返回标准呼叫处理以表示检测到匹配的触发器状态。
如果在块716把NULL触发器数据索引返还标准呼叫处理，则标准呼叫处理在呼叫的当前点处恢复呼叫处理。另一方面，如果在块713中触发器处理表示匹配状态并返还了不包括NULL触发器数据索引，则标准呼叫处理使用由返还的触发器数据索引所指的触发器数据来建立队列报文并把它传送到业务控制点应用或呼叫逻辑程序。触发器数据621中的触发器类型字段622定义了要建立的队列报文的类型，触发器判据类型字段623是包含在结果队列报文中的在工业上定义的参数。如果要使队列报文指向业务控制点应用，则字段624中的全局标题编译标志或点代码和子系统号码字段625和626具有非NULL值。如果要使队列报文指向呼叫逻辑程序，则全局标题编译、点代码以及子系统号码字段具有NULL值。然后，标准呼叫处理使用报文队列字段627对业务控制点应用或呼叫逻辑程序所建立的队列报文进行排列。
在操作中，电话业务供应商可使用在依据其可编程呼叫处理系统和方法的呼叫逻辑应用程序接口中提供的功能来实行它自己的定制呼叫逻辑程序。依据本发明的原理，把构成的可编程呼叫处理系统和方法52主要设计成支持用户特征。可支持特征的一个例子是增强的编译能力。电信业务供应商不能开发需要改变底层系统的那些特征。例如，不能通过可编程呼叫处理系统52来实行把新的信令协议加到该系统。
用户开发的呼叫逻辑应用是与标准交换软件过程分开的过程。把这些应用开发成为C++程序或使用业务产生环境工具来产生。其后，可使用商用的软件工具来进行编译，这些应用使用留在系统10上的软件库。这些用户开发的呼叫逻辑应用以独立的POSIX/“类似于UNIX”的过程来运行，且这些应用服从由此操作系统所加的所有限制。用户开发的程序可以使用呼叫处理元素和系统数据库以及发报设备。可编程呼叫处理系统52对用户开发的呼叫逻辑程序和标准呼叫处理功能之间的接口提供屏蔽。可编程呼叫处理系统还保证传送到嵌套的系统功能的所有数据都有效并丢弃那些未通过检查和检验的数据。
例如，检查如何来实行用户开发的呼叫逻辑程序来提供增强的编译能力是有益的。在图8中示出示例的处理流程。参考图8，在块800中开始实行用户开发的呼叫逻辑程序的处理流程。在块802，用户开发的呼叫逻辑程序使用呼叫逻辑应用程序接口来设定用于诸如在特定中继线群电路上接收到SS7原始地址报文(IAM)等特殊事件的触发器。其后，如块804所示，在碰到指定的事件时，诸如当标准呼叫处理状态机接收到IAM报文时，标准呼叫处理过程击中触发器，这表明要由用户开发的呼叫逻辑程序来处理该事件。然后，如块806和808所示，标准呼叫处理过程对适合的报文进行格式化，把该报文传送到用户开发的呼叫逻辑程序并把电路置于“等待”状态。
在块810中，用户开发的呼叫逻辑程序接收到由标准呼叫处理所发送的报文并进行如块812所示的适当操作，诸如访问其编译数据库来确定如何传送此呼叫并把路由数据置于与该电路有关的呼叫块中。如块814所示，当用户开发的呼叫逻辑程序结束其操作时，它把一报文送回标准呼叫处理过程以通知它继续处理和传送该呼叫。如块816所示，标准呼叫处理过程在接收到该报文时，继续该呼叫并在被中断的点或由用户开发的呼叫逻辑程序所指的不同点处恢复标准处理。标准呼叫处理可连续碰到使它把控制传送到用户开发的呼叫逻辑程序的一个或多个附加的触发器。
这样，可编程呼叫处理系统和方法在公共交换系统的完整部分通用计算平台上提供了集成的可编程呼叫处理构造。可编程呼叫处理系统和方法为业务供应商提供了一种方法，以控制相对于不容易用智能网络技术复制的业务特征和操作支持数据的交换功能。
本构造的一个优点是可容易地把基于标准的呼叫模型扩展到提供定制的呼叫处理特征。可在更新工业标准前，使终端用户利用这些特征。此构造还允许支持与定制操作平行操作的工业标准。
此交换产品中的呼叫逻辑程序管理能力保证了●整个系统的可靠性不受业务供应商的编程的影响。这是通过所支持的应用程序接口所进行的呼叫逻辑程序执行监控、POSIX/“类似于UNIX”过程管理以及对普通操作系统能力的受控访问来实现的。
●呼叫逻辑程序的受控安装、测试、启动、去启动和翻译。
●呼叫逻辑程序资源控制。
●可获得呼叫逻辑程序性能统计。
呼叫逻辑程序应用程序接口在本地的呼叫处理软件上提供了基于标准的特殊和可编程的功能性操作。这些功能性操作允许●对将与本地呼叫处理功能相关的话务量计量和测量收集计数器进行特殊化。在相关后，由本地呼叫测量功能使这些计数器自动递增，接着为进行进一步处理由呼叫逻辑程序来读取这些计数器。
●可从呼叫逻辑程序中访问与每次呼叫记费数据收集有关的本地呼叫处理呼叫详细记录。呼叫逻辑应用程序接口提供了把选中字段修改以及可变长度字段加到呼叫详细记录中作为业务提供的专用字段的方法。
●呼叫逻辑程序可看到在涉及SS7 ISUP和ISDN主速率的各种报文定向访问配置中所使用的呼叫控制网络信令协议。呼叫逻辑程序可在输入和输出呼叫处理动作的选中点处增加、修改或删除标准、任意和业务供应商的专用参数。这些呼叫逻辑程序动作提供了明显通过和受行为影响的本地呼叫处理。
●关于来自Bellcore和ITU的各种工业标准文件中所述的智能网络呼叫模型的概念，呼叫逻辑程序通过应用程序接口可使用的许多增强的操作。
●配备(arm)/不配备(disarm)当前执行呼叫模型中的触发器/事件检测点。
●在优先级中插入或除去触发器检测点处的触发器滤波规则。
●根据触发器处理标准的满足程度，控制将在呼叫逻辑程序启动时呈现给它的各种静态和动态数据元素的可见度。
●使呼叫中新的点(具有附属触发器和事件检测点、触发器类型和触发器标准)与本地基本呼叫处理软件中的入口点相关。
●与本地呼叫处理构造内的特征交互管理软件交互来实现所定制的业务交互控制。
●与本地呼叫处理构造中的业务交换功能交互来修改与外部智能网络系统有关的交互规则。这些交互可影响智能网络报文的格式化、网络系统路由和多信道广播。
●与信息记录和从盘片的搜索有关的文件系统操作的请求(invocation)。
●对应于该记录处的网络管理数据通信链路和文件传输等级的管理操作的请求。
权利要求
1．一种用于电信交换系统的可编程呼叫处理系统，其特征在于包括标准呼叫处理过程，用于依据工业标准呼叫模型来进行呼叫处理；至少一个数据库，用于存储可被所述标准呼叫处理过程组访问的呼叫处理数据；至少一个定制的呼叫逻辑程序，用于在电信交换系统上实行扩展的用户特征；以及应用程序接口，用于提供所述至少一个定制的呼叫逻辑程序对所述至少一个呼叫处理数据库的入口，且为了执行所述至少一个定制的呼叫逻辑程序而中断所述标准呼叫处理过程。
2．如权利要求1所述的可编程呼叫处理系统，其特征在于所述标准呼叫处理过程包括由所述应用程序接口插入的至少一个触发器，用于在发生特定事件时把控制传递到定制的呼叫逻辑程序。
3．如权利要求1所述的可编程呼叫处理系统，其特征在于还包括存储用于中断所述标准呼叫处理过程并把控制传递到所述至少一个定制的呼叫逻辑程序的一个或多个触发器定义的触发器数据库。
4．如权利要求3所述的可编程呼叫处理系统，其特征在于所述触发器数据库包括以呼叫中发生触发事件的点来编索引的触发器规则项目点清单；由所述触发器规则项目点清单所指的至少一个触发器规则表，在所述表中存储有触发器判据和触发器数据，用于把控制传递到所述至少一个定制的呼叫逻辑程序。
5．如权利要求4所述的可编程呼叫处理系统，其特征在于所述至少一个触发器规则表包括触发器规则项目表，具有用于估计触发事件的多个触发器规则项目；判据节点表，具有用于估计触发事件的数据；以及触发器数据表，具有用于把一报文集中到所述至少一个定制的呼叫逻辑程序以向其传递控制的数据。
6．如权利要求5所述的可编程呼叫处理系统，其特征在于所述至少一个触发器规则表还包括具有在所述触发器事件估计中所使用的值的匹配值表。
7．如权利要求3所述的可编程呼叫处理系统，其特征在于所述触发器数据库包括以呼叫中发生触发事件的点来编索引的触发器规则项目点清单；触发器规则项目判断树，具有由所述触发器规则项目点清单所指的至少一个节点，每个节点存储有触发器判据和触发器数据，用于把控制传递到所述至少一个定制的呼叫逻辑程序。
8．如权利要求1所述的可编程呼叫处理系统，其特征在于所述至少一个定制的呼叫逻辑程序是与所述标准呼叫处理过程分开的过程且它与所述标准呼叫处理过程平行地在所述交换系统上运行。
9．如权利要求1所述的可编程呼叫处理系统，其特征在于所述标准呼叫处理过程起到一组有限状态机的作用，所述至少一个定制的呼叫逻辑程序是嵌套在所述标准呼叫处理状态机内的子状态机。
10．如权利要求1所述的可编程呼叫处理系统，其特征在于所述至少一个呼叫处理数据库包括存储所述交换系统的电路结构的静态数据库。
11．如权利要求1所述的可编程呼叫处理系统，其特征在于还包括用于在所述标准呼叫处理过程和所述定制的呼叫逻辑程序之间传送报文的发报功能。
12．如权利要求1所述的可编程呼叫处理系统，其特征在于所述至少一个呼叫处理数据库包括用于存储呼叫数据块的动态数据库。
13．如权利要求1所述的可编程呼叫处理系统，其特征在于所述应用程序接口包括用于被所述定制的呼叫逻辑程序所使用且包含的接口库。
14．一种用于电信交换系统的可编程呼叫处理的方法，其特征在于包括以下步骤提供用于扩展由标准呼叫处理过程所提供的用户业务的至少一个定制的呼叫逻辑程序；对所述标准呼叫处理过程进行初始化；在发生特定事件时，把控制从所述标准呼叫处理过程传递到所述至少一个定制的呼叫逻辑程序。
15．如权利要求14所述的方法，其特征在于还包括以下步骤把用于触发事件的触发器插入所述标准呼叫处理过程以中断其执行；以及在所述触发事件触发时分析所述事件。
16．如权利要求15所述的方法，其特征在于所述触发器事件分析步骤包括查询用于估计判据和值的触发器数据库。
17．如权利要求15所述的方法，其特征在于所述触发器事件分析步骤包括以下步骤查询具有用于估计触发事件的多个触发器规则项目的触发器规则项目表；查询具有用于估计触发事件的数据的判据节点；以及查询具有用于把一报文集中到所述至少一个定制的呼叫逻辑程序以向其传递控制的数据的触发器数据表。
18．如权利要求17所述的方法，其特征在于触发器数据表查询步骤包括查询具有在所述触发事件估计中所使用的值的匹配值表的步骤。
19．如权利要求15所述的方法，其特征在于所述触发事件分析步骤包括以下步骤查询以呼叫中发生触发事件的点来编索引的触发器规则项目点清单；以及查询触发器规则项目判断树，所述判断树具有由所述触发器规则项目点清单所指的至少一个节点，在每个节点存储有触发器判据和触发器数据，用于把控制传递到所述至少一个定制的呼叫逻辑程序。
20．如权利要求14所述的方法，其特征在于还包括使所述至少一个定制的呼叫逻辑程序访问呼叫处理数据库的步骤。
21．如权利要求14所述的方法，其特征在于还包括以下步骤使所述至少一个定制的呼叫逻辑程序访问具有所述交换系统的电路结构的静态呼叫处理数据库；以及使所述至少一个定制的呼叫逻辑程序访问具有呼叫数据块的静态呼叫处理数据库。
22．如权利要求14所述的方法，其特征在于还包括在完成定制的呼叫处理后在所述特定事件处把控制从所述至少一个定制的呼叫逻辑程序传回所述标准呼叫处理过程的步骤。
23．如权利要求14所述的方法，其特征在于还包括在完成定制的呼叫处理后在特定点处把控制从所述至少一个定制的呼叫逻辑程序传回所述标准呼叫处理过程的步骤。
24．如权利要求14所述的方法，其特征在于还包括在所述标准呼叫处理过程和所述至少一个定制的呼叫逻辑程序之间提供用于在其间传递控制的应用程序接口的步骤。
25．如权利要求14所述的方法，其特征在于还包括使所述至少一个定制的呼叫逻辑程序把呼叫数据块写到用于存储多个呼叫数据块的静态呼叫处理数据库的步骤。
26．如权利要求15所述的方法，其特征在于还包括从所述步骤呼叫处理过程中除去触发器的步骤。
27．如权利要求14所述的方法，其特征在于还包括以下步骤由所述标准呼叫处理过程产生呼叫详细记录；以及使所述定制的呼叫逻辑程序制订呼叫详细记录来替换由所述标准呼叫处理过程所产生的所述呼叫详细记录。
28．如权利要求14所述的方法，其特征在于还包括以下步骤由所述标准呼叫处理过程来制订呼叫详细记录；以及使所述定制的呼叫逻辑程序改变所述呼叫详细记录的选中字段。
29．如权利要求14所述的方法，其特征在于还包括在所述标准呼叫处理过程中嵌套所述至少一个定制的呼叫逻辑程序的步骤。
30．如权利要求14所述的方法，其特征在于还包括以下步骤把所述标准呼叫处理过程模块化成一组有限状态机；以及把所述定制的呼叫逻辑程序模块化成嵌套在所述标准呼叫处理过程状态机中的子状态机。
31．如权利要求14所述的方法，其特征在于还包括以下步骤把所述标准呼叫处理过程模块化成一组有限状态机；以及把至少一个子状态加到所述标准呼叫处理过程状态机。
32．一种用于电信交换系统的可编程呼叫处理的方法，其特征在于包括以下步骤提供用于扩展由标准呼叫处理过程所提供的用户业务的至少一个定制的呼叫逻辑程序；在所述标准呼叫处理过程中设定用于特定状态存在的触发器；对所述标准呼叫处理过程进行初始化；响应特定状态的存在而检测所述触发器，中断所述标准呼叫处理过程，并把控制从所述标准呼叫处理过程传递到所述至少一个定制的呼叫逻辑程序。
33．如权利要求32所述的方法，其特征在于还包括分析所述触发器状态并查询用于估计判据和值的触发器数据库的步骤。
34．如权利要求33所述的方法，其特征在于所述触发器状态分析步骤包括以下步骤查询具有用于估计触器状态的多个触发器规则项目的触发器规则项目表；查询具有用于估计触发器状态的数据的判据节点；以及查询具有用于把一报文集中到所述至少一个定制的呼叫逻辑程序以向其传递控制的数据的触发器数据表。
35．如权利要求33所述的方法，其特征在于触发器数据表查询步骤包括查询具有在所述触发器状态估计中所使用的值的匹配值表的步骤。
36．如权利要求33所述的方法，其特征在于所述触发器状态分析步骤包括以下步骤查询以呼叫中发生触发事件的点来编索引的触发器规则项目点清单；以及查询触发器规则项目判断树，所述判断树具有由所述触发器规则项目点清单所指的至少一个节点，在每个节点存储有触发器判据和触发器数据，用于把控制传递到所述至少一个定制的呼叫逻辑程序。
37．如权利要求32所述的方法，其特征在于还包括使所述至少一个定制的呼叫逻辑程序访问呼叫处理数据库的步骤。
38．如权利要求32所述的方法，其特征在于还包括以下步骤使所述至少一个定制的呼叫逻辑程序访问具有所述交换系统的电路结构的静态呼叫处理数据库；以及使所述至少一个定制的呼叫逻辑程序访问具有呼叫数据块的静态呼叫处理数据库。
39．如权利要求32所述的方法，其特征在于还包括在完成定制的呼叫处理后在所述特定状态处把控制从所述至少一个定制的呼叫逻辑程序传回所述标准呼叫处理过程的步骤。
40．如权利要求32所述的方法，其特征在于还包括在完成定制的呼叫处理后在特定点处把控制从所述至少一个定制的呼叫逻辑程序传回所述标准呼叫处理过程的步骤。
41．如权利要求32所述的方法，其特征在于还包括在所述标准呼叫处理过程和所述至少一个定制的呼叫逻辑程序之间提供用于在其间传递控制的应用程序接口的步骤。
42．如权利要求32所述的方法，其特征在于还包括使所述至少一个定制的呼叫逻辑程序把呼叫数据块写到用于存储多个呼叫数据块的静态呼叫处理数据库的步骤。
43．如权利要求32所述的方法，其特征在于还包括从所述标准呼叫处理过程中除去触发器的步骤。
44．如权利要求32所述的方法，其特征在于还包括以下步骤由所述标准呼叫处理过程产生呼叫详细记录；以及使所述定制的呼叫逻辑程序制订呼叫详细记录来替换由所述标准呼叫处理过程所产生的所述呼叫详细记录。
45．如权利要求32所述的方法，其特征在于还包括以下步骤由所述标准呼叫处理过程来制订呼叫详细记录；以及使所述定制的呼叫逻辑程序来改变所述呼叫详细记录的选中字段。
46．如权利要求32所述的方法，其特征在于还包括在所述标准呼叫处理过程中嵌套所述至少一个定制的呼叫逻辑程序的步骤。
47．如权利要求32所述的方法，其特征在于还包括以下步骤把所述标准呼叫处理过程模块化成一组有限状态机；以及把所述定制的呼叫逻辑程序模块化成嵌套在所述标准呼叫处理过程状态机中的子状态机。
48．如权利要求32所述的方法，其特征在于还包括以下步骤把所述标准呼叫处理过程模块化成一组有限状态机；以及把至少一个子状态加到所述标准呼叫处理过程状态机。
全文摘要
一种可编程呼叫处理系统(52)提供了依据工业标准呼叫模型进行呼叫处理的标准呼叫处理过程(80)、用于存储可被标准呼叫处理过程组(80)所访问的呼叫处理数据的至少一个数据库(84,86)以及用于在电信交换系统(10,30)上实行扩展的用户特征的至少一个定制的呼叫逻辑程序(92)。此外,应用程序接口(56,94)提供至少一个定制的呼叫逻辑程序(92)对至少一个呼叫处理数据库(84,86)的入口,且为了执行至少一个定制的呼叫逻辑程序(92)而中断标准呼叫处理过程(80)。
文档编号H04Q3/545GK1221539SQ97195359
公开日1999年6月30日 申请日期1997年4月8日 优先权日1996年4月10日
发明者J·L·邦奇, R·A·约文, S·O·佩里三世, L·J·普钦斯基, 小W·C·罗伯逊, R·L·洗德 申请人:Dsc电讯有限合伙公司