Introduction

In many contact center operations, it is necessary to automatically replicate call recordings and chat conversations to a customer-owned server, whether for internal policies, auditing, backup, or regulatory compliance.

For this purpose, RSYNC over SSH is an alternative that makes it possible to transfer information from wolkvox to a storage infrastructure managed by the customer, such as a NAS, SAN, or Linux server.

From wolkvox Manager, this integration can be configured for:

• Automatic copying of call recordings.
• Additional delivery of recordings in MP3 format.
• Automatic copying of chat conversations in HTML format.

Important information about chat copying: The Automatic Chat Copy functionality is currently in Beta. During this stage, unexpected behavior, incomplete transfers, or data loss may occur. For this reason, it is recommended to periodically validate the received files and not use this functionality as the sole backup or auditing mechanism for conversations.

Requirements

To configure RSYNC, you must have:

• A NAS, SAN, or Linux server with support for RSYNC over SSH.
• A user with write permissions for the selected path on the NAS or server.
• A port enabled in the firewall for remote access from the server sending the information.
• An SSH public key shared by wolkvox when configuring the service in wolkvox Manager or provided by a wolkvox agent.

To specifically use automatic chat copying, the operation must also have contact center licenses and the RSYNC integration enabled.

Configuration in wolkvox Manager

1. Log in to wolkvox Manager with a user who has administrator permissions. Click “Settings” from the menu located in the upper-right corner.
2. Go to the “Integrations” section.
3. Select the “Rsync” option.
4. If you want to copy call recordings, enable the “Enable audio copy via rsync” checkbox.
5. In the ssh port field, enter the port that will be used to communicate with the customer’s server.
6. In the path (user@ip:/folder) field, enter the destination path using the following format: user@(IP/Domain):/remote/path
   • Example: user@203.0.113.10:/mnt/recordings
7. Enable the “MP3 (Send mp3 copy)” option if you also want to receive recordings in MP3 format. Keep in mind that this option may generate additional charges and higher storage consumption on the customer’s infrastructure.
8. If you want to enable the transfer of chat conversations, select the “Automatic chat copy (Beta)” checkbox.
9. Use the “View SSH key” option to view the SSH public key that must be configured on the destination server.
10. Copy the content displayed in the “SSH Public Key” field and add it to the authorized_keys file of the user configured for synchronization.
11. Click “Save” to apply the changes.

Automatic chat copying via RSYNC

When the Automatic Chat Copy (Beta) option is enabled, wolkvox generates an independent HTML file for each conversation that must be synchronized.

The HTML contains the chat message history and, whenever possible, also embeds attachments directly within the same document.

Attachments are not transferred as separate files.

Which conversations are synchronized?

During each execution, the process searches for conversations that were closed within the period between the previous 15 days and the day immediately before the execution.

Dates are calculated using the time zone configured for the operation.

For each conversation, the system retrieves information such as:

• Message sender.
• Recipient.
• Person who wrote the message.
• Date and time.
• Message text.
• Attachment URL, when available.

This information is used to generate the HTML file corresponding to the conversation.

The file is then transferred through RSYNC over SSH using the port and path configured in the integration.

Chat storage structure

On the destination server, conversations are stored using the following structure:

{path}/{operation}/chats/{year}/{month}/{year}-{month}-{day}/

For example:

/mnt/recordings/my_operation/chats/2026/09/2026-09-28/

The folder used corresponds to the conversation closing date.

File naming convention

Each conversation generates a file using the following structure: chat_{chat_id}_{phone_or_name}_{agent_id}_{YYYYMMDD}.html

Where:

• chat_id: conversation identifier.
• phone_or_name: customer’s phone number. If the chat does not have a registered phone number, the name is used.
• agent_id: identifier of the agent who handled the conversation.
• YYYYMMDD: chat closing date.

If the conversation did not have an associated agent, the segment corresponding to the agent identifier will be left empty.

Example

chat_88421_3001234567_agte014_20260928.html

This file would be stored in the folder:

2026/09/2026-09-28/

The date used both in the file name and the folder corresponds to date_close, that is, the conversation closing date and not the date of each message.

What happens if a chat has already been synchronized?

The transfer uses the following option: --ignore-existing

This means that if the HTML file already exists on the destination server, RSYNC will not replace or copy it again.

Therefore, the first version of the file that reaches the customer’s storage will remain there.

The local directories temporarily used by wolkvox to generate chat files for an operation are deleted after 5 days.

Attachment handling

When a message contains a value in attach_url, wolkvox attempts to download the file through HTTP or HTTPS before generating the HTML.

The download attempt has a maximum timeout of 20 seconds.

When the download is successful, the file is converted to Base64 and embedded directly within the conversation HTML.

The behavior depends on the file type.

Images

The image is embedded directly within the HTML and can be viewed when the conversation is opened.

Audio and video

The file is included within the HTML and displayed through a media player compatible with the content type.

PDF and other documents

The HTML includes a download link using the file’s original name.

The document content is also stored in Base64 within the same HTML.

PDF file thumbnails

In some cases, attach_url may point to a preview image or PDF thumbnail, for example, a file named chat pdf.png.

When this occurs, the process searches the message text for the actual URL corresponding to the .pdf file and attempts to download that document.

What happens if an attachment cannot be downloaded?

If the file download fails, the HTML retains the original URL provided in attach_url.

In this scenario, the attachment can only be opened while that address remains available in the source system.

When the file is successfully downloaded and embedded in Base64, the attachment replaces the textual content of that message within the HTML. In other words, that message will display the embedded file rather than the text and file simultaneously.

Important considerations for the Beta functionality

Automatic chat copying is currently in Beta. Before using it as part of an operational or backup process, keep the following considerations in mind:

• Some conversations or attachments may not be transferred correctly.
• A file that has already been transferred will not be replaced due to the use of --ignore-existing.
• If an attachment cannot be embedded in the HTML, its availability will depend on the original URL remaining active.
• Local files temporarily generated by wolkvox are deleted after 5 days.
• It is recommended to implement your own verification mechanism to periodically confirm that the expected files are available on the destination server.

Customer firewall configuration

Enable access through the selected port to the published server.

Preferably, restrict access only to the IP addresses corresponding to the wolkvox server or servers that will send the information.

Example: port 2022 -> internal IP 192.168.10.10

Customer server configuration (Linux)

1. Create the user that will be used for the connection.
   • Example: wolkvox
2. Create or select the directory where the information will be stored.
   • Example: /Recordings
3. Assign write permissions on the directory to the created user, either as the owner or through a group.
4. In the directory of the user used for synchronization, add the SSH public key provided by wolkvox to the authorized_keys file.

You can edit it using the text editor of your choice.

Examples:

vim /home/wolkvox/.ssh/authorized_keys

nano /home/wolkvox/.ssh/authorized_keys

Validation recommendations in case of issues

Important

The following validations are general recommendations.

Each customer may have specific security, NAS, server, or internal policy configurations. wolkvox does not directly manage or modify the customer’s infrastructure.

User in a Chrooted environment

Some servers use Chrooted environments to restrict SSH user access.

What to check

Whether the RSYNC user is restricted through ChrootDirectory.

Whether the path configured in wolkvox Manager must be expressed relative to the chroot rather than as an absolute path.

Recommendation

Review the file: /etc/ssh/sshd_config

Validate the ChrootDirectory directives applied to the user or group.

Directory permissions and ownership

One of the most common errors occurs when the configured user does not have write permissions for the directory.

Recommended validation

ls -ld /storage/path

Example actions

sudo chown wolkvox:wolkvox /storage/path

sudo chmod 755 /storage/path

Final permissions must be established according to the customer’s infrastructure security policies.

Reviewing SSH service logs

SSH service logs can help identify the cause of a connection or synchronization failure.

Common locations

• Debian / Ubuntu: /var/log/auth.log
• CentOS / RHEL / Fedora: /var/log/secure

Validation command

sudo journalctl -u sshd | grep rsync

Some messages that may indicate an issue

• Permission denied
• Invalid key
• Chrooted path error