CA2567514A1 - Duplicate media stream - Google Patents
Duplicate media stream Download PDFInfo
- Publication number
- CA2567514A1 CA2567514A1 CA002567514A CA2567514A CA2567514A1 CA 2567514 A1 CA2567514 A1 CA 2567514A1 CA 002567514 A CA002567514 A CA 002567514A CA 2567514 A CA2567514 A CA 2567514A CA 2567514 A1 CA2567514 A1 CA 2567514A1
- Authority
- CA
- Canada
- Prior art keywords
- received data
- copied version
- communications device
- logic configured
- data
- 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.)
- Abandoned
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
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
Abstract
Included are embodiments of a method for recording in an Internet Protocol (IP) environment. At least one embodiment includes receiving data related to a communication, generating a copied version of at least a portion of the received data, and modifying the copied version of the received data. Other embodiments include sending at least a portion of the modified copied version of the received data to a recording device.
Description
DUPLICATE MEDIA STREAM
BACKGROUND
In Internet Protocol (IP) telephony, the path that the audio packets travel between endpoints generally varies. IP and switched Ethernet networks deliberately switch traffic onto specific routes, oftentimes making it difficult to use traditional passive tap techniques to record the telephony traffic. Generally speaking, as passive tap techniques access the packets somewhere between endpoints, along the route of the phone call, a passive tap has difficulty in that the data can be broken up into discrete packets, which may traverse different paths to reach the desired destination.
As encryption of IP traffic becomes more widespread, passive tapping techniques become even more problematic.
Additionally, while some approaches have been implemented that use the duplication of media streams, these current techniques of creating exact (or almost exact) copies of the streams is not without drawbacks. More specifically, current techniques often require additional network capacity to facilitate communication of the duplicate streams. Additionally, the bandwidth utilized between the communications device and the recording device is often twice the bandwidth of the original call. Another drawback of the current techniques is that the packets sent to the recorder are often sent in a very inefficient manner, as echo and fitter reduction techniques are utilized, as in the original call. Further, the compression scheme in many current techniques is chosen on the basis of the network bandwidth and available bandwidth taken by the call, without regard to the path between the communications device and the recording device.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.
SUMMARY
Included are methods for recording in an Internet Protocol (IP) environment.
At least one embodiment of a method includes receiving data related to a communication, generating a copied version of at least a portion of the received data, and modifying the copied version of the received data. Other embodiments include sending at least a portion of the modified copied version of the received data to a recording device.
Also included are embodiments of a computer readable medium for recording in an Internet Protocol (IP) environment. At least one embodiment includes logic configured to receive data related to a communication, logic configured to generate a copied version of at least a portion of the received data, and logic configured to modify the copied version of the received data. Other embodiments include logic configured to send at least a portion of the modified copied version of the received data to a recording device.
Also included are embodiments of a communications device for facilitating a recording in an Internet Protocol (IP) environment. At least one embodiment includes logic configured to receive data related to a communication, logic configured to generate a copied version of at least a portion of the received data, and logic configured to modify the copied version of the received data. Other embodiments include logic configured to send at least a portion of the modified copied version of the received data to a recording device.
Other systems, methods, features, and advantages of this disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description and be within the scope of the present disclosure.
BRIEF DESCRIPTION
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, there is no intent to limit the disclosure to the embodiment or embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents.
FIG. 1 is an exemplary diagram illustrating a configuration for recording a communication.
FIG. 2 is a network diagram illustrating another exemplary configuration for recording a communication using a remote recording device.
FIG. 3 is an exemplary network diagram illustrating a plurality of network components that may be present in a communications network, illustrating a configuration for duplicative recording of a communication.
FIG. 4 is a diagram illustrating an exemplary embodiment of a communications device and/or computing device that may be configured to communicate via a communications network such as the networks from FIGS. 1 and 2.
FIG. 5 is a flowchart illustrating exemplary steps that can be taken by a communications device for recording a communication in a communications network, such as the communications network from FIG. 3.
FIG. 6 is a flowchart illustrating exemplary steps that can be taken by a communications device in buffering a recording in a communications network, such as the communications network from FIG. 3.
FIG. 7 is a flowchart illustrating exemplary steps that can be taken by a communications device for lossy recording of a communication in a communications network, such as the network from FIG. 3.
FIG. 7 is a flowchart illustrating exemplary steps that can be taking by a remote recording device for recording a communication in a communications device, such as the communications network from FIG. 3.
FIG. 8 is a flowchart illustrating exemplary steps that can be taken by a communications device in sending data related to a communications to a recording device in a communications network, such as the communications network from FIG. 3.
DETAILED DESCRIPTION
One approach to overcome the above listed recording problems is to instruct a device that is party to the call (such as a Voice over Internet Protocol (VoIP) telephone, softphone, or other communications device) to forward copies of the data packets that the communications device is receiving and/or transmitting. In such a configuration, the communications device can send copies of the Real Time Protocol (RTP) packets associated with the call to a recorder. The destination addresses for this data are included in instructions from the recorder to the communications device.
FIG. 1 is an exemplary diagram illustrating a configuration for recording a Voice over IP (VoIP) communication. As shown, the nonlimiting example of FIG.
includes communications devices 106a, 106b coupled to communications network 100. Communications network can include a Wide Access Network (WAN), the Internet, or other communications network. Additionally communications device 106a, is also coupled to computing devices 104a. In this configuration, computing device 104a, is configured to receive voice data (as well as other data) from a user communicating with a third party via communications device 106b. The computing device 104a is configured to convert the voice data into data recognizable by a data network, such as the Internet (which may form part of communications network 100).
Generally speaking the computing device 104a is configured to receive the voice (and visual, depending on the particular configuration) and convert this data into a plurality of Internet Protocol (IP) packets. As one of ordinary skill in the art will understand, the computing device can convert this data according to any of a plurality of protocols.
Computing devices 104a, 104b may also be directly (or indirectly, depending on the configuration) coupled to communications network 100 to facilitate communication of the converted data.
Similarly, communications device 106b is coupled to communications network 100. Computing device 104b is also coupled to communications network 100. In this nonlimiting example, a direct connection between the communications device 106b and the computing device 104b is not utilized, as communication between these devices can be facilitated by communications network 100. In many embodiments, the implementation with communications device 106a and computing device 104a is similar in functionality as the configuration with communications device 106b and computing device 104b.
As illustrated in the nonlimiting example of FIG. l, recording device 108 is coupled between communications network 100 and communications device 106b.
While such a configuration can satisfy recording needs of communications device 106b, such a configuration can become unduly costly in network environments that include multiple communications devices, as one or more recording devices would likely be implemented at each site for recording.
FIG. 2 is an exemplary network diagram illustrating another exemplary configuration for recording a communication using a remote recording device.
More specifically, in this nonlimiting example, communications devices 204a and 204b are coupled to communications network 100. While communications devices 204a and 204b are illustrated as being similar to computing device 104, communications devices 204a and 204b are configured to operate with the functionality of both communications device 106 and computing device 104 (such as a softphone). As one of ordinary skill in the art will understand, communications devices 204a, 204b can be similar hardware (such as a headset, handset, or other device) for sending and receiving audio (as well as other) data related to a communication that is present in communications devices 104a, 104b. Other embodiments of communications devices 204a, 204b include logic for implementing a softphone. In any event, communications devices 204a, 204b are configured with most, if not all of the functionality of communications device and computing device 104.
As also illustrated in FIG. 2, recording device 108 is coupled to communications network 100. In this configuration, recording device 108 is configured remotely from communications device 204a and communications device 204b. Such a configuration can involve coupling the recording device 108 to a path of communication between communication device 204a and communication device 204b. While this configuration is beneficial in networks where a physical connection exists between communications device 204a and communications device 204b, such a configuration is has historically been difficult to implement when operating over a data network, such as the Internet.
More specifically, in an exemplary embodiment, communications device 204a receives a voice communication, a visual communication, and/or a data communication (or any permutation of these and other types of communication) from a user operating communications device 204b. Communications device 204b converts the communication received from a user of communications device 204b into a plurality of packets, which generally include a header and a payload.
The packets are sent individually to a destination address associated with communications device 204a, intermediate gateway, conference bridge, etc. The destination address is listed in each packet header. To increase the speed that this data is communicated to communications device 204a, each packet is configured to traverse a path of least resistance along the communications network. Because each packet traverses a path of least resistance, each packet can potentially take a different path between communications device 204b and communications device 204a.
When all (or a predetermined number) of the packets reach communications device 204a, the communications device 204a reads the packet headers to determine how to convert the payload data back to a format that is understandable to a user of communications device 204a. When a user associated with communications device 204a responds, a similar process is completed to communicate the voice to the user associated with communications device 204b. Because in such a configuration, packet data is communicated over a plurality of paths, a recording device coupled to a single path of the communications network can be problematic as a desired number of packets associated with the communication may not be received by recording device 108.
More recent attempts to implement a recording device remote from the endpoints (communications devices 204a, 204b) of a communication have included forwarding an exact duplicate of the communication to the recording device.
More specifically, as packets are sent between endpoints of the communication at a predetermined rate (e.g., 20 milliseconds), an exact duplicate of this data is sent at the same rate to the recorder. Such a configuration, while overcoming many of the obstacles of passive tap recording is not without inefficiencies.
FIG. 3 is an exemplary network diagram illustrating a plurality of network components that may be present in a communications network, further illustrating a configuration for recording a communication using a remote recording device.
Similar to the network from FIGS. 1 and 2, the nonlimiting example of FIG. 3 includes a plurality of communications devices 106c, 106d, 106e, and 106f.
However, in this exemplary communications network, a local network 300a is also coupled to communications devices 106c and 106d. Similarly, local network 300b is coupled to communications devices 106e and 106f. Also included is a voicemail server 312, a conference bridge 310, and data storage 314. Recording device 308 is coupled to communications network, similar to the configuration from FIG. 2.
One should note that, while the nonlimiting examples of FIGS. 2 and 3 illustrate communications device 106, this is but a nonlimiting example. Other communications devices and/or computing devices may be added or substituted for the communications devices in FIGS. 2 and 3. Depending on the particular network, various components may be utilized to provide the desired functionality.
One should also note that, depending on the particular configuration, data sent to the recorders) can be encrypted in any of a plurality of ways. More specifically, any of a plurality of protocols and/or any of a plurality of encryption techniques can be implemented to provide more secure data transfer.
FIG. 4 is an exemplary diagram illustrating an embodiment of a computing device and/or communications device that may be configured to communicate via a communications network such as the networks from FIGS. 1 and 2. Although a wire-line device is illustrated, this discussion can be applied to any device.
Generally, in terms of hardware architecture, as shown in FIG. 4, the device 106, 204 includes a processor 482, volatile and nonvolatile memory 484, a display interface 494, data storage 495, and one or more input and/or output (I/O) device interfaces) 496 that are communicatively coupled via a local interface 492. The local interface 492 can include, for example but not limited to, one or more buses or other wired or wireless connections. The local interface 492 may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components. The processor 482 may be a hardware device for executing software, particularly software stored in volatile and nonvolatile memory 484.
The processor 482 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the device 106, 204, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions. Examples of suitable commercially available microprocessors are as follows: a PA-RISC series microprocessor from Hewlett-Packard~ Company, an 80x86 or Pentium~ series microprocessor from Intel~ Corporation, a PowerPC~
microprocessor from IBM~, a Sparc~ microprocessor from Sun Microsystems~, Inc, or a 68xxx series microprocessor from Motorola~ Corporation.
The volatile and nonvolatile memory 484 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory 484 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the volatile and nonvolatile memory 484 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 482. Additionally, volatile and nonvolatile memory 484 can also include an operating system 486, as well as communications software 499.
The software in volatile and nonvolatile memory 484 may include one or more separate programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 4, the software in the volatile and nonvolatile memory 484 may include communications software client software 499, as well as operating system 486. The communications software 499 can include logic configured to converting voice data into a format for transmission over a data network, as well as logic configured to otherwise facilitate a communication. As a nonlimiting example, embodiments of communications software 499 are configured to convert received voice data into a plurality of packets for transmission via the Internet. Additionally, in at least one nonlimiting example, communications software 499 is configured to convert visual data (as well as other types of data) into a format for transmission via the Internet.
Similarly, with respect to operating system 486, a nonexhaustive list of examples of suitable commercially available operating systems is as follows:
(a) a Windows~ operating system available from Microsoft~ Corporation; (b) a Netware~
operating system available from Novell~, Inc.; (c) a Macintosh~ operating system available from Apple~ Computer, Inc.; (d) a UNIX operating system, which is available for purchase from many vendors, such as the Hewlett-Packard~
Company, Sun Microsystems~, Inc., and AT&T~ Corporation; (e) a LINUX operating system, which is freeware that is readily available on the Internet 100; (f) a run time Vxworks~ operating system from WindRiver~ Systems, Inc.; or (g) an appliance-based operating system, such as that implemented in handheld computers or personal data assistants (PDAs) (e.g., PaImOS~ available from Palm~ Computing, Inc., and Windows CE~ available from Microsoft~ Corporation). The operating system 486 can be configured to control the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.
A system component embodied as software may also be construed as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When constructed as a source program, the program is translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the volatile and nonvolatile memory 484, so as to operate properly in connection with the Operating System 486.
The Input/output devices that may be coupled to system I/O Interfaces) 496 may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, headset, handset, microphone, earphone, etc. Further, the Input/output devices may also include output devices, for example but not limited to, a printer, display, etc. Finally, the Input/output devices may further include devices that communicate both as inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a muter, etc.
If the communications device 106, 204 is a personal computer, workstation, or the like, the software in the volatile and nonvolatile memory 484 may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of software routines that initialize and test hardware at startup, start the Operating System, and support the transfer of data among the hardware devices. The BIOS
is stored in ROM so that the BIOS can be executed when the communications device 106 is activated.
When the communications device 106 is in operation, the processor 482 is configured to execute software stored within the volatile and nonvolatile memory 484, to communicate data to and from the volatile and nonvolatile memory 484, and to generally control operations of the communications device 106 pursuant to the software. Software in memory, in whole or in part, are read by the processor 482, perhaps buffered within the processor 482, and then executed.
FIG. 5 is a flowchart illustrating exemplary steps that can be taken by a communications device for recording a communication in a communications network, such as the communications network from FIG. 3. The first step in this nonlimiting example is for a communications device to receive a communication (block 530). The communication can be received from a user directly (i.e., placing an outgoing call) or from the network (i.e., receiving an incoming call).
Regardless, once the communication is received, the communications device receives a recording instruction with a destination address (block 532). This recording instruction can be received via a remote recording device. The remote recording device can be configured to determine when a recording is desired and can send an address for the communications device to send data for recording.
Once the communications device receives the recording instruction, the communications device can receive and/or create data for a communication (block 534). More specifically, this step includes the communications device receiving a voice communication (or other type, such as video, web chat, email, etc., as discussed above) from the user or data related to a voice communication from a third party (with whom the user is communicating). Once the data is created and/or received, the communications device sends a copy of the data to the third party (block 540). The communications device can then send the data to the recorder for recording (block 542).
FIG. 6 is a flowchart illustrating exemplary steps that can be taken by a communications device for lossless recording of a communication a communications network, such as the communications network from FIG. 3. The first step in this nonlimiting example is for a communications device to receive a recording instruction with a destination address (block 630). Next, the communications device can receive packet data related to a communication (block 632). Similar to the nonlimiting example from FIG. 5, the packet data related to a communication can come in the form of an incoming call or an outgoing call.
Once communication and the recording instruction are received, the communications device can strip the header from at least one received packet. As one of ordinary skill in the art will understand, IP packets (such as RTP packets) generally include a header and a payload. The header can include any of a plurality of administrative data such as version, extension, payload type, etc. The payload of an IP
packet generally includes traffic data. More specifically, in the nonlimiting example of a voice communication, the payload generally includes data that comprises the substance of the communication (or at least a portion thereof). Depending on the particular protocol being utilized, the packet data can be communicated with a certain size of header and payload. Additionally, the packet data is, depending on the particular protocol, sent to a destination in predetermined intervals (such as 20 milliseconds).
Next, the communications device can strip the header from at least one packet (block 634). Upon stripping the header, the communications device can combine the payload from at least one stripped packet with at least one other packet (block 636). By combining two packet payloads into a single packet, the communication device can more efficiently send data to the recorder. As a nonlimiting example, if the received packet data is configured for transmission in 20 millisecond intervals, by combining two packets into one, the recorder can receive the data in roughly half the time that unrefined data would be communicated (one should note that depending on header size, the actual efficiency gains can vary).
Next, the communications device can store the refined data for subsequent communication (block 638). The data can be stored in a buffer such that payload data from a plurality of packets can be accumulated. When the buffer reaches maximum capacity, a single, larger packet can be created for subsequent transmission. The communications device can then copy the received data related to the communication (block 640). The communications device can then send unrefined data to a third party of the communications (block 642). More specifically, the communications device can further facilitate the communication by sending packetized voice data from the user to the third party, to whom the user is communicating. As one of ordinary skill in the art will understand, this step can be performed before, during, and/or after the other steps in this nonlimiting example.
Next, the communications device can receive an indication of reduced network traffic (block 644). Upon receiving the indication of reduced network traffic, the communications device can send the refined data to the recorder (block 646).
One should note that other embodiments may provide that any component within the IP telephone network through which some or all of the audio content of a call passes is configured to process and record media streams. This can include trunk interface cards, conference bridges, voicemail and other servers, routing components trans-coding components etc. Additionally, in still other embodiments, the communications device can, if instructed, merge the two data streams (incoming and outgoing data streams) into a single data stream. This may be accomplished by encapsulating a pair of packets (such as RTP packets) inside a User Datagram Protocol (UDP) payload. Many techniques place two RTP packets in the payload of a UDP packet, preceded by two by 16 bit length fields indicating the length of each RTP
packet. At least one embodiment of the present disclosure includes removing the redundant information in the RTP packet header (e.g., the source of one is the destination of the other).
FIG. 7 is a flowchart illustrating exemplary steps that can be taken by a communications device for lossy recording of a communication in a communications network, such as the network from FIG. 3. More specifically, the first step in the nonlimiting example of FIG. 7 is for the communication device to receive a recording instruction (block 730). Next, the communications device can receive packet data related to a communication (block 732). Once the communications device has received the recording instruction and data related to the communication, the communications device can copy at least a portion of the packet data related to the communication (block 734).
Next, the communications device can compress the copied data (block 736).
The compression can take the form of G729A, 6711, or other compression format.
Once the data is compressed, the communications device can store the compressed data (block 738) for subsequent delivery. The communications device can send the uncompressed data to the third party (to whom the user is communicating), as illustrated in block 740. Then, the communication device can receive an indication of reduced network traffic (block 742) and send the compressed data to the recorder (block 744).
One should note that since the recording device is generally a receive-only device, echo is generally not a concern when recording. Therefore, there is generally no hard real-time requirement on transmission time or fitter. Hence at least one embodiment of the communications device can be configured support an option to send traffic to the recorder as "data" rather than "real-time" packets (e.g.
if using Quality of Service graded networks, the traffic to the recording device need not be marked as requiring rapid delivery). This allows the recorder traffic to co-exist on limited bandwidth networks with the real VoIP traffic and not degrade the service experienced by the VoIP calls. The communications device is configured to send traffic at times of reduced network traffic, thereby giving priority to the real-time voice traffic.
FIG. 8 is a flowchart illustrating exemplary steps that can be taking by a remote recording device for recording a communication in a communications device, such as the communications network from FIG. 3. The first step in the nonlimiting example of FIG. 8 is for the recording device to receive an indication of a communication (block 830). Depending on the particular configuration, an indication of a communication may or may not include a record request. Once the call indication is received, the recording device sends a record instruction with a destination address (block 832). In at least one embodiment, the destination address includes an address for sending data to the recording device. Once the record instruction is sent, the recording device can receive data related to the communication (block 834) and store the received data (block 836).
Additionally, embodiments of the communications device can, if instructed, forward packets containing mixed audio of the transmitted and received streams. As the communications device can be configured to decompress incoming packets and is responsible for any compression of outgoing packets, the communications device may already have access to the uncompressed audio and hence can mix these data streams (as the communications device does when applying side-tone to the received audio the communications device plays via the ear piece). Instead of forwarding the raw contents of the RTP packets, the communications device can be configured to take (a) audio that has been converted into linear form and ready for output to the handset/speaker and (b) audio the communications device has collected from the microphone and is in linear format prior to compression. The communications device can be configured to add (a) and (b) together to provide the mixed audio signal. The communications device can then compress this mixed data (using the compression format, if any, requested by the recorder) and place this in RTP packets for transmission to the recorder. Further, as communications devices generally support a range of compression formats, and with Digital Signal Processing (DSP) power increasing to the point where there is spare processing power available, the communications device can be instructed to compress the audio (whether split or mixed) before packetizing and sending the audio data to the recorder. As a lower quality of audio is often acceptable in a recording than in a live call, a more aggressive compression format is applied to the recorded stream than was applied to the original audio. This can result in reduced bandwidth consumption during recording.
One should also note that rather than forward RTP packets to the recorder, at least one embodiment of the communications device can be configured to support the establishment of a reliable connection to the recorder (e.g. full TCP/IP
socket connection). This allows the packets being sent to the recorder (a) to be received reliably with retransmission being handled by the TCP stack (a critical requirement in some recording applications) and (b) allows this recording stream to traverse the network at a lower Quality of Service threshold than the VoIP calls. This means that the network does not have to be capable of supporting the sum of live plus recorded traffic at the same high quality generally utilized in VoIP calls.
Additionally, embodiments of the communications device are configured to establish contact with the recorder and accept subsequent instructions (e.g. start/stop, mix, compress, buffer) directly from the recorder, rather than having these commands delivered via the other components of the telephone system. Still other embodiments of the communications device are configured to support multiple concurrent and independent requests for forwarding/copying/buffering of data from multiple recorders. This allows, as a nonlimiting example, live monitoring and recording concurrently. The communications device can be configured to perform the forwarding operation as many times and to as many different addresses as requested. This also works well for live backups (where recordings are sent to two different locations in real time) These techniques are often more secure than having one recorder store the data and then copy that data to another location.
This technique can usefully exploit the normally spare bandwidth that may be available between a satellite site and the backup parent site (i.e., WAN
designed to have traffic communicated from A to B but has additional capacity to communicate data from A to C to allow continued operation in the event of failure of site B. This bandwidth is often otherwise unused and it may be desirable for A to send data to both B and C than to have the data copied from B to C at a later time.
In addition to sending audio content of the communication, embodiments of the communications device may also be configured to receive requests to forward details of the quality of the call, derived, for example, from the Real Time Control Protocol (RTCP) packets exchanged with the remote party on the call. In addition to sending the audio content of the communication, the communications device may also be forwarded details of the call. Information available to the communications device, whether made visible to the user or not, can be forwarded to the recorder.
Additionally, embodiments of the communications device can be configured to forward details of the user's interaction with the communications device and the recorder. As a nonlimiting example, embodiments of the communications device can be configured to forward data such as speed of dialing, time when the communications device goes off hook, etc. (i.e. events that do not form part of the normally recorded call).
Also included within the scope of this disclosure is packet loss detection and analysis. By analyzing the sequence numbers and timestamps of the RTP packets, one can determine the proportion of packets have been lost. Alarms can be raised should this exceed an acceptable threshold. Where two streams are sent from a device (those the device received and those the transmitted), it is possible to determine from the loss characteristics whether packet loss is occurring between the recorder and the device performing the duplication (in which case losses on the two streams should be comparable) or between the two devices engaged in the original communication (in which cases losses are heavier on one stream - that duplicating the packets received by the forwarding device - than on the other).
Additionally included within the scope of this disclosure is quantification of packet transmission statistics. In addition to forwarding the packets (such as RTP
packets), if the forwarding device can also be configured to forward the RTCP
packets sent that relate to the original RTP link. The recorder can analyze this data to determine the quality of transmission between the original parties on the call. If RTCP is exchanged between the recorder and the forwarding device, it can determine the quality of that link. An overall quality level for the recording can therefore be determined. Where RTCP packets are forwarded, these can be wrapped inside a protocol and buffered with the RTP streams so as not to use much additional bandwidth or sockets en route to the recorder.
One should also note that the flowcharts included herein show the architecture, functionality, and operation of a possible implementation of software. In this regard, each block can be interpreted to represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
One should note that any of the programs listed herein, which can include an ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device.
More specific examples (a nonexhaustive list) of the computer-readable medium could include an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). In addition, the scope of the certain embodiments of this disclosure can include embodying the functionality described in logic embodied in hardware or software-configured mediums.
It should be emphasized that the above-described embodiments are merely possible examples of implementations, merely set forth for a clear understanding of the principles of this disclosure. Many variations and modifications may be made to the above-described embodiments) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure.
BACKGROUND
In Internet Protocol (IP) telephony, the path that the audio packets travel between endpoints generally varies. IP and switched Ethernet networks deliberately switch traffic onto specific routes, oftentimes making it difficult to use traditional passive tap techniques to record the telephony traffic. Generally speaking, as passive tap techniques access the packets somewhere between endpoints, along the route of the phone call, a passive tap has difficulty in that the data can be broken up into discrete packets, which may traverse different paths to reach the desired destination.
As encryption of IP traffic becomes more widespread, passive tapping techniques become even more problematic.
Additionally, while some approaches have been implemented that use the duplication of media streams, these current techniques of creating exact (or almost exact) copies of the streams is not without drawbacks. More specifically, current techniques often require additional network capacity to facilitate communication of the duplicate streams. Additionally, the bandwidth utilized between the communications device and the recording device is often twice the bandwidth of the original call. Another drawback of the current techniques is that the packets sent to the recorder are often sent in a very inefficient manner, as echo and fitter reduction techniques are utilized, as in the original call. Further, the compression scheme in many current techniques is chosen on the basis of the network bandwidth and available bandwidth taken by the call, without regard to the path between the communications device and the recording device.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.
SUMMARY
Included are methods for recording in an Internet Protocol (IP) environment.
At least one embodiment of a method includes receiving data related to a communication, generating a copied version of at least a portion of the received data, and modifying the copied version of the received data. Other embodiments include sending at least a portion of the modified copied version of the received data to a recording device.
Also included are embodiments of a computer readable medium for recording in an Internet Protocol (IP) environment. At least one embodiment includes logic configured to receive data related to a communication, logic configured to generate a copied version of at least a portion of the received data, and logic configured to modify the copied version of the received data. Other embodiments include logic configured to send at least a portion of the modified copied version of the received data to a recording device.
Also included are embodiments of a communications device for facilitating a recording in an Internet Protocol (IP) environment. At least one embodiment includes logic configured to receive data related to a communication, logic configured to generate a copied version of at least a portion of the received data, and logic configured to modify the copied version of the received data. Other embodiments include logic configured to send at least a portion of the modified copied version of the received data to a recording device.
Other systems, methods, features, and advantages of this disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description and be within the scope of the present disclosure.
BRIEF DESCRIPTION
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, there is no intent to limit the disclosure to the embodiment or embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents.
FIG. 1 is an exemplary diagram illustrating a configuration for recording a communication.
FIG. 2 is a network diagram illustrating another exemplary configuration for recording a communication using a remote recording device.
FIG. 3 is an exemplary network diagram illustrating a plurality of network components that may be present in a communications network, illustrating a configuration for duplicative recording of a communication.
FIG. 4 is a diagram illustrating an exemplary embodiment of a communications device and/or computing device that may be configured to communicate via a communications network such as the networks from FIGS. 1 and 2.
FIG. 5 is a flowchart illustrating exemplary steps that can be taken by a communications device for recording a communication in a communications network, such as the communications network from FIG. 3.
FIG. 6 is a flowchart illustrating exemplary steps that can be taken by a communications device in buffering a recording in a communications network, such as the communications network from FIG. 3.
FIG. 7 is a flowchart illustrating exemplary steps that can be taken by a communications device for lossy recording of a communication in a communications network, such as the network from FIG. 3.
FIG. 7 is a flowchart illustrating exemplary steps that can be taking by a remote recording device for recording a communication in a communications device, such as the communications network from FIG. 3.
FIG. 8 is a flowchart illustrating exemplary steps that can be taken by a communications device in sending data related to a communications to a recording device in a communications network, such as the communications network from FIG. 3.
DETAILED DESCRIPTION
One approach to overcome the above listed recording problems is to instruct a device that is party to the call (such as a Voice over Internet Protocol (VoIP) telephone, softphone, or other communications device) to forward copies of the data packets that the communications device is receiving and/or transmitting. In such a configuration, the communications device can send copies of the Real Time Protocol (RTP) packets associated with the call to a recorder. The destination addresses for this data are included in instructions from the recorder to the communications device.
FIG. 1 is an exemplary diagram illustrating a configuration for recording a Voice over IP (VoIP) communication. As shown, the nonlimiting example of FIG.
includes communications devices 106a, 106b coupled to communications network 100. Communications network can include a Wide Access Network (WAN), the Internet, or other communications network. Additionally communications device 106a, is also coupled to computing devices 104a. In this configuration, computing device 104a, is configured to receive voice data (as well as other data) from a user communicating with a third party via communications device 106b. The computing device 104a is configured to convert the voice data into data recognizable by a data network, such as the Internet (which may form part of communications network 100).
Generally speaking the computing device 104a is configured to receive the voice (and visual, depending on the particular configuration) and convert this data into a plurality of Internet Protocol (IP) packets. As one of ordinary skill in the art will understand, the computing device can convert this data according to any of a plurality of protocols.
Computing devices 104a, 104b may also be directly (or indirectly, depending on the configuration) coupled to communications network 100 to facilitate communication of the converted data.
Similarly, communications device 106b is coupled to communications network 100. Computing device 104b is also coupled to communications network 100. In this nonlimiting example, a direct connection between the communications device 106b and the computing device 104b is not utilized, as communication between these devices can be facilitated by communications network 100. In many embodiments, the implementation with communications device 106a and computing device 104a is similar in functionality as the configuration with communications device 106b and computing device 104b.
As illustrated in the nonlimiting example of FIG. l, recording device 108 is coupled between communications network 100 and communications device 106b.
While such a configuration can satisfy recording needs of communications device 106b, such a configuration can become unduly costly in network environments that include multiple communications devices, as one or more recording devices would likely be implemented at each site for recording.
FIG. 2 is an exemplary network diagram illustrating another exemplary configuration for recording a communication using a remote recording device.
More specifically, in this nonlimiting example, communications devices 204a and 204b are coupled to communications network 100. While communications devices 204a and 204b are illustrated as being similar to computing device 104, communications devices 204a and 204b are configured to operate with the functionality of both communications device 106 and computing device 104 (such as a softphone). As one of ordinary skill in the art will understand, communications devices 204a, 204b can be similar hardware (such as a headset, handset, or other device) for sending and receiving audio (as well as other) data related to a communication that is present in communications devices 104a, 104b. Other embodiments of communications devices 204a, 204b include logic for implementing a softphone. In any event, communications devices 204a, 204b are configured with most, if not all of the functionality of communications device and computing device 104.
As also illustrated in FIG. 2, recording device 108 is coupled to communications network 100. In this configuration, recording device 108 is configured remotely from communications device 204a and communications device 204b. Such a configuration can involve coupling the recording device 108 to a path of communication between communication device 204a and communication device 204b. While this configuration is beneficial in networks where a physical connection exists between communications device 204a and communications device 204b, such a configuration is has historically been difficult to implement when operating over a data network, such as the Internet.
More specifically, in an exemplary embodiment, communications device 204a receives a voice communication, a visual communication, and/or a data communication (or any permutation of these and other types of communication) from a user operating communications device 204b. Communications device 204b converts the communication received from a user of communications device 204b into a plurality of packets, which generally include a header and a payload.
The packets are sent individually to a destination address associated with communications device 204a, intermediate gateway, conference bridge, etc. The destination address is listed in each packet header. To increase the speed that this data is communicated to communications device 204a, each packet is configured to traverse a path of least resistance along the communications network. Because each packet traverses a path of least resistance, each packet can potentially take a different path between communications device 204b and communications device 204a.
When all (or a predetermined number) of the packets reach communications device 204a, the communications device 204a reads the packet headers to determine how to convert the payload data back to a format that is understandable to a user of communications device 204a. When a user associated with communications device 204a responds, a similar process is completed to communicate the voice to the user associated with communications device 204b. Because in such a configuration, packet data is communicated over a plurality of paths, a recording device coupled to a single path of the communications network can be problematic as a desired number of packets associated with the communication may not be received by recording device 108.
More recent attempts to implement a recording device remote from the endpoints (communications devices 204a, 204b) of a communication have included forwarding an exact duplicate of the communication to the recording device.
More specifically, as packets are sent between endpoints of the communication at a predetermined rate (e.g., 20 milliseconds), an exact duplicate of this data is sent at the same rate to the recorder. Such a configuration, while overcoming many of the obstacles of passive tap recording is not without inefficiencies.
FIG. 3 is an exemplary network diagram illustrating a plurality of network components that may be present in a communications network, further illustrating a configuration for recording a communication using a remote recording device.
Similar to the network from FIGS. 1 and 2, the nonlimiting example of FIG. 3 includes a plurality of communications devices 106c, 106d, 106e, and 106f.
However, in this exemplary communications network, a local network 300a is also coupled to communications devices 106c and 106d. Similarly, local network 300b is coupled to communications devices 106e and 106f. Also included is a voicemail server 312, a conference bridge 310, and data storage 314. Recording device 308 is coupled to communications network, similar to the configuration from FIG. 2.
One should note that, while the nonlimiting examples of FIGS. 2 and 3 illustrate communications device 106, this is but a nonlimiting example. Other communications devices and/or computing devices may be added or substituted for the communications devices in FIGS. 2 and 3. Depending on the particular network, various components may be utilized to provide the desired functionality.
One should also note that, depending on the particular configuration, data sent to the recorders) can be encrypted in any of a plurality of ways. More specifically, any of a plurality of protocols and/or any of a plurality of encryption techniques can be implemented to provide more secure data transfer.
FIG. 4 is an exemplary diagram illustrating an embodiment of a computing device and/or communications device that may be configured to communicate via a communications network such as the networks from FIGS. 1 and 2. Although a wire-line device is illustrated, this discussion can be applied to any device.
Generally, in terms of hardware architecture, as shown in FIG. 4, the device 106, 204 includes a processor 482, volatile and nonvolatile memory 484, a display interface 494, data storage 495, and one or more input and/or output (I/O) device interfaces) 496 that are communicatively coupled via a local interface 492. The local interface 492 can include, for example but not limited to, one or more buses or other wired or wireless connections. The local interface 492 may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components. The processor 482 may be a hardware device for executing software, particularly software stored in volatile and nonvolatile memory 484.
The processor 482 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the device 106, 204, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions. Examples of suitable commercially available microprocessors are as follows: a PA-RISC series microprocessor from Hewlett-Packard~ Company, an 80x86 or Pentium~ series microprocessor from Intel~ Corporation, a PowerPC~
microprocessor from IBM~, a Sparc~ microprocessor from Sun Microsystems~, Inc, or a 68xxx series microprocessor from Motorola~ Corporation.
The volatile and nonvolatile memory 484 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory 484 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the volatile and nonvolatile memory 484 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 482. Additionally, volatile and nonvolatile memory 484 can also include an operating system 486, as well as communications software 499.
The software in volatile and nonvolatile memory 484 may include one or more separate programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 4, the software in the volatile and nonvolatile memory 484 may include communications software client software 499, as well as operating system 486. The communications software 499 can include logic configured to converting voice data into a format for transmission over a data network, as well as logic configured to otherwise facilitate a communication. As a nonlimiting example, embodiments of communications software 499 are configured to convert received voice data into a plurality of packets for transmission via the Internet. Additionally, in at least one nonlimiting example, communications software 499 is configured to convert visual data (as well as other types of data) into a format for transmission via the Internet.
Similarly, with respect to operating system 486, a nonexhaustive list of examples of suitable commercially available operating systems is as follows:
(a) a Windows~ operating system available from Microsoft~ Corporation; (b) a Netware~
operating system available from Novell~, Inc.; (c) a Macintosh~ operating system available from Apple~ Computer, Inc.; (d) a UNIX operating system, which is available for purchase from many vendors, such as the Hewlett-Packard~
Company, Sun Microsystems~, Inc., and AT&T~ Corporation; (e) a LINUX operating system, which is freeware that is readily available on the Internet 100; (f) a run time Vxworks~ operating system from WindRiver~ Systems, Inc.; or (g) an appliance-based operating system, such as that implemented in handheld computers or personal data assistants (PDAs) (e.g., PaImOS~ available from Palm~ Computing, Inc., and Windows CE~ available from Microsoft~ Corporation). The operating system 486 can be configured to control the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.
A system component embodied as software may also be construed as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When constructed as a source program, the program is translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the volatile and nonvolatile memory 484, so as to operate properly in connection with the Operating System 486.
The Input/output devices that may be coupled to system I/O Interfaces) 496 may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, headset, handset, microphone, earphone, etc. Further, the Input/output devices may also include output devices, for example but not limited to, a printer, display, etc. Finally, the Input/output devices may further include devices that communicate both as inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a muter, etc.
If the communications device 106, 204 is a personal computer, workstation, or the like, the software in the volatile and nonvolatile memory 484 may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of software routines that initialize and test hardware at startup, start the Operating System, and support the transfer of data among the hardware devices. The BIOS
is stored in ROM so that the BIOS can be executed when the communications device 106 is activated.
When the communications device 106 is in operation, the processor 482 is configured to execute software stored within the volatile and nonvolatile memory 484, to communicate data to and from the volatile and nonvolatile memory 484, and to generally control operations of the communications device 106 pursuant to the software. Software in memory, in whole or in part, are read by the processor 482, perhaps buffered within the processor 482, and then executed.
FIG. 5 is a flowchart illustrating exemplary steps that can be taken by a communications device for recording a communication in a communications network, such as the communications network from FIG. 3. The first step in this nonlimiting example is for a communications device to receive a communication (block 530). The communication can be received from a user directly (i.e., placing an outgoing call) or from the network (i.e., receiving an incoming call).
Regardless, once the communication is received, the communications device receives a recording instruction with a destination address (block 532). This recording instruction can be received via a remote recording device. The remote recording device can be configured to determine when a recording is desired and can send an address for the communications device to send data for recording.
Once the communications device receives the recording instruction, the communications device can receive and/or create data for a communication (block 534). More specifically, this step includes the communications device receiving a voice communication (or other type, such as video, web chat, email, etc., as discussed above) from the user or data related to a voice communication from a third party (with whom the user is communicating). Once the data is created and/or received, the communications device sends a copy of the data to the third party (block 540). The communications device can then send the data to the recorder for recording (block 542).
FIG. 6 is a flowchart illustrating exemplary steps that can be taken by a communications device for lossless recording of a communication a communications network, such as the communications network from FIG. 3. The first step in this nonlimiting example is for a communications device to receive a recording instruction with a destination address (block 630). Next, the communications device can receive packet data related to a communication (block 632). Similar to the nonlimiting example from FIG. 5, the packet data related to a communication can come in the form of an incoming call or an outgoing call.
Once communication and the recording instruction are received, the communications device can strip the header from at least one received packet. As one of ordinary skill in the art will understand, IP packets (such as RTP packets) generally include a header and a payload. The header can include any of a plurality of administrative data such as version, extension, payload type, etc. The payload of an IP
packet generally includes traffic data. More specifically, in the nonlimiting example of a voice communication, the payload generally includes data that comprises the substance of the communication (or at least a portion thereof). Depending on the particular protocol being utilized, the packet data can be communicated with a certain size of header and payload. Additionally, the packet data is, depending on the particular protocol, sent to a destination in predetermined intervals (such as 20 milliseconds).
Next, the communications device can strip the header from at least one packet (block 634). Upon stripping the header, the communications device can combine the payload from at least one stripped packet with at least one other packet (block 636). By combining two packet payloads into a single packet, the communication device can more efficiently send data to the recorder. As a nonlimiting example, if the received packet data is configured for transmission in 20 millisecond intervals, by combining two packets into one, the recorder can receive the data in roughly half the time that unrefined data would be communicated (one should note that depending on header size, the actual efficiency gains can vary).
Next, the communications device can store the refined data for subsequent communication (block 638). The data can be stored in a buffer such that payload data from a plurality of packets can be accumulated. When the buffer reaches maximum capacity, a single, larger packet can be created for subsequent transmission. The communications device can then copy the received data related to the communication (block 640). The communications device can then send unrefined data to a third party of the communications (block 642). More specifically, the communications device can further facilitate the communication by sending packetized voice data from the user to the third party, to whom the user is communicating. As one of ordinary skill in the art will understand, this step can be performed before, during, and/or after the other steps in this nonlimiting example.
Next, the communications device can receive an indication of reduced network traffic (block 644). Upon receiving the indication of reduced network traffic, the communications device can send the refined data to the recorder (block 646).
One should note that other embodiments may provide that any component within the IP telephone network through which some or all of the audio content of a call passes is configured to process and record media streams. This can include trunk interface cards, conference bridges, voicemail and other servers, routing components trans-coding components etc. Additionally, in still other embodiments, the communications device can, if instructed, merge the two data streams (incoming and outgoing data streams) into a single data stream. This may be accomplished by encapsulating a pair of packets (such as RTP packets) inside a User Datagram Protocol (UDP) payload. Many techniques place two RTP packets in the payload of a UDP packet, preceded by two by 16 bit length fields indicating the length of each RTP
packet. At least one embodiment of the present disclosure includes removing the redundant information in the RTP packet header (e.g., the source of one is the destination of the other).
FIG. 7 is a flowchart illustrating exemplary steps that can be taken by a communications device for lossy recording of a communication in a communications network, such as the network from FIG. 3. More specifically, the first step in the nonlimiting example of FIG. 7 is for the communication device to receive a recording instruction (block 730). Next, the communications device can receive packet data related to a communication (block 732). Once the communications device has received the recording instruction and data related to the communication, the communications device can copy at least a portion of the packet data related to the communication (block 734).
Next, the communications device can compress the copied data (block 736).
The compression can take the form of G729A, 6711, or other compression format.
Once the data is compressed, the communications device can store the compressed data (block 738) for subsequent delivery. The communications device can send the uncompressed data to the third party (to whom the user is communicating), as illustrated in block 740. Then, the communication device can receive an indication of reduced network traffic (block 742) and send the compressed data to the recorder (block 744).
One should note that since the recording device is generally a receive-only device, echo is generally not a concern when recording. Therefore, there is generally no hard real-time requirement on transmission time or fitter. Hence at least one embodiment of the communications device can be configured support an option to send traffic to the recorder as "data" rather than "real-time" packets (e.g.
if using Quality of Service graded networks, the traffic to the recording device need not be marked as requiring rapid delivery). This allows the recorder traffic to co-exist on limited bandwidth networks with the real VoIP traffic and not degrade the service experienced by the VoIP calls. The communications device is configured to send traffic at times of reduced network traffic, thereby giving priority to the real-time voice traffic.
FIG. 8 is a flowchart illustrating exemplary steps that can be taking by a remote recording device for recording a communication in a communications device, such as the communications network from FIG. 3. The first step in the nonlimiting example of FIG. 8 is for the recording device to receive an indication of a communication (block 830). Depending on the particular configuration, an indication of a communication may or may not include a record request. Once the call indication is received, the recording device sends a record instruction with a destination address (block 832). In at least one embodiment, the destination address includes an address for sending data to the recording device. Once the record instruction is sent, the recording device can receive data related to the communication (block 834) and store the received data (block 836).
Additionally, embodiments of the communications device can, if instructed, forward packets containing mixed audio of the transmitted and received streams. As the communications device can be configured to decompress incoming packets and is responsible for any compression of outgoing packets, the communications device may already have access to the uncompressed audio and hence can mix these data streams (as the communications device does when applying side-tone to the received audio the communications device plays via the ear piece). Instead of forwarding the raw contents of the RTP packets, the communications device can be configured to take (a) audio that has been converted into linear form and ready for output to the handset/speaker and (b) audio the communications device has collected from the microphone and is in linear format prior to compression. The communications device can be configured to add (a) and (b) together to provide the mixed audio signal. The communications device can then compress this mixed data (using the compression format, if any, requested by the recorder) and place this in RTP packets for transmission to the recorder. Further, as communications devices generally support a range of compression formats, and with Digital Signal Processing (DSP) power increasing to the point where there is spare processing power available, the communications device can be instructed to compress the audio (whether split or mixed) before packetizing and sending the audio data to the recorder. As a lower quality of audio is often acceptable in a recording than in a live call, a more aggressive compression format is applied to the recorded stream than was applied to the original audio. This can result in reduced bandwidth consumption during recording.
One should also note that rather than forward RTP packets to the recorder, at least one embodiment of the communications device can be configured to support the establishment of a reliable connection to the recorder (e.g. full TCP/IP
socket connection). This allows the packets being sent to the recorder (a) to be received reliably with retransmission being handled by the TCP stack (a critical requirement in some recording applications) and (b) allows this recording stream to traverse the network at a lower Quality of Service threshold than the VoIP calls. This means that the network does not have to be capable of supporting the sum of live plus recorded traffic at the same high quality generally utilized in VoIP calls.
Additionally, embodiments of the communications device are configured to establish contact with the recorder and accept subsequent instructions (e.g. start/stop, mix, compress, buffer) directly from the recorder, rather than having these commands delivered via the other components of the telephone system. Still other embodiments of the communications device are configured to support multiple concurrent and independent requests for forwarding/copying/buffering of data from multiple recorders. This allows, as a nonlimiting example, live monitoring and recording concurrently. The communications device can be configured to perform the forwarding operation as many times and to as many different addresses as requested. This also works well for live backups (where recordings are sent to two different locations in real time) These techniques are often more secure than having one recorder store the data and then copy that data to another location.
This technique can usefully exploit the normally spare bandwidth that may be available between a satellite site and the backup parent site (i.e., WAN
designed to have traffic communicated from A to B but has additional capacity to communicate data from A to C to allow continued operation in the event of failure of site B. This bandwidth is often otherwise unused and it may be desirable for A to send data to both B and C than to have the data copied from B to C at a later time.
In addition to sending audio content of the communication, embodiments of the communications device may also be configured to receive requests to forward details of the quality of the call, derived, for example, from the Real Time Control Protocol (RTCP) packets exchanged with the remote party on the call. In addition to sending the audio content of the communication, the communications device may also be forwarded details of the call. Information available to the communications device, whether made visible to the user or not, can be forwarded to the recorder.
Additionally, embodiments of the communications device can be configured to forward details of the user's interaction with the communications device and the recorder. As a nonlimiting example, embodiments of the communications device can be configured to forward data such as speed of dialing, time when the communications device goes off hook, etc. (i.e. events that do not form part of the normally recorded call).
Also included within the scope of this disclosure is packet loss detection and analysis. By analyzing the sequence numbers and timestamps of the RTP packets, one can determine the proportion of packets have been lost. Alarms can be raised should this exceed an acceptable threshold. Where two streams are sent from a device (those the device received and those the transmitted), it is possible to determine from the loss characteristics whether packet loss is occurring between the recorder and the device performing the duplication (in which case losses on the two streams should be comparable) or between the two devices engaged in the original communication (in which cases losses are heavier on one stream - that duplicating the packets received by the forwarding device - than on the other).
Additionally included within the scope of this disclosure is quantification of packet transmission statistics. In addition to forwarding the packets (such as RTP
packets), if the forwarding device can also be configured to forward the RTCP
packets sent that relate to the original RTP link. The recorder can analyze this data to determine the quality of transmission between the original parties on the call. If RTCP is exchanged between the recorder and the forwarding device, it can determine the quality of that link. An overall quality level for the recording can therefore be determined. Where RTCP packets are forwarded, these can be wrapped inside a protocol and buffered with the RTP streams so as not to use much additional bandwidth or sockets en route to the recorder.
One should also note that the flowcharts included herein show the architecture, functionality, and operation of a possible implementation of software. In this regard, each block can be interpreted to represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
One should note that any of the programs listed herein, which can include an ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device.
More specific examples (a nonexhaustive list) of the computer-readable medium could include an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). In addition, the scope of the certain embodiments of this disclosure can include embodying the functionality described in logic embodied in hardware or software-configured mediums.
It should be emphasized that the above-described embodiments are merely possible examples of implementations, merely set forth for a clear understanding of the principles of this disclosure. Many variations and modifications may be made to the above-described embodiments) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure.
Claims (20)
1. A method for recording in an Internet Protocol (IP) environment, comprising:
receiving data related to a communication;
generating a copied version of at least a portion of the received data;
modifying the copied version of the received data; and sending at least a portion of the modified copied version of the received data to a recording device.
receiving data related to a communication;
generating a copied version of at least a portion of the received data;
modifying the copied version of the received data; and sending at least a portion of the modified copied version of the received data to a recording device.
2. The method of claim 1, wherein modifying the copied version of the received data includes lossless compression.
3. The method of claim 1, wherein modifying the copied version of the received data includes combining at least two packets associated with the copied version of the received data.
4. The method of claim 1, wherein modifying the copied version of the received data includes transmitting at least a portion of the modified copied version of the received data in intervals that are shorter than the received data is received
5. The method of claim 1, wherein modifying the copied version the copied version of the received data includes lossy compression
6. The method of claim 1, wherein modifying the copied version of the received data includes reducing a size component of at least one header associated with the copied version of the received data.
7. The method of claim 1, wherein modifying the copied version of the received data includes reducing quality of the copied version of the received data.
8. A computer readable medium for recording in an Internet Protocol (IP) environment, comprising:
logic configured to receive data related to a communication;
logic configured to generate a copied version of at least a portion of the received data;
logic configured to modify the copied version of the received data; and logic configured to send at least a portion of the modified copied version of the received data to a recording device.
logic configured to receive data related to a communication;
logic configured to generate a copied version of at least a portion of the received data;
logic configured to modify the copied version of the received data; and logic configured to send at least a portion of the modified copied version of the received data to a recording device.
9. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to execute lossless compression.
10. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to combine at least two packets associated with the copied version of the received data.
11. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to transmit at least a portion of the modified copied version of the received data in intervals that are shorter than the received data is received.
12. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to includes logic configured to execute lossy compression.
13. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to reduce a size component of at least one header associated with the copied version of the received data.
14. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to reduce quality of the copied version of the received data.
15. A communications device for facilitating a recording in an Internet Protocol (IP) environment, comprising:
logic configured to receive data related to a communication;
logic configured to generate a copied version of at least a portion of the received data;
logic configured to modify the copied version of the received data; and logic configured to send at least a portion of the modified copied version of the received data to a recording device.
logic configured to receive data related to a communication;
logic configured to generate a copied version of at least a portion of the received data;
logic configured to modify the copied version of the received data; and logic configured to send at least a portion of the modified copied version of the received data to a recording device.
16. The communications device of claim 15, wherein the logic configured to modify the copied version of the received data is further configured to execute lossless compression.
17. The communications device of claim 15, wherein the communications device includes at least one of the following: an Internet Protocol (IP) telephone, a softphone, a web conference enabled communications device, an email enabled communications device, and an instant messaging enabled communications device.
18. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to combine at least two packets associated with the copied version of the received data.
19. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to includes logic configured to execute lossy compression.
20. The computer readable medium of claim 8, wherein the logic configured to modify the copied version of the received data is further configured to reduce quality of the copied version of the received data.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/394,496 US7822018B2 (en) | 2006-03-31 | 2006-03-31 | Duplicate media stream |
US11/394,496 | 2006-03-31 |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2567514A1 true CA2567514A1 (en) | 2007-02-07 |
Family
ID=37728108
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002567514A Abandoned CA2567514A1 (en) | 2006-03-31 | 2006-11-07 | Duplicate media stream |
Country Status (2)
Country | Link |
---|---|
US (1) | US7822018B2 (en) |
CA (1) | CA2567514A1 (en) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10350353A1 (en) * | 2003-10-29 | 2005-06-02 | Siemens Ag | Method for effort limitation in the transmission of unidirectional information streams |
US8094803B2 (en) | 2005-05-18 | 2012-01-10 | Mattersight Corporation | Method and system for analyzing separated voice data of a telephonic communication between a customer and a contact center by applying a psychological behavioral model thereto |
US8094790B2 (en) | 2005-05-18 | 2012-01-10 | Mattersight Corporation | Method and software for training a customer service representative by analysis of a telephonic interaction between a customer and a contact center |
US8599747B1 (en) * | 2006-12-20 | 2013-12-03 | Radisys Canada Inc. | Lawful interception of real time packet data |
US8437465B1 (en) * | 2007-03-30 | 2013-05-07 | Verint Americas, Inc. | Systems and methods for capturing communications data |
US8718262B2 (en) | 2007-03-30 | 2014-05-06 | Mattersight Corporation | Method and system for automatically routing a telephonic communication base on analytic attributes associated with prior telephonic communication |
US8023639B2 (en) | 2007-03-30 | 2011-09-20 | Mattersight Corporation | Method and system determining the complexity of a telephonic communication received by a contact center |
US10419611B2 (en) | 2007-09-28 | 2019-09-17 | Mattersight Corporation | System and methods for determining trends in electronic communications |
WO2012029575A1 (en) * | 2010-08-30 | 2012-03-08 | ソニー株式会社 | Packet transmission control device, packet transmission control method, and program |
US9369570B1 (en) * | 2015-05-18 | 2016-06-14 | Nice-Systems Ltd | Concurrent recordings of telephonic interactions |
US10594861B2 (en) * | 2017-09-28 | 2020-03-17 | Plantronics, Inc. | Forking transmit and receive call audio channels |
Family Cites Families (170)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3594919A (en) * | 1969-09-23 | 1971-07-27 | Economy Co | Tutoring devices |
US3705271A (en) | 1971-03-26 | 1972-12-05 | Economy Co | Audio tutoring device including recording capability |
US4510351A (en) * | 1982-10-28 | 1985-04-09 | At&T Bell Laboratories | ACD Management information system |
US4684349A (en) * | 1984-02-15 | 1987-08-04 | Frank Ferguson | Audio-visual teaching system and method |
US4763353A (en) * | 1986-02-14 | 1988-08-09 | American Telephone And Telegraph Company | Terminal based adjunct call manager for a communication system |
US4694483A (en) | 1986-06-02 | 1987-09-15 | Innings Telecom Inc. | Computerized system for routing incoming telephone calls to a plurality of agent positions |
US5008926A (en) * | 1986-07-17 | 1991-04-16 | Efrat Future Technology Ltd. | Message management system |
US4924488A (en) * | 1987-07-28 | 1990-05-08 | Enforcement Support Incorporated | Multiline computerized telephone monitoring system |
US4815120A (en) * | 1987-07-28 | 1989-03-21 | Enforcement Support Incorporated | Computerized telephone monitoring system |
US5101402A (en) * | 1988-05-24 | 1992-03-31 | Digital Equipment Corporation | Apparatus and method for realtime monitoring of network sessions in a local area network |
US4953159A (en) * | 1989-01-03 | 1990-08-28 | American Telephone And Telegraph Company | Audiographics conferencing arrangement |
US5117225A (en) * | 1989-05-01 | 1992-05-26 | Summit Micro Design | Computer display screen monitoring system |
US5016272A (en) * | 1989-06-16 | 1991-05-14 | Stubbs James R | Home video system |
US5195086A (en) | 1990-04-12 | 1993-03-16 | At&T Bell Laboratories | Multiple call control method in a multimedia conferencing system |
US5311422A (en) * | 1990-06-28 | 1994-05-10 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | General purpose architecture for intelligent computer-aided training |
US5388252A (en) * | 1990-09-07 | 1995-02-07 | Eastman Kodak Company | System for transparent monitoring of processors in a network with display of screen images at a remote station for diagnosis by technical support personnel |
US5113430A (en) | 1990-10-01 | 1992-05-12 | United States Advanced Network, Inc. | Enhanced wide area audio response network |
AU9063891A (en) * | 1990-11-20 | 1992-06-11 | Unifi Communications Corporation | Telephone call handling system |
US5241625A (en) * | 1990-11-27 | 1993-08-31 | Farallon Computing, Inc. | Screen image sharing among heterogeneous computers |
US5239460A (en) * | 1991-01-03 | 1993-08-24 | At&T Bell Laboratories | Arrangement for motivating telemarketing agents |
US5475625A (en) | 1991-01-16 | 1995-12-12 | Siemens Nixdorf Informationssysteme Aktiengesellschaft | Method and arrangement for monitoring computer manipulations |
US5381470A (en) | 1991-05-28 | 1995-01-10 | Davox Corporation | Supervisory management center with parameter testing and alerts |
US5210789A (en) * | 1991-06-28 | 1993-05-11 | International Telecharge, Inc. | Interactive telephone operator terminal |
US5315711A (en) * | 1991-11-01 | 1994-05-24 | Unisys Corporation | Method and apparatus for remotely and centrally controlling a plurality of host processors |
US5267865A (en) | 1992-02-11 | 1993-12-07 | John R. Lee | Interactive computer aided natural learning method and apparatus |
JPH0612288A (en) * | 1992-06-29 | 1994-01-21 | Hitachi Ltd | Information processing system and monitoring method therefor |
GB2270581A (en) * | 1992-09-15 | 1994-03-16 | Ibm | Computer workstation |
JPH0772999A (en) * | 1992-10-20 | 1995-03-17 | Hewlett Packard Co <Hp> | Method and apparatus for monitoring of display screen event in screen-corresponding software application tool |
US5499291A (en) * | 1993-01-14 | 1996-03-12 | At&T Corp. | Arrangement for automating call-center agent-schedule-notification and schedule-adherence functions |
AU693462B2 (en) * | 1993-09-22 | 1998-07-02 | E-Talk Corporation | Method and system for automatically monitoring the performance quality of call center service representatives |
US5689641A (en) * | 1993-10-01 | 1997-11-18 | Vicor, Inc. | Multimedia collaboration system arrangement for routing compressed AV signal through a participant site without decompressing the AV signal |
US5347306A (en) | 1993-12-17 | 1994-09-13 | Mitsubishi Electric Research Laboratories, Inc. | Animated electronic meeting place |
US5396371A (en) * | 1993-12-21 | 1995-03-07 | Dictaphone Corporation | Endless loop voice data storage and retrievable apparatus and method thereof |
US5572652A (en) | 1994-04-04 | 1996-11-05 | The United States Of America As Represented By The Secretary Of The Navy | System and method for monitoring and controlling one or more computer sites |
US5918214A (en) * | 1996-10-25 | 1999-06-29 | Ipf, Inc. | System and method for finding product and service related information on the internet |
US5597312A (en) * | 1994-05-04 | 1997-01-28 | U S West Technologies, Inc. | Intelligent tutoring method and system |
US5465286A (en) | 1994-05-24 | 1995-11-07 | Executone Information Systems, Inc. | Apparatus for supervising an automatic call distribution telephone system |
US5784452A (en) * | 1994-06-01 | 1998-07-21 | Davox Corporation | Telephony call center with agent work groups |
US5590171A (en) | 1994-07-07 | 1996-12-31 | Bellsouth Corporation | Method and apparatus for communications monitoring |
US6130668A (en) | 1994-07-25 | 2000-10-10 | Apple Computer, Inc. | Supervisory control system for networked multimedia workstations that provides simultaneous observation of multiple remote workstations |
US5619183A (en) * | 1994-09-12 | 1997-04-08 | Richard C. Ziegra | Video audio data remote system |
US5982857A (en) | 1994-10-17 | 1999-11-09 | Apropros Technology | Voice recording method and system providing context specific storage and retrieval |
US6244758B1 (en) * | 1994-11-15 | 2001-06-12 | Absolute Software Corp. | Apparatus and method for monitoring electronic devices via a global network |
US6091712A (en) * | 1994-12-23 | 2000-07-18 | Applied Digital Access, Inc. | Method and apparatus for storing and retrieving performance data collected by a network interface unit |
US5742670A (en) * | 1995-01-09 | 1998-04-21 | Ncr Corporation | Passive telephone monitor to control collaborative systems |
US5696906A (en) | 1995-03-09 | 1997-12-09 | Continental Cablevision, Inc. | Telecommunicaion user account management system and method |
ATE330416T1 (en) | 1995-04-24 | 2006-07-15 | Ibm | METHOD AND APPARATUS FOR SKILL-BASED ROUTING IN A CALL CENTER |
US5721842A (en) * | 1995-08-25 | 1998-02-24 | Apex Pc Solutions, Inc. | Interconnection system for viewing and controlling remotely connected computers with on-screen video overlay for controlling of the interconnection switch |
US5748499A (en) * | 1995-09-19 | 1998-05-05 | Sony Corporation | Computer graphics data recording and playback system with a VCR-based graphic user interface |
US5884032A (en) * | 1995-09-25 | 1999-03-16 | The New Brunswick Telephone Company, Limited | System for coordinating communications via customer contact channel changing system using call centre for setting up the call between customer and an available help agent |
US6122668A (en) | 1995-11-02 | 2000-09-19 | Starlight Networks | Synchronization of audio and video signals in a live multicast in a LAN |
US5717879A (en) * | 1995-11-03 | 1998-02-10 | Xerox Corporation | System for the capture and replay of temporal data representing collaborative activities |
US5778182A (en) * | 1995-11-07 | 1998-07-07 | At&T Corp. | Usage management system |
US6052454A (en) * | 1996-01-16 | 2000-04-18 | Global Tel*Link Corp. | Telephone apparatus with recording of phone conversations on massive storage |
US5826014A (en) * | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
US6225993B1 (en) * | 1996-04-22 | 2001-05-01 | Sun Microsystems, Inc. | Video on demand applet method and apparatus for inclusion of motion video in multimedia documents |
US5727950A (en) * | 1996-05-22 | 1998-03-17 | Netsage Corporation | Agent based instruction system and method |
US6018619A (en) * | 1996-05-24 | 2000-01-25 | Microsoft Corporation | Method, system and apparatus for client-side usage tracking of information server systems |
US6370574B1 (en) | 1996-05-31 | 2002-04-09 | Witness Systems, Inc. | Method and apparatus for simultaneously monitoring computer user screen and telephone activity from a remote location |
US20030144900A1 (en) * | 2002-01-28 | 2003-07-31 | Whitmer Michael L. | Method and system for improving enterprise performance |
US5790798A (en) * | 1996-05-31 | 1998-08-04 | Witness Systems, Inc. | Method and apparatus for simultaneously monitoring computer user screen and telephone activity from a remote location |
US5907680A (en) * | 1996-06-24 | 1999-05-25 | Sun Microsystems, Inc. | Client-side, server-side and collaborative spell check of URL's |
US5862330A (en) * | 1996-07-16 | 1999-01-19 | Lucent Technologies Inc. | Technique for obtaining and exchanging information on wolrd wide web |
US6157808A (en) | 1996-07-17 | 2000-12-05 | Gpu, Inc. | Computerized employee certification and training system |
US5809247A (en) | 1996-07-22 | 1998-09-15 | Intel Corporation | Method and apparatus for guided touring of internet/intranet websites |
US5933811A (en) | 1996-08-20 | 1999-08-03 | Paul D. Angles | System and method for delivering customized advertisements within interactive communication systems |
US6014134A (en) * | 1996-08-23 | 2000-01-11 | U S West, Inc. | Network-based intelligent tutoring system |
US5923746A (en) * | 1996-09-18 | 1999-07-13 | Rockwell International Corp. | Call recording system and method for use with a telephonic switch |
WO1998013807A1 (en) | 1996-09-25 | 1998-04-02 | Sylvan Learning Systems, Inc. | Automated testing and electronic instructional delivery and student management system |
GB9620082D0 (en) * | 1996-09-26 | 1996-11-13 | Eyretel Ltd | Signal monitoring apparatus |
US5944791A (en) | 1996-10-04 | 1999-08-31 | Contigo Software Llc | Collaborative web browser |
US5809250A (en) | 1996-10-23 | 1998-09-15 | Intel Corporation | Methods for creating and sharing replayable modules representive of Web browsing session |
US6487195B1 (en) | 1996-10-23 | 2002-11-26 | Ncr Corporation | Collaborative network navigation synchronization mechanism |
US6039575A (en) * | 1996-10-24 | 2000-03-21 | National Education Corporation | Interactive learning system with pretest |
US5948061A (en) | 1996-10-29 | 1999-09-07 | Double Click, Inc. | Method of delivery, targeting, and measuring advertising over networks |
US5990852A (en) | 1996-10-31 | 1999-11-23 | Fujitsu Limited | Display screen duplication system and method |
US6335927B1 (en) * | 1996-11-18 | 2002-01-01 | Mci Communications Corporation | System and method for providing requested quality of service in a hybrid network |
US5864772A (en) * | 1996-12-23 | 1999-01-26 | Schlumberger Technology Corporation | Apparatus, system and method to transmit and display acquired well data in near real time at a remote location |
US5917489A (en) * | 1997-01-31 | 1999-06-29 | Microsoft Corporation | System and method for creating, editing, and distributing rules for processing electronic messages |
US6560328B1 (en) * | 1997-04-03 | 2003-05-06 | Genesys Telecommunications Laboratories, Inc. | Voice extensions in a call-in center employing virtual restructuring for computer telephony integrated functionality |
US5978648A (en) | 1997-03-06 | 1999-11-02 | Forte Systems, Inc. | Interactive multimedia performance assessment system and process for use by students, educators and administrators |
US5796952A (en) * | 1997-03-21 | 1998-08-18 | Dot Com Development, Inc. | Method and apparatus for tracking client interaction with a network resource and creating client profiles and resource database |
US6301573B1 (en) | 1997-03-21 | 2001-10-09 | Knowlagent, Inc. | Recurrent training system |
US6078894A (en) * | 1997-03-28 | 2000-06-20 | Clawson; Jeffrey J. | Method and system for evaluating the performance of emergency medical dispatchers |
US6578077B1 (en) | 1997-05-27 | 2003-06-10 | Novell, Inc. | Traffic monitoring tool for bandwidth management |
US6171109B1 (en) * | 1997-06-18 | 2001-01-09 | Adin Research, Inc. | Method for generating a multi-strata model and an intellectual information processing device |
US6282548B1 (en) | 1997-06-21 | 2001-08-28 | Alexa Internet | Automatically generate and displaying metadata as supplemental information concurrently with the web page, there being no link between web page and metadata |
JP2000513916A (en) * | 1997-06-25 | 2000-10-17 | サムソン エレクトロニクス カンパニー リミテッド | Method and apparatus for home network automatic tree generator |
US6014647A (en) * | 1997-07-08 | 2000-01-11 | Nizzari; Marcia M. | Customer interaction tracking |
US5958016A (en) | 1997-07-13 | 1999-09-28 | Bell Atlantic Network Services, Inc. | Internet-web link for access to intelligent network service control |
US6076099A (en) * | 1997-09-09 | 2000-06-13 | Chen; Thomas C. H. | Method for configurable intelligent-agent-based wireless communication system |
US5964836A (en) | 1997-09-11 | 1999-10-12 | International Business Machines Corporation | Apparatus, methods and computer program products for managing web-page-embedded sessions with a host-based application |
US5991373A (en) | 1997-09-15 | 1999-11-23 | Teknekron Infoswitch Corporation | Reproduction of a voice and video session |
US6108711A (en) | 1998-09-11 | 2000-08-22 | Genesys Telecommunications Laboratories, Inc. | Operating system having external media layer, workflow layer, internal media layer, and knowledge base for routing media events between transactions |
US6418471B1 (en) * | 1997-10-06 | 2002-07-09 | Ncr Corporation | Method for recording and reproducing the browsing activities of an individual web browser |
US6035332A (en) * | 1997-10-06 | 2000-03-07 | Ncr Corporation | Method for monitoring user interactions with web pages from web server using data and command lists for maintaining information visited and issued by participants |
US6546405B2 (en) * | 1997-10-23 | 2003-04-08 | Microsoft Corporation | Annotating temporally-dimensioned multimedia content |
US6351467B1 (en) * | 1997-10-27 | 2002-02-26 | Hughes Electronics Corporation | System and method for multicasting multimedia content |
US6009429A (en) | 1997-11-13 | 1999-12-28 | International Business Machines Corporation | HTML guided web tour |
US5987466A (en) | 1997-11-25 | 1999-11-16 | International Business Machines Corporation | Presenting web pages with discrete, browser-controlled complexity levels |
US6286046B1 (en) | 1997-12-22 | 2001-09-04 | International Business Machines Corporation | Method of recording and measuring e-business sessions on the world wide web |
US6005932A (en) | 1997-12-24 | 1999-12-21 | Rockwell Semiconductor Systems Inc. | Dynamic schedule profiler for ACD |
US6195679B1 (en) * | 1998-01-06 | 2001-02-27 | Netscape Communications Corporation | Browsing session recording playback and editing system for generating user defined paths and allowing users to mark the priority of items in the paths |
JP3371791B2 (en) * | 1998-01-29 | 2003-01-27 | ヤマハ株式会社 | Music training system and music training device, and recording medium on which music training program is recorded |
US6151622A (en) | 1998-02-02 | 2000-11-21 | International Business Machines Corp. | Method and system for portably enabling view synchronization over the world-wide web using frame hierarchies |
US6144991A (en) | 1998-02-19 | 2000-11-07 | Telcordia Technologies, Inc. | System and method for managing interactions between users in a browser-based telecommunications network |
US6138139A (en) | 1998-10-29 | 2000-10-24 | Genesys Telecommunications Laboraties, Inc. | Method and apparatus for supporting diverse interaction paths within a multimedia communication center |
US6038544A (en) * | 1998-02-26 | 2000-03-14 | Teknekron Infoswitch Corporation | System and method for determining the performance of a user responding to a call |
US20010043697A1 (en) | 1998-05-11 | 2001-11-22 | Patrick M. Cox | Monitoring of and remote access to call center activity |
US6154771A (en) | 1998-06-01 | 2000-11-28 | Mediastra, Inc. | Real-time receipt, decompression and play of compressed streaming video/hypervideo; with thumbnail display of past scenes and with replay, hyperlinking and/or recording permissively intiated retrospectively |
US6347374B1 (en) * | 1998-06-05 | 2002-02-12 | Intrusion.Com, Inc. | Event detection |
EP1090505A1 (en) * | 1998-06-26 | 2001-04-11 | General Instrument Corporation | Terminal for composing and presenting mpeg-4 video programs |
US6229887B1 (en) * | 1998-07-09 | 2001-05-08 | Bell Atlantic Network Services, Inc. | Advanced intelligent network (AIN) functionality for electronic surveillance |
US6286030B1 (en) | 1998-07-10 | 2001-09-04 | Sap Aktiengesellschaft | Systems and methods for recording and visually recreating sessions in a client-server environment |
US6122665A (en) | 1998-08-26 | 2000-09-19 | Sts Software System Ltd. | Communication management system for computer network-based telephones |
FR2782875B1 (en) | 1998-08-27 | 2000-11-03 | France Telecom | TELEPHONE DEVICE FOR PRISON |
US6493758B1 (en) | 1998-09-08 | 2002-12-10 | Microsoft Corporation | Offline viewing of internet content with a mobile device |
TW430147U (en) * | 1998-11-02 | 2001-04-11 | Hon Hai Prec Ind Co Ltd | Electrical connector and its locking device |
US6411989B1 (en) * | 1998-12-28 | 2002-06-25 | Lucent Technologies Inc. | Apparatus and method for sharing information in simultaneously viewed documents on a communication system |
US6353851B1 (en) * | 1998-12-28 | 2002-03-05 | Lucent Technologies Inc. | Method and apparatus for sharing asymmetric information and services in simultaneously viewed documents on a communication system |
US6360250B1 (en) * | 1998-12-28 | 2002-03-19 | Lucent Technologies Inc. | Apparatus and method for sharing information in simultaneously viewed documents on a communication system |
US6236977B1 (en) * | 1999-01-04 | 2001-05-22 | Realty One, Inc. | Computer implemented marketing system |
US6301462B1 (en) | 1999-01-15 | 2001-10-09 | Unext. Com | Online collaborative apprenticeship |
US6370547B1 (en) * | 1999-04-21 | 2002-04-09 | Union Oil Company Of California | Database correlation method |
US6606657B1 (en) | 1999-06-22 | 2003-08-12 | Comverse, Ltd. | System and method for processing and presenting internet usage information |
US6288753B1 (en) | 1999-07-07 | 2001-09-11 | Corrugated Services Corp. | System and method for live interactive distance learning |
US6289340B1 (en) | 1999-08-03 | 2001-09-11 | Ixmatch, Inc. | Consultant matching system and method for selecting candidates from a candidate pool by adjusting skill values |
US6665644B1 (en) | 1999-08-10 | 2003-12-16 | International Business Machines Corporation | Conversational data mining |
US6772396B1 (en) | 1999-10-07 | 2004-08-03 | Microsoft Corporation | Content distribution system for network environments |
US6823384B1 (en) | 1999-10-15 | 2004-11-23 | James Wilson | Methods and apparatus for securely collecting customer service agent data in a multi-tenant environment |
US6792575B1 (en) | 1999-10-21 | 2004-09-14 | Equilibrium Technologies | Automated processing and delivery of media to web servers |
US6901438B1 (en) * | 1999-11-12 | 2005-05-31 | Bmc Software | System selects a best-fit form or URL in an originating web page as a target URL for replaying a predefined path through the internet |
US6535909B1 (en) * | 1999-11-18 | 2003-03-18 | Contigo Software, Inc. | System and method for record and playback of collaborative Web browsing session |
US6674447B1 (en) * | 1999-12-06 | 2004-01-06 | Oridus, Inc. | Method and apparatus for automatically recording snapshots of a computer screen during a computer session for later playback |
US7613695B1 (en) | 1999-12-06 | 2009-11-03 | Reed Elsevier Inc. | Relationship management system that provides an indication of users having a relationship with a specified contact |
US6959078B1 (en) | 2000-01-24 | 2005-10-25 | Verint Systems Inc. | Apparatus and method for monitoring and adapting to environmental factors within a contact center |
IL141002A0 (en) | 2000-01-24 | 2002-02-10 | Comverse Infosys Inc | Open storage portal apparatus and method to access contact center information |
US6724887B1 (en) * | 2000-01-24 | 2004-04-20 | Verint Systems, Inc. | Method and system for analyzing customer communications with a contact center |
US6810414B1 (en) | 2000-02-04 | 2004-10-26 | Dennis A. Brittain | System and methods for easy-to-use periodic network data capture engine with automatic target data location, extraction and storage |
US6542602B1 (en) * | 2000-02-14 | 2003-04-01 | Nice Systems Ltd. | Telephone call monitoring system |
US6324282B1 (en) | 2000-03-02 | 2001-11-27 | Knowlagent, Inc. | Method and system for delivery of individualized training to call center agents |
US6775377B2 (en) | 2001-09-10 | 2004-08-10 | Knowlagent, Inc. | Method and system for delivery of individualized training to call center agents |
WO2001067267A1 (en) | 2000-03-03 | 2001-09-13 | Jones Lawrence R | Picture communications system and associated network services |
US6683633B2 (en) * | 2000-03-20 | 2004-01-27 | Incontext Enterprises, Inc. | Method and system for accessing information |
US6668044B1 (en) * | 2000-07-19 | 2003-12-23 | Xtend Communications Corp. | System and method for recording telephonic communications |
US6697858B1 (en) * | 2000-08-14 | 2004-02-24 | Telephony@Work | Call center |
EP1189161A1 (en) * | 2000-09-13 | 2002-03-20 | iMediation, S.A. | A method and system for managing network-based partner relationships |
US7287071B2 (en) * | 2000-09-28 | 2007-10-23 | Vignette Corporation | Transaction management system |
US20020065911A1 (en) * | 2000-10-03 | 2002-05-30 | Von Klopp Ana H. | HTTP transaction monitor with edit and replay capacity |
AU2002235147A1 (en) * | 2000-11-30 | 2002-06-11 | Webtone Technologies, Inc. | Web session collaboration |
WO2002048830A2 (en) | 2000-12-11 | 2002-06-20 | Phlair, Inc. | System and method for detecting and reporting online activity using real-time content-based network monitoring |
US20020143925A1 (en) | 2000-12-29 | 2002-10-03 | Ncr Corporation | Identifying web-log data representing a single user session |
US7506047B2 (en) * | 2001-03-30 | 2009-03-17 | Bmc Software, Inc. | Synthetic transaction monitor with replay capability |
US6944660B2 (en) | 2001-05-04 | 2005-09-13 | Hewlett-Packard Development Company, L.P. | System and method for monitoring browser event activities |
US20040100507A1 (en) * | 2001-08-24 | 2004-05-27 | Omri Hayner | System and method for capturing browser sessions and user actions |
US6738456B2 (en) * | 2001-09-07 | 2004-05-18 | Ronco Communications And Electronics, Inc. | School observation and supervisory system |
US6870916B2 (en) * | 2001-09-14 | 2005-03-22 | Lucent Technologies Inc. | Targeted and intelligent multimedia conference establishment services |
US20030079020A1 (en) * | 2001-10-23 | 2003-04-24 | Christophe Gourraud | Method, system and service provider for IP media program transfer-and-viewing-on-demand |
US6965886B2 (en) | 2001-11-01 | 2005-11-15 | Actimize Ltd. | System and method for analyzing and utilizing data, by executing complex analytical models in real time |
US6801618B2 (en) | 2002-02-08 | 2004-10-05 | Etalk Corporation | System and method for implementing recording plans using a session manager |
US6987849B2 (en) * | 2002-04-09 | 2006-01-17 | Tekelec | Method and systems for intelligent signaling router-based surveillance |
US7535993B2 (en) * | 2003-04-21 | 2009-05-19 | Alcatel-Lucent Usa Inc. | Call control component employment of one or more criteria for internet protocol call selection for eavesdrop component monitoring |
US20050138560A1 (en) | 2003-12-18 | 2005-06-23 | Kuo-Chun Lee | Method and apparatus for broadcasting live personal performances over the internet |
KR100592907B1 (en) * | 2003-12-22 | 2006-06-23 | 삼성전자주식회사 | Wireless internet terminal and method for transmitting packet to enhance QoS |
US20060227721A1 (en) * | 2004-11-24 | 2006-10-12 | Junichi Hirai | Content transmission device and content transmission method |
US20070104096A1 (en) * | 2005-05-25 | 2007-05-10 | Lga Partnership | Next generation network for providing diverse data types |
US7778169B2 (en) * | 2005-09-02 | 2010-08-17 | Cisco Technology, Inc. | Packetizing media for a time slotted communication system |
US7548995B2 (en) * | 2005-10-21 | 2009-06-16 | Microsoft Corporation | Strategies for disseminating media information using redundant network streams |
US8677002B2 (en) * | 2006-01-28 | 2014-03-18 | Blackfire Research Corp | Streaming media system and method |
US20070183415A1 (en) * | 2006-02-03 | 2007-08-09 | Utstarcom Incorporated | Method and system for internal data loop back in a high data rate switch |
-
2006
- 2006-03-31 US US11/394,496 patent/US7822018B2/en active Active
- 2006-11-07 CA CA002567514A patent/CA2567514A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US7822018B2 (en) | 2010-10-26 |
US20070258434A1 (en) | 2007-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7822018B2 (en) | Duplicate media stream | |
US8713167B1 (en) | Distributive data capture | |
US7751316B2 (en) | Relay Server for SIP/RTP messages with buffer management | |
US8442033B2 (en) | Distributed voice over internet protocol recording | |
US7873035B2 (en) | Method and apparatus for voice-over-IP call recording and analysis | |
US7548609B2 (en) | Process for scalable conversation recording | |
JP2007049415A (en) | Voice data conversion apparatus, network system, and control method and program | |
WO2008042730A2 (en) | Systems and methods for recording in a customer center environment | |
US8275944B1 (en) | Distributive network control | |
Flanagan | VoIP and unified communications: internet telephony and the future voice network | |
JP2007282004A (en) | Voice monitoring and recording system, and method therefor | |
US9973402B2 (en) | Transmission device, receiving device, and relay device | |
US20060265088A1 (en) | Method and system for recording an electronic communication and extracting constituent audio data therefrom | |
US7899040B2 (en) | Synchronization of event processing at a media gateway | |
US20080008296A1 (en) | Data Capture in a Distributed Network | |
JP2011071853A (en) | Ip telephone system, communication content recorder and communication method | |
JP2008271415A (en) | Received voice output apparatus | |
US20040076150A1 (en) | Method and apparatus for storing a media file | |
CN112866178B (en) | Method and device for transmitting audio data | |
KR101051271B1 (en) | Personal call recording device for 단말 oIP terminal | |
CN114979385A (en) | Voice transmission method, device, equipment and medium | |
CN114927138A (en) | Network telephone processing method, system, equipment and storage medium | |
CA2600378C (en) | Systems and methods for recording in a customer center environment | |
JP2005210519A (en) | Maintenance device for maintaining ip telephone terminal, ip telephone system, and recording medium storing program | |
JP2006333524A (en) | Call control server and voice data communication method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Dead |