SelectiveCall Recording SIPREC

The SIPREC protocol is the protocol used to interact between a Session Recording Client (SRC) (the role performed by SBC) and a Session Recording Server (SRS) (a 3rd party call recorder or Oracle Communications Interactive Session Recorder’s Record and Store Server (RSS)). It controls the recording of media transmitted in the context of a communications session (CS) between multiple user agents.

SIPREC provides a selective-based call recording solution that increases media and signaling performance on a recording server, more robust failovers, and the ability to selectively record. SIPREC also isolates the RSS from the communication session.

The SRC starts a recording session for every call within a configured realm. All call filtering, if desired, must be accomplished by the recording server. The recording server performs the filtering and selection of which sessions it should record.

SIPREC for Active Recording

SIPREC supports active recording, where the SBC acting as the SRC, purposefully streams media to the Oracle Communications Interactive Session Recorder’s RSS (or 3rd party call recorder) acting as the SRS. The SRC and SRS act as SIP User Agents (UAs). The SRC provides additional information to the SRS to describe the communication sessions, participants and media streams for the recording session to facilitate archival and retrieval of the recorded information.

The SBC acting as the SRC, is the source for the recorded media. The SBC consumes configuration information describing the ecosystem within which it operates. The interface, realm and session agent configuration objects specify the SIPREC configuration. A SIP UA can elect to allow or disallow any network element from recording its media.

During the establishment of a SIP Session, the SBC determines if SIPREC is configured for recording the call. If so, it then duplicates the media prior to initiating the session with the SRS. (Media replication is set up prior to the recording session). The SRS may choose to record, not record, or cancel the recording session, and then communicates via SIP signaling to the SBC. If the call is not to be recorded, the SRS signals termination of the recording session.

The SBC maintains SIPREC metadata information associated with recording sessions. The recording session metadata describes the current state of the recording session and its communication session(s). It is updated when a change of state in the communication session(s) is observed by the SBC. The SRS is responsible for maintaining call history, etc. The SBC creates and logs call detail records (CDRs) in the current manner, the 3rd party SRS vendor may collate this information if desired. (For more information about the contents of metadata, see Metadata Contents).

The following illustration shows two endpoints, User Agent A (UA-A) and User Agent B (UA-B). Their session is being recorded by an SRC (the SBC) and an SRS.

The SIPREC Active Recording diagram is described above.

Preserve SIPREC with SIP REFER Header

When the SBC generates a new INVITE as part of terminating a SIP REFER, the SBC evaluates the SIPREC configuration of the realms and session agents involved in the new call leg and responds accordingly. The REFER and Transfer mechanism automatically preserves the UCID, XUCID, GUID, GUCID, and UUI in the metadata, and can forward this information to the Session Recording Server. The SBC can Start, Stop, Pause, and Resume SIPREC sessions in response to any re-INVITE, UPDATE, new INVITE, REFER, or specified SIP Response Message.

The SBC can establish a new session or update the existing session with the SIPREC server in the following ways.
  • When the A-B call leg SA-realm-sipinterface is configured for SIPREC, and the B-C call leg SA-realm-sipinterface is not configured for SIPREC, the SBC sends metadata to the Session Recording Server to stop the recording on the sessionID associated with the original call.
  • When both the A-B call leg and the B-C call leg have the same SIPREC configuration on their SA-realm-sipinterface, the SBC sends metadata to the Session Recording Server to stop Party A participation and start Party C participation within the same sessionID.
  • When the A-B and B-C call legs have a different SIPREC configurations on their SA-realm-sipinterface, the SBC sends metadata to the A-B call leg Session Recording Server to stop the current recording session and sends metadata to the B-C call leg Session Recording Server to start a new recording session with a new sessionID.

Configuring SIPREC

For more information on configuring SIPREC on an SBC, see the Oracle Communications Session Border Controller Call Monitoring Guide.