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
Post Dial Delay (PDD) is experienced by the originating customer as the time from the sending of the final dialled digit to the point at which they hear ringtone or other in-band information. Where the originating network is required to play an announcement before completing the call then this definition of PDD excludes the duration of such announcements.
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 of information. If you are using FusionPBX (and FreeSWITCH of course) with my RPMs 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 an extension or PSTN), with FusionPBX it follows this path:
- The SIP INVITE signal is sent and it travels across the cloud until it arrives at the server, which is caught by the FreeSWITCH daemon
- FusionPBX has Memcache support, it will try to consult if the requested XML is there. If it is, go to step 4
- 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 the 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 fix the Memcache for future use.
- 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.
- FreeSWITCH will update into the database the call state as specified in Step 3
- FreeSWITCH will send an ACN and RINGING signal to the origin. This is when you listen to the ring-bank
Many Bottlenecks?
Short answer yes. The more complex 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 is wasting space.
- Database: it depends on what you want to do, in a stand-alone deployment you do not need to record call states or store the core database in an external database. Please note that high availability or load balance needs a database.
If you are in a high availability or load-balanced environment, the call flow is much more complex and the database interaction is more intense.
If you are using a database cluster, you need to see what I/O impact your database has.
Some Actions
Here 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 many complex SELECTS involve more than one table. Sadly, as far as I have researched, there is no indexing in the database, which impacts the performance. Using indexing will speed up many SQL queries, especially those involved with directory and dial-plan. If you are using my RPMs, 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 queries as fast as possible. Please note that speed is directly related to the memory assigned and if you are using HDD or SDD, do not forget to tune your parameters, a server with 32GB of RAM may have worse 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 other 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 for the destination to be reached or not. However, this might backfire:
- Origin will listen to the ring-back tone, and if something happens it will change to a busy or congested 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!
";