A significant part of the Threads functionality is its ability to transcribe phone calls so that they may be summarised and searched. Challenging as speech transcription is, Threads must first ingest the digitised speech from the phone call and this process that can be equally challenging.
In an office environment, calls are handled by a device called a Private Branch Exchange or PBX which connects employees to each other and their office telephone network to the Public (switched) telephone network or PSTN. 20 years ago, calls were typically routed through dedicated telephony networks but nowadays most telephony data is routed over the Internet following a set of rules (also called a protocol) known as the Voice over Internet Protocol or VoIP. The need for the PBXs still exists but the majority of offices use their existing local area networks (LANs) instead of dedicated wiring. The PBX functionality is provided by software which runs on computers in the Cloud so that many offices now require only internet accessible handsets or other devices that simulate handsets. Their connection to LAN may be by cables or wifi. The need for a physical PBX device is completely obviated.
In order for Threads to ingest calls for transcription and storage, it must connect to the PBX. Since there are many hundreds of PBX manufacturers, each with their own standards, it is impractical to write “plug-ins” to ingest calls from all these disparate PBXs. Not only do these PBXs use different methods to export calls, they all have different ways of managing call flow. In an office situation, calls may be internal or external; transferred between several staff; parked; transferred to voicemail or routed in some other way. In order that the call transcription is accessed only by authorised, relevant staff, Threads must keep accurate track of call transfers. This task is almost as complicated as the transcription itself and to support every PBX manufacturer would have made an impractical task almost impossible.
The original solution for Threads was to intercept calls as they passed around the subscribers LAN and route those calls of interest directly to the subscriber’s Threads server in the Cloud. This made Threads agnostic of the PBX manufacturer because there is an open standard for delivering VoIP calls, called the Session Initiation Protocol or SIP – which manufacturers must adhere to when using the Internet as the transport medium. Although the interception of SIP packets at the network level was a neat solution, it did require some hardware to ingest (or sniff) the calls from the LAN. Furthermore, such is the design of modern LANs that the point where calls are picked up is crucial. Simply sniffing the network at some random point will likely miss most of the SIP traffic.
The need to host dedicated hardware at a specific physical location can make Threads an unviable proposition for some prospective subscribers, hence we looked at the possibility of making the “soft” integration of Threads to Cloud-based PBX systems. As such, Threads operates entirely from its Internet access.
Our first choice was the open source PBX called FreePBX and its commercial variant PBXact (hereafter we refer to both products as FreePBX). FreePBX is a complete system which provides all the facilities necessary to run and manage a private branch exchange. At its heart (and the cause of much confusion) is another open source product called Asterisk. Asterisk essentially provides the PBX functionality, while FreePBX provides the user interface to allow the PBX to be set up and managed.
While tightly coupling Threads to FreePBX does not imply compatibility with other PBX systems, it serves as a model on which to base other integrations where there is sufficient installed base and network sniffing solution is deemed impractical. As long as the PBX has an API which provides access to calls digitised at sufficient quality, Threads can be integrated.
FreePBX was chosen first for several reasons:
- It is open source software.
- It has one of the highest deployments of all PBXs in operation Worldwide today.
- The Canadian telephony company Sangoma coordinates the development of FreePBX and has significantly contributed to its evolution, popularity and robustness.
- It is the basis for many commercial telephone systems, including of course, those from Sangoma.
- It provides an Application Program Interface (API) that permits application programs such as Threads to extract digitised speech and data on call flow and manage the PBX.
- It provides the call flow information essential to establish the route and correct access permissions for call recordings and transcriptions.
- It provides access to SIP data at the lowest possible level – channel separated, high sample rate, uncompressed – and thereby allowing the best possible speech recognition performance.
FreePBX call flow analysis can be performed by analysing a database known as the Call Detail Record or CDR. However, while the CDR provides sufficient information for ad-hoc analysis, it is not suitable for operational transcription purposes. For this, analysis of the higher resolution Call Event List or CEL database is required.
Furthermore, since most existing FreePBX sites manage their PBX system – eg maintaining user directories and assigning handset extensions – using the FreePBX user interface, Threads administration has been extended to automatically synchronise with this. The following screenshots show examples of data shared with Threads…
As a result, Threads may be tightly integrated with FreePBX in such a way that users and administrators require virtually no training. Call recordings, transcribed calls and call summaries are emailed to relevant authorised staff soon after each call is completed. The fact that call transcriptions and summaries are stored in Threads as text files means that calls may be easily located by searching for keywords, a feature most users take for granted when searching emails. Indeed, for many subscribers, the ability to search telephone calls for keywords is as important as the transcription capability. And viewing the calls in the context of emails – Threads is a repository for any digital message, including emails – provides another very powerful way in which FreePBX may be utilised. However, searching calls is not an intrinsic feature of FreePBX so this needs to be done via the Threads user interface.
In addition to providing a call recording and transcription, Threads uses AI to summarise calls. This feature is extremely useful for browsing calls lasting more than a few minutes so as to establish if it is worth listening to the complete call. You can read a more detailed description of call summarisation on this blog post.
FreePBX provides a standardised way of integrating third-party applications. These are called FreePBX modules and we have developed one for Threads so that existing FreePBX users may quickly and easily connect Threads to their PBX. They also allow the module to automatically update itself when a new version is released.
Hopefully, this blog provides a brief overview of reasons behind the development of the Threads/FreePBX module and some of the engineering challenges, but for a more detailed overview, then we recommend watching Thomas Michel’s presentation at Astricon 2024.