Step 17. Streaming statistics and call recordings

A cdr log is a text file related to a specific date. Each line contains an event and its basic attributes. It is used for quick history analysis by an administrator who has access to the servers' file system or to the monitoring API (for downloading logs). This mode works even when all others are unconfigured or unavailable. Log files are automatically split into 100 MB chunks and by date. They are automatically deleted by the system after a short storage period (2 days) or when the number of files in the directory exceeds 20 files.

B2B generates the main events of the class callevents. Additional events of the callevents class also generate mixer, recmover, asr.

Events of the callevents class are sent to the broker. The CallStore takes them from there. It builds a call model, monitors the signaling server and media gateway. Generates spare events to terminate dropped calls. Fills the master domain model database with SORM events-3. Mixer jobs are sent to the broker. They are generated by B2B or CallStore. Jobs for recmover are sent to the broker. They are generated by the corresponding mixer that processed the recording. Asr jobs are sent to the broker. They are generated recmover.

During job completion, each of the mentioned services generates an event of the callevents class and a job for the next event. The callevents are sent to all the above mentioned destinations directly from the generation node on a common basis.

The recording is mixed in case it was conducted by local services.

Mixer role instances are competing Borker subscribers to a queue c pattern "mixer.tasks" that is populated by B2B or CallStore role instances based on CDR events associated with the end of a call. It is sequentially produced by:

The result of mixing is a mono or stereo audio file in MP3, G.711 or G.610 codec - codec and bitrate are configurable in the role options. The target audio (and video) mixing task is demanding on resources. It is easy to give such a load on the site that the amount of traffic to be mixed and packaged will exceed the performance of a single server. Therefore, the Mixer role is redundant and scaled in Active-Active mode. In the configuration of a densely loaded system it is advisable to provide separate servers for Mixer roles, similarly to roles MG.

The file storage for call recordings is an external network disk or S3 storage, the access point to which is defined in the storage list. In case the file storage is unavailable, Mixer continues its work by storing the results on the local disk. When access to the storage is restored, the files are automatically migrated. Therefore, for the Mixer role it is important to have free space on the local disk in addition to a productive processor.

The recmover service is active-passive within the site. It is the broker’s subscriber and event generator callevents.records_moved. RecMover migrates data to the storage configured in the worker domains, which is either local disk, NFS, or S3.

The operation of the system’s critical communication processes does not depend on the availability and performance of the event concatenators and databases. However, the event history function and related functions such as accessing call logs, listening to call recordings, and building reports based on call history depend on it.

The WSSubscr role contains all web socket subscriptions to all event classes. Subscription is done through the WebSocket API of the WS role. Subscriptions can only be created temporarily, and are renewable. The subscription sets the categories and types of events of interest, as well as a filter on the user accounts associated with the event.

So for example, some external system can make two event subscriptions callevents:

As a result, the WSSubscr role will notify the external system of each call 101 and 102, with the entire series of events being sent for calls 102, and only dlg_start and dlg_stop for calls 101. In this case, if a conversation between 101 and 102 occurs, the dlg_start and dlg_stop events will not be duplicated.

Subscription is performed within the domain in which the external system is authorized. That is, calls between users of other domains are not sent to the subscriber. But domain events are sent from all sites where the domain is served (although this makes sense only if the domain does not use a product layer that requires a data integrity point).

The event sender accesses WSSubscr for subscriptions and sends events to the web servers serving the detected and filtered connections.

Next to each call, a call context script that handles all events can be active on the same site. This script is created by the master domain administrator. What can the script do? Anything that the administrator has configured. For example, it can handle events on its own. Or it can initiate the launch of context scripts in child domains and then forward events to them. Those, in turn, are created by domain administrators and can, for example, send events to external systems, following some custom protocols.

The context script can also be configured in the worker domain. It will receive all events of callevents class generated in calls initiated by domain subscribers (including services).

If there is a need to save all CDR events, it is advisable to configure a connection to an external broker in the master domain KAFKA. Each event is sent directly from the node that generated it to one of the available endpoints.