IE83902B1 - A telephone call monitoring system - Google Patents
A telephone call monitoring system Download PDFInfo
- Publication number
- IE83902B1 IE83902B1 IE1997/0169A IE970169A IE83902B1 IE 83902 B1 IE83902 B1 IE 83902B1 IE 1997/0169 A IE1997/0169 A IE 1997/0169A IE 970169 A IE970169 A IE 970169A IE 83902 B1 IE83902 B1 IE 83902B1
- Authority
- IE
- Ireland
- Prior art keywords
- call
- data
- monitoring system
- telephone call
- database
- Prior art date
Links
- UIIMBOGNXHQVGW-UHFFFAOYSA-M buffer Substances [Na+].OC([O-])=O UIIMBOGNXHQVGW-UHFFFAOYSA-M 0.000 claims description 17
- 230000003213 activating Effects 0.000 claims description 6
- 238000007906 compression Methods 0.000 claims description 2
- 238000001514 detection method Methods 0.000 claims description 2
- 238000000034 method Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 239000000969 carrier Substances 0.000 description 2
- 238000010276 construction Methods 0.000 description 1
- 229920003013 deoxyribonucleic acid Polymers 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 235000010384 tocopherol Nutrition 0.000 description 1
- 235000019731 tricalcium phosphate Nutrition 0.000 description 1
Description
"A Telephone Call Monitoring Svstem"
The invention relates ‘to a telephone call monitoring
system.
Conventionally, such systems comprise a host computer
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 typesi 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:—
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 RAM "before real time call, data
processing;
a call record handler comprising:—
means for communicating with the communication
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
RAM, and
means for writing’ the processed data
dedicated call database; and
to a
a reporting module comprising means for reading the
call database and means for reading 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.
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 at 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 mechanisnx 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. l 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 ll 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 (CDR5).
The server 10 is programmed to operate independently of
the other parts of the system 1.
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 SendMessagem 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 systenx 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 lpoll 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 (outgoing call)
(trunk no.)
:17:20 (start time)
:01:40 (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 tar the reporting
module 19 in. a quick and simple manneru 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 hard-
coded destinations are indicated by the numerals 40, 41
and 42 respectively in Fig. 2.
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
_ 10 _
be 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.
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 Inodule 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 (1)
- CLAIMS 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 said dataset, managers comprising means for automatically writing contents of the values database to RAM before real time call data processing; a call record handler comprising:— means for communicating with the communication server via an API,Tand for processing received data in real timeias it is received via said API according to the parameter values in said RAM, and means for writing the processed data to a dedicated call database; and a reporting module comprising means for reading the call database and. means for reading 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. A telephone call monitoring" system as claimed in claim l, wherein the communications server comprises means for establishing separate and independent data streams and memory buffers for different private exchanges, either local or remote. 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. 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. A telephone call nwnitoring 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. 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. A telephone call monitoring system as claimed in any preceding claim, wherein the call record handler comprises means for performing in—line compression of particular data items before writing to the call database. A telephone call monitoring system as claimed in any wherein the call record handler call temporary storage of processed call data between call preceding claim, comprises means for mapping a buffer for database updates, and. for mapping a call portion buffer for temporary storage of portions of complex call records. A telephone call monitoring system as claimed in any l“claim, further comprising a data distribution mechanism, and wherein the call record handler conditions in the comprises means for detecting alarm call transmitting data indicating said conditions to the received data and for data distribution mechanism. 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. 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. A telephone call monitoring system substantially as hereinbefore described with reference to the accompanying drawings.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IE1997/0169A IE83902B1 (en) | 1997-03-10 | A telephone call monitoring system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IE1997/0169A IE83902B1 (en) | 1997-03-10 | A telephone call monitoring system |
Publications (3)
Publication Number | Publication Date |
---|---|
IE19970169A1 IE19970169A1 (en) | 1998-09-10 |
IE970169A1 IE970169A1 (en) | 1998-09-23 |
IE83902B1 true IE83902B1 (en) | 2005-05-18 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9571361B1 (en) | Status reporting system | |
EP0744055B1 (en) | Distributed data base system | |
US6173328B1 (en) | System for transferring multimedia information | |
US6496856B1 (en) | Video storage and retrieval system | |
JP2646385B2 (en) | Call transfer control method and apparatus | |
US6212676B1 (en) | Event architecture for system management in an operating system | |
US6330555B1 (en) | Method and apparatus for enabling a view of data across a database | |
US20030086554A1 (en) | Automatic call distribution groups in call center management systems | |
JP2002530740A (en) | Application-independent messaging system | |
US20040109544A1 (en) | Architecture for unified messaging | |
GB2323243A (en) | Telephone call monitoring | |
IE83902B1 (en) | A telephone call monitoring system | |
IE19970169A1 (en) | A telephone call monitoring system | |
IE970169A1 (en) | A telephone call monitoring system | |
EP1109413A1 (en) | Summary building block, system and method for network management | |
JPH0362167A (en) | Distributed information retrieval system | |
CN1722757B (en) | Recording system based on voice communication | |
US6347348B1 (en) | Buffer management system having an output control configured to retrieve data in response to a retrieval request from a requesting one of a plurality of destinations | |
JPH11239151A (en) | Device and method for controlling round robin | |
WO1999021111A1 (en) | Attribute driven message management device and method | |
WO2021063242A1 (en) | Metadata transmission method of storage system, and storage system | |
GB2351372A (en) | Data processing of invoices | |
JPH0784857A (en) | Relay type file transfer system | |
JPH1131111A (en) | Electronic mail item managing system and medium used for the same | |
JPS63318628A (en) | Horizontally dividing system for data base |