Insight from Interactions

Lately, there seems to be a lot of discussion about voice over IP (VoIP) call recording technologies. I have received many questions from customers, and participated in many conversations about the pros and cons of various VoIP call recording options and the advances in emerging technologies in this area. I’ll try to recap the main points here in the hopes of bringing in a wider audience perspective.

The first method utilized for VoIP call recording was passive sniffing of media packets directly from the network gateways. Passive sniffing requires that gateways be configured to copy all network traffic to the recording system. The drawbacks of this method are limited scalability, and increased administration and security risks.

Next, Active VoIP Recording was introduced. In this method, telephony or network components provide an interface that enables the initiation of the recording session. Active VoIP recording can be divided into three options (from the oldest to the newest):

• Conference-based VoIP recording is the least attractive, in my view. It utilizes valuable conference resources and requires a change in the real-time transport protocol (RTP) path, forcing every recorded call to go through the forking entity (media gateway).
• Forking by phone (or end points) seems to be a better option, but also has some disadvantages. It requires triple uplink bandwidth (between branches and the data center), as well as special, more expensive phones.
• The third option is most promising — VoIP call recording that forks by network components (router, session border controller [SBC] or gateway).  This method reuses components that are already in the call’s path and hence presents the most efficient and cost-effective option. I’m calling this option “Recording in the Network.”

 The main concept behind Recording in the Network (RiN) is to capture media directly from the network layer (gateways, switches, SBC, media servers), either in the enterprise or provider’s network, and correlate it with call information received from the enterprise application layers.

Conference and phone-based VoIP recording technologies rely on PBX vendors to provide VoIP signaling and media, however this is not always feasible or optimal. With Recording in the network this is done by integrating with the network infrastructure layer and therefore bypassing PBX interfaces, which also greatly reduces PBX licensing fees.

In addition, when recording of IVR interactions is required, the local PBX is not aware of such interactions. The only way to record them is to capture media from the SBC or gateway, and receive the CTI data directly from the IVR. In this type of integration interoperability is a critical requirement, both from customers and vendors.

NICE understands the importance of interoperability and believes that Recording in the Network is the optimal practice.  NICE actively participates in the IETF (Internet Engineering Task Force, see my previous post – Session Recording Protocol), which sets standards for VoIP call recording and other common industry practices. We submit proposals for standards and best practices, seeking to guide the evolution of VoIP recording toward a practical method for all organizations that rely on stored VoIP calls for regulatory compliance, quality management or for other reasons.

One of the most exciting projects that I am working on right now is the IETF (Internet Engineering Task Force) draft for the standardization of session recording interfaces. The main idea behind this work is to take the opportunity – while almost all major telephony vendors are working on session initiation protocol (SIP)-based recording interfaces for their new SIP-based voice over Internet Protocol (VoIP) telephony systems – to create an interoperable standard for call recording.

Currently, the lack of standard call recording protocol limits the adoption of IP telephony in enterprises. There are many existing proprietary, non-interoperable protocols; migrating them to an interoperable standard will serve the interests of vendors and customers alike. Not surprisingly, then, the authors of this standardization draft are leading architects from all major telephony vendors, including Acme Packets, Alcatel-Lucent, Avaya, Cisco, IPC, Siemens, and of course NICE.

In one or two years from now, most requests for proposals (RFPs) will include demands from clients to comply with the Session Recording Protocol standard. Is there a down side?

Let me know what’s your view on this.