What is SIP Recording (SIPREC)?

The Session Recording Protocol (SIPREC) is an open SIP-based protocol for call recording. The standard is defined by Internet Engineering Task Force (IETF). It is supported by many phone platform and call recording system vendors.

Session Border Controllers (SBC) supporting SIPREC interface:

Hosted PBX platforms supporting SIPREC interface:

Overview of SIPREC protocol

The SIPREC standard defines a protocol used to interact between a Session Recording Client (SRC) (the role performed by PBX system or Session Border Controller) and a Session Recording Server (SRS) (a 3rd party call recorder, like MiaRec).

The following illustration shows two endpoints, sip user agents. The communications session is established through the Session Recording Client device. Their session is being recorded by an SRC and and SRS.

SIPREC recording session flow

The Session Recording Client has access to media path between the user agents. The SRC SRC then establishes the Recording Session with the SRS and sends replicated media towards the SRS. The SRC is responsible also for the delivery of metadata to the SRS, such as participant information (dialed phone number, callerid, etc.) in XML format. The standard permits also extension of the sent metadata. The vendors are free to send extra metadata attributes which are specific to their phone system. For example, BroadWorks sends "Service Provider ID", "Group ID" and "User ID" values. Metaswitch CFS sends "Business Group Name" and other attributes.

It should be noted, that an SRC is a logical function. Its capabilities may be implemented in a Session Border Controller , a SIP Media Gateway, SIP Phone or a SIP Media Server integrated with an Application Server.

Deployment models

The SIPREC based recording server could be deployed either on the Enterprise's premises or within the Service Provider network.

The following diagrams illustrate difference between these two models.

SIPREC recording enterprise premises

Many enterprises connect their local PBX system to SIP Trunk services from one of cloud service providers. They can utilize SIPREC function on their SBCs to record calls. In this configuration, the recording service is located within the Enterprise's network.

SIPREC recording hosted multitenant

The Service Providers may deploy SIPREC based recording solution within own datacenter. Such deployment model allows the Service Providers to offer the call recording as a hosted service.

The hosted deployment model has a number of benefits for both service providers and end users (enterprises):

Benefits for customers

Lower cost-of-ownership. The cost to deploy a premise-based recording system can be high, involving a large capital investment, and is typically out of reach for many small enterprises. The multi-tenant architecture of MiaRec allows to achieve economies of scale with consolidation of both IT personnel and hardware resources.
No upfront investments. Customers pay monthly fee. The call recording service is provides using Software-as-a-Service (SaaS) model
No administration/maintenance burden. The software is managed by Service Provider.

Benefits for Service Provider:

A hosted call recording service offers a high revenue generating opportunity for the service providers, allowing them to reach into new markets, attract new customers and expand their solutions portfolio.

Call recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. The Service Providers could gain a competitive advantage with the call recording service on such markets.

High availability

Most implementations of SIPREC protocol provide support of high availability architecture.

Because of SIPREC is based on SIP protocol, it supports the field-proven techniques, like DNS SRV for load balancing and auto-failover.

Besides that, many of phone platform vendors implement proprietary solutions for supporting multiple recording servers simultaneously. Usually, the configuration allows a setup a group of recording servers with some policies of load balancing and failover. The phone platform, for instance, the Session Border Controller, periodically checks the availability of each of recording servers in the group using some sort of ping (for example, by sending SIP OPTIONS message and checking the response). This mechanism allows the SBC to intelligently choose the "available" server in the group.

SIPREC recording high availability

Besides a support on the SRC side, the SRS needs to support data synchronization between servers in a cluster. Such data synchronization allows to achieve data redundancy (each call recording is stored on at least two servers simultaneously) as well as provide a single point of access to data and configuration (i.e. no need to access each of servers individually). MiaRec software supports multi-master asynchronous replication of data between servers.

Interoperability of SIPREC based solutions from different vendors

The SIPREC protocol is an open standard. Most vendors aim to follow the requirements of this standard.

In base recording scenarios, the SIPREC compatible system from one vendors should be easily replaceable with another vendor's system, whether it is the phone platform (SRC role) or the recording system (SRS role).

In real world, it is not always true.

First, many phone system vendors use proprietary extension to metadata. This additional metadata may be important for end users and the recording system needs to parse it and process appropriately. Thanks to open standard, this proprietary data is sent in plain-text XML format, usually self-descriptive.

Second, some implementations suffer from slight deviations from the standard. For example, at least two SBC vendors do not allow codec negotiation with the recording system, i.e. they silently ignore the SDP response from the recording system. The recording system should be prepared to receive RTP packets in non-expected codec. Another example, one of big players was an early adopter of the SIPREC standard. They implemented the early draft version of SIPREC protocol in own product. The final version of SIPREC protocol received some backward-incompatible modifications. Due to large deployment base, the vendor sticks to the old version of SIPREC protocol.

Tags:

siprec