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

Overview

TIM Enterprise offers the ability to obfuscate (mask out) one or more sections of the audio of a telephone call with an audible tone, preventing the listener from hearing the original speech.

This is normally required for compliance in certain industries where regulations dictate that certain spoken information be masked out, e.g. the Payment Card Industry - Data Security Standard (PCI-DSS).

Throughout this guide, we'll 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'll 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

Because TIM Enterprise (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 reconcilliation occurs automatically by TIM Enterprise, 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 Enterprise. Together, these two signals allow TIM Enterprise 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 Enterprise, 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 Enterprise, which records that event too.

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

Assumptions

This guide assumes the following statements are true:

  • You have a licensed copy of TIM Enterprise that includes voice recording
  • Your installation is at least version 3.0.0.55
  • You have one or more Magic Boxes installed, each with their governing RTA Service

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 Enterprise web server.

Every request to the web server requires authentication, so 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 the search should be performed 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

The region of the Directory the search should be performed is specified by the key parameter (below) and it is governed by the directory access 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 Enterprise 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 Enterprise database.

 

 

 

 

 

Labels: