MiaRec. Architecture for SIPREC recording

Transcription

1 Architecture for SIPREC recording

2 Table of Contents 1 Overview Architecture Third-party application integration REST API Direct access to MiaRec resources High availability and automatic failover Specification

3 1 Overview This document describes architecture of the MiaRec call recording solution for SIPREC interface. 3

4 Telnet MiaRec 2 Architecture The MiaRec call recording solution consists of multiple parts as shown in the following diagram. All these parts may be deployed on a single server in case of small size project (up to 500 concurrently recorded sessions) or distributed over multiple dedicated servers, optionally, with duplication/redundancy. Live monitoring (RTSP) Store call metadata Load configuration DATABASE (call metadata + configuration) End User SIPREC RECORDING SERVICE SOAP API Call event notification (REST API) WEB PORTAL REST API FILE STORAGE (mp3 audio files) Third-party application Recording service The Recording service captures call recordings from phone system via SIPREC interface. It decodes RTP audio data and stores audio in MP3 format on local file system or NAS/SAN. Call metadata is stored in database. The recording service loads configuration from database. Telnet CLI is used for troubleshooting purposes. SOAP API is used for retrieving of real-time information about calls recording and changing of recorder s behavior, for example, trigger on-demand recording, pause/resume recording etc. SOAP API is described in details in a separate document. Recording service supports a real-time notification of web-port about call events (call start, stop, update). RTSP protocol is used for streaming of real-time audio for live monitoring. File storage MP3 audio files are stored either locally or on a network-based storage device or a combination of a local and a network-based storage. In the latter case, the recording service stores audio files on a local disk during the active phase of the call and then automatically moves files to a networkbased storage when the call is completed. This allows to improve disk operations performance and achieve resilience in case of network failure (see chapter High Availability and automatic failover). 4

5 Database Database is used for storing call metadata and system configuration. Web portal Web portal is used for call recordings access by end-users and system configuration by administrators. Web portal also implements REST API, which may be used by third-party applications for accessing call recordings and configuring of system. 5

6 3 Third-party application integration 3.1 REST API MiaRec REST API is a single point of entry to all resources of MiaRec platform. A third-party client application communicates with MiaRec REST API to retrieve resources (for example, calls or users) and create/update/delete resources (for example, create a new user, delete call, pause/resume recording etc). The client application sends HTTP requests to MiaRec API. The HTTP response data is encoded in JSON format. Recorder Service Client Application HTTP Request HTTP Response MiaRec Web Services API Database (configuration, call history) File storage Example of request: GET Example of response: { } "user": { "id": "JohnSmith", "first_name": "John", "last_name": "Smith", group_id : Group1 } REST API is described in details in a separate document. 6

7 Telnet MiaRec 3.2 Direct access to MiaRec resources Besides REST API, MiaRec supports direct integration with third-party applications. The thirdparty application may have direct access to database, file storage and SOAP API of recording service. Such option allows tighter integration with MiaRec and better performance in some cases, like complex database search queries. At the same time, such integration option has one significant drawback: maintenance of such system is more challenging. When MiaRec database structure changes with new software release, an update of third-party application may be required too. This issue doesn t occur with REST API because the latter is relatively stable and doesn t change very often. Store call metadata Load configuration DATABASE (call metadata + configuration) MiaRec Admin UI SIPREC RECORDING SERVICE SOAP API Call event notification (REST API) WEB PORTAL Third-party application Web UI FILE STORAGE (mp3 audio files) End User SOAP API Call event notification (REST API) 7

8 4 High availability and automatic failover High availability and automatic failover for SIPREC interface is based on two technologies: 1) DNS SRV 2) MiaRec call replication Master 1 Master 2 MiaRec Recorder DB Web Storage Two-way replication MiaRec Recorder DB Web Storage BroadWorks Load-balancing and/or failover (DNS SRV based) More than 2 masters supported BroadWorks platform supports DNS SRV records for SIPREC interface. This allows building of the following configurations: Multiple recording servers and split SIPREC traffic between them (load balancing) Multiple recording servers with automatic failover from a primary server to a secondary one. A combination of above two variants. MiaRec supports automatic call replication between two or more recording servers. Audio file and call metadata is automatically uploaded to replication target server(s) upon call completion or by schedule (for example, at night). Example of DNS SRV records: # _service._proto.name. TTL class SRV priority weight port target. _sip._tcp.example.com IN SRV miarec1.example.com. _sip._tcp.example.com IN SRV miarec2.example.com. _sip._tcp.example.com IN SRV miarec3.example.com. _sip._tcp.example.com IN SRV miarec4.example.com. The first three records share a priority of 10, so the weight field s value will be used by BroadWorks to determine which recording server to contact. The sum of all three values is 100, so miarec1 will be used 40% of the time. The remaining two hosts miarec2 and miarec3 8

9 will be used for 30% of requests each. If miarec1 is unavailable, these two remaining servers will share the load equally, since they will each be selected 50% of the time. If all three servers with a priority of 10 are unavailable, the records with the next lowest priority value will be chosen, which is miarec4. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first three servers to become unavailable. Limitations: The load balancing provided by SRV records is inherently limited, since the information is essentially static. Current load of servers is not taken into account. In case of failover from one server to another, the currently active recordings on the failed server are interrupted. A new recording server will handle only new SIPREC requests. 9

10 5 Specification Supported codecs G.711 G.722 G k GSM G.729 Supported recording methods SIPREC (Broadworks, Acme) Port mirroring Cisco BiB Avaya TSAPI+DMCC Supported signaling protocols (for port mirroring) SIP H.323 MGCP Skinny Audio file compression MP3 (with configurable bitrate and quality) o 7.2MB/hour (mixed) o 14.4MB/hour (dual) WAV (uncompressed) o 57.6MB/hour (mixed) o 115.2MB/hour (dual) Audio mixing dual (each party is stored in separate audio channel of stereo file) mixed Audio quality improvements AGC (automatic gain control) PLC (packet loss concealment) Encryption AES 256-bit encryption (for audio files) RSA 2048-bit or 4096-bit (unique pair of asymmetric encryption keys per user and per tenant) PCI Compliance Audio encryption Pause/resume recording Audit log Live monitoring RTSP protocol Integration with thirdparty applications SOAP API REST API Direct access to database Supported platforms CentOS/RedHat (64-bit) Windows (32-bit, 64-bit) Database PostgreSQL

11 Web UI Apache web server Python web scripts Celery (asynchronous task queue) Redis (message broker, cache) 11