Move FreeSWITCH DB from SQLite into PostgreSql

[Adrian Fretwell]

Over the next few days, we will be introducing a change that will move the FreeSWITCH database from SQLite into PostgreSql.

The key reason for doing this is to allow the FreeSWITCH database to be read directly from within the DjangoPBX application. The benefits of doing this will be better and easier reporting in applications like mod_callcenter but also it will allow all the tables to be viewed in the Admin interface and thus make diagnostics easier.

Once we have done this you will see an additional database dictionary in your settings.py file. This databse definition will be for the freeswitch database, it will contain the github insecure password so on an existing installation you will need to edit the settings.py file and change 'postgres-insecure-abcdef9876543210' to be the same as the password you have for the 'default' database shown just above in the settings file:

    'freeswitch': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'freeswitch',
        'USER': 'freeswitch',
        'PASSWORD': 'postgres-insecure-abcdef9876543210',
        'HOST': '127.0.0.1',
        'PORT': '5432'
    }

 

[mcs3ss2]

Hey @Adrian Fretwell

Let us know when the switch over is actioned and completed.

I would like to test this PBX

Cheers. mcs3ss2

 

[Adrian Fretwell]

Hey @Adrian Fretwell

Let us know when the switch over is actioned and completed.

I would like to test this PBX

Cheers. mcs3ss2

Hi mcs3ss2,
Yes I will let you know. It will be a select-able option in the install script. We need to add some additional primary key fields to the FreeSWITCH schema for the add on viewing application to work correctly, but this is nearly done now.

 

[ttt]

Could I offer a suggestion here - switch from Postgress to MySQL. Most of our larger installations have other apps running on their PBX's and they need MySQL. Pretty much all of these companies resent running a 2nd major database service on the PBX. That's also a barrier for moving our FreePBX clients over to FreeSWITCH. A totally MySQL solution would be a big step forward.

I don't think there is a real reason for using PostgreSQL other than convience (eg. using GUID field type, whereas in MySQL you would use a char array type). The SQLite tables were actually a positive (anything to keep tables out of PostgreSQL).

 

[ardyhash]

Could I offer a suggestion here - switch from Postgress to MySQL. Most of our larger installations have other apps running on their PBX's and they need MySQL. Pretty much all of these companies resent running a 2nd major database service on the PBX. That's also a barrier for moving our FreePBX clients over to FreeSWITCH. A totally MySQL solution would be a big step forward.

I don't think there is a real reason for using PostgreSQL other than convience (eg. using GUID field type, whereas in MySQL you would use a char array type). The SQLite tables were actually a positive (anything to keep tables out of PostgreSQL).

Thats cute, but if there's one thing I've learned over the years is that the customer is never right. That's not to say those requresting MySQL are right either, Postgresql is the better choice. The people maintaining those larger installations really should get back to the basics and try to follow best practices, unfortunately its easier to get a job in tech than Chick-Fil-A or Chipotle, which is why they serve excellent food and people are stuck with subpar technology solutions.

 

[ttt]

I've found it risky to assume the customer is stupid and I know better. We deal with large clients (hospitals, US military, PSAP call centers, etc) and they have some very capable IT departments. I have no doubt that you are highly skilled so if you find the customer's point of view 'cute' then it's based on your career experience, but we tend to take a different approach.

 

[johnny]

It may help to understand some key differences here and a clear reason why PostgreSQL was chosen:

PostgreSQL and MariaDB are both highly capable open-source relational database management systems. Each has its strengths, making them better suited to different use cases and environments. When considering the use case of a PBX (Private Branch Exchange) system, which is a private telephone network used within a company or organization, certain features and capabilities of PostgreSQL might make it more appealing compared to MariaDB. Here are ten reasons why PostgreSQL could be considered better than MariaDB for a PBX system:

1. Advanced Data Types: PostgreSQL supports a wider range of data types including geometric primitives, network addresses, and JSONB. This is particularly useful for PBX systems that need to store complex data structures or require efficient querying within those data structures.
2. Superior Transactional Integrity: PostgreSQL adheres strictly to ACID (Atomicity, Consistency, Isolation, Durability) principles, providing robust transactional integrity and multi-version concurrency control. This ensures data consistency and reliability in PBX systems where transaction integrity is crucial.
3. Extensible Framework: PostgreSQL is highly extensible. Users can define their own data types, custom functions, and even code from different programming languages. This flexibility can be beneficial for integrating custom functionalities within a PBX system.
4. Full Text Search: PostgreSQL includes powerful full-text search capabilities that are easy to use, supporting complex search queries natively. This can be particularly useful for PBX systems in searching through call records, notes, or other textual data.
5. Superior Support for Geospatial Data: With its PostGIS extension, PostgreSQL offers advanced support for geographic objects, allowing for location-based queries and operations. This could be useful for PBX systems needing to manage data related to geographic locations, such as in dispatch systems or location-based routing.
6. Concurrency and Performance: PostgreSQL's MVCC (Multi-Version Concurrency Control) model offers high levels of concurrency, with improved performance in environments where read operations are more common than writes, which is often the case in PBX systems.
7. Robust Security Features: PostgreSQL offers strong built-in security features, including robust access controls, SSL for data encryption, and column-level encryption. This is essential for PBX systems that handle sensitive information.
8. Comprehensive Indexing: PostgreSQL supports a variety of indexing techniques, including B-tree, Hash, GiST, SP-GiST, GIN, and BRIN. This allows for faster query processing and can significantly enhance the performance of PBX systems with large datasets.
9. Large Community and Ecosystem: PostgreSQL has a large and active community, providing an extensive ecosystem of tools, extensions, and libraries. This can be beneficial for PBX systems requiring integration with other tools or needing custom extensions for specific functionalities.
10. Foreign Data Wrappers: PostgreSQL supports foreign data wrappers (FDWs), which allow it to connect and query other databases or data sources directly. This interoperability can be useful for PBX systems that need to integrate with other systems or databases.

While PostgreSQL offers many advantages, the best choice between PostgreSQL and MariaDB depends on the specific requirements of the PBX system, including factors like existing infrastructure, performance needs, and the skill set of the development team. MariaDB also has its strengths, such as a focus on scalability and speed, making it a worthy contender depending on the scenario.

 

[ardyhash]

Thanks Johnny for the detailed explanation, and sorry ttt for the tone. Just because something can be done doesn't always mean that it should, we could be living in a much better world if not for the fact that anyone who can do anything does so without considerations beyond their immediate wants or needs.

Experienced, people with knowledge beyond your customers' wants have invested good time in making the best decisions, then here you come making a 'suggestion' based purely on your requirements. The project is generously shared as open source, and frankly due to good decisions made during design I imagine its quite trivial to change the backend datasource, but to then write the documentation and do the testing and to have to support a configuration only the guy who isn't a contributor or customer is running suddenly makes a cool fun project feel like work work instead of fun work... but that doesn't excuse my poor tone, I should have done as Johnny did and shed light.

 

[NerdUno]

If I'm not mistaken, both Facebook and Meta use MySQL as their database engine of choice which is to say it scales pretty well.

 

[Adrian Fretwell]

If I'm not mistaken, both Facebook and Meta use MySQL as their database engine of choice which is to say it scales pretty well.

Currently only PostgreSQL is integrated into the core of FreeSWITCH - hence it is native. Other DBs can be used via ODBC but that would not be my choice.

 

[ardyhash]

I would have figured the meta crowd to be pioneers of NoSQL or graphQL, though not surprised, wouldn't even be surprised to learn they’ve spun up a few storage engines of their own.

 

[babak]

Currently only PostgreSQL is integrated into the core of FreeSWITCH - hence it is native. Other DBs can be used via ODBC but that would not be my choice.

Hi Adrian
Thank you for DjangoPBX and your other contributions.
As my understanding from release notes 1.10.0 pgsql removed from the core to its own module (mod_pgsql).
MariaDB has Galera for Master/Master replication and big VOIP Projects like Sipwise use them:
https://www.sipwise.com/docmr11.0.1/spce/ce/mr11.0.1/architecture/architecture.html

Regards.

​

​

 

[Adrian Fretwell]

Hi Babak,
Thank you for the information.

Yes there have been some changes, but read "Core" as having a native module available, as opposed to having to connect via ODBC or similar.
mod_mariadb is also available and has been around for about five years.
Mariadb was my database of choice for many years, but I have really enjoyed some of the extra features delivered by PostgreSql.

Database replication of any kind has to be implemented in the context of your system design criteria and Master/Master requires special attention. For example, take a simple Master/Slave setup implemented purely for fail over purposes. You would not want to blindly replicate the master because if someone has maliciously or accidentally corrupted your database, your would not want this damage immediately replicating to your fail over (slave) Db.

On a different note, but within the subject of this thread, we now have an add-on application built for accessing all the FreeSWITCH tables from within the DjangoPBX application. It is just going through some final testing before I upload it to the repository.

 

[babak]

Hi @Adrian Fretwell
Did you see any performance difference between SQLite and PostgreSQL?

 

[Adrian Fretwell]

Hi @babak
I have not yet noticed any difference, but we don't have any very heavily loaded systems to compare performance with. Several people have been doing some load testing using sipp with no reported issues.

SqLite in ramfs is going to be about as fast as you can get, but I don't mind sacrificing a little speed for the robustness and reliability of PostgreSql. The other advantage of putting the DB in PostgreSql is it allows me to expose read only API endpoints to the freeswitch data.

 

[manikanta]

Hi @Adrian Fretwell
I've been following your contributions in the FreeSWITCH community for quite some time now, and I truly appreciate your prompt and helpful responses to everyone's queries.
I'm currently encountering some difficulties configuring PostgreSQL in FreeSWITCH on Debian 12. Despite my efforts, I've found the available documentation to be outdated, leaving me in need of guidance. Given your expertise in FreeSWITCH, could you please assist me in properly setting up PostgreSQL with FreeSWITCH on Debian 12? Any insights or resources you can provide would be greatly appreciated. i'm getting following errors.

 

[Adrian Fretwell]

Yes, I will help if I can, I'm out most of today and tomorrow, so there may be a delay in my responding.
The DjangoPBX install script will give you some help on how we do it.

I have replicated the relevant sections below for you:

The steps are basically:
1. Make sure you create the FreeSWITCH databse and schema (don't let freeswitch do ti itself)
2. Set the DSN values in vars.xml
3. Edit the various config files in freeswitch/autoload_configs.

###############################################
# PostgreSQL
###############################################

apt-get install -y postgresql

cwd=$(pwd)
cd /tmp

# add the databases, users and grant permissions to them
sudo -u postgres psql -c "CREATE DATABASE djangopbx;";
sudo -u postgres psql -c "CREATE DATABASE freeswitch;";
sudo -u postgres psql -c "CREATE ROLE djangopbx WITH SUPERUSER LOGIN PASSWORD '$database_password';"
sudo -u postgres psql -c "CREATE ROLE freeswitch WITH SUPERUSER LOGIN PASSWORD '$database_password';"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE djangopbx to djangopbx;"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE freeswitch to freeswitch;"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE freeswitch to djangopbx;"
sudo -u postgres psql -c 'CREATE EXTENSION IF NOT EXISTS "uuid-ossp";'
# create the freeswitch schema
sudo -u postgres psql -d freeswitch -1 -f /home/django-pbx/pbx/switch/resources/templates/sql/switch.sql
cd $cwd


###############################################
# Freeswitch core DB in postgreSql
###############################################
if [[ $freeswitch_core_in_postgres == "yes" ]]
then
    echo " "
    echo "Updating Switch DSNs..."
    sudo -u django-pbx bash -c "source ~/envdpbx/bin/activate && cd /home/django-pbx/pbx && python3 manage.py updateswitchvariable --category DSN --name dsn --value \"pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='${database_password}'\""
    sudo -u django-pbx bash -c "source ~/envdpbx/bin/activate && cd /home/django-pbx/pbx && python3 manage.py updateswitchvariable --category DSN --name dsn_callcentre --value \"pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='${database_password}'\""
    sudo -u django-pbx bash -c "source ~/envdpbx/bin/activate && cd /home/django-pbx/pbx && python3 manage.py updateswitchvariable --category DSN --name dsn_voicemail --value \"pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='${database_password}'\""
    sed -r -i 's/<!-- (<param name="core-db-dsn" value="\$\$\{dsn\}" \/>) -->/\1/g' /home/django-pbx/freeswitch/autoload_configs/switch.conf.xml
    sed -r -i 's/<!-- (<param name="auto-create-schemas" value="false"\/>) -->/\1/g' /home/django-pbx/freeswitch/autoload_configs/switch.conf.xml
    sed -r -i 's/<!-- (<param name="auto-clear-sql" value="false"\/>) -->/\1/g' /home/django-pbx/freeswitch/autoload_configs/switch.conf.xml
    sed -r -i 's/<!--(<param name="odbc-dsn" value="\$\$\{dsn\}"\/>)-->/\1/g' /home/django-pbx/freeswitch/autoload_configs/voicemail.conf.xml
    sed -r -i 's/<!--(<param name="odbc-dsn" value="\$\$\{dsn\}"\/>)-->/\1/g' /home/django-pbx/freeswitch/autoload_configs/fifo.conf.xml
    sed -r -i 's/<!--(<param name="odbc-dsn" value="\$\$\{dsn\}"\/>)-->/\1/g' /home/django-pbx/freeswitch/autoload_configs/db.conf.xml
    sed -r -i 's/(<param name="dbname" value="\/var\/lib\/freeswitch\/vm_db\/voicemail_default.db"\/>)/<!--\1-->/g' /home/django-pbx/freeswitch/autoload_configs/voicemail.conf.xml
    sudo -u postgres psql -d djangopbx -c "update pbx_sip_profile_settings set enabled = 'true' where name = 'odbc-dsn';"
    sudo -u django-pbx bash -c 'source ~/envdpbx/bin/activate && cd /home/django-pbx/pbx && python3 manage.py writeoutswitchvars'
fi

 

[manikanta]

Thank you very much @Adrian Fretwell for your prompt response and the valuable information provided regarding the "dsn" value in the "vars.xml" file. Your assistance is greatly appreciated.

However, as I am relatively new to FreeSWITCH, I find myself a bit lost regarding which files need to be edited in the freeswitch/autoload_configs directory. Could you please guide me through all the relevant steps, considering my beginner level of familiarity with FreeSWITCH? Your expertise would be immensely helpful as I work on configuring FreeSWITCH for my graduation project. Once again, thank you for your time and willingness to assist.

 

[Adrian Fretwell]

Ok the files in autoload_configs are:

callcenter.conf.xml
db.conf.xml
fifo.conf.xml
switch.conf.xml
voicemail.conf.xml

If you are delivering configuration dynamically with DjangoPBX or similar, modifications to callcenter.conf.xml are not required.

The parameters reference variables that are set in vars.xml:

<!-- DSN -->
<X-PRE-PROCESS cmd="set" data="dsn=pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='postgres-insecure-abcdef9876543210'" />
<X-PRE-PROCESS cmd="set" data="dsn_callcentre=pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='postgres-insecure-abcdef9876543210'" />
<X-PRE-PROCESS cmd="set" data="dsn_voicemail=pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='postgres-insecure-abcdef9876543210'" />

Obviously change the password value to whatever your database password is set to.

I don't know how well you read diff files, but here are the diffs between the modified configs and the original ones:

diff db.conf.xml /etc/freeswitch.orig/autoload_configs/db.conf.xml

3c3
<     <param name="odbc-dsn" value="$${dsn}"/>
---
>     <!--<param name="odbc-dsn" value="dsn:user:pass"/>-->

diff fifo.conf.xml /etc/freeswitch.orig/autoload_configs/fifo.conf.xml

3d2
<     <param name="odbc-dsn" value="$${dsn}"/>

diff switch.conf.xml /etc/freeswitch.orig/autoload_configs/switch.conf.xml

3,156c3,197
<     <cli-keybindings>
<         <key name="1" value="help"/>
<         <key name="2" value="status"/>
<         <key name="3" value="show channels"/>
<         <key name="4" value="show calls"/>
<         <key name="5" value="sofia status"/>
<         <key name="6" value="reloadxml"/>
<         <key name="7" value="console loglevel 0"/>
<         <key name="8" value="console loglevel 7"/>
<         <key name="9" value="sofia status profile internal"/>
<         <key name="10" value="sofia profile internal siptrace on"/>
<         <key name="11" value="sofia profile internal siptrace off"/>
<         <key name="12" value="version"/>
<     </cli-keybindings>
<
<     <default-ptimes>
<         <!-- Set this to override the 20ms assumption of various codecs in the sdp with no ptime defined -->
<         <!-- <codec name="G729" ptime="40"/> -->
<     </default-ptimes>
<
<     <settings>
<         <!-- Colorize the Console -->
<         <param name="colorize-console" value="true"/>
<
<         <!-- Run the timer at 20ms by default and drop down as needed unless you set 1m-timer=true which was previous default -->
<         <!-- <param name="1ms-timer" value="true"/> -->
<
<         <!--
<         Set the Switch Name for HA environments.
<         When setting the switch name, it will override the system hostname for all DB and CURL requests
<         allowing cluster environments such as RHCS to have identical FreeSWITCH configurations but run
<         as different hostnames.
<         -->
<         <!-- <param name="switchname" value="freeswitch"/> -->
<
<         <!-- Maximum number of simultaneous DB handles open -->
<         <param name="max-db-handles" value="50"/>
<         <!-- Maximum number of seconds to wait for a new DB handle before failing -->
<         <param name="db-handle-timeout" value="10"/>
<
<         <!-- Minimum idle CPU before refusing calls -->
<         <!-- <param name="min-idle-cpu" value="25"/> -->
<
<         <!--
<         Max number of sessions to allow at any given time.
<
<         NOTICE: If you're driving 28 T1's in a single box you should set this to 644*2 or 1288
<         this will ensure you're able to use the entire DS3 without a problem.  Otherwise you'll
<         be 144 channels short of always filling that DS3 up which can translate into waste.
<         -->
<         <param name="max-sessions" value="1000"/>
<         <!--Most channels to create per second -->
<         <param name="sessions-per-second" value="30"/>
<         <!-- Default Global Log Level - value is one of debug,info,notice,warning,err,crit,alert -->
<         <param name="loglevel" value="err"/>
<
<         <!-- Set the core DEBUG level (0-10) -->
<         <!-- <param name="debug-level" value="10"/> -->
<
<         <!-- SQL Buffer length within rage of 32k to 10m -->
<         <!-- <param name="sql-buffer-len" value="1m"/> -->
<         <!-- Maximum SQL Buffer length must be greater than sql-buffer-len -->
<         <!-- <param name="max-sql-buffer-len" value="2m"/> -->
<
<         <!--
<          The min-dtmf-duration specifies the minimum DTMF duration to use on
<          outgoing events. Events shorter than this will be increased in duration
<          to match min_dtmf_duration. You cannot configure a dtmf duration on a
<          profile that is less than this setting. You may increase this value,
<          but cannot set it lower than 400. This value cannot exceed
<          max-dtmf-duration. -->
<         <param name="min-dtmf-duration" value="640"/>
<
<         <!--
<          The max-dtmf-duration caps the playout of a DTMF event at the specified
<          duration. Events exceeding this duration will be truncated to this
<          duration. You cannot configure a duration on a profile that exceeds
<          this setting. This setting can be lowered, but cannot exceed 192000.
<          This setting cannot be set lower than min_dtmf_duration. -->
<         <!-- <param name="max-dtmf-duration" value="192000"/> -->
<
<         <!--
<          The default_dtmf_duration specifies the DTMF duration to use on
<          originated DTMF events or on events that are received without a
<          duration specified. This value can be increased or lowered. This
<          value is lower-bounded by min_dtmf_duration and upper-bounded by
<          max-dtmf-duration\. -->
<         <!-- <param name="default-dtmf-duration" value="2000"/> -->
<
<         <!--
<         If you want to send out voicemail notifications via Windows you'll need to change the mailer-app
<         variable to the setting below:
<
<         <param name="mailer-app" value="msmtp"/>
<
<         Do not change mailer-app-args.
<         You will also need to download a sendmail clone for Windows (msmtp). This version works without issue:
<         http://msmtp.sourceforge.net/index.html. Download and copy the .exe to %winddir%\system32.
<         You'll need to create a small config file for smtp credentials (host name, authentication, tls, etc.) in
<         %USERPROFILE%\Application Data\ called "msmtprc.txt". Below is a sample copy of this file:
<
<         ###################################
<         # The SMTP server of the provider.
<         account provider
<         host smtp.myisp.com
<         from john@myisp.com
<         auth login
<         user johndoe
<         password mypassword
<
<              # Set a default account
<              account default : provider
<              ###################################
<         -->
<         <!--<param name="mailer-app" value="sendmail"/>-->
<         <!--<param name="mailer-app-args" value="-t"/>-->
<         <param name="mailer-app" value="/home/django-pbx/pbx/pbx/scripts/sendmail.py"/>
<         <param name="mailer-app-args" value="-t"/>
<         <param name="dump-cores" value="yes"/>
<         <!-- Enable verbose channel events to include every detail about a channel on every event  -->
<         <!-- <param name="verbose-channel-events" value="no"/> -->
<
<         <!-- Enable clock nanosleep -->
<         <!-- <param name="enable-clock-nanosleep" value="true"/> -->
<
<         <!-- Enable monotonic timing -->
<         <!-- <param name="enable-monotonic-timing" value="true"/> -->
<
<         <!-- NEEDS DOCUMENTATION -->
<         <!-- <param name="enable-softtimer-timerfd" value="true"/> -->
<         <!-- <param name="enable-cond-yield" value="true"/> -->
<         <!-- <param name="enable-timer-matrix" value="true"/> -->
<         <!-- <param name="threaded-system-exec" value="true"/> -->
<         <!-- <param name="tipping-point" value="0"/> -->
<         <!-- <param name="timer-affinity" value="disabled"/> -->
<         <!-- NEEDS DOCUMENTATION -->
<
<         <!-- RTP port range -->
<         <!-- <param name="rtp-start-port" value="16384"/> -->
<         <!-- <param name="rtp-end-port" value="32768"/> -->
<
<         <!-- <param name="rtp-enable-zrtp" value="true"/> -->
<
<         <param name="core-db-dsn" value="$${dsn}" />
<         <!--
<          Allow to specify the sqlite db at a different location (In this example, move it to ramdrive for
<          better performance on most linux distro (note, you loose the data if you reboot))
<         -->
<         <!-- <param name="core-db-name" value="/dev/shm/core.db" /> -->
<
<         <!-- The system will create all the db schemas automatically, set this to false to avoid this behaviour -->
<         <param name="auto-create-schemas" value="false"/>
<         <param name="auto-clear-sql" value="false"/>
<         <!-- <param name="enable-early-hangup" value="true"/> -->
---
>   <cli-keybindings>
>     <key name="1" value="help"/>
>     <key name="2" value="status"/>
>     <key name="3" value="show channels"/>
>     <key name="4" value="show calls"/>
>     <key name="5" value="sofia status"/>
>     <key name="6" value="reloadxml"/>
>     <key name="7" value="console loglevel 0"/>
>     <key name="8" value="console loglevel 7"/>
>     <key name="9" value="sofia status profile internal"/>
>     <key name="10" value="sofia profile internal siptrace on"/>
>     <key name="11" value="sofia profile internal siptrace off"/>
>     <key name="12" value="version"/>
>   </cli-keybindings>
>   
>   <default-ptimes>
>     <!-- Set this to override the 20ms assumption of various codecs in the sdp with no ptime defined -->
>     <!-- <codec name="G729" ptime="40"/> -->
>   </default-ptimes>
>   
>   <settings>
>     <!-- Colorize the Console -->
>     <param name="colorize-console" value="true"/>
>
>     <!--Include full timestamps in dialplan logs -->
>     <param name="dialplan-timestamps" value="false"/>
>
>     <!-- Run the timer at 20ms by default and drop down as needed unless you set 1m-timer=true which was previous default -->
>     <!-- <param name="1ms-timer" value="true"/> -->
>
>     <!--
>     Set the Switch Name for HA environments.
>     When setting the switch name, it will override the system hostname for all DB and CURL requests
>     allowing cluster environments such as RHCS to have identical FreeSWITCH configurations but run
>     as different hostnames.
>     -->
>     <!-- <param name="switchname" value="freeswitch"/> -->
>     <!-- <param name="cpu-idle-smoothing-depth" value="30"/> -->
>
>
>     <!-- Maximum number of simultaneous DB handles open -->
>     <param name="max-db-handles" value="50"/>
>     <!-- Maximum number of seconds to wait for a new DB handle before failing -->
>     <param name="db-handle-timeout" value="10"/>
>
>     <!-- Minimum idle CPU before refusing calls -->
>     <!-- <param name="min-idle-cpu" value="25"/> -->
>
>     <!-- Interval between heartbeat events -->
>     <!-- <param name="event-heartbeat-interval" value="20"/> -->
>
>     <!--
>     Max number of sessions to allow at any given time.
>     
>     NOTICE: If you're driving 28 T1's in a single box you should set this to 644*2 or 1288
>     this will ensure you're able to use the entire DS3 without a problem.  Otherwise you'll
>     be 144 channels short of always filling that DS3 up which can translate into waste.
>     -->
>     <param name="max-sessions" value="1000"/>
>     <!--Most channels to create per second -->
>     <param name="sessions-per-second" value="30"/>
>     <!-- Default Global Log Level - value is one of debug,info,notice,warning,err,crit,alert -->
>     <param name="loglevel" value="debug"/>
>
>     <!-- Set the core DEBUG level (0-10) -->
>     <!-- <param name="debug-level" value="10"/> -->
>
>     <!-- SQL Buffer length within rage of 32k to 10m -->
>     <!-- <param name="sql-buffer-len" value="1m"/> -->
>     <!-- Maximum SQL Buffer length must be greater than sql-buffer-len -->
>     <!-- <param name="max-sql-buffer-len" value="2m"/> -->
>
>     <!--
>      The min-dtmf-duration specifies the minimum DTMF duration to use on
>      outgoing events. Events shorter than this will be increased in duration
>      to match min_dtmf_duration. You cannot configure a dtmf duration on a
>      profile that is less than this setting. You may increase this value,
>      but cannot set it lower than 400. This value cannot exceed
>      max-dtmf-duration. -->
>     <!-- <param name="min-dtmf-duration" value="400"/> -->
>
>     <!--
>      The max-dtmf-duration caps the playout of a DTMF event at the specified
>      duration. Events exceeding this duration will be truncated to this
>      duration. You cannot configure a duration on a profile that exceeds
>      this setting. This setting can be lowered, but cannot exceed 192000.
>      This setting cannot be set lower than min_dtmf_duration. -->
>     <!-- <param name="max-dtmf-duration" value="192000"/> -->
>
>     <!--
>      The default_dtmf_duration specifies the DTMF duration to use on
>      originated DTMF events or on events that are received without a
>      duration specified. This value can be increased or lowered. This
>      value is lower-bounded by min_dtmf_duration and upper-bounded by
>      max-dtmf-duration\. -->
>     <!-- <param name="default-dtmf-duration" value="2000"/> -->
>
>     <!--
>     If you want to send out voicemail notifications via Windows you'll need to change the mailer-app
>     variable to the setting below:
>     
>     <param name="mailer-app" value="msmtp"/>
>     
>     Do not change mailer-app-args.
>     You will also need to download a sendmail clone for Windows (msmtp). This version works without issue:
>     http://msmtp.sourceforge.net/index.html. Download and copy the .exe to %winddir%\system32.
>     You'll need to create a small config file for smtp credentials (host name, authentication, tls, etc.) in
>     %USERPROFILE%\Application Data\ called "msmtprc.txt". Below is a sample copy of this file:
>     
>     ###################################
>     # The SMTP server of the provider.
>     account provider
>     host smtp.myisp.com
>     from john@myisp.com
>     auth login
>     user johndoe
>     password mypassword
>     
>     # Set a default account
>     account default : provider
>     ###################################
>     
>     -->   
>
>     <param name="mailer-app" value="sendmail"/>
>     <param name="mailer-app-args" value="-t"/>
>     <param name="dump-cores" value="yes"/>
>
>     <!-- Enable verbose channel events to include every detail about a channel on every event  -->
>     <!-- <param name="verbose-channel-events" value="no"/> -->
>
>     <!-- Enable clock nanosleep -->
>     <!-- <param name="enable-clock-nanosleep" value="true"/> -->
>
>     <!-- Enable monotonic timing -->
>     <!-- <param name="enable-monotonic-timing" value="true"/> -->
>
>     <!-- NEEDS DOCUMENTATION -->
>     <!-- <param name="enable-softtimer-timerfd" value="true"/> -->
>     <!-- <param name="enable-cond-yield" value="true"/> -->
>     <!-- <param name="enable-timer-matrix" value="true"/> -->
>     <!-- <param name="threaded-system-exec" value="true"/> -->
>     <!-- <param name="tipping-point" value="0"/> -->
>     <!-- <param name="timer-affinity" value="disabled"/> -->
>     <!-- NEEDS DOCUMENTATION -->
>
>     <!-- RTP port range -->
>     <!-- <param name="rtp-start-port" value="16384"/> -->
>     <!-- <param name="rtp-end-port" value="32768"/> -->
>
>     <!-- Test each port to make sure it is not in use by some other process before allocating it to RTP -->
>     <!-- <param name="rtp-port-usage-robustness" value="true"/> -->
>
>     <!--
>      Store encryption keys for secure media in channel variables and call CDRs. Default: false.
>      WARNING: If true, anyone with CDR access can decrypt secure media!
>     -->
>     <!-- <param name="rtp-retain-crypto-keys" value="true"/> -->
>
>     <!--
>      Native PostgreSQL support was removed from the FreeSWITCH Core!
>      =================================
>      NOTICE: You MUST enable mod_pgsql       
>      =================================
>      According to https://www.postgresql.org/docs/9.6/libpq-connect.html#LIBPQ-CONNSTRING
>      There are two accepted formats for connection strings supported by the libpq library:
>      * For plain keyword = value strings use pgsql://
>        pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='' options='-c client_min_messages=NOTICE'
>      * For RFC 3986 URIs use postgresql:// or postgres://
>        postgresql://
>        postgresql://localhost
>        postgresql://localhost:5433
>        postgresql://localhost/mydb
>        postgresql://user@localhost
>        postgresql://user:secret@localhost
>        postgresql://other@localhost/otherdb?connect_timeout=10&application_name=myapp
>        postgresql:///mydb?host=localhost&port=5433
>     -->
>     <!-- <param name="core-db-dsn" value="pgsql://hostaddr=127.0.0.1 dbname=freeswitch user=freeswitch password='' options='-c client_min_messages=NOTICE'" /> -->
>     <!-- <param name="core-db-dsn" value="postgresql://freeswitch:@127.0.0.1/freeswitch?options=-c%20client_min_messages%3DNOTICE" /> -->
>     <!-- <param name="core-db-dsn" value="mariadb://Server=localhost;Database=freeswitch;Uid=freeswitch;Pwd=pass;" /> -->
>     <!-- <param name="core-db-dsn" value="dsn:username:password" /> -->
>
>     <!-- <param name="odbc-skip-autocommit-flip" value="true" /> -->
>
>     <!--
>      Allow to specify the sqlite db at a different location (In this example, move it to ramdrive for
>      better performance on most linux distro (note, you loose the data if you reboot))
>     -->
>     <!-- <param name="core-db-name" value="/dev/shm/core.db" /> -->
>
>     <!-- The system will create all the db schemas automatically, set this to false to avoid this behaviour -->
>     <!-- <param name="auto-create-schemas" value="true"/> -->
>     <!-- <param name="auto-clear-sql" value="true"/> -->
>     <!-- <param name="enable-early-hangup" value="true"/> -->
158c199
<         <!-- <param name="core-dbtype" value="MSSQL"/> -->
---
>     <!-- <param name="core-dbtype" value="MSSQL"/> -->
160,161c201,202
<         <!-- Allow multiple registrations to the same account in the central registration table -->
<         <!-- <param name="multiple-registrations" value="true"/> -->
---
>     <!-- Allow multiple registrations to the same account in the central registration table -->
>     <!-- <param name="multiple-registrations" value="true"/> -->
163c204,206
<     </settings>
---
>     <!-- <param name="max-audio-channels" value="2"/> -->
>
>   </settings>
165a209
>

diff voicemail.conf.xml /etc/freeswitch.orig/autoload_configs/voicemail.conf.xml

18,19c18,23
<       <param name="login-keys" value="*"/>
<       <param name="main-menu-key" value="*"/>
---
>       <!-- play-new-messages-lifo and play-saved-messages-lifo default is false, playing oldest messages first
>        <param name="play-new-messages-lifo" value="false"/>
>        <param name="play-saved-messages-lifo" value="false"/>
>       -->
>       <param name="login-keys" value="0"/>
>       <param name="main-menu-key" value="0"/>
41c45
<       <param name="record-silence-hits" value="10"/>
---
>       <param name="record-silence-hits" value="2"/>
51c55
<       <param name="operator-key" value="0"/>
---
>       <param name="operator-key" value="9"/>
63,64c67,68
<       <!--<param name="storage-dir" value="/tmp"/>-->
<       <param name="odbc-dsn" value="$${dsn}"/>
---
>       <!--<param name="storage-dir" value="$${storage_dir}"/>-->
>       <!--<param name="odbc-dsn" value="dsn:user:pass"/>-->
68d71
<       <!--<param name="dbname" value="/var/lib/freeswitch/vm_db/voicemail_default.db"/>-->
71c74
< </configuration>
---
> </configuration>

You will find details of the FreeSWITCH schema here:
/home/django-pbx/pbx/switch/resources/templates/sql/switch.sql

I hope that is helpful.

 

[manikanta]

Hi @Adrian Fretwell . I hope this message finds you well. I've been facing persistent challenges with connecting my database to FreeSWITCH and encountered issues with Linphone connectivity through DjangoPBX. Your guidance has been invaluable thus far, and I'm reaching out for further assistance with humility and gratitude. Any insights or advice you could offer would be greatly appreciated.