1. When running in Docker container with built-in Redis, LibreSBC starts Redis, but doesn't wait for it to be ready and tries to retrive Kamailio layers from database immediatly. If Redis is not started yet, basestartup() will simply exit with no Kamailio instances started.

2. By default, Redis saves database to disk after a very long time, so many changes in configuration are lost if server failed/rebooted soon after changes.

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 change was performed
#   * After 300 seconds (5 minutes) if at least 100 changes were performed
#   * After 60 seconds if at least 10000 changes were performed

One of solutions is to use "--appendonly yes" which make Redis to immediatly write changes to AOF file (https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/).
Note: AOF file will become bigger on every change, but is reduced when it reaches 64mb by default. This can be managed with '--auto-aof-rewrite-min-size 64mb'.

3. If server or container with running Kamailio is not shut down properly, the /run/kamailio/{layer}.pid file persists and blocks Kamailio from starting next time, so i suppose to delete it manually.

If TLS is included in transports of AccessService, Kamailio module tls.so is added to 'layer.cfg' with config file "{{layer}}.tls.cfg". Howewer, this TLS config file is not created anywhere, so Kamailio simply fails to start.
This fix adds template for this file and makes it be created when user enables TLS transport.
A new TLS class is also added to AccessService class to make Kamailio TLS configurable by user. The most common settings are included:
- TLS version
- path to certificate
- path to private key
- custom Server Name Indication string

…C domain mames

Many SIP clients have only one 'domain' field, which implies both the hostname of SIP registrar and the 'domain' field in AOR.
A field to set SIP registrar address separately may be missing or hidden deep in the settings.
On the other hand, server with LibreSBC may not have a real domain name.
It seems to be good to allow administrator of such server create Access Domains with IP address instead of RFC domain name to simplify setup of various SIP clients.

First, the Go must be installed: curl -L https://go.dev/dl/go1.23.2.linux-amd64.tar.gz -o /usr/local/go1.23.2.linux-amd64.tar.gz && tar -xzf /usr/local/go1.23.2.linux-amd64.tar.gz -C /usr/local
And then WebUI compiled: cd /opt/libresbc/webui && /usr/local/go/bin/go build -o /opt/libresbc/webui/webuisrv

(These steps will be automated when installing in Docker. Dockerfile coming soon.)

If LIBRE_WEBUI environmental variable is set to TRUE, 1 or YES, WebUI will be started with LibreSBC on port 8088.

1. With Docker multi-stage builds, entire process is divided for two stages: build and runtime.
In build stage all build tools and packages are installed and sources are downloaded and compiled.
In runtime stage, a smaller debian image is used, only runtime necessary packages are installed, and only binaries are copied from build stage.
This made it possible to reduce the size of container from 2.64 Gb to less than 1 Gb (!)

2. All heavy steps such as downloading tons of sources and building freeswitch and kamailio are moved to the beginning of the Dockerfile.
Now, when the changes are made only to LibreSBC code, docker uses build cache for these heavy steps, so subsequent bulds are made MUCH faster.

3. A docker volume 'libresbc' for storing Redis database and other data created by user. Now the libresbc container can be safely deleted and replaced (e.g. for update), and all user settings are persisted in real host file system (currently /var/lib/docker/volumes/libresbc)

4. WebUI is included into image

5. Built-in Redis and WebUI are enabled by default for smoother user experience. Docker best practices recommend to build ready-to-use container with all components inside it.