In the following entries we will implement a basic SIP recording solution using Oracle Interactive Recording (ISR), but before go in deep to the ISR implementation lets take a few minutes to describe a SIPRec environment.

When using SIPRec, we need to first define three key elements in communication:

Session Recording Server (SRS) – Passive device that participates in the recording solution only receiving SIPRec signaling and RTP traffic coming from a Session Recording Client.

Session Recording Client (SRC) – Active device that participate communicating two (or more) SIP User Agent (phone or PBX), its in charge to create a SIPRec session and send it to the SRS.

SIPRec Session – it’s a special session that includes SIP and metadata with 2 or more m lines in SDP (describing the pots used for RTP transmission)

This is the most basic diagram we can find in a SIPRec solution:

You can probably find environments where the Session Recording Servers can be duplicated, but we will discuss more in dept in a future entry. Session Recording Client is frequently implemented using Session Border Controllers, the following image shows a Cisco SBC (CUBE) forking SIPRec to another CUBE which is in charge of provide the communication to the recording solution implementing TLS, SRTP in different networks (cloud and on-premises).

As mentioned before a Recording Session (RS) is different from a normal SIP session (CS) as INVITE comes with metadata and multiple m-lines, and the 200 OK coming from the SRS have session inactive.

The following image shows the most basic SIP/SIPRec flow (we well get some captures in the ISR lab environment):

In the following entry we will describe the ISR solution to be deployed in the lab.