Telephony Fraud – Still going strong

Who would believe, in the age of Skype, Whatsapp and Facebook – telephony fraud, one of the most lucrative and cleanest form of theft – is still going strong. Applications of the social nature are believed to be harming the world wide carrier market – and carrier are surely complaining to regulators – and for a legitimate reason. But having said that, looking at some alarming fraud attempt statistics, thing will show you a fairly different story.

So, analysing fraud is one of my things, I enjoy dropping honeypots around the world, let them live for a few days and then collect my data. My rig is fairly simplistic:

  1. A have a Homer ( server to capture all my traffic
  2. A have an amazon AWS cloudformation script that launches up instances of Asterisk, FreeSwitch and Kamailio
  3. All instances are pre-configured to report anything back to Homer
  4. Upon receiving a call – it will be rejected with a 403

Why is this a good honeypot scheme? simple – it gives the remote bot a response from the server, making it keep on hitting it with different combinations. In order to make the analysis juicy, I’ve decided to concentrate on the time period between 24.12.2016 till 25.12.2016 – in other words, Christmas.

I have to admit, the results were fairly surprising:

  1. A total of 2000 attacks were registered on the honeypot server
  2. The 2 dominant fraud destinations were: The palestinian authority and the UK
  3. All attacks originated from only 5 distinct IP numbers

Are you wondering what the actual numbers are? Here is the summary:

Row Labels Grand Total
441224928354 19         19
441873770007       204   204
76264259990     1     1
17786514103         2 2
972592315527   1774       1774
Grand Total 19 1774 1 204 2 2000

As you can see, the number 972592315527 was dailed 1774 from a single IP – I can only assume this is a botnet of some sort, but the mix of IP numbers intrigued me. So, a fast analysis revealed the following:

Amsterdam? I wonder if it’s a coffee shop or something. The thing that also intrigued me was the phone number, why would the bot continue hitting the same mobile phone number? I couldn’t find any documentation of this number anywhere. Also, the 97259 prefix automatically suggests a mobile number in the PA, so my only conclusion would be that this is a bot looking for a “IPRN” loop hole – which is again fraudulent.

So, if this what happens in 48 hours – you can imagine what happens over a month or a year.


The above post contains only partial information, from a specific server on a network of worldwide deployed honeypots. The information provided as-is and you may extrapolate or hypothesize what it means – as you see fit. I have only raised some points of discussion and interest.

Should you wish to join the lively discussion on HackerNews, please follow this link: for further discussion.




Goodbye Elastix – we will miss you

Last week marked a sad point in the history of Open Source, the highly acclaimed and established Asterisk distribution was taken down from the Internet, leaving all of its users, followers, eco-system, resellers, integrators and more with a gigantic void to be filled.

While the void will be filled at some point, I can’t but help but observe the joy and cheerfulness of the proprietary telecommunications industry, as 3CX had rapidly taken over the Elastix business in such brutal manner. According to the various discussions in the Open Source community, the entire thing was cause by, a so called “violation of copyright” or “violation of IP” of some sort, within the Open Source communities. In the past, as far as I know, when various distributions or projects violated each other’s copyright, they would notify one another – and would ask to rectify the situation. Apparently, this hadn’t happened here – or if it happened, it wasn’t published in an open manner – as you would expect.

One of the things that the community started shouting was: “Elastix had been trixboxed”. Honestly, I don’t see the similarity between the two cases. When fonality acquired trixbox, they had a clear indication of where they are going. This is not 3CX acquired Elastix, this is 3CX obliterated Elastix. This is something completely different – and with major personas in the open source community indicating that a certain, well known and renowned, Open Source persona was involved in this happening, I can only be highly offended by the everlasting stench of people’s own ambition and personal hatred towards things that are not their own.

I admit it, I never really used Elastix in my projects, I found it to be bloated, inflated with software that shouldn’t be there, too slow for my taste and with a lack of proper project leadership, patches went in and out like crazy. Yet, I can’t argue with their success and the acceptance of the product around the world. I remember being at VoIP2Today in Madrid only a few weeks ago, and there were Elastix boxes sitting on tables. Yes, Elastix wasn’t my first choice for an Office PBX, but yes, they were a choice – the idea of a commercial company coming in and removing that choice off the table – is just annoying and troubling at the same time.

My hope is that some Elastix developers will simply post the entire source code to Github or some other public repository, slapping a BSD/MIT license on their work – telling the world: “Here is our creation, the proprietary daemons decided it should die – but no one can kill an idea!” – and Elastix will keep on living in the Open Source like other projects. If the world will forget it, then so be its fate – but if the world needs it, let the world take it in two hands and raise it up to the sky and say: “You shall not die!”


The GUI Game

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, 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.

Is it truly the destiny of an Open Source product? to become dominated by their creators? to become a mere vessel of their creators to market their solutions and services. A recent conversation I had with a prospective client went somewhat sour, with me at a loss of answers to a very simple question. The client asked me: “Is there a FreePBX high availability solution? – one that is off the shelf”, my responses were these:

  • You can use the Schmoozecom High Availability solution
  • You can use the Digium High Availability solution
  • You can use the Xorcom High Availability solution

He replied – “What? isn’t there an Open Source alternative? something that had been tested and verified?” – my answer was: “We can always use Linux-HA, Heartbeat, mond and other Open Source tools to create the solution. But it won’t be as slick and neat as the commercial solutions, simply because that requires time.

About 9 years ago, Digium had a product called “Asterisk Business Edition”. The business edition was a highly regressed version of Asterisk, with slightly less features, aimed at being an Enterprise Grade product to work against. Digium realized fairly fast that the product had no place and had abandoned it several years later. Open source is about choice, make your choice, aid others is making a choice – but don’t take our freedom for choice. In my view, the distributions should target themselves to be “Market Aggregators”, not “Market Shapers” or “Market Makers” – this is not the stock market and no wolves den. The Asterisk Exchange is a good idea, if Digium would turn that into something that is embedded into AsteriskNOW and allows people to buy and install, directly from the UI, that would be a winner.

The Apple Store and Google Play became a success not because Apple or Google promoted them, they were made into success by the developers and people who wrote new things. Asterisk, FreeSwitch, Kamailio, OpenSIPS, FreePBX, Asterisk GUI – at least as see it, should be regarded as platforms for innovation, the things that make us go: “Hmmm…. interesting”, the immortal “Facsinating” comment made Mr. Spock.

Just my 0.02$ on the issue…

Statisics, Analytics – stop whacking off

Managers! Project Managers, Sales Managers, Marketing Managers, Performance Managers – they are all obsessed! – Why are they obsessed, because we made them that way – it’s our fault! Since the invention of the electronic spreadsheet, managers relied on the same tools for making decisions – charts, tables, graphs – between us, I hate Excel or for that respect, any other “spreadsheet” product. Managers rely on charts to translate the ever complex world we live in, into calculable, simple to understand, dry and boring numbers.
Just to give a rough idea, I have a friend who’s a CEO of a high-tech company in the “social media” sector. He knows how to calculate how much every dollar he spent on Google adwords, is translated back into sales. He is able to tell me exactly how much a new customer cost him and he is very much capable of telling these number just like that. When we last met he asked me: “Say, how do you determine your performance on your network? is there proper and agreed upon metric you use?” – it got me thinking, I’ve been using ASR and ACD for years, but, have we been using it wrong?

So, the question is: What is the proper way of calculating your ASR and ACD? and is MoS a truly reputable measure for assessing your service quality.

Calculating ACD and Why is MoS so biased

ACD stands for Average Call Duration (in most cases), which means that it is the average call duration for answered calls. Normally, an ACD is a factor to determine if the quality of your termination is good – of course, in very much empirical manner only. Normally, if you ask anyone in the industry he will say the following: “If the ACD is over 3.5 minutes, your general quality is good. If your ACD is under 1 minute, your quality is degraded or just shitty. Anything in between, a little hard to say. So, in that respect, MoS comes to the rescue. MoS stands for Mean Opinion Score – in general terms in means, judging from one side of the call, how does that side see the general quality of the line. MoS is presented as a float number, ranging from 0 to 5. Where 0 is the absolute worst quality you can get (to be honest, I’ve never seen anything worse than 3.2) and 5 represents the best quality you can get (again, I’ve never seen anything go above 4.6).

So, this means that if our ACD is anything between 1 minute and 3.5 minutes, we should consult our MoS to see if the quality is ok or not. But here is a tricky question: “Where do you monitor the quality? – the client or the server? the connection into the network? or the connection going out of the network? in other words, too many factors, too many places to check, too much statistical data to analyse – in other words, many graphs, many charts – no real information provided.

If your statistical information isn’t able of providing you with concise information, like: “The ACD in the past 15 minutes to Canada had dropped 15 points and is currently at 1.8 minutes per call – get this sorted!”, then all the graphs you may have are pointless.

Calculating ASR and the Release Cause Forest

While ISDN (Q.931) made the question of understanding your release cause fairly simple, VoIP made the once fairly clear world into a mess. Why is that? Q.931 was very much preset for you at the network layer – SIP makes life easier for the admin to setup his own release causes. For example, I have a friend who says: “I translate all 500 errors from my providers to a 486 error to my customers” – Why would he do that? why in gods name would somebody deliberately make his customers see a falsified view of their termination quality – simple: SLA’s and commitments. If my commitment to a customer would be for a 90% success service level, I would make sure that my release causes to him won’t include 5XX errors that much. A SIP 486 isn’t an error or an issue, the subscriber is simply busy – what can you ask more than that?

As I see it, ASR should be calculated into 3 distinct numbers: SUCCESS, FAILURE and NOS (None Other Specified). NOS is very much similar to the old Q.931 release of “Normal, unspecified” – Release Cause 31. So what goes where exactly?

SUCCESS has only one value in to – ANSWER, or Q.931 Release cause 16 – Normal Call Clearing

FAILURE will include anything in the range of 5XX errors: “Server failure”, “Congestion”, etc.

NOS will include the following: “No Answer”, “Busy (486)”, “Cancel (487)”, “Number not found (404)”, etc

Each one of these should get a proper percentage number. You will be amazed at your results. We’ve implemented such a methodology for several of our customers, who were complaining that all their routes were performing badly. We were amazed to find out that their routes had 40% success, 15% failure and 45% NOS. Are we done? not even close.

The NOS Drill Down

Now, NOS should drilled down – but that analysis should not be part of the general ASR calculation. We should now re-calculate our NOS, according to the following grouping:

“BUSY GROUP” – Will include the number of busy release codes examined

“CANCEL GROUP” – Will include the number of cancelled calls examined

“NOT FOUND” – Will include any situation where the number wasn’t found (short number, ported, wrong dialing code, etc)

“ALL OTHERS” – Anything that doesn’t fall into the above categories

This drill down can rapidly show any of the below scenarios:

  • BUSY GROUP is not proportional – Normally will indicate a large amount of calls to similar destinations on your network. Normally, may indicate one of the following issues:
    • It’s holiday season and many people are on the phone – common
    • You have a large number of call center customers, targeting the same locations – common
    • One of your signalling gateway is being attacked – rare
    • One or more of your termination providers is return the wrong release code – common
  • CANCEL GROUP is not proportional – Normally will indicate a large number of calls are being canceled at the source, either a routed source of a direct source. Normally, may indicate one of the following issues:
    • You have severe latency issues in your network and your PDD (Pre Dial Delay) had increased – rare
    • Your network is under attack, causing a higher PDD – common
    • You have a customer originating the annoying “Missed Call” dialing methodology – common
    • One of your termination providers has False Answer Supervision due to usage of SIM gateways – common when dialing Africa
  • NOT FOUND GROUP is not proportional – Normally will indicate a large number of calls are being rejected by your carriers. Normally, may indicate one of he following issues:
    • One of your call center customers is using a shitty data list to generate calls – common
    • One of your call center customers is trying to phish numbers – common
    • One of your signalling gateways is under attack and you are currently being scanned – common
    • One of your upstream carriers is returning the wrong release code for error 503 – common

So, now the ball is in the hands of the tech teams to investigate the issue and understand the source. The most dangerous issues are the ones where your upstream carrier will change release causes, as these are the most problematic to analyse. If you do find a carrier that does this – just drop them completely, don’t complain, just pay them their dues and walk away. Don’t expect to get your money’s worth out of them, the chances are very slim for that.



Asterisk ARI – What AGI/AMI should have been

Asterisk ARI – for a seasoned AGI/AMI developer like myself, ARI is a serious mind warp. Why is it a mind warp? simple, it’s all the things we wanted AGI to be, and the reliability we wanted AMI to have, minus all the work around we needed to do – in order to get similar functionality in the past.

So, is ARI truly a replacement for AGI/AMI? well… I think the true answer will be NO. Is a replacement for the Asterisk dialplan? well… I think the answer to that is NO as well. “Say, are you messed in the head? first you say “What AGI/AMI should have been”, and then you say it’s not a replacement? – are you mental?” – well, there are a few reasons why I claim it’s not a direct replacement, and I’ll detail these here.

In order to explain, I’ll give a few examples, using the “in-development” PHP ARI wireframe that I’m developing, called Stanley.

Synchronous vs. Asynchronous

ARI by definition is asynchronous. Keeping that in mind, in means that that any command you give it will get queued or spooled in some manner, and return back an immediate result. Just to illustrate it, let’s examine the following code segment:

$this->stasisLogger->notice("Stasis Start");
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:hello-world");
$this->stasisLogger->notice("Last result: " . $lastResult);
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:demo-congrats");
$this->stasisLogger->notice("Last result: " . $lastResult);

For all practical purposes, you should regard $this->stasisLogger as a simple logging object, and $this->channels as a model to initiate ARI Channel requests. If you use the above the code, and activate it from with a Stasis application, you would listen to the “hello-world” and “demo-congrats” segments. Now, let us examine the following code segment:

$this->stasisLogger->notice("Stasis Start");
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:hello-world");
$this->stasisLogger->notice("Last result: " . $lastResult);
$lastResult = $this->channels->channel_playback($this->ari_endpoint, $messageData->channel->id, "sound:demo-congrats");
$this->stasisLogger->notice("Last result: " . $lastResult);
$this->channels->channel_delete($this->ari_endpoint, $messageData->channel->id);

The only difference here is the last line. If you activate this code, you will hear the world “Hello”, immediately followed by a disconnect. “Wait a minute, what just happened? – wasn’t I supposed to hear everything?” – that’s exactly the point, the answer is NO! The asynch nature of ARI will simply queue the first 2 playback requests, while the hangup is performed almost immediately – the playback simply never get to be executed.

In other words, if you need something to be synchronous within the dialplan, you may need to work differently about it. If you are familiar with the Node.JS framework, you are fairly familiar with this issue.

ARI is for writing applications, not IVRs

When the Asterisk team created ARI, their idea was simple: “Don’t manage the queue application, simply write your own”. Same applies for managing multi party conference calls, call origination, etc. In 2009 I wrote a book about AGI programming, where I’ve explained the methodology for “Atomic AGI development“. The concept behind Atomic AGI was to contain small logic units in AGI scripts, and leave most of the heavy lifting to the dialplan. This methodology enables to create scaleable Asterisk platforms at fair ease, and introduce additional technologies, without going about and adding odd things into Asterisk.

ARI is meant to do something similar, in the form where you can go about and create your own logic, contain it into a singular application and activate when you require – for example, rewriting the queue application. One of the first applications that I’ve decided to re-write using ARI was a Radio broadcasting system that I’ve developed in 2006. The problem with that application was that I need to hold about 600 callers in a single queue, and attach them over to the broadcasting booth as required. Of course I needed to enable full call control, caller management, UI and more. Initially, I used MeetMe, MySQL, and AMI to do this. Later on it changed to MeetMe, Redis, AstManProxy and some other tools – but it never seemed to please me. The fact that I needed to maintain 2 MeetMe bridges, one for holding people and one for the actual broadcasting really bugged me. Yes, when Asterisk 1.8 came out I migrated to the Bridge application and yes, I updated bits and pieces here and there, but it was never what I wanted it to be.

When I started playing around with ARI, I said to myself – this is the perfect application to migrate to ARI. The only thing I needed was a simple Stasis application to read my state correctly, and that would be activated once the called is put into the waiting area – so in terms, I’ve developed a very simple queue application.

IVR heavy lifting was done using dialplan, but the actual service was done with ARI.

Blades and Bleeding Edge

Now, before you go about migrating all your existing code to ARI – you must remember this: If you walk on the bleeding edge, expect the blade to cut you here and there. Currently, I hadn’t yet seen any proper ARI wireframe available. I’ve seen some work done with Node.JS and Ruby, but I can’t say that I’ve taken a fancy to any of those. Honestly, my comfort zone is very much PHP and C/C++, what can I say, I’m old school.

When I started building the Stanley wireframe, it was fairly frustrating – simply because not everything was that much clear and clean. In addition, as Asterisk advances, ARI will change and advance as well. What ever you write, make sure it’s modular enough so you can change it as required.