Call recording
General
The platform can record calls.
A prerequisite is that the media traffic is processed by the server. Recording cannot be performed if the configuration has set up call gatewaying without media processing. For example, the call came through the corresponding SG instance, ESG instance, or it is a dialog with an IVR and media handling for such calls is turned off on the handling B2B instance.
If recording is enabled, it starts immediately after the called party answers and lasts until the dialog is completed. Each dialog is recorded independently of the others.
If multiple records were generated during the dialog due to media gateway migration, the final record is merged.
The recording contains only the sound of the initiator and the called party. The hold melody generated by the server is not included in the recording; silence is recorded instead.
By default (unless configured otherwise), the recording is stored in an MP3 file in stereo mode. The left channel contains the stream from the initiator and the right channel contains the stream from the called party.
It is possible to enable recording temporarily in a dialog that is already in progress (via API).
Recording rules
Recording is turned on or off according to the recording rules applied to each new dialog.
When both subscribers are established (the called party has answered), their shared domain is searched for the highest priority recording rule appropriate for this dialog based on the numbers of its participants.
If subscribers belong to different domains, the recording rules are executed in both domains based on the listed numbers of both participants. If no domain has requested a recording, no recording is performed. If at least one domain has requested a record, then a record is performed and mixed, but only folded into that one. If both domains have requested a record, the record is enabled, mixed, and copied to both domains' stores. The recording rule includes the required recording modes that can be operated simultaneously.
Recording Modes
Local recording using platform tools
Local recording is the standard mode. The media gateway simultaneously saves each channel to a local file while exchanging media traffic between subscribers' devices.
After the dialog is completed, the mixer pulls the necessary files from there and merges them into one. The files are then distributed to the storage locations configured in the domains.
Such recordings are present in the call log and are available for listening from the platform applications (according to the role policy), or through the API.
External recording
Simultaneously with or instead of normal recording, each dialog can be recorded to an external server by making special call(s). Multiple calls to multiple external servers at the same time can be configured. Can be set to record in several different modes at the same time.
External protocol recording RFC-7866 (siprec)
Recording is performed by a special call to an external recording server via protocol RFC-7866. The responsibility for recording and storing, as well as making records available to users in this case, lies with the external system.
Recording is enabled by the 'siprec' field of the recording rule and requires setting up a connection to the recording servers, as well as some other options.
For more information on setting this mode: Settings 'siprec'
External recording with two calls (streamed_call_rec)
Recording is performed by two SIP calls to an external recording server, where each of the calls broadcasts the channel of one of the participants of the recorded dialog. The responsibility for recording and storing, as well as making records available to users in this case, lies with the external system.
Recording is enabled by the 'streamed_call_rec' field of the recording rule and requires setting up a connection to the recording servers, as well as some other options.
For more information on setting this mode: Settings 'streamed_call_rec'
External recording with one call (mixed_call_rec)
Recording is performed by a SIP call to an external recording server broadcasting a mixed channel with streams of both participants of the recorded dialog. The responsibility for recording and storing, as well as making records available to users in this case, lies with the external system.
Recording is enabled by the 'mixed_call_rec' field of the recording rule and requires setting up a connection to the recording servers, as well as some other options.
For more information on setting this mode: Settings 'mixed_call_rec'
Stenography
The platform can perform stenography of recorded conversations.
Only dialog recordings made by the system itself (local recording) can be subjected to stenography.
Whether shorthand is enabled or disabled is determined by shorthand rules. These rules, like record rules, apply to every dialog in the domains of its participants. Only those dialogs for which at least one domain has requested stenography are stenographed.
Stenography requires configured access to a text recognition service. A docker image with a recognition system can be supplied along with the system, and the container can be started. You need to prescribe accesses to it in master domain settings.
Stenography consumes a lot of resources. One server (container) can stenograph up to 6 dialogs in parallel. The time to prepare a transcript can be equivalent to the time of the dialog itself. The dialogs that require shorthand are used to form a queue of tasks for the service.
The results of the dialog shorthand are stacked in the appropriate field in the call log.
The quality of shorthand by the built-in service is far from ideal, especially places with terms or national language peculiarities suffer.
Microservices
Recording and processing is provided by the following microservices:
-
B2B - organizes the dialog, applies recording rules, initiates recording, and places a completion event for the mixer. When special recording modes with external server calls are activated - initiates these calls to external servers directly (point-to-point).
-
MGC - translates commands from the control layer to the media gateway serving the context.
-
MG - provides RTP traffic exchange, performs local recording of each stream separately, stores local records for 6 hours.
-
MIXER - pulls recordings from the media gateway, mixes them according to the settings in the configuration, and places the recording in a shared directory (NFS or locally).
-
RECMOVER - moves the record to the repositories of the domains whose subscribers participated in the dialog and whose rules enabled the record.
-
MWARE - initiates stenography of the record and placement of the transcript.
Record storage location
Records made locally, after being transferred to the domains of the dialog participants, are stored in domain storages.
Options:
-
NFS-a folder attached to the NFS server and connected as a volum in the system container. During installation, the file 'rshare.sign' is placed in this folder to indicate the availability of the server.
-
Under the same conditions, if the folder is not NFS-connected, it is hosted locally on a server with the role recmover. When the file is accessed, all servers where instances of the microservice are active are enumerated recmover.
-
in S3 storage (if storage is created and configured for such in the domain, and its code from the field is specified in the record rule) 'instance').
During the dialog, recording is performed by the MG microservice to the local folder RECORD. The default configuration for this specifies the folder attached as a docker-volume to the docker container with the platform. During the installation of the system on each server, the installer asks for the location of this folder in the server host. It is recommended that this folder be located on a disk that has no risk of creating a write access queue. Despite the fact that the data is folded into the file asynchronously, the opening of the file itself is a synchronous procedure and strictly limited in time. If there is a timeout of several seconds - the conversation will not take place.
The mixer copies the MG file to its working directory ("/var/lib/era" inside the container), and mixes there. After the mix operation, the file is moved (copied and deleted) to the RECSTORE directory in the shared partition.
After domain partitioning, the record file is either moved to the domain’s external storage or copied to the domain partition of the same directory RECSTORE. By appropriately setting the instance properties in the configuration, an entry from a shared partition can either be deleted or left there.
Access to recordings for listening
Listening to recordings by means of the platform (via API or from the platform applications) is possible only if the recording was made in the local mode.
Access to records is determined by role policy.
A temporary link with a complex unique name is always generated to access the file, available publicly for 5 minutes.
Conference recording
A conference is a separate user-agent that has its own media context. Each participant is connected to the media context of the conference through a dialog that has its own media context within the call.
Like other media contexts, the conference context has a recording feature, but it is not available to the user. In complex conference topologies, there is no unambiguously correct composition of participants to form a single record file. Therefore, the platform does not record the media context of the conference, assuming that the recording is done in supersystems:
-
Each participant must be able to listen to exactly the section and composition of the conference in which he or she participated and had the opportunity to listen. Therefore, a recording of the caller’s conversation with the conference can be made. This is controlled by standard recording rules. If a subscriber can access the recordings of his own conversations, he will also have access to the recording of the conference (i.e. his conversation with the conference participants).
-
Any number of technical participants - recorders - can be added to the conference at any time, and the necessary topology can be set for them. For example, they can be calls from IVR with the "Record" component. In this case the placement and access to this record is the responsibility of the script and the supersystem.