“This call may be recorded for quality assurance.”
It’s nearly impossible to call a contact center without hearing that message or something very similar. A company will record calls for a variety of reasons. It may be to help improve customer service. Supervisors listen to their agent’s interactions for training and evaluation purposes. Companies also record calls to protect themselves. A significant number of “he said, she said” arguments can be cleared up by simply playing a recording of the customer’s conversation. There are also situations where call recording is required by law.
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 one such 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 lends 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 most 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, 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 Nice.
The following diagram shows the relationship between the different entities. Note that SIPREC message types are only applicable between the SRC and the SRS. Normal SIP messages are sent between the SBC and the SIP carrier and the SBC and the communications platform. Also, although I have shown a SIP telephone inside the enterprise, there is no reason why it needs to be SIP. It could be any telephone type supported by a SIP communications system.
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 message. 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 an SIPREC INVITE is formatted as XML data. 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:
<participant>
participant_id=”srfBElmCRp2QB23b7Mpk0w==”>
<nameID aor=sip:bob@biloxi.com>
<name xml:lang=”it”>Bob B</name>
</nameID>
</participant>
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 am not about to present all the gory details of SIPREC metadata, but I can direct you straight to the source.
http://tools.ietf.org/html/draft-ietf-siprec-metadata-15
It is important to know that SIPREC is still in draft form and has not been ratified by the IETF. However, a number of vendors have already begun to adopt it in anticipation of its ratification. Among the SBC vendors, I’ve seen Sonus, AudioCodes, and Oracle Acme state their support for SIPREC. Among the call recording platforms, I’ve seen Oracle Acme and Nice. This doesn’t mean that other vendors don’t support SIPREC. I simply haven’t run across documentation stating their acceptance one way or the other.
I have just discussed SIPREC as a mechanism for trunk-side recording. However, there is nothing to say that it cannot be used for station-side recording, too. Of interest is the Avaya SBC which is being positioned as both an edge and internal security device. If an Avaya SBC was placed between all internal SIP endpoints and Session Manager, it could easily use SIPREC to perform call recording for station to station calls.
Stay tuned for further developments.
Tao, Zen, and Tomorrow 
Andrew, the first blog of it’s kind I’ve come across so far (i.e. well presented information on SIP/SIPREC). I’ve been dabbling in the world of SIPREC recently, specifically acting as an SRS with the intention of recording/monitoring calls. However, no matter what I try, the SRC always just sends me invites. i.e. I receive an INVITE when a call is established as expected, to which I reply OK, expecting to see an ACK come back to me as defined in the spec, followed by some RTP streams on the ports specified in my OK SDP. However, it just sends me a duplicate INVITE each time (a max of 3 per call) which makes me think my OK format might be off somehow. Have you come across this before or have some tips or diagnosing such an issue?
Tommy, it sounds as if your 200 is not matching the dialog of the INVITE. Have you ensured that you are sending the correct call-ID, CSEQ, and tag values?
Coming from the prespective of a Service Provider; If there are additional header fields within the SIP message, how would you go about ensuring the subscriber is unaware of the recording process when you receive a request from law enforcement (CALEA)?
(I’ll read the the draft now, and may very well answer my own question)
Robert, I am not sure that you have to do anything to make the caller unaware of the recording process. The INVITE to the call recorder should be hidden from him or her.
Hi Andrew, is there a way that the SIP invite from SRC can show the A and B party in the SIP header instead of the SRS IP only in the To portion. To:
That should be ideally be present in the recoding metadata.