Posts Tagged sip

Resetting GSM modules on Yeastar gateways using Ansible

Sometimes there’s a need to reset a GSM module on a Yeastar GSM gateway. For example, SIM cards of one of our providers get into faulty state every few weeks, and only a reset helps.

The GSM module can either be rebooted via Web GUI, or from the Asterisk console. But the Asterisk console can only work on the same host where the asterisk daemon runs, so you need to make an SSH connection into the Yeastar box to do that. Also it’s impossible to save a public SSH key in a Yeastar box, so only password authentication works.

Ansible is a powerful toolset for managing remote hosts, and it appears to be perfectly suitable for managing the GSM gateways.

Ansible 2.x is available for Debian 8 from jessie-backports repository. There are some important differences from version 1.7 that is installed from default repositories, and in particular, ansible_host and ansible_port variables.

After installing Ansible, uncomment host_key_checking = False in /etc/ansible/ansible.cfg , so that the SSH client stops verifying the remote host SSH signatures. Otherwise the host signatures should be listed in your known_hosts file.

The following lines in /etc/ansible/hosts list your GSM gateways:

[yeastar]
gsm01 ansible_host=192.168.99.66 ansible_ssh_pass=kljckhjeswvdfesv
gsm02 ansible_host=192.168.99.67 ansible_ssh_pass=dmnckjfvrever
gsm03 ansible_host=192.168.99.68 ansible_ssh_pass=dcmnkljdfhfe

[yeastar:vars]
ansible_user=root
ansible_port=8022

If you use the same root password on all devices, the password variable can be moved to the group variables.

Ansible uses SFTP for ad-hoc commands, and SFTP is not available on Yestar gateways. But the raw module works just fine, and resetting a GSM module can now be done with a simple command from your management server:

ansible gsm03 -m raw -a '/bin/asterisk -rx "gsm power reset 2"'

 

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

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

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

End-to-end VoIP quality testing probes

This is a result of a project where we needed to measure voice QoS parameters (jitter and packet loss) in the customer network. I’ve set up small probe computers (old 10″ Intel Atom netbooks like Acer Aspire One) with FreeSWITCH and a few scripts for test automation. Each test consists of a 30-second call (producing approximately 1500 RTP packets in each direction), and tshark is measuring the received jitter and loss on each side.

Test details and the installation procedure are outlined on Github:

https://github.com/xlab1/voip_qos_probe

 

, , , ,

Leave a comment

FreeSWITCH performance test on PC Engines APU

This test is analogous to the one I described for Intel Atom CPU.This time it’s the new APU board from PC Engines, the maker of famous ALIX and WRAP boards. APU is a fanless appliance board, with a dual-core 1GHz AMD G series CPU. The overall performance is comparable to that of Intel Atom.

In these tests, FreeSWITCH was forwarding the call to itself on request by pressing *1. Each such forwarding resulted in creating four new channels in G722 and G711, thus resulting in transcoding to G711 and back. For example, if “show channels” shows 5 channels, it’s equivalent to 2 simultaneous calls with transcoding.

Test result: 57 channels were running completely fine, 65 channels had slight distortions, and with 85 channels the speech was still recognizable, but with significant distortions. With Speex instead of G722, distortions were quite annoying at 25 channels. Thus, the APU platform can easily be used as a small-to-medium business PBX for  20-30 simultaneous calls if there’s not too much transcoding.

Test details follow.

Read the rest of this entry »

, , , ,

1 Comment

Call forwarding/redirection in FreeSWITCH

Consider you have two different contexts in your dialplan for inbound and outbound calls: the “public” context transfers the calls into “XXX_inbound” (XXX being your organization name), and the user directory has “XXX_outbound” as “user_context” variable.

Having two contexts, you have more flexibility in defining the short dial strings and outbound destinations.

But there’s a little problem: if the SIP client redirects the ringing call, or if the user makes an attended transfer, FreeSWITCH would initiate a new outbound leg in the same context where the call was bridged toward the SIP client.

As a solution, you need to define a new extension in your XXX_inbound context which would match PSTN outbound numbers. The channel will already have all custom variables which were set before bridging toward the SIP client, so you can set an additional condition criteria to make sure that this is the redirected call. This example would be placed at the bottom of the inbound context, and “directory_ext” is the variable that was earlier in the same context before the call was bridged to the SIP client:

    <extension name="call_forward">
      <condition field="destination_number" expression="^\d+$"/>
      <condition field="${directory_ext}" expression="^70\d$">
        <action application="set" data="hangup_after_bridge=true"/>
        <action application="set" data="continue_on_fail=false"/>
        <action application="bridge" data="${outgw}/${destination_number}"/>
      </condition>        
    </extension>

, , ,

1 Comment

Minimal FreeSWITCH configuration

It’s always a bit of an effort to remove unneeded features from the default FreeSWITCH configuration. So, I made the minimal configuration which still allows to start the server, but does completely nothing. It’s now much easier to start a new server configuration for any new project.

The configuration is placed at Github. It’s very straightforward to use with FreeSWITCH Debian packages, and can also be used if you compile it from sources:

cd /etc
git clone https://github.com/xlab1/freeswitch_conf_minimal.git freeswitch

The configuration contains a number of empty “stub.xml” files in order to make the XML pre-processor happy.

It also makes sense to start using Git for your own FreeSWITCH configurations 🙂

, , , ,

2 Comments

FreeSWITCH performance on Intel Atom CPU

There are multiple low-power, fanless  appliances on the market, and most of them are powered by Intel Atom processors. I needed an estimation how well an Atom would perform for a FreeSWITCH PBX application.

In this test, I use two Acer Aspire One notebooks with different processors:

  • atom01: Atom N2600 (2 cores, 4 virtual CPUs, 512KB cache and 600MHz per virtual CPU, 12768.02 BogoMIPS)
  • atom02: Atom N570 (2 cores, 4 virtual CPUs, 512KB cache and 1000MHz per virtual CPU, 13302.08 BogoMIPS)

Both notebooks are running 32-bit Debian 7 Wheezy (Kernel version 3.2.0-4-686-pae), and FreeSWITCH version 1.2.13 from pre-built Debian packages.

Test results summary

All calls in this test used transcoding between G.711alaw and G.722. The bottleneck in performance was always at the N2600 (atom01), because of slower CPU. In general, N570 can handle approximately 30% higher load than N2600.

With 10 concurrent calls (21 channels on atom01 and 20 channels on atom02), there is no voice distortion and new call processing does not disturb the ongoing calls. Each virtual CPU is busy at 20-25%

With 20 concurrent calls (41 channels on atom01 and 40 cannels on atom02), there is some minor voice distortion, especially during incoming calls, but quality s still acceptable.

With 27 concurrent calls (55 and 54 channels), voice distortions were too high and not acceptable. Every virtual CPU on atom01 was busy at around 50%, which means full load for the whole CPU.

With 20 concurrent calls without transcoding (PCMA only in all call legs), each CPU core on atom01 was utilized at around 9-10%. So, theoretically the platform can handle up to 40-50 simultaneous calls in non-transcoding mode.

Only the voice quality was tested. CPS was not tested, and it depends heavily on the complexity of the dialplan. But the overall response of the system was quite acceptable.

Read the rest of this entry »

, , , , , ,

1 Comment