Posts Tagged freeswitch

FreeSWITCH startup for FusionPBX

If you install FreeSWITCH 1.6 on Debian 8 from official .deb packages, and then add FusionPBX on top, the server boot sequence needs a modification: now FreeSWITCH configuration depends on the presence of Postgresql server, and it would load an empty configuration if the database service is not available at the moment of start.

This fixup adds a dependency on FreeSWITCH systemd service, so that it launches only after Postgresql has started:

mkdir /etc/systemd/system/freeswitch.service.d/
cat  >/etc/systemd/system/freeswitch.service.d/fusionpbx.conf <<'EOT'
[Unit]
After=syslog.target network.target local-fs.target postgresql.service
EOT
Advertisements

, , ,

Leave a comment

Quality Assurance for VoIP calls: integration scripts

The scripts for integrating FreeSWITCH with Sevana AQuA software are now available at github: https://github.com/voxserv/fsqa

More details on what they are doing are available in this older post: https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/

, , , , ,

Leave a comment

Quality Assurance for VoIP calls

UPD: the FreeSWITCH integration scripts are available at https://github.com/voxserv/fsqa

A customer has requested to set up a QA service that would continuously monitor the voice quality in their telephony infrastructure. They use a number of telephony carriers, and a set of applications on top of Plivo and FreeSWITCH. Also the conference module in FreeSWITCH is actively used.

Measuring jitter and packet loss, like it’s done in VoIPmonitor, is not sufficient, as we need to monitor end-to-end performance, including that of the FreeSWITCH server itself. So, there has to be a software component that compares the source audio with the recording on the other end of a call.

There are currently two major player on the market for voice quality measurements:

  1. ITU-T PESQ algorithm is proposed as an ITU recommendation P.862. Its source code is available at the ITU website and on Github. But the algorithm is patented, and the source code license does not allow any production use. The evaluation went quite smoothly, and the algorithm was able to detect even minor distortions, like one 20ms frame loss in a 2-minute call. The PESQ algorithm is designed and calibrated to be used for audio files of 6 to 20 seconds in length. Processing of a 2-minute recording takes approximately 5 seconds on a modern Xeon CPU. Commercial software is provided by OPTICOM and PsyTechnics.
  2. Sevana.biz is an Estonian company that provides their own algorithms and software product for voice quality assessment. Their AQuA (Audio Quality Analyzer) software provides a fast and reliable way to compare the audio files: processing of a 2-minutes recording took about half a second on a modern CPU. Sevana has kindly provided a 10-days evaluation license and a fully functional software package, and the customer decided to go ahead with purchasing the license.

The simplest single-server license for Sevana AQuA allows running only one AQuA process at a time, so we wrapped its execution into a Perl script that utilizes a simple exclusive locking mechanism and performs audio file processing one at a time.

AQuA produces two scores in each measurement: the similarity percentage, and the MOS score. Both metrics are useful for quality analysis (for example, a 20ms frame added or lost inside of a silent pause influences the similarity score more significantly than MOS). It also takes a number of command-line options which can increase its tolerance to certain types of distortions, such as frequencies outside of G.711 range.

FreeSWITCH software is used as the SIP server for sending and terminating voice calls and for recording the received audio. It allows recording in several different formats: a) raw codec recording, done in the same thread as RTP processing; b) 16-bit signed PCM in WAV format, and file writing is done in a separate thread; c) compressed voice in a number of formats. The first two options produce similar results (raw codec recording had difficulties in the beginning). In case of raw codec recording, an additional step is required to convert the input files into 16-bit PCM WAV.

The call recording server requires to have a precise clock reference, so a baremetal hardware is required. Virtualized environments add up some uncontrollable imprecision to the virtual machines, although a thorough lab test is requires to verify this. It also depends on the type of hypervisor, as they implement the system clock differently.

The Linux kernel provides access to various clock sources. TSC is commonly used as default, and there is also HPET clock on modern hardware platforms. HPET is supposed to provide a more precise clock source, but it appears that it depends on CPU load: we accidentally discovered that audio recording in FreeSWITCH is significantly distorted when there’s some CPU activity is done in parallel (Debian package builder was working on the same 8-core machine). So far, TSC clock on a baremetal server provided the most reliable results.

The recording is done into a tmpfs mounted partition, in order to avoid any dependency on I/O load. The processing script performs the quality assessment on recorded files, and then moves or deletes them, depending on the measured score.

The SIP service was attached to an unusual UDP port, as port 5060 is frequently accessed by port scanners in public Internet. The DNS NAPTR and SRV records are used in order to use a universal SIP URI string, without having to reconfigure the remote servers if the IP address or UDP port changes.

Jitter buffer is disabled by default in FreeSWITCH, and it has to be activated whenever the calls are terminated on the server. In our case, the “jitterbuffer_msec” variable is set to “50:50” in the dialplan before answering and recording the call. With this, the jitter buffer is not allowed to grow dynamically above 50ms. So, we tolerate most of typical Internet-imposed jitter, but clock drift on the sending side would cause packet drop on the receiver.

The dialplan is designed to accept direct SIP calls from remote servers, and PSTN calls from telephony providers. If a remote server calls our QA service directly, it encodes the source name in the user part of the SIP URI. Also there are two options for a QA call: it can playback the test audio, or send silence. In case of PSTN calls, the caller ID is used as the source identifier. The dialplan activates audio recording into a WAV file on a tmpfs partition, and launches the processing script after the hangup.

The conference dialer is used for testing the conferencing performance on a production FreeSWITCH server. It requires a conferencing profile that does not play any greetings to conference participants. Also in case of more than two participants, only one has to be chosen as a speaker, and all others would be listeners. A dedicated SIP URI on the QA server is reserved to playback the test audio and not to perform any recording.

Each measurement result for QA calls is stored in an SQL database for further processing, and also sent to Syslog for real-time monitoring.

The test audio is a concatenation of speech samples from ITU-T Recommendation P.50 Appendix I, resampled from 16KHz to 8KHz and stored as 16-bit signed PCM audio.

, , , , ,

2 Comments

Testing FreeSWITCH performance on Scaleway C1

The dedicated ARM hosting servers at Scaleway appear to be a decent platform for a mid-sized PBX.

In short, the platform displays the following results in performance tests:

  • OPUS<->PCMA transcoding: 16 simultaneous calls with  at about 95% total CPU load and no noticeable distortions.
  • SILK<->PCMA transcoding: 72 simultaneous calls were going without distortions, with average total CPU load at 63%. Higher number of calls resulted in noticeable distortions.
  • G722<->PCMA transcoding: 96 simultaneous calls without distortions, at 76% CPU load, and noticeable distortions for higher numbers.

Read the rest of this entry »

, , , ,

3 Comments

Installing FreeSWITCH on Scaleway C1

Scaleway (a cloud service by online.net) offers ARM-based dedicated servers for EUR9.99/month, and the first month free. The platform is powerful enough to run a small or FreeSWITCH server, and it shows nice results in voice quality tests.

These instructions are for Debian Wheezy distribution.

By default, the server is created with Linux kernel 3.2.34, and this kernel version does not have a high-resolution timer. You need to choose 3.19.3 in server settings.

At Scaleway, you get a dedicated public IP address and 1:1 NAT to a private IP address on your server. So, FreeSWITCH SIP profiles need to be updated (“ext-rtp-ip” and “ext-sip-ip” to point to you rpublic IP address).

FreeSWITCH compiles and links “mpg123-1.13.2” library, which fails to compile on ARM architecture.  You need to edit the corresponding files to point to “mpg123-1.19.0” and commit back to Git, because the build scripts check if any modified and uncommitted files exist in the source tree. Also the patch forces to use gcc-4.7, as 4.6 is known with some problems on ARM architecture. Read the rest of this entry »

, , , ,

8 Comments

Simple PBX tutorial for FreeSWITCH

Here is a short tutorial that helps building a PBX with FreeSWITCH.

, , ,

Leave a comment

Call generator for performance tests

Here I wrote a simple call generator for FreeSWITCH, and it can be used for performance tests:

https://github.com/voxserv/freeswitch-perf-dialer

, , ,

Leave a comment

Connecting Yeastar TG200 GSM gateway to FreeSWITCH

I needed to connect a GSM gateway to my FreeSWITCH PBX, in order to receive SMS and mobile calls and emulate a normal mobile phone. I’ve got the Yeastar Neogate TG200 V2 for this purpose (Firmware Version: 53.18.0.39, running Asterisk 1.6.2.6 on an ARM processor).

This blog entry has helped a lot and saved a bunch of time.

The box supports OpenVPN, so you can place it in some remote location behind NAT, and manage it via the VPN connection. The client version is rather old (2.0.5), so it does not support embedded certificates in the client config, and also “topology subnet” option is not supported. You need to pack your vpn.conf and the certificates and pivate key into a TAR archive and upload to Neogate via its web interface.

It’s sufficient to configure one SIP trunk to your PBX, and manipulate the To: header in order to distinguish between SIM cards on incoming calls.

When the SIP trunk was configured (FreeSWITCH as a registrar), I started receiving the following warnings on FreeSWITCH, and the registration status was quickly removed after neogate’s REGISTER message:

2014-12-22 12:29:42.208567 [WARNING] sofia.c:5721 Sip user 'gsm01@xxxxx.net' is now Unreachable
2014-12-22 12:29:42.208567 [WARNING] sofia.c:5732 Expire sip user 'gsm01@xxxxx.net' due to options failure

My FreeSWITCH was sending SIP OPTIONS requests to all registered users and removed the registrations unless the clients responded with status 200 or 468. Neogate responds with 404 Not Found on such requests toward the trunk SIP user. I had to disable “unregister-on-options-fail” option in FreeSWITCH internal SIP profile.

In SIP trunk configuration, “Advanced->Caller ID” was automatically set to my trunk’s registration user name. Because of this, all incoming calls had this name as the caller ID, and the original caller number was lost. After setting this field to blank, the problem was resolved.

In “Mobile to IP” rules, you can set a different rule for each SIM card. The “Hotline” field should not be blank, and should contain some distinguishing number. It will be used in To field in the SIP INVITE on incoming calls. If you leave “Hotline” empty, the Neogate will respond with dial tone and collect DTMF digits before placing the call to your SIP trunk. So far I could not find any documentation that describes this.

Also in trunk configuration, sometimes I had to reboot the box in order for my changes to take effect.

The box uses the standard Asterisk management interface for sending and receiving SMS, and I’m planning to use this Perl module through the VPN connection.

, , ,

Leave a comment

Using Voxbeam for outbound calls with FreeSWITCH

Voxbeam is providing worldwide PSTN connectivity at competitive rates, and it allows you to use any Caller ID, which is very convenient for call forwarding. The Voxbeam gateway authenticates the clients by their IP addresses only, so you need a static IP address, and no username or password are required. The FreeSWITCH configuration shown below allows you to control which destinations should be routed to Voxbeam. With a bit of further extension, you can also control which destinations would use different tariff plans at Voxbeam. This configuration covers only their Standard pricing plan. Here INTERNALDOMAIN is a name of the SIP realm that is used for registered users. We assume that the variable “outbound_caller_id_number” is set elsewhere above in the dialplan.

--- File: ip_profiles/external/voxbeam.xml ---
<include>
  <gateway name="voxbeam_outbound">
    <param name="realm" value="sbc.voxbeam.com" />
    <param name="register" value="false" />
    <!-- important, so that your caller ID is transmitted properly -->
    <param name="caller-id-in-from" value="true"/> 
  </gateway>
</include> 

--- File: dialplan/INTERNALDOMAIN/05_pstn_outbound.xml ---
<include>
  <!-- Express destination and caller numbers in E.164 notation without leading plus sign.
       Note that we treat numbers with one leading zero as local Swiss numbers -->
  <extension name="pstn_normalize" continue="true">
    <condition field="destination_number" expression="^00([1-9]\d+)$" break="never">
      <action inline="true" application="set" data="e164_dest=$1"/>
    </condition>
    <condition field="destination_number" expression="^0([1-9]\d+)$" break="never">
      <action inline="true" application="set" data="e164_dest=41$1"/>
    </condition>
    <condition field="${outbound_caller_id_number}" expression="^00([1-9]\d+)$" break="never">
      <action inline="true" application="set" data="e164_cid=$1"/>
    </condition>
    <condition field="${outbound_caller_id_number}" expression="^0([1-9]\d+)$" break="never">
      <action inline="true" application="set" data="e164_cid=41$1"/>
    </condition>
  </extension>

  <!-- Here we define that calls to Russia and Ukraine should go through Voxbeam -->
  <extension name="pstn_select_itsp" continue="true">
    <condition field="${e164_dest}" expression="^(7|38)" break="on-true">
      <action inline="true" application="set" data="outbound_itsp=voxbeam"/>
    </condition>
  </extension>

  <!-- send matched calls to Voxbeam -->
  <extension name="pstn_voxbeam">
    <condition field="${outbound_itsp}" expression="^voxbeam$" break="on-false">
      <action application="set" data="effective_caller_id_number=${e164_cid}"/>
      <action application="bridge" data="sofia/gateway/voxbeam_outbound/0011103${e164_dest}"/>
    </condition>
  </extension>

  <!-- send everything else to Sipcall.ch -->
  <extension name="pstn_sipcall">
    <condition field="destination_number" expression="^(0\d+)$">
      <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
      <action application="bridge" data="sofia/gateway/sipcall/$1"/>
    </condition>
  </extension>
</include>

This is a very simple example, and a bit more logic can be introduced, such as looking up in some kind of a database for least cost routing, and so on.

 

, , ,

2 Comments

Simple performance test for FreeSWITCH conferencing

This is a simple test that gives you an estimation of audio conferencing scalability of FreeSWITCH on your hardware.

  1. You need one or two FreeSWITCH servers, and one of them should answer to sip:moh@IPADDR:5080. The fastest way is to install this FreeSWITCH configuration: https://github.com/xlab1/voip_qos_probe
  2. Edit vars.xml and remove G722 codec (or leave or replace it, if you want to test transcoding performance at the same time).
  3. Start FreeSWITCH:
    service freeswitch start
  4. Create conference participants by calling the MOH extension on the remote or the same server. This command will add a few dozens of participants in one go:
    timeout 2 sh -c "while true; do fs_cli -x 'conference xx dial sofia/internal/moh@IPADDR:5080'; done"
  5. check the number of participants:
    fs_cli -x 'show channels'
  6. run “top” or “mpstat -P ALL 1” to see the CPU load, and add more batches of participants.

This test differs from real world because in a real conference, one speaks and others are listening. Here everyone speaks at the same time. FreeSWITCH evaluates the energy level to find the active speaker before replicating their voice, so I guess the real conference would take less CPU power (need to look into the source code).

Some test results: PC Engines APU platform with 50 conference participants had the CPU usage about 60%. A single core VPS at digitalocean.com was busy at around 50% during a test with 200 participants.

UPD1: (thanks bob bowles) Call out to yourself and monitor the sound quality with your own ear:

fs_cli -x 'conference human dial sofia/external/user@sip.domain.com'

,

Leave a comment