Recording Service - SIPRec Example
Download OpenAPI specification:Download
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.
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.
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.
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.
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:
A first call is initiated and recorded, generating a
RECORDINGSTARTED
event.A second call starts while the first call is still active, creating an overlapping recording session.
Both calls are recorded simultaneously for a period, ensuring they are related.
The first call ends, triggering a
RECORDINGREADY
event, which includes information about related recordings and detected conference segments.The second call ends, triggering another
RECORDINGREADY
event, with references to the first call and any overlapping segments.The application issues a
MERGERECORDINGS
command, using thetoMerge
array populated withrecordingId
,startTime
, and detectedconferenceSegments
to ensure accurate merging without duplicate conference audio.The service processes the merge request, stores the merged recording, and generates a
RECORDINGSMERGED
event.The application issues
DELETERECORDING
commands for each of the individual recordings to clean up temporary files.The merged recording is available for retrieval in the designated storage location.