SYSTEM AND METHOD FOR RECORDING CALLS IN AN IP-BASED COMMUNICATIONS SYSTEM
A software solution to recording IP based communications that is highly scalable and reliable. Recordings can be configured to occur automatically or be triggered on-demand by a user that has been given the rights to do so. The user initiating the on-demand recording need not be a participant on the call. The solution is based on two server components: a call manager and a media server. The call manager is responsible for re-routing the IP media stream between two endpoints via the media server. The media server relays the IP media packets while capturing a copy that is stored as the recording. The recordings are stored on a network share and secured using standard network file security mechanisms. Access to playback recordings requires rights that are configured via the administrator. Playback of the recordings can be accomplished via the phone, client application or web service. Each playback interface offers a listing of recordings that the user has rights to access.
Priority of provisional application serial number 60/774,000, filed on Feb. 15, 2006 is claimed.
BACKGROUND OF THE INVENTIONThe recording of telephone calls has hithertofore been accomplished by the use of at least some hardware devices introduced into a voice circuit. Even the latest generation of packet-sniffing call-recording products requires special hardware in the form of Ethernet switches that are capable of port mirroring. Examples of prior art systems incorporating hardware for recording telephone calls are disclosed in U.S. Pat. Nos. 5,392,329; 5,923,746; 6,249,570; 6,665,376; and 6,728,345. The present invention is directed to a purely software method and system for recording telephone calls.
SUMMARY OF THE INVENTIONThe present invention is directed to a purely software solution for recording telephone calls in an IP packet-based system. This software solution runs on a standard PC, and has no special hardware dedicated to it. Furthermore, the recording software of the invention may be co-located on the server providing call-control for the entire IP communications system. A benefit of this distributed software solution of the invention is that, as more recording capability is required, additional recording nodes may be added to the network of the IP communications system. Also, as the PC platform continues to increase in performance, recording capacity will correspondingly increase as well.
The distributed software architecture of the invention consists of recording resources of 1 to n processing elements or nodes. This ability to distribute the recording nodes allows recording resources to be located near the endpoints to be recorded, to thus minimize the networking resources that are required.
The software architecture of the invention ensures that the failure of any element only affects the calls in progress associated with that element. Subsequent calls for that network element are routed to other elements in the network having available capacity. The software architecture of the invention is scalable, allowing as many additional recording resources as required, with additional processing elements being added to the network as needs dictate. The software architecture of the invention is very reliable due to the nature of the packet-based system in which it is employed, while the recording resources do not need to be dedicated to a single terminal in the system. The recording resources are allocated on a call-by-call basis, therefore allowing a pool of resources to be shared over a greater number of potential terminals to be recorded. Administrators have several options on how to configure the automatic recording. By allowing the administrator to configure the system to only record calls of interest, CPU processing, bandwidth, and disk space will be saved.
The software architecture of the invention is easily and readily configurable, whereby the administration is integrated into the IP communication system itself, allowing recording configuration via the same interface from which all other communication system configurations are managed. Auto-recording is triggered using addresses. Dialing an address that has auto-record enabled will record the call and tag the recording against the dialed address. Dialing a call from a primary address that has auto-recording enabled will record the call and tag the recording against the primary address.
An example of the granularity, or packaging, of control that can be provided by the software of the present invention is demonstrated by the administration of call-recording for group addresses. A group address can be configured for auto-record in one step. When one member of a larger address group answers a call, the recording is stored against the group address and not the primary address of the station. This optimizes resources by only recording calls to the group address and not calls to and from the primary address. Another example of the administrative control offered by the software architecture of the invention is the ability to provide a selectable means of recording outbound calls. Two outside service addresses may be created for the same station or group, with one configured to record and the other not. Users then have to option of choosing the outside service that suits their need to record or not, once again providing better management of recording resources.
On-Demand recording is also provided. Recording can be initiated at any time once a call is connected. Users may stop and restart on-demand recording of a call explicitly by issuing a “stop” or “start” recording command. On-Demand recording is invoked by sending a message to the call-control application. This can be achieved by a number of means. Some examples are pressing a button on an IP telephone, using a computer-telephony integration (CTI) application or via a Web Service. The administrator can manage this privilege by assigning rights to on-demand recording via a COS (Class of Service) profile.
The software architecture of the invention provides hierarchical rights management. Recording rights may be administered at both station and user level. A station refers to a voice terminal, such as an IP telephone, while a user refers to someone that uses a terminal in the system to communicate. Users are identified by some form of credentials, such as a user name, password or a PIN code. A user is typically assigned rights to one or more voice stations or terminals. The user is then able to invoke recording for a call in progress on that terminal. The call manager applications software of the invention re-routes the IP media streams between voice terminals to be recorded through the media server.
The invention will be more readily understood with reference to the accompanying drawings, wherein:
Referring now to the drawings in greater detail, and to
The specific media server 12 of the 1 through n media servers 12 that is used for recording calls of a specific end user or workstation is determined using the following algorithm to optimize networking resources:
-
- 1. Media server of the call manager that is hosting the triggering end-user;
- 2. The lowest loaded media server on the same LAN of the triggering end-user; or
- 3. The lowest loaded media server on another LAN when call-admission control is disabled.
This approach provides considerable benefits for systems that span multiple geographic locations. By utilizing the optimal call manager to manage the media stream, additional optimization is capable by utilizing the call manager's knowledge of the call-state. When an end-point being recorded is put on hold, the call manger does not route the MOH (message-on-hold) stream through the recording media server, thus not wasting resources recording that MOH call. Another instance involves transfers. Since the call manager of the optimal media server knows every call-state, when an ongoing call of an end-point 10 being recorded is transferred, the recording is automatically split into two recording files, since the call manager is made aware of the call-transfer state. An example where this is especially useful is as follows: A PSTN call arrives to a customer-service agent end-user 10; after being unable to solve the problem, the service agent transfers the call to a supervisor at another end-point 10. Afterwards, the supervisor would like to review the call with the agent. The supervisor may easily access the leg of the call between the customer and the agent without exposing his discussion with the customer that occurred after the transfer.
Each media server 12 creates a recording of the session in a common format for easy playback. This format may be, for example, an 8 KHz, 8-bit sampled, u-law wav file. Recordings are initially cached on the local or optimal processing media server 12, where they remain, or may optionally transferred to an alternative storage share or file server 14 of the data network, thus providing flexible recording storage. In the case of workstation or PC to which an IP phone or end-point 10 is connected, a desktop CTI (computer-telephony interface) application playback can be used to obtain credentials and access his or her recording log. The selected recording can be streamed back via RTSP (Real-Time Streaming Protocol) or downloaded and played back locally.
Since the storage of recordings are stored on a file-share in the data network using secure identity, prevention of any unauthorized access to the recording store is achieved, thus providing secure playback of recordings, where access to the recordings require some form of authentication. Playback may also be achieved by phone playback using a PIN code to identify the user where a recording log is displayed for selection of a recording for playback. Alternatively, web-service playback is also possible via a secure web-service using username/password credentials to obtain the recording log. The selected recording can be streamed back via RTSP (Real-Time Streaming Protocol) or downloaded and played back locally.
Referring now to
It is noted that the above-described packet reflection procedure is CODEC (coder-decoder) independent. At the application level, the packets to be recorded are independently decoded, whereby the bi-directional media streams 32, 34 utilizing asymmetric codes are supported. The two streams 32, 34 are summed to create a single recording of both sources in the call. The summed stream is converted to a common format for storage and playback, such as 8 KHz, 8-bit sampled, u-law wav file. Since the real time reflection of the stream is handled below the IP stack, the application layer utilizes the IP stack buffering while performing the decoding, summing, recoding and transfer to recording-storage operations. Information regarding the call recording is stored as an extension to the CDR (Call Detail Record). Therefore, recordings are searchable by all CDR attributes such as Caller ID (CLID) or Automatic Number Identification (ANI); Dialed Number Identification Service (DNIS). CDR reports can provide an indication that there is a recording available for a call.
Referring now to
Referring to
Referring now to
The steps from blocks 78 through 88 are used to sum both audio streams 32, 34 (streams 0 and 1) in buffer in order that the complete conversation is recorded, with both ends of the call recorded in sequence as it actually occurred, as described above. If the answer to decision block 74 is “NO”, or after completing the sum-data step of block 88, the program then increments in block 90 from data Stream 0 to data Stream 1, if data Stream 0 had been processed. If data Stream 1 had been processed, then the software determines that the audio data stream is greater than one (“YES” to decision block 90), meaning the software will return and await data for stream 0 again. If the answer is “NO” to decision block 92, then the program awaits receipt of audio data for Stream 1 from the RTP bridge level. The queue consists of a buffer with 2 pointers, one pointer for each stream (STREAM 0 pointer and STREAM 1 pointer). The queue is initialized to silence and each sample flushed to disk is replaced with silence. As packets arrive for each system, they are summed into the next available location in the queue, resulting in either packets containing the sum of stream 0 and stream 1 or the data from a single system stream if the other stream is unavailable for a period of time (some stream data may not available due to packet loss or excessive jitter).
Referring to
The redirection table redirection table 30 at the RTP bridge driver level 24 (
- Endpoint A→MediaServer→Endpoint B
- Endpoint A←MediaServer←Endpoint B
The parameters of a table entry are as follows:- ListenPort—The UDP (user datagram protocol) Port the Media Server listens on for the incoming RTP stream to be processed;
- SendPort—The UDP (user datagram protocol) Port the Media Server will use to transmit copied RTP packet from;
- RedirectPort—The Port of the destination endpoint that the Media Server will send RTP to;
- RedirectIPAddr—The IP Address of the destination endpoint that the Media Server will send RTP to;
- RedirectMACAddr—MAC (media access control) address to redirect to (this may be the endpoint or the gateway if located on another subnet)
The redirection table parameters are obtained by the recording application of
The application of the RTPBridge is not limited to the recording of audio RTP. The present invention may be used to record video RTP. It may be utilized for applications beyond recording. For example, it may also be used to construct an n-party conference broadcast application as diagrammed below:
-
- Endpoint A→MediaServer→Endpoint B
- Endpoint A→MediaServer→Endpoint C
- Endpoint A→MediaServer→Endpoint D
- Endpoint A→MediaServer→Endpoint n
The present invention is not restricted to RTP traffic. It may be used for any application requiring the need to efficiently relay real time UDP traffic.
While a specific embodiment of the invention has been shown and described, it is to be understood that numerous changes and modifications may be made therein without departing from the scope and spirit of the invention as set forth in the appended claims.
Claims
1. (canceled).
2. The method of recording calls in an IP packet-based data network according to claim 21, wherein said IP packet-based data network comprises a plurality of media servers, said method further comprising:
- (g) directing the data streams between end-users to an intermediate real-time protocol driver interface of another said media server, when said one media server is not capable of handling the data streams.
3. The method of recording calls in an IP packet-based data network according to claim 21, said method further comprising:
- (g) directing the data streams between end-users to an intermediate real-time protocol driver interface of a said media server of a different IP-based packet-data network, when said at least one media server is not capable of handling the data streams.
4. The method of recording calls in an IP packet-based data network according to claim 21, wherein said data streams of said step (a) are bidirectional media streams of end-users; said step (c) comprises summing the two streams of said bidirectional media streams for providing a single recording of the both sources of a call.
5. The method of recording calls in an IP packet-based data network according to claim 4, wherein said step (c) comprises storing the information of said bidirectional media streams as an extension to the Call Detail Record;
- said method further comprising searching the stored information of said bidirectional media steams by Call Detail Record attributes.
6. The method of recording calls in an IP packet-based data network according to claim 5, wherein said step of searching Call Detail Record attributes comprises searching for at least one of the following attributes: Caller ID, Automatic Number Identification, and Dialed Number Identification Service.
7. The method of recording calls in an IP packet-based data network according to claim 21, wherein said step (e) comprises rewriting the source and destination IP addresses and ports using a redirection table having the following parameters:
- ListenPort, SendPort, RedirectPort, and RedirectIPAddr.
8. The method of recording calls in an IP packet-based data network according to claim 7, wherein said (e) further comprises rewriting the source and destination IP addresses and ports using a redirection table having the additional parameters of RedirectMACAddr.
9. The method of recording calls in an IP packet-based data network according to claim 21, wherein said data streams are at least one of: audio packet-data stream and video packet-data stream.
10. The method of recording calls in an IP packet-based data network according to claim 21, wherein said real-time protocol driver interface comprises a RTP bridge device driver.
11. (canceled)
12. The IP packet-based data network according to claim 22, further comprising a plurality of media servers each having a said manager software program, each said manager software program of each said media server comprising transferring means for transferring the data stream between end-users to a said intermediate real-time protocol driver interface of another said media server, when one said media server is not capable of handling the data streams.
13. The IP packet-based data network according to claim 22, wherein said manager software program comprises transferring means for transferring the data streams between end-users to an intermediate real-time protocol driver interface of a said media server of a different IP-based packet-data network, when said at least one media server is not capable of handling the data streams.
14. The IP packet-based data network according to claim 22, wherein said data streams are bidirectional media streams of end-users; said recording program comprising summing means for summing the two streams of said bidirectional media streams for providing a single recording of the both sources of a call.
15. The IP packet-based data network according to claim 22, wherein said recording program comprises means for storing the information of said bidirectional media streams as an extension to the Call Detail Record; and
- further comprising searching means for searching the stored information of said bidirectional media steams by Call Detail Record attributes.
16. The IP packet-based data network according to claim 15, wherein said searching means searches said stored information of said bidirectional media streams for at least one of the following attributes: Caller ID, Automatic Number Identification, and Dialed Number Identification Service.
17. The IP packet-based data network according to claim 15, wherein said redirection table comprises the following parameters: ListenPort, SendPort, RedirectPort, and RedirectIPAddr.
18. (canceled)
19. The media server according to claim 23, wherein said data streams are bidirectional media streams of end-users; said recording program comprising summing means for summing the two streams of said bidirectional media streams for providing a single recording of the both sources of a call said memory comprising means for storing the information of said bidirectional media streams as an extension to the Call Detail Record; and means for searching the stored information of said bidirectional media steams by Call Detail Record attributes.
20. The media server according to claim 23, wherein said redirection table comprises the following parameters: ListenPort, SendPort, RedirectPort, and RedirectIPAddr.
21. A method of recording calls in an IP packet-based data network, which network includes a plurality of end-users and at least one media server used in connecting the end-users, said at least one media server having memory for storing software applications, said at least one media server comprising a protocol stack stored in said memory, said method comprising:
- (a) directing data streams between end-users to an intermediate real-time protocol driver interface of said at least one media server, and sending the real-time data streams to upper level protocol of said protocol stack;
- (b) sending the real-time data streams to a call recording software program stored in the memory of the at least one media server;
- (c) storing the data streams of said (b) in memory of said at least one media sever using the call recording software program;
- (d) duplicating the data streams using a software driver program having a redirection table;
- (e) rewriting the source and destination IP addresses and ports of said data streams as defined by said redirection table of said software driver program of said step (d); and
- (f) transmitting the data streams of said step (d) to the addresses and ports of said redirection table of said step (e).
22. In an IP packet-based data network, which network includes a plurality of end-users and at least one media server used in connecting the end-users for transmission of data streams, said at least one media server having memory for storing software applications, said at least one media server comprising a protocol stack stored in said memory, the improvement comprising:
- said protocol stack comprising an intermediate real-time protocol driver interface to which data streams between end-users are sent, a manager software program for controlling calls, and a recording program;
- said manager software program comprising driver software for duplicating said data streams delivered to it by said intermediate real-time protocol driver interface for subsequent resending of data streams;
- said manager software program further comprising rewriting means for rewriting the source and destination IP addresses and ports of said data streams, and a redirection table consisting of rewritten source and destination IP addresses and ports of said data streams received from said rewriting means for redirecting the data streams to their designated end-point;
- said intermediate real-time protocol driver interface transmitting the duplicated data streams to the addresses and ports of said redirection table.
23. In a media server forming part of an IP packet-based data network, which network includes a plurality of end-users and which media server is used in connecting data streams between end-users, said at least one media server having memory for storing software applications, and a protocol stack stored in said memory, the improvement comprising:
- said protocol stack comprising an intermediate real-time protocol driver interface to which data streams between end-users are sent, a manager software program for controlling calls, and a recording program;
- said manager software program comprising driver software for duplicating said data streams delivered to it by said intermediate real-time protocol driver interface for subsequent resending of data streams;
- said manager software program further comprising rewriting means for rewriting the source and destination IP addresses and ports of said data streams, and a redirection table consisting of rewritten source and destination IP addresses and ports of said data streams received from said rewriting means for redirecting the data streams to their designated end-point;
- said intermediate real-time protocol driver interface transmitting the duplicated data streams to the addresses and ports of said redirection table.
Type: Application
Filed: Jan 14, 2007
Publication Date: Aug 30, 2007
Patent Grant number: 8553851
Inventors: Alan Weir (Libertyville, IL), Randy Vyskocil (Buffalo Grove, IL), Bhama Rao (Lake Barrington, IL), Steven Greco (Round Lake, IL), John Blasko (Gurnee, IL)
Application Number: 11/623,078
International Classification: H04L 12/66 (20060101);