Trying to Decrease PDD in FusionPBX & FreeSWITCH

These holidays I got an observation from one of my customers. His carrier claims that PDD was variable with some 6-second peaks. Although 6 seconds I believe it is not that critical, it is in the annoying area. Usually, 3-4 seconds are acceptable.

First, I will define what is PDD. From: NICC ND 1704 V1.2.2 2009-05 End-to-End Network Performance Rules & Objectives for the Interconnection of NGNs

For SIP the PDD would be the time from Sending the INVITE to receiving the first ringing response for example: an SIP/2.0 180 Ringing response.

FreeSWITCH and FusionPBX Information Flow

Before starting to explain where to look at, and what you may do, I will explain the flow information. If you are using FusionPBX (and FreeSWITCH of course) with my RPM's or with the vanilla installer, it is most likely you are using a database backend.

Usually, when a call starts (it does not matter if it is from extension or from PSTN), with FusionPBX it follows this path:

1. The SIP INVITE signal is sent and it travels across the cloud until it arrives at the server, which it is caught by the FreeSWITCH daemon
2. FusionPBX has Memcache support, it will try to consult if the requested XML is there. If it is, go to step 4
3. The XML Handler from FusionPBX will consult the database and extract the requested XML. Depending on your configuration, if you have your profile using a database and call-tracking option is on (most likely if you are in a load balanced or high availability environment), the FreeSWITCH daemon will update in the database the state of your call. FusionPBX XML Handler will fee the Memcache for future use.
4. FreeSWITCH sends the INVITE to the destination. If the destination is enabled (in this example it is), it will send an ACK and RINGING signal back.
5. FreeSWITCH will update into the database the call state as specified in step 3
6. FreeSWITCH will send an ACN and RINGING signal to the origin. This is when you listen the ring-bank

Many Bottlenecks?

Short answer yes. The more complex is your call flow, possible bottlenecks you have. The last example showed a stand-alone FusionPBX server, in which I can identify the following bottlenecks:

• Caching: a cache that does not hit very often is a cache that it is wasting space.
• Database: it really depends on what you want to do, in a stand-alone deployment you do not need to record call states or storing the core database in an external database. Please note that high availability or load balanced need database.

If you are in a high availability or load balanced environment, the call flow is much more complex and the database interaction more intense.

If you are using a database cluster, you need to see what I/O impact does your database have.

Some Actions

Here there are some actions I would suggest based on my experience:

• Rise Memcache TTL objects, FusionPBX by default has 3600 seconds (1 hour). I have learned that once dial-plan configuration is done, they do not change very often. Raising your TTL to 86400 seconds (1 day) is a safe approach.
• Central or WEB Cache strategy: if you are using more than one server (AKA load balancing or high availability), you might want to keep your caches in sync. There are two ways to do this:
  • Central Memcached Server: all FreeSWITCH servers point there
  • WEB Mesh: all FreeSWITCH servers point to all Memcached servers
• Use Indexes in your database: when you install FusionPBX, the installer will create many tables. These tables contain information that is linked somehow among them. If you read the code, you will find that there are many complex SELECTS that involve more than one table. Sadly, as far as I have researched, there is no indexing in the database, which it impacts the performance. Using indexing will speed up many SQL queries, especially those involved with directory and dial-plan. If you are using my RPM's, they push indexing in your database then you are covered.
• Tun your database: regardless if you are with PostgreSQL or MySQL/MariaDB, both databases need babysitting and parameter tuning. You will need to tune your database to answer to queries as fast as possible. Please note that speed is directly related to memory assigned and if you are using HDD or SDD, but do not forget tuning your parameters, a server with 32GB of RAM may have worst performance than one with 4 GB of RAM if it is not tunned. For example: turn on the query cache.
• Turn off options: for example, if you are not using high availability it is safe to turn off the call-tracking feature in the sofia sip profiles. There are others parameters.
• Use a RAM or TMPFS partition for DB: if you are not using a database as a backend, you will need to speed up I/O access as much as possible. One way is to put a RAM or TMPFS mount point where FreeSWITCH writes the SQLite files, usually, it is in /var/lib/freeswitch/db.

Nasty Workaround

If you put a dial-plan that does a pre_answer action when hitting the server, this will send the RINGING signal back to the origin without waiting that the destination is reached or not. However, this might backfire:

• Origin will listen to the ring-back tone, and if something happens it will change to busy or congestion tone.
• Debugging will be very difficult as user feedback will be almost the same in all scenarios

I suggest you go for the actions and use the workaround as the last resource.

Enjoy!