Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current ·  View Page History

Throughout this guide, we will adopt the PCI-DSS example above, where telephone calls that contain spoken credit card information need to be masked out by an audible tone, but only during those parts of the call when the card details are being spoken, leaving intact the rest of the call audio.

In this scenario, we will assume that agents (employees that make or receive telephone calls) utilise an in-house or third-party data entry system into which credit card detailed are entered using a computer.

How it works

Considering TIM Plus (in conjunction with one or more Magic boxes) records the call audio at strategic boundaries in your telecom infrastructure - usually your organisation's telephone lines, rather than each user's telephone handset - some reconciliation is normally required between those boundaries and the actual agent that handled the call.

By default, this reconciliation occurs automatically in TIM Plus, which is how the agent-centric calls that you see in call reports are able to be associated (matched) with each call, as seen from the point of view of a telephone line which delivers calls to many agents.

During obfuscation, it is necessary that a user or device sends at least two signals to TIM Plus. Together, these two signals allow TIM Plus to mask out the audio between the two points in time that each signal was received.


At the point in time during an agent's call when obfuscation is necessary - e.g. "Can I have your CVV number please?" is spoken by the agent - a signal is sent by the agent to TIM Plus, which records the event along with the exact time it was sent. Similarly, when the sensitive part of the call has completed, a further signal is sent by the agent to TIM Plus, which is also being recorded.

A single telephone call can contain more than one obfuscation and the number of signals required is always twice the amount of obfuscations in a call.

Assumptions

This guide assumes the following statements are true:

  • You have a licensed copy of TIM Plus that includes voice recording
  • Your installation is at least version 3.0.0.55

Common solutions

Taking the example of masking out some digits of a phone call when a credit card number is being quoted, most solution providers modify the data entry system that an agent uses.

Implementation

HTTP request

To send a start or stop signal, a simple HTTP GET request must be sent to the TIM Plus web server.

Every request to the web server requires authentication, therefore you need to ensure that the relevant HTTP authentication headers are sent with your request and that the username and password combination match an existing web user object in the Directory.

The response status code will indicate success or failure.

Request format

The request should be a GET request and take the following URL- encoded parameters, as per the following example:

Valid parameters are described in the table below:

ParameterDescription
catSignal category. For audio masking, this value is always 0x04
typeThe type of signal. Valid values for 0x04-categorysignals are:
  • 0x01 Mute On
  • 0x02 Mute Off
objtypeThe type of object that this signal relates to. This can be one of two values:
  • user (a user object)
  • channel (a channel object)
objidThe unique ID of the object type as specified by the objtypeparameter (above). This is used to locate the object in the Directory

The region of the Directory to search in is specified by the key parameter (below) and governed by the access implied by the placement of the web user whose credentials are used to effect the web request

keySpecifies the key relating to a container object in the directory (or blank, implying the whole directory) whereby a search on the object specified by objtype and objid is performed below

Return values are specified as HTTP response status code. Although the body of some responses may contain informational text, you should not rely on this text to make any decisions as to whether the request was successful or not.

Valid status codes are as follows:

ParameterDescription
200The signal was received and stored successfully
400The request was not acceptable for one of the following reasons:
  • An invalid type parameter was specified. The type parameter is specific to the category specified by the cat parameter. Further, the type value (e.g. 0x01) can be used in multiple categories
  • The objid was missing. Specify the ID of the object you want the signal to relate to
  • The cat and type parameters - category and signal type, respectively - must be specified and cannot be zero
  • The version of TIM Plus you are running does not understand the signal.js script
404The object specified by the combination of the objtype and objid parameters - and optionally the key parameter - could not be found
500Internal Server Error prevented the signal from being stored successfully. This may be due to a badly-configured database, or the lack of a signals table in the TIM Plus database
Labels: