Re-installing from the old Centos ISO on a new machine, there is a really simple way to bring fusionpbx up to date. Go to /var/www and do rm -r -f fusionpbx. Then svn checkout http://fusionpbx.googlecode.com/svn/trunk/fusionpbx. Then svn update. This will download all the latest fusionpbx code.
Then chmod -R 776 fusionpbx and chown -R apache:daemon fusionpbx to set the permissions correctly and now you can go to the web gui and log in - as it will be the first time it will take you through the install dialogs and then you are up and running with a brand new pbx.
Of course, you don't actually have to be installing from the Centos ISO. If you are running Centos (or presumably any other OS with svn available) you can follow the same procedure. The only thing is in this case you will have had to already install freeswitch (which can't be installed that simply as far as I can determine - you'll need to be able to compile it and I haven't tried that yet).
Once you've installed fusionpbx this way, if you want, rather than pressing the upgrade button in the GUI, you can always go to the shell prompt and cd /var/www/fusionpbx and do svn update. However, after doing this you also need to go to http://yourpbxipaddress/core/upgrade/upgrade_schema.php as that will ensure that your database is updated to include any new tables that have been added with the latest update.
Thursday, September 23
Tuesday, September 21
Things to be aware of in pfsense fusionpbx (including module problems) and why I am returning to centos (but pfsense may still be good for you)
By default, fusionpbx web GUI communicates with various parts of freeswitch using an event socket (implemented through the module mod_event_socket) on 127.0.0.1 port 8021. Unfortunately in pfsense, the loopback address is somehow disabled, therefore if you are using pfsense you have to change this to use the specific IP address of your server instead. You have to do this in two places. One is System-Settings, and the other is Advanced-XML Editor-Autoload_configs/event_socket.conf.xml (param name="listen-ip" - change the value). After saving these two changes and restarting freeswitch it will work.
I also ran into some problems with modules in the pfsense version of fusionpbx. The modules section of fusionpbx defined a module called hash. I had to edit this by replacing each instance of the word hash to limit. so mod_hash became mod_limit.
This was preventing javascripts from running. However, javascripts were also prevented from running because of a fault loading spidermonkey (it cannot be made to load as it claims to be missing library files which are present) and accordingly, if you need javascript support the current release of freeswitch for pfsense is not going to work for you. If you can use LUA instead then you should be ok. Unfortunately the only way to upgrade freeswitch on pfsense is to recompile a new copy, which can't be done on pfsense because the necessary files are missing and can't be loaded, so you need to have a freebsd install that matches the pfsense install and compile it there and transfer the files over - too complicated for me at this point.
So for now, this is where I leave pfsense. I will return to Centos as I need the javascript support at this point in time. The other reasons I am leaving pfsense at this time are:
- I can't find an easy way to back up the harddrive image as the unix applications I know how to use (eg. gparted and partimage) are not available in freebsd and if I install tinycore linux on the same system and run them from there instead, I still can't access the pfsense harddrive area because it is running ufs which apparently isn't supported in linux. Someone with a better understanding of freebsd probably doesn't have this problem.
- I was struggling to get the phone system to work the way I wanted it - with pfsense 1.2.3 you have to have two network cards. Fusionpbx binds to the WAN card, so I wanted to have the LAN card with nothing plugged into it and to have all the phones connected on the WAN side. ie. fusionpbx would be a node on the private LAN but connected only by the WAN card. I couldn't get the phones to register with it when setup this way - probably because I wasn't fully understanding the firewall functionality in pfsense.
- I probably could have got this to work with a bit more research, but I concluded that because I could only do the web gui administration from the LAN card side of pfsense, and I wanted to be able to do remote support of it, I needed to get OpenVPN working so I could use that to reach the LAN side of pfsense from the WAN side. But I didn't get OpenVPN working yet.
I don't think any of these problems are insurmountable, but at this time I don't have the time available to research and play to overcome them. Therefore I'm returning to Centos based FusionPBX for now as I know that will work as I use that in my test environment still.
I also ran into some problems with modules in the pfsense version of fusionpbx. The modules section of fusionpbx defined a module called hash. I had to edit this by replacing each instance of the word hash to limit. so mod_hash became mod_limit.
This was preventing javascripts from running. However, javascripts were also prevented from running because of a fault loading spidermonkey (it cannot be made to load as it claims to be missing library files which are present) and accordingly, if you need javascript support the current release of freeswitch for pfsense is not going to work for you. If you can use LUA instead then you should be ok. Unfortunately the only way to upgrade freeswitch on pfsense is to recompile a new copy, which can't be done on pfsense because the necessary files are missing and can't be loaded, so you need to have a freebsd install that matches the pfsense install and compile it there and transfer the files over - too complicated for me at this point.
So for now, this is where I leave pfsense. I will return to Centos as I need the javascript support at this point in time. The other reasons I am leaving pfsense at this time are:
- I can't find an easy way to back up the harddrive image as the unix applications I know how to use (eg. gparted and partimage) are not available in freebsd and if I install tinycore linux on the same system and run them from there instead, I still can't access the pfsense harddrive area because it is running ufs which apparently isn't supported in linux. Someone with a better understanding of freebsd probably doesn't have this problem.
- I was struggling to get the phone system to work the way I wanted it - with pfsense 1.2.3 you have to have two network cards. Fusionpbx binds to the WAN card, so I wanted to have the LAN card with nothing plugged into it and to have all the phones connected on the WAN side. ie. fusionpbx would be a node on the private LAN but connected only by the WAN card. I couldn't get the phones to register with it when setup this way - probably because I wasn't fully understanding the firewall functionality in pfsense.
- I probably could have got this to work with a bit more research, but I concluded that because I could only do the web gui administration from the LAN card side of pfsense, and I wanted to be able to do remote support of it, I needed to get OpenVPN working so I could use that to reach the LAN side of pfsense from the WAN side. But I didn't get OpenVPN working yet.
I don't think any of these problems are insurmountable, but at this time I don't have the time available to research and play to overcome them. Therefore I'm returning to Centos based FusionPBX for now as I know that will work as I use that in my test environment still.
Friday, September 17
Odd IVR behaviour
If you are using Freeswitch 1.0.6 or earlier in your Fusion PBX (type version at a freeswitch command prompt - eg. through the command editor in FusionPBX or at the fs_cli to find out your version) then you should be aware that IVRs don't work quite as you might expect. If you put multiple actions per IVR choice (eg. set a variable and then execute a script if someone presses 1) then the multiple actions will execute in REVERSE order!
You have two alternatives:
1. write your actions in reverse order
2. upgrade to a later version of freeswitch
I reported this behaviour to the freeswitch team and they have fixed this for future updates today. They actually didn't know it was possible to use their IVR capability this way - multiple actions per choice was a feature that they didn't realise that they had - so they had never realised it didn't work in a logical fashion.
If you choose option 1, just note that if you upgrade freeswitch in the future you will have to reverse the IVR actions then or it will then operate backward.
You have two alternatives:
1. write your actions in reverse order
2. upgrade to a later version of freeswitch
I reported this behaviour to the freeswitch team and they have fixed this for future updates today. They actually didn't know it was possible to use their IVR capability this way - multiple actions per choice was a feature that they didn't realise that they had - so they had never realised it didn't work in a logical fashion.
If you choose option 1, just note that if you upgrade freeswitch in the future you will have to reverse the IVR actions then or it will then operate backward.
Thursday, September 16
Important things to know if you add your own sound files to FusionPBX
Freeswitch has a clearly defined structure for where to keep sound files. FusionPBX honours that structure. If you put sound files in other places you will probably create problems for yourself. I did...
In the freeswitch directory there is a sounds directory. This is where your sound files belong. Each directory level below that has a clearly defined function.
The first level is language. On a default installation the only content is "en" for English.
The next level is dialect. On a default installation the only content is "us" for American accent.
The next level is voice. On a default installation the only content is "callie" - the name of the voice talent who recorded the standard sounds.
If you create sound files you should put them in a subdirectory inside the callie directory. Intuitively this doesn't make sense because you probably haven't paid callie to record extra sounds for you and you probably just recorded them yourself. But the reality is that we could just call the callie directory "default" and then it would make more sense as it is the default set of sounds you have on your system.
Do not try to put your sound files at any higher level in the directory tree or it will cause problems with FusionPBX's drop down menus for selecting sound files and it will be unable to find your sound files even though you can select them - this is because FusionPBX follows the freeswitch standard and by putting files there you break the standard.
However, if you hired your own voice talent and recorded a complete set of sounds (to match all of the callie sounds plus any others you want) in another voice you would put them at the same level as the callie directory. For instance you might want a male voice - let's say it is Daniel. Inside the daniel directory you would have all the sounds that daniel said, arranged in subdirectories that match all the subdirectories in the callie sub-directory.
If you hired your own voice talent and recorded a complete set of sounds matching callie's in another accent, say Australian, then you would put them in an "au" directory (for Australia) at the same level as the "us" directory in the default installation. Beneath that you would have the name of the voice, eg. Bruce, and then beneath that you would have all the recordings matching the layout of the callie directory.
If you hired your own voice talent and recorded a complete set of sounds matching callie's in another language, say Japanese, then you would put them in a "jp" directory (for Japan) at the same level as the "en" directory in the default installation. Beneath that you would have the dialect, (I'm not sure if there are distinct dialects of Japanese, so if there aren't we might just use "jp" again), and beneath that you would have the name of the voice, eg. Akiko, and then beneath that you would have all the recordings matching the layout of the callie directory.
Following these rules will ensure that your system works as it is designed to.
As a note, the fusionpbx installation sets default_language, default_dialect, default_voice variables. You can override these on an incoming call to select the appropriate sound set for that channel. So if your call comes in on a number that you know is dedicated to Italian callers you can set theses variables on that channel to the appropriate settings for your Italian sound set.
Something you need to do
Due to enhancements in FusionPBX that are not yet supported by changes to the installation process, any menus that allow you to choose sound files to play (I came across this when trying to setup an IVR) will not be able to find the sound file unless you first define some variables.
Go to the System-Variables menu. Look for the following variables in the Defaults section. If they are not there you will need to add them.
default_language=en
default_dialect=us
default_voice=callie
Once you have added them your IVRs will be able to find the sound files to play. (don't forget to apply the changes)
Go to the System-Variables menu. Look for the following variables in the Defaults section. If they are not there you will need to add them.
default_language=en
default_dialect=us
default_voice=callie
Once you have added them your IVRs will be able to find the sound files to play. (don't forget to apply the changes)
Wednesday, September 15
Understanding dial plans in more depth
Since writing my earlier posts about dial plans, I've discussed them with people and learnt a bit more about them so I'm sharing that with you to make your life easier as well!
The default dialplan that ships with freeswitch gives you 1000-1019 and 2000-2999 for use for extensions and uses lots of other numbers for other purposes. When FusionPBX was created it was decided to move all these pre-defined things that were in the freeswitch default configuration out of the way so that people were unrestricted in what extension numbers they could use.
Accordingly all the default freeswitch dialplan configurations have been moved to start with *. You can see these in dialplan/default.xml. The easiest way to look at this is to go to the Dialplan Manager screen and press the Advanced button. This will open up an editor that shows you this particular file and allows you to change it.
All the dial plan entries you create in FusionPBX are stored in the database and the database is used to automatically generate the dialplan files located in default/*.xml. So if you have a look through the default dialplan you will see this line halfway down the file:
X-PRE-PROCESS cmd="include" data="default/*.xml"
Everything in the default dialplan BEFORE this line is processed before your dialplan entries and therefore will override anything in your default dialplan. Anything in the default dialplan AFTER this line is processed after your dialplan entries and therefore will be overridden by anything in your default dialplan.
Additionally, you can, if you want, modify this default dialplan directly in the editor. Anything you see in the default dialplan is only defined there, it isn't stored in the fusionPBX database.
I hope that removes some of the pain of understanding dialplans!
The default dialplan that ships with freeswitch gives you 1000-1019 and 2000-2999 for use for extensions and uses lots of other numbers for other purposes. When FusionPBX was created it was decided to move all these pre-defined things that were in the freeswitch default configuration out of the way so that people were unrestricted in what extension numbers they could use.
Accordingly all the default freeswitch dialplan configurations have been moved to start with *. You can see these in dialplan/default.xml. The easiest way to look at this is to go to the Dialplan Manager screen and press the Advanced button. This will open up an editor that shows you this particular file and allows you to change it.
All the dial plan entries you create in FusionPBX are stored in the database and the database is used to automatically generate the dialplan files located in default/*.xml. So if you have a look through the default dialplan you will see this line halfway down the file:
X-PRE-PROCESS cmd="include" data="default/*.xml"
Everything in the default dialplan BEFORE this line is processed before your dialplan entries and therefore will override anything in your default dialplan. Anything in the default dialplan AFTER this line is processed after your dialplan entries and therefore will be overridden by anything in your default dialplan.
Additionally, you can, if you want, modify this default dialplan directly in the editor. Anything you see in the default dialplan is only defined there, it isn't stored in the fusionPBX database.
I hope that removes some of the pain of understanding dialplans!
Tuesday, September 7
Dial plans - an easy mistake
One of the mistakes I keep making in the dial plans is that I enter a number that I want people to dial in order to reach a special function on the phone system, instead of entering a regular expression defining that number. So for instance if I want them to dial 1 to reach a function I have been setting my condition as destination_number=1 but this is wrong. The correct condition is destination_number=^1$
Don't get caught in the same way!
Don't get caught in the same way!
A trap for young players...modules
One of the nice things about FusionPBX (unlike FreePBX as used in Trixbox) is that by default, customisations you have made to freeswitch are not overwritten. However, this can be a trap for you if you are not careful.
For example, I made the mistake of assuming that what I saw on the Modules configuration page in FusionPBX were actually the settings that were configured in Freeswitch. This is not the case by default - in order to protect any customisations that people have made directly in freeswitch to which modules are loaded (some people might not want to use the module GUI in FusionPBX and might prefer working directly with Freeswitch). If you find that a module that you are expecting to be enabled is not working, go to the Modules page and edit any module setting, you don't need to actually make a change, just save the settings as they are. Then apply your settings. What you achieve by doing this is that you commit these settings into freeswitch/conf/autoload_configs/modules.conf.xml. You can actually see the settings in the FusionPBX XML editor under autoload_configs/modules.conf.xml. If the settings in there don't match the settings you see on the modules page, and you want them to, then you will need to do these same steps as I did also.
For example, I made the mistake of assuming that what I saw on the Modules configuration page in FusionPBX were actually the settings that were configured in Freeswitch. This is not the case by default - in order to protect any customisations that people have made directly in freeswitch to which modules are loaded (some people might not want to use the module GUI in FusionPBX and might prefer working directly with Freeswitch). If you find that a module that you are expecting to be enabled is not working, go to the Modules page and edit any module setting, you don't need to actually make a change, just save the settings as they are. Then apply your settings. What you achieve by doing this is that you commit these settings into freeswitch/conf/autoload_configs/modules.conf.xml. You can actually see the settings in the FusionPBX XML editor under autoload_configs/modules.conf.xml. If the settings in there don't match the settings you see on the modules page, and you want them to, then you will need to do these same steps as I did also.
Subscribe to:
Posts (Atom)