IE970169A1 - A telephone call monitoring system - Google Patents

Abstract

A telephoning call monitoring system (1) has a call record handler (14) which performs real time processing of call data. It communicates with a communications server (10) via an API and is thus isolated from the communications elements which are scalable in a modular manner. Processed data is written to a dedicated call database (15) for which write access is only allowed to the call record handler (14). Parameter values for the processing are stored in a separate values database (VDB, 26) which may be accessed by a user interface (20). Data managers (27) provide comprehensive parameter value updates to a master RAM (28) used by the CRH (14), to a reporting database (RDB 20) and to the values database (VDB 26). A reporting module (19) has read only access to the CDB (15) and to the RDB (20). Reporting criteria are stored in separate objects and lower-level filters which may be easily modified for flexible report outputting. <Fig. 1>

Description

Conventionally, such systems comprise a host computer 5 programmed to capture data from a PBX, log the data, process the data, and generate output reports according to report criteria.

The environment in which such systems operate has become more complex in recent years. For example, there is often a need to connect more than one PBX and thus multiple data streams must be processed simultaneously. In addition, call volumes are increasing dramatically. Further, with increasingly complex telephone network environments and customer call reporting requirements, the performance of call monitoring systems has been challenged despite the improvement in hardware processing capacity. Another problem is that existing systems tend to be inflexible in operation, both in respect of the extent of data which can be captured and processed, and the outputs which may be provided.

The invention is therefore directed towards providing a telephone call monitoring system which has improved flexibility for operation in different environments such as single-user or LAN environments. Another object is that the system provides different types of reporting outputs, while achieving short response times relative to the volume of data.

According to the invention, there is provided a telephone call monitoring system comprising:i$T Cl. -----—— ·; 3.RULE 23 , ,,, .,; a communication server having a port for connection to a private exchange for reception of call detail records (CDRs), said server having means for mapping real time buffer memory for received data; a user interface comprising means for interactively maintaining a parameter values database having a relational record structure; a data manager associated with each parameter value dataset, said managers comprising means for automatically writing contents of the values database to memory before real time call data processing; a call record handler comprising:means for communicating with the server via an API, and for processing received data in real time as it is received via said API according to the parameter values in said memory, and means for writing the processed data to a dedicated call database; and a reporting module comprising means for reading the call database and a dedicated reporting parameter values database and for generating output data reports according to pre-set filters, the reporting module having read-only access to said databases.

In one embodiment, the communications server comprises means for establishing separate and independent data streams and memory buffers for different private exchanges, either local or remote. b· ii /nj· λα «- u ioy Preferably, the communications server comprises means for retrieving setup values from operating system datasets and for storing said values in a dedicated register during processing.

In one embodiment, the call record handler comprises means for automatically activating relevant data managers to update values in the memory upon detection of a parameter value change in received call data.

In another embodiment, the user interface comprises means for indicating the relevant parameter value category to the call record handler upon amending a value in the values database, and the call record handler comprises means for automatically activating the relevant data manager to update the memory.

In a further embodiment, the date managers comprise means for automatically transferring a default parameter value to the call record handler when said handler can not determine a value for received call data.

Ideally, the call record handler comprises means for performing in-line compression of particular data items before writing to the call database.

Preferably, the call record handler comprises means for mapping a call buffer for temporary storage of processed call data between call database updates, and for mapping a call portion buffer for temporary storage of portions of complex call records.

In another embodiment, the system further comprises a data distribution mechanism, and wherein the call record handler comprises means for detecting alarm conditions in the received call data and for transmitting data indicating said conditions to the data distribution mechanism.

Preferably, said data distribution mechanism comprises means for automatically routing signals to hard-coded destinations .

In another embodiment, the reporting module comprises programmed addressable objects, each storing a set of report criteria and filters defined by object attributes, and a scheduler for activating said objects according to stored times.

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only, with reference to the accompanying drawings in which:Fig. 1 is a schematic representation of a telephone call monitoring system of the invention; and Fig. 2 is a set of flow diagrams illustrating operation of the system.

Referring to the drawings, and initially to Fig. 1, there is shown a telephone call monitoring system 1 of the invention. The system 1 is shown connected to two private exchanges, namely, a PBX 2 and a PBX 3.

The system 1 comprises a communications server 10 which communicates with the PBXs 2 and 3 and has a mapped section of RAM 11 associated with the PBX 2 and a section 12 associated with the PBX 3. These sections are for buffer storage of received Call Detail Records (CDRs). The server 10 is programmed to operate independently of the other parts of the system 1. Έ 970169 The server 10 communicates via an API with a call record handler (CRH) 14. The primary function of the call record handler 14 is to perform real time processing of the call data which is received from the server 10, including costing of the calls. The processed data is routed directly to a call database (CDB) 15. The CRH 14 is also programmed to operate independently of the other processing modules. It includes an output interface for real time display of processed call data, and a maintenance interface for specialist access to the CDB 15 for maintenance. The CRH 14 is the only processor which has write access to the CDB 15.

The CRH 14 is programmed to detect certain alarm events and to immediately notify a data distribution mechanism (DDM) 18, which is programmed to automatically route certain events to destinations which may be either remote or local. An example is immediate signalling to a network workstation that a 999 call has been made.

An independent reporting module 19 is programmed to retrieve data directly from the CDB 15, and to read parameter values from a reporting database (RDB) 20. The reporting module 19 can perform reads only from both of these databases. This helps to ensure data integrity. Operation of the reporting module 19 is not necessarily in real time.

The system 1 also comprises a user interface 25 which uses graphical interface displays to allow easy user updating of various parameter values and settings. These values are updated in a parameter values database (VDB) 26. This database is used by data managers 27 to update an 8 MB memory 28 which becomes a master store of parameter values while real time processing is taking place. Because these values are stored in RAM, the CRH 14 can provide a very fast response. There is a data manager 27 for every dataset, such as a carrier table, a band table, or a number prefix table.

When parameter values are updated by the interface 25 during real time processing, the CRH 14 is automatically notified of the category of the data involved. The CRH then activates the relevant data manager 27 to ensure that all memory and storage is updated accordingly. The relevant data manager 27 will update the RAM 28 and the RDB 20.

Operation of the system 1 is now described in more detail with reference to processes 30 shown in Fig. 2. In step 31, the communications server 10 sets up various communication parameters. The server 10 initialises communication with the CRH 14 by use of the API which is of the Windows SendMessage™ type. This API allows the memory control of the server 10 to be transparent to the CRH 14. The set-up values for the server 10 are stored in an operating system file and are written to a server register for use during a particular communications session. The parameters which are required at set-up are: connection type: direct, semi-conductor buffer, tape buffer communications port: Com 1, Com 4 baud rate: various settings between 110 and 38400 data bits: 7 or 8 stop bits: 1 or 2 parity: none, odd, even flow control: Xon/Xoff, hardware, none non standard Xon Xon/Xoff with High Bit Set Xon and Xoff character directory addresses for the VDB 21 limit for issue of warnings about available buffer memory space time delay before issuing a warning if no data is received.

These setup values may be modified via a dedicated server user interface.

In step 32, the server 10 uses a one-second call-back timer to poll each PBX which will supply data. Immediately following establishment of the communication streams, the server 10 in step 33 maps the RAM buffers 11 and 12 - one for each stream. Each buffer is 0.5 MB in size.

As data is received from the PBXs 2 and 3, the server 10 immediately routes it to the CRH 14 in step 34. It only uses the buffers 11 and 12 in exceptional circumstances. The following is an example of a CDR which is received and routed to the CRH 14:- OTG 16:17:20 00:01:40 246 6512345 (outgoing call) (trunk no.) (start time) (duration) (extension used) (telephone number dialled) Because the parameter values required by the CRH 14 are stored in the RAM 28 in step 50, it may process the CDRs which are received very quickly in real time. The parameter values stored in the RAM 28 include tables for charging bands, PBX extensions, number prefixes, carriers, organisation departments, reporting filters, alarm search criteria for the data distribution mechanism 18, charging rates, DNA synchronisation data, exchange output format, and PBX format. Fig. 2 also shows a step 51 of the data managers 27 updating the RDB 20.

When processing the data in step 35, the CRH 14 initially checks for the alarm conditions and then proceeds with the conventional processing to update the CDB 15.

The processed data is in a very simple record structure which is written to the CDB 15 very quickly in variable length records - and also retrieved by the reporting module 19 in a quick and simple manner. The CRH 14 compresses some data items such as the destination telephone number in an in-line manner. This saves on time for the write operations, and also allows faster searching by the reporting module 19.

The steps of detecting alarm conditions, notifying the DDM 18, and of the DDM 18 routing the signals to the hardcoded destinations are indicated by the numerals 40, 41 and 42 respectively in Fig. 2. l_ 11 / I ΙΊ ln.ll 11— CJ I V I VC/ The CRH 14 writes processed data to the call buffer 16 and at regular intervals which are set by a time limit and by a space limit, whichever is the lower, triggers the writing of an update to the CDB 15 in step 36. The call portion buffer 17 is used for storage of portions of a full CDR while awaiting the remainder. An example of such data is that for a call which is transferred.

The data managers 27 play an important role in ensuring that the CRH 14 processes received data in real time. As described above, they are used to refresh and synchronise all data after the CRH 14 receives a notification from the user interface 25. In addition, if the CRH 14 receives a CDR for which it cannot ascertain an item of data such as charging band, it requests a default value from the data manager for that dataset. This helps to ensure continuity of processing. Further, if the CRH 14 identifies a parameter value change in received call data, it activates the relevant data manager 27 to update the memory 28, the VDB 26, and the RDB 20. An example of such an event is receiving an unknown PBX extension number.

In step 37, the reporting module 19 retrieves data from the CDB 15 and outputs it according to search criteria and filters. The reporting module 19 comprises a large set of objects, each being a report with a set of report conditions, or a lower level report filter. There may be a number of different filters within a single report. In more detail, each object has a set of attributes including a common set of attributes including an identifier, a data size limit, an associated GUI display icon, and a flag indicating whether or not the report is scheduled. The reporting module 19 also includes a scheduler which activates objects according to time to provide automatic reporting in a very comprehensive manner. It has been found that this structure for the reporting module 19 may IE 9/0169 -10be easily modified because of its modular nature and the manner in which the objects may be easily modified for different search and filter criteria.

During real time processing, the CRH 14 relies on the parameter values in the RAM 28, and thus this data is essentially the master data during real time processing. Thus, whenever the CRH 14 receives a notification of a change in these values it immediately activates the relevant data manager 27 to cause the necessary updates to be made. Referring again to Fig. 2, a parameter update signal is received in step 55 at the user interface 25 and this is notified to the CRH 14 in step 56. The CRH 14 in turn notifies the relevant data manager 22 in step 57 and this updates both the RAM 28 and the RDB 20.

Another aspect of the operation of the CRH 14 which helps to achieve a very fast response time is the fact that the record it writes to the CDB 15 may include some raw data as well as processed data. This allows a finer level of detail to be processed by the reporting module 16 subsequent to processing by the CRH 14. The following is an example of the processing which may be left to the reporting module 19:placename resolution, destination type resolution, and flags and feature data processing.

Taking PBX flag information as an example, this is received by the CRH 14 which compacts it and writes it to the record without further processing. The reporting module 19 may use filters to determine which records to include in reports, based on the state of the PBX flag. - 11 It will be appreciated that the invention allows very flexible operation of a telephone call monitoring system. The communication server 10 is scalable in a modular manner to allow connection to different call data sources, including TCP/IP networks. Further, the objects of the reporting module 19 (which is separated from the core processing) may be easily updated. A very fast response time is achieved by virtue of the separation of the CRH 14 from the communications server and the fast writes to the CDB 15, with parameter values being stored in a completely separate database which is accessible by the user interface 25. The CDB 15 is in effect a dedicated real time processing database which may be accessed only by the CRH 14 for writes, the reporting module 19 only performing reads. The data managers 27 achieve comprehensive data updates in real time while allowing the master values to be stored in RAM. In general, the modular architecture allows implementation with a single hardware machine or a distributed hardware arrangement.

The invention is not limited to the embodiments hereinbefore described, but may be varied within the scope of the claims in construction and detail.

Claims (12)

1. A telephone call monitoring system comprising:a communication server having a port for connection to a private exchange for reception of call detail records (CDRs), said server having means for mapping real time buffer memory for received data; a user interface comprising means for interactively maintaining a parameter values database having a relational record structure; a data manager associated with each parameter value dataset, said managers comprising means for automatically writing contents of the values database to memory before real time call data processing; a call record handler comprising:means for communicating with the server via an API, and for processing received data in real time as it is received via said API according to the parameter values in said memory, and means for writing the processed data to a dedicated call database; and a reporting module comprising means for reading the call database and a dedicated reporting parameter values database and for generating output data reports according to pre-set filters, the reporting module having read-only access to said databases.

2. A telephone call monitoring system as claimed in claim 1, wherein the communications server comprises - 13 means for establishing separate and independent data streams and memory buffers for different private exchanges, either local or remote.

3. A telephone call monitoring system as claimed in claim 2, wherein the communications server comprises means for retrieving setup values from operating system datasets and for storing said values in a dedicated register during processing.

4. A telephone call monitoring system as claimed in any preceding claim, wherein the call record handler comprises means for automatically activating relevant data managers to update values in the memory upon detection of a parameter value change in received call data.

5. A telephone call monitoring system as claimed in claim 4, wherein the user interface comprises means for indicating the relevant parameter value category to the call record handler upon amending a value in the values database, and the call record handler comprises means for automatically activating the relevant data manager to update the memory.

6. A telephone call monitoring system as claimed in any preceding claim, wherein the data managers comprise means for automatically transferring a default parameter value to the call record handler when said handler can not determine a value for received call data.

7. A telephone call monitoring system as claimed in any preceding claim, wherein the call record handler comprises means for performing in-line compression of I VC? particular data items before writing to the call database.

8. A telephone call monitoring system as claimed in any preceding claim, wherein the call record handler comprises means for mapping a call buffer for temporary storage of processed call data between call database updates, and for mapping a call portion buffer for temporary storage of portions of complex call records.

9. A telephone call monitoring system as claimed in any preceding claim, further comprising a data distribution mechanism, and wherein the call record handler comprises means for detecting alarm conditions in the received call data and for transmitting data indicating said conditions to the data distribution mechanism.

10. A telephone call monitoring system as claimed in claim 9, wherein said data distribution mechanism comprises means for automatically routing signals to hard-coded destinations .

11. A telephone call monitoring system as claimed in any preceding claim, wherein the reporting module comprises programmed addressable objects, each storing a set of report criteria and filters defined by object attributes, and a scheduler for activating said objects according to stored times.

12. A telephone call monitoring system substantially as hereinbefore described with reference to the accompanying drawings .