File storage

System → File storage (admin only) decides where the chat service keeps chat files: message attachments, their thumbnails and group pictures.

With a bucket, large files stay off the PBX's disk and out of its backups.

Call recordings and faxes can go into the same bucket: tick Call recordings in the bucket too (see Call recordings) and/or Faxes in the bucket too (below). Heard voicemail can be archived there too (below).

Faxes in the bucket

The PDF and TIFF of received and sent faxes move to the bucket an hour after the fax finished (/usr/local/bin/fax_to_bucket.php, every 5 minutes, 200 files per run), so the e-mail with the PDF and a quick Send again still use the local files. A file that a pending fax still uses (a fax sent again reuses the same TIFF) waits until that fax has finished too.

• Viewing and downloading work as before, with the same access rules; the files come through the PBX.
• Send again on a fax whose files are in the bucket brings the TIFF back to the disk first.
• Deleting a fax, and the retention period (Fax settings → retention days), delete the files in the bucket too.
• When the bucket cannot be reached, the files stay on the disk and move on a later run.

Voicemail archive

Archive heard voicemail older than (days) (0 = never): once an hour, messages that were already listened to (the mailbox's Old folder) and are older than that move to the bucket (/usr/local/bin/voicemail_to_bucket.php) and leave Asterisk's spool. New messages are never moved, so the voicemail lamp and listening from a desk phone stay as they are.

Archived messages are listed as Archive under My Phone → Voicemail and in the mobile apps, where they can be played, downloaded and deleted; a desk phone (\*97) no longer offers them. A mailbox that Asterisk changed in the last two minutes (someone listening) waits for the next run.

Access stays the same

Files are always downloaded through the chat service (/chat/media/…), which checks that the person is a participant of a chat that contains the file. The bucket is never shown to browsers or apps, so it can, and should, stay private: no public access and no bucket policy for anonymous reads.

Setting up a bucket

1. Create a bucket at your provider, plus a key that may only use that bucket. It needs s3:PutObject, s3:GetObject and s3:DeleteObject on the bucket's objects. For example, on AWS:

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
       "Resource": "arn:aws:s3:::aipbx-chat/*"
     }]
   }

1. On System → File storage choose S3-compatible storage and fill in:

1. Test connection writes a small file, reads it back and deletes it, and shows the provider's error when something is wrong (for example AccessDenied or NoSuchBucket). Save runs the same test first, so the PBX never switches to a bucket it cannot write to.

The secret key is encrypted in the database with the same key as the Cloud TTS credentials (AIPBX_SETTINGS_KEY or /var/lib/aipbx/settings.key) and is never sent back to the browser. Leave the field empty to keep the stored secret.

The chat service picks up a change within about ten seconds; no restart is needed.

Files from before the switch

Files that were on the local disk before the switch are still served from there. Once S3 is in use, the page shows how many files are left on the disk, and Move files to the bucket moves them in the background. Each file is removed from the disk only after the bucket holds it with the same size. A file that fails stays on the disk, the page shows the last error, and the move can be run again.

Switching back to the local disk is possible at any time: new files are written to the disk again, and files already in the bucket stay readable as long as the bucket settings are kept.

Troubleshooting

• "the chat service did not answer": check systemctl status aipbx-chat and journalctl -u aipbx-chat.
• Uploads fail after saving: the key may have lost its rights; Test connection shows the provider's answer. The chat service's log names the failing file.
• SignatureDoesNotMatch: usually a wrong secret key or region.
• TLS errors with a bucket name that contains dots: turn on Path-style addresses.