Call Recording with SIP
Session Initiation Protocol Recording, or SIPREC for short, defines the architecture, associated call flows, and metadata that can be used for call recording.
"This call may be recorded for quality assurance."
Call into nearly any contact center on the face of the earth and you are going to hear that message. Companies use call recording for any number of purposes. Some, like financial institutions, are required by law to record certain transactions between their customers and employees. Others use call recording to improve agent performance and increase customer satisfaction. No matter what the reason, recording inbound and outbound calls is expected for most customer care interactions.
I began my career well before SIP and remember trunk-side recording with TDM taps. These taps were devices that split a T1 into two links. One went to the PBX and the other to a call recorder. They were effective, but required a tapping device for every T1 line.
With the advent of SIP, we are able to move away from T1s and their channelized DS1s and DS0s to a network connection where the number of trunks is limited only by the amount of available bandwidth.
Tapping into a dedicated line is no longer an option with SIP. Ethernet and MPLS are not physical mediums that lend themselves to hardware taps. We need a new way to perform trunk-side recording.
As with many questions related to SIP, the answer is the Session Border Controller. It is, after all, the device that sits between the carrier and your enterprise. Can you think of a better place to "tap" into a SIP call and simultaneously send it to a call recorder and your communications system? I can't.
To help the SBC with the job of call recording, the IETF (Internet Engineering Task Force – the folks who manage SIP and many of the Internet protocols) came up with a framework that manufacturers of SBCs and call recorders can follow. Session Initiation Protocol Recording, or SIPREC for short (RFC 6341), defines the architecture, associated call flows, and metadata that can be used for call recording.
SIPREC identifies two players involved in call recording – the Session Recording Client (SRC) and the Session Recording Server (SRS). Although SIPREC doesn't limit the SRC and SRS to specific entity types, for the purposes of trunk-side recording, it is safe to say that the SRC is an SBC and the SRS is a call recording platform such as one provided by Verint or Nice.
There are no new SIP message types to support SIPREC. SIPREC utilizes common messages such as INVITE and BYE. The big change lies within the message body of those INVITE and BYE messages. As is expected with all SIP call flows, Session Description Protocol (SDP) describes the session's media (e.g. G.711 or G.729).
In addition to SDP, the message body of a SIPREC INVITE contains a second part. In SIP parlance, this is known as a multipart MIME message body. The first part of the message body is SDP and the second part contains SIPREC metadata. This metadata is used to convey information that is specific to the process of call recording.
The metadata of a SIPREC INVITE is formatted as XML. This means that there will be tags that define the start of a section of data and tags that define the end of a section of data. For example, a participant might be encoded as follows:
A SIPREC INVITE will typically contain information about both participants in a call and descriptors for the recording session. A SIPREC BYE will contain similar metadata to stop and archive the recording.
I think about buying an SBC the same way I think about buying a car. I drive a Toyota Prius and although I am very happy with my choice, I know plenty of people who have no interest in owning one. For me, fuel efficiency and reliability top luxury and sportiness. That doesn't make me right and anyone who buys a Cadillac Escalade or Mini Cooper wrong. Different priorities lead to different choices and depending on the person and his or her requirements, the right choice will vary.
That's why I don't have a back pocket SBC that I recommend in all cases. While every product on the market supports the minimum requirements for an SBC, there are a number of factors that must be considered before zeroing in on one.
In terms of call recording and SIPREC, I start with three questions:
First, does the SBC support SIPREC? While this may seem like a silly question, not every SBC does, and until you read this article, you may not even have known to ask for it.
Off the top of my head, I am aware of SIPREC support from Oracle Acme Packet, Sonus, AudioCodes, and most recently Avaya. There are most likely others, but you will need to do your own homework before buying from another vendor.
Second, once you are sure that the SBC you are interested in supports SIPREC, you must determine if it works with your call recording platform. Ask to see the implementation notes. Like all things SIP, there are different interpretations and levels of support for SIPREC. Don't get stuck with an unsupported configuration.
Lastly, those media streams between the SBC and the call recording server use bandwidth. In nearly every case, you will have a minimum of two media streams for every recorded call. So, even though an SBC supports SIPREC, you need to make sure that it can handle the number of simultaneous G.711/G.729 calls you want to record. This may force you to move from an SBC with 1gig interfaces to one with 10gig interfaces. The important thing is that you do the math before making a purchase.
From Trunk Side to Line Side
So far, everything I have written about is for trunk side recording, but what if you want to do line side recording? A session border controller can make a difference here, too, although the concept of "border" disappears. Avaya is positioning its SBC to not only sit on an enterprise's network border, but within the network itself. All internal SIP telephones will send their traffic through the SBC, which can then record station-to-station calls.
I expect to see this SBC repositioning adopted by other SBC vendors as they expand their roles as security devices.
I hope this helps and wasn't too technical. Call recording is a very expensive proposition, and it's essential that you walk into any decision armed with enough information to make an intelligent decision. Ask questions of your vendors and make sure they are selling you the solution that makes sense for your enterprise.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!