The MiaRec call recording solution consists of multiple components:
- Web server
- Job scheduler
All these components may be deployed on a single server, in case of small size project, or distributed over multiple dedicated servers, optionally, with duplication/redundancy.
Below you can find a simplified as well as detailed diagram of MiaRec architecture.
The Recording service is a major component of MiaRec solution.
It captures call recordings from phone system via passive (port mirroring) or active recording method (SIPREC, Cisco BIB, Avaya TSAPI+DMCC etc).
Voice data is stored in WAV/MP3 format on local file system or NAS/SAN.
Call metadata is stored in database and/or textual CSV files (for backup/fail-over purposes).
REST API is used for retrieving of real-time information about call recordings and changing of recorder's behavior, for example, trigger on-demand recording, pause/resume recording, reload configuration etc.
Live monitoring feature is based on RTSP protocol for streaming real-time audio to end user.
Recorder service notifies a web-portal about call events in real-time (call begin/finish) via REST API. Such notification is used to trigger some post-processing tasks like continuous call replication, grouping of multi-segment calls into single interaction etc.
Telnet CLI is used for troubleshooting and monitoring purposes.
Recorder service loads own configuration from MiaRec.ini file at first. From INI file it reads database connection settings (host, port, login etc) and then load configuration from database.
By design the recorder service is independent from other components. It doesn't depend on web-portal component at all. And it continues to record calls even if database is down. In this case, call metadata will be stored in textual CSV files, which may be imported into database when the latter is up again.
Audio files are stored either locally or on a network-based storage device.
Additionally, MiaRec supports two-phase file storage to improve performance and provide fault-tolerance. When call recordings starts, the recorder creates audio file on local disk array (usually high-speed). When call recording completes, audio file is moved automatically to long-term storage (network-based or high volume but low-speed disk array). If network-based storage is not available, file move operation will fail, but the audio file itself will be successfully stored on local disk array. Such architecture protects from occasional issues with network.
Two-phase file storage architecture is used also to improve performance during active recording phase. When call is in progress, the recorder flushes periodically data to disk by small portions. If there are hundreds of concurrent call recordings, then it causes high IOPS (input-output operations per second) on disk array. In this case, usage of local high-speed disk array is highly recommended. When call completes, its audio file is moved to long-term storage. Such move operation will trigger a single disk write operation per call. IOPS on long-term storage is significantly lower in this case.
Database is used for storing call metadata, recorder configuration as well as web-portal data.
Web portal provides access to call recordings to end-users.
Additionally, web portal implements REST API which may be used by third-party applications for accessing call recordings and other resources (like users, groups, roles etc).
Celery is a job scheduler and background task manager. It executes such jobs like backup, replication, ldap user synchronization etc.