构成呼叫处理的方法和电话呼叫处理的交换系统的制作方法

专利名称：构成呼叫处理的方法和电话呼叫处理的交换系统的制作方法
技术领域：
本发明涉及一种用于呼叫处理的数据结构，特别是涉及一种对于电信应用的话务控制处理中的数据构成。
背景技术：
在电信系统中一次呼叫的处理期间，需要进行处理或控制大量的数据。这些与呼叫有关的数据彼此有所不同，取决于在某一具体呼叫中使用哪一类业务，及与周围网络通信使用哪些协议。数据中含有对于电信系统不同种类用户有用的信息。一种网络/服务提供者可能希望产生计费记录，而另外的提供者希望产生不同种类的统计。因为卖主希望不取决用户希望使用哪些数据，和不需要改变业已存在的软件的情况下，仍然可能与新的业务一起增加新的数据，这种与呼叫有关的数据记录则必须以一种新的有效方式进行处理。
存在着若干种处理与呼叫有关的数据的可能的解决办法。一种明显的办法是使用常规的数据库采集信息，这种办法很快就表现出容量的问题。另外一种解决办法是挑选一个说明的解决办法，在这种办法中要做出各内容的一个说明(例如，比较以PASCAL语言的一个记录)。按照PASCAL语言的记录的一个说明的解决办法的缺点是它不能提供所需要的灵活性。再另外一个办法是只要是需要，就在各个对象之间发送数据。
在现有技术阶段有几个涉及在现代电信系统中用于处理的面向对象的软件结构的概念。名称为“电信系统的数据处理系统的逻辑结构(Structure de logiciel pour syste`me de traitement de donne｀es，Iamment pour syste｀me de te｀lecommunications)”特别是在电信系统中用于处理数据的逻辑结构系统。该结构按照CCITT X200规则，特别地简化了各个对象之间的实时通信。名称为“信息处理系统的逻辑结构(Structure de logiciel pour syste｀me de traitement d｀informations)”的EP-0 524 077 A1描述了隐藏硬件和软件系统特征到应用程序中的一种结构。
EP-0 470 415 A2描述了在电话系统中访问公共数据库的与呼叫有关信息提供多个应用处理器的一种方法。只要通信在持续，该信息在数据库中的作为有关记录被暂时标记和存储。该信息特别用于在由操作员控制的交换系统中用于在一个显示终端上直接可视地监控。
本发明的概要因此，在电信系统中有一个要求，即，最好是通过软件的方式产生一个标准和通用结构，在不影响业已存在的利用半呼叫(half-call)原理的系统软件的操作情况下，可能以新的业务和数据扩充该系统。
按照本发明的第一个目的是将半呼叫原理和各个正在执行的半呼叫之间的通用协议相组合且包括一个由对话作用域和利用存储功能的话务情况作用域组成的对话期间，其中不同的记录存储各指针到本地存储器功能单元，将指针和一个标记单元进行组合借助它那些本地存储的数据将被唯一地识别和虽然不是真正的全局数据，但是在特定记录存在的周期的一个特定的对话期间仍然可以被作为全局数据来利用。
按照本发明的第二个目的是该特定的对话作用域利用存储各个指针的对话记录执行该呼叫的各个对象和从该记录将有可能找到在该对话期间内的所有其它对象，如果对象在其下被存贮的标记单元是已知的，其它数据对象参照对话记录或话务情况记录被存储在事务处理记录中。
按照本发明的第三个目的，话务情况作用域具有与对话作用域相类似的结构和话务情况记录是参照对话记录的和话务情况记录是被形成用于执行一个呼叫的各个对象。
按照本发明的第四目的是，事务处理记录存贮属于话务情况的各个数据对象。
本发明的第五个目的是，标记单元是利用唯一地分配给每个执行的对象或被存储的数据对象的一个整数来实现的。
附图简述通过参照下面的结合各附图的描述，本发明的其它目的和优点将会得到更好的理解，其中

图1是具有对话控制器SC的一个对话期间的说明，该对话控制器处理若干个话务情况，该若干个话务情况包括对于每个话务情况来说具有一个相应的始发呼叫OC，与其它的包括一个相应的端接呼叫TC的话务情况进行通信；图2表示利用按照本发明的方法和系统的对话期间控制器SC，一个对话期间记录存储执行各个对象的参考和事务处理记录存储各个数据对象的参考；图3表示按照本发明的方法和系统的采集，在始发呼叫OC内存储一个话务情况对象；图4是在一个对话期间中控制数据流的各个对象的说明；图5表示当计费基础数据被从对话期间提取时的一个例子；图6表示在所产生的被管理的各个对象之间的关系的一个简单例子；图7表示按照图6的简单例子的完整静态图；图8在呼叫处理期间的事务处理记录中的呼叫数据采集的简单流程图；和图9是包括在输出中的数据的规范的简单流程图。
基本原理为了以有效方式处理本发明的各个主题，将首先具体地定义一些技术术语，这些术语在下面的描述中自始至终是有用的。
在电话呼叫处理交换系统中构成软件的一种普通方式是将呼叫的控制分为两半，一个半呼叫A和一个半呼叫B。在被称为session(对话期间)的过程执行控制一个半呼叫的软件。一个对话期间可以同时处理一个或若干话务情况(Traffic Cases)(例如在多个呼叫状态中)。话务情况定义在一个对话期间中处理一个呼叫的功能和数据。注意，三方呼叫是由在一个对话期间中的两个话务情况处理的，一个话务情况用于一个呼叫支线。
为了简单起见，对话期间是以不同的作用域构成的和因此引人对话期间作用域(Session Scope)和话务情况作用域(Traffic CasesScope)。对话期间作用域受基本码流对话期间控制器SC的控制。对话期间控制器的主要任务是作为接入协议ACP的命令翻译器和根据这些命令(消息)进行业务分析。这包括例如，然后初始化和结束新的话务情况，从接入协议向正确的话务情况分配信息，初始化新的业务等等。
在对话期间内的每个话务情况由一个基本码流(basefiow)控制。这种基本码流可以是一个始发呼叫OC，或者是一个终接呼叫TC。这个基本码流的主要任务是管理该基本呼叫的处理。这包括例如建立/断开一个呼叫(包括各呼叫的各一半之间的电信业务协议TSP的处理)，调整连接的建立/断开(例如话音连接)，和调整地址信息分析等。
为了支持不同作用域和控制其中的逻辑操作，需要一种类似的数据结构。因此，数据必须是以某种方式来构成，以使其有可能实现和保持各种应用。从而，存在着两种不同的对象类型，在本说明书中这两种对象类型被表示为执行对象和数据对象。
执行对象将在该对话期间进行执行，例如控制对象、协议对象、资源对象等。纯数据对象将包含例如从电信业务协议消息中接收的数据。还可能将输出这种数据类型，用于计费或统计的目的。该两种对象类型具有不同的语义(semantics)和被存储在对话期间的不同记录中。这样一个记录称为对话期间记录(Session Record)和被用于存储指向由对话期间内的控制和资源对象实例化的协议对象和资源对象的指针。存储在对话期间记录中的各个对象对于整个对话期间是公用的。存储的纯数据对象被用于事务处理记录(Transaction Record)。以与对话期间记录存储指向各个对象的指针相类似的方式，事务处理记录(也称为呼叫记录)被用于存储指向由在该对话期间中的控制、协议、和资源对象或对话期间正在执行的话务情况所实例化的各个纯数据对象的指针。
对话期间记录的用户视称为对话期间记录视(Session RecordView)和在高度抽象级上给予用户到对话期间记录的一个接口。类似地，事务处理记录的用户视称为事务处理记录视(Transaction RecordView)和在高度抽象级上给予用户到事务处理记录的一个接口。
最后，还有一个话务情况记录，该记录中存贮了指向属于一个话务情况的对象的指针。这个记录中只有指向协议对象和各个资源对象的指针。将要使用事务处理记录来存储纯数据对象。话务情况记录的用户视称为话务情况记录视和在高度抽象级上给予用户到对话期间记录的一个接口。
优选实施例的详细描述为了在电信系统中支持一个呼叫处理的不同的作用域和对应的控制逻辑，我们需要一个合适的数据结构。数据必须被构成为使其可能实现和保持各种应用。因此，我们分别引人了在一个对话期间保持跟踪的两种不同的对象类型，即，执行对象和数据对象。这两个在上文已经被定义了的术语具有不同的语义和被存储在产生的对话期间的不同记录中。当在集合中存储一个对象时，仅仅是存储一个指向该要被存储的对象是指针的问题和因此在这样一个步骤中没有复制该对象本身。这还意味着，对于这样一个指针存储，实际上不需要知道具体对象的大小。
图1是对话期间作用域的概括的图，该作用域由对话期间控制器SC进行控制。对话期间控制器相对于接入协议ACP，起到一个命令翻译器的作用，ACP是用于用户或网络接入的公共术语。从图1显而易见，该对话期间包含一个或几个话务情况，和这里具体的对话期间包含两个都是OC(始发呼叫)型的话务情况。两个OC型的话务情况的每一个是通过处理电信业务协议TSP，借助于相应的话务情况到另外的TC(终接呼叫)型话务情况建立的。
如图2所示，在对话作用域中有一个对话期间记录，该记录将被用于存储一个指向每个对象，例如一个所谓对话期间代理(sessionagent)的指针PTR。借助于其它的指针对话期间记录SR是在每个对话期间中数据结构的根。整个对话期间的数据对象是借助于它们各自的指针PTR在事务处理记录中建立的。在对话期间记录中的每个入口有一个具体的名称或密钥，TAG，若具体的系统操作员知道该具体的名称或TAG，则有可能在对话期间作用域内定位任何对象。
图3是一个话务情况作用域的略图，其中包含一个始发呼叫类型OC，而终接呼叫类型TC应当具有相对应的结构。如果该应用需要在该对话期间执行任意数量的并行话务情况，则将必须引入这个作用域。因此，该话务情况作用域的结构类似于对话期间作用域。对于在一个对话期间的每个话务情况，产生一个话务记录，以存储正在执行的各个对象。类似于在对话记录是利用一个名称或TAR和一个指针PTR。话务情况记录是参考对话期间记录的。因此，存储属于该话务情况的各个数据对象被用于事务处理记录TR，产生用于在这个话务情况级上的各个数据对象的一个表。
每个对话期间或话务情况记录的用户具有一个自己的对象图，通过该对象图可以访问存储的执行对象或数据对象。
图4更为详细地表示通过执行一个始发呼叫OC的对话期间的数据流。当由一个接入代理或输入代理接收某些数据时，该数据流开始。该接收的数据被变换为一种AXE内部表示。然后被变换的数据被存储到事务处理记录TR中。该数据对象是利用标记存储的。该标记是为这个特定数据对象保留的一个整数。其它各用户，例如需要该数据对象的应用分析可以通过标记和通过事务处理记录图对象，即，TR_图，从事务处理记录中提取该数据对象。上述例子也可以说明数据何时由输出代理通过电信业务协议TSP发送到另外的半呼叫。数据是以一种参数形式被发送的，该参数除了数据外还包括识别该数据的标记。
如上所述，数据对象被存储在事务处理记录(事务处理记录的同义词也称为记录)中。正如上面已经描述的那样，经由一个视对象访问事务处理记录TR。视对象给用户一个到TR的高级接口，该接口在下面将要进一步描述。存储在事务处理记录中的每个数据对象利用称为TAG的名称或密钥被从语义上识别。TAG在示例性的实施例中是一个16比特字的整数，该TAG已经为一个特定数据对象而保留。通过利用诸如事务处理记录的动态存储，各个数据对象利用标记进行存储，从而可能支持一种非常灵活的输出机制。换句话说，将非常容易地，在不影响电信系统的一般操作的情况下，按照用户对于后面分析的需求，在任何特定的时间周期提取任何选择的数据对象。其结果是，将非常容易地增加附加的业务到按照这样一种构成方式操作的系统中。
假设，该代理接收了协议ACP的参数“主叫方号码”。该数据将被变换为一个AXE内部表示和与专用标记“App Calling Party NumberTag”一起被存储到TR中。需要该主叫方号码的TR的其它用户然后可以借助于TR和请求用TAG“App Calling Party Number Tag”存储的该数据对象。一个接口应用平台标记接口ATI包含多个由各个功能使用的标记。ATI还包含当新的标记被保留时所遵循的规则。
正如已经描述的那样，该TR总是经由一个视对象被访问。该视对象具有两个主要的任务。第一个是提供指向该TR的一个定制的接口。该TR的每个用户应当具有一个与该TR内容的专用接口。第二个任务是起到指向TR的一个处理对象的作用，该处理保证TR在所有的处理被删除之前不会删除TR。
各个视对象还被用于访问存在的其它两种记录类型的内容，即，对话期间记录和话务情况记录的内容。如上所述，视对象的一个任务是在指向一个记录的在高度抽象级上提供该用户一个定制的接口。定制意味着，接口使各用户仅访问需要访问的各个对象，这些对象可能仅是在记录中总的内容的一部分。
指向事务处理记录和话务情况记录的各个视对象的第二个主要任务是它们起到一种句柄的作用。只要一个记录具有一个句柄，则它就不能被删除。当指向一个记录的最后的句柄被删除，则该记录和它的所有内容也被从本地存储器的存贮中删除。显而易见，这产生一种非常方便的本地存储器存贮的管理。
已经描述的呼叫记录输出机制被用于输出后处理的事务处理记录的部分内容。应当注意，对话期间记录和话务情况记录和事务处理记录的内容仅在该特定的对话期间是存在的和当该对话期间结束时将消失。该输出机制是围绕若干包含标记表的被管理的对象建立的。在电信系统的操作中，例如存在采集计费数据的需要，以便能够正确地对不同的用户进行计费。图5是举例说明在一个对话期间中可能发生的情形。一个控制对象“计费”已经打开一个对象Cro_type。这个特定的Cro_type对象包含从数据库提取的一个标记表，表示要从事务处理记录提供的各数据对象。Cro_type然后被排序，编辑由存储在数据库中的标记表识别的各个数据对象组成的报告。然后，该控制对象使用Cro_type接口数据进行排序，在该特定对话存在的期间采集数据。该数据可在一个数据区域中进行打包，然后被发送到后处理节点。因此，计费基础由于增加了业务可能被在任何时间改变，仅通过简单地修改标记表，而不用干扰按照本发明的结构的现存的系统就能够完成。
其有效结果是，即使不同的对话期间的内容被作为本地数据来定义，也有可能同时使用该内容的所需求部分，如同它们构成全局数据。本地和全局数据之间的差别例如是，通常后者要被分配在预定的存储器位置以便能够被其它用户访问。
在所说明的实施例中，我们利用了三种类型的被管对象，实现本说明书所描述的灵活输出机制。它们被表示为CroService Template、CroType和CroCustomer Template。第一被管理对象类型CroService Template被用于规定可能为一种基本或附加业务提取哪些数据对象。CroService Template包含一种标志，可能是TAG，表示可能从事务处理记录TR中提取哪些数据用于一种特定的业务，例如在本文中的“基本呼叫”或“三方呼叫”。
第二个被管理对象类型是CroType，它用于规定某种输出类型。CroType的每种情况都是与一个或多个CroServiceTemplate的情况相联系的。这些CroServiceTemplate的数据的结合确定对于一个具体的CroType来说，可能输出哪些数据。
第三和最后的被管理对象类型是CroCustomerTemplate，它是保持在一个具体的输出类型CroType中，为一个具体用户提取哪个数据的信息的一个被管理对象。
图6表示具有以下条件的一个小例子-有两个用户，A和B；-有两种业务，“基本呼叫”和“三方呼叫”；-有两种CroType，CroType1和CroType2。
由于有两种业务，我们需要两个CroServiceTemplate-CroServiceTemplate基本呼叫，包含标记1、2、5和8。
-CroServiceTemplate三方呼叫，包含标记1、2、6和9。
这意味着，对于“基本呼叫”，我们可以输出存储在TR中具有标记1、2、5和8的数据，而对于“三方呼叫”业务，我们可以输出存储在标记1、2、6和9之下的数据。
然后，我们定义两个输出类型，CroType1表示这样，即它将能够输出涉及两种业务的数据，和CroType2表示这样，即它能够输出涉及基本呼叫的数据。图6直观地表示该基本结构和所产生的被管理对象之间的关系。
每个用户和CroType都要求一个CroCustomer Template，使输出机制“呼叫记录输出”CRO能够对于所有用户执行所有CroType的输出。在这个例子中，这总共导致四个CroCustomer Template。图7表示产生的结构。用户A要求来自CroType1的所有可能的标记和来自CroType2的标记1和2，和用户B要求来自所有CroType的标号低于8的所有标记。然后，我们具有一个最后的结构，它的输出机制CRO需要适当的分配。我们已经规定了来自所有不同CroType的哪些数据段是所有用户需要的。
在图4中的数据流的最后部分描述了什么时候该数据将被发送到另外的半呼叫。各半呼叫借助于电信业务协议TSP进行通信。TSP承载着各个自识别参数。一个参数包含一个数据对象和由一个标记来识别。接收机可以通过查看标记Tag确定哪个数据被接收。被用于在TSP识别一个参数的标记是与被用于识别在TR中存贮的一个数据的标记一样的。
图8综合了在呼叫处理期间的事务处理记录中，呼叫数据采集的一个简单的流程图若干步骤。这样一个处理是在步骤100开始的。在该处理的第一个实际步骤101中，通过一个外部协议接收一个消息。该消息是在该系统内的动态处理中的一个协议代理中接收的。接下来，在步骤102中，数据被从外部表示变换为一种内部表示。在这个动态处理中产生一个数据对象。然后，这个数据对象包含该接收数据的内部表示。
在第三个步骤103中，该数据对象被用一个唯一标记单元存储在事务处理记录中。在呼叫处理期间，利用事务处理记录视对象在第四步骤104从事务处理记录中提取数据，然后利用该标记单元得到正确的指针PTR，检索该规定的数据。
当该呼叫结束或当为了统计或计费目的需要呼叫数据的输出时，在第五步骤105调用该功能调用记录输出。这个功能访问数据库，找出输出哪个数据。结果，该功能得到一个标记单元表。在步骤104中从TR采集所希望的数据和放置到一个输出缓冲器。然后这个缓冲器可以输出到一个外部媒体。该数据可以被后处理，以便用于例如产生计费信息等。
最后，图9通过三个步骤表示将要被包括在一个输出中的数据规范的一个简单的流程图。该程序在步骤200开始。在步骤201中，业务提供者或管理该系统的任何其它操作者判断为不同的呼叫类型输出哪些数据。在第二步骤202通过以输出的标记表填充各样板规定这些不同的输出类型。在最后步骤203中，利用例如借助于一个单独的终端和/或键盘输入各标记表来把这些模板存储在数据库中。这些输入的标记表随后在呼叫过程中被访问。各标记表的输入将不影响电信系统对于启始和终接话务情况、从接入协议到正确话务情况的信息分配、启动新的业务等的正常呼叫处理，但是当输入时，将判断哪些数据将被存储在数据库以便后处理。
本专业的技术人员将理解，在不脱离由所附的权利要求书限定的本发明的精神和范围的情况下，可以对本发明做出各种修改和改变。
权利要求
1.一种在电信系统中构成呼叫处理的方法，最好是通过软件产生标准和通用的结构，该结构能够利用新的业务和数据扩展所述系统，并不影响利用半呼叫原理的系统业已存在的主要操作软件，其特征是，将该半呼叫原理和各个正在执行的半呼叫之间的通用协议相组合且包括由对话作用域和利用存储功能的话务情况作用域组成的对话期间，其中不同的记录存储指向本地存储器功能单元的指针(PTR)，将上述指针和一个标记单元(TAG)进行组合，本地存贮的数据将能被其唯一地标识，以及虽然不是真正的全局数据，但是在特定记录存在的周期的一个特定的对话期间仍然可以被作为全局数据来利用。
2.按照权利要求1的方法，其特征是，该特定的对话作用域利用一个对话记录(SR)存储各个指向呼叫的执行对象的指针和从该记录将有可能找到在该对话期间内的所有其它对象，如果在该标记单元(TAG)下被存储的对象是已知的，所述其它数据对象被存储在对话记录(SR)或话务情况记录的事务处理记录(TR)中。
3.按照权利要求2的方法，其特征是，所述话务情况作用域具有与所述对话期间作用域类似的结构和所述所述话务情况记录参考所述对话期间记录(SR)和所述话务情况记录是为了存储一个呼叫的各执行对象而产生的。
4.按照权利要求2的方法，其特征是，所述事务处理记录(TR)存储属于所述话务情况的各数据对象。
5.按照权利要求1到4任何一个的方法，其特征是，所述标记单元(TAG)是由唯一地分配给每个执行对象或被存储的数据对象的一个整数实现的。
6.一种用于电话的呼叫处理交换系统，使得能够利用新的业务和数据扩展所述系统，而不影响利用半呼叫原理的该系统的已经存在的主操作软件，其特征是，将半呼叫原理和各个正在执行的半呼叫之间的一个通用协议相组合，且包括由对话作用域和利用存储功能的话务情况作用域组成的对话期间，它利用其中不同的记录存储指向本地存储功能单元的指针，上述指针和一个标记单元(TAG)进行组合，借助于它本地存贮的数据将被唯一地识别和虽然不是真正的全局数据，但是在特定记录存在的周期的一个特定的对话期间仍然可以被作为全局数据来利用。
7.按照权利要求6的系统，其特征是，该特定的对话作用域利用对话记录(SR)存储指向该呼叫的执行对象的指针，如果知道对象在其下被存贮的标记单元(TAG)则从该记录将有可能找到在该对话期间内的所有其它对象，从而其它数据对象被存储在对话记录(SR)或话务情况记录的事务处理记录(TR)中。
8.按照权利要求7的系统，其特征是，所述话务情况作用域具有与所述对话期间作用域类似的结构和所述所述话务情况记录是参照所述对话期间记录(SR)的和所述话务情况记录被形成以存储一个呼叫的各执行对象。
9.按照权利要求8的系统，其特征是，所述事务处理记录(TR)存储属于所述话务情况的各数据对象。
10.按照权利要求6到9的系统，其特征在于，所述标记单元是由唯一地分配给每个执行对象或被存贮的数据对象的整数组成的。
全文摘要
本发明描述了一种在电信系统中构成呼叫处理的方法，最好是通过软件产生一个标准和通用结构，该方法有可能利用新的业务和数据扩展所述系统，而不影响利用半呼叫原理的该系统的业已存在的整个操作，通过将这个半呼叫原理和对话期间中的正在执行的半呼叫之间的一个通用协议相组合，该对话期间有一个对话期间作用域和话务情况作用域，它利用其中不同记录存贮指向一个本地存贮器功能的指针功能，其中所述指针和一个标记单元相结合，通过它本地存贮的数据将被唯一地标识，和在一个特定的对话期间持续期，在该周期中存在着一个特定的记录的情况下，在该期间虽然不是真正的全局数据，仍然可以用作全局数据。
文档编号H04M3/42GK1158205SQ9519515
公开日1997年8月27日 申请日期1995年9月12日 优先权日1994年9月19日
发明者M·P·E·基尔黑格 申请人:艾利森电话股份有限公司