EP1183852A1 - A system and method for call record creation and processing - Google Patents
A system and method for call record creation and processingInfo
- Publication number
- EP1183852A1 EP1183852A1 EP00938220A EP00938220A EP1183852A1 EP 1183852 A1 EP1183852 A1 EP 1183852A1 EP 00938220 A EP00938220 A EP 00938220A EP 00938220 A EP00938220 A EP 00938220A EP 1183852 A1 EP1183852 A1 EP 1183852A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- call
- data
- cti
- telephone
- record
- 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.)
- Withdrawn
Links
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
Definitions
- This invention relates generally to computer-aided data recording.
- it relates to computer-aided monitoring and recording of voice signals, such as telephone calls.
- Telephone call monitoring systems are used in a variety of contexts, including emergency dispatch centers and commercial call centers.
- a multitude of audio input sources (“channels") are monitored and recorded by a single hardware unit, and the audio recordings are saved and organized according to the input channel, date, time and duration.
- the capacity of the recording unit can be expanded to handle a larger number of channels by combining several recording units into a system using a local area network (LAN).
- LAN local area network
- CTI computer telephony integration
- PBX private branch exchange
- Data fields that are available within this expanded information may include the external telephone number of the calling party, as well as identification numbers to help associate a series of events pertaining to the same call.
- the search and retrieval system can be supplemented by constructing a database that combines the previously discussed basic search criteria with enhanced search criteria (based upon information obtained through a CTI data link) such as: telephone numbers of parties involved in the call; Caller ID (CLID) or Automatic Number Identification (ANI); Dialed Number Identification Service (DNIS); or the Agent ID Number of the Customer Service Representative.
- CTI data link such as: telephone numbers of parties involved in the call; Caller ID (CLID) or Automatic Number Identification (ANI); Dialed Number Identification Service (DNIS); or the Agent ID Number of the Customer Service Representative.
- CTI data link such as: telephone numbers of parties involved in the call; Caller ID (CLID) or Automatic Number Identification (ANI); Dialed Number Identification Service (DNIS); or the Agent ID Number of the Customer Service Representative.
- CTI data link such as: telephone numbers of parties involved in the call; Caller ID (CLID) or Automatic Number Identification (ANI); Dialed Number Identification Service (DNIS); or the Agent ID Number of the Customer Service Representative.
- a recording unit can intercept telephone
- SMDR tation Message Detail Recording
- CDR Call Detail Recording
- Information from these links is generally provided after the call has concluded, and as such is suitable for billing applications or traffic analysis software.
- Many newer links use real-time interfaces that are designed to supply a series of events while a telephone call is still active within the PBX, to enable computer and multimedia systems to respond and interact with an external caller. The information provided by such real-time links is typically much more detailed than that provided by SMDR.
- CTI link The detailed information and real-time nature of a CTI link is particularly important when building a recording system that is intended to react to telephone calls as they occur and to dynamically select which calls ought to be recorded or discarded. CTI-supplied information is also important when building a recording system that is intended to capture the full history of a telephone call, including recording the different agents who were involved in the conversation and how the call was held, transferred or conferenced. Likewise, real-time information is important in a system that intends to support (a) a live display of active calls, and (b) the capability for a user to listen and monitor the live audio traffic.
- a "trunk-side" solution based upon voice recording alone will not satisfy the above requirements in a practical manner, since telephone calls are assigned to trunks dynamically as needed to handle the traffic. What trunk channel a particular call will be carried on cannot be predicted in advance. Without information to associate a logical telephone call with a physical recording of audio from a trunk channel, a user might have to search and retrieve many recordings before finding the one that is of interest. Moreover, in a system designed to make use of the enhanced search criteria provided by a data link, it would not be possible to programmatically associate the search data with the voice recording without information about the trunk channel where the call occurred.
- the present invention is directed to a system and method that are capable of constructing a call record for each telephone call; receiving data regarding telephony events; matching a received telephony event with a call record; updating the matching call record based on the received telephony event data; and combining the updated call record with data indicating the location of recorded audio data for the segment of the call, to generate a master call record representing the lifetime of the telephone call.
- the system and method are capable of assembling and playing back segments of telephone calls using the recorder locations described in the master call record for each telephone call, and of using said master call record to display a graphical representation of said telephone call.
- a preferred embodiment of the subject invention is also directed to a system and method for playing back data segments stored in one or more locations and managed by one or more playback servers.
- the system and method receives data describing data segments to be played back, transmits notifications to the playback servers to prepare for playback, and then transmits playback requests to the playback servers.
- the received data comprises data describing the duration of each data segment, and the system uses the data segment duration data to determine when to transmit playback requests to the playback servers and times the requests so as to minimize any gaps between the segments when they are played back.
- a graphical display can be provided to display the status of the segments being played back.
- a preferred embodiment of the subject invention is also directed to a system and method that is capable of simultaneously monitoring two or more data links, gathering information about calls from those data links, combining that information into a single data model of the telephony activity within the call center, and combining the data model with information concerning the location of call recordings, resulting in a "master call record" that contains data matching each call with the segments of which it is comprised, and matching the data for each segment with the location of the recording of that segment.
- the subject invention is also directed to a system and method that is capable of simultaneously monitoring two or more data links, gathering information about calls from those data links, and combining that information into a single data model of the telephony activity within the call center.
- the invention is a method of recording telephone call information comprising electronically receiving data from a first source regarding telephony events related to one or more telephone calls; electronically receiving data from a second source regarding telephony events related to one or more telephone calls; and electronically combining event data from the first source and event data from the second source into a single call record when event data from the first and second sources is related to the same telephone call.
- the first source is a CTI link and the second source is an SMDR link.
- the method comprises using a confidence factor to match incoming event data with existing call records.
- the invention is a computer program executable to process telephone call information, comprising one or more data collection threads for receiving data regarding telephony events from a plurality of sources; one or more data normalization threads for combining event data received via the data collection threads into call records; and one or more message emitter threads for converting data from the one or more data normalization threads into a format specific to a target platform, and transmitting the converted data to the target platform.
- the first source is a CTI link and the second source is an SMDR link.
- the program uses a confidence factor algorithm to match incoming event data with existing call records.
- the invention is an article of manufacture comprising a computer-readable medium storing a computer program for processing telephone call information, comprising one or more data collection threads for receiving data regarding telephony events from a plurality of sources; one or more data normalization threads for combining event data received via the data collection threads into call records; and one or more message emitter threads for converting data from the one or more data normalization threads into a format specific to a target platform, and transmitting the converted data to the target platform.
- the invention is a computer program controlling software components for processing telephone call information comprising computer software for receiving data from a first source regarding telephony events related to one or more telephone calls; computer software for receiving data from a second source regarding telephony events related to one or more telephone calls; and computer software for combining event data from the first source and event data from the second source into a single call record when event data from the first and second sources is related to the same telephone call.
- the invention is an article of manufacture storing a computer program controlling software components for processing telephone call information comprising computer software for receiving data from a first source regarding telephony events related to one or more telephone calls; computer software for receiving data from a second source regarding telephony events related to one or more telephone calls; and computer software for combining event data from said first source and event data from said second source into a single call record when event data from said first and second sources is related to the same telephone call.
- FIG. 1 is a block diagram of the system of this invention in a preferred embodiment.
- FIG. 2 illustrates the difference between trunk-side and station-side recording.
- FIG. 3 shows a line-chart that illustrates various parties involved in a complex call.
- FIG. 4 shows a schematic block diagram of a preferred embodiment for translating, summarizing and normalizing signals received from both an SMDR link and a Dialogic CT- Connect CTI service.
- FIG. 5 illustrates the steps by which the translation module CtiCtc.exe integrates the data received from the CTI and SMDR links.
- FIG. 6 illustrates how the CTI Server can be viewed as a set of logically distinct layers that deal with translating and distributing CTI events.
- FIG. 7 illustrates how, in addition to telephony events, the CTI Server 710 is responsible for supplying certain metadata regarding agent events to the System Controller 130.
- FIG. 10 depicts key elements of the data model used in a preferred embodiment.
- FIG. 11 illustrates three distinct layers of the CTI Server in a preferred embodiment.
- FIG. 12 shows in block diagram form several threads of the CTI Server in a preferred embodiment that implement three distinct layers of processing (data collection, data normalization, and message emission).
- FIG. 13 illustrates the program logic flow of the analyzer layer of the preferred embodiment.
- FIG. 14 depicts the flow of information within the recording system of this invention in a preferred embodiment.
- FIG. 15 shows how a recording unit operating with only voice signaling to guide the creation of its call records could make a number of fragmented audio segments.
- FIG. 16 shows a graphical user interface used in the preferred embodiment.
- FIG. 16 A shows a system containing a CTI Server and a Recorder in a specific embodiment of the present invention.
- FIG. 16B is a table illustrating descriptive information from the CTI Server used in a specific embodiment.
- FIG. 17 illustrates steps in the creation of a Master Call Record used in a specific embodiment..
- FIG. 18 shows the processing threads and data structures that comprise the CRG module in accordance with the present invention.
- FIG. 19 illustrates the class diagram of the Call Record Generator used in a specific embodiment.
- the present invention is directed to a communication recording system and method.
- the functionality of the system involves tapping into activity on a PBX (Private Branch Exchange) by intercepting audio on either the trunk or station side of a telephone call.
- the tapped audio is then redirected as input to a channel on a Digital Signal Processor (DSP) based voice processing board, which in turn is digitized into program addressable buffers.
- DSP Digital Signal Processor
- the recorded digitized audio is then combined with descriptive information ("metadata") obtained through a Computer Telephony Integration (CTI) communications link with the PBX, and stored as a single manageable unit (“Voicedata”) to facilitate its subsequent search and retrieval.
- CTI Computer Telephony Integration
- the communications recording system comprises multiple rack-mountable computer-processing servers (such as the Compaq ProLiant 1600 R), using a multi-tasking operating system (e.g., Microsoft Windows NT), DSP voice processing boards (e.g., Dialogic D/160SC), and a distributed set of software components available from Dictaphone Corporation.
- a multi-tasking operating system e.g., Microsoft Windows NT
- DSP voice processing boards e.g., Dialogic D/160SC
- a distributed set of software components available from Dictaphone Corporation.
- all of these components may reside in a single computer-processing server.
- related components are typically packaged in combinations and the entire system spans multiple servers that coordinate processing through a Local Area Network (LAN).
- LAN Local Area Network
- the overall system generally comprises CTI Servers,
- Voice Servers a Central Database Server
- User Workstations generally use a set of components to manage a data communications link with a telephone switch environment, to obtain notification of calls as they occur, along with the descriptive information about the calls (e.g., source and destination telephone numbers).
- the Voice Servers use a set of components to collect audio recordings, manage their storage, and facilitate their playback through the LAN.
- the Central Database Server uses a set of components to manage system- wide search and retrieval of recorded calls.
- User Workstations are typically desktop computers that use a set of components to allow a person to submit requests to search and retrieve recorded calls for playback and to control automatically scheduled functions within the recording system.
- FIG. 1 shows in a block diagram from components of the system of this invention in a preferred embodiment.
- Data enters the recording system from a variety of sources. These sources can include a PBX 100, CTI middleware 105, ISDN lines 110, or other input sources 115.
- sources can include a PBX 100, CTI middleware 105, ISDN lines 110, or other input sources 115.
- the system of the present invention can be used for monitoring and recording of information about any type of electronic communications.
- Telephone calls For simplicity, the following discussion uses the term Telephone calls. However, it is intended that term covers any electronic communication unless specified otherwise expressly.
- Audio Recorders 145 may be used for passive trunk-side 170 and extension-side 180 recording on a pre-determined static set of devices, as well as dynamically initiated recording of specific devices according to scheduling criteria through the Service Observance feature
- the CTI translation modules 165 and CTI message router 120 are co-resident upon a computer-processing server called the CTI Server 710.
- the combined set of components including the Time Service 125, Scheduling & Control Services 130, Audio Recorder 145, Audio Storage 140, and Call Record Generator 150, in a specific embodiment can be co-resident upon a computer-processing server called the Time Service 125, Scheduling & Control Services 130, Audio Recorder 145, Audio Storage 140, and Call Record Generator 150, in a specific embodiment can be co-resident upon a computer-processing server called the Time Service 125, Scheduling & Control Services 130, Audio Recorder 145, Audio Storage 140, and Call Record Generator 150, in a specific embodiment can be co-resident upon a computer-processing server called
- the CTI Server comprises two main components
- the CTI Server may have several translation modules, for example, one for each PBX interface, or for each vendor API layer.
- the CTI Server of the preferred embodiment accepts data from a PBX or similar equipment in a telephone switch environment, and can use both real-time CTI communications links and asynchronous information sources such the Station Message Detail Recording (SMDR) interface.
- the CTI Server translates and combines the various types of input data into a unified, normalized format. Normalized format information is then passed by the Message Router to various components of the system, as required.
- the Voice Server in a specific embodiment has several modules, including the Audio Recorder 145 and Call Record Generator (CRG) 150.
- the Audio Recorder 145 and Call Record Generator (CRG) 150.
- CCG Call Record Generator
- the Call Record Generator produces Master Call Records, which encapsulate information (metadata) describing a telephone call.
- This descriptive information comes from a plurality of sources, including but not limited to an Audio Recorder and a CTI Server.
- the call records are created using a participant-oriented Call Record Model.
- the CRG attempts to match the call records with existing recorded audio data. The CRG is thus able to combine data arriving in different chronological order into a single manageable entity which describes the complete history of a telephone call.
- a Playback Server (PBServer) (not shown) is a subcomponent within the Audio Recorder module which uses call records to retrieve and play back telephone calls.
- PBServer Playback Server
- Each recorder has its own PBServer, which is connected to a Player module (not shown) on the User Workstation 160.
- the Player module generally contains a Stream Control Manager module, which enables the Player module to use the PBServers to play back a telephone call which has several different participants and thus may have portions of the call stored on different recorders.
- the CTI server performs the task of analyzing and reorganizing data from both the real-time (CTI) and SMDR (asynchronous) links, and passing the results onwards into the recording system for further processing.
- CTI real-time
- SMDR asynchronous
- the Call Record Generator 150 integrates that data into a single call record, which is updated after every event during the call, so that at the end of the call, the call's entire history is contained in the call record.
- the CRG matches the call record to the recording segments created by the Audio Recorders.
- the CRG integrates the call record with the metadata for the associated recordings of the phone call to generate a Master Call Record.
- an operator wants to hear a recorded phone call, he uses the User Workstation (preferably equipped with a graphical user interface) to recall and play back the recorded call. Since the phone call may have had several different participants, pieces of the call may have been recorded on different recorders, each of which is associated with a different Playback Server. The system is nevertheless capable of playing back the entire phone call in the proper sequence.
- the CTI Server obtains the information regarding telephony events from various telephone switching environments, including PBXs, ACDs, and turret systems, which may have a wide variety of proprietary CTI interfaces.
- a telephone switching environment is a local telephone system that provides for routing of calls on a static or dynamic basis between specific destinations; the system is capable of identifying of when calls occur and who is involved in the calls.
- the CTI Server converts the information received into a common "normalized" format that is a simplified subset of the types of information available across the different vendors' PBXs, ACDs, and turret systems.
- Alternate embodiments of the translation module use Lucent Centre Vu Computer Telephony Server for Windows NT, or Genesys T-Server, as middleware instead of Dialogic CT-Connect. Additional alternate embodiments include direct "native" interfaces to a particular telephone switch, such as Aspect, without an interposing middleware product. In terms of the CTI messages exchanged between the CTI Server and the various components
- the CTI Server is a "passive listener.” That is, the CTI Server will monitor and receive information about call activity, but it will not send messages to affect, control, or redirect the calls. Using an "active" CTI server is also contemplated in specific embodiments.
- the focal point of a Voice Server is recording content (e.g., audio clips)
- the metadata generated by the CTI Server is focused on describing the facts pertinent to the start and end points of each participant's involvement within a call.
- recording is managed in a call-centric (rather than event- centric) fashion. This corresponds with the typical caller's point of view, in which a call is the entire conversation with a business entity, even if the conversation involves transfers to other agents or conferencing of multiple parties.
- the CTI Server generates events with metadata for the start and end points of the various recording segments of a complex conversation. These event records are interrelated by ID numbers and reason codes (see FIG.
- a browser application preferably implemented on the User Workstation 160.
- a single CTI Server may be configured so as to connect with several PBXs, ACDs, and turret systems, depending upon the traffic load and physical connectivity requirements.
- different CTI servers can be attached to different input sources.
- the number of CTI Servers within the system does not have a direct relationship with the number of Voice Servers.
- the telephony events generated by a CTI Server are individually filtered and re-transmitted to the appropriate Voice Server based upon configuration data for the system as a whole (managed by the Central Database Server), which maps the recording locations (extension number, or trunk & channel ID) with the Voice Server name and recording input port (channel).
- a historical call record that tracks each participant within the call.
- Each participant record includes descriptive fields for telephone numbers, agent ID numbers, time ranges, and reason codes for joining and leaving the conversation.
- the call record is transmitted onward to allow the rest of the recording system to process the information accumulated thus far.
- the CTI server Upon the conclusion of the call, the CTI server retains a copy of the call record for a configurable time interval before discarding it from memory. This delay is intended to allow for the arrival of the SMDR data.
- the CTI server Upon receiving SMDR data, the CTI server searches its memory for a call record pertaining to the same logical telephone call that would have been accumulated from previous real-time messages. Matching this information is not a trivial task, since the SMDR link and real-time CTI link do not share a common reference ID number for use by their messages in describing the occurrence of the telephone call. Therefore the software of the preferred embodiment must use other "clues" to guide the matching process, by comparison on a combination of other data fields that exists in common between the SMDR and real-time CTI data.
- These data fields include: (l) the telephone number of the first external party involved in the call; (2) the telephone number of the first internal party involved in the call; (3) the direction of the call (e.g., inbound, outbound); (4) the start time of the call, in hours and minutes; and (5) the duration, in seconds, of the call.
- the matching process is not trivial because the SMDR link gives the starting time of the call only in hours and minutes, whereas the starting time given by the real-time link also includes seconds. It is quite possible that more than one call could be started and stopped within a single minute. This would result in an ambiguous match, if not combined with other search fields. The same argument holds true for each of the other fields upon which a match can be performed. No single field alone will provide an unambiguous matching of the records. Even in combination, it is conceivable (although statistically unlikely) that an ambiguous case could occur: if the same two parties were to call each other twice within the span of a minute, and each call was roughly the same length in seconds.
- the preferred embodiment incorporates a weighted formula that is applied to potential match candidates.
- the formula yields a numerical confidence factor that can be used to select the best apparent match candidate.
- a test is conducted to determine the quality of matching on that data field. This matching quality is rated as a percentage. Certain fields, such as time values, are allowed to vary within a configurable tolerance range, whereas other fields are required to match exactly or not at all.
- the matching quality of a field has been determined, it is multiplied by an importance factor that applies a relative weight to each of the various fields that can be examined during matching.
- the final confidence factor is the summation of these calculations:
- Confidence Factor ⁇ , ((Match Quality), * (Weighting Factor),)
- the tolerance factors e.g., for time value offsets
- the weighting factors are re-configurable.
- the configuration data will define an allowable variance range (plus or minus a certain number of seconds). Values that do not match exactly, but fall within the variance range, are rated with match quality expressed in percentage that is measured by one minus the ratio of the difference from the expected value versus the maximum variance.
- CLID Calling Line Identification
- SMDR records arrive which could possibly match with this call.
- the first record indicates an inbound call received by extension 1234 at 12:26 and lasting 26 seconds.
- the second record indicates an inbound
- Weighting Factors are: 15
- the system will therefore match the CTI events with the second SMDR record.
- the trunk channel information (and any other useful information that can supplement the previously gathered real-time CTI data) is extracted from the SMDR data and added to the call record within the CTI server's data model of telephony activity. Then the updated call record is transmitted onward to allow the rest of the recording system to process it.
- the recording system is able to associate the enhanced logical search information with the physical voice recording, and take whatever actions may have been dependent upon this information, such as selectively recording or discarding the call.
- FIG. 2 is an illustration of the difference between trunk-side and station-side recording at a call center with agents.
- a recording unit can intercept telephone call traffic using either of these two methods.
- the traffic can be intercepted and recorded as it passes between the PBX 100 and the agent telephone sets 230.
- This first method is known as "station-side” recording.
- PSTN Public Switched Telephone Network
- the traffic can be intercepted at its point of entry into the call center before the calls are dispatched by the PBX.
- PSTN Public Switched Telephone Network
- a third type of recording interface is Service Observance 185 (see FIG. 1), which is physically wired in manner like station-side recording, but using separated dedicated lines to a recording input channel rather than being inte ⁇ osed between a PBX and telephone set.
- the Recorder joins into a telephone call as a silent conference participant using the PBX Service Observance feature (originally intended to enable a supervisor to directly monitor an employee's telephone calls upon demand).
- FIG. 3 shows a line-chart that illustrates various parties involved in a complex call.
- A is the customer phone number
- B and C are the agent phone numbers located behind recording channels R20 and R21 respectively (see FIG. 2).
- the call comes in from line A 335 to line B 340.
- a real-time CTI message occurs describing that phone B is ringing, but not yet answered.
- B answers the phone 365 at time tO 310.
- the "NS" at 360 indicates the normal start of a phone call.
- a real-time CTI message occurs describing the start of the call between A and B.
- the telephony model is updated to reflect the fact that the call between the initial 2 participants (A and B) started normally at time tO 310.
- a copy of the call record is then sent onward to the rest of the recording system.
- the call record is retained within the telephony model, associated with device (or line) B.
- B places the call on hold 370 (the "XA” at 370 indicates that the call was transferred away from B; the "XR” at 375 indicates that the transfer was received by HOLD).
- a real time CTI message occurs describing that B placed the call on hold.
- the telephony model is updated to reflect that B transferred the call to HOLD 345 at time tl 315. (This information is accumulated with the information previously gathered at tO 310).
- a copy of the call record is then sent onward to the rest of the recording system.
- the call record is removed from device B within the telephony model, but kept in a list of held calls.
- B returns to the call 380 and conferences in C 355 (the "XA” at 380 indicates that the call was transferred away from HOLD; the "XR” at 382 indicates that the transfer was received by B; the "CA” at 384 indicates that C was added as a conference participant).
- a real-time CTI message occurs describing that B returned to the call and invited C by conferencing.
- the call record is moved within the telephony model from the list of held calls back to device B.
- the telephony model is updated to reflect that HOLD 345 transferred the call 380 back to B at t2 320. (Note that information is accumulated with the information previously gathered at tO 310 and tl 315).
- a copy of the call record is then sent onward to the rest of the recording system.
- the telephony model is updated to reflect that C joined the call 384 as a conference participant at t2. (This information continues to be accumulated with previously gathered information).
- a copy of the call record is then sent onward to the rest of the recording system.
- the call record is retained with both devices B and C within the telephony model.
- a real-time CTI message occurs describing that C dropped out 386 of the call (the "CD" at 386 indicates that C was dropped from the conference).
- the telephony model is updated to reflect that C dropped out of the conference at t3. (This information continues to be accumulated with previously gathered information).
- a copy of the call record is sent onward to the rest of the recording system.
- the call record is removed from device C within the telephony model, but retained with device B.
- a real-time CTI message occurs describing that A terminated the call (The "ND" at 390 indicates that a normal drop of the call occurred; the "OPH” at 395 indicates that the other party hung up).
- the telephony model is updated to reflect that A stopped normally and B stopped because the other party hung up at t4. (This information continues to be accumulated with previously gathered information).
- a copy of the call record is then sent onward to the rest of the recording system.
- the call record is then removed from device B, but kept in a list of completed calls.
- An SMDR message is received which summarizes the call in its entirety. The list of completed calls is searched to find a match, and the appropriate call record is retrieved.
- FIG. 4 shows a schematic block diagram of a preferred embodiment for translating, summarizing and normalizing signals received from both an SMDR link and a Dialogic CT- Connect CTI unit.
- the recording system of the subject system is represented by da VinciTM, a new generation recording system of Dictaphone Co ⁇ .
- Dictaphone's SymphonyTM CTI software can be used, in conjunction with Dictaphone's ProLogTM recording system (the system preceding daVinciTM).
- the translation summarization module of the preferred embodiment illustrated in FIG. 4 will be referred to as CtiCtc.exe.
- the module CtiCtc.exe is itself comprised of a plurality of modules, as shown in FIG. 4.
- a CtiAgentEvent module 448 is comprised of a data structure for agent log-on and log-off messages.
- a CtiAgentStatusFile module 454 manages a file that tracks agents currently logged on.
- a CtiCallEvent module 416 is comprised of a data structure for a call record (i.e., normalized and summarized CTI events).
- a CtiCallState module 418 is comprised of a generic data structure to represent the state of telephony activity at a particular location (extension, hold area, etc.).
- a CtiComMessageEmitter module 476 comprises a layer that converts the stream of CtiCallEvent objects (generated by a CtiCtcAnalyzer 456) into a format that can be sent to other da Vinci system components.
- a CtiCtcAnalyzer module 456 comprises a processing engine which examines CTC and SMDR messages and keeps track of a state machine for the activity on each extension. The CtiCtcAnalayzer module performs normalization of the CTC and SMDR data.
- a CtiCtcDataFile module 412 manages a file of CtiCtcData objects that can be captured or displayed.
- a CtiCtcExtensionlnfo module 442 manages a collection of CtiCtcCallState objects, with one object for each extension.
- a CtiCtcInput module 464 comprises an input source engine that obtains incoming CtiCtcData objects, either from a "live" server or from a playback file.
- a CtiCtcMain module comprises the main() function for CtiCtc.exe. The main() function handles command line and registry parameters, along with other start-up processing.
- a CtiCtcParameters module 472 comprises data structure and program logic for managing the configuration parameters in the Windows NT registry.
- a CtiCtcScanner module 446 comprises a utility module for building a list of all available extensions on a particular telephone switch.
- a CtiCtcStats module 434 comprises a data structure for compiling statistics on the number of CTC, SMDR, and CTI messages.
- a CtiDtpField module (not shown) is used by a
- CtiDtpMessageEmitter module 478 and comprises a data structure for an individual field in the Dictaphone Telephony Protocol ("DTP"), used to communicate with other Symphony CTI system components.
- a CtiDtpMessage module (not shown) is used by a CtiDtpMessageEmitter module 478, and comprises a data structure for a complete message in the DTP to be sent onwards to the Symphony CTI system.
- a CtiDtpMessageEmitter module 478 comprises a layer that converts the stream of CtiCallEvent objects (generated by CtiCtcAnalyzer 456) into a format that can be sent to the Symphony CTI recording platform.
- a CtiDtpSocketSrv module (not shown) manages the TCP/IP connection through which messages for DTP are sent to the Symphony CTI platform.
- a CtiDtpUtility module (not shown) comprises a collection of utility routines that assist in examining and processing DTP messages.
- a CtiExtensionFile module 450 manages the configuration file that lists all available telephone extensions.
- a CtiExtensionlnfo module 440 manages a collection of CtiCallState objects, with one object for each extension.
- a CtiExtensionNumber module 430 comprises an abstraction of an individual extension number as either a numerical or string value, so that changes to this model will not have a global impact in CtiCtc.exe.
- a CtiMessageEmitter module 458 comprises an abstract layer that converts the stream of CtiCallEvent objects (generated by CtiCtcAnalyzer 456) into a format that can be sent to various target platforms, including the da Vinci and SymphonyCTI systems.
- a CtiMessageEmitterParameters module 474 comprises a data structure and program logic for managing configuration parameters that relate only to the message emitter(s).
- a CtiMessageQueue module 462 comprises shared memory for transferring data between threads. As is known to those skilled in the art, a "thread" is a part of a program that can execute independently of other parts.
- a CtiSmdrlnput module 466 comprises an input source engine that obtains incoming CtiSmdrData objects, either from a "live" server or from a playback file.
- a CtiTagNames module 436 comprises a utility module that converts number values to descriptive strings for debugging and tracing pu ⁇ oses.
- a CtiTime module 438 comprises a utility module that converts time values to UTC for internal storage and conditionally prints times in either the UTC or local time zone.
- a CtiTrunkMap module 426 comprises a data structure that describes a mapping between logical trunks and logical trunk groups, into physical trunks and TDM timeslots.
- a CtiTrunkMapFile module 410 manages a configuration file that contains the CtiTrunkMap information.
- the module determines at step 512 that the CTI message indicates that the call has been concluded, at step 520 the module removes the call record from the associated devices. The translation module then adds the call record to the list of recently completed calls at step 528. Completed calls are discarded (step 530) after they get too old (i.e., after a predetermined number of recorded calls, or a given time period after the original recording of the call). Processing then continues again from step 502 by receiving the next incoming message. If at step 512 the call has not been concluded, the completed calls are discarded (step 530) after they get too old. Processing then continues again from step 502 by receiving the next incoming message.
- the call record is updated within the list of recently completed calls.
- the call record is transmitted at step 548 to the rest of the recording system.
- the call record is discarded from the list of recently completed calls. Cpleted call are discarded (step 530) after they get too old. If no matches were found at step 516, the completed calls are discarded (step 530) after they get too old. Processing then continues again from step 502 by receiving 0 the next incoming message.
- the CTI Server can be viewed as a set of logically distinct layers that deal with translating and distributing CTI events.
- CTI events flow from a PBX in its proprietary format to Dialogic CT-Connect middleware 640 another API layer 650 or custom interface layer 660 that each provide partial 5 normalization of the data. This helps to reduce the complexity of the "translation" job, since there are fewer APIs than individual PBX types.
- the CTI Server 710 used in accordance with the present invention is responsible for supplying certain metadata regarding agent events to the System Controller, which is part of the Scheduling & Control Services 130 shown in Figure 1.
- This information which generally includes agent ID, extension number, logon and logoff time, etc., is obtained when available from the various PBXs, ACDs, and turret systems.
- the agent events delivered to the System Controller 130 enable a map to be maintained of the extension number(s) where a real person can be found, at a given date and time. This information enables a browser application to intelligently associate some of the previously recorded calls even if a person was using different telephone sets according to a 'free seating' plan.
- the CTI Server 710 also keeps a local cache of the agent information, so that agent information can be included when sending the telephony events to the Call Record Generator 150.
- the physical layout of the CTI Server used in a specific embodiment is shown in FIG. 8.
- the translation modules are implemented by separate programs, such as CtiCtc.exe 406, which encapsulate the details on converting a specific PBX interface or vendor API layer into a normalized format.
- the distribution module is preferably implemented by a single program, CtiServ.exe 820, which includes the main processing and routing logic for the CTI Server.
- the translation modules of the CTI Server convert proprietary-format CTI information into a normalized format. In accordance with a preferred embodiment , this is done in several layers within the program. The information is first converted by Dialogic 's CT-Connect software into the CTC-API format, and then the conversion to the generic format used by the other components of the recording system is completed by the translation module CtiCtc.exe. Once the data is converted, it is transmitted to the distribution module (CtiServ.exe) by using a distributed communications method such as DCOM.
- Component Object Model is a Microsoft specification that defines the interaction between objects in the Windows environment.
- DCOM Distributed Component Object Model
- MCMQ Microsoft Message Queue
- the translation module and the distribution module of the CTI Server can be located on different machines, if desired. There can be multiple translation modules running in the system — one for each PBX or CTI middleware environment. There can also be different types of translation modules, with one version for each interface or API layer. As depicted in FIG. 8, CtiCtc.exe deals with the Dialogic CT-Connect API, and there are 3 copies of this program running to handle the PBXs. If other types of APIs are used, there would be other programs for these various interfaces. All translation modules contribute data upward to the distribution module in a single, common, normalized format.
- FIG. 9 An example of a version of CtiCtc.exe configured to work with a Lucent Telephony Services interface (and thus called CtiLts.exe instead of CtiCtc.exe) is shown in FIG. 9.
- the modules which are common to both versions of the program are shown in FIG. 9 as shaded gray.
- the unshaded modules represent those portions of the program that necessarily vary between CtiCtc.exe and CtiLts.exe, due to the differing input parameters and data structures used by both systems.
- the distribution module (CtiServ.exe) receives and collects all the CTI events from the various translation modules. Then it puts the events into a single inbound queue 830 for processing by a main control thread 835.
- the main processing thread 855 (WinMain) is deliberately isolated (decoupled) from the inputs and outputs to ensure that delays in transmitting or receiving data will not impact the overall performance of the CTI Server.
- the layer receives a CTI event, and at step 1216 posts the CTI event to the Message Queue 462 (see FIG. 4). If at step 1218 a shutdown is in progress, the connection to the CTI data source is closed at step 1220, and at step 1222 data collection is
- step 1218 If at step 1218 a shutdown is not in progress, the CTI connection remains open (step 1212).
- the call state is posted to the Message Queue, if necessary.
- completed calls are discarded from memory after they age beyond a configurable time limit.
- the "hang-up" routine is called to update the telephony model for held or bumped calls after they age beyond a configurable time limit.
- the data normalization layer checks the inbound message queue at step 1236. If the message
- the message emission process begins with opening a connection to a target platform, such as the da Vinci or SymphonyCTI recording systems at step 1240.
- a target platform such as the da Vinci or SymphonyCTI recording systems
- the 20 message emission layer receives the call state from the message queue 462.
- the call state data is converted into a platform-specific format.
- the message emitter sends the message to the target platform.
- a check is made at step 1252 for whether the inbound message queue is empty. If the inbound message queue is empty, message emission is ended at step 1254. If the inbound message
- the list of participants is cumulative, and information regarding participants is retained for the entire duration of the call even when some participants in the list may have dropped off from the call. If a participant rejoins the call, a new, separate entry will be created to reflect that change within the participant list.
- the following table shows the fields contained within these messages.
- ObjectSpace is a set of C++ class libraries provided by ObjectSpace, Inc., that define useful general-pu ⁇ ose data structures including representations of strings, time values, and collections of objects (such as vector arrays or linked lists). These class libraries are implemented in a way that supports a wide variety of computer operating systems. Those skilled in the art will appreciate that many alternate implementations for such data structures are suitable for this role.
- the CTI Server sends "Agent Event Records” onward to the recording platform's System Controller to convey information when an agent logs on/off at a particular location.
- the following table shows the fields contained within these messages.
- Console Within any given "Agent Event Record", only one of the following three fields will be applicable: Console, Station, or Extension.
- the actual mapping is determined by the LocationType. Unused string fields will be null terminated. Unused number fields are set to zero.
- the CTI server of the preferred embodiment retains a copy of the call record for a configurable time interval before discarding it from memory. This delay allows for the arrival of the SMDR data.
- the call records are organized into a two-tiered hierarchy of calls and participants. Certain data fields that apply globally to the entire call are stored at the upper level. Most data fields, however, apply only to a specific party involved within a call, and are stored at the lower level. Individual participants can have identifying information (such as extension number, agent ID, telephone number via DNIS / ANI / CLID, trunk and channel) along with time-stamps and reason codes for the entry and exit from participation in the telephone call. Reason codes include initial start, transfer, hold, resume, conference add/drop, and hang-up.
- identifying information such as extension number, agent ID, telephone number via DNIS / ANI / CLID, trunk and channel
- Reason codes include initial start, transfer, hold, resume, conference add/drop, and hang-up.
- the currently active call on each telephone set being monitored is maintained within a storage area 1020 of the data model. Also, the data model provides for an open-ended list
- the CTI server of the preferred embodiment obtains a Globally Unique Identifier (GUID), that is generated at the software's request by the underlying Microsoft Windows NT 5 operating system, and uses that GUID to identify the call uniquely within the recording system's memory, online storage database, and offline storage archives.
- GUID Globally Unique Identifier
- the GUID is initially requested at the start of the call. While the call remains active, the CTI server maintains a record of both the call identification number assigned by the PBX, and the GUID assigned to the call by the software of the preferred embodiment.
- the system searches the telephony model to find a matching call record for the PBX-assigned call identification number.
- the CTI server consists of three distinct layers. Each layer actually runs in a separate thread of execution, and communicates with the other layers through shared memory, control semaphores, and message queues.
- the first layer 1110 is responsible for gathering input from the PBX data link(s), and there can actually be several threads running to provide better throughput capacity or to handle multiple diverse input sources (e.g., SMDR and real-time CTI messages). After saving the clock time when a message is received, the first layer 1110 places the message into a queue for subsequent processing by the second "analyzer" layer.
- the second layer 1120 is responsible for updating and maintaining the telephony model within the memory of the CTI server, and for deciding when to send copies of call records onward to the rest of the recording system.
- the call record is placed into a message queue for subsequent processing by a third "message emitter” layer 1130, which is responsible for communications with other components of the overall recording system.
- This separation of layers gives the CTI server the flexibility to process its input and output sources in a de-coupled fashion, so that any delay in one area of communications does not affect the processing of another area.
- the design approach provides a virtual "shock absorber" so that bursts of input traffic, or temporary lag times in communicating with other parts of the recording system, can be tolerated without loss of data or incorrect operation of the system.
- the analyzer layer is of particular interest, since it is responsible for updating and maintaining the data model of telephony activity. Its overall program logic flow is illustrated in FIG. 12 and the subroutine called at step 1230 is shown in further detail by FIG. 13. This program logic is described below.
- step 1324 use the previous state as recording within the telephony model, along with the new state reported in the CTI event, to select the appropriate handler routine at step 1332 from a matrix of choices.
- the handler routine will be one such as those described below.
- step 1340 run the steps of the handler routine. This will commonly include steps to save at step 1342 information from the CTI event into the call record, to update the call-related portion of the Object Status, if necessary (step 1344), to update Participants within the Object Status, if necessary (step 1352), to run additional action methods or handler routines for other affected telephony objects, if necessary (step 1348), and to post Object Status to the message Queue for the Emitter to a target platform (step 1354).
- step 1360 returning to FIG. 12, at step 1232, discard completed calls within the data model of telephony activity, if they have aged beyond a certain re-configurable time limit.
- DialTone save the initial start-time of the call save the original dialed number, if available adjust state based on CTI event Ringln: adjust state based on CTI event time-stamp when ring occurred clear call record set inbound, outbound, internal Answer: adjust state based on CTI event compute total ringing duration fill in call record with calling party & called party generate START message to recording system
- Abort adjust state based on CTI event clear timers & original dialed number
- Hang-Up adjust state based on CTI event update call record to stop all parties indicate which party actually hung up on the call generate STOP message to recording system
- RingOut adjust state based on CTI event time-stamp when ring occurred (i.e., now) clear call record set inbound, outbound, internal compute total ringing duration (i.e., zero) fill in call record with calling party & called party generate START message to recording system
- Hold adjust state based on CTI event stop participant placing the call on hold add new placeholder participant for
- step-by-step description describes the same call scenario as in FIG. 3, but with emphasis on the data model of telephony activity.
- a real-time CTI message occurs describing that phone B is ringing, but not yet answered.
- the telephony model is updated with the time when ringing started (for use later in measuring ring duration) and the call direction. These facts are stored with device B 340. 4. A real-time CTI message occurs describing the start of the call between A 335 and B 340.
- the telephony model is updated to reflect the initial 2 participants (A and B) started normally at tO 310. 7. A copy of the call record is sent onward to the rest of the recording system.
- the call record is retained within the telephony model, associated with device B 340.
- a real time CTI message occurs describing that B 340 placed the call on hold.
- the telephony model is updated to reflect that B 340 transferred the call to HOLD 345 at tl 315. (This information is accumulated with the information previously gathered at tO). 12. A copy of the call record is sent onward to the rest of the recording system.
- the call record is removed from device B 340 within the telephony model, but kept in a list of held calls.
- a real-time CTI message occurs describing that B 350 returned to the call and invited 5 C 355 by conferencing.
- the call record is moved within the telephony model from the list of held calls back to device B 350.
- the telephony model is updated to reflect that HOLD 345 transferred the call back to 10 B 350 at t2 320. (Note that information is accumulated with the information previously gathered at tO and tl).
- a copy of the call record is sent onward to the rest of the recording system.
- the telephony model is updated to reflect that C 355 joined the call as a conference participant at t2 320. (This information continues to be accumulated with previously
- a copy of the call record is sent onward to the rest of the recording system.
- the call record is retained with both devices B 350 and C 355 within the telephony model.
- the telephony model is updated to reflect that C dropped out of the conference at t3. (This information continues to be accumulated with previously gathered information).
- a copy of the call record is sent onward to the rest of the recording system.
- the call record is removed from device C within the telephony model, but retained 25 with device B.
- a real-time CTI message occurs describing that A terminated the call.
- the telephony model is updated to reflect that A stopped normally and B stopped because the other party hung up at t4 330. (This information continues to be
- a copy of the call record is sent onward to the rest of the recording system. 31.
- the call record is removed form device B 350, but kept in a list of completed calls.
- a SMDR message occurs summarizing the call in its entirety.
- the list of completed calls is searched to find a match, and the appropriate call record is retrieved.
- the call record is updated with the trunk channel information from the SMDR message.
- a copy of the call record is sent onward to the rest of the recording system.
- the call record is removed from the list of completed calls.
- FIG. 14 depicts the flow of information within the remainder of the recording system.
- the same enhanced search information SI 1412 is provided by the CTI server to all of the recording units involved in handling a portion of the call. Even if a call is transferred to another telephone set, which is attached to an input channel on a different recorder, the entire call will still remain associated as one entity within the system.
- Each recorder maintains a local copy of the audio sections VI 1416, V2 1420, and V3 1424 that it obtained during the call, along with a complete call record containing search information SI 1412 which contains the two-tiered call and participant model.
- the search information is copied to a central database server 1450, along with references (i.e., logical pointers) to the original audio recordings VR1 1428, VR2 1432, and VR3 1436.
- the search results 1465 will include the complete call record SI 1412.
- the playback software can reassemble the complete audio for the original call, including sections possibly obtained from different physical recording units.
- CALL RECORD GENERATOR The Call Record Generator (CRG) in accordance with the present invention performs the function of combining voice and data into call records. It performs this function at or near real time.
- the CRG when combined with the metadata normalization module CTI Server, makes up a system that can be used in current and future communication recording products.
- the CRG is responsible for collecting data from different sources with respect to portions of a call on various recording input channels, and merging them together into a unified call record.
- One of these sources is the recorder that creates the files containing media.
- Another sources provides metadata describing the when, who, why and where information of a call.
- This call record metadata comprises the start and stop times of a segment within a call, as well as CTI data such as telephone numbers and agent IDs.
- CTI data such as telephone numbers and agent IDs.
- These metadata sources include but are not limited to Telephony switches and Trunked Radio servers.
- the CRG depends upon the CTI Server to normalize data from these sources.
- FIG. 1 illustrates the relationship between the CRG and the rest of the system. Since call records are an essential part of the recording system, there is one CRG dedicated to each recorder and physically located in the same Voice Server. If other system components become inoperable, call record generation will remain functional (albeit at a reduced level).
- the CTI server supplies switch events to the appropriate recorder indicating either the status of calls or providing data for population.
- the CTI server provides, along with call record data, the association between the recorder location (i.e., Voice Server and recording input channel number) and the switch connection point.
- the switch connection point is described as either the extension for extension side recording or the Trunk ID/virtual channel (TDM time slot) for trunk side recording. In addition to this mapping, an agent identification will be supplied for agents currently associated with this call.
- the recorder location, switch identification and corresponding agent are stored in the call record.
- the CRG is designed to work with many different configurations of the disclosed system. These configurations include: systems without CTI Servers; systems with Real-time CTI Servers; systems with non-Real-time CTI Servers; recorders with analog inputs; recorders with digital inputs; recording on the trunk side of the telephony switch; and any combination of CTI Servers, Recorder inputs, and recorder positions mentioned above.
- the CRG must handle event data arriving in different chronological order. In accordance with a preferred embodiment, it accomplishes this by requiring all events to indicate time of occurrence and maintaining a history of them.
- a call record can be created solely from either event sources but when both are present, call records are generated using recorder information together with CTI data.
- VOX Dialogic Co ⁇ oration's digital encoding format for audio samples. This term is also sometimes used to refer voice-activated initiation of recording, a process that conserves storage space since a continuous recording process would include periods of silence. These VOX events mark the beginning of energy activity on a phone line and are terminated by the lack of activity. With this approach, an actual phone call may include several call records. To address this problem, the recorder waits a configurable holdover period while silence is present before terminating an active VOX clip (the term “Recorder” is used interchangeably herein with the term “Voice Server”; both terms refer to the physical recording server). The goal is to concatenate parts of a phone call where gaps of silence exist.
- the solution lies in determining an appropriate holdover time so as to avoid merging audio from the next phone call if it occurs close to the end of the last call.
- the next level of operation is where the recorder hardware can detect telephony signaling such as off hook and on hook.
- the CRG has no CTI input from the switch and is recording solely on events from the recorder controller, but these events mark the beginning and end of a phone call (off hook and on hook).
- the resultant call record reflects a phone call in entirety but lacks much descriptive data that accompanies switch data.
- the highest level of operation involves the use of a CTI Server.
- the CRG receives recorder events as well as CTI events. Since CTI events give the CRG a description of the entire phone call, information obtained from them drive the creation of call records. Recorder data describing audio events are absorbed into the CTI call record whenever audio and CTI times overlap. With CTI events driving call record generation, non- audio based call records can be created.
- CTI data occurs by comparing ranges of time indicated. For example, a person whose telephone extension is being recorded is involved in a phone call for a given period of time. The recorder events indicating that audio was recording on the same extension during the same time period are associated with the CTI metadata for that phone call. Since the data from the CTI Server may arrive before or after the corresponding recorder events, the CRG maintains an independent history for each type of data. For the case where CTI events arrive before the recorder events, the CTI events are added to the CTI history list. When the corresponding recorder events arrive, the CTI history list is swept for matching time ranges and associations are made when they occur. For the case where recorder events arrive before the CTI events, the recorder events are added to the recorder history list. When the corresponding CTI events arrive, the recorder history list is swept for matching time ranges and associations are made when they occur.
- Previous recording systems stored voice data and metadata in separate locations.
- a significant disadvantage to this approach is that it is left up to the other software subsystems to combine the information when required.
- This approach makes the work of other system features, such as playback and archiving to offline storage, more complicated and prone to error.
- By performing this "early binding" of the audio and CTI data in accordance with the present invention such problems are avoided and the above desirable features are therefore much simpler to implement in a correct, robust fashion.
- the playback mechanism When attempting to playback media for a given call record, the playback mechanism must figure out where the audio for the call record exists and when determined, retrieve and locate the start time inside this media.
- the CRG places this media metadata in related tables, thus informing the playback mechanism what files are associated, their location, and what time ranges inside the file are available for playback.
- CRG used in accordance with this invention assists with archiving by allowing both call record metadata and the media files to be stored on the same offline media.
- Current versions of recording systems store call record metadata and media files on separate offline media making restore operations more complicated.
- the CRG accesses media files associated with a call record through the use of media segmentation.
- a media segment includes, in addition to a media filename and location, a start time and duration inside the media file.
- Media segmentation is necessary when creating CTI based call records since a call record may involve many recording locations throughout the life of the call.
- the specified time range isolates a portion of the media file that can be accessed through this call record. This feature is very important when there are many call records located in one media file.
- a user attempting to play back media of a call record, to which he has the permission for access may or may not have permission to play back other call records sharing the same physical file.
- the Call Record Generator is responsible for merging CTI search data and a multitude of voice recording segments together into a single manageable unit of data.
- This software includes a flexible receiver algorithm to allow voice and search data to arrive in either order, without requiring one to precede the other.
- the call record can be managed as a single entity, which greatly simplifies and reduces the work necessary to perform search, retrieval, and archival operations. This approach also offers a more natural and flexible framework for controlling security access to the recordings, on an individual call basis (or even on selected portions within a call).
- a recording unit operating with only voice signaling to guide the creation of its call records could make a number of fragmented audio segments.
- the recording unit is supplied with CTI search data giving a complete history of the call's lifetime, and when it is designed to merge the CTI search data and audio segments into a combined unit of VoicedataTM, the results can simplify and reduce the work necessary for a user to obtain a desired call from the system.
- Several audio segments can be grouped together, and can be understood by the system as being part of the same logical telephone call. It is also possible that a single audio segment was recorded, even though parts belong to separate telephone calls, because the delay between stopping the first call and starting the second call was very brief.
- the system can use this information to recognize when an audio segment should be split and divided between two logically distinct calls.
- the pu ⁇ ose of the Call Record Generator is to collect information describing multimedia data and store it in a central location.
- the CRG produces Master Call Records (MCRs) that encapsulate information describing a phone call as well as the location multimedia that is associated with it.
- MCRs Master Call Records
- This description data comes from a multitude of sources including but not limited to a Voice Server and CTI Server.
- the design of the system envisions that there will be a number of possible input sources for audio recording.
- the CTI information is passed from the translation modules to a message router. From that point, copies of the information are sent to the scheduling and control services and to the CRG for the appropriate recorder(s).
- the scheduling and control services are responsible for starting and stopping the audio recorder, according to pre-defined rules that are dependent upon time and CTI information.
- the CRG is responsible for merging the audio recording with the CTI information to determine the temporal boundaries of the call and prepare the Voicedata for storage.
- the user workstation typically searches and retrieves records from the Voicedata storage, and then obtains audio for playback directly from each recorder's private storage area.
- the user workstation can also be used to monitor "live" conversations by communicating directly with the recorder.
- the user workstation can also control the audio recorder indirectly by manipulating the rules used by the scheduling and control services.
- the user workstation has software that is configured to display a graphical user interface (GUI) such as that shown in FIG. 16.
- GUI graphical user interface
- the GUI in FIG. 16 uses the information compiled in the Master Call Record to generate a graphical representation 1610 of the call, as well as displaying the call record information in alphanumeric form in a table 1620. Further, when the call is played back, the displayed segments in the graphical representation are highlighted to indicate the portion of the call being played back. For example, in FIG. 16, if the entire call is played back, when the portion of the call that occurred between 6:20:08 AM and 6:55:31 AM is played back the bars 1632, 1634, and 1636 are highlighted from left to right as the call is played back.
- bar 1634 is fully highlighted, and bars 1632 and 1636 are highlighted starting from the left and extending to those points on bars 1632 and 1636 that are directly above and below the right-hand endpoint of bar 1634.
- the bar 1638 begins to be highlighted starting at the left endpoint.
- the bar 1636 is fully highlighted. At that point, the bars 1632 and 1636 are highlighted from their left-hand endpoints and extending to points directly above the right-hand endpoint of bar 1638.
- playback of a potion of a call can be activated directly from the graphical view by mouse-clicking or by selecting from a pop-up menu; circular "pie-charts" show the percentage of time for each party involved during the lifetime of the call; an animated vertical line scrolls along to indicate the progression of time when the call whose graph is being displayed is played back; and miniature pictorial icons are shown within the graphs to indicate start/stop reasons, type of participant, etc. All of these embodiments are enabled by the data contained in the Master Call Record.
- the preferred embodiment of the system uses data abstraction to isolate the internal details of certain structures to those components which need to operate directly upon them. Information is organized by the collectors (or producers) of that data, into a digested form that is more easily usable by the applications which need to retrieve and process the data.
- the CTI translation modules supply normalized records to the rest of the system in a common shared format, rather than exposing the details of various different CTI links.
- the system data model is call-centric, containing a detailed cumulative ("cradle to grave") history, rather than event-centric, which would place the burden of work on the receiving applications.
- agent information is session-oriented rather than event- oriented.
- the system architecture is designed to avoid any interference with the normal operation of a call center environment.
- the CTI translation modules are focused exclusively on collecting and normalizing information that is to be supplied to the rest of the system.
- Liability recording systems, and quality monitoring systems that use "service observance” techniques do not require any active call control on the CTI links.
- Only the technique known as "dynamic channel allocation” requires active call control through CTI links to establish a "conference” or "bridge” session between the audio recorder and the telephone call participants. When active control is required to implement such a feature, it can be implemented through a new logically separate task, without significantly affecting the rest of the system design. For customers that have existing CTI infrastructure and applications, the system will not interfere with their existing operations.
- the CRG is responsible for collecting data from the CTI Server, creating CTI-based call records, and attempting to match those records with existing recorded audio data. If the CRG receives CTI information indicating that audio data for the same call resides on two or more recorders (for example, due to a transfer), records will be generated for each portion with a common call record ID. This ID can later be used to query for all of the pieces (“segments") comprising the complete call. Each segment will identify the recorder that contains that piece of the call.
- PBServer Playback server
- the machine name of the particular Voice Server which holds an audio segment is stored by the CRG in the call record table within the Voicedata storage, and is passed into the player module after being extracted by a User Workstation's sub-component known as the call record browser.
- a call record playback request is then submitted, which causes the PBServer to query for a specific call record's audio files located on that physical machine, open them, and prepare to stream the audio upon buffer requests back to the client software (the player module) on the User Workstation.
- a series of requests is then issued from the client, each of which will obtain just enough audio to play to a waveOut device while maintaining a safety net of extra audio in case of network delays.
- the PBServer Upon a request to "move" within the scope of a call record, the PBServer repositions its lead pointer to the desired location and then begins passing buffers from that point. This series of Request and Move commands continues until the user chooses to end the session by shutting down the client-side audio player.
- the term "Call Control” refers to the part of the metadata concerning the creation and termination of call records.
- Media refers to the actual data that is being recorded. This term is used interchangeably with audio since the primary design of the CRG is to support audio recording. However, the CRG could apply to any data being
- the term “Metadata” refers to informational data associated with multimedia data describing its contents.
- the term “Call Participant” refers to an entity that is involved in a phone call. There are at least two participants involved in a call; namely the calling and called parties. Participants can consist of people, VRUs, or placeholders for parties being placed on hold.
- the term “Recorder 0 Participant” refers to a participant in the MCRs Participant list who is located at the same connection point on the Switch to which the recorder input channel is connected. In accordance with the present invention, there can be more than one Recorder Participant associated with a call record since participants can enter and leave many times in a call.
- a "VOX-based Master Call Record contains information contributed by events from the Recorder alone, in the absence of data from a CTI Server.
- a VRU is a Voice Response Unit: an automated system that prompts calling parties for information and forwards them to the appropriate handler. 0
- a recorder channel becomes involved in a phone call, it will be associated with all subsequent CTI events pertaining to the same call. This occurs even if the recorder location is no longer involved in the call.
- FIG. 16A shows the subject system containing a CTI Server 710 and Recorder 1640.
- a recorder channel 0 1650 is attached to the extension side to extension 0001 1622.
- 25 phone call is initiated from the outside by some agent "A” 1602 and initially connects to agent “B” 1608 at extension 0001 1622.
- Agent "B” 1608 places “A” 1602 on hold and transfers him to Agent “C” 1612 at extension 0002 1630.
- the CRG recording extension 0001 1622 would receive all update messages with regard to this call since he/she participated in the call. Descriptive information from the CTI Server 710 would look like that in table 1600 in FIG.
- Audio clips recorded while agent "B” 1608 was involved in the call are recorded in a VOX based call record as shown in FIG. 17.
- the three media files created from the conversation may overlap with the recorder participant (agent "B").
- audio data information from the VOX call record is absorbed into the CTI MCR for the times the recorder participant is involved (see the results after the sweep of the VOX and CTI history lists). For this call record, audio recorded between times t, and t 4 is absorbed. Any remaining audio is left in the VOX MCR for possible abso ⁇ tion in other CTI MCRs adjacent in time to this one.
- extension 0001 in this call record is different from the other participants in that it is associated with the same switch point as the recorder channel, he/she is referred to as the Recorder Participant. From time t4 and on when the Record Participant is no longer involved in the call, CTI events are still received for that channel. This allows the system to supply information about the entire phone call involving extension 0001 that may be of interest to the customer.
- the CRG Since the CRG must be prepared to handle messages from different components arriving in any order, it is designed to collect information in separate structures. Depending upon the operating mode of the CRG channel, call records are created from information collected in one or more of these repositories. The name given for these structures is Master Call Record (MCR).
- MCR Master Call Record
- the major components of the preferred embodiment contributing information for call records are the Recorder and the CTI Server.
- other multimedia or screen image data may be provided to the CRG in order to be merged with descriptive metadata.
- Recorder events are assembled into VOX MCRs identified by a unique sequence number. Individual events contain a sequence number identifying a specific structure to update (or create). For example, a recorder event would be used to indicate the beginning of a new audio segment. While that segment is active, other messages containing the same sequence number are used to add metadata to the audio segment.
- update events include, without limitation: DTMF digit data; agent association information; change of audio filenames holding future audio data; selective record control; and ANI, ALI, DNIS information.
- DTMF Dual Tone Multi-Frequency and refers to sounds emitted when a key is pressed on a telephone's touch-tone keypad
- ALI Automatic Location Identification
- a disconnect message identifies the end of an audio segment.
- CTI MCRs Events received from the CTI Server are accumulated in CTI MCRs. Each event received from the CTI server contains a unique identifier. Events containing the same unique identifier are associated with the same CTI MCR. If any VOX MCR contains audio data that overlaps in time with Recorder Participants in a CTI MCR, then that audio data is transferred to the CTI MCR. If the abso ⁇ tion process causes all audio metadata for a VOX MCR to be consumed, the VOX MCR is deleted from the VOX list. Therefore, call records generated on the same channel will never have overlapping audio data. VOX MCRs containing leftover audio not absorbed by CTI MCRs are either be saved into the central database if of significant duration or discarded.
- VOX MCRs drive call record creation in the system. Otherwise, the CTI MCRs drive call record creation in the system.
- the VOX and CTI MCR structures are maintained in two separate lists for each recording input channel. These are the VOX History List and CTI History List respectively. These lists represent a history of call activity sorted chronologically. The depth of the history list is driven by a configurable time parameter indicating the amount of history that should be maintained. By maintaining a history, the CRG tolerates events received in any order as long as received within the time boundaries of the history list.
- Some CTI Servers obtain data from SMDR type switches which report entire phone calls at the end of the call with a summary message. Maintaining a history buffer for VOX MCRs allows us to hold onto audio data for a period of time to allow later CTI summary messages to consume (absorb) the associated audio.
- the MCR has status fields associated with them indicating its current state.
- a recording input channel receives a CTI event, it may indicate that a participant connected at the same telephony switch location as the recorder (Recorder Participant) is active in the call.
- the MCR is considered active as long as there is a Recorder Participant still active in the call. During this period, any new audio arriving on this channel is associated with the MCR.
- the MCR becomes inactive. Since any Recorder Participant can become involved in the conversation at any given time through transfers or conferences, the MCR can transition into and out of active state many times throughout the phone call.
- Another field in the MCR indicates the overall status of the call. This flag, called m bComplete, indicates when the phone call is over. An MCR is considered incomplete as long as there is at least one participant still active in the call. When there are no participants active in a MCR it is considered to be complete. Therefore, calls created in real-time will start as incomplete and at some point transition into completed state.
- a Closed Time variable is set to the current time. This time is used in maintenance of the History List. A closed MCR is allowed to stay in the History list for a configurable amount of time before it is deleted. During this window of time, events arriving out of timely order are allowed to update the MCR.
- the MCR is updated in the local database, marked complete, and deleted from the History List.
- the CRG starts, it initializes, for each recording input channel, a location which identifies where it is attached to the telephony switch.
- Each recorder location contains status fields describing the state of the switch and CTI server involved. These fields are m_SwitchStatus and m_MetadataServerStatus respectively and are set to "down" state until an event is received that indicates otherwise.
- m_SwitchStatus and m_MetadataServerStatus respectively and are set to "down" state until an event is received that indicates otherwise.
- all associated recorder locations are updated with the new state value. Any changes in operation are processed upon receipt of the next event for the channel.
- m_ExternMetaDataSource is set to zero when a record channel is to be driven by recorder events only. It is set to non- zero when external events are allowed to generate MCRs.
- the CRG is able to react to a variety of situations that may arise. For example, when the CRG first initializes and a record channel is configured to receive CTI input, how are call records generated if the CTI server is not running? What if the CTI Server is running but the communication path to the recorder is down? The CRG must also be able to react to external parts of the system, that it normally relies on for input, being temporarily unavailable for periods of time. In accordance with a preferred embodiment, the CRG handles these situations by operating in different modes: Initial, Degraded, and Normal. These modes are applied individually to each channel in the recorder.
- VOX MCRs are created from these recorder events and are stored in the VOX History List. When VOX MCRs are completed, they are made persistent in the Local Data Store.
- the CRG system will remain in this mode until all of the following conditions occur: (1) the CTI server becomes available; (2) the switch being recorded by this channel becomes available; and (3) a configuration option for the channel indicates it is to be driven from an online CTI server and switch.
- Degraded Mode If a record channel is configured to be driven from a CTI source, only CTI MCRs are entered into the database. These CTI MCRs absorb any recorder metadata that intersects with the time ranges of the CTI events. No VOX MCRs are made persistent. If, however, the CRG detects that the CTI Server, switch, or associated communication paths are down, the channel enters Degraded mode. This mode is similar to Initial mode in that VOX MCRs are made persistent when completed. Any CTI MCRs that were left open at the time the CTI Server went down are closed and updated for the last time. The recorder channel will remain in this state until the three conditions indicated in "Initial Mode" are met. Only then will the recorder channel transition into Normal mode.
- MCRs are created whenever a VOX or CTI connect event is received and stored in the appropriate list.
- the CTI History List is swept to see if audio metadata can be absorbed by a matching MCR. Any remaining audio data is placed in a VOX MCR.
- the list of VOX MCRs is swept to see if audio metadata can be absorbed.
- CTI MCRs are made persistent to the Local Datastore when first created, upon significant update events, and when completed.
- VOX MCRs are not made persistent to the Local Datastore as they should be completely absorbed by CTI MCRs. There is a configuration parameter that can enable leftover VOX MCRs to be made persistent when they are removed from the VOX MCR history list.
- the CRG will still create and maintain MCRs in the VOX list and force MCR closure on open CTI MCRs as they pass out of the CTI history buffer.
- the sweeping action of audio metadata among incomplete CTI MCRs will cease, preventing all future audio data from being absorbed by it.
- VOX MCRs are made persistent in the database when they leave the history buffer.
- Trunked Radio Mode In an alternate embodiment of the subject invention, fields in the call record structure are added to support trunking radio. Information contributing to these fields may be obtained from communications with a Motorola SmartZone system. This system uses the Air Traffic Information Access (ATLA) protocol to communicate metadata related to radio activity.
- ATLA Air Traffic Information Access
- the embodiment has a trunking radio server similar to the CTI server that provides an interface between the SmartZone system and the recorders of the preferred system. This server provides the normalization of data and distribution to the correct recorder. There are currently two modes of operation of the Motorola trunking radio system that are discussed below.
- Message Trunking In this mode, when a radio is keyed, it is assigned a particular frequency to communicate on. When the radio is de-keyed, a message timeout timer (2-6 seconds) is started. If another radio in the talk group keys up during this time, the controller uses the same frequency for transmission and resets the timer. The conversation will remain on this frequency until the timer is allowed to expire. During this time, all events that are reported with respect to this conversation will have the same call number associated with them. Therefore, the concept of CTI based call records with many participants has been applied to Message Trunking.
- Virtual CRG MCRs can exist in the subject system's database that have no audio associated with them. These non-audio MCRs can be created due to different features of the subject system. Some customers may require that all CTI data coming from their switch be saved even though they are not recording all extensions or trunk lines. By creating records from the CTI data alone, in the absence of recorded audio, this mode of operation can provide the customer with useful information for statistical analysis or charting pu ⁇ oses. Likewise, records created based upon CTI data alone may provide a useful audit trail to verify the occurrence of certain telephone calls, analyze traffic patterns, or to perform other types of "data mining" operations. In that case, a CRG is associated with the CTI Server mechanism to receive all CTI events that are not matched to a specific recorder. These CTI MCRs are made persistent to the Central Database upon call completion.
- Call record start and stop events originate from two independent sources: the Recorder and the CTI server.
- the CRG must perform some method of merging events from these two sources in such a way that the resultant call record contains the best information available.
- CTI server events are advantageous in that they provide more information than the recorder and can also accurately determine a call record boundary.
- MCR The structuring of call records is weighed towards trunk side recording with the services of the CTI server driving call record creation. This type of configuration enables the system to summarize phone calls in the most effective manner. The manner in which the structure of the MCR designed to achieve this goal is discussed below.
- the version number is used to indicate the structure of data contained within the call record.
- changes to call record structures will be performed in an additive nature. That is, current members of the call record will not change in position, size, or meaning.
- Each call record will contain a list to store participant information. There will be at least two participants in a call record; the calling and called parties. Any additional connections that are conferenced in or transferred to are appended to the end of this list. Only one active NOX and CTI based Master Call Record is allowed per recording input channel at any given time.
- FIG. 18 shows the processing threads and data structures that comprise the CRG module in a preferred embodiment.
- Event Processing when the CRG is created and initialized, three threads are created. These threads are the CRG Event Processor thread 1810, Facade thread (The terms “facade,” “facade,” and “fascade” are used interchangeably in this disclosure) 1812 and Local Data Store thread 1816. Additionally, three message queues are created and are known as the Recorder 1824, Facade 1832, and Data Store 1844 queues, respectively. These queues enable the processing of various input messages in a de-coupled fashion within the CRG, so that any delay in one area of communications does not affect the processing of another area. Each thread is described below. Event Processor Thread: the Event Processor is the primary thread of the CRG module.
- the primary purpose of the Local Data Store thread 1816 is to take internal Master Call Record (MCR) structures and translate their contents into structures compatible with database technologies, such as Microsoft SQL Server, or comparable types of storage means. These resultant structures are stored within the database in order to make the call record persistent.
- MCR Master Call Record
- the following paragraphs define the types of events the CRG is designed to accept and process. These events may cause the CRG to initialize, process metadata into call records, or prepare the system for shutdown.
- the Master Controller (a sub-component of the present system's Scheduling &
- the Master Controller notifies the CRG of system related changes such as configuration changes, CTI server status and system shutdown events.
- the CRG changes its behavior based upon events received from the Master Controller.
- the CRG supports two event messages that inform it of status changes that are needed to either update its memory resident configuration information or change its mode of operation. These methods are CtiStatus and AgentExtensionStatus. Each method is described in the following paragraphs.
- Pause Event This method suspends all threads of the CRG.
- Resume Event This method is called after the Pause command to enable all CRG threads to continue processing.
- Ping Event This method is used by client applications to test the connection to the CRG. The method simply returns a positive acknowledgment to let the client know that the CRG is still running.
- CtiStatus Event This event informs the CRG of the operational status of the CTI server that is providing it with telephony metadata needed for CTI call record generation.
- the Scheduler component of the subject system is responsible for maintaining a heartbeat with the CTI server to detect when connection has been lost. Any changes in CTI server status result in a CtiStatus message directed at the CRG.
- This message contains one parameter that indicates the new state of the CTI Server. If the parameter indicates that a CTI Server has become operational, recording input channels associated with the CTI Server change from "Degraded" mode of operation of "Normal” mode. If the parameter indicates that the CTI Server is not operational, recording input channels associated with the CTI Server change from "Normal" mode of operation to "Degraded”mode.
- Call Record Events When a call record event is received, the message is interpreted to determine which recording input channel may be affected. Any filtering necessary on a per channel basis is performed at this stage. Call record events are then dispatched to the appropriate Call Record Channel Manager. There is a separate call record channel manager, which is a software sub-component of the CRG, for each recording input channel in a Voice Server. There are three messages that directly contribute to the creation and completion of call records. One comes from the CTI Server in the form of a CTI Event. The other two originate from the recorder and are the VoxSummary and VoxDisconnect messages. Each message is described in detail below.
- the CTI Event is a message originating from the CTI Server software module that processes the information received from the telephone switch.
- the message details each participant involved with the phone call as well as information global to the call such as ring duration and DTMF codes.
- a CTI event message is sent to the CRG whenever a change in participant status occurs as well as when new ones enter the call.
- the messages are cumulative in that all information of the previous messages is contained in the new one with any additions included. This makes for a more robust system in cases where one of the messages is lost.
- the second mode is used to indicate a history of audio activity.
- the VOX Summary start and end times reflect the period of time covered by all accompanying media files.
- the media files also have there respective start and end times filled in. This message is complete and thus requires no follow up messages.
- the VOXSummary message is shown below.
- the VOX Disconnect Event is a message originating from the recorder associated with this CRG. It is used to terminate a VOX segment that has been started by a real-time VOXSummary message.
- the VOXDisconnect message is shown below.
- Correction Events exist to remove a previous alteration to a call record after it has already been populated.
- One reason for such an event is to support selective record. An audio file that cannot be recorded due to customer or legal reasons might need to be removed from the call record or the entire call record might need to be deleted. The VOX event for a filename might have already been processed into a call record before the selective record mechanism has determined it not to be recorded.
- Selective Record is an important feature of the subject system, imposed by customer requirements. If the customer does not want certain participants recorded when they become involved in a recorded call, the CRG must exclude any audio associated with the call record for that participants' time of involvement.
- the CTI Event message is routed through the Scheduler, and is altered by the Scheduler to indicate which participants re recorder participants as well as which ones are selective record participants. Recorder participants trigger the CRG to sweep any audio from VOX MCRs that overlap in time. When the CRG detects an overlap between recorder participant and selective record participant times, the audio that is swept into the CTI MCR for this overlap period is discarded. This causes the audio to be removed from both VOX and CTI MCRs, which prevents any chance of the audio being made available for playback or archive.
- Selective Record Event is an event originating from the Scheduler. It identifies either a participant that is not to be recorded or that an entire call record should not be recorded. In one embodiment the system is capable of handling recording exceptions based upon information obtained from the CTI data. Criteria for selective record processing are discussed below.
- Selective Record feature can take on two meanings. In one instance, a customer may want to record all telephony events except for ones that meet specific criteria. In a second instance, a customer may only want to record calls that meet certain criteria.
- this decision process is located in the Master Controller, a subcomponent of the subject system's Scheduling & Control Services. Suggested reasons for not recording all or parts of a call are based upon the following examples of CTI event data.
- MC Controller
- CRG creates new call record based upon VOX event.
- the CTI server sends call events to CRG and MC.
- CRG associates CTI event data with VOX based call record.
- MC checks for selective record triggers based upon criteria indicated above. If a criterion is met, a Selective Record (exclusion) command is sent to both Recorder and CRG indicating the start of the selective record interval.
- Recorder deletes audio indicated in selective record message and continues to suppress recording until instructed otherwise.
- CRG alters the call record to eliminate details of participant or deletes the call record.
- the CTI Server Upon completion of the call, the CTI Server sends call events to the CRG and MC. 10. MC checks for selective record triggers based upon criteria indicated above. If a criterion is met, a selective record (exclusion) is sent to the Recorder indicating the end of the selective record interval. 11. The Recorder resumes its normal mode of audio recording.
- the CTI server sends call events to CRG and MC.
- CRG creates MCR and populates with events. Since default is set not to record, the flag m bDontArchive is set to prevent the local data store from writing it to the database.
- MC checks for selective record triggers based upon criteria indicated above. If a criterion is met, a Selective Record (inclusion) command is sent to both Recorder and CRG indicating the start of the selective record interval.
- CRG sets m_bDontArchive to false and immediately instructs local data store to archive.
- Recorder detects presence of audio and records to audio buffer. 4. Recorder sends history of VOX events to CRG in a VoxSummary message.
- CRG creates new call record based upon VOX event.
- CRG associates CTI event data with VOX based call record.
- the CTI Server Upon completion of the call, the CTI Server sends call events to the CRG and MC.
- MC checks for selective record triggers based upon criteria indicated above. If a criterion is met, a selective record (inclusion) command is sent to the Recorder indicating the end of the selective record interval.
- the Recorder resumes its normal mode of suppressing the audio recording.
- the MC needs to inform the recorder when to start a selective record interval and when to stop.
- the boolean bRecordAudio signifies what action should be taken during this interval.
- the Recorder's selective record command informs the recorder of the interval start.
- the End time is most likely not known at this point so it is set to some invalid value in order to indicate that audio should be recorded (or suppressed) for an indefinite period until a subsequent command is received.
- the Recorder's selective record command informs the recorder of the interval end.
- the End time indicates when the selective record interval is complete. The recorder returns to its normal recording mode based upon its original configuration. Any selected audio committed to file needs to be removed from the file and replaced with a silence entry for that period.
- the CRG will mark the call record such that it is removed from the database if it has already been written or not logged in the first place. If selective record affects a specific participant, the call record can either be left unmodified (since the recorder has already handled deletion of audio) or the participant can be overwritten to remove his/her details.
- the system configuration can be adjusted so that the CRG will operate in either fashion, depending on whether removing the audio alone is sufficient for the desired application of the system, or if the metadata must also be removed to eliminate the records of telephone numbers dialed, etc.
- the CRG is implemented as an in- process COM DLL that is associated with the Audio Recorder process, and therefore these two components reside together upon the Voice Server.
- COM is Common Object
- DLL Dynamic Link Library
- the Audio Recorder process is responsible for creating the CRG COM object as well as starting and stopping the CRG subsystem.
- the Data Store module that interfaces with the CRG is a statically linked DLL.
- FIG. 19 illustrates the class diagram of the Call Record Generator.
- the CRG module is itself comprised of a plurality of modules, as shown in the figure, and explained below.
- CallRecordEvent Processor - the CallRecordEventProcessor class 1912 is the main class of the CRG. It is instantiated during the Initialize method call of the CRG interface. It is responsible for allocating the rest of the CRG objects. On instantiation, it acquires the channel count for the recorder (currently limited to 128) and instantiates a group a classes for each recording input channel. These classes include a CallRecordChannelManager 1916 and RecorderLocation 1920 for each channel. The CallRecordEventProcessor 1912 creates the Recorder 1924 and Facade 1928 Event input queues. Reading and processing of configuration information from the subject system's database takes place in the CallRecordEventProcessor 1912. Events received that cause a change in configuration are processed there.
- CallRecordChannelManager This class manages the call records for a specific recording input channel. It is responsible for creating, populating, and closing call records with event information received from the CRG event processor. If event information is deemed as significant, the CallRecordChannelManager 1916 will send an event to the DataStoreEventQueue 1932 in order for the update to be reflected in the local data store.
- MasterCallRecord - This class 1936 holds information that is global to an entire call. Global information includes identifiers for the call record, the start and stop times of the entire call, the recorder location with respect to the switch, and flags indicating the call record status. It also contains a list of the participants within a call, based upon information supplied by CTI events. It acts as a centralized point of control for merging call record information for a given telephone call.
- VoxCallRecord - This class 1940 is a superclass of the MasterCallRecord class 1936.
- RecorderLocation - This class 1920 holds the information relating a logical device on a telephony switch with a specific Voice Server and recording input channel.
- the following table indicates configuration information needed by the CRG at runtime.
- the system of the present invention taps into activity on a PBX (Private Branch Exchange) by intercepting audio on either the trunk or extension side of a phone call.
- PBX Primary Branch Exchange
- the tapped audio is then redirected as input to a channel on a DSP (Digital Signal Processor) based voice processing board, which in turn is digitized and stored into program-addressable buffers.
- DSP Digital Signal Processor
- the recorded audio is then combined with descriptive information ("metadata") obtained through a Computer Telephony Integration (CTI) communications link with the PBX and stored as a single manageable unit (“Voicedata”) to facilitate its subsequent search and retrieval.
- CTI Computer Telephony Integration
- the preferred embodiment leverages Computer Telephony Integration, to supplement the recorded audio data.
- CTI is provided through a data link from specific telephone switching equipment located at the customer site, which is then input to the recording system's CTI Server. Supplied data includes such items as telephone numbers of involved parties, caller ID/ ANI information, DNIS information, and agent ID numbers.
- the CTI Server performs the task of analyzing and reorganizing data from both the real-time and SMDR (asynchronous) links, and passing the results onwards to the remainder of the recording system for further processing.
- a module called the "Call Record Generator,” or CRG, discussed above, is then responsible for collecting data from the CTI Server, creating 'master call records' and attempting to match those records with existing recorded audio data. If the CRG receives CTI information indicating that audio data recorded on two Voice Servers is related (for example, due to a transferred call), records will be generated for each portion with a common call record ID. This ID can later be used to query for all the pieces (or “segments") comprising the complete call. In addition, each segment will indicate the Voice Server which contains that piece of the call.
- the User Workstation's player module connects to a program located on a Voice Server called the Playback Server, or PBServer.
- the machine name of the particular Voice Server with which a communications session should be established stored by the CRG in the call record table of the Voicedata storage module, is passed into the player module after being extracted by the User Workstation's call record browser.
- a call record playback request is then submitted, which causes the PBServer to query for a specific call record's audio files located on that physical machine, open them, and prepare to stream the audio upon buffer requests back to the client. If successful, a series of requests is then issued from the client, each of which will obtain just enough audio to play to a waveOut device while maintaining a safety net of extra audio in case of network delays.
- the PBServer Upon a request to "Move" within the scope of a call record, the PBServer will reposition its read pointer to the desired location and then begin passing back buffers from that point. This series of Request and Move commands will continue until the user chooses to end the session by shutting down the client-side audio player.
- the call When a call is transferred between locations, it is possible that the call may span multiple Voice Servers, since the extensions or trunks involved may be monitored by different recorders. If this is the case, the audio data is spread out between playback servers, and it must be properly pieced back together to reconstruct the complete call for a playback client.
- the Stream Control Manager (SCM) used in accordance with a preferred embodiment is the result of addressing the issues referred to in the second solution discussed above.
- the solution was to simply move the "funneling" module from one central server to the client side. In this way, servers are still providing the actual requested data, but it becomes the client side's responsibility to bring the data together. Yet the SCM remains a separate, COM-based module so encapsulation is still maintained (a client application is not hard-wired directly into the SCM code).
- the process of stream management begins when the SCM is sent a list of segments which comprise the entire call.
- Each segment includes the machine name of the Voice Server, the segment's start time, duration, channel ID, and an event callback routine provided by the client which serves as a destination for the final organized data.
- the SCM proceeds to try connecting to all servers required to play back this call.
- the connection if successfully established, is associated with its respective segment via a pointer in the segment entry.
- the connection is also added to an array so that if a subsequent segment's server is the same as an earlier segment, the connection can be reused. This may occur if a call transfers away to a line monitored by a second recorder and is later transferred back again to the original line. If the process cannot complete successfully (i.e., if a Voice Server is malfunctioning), playback is aborted to avoid skipping over any necessary data.
- the SCM goes through its list of segments and for each, handshakes with its server through a series of function calls.
- the SCM informs each playback server of the desired segment to stream back by providing its start time, duration, channel ID using the parameter data that was passed in earlier.
- the entire initialization and thus playback is aborted.
- every server should have loaded all the audio files associated with their portion of the entire data stream. Each is now ready for audio buffer requests.
- the SCM then waits for a client to execute a "StartStream" call. In a graphical interface, this would occur, for example, when a user hits a Play button or begins a Save operation. Once this function is called, a separate thread spawns which will handle the entire process.
- the current play position is checked to see which segment to begin playing on (a Move operation, explained below, controls the manual repositioning of this value). This is determined by looping through all of the segments, adding each segment's duration to a running total. When the current segment's duration added to the total exceeds the play position, that is the segment which contains the current play position.
- a loop begins which starts from the previously determined segment and proceeds through the rest of the segment vector. For each segment, requests are formed for a predetermined buffer size and sent to the associated server. Once a buffer is returned, based on a flag configurable from the client, the SCM will either directly send back this data or "slice" it for the client first before returning it.
- slicing refers to a process of dividing the buffer into smaller buffers by a least common multiple known as a block align; this is sometimes useful to a client with a graphical component because the interface may need to reflect the amount played in smaller subdivisions.
- the SCM When it is detected that all data from a segment has been requested, the SCM automatically steps to the next segment (possibly located on a different Voice Server) and begins requesting data from it instead. Because all Voice Servers are pre-loaded with the data and "ready to go,” this process takes place in a fraction of a second, and the client does not sense any gap in the audio data being returned. In fact, the only true method for discerning the segment boundaries involves listening for normal, audible indicators of a transfer being made (clicking, ringing, or hearing the voice of a new participant) as provided through the telephone switch environment.
- StopStream call is made to the SCM.
- the thread detects that the stopped state has been entered, exits from the request loop code, and frees up any used resources. Finally, it informs the client that a Stop event has occurred. If the entire call record is played without calling StopStream, the SCM performs the same exit and cleanup code, but informs the client that a Done event has occurred instead.
- Movement within the overall stream is straightforward, given the aforementioned method that the SCM uses to determine which segment to begin playing from.
- a global variable holds the total number of milliseconds of audio data requested thus far.
- Stop received a.) Exit from request loop, b.) Clean up used resources, c.) Send "Stop” event back to client.
- FIGS. 20, 20A, 20B, 21, 22, 22A, 22B, and 22C Detailed flow diagrams describing SCM operation are provided in FIGS. 20, 20A, 20B, 21, 22, 22A, 22B, and 22C.
- FIG. 20 illustrates the initialization process of the Stream Control Manager.
- the Initialization Sequence begins when a user enters the User Workstation playback software and at step 2010 queries for a recorded call record by desired criteria.
- a call record browser displays resulting call records.
- the user selects the desired record for playback.
- the browser invokes a PbkControlWin object: a dialog containing the 'player' ActiveX control.
- the browser sends information to PbkControlWin about all segments comprising the call record. If at step 2024 immediate playback is not required, at step 2028 the entry is added to a playlist for future playback, and at step 2030 SUCCESS is returned. If at step 2024 immediate playback is required, at step 2032 the call record ID and segment list are forwarded to a GUI Player module.
- the player module instantiates a local SCM (StreamControl) object and stores a pointer in m_pIStreamControl.
- the player module accepts the data, displays starting time and total duration (by parsing out string data), and forwards it to the final module, the Stream Control Manager (SCM), for audio playback.
- SCM Stream Control Manager
- Step 2046 begins the creation of a segments vector.
- a segment is parsed out from segList.
- recorder ID, start time, duration, and channel are parsed out from the segment.
- a new SEGMENT structure is created from recorder ID, start time, duration, and channel.
- a new SEGMENT is added to the SEGMENT vector.
- step 2054 if all segments have been parsed from segList, at step 2058 an element is gotten from the SEGMENT vector. If at step 2054 more segments remain to be parsed from segList, steps 2046, 2048, 2050, and 2052 are repeated.
- the program determines at step 2060 whether a new DCOM connection is required to the recorder for this segment. If not, at step 2062 the existing pointer is copied from the Connections vector to the server pointer in the SEGMENT vector and the program proceeds to step 2076. If at step 2060 the connection is new, a connection is made to the indicated recorder's "PlayBackServer" DCOM object using CoCreatelnstanceEx. At step 2066 the program checks whether the object instantiated successfully. If not, at step 2068 a log error message occurs and at step 2070 ERROR (C) is returned. If at step 2066 the object instantiated successfully, at step 2072 (see FIG. 20B) the new object's pointer is added to the Connections vector.
- ERROR ERROR
- step 2074 the program determines whether all segments have been connected. If not, the program returns to step 2058. If at step 2074 all segments have been connected, at step 2076 an element is gotten from the SEGMENT vector. At step 2078 the program queries for a list of wave files on the server that go with this segment. At step 2080 the program determines whether the query was successful. If not, at step 2082 a log error message occurs, and at step 2084 ERROR (C) is returned.
- C ERROR
- step 2088 the program opens the wave files on the server and prepares them for streaming. It also returns the wave format of the audio in the segment.
- step 2093 the program determines whether the wave files and format were obtained successfully. If not, at step 2094 a log error message occurs and at step 2095 ERROR (C) is returned. If step 2088 is determined at step 2093 to have been successful, at step 2096 the program checks whether all segments have been initialized. If not, the program returns to step 2076. If so, step 2097 is performed and at step 2098 SUCCESS is returned.
- FIG. 21 illustrates how the program manages a Player Object 2110 and a PbkControlWin Object 2132.
- FIG. 22 illustrates the playback sequence of the Stream Control Manager.
- a user has completed initialization and is waiting to hit Play in the Player GUI.
- the user hits the Play button.
- a message is sent to the Play method in the Player ActiveX control.
- the Play method in Player ActiveX control causes the output buffers to be "sliced” to increase the number of smaller buffers sent, thus increasing the resolution of the "totalPlayed" variable.
- Play method causes the server-side position to move to the current slider position.
- the program gets segment i++ from the SEGMENT vector.
- the program determines whether the End Time offset for segment i is greater than curPosition.
- step 2222 the program returns to step 2222. If so, the program proceeds to step 2226 and causes the file pointer on the server side to change to the appropriate new location.
- the program checks at step 2230 whether step 2226 was successful. If not, at step 2232 a log error message occurs and at step 2234 ERROR (C) is returned.
- step 2230 the program calls Stream Control:: StartStream.
- step 2242 the program gets segment i++ from the SEGMENT vector.
- step 2244 the program calls CoMarshallnterThreadlnterfacelnStream to marshal a DCOM pointer member across a thread boundary.
- step 2246 the program determines whether all SEGMENT elements have been marshaled. If not, the program returns to step 2242. If so, at step 2248 the main SCM streaming thread is spawned.
- FIG. 22B illustrates an SCM main streaming thread.
- the thread gets a segment from the SEGMENT vector.
- CoCetlnterfaceAndReleaseStream is called to unmarshal a DCOM pointer member across the thread boundary.
- the thread checks whether all SEGMENT elements have been unmarshaled. If not, the thread returns to step 2250. If at step 2250 all SEGMENT elements are determined to have been unmarshaled, at step 2256 the thread gets a segment from the SEGMENT vector. The thread then checks at step 2258 whether the End Time offset for segment i is greater than curAmountRequested. If not, the thread returns to step 2256.
- step 2260 the thread gets Segment[i++].
- the thread checks at step 2262 whether i is less than the highest segment number. If not, an Event: :Done method is called at step 2264, and at step 2266 SUCCESS (C) is returned. If so, at step 2268 the thread determines whether this is the first segment to be played in this instance of the thread. If not, at step 2270 the thread calls PBServer: :PositionPLay(totalRequested) for Segment[i] and goes to step 2272. If so, the thread goes directly to step 2272.
- the thread checks whether totalRequested is less than Segment[i].endTimeOffset. If not, the thread returns to step 2260. If so, the thread proceeds to step 2274 and checks whether totalRequested plus bufferSize is less than or equal to Segment[i].endTimeOffset. If not, at step 2276 the thread calculates a new bufferSize in multiples of the audio format's "block align.” and proceeds to step 2278 (see FIG. 22C). If so, the thread proceeds directly to step 2278. At step 2278, the thread calls PBServer: :ReqBuffer for Segment[i]. This is the core routine that actually retrieves a buffer of data from the PlayBack Server. At step 2286 the thread checks whether step 2278 was successful. If not, at step 2284 a log error message occurs, and at step 2282 ERROR (C) is returned.
- PBServer : :ReqBuffer for Segment[i]. This is the core routine that actually retrieves a buffer of data from the PlayBack Server.
- step 2286 determines that step 2278 was successful, at step 2287 toatlRequested is set equal to totalRequested plus Actual returned buffer size.
- step 2288 the thread checks whether Blockslicing is enabled. If not, at step 2289 the thread sends the buffer back to the Player via Event: :SendData method and returns to step 2274. If BlockSlicing has been enabled, at step 2292 the thread checks whether the CODEC is Dialogic OKI ADPCM or PCM. If not, at step 2293 the slice of the slices is set equal to the audio format's block align and the thread proceeds to step 2296. If so, at step 2294 the size of the slices is set to an even dividend of the buffer size (e.g., one-tenth of the buffer size).
- the thread copies out "slice size" from the buffer and sends it back to Player via Event: :SendData method.
- the thread checks whether the entire buffer has been sent back. If not, the thread returns to step 2298. If so, the thread returns to step 2274.
- the Stream Control Manager could theoretically be adapted to be used in more general streaming media situations, outside that of communications recording systems. In most current stream-based systems for network-based playback of audio content, such as RealMedia and NetShow, two general broadcast architectures exist known as unicast and multicast. Unicast involves a single client-server connection for data streaming, while in the multicast scenario a server pushes data to a single network address which multiple clients can then "tune in" to.
- the SCM model could provide an innovative solution where the client side has the power to weave together many streams into a single playback session.
- An example could be imagined where a news organization, such as CNN, dynamically assembles a streaming broadcast for the online viewer from many different reports located on servers across the country.
- the components could be played seamlessly end-on-end using the SCM model, and if the viewer desired to rewind or fast-forward to a specific point in the stream, the SCM model would allow for complete transparent control.
Abstract
Description
Claims
Applications Claiming Priority (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US328294 | 1981-12-07 | ||
US328295 | 1981-12-07 | ||
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 |
US328299 | 1999-06-08 | ||
US09/328,299 US6249570B1 (en) | 1999-06-08 | 1999-06-08 | System and method for recording and storing telephone call information |
US09/328,295 US6252947B1 (en) | 1999-06-08 | 1999-06-08 | System and method for data recording and playback |
PCT/US2000/015748 WO2000076188A1 (en) | 1999-06-08 | 2000-06-08 | A system and method for call record creation and processing |
US328298 | 2002-12-23 |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1183852A1 true EP1183852A1 (en) | 2002-03-06 |
EP1183852A4 EP1183852A4 (en) | 2005-11-23 |
Family
ID=27502378
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP00938220A Withdrawn EP1183852A4 (en) | 1999-06-08 | 2000-06-08 | A system and method for call record creation and processing |
Country Status (11)
Country | Link |
---|---|
EP (1) | EP1183852A4 (en) |
CN (1) | CN1369170A (en) |
AU (1) | AU5329200A (en) |
CA (1) | CA2376157C (en) |
DE (1) | DE1183852T1 (en) |
ES (1) | ES2191574T1 (en) |
HK (1) | HK1045231A1 (en) |
IL (4) | IL146901A0 (en) |
MX (1) | MXPA01012606A (en) |
NZ (1) | NZ516066A (en) |
WO (1) | WO2000076188A1 (en) |
Families Citing this family (17)
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 |
US20030007611A1 (en) * | 2000-05-15 | 2003-01-09 | Junichi Morita | Voice storage system, exchange and voice storage apparatus |
GB0029574D0 (en) * | 2000-12-02 | 2001-01-17 | Hewlett Packard Co | Recordal service for voice communications |
AU2247902A (en) | 2000-12-12 | 2002-06-24 | Nice Systems Ltd | A method and system for monitoring and recording voice from circuit-switched switches via a packet-switched network |
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 |
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 |
KR100608780B1 (en) * | 2004-05-07 | 2006-08-08 | 엘지전자 주식회사 | A method and a apparatus of displaying communication history for mobile phone |
GB0501939D0 (en) * | 2005-01-29 | 2005-03-09 | Retell Holdings Ltd | A telephone system |
CN1984181B (en) * | 2006-04-21 | 2010-08-04 | 华为技术有限公司 | Method for collecting talk record |
CN101997993A (en) * | 2009-08-25 | 2011-03-30 | 北京合力金桥软件技术有限责任公司 | Method for applying embedded memory database by CTI |
CN103220420B (en) * | 2013-04-07 | 2015-02-25 | 广东欧珀移动通信有限公司 | Method and device for permanently storing call record |
CN103297419B (en) * | 2013-04-23 | 2016-01-20 | 携程计算机技术(上海)有限公司 | Line rolls off the production line upper data fusion method and system |
CN105100378A (en) * | 2014-05-19 | 2015-11-25 | 腾讯科技(深圳)有限公司 | Method and device for processing mobile terminal communication records |
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 |
CN108401194B (en) * | 2018-04-27 | 2020-06-30 | 广州酷狗计算机科技有限公司 | Time stamp determination method, apparatus and computer-readable storage medium |
CN109830248B (en) * | 2018-12-14 | 2020-10-27 | 维沃移动通信有限公司 | Audio recording method and terminal equipment |
CN113067848B (en) * | 2021-02-05 | 2023-09-26 | 厦门亿联网络技术股份有限公司 | Call record synchronization method and system and electronic equipment |
Family Cites Families (3)
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 |
-
2000
- 2000-06-08 NZ NZ516066A patent/NZ516066A/en not_active IP Right Cessation
- 2000-06-08 IL IL14690100A patent/IL146901A0/en not_active IP Right Cessation
- 2000-06-08 CA CA002376157A patent/CA2376157C/en not_active Expired - Lifetime
- 2000-06-08 DE DE1183852T patent/DE1183852T1/en active Pending
- 2000-06-08 MX MXPA01012606A patent/MXPA01012606A/en unknown
- 2000-06-08 CN CN00811409A patent/CN1369170A/en active Pending
- 2000-06-08 ES ES00938220T patent/ES2191574T1/en active Pending
- 2000-06-08 EP EP00938220A patent/EP1183852A4/en not_active Withdrawn
- 2000-06-08 WO PCT/US2000/015748 patent/WO2000076188A1/en active Application Filing
- 2000-06-08 AU AU53292/00A patent/AU5329200A/en not_active Abandoned
-
2002
- 2002-09-02 HK HK02106455.3A patent/HK1045231A1/en unknown
-
2007
- 2007-04-19 IL IL182673A patent/IL182673A/en not_active IP Right Cessation
- 2007-04-19 IL IL182675A patent/IL182675A/en not_active IP Right Cessation
- 2007-04-19 IL IL182674A patent/IL182674A/en not_active IP Right Cessation
Non-Patent Citations (2)
Title |
---|
No further relevant documents disclosed * |
See also references of WO0076188A1 * |
Also Published As
Publication number | Publication date |
---|---|
IL182674A (en) | 2009-07-20 |
HK1045231A1 (en) | 2002-11-15 |
IL182675A0 (en) | 2007-09-20 |
IL182674A0 (en) | 2007-09-20 |
NZ516066A (en) | 2003-07-25 |
IL182673A (en) | 2009-07-20 |
CA2376157C (en) | 2009-03-24 |
ES2191574T1 (en) | 2003-09-16 |
CN1369170A (en) | 2002-09-11 |
WO2000076188A1 (en) | 2000-12-14 |
CA2376157A1 (en) | 2000-12-14 |
EP1183852A4 (en) | 2005-11-23 |
MXPA01012606A (en) | 2002-06-21 |
IL182673A0 (en) | 2007-09-20 |
AU5329200A (en) | 2000-12-28 |
IL182675A (en) | 2009-07-20 |
IL146901A0 (en) | 2002-08-14 |
DE1183852T1 (en) | 2003-06-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6785370B2 (en) | System and method for integrating call record information | |
US6785369B2 (en) | System and method for data recording and playback | |
US6246752B1 (en) | System and method for data recording | |
US6249570B1 (en) | System and method for recording and storing telephone call information | |
IL182674A (en) | System and method for recording and storing telephone call information | |
JP4205310B2 (en) | Rule-based multimedia customer / business dialogue network operating system | |
US20060198504A1 (en) | Call recording platform | |
US6278772B1 (en) | Voice recognition of telephone conversations | |
US6587556B1 (en) | Skills based routing method and system for call center | |
US6173052B1 (en) | Blending communications in a call center | |
US7321298B2 (en) | Skills based routing method and system for call center | |
US5982857A (en) | Voice recording method and system providing context specific storage and retrieval | |
US6603854B1 (en) | System and method for evaluating agents in call center | |
US9276903B2 (en) | Branch IP recording | |
WO1999059316A1 (en) | Monitoring of and remote access to call center activity | |
JP2003502720A (en) | Method and apparatus for rule-based storage and retrieval of multimedia interactions within a communication center | |
US6418205B2 (en) | Call and circuit state machine for a transaction control layer of a communications signaling gateway | |
Chou et al. | Computer telephony integration and its applications | |
CN100388284C (en) | Digital video and audio recording system | |
US6396909B1 (en) | Inter-system call transfer | |
CN1722757B (en) | Recording system based on voice communication | |
CN115967767A (en) | Telephone alarm system based on OCS and dynamic scheduling mechanism | |
de Albuquerque | Phone RecordSolu¸ cão de Gravação e Monitorização VoIP | |
IES80396B2 (en) | A teleconferencing system | |
MXPA99010454A (en) | Method and system for monitoring call center service representatives |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |
|
AX | Request for extension of the european patent |
Free format text: AL;LT;LV;MK;RO;SI |
|
17P | Request for examination filed |
Effective date: 20011221 |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: BSCHEIDER, VALERIE Inventor name: DIAMOND, DAVID, A. Inventor name: NI, PHIL MIN Inventor name: GLOWNY, DAVID, A. Inventor name: RICHTER, JOHN, E. Inventor name: NGUYEN, TRONG |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: DICTAPHONE CORPORATION |
|
TCAT | At: translation of patent claims filed | ||
TCNL | Nl: translation of patent claims filed | ||
REG | Reference to a national code |
Ref country code: GR Ref legal event code: PP Ref document number: 20030300005 Country of ref document: GR |
|
EL | Fr: translation of claims filed | ||
DET | De: translation of patent claims | ||
A4 | Supplementary search report drawn up and despatched |
Effective date: 20051012 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: 7H 04M 3/36 A Ipc: 7H 04M 3/42 B |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: NICE SYSTEMS, INC. |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20090630 |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: WD Ref document number: 1045231 Country of ref document: HK |