- Details
- Category: Technology
This could be wrong or could be right. I do not know, but what I have seen is that since the COVID-19 pandemic started, businesses have been struggling with how to get income. Sadly, some indispensable businesses know their status and they have started to impose new fees. The telecommunication industry is no exception; since November 2020 at some point, carriers started to apply a short call policy with a fee. If the policy already existed and is not enforced, I can't tell, but what I can is the charge. If you ask one of them why the charge, they will answer they try to stop dialers. Again, nobody can tell if this is the real reason.
Read more: Fighting the Short Calls Policy Imposed by VoIP Carriers (Part 1)
- Details
- Category: Technology
So I have decided to make public the most useful SQL queries I have developed while dealing with FusionPBX. Please note that I am a MariaDB user, I have no intention to translate to PostgreSQL for free. Remember to change them to fit your specific needs.
- Details
- Category: Technology
These last days of 2020 I have spent hours patching the "soon-to-be" FusionPBX 4.6. One of the things I don't like is the way the cache engine is designed. Since FusionPBX 4.4, there are two ways of doing cache:
- using a file system cache (default),
- using the classic Memcache
I will first talk about how they are now (Dec 30th, 2020) and what my published pull request will fix and enhance.
File System Cache in FusionPBX
Available in FusionPBX 4.4 and turned on by default, the file system cache engine writes all its information in the directory specified by the default setting cache - location - text; by default, it points to /var/cache/fusionpbx. I have never liked the way it is at this point:
- it adds unnecessary I/O, although this could be worked around using the tmpfs filesystem,
- it lacks an expiration mechanism therefore all objects created are valid until the given file is manually deleted. This could give some kind of persistence, but if fast I/O is your priority (tmpfs deployed), then persistence can't be archived. It also messes up with VoIP clusters.
Nowadays, hard disks are pretty fast, but they will never be as fast as RAM.
Enhancements and Fixes of the File Cache
My pull request adds the following:
- expiration mechanism
At this very moment, all the files are stored with the key as a file name. There is no way to specify somehow the expiration timestamp. My solution is simple, adding a numeric extension with the Unix time (aka epoch time) of when that given object will expire. If an object with the key 'directory:100@mydomain' is created with an expiration date of January 27th, 2021 07:49:00, then the file
- Set for a second time the same key: the PR will delete all the directory.100@mydomain.* files before creating again the new filename.
- Delete the key: the PR will delete all the directory.100@mydomain.* files.
- Read the key: the PR will get all the 100@mydomain.* files, then it will split the extensions and select the one with the highest value; and only if that selected value is less or equal to the current timestamp it will return the value, otherwise it will return a not found as usual.
If you are familiar with my pull requests, you will find a PR that fixes the Azure STT voicemail. The issue here is that because the current file cache engine lacks an expiration mechanism, the authorization token from Azure will expire and the LUA code won't be able to make a difference if it should reuse it or not. If you must use Azure STT, you can use this patch or switch to Memcached.
Memcached System Cache in FusionPBX
At this very moment, the PHP and LUA code in FusionPBX connects to the FreeSWITCH event socket and pushes Memcache commands through it. In my opinion, this has a lot of limitations, for starters:
- You can't split the FusionPBX to another server. If you do anyway, you must have turned off a local FreeSWITCH daemon which is a waste of resources just to do cache operations.
- The Memcached server is always localhost. On big deployments (clusters), saving some database queries will make a difference in performance, then having a way to specify more than one server and a different port than 11211 is crucial. Please read my article about the Memcache Protocol Router to have an insight into Memcached clusters.
Enhancements and Fixes of the Memcached Cache
My pull request adds the following:
- ability to use the pecl-memcached package if present,
- ability to not depend on a local freeswitch to interact with Memcache,
- ability to specify a different Memcache server than 127.0.0.1:11211 and more than one Memcache server,
- if your PHP deployment has installed the PECL Memcached extension use it.
Please report to me any bug regarding this, I will gladly fix it as soon as possible.
Happy VoIP and good luck!
- Details
- Category: Technology
CentOS 6 has reached its EOF last November 2020. The truth is that it is harder and harder to maintain a very old distribution by updating packages without breaking dependencies.
I will stop adding new RPMs for CentOS 6. You are very welcome to use them while they are published.
If someone needs something for CentOS 6, please contact me.
Good luck!
- Details
- Category: Technology
It is not news that many people are searching for the not-very-new codec G.729. Since 2018 (please google it), the codec G.729 is not under patent, therefore you can use it without paying patent fees. This is a huge step for the VoIP work, why? Because the G.729 codec offers many advantages, one is the low bandwidth requirement; it needs about 11 kbps up and down each. If you think it, the less bandwidth required means your service will be more tolerant of the overuse of links. It is widespread that in an office or a residence, more than one is watching any streaming or downloading a big file.
Because of this, I think it is very important to tell the world how to install G.729 on your FreeSWITCH server.
Read more: Enabling the G.729 Codec in FreeSWITCH (FusionPBX)
