One of the reasons that I stopped using Trixbox was because there was an ongoing problem with it as to how it handled DTMF codes. If you were calling a remote service such as a conference bridge or an automated payment system that required you to enter DTMF codes it would not pass them through properly so that the remote system could handle them correctly.
FreeSWITCH does pass them properly. However, this doesn't mean that you will avoid all problems. Beyond this point there will mostly be problems with client configuration.
I have Linksys and Grandstream ATAs. Linksys have an AUTO mode that selects the most appropriate method for DTMF handling (who knows how...) - it seems to work well. Grandstream require you to select for DTMF to be sent in Audio or in RFC2833 or in SIP info packets. If you select more than one of these options simultaneously you may cause yourself problems.
In early versions of FreeSWITCH it seems that the audio stream was somewhat muted while RFC2833 packets were being sent, however in recent builds this is not the case. So in an earlier build my Grandstream worked happily with audio AND RFC2833 being sent simultaneously, but in a later build this resulted in the far end being unable to understand the DTMF signals - as it was getting extra digits due to hearing both the RFC2833 packets AND the audio DTMF.
So if you have problems with DTMF being understood by remote systems, check to see if you are using more than one method of sending it.
Friday, February 25
Tuesday, February 22
Compiling FreeSWITCH
This is something I was putting off doing as it seemed a little too complicated to learn to do. But I can no longer put it off. As you know if you've been reading my blog, I'm using a FusionPBX/FreeSWITCH build that came as an ISO and was created in April 2010. That means it is getting old. I keep FusionPBX up to date as that doesn't require re-compiles, but I've never learnt to compile FreeSWITCH.
Unfortunately, FusionPBX now relies on the presence of a module (valet park) that wasn't included in the ISO and therefore it is time to either build again using a currently available ISO (ie. UBUNTU) or to learn to recompile FreeSWITCH. While I am interested in trying the Ubuntu ISO, I think it is ultimately going to be more worthwhile to learn to compile FreeSWITCH. So here goes... But one extra note first - few of us have the luxury of a dedicated development box that we can compile on, so I'm going to be doing it on my live system. This means that I need to compile it in another directory and when it is finished I'll need to swap the directory structures (with a brief outage of FreeSWITCH while I do that). To do this, instead of using make install to compile FreeSWITCH, I'll be using make alone and delaying the install part. If you do have the luxury of a development box go ahead and use that rather than placing unnecessary load on your live system - you could zip the directory structure and ftp it to your live system and have a brief outage while you unzip it into place (with freeswitch stopped at the time), however, I did try doing this and failed. Having now tried the method below I'm convinced that this method below is the better option because it preserves your FreeSWITCH configuration files during the upgrade.
Be warned, compiling FreeSWITCH, although not difficult, will take time - there is lots of time spent waiting for your computer, so get a book or something else to do and then you can get started.
Before starting with FreeSWITCH, I'll need GIT - which wasn't included in the ISO. The instructions for this are here http://wiki.freeswitch.org/wiki/Git_Install. Follow them exactly - they are simple!
After that we need to follow a modified version of http://wiki.freeswitch.org/wiki/Installation_Guide.
First: get the prerequisites in place for building freeswitch. If you are cutting and pasting these commands please do these two separately as you will have to respond "Y" to each one as it runs so that it can continue.
yum install autoconf automake gcc-c++ git-core libjpeg-devel libtool make ncurses-devel
yum install unixODBC-devel openssl-devel gnutls-devel libogg-devel libvorbis-devel curl-devel libtiff-devel libjpeg-devel
Unfortunately, FusionPBX now relies on the presence of a module (valet park) that wasn't included in the ISO and therefore it is time to either build again using a currently available ISO (ie. UBUNTU) or to learn to recompile FreeSWITCH. While I am interested in trying the Ubuntu ISO, I think it is ultimately going to be more worthwhile to learn to compile FreeSWITCH. So here goes... But one extra note first - few of us have the luxury of a dedicated development box that we can compile on, so I'm going to be doing it on my live system. This means that I need to compile it in another directory and when it is finished I'll need to swap the directory structures (with a brief outage of FreeSWITCH while I do that). To do this, instead of using make install to compile FreeSWITCH, I'll be using make alone and delaying the install part. If you do have the luxury of a development box go ahead and use that rather than placing unnecessary load on your live system - you could zip the directory structure and ftp it to your live system and have a brief outage while you unzip it into place (with freeswitch stopped at the time), however, I did try doing this and failed. Having now tried the method below I'm convinced that this method below is the better option because it preserves your FreeSWITCH configuration files during the upgrade.
Be warned, compiling FreeSWITCH, although not difficult, will take time - there is lots of time spent waiting for your computer, so get a book or something else to do and then you can get started.
Before starting with FreeSWITCH, I'll need GIT - which wasn't included in the ISO. The instructions for this are here http://wiki.freeswitch.org/wiki/Git_Install. Follow them exactly - they are simple!
After that we need to follow a modified version of http://wiki.freeswitch.org/wiki/Installation_Guide.
First: get the prerequisites in place for building freeswitch. If you are cutting and pasting these commands please do these two separately as you will have to respond "Y" to each one as it runs so that it can continue.
yum install autoconf automake gcc-c++ git-core libjpeg-devel libtool make ncurses-devel
yum install unixODBC-devel openssl-devel gnutls-devel libogg-devel libvorbis-devel curl-devel libtiff-devel libjpeg-devel
Next: download the source from git
cd /usr/local/src
git clone git://git.freeswitch.org/freeswitch.git
Next: switch to the source directory so we can start building (note that the following commands are all issued from that directory
cd /usr/local/src/freeswitch
Next: build the configuration files
./bootstrap.sh
Next: configure
./configure
Next: the next step in the instructions is to edit modules.conf - the best way to handle this in my opinion is to compare the modules list in your active FusionPBX system with the modules.conf file and edit the conf file to enable all the modules that FusionPBX requires. Note that you will need to make quite a number of changes as FusionPBX uses a number of modules that are not enabled in the default FreeSWITCH configuration. It is probably unnecessary to disable modules that FreeSWITCH has enabled by default, but just ensure that you enable FusionPBX required modules. To do this use nano and when you are looking through the file you can use CTRL-W to search for a module and then to enable it, ensure that the start of the line it is on does not have a # (ie. a comment character - when it is commented the compiler ignores it). Be aware that some modules might not be present in the default modules.conf file, if this happens you could search the FreeSWITCH wiki for the module name to see if it has been deprecated and replaced by a new module - you might want to start by looking here: http://wiki.freeswitch.org/wiki/FreeSwitch_Modules. If you still can't find it, go to the #freeswitch irc channel and ask there (http://webchat.freenode.net/?channels=freeswitch).
nano modules.conf
Next: the moment of truth (and a long long moment) - we now make the new build
make
You might get errors as I did - these were the errors I received:
make[5]: *** [mod_opal.lo] Error 1
make[4]: *** [all] Error 1
make[3]: *** [mod_opal-all] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
In my case, I wasn't too concerned about the opal module as I don't actually need that functionality, so I just edited modules.conf again and commented out the opal module. If you can't comment out any modules you have an issue with then you might need to get help from the FreeSWITCH irc channel. After correcting errors, you can try to make again in the same way as before.
Once you have completed a successful make you will be told that you can install it using make install. At this point you need to plan your outage. When you do make install it will do a bunch of stuff (a couple of minutes) and then at the time that it starts copying files into the freeswitch directory structure it will kill your running instance of freeswitch. Once it completes (in my case under a minute later) a quick reboot of the system was all that was required to get it up and running again. So your outage really only needs to be a few minutes long and then you are up and running again with a fresh install of freeswitch.
Just a note - if you had to substitute modules because ones you were previously using have been deprecated it is important after you have restarted your system to go to the modules page in fusionpbx and change the module entries to reflect the new names of modules that need to be started. All the ones that aren't there anymore will show with a bold stopped so that you know they need to be fixed.
Just a note - if you had to substitute modules because ones you were previously using have been deprecated it is important after you have restarted your system to go to the modules page in fusionpbx and change the module entries to reflect the new names of modules that need to be started. All the ones that aren't there anymore will show with a bold stopped so that you know they need to be fixed.
Monday, February 7
Double NAT
I wanted to put a phone for my phone system on someone else's home network. This means that the FreeSWITCH/FusionPBX server is on my home network behind NAT and the phone is behind NAT on their home network. ie. it is a double NAT scenario.
This worked for me - I created a doublenat sip profile following instructions in the FreeSWITCH wiki (http://wiki.freeswitch.org/wiki/General_NAT_example_scenarios). If you want to save yourself some trouble you can upload this to your server in the freeswitch/conf/sip_profiles directory on your server. Make sure you set the permissions on the new file to be the same as the existing profiles in that directory. After this you should be able to restart freeswitch and see the new profile there. You will need to register the remote phone with your external IP address:5090.
Download the doublenat profile here.
This worked for me - I created a doublenat sip profile following instructions in the FreeSWITCH wiki (http://wiki.freeswitch.org/wiki/General_NAT_example_scenarios). If you want to save yourself some trouble you can upload this to your server in the freeswitch/conf/sip_profiles directory on your server. Make sure you set the permissions on the new file to be the same as the existing profiles in that directory. After this you should be able to restart freeswitch and see the new profile there. You will need to register the remote phone with your external IP address:5090.
Download the doublenat profile here.
Subscribe to:
Posts (Atom)