automake support in dahdi-tools
Wed, 20 May 2015 12:33:45 +1200
Tzafrir Cohen from Xorcom has written a post about converting DAHDI-tools to automaker.

Hi,

Oron and I have been working at converting dahdi-tools\'s build system to use automake.

The current patchset is in a separate branch at the dahdi-tools git repository:

http://git.asterisk.org/gitweb/?p=dahdi/tools.git;a=shortlog;h=refs/heads/review-automake

Some changes:
* If you check out from git, you\'ll need to run autoreconf [-i].
- Though on most cases later on even changes to configure.ac trigger an automatic re-run of the configure script.
- Right, no failed \'make\' if you forgot to run ./configure .
- version.c is created at configure time.
- The dist tarball is created from local files and not from the git HEAD.
- Its version name has also changed if you package from git: just version number.
* Everything builds. Minimize the number of secondary targets
- dahdi_pcap will build (if dahdi-linux is right and id you have pcap)
- pppd plugin will build if you have pppd
...
* libtonezone.so.1 is gone. Yes, it\'s the same as 2, but noone should be using it.
- Asterisk looks for libtonezone.so.2.0 . This name is not the standard name generated by autotools (libtonezone.so.2 or libtonezone.so.2.0.0). A symlink is manually generated.
* Installation of configuration files changed:
- Files that may be generated: \'make install\' installs them as .sample to /etc/dahdi.
- Others (init.conf, modprobe.d/dahdi{,-blacklist}.conf) are installed unconditionally in the new install-config target.
- Yet others (init script mostly) are install in install-config, but don\'t replace existing configuration. This is the same as the existing \'config\' target and doesn\'t make sense to me.
* Still some unconverted leftovers in Makefile.legacy (mainly for install targets).
* make distcheck still doesn\'t work
- One odd manupulation of sysconfdir in configure.ac which I\'m not sure I can remove.
- Setting the perl path to sitelib causes a problem as well.

Some changees I\'d like to apply soon:
* There\'s a patch in the Debian package to remove dahdi_speed. It has been there for quite some time and I don\'t remember anybody asking for it. Could it be removed? Or at least: not installed by default?
* Add an option to set the perl directory to the vendorlib (again, a pending Debian patch).

I\'d like to commit this patchset in a few days, if there are no comments.

--
Tzafrir Cohen
Monitoring SIP Service
Wed, 20 May 2015 02:29:34 +1200
Jai Rangi from didforsale.com has posted an article on monitoring Asterisk or FreeSwitch from nagios:

A very common concern from new Asterisk, Freeswitch, opensips and freepbx owners is how can we monitor Asterisk and what happens if the service stops responding.

Here is a small howto on monitoring asterisk with nagios. I am sure there are plenty of options and suggestions, but this is one of them and has been working out very well for us for years.

http://www.didforsale.com/monitor-sip-server

Best,
-Jai
Asterisk Beacon Module Proposal
Sat, 09 May 2015 01:29:26 +1200
Matt Jordan has posted an article about a module for reporting Asterisk server usage back to developers. This would be a great addition because it would show what people are doing with their servers and where development efforts should be directed.

Here\'s his note:

Hey everyone -

At the past several AstriDevCon events, we\'ve had an open discussion about adding a module to Asterisk that would gather anonymous usage statistics. Said module would be used to help the Asterisk Developer community better support the users of Asterisk, as we would have some indication of the modules being used by the reporting segment of the Asterisk community. There are, of course, a couple of agreed upon stipulations for such a module:

* As noted, all information gathering must be anonymous. No information about the sending system should allow for someone viewing the data to be able to identify the system in quesiton.

* The module must send all of its data encrypted.

* Users must be notified as the last message on startup that anonymous usage statistics are being gathered.

* The module must provide the ability for users to opt out of gathering statistics.

* Users must be able to go to asterisk.org and view the statistics gathered for their server. The module must provide a unique, non-identifying token that users can use to view the gathered statistics for their servers.

After some careful thought, we\'ve put together a proposal for such a module ? called ?Beacon? - on the Asterisk wiki [1]. In addition to meeting the requirements discussed at previous AstriDevCons, the proposal on the wiki outlines a Swagger schema for a REST API that the module will talk to. The module configuration will support sending the usage statistics to more than just the server at asterisk.org, effectively allowing anyone to send statistics from their servers to other implementations of the REST API. This can be beneficial for people deploying large numbers of Asterisk servers.

As mentioned, the asterisk.org site will be updated to allow for users to view the collected statistics. A sample screenshot is attached to this e-mail. Note that this is merely a mock up given some fake data, but it should hopefully illustrate what this may look like for Asterisk users.

Please take a look at the spec on the wiki and the proposed project, and comment here with any suggestions for improvements.

Thanks!

Matt

--
Matthew Jordan
Digium, Inc. | Director of Technology

Here\'s an image of what it looks like:

Social VoIP < $100,000
Fri, 08 May 2015 07:46:50 +1200
Nir has written a blog post about his take on \"Federated VoIP Switching\":

Excerpt from his post:

Skype, Viber, Line2, Tango and recently, Whatsapp and Facebook - they are all competing within the same market niche. Each one with its own level of success and market traction, but at the end of the day, they are all racing towards the same goal - don\'t let the user out of your application. The FOMO affect (Fear Of Missing Out) that is rapidly spreading among all of us had degraded our attention span and our ability to concentrate. The battle to re-focus your usage of your mobile device to a single application had begun.

Since 2010, we had become increasingly involved in the development and operation of several VoIP enabled networks - 2 of which had already crossed the several hundred thousands of users, using both our server technology and our mobile VoIP SDK technology. The buildup of a mobile application within the VoIP sector is different, it is not your normal Big-Data application, it surpasses both the realms of Big-Data and content distribution. It is a combination of Big-Data, coupled with in-depth networking know-how, with sprinkles of user flow usage and UX understanding.

At the heart of our technology, is a VoIP platform design pattern we like calling: \"Federated VoIP Switching\" - which means, a VoIP switching network that has no single point of failure, no single point of entry and no single management data store. Thus, providing a highly scaleable, highly robust and most importantly, a highly economical solution - without the need to invest a great deal into multiple servers and special IT skills. In fact, all of our platforms are deployed into public clouds, like Amazon AWS, Google Compute/AppEngine and DigitalOcean.

Read More
The GUI Game
Wed, 06 May 2015 01:50:20 +1200
Nir Simionovich has written a great blog post on the state of Open Source GUI platforms for VoIP.

Excerpt from his article:

A recent post on the Elastix community page yielded the following:

Guayaquil, Ecuador, May 4th 2015 - PaloSanto Solutions, the company behind the Elastix Project, has established today a GIT repository for the development of a brand and distro agnostic GUI for unified communications servers. Additionally it conceives multi-tenancy.

The project will be independent and will start off with the mutiltenant GUI from Elastix MT. Currently this development is focused on using Asterisk as the telephony manager at its core, however, the project seeks to establish the basis for the inclusion of other projects that currently exist in the industry like FreeSwitch.

This project will be initially hosted and moderated by PaloSanto Solutions; it is an idea together with the PBX in a Flash team.

\"We believe that by using Elastix GUI to kick off the project will help in assimilating it faster, said PBX in a Flash\'s CEO, Ward Mundy. \"PaloSanto Solutions\' decision to create a GIT repo for development cooperation is also important because it will attract new actors to the project that will enhance its functionality\", he added.

\"Since the release of Elastix MT we believed that there is the possibility to continue revolutionizing unified communications, and to establish tools that had not been integrated before\". Said Edgar Landivar, CEO of Elastix. \"With the establishment of this repo we hope to establish a standard in the industry that will replace the concept of VoIP PBX\", he concluded.

The project is available today at https://github.com/elastixmt/elastix-mt-gui, and rules are being set regarding contributions to the development so that all interested people can join immediately.

Well, I think that I can understand where Elastix/PIAF are going with this. For a while now, I\'ve seen various communications and rants roaming the community, regarding the way the FreePBX GUI is dominating the \"Distro Market\" - so to speak.

In general, I see this as a good thing, as it means that people will start re-focusing on technology. On the other side, we will end up - again - with the normal Open Source/Commercial debates (should we do? why shouldn\'t we do?).

I know that people are going to jump me for what I\'m about to say right now, but since the introduction of Asterisk 13 and ARI, the gaps between Asterisk and FreeSWITCH are rapidly closing in my book. I\'ve already deployed several systems using ARI - and I don\'t use a GUI at all. FreePBX in my book had become a large set of code, assembled partially by people who know what they are doing and partially not. With the Sangoma buy-out, I suspect that we\'ll see more and more \"Sangoma Centric\" modules and features - and that\'s normal. Same will apply to the Palo Santo alternative, as it becomes more and more acceptable by the market.

Read More...
Original Content (C) 2005 Matt Riddell