Recording Service - SIPRec Example

This document provides practical examples of how developers can integrate the Recording Service from iotcomms.io into their application workflows. The recording service offers scalable and compliant call recording capabilities via SIPRec interface. Through REST APIs and real-time callbacks, allowing developers to efficiently embed call recording into their applications with full control over the recording lifecycle.

The recording service operates using the following key components:

• Session recording client (SRC) – The telephony system component responsible for initiating a recording session. It establishes a SIPRec session with the session recording server (SRS), as defined in RFC 7866, by sending a SIP INVITE request containing a session description protocol (SDP) body that describes the media streams to be recorded.

• Session recording server (SRS) – The recording service component that processes SIPRec INVITE requests, negotiates media parameters, and securely stores recordings. The SRS also manages metadata, ensuring session correlation as per RFC 7866.

• Storage destination – A secure location (e.g., Amazon S3 or on-premise storage) where recordings are stored after processing. The service ensures encryption and compliance with regulatory standards such as GDPR and HIPAA.

When a SIPRec session is initiated, the SRC sends an INVITE request to the SRS, negotiating recording parameters via SDP. The SRS then establishes RTP streams, monitors session states, and provides event callbacks and APIs to allow the application to manage the recording workflow efficiently.

1. SIPRec session initiation

   • The SRC establishes a SIP dialog with the SRS using a standard SIP INVITE request.

   • The INVITE request includes a session description protocol (SDP) body specifying the media streams (e.g., caller and callee audio) to be recorded.

   • Upon receiving the SIP INVITE, the recording service sends a /newCall callback to the application, allowing it to decide whether to record the session.

2. Recording start

   • If the application responds positively, the SRS acknowledges the session with a 200 OK SIP response, completing the session negotiation.

   • The recording begins immediately, and a RECORDINGSTARTED event is sent to the application.

   • The RTP streams transmitted between the caller and callee are forked by the SRC and forwarded to the SRS for processing and temporary storage.

3. Recording completion

   • When the call ends, the SRC sends a SIP BYE request to terminate the recording session.

   • The SRS acknowledges the termination and generates a RECORDINGREADY event notifying the application that the recording is available.

4. Storage and processing

   The recording service allows developers to apply trimming and masking to recorded sessions before they are stored. Trimming enables selecting only a specific portion of the call to retain, while masking allows replacing sensitive sections (such as credit card details) with silence or a beep sound to comply with privacy and regulatory standards such as PCI DSS.

   • The application sends a STORERECORDING command to specify the final storage destination and any required processing.

   • The SRS encapsulates the recording metadata in accordance with RFC 7866, ensuring session correlation.

   • The recording is securely transferred to the configured storage location, and a RECORDINGSTORED event confirms the successful operation.

   • The application sends a DELETERECORDING command to delete the recording from the service. If no DELETERECORDING is sent the recording is automatically removed from the system after 2 days.

   • The recording is then deleted, and RECORDINGDELETED event confirms the successful deleteion.

The example below demonstrates how to merge two related call recordings:

1. A first call is initiated and recorded, generating a RECORDINGSTARTED event.

2. A second call starts while the first call is still active, creating an overlapping recording session.

3. Both calls are recorded simultaneously for a period, ensuring they are related.

4. The first call ends, triggering a RECORDINGREADY event, which includes information about related recordings and detected conference segments.

5. The second call ends, triggering another RECORDINGREADY event, with references to the first call and any overlapping segments.

6. The application issues a MERGERECORDINGS command, using the toMerge array populated with recordingId, startTime, and detected conferenceSegments to ensure accurate merging without duplicate conference audio.

7. The service processes the merge request, stores the merged recording, and generates a RECORDINGSMERGED event.

8. The application issues DELETERECORDING commands for each of the individual recordings to clean up temporary files.

9. The merged recording is available for retrieval in the designated storage location.