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 platforms 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 third 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 SRS.

SIPREC recording session flow

The Session Recording Client has access to media path between the user agents. The SRC then establishes the recording session with the SRS and sends replicated media towards the SRS. The SRC is also responsible 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,a 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 cloud service providers. They can utilize SIPREC functionality on their SBCs to record calls. In this configuration, the recording service is located within the Enterprise's network.

SIPREC recording hosted multitenant

Service Providers may deploy SIPREC based recording solutions within their own datacenter. Such deployment model allows 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 one 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 provided 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. Service Providers can 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 SIPREC is based on the SIP protocol, it supports field-proven techniques like DNS SRV for load balancing and autofailover.

Besides that, many 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 one 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 server 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 simple recording scenarios, the SIPREC-compatible system from one vendor should be easily replaceable with another vendor's system, whether it is the phone platform (SRC role) or the recording system (SRS role).

In the real world, this 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 an 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 designed to receive RTP packets in unexpected codec. Another example, one big player was an early adopter of the SIPREC standard. They implemented the early draft version of SIPREC protocol in their own product. The final version of SIPREC protocol received some backward-incompatible modifications. Due to a large deployment base, the vendor sticks to the old version of SIPREC protocol.

Tags:

siprec