Call Recording in OpenSIPS 2.4 using SIPREC

The ability to record the calls that go through your platform is gradually shifting from being a feature to being a necessity. Whether you run a call center and you need it to monitor your agents’ activity,  to comply with your countries laws, or simply to improve your services, you need a recording solution that is simple to deploy and does not affect the quality of the calls. This article shows how you can achieve that using the new SIPREC module available starting with OpenSIPS 2.4.

First, let’s see the requirements for call recording and what are the existing solutions out there and how they are doing it.

Requirements

The most important requirement when doing call recording is to have control over the RTP/media stream of the call. To do this, we need to force the media go through one of our platform’s network equipment that we have access to and that we can use to peak and extract the RTP stream. Most of the PBXes out there are already doing this for Class 5 services, but a SIP proxy (such as OpenSIPS) does not have any media capabilities, thus it needs further help from a media server (such as RTPProxy, MediaProxy or RTPEngine).

After taking control of the RTP/media streams, we need to split them into several files, classify them based on different requirements and dump them in a persistent storage. In order to be able to search and filter them later, we need to annotate them with  certain meta-data. The following section shows you how you can do this based on the solutions you have.

Call Recording Methods

When talking about call recording, there are three possible ways to do it:

• Passive – done at the networking layer by sniffing the entire traffic and inspect the packets to gather metadata information about the actual call, as well as to determine which stream belongs to which call. This method is fairly easy to deploy ( by using SPAN or port mirroring, or simply by tapping the network interfaces) and it is non-intrusive, since recording is done asynchronously. However, the necessity to inspect each packet to determine whether it should be recorded or not and process it to determine to which call it belongs to, prevents you from having a scalable solution. Moreover, in terms of metadata, you are stuck with all the information that’s present “on the wire” – you cannot use external logic to group users or fetch additional user that’s not present in the messages.
• Active – the media server in the path of the call is recording the RTP packets that pass through it. Since the media already passes through the media server, it might as well dump it in a file. Using this solution, annotating metadata is quite simple, because you already have all the information used for routing, all you have to do is to attach it to the right RTP session. The downside of this solution is that it brings some overhead to the PBX/Media Server, thus a proper external load-balancing logic has to be implemented.
• External – very similar to the active model, but aims to solve the balancing and intrusion issues. Instead of using a single PBX/Media Server to do the call recording, you can send both the RTP stream and the metadata to an external server of your choice (determined by load balancing) and have it record the call without interfering with the ongoing call. This is how the SIPREC protocol works, as detailed in the following section.

SIPREC

SIPREC is an IETF standard that describes how to do call recording to an external recorder. It contains specifications about how to send both call metadata and RTP streams to the recorder in a send-only mode, without any impact on the ongoing call. The metadata transported through this protocol is very flexible, allowing you to organize recorded calls based on their participants (caller, callee), domain, type of call (inbound/outbound), the groups they belong to, etc.

The SIPREC module in OpenSIPS implements this protocol, offering the ability to do call recording for any call that is proxied through it. Being a standard, it can be used to integrate OpenSIPS with any call recorder that implements the protocol. Such a recorder is the Oreka open-source project, powered by Orecx, that is able to receive the SIPREC metadata and RTP stream and record the calls accordingly.

As stated earlier, OpenSIPS does not have media capabilities to fork traffic to the recorder, thus a media server such as RTPProxy is required. Below you can find a picture of all the components involved in the call recording process:

Oreka Total Recorder

Oreka TR is a web interface that allows you to access the recorded calls, categorize and  organize them, filter, and listen to the conversations. Based on the information provided by OpenSIPS from the signalling level, the Oreka TR can be used to:

• Record both plain and secure RTP (SRTP)
• Enable/Disable recording for specific users
• Playback recorded calls via browser
• Do quality management and live monitoring
• Categorize calls in groups
• Tag calls to filter easier
• Enhanced filters
• Recorded files management
• Encrypt recorded files

Other features provided by Oreka TR:

• Multi-tenant support for different levels of access
• An API to query the system
• Means to configure as an aggregator of multiple recording platform

The web interface is very intuitive – you can find a screenshot of the main page below:

Configuration

You can find here a full tutorial about how to setup OpenSIPS and RTPProxy to work with a SIPREC recorder. For the recorder configuration, check the Oreka Documentation page. For the Oreka TR documentation, check the product’s page for more details.

Acknowledgements

We would like to thank the OrecX team for sponsoring the development of the OpenSIPS SIPREC module, as well as for the support offered during the integration.