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.
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 220.127.116.11
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.
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.
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:
|cat||Signal category. For audio masking, this value is always 0x04|
|type||The type of signal. Valid values for 0x04-categorysignals are:|
|objtype||The type of object that this signal relates to. This can be one of two values:|
|objid||The 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
|key||Specifies 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:
|200||The signal was received and stored successfully|
|400||The request was not acceptable for one of the following reasons:|
|404||The object specified by the combination of the objtype and objid parameters - and optionally the key parameter - could not be found|
|500||Internal 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|