CN1369170A - 一种用于通话记录创建及处理的系统和方法 - Google Patents

一种用于通话记录创建及处理的系统和方法 Download PDF

Info

Publication number
CN1369170A
CN1369170A CN00811409A CN00811409A CN1369170A CN 1369170 A CN1369170 A CN 1369170A CN 00811409 A CN00811409 A CN 00811409A CN 00811409 A CN00811409 A CN 00811409A CN 1369170 A CN1369170 A CN 1369170A
Authority
CN
China
Prior art keywords
data
telephone
event
cti
conversation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN00811409A
Other languages
English (en)
Inventor
V·布谢德
D·A·格罗尼
J·E·里希特
P·M·倪
D·A·迪尔蒙德
T·恩古芸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dictaphone Corp
Original Assignee
Dictaphone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/328,294 external-priority patent/US6252946B1/en
Priority claimed from US09/328,298 external-priority patent/US6246752B1/en
Priority claimed from US09/328,295 external-priority patent/US6252947B1/en
Priority claimed from US09/328,299 external-priority patent/US6249570B1/en
Application filed by Dictaphone Corp filed Critical Dictaphone Corp
Publication of CN1369170A publication Critical patent/CN1369170A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42221—Conversation recording systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/36—Statistical metering, e.g. recording occasions when traffic exceeds capacity of trunks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/30—Aspects of automatic or semi-automatic exchanges related to audio recordings in general
    • H04M2203/301—Management of recordings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2218—Call detail recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H04M3/42323—PBX's with CTI arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/5175—Call or contact centers supervision arrangements

Abstract

描述了一种用于监视电话交换环境的系统和方法,并且该系统和方法包括为每个电话通话构建一个通话记录(150)、接收有关电话事件的数据、将接收的电话事件与通话记录相匹配、基于接收的电话事件数据更新匹配的通话记录、以及将更新的通话记录与为该通话的段指示记录的音频数据的位置(140,145)的数据合并,以生成表示电话通话持续时间的主通话记录。除此之外,该系统和方法能够利用主通话记录中描述的每个电话通话的记录器位置组装和播放电话通话段,并且能够利用主通话记录来显示该电话通话的图形表示(160)。

Description

一种用于通话记录创建及处理的系统和方法
                     发明领域
本发明总体上涉及计算机辅助数据记录。更具体而言是涉及语音信号，如电话通话的计算机辅助监视和记录。
                     发明背景
电话呼叫监视系统用于许多场合下，包括应急调度中心和商业呼叫中心。在许多当前可用的通话监视系统中，由一个单一硬件单元监视并记录多个音频输入源(“信道”)，并且音频记录按照输入信道、日期、时间和持续时间进行保存和组织。通过利用局域网(LAN)将几个记录单元组合在一个系统中，可以扩展记录单元的容量以处理更多信道。因为检索只可能采用基本搜索规则(记录单元、信道、日期、时间和持续时间)，所以通常很难定位感兴趣的一个特定音频记录。当需要根据简单语音记录不直接支持的搜索规则来搜索一个记录时，定位一个特定记录需要乏味而且重复的搜索。例如，如果需要找到一个特定客户的通话以解决一个有争议的交易，则可能不知道记录上述原始通话的记录单元和信道，因此搜索者在找到正确的记录之前被迫手工播放许多通话。
随着计算机电话集成(CTI)的到来，现在可以监视一条除了简单语音记录外，还提供关于电话呼叫更多信息的数据链路。在一个典型的CTI系统中，电话交换机或用户交换机(PBX)提供了适合计算机处理的接口，并且在通话出现时通过这个接口可以得到电话呼叫的扩展信息。这一扩展信息中可用的数据域包括主叫方的外部电话号码，以及有助于将与相同通话有关的一系列事件相联系的识别号。随着在语音记录系统中使用这样的数据链路，通过构造一个数据库将前面讨论的基本搜索规则与增强的搜索规则(基于通过CTI数据链路获得的信息)如：通话中涉及各方的电话号码；主叫用户ID(CLID)或自动号码识别(ANI)；拨号识别业务(DNIS)；或客户业务代表的代理ID号码相结合可以补充上述搜索和检索系统。
如图2所示，通过将合适的设备分接入语音通信线路，记录单元可以使用两种方法截获电话呼叫流量。通过接入电线记录呼叫中心内部每个分机上的信道，话务在流经PBX和代理电话机之间时可以被截获和记录。这第一种方法称为“用户端(station-side)”记录180。替代地，通过在PBX和公众电话交换网(PSTN)之间的中继链路上接入设备，通话由PBX发送之前流量在进入呼叫中心的点可被截获。这第二种方法称为“中继端(trunk-side)”记录170。因为商业公司通常代理电话比中继线多，“中继端”解决方案可能需要更少的记录设备并且因此更便宜。考虑的另外重要一点是“中继端”仅提供对外部呼入或呼出电话，也就是典型地涉及商业公司客户的电话的访问，而“用户端”还提供代理之间内部通话的访问(这可能涉及或不涉及外部客户的交易)。
关于向计算机提供通话信息的数据链路，典型地从可用的PBX有两种链路分类。一些较旧的链路采用如SMDR(用户端消息详细记录)或CDR(通话详单)提供面向行的文本格式的电话呼叫汇总信息。两个首字母简略词指基本上相同类型的系统。从这些链路来的信息通常在通话结束后提供，这对于计费应用或业务量分析软件是合适的。许多较新的链路使用设计为在PBX中电话呼叫仍有效期间提供一系列事件的实时接口，使得计算机和多媒体系统能够响应并与外部主叫用户交互。这种实时链路提供的信息典型地比SMDR提供的信息详细得多。
当建立想要在电话呼叫出现时对其作出反应并动态选择哪些通话应该记录或丢弃的记录系统时，CTI链路的详细信息和实时特性尤其重要。当建立想要捕获电话呼叫的所有历史，包括记录会话中涉及哪些不同代理以及通话如何保持、转接或开会的记录系统时，CTI支持的信息也很重要。同样，在想要支持(a)有效通话的实况显示以及(b)用户听或监视一个实况音频流量需要的容量的系统中实时信息很重要。
因为电话随处理话务量的需要动态分配到中继，所以基于语音记录的“中继端”解决方案单独不能以实用的方式满足上述需要。一个特定电话承载在哪个中继信道上事先是无法预测的。没有将逻辑电话通话与来自一条中继信道的音频物理记录相关联的信息，用户在找到感兴趣的记录之前必须搜索和检索许多记录。而且，在设计为使用数据链路提供的增强搜索规则的系统中，没有关于通话发生的中继信道信息不可能编程地将搜索数据与语音记录相关联。
只要数据链路提供关于每个通话使用的中继信道的足够信息，这个问题就可以避免。不幸地是，一些PBX环境没有提供关于实时CTI链路提供的数据中的中继信道这一关键信息。例如，在北美广泛使用的朗讯科技的DEFINITY G3 PBX，就出现了这个问题。尽管朗讯G3 PBX通过其SMDR链路提供中继信道信息，但该信息直到通话结束后才能得到。这对于依靠实时数据的系统特性和功能存在一个问题。朗讯G3PBX提供的实时数据链路没有提供关于中继信道的必要信息。因此需要一种系统能够同时监视SMDR链路和实时CTI链路，搜集来自两个数据源的通话信息，并且将上述信息组合在呼叫中心内的一个单一电话活动数据模型中。还需要一种系统将数据模型与电话记录的位置信息合并，形成包括使每个通话与其包含的段相匹配的数据的“主通话记录”，并且将每段数据与该段记录的位置相匹配。这样的系统将便于监视、记录和播放完整的电话呼叫。
                      发明概述
本发明面向一种能够为每个电话呼叫建立通话记录的系统和方法；接收关于电话事件的数据；将接收的电话事件与电话记录相匹配；基于接收的电话事件数据更新匹配电话记录；以及将更新的通话记录与指示通话段的记录的音频数据位置的数据合并，以生成表示电话呼叫持续时间的主通话记录。在另一个实施方案中上述系统和方法能够对于每个电话呼叫利用主通话记录中描述的记录器位置装配和播放电话呼叫段，并且利用上述主通话记录显示所述电话的图形表示。
上述主题发明的一个优选实施方案还面向一种用于播放存储在一个或多个位置并由一个或多个播放服务器管理的数据段的系统和方法。在这个优选实施方案中，该系统和方法接收描述将播放数据段的数据，向播放服务器发送准备播放的通知，然后将播放请求发送到播放服务器。优选地，接收的数据包括描述每个数据段持续时间的数据，系统则利用数据段持续时间数据确定何时向播放服务器发送播放请求并且安排请求时间以便在数据段播放时最小化段之间的间隙。除此之外，可提供显示播放段状态的图形显示。
上述主题发明的一个优选实施方案还面向一种系统和方法，能够同时监视两个或更多数据链路，从这些数据链路收集有关通话信息，将该信息组合在呼叫中心的电话活动单一数据模型中，并且将该数据模型与通话记录位置相关信息组合，形成包括使每个通话与其包含的段相匹配的数据的“主通话记录”，并且将每段数据与该段记录的位置相匹配。
上述主题发明还面向一种系统和方法，能够同时监视两个或更多数据链路，从这些数据链路收集有关通话信息，将该信息组合在呼叫中心的电话活动单一数据模型中。在一个实施方案中，本发明是一种记录电话呼叫信息的方法，包括电接收来自第一个源的关于与一个或多个电话呼叫相关电话事件的数据；电接收来自第二个源的关于与一个或多个电话呼叫相关电话事件的数据；以及当来自第一和第二个源的事件数据与相同电话呼叫相关时，将来自第一个源的事件数据与来自第二个源的事件数据组合成单一通话记录。在上述方法的另一个实施方案中，第一个源是一条CTI链路而第二个源是一条SMDR链路。在另一个实施方案中上述方法包括采用一个信用因数将进入事件数据与已有通话记录相匹配。
在另一个实施方案中本发明是一个用于处理电话呼叫信息的计算机可执行程序，包括用于从多个源接收电话事件相关数据的一个或多个数据采集线程；用于将通过数据采集线程接收的事件数据合并到通话记录的一个或多个数据标准化线程；以及用于将来自一个或多个数据标准化线程的数据转换成目标平台特定格式，并且将转换的数据发送到该目标平台的一个或多个消息发射器线程。在上述程序的另一个实施方案中，第一个源是CTI链路而第二个源是SMDR链路。在另一个实施方案中上述程序使用信用因数算法将进入事件数据与已有通话记录相匹配。
在另一个实施方案中，本发明是一件制造商品，包括存储用于处理电话呼叫信息的计算机程序的计算机可读介质，包括一个或多个从多个源采集电话事件相关数据的数据采集线程；用于将通过数据采集线程接收的事件数据合并到通话记录的一个或多个数据标准化线程；以及用于将来自一个或多个数据标准化线程的数据转换成目标平台特定格式，并且将转换的数据发送到该目标平台的一个或多个消息发射器线程。
在另一个实施方案中，本发明是一个控制用于处理电话呼叫信息的软件组件的计算机程序，包括用于从第一个源接收与一个或多个电话呼叫相关的电话事件数据的计算机软件；用于从第二个源接收与一个或多个电话呼叫相关的电话事件数据的计算机软件；以及用于当来自第一和第二个源的事件数据与相同电话呼叫相关时，将来自第一个源的事件数据与来自第二个源的事件数据组合成单一通话记录的计算机软件。在另一个实施方案中，本发明是一个存储控制用于处理电话呼叫信息的软件组件的计算机程序的制造商品，包括用于从第一个源接收与一个或多个电话呼叫相关的电话事件数据的计算机软件；用于从第二个源接收与一个或多个电话呼叫相关的电话事件数据的计算机软件；以及用于当来自所述第一和第二个源的事件数据与相同电话呼叫相关时，将来自所述第一个源的事件数据与来自所述第二个源的事件数据组合成单一通话记录的计算机软件。
                       附图简述
图1是本发明的一个优选实施方案中的系统框图。
图2说明了中继端和用户端记录的区别。
图3显示了说明一个复杂通话中涉及的不同方的线图。
图4显示了用于对从SMDR链路和Dialogic CT-Connect CTI业务接收的信号进行转换、汇总和标准化的一个优选实施方案的图解框图。
图5说明了转换模块CtiCtc.exe集成从CTI和SMDR链路接收的数据的步骤。
图6说明了CTI服务器如何被看做一组逻辑清晰的层来处理CTI事件的转换和分发。
图7说明了除了电话事件，CTI服务器710如何负责为系统控制器130提供关于代理事件的某些元数据。
图8显示了CTI服务器的布局。
图9显示了CtiCtc.exe被配置与朗讯电话业务接口一起工作的一个版本(因此称为CtiLts.exe，而不是CtiCtc.exe)。
图10描绘了一个优选实施方案中使用的数据模型的关键元件。
图11说明了一个优选实施方案中CTI服务器的三个不同层。
图12以框图形式显示了一个优选实施方案中实现三个不同处理(数据采集、数据标准化、以及消息发送)层的CTI服务器的几个线程。
图13说明了优选实施方案的分析器层的程序逻辑流。
图14描绘了本发明的一个优选实施方案中记录系统内的信息流。
图15显示了仅与语音信令一起操作以指导通话记录创建的记录单元如何生成多个分裂的音频段。
图16显示了优选实施方案中的图形用户界面。
图16A显示了本发明的一个特定实施方案中一个包含CTI服务器和记录器的系统。
图16B是一个说明来自特定实施方案中使用的CTI服务器的描述信息的表。
图17说明了特定实施方案中用于创建主通话记录的步骤。
图18显示了根据本发明包括CRG模块的处理线程和数据结构。
图19说明了特定实施方案中使用的通话记录生成器的类表。
图20、20A、20B、21、22、22A、22B和22C说明了流控制管理器的操作。
                  优选实施方案详述
本发明面向一种通信记录系统和方法。通常，本系统的功能涉及通过在电话的中继端或用户端截获音频来分接(tap)PBX(用户交换机)中的活动。然后分接的音频重定向为基于数字信号处理(DSP)的语音处理板上信道的输入，进而又数字化进入程序可寻址的缓存。然后记录的数字化音频与通过PBX的计算机电话集成(CTI)通信链路获得的描述信息(“元数据”)相结合，并且作为单一可管理单元(“语音数据”)存储以便于后续的搜索和检索。该系统在硬件和软件上都使用模块化结构，因此任何一个组件可在不影响系统其他部分的情况下被替换或升级。
在一个优选实施方案中，通信记录系统包括多个采用多任务操作系统(如Microsoft Windows NT)的可机架安装的计算机处理服务器(如Compag ProLiant 1600R)、DSP语音处理板(如DialogicD/160SC)，以及Dictaphone公司的一组分布式软件组件。在面向最小配置的一个特定实施方案中，所有这些组件都驻留在一个计算机处理服务器上。在其他优选实施方案中，相关组件典型地包装在一起并且整个系统跨越在局域网(LAN)中协调处理的多个服务器。
在这个优选实施方案中，整个系统通常包括CTI服务器、语音服务器、中央数据库服务器和用户工作站。CTI服务器通常使用一组组件来管理与电话交换环境的数据通信链路，以便在通话发生时获得通知，以及关于通话的描述信息(例如，源和目的电话号码)。语音服务器使用一组组件收集音频记录，管理其存储，以及便于在LAN中进行播放。中央数据库服务器使用一组组件管理系统范围内记录通话的搜索和检索。用户工作站典型地是桌面计算机，利用一组组件使用户提交搜索和检索播放记录的请求以及自动控制记录系统中调度功能的请求。
图1显示了一个优选实施方案中本发明的系统组件的框图。数据从多种源进入记录系统。这些源包括PBX100、CTI中间件105、ISDN线110、或其他输入源115。因此可以理解，本发明的系统可用于监视和记录关于任何类型电子通信的信息。为简单起见，下面的讨论采用术语电话呼叫。但是，除非明确指明其他方面，否则该术语覆盖任何电子通信。
从数据源100、105、110或115来的数据发送到一个或多个CTI转换模块165，该模块将输入数据转换为一个通用格式。然后该数据发送到CTI消息发送程序120，由其将数据向前分发到系统中合适的组件。
音频记录器145可用于调度静态集设备上被动中继端170和分机端180记录，以及根据调度规则通过电话交换环境提供的业务遵守特性185动态启动特定设备的记录。记录存储在音频存储设备140中。通话记录生成器150将来自音频记录器145的数据与CTI消息发送程序120发送的数据相匹配，以便为每个电话创建一个主通话记录(MCR)。MCR存储在语音数据存储模块155中。一个或多个用户工作站160使用MCR重建和播放存储在音频存储设备140中的全部或部分电话对话。调度和控制业务模块130控制音频记录器145并且与用户工作站160进行通信。调度和控制业务模块根据依赖时间业务115和CTI信息提供的时间数据的调度规则，负责启动和停止音频记录活动。因为系统组件打包在典型配置中，所以CTI转换模块165和CTI消息发送程序120共同驻留在称为CTI服务器710的计算机处理服务器上。在类似的形式下，组合组件包括时间业务125、调度和控制业务130、音频记录器145、音频存储140、以及通话记录生成器150，在一个特定实施方案中可以共同驻留在一个称为语音服务器124的计算机处理服务器中。语音数据存储155驻留在称为中央数据库服务器的计算机处理服务器中。用户工作站160的专用应用软件驻留在桌面计算机上，该计算机在一个优选实施方案中采用MicrosoftWindows 95、Windows 98或Windows NT操作系统。
如上所述，在特定实施方案中CTI服务器包括两个主要模块：CTI转换模块(如软件程序CtiCtc.exe、CtiLts.exe、以及其他转换模块)和CTI消息发送程序模块(如下面讨论的软件程序CtiServ.exe及其等价程序)。在一个特定实施方案中，CTI服务器可以有几个转换模块，例如，每个PBX接口一个，或每个供货商API层一个。如图1所示，优选实施方案的CTI服务器接受来自PBX或电话交换环境中类似设备的数据，并且可以利用所有实时CTI通信链路和异步信息源如用户端消息详细记录(SMDR)接口。CTI服务器转换各种类型的输入数据并合并成一种统一标准格式。然后标准化格式的信息通过消息发送程序根据需要发送到系统的各个组件。
如上所述，特定实施方案中的语音服务器具有几个模块，包括音频记录器145和通话记录生成器(CRG)150。音频记录器收集多个音频段，这些音频段表示电话通话的各部分，其中声级超过了可调整误差门限，因此识别讲话和无声的交替时期。功能上，通话记录生成器(CRG)生成主通话记录，其压缩了描述电话通话的信息(元数据)。这一描述信息来自多个源，包括但是不限于音频记录器和CTI服务器。利用面向参与者的通话记录模块生成通话记录。CRG则试图将通话记录与现有的已记录音频数据相匹配。因此CRG能够将按不同年代顺序到达的数据组合成描述电话通话完整历史的单一可管理实体。
在特定实施方案中，播放服务器(PBServer)(未示出)是音频记录器模块中的一个子组件，其利用通话记录检索和播放电话通话。每个记录器有自己的PBServer，该PBServer连接到用户工作站160上的播放器模块(未示出)。播放器模块通常包括一个流控制管理程序模块，使播放器模块能够使用PBServer播放有几个不同参与方并且因此通话的各部分存储在不同记录器上的电话通话。
CTI SERVER仍参见图1，当通话进入PBX系统时，PBX生成SMDR和实时CTI数据，并通过SMDR和CTI链路提供给记录系统。根据本发明，这两种类型的数据由CTI服务器集成为一种通用格式。
如本领域所知道的，CTI(计算机电话集成)以几种重要方式对记录的音频数据进行补充。通过来自位于客户端的特定电话交换设备的数据通信链路提供CTI数据。提供的数据包括如涉及的通话方的电话号码、主叫用户ID/ANI信息、DNIS信息、以及代理ID号等项。ANI是自动号码识别，一种识别主叫方电话号码的信令方法；该方法典型地在大规模商业呼叫中心使用。DNIS是拨打号码识别业务，一种识别原始“拔打数字”的特性，在大规模商业呼叫中心当多个电话号码路由到相同的接收中继组时通常采用这种特性。根据本发明，CTI服务器执行对来自实时(CTI)和SMDR(异步)链路的数据进行分析和重新组织，并将结果向前传送给记录系统进行进一步处理的任务。
优选实施方案的系统设计预想将有许多CTI转换模块165以适应各种可能的输入源如“本地(native)”PBX接口、CTI“中间件”供应商、ISDN数据信道接口等。系统设计以这样的方式合并了灵活性，即收集CTI信息，使系统准备好与客户端可能已经存在的CTI链路集成。优选实施方案的CTI服务器能够同时监视SMDR链路和实时CTI链路，收集来自两个源的通话信息，并且将信息合并到呼叫中心的电话活动的单一数据模型中。
CTI服务器负责将电话事件有关的某些元数据提供给语音服务器的通话记录生成器150。这个元数据，如被叫方和主叫方号码、中继和信道ID、日期和时间、代理ID等通过通话记录生成器与其他元数据，以及音频记录器145自己提供的数据组合在一起。利用这个信息，系统中其他组件能够利用大量各种有用并且有意义的规则，而不是简单地利用记录器信道、日期和时间来搜索通话。如本领域的技术人员所熟知的，“事件”简单地是计算机程序检查到的一个行为或发生的事。通话记录生成器150将该数据合并到一个单一通话记录中，在通话期间每次事件之后更新该记录，因此在通话结束时，该通话的全部历史就包含在上述通话记录中。CRG将上述通话记录与音频记录器生成的记录段相匹配。CRG将上述通话记录与该电话相关记录的元数据合并以生成一条主通话记录。当操作员想要听一条记录的电话通话时，他使用用户工作站(优选地配备有图形用户界面)检索并播放该记录通话。因为电话可能有几个不同的参与方，所以电话的各部分可能记录在不同记录器上，每一个与不同的播放服务器相关。系统仍能够按正确的顺序播放整个电话通话。
在一个优选实施方案中，CTI服务器从各种电话交换环境，包括PBX、ACD和台式小交换机系统中获取关于电话事件的信息，这些环境可能有大量不同的专有CTI接口。电话交换环境是在具体目的地之间在静态或动态基础上提供通话发送的本地电话系统；该系统能够识别何时通话发生以及谁在通话中。CTI服务器将接收到的信息转换为作为从不同供货商的PBX、ACD和台式小交换机系统获得的信息类型的简化子集的通用“标准”格式。如Dialogic的CT-Connect API产品部分地实现这种数据转换，其能够处理来自主要供货商交换机的CTI消息，如朗讯DEFINITY G3、北电Meridian和DMS-100、Aspect，Rolm 9751、Rockwell Spectrum和Galaxy、西门子Hicom、和Intecom。但是，根据优选实施方案，在CTI服务器中存在额外的软件层以进一步过滤和标准化CTI信息。这一特性也允许与连接其他交换机供货商，尤其是Dialogic的CT-Connect(CTC)产品不支持的某些台式小交换机系统所必须的定制软件接口的单点集成。转换模块的替代实施方案采用Windows NT或Genesys T-Server的朗讯CentreVu计算机电话服务器代替Dialogic的CT-Connect作为中间件。额外的替代实施方案包括到特定电话交换机，如Aspect的直接“本地”接口，而没有中间的中间件产品。
在CTI服务器和各种PBX、ACD和台式小交换机系统之间交换的CTI消息方面，根据一个优选实施方案，CTI服务器是“被动收听者”。也就是，CTI服务器将监视和接收关于通话活动的信息，但是不发送影响、控制和重定向通话的消息。在具体实施方案中也考虑采用“主动”CTI服务器。
虽然语音服务器的焦点是记录内容(例如音频片)，但是CTI服务器生成的元数据重点在描述关于通话中各方包含的起点和终点的事实。换句话说，在优选实施方案的系统中，记录是以通话为中心(而不是事件为中心)的形式管理的。这与典型的主叫用户的观点相对应，其中即使通话涉及转移到其他代理或多方会议，通话也是与商业机构的整个通话。CTI服务器为复杂通话的不同记录段的起点和终点生成带有元数据的事件。这些事件记录通过ID号和原因代码(参见图3)相互关联，因此一个复杂通话的整个事件序列可以通过浏览器应用程序重新构建，并最好在用户工作站160上实现。
根据优选实施方案，在主题系统的系统中根据处理多个PBX、ACD和台式小交换机系统生成的CTI信息的业务量负载的需要可以有一个或多个CTI服务器。在特定实施方案中，可以根据业务量负载和物理连接性需要配置一个CTI服务器与几个PBX、ACD和台式小交换机系统相连接。在替代实施方案中，不同CTI服务器可以连接到不同输入源上。通常，系统中CTI服务器的数量与语音服务器的数量没有直接关系。由CTI服务器生成的电话事件基于整个系统(由中央数据库服务器管理)的配置数据单独过滤并重新发送到合适的语音服务器，其将记录位置(分机号码、或中继和信道ID)与语音服务器名称和记录输入端口(信道)相匹配。
在通话的有效持续时间期间，实时信息在跟踪通话中每个参与方的历史通话记录中积累。每个参与方记录包括电话号码、代理ID号、时间范围、以及加入和离开通话的原因代码的描述域。在数据积累的一些关键点无论何时一方加入或离开通话，通话记录都向前发送以便记录系统的其他部分处理至此为止积累的信息。根据通话的结论，CTI服务器在将通话记录从存储器中丢弃之前以一个可配置的时间间隔保留一份通话记录的拷贝。这一延迟意味着允许SMDR数据的到达。
CTI服务器一接收到SMDR数据，就在其存储器搜索与从前面实时消息积累的相同逻辑电话相关的通话记录。因为SMDR链路和实时CTI链路不共享一个通用参照ID号用于描述电话发生的消息，因此匹配这个信息不是一个微不足道的任务。
因此优选实施方案的软件必须通过在SMDR和实时CTI数据之间共同存在的其他数据域的组合上进行比较，使用其他“线索”来指导匹配过程。这些数据域包括：(1)通话涉及的第一个外方的电话号码；(2)通话涉及的第一个内部一方的电话号码；(3)通话的方向(例如打入、打出)；(4)以小时和分钟计算的通话开始时间；以及(5)以秒计算的通话时长。
再一次，因为SMDR链路只以小时和分钟给出通话的开始时间，而实时链路给出的开始时间还包括秒，因此匹配过程不是微不足道的。在一分钟之内很可能不只一个电话通话开始和停止。如果不与其他搜索域结合将导致多义的匹配。对于在其上执行匹配的每个其他域相同的论点也是真实的。没有一个域单独就能提供记录的非二义性匹配。甚至在组合情况下，很明显也可能发生二义性(虽然统计上不太可能)：如果在一分钟内相同的两方通话对方两次，并且每个电话大概相同的秒数时长。如果大量的通话通过一个公共进入点发送到呼叫中心，如果通话涉及的第一个内部方是共享语音响应单元(VRU)或自动通话发送(ACD)队列就会是这种情况，则这个问题发生的可能性就会增加。除此之外，如果受到PSTN或入中继配置的限制外部方的号码信息丢失了，则匹配电话记录更会成为问题。
增加到这些困难上的事实是SMDR链路和实时CTI链路报告的时钟值彼此不可能很好地互相同步。因此，优选实施方案包括一种可以容忍时间不完全匹配的机制，而在匹配通话记录中仍然保持可接受程度的可靠性。
因为这些各种因素需要匹配算法有一定程度的灵活性，所以优选实施方案结合了在潜在匹配候选者中应用的一个加权公式。该公式产生一个数学表示的信用因数，可用于选择最明显的匹配候选者。对于每个“线索”，执行一个测试以确定该数据域上的匹配质量。这一匹配质量被评为一个百分比。某些域，如时间值在一个可配置的误差范围内可以变化，而其他域则要求完全匹配或完全不匹配。域的匹配质量确定之后，与重要因数相乘，其为匹配期间可以检查的不同域的每一个使用一个相对加权。最终的信用因数是这些计算的和：
信用因数＝∑i((匹配质量)i*(加权因数)i)
为了考虑各个呼叫中心之间通话业务量的特点可能显著不同的事实，容忍因数(如时间值偏差)和加权因数可重新配置。信用因数也有一个可重新配置的最低限，在其下的匹配候选者总是被丢弃。
对于如时间或时长这样的域，可以允许一个不精确的匹配，配置数据将规定一个允许偏差范围(正或负的一定秒数)。不完全匹配但是落在偏差范围内的值通过用1减去和要求值的差别与最大偏差的比率的百分数来表示匹配的质量。
匹配质量＝1-(abs(要求值-实际值)/最大偏差)
在偏差范围之外的值认为匹配质量为零。这生成了一个线性比例匹配质量。替代实施方案可以采用其它分布(如标准偏差“贝尔曲线”)来生成匹配质量的非线性比例。对于要求完全匹配的域，匹配质量要么是100％，要么是0。
示例  实时CTI事件报告有一个电话从未知的外部方(丢失或故意取消ANI/CLID信息)打到分机1234的内部方，12：25：03开始并且持续17秒(CLID是主叫线识别，一种识别主叫方电话号码的信令方法；该方法典型地用于住宅用户和小企业)。可能与此通话匹配的两个SMDR记录到达。第一个记录指出分机1234在12：26接收打入电话并持续26秒。第二个记录指出分机1234在12：27接收打入电话并持续20秒。系统配置为开始时间偏差为正负3秒，而时长偏差为正负10秒。
加权因数为：
20  外方电话号码
40  内部电话号码
30  方向
20  开始时间
20  时长
因此信用因数计算如下：
CF1＝(20*1.00)＝(40*1.00)+(30*1.00)+(20*(1-1/3))+(20*(1-9/10))
   ＝105 1/3
CF2＝(20*1.00)+(40*1.00)+(30*1.00)+(20*(1-2/3))+(20*(1-3/10))
   ＝110 2/3
因此系统将CTI事件与第二个SMDR记录相匹配。
选择了匹配之后，从SMDR数据中提取中继信道信息(以及任何能够补充前面收集的实时CTI数据的其他有用信息)并且增加到电话活动的CTI服务器的数据模型中的通话记录中。然后更新后的通话记录向前发送以便记录系统中的其余部分对其进行处理。利用手头的中继信道信息，记录系统能够将增强的逻辑搜索信息与物理语音记录相结合，并且依赖这一信息采取任何可能的操作，如选择记录或丢弃通话。
图2说明了带有代理的呼叫中心中继端和用户端记录之间的区别。通过将合适的设备分接入语音通信链路，记录单元可以利用两种方法中的任何一种截取电话业务量。通过接入电线在呼叫中心的每个分机上记录信道180，在流量通过PBX100和代理电话机230之间时截获并记录。这第一种方法称为“用户端”记录。替代地，通过在PBX和公共电话交换网(PSTN)250之间的中继线上接入设备170，流量在由PBX发送之前在呼叫中心的进入点处可以截获。这第二种方法称为“中继端”记录。因为商业公司的代理电话机通常比中继线多，所以“中继端”解决方案可能需要更少的记录设备因此也更便宜。需要考虑的另一个重要点是“中继端”仅提供对外部呼入或呼出电话，也就是典型地涉及商业公司客户的电话的访问，而“用户端”还提供代理之间内部通话的访问(这可能涉及或不涉及外部客户的交易)。
第三种类型的记录接口是业务遵守185(参见图1)，其物理连线与用户端记录方式相同，但是对于记录输入信道采用单独的专线而不是放置在PBX和电话机之间。在这种操作模式下，记录器利用PBX业务遵守特性(最初用于使管理者根据要求直接监视雇员的电话)作为不发言的会议参加者加入电话通话。折衷方式给定输入信道上被记录的内部一方可根据要求变化，而不是由连线模式固定，在这方面与通常用户端记录不同。
图3显示了说明一个复杂通话中涉及各方的线图。A是客户电话号码，而B和C是分别位于记录信道R20和R21之后的代理电话号码(参见图2)。
开始时，通话从线A335进入线B340。出现一条实时CTI消息描述电话B振铃但是还没有接听。B在时间t0 310接听电话365。360处的“NS”指示电话正常开始。出现一条实时CTI消息描述A和B之间的通话开始。更新电话模型以反映最初两个参与方(A和B)之间在时间t0 310正常开始通话的事实。然后通话记录的拷贝向前发送到记录系统的其他部分。通话记录保留在与设备(或线)B相关的电话模型中。在时间t1 315，B将电话通话保持在370(370处的“XA”指示电话从B转走；375处的“XR”指示转接电话由HOLD接收)。出现一条实时CTI消息描述B将电话保持。更新电话模型以反映B在时间t1 315将电话转移到HOLD345。(这个信息与前面在t0 310收集的信息积累在一起)。然后通话记录的拷贝向前发送到记录系统的其他部分。通话记录在电话模型中从设备B删除，但是保留在保持电话通话列表中。
在时间t2 320，B回到电话通话380并且与C355进行会议电话(380处的“XA”指示电话从HOLD转出；382处的“XR”指示B接收了上述转移；384处的“CA”指示C作为会议参与方加入)。出现一条实时CTI消息描述B回到电话并且邀请C加入会议。通话记录从保持电话列表移回电话模型中的设备B。更新电话模型以反映HOLD345在t2 320将电话转回B。(注意该信息与前面在t0 310和t1 315收集的信息积累在一起)。然后通话记录的拷贝向前发送到记录系统的其他部分。更新电话模型以反映C在t2作为会议参加者加入通话384。(该信息继续与前面收集的信息积累在一起)。然后通话记录的拷贝向前发送到记录系统的其他部分。通话记录保持在电话模型内的设备B和设备C。
在时间t3 325，出现一条实时CTI消息描述C从通话中离开386(386处的“CD”指示C从会议中离开)。更新电话模型以反映C在t3离开会议。(该信息继续与前面收集的信息积累在一起)。然后通话记录的拷贝向前发送到记录系统的其他部分。通话记录从电话模型内的设备C中删除，但是保留在设备B中。
在时间t4 330，A结束对B的电话。出现一条实时CTI消息描述A结束通话(390处的“ND”指示发生通话的正常停止；395处的“OPH”指示另一方挂机)。更新电话模型以反映A正常停止并且B因另一方在t4挂机而停止。(该信息继续与前面收集的信息积累在一起)。然后通话记录的拷贝向前发送到记录系统的其他部分。通话记录从设备B中删除，但是保留在完成通话列表中。接收到一条SMDR消息将通话整体汇总。搜索完成通话列表找到一个匹配的，然后检索到合适的通话记录。通话记录根据来自SMDR消息的中继信道信息进行更新。然后通话记录的拷贝向前发送到记录系统的其他部分。通话记录从完成通话列表中删除。
图4显示了用于对从SMDR链路和Dialogic CT-Connect CTI业务接收的信号进行转换、汇总和标准化的一个优选实施方案的示意框图。在图4所示的实施方案中，主题系统的记录系统由Dictaphone公司的新一代记录系统daVinciTM表示。替代地(或同时)，Dictaphone的SymphonyTM CTI软件可以与Dictaphone的ProLogTM记录系统(在daVinciTM之前的系统)一起使用。在下文中，图4说明的优选实施方案的转换/汇总模块将被称作CtiCtc.exe。
模块CtiCtc.exe本身包括多个模块，如图4所示。CtiAgentEvent模块448包括代理注册和注销消息的数据结构。CtiAgentStatusFile模块454管理一个跟踪当前已注册代理的文件。CtiCallEvent模块416包括通话记录的数据结构(也就是标准化和汇总后的CTI事件)。CtiCallState模块418包括表示一个特定位置(分机、保持区域等)处的电话活动状态的一般数据结构。CtiComMessageEmitter模块476包括将CtiCallEvent对象(由CtiCtcAnalyzer456生成)流转换成可以发送到其他da Vinci系统组件的格式的一个层。CtiCtcAnalyzer模块456包括一个检验CTC和SMDR消息并跟踪每个分机活动的状态机的处理引擎。CtiCtcAnalyzer模块执行CTC和SMDR数据的标准化。
CtiCtcAnalyzerUtils模块452包括一个辅助检验CTC和SMDR消息的应用子程序集合。CtiCtcCallState模块420包括表示一个特定位置(分机、保持区域等)处的电话活动状态的包括CTC具体信息的数据结构。CtiCtcCallStateList模块432管理一个CtiCtcCallState对象的可扩充集合。这个对象集合典型地用于跟踪“保持”或“受干扰”电话。CtiCtcData模块428包括一个环绕原始CTC数据，外加一个指示消息到达时间的时间戳的数据结构。CtiCtcDataFile模块412管理一个可以捕获或显示的CtiCtcData对象文件。CtiCtcExtensionInfo模块442管理一个CtiCtcCallState对象集，每个分机一个对象。
CtiCtcInput模块464包括一个从“实况”服务器或“播放”服务器获得输入CtiCtcData对象的输入源引擎。CtiCtcMain模块包括CtiCtc.exe的main()函数。该main()函数处理命令行和注册参数，以及其他启动处理。CtiCtcParameters模块472包括用于管理Windows NT注册表中配置参数的数据结构和程序逻辑。CtiCtcScanner模块446包括一个用于建立特定电话交换机中所有可用分机列表的应用模块。CtiCtcStats模块434包括一个用于在CTC、SMDR和CTI消息数量上编译统计数字的数据结构。CtiDtpField模块(未示出)由CtiDtpMessageEmitter模块478使用，并且包括录音电话机电话协议(“DTP”)中单个域的数据结构，用于与其他Symphony CTI系统组件通信。CtiDtpMessage模块(未示出)由CtiDtpMessageEmitter模块478使用，并且包括一个用于将DTP中完整消息向前发送到Symphony CTI系统的数据结构。
CtiDtpMessageEmitter模块478包括将CtiCallEvent对象(由CtiCtcAnalyzer456生成)的流转换成一种能够发送到Symphony CTI记录平台的格式的一个层。CtiDtpSocketSrv模块(未示出)管理TCP/IP连接，通过该连接DTP消息发送到Symphony CTI平台。CtiDtpUtility模块(未示出)包括一个辅助检验和处理DTP消息的应用子程序集合。CtiExtensionFile模块450管理列出所有可用电话分机的配置文件。CtiExtensionInfo模块440管理一个CtiCallState对象集，每个分机一个对象。CtiExtensionNumber模块430包括一个单个分机号码作为数字或字符串值的抽象，因此改变这个模块不会在CtiCtc.exe中造成全局影响。
CtiMessageEmitter模块458包括将CtiCallEvent对象(由CtiCtcAnalyzer456生成)的流转换成一种能够发送到包括da Vinci和Symphony CTI系统的各种目标平台的格式的一个抽象层。CtiMessageEmitterParameters模块474包括用于管理仅与消息发送器相关的配置参数的一种数据结构和程序逻辑。CtiMessageQueue模块462包括用于在线程之间发送数据的共享内存。正如本领域技术人员所知道的，“线程”是可以独立与程序其他部分执行的程序的一部分。CtiNulMessageEmitter模块460包括接受CtiCallEvent对象(由CtiCtcAnalyzer456生成)的流并且将其丢弃而不是发送到目标平台的一个层。典型地，仅当调试CtiCtc.exe或从PBX中捕获一个CTI事件采样文件而不将其发送到da Vinci和Symphony CTI系统时才用到这一层。CtiPartyListElement模块414包括CtiCallEvent数据结构416的子构件。模块414跟踪关于通话中单个参与者(如主叫方、接收方)的信息。
CtiPeriodicMsg模块468包括用于发送基于定时器的内务处理消息的一般处理程序。CtiPrint模块444包括管理控制台输出和条件跟踪消息的一个层。CtiSmdrData模块424包括一个环绕原始SMDR数据，外加一个指示消息到达时间的时间戳的数据结构。CtiSmdrDataFile模块408管理一个可以捕获或重新播放的CtiSmdrData对象文件。CtiSmdrDataList模块422管理一个CtiSmdrData对象的可扩充集合。这典型地用于缓存与CTC记录不成对的SMDR记录。CtiSmdrInput模块466包括一个从“实况”或播放文件中获取输入CtiSmdrData对象的输入源引擎。
CtiTagNames模块436包括一个将数字值转换为用于调试和跟踪目的的描述字符串的应用模块。CtiTime模块438包括一个将时间值转换为UTC以便内部存储并且有条件地以UTC或本地时区打印时间的应用模块。CtiTrunkMap模块426包括一种描述逻辑中继和逻辑中继群与物理中继和TDM时隙之间映射的数据结构。CtiTrunkMapFile模块410管理一个包含CtiTrunkMap信息的配置文件。
图5说明了转换模块CtiCtc.exe集成从CTI和SMDR链路接收的数据的步骤。开始时，在步骤502，转换模块从SMDR链路或CTI链路接收到一条消息。如果在步骤504，确定该消息是一条CTI消息，则在步骤506就更新电话活动的当前数据模型。如果在步骤514转换模块确定上述CTI消息指示一方加入或离开通话，则在继续步骤512之前在步骤518上述通话记录向前发送到记录系统的其余部分。否则，没有消息向前发送到记录系统的其余部分并且处理直接在步骤512继续。如果在步骤512转换模块确定上述CTI消息指示通话结束，则在步骤520模块从相关设备中删除上述通话记录。然后转换模块在步骤528将上述通话记录增加到最近完成通话列表中。完成通话在变得足够旧之后(也就是在调度数量的记录通话之后，或通话初始记录一段给定时间之后)被丢弃(步骤530)。然后处理再次从步骤502处继续接收下一个到来的消息。如果在步骤512该通话还没有结束，则完成通话在变得足够旧之后被丢弃(步骤530)。然后处理从步骤502处再次继续接收下一个到来的消息。
如果在步骤504处消息是一个SMDR消息，则在步骤508转换模块检索最近完成的通话列表。在步骤510转换模块利用下面的公式为最近完成的通话计算信用因数：
信用因数＝∑i((匹配质量)i*(加权因数)i)
如果找到匹配(步骤516)，并且找到不止一个匹配(步骤522)，则采用信用因数最高的匹配(步骤526)。如果仅找到一个匹配，就使用该匹配(步骤524)。在步骤540，提取中继信道信息，并且在步骤544最近完成通话列表中的通话记录更新。在步骤548该通话记录发送到记录系统的其他部分。在步骤550通话记录从最近完成通话列表中丢弃。完成的通话在变得太旧后被丢弃(步骤530)。如果在步骤516没有找到匹配，则完成的通话在变得太旧后被丢弃(步骤530)。然后处理从步骤502再次继续接收下一条到来的消息。
如图6所示，CTI服务器可以看作处理转换和分发CTI事件的一组逻辑区分层。从图的下部开始，CTI事件从PBX以其专有的格式流入Dialogic CT-Connect中间件640，另一个API层650或客户接口层660每个提供数据的部分标准化。因为API比单独的PBX类型少，因此有助于降低“转换”工作的复杂性。但是因为主题系统的一个目的是保持灵活性以便与各种第三方CTI供货商(如Dialogic、Genesys等)集成，所以在API或客户接口层之上有另外一层670来完成“转换”工作。通过这个“标准化”层的最终结果是所有的CTI事件采用单一、通用、综合的数据格式。
CTI事件一旦转换成标准格式，CTI服务器就可以进行它的另一个分发(发送)消息的任务。分发层680检查每个消息以确定接收每个消息需要什么样的其他记录系统组件，然后将事件的拷贝发送到合适的目的地。
优选实施方案中采用的这种职责分离简化了实现主题系统需要的编程。转换模块不必知道其他记录系统组件的任何事情，其可以关注于处理一个单一具体PBX或供货商API层。同样，分发模块不需要知道具体PBX或供货商API层的任何事情，其可以关注于制定路由决定以及与记录系统的其他部分通信。
图7说明了除了电话事件，根据本发明采用的CTI服务器710是如何负责向系统控制器提供关于代理事件的具体元数据的，这是图1所示调度与控制业务130的一部分。这个信息，通常包括代理ID、分机号码、注册和注销时间等，当从不同PBX、ACD和台式小交换机系统中可用时获得该信息。发送到系统控制器130的代理事件使得能够维护一个分机号码图其中在给定日期和时间可以找到真实的人。这个信息使得即使按照‘自由座席’的计划用户使用不同电话机，浏览器应用程序也可以智能地关联一些以前记录的通话。CTI服务器710还保持一个代理信息的本地高速缓存，以便当发送电话事件到通话记录生成器150时可以包含代理信息。
图8显示了一个具体实施方案中CTI服务器的物理布局，参照图1，转换模块通过单独的程序如CtiCtc.exe 406实现，其封装将具体PBX接口或供货商API层转换为标准化格式的细节。分发模块最好通过包括CTI服务器主处理和发送逻辑的单个程序CtiServ.exe 820实现。
如上所述，CTI服务器的转换模块将专有格式的CTI信息转换为标准格式。根据优选实施方案，这由程序中的几层来完成。首先由Dialogic的CT-Connect软件将信息转换为CTC-API格式，然后由转换模块CtiCtc.exe完成到记录系统中其他组件使用的一般格式的转换。一旦数据转换完成，就采用分布式通信方法如DCOM发送到分发模块(CtiServ.exe)。组件对象模型(COM)是一个规定Windows环境中对象之间交互的微软规范。DCOM(分布式组件对象模型)是COM的网络版，允许连接到网络中不同交换机上的对象交互。CTI服务器的一个替代实施方案利用微软消息队列(MSMQ)技术而不是CtiServ.exe使用的原始DCOM方法，作为在系统组件之间携带消息的手段，本领域的技术人员应当理解，各种附加的数据通信技术也适合这一任务。
CTI服务器的转换模块和分发模块在需要时可以位于不同的机器上。系统中可以有多个转换模块运行—每个PBX或CTI中间件环境一个。也可以有不同类型的转换模块，每个接口或API层一个版本。如图8所示，CtiCtc.exe处理Dialogic CT-Connect API，而且这个程序有三个拷贝在运行以处理PBX。如果使用其他类型的API，则对这些不同接口会有其他程序。所有转换模块将数据以单一、通用、标准的格式向前提供给分发模块。图9显示了配置与朗讯科技业务接口一起工作的CtiCtc.exe版本的一个例子(因此称为CtiLts.exe而不是CtiCtc.exe)。图9中灰色阴影部分显示了该程序两个版本中的通用模块。没有阴影的模块表示该程序在CtiCtc.exe和CtiLts.exe之间因为两个系统使用的不同的输入参数和数据结构而不同的部分。
在参见图8，分发模块(CtiServ.exe)从不同转换模块接收和收集所有CTI事件。然后其将事件放入单一打入队列830由主控制线程835处理。事件处理之后，被分离为单独的打出队列840。最后，事件由各种发送线程850发送到不同语音服务器内的CRG组件。主处理线程850(WinMain)故意与输入和输出绝缘(去耦合)以便保证发送或接收数据的延迟不会影响CTI服务器的整体性能。
图11显示了根据具体实施方案CTI服务器如何由实现三个不同处理层(数据采集1110、数据标准化1120和消息发送1130)的几个线程组成。图12说明这些层的处理步骤。虚线指示线程之间的消息流，而实线指示程序逻辑流。因此CTI转换模块内部划分为3个主要子任务：(1)从输入源(PBX、CTI中间件等)收集数据；(2)将数据标准化为通用格式；(3)与系统平台通信。
在数据采集层，初始步骤1210打开与CTI数据源的连接。在步骤1214该层接收一个CTI事件，并且在步骤1216将该CTI事件记入到消息队列462(参见图4)。如果在步骤1218在进行关机，则在步骤1220关闭到CTI数据源的连接，并且在步骤1222数据采集结束。如果在步骤1218没有在进行关机，则CTI连接保持(步骤1212)。
在步骤1228，数据标准化层从消息队列462中接收一个CTI事件。数据标准化层在步骤1230更新电话模型。更新电话模型的更详细解释参见图13。在步骤1231，在需要时通话状态记入到消息队列。在步骤1232完成通话在超过可配置时限后从存储器中丢弃。在步骤1233当保持或受干扰电话超过可配置时限后调用一个“挂断”例程更新保持或受干扰电话的电话模型。在步骤1234，如果在进行关机，则数据标准化层在步骤1236检查打入消息队列。如果消息队列为空，则数据标准化结束(步骤1238)。如果在步骤1236消息队列不为空或在步骤1234没有在进行关机，则数据标准化层则转到步骤1226并且等待下一个CTI事件到达。
消息发送处理从步骤1240打开到目标平台，如da Vinci或Symphony CTI记录系统的一个连接开始。在步骤1244，消息发送层从消息队列462中接收通话状态。在步骤1246，通话状态数据转换成特定平台格式。在步骤1248，消息发送器将消息发送到目标平台。在步骤1250，如果在进行关机，则在步骤1252进行检查看打入消息队列是否为空。如果打入消息队列为空，则在步骤1254消息发送结束。如果在步骤1252打入消息队列不为空，或在步骤1250没有进行关机，则在步骤1242消息发送层保持与目标平台的连接并且等待下一个通话状态的发送。
主通话记录CTI服务器将“主通话记录”向前发送到记录平台。这些消息提供通话开始和结束时的详细信息，以及影响通话参与方列表的重要变化。参与方列表是累加的，即使列表中有些参与方从通话中退出，关于参与方的信息在整个通话期间仍被保留。如果参与方重新加入通话，则将生成一条新的、单独的条目反映参与方列表中的变化。下表显示了这些消息中包含的域。CtiCallEvent
 名称  类型(最大长度) 描述
 VersionMessageIDRecorderNodeRecorderChannelEventTypeEventReasonCTICallRecId  WORDGUIDWORDWORDBTYEBYTEGUID 该消息格式的版本号，反向兼容。该消息实例的唯一ID识别特定语音服务器的号码识别语音服务器上记录输入信道的号码指示该事件是通话中加入(0x01)和/或离开(0x02)方。指示该通话是否受到正常(1)、会议(2)或转接(3)电话事件影响关于整个通话的唯一ID(CTI服务器为转接、会议等通话提供相同的ID)
CallDirection  BYTE 指示通话起源-打出(0x12)、打入(0x21)、内部(0x11)或未知(0x44)
RingLength  WORD 第一振铃信号和摘机(拿起电话)之间的秒数
DTMFCode  String*(50) 通话期间进入的DTMF代码
ApplicationData  String*(32) 交换机与通话(如帐号号码)一起提供的信息专用字符数组
CallingParty  WORD 参与方列表中主叫方的索引号。通常是零。
CalledParty  WORD 参与方列表中被叫方的索引号。通常是1。
PBXCallRecId  DWORD PBX提供的识别通话的号码
NumberOfParticipants  WORD 下面数组中参与方的计数
ParticipantList  Vector* PartyListElement数组描述通话涉及的所有参与方
*-ObjectSpace数据类型
ObjectSpace是由ObjectSpace公司提供的一组C++类库，其定义有用的通用数据结构包括字符串、时间值的表示以及对象集(如矢量数组或链接列表)。这些类库以支持大量不同计算机操作系统的方式实现。本领域的技术人员应当理解，对这些数据结构有许多替代的实现适用于这一任务。CtiPartyListElement
名称  类型 描述
AgentID  String*(24) 人的注册ID，典型地用于“自由座席”呼叫中心环境
Number  String*(24) 这个参与方的电话号码(如ANI、DNIS、拨号数字)
Console  String*(10) 包括一个或多个用户话机(station)的座席位置
Station  String*(10) 可能有多个分机的唯一电话机
Extension  String*(6) 参与方的内线号码
SwitchId  WORD 处理通话的交换机(PBX、ACD或台式小交换机)号
TrunkID  WORD 处理通话的中继线识别号
VirtChannel  WORD 处理通话的中继信道(时隙)识别
LocationReference  BYTE 描述参与方关于交换机的位置-可以是内部(1)、外部(2)或未知(3)
StartTime  time_and_date* 参与方加入通话的时间
EndTime  time_and_date* 参与方离开通话的时间
ConnectReason  BYTE 参与方如何加入通话：通话正常开始(1)、加入会议(2)或接收转接电话(3)
DisconnectReason  BYTE 参与方如何离开电话：电话通过挂机正常结束(1)、离开会议(2)、转走电话(3)或由另一方挂断电话(4)
Changed  BOOL 指示CTI消息中是否有最近的变化
*-ObjectSpace数据类型
对于外部参与方，只有Number、SwitchName、TrunkID、VirtChannel、LocationReference、StartTime、EndTime、ConnectReason和DisconnectReason域适用。对于内部参与方，所有域都适用。未使用的字符串域以空结束。未使用的数字域设置为零。每个通话事件记录包含列表中至少两个参与方。这两个参与方是初始主叫方(0)和被叫方(1)并且按各自在列表中的顺序出现。
注意：数据域“Number”会依赖参与方的类型和通话方向以不同方式填充。
参与方类型 通话方向 Number域
外部参与方 打入电话 ANI
外部参与方 打出电话 拨打数字
内部参与方 打入电话 DNIS或分机
内部参与方 打出电话 分机
内部参与方 内部通话 拨打数字或分机
当代理在一个特定位置注册/注销时，CTI服务器将“代理事件记录”向前发送到记录平台的系统控制器以传达信息。下表显示这些消息中包含的域。CtiAgentEvent
名称  类型(最大长度) 描述
Version  WORD 消息格式的版本号，用于反向兼容
MessageID  GUID 消息实例的唯一ID
EventType  BYTE 指示该事件属于注册(1)或注销(2)
LocationType  BYTE 指示该事件是否属于本地类型如控制台(1)、用户端(2)或分机(3)
AgentID  String*(24) 人的注册ID，典型地用于“自由坐席”呼叫中心环境
SwitchId  WORD 代理连接的交换机(PBX、ACD、或台式小交换机)数量
Console  String*(10) 由一个或多个用户话机(station)组成的座位位置
Station  String*(10) 可能有多个分机的唯一的电话机
Extension  String*(6) 参与方的内线号码
StartTime  time_and_date* 代理注册时间
EndTime  time_and_date* 代理注销时间
*-ObjectSpace数据类型
在任何给定的“代理事件记录”中，下列三个域只有一个适用：Console、Station或Extension。实际映射由LocationType决定。未使用的字符串域用空结束。未使用的数字域设置为零。
应当理解，上述方法背后的一般原则不仅适用于将实时CTI数据与来自SMDR消息的中继信道信息相关联和合并，而且还可用于由两个或多个源提供混合信息并且需要收集和合并该信息以得到系统中实际发生情况的更完整图象的任何场合。公开的方法很容易由本领域的普通技术人员将其适用于多个信息源之间的映射或关联是“弱”的并且易于产生多义性的场合。虽然本方法不会使潜在的多义性消失，但是当一个匹配好得足以遵照其操作时本方法有助于确定一个定量的规则集以使得一个判断通话接通。虽然人们通常能够直觉地作出这种判断，但计算机需要特定指令集来对输入数据以可重复并且可靠的方式进行操作。
前面利用收集增强搜索信息的记录系统模仿来自PBX的数据链路上提供的面向事件的接口。对于在电话的整个持续时间期间出现的事件，单个数据库记录在1对1基础上构建。事件序列的解释留给用户端用户。因为PBX给出的电话识别号码在电话被转接或进行会议后可能改变，或者号码随着时间过去被循环和重新使用，所以在某些情况下相关事件之间的联系非常困难。从外部客户的观点跟随和跟踪一个完整通话的事件历史需要许多手工和重复的搜索。播放整个一组从该客户与商业公司交互开始，到该客户交易的最终结论的音频记录也需要额外重复的手工请求播放通话中被转接或开会的单独记录段。
为解决这个问题，优选实施方案的CTI服务器在电话活动的一个数据模型中保持和积累信息。图10描述了该数据模型的关键元素。当参与方加入或离开通话时这一统一信息在记录系统的其余部分共享，因此不需要下游组件存储或解释通话持续时间中发生的单独CTI事件。
在通话的活动持续时间中，实时信息在历史通话记录中积累以跟踪通话的每个参与方。在数据积累的某些关键点，无论何时一方加入或离开通话，通话记录向前发送以使得记录系统的其余部分能够处理积累到该点的信息。通话一结束，优选实施方案的CTI服务器就在将通话记录拷贝从存储器中丢弃之前将其保留一个可配置的时间间隔。这个延迟允许SMDR数据的到达。
通话记录被组织为通话和参与方的两层结构。在整个通话全局使用的某些数据域存储在上层。但是大部分数据域仅用于通话涉及的具体一方，则存储在底层。各参与方可以有带有时间戳的识别信息(如分机号码、代理ID、通过DNIS/ANI/CLID的电话号码、中继和信道)和参与及离开电话通话的原因代码。原因代码包括最初开始、转接、保持、恢复、会议加入/离开以及挂机。
被监视的每个电话机的当前活动通话保持在数据模型的存储区域1020。该数据模型还提供可能“保持”(因此不与任何电话机关联)的通话的一个可扩充列表1040。还有一个列表1030可临时用于转接、排队或重新发送期间处于过渡状态的通话，以及一个有效通话与其初始电话机不关联，但是还没有与一个新电话机关联的短暂时间段。最后，有一个最近完成通话列表1050用于等待可能由SMDR消息提供的额外信息。
为监视整个呼叫中心环境中单独一个PBX的每个CTI服务器单独复制上述一组完整的数据结构。
以通话为中心的结构和参与方列表促使对在通话期间可能出现的各种类型复杂通话情景建模的通用框架，远超过基本的两方通话的最简单的例子。而且，记录单元可以为部分通话的音频记录连接参照(也就是逻辑指针)，因此这些音频段与逻辑电话的整个历史相关联。每个通话记录在数据库中可以与一个参照的可扩充列表相链接，该列表提供：语音服务器名称；包含音频记录的.WAV文件的名称；.WAV文件中与记录段开始的偏移；记录段的开始时间；以及记录段的时长。
优选实施方案的CTI服务器获得一个根据软件请求由下面的微软Windows NT操作系统生成的全局唯一识别号(GUID)，而不是专门依赖于PBX分配的通话识别号码，CTI服务器利用GUID在记录系统的存储器、在线存储数据库、以及离线存储档案库中唯一地识别该通话。GUID在通话开始时最初请求。当通话保持有效时，CTI服务器保持一条PBX分配的通话识别号码，以及优选实施方案的软件分配给该通话的GUID的记录。当CTI事件到达时，系统搜索电话模型找到与PBX分配通话识别号码匹配的通话记录。在通话持续时间的过渡点，如当通话被转接或会议时，PBX典型地在该单一转换事件中一起提供旧的和新的识别号码。在这些情况下，在定位匹配的通话记录之后，优选实施方案的软件更新目前PBX使用的该记录的通话识别号码而保留原始分配的GUID值。在这种方式下，在通话的整个持续时间，即使PBX通话标识符改变了，相同的GUID可以识别该通话。GUID值的长期唯一对于如果PBX循环并重新使用以前分配的通话识别号也非常有用。其还有助于在多个PBX环境中处理通话。当另一个PBX碰巧使用相同的通话识别号时，在每个单独通话的开始分配了一个不同的GUID，因此避免了在电话模型中的冲突。
如图11所示，CTI服务器由三个不同层组成。每一层实际上运行单独的执行线程，并且通过共享内存、控制信号灯、以及消息队列与其他层通信。第一层1110负责从PBX数据链路收集输入，实际上可以运行几个线程以提供更好的吞吐量或处理多个不同的输入源(如SMDR和实时CTI消息)。当消息到达时存储完时钟时间后，第一层1110将该消息放到队列中以便由第二层“分析器”进行后续处理。第二层1120负责更新和维护CTI服务器存储器中的电话模型，以及决定何时将通话记录的拷贝向前发送到记录系统的其余部分。当一个通话记录需要向前发送时，该通话记录被放在一个消息队列中由第三层“消息发送器”1130后续处理。第三层负责与整个记录系统的其他组件通信。这种层的分离使CTI服务器具有灵活性以便以去偶合形式处理其输入和输出源，因此一个通信区域的延迟不影响另一个区域的处理。在某种意义上，这种设计方法提供了一个虚拟的“减振器”，因此可以忍受输入业务量的猛增，或者与记录系统其他部分的通信的临时延迟，而没有数据的损失和系统的不正确操作。
在电话模型中保存的通话记录还包括PBX报告的设备的上一个状态记录。分析器运行状态机规则时使用这个信息，以便为随后的消息选择一个处理器例程。CTI服务器利用该设备的前一个状态(如振铃、应答等)及该设备的当前状态从一个潜在的选择矩阵中选择一个处理器例程。
分析器层因为负责更新和维护电话活动的数据模型，因此特别重要。图12显示了其整体程序逻辑流并且在图13更详细地显示了在步骤1230调用的子例程。该程序逻辑描述如下。
1、在步骤1228接收来自消息队列的CTI事件。
2、在步骤1230进入子例程来更新电话模型。现在参见图13，搜索电话活动模型的数据，在步骤1322找到与相同被监视设备(也就是电话机)匹配的一条记录。
3、如果PBX分配的通话识别号码不适合，则在保持、过渡状态或最近完成的通话列表中搜索匹配记录。如果找到匹配记录，则将受影响的设备上的通话记录移到过渡状态的电话列表中，并且将匹配的记录移到被监视设备。
4、在步骤1324，使用前面的状态作为电话模型中的记录，与CTI事件中报告的新状态一起，在步骤1332从选择矩阵中选择合适的处理器例程。处理器例程是下面描述的例程中的一个。
5、在步骤1340，运行该处理器例程的步骤。这通常包括在步骤1342将来自CTI事件的信息保存到通话记录中，在需要时更新对象状态中与通话相关的部分(步骤1344)，在需要时更新对象状态中参与方(步骤1352)，在需要时为其他受影响的电话对象运行额外操作方法或处理器例程(步骤1348)以及将对象状态记入到消息队列中使发送器发送到目标平台(步骤1354)这些步骤。
6、在步骤1360，返回图12，在步骤1232，如果完成通话超过了一定的可重配置时限，就将其从电话活动的数据模型中丢弃。
7、在步骤1233为超过一个单独可重配置时限的任何保持通话调用“挂断”例程。同样，为任何标记为过渡状态的超过另一个单独可重配置时限的通话调用“挂断”例程。
8、从这个逻辑程序流的开始在步骤1226处继续。
下面的描述列出了各种处理器例程的处理步骤，可能响应某些事件类型采用基于过去和当前状态信息的决定矩阵来调用这些例程。
处理器例程
忽略：      基于CTI事件调整状态
拨号音：    保存通话的初始开始时间
            如果可获得，则保存初始拨号号码
            基于CTI事件调整状态
呼入振铃(RingIn)：  基于CTI调整状态
                    当振铃时事件时间戳
                    清除通话记录
                    设置打入、打出、内部
应答：      基于CTI事件调整状态
              计算整个振铃时长
              用主叫方和被叫方填充通话记录
              向记录系统生成START消息异常终止：        基于CTI事件调整状态
              清除定时器与初始拨叫号码挂断：            基于CTI事件调整状态
              更新通话记录以停止所有方
              指示实际上哪一方挂断电话
              向记录系统生成STOP消息呼出振铃：        基于CTI事件调整状态
              当振铃出现时(也就是现在)盖时间戳
              清除通话记录
              设置打入、打出、内部
              计算整个振铃时长(也就是零)
              用主叫方和被叫方填充通话记录
              向记录系统生成START消息保持：            基于CTI事件调整状态
              停止参与方保持电话
              为HOLD加入新的占位符参与方
              向记录系统生成TRANSFER消息
              将通话记录移到保持区
              用新的空通话记录填充设备空位恢复：            如果设备空位没有空闲，则将通话记录移到过渡
              列表
              将匹配的通话记录从保持区移到设备空位
              将状态调整为“有效”
              停止HOLD的占位符参与方
              为恢复通话的电话机加入新的参与方
              向记录系统生成TRANSFER消息会议：            如果在保持区发现通话记录，
                如果设备空位没有空闲，则将通话记录移到过
                渡列表
          将匹配的通话记录从保持区移到设备空位
          将状态调整为“有效”
          停止HOLD的占位符参与方
          为恢复通话的电话机加入新的参与方
          向记录系统生成TRANSFER消息
          基于CTI事件调整状态
          为通过会议增加的电话机加入新的参与方
          向记录系统生成CONFERENCE-ADD消息
转接：    如果在保持区发现通话记录，
            如果设备空位没有空闲，则将通话记录移到过
            渡列表
            将匹配的通话记录从保持区移到设备空位
          基于CTI事件调整状态
          停止离开通话范围的参与方(设备或HOLD)
          加入接收转接的通话的新的参与方
          向记录系统生成TRANSFER消息
离开会议：基于CTI事件调整状态
          停止离开通话范围的参与方
          向记录系统生成CONFERENCE-DROP消息
Op应答：  基于CTI事件调整状态
          重新计算整个振铃时长
          修正通话记录中受影响的参与方条目
          生成CORRECTED消息
改变目标：清除通话记录
          通话将通过后续CTI事件处理
下面的逐步描述说明了与图3相同的通话情景，但是重点在电话活动的数据模型上。
1、出现描述电话B振铃但是还没有接听的实时CTI消息。
2、调用“RingIn”例程。
3、用振铃开始时间(后面用于测量振铃时长)和通话时长更新电话模型。这些事实存储在设备B340中。
4、出现描述A335和B340之间通话开始的实时CTI消息。
5、调用“Answer”例程。
6、更新电话模型以反映在t0 310正常开始的初始两个参与方(A和B)。
7、将通话记录的拷贝向前发送到记录系统的其他部分。
8、与设备B340相关的通话记录保留在电话模型中。
9、出现描述B340将电话保持的实时CTI消息。
10、调用“Hold”例程。
11、更新电话模型以反映B340在t1 315将通话转接到HOLD345。(这个信息与前面t0时收集的信息积累在一起。)
12、将该通话记录的拷贝向前发送到记录系统的其他部分。
13、该通话记录从电话模型中设备B340中删除，但是保存在保持电话列表中。
14、出现描述B350返回通话并且通过开会邀请C355的实时CTI消息。
15、调用“Conference”例程。
16、该通话记录在电话模型中从保持电话列表移回设备B350。
17、更新电话模型以反映HOLD345在t2 320将电话转接回B350。(注意这个信息与前面t0和t1时收集的信息积累在一起。)
18、将该通话记录的拷贝向前发送到记录系统的其他部分。
19、更新电话模型以反映C355在t2 320作为会议参与方加入通话。(这个信息继续与前面收集的信息积累在一起。)
20、将该通话记录的拷贝向前发送到记录系统的其他部分。
21、该通话记录在电话模型中保留在设备B350和C355中。
22、出现描述C355离开通话的实时CTI消息。
23、调用“ConfDrop”例程386。
24、更新电话模型以反映C在t3离开会议。(这个信息继续与前面收集的信息积累在一起。)
25、将该通话记录的拷贝向前发送到记录系统的其他部分。
26、该通话记录在电话模型中从设备C删除，但是保留在设备B中。
27、出现描述A终止通话的实时CTI消息。
28、调用“Hang-Up”例程。
29、更新电话模型以反映在t4 330A正常停止和因为另一方挂断B也停止。(这个信息继续与前面收集的信息积累在一起。)
30、将该通话记录的拷贝向前发送到记录系统的其他部分。
31、该通话记录从设备B350删除，但是保留在完成通话列表中。
32、出现SMDR消息对通话整体汇总。
33、搜索完成通话列表以找到一条匹配记录，并且检索出合适的通话记录。
34、用来自SMDR消息的中继信道信息更新该通话记录。
35、将该通话记录的拷贝向前发送到记录系统的其他部分。
36、从完成通话列表中删除该通话记录。
图14描述了记录系统其余部分中的信息流。CTI服务器为处理通话一部分所涉及的所有记录单元提供相同的增强搜索信息S11412。即使通话转接到连接到不同记录器输入信道的另一个话机上，整个通话仍然保持关联在系统中作为一个实体。每个记录器保留通话期间其获得的音频部分V1 1416、V2 1420和V3 1424的一个本地拷贝，以及一个包含搜索信息S1 1412的完整通话记录，该搜索信息中包含两层通话和参与方模型。该搜索信息与到原始音频记录VR11428、VR2 1432和VR3 1436的参照(也就是逻辑指针)一起拷贝到中央数据库服务器1450中。当用户搜索通话时，搜索结果1465将包括完整通话记录S1 1412。通过利用音频参照，播放软件可以为原始通话重新组装完整的音频，包括可能从不同物理记录单元获得的部分。
上述方法后面的一般原理不仅适用于表示电话持续时间的完整历史，而且适合于其他形式的多方通话。这包括具有提供“交谈组”识别号码(或与音频通信量相关的类似类型的描述搜索数据)相关数据链路的某些形式的射频通信量。
通话记录生成器
根据本发明的通话记录生成器(CRG)执行将语音和数据合并在通话记录中的功能。其实时或接近实时地执行这一功能。CRG与元数据标准化模块CTI服务器组合在一起时，组成了一个可以用于当前和未来通信记录产品的系统。
CRG负责从不同源收集与各种记录输入信道上通话部分相关的数据，并且将其合并到一个统一通话记录中。这些源中的一个是生成包含介质的文件的记录器。另一个源提供描绘通话的何时、何人、为什么以及哪里信息的元数据。这个通话记录元数据包括通话中一个段的开始和终止时间，以及如电话号码和代理ID的CTI数据。这些元数据源包括但是不限于电话交换机和中继射频服务器。CRG依靠CTI服务器标准化来自这些源的数据。
图1说明了CRG和系统其余部分的关系。因为通话记录是记录系统的基本部分，所以每个记录器有一个专用CRG并且物理地位于相同的语音服务器上。如果其他系统组件不能工作，则通话记录生成仍保持能用(虽然在简化的级别)。
CTI服务器将交换机事件提供给合适的记录器，指示通话状态或为总体提供数据。CTI服务器随通话记录数据一起，还提供记录器位置(也就是语音服务器和记录输入信道号码)和交换机连接点之间的关系。交换机连接点描述为分机端记录的分机或中继端记录的中继ID/虚拟信道(TDM时隙)。除了这一映射，还为与当前通话相关的代理提供代理识别。记录器位置、交换机识别和相应的代理存储在通话记录中。CRG设计为与公开系统的许多不同配置一起工作。这些配置包括：没有CTI服务器的系统；带有实时CTI服务器的系统；带有非实时CTI服务器的系统；具有模拟输入的记录器；具有数字输入的记录器；在电话交换机的中继端记录；以及上述CTI服务器、记录器输入以及记录器位置的任意组合。
因为电话交换机的非标准操作以及记录设备的灵活性需求，CRG必须处理按不同年代顺序到达的事件数据。根据一个优选实施方案，其通过要求所有事件都指明发生时间并且保留所有事件的历史来实现这一点。通话记录可以仅从事件源创建但是当都存在时，通话记录可以利用记录器信息和CTI数据一起生成。
很显然为支持整个系统的各种替代配置的需要，利用不同的数据源和不同步消息使CRG增加了相当多的复杂性。例如，随着许多不同对象为一个特定通话提供信息，来自每个对象的消息可以按任意顺序接收。CRG必须能够满足这种需求。在某些配置中，对象为CRG提供冗余信息。CRG提供一种机制用于选择哪个信息将填充该通话记录。
在最基本的操作模式下，CRG没有CTI输入并且仅记录来自记录器控制器的VOX事件(术语“记录器控制器”这里可与“音频记录器”交换使用；两个术语都指主要指导音频数据处理的软件)。VOX是Dialogic公司的用于音频采样的数字编码格式。该术语有时还用于指记录的语音激活启动，一种因为一个连续的记录过程可能包含无声期而保存存储空间的过程。这些VOX事件标志电话线上能量活动的开始并且因缺少活动而终止。利用这种方法，一个实际电话可能包括几个通话记录。为解决这个问题，在终止一个活动的VOX片之前，当出现无声期时记录器等待一个可配置的延期期间(术语“记录器”在这里可与术语“语音服务器”交换使用；两个术语都指物理记录服务器。)目的是在存在无声期空隙的地方拼接电话的各部分。该解决方案在于确定一个合适的延迟时间以避免在下一个电话接近上个电话结束时混合下一个电话的音频。
操作的下一级是记录器硬件在哪儿可以检查出电话信令如摘机或挂起。CRG没有来自交换机的输入并且只记录来自记录器控制器的事件，但是这些事件标志电话的开始和结束(摘机和挂起)。这些作为结果的通话记录整体反映了一个电话但是缺少许多伴随交换机数据的描述数据。
操作的最高级涉及CTI服务器的使用。在这个配置中，CRG既接收记录器事件，也接收CTI事件。因为CTI事件给出CRG整个电话的描述，因此从其中获得的信息驱动通话记录的创建。无论何时音频和CTI时间重叠，描述音频事件的记录器数据被吸收进CTI通话记录中。随着CTI事件驱动通话记录生成，不能再创建基于音频的通话记录。
通过比较指示时间范围出现记录器和CTI数据的混合。例如，一个分机被记录的人在一个给定的时间期间涉及一个电话。指示在相同时间期间在相同分机上记录音频的记录器事件与该电话的CTI元数据相关联。因为来自CTI服务器的数据可能早于或晚于相应的记录器事件到达，所以CRG为每种类型的数据维护一个独立的历史。
对于CTI事件比记录器事件早到达的情况，CTI事件增加到CTI历史列表中。当对应的记录器事件到达时，为匹配时间范围扫描CTI历史列表并且在出现关联时形成关联。对于记录器事件比CTI事件早到达的情况，记录器事件增加到记录器历史列表中。当相应的CTI事件到达时，扫描记录器历史列表以匹配时间范围，并且在出现关联时形成关联。
前面的记录系统在分开的位置存放语音数据和元数据。这种方法的一个主要缺点是由其他软件子系统在需要时合并上述信息。这种方法使得其他系统功能的工作，如播放和向离线存储器归档，变得更复杂并且易于出错。根据本发明通过执行这种音频和CTI数据的“及早绑定”，就避免了这些问题并且因此上述想要的功能变得更简单，以便以正确牢固的形式实现。
当想要播放一个给定通话记录的介质时，播放机制必须找出该通话记录的音频在哪里以及何时确定、检索和定位该介质中的开始时间。CRG将这一介质元数据放在相关表中，因此在播放时可以通知播放机制涉及哪些文件、其位置，以及该文件中的时间范围。
大多数通信系统需要一个归档机制来存储因容量限制而不能在线保持的大量数据。根据本发明使用的CRG通过允许通话记录元数据和介质文件存储在同一个离线介质上来帮助归档。当前版本的记录系统将通话记录元数据和介质文件存储在分离的离线介质上，使得恢复操作更复杂。
在一个优选实施方案中出于增强安全目的，CRG通过使用介质段访问与通话记录相关的介质文件。一个介质段除了包括介质文件名和位置之外，还包括介质文件内的开始时间和期间。当创建基于CTI的通话记录时，因为一个通话记录在整个通话生命期可能涉及许多记录位置，因此介质分段是必要的。特定的时间范围隔离出通过这个通话记录可以访问的介质文件部分。当有许多通话记录位于一个介质文件中时这个功能非常重要。一个想要播放一个通话记录介质，并且对该段介质有访问权限的用户，可能有或没有播放共享同一物理文件的其他通话记录的许可。
通话记录生成器负责将CTI搜索数据和大量语音记录段合并在一个单一可管理数据单元中。这个软件包括一个灵活的接收器算法，可允许语音和搜索数据以任何顺序到达而不需要一个先于一个到达。一旦合并，该通话记录就可以作为单一实体来管理，这大大简化和减少了执行搜索、检索和归档操作所必须的工作。这个方法还为在个人通话基础上(或甚至在通话的选定部分)控制对记录的安全访问提供了更自然和灵活的框架。
如图15所示，一个仅与语音信令一起操作来指导其通话记录创建的记录单元可以形成许多分段音频段。当为记录单元提供给出通话持续时间的完整历史的CTI搜索数据时，并且当其设计为将CTI搜索数据和音频段合并到一个VoicedataTM的合并单元时，其结果可以简化和减少用户从系统中获取想要的通话所必须的工作。几个音频段可以一起组成组，并且可以被系统理解为相同逻辑电话的一部分。因为停止第一个通话和开始第二个通话之间的延迟非常短，因此即使各部分属于单独电话，也可以记录为单一音频段。没有足够的无声期间隔，在语音记录单元看来这是一个连续的音频段，而不是属于两个单独的通话。当CTI搜索数据与音频段合并时，系统可以使用这个信息识别何时音频段应该分开并且在两个逻辑区分的通话之间划分。
通话记录生成器(CRG)的目的是收集描述多媒体数据的信息并且将其存储在中央位置。CRG生成主通话记录(MCR)，其封装描述电话通话以及与之相关的多媒体位置的信息。这个描述数据来自包括但是不限于语音服务器和CTI服务器的多个源。同样，系统的设计预想对于音频记录将会有许多可能的输入源。
无论采用什么装置收集CTI信息，其以常用、标准化的格式与系统的其他部分通信。CTI信息从转换模块传送到消息发送程序。从该点，信息的拷贝为合适的记录器发送到调度和控制业务以及CRG。调度和控制业务根据依赖于时间和CTI信息的调度规则负责启动和停止音频记录器。CRG负责将音频记录合并到CTI信息中以确定通话的时间界限和为存储准备语音数据。
用户工作站典型地从语音数据存储器搜索和检索记录，并且为从每个记录器的私有存储器区域直接播放获得音频。用户工作站也可用于通过直接与记录器通信来监视“实况”通话。用户工作站还可以通过使用调度和控制业务使用的规则间接地控制音频记录器。
在优选实施方案中，用户工作站具有配置为显示如图16所示的图形用户界面(GUI)的软件。图16中的GUI使用主通话记录中编辑的信息来生成该通话的图形表示1610，并显示表1620中文字与数字形式的通话记录信息。而且，当播放该通话时，图形表示中显示的段高亮显示以指示该通话播放的部分。例如，在图16中，如果播放整个通话，则当播放发生在6：20：08AM和6：55：31AM之间的通话部分时，随着该通话播放，条1632、1634和1636从左到右高亮显示。因此当到达该通话出现在6：55：31AM时的部分时，条1634完全高亮显示，而条1632和1636从左边延伸到条1632和1636上正好位于条1634右手端点的上面和下面的那些点高亮显示。当播放的通话记录到达出现在6：55：31AM的部分时，条1638从左边端点开始高亮显示。当到达该通话出现在7：10：22AM的部分时，条1636完全高亮显示。在该点，条1632和1636从其左手端点延伸到正好位于条1638右手端点上方的点高亮显示。只要该通话播放，这个过程就一直继续，直到条1632、1634、1636、1638、1642和1644完全高亮显示为止。
在主题发明的替代实施方案中，可以直接从图形视图通过鼠标点击或从弹出菜单中选择来激活通话一部分的播放；圆形“饼图”显示通话持续时间中涉及的每一方的时间的百分比；当显示其图形的通话在播放时一个动画的垂直线向前滚动指示时间进展；并且在图形中显示一个小图标以指示开始/结束原因，参与方类型等。所有这些实施方案由主通话记录中包含的数据启动。
作为管理复杂性的一种方法，系统的优选实施方案利用数据抽象来对需要在结构上直接操作的组件隔离某些结构的内部细节。由该数据的收集器(或生成器)将信息组织成提要形式，可以由需要对数据进行检索和处理的应用程序更方便地使用。
例如，CTI转换模块以一种通用共享格式向系统的其余部分提供标准化的记录，而不是暴露各种不同CTI链路的细节。系统数据模型是以通话为中心的，包括详细的累积(“一生的”)历史，而不是将工作负担留给接收应用程序的以事件为中心的。同样，代理信息是面向会话的，而不是面向事件的。
是否从CTI链路收集信息，或从电话记录音频，优选实施方案系统的一个基本设计优点是从最终用户看来其操作实际上是不可见的。系统结构设计为避免与呼叫中心环境的正常操作有任何干扰。
例如，CTI转换模块专注于收集和标准化将提供给系统其他部分的信息。利用“业务遵守”技术的负债记录系统和质量监视系统不需要CTI链路上的任何有效通话控制。只有称为“动态信道分配”的技术需要通过CTL链路的有效通话控制以在音频记录器和电话参与方之间建立“会议”或“桥”会话。当需要有效控制来实现这种功能时，可以通过一个新的逻辑分离任务来实现，而不显著影响系统设计的其余部分。对于有已有CTI基础设施和应用程序的客户，该系统不会与他们已有的操作产生干扰。
CRG负责从CTI服务器收集数据，创建基于CTI的通话记录，并且试图将这些记录与已存在记录的音频数据相匹配。如果CRG接收指示相同通话的音频数据存在在两个或更多个记录器(例如，因为转移)上的CTI信息，则为每部分将生成带有一个通用通话记录ID的记录。该ID在后面可用于查询组成完整通话的所有片(“段”)。每个段将识别包含该通话片的记录器。
在播放期间，播放器模块连接到位于称为播放服务器(“PBServer”)的语音服务器上的一个程序。保存有语音段的特定语音服务器的机器名由CRG存储在语音数据存储器的通话记录表中，并且在由称为通话记录浏览器的用户工作站的子组件提取后发送给播放器模块。然后提交通话记录播放请求，这引起PBServer查询一个位于该物理机器上的特定通话记录的音频文件，将文件打开，然后准备将依据缓存请求的音频流回用户工作站上的客户端软件(播放器模块)。如果成功，则从客户端发出一系列请求，每个将获得足够的音频以便向waveOut设备播放，同时保持在网络延迟时有一个安全额外音频。请求一“移入”通话记录的范围，PBServer就将其引导指针重新定位到想要的位置并且开始从该点传递缓存。这一系列请求和移动命令一直继续直到用户通过关闭客户端音频播放器选择结束会话为止。
如这里使用的，术语“通话控制”指与通话记录建立和终止有关的元数据部分。术语“介质”指记录的实际数据。该术语可与音频互换使用，因为CRG的主要设计是支持音频记录。但是，CRG可以应用于包括多媒体或屏幕图象数据的任何记录的数据。术语“元数据”指与描述其内容的多媒体数据相关的信息数据。术语“通话参与方”指通话中涉及的一个实体。一个通话中至少有两个参与方；也就是主叫方和被叫方。参与方可以包括人、VRU、或放置在保持的参与方的占位符。术语“记录器参与方”指MCR参与方列表中的参与方，其在交换机上与连接的记录器输入信道在相同的连接点上。根据本发明，因为在一个通话中参与方可以进入和离开许多次，所以可以有不止一个与通话记录相关的记录器参与方。对于任何给定的记录器信道，在跨越与该信道相关的所有通话记录的任何给定时间只能有一个匹配的记录器参与方有效(没有断开)。“基于VOX的主通话记录”包括没有来自CTI服务器的数据，由仅来自记录器的事件提供的信息。VRU是语音响应单元：一个提示主叫方以获得信息并将其发送给适当处理器的自动系统。
一旦记录器信道涉及一个电话通话，其就将与相同通话相关的所有后续CTI事件相关联。即使该记录器位置已不再涉及该通话也会发生这一点。作为例子，考虑一个涉及转接的电话通话。图16A显示包括CTI服务器710和记录器1640的主题系统。记录器信道0 1650连接到分机端到分机0001 1622。从外部由某个代理“A”1602发起电话通话并且在分机0001 1622初始连接到代理“B”1608。代理“B”1608将“A”1602置为保持并且将其转接到分机0002 1630的代理“C”。记录分机0001 1622的CRG将接收自从他/她参加该通话以来关于这个通话的所有更新消息。来自CTI服务器710的描述信息和图16B中的表1600一样。当代理“B”1608涉及到该通话中时记录的音频片记录在如图17所示的基于VOX的通话记录中。从该通话建立的三个介质文件可能与记录器参与方(代理“B”)重叠。在某些点，由接收记录器和CTI事件的顺序确定，来自VOX通话记录的音频数据信息在记录器参与方涉及时被吸收进CTI MCR中(参见扫描VOX和CTI历史列表后的结果)。对于这个通话记录，时间t1和t4之间记录的音频被吸收。任何剩余的音频留在VOX MCR中以便可能由时间上临近这个的其他CTI MCR吸收。因为在这个通话记录中分机0001与其他参与方不同，在于其与作为记录器信道的相同的交换机点相联系，所以他/她称作记录器参与方。从时间t4往后当记录器参与方不再涉及该通话时，仍为该信道接收CTI事件。这使得系统能够提供客户可能感兴趣的包括分机0001的关于整个电话通话的信息。
因为CRG必须准备好处理来自不同组件的以任何顺序到达的消息，所以其设计为以单独结构收集信息。依靠CRG信道的操作模式，通话记录从一个或多个这样的存储库中收集的信息创建。这些结构的名称是主通话记录(MCR)。
为通话记录提供信息的优选实施方案的主要组件是记录器和CTI服务器。在主题发明的替代实施方案中，其他多媒体或屏幕图象数据可能提供给CRG以便与描述元数据合并。
记录器事件组装进由唯一序列号识别的VOX MCR。单独事件包括一个识别特定结构以便更新(或创建)的序列号。例如，可以使用一个记录器事件来指示一个新音频段的开始。当该段有效时，使用其他包含相同序列号的消息来将元数据增加到该音频段。这些更新事件非限制地包括：DTMF数字数据；代理相关信息；保存未来音频数据的音频文件名的改变；选择记录控制；以及ANI、ALI、DNIS信息。DTMF是双音多频并且指在电话的按键式键盘上按下一个键时发出的声音；ALI是自动位置识别，识别主叫方的物理街道地址的一种信令方法并且典型地用于支持紧急911响应。最后，断开消息识别音频段的结束。
从CTI服务器接收的事件在CTI MCR中累积。从CTI服务器接收的每个事件包括一个唯一识别号。包括相同唯一识别号的事件与相同的CTI MCR相关。如果任何VOX MCR包括与CTI MCR中的记录器参与方在时间上重叠的音频数据，则该音频数据被发送到CTI MCR。如果吸收处理使得VOX MCR的所有音频元数据被消耗掉，则VOX MCR从VOX列表中删除。因此，在相同信道上生成的通话记录将不再有重叠的音频数据。包含没有被CTI MCR吸收的剩余音频的VOX MCR如果有重要期间就保存在中央数据库中，或者丢弃。
单独来自主通话记录的数据处理为位于系统中央数据库中的通话记录。因此，如果该记录器信道仅仅为基于VOX的记录准备好或如果CTI服务器关机，则VOX MCR驱动系统中通话记录的创建。否则，CTI MCR驱动系统中通话记录的创建。
为每个记录输入信道在两个单独列表中维护VOX和CTI MCR结构。这些分别是VOX历史列表和CTI历史列表。这些列表表示按年代顺序排序的通话活动历史。历史列表的深度由一个指示需要维护的历史量的可配置时间参数驱动。通过维护历史，只要事件在历史列表的时间范围内接收，CRG就能容忍以任何顺序接收的事件。一些CTI服务器从在通话结束时以一个汇总消息报告整个电话的SMDR类型的交换机中获取数据。为VOX MCR维护历史缓存使得我们能够保持音频数据一段时间以便后面的CTI汇总消息能够消耗(吸收)相关音频。
MCR有与之相关的指示其当前状态的状态域。在涉及实时CTI事件的安装中，当记录输入信道接收到一个CTI事件时，其指示连接到相同电话交换机位置作为记录器(记录器参与方)的一个参与方在通话中有效。只要记录器参与方在通话中有效就认为MCR有效。在这期间，到达这个信道的任何新的音频都与MCR相关。当记录器参与方离开该通话时，MCR变得不活动。因为任何记录器参与方在转接或会议期间可以在任何给定时间涉及到通话中，所以在该电话过程中MCR可以进出有效状态转换很多次。
MCR中的另一个域指示上述通话的整体状态。这个称为m bComplete的标记指示何时电话结束。只要在通话中有至少一个参与方还有效就认为MCR不完整。当MCR中没有参与方有效时，就认为MCR是完整的。因此，实时生成的通话开始时不完整并且在某个点转变为完整的状态。当MCR进入完整状态，一个关闭的时间变量设置为当前时间。在维护历史列表时使用这个时间。一个关闭的MCR在从历史列表中删除之前可以在历史列表中停留一个可配置的时间。在这个时间窗口中，允许及时顺序之外到达的事件以更新MCR。一旦超过该可配置时间，本地数据库中的MCR被更新，标记为完整的，并且从历史列表中删除。
当CRG启动，其为每个记录输入信道初始化一个识别其连接到电话交换机的位置。每个记录器位置包括描述涉及的交换机和CTI服务器状态的状态域。这些域分别是m_SwitchStatus和m_MetadataServerStatus，并且设置为“关机”状态，直到接收到指示其他状态的事件。当接收到指示状态改变的消息时，所有相关的记录器位置更新为新的状态值。操作中的任何改变都基于接收到该信道的下一个事件来处理。
另一个配置设置指示允许哪些类型的外部源在记录信道创建的通话记录中占有一席之地。当记录信道仅由记录器事件驱动时设置m_ExternMetaDataSource设置为零。当允许外部事件生成MCR时其设置为非零。
CRG能够对可能出现的各种情况作出反应。例如，当CRG第一次初始化并且记录信道被配置为接收CTI输入时，如果CTI服务器没有运行如何生成通话记录呢？如果CTI服务器运行但是到记录器的通信信道关闭时怎么办？CRG必须还能够对系统的外部部分作出反应，其通常依赖于输入，会有段时间临时不可用。根据优选实施方案，CRG通过在不同模式下运行来处理这些情况：初始化、降级和正常。单独为记录器中的每个信道提供这些模式。
初始化模式：当记录器启动时，系统的其他部分变得可操作之前可以有相当长的一段时间。CRG必须准备好处理启动后立即来自记录器的事件。因此，CRG必须准备好在没有来自CTI服务器的支持信息的情况下接收记录器元数据。从这些记录器事件中创建VOX MCR并且存储在VOX历史列表中。当VOX MCR完成后，其将长久位于本地数据存储器中。
CRG系统将保持这种模式直到下面所有的情况发生之后：(1)CTI服务器变得可用；(2)该信道记录的交换机变得可用；以及(3)该信道的可配置选择指示其将由一个在线CTI服务器和交换机驱动。
降级模式：如果记录信道配置为由CTI源驱动，则只有CTI MCR进入数据库。这些CTI MCR吸收任何与CTI事件的时间范围相交叉的记录器元数据。没有永久VOX MCR。但是如果CRG检查到CTI服务器、交换机、或相关通信信道关闭，该信道进入降级模式。这个模式在VOX MCR一旦完成就变得永久方面与初始化模式类似。在CTI服务器停机时处于打开的任何CTI MCR都关闭并且为上次更新。记录器信道将保持这一状态直到“初始化模式”中指示的三个条件得到满足。只有到那时记录器信道才转变为正常模式。
正常模式：在具有CTI服务器和交换机在线的系统的正常操作过程下，无论何时接收到一个VOX或CTI连接事件并存储在合适的列表中时就创建MCR。对于接收的每个VOX消息，扫描CTI历史列表来看看匹配的MCR是否能吸收音频元数据。任何剩余的音频数据放置在VOX MCR中。对于涉及记录器参与方更新的CTI事件，扫描VOX MCR列表来看看音频元数据是否能被吸收。当CTI MCR第一次建立时、依据显著更新事件，以及完成时就变得永久存在于本地数据存储器中。VOX MCR在应该完全被CTI MCR吸收时不会变得永久存在于本地数据存储器中。有一个可配置参数可以使得剩余的VOX MCR从VOX MCR历史列表中删除时变得永久。
从初始化/降级到正常模式的转变：当CRG信道在初始化或降级模式时，VOX MCR完成时被记录在本地数据存储器中。如果接收到通知指示有记录器信道满足“初始化模式”指示的三个标准，该信道就设置正常状态。从这一点开始，只有基于CTI的MCR可以变为永久而VOX MCRs则由VOX事件吸收。因为CTI事件表示一个电话的累积历史，所以在CRG和CTI服务器之间的连接丢失时(或者还没有建立)发生的先前的事件仍然汇总在每个更新消息中。记录器参与方的时间跨度与VOX MCR列表中的音频数据相比较，任何重叠将导致音频数据被吸收。用这种方式，在到外部组件的连接临时不可用期间出现的任何音频数据仍能够被正确地关联。
从正常到初始化/降级模式的转变：当CTI服务器和交换机可以用于驱动通话记录的创建和处理时，CRG信道进入正常模式。利用一个心跳消息周期地更新该交换机和CTI服务器的状态。当该心跳消失或有一个消息指示有一个组件停止时，该记录器信道转换为降级模式。CRG仍将在VOX列表中创建和维护MCR并且在打开CTI MCR离开CTI历史缓存器时迫使打开CTI MCR上的MCR关闭。不完整CTI MCR中的音频元数据的扫描操作将停止，阻止所有将来的音频数据被其吸收。VOX MCR在离开历史缓存时变得在数据库中永久存在。
中继广播模式：在主题发明的一个替代实施方案中，增加了通话记录结构中的域以支持中继广播。提供给这些域的信息可以从与摩托罗拉的SmartZone系统的通信中获得。该系统使用空中交通信息访问(ATIA)协议来传送涉及无线活动的元数据。该实施方案有一个与CTI服务器类似的中继无线服务器，提供SmartZone系统和优选系统的记录器之间的接口。该服务器提供数据标准化和向正确记录器的分发。摩托罗拉的中继无线系统目前有两种操作模式，将在下面讨论。
消息中继：在这种模式下，当打开(key)无线电设备时，就为其分配一个频率用于通信。当关上(de-key)无线电设备时，就启动消息超时定时器(2-6秒)。如果在这段时间打开谈话组中另一个无线电设备，则控制器采用相同的频率来传输和复位该定时器。通话将一直保持在这个频率上直到允许定时器到期。在这段时间，关于该通话报告的所有事件将具有与之相关的相同的通话号码。因此，多方参与的基于CTI的通话记录的概念就应用到消息中继上。
如果允许定时器到期，将为将来的无线传输分配另一个频率和通话号码。服务器需要检查这一事件并且正确地终止通话记录。
传输中继：传输中继中不使用在消息中继中使用的延期定时器机制。当打开一个无线电设备时，为其分配一个特定频率用于传输。当关闭时，该信道频率立即释放由另一个通话组使用。因此，通话可以在许多信道上发生而没有一个将其相关联的通话号码。在这种模式中使用每个MCR包含一个无线片的基于VOX的通话记录的概念。
选择记录：可能有某些电话涉及没有记录的分机或代理。选择记录是一种告诉系统在某个特定条件存在时不再记录通话的功能。
虚拟CRG：MCR可以存在于主题系统的数据库中而没有与之相关的音频。这些非音频MCR可以因主题系统的不同功能而创建。有些客户虽然没有记录所有的分机和中继线也希望保存来自其交换机的所有CTI数据。通过只从CTI数据创建记录，在缺少记录的音频情况下，这种操作模式可以为客户提供用于统计分析或制图表的有用信息。同样，仅基于CTI数据创建的记录可提供一个有用的审计跟踪来验证某些电话的发生，分析业务量模型，或执行其他类型的“数据挖掘”操作。在这种情况下，CRG与CTI服务器机制相结合来接收与特定记录器不匹配的所有CTI事件。这些CTI MCR在通话结束时永久存在于中央数据库中。
通话记录结构：通话记录开始和结束事件源自两个独立的源：记录器和CTI服务器。CRG必须执行一些方法，以这样的方式将来自这两个源的事件合并，即结果的通话记录包含最好的可用信息。CTI服务器事件的优点在于其比记录器提供更多的信息并且还可以准确地确定一个通话记录的边界。基于记录器的事件是CTI服务器事件的一个子集并且只能基于VOX或摘机/挂起来区分通话记录边界。记录器的优点是因为其与CRG在一个箱中，所以只要记录器运行就能确保这些事件的接收。装配过程的主要目的是以整个电话通话组装在一个主通话记录(MCR)中的方式来利用来自CTI服务器的信息。通话记录的构造偏重于中继端，与驱动通话记录创建的CTI服务器的业务一起记录。这种类型的配置使系统能够以最有效的方式汇总电话。下面讨论设计MCR结构以达到此目的的方式。
主通话记录：MCR保存为接收的所有事件积累的信息用于在本地数据存储器中归档。其由对整个通话记录全局可用的单独的域以及特定信息列表组成。全局信息包括该通话记录的识别号、整个通话的开始和结束时间、记录器相对于交换机的位置、以及指示该通话记录状态的标志。
每个MCR包括的列表包含下面的信息：介质文件列表-组成通话的介质文件名的列表(例如，电话或无线通信)；屏幕数据捕获文件列表-与该信道相关的屏幕图象文件列表；以及参与方列表-该通话中涉及的参与方。
MCR由来自CTI服务器和记录器的事件填充。下面的表显示了优选实施方案中的MCR中的域，其数据类型、描述以及其是否存在数据库中。
主通话记录结构
名称  类型(最大长度) 归档 描述
m_CallRecID  String+ 是 关于整个通话(Ctl和中继无线服务器为与相同通话有关的通话方提供相同的ID)的唯一ID(UUID)
m_MetaDataSource  BYTE 是 指示用于填充通话记录信息的源0＝没有1＝CTI2＝中继无线
m_bCallComplete  bool 否 指示通话结束(也就是没有涉及更多的有效参与方)
m_bCall-HoldoverExceeded  bool 否 如果为真，MCR在超过配置通话延期时间的一段时间处于完成状态
m_bMetadataHoldoverExceeded  bool 否 如果为真，MCR在超过配置元数据延期时间的一段时间处于不活动。用于使可能因事件丢失在很长一段事件没有更新的MCR完成
m_bLastUpdate  bool 否 当CRG决定发送该MCR的最后更新时为真。用于禁止任何未来的更新。
m_bDontArchive  bool 否 指示该通话记录是否由数据存储器归档。某些记录特性如选择记录可能禁止存储该记录。
m_CallDirectrion  BYTE 是 指示通话起源打出＝0x12、打入＝0x21、内部＝0x11、未知＝0x44
m_CustomerNumber  String+ 是 可变长度字符数组，用于交换机为通话提供的信息。用于客户通话记录支持(例如，帐号)
m_pRecLoc  RecorderLocation 否 与该信道相关的记录器位置描述符的指针(参见RecorderLocation类)
m_SSFile  List+ 是 表示与通话记录相关的屏幕数据捕获文件名的带时间戳的文件名对象列表(见下文)
m_Participants  List+ 是 描述通话中涉及的所有参与方的通话参与方数组(见下文)
m_XactionSema  HANDLE 否 用于锁定该MCR防止被任何其他线程修改的信号灯
m_SemaTimeoutVal  unsigned long 否 在返回之前被阻止在m_XactionSema访问的最大时间线程
m_bModified  bool 否 无论何时MCR改变将其以需要在本地数据存储器中更新的方式来设置
VOX通话记录(派生)
m_dwVoxCrNum  DWORD 否 与该CTI MCR相关的第一个VOX MCR的序列号(如果可用)
m_bVoxInProgress  bool 否 指示该VOX片仍有效(也就是结束时间是缺省时间)
m_CreationTime  time_and_date+ 否 保存通话记录生成的时间。用于调试以测量通话记录存活多长时间
m_CloseTime  time_and_date+ 否 MCR标志为结束的本地时间。用于确定何时通话记录准备归档。
m_MediaFiles  list 否 表示用于存储与该通话记录有关的数据的多媒体文件的带时间戳的文件名类的列表
m_CtiInfo  CtiInfo 否 包含与通话记录有关的CTI类型数据的类
基本通话记录(派生)
m_wVersion  WORD 否 通话记录的版本号
m_StartTime  time_and_date+ 是 通话记录开始时间
m_EndTime  time_and_date+ 是 通话记录结束时间
记录器位置
m_MetadataServerStatus  BYTE 指示为该特定记录器位置驱动通话记录的元数据服务器的状态。这个源在大多数情况下是CTI服务器，但是也可以是其他服务器如中继无线服务器0＝“关机”，1＝“开机”
m_SwitchStatus  BYTE 指示为该特定记录器位置提供通话记录信息的电话交换机的状态。0＝“关机”，1＝“开机”
m_ExternMetaDataSource  BYTE 指示何种外部源(如果有为该信道提供通话记录元数据的)0＝没有(只有记录器)2＝CTI服务器
m_ChanID  ChannelIdentifier 识别记录器信道的类
m_SwitchID  Switch Identifier 识别交换机连接点的类
m_SwitchChars  SwitchCharacteristics 识别CRG需要的交换机特征的类
交换机识别号
m_SwitchNum  WORD 识别交换机的号码
m_wTrunkID  WORD 连接到交换机的中继线的标识(仅在不等于-1时有效)
m_dwVirtualChannel  DWORD 识别感兴趣的数字线(T1或E1)的时隙(仅在TrunkID不等于-1时有效)
m_Extension  String+(6) 分机号码(仅在m_wTrunkID等于-1时有效)
信道标识符
m_wNode  WORD 用于区分多个语音服务器的唯一号
m_wChannel  WORD 用于区分一个语音服务器中多个记录输入信道的唯一号
m_bSignalSuppoft  bool 指示与该信道相关的硬件是否支持摘机/挂起信令
交换机特征
m_bTimeSynced  bool 指示交换机是否与系统同步
m_bRealtime  bool 指示交换机是实时(真)提供CTI信息还是批处理并周期性发送(假)
m_iCmdTimeOffset  int 指示在交换机接收事件和相同信号在记录器上接收的时间之间的任何已知时间偏移的值。该值将用于在与记录器事件比较前调整CTI生成的时间戳。
m_iSwitchTimeOffset  int 对于与系统时间不同步的交换机，该值指示交换机和系统时间之间的任何已知时间偏移。如果有方法周期性地更新交换机和我们的系统之间的时间差值，可以利用这个值。
CtiInfo
 RingLength  WORD 第一次振铃信号和摘机之间的时间(以秒计)
 DTMFCode  String+(50) 通话期间进入的DTMF代码
时间戳文件名
名称  类型 描述
m_AFStartTime  Time_and_date+ 音频文件开始时间
m_StartTime  Time_and_date+ 兴趣(interest)开始时间
m_EndTime  Time_and_date+ 兴趣结束时间
m_SegStartTime  Time_and_date+ 由该MCR吸收的文件中的段的开始时间
m_SegEndTime  Time_and_date+ 由该MCR吸收的文件中的段的结束时间
m_PathName  string+(36) 描述语音服务器和音频文件存在的目录位置的路径
m_FileName  string+(36) 唯一识别特定音频段的记录文件的基于GUID的名称
m_wFileType  WORD 指示与MCR相关的介质类型的位图。比特  数据0-    音频2-    传真3-    视频3-    屏幕捕获数据
m_wFileFormat  WORD 由微软公司的多媒体描述文件“mmreg.h”定义的介质数据的记录格式。
m_bNew  bool 由本地数据存储器用于指示该记录是否需要插入数据库(真)或在数据库中更新(假)
m_bDiscard  bool 如果为真，则不允许对该介质播放或归档。用于选择记录功能。
m_dwVoxCrNum  DWORD 对应于提供该介质的VOX通话记录的序列号
m_iAssocPart  int 导致该介质文件与MCR相关的参与方列表中的记录器参与方的索引
通话参与方
名称  类型 描述
m_AgentID  string+(24) 在分机(CTI)或无线别名(中继无线)的代理注册ID
m_Number  string+(24) 参与方的完整电话号码(也就是ANI、DNIS)
m_Console  string+(10) 由一个或多个台(CTI)或谈话组ID(中继无线)组成的参与方的座位位置
m_Station  string+(10) 唯一电话机。可能与多个分机相连
m_LocRef  BYTE 描述与交换机相关的参与方的位置(1＝内部，2＝外部，3＝未知)
m_SwitchLoc  SwitchIdentifier 识别参与方相对于电话交换机的位置的类
m_StartTime  Time_and_date+ 参与方加入通话的时间
m_EndTime  Time_and_date+ 参与方离开通话的时间
m_ConnectReason  BYTE 参与方如何加入通话未连接  ＝0，正常开始＝1，会议加入＝2，转接接收(TransferRecv)＝3，未知连接＝9
m_DisconnectReason  BYTE 参与方如何离开通话未断开    ＝0，正常结束  ＝1，会议离开  ＝2，转接走    ＝3，其他方挂断＝4，未知连接  ＝9
Changed  bool 指示CTI消息最近是否改变(未归档)
仅用于中继无线的信息
SourceSiteID  BYTE 当前为有效通话提供音频源的位置号
ZoneID  BYTE 参与方当前所在区域
CIUNumber  BYTE 控制台接口单元。将12kbit转换为清楚音频或相反。
CDLNumber  BYTE 与CIU相关的信道
DIUNumber  BYTE 数字接口单元。将ASTRO清晰安全数据转换为模拟音频或相反
DBLNumber  BYTE 与DIU相关的信道
+-Objectspace数据类型
未使用的字符串域为空。未使用的数字域设置为零。
版本号用于指示通话记录中包含的数据结构。为了保持与将来版本的兼容性，通话记录结构的改变以附加特性执行。也就是，通话记录的当前成员的位置、大小和意义不改变。
每个通话记录将包括一个存储参与方信息的列表。在通话记录中至少有两个参与方；主叫方和被叫方。会议加入或转接的任何附加的连接都附加在该列表的末尾。
在任何给定时间每个记录输入信道只允许一个有效的基于VOX和CTI的主通话记录。
CRG软件结构
图18显示了优选实施方案中包括CRG模块的处理线程和数据结构。
事件处理：当创建并初始化CRG时，生成三个线程。这些线程是CRG事件处理器线程1810、外观(Facade)线程(术语“facade”和“fascade”在本公开内容中可互换使用)1812以及本地数据存储器线程1816。除此之外，产生三个消息队列，分别称为记录器1824、外观1832和数据存储器1844队列。这些队列使各种输入消息可以在CRG中以一种去耦合的形式处理，因此一个通信区域的任何延迟不影响另一个区域的处理。下面描述每个线程。
事件处理器线程：事件处理器是CRG模块中的一个主要线程。其职责包括读取记录器1824和外观1832队列中放入的任何消息。对应这些消息的处理活动导致属于记录输入信道中的一个1856的通话记录被更新。如果这些改变导致一个通话记录完成，则向数据存储器队列1844发送一个消息请求该通话记录永久存放在本地数据库中。该线程还负责处理状态改变消息，导致存储器驻留结构刷新或关闭CRG模块。
外观线程：外观线程处理来自语音服务器外部的消息。其主要功能是寻找CRG的外部Microsoft消息队列(MSMQ)1864中的消息，该队列中事件可能从整个主题系统内的其他组件中到达。一接收到消息，外观线程就读取该消息，将其转换为CRG内部数据结构的合适格式，并且将转换后的拷贝放置在外观队列1832中。该线程称为外观线程，因为其管理CRG与主题系统中其他组件的外部交互。
本地数据存储器线程：本地数据存储器线程1816处理来自CRG事件处理器线程1810的请求。本地数据存储器线程1816的主要目的是获取内部主通话记录(MCR)结构并将其内容转换为与数据库技术，如微软的SQL服务器或类似类型的存储装置一致的结构。这些结果结构存储在数据库中以便使得通话记录永久存在。
有些交换机的特性要求CRG能够非实时地处理CTI事件。有些交换机将事件批处理并周期性地发送出去。利用时间限制历史列表的CRG配置设置必须设置得足够长以适应该交换机的特性。因此，交换机报告(通过记录器事件)之间生成的通话记录直到一个可配置时间段(窗口)之后才结束，该时间之后通话记录才终止。这个窗口(CallHoldoverPeriod)需要设置为交换机报告之间的最小时间周期。一旦通话记录离开该时间窗口，就标志为只读并且提交给本地存储器。
需要处理的一种情况是当电话交换机与系统的其他部分时间不同步。为促使时间不同步系统中记录器和交换机事件的有效合并，将论述主题系统的替代实施方案。
主题系统的一个替代实施方案有一种机制能够周期性地同步系统中的时钟(手工或自动)。这必须保证时间偏移小于某个小的已知量。第二个实施方案有一种测量交换机和主题系统之间时间增量的机制。这个值在合并处理中由CRG周期地更新并使用。第三个实施方案实现前两个的组合。
在通话记录合并处理期间，使用一个全局时间增量来在与已有通话记录数据比较前调整交换机事件时间戳。
下面的几段定义CRG设计接受和处理的事件类型。这些事件可导致CRG初始化、将元数据处理为通话记录，或准备系统关机。
主控制器(本系统调度和控制业务的子组件)提供系统事件。主控制器将系统相关变化如配置改变、CTI服务器状态和系统关机事件通知CRG。CRG根据从主控制器接收到的事件改变其行为。
系统事件：CRG提供一个接口允许客户端应用控制其操作状态。这通过一个主题系统中大多数组件使用的接口类来实现。该接口称为IProcCtrl并且支持下面的方法：Initialize()；Start()；Stop()；Pause()；Resume()；Ping()；以及Shutdown()。
除了这些程序，CRG支持通知其状态改变需要更新其存储器驻留配置信息或改变其操作模式的两个事件消息。这些程序是CtiStatus和AgentExtensionStatus。下面的段落描述每个程序。
初始化事件：该方法是CRG创建之后应该调用的第一个方法。当创建了CRG对象之后，它从主题系统的数据库中提取配置信息。这个信息描述记录器中的信道数，每个信道连接的交换机位置，任何固定联结的电话分机或代理标识符。还包括确定CRG行为的参数。产生线程来处理CRG事件的处理，与外部元数据提供者的通信，以及处理信息到通话记录表中。这些线程以暂停状态生成并且需要启动或重新开始命令来开始处理活动。
启动事件：该方法应该在初始化事件之后调用。其重新开始CRG的所有线程使其能处理进入的事件。
暂停事件：该程序暂停CRG的所有线程。
恢复事件：该方法在暂停命令之后调用来使所有CRG线程继续处理。
Ping事件：该方法由客户端应用程序用来测试到CRG的连接。该程序简单地返回一个肯定确认使客户端知道CRG仍在运行。
关机事件：该方法通知CRG主题系统何时要关机，以便其可以干净地结束自己。停机事件支持指示应该如何关机的单一参数(ShutdownMode)。
如果ShutdownMode确定为“正常”，则从输入事件队列中读取所有未决事件并处理到通话记录中，任何剩余的打开的通话记录在当前时间关闭并写入数据库。
如果ShutdownMode是“立即”，则输入事件队列不处理到通话记录中而直接清除，打开的通话记录闭并写入数据库。
一旦这些操作完成，CRG线程终止。此时，客户端应用程序可以安全地释放CRG的资源。
停止事件：该方法与IprocCtrl的通用接口一致地实现。对于此方法，CRG没什么用途并且仅返回一个肯定的确认。
CtiStatus事件：该事件通知CRG CTI服务器的运行状态，为其提供生成CTI通话记录所需要的电话元数据。主题系统的调度程序组件负责维护CTI服务器的心跳以检查何时失去连接。CTI服务器状态的任何改变导致在CRG处的一个CtiStatus消息。
该消息包括一个指示CTI服务器新状态的参数。如果该参数指示CTI服务器变得可操作，则与CTI服务器相关的记录输入信道就从“降级”操作模式转变为“正常”模式。如果该参数指示CTI服务器不可操作，则与CTI服务器相关的记录输入信道就从“正常”操作模式转变为“降级”模式。
代理分机状态事件：该事件指示一个代理或分机表发生改变。因为CRG使用这些表与记录器信道相关联，因此必须更新存储器驻留版本。因此，该事件导致CRG读取这些表并更新其存储器驻留拷贝。
通话记录事件：当接收到一个通话记录事件时，解释该消息来确定哪个记录输入信道会受到影响。在这个阶段还在每个信道基础上进行任何必要的过滤。然后将通话记录事件发送到合适的通话记录信道管理器。对于语音服务器中的每个记录输入信道，有一个单独的通话记录信道管理器，其是CRG的软件子组件。有三个消息直接促使通话记录的创建和完成。一个以CTI事件形式来自CTI服务器。另外两个源自记录器，是VoxSummary和VoxDisconnect消息。下面详细描述每个消息。
CTI事件：CTI事件是源自CTI服务器软件模块的一条消息，处理从电话交换机接收的信息。该消息详述电话通话中涉及的每个参与方以及该通话的全局信息如振铃时长和DTMF代码。无论何时参与方状态发生改变以及当新的参与方加入通话时就将CTI事件消息发送到CRG。该消息以前面消息的所有信息通过包含的附加部分包括在新消息中的方式累积。这在有一条消息丢失的情况下形成更牢固的系统。
处理CTI事件的伪代码显示如下：
CTI事件伪代码
∥---------CTI EVENT(开始)---------
				
				<dp n="d56"/>
∥如果不在正确的模式下不要处理CTI事件
该记录器信道配置好来接收CTI事件数据了吗？
{∥是

　　该事件是否与我CTI历史列表中的一个MCR匹配？

　　{∥是

　　    用CTI事件中的匹配记录更新MCR参与方

　　    将任何新的参与方加入MCR。

　　    UpdateMediaFiles()(参见伪代码)
}∥结束-该事件是否与我CTI历史列表中的一个MCR匹配？

　　否则

　　{

　　    创建新的MCR

　　    从事件中最旧的参与方开始时间初始化MCR开始时间

　　    将参与方从事件拷贝到给MCR的消息。

　　    ∥现在我们已经更新了参与方，看看是否

　　    ∥我们需要改变介质文件关联。

　　    UpdateMediaFiles()(参见伪代码)

　　    向Cti MCR历史列表中插入新的MCR。

　　}
是否还有任何有效的参与方？

　　标志MCR有效
否则

　　标志MCR完成
}∥结束-该记录器信道配置好来接收CTI事件数据了吗？
∥----------CTI EVENT(结束)---------
∥----------UpdateMediaFiles(开始)--------
对于MCR中的每个记录器参与方
{

　　这不是一个新的记录器参与方？

　　{

　　∥这个参与方的开始和/或结束时间可能已经调整。
				
				<dp n="d57"/>
　　∥看看以前由其吸收的音频是否需要返回到VOX历史列表

　　FindGiveBakcMediaFiles()(参见下面的伪代码)

　　}

　　对于VOX历史列表中时间范围与该记录器参与方重叠的每个MCR

　　{

　　对于该VOX MCR中时间跨度与该记录器参与方重叠的每个介质文件

　　{

　　CheckAndApplyMediaFile()(参见伪代码)

　　}结束-对于该VOX MCR中时间跨度与该记录器参与方重叠的每个

　　介质文件

　　是否消耗了该VOX MCR中的所有音频？

　　将VOX MCR从历史；列表中移走并删除。

　　}结束-对于VOX历史列表中时间范围与该记录器参与方重叠的

　　每个MCR
}结束-对于MCR中的每个记录器参与方
GiveBackAudio()(参见伪代码)
∥---------UpdateMediaFiles(结束)-----------
∥----------FindGiveBackMediaFiles(开始)---------
对于与给定CTI MCR相关的每个介质文件
{
该介质文件是否来自给定的记录器参与方？
{∥是

　　介质文件是否完全位于记录器参与方时间间隔之外？

　　|←---参与方时间间隔---→|

　　                         |←---介质文件时间间隔---→|

　　将整个介质文件移到Giveback列表中

　　否则，介质文件的开始时间是否早于记录器参与方的开始时间？

　　    |←-----参与方时间间隔------→|

　　|←-----介质文件时间间隔-----→|

　　将该介质文件拷贝并将其结束时间设置为参与方开始时间。
				
				<dp n="d58"/>
　　将介质文件加入giveback列表

　　将初始介质文件开始时间设置为记录器参与方的开始时间。

　　否则，介质文件结束时间是否在记录器参与方结束时间之后？

　　|←-----参与方时间间隔------→|

　　                     |←-----介质文件时间间隔------→|

　　将该介质文件拷贝并将其开始时间设置为参与方结束时间。

　　将介质文件加入giveback列表。

　　将初始介质文件结束时间设置为记录器参与方的结束时间。
}
}结束-对于与给定CTI MCR相关的每个介质文件
∥---------------FindGiveBackMediaFiles(结束)------
∥---------------GivebackAudio(开始)---------
∥在VOX MCR中扫描以重新填充任何归还(giveback)音频
对于giveback列表中的所有音频部分
{
是否找到该音频初始来自的VOX MCR？
{∥是试图将归还介质文件与已有的开始时间或结束时间与该归还介
质文件临近的VOX MCR介质文件合并。
否则，将这个介质文件与VOX MCR关联。
}结束-是否找到该音频初始来自的VOX MCR？
否则
{
∥包含该音频文件的原始VOX MCR不再存在。
创建一个新的MCR。
将该归还介质文件与新的MCR关联
将MCR插入VOX历史列表中
}
}结束-对于归还的所有音频部分
∥--------------GivebackAudio(结束)--------
∥---------------CheckAndApplyMediaFile(开始)--------
				
				<dp n="d59"/>
记录器参与方是否跨越整个介质文件？

　　|←------------参与方时间间隔------------→|

　　       |←-----介质文件时间间隔------→|
将介质文件从VOX MCR移到Cit MCR。
否则，记录器参与方是否与介质文件的开始时间重叠？

　　|←------------参与方时间间隔-----------→|

　　                     |←-----介质文件时间间隔-----→|
将该介质文件拷贝并将其结束时间设置为参与方结束时间并且与记
录器参与方MCR相关联。
将初始介质文件的开始时间设置为记录器参与方的结束时间。
否则，记录器参与方是否与介质文件的结束时间重叠？

　　        |←-------参与方时间间隔--------→|

　　|←------介质文件时间间隔---------→|
将该介质文件拷贝并将其开始时间设置为参与方开始时间，并且制作
该介质文件的另一个拷贝并且将其开始时间设置为参与方的结束时
间并与VOX MCR相关联。
将初始介质文件的结束时间设置为记录器参与方的开始时间。
∥-----------CheckAndApplyMediaFile(结束)--------

　　VOX汇总事件：VOX汇总事件是一条来自与该CRG相关的记录器
的消息。其可以两种方式中的一种使用。
该消息的主要用途是实时指示音频活动的开始。当在这种模式下使用时，VOXSummary命令指示音频活动的开始。但是因为活动没有结束，所以设置结束时间来指示VOX段是不完整的。不完整的介质文件的结束时间也用这种方式设置。在这种情况下，需要一个VOX断开消息来完成结束时间。
采用第二种模式来指示音频活动的历史。VOX汇总开始和结束时间反映了所有伴随介质文件覆盖的时间段。该介质文件还填充有各自的开始和结束时间。该消息是完整的因此不需要后续消息。VOXSummary消息显示如下。VOX汇总消息格式
域名 描述
Channel 音频活动的记录器信道
VOXCrNum 用于使相关VOX事件相互关联的序列号
StartTime 音频活动初次开始的时间
EndTime 上一个音频活动结束的时间
Media Files 用于存储该通话记录相关数据的多媒体文件名的列表。(详细内容参见下面)
RingLength 从振铃开始到摘机的时间(以秒为单位)
DtmfCodes 在VOXSummary期间检查到的DTMF代码串
ConnectReason 指示VOX段开始的原因
DisconnectReason 指示VOX段结束的原因
介质文件结构
域名 描述
FileStartTime 对应于文件中音频数据第一个字节的时间
StartTime 对应音频中活动发生的第一个字节的时间
EndTime 对应音频中活动发生的最后一个字节的时间
FileName 包含音频文件名的字符串
PathName 描述音频文件位置的字符串
iAssocPart 由CRG用于指示当音频段是基于CTI的MCR一部分时该音频段与哪个记录器参与方相关联。
dwVOXCrNum 由CRG用于指示该音频段源自VOX历史列表中哪个MCR。 
下面是用于处理一个VOX汇总事件的伪代码。
∥---------------VOXSummary(开始)-----------
该记录器信道是否配置为接收CTI事件数据？
{∥是
∥试图将消息中的介质文件与基于CTI的MCR合并

　　对于历史列表中的每个CTI MCR

　　{

　　是否有任何给定介质文件落入Cti MCR的时间间隔中？

　　{∥是
				
				<dp n="d61"/>
　　∥将介质文件与CTI MCR中覆盖的记录器参与方合并

　　对于VOX汇总消息中的每个给定介质文件

　　{

　　对于给定CTI MCR中的每个记录器参与方

　　    {

　　    CheckAndApplyMediaFile()(参见伪代码)

　　    }结束-对于给定CTI MCR中的每个记录器参与方

　　}结束-对于每个给定的介质文件
  }结束-是否有给定介质文件落入Cti MCR的时间间隔中？
}结束-对于历史列表中的每个CTI MCR
从VOX汇总消息中删除完全消耗的介质文件
}
消息中是否剩余有未吸收的音频？
{∥是
  为剩余音频创建MCR。
  将MCR插入VOX历史列表
}
∥-------------VOXSummary(结束)----------
VOX断开事件：VOX断开事件是一条源自与该CRG相关的记录器的消息。其用于终止已经由实时VOXSummary消息启动的VOX段。
下面为VOX断开消息。VOX断开消息格式
域名 描述
Channel 音频活动的记录器信道
VOXCrNum 用于使相关VOX事件相互关联的序列号
Time VOX段的结束时间。也指打开介质文件的结束时间。
DisconnectReason 指示VOX段终止的原因
下面是用于处理一个VOX断开事件的伪代码。
∥--------------VOXDisconnect(开始)-------------
VOX历史列表中是否有具有相同序列号的MCR？
{∥是
				
				<dp n="d62"/>
  ∥关闭并更新VOX和MCR列表中与该MCR相关的所有介质文件
  在给定的消息时间关闭VOX MCR中的活动介质文件
  UpdateFromMediaFile()
  ∥将吸收音频文件的任何CtiMCR更新为关闭。
  对于CTI历史列表中的每个MCR
  {

　　  ∥试图将音频合并到MCR。

　　  ∥寻找与音频文件名的匹配。

　　  对于由该VOX片提供的Cti MCR中的每个介质文件

　　  {

　　      在给定消息时间关闭介质文件

　　      ∥现在我们已经将其关闭了，该介质文件是否还属于该

　　      CtiMCR？

　　      介质文件仍落入MCR的时间间隔内吗？

　　      {∥是

　　      CheckAndApplyMediaFile()(参见伪代码)

　　      }

　　      否则

　　      {

　　          将介质文件从MCR列表中移出并丢弃

　　      }

　　  }结束-对于由该VOX片提供的Cti MCR中的每个介质文件

　　}

　　关闭VOX MCR并且标记为完成
}
∥----------VOXDisconnect(结束)---------
∥-----------UpdateFromMediaFile(开始)---------
∥寻找与音频文件名匹配的记录
对于由该VOX片提供的MCR中的每个介质文件
{

　　在给定的消息时间关闭介质文件
				
				<dp n="d63"/>
　　∥现在我们已经将其关闭了，该介质文件是否还属于该CtiMCR？

　　      介质文件仍落入MCR的时间间隔内吗？

　　      {∥否

　　      CheckAndApplyMediaFile()(参见伪代码)

　　      }

　　      否则

　　      {

　　          将介质文件从MCR列表中移出并丢弃

　　      }

　　    }结束-对于由该VOX片提供的MCR中的每个介质文件
∥----------UpdateFromMediaFile(结束)----------
数据事件：数据事件附加在当前打开的相关通话记录上。对于CTI数据事件，这是关于当前打开的基于CTI连接事件的MCR并且包括一个匹配的通话记录ID。对于VOX数据事件，影响当前打开的VOX通话记录。如果不存在打开的通话记录，则报告一种错误情况。
校正事件：校正事件存在用于在通话记录已经填充后去除一个以前的替代记录。存在这样一种事件的一个原因是为了支持选择记录。因客户或法律的原因不能记录的音频文件可能需要从通话记录中删除或整个通话记录需要删除。文件名的VOX事件在选择记录机制确定不应被记录之前可能已经处理进入一个通话记录。
选择记录(排除)：选择记录是由客户需求加入的主题系统的一个重要功能。如果客户不希望被记录通话中涉及的某些参与方被记录，则CRG必须排除与涉及该参与方时间的通话记录相关的任何音频。这一功能的实现因客户交换机的不同特性而非常复杂。如果电话交换机环境实时地报告事件，则通过在涉及选择记录参与方时间期间关闭记录输入信道可以禁止介质记录。但是，当交换机不能实时报告事件时会发生什么？答案依赖于前面讨论的记录器参与方的CRG的扫描操作。
CTI事件消息通过调度程序发送，并且由调度程序改变以指示哪个参与方是记录器参与方以及哪些是选择记录参与方。记录器参与方触发CRG扫描来自VOX MCR的时间重叠的任何音频。当CRG检查到记录器参与方和选择记录参与方时间之间的重叠后，就丢弃这个重叠期间扫描到CTI MCR中的音频。这使得从VOX和CTI MCR中都删除该音频，从而禁止该音频可用于播放或归档的任何机会。
选择记录事件：选择记录命令是源自调度程序的一个事件。其识别将不被记录的参与方或是整个通话记录不应该被记录。在一个实施方案中系统能够基于从CTI数据获得的信息处理记录异常。下面讨论选择记录处理的标准。
选择记录功能可以具有两种含义。在一个实例中，客户可能想要记录除符合特定标准之外的所有电话事件。在另一个实例中，客户可能只想记录符合某些标准的通话。
因为选择记录可能从多个源触发，所以在一个优选实施方案中这个决定过程位于作为主题系统的调度和控制业务的一个子组件的主控制器中。
不记录全部或部分通话的暗示原因基于CTI事件数据的下列例子。
事件数据 解释 结果
基于参与方代理ID的代理排除 不包括涉及管理员的通话 在通话期间删除代理的参与方的音频以及MCR中的相关参照
基于分机或完全合格的参与方电话号码的排除 不记录涉及CEO的通话(无论在办公室还是在家) 在通话期间删除代理的参与方的音频以及MCR中的相关参照
参与方代理ID和另一个参与方的完全合格的电话号码的组合 犯人与其律师通话 删除所有音频以及整个通话记录
基于这些情况和建立在主控制器(MC)中的任何将来的规则，排除可以在目标参与方涉入的时间或整个通话记录期间记录的音频上发生。
选择记录(称为排除)的事件链如下：
1、记录器检查音频的存在并且记录到音频缓存中。
2、记录器向CRG发送VOX事件指示音频的存在。
3、CRG基于VOX事件生成新的通话记录。
4、CTI服务器向CRG和MC发送通话事件。
5、CRG将CTI事件数据与基于VOX的通话记录相关联。
6、MC基于上面指示的标准检查选择记录触发器。如果满足一个标准，则向记录器和CRG发送一个选择记录(排除)命令指示选择记录间隔开始。
7、记录器删除选择记录消息中指示的音频并且继续禁止记录直到有其他命令。
8、CRG改变通话记录以清除参与方细节或删除该通话记录。
9、一完成通话，CTI服务器就向CRG和MC发送通话事件。
10、MC基于上面指示的标准检查选择记录触发器。如果满足一个标准，则向记录器和CRG发送一个选择记录(排除)命令指示选择记录间隔结束。
11、记录器恢复其音频记录的正常模式。
选择记录(称为包含)
1、CTI服务器向CRG和MC发送通话事件。CRG生成MCR并且填充事件。因为缺省设置是不记录，所以设置标志m_bDontArchive为禁止本地数据存储器将其写入数据库。
2、MC基于上面暗示的标准检查选择记录触发器。如果满足一个标准，则向记录器和CRG发送一个选择记录(包含)命令指示选择记录间隔开始。CRG将m_bDontArchive设置为假并且立即指示本地数据存储器归档。
3、记录器检查音频的存在并且记录到音频缓存中。
4、记录器在VOXSummary消息中将VOX事件历史发送到CRG。
5、CRG基于VOX事件生成新的通话记录。
6、CRG将CTI事件数据与基于VOX的通话记录相关联。
7、一完成通话，CTI服务器就将通话事件发送到CRG和MC。
8、MC基于上面指示的标准检查选择记录触发器。如果满足一个标准，则向记录器发送一个选择记录(包含)命令指示选择记录间隔结束。
9、记录器恢复其禁止音频记录的正常模式。
记录器的选择记录命令格式显示如下。
名称  类型 描述
StartTime  time_and_date 记录间隔的开始时间
EndTime  time_and_date 记录间隔的结束时间
bRecordAudio  bool 如果为真，在指示的时间间隔记录音频。如果为假，在指示的时间间隔禁止任何音频记录。
因为记录器不知道参与方或通话记录边界，所以MC需要通知记录器何时开始一个选择记录时间间隔以及何时结束。布尔值bRecordAudio表示在这个时间间隔期间应该采取什么行动。
当发生一个事件触发了选择记录时间间隔的开始时，记录器的选择记录命令通知记录器该时间间隔开始。此时很可能不知道结束时间，因此将结束时间设为某个非法值以便指示应该在一个不确定的周期内记录音频直到接收到一个后续命令为止。
当发生一个事件触发了选择记录时间间隔的结束时，记录器的选择记录命令通知记录器该时间间隔结束。结束时间指示该选择记录时间间隔何时结束。记录器返回其基于初始配置的正常记录模式。
已经提交到文件的任何选定音频需要从该文件中删除并且在该时期用一个无声条目代替。
CRG选择记录命令的格式显示如下。
名称 类型 描述
MCR号 UUID 该选择记录命令影响的MCR
参与方索引 UNIT MCR中未记录的参与方索引(如果原因＝1)
原因 BYTE 1＝参与方，2＝整个通话
对于CRG，只需要一个单一事件指示选择记录的是什么。如果原因代码指示将删除整个通话记录，若该通话记录已经写入或在第一个位置没有注册，则CRG将标记该通话记录以便将其从数据库中删除。如果选择记录影响了一个特定参与方，则该通话记录可以无改变的保留(因为记录器已经处理了音频的删除)或可以重写该参与方以去掉他/她的细节。
可以调整系统配置以便CRG以两种方式中的任何一种操作，依赖于仅删除音频对于系统的想要应用是否足够，或是否元数据也必须删除以清除拨打的电话号码记录等。
CRG软件实现
在主题系统的优选实施方案中，上述CRG作为于音频记录器过程相关的一个过程中的COM DLL实现，因此这两个组件一起位于语音服务器上。这里的COM是通用对象模型，由微软公司设计的一种分布式计算结构，以便促使LAN中的软件单元之间的合作处理。DLL是动态链接库，一种方法，由此可执行代码可封装在可通过命令加载并由几个程序共享的一个程序包中，而不是作为一个单独的、孤立的可执行程序打包。音频记录器过程负责生成CRG COM对象以及启动和停止CRG子系统。与CRG接口的数据存储器模块是一个静态链接库。
类设计
图19说明了通话记录生成器的类图。CRG模块本身包括多个模块，如图所示，并且解释如下。
CallRecordEventProcessor-CallRecordEventProcessor类1912是CRG中的主类。其在CRG接口的初始程序调用期间例示。其负责分配剩余的CRG对象。在例示中，其获得记录器的信道数量(当前限制为128)并且为每个记录输入信道例示一组类。这些类包括每个信道的CallRecordChannelManager1916和RecorderLocation1920。CallRecordEventProcessor 1912生成记录器1924和外观1928事件输入队列。从主题系统的数据库中读取和处理配置信息在CallRecordEventProcessor1912中进行。这里还处理接收到的引起配置变化的事件。
CallRecordChannelManager-该类管理特定记录输入信道的通话记录。其负责利用从CRG事件处理器接收的事件信息来创建、填充和关闭通话记录。如果事件信息判断为很重要，则CallRecordChannelManager1916将向DataStoreEventQueue1932发送一个事件以便在本地数据存储器中反映该更新。
MasterCallRecord-该类1936保存整个通话的全局信息。全局信息包括该通话记录的标识符、整个通话的开始和结束时间、相对于交换机的记录器位置、以及指示该通话记录状态的标志。其还包括基于CTI事件提供的信息的通话内的参与方列表。其作为为给定电话合并通话记录信息的控制集中点。
VoxCallRecord-该类1940是MasterCallRecord类1936的超类。其包括处理记录器提供事件的信息。其保存通话的详细信息，如开始/结束时间、介质文件名以及记录器可以提供的其他数据。
RecorderLocation-该类1920保存将电话交换机上一个逻辑设备与特定语音服务器相关的信息以及记录输入信道的信息。
下表指示CRG运行时需要的配置信息。
配置域  类型 接受值  缺省值 描述
sSysTimeCoupling  String “TIGHT”，”LOOSE” “LOOSE” 指示基于时间的记录器和CTI服务器如何比较以确定一个匹配。TIGHT-记录器时间必须完全落入CTI时间以得到正的结果。LOOSE-记录器时间需要与CTI时间重叠以得到正的结果。
nCompleteCallHoldOverPeriod  DWORD  0..4294967296(秒) 90-对于实时CTI。(如果是非实时CTI则更大 历史列表中保存的完整通话记录的最大秒数。该延迟允许来自不同源的事件在变永久之前影响该通话记录。这个延迟期过后，没有事件可以更新该通话记录。
nActiveCallHolderPeriod  DWORD  0..4294967296(秒) 86400(24小时) 通话在被迫关闭之前允许存在的最大秒数。这作为一种防止通常结束通话记录的CTI和记录器事件丢失的安全措施。
nMCRMaxSize  WORD  0..65535条目 100 主通话记录历史列表中的最大条目数
nSystemSkew  WORD  0..65535(秒) 0 确定记录器时钟和PBX时钟之间差异的一个已知、固定差值(秒)。用于在处理到来的CTI事件时间以及与记录器事件时间比较之前对其进行调整。
ynCTIDataFromRecorder  bool  1＝是0＝否 是 在记录器和CTI信息重叠时，识别哪个源优选地填充该通话记录
nSaveVoxClipsLongerThanSeconds  WORD  0..65535  6 该设置用于避免从记录输入信道上的噪声中生成基于VOX的通话记录。其指示CRG丢弃持续时间没有超过特定秒数的VOX片。
流控制管理器  如上说明，在优选实施方案中，本发明的系统通过在电话通话的中继或分机端截取音频分接PBX(用户交换机)上的活动。分接的音频则重定向作为基于DSP(数字信号处理)的语音处理板上信道的输入，进而又数字化并存储在程序可寻址缓存中。然后记录的音频与通过计算机电话集成(CTI)与PBX的通信链路获得的描述信息(“元数据”)相结合并且作为单一可管理单元(“语音数据”)存储以便于其后续的搜索和检索。
优选实施方案利用计算机电话集成来补充记录的音频数据。如上所述，通过从位于客户端的特定电话交换设备的数据链路提供CTI，然后将其输入记录系统的CTI服务器。提供的数据包括的项有涉及方的电话号码、主叫方ID/AND信息、DNIS信息以及代理ID号。CTI服务器执行对来自实时和SMDR(异步)链路的数据进行分析和重新组织的任务，并且将结果向前发送给记录系统的其余部分以进一步处理。
上述的称为“通话记录生成器”或CRG的模块则负责从CTI服务器收集数据，创建“主通话记录”并且试图将这些记录与已有的记录音频数据相匹配。如果CRG接收到CTI信息指示了两个语音服务器上记录的音频数据是相关的(例如，因转接电话)，则为每一部分将生成带有通用通话记录ID的记录。该ID在后面可用于查询组成完整通话的所有片(或“段”)。除此之外，每个段将指示包含通话中该片的语音服务器。
在播放期间，用户工作站播放器模块连接到位于称为播放服务器或PBServer的语音服务器上的程序。应该与之建立通信会话的特定语音服务器的机器名(该机器名由CRG存放在语音数据存储模块的通话记录表中)，在由用户工作站的通话记录浏览器提取之后发送到播放器模块中。然后提交通话记录播放请求，导致PBServer查询位于该物理机器上的特定通话记录的音频文件，将它们打开并且准备将该音频在缓存请求下流回客户端。如果成功，则从客户端发出一系列请求，每个将获得足够的音频在waveOut设备上播放同时保持一个安全的额外音频以备网络延迟。请求一“移动”到通话记录的范围内，PBServer就将其读取指针重新定位到想要的位置然后从该点开始回传缓存。这一系列的请求和移动命令一直继续到用户通过关闭客户端音频播放器来选择结束会话为止。
当通话在位置之间转接时，因为涉及的分机或中继可由不同的记录器监视，所以该通话可能跨越多个语音服务器。如果是这种情况，音频数据就在播放服务器之间展开并且必须正确地重新组合在一起以便为播放客户端重新构建完整通话。
该问题有几种可能的解决方案。首先，可以选择一个中央服务器并且从涉及的服务器中拷贝所有数据。这和在本地将文件拷贝到客户端一样慢，但是其至少将数据整合到一个位置以便播放服务器来操作。但是假设选择该方法，就出现了几个新问题。第一个是驱动器空间的问题：根据通话记录中涉及的转接和记录器的数量，中央播放服务器可能突然停止存储大量文件。这还要与请求播放对话的所有客户端数量相乘。很快，大量无法预见的空间在没有合理方式估计为所有请求服务所必须的空间情况下被分配和释放。类似地，因为即使正常单一记录器播放对话也会通过这台机器发送，所以该服务器上的处理器和存储器负载受到每个播放请求使用的冲击。
另一个解决方案是使中央播放服务器运行某个中间过程象一个“漏斗”一样，将所有数据从多个服务器流回每个客户端。这可以避免拷贝和驱动空间问题，但是仍然有两个问题。第一，该服务器的集中再次将整个负载加在单个机器上。但是更重要的是，如果多个流通过这一个位置灌入，则该服务器由于某种原因需要对流进行组织以便在播放期间其表现为以正确顺序组织好。
根据优选实施方案采用的流控制管理器(SCM)是解决上述第二种解决方案所指问题的结果。关于资源问题，该解决方案只是简单地将“漏斗”模块从一个中央服务器移到客户端。在这种方式下，服务器仍提供实际请求数据，但是将数据集合在一起成为客户端的责任。SCM仍保持一个单独、基于COM的模块因此仍维持封装(客户应用程序不是直接硬布线到SCM代码的)。因为系统替代实施方案中的其他系统模块需要重新使用SCM来收集播放数据(例如对于电话听筒播放支持而不是LAN播放支持)或从大量语音服务器收集音频用于在DAT或DVD介质上长期离线存储，所以这样做是有意的。
当SCM发送包括整个通话的段列表时流管理过程开始。每个段包括语音服务器的机器名、段开始时间、时长、信道ID以及由作为最终组织数据目的地的客户端提供的事件回叫例程。
一旦接收该列表并作为矢量(数组)存储，SCM开始试图连接播放该通话需要的所有服务器。连接如果成功建立，就通过段记录中的一个指针与其各自的段相关联。该连接还加入一个数组中，这样如果后续段的服务器与前一个段相同时，则可以重新使用该连接。如果通话转接到一条由第二个记录器监视的线上并且后来又转接回原先的线时会发生这种情况。如果过程不能成功完成(也就是如果语音服务器有故障)，播放就异常终止以避免跳过任何必须的数据。
接着，SCM检查其段列表，对于每个通过一系列函数调用与其服务器握手。在这个阶段，SCM通知想要段的每个播放服务器通过利用以前传递的参数数据提供其开始时间、时长、信道ID来回流。再一次，如果该过程的任何部分失败，则整个初始化(以及因此的播放)异常终止。这个阶段结束时，每个服务器应该已经加载了整个数据流中与其部分相关的所有音频文件。现在每个都准备好接受音频缓存的请求。
然后SCM等待客户执行“StartStream”调用。在图形界面中，例如当用户点击播放按钮或开始保存操作时将发生这个操作。一旦调用该函数，就产生一个单独的线程来处整个过程。
首先，检查当前播放位置来看看播放哪个段(下面解释的移动操作控制该值的手工重新定位)。这通过在所有段中循环，将每个段的时长增加到整个运行时长中来确定。当增加到总时长中的当前段的时长超过播放位置时，它就是包括当前播放位置的段。
一旦该计算完成，就开始一个循环，从前面确定的段开始经过段矢量的其余部分继续。对于每个段，为调度缓存大小形成请求并且发送到相关服务器。一旦基于一个客户端可配置的标志返回一个缓存，SCM就或者直接将该数据送回或者“在返回之前首先为客户端将数据“切片”。这里，切片指用一个称为块对齐的最小公倍数将缓存划分成更小缓存的过程；这有时对于具有图形组件的客户端非常有用，因为该界面需要反映在更小子部分中播放的量。
当检查到一个段中的所有数据都被请求过时，SCM自动移到下一段(可能位于不同语音服务器上)并且开始代替地从其中请求数据。因为所有语音服务器是预加载数据的并且“准备好执行”，所以这个过程在一秒的很小部分时间发生，并且客户端没有感觉到音频数据返回的任何间隔。实际上，识别段边界的唯一正确方法是监听在电话交换环境中提供的转接的正常、可听指示符(卡嗒声、振铃或听到新的参与方的声音)。
在播放会话结束时(例如用户在与图16描述的GUI一起显示的典型音频播放GUI中点击停止或暂停)为SCM调用StopStream。该线程进而又检查已经进入停止状态，从请求循环代码中退出，并且释放任何使用的资源。最后，其通知客户端停止事件发生。如果播放整个通话记录而没有调用StopStream，SCM执行相同的退出和清除代码，但是通知客户端完成事件。
假定SCM采用上述方法确定将从哪个段开始播放，则在整个流中的移动就是顺向的。一个全局变量保存音频数据至今需要的全部毫秒数。当执行一移动时，告诉在目标位置包含数据的服务器对自己重新定位并且重新设置当前播放位置。现在，一旦StopStream又开始执行，其最初将从刚移动到的服务器开始请求。并且因为该服务器也已经将位置指针前移，所以数据将不会从该段的开始处流出，而是从移动位置落入的段开始。因此移动是对客户端完全透明的一个同步操作，其最终只关心将数据作为一个单一流来处理。
SCM伪代码
1、初始化接收段描述数据(开始时间、时长等)。
    a)形成所有段的矢量。
    b)试图与所有段的服务器连接。
    c)如果在与任何服务器连接时出现错误，则退出。
    d)试图初始化每个已连接服务器。
    e)如果在初始化任何服务器时出现错误，则退出。
2、如果接收到StartStream：
    a)检查段列表。找到当前播放位置的段。
    b)从该段开始，联系相关服务器并且开始请求缓存。
    c)如果设置选项，则将缓存划分为更小的字节片。
    d)通过事件回叫向客户端发送缓存。
    e)重复直到所有数据请求该服务器上该段的。
    f)从步骤b开始对列表中下一段重复。
3、如果接收到停止：
    a)从请求循环中退出。
    b)清除已用资源。
    c)将“停止”事件发送回客户端。
4、如果没有接收到停止，但是所有段的所有数据都播放了：
    a)从请求循环中退出。
    b)清除已用资源。
    c)将“完成”事件发送回客户端。
5、接收到移动：
    a)检查段列表。找到想要播放位置的段。
    b)联系相关服务器并且重定位到该想要的位置。
    c)重新设置当前播放位置变量以反映变化。
图20、20A、20B、21、22、22A、22B和22C提供了描述SCM操作的详细流程图。
图20说明流控制管理器的初始化过程。当用户进入用户工作站播放软件并且在步骤2010按想要标准查询一个已记录通话记录时初始化序列开始。在步骤2012通话记录浏览器显示结果通话记录。在步骤2014该用户选择想要的播放记录。在步骤2016该浏览器调用PbkControlWin对象：一个包含“播放器”ActiveX控件的对话框。
在步骤2020该浏览器将关于包含该通话记录的所有段信息发送给PbkControlWin。如果在步骤2024不要求立即播放，则在步骤2028该条目增加到播放列表中供以后播放，并且在步骤2030返回SUCCESS。如果在步骤2024要求立即播放，则在步骤2032该通话记录ID和段列表发送到GUI播放器模块。在步骤2038(参见图20A)播放器模块例示一个本地SCM(流控制)对象，并且在m_pIStreamControl中存储一个指针。在步骤2040播放器模块接受该数据，显示开始时间和整个时长(通过解析出字符串数据)，并且将其转发到最终模块，流控制管理器(SCM)进行音频播放。
步骤2046开始段矢量的创建。在步骤2046，从segList中解析出段。在步骤2048，从段中解析出来记录器ID、开始时间、时长和信道。在步骤2050，从记录器ID、开始时间、时长和信道中生成一个新的SEGMENT结构。在步骤2052，一个新的SEGMENT被增加到SEGMENT矢量中。在步骤2054，如果从segList中已经解析出所有的段，则在步骤2058从该SEGMENT矢量中得到一个元素。如果在步骤2054还有更多段需要从segList中解析，则重复步骤2046、2048、2050和2052。
在步骤2058之后，该程序确定在步骤2060是否需要到该段记录器的一个新的DCOM连接。如果不需要，则在步骤2062从连接矢量将已有指针拷贝到SEGMENT矢量中的服务器指针中并且该程序进行到步骤2076。如果在步骤2060该连接是新的，则通过CoCreateInstanceEx产生一个到专用记录器的“PlayBackServer”DCOM对象的连接。在步骤2066该程序检查对象例示是否成功。如果不成功，则在步骤2068出现一个日志错误消息并且在步骤2070返回ERROR(C)。如果在步骤2066对象例示成功，则在步骤2072(参见图20B)连接器矢量中加入一个新对象的指针。在步骤2074该程序确定是否所有的段已经连接。如果没有，该程序则返回步骤2058。如果在步骤2074所有段已经连接，则在步骤2076从SEGMENT矢量获得一个元素。在步骤2078该程序在伴随该段的服务器上查询波文件列表。在步骤2080该程序确定上述查询是否成功。如果不成功，则在步骤2082，产生一个日志错误消息，并且在步骤2084返回ERROR(C)。
如果在步骤2080上述查询成功，则在步骤2088该程序打开服务器上的波文件并且准备好流。其还返回该段中音频的波格式。在步骤2093该程序确定波文件和格式是否成功获得。如果不成功，则在步骤2094产生一个日志错误消息，并且在步骤2095返回ERROR(C)。如果在步骤2093确定步骤2088已经成功，则在步骤2096该程序检查是否所有的段已经初始化。如果没有，则程序返回步骤2076。如果是，执行步骤2097并且在步骤2098返回SUCCESS。
图21说明该程序如何管理播放器对象2110和PbkControlWin对象2132。
图22说明流控制管理器的播放顺序。初始地，在步骤2202用户已经完成了初始化并且等待在播放器GUI中点击播放。在步骤2202该用户点击播放按钮。在步骤2206将一条消息发送到播放器ActiveX控件中的播放方法。在步骤2210播放器ActiveX控件中的该播放方法导致输出缓存“分片”以增加发送的更小的缓存的数量，因此增加“totalPlayed”变量的分辨率。在步骤2218播放方法引起服务器端位置移动到当前滑动器位置。在步骤2222该程序从SEGMENT矢量中得到segment i++。在步骤2224(参见图22A)该程序确定segmenti的结束时间偏移是否大于CurPosition。如果不大于，该程序返回步骤2222。如果大于，该程序进行到步骤2226并且使服务器端的文件指针改变到合适的新位置。该程序在步骤2230检查步骤2226是否成功。如果不成功，产生一个日志错误消息，并且在步骤2234返回ERROR(C)。
如果在步骤2230确定步骤2226已经成功，则在步骤2238该程序调用Stream Control::StartStream。在步骤2242该程序从SEGMENT矢量中得到Segment i++。在步骤2244该程序调用CoMarshalInterThreadInterfaceInStream来配置一个DCOM指针成员越过线程边界。在步骤2246该程序确定是否所有的SEGMENT元素都已经被配置了。如果没有，则该程序返回步骤2242。如果是，则在步骤2248产生主SCM流线程。
图22B说明SCM主流线程。当该线程开始时，在步骤2250该线程从SEGMENT矢量中得到一个段。在步骤2252调用CoCetInterfaceAndReleaseStream解除DCOM指针成员越过该线程边界的配置。在步骤2254该线程检查是否所有的段元素都已经被解除配置。若没有，则该线程返回步骤2250。如果在步骤2250确定所有SEGMENT元素都已经被解除配置，则在步骤2256该线程从SEGMENT矢量中得到一个段。然后该线程在步骤2258检查Segment i的结束时间偏移是否大于curAmountRequested。如果不大于，则该线程返回步骤2256。如果大于，则在步骤2260该线程得到Segment[i++]。在步骤2262该线程检查i是否小于最高段号。如果不小于，则在步骤2264调用Event::Done方法，并且在步骤2266返回SUCCESS(C)。如果小于，则在步骤2268该线程确定这是否是该线程实例中要播放的第一个段。如果不是，则在步骤2270该线程为Segment[i]调用PBServer::PositionPLay(totalRequested)并且到达步骤2272。如果是，该线程直接到步骤2272。
在步骤2272，该线程检查totalRequested是否小于Segment[i]。endTimeOffset。如果不小于，则该线程返回步骤2260。如果小于，则该线程进行步骤2274并且检查totalRequested加上bufferSize是否小于或等于Segment[i]。endTimeOffset。如果不小于或等于，则在步骤2276该线程在多个音频格式的“块对齐”中计算新的bufferSize并且继续步骤2278(参见图22C)。如果小于或等于，则该线程直接继续步骤2278。在步骤2278，该线程为Segment[i]调用PBServer::ReqBuffer。这是实际从播放服务器中检索缓存数据的核心例程。在步骤2286该线程检查步骤2278是否成功。如果不成功，则在步骤2284产生一个日志错误消息，并且在步骤2282返回ERROR(C)。
如果在步骤2286该线程确定步骤2278成功，则在步骤2287totalRequested设置为等于totalRequested加上实际返回的缓存大小。在步骤2288，该线程检查是否允许块分片。如果不允许，则在步骤2289该线程将通过Event::SendData程序将缓存发送回播放器并且返回步骤2274。如果已经允许块分片，则在步骤2292该线程检查编解码器是否是Dialogic OKI ADPCM或PCM。如果不是，则在步骤2293分片的片设置为等于音频格式的块对齐并且该线程进行到步骤2296。如果是，在步骤2294分片的大小设置为缓存大小的偶被除数(even dividend)(例如缓存大小的十分之一)。在步骤2296，该线程从缓存中拷贝出“分片大小”并且通过Event::SendData方法将其发送回播放器。在步骤2298该线程检查整个缓存是否已经全部送回。如果没有，则该线程返回步骤2298。如果是，则该线程返回步骤2274。
流控制管理器理论上适合于用在通信记录系统之外的更通用的流媒体情况中。在最近的用于基于网络的音频内容播放的基于流的系统中，如RealMedia和NetShow，存在称为单播和组播的两种常用广播结构。单播涉及用于数据流的单一的客户端-服务器连接，而在组播情况下服务器将数据推进多个客户端可以“调谐进去”的单一网络地址。但是两种模型都假设数据持续从一个单一服务器流入。为了负载均衡，或如果流图象的片跨过多个位置展开，则SCM模型可以提供一个创新的解决方案，其中客户端有能力将许多流组合成单一播放会话。可以想象一个例子其中新的机构，如CNN，为在线观众动态地将来自位于遍布全国的服务器上的许多不同报告组装成流广播。利用SCM模块该组件可以无缝地端到端播放，并且如果观众想要倒带或者快进到流中的一个特定点，则SCM模块允许完全透明的控制。
本发明并不限于这里描述的特定实施方案的范围。实际上，除了这里描述的那些，对于本领域的技术人员从上述描述和附图可以很清除地看到优选实施方案的修改。无疑，在不背离本发明教导的情况下可以设想大量的其他实施方案，本发明的范围由下面的权利要求书规定。
除特别声明的之外，本说明书中公开的所有特性(包括任何附带的权利要求书、摘要和附图)可以由提供相同、相等或类似目的的替代特性替换。因此，除非特别声明，公开的每个特性仅仅是通用一系列等价物或类似特性的一个例子。

Claims (38)

1、一种提供包括一个或多个段的电话通话的持续时间记录的方法，每个段的音频数据在一个或多个具有已知位置的记录器上记录，该方法包括：
(a)为至少一个电话通话构建通话记录；
(b)接收与一个或多个电话通话相关的有关电话事件的数据；
(c)将一个接收的电话事件与构建的通话记录相匹配；
(d)基于接收的电话事件数据更新匹配通话记录；以及
(e)将更新的通话记录与为通话的段指示记录的音频数据位置的数据组合，以获得表示该电话通话持续时间的主通话记录。
2、权利要求1的方法，其中在步骤(c)使用了一个信用因数算法来确定是否已经找到一个匹配。
3、权利要求1的方法，还包括，利用主通话记录中记录的音频数据的位置来为至少一个电话通话的播放段进行组装的步骤。
4、权利要求1的方法，还包括显示基于主通话记录的电话通话的图形表示的步骤。
5、权利要求4的方法，其中图形表示包括电话通话每个段的表示。
6、用于实现根据权利要求1、2、3、4或5的方法步骤的计算机软件。
7、用于存储权利要求6的软件的制品。
8、一种播放存储在可由一个或多个播放服务器访问的位置中的数据段的方法，该方法包括：
(a)识别要播放的数据段以及识别的段播放的顺序；
(b)向播放服务器发送与所识别的准备播放的数据段相关联的通知；以及
(c)在接收到播放请求时按识别的顺序播放识别的段。
9、权利要求8的方法，其中识别步骤还包括识别将播放的数据段的位置。
10、权利要求8的方法，其中识别步骤还包括识别至少一个数据段的时长以及访问所述至少一个数据段的播放服务器。
11、权利要求8的方法，其中识别步骤还包括为识别的数据段识别一个或多个播放目的地。
12、权利要求10的方法，还包括接收描述所述至少一个数据段的时长的数据、基于接收到的时长数据确定何时向播放服务器发送播放请求、以及对请求定时以便使播放期间段之间的任何间隔最小化。
13、权利要求8的方法，还包括显示播放的数据段的播放状态的图形表示的步骤。
14、用于实现根据权利要求8、9、10、11、12或13的方法步骤的计算机软件。
15、用于存储权利要求14的计算机软件的制品。
16、一种用于记录关于包括一个或多个段的电话通话的信息的系统，包括：
(a)具有用于存储关于一个或多个电话通话的有关电话通话段的音频数据的一个或多个位置的第一存储器；
(b)具有用于存储与电话通话段相关的有关电话事件的数据的一个或多个位置的第二存储器；
(c)一个处理器，其被编程用于识别与一个电话通话相关的电话通话段以及利用与电话通话的电话通话段相关联的有关电话事件的数据构建该电话通话持续时间的数据表示。
17、权利要求16的系统，其中数据表示包括：
(i)电话中的参与方列表，以及
(ii)通话的开始和结束时间。
18、权利要求16的系统，其中上述数据表示包括：
(i)关于该通话的电话事件列表，以及
(ii)包括每个电话事件发生时间的列表。
19、权利要求16的系统，其中数据表示包括对于该通话的每个段存储的该段的音频数据的位置。
20、权利要求16的系统，其中关于电话事件的数据是从连接到电话交换环境的多个源接收的。
21、一种用于记录关于包括一个或多个段的电话通话的信息的方法，包括：
(a)接收与一个或多个电话通话相关的有关一个或多个电话通话段的音频数据，以及与所述电话通话段相关的有关电话事件的数据；
(b)存储接收的关于电话通话段的音频数据；
(c)存储接收的与所述电话通话段相关的有关电话事件的数据；
(d)识别与一个电话通话相关的电话通话段；以及
(e)利用与电话通话的电话通话段相关的有关电话事件的数据构建电话通话持续时间的数据表示。
22、权利要求21的方法，其中数据表示包括：
(i)该电话通话中的参与方列表，以及
(ii)该通话的开始和结束时间。
23、权利要求21的方法，其中数据表示包括：
(i)关于该通话的电话事件列表，以及
(ii)包括每个电话事件发生时间的列表。
24、权利要求21的方法，其中数据表示包括对于通话每个段存储的该段的音频数据的位置。
25、权利要求21的方法，其中关于电话事件的数据是从连接到电话交换环境的多个源接收的。
26、权利要求21的方法，还包括使用所述数据表示来显示所述电话通话的图形表示的步骤。
27、权利要求22的方法，还包括使用所述数据表示来显示所述电话通话的图形表示的步骤。
28、权利要求27的方法，其中图形表示包括通话的每个段的表示。
29、一种记录电话通话信息的方法，包括：
(a)从与一个或多个电话通话相关的有关电话事件的第一个源电子地接收数据；
(b)从与一个或多个电话通话相关的有关电话事件的第二个源电子地接收数据；以及
(c)当来自所述第一和第二个源的事件数据是关于相同电话通话时，电子地将来自所述第一个源的事件数据和来自所述第二个源的事件数据合并成单一通话记录。
30、权利要求29的方法，其中来自所述第一个源的所述数据是实时数据并且来自所述第二个源的数据是异步数据。
31、权利要求29的方法，其中合并事件数据的步骤(c)还包括利用信用因数来将进入事件数据与已有通话记录相匹配。
32、权利要求29的方法，还包括将来自所述第一和所述第二个源的事件数据转换为特定平台格式，以及将所述转换后的事件数据发送到目标平台的步骤。
33、可执行用来处理电话通话信息的计算机软件包括：
(a)用于从多个源接收关于电话事件数据的一个或多个数据采集线程；
(b)用于将通过数据采集线程收集到的事件数据合并为通话记录的一个或多个数据标准化线程；以及
(c)用于将来自一个或多个标准化线程的数据转换为目标平台特定的格式，并且将所述转换后的数据发送到目标平台的一个或多个消息发送器线程。
34、权利要求33的程序，其中用于一个或多个标准化线程的软件包括一个信用因数算法以将进入事件数据与已有通话记录相匹配。
35、权利要求33的程序，其中提供关于电话事件的数据的至少一个源是CTI链路。
36、用于存储权利要求33或34的计算机软件的制品。
37、用于实现根据权利要求29或30的方法步骤的计算机软件。
38、用于存储权利要求37的计算机软件的制品。
CN00811409A 1999-06-08 2000-06-08 一种用于通话记录创建及处理的系统和方法 Pending CN1369170A (zh)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US09/328,298 1999-06-08
US09/328,294 US6252946B1 (en) 1999-06-08 1999-06-08 System and method for integrating call record information
US09/328,298 US6246752B1 (en) 1999-06-08 1999-06-08 System and method for data recording
US09/328,295 US6252947B1 (en) 1999-06-08 1999-06-08 System and method for data recording and playback
US09/328,299 US6249570B1 (en) 1999-06-08 1999-06-08 System and method for recording and storing telephone call information
US09/328,299 1999-06-08
US09/328,295 1999-06-08
US09/328,294 1999-06-08

Publications (1)

Publication Number Publication Date
CN1369170A true CN1369170A (zh) 2002-09-11

Family

ID=27502378

Family Applications (1)

Application Number Title Priority Date Filing Date
CN00811409A Pending CN1369170A (zh) 1999-06-08 2000-06-08 一种用于通话记录创建及处理的系统和方法

Country Status (11)

Country Link
EP (1) EP1183852A4 (zh)
CN (1) CN1369170A (zh)
AU (1) AU5329200A (zh)
CA (1) CA2376157C (zh)
DE (1) DE1183852T1 (zh)
ES (1) ES2191574T1 (zh)
HK (1) HK1045231A1 (zh)
IL (4) IL146901A0 (zh)
MX (1) MXPA01012606A (zh)
NZ (1) NZ516066A (zh)
WO (1) WO2000076188A1 (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100334913C (zh) * 2004-05-07 2007-08-29 乐金电子(中国)研究开发中心有限公司 便携终端的通信细目分析装置及方法
CN101997993A (zh) * 2009-08-25 2011-03-30 北京合力金桥软件技术有限责任公司 一种cti应用嵌入式内存数据库的方法
CN103220420A (zh) * 2013-04-07 2013-07-24 广东欧珀移动通信有限公司 一种永久存储通话记录的方法和装置
CN103297419A (zh) * 2013-04-23 2013-09-11 携程计算机技术（上海）有限公司 线下线上数据融合方法及系统
CN105100378A (zh) * 2014-05-19 2015-11-25 腾讯科技（深圳）有限公司 移动终端通信记录的处理方法和装置
CN108401194A (zh) * 2018-04-27 2018-08-14 广州酷狗计算机科技有限公司 时间戳确定方法、装置和计算机可读存储介质
CN109830248A (zh) * 2018-12-14 2019-05-31 维沃移动通信有限公司 一种音频录制方法及终端设备
CN113067848A (zh) * 2021-02-05 2021-07-02 厦门亿联网络技术股份有限公司 一种通话记录同步方法、系统及电子设备

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0000735D0 (en) * 2000-01-13 2000-03-08 Eyretel Ltd System and method for analysing communication streams
CN1386358A (zh) * 2000-05-15 2002-12-18 松下电器产业株式会社 语音存储系统、交换机及语音存储装置
GB0029574D0 (en) * 2000-12-02 2001-01-17 Hewlett Packard Co Recordal service for voice communications
AU2002222479B2 (en) 2000-12-12 2007-04-05 Nice Systems Ltd. A method and system for monitoring and recording voice from circuit-switched switches via a packet-switched network
US6868141B2 (en) 2001-08-22 2005-03-15 Siemens Aktiengesellschaft Method and telephone agent system for generating a message record of at least a part of a conversation between telephone agents and for transmitting information regarding the message record to the telephone agent requesting it
EP1286524A1 (en) * 2001-08-22 2003-02-26 Siemens Aktiengesellschaft Generating a message record of a conversation between telephone agents and transmitting information regarding the message record to a telephone agent who has requested it
GB0501939D0 (en) * 2005-01-29 2005-03-09 Retell Holdings Ltd A telephone system
CN1984181B (zh) * 2006-04-21 2010-08-04 华为技术有限公司 一种回收通话记录的方法
US9787534B1 (en) 2015-01-15 2017-10-10 Amdocs Software Systems Limited System, method, and computer program for generating event tests associated with a testing project

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5533103A (en) * 1994-04-28 1996-07-02 Electronic Information Systems, Inc. Calling system and method
US5982857A (en) * 1994-10-17 1999-11-09 Apropros Technology Voice recording method and system providing context specific storage and retrieval
US5867559A (en) * 1996-02-20 1999-02-02 Eis International, Inc. Real-time, on-line, call verification system

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100334913C (zh) * 2004-05-07 2007-08-29 乐金电子(中国)研究开发中心有限公司 便携终端的通信细目分析装置及方法
CN101997993A (zh) * 2009-08-25 2011-03-30 北京合力金桥软件技术有限责任公司 一种cti应用嵌入式内存数据库的方法
CN103220420B (zh) * 2013-04-07 2015-02-25 广东欧珀移动通信有限公司 一种永久存储通话记录的方法和装置
CN103220420A (zh) * 2013-04-07 2013-07-24 广东欧珀移动通信有限公司 一种永久存储通话记录的方法和装置
CN103297419B (zh) * 2013-04-23 2016-01-20 携程计算机技术（上海）有限公司 线下线上数据融合方法及系统
CN103297419A (zh) * 2013-04-23 2013-09-11 携程计算机技术（上海）有限公司 线下线上数据融合方法及系统
CN105100378A (zh) * 2014-05-19 2015-11-25 腾讯科技（深圳）有限公司 移动终端通信记录的处理方法和装置
CN108401194A (zh) * 2018-04-27 2018-08-14 广州酷狗计算机科技有限公司 时间戳确定方法、装置和计算机可读存储介质
CN108401194B (zh) * 2018-04-27 2020-06-30 广州酷狗计算机科技有限公司 时间戳确定方法、装置和计算机可读存储介质
CN109830248A (zh) * 2018-12-14 2019-05-31 维沃移动通信有限公司 一种音频录制方法及终端设备
CN109830248B (zh) * 2018-12-14 2020-10-27 维沃移动通信有限公司 一种音频录制方法及终端设备
CN113067848A (zh) * 2021-02-05 2021-07-02 厦门亿联网络技术股份有限公司 一种通话记录同步方法、系统及电子设备
CN113067848B (zh) * 2021-02-05 2023-09-26 厦门亿联网络技术股份有限公司 一种通话记录同步方法、系统及电子设备

Also Published As

Publication number Publication date
CA2376157C (en) 2009-03-24
HK1045231A1 (zh) 2002-11-15
NZ516066A (en) 2003-07-25
AU5329200A (en) 2000-12-28
WO2000076188A1 (en) 2000-12-14
IL182674A (en) 2009-07-20
DE1183852T1 (de) 2003-06-26
IL182673A (en) 2009-07-20
IL182674A0 (en) 2007-09-20
MXPA01012606A (es) 2002-06-21
ES2191574T1 (es) 2003-09-16
CA2376157A1 (en) 2000-12-14
IL182673A0 (en) 2007-09-20
EP1183852A1 (en) 2002-03-06
IL146901A0 (en) 2002-08-14
IL182675A (en) 2009-07-20
EP1183852A4 (en) 2005-11-23
IL182675A0 (en) 2007-09-20

Similar Documents

Publication Publication Date Title
CN1369170A (zh) 一种用于通话记录创建及处理的系统和方法
CN1171433C (zh) 检测通信网络的可能的非法使用的方法及系统
CN1147325A (zh) 通信网络中的服务分配
CN1336068A (zh) 智能网
CN1497932A (zh) 管理个人电话记录的系统和方法
CN1497931A (zh) 复制和传送电话对话的系统和方法
CN100342735C (zh) 用于移动电话业务的自动传送和信息系统
CN1252642C (zh) 集成化提供与多重终端仿真、超媒体及电话系统的并行交互作用的远程服务工作站
CN1497930A (zh) 处理个人电话记录器命令的系统和方法
CN1226885C (zh) 无线电通信装置和其中建立双模式呼叫的方法
CN1198862A (zh) 对比资料及通过引用加入的软件
CN1224559A (zh) 扩充寻址方案的方法和系统
CN1389075A (zh) 电子数字开门器
CN1133662A (zh) 面向对象的电话系统
CN1435043A (zh) 呼叫中心运用方法及装置
CN1122639A (zh) 通信网络的数据校正系统
CN1823347A (zh) 用来提供一种服务的系统和方法
CN1507725A (zh) 因特网通信系统、因特网通信方法、对话管理服务器、通信适配器、通信中继服务器及程序
CN1828528A (zh) 统一消息通信状态改变的动态配置
CN1852355A (zh) 一种收集用户通信特征信息的方法和装置
CN1140367A (zh) 电信服务干扰
CN1760900A (zh) 广播电视媒体资产管理系统及其调控方法
CN1399839A (zh) 包括一个或多个有程序设计功能的电话通信设备的分布式通信网络
CN1650607A (zh) 移动终端用服务器
CN1235421C (zh) 智能终端应用协议

Legal Events

Date Code Title Description
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication