of 3

Documentation

Unblu 7 (latest)

Unblu’s conversation recording capabilities help your organization to meet compliance requirements and to maintain high standards of service.

When customers chat with your agents, a record of the entire conversation is stored in the conversation history. If your organization uses Unblu video and voice call features, you can record the audio and video feeds of the call.

The conversation recording feature introduced with Unblu 7 extends these recording options to the co-browsing and screen sharing collaboration layers. It also allows you to archive video and voice calls without using Vonage’s archiving feature.

How conversation recording works

  1. When a situation arises where conversation recording should be started, the Unblu server creates a unique entry point and launches an instance of the Unblu rendering service. It then waits for the recording rendering service to connect to the entry point.

  2. The recording rendering service acts like a passive, hidden participant in the conversation. It automatically connects to any collaboration layers and calls to be recorded.

  3. The headless browser that the rendering service runs receives audio and video content from these calls and collaboration layers.

  4. The rendering service sends the data that the headless browser receives back to the Unblu server.

  5. The Unblu Server then streams this data to your object storage service of choice.

How conversation recording works

Configuring conversation recording

Conversation recording is a separately licensed feature of Unblu, so before you configure the feature, you must first obtain a license that covers it. Once you have that, proceed as follows:

  1. Enable conversation recording for your account by setting the account-level configuration property com.unblu.messenger.recordingEnabled to true.

  2. Conversation recordings aren’t stored in the Unblu server’s database, so the next step is to configure the object storage service where you want to store the recordings. Please review the section on using a dedicated storage in the main Unblu documentation for information on the relevant configuration properties.

  3. Finally, set com.unblu.identifier.recordingEntryPointBaseUrl to the base URL that the recording rendering service should use to resolve to the Unblu server.

With the exception of the first configuration property, these properties are set in the IMMUTABLE scope.

With conversation recording enabled in your Unblu account, you can define how the feature should work in conversations based on different conversation templates.

Conversation template scope configuration

To enable conversation recording in a conversation template, set the template’s configuration property com.unblu.conversation.recording.recordingEnabled to true.

Starting conversation recording

You can configure various aspects of how conversation recording is initialized.

  • Specify the type or types of interaction that trigger conversation recording in the configuration property com.unblu.conversation.recording.recordingTriggeringSources. The possible values are:

    • CALL for video & voice calls

    • COLLABORATION_LAYER for any collaboration layer (document co-browsing, embedded co-browsing, universal co-browsing, and screen sharing)

    The setting determines when recording should start and end. Recording ends when all types of interaction that could have triggered the recording end. The following example illustrates this point:

    + Suppose that conversation recording started because an agent launched an embedded co-browsing session. They then initiated a voice call with the visitor. During the voice call, the embedded co-browsing session is no longer needed, so the agent stops it. Recording will only continue if CALL is included in the sources that trigger recording.

  • The configuration property com.unblu.conversation.recording.recordingMaxRetries specifies how many times the Unblu server should try to start a conversation recording.

    Each attempt to start a recording will start a recording rendering service and wait for it to connect to the conversation’s entry point. It will wait for a response for the time specified in the configuration property com.unblu.conversation.recording.initializationTimeout.

    If the Unblu server doesn’t receive a response from the rendering service to any of its attempts to start a recording, it switches to failover mode.

  • Starting a conversation recording can lead to a slight delay in providing access to a call or a collaboration layer, because the rendering service must first launch and then inform the Unblu server that it has launched and is recording. To avoid this delay, set com.unblu.conversation.recording.recordingStartMode to ASYNCHRONOUS. Doing so enables the conversation participants to start their call or collaboration session immediately. However, it may result in the recording missing the first seconds of the interaction.

    If you keep the default start mode setting, SYNCHRONOUS, calls and collaboration layers will not start until Unblu is ready to record the conversation.

For information on how Unblu behaves if it fails to start recording, read the section below on conversation recording failover.

Conversation recording behavior

A number of configuration properties influence the recording itself:

Conversation recording failover

Conversation recording may fail to start, or a recording may be interrupted. com.unblu.conversation.recording.recordingFailoverMode defines how Unblu should react in these circumstances:

  • RETRY failover mode will start a new recording if an error occurs. Any calls or collaboration layers currently in use will continue to work while Unblu tries to start a new recording. There will, however, be a gap between the recordings where the interaction isn’t recorded.

  • ABORT failover mode will stop the recording and close any calls or collaboration layers that were being recorded when the error occurred.

RETRY is the default failover mode.

Failover mode also comes into play when an error occurs while starting a recording. Once Unblu has reached the maximum number of retries to launch a rendering service for conversation recording, failover mode determines how the Unblu server deals with the issue.

  • If failover mode is set to RETRY, Unblu will keep trying to start recording. However, its behavior while doing so will depend on the start mode.

    • In SYNCHRONOUS start mode, Unblu will continue its attempts to start the recording until it reaches the maximum number of retries (com.unblu.conversation.recording.recordingMaxRetries). After that, it will launch the interaction while still trying to start the recording.

    • In ASYNCHRONOUS start mode, Unblu will immediately launch the interaction that triggered recording and participants will be able to use it. It will keep trying to start the recording.

    If failover mode was triggered because the object store was unreachable, Unblu will not make any further attempts to start the recording.
  • If failover mode is set to ABORT, Unblu will terminate the interaction that triggered the recording, regardless of whether start mode is set to SYNCHRONOUS or ASYNCHRONOUS. This also applies if failover mode was triggered because the object store was unreachable.

When trying to recover from a recording failure, each recovery attempt involves starting a new recording rendering service, which requires significant resources. If the failure was not caused by an issue with the recording rendering service, these recovery attempts would consume resources unnecessarily. To avoid overwhelming the cluster, Unblu therefore uses an exponential backoff retry policy. The configuration property com.unblu.conversation.recording.recordingMaxRetryDelay specifies the maximum exponential backoff delay in seconds for retrying a failed conversation recording.

Accessing conversation recordings

Conversation recordings are always related to a particular conversation, so authorized users can access conversation recordings via the conversation they are related to.

A single conversation may have multiple conversation recordings. For example, a visitor may first request an embedded co-browsing session, which is recorded. After the embedded co-browsing session has ended, the agent and visitor want to speak together, so the agent initiates a voice call, which triggers a second conversation recording. Both recordings will be related to the same conversation.

All of a conversation’s recordings are listed in the fly-in page displayed when you select a conversation in the conversation history. Each recording is linked in the fly-in page. Clicking on it will open the recording in a new tab.

A conversation recording in the conversation fly-in page

Conversation recordings are also embedded in the history of the conversation itself. If you open a conversation in the conversation history, you can see the point in the conversation at which a recording started and ended along with any chat messages that were exchanged while the recording took place. Here, recordings are displayed in their own conversation message type.

A conversation recording displayed in the conversation itself

The configuration property com.unblu.conversation.recording.recordingFilenamePattern allows you to specify a pattern for the names of the MP4 files that are created when recording is over. The filename is displayed in both the conversation and the conversation’s fly-in page.

Conversation recordings remain available until the conversation they were made in is deleted. There is no way to delete conversation recordings while the conversation they are related to exists.

Requirements

  • To use conversation recording, you must either be running a cluster installations of Unblu, or using the Unblu Cloud.

  • Each recording launches a rendering service dedicated to recording the interaction. As a result, the number of rendering services required for universal co-browsing, document co-browsing, and screen sharing doubles if you record them. Take this into consideration when deciding on the resources to provision for your cluster.

  • You must provide an S3-compatible object storage service such as Amazon S3 or min.io, or access to Google Cloud Storage.

  • The size of a conversation recording depends on numerous factors, including the resolution of the recording and the complexity of audiovisual data. As a rule of thumb, however, a 10 second recording of a collaboration layer at a resolution of 1920x1080 pixels with sound will result in a MP4 file roughly 1 MB large.

  • Conversation recordings can be viewed in any browser that supports fragmented MP4 (fMP4). Safari and Firefox on MacOS both don’t support fMP4, nor does QuickTime.

    You can download conversation recordings and view them in any media player that supports fMP4, for example VLC.

See also