In this post we explain a little about business telephone systems and how Threads ingests phone calls so that they may be replayed and transcribed (using ASR) at will. A key feature of Threads call ingestion is that it happens transparently to the user and is totally independent of the telephone system in use. As a result, the Threads subscriber is not tied to one particular business telephone system manufacturer nor to require special software or plug-ins. We discuss how calls may be ingested from both landline and mobile networks.
1 Landline Networks **
We have discussed in an earlier blog post how Threads ingests emails. Although, once ingested, Threads treats phone calls and emails (or indeed any digital message) in the same way, the method by which it ingests these types of message differs. This is because phone calls and emails use different types of networks for connecting users. Emails are mostly exchanged via the Internet whereas historically in most business telephone systems, phone calls are routed via the Public Switched Telephone Network (PSTN) through a dedicated network of what are termed landlines – these are typically owned and managed by telephone network company such as British Telecom, AT&T, etc. However, the routing of email and phone calls is tending to converge to the Internet as the preferred medium for transfer.
Emails are exchanged as strings of text when the user connects an email client application to an email server. This could be a local server (ie in the subscribers offices) or a cloud-based server such as Gmail or Microsoft Office 365.
Phone calls are exchanged as streams of digitally encoded acoustic speech. The phone equivalent of the email server is called a branch exchange in the PSTN. Just like an email server, the branch exchange is responsible for routing the call to the correct user. For domestic subscribers, the branch exchange is commonly located at a geographically central location in a building called a telephone exchange. The telephone exchange typically connects calls to individual consumer telephones, however in an office environment where there may be many users that are called via a single telephone number, there will be the need for a Private Branch Exchange (PBX). Once a call has been connected to an office, then the PBX routes it to an individual handset (or extension).
The trend nowadays is for PBX systems to use an office’s digital data network (often called a Local Area Network or LAN) to connect handsets as opposed to the traditional method of dedicated wiring using analogue signals. All these legacy analogue phone systems are unique, so to ingest calls from them into Threads would require engineering effort for every individual system to be supported. Therefore the approach taken by Threads is to support only modern digital telephone systems using a protocol called Voice Over IP or VoIP – a standard now adopted by most telephone system manufacturers.
An additional benefit is that Threads can ingest phone calls from so-called “hosted” PBXs. In this case, the PBX is provided as a Cloud service and connections are made to the PSTN via the hosted PBX provider.
2. Ingesting calls
Ingesting calls is one of the single biggest obstacles to providing a call recording and transcription service and the main reason why so few companies have been able to adopt it. Not only must the call be captured, it must be captured at the highest possible fidelity to ensure the transcription algorithms have the best possible data to work with. Large corporations and dedicated call centres have the resources and business case to dedicate to bespoke systems for call ingestion, but the aim of Threads has always been to provide an off-the-shelf solution suitable for any sized company.
Threads offers two ways of ingesting calls, Direct Connection, and Network Packet Interception.
2.1 Direct Connection
Direct connection involves software that is able to extract calls directly from the PBX and channel them Threads. This connection is made using a PBX manufacturer supported Applications Programmer Interface or API which Threads uses to directly read calls from the PBX call recording files.
The benefit of this method is that it is completely “soft” and requires no physical connection to the subscribers network. However, there are several reasons why it cannot be universally used. For one thing, many PBX manufacturers do not provide an API, and for another, while some provide APIs, they do not store calls at sufficient fidelity for good transcription. Last but not least, there are hundreds of proprietary PBXs on the market and it would be impossible to support all of them.
The approach taken in Threads is to support and OpenSource product called FreePBX which as the name implies has massive worldwide adoption due to it being free, but also because a large number of commercial PBXs are based on it. FreePBX meets all the requirements necessary to ingest calls from both local and Cloud-based PBX systems. It is a high-quality fully maintained piece of software in many ways superior to commercial proprietary PBX systems.
2.2 Network Packet Interception
To cater for subscribers that cannot use FreePBX, mostly because they have a legacy telephone system,. Threads ingests VoIP traffic by intercepting VoIP traffic at the point at which is it routed to the internal or hosted PBX. Rather than re-invent the wheel, Threads uses tried and tested open source software developed by a company called Orecx. For local PBXs hosted on the subscriber’s premises, Orecx runs on a low-cost stand-alone server – typically a PC running Linux – or on a virtual machine.
There are also versions that run in the Cloud, for subscribers use Cloud-hosted PBXs. Although Orecx supports an open source version, we strongly recommend that Threads subscribers use the commercially supported version.
Threads ingests calls from Orecx using some software we call the Threads-Orecx Gateway. Once the Orecx server has been deployed, we install the Threads-Orecx Gateway on same machine. The digital speech as well as the accompanying metadata (addressing details) are then transferred to the Threads server in the Cloud for processing. Before being transferred, the data is optimally conditioned for speech recognition.
Threads-Orecx software collects VoIP traffic directly from subscriber’s hosted PBX and sendts to Threads server in the Cloud
3. Mobile phone networks
Much of the general architecture of landline networks applies to mobile phone networks. However, since these networks are mostly proprietary, mobile phone data cannot be ingested in the same way as that routed over the PSTN.
There are essentially 3 ways in which mobile phone data can be ingested by Threads;
- Redirection
- Mobile Virtual Network Operator (MVNO)
- Threads phone app
Threads is intended for cooperative interception of call data to assist in an organisation’s collaborative working. Therefore, all the privacy and security mechanisms for other types of messages apply the same, however, if the user wishes to obviate their use, the user may do so with ease.
3.1 Redirection
This technique involves routing mobile traffic via the subscriber’s LAN.
Incoming calls are redirected to the user’s mobile telephone. Callers are always given the landline number and the user sets up a redirect whenever not in the office.
Outgoing calls are made via the office. This is a simple a phone book in which all outgoing numbers are automatically prefixed with the subscriber’s office number. The office PBX is set to redirect the call on connection.
3.2 Mobile Virtual Network Operator (MVNO)
Many mobile phone operator’s offer a facility for subscribers to run their own (virtual) network. This uses the existing operators infrastructure but allows the subscriber to intercept the call traffic made via the network.
3.3 Phone app
This is a simple phone application which operates in a similar way to other personal messaging systems such as Whatsapp but intercepts traffic for ingestion. There is no current Threads phone app, but if this of interest, please let us know by contacting sales@threads.cloud.
Further Information
** For a more in-depth discussion of the relevant technology, please refer to Adopting an Open Source VoIP phone system