We’re shouting from the rooftops about how speech analytics can be a game-changer for businesses. How so? This tech can extract content and contextual data from not just a sample of calls, but every call.
However, before you can get those sweet, state-of-the-art analytics from your voice interactions, you’ll need to make a recording first. The bad news is, it’s not always so easy. But the good news is that there’s a growing number of ways to do this easily and with great results.
There’s even an official standard for recording SIP calls known as SIPREC. In this post I’ll explain what SIPREC is and how you could use it to help start a speech analytics project.
In older commercial PBX and call center systems, recording was usually done in a proprietary manner. Recording on an Avaya system, for example, required an Avaya recorder or equipment from a vendor that had a specific Avaya implementation. As often happens, technological requirements continue to move quickly, making these systems obsolete. Call centers and telephony providers do not want to be tied into vendor-specific solutions or hardware that limit their flexibility.
To address the growing demand for recording, the Internet Engineering Task Force (IETF), the standardization body behind SIP, has spent the past eight years working on a new, standardized way to record calls. The main idea was that SIP devices should be able to send calls to another vendor’s recording device in a secure way. In 2016 and after 18 drafts, the working group ratified their work into a new standard known SIPREC.
How does SIPREC work?
The idea behind SIPREC is that users should be able record calls without interfering with the original call. In most situations, metadata about the caller and callee are needed to identify customers and employees associated with the call. So we’re talking about the call center agent name and the caller ID.
The SIPREC architecture achieves these goals with three main components:
- Session Recording Client (SRC): This is a network element that copies the calls and metadata and sends them to be recorded.
- Session Recording Server (SRS): The recorder that receives the calls will save them to disk, and ties in any associated metadata.
- Metadata: SIPREC standardizes common fields that can be sent in a standard XML format.
The structure typically looks something like this:
The SRC makes a copy of the caller and callee streams and sends them to the SRS along with metadata for both legs of the call. The diagram shows the caller and callee locally connected to the telephony infrastructure, but in reality, it does not matter how these calls come into the infrastructure – as long as they terminate there the SRC should be able to fork them.
The SIPREC Session Recording Client is supported in most popular commercial Session Border Controllers (SBCs). As the standard matured, it has turned from an obscure feature to one that is standard.
Like any new technology, SIPREC is not without its challenges. The biggest once is often in adding equipment that supports SIPREC. Most commercial SBCs can act as a SIPREC SRC, but they may not be configured to do so without additional licensing. Support for open source is relatively immature, too.
Since the specification has gone through so many revisions, there are a lot of scenarios that are not fully interoperable between vendors. Some systems do not automatically include the metadata you might care about or only support fields that are available in support older versions of the spec.
SIPREC at Voxbone
For users looking for the easiest way to record, they can use a Voxbone DID. But we recognize Voxbone may be one of many providers to our customers. In our mission to make speech analytics strangely simple but also provide 100% call coverage even if Voxbone is not handling the call. To that end, we introduced SIPREC support last year so that we can handle any call, even if it does not normally traverse Voxbone. In the diagram above, our recorder acts like an SRS.
After working through several commercial and open source implementations that were each very different, we concluded flexibility is critical. We have implemented an adaptable SIP engine for quick interoperability and can flexibly map any XML metadata that is sent to us.
Moving forward, we are very encouraged to see open source solutions provide a new alternative to the many commercial SIPREC systems out there. More entrants and use of SIPREC will benefit the entire ecosystem and bring more focus to this technology.
Interested in learning more about SIPREC or giving Voxbone’s cloud recording and speech analytics solution a try? Check us out at voxbone.ai.