I love the feeling of unboxing a brand new IP phone, specifically, when it’s one that comes from Digium. Yes, I’m a little biased, I admit it – but I’ll do my best to refrain from dancing in the rain with this post.

So, during ITExpo 2017 (Ft. Lauderdale, Florida), Digium unveiled their new D65 Color Screen IP phone. Malcolm Davenport and the good people at Digium were inclined to send me a couple of phones for testing, which I was fairly happy to do – specifically due to the addition of the Opus Codec to the hardware.

If you are not familiar with Opus – you had most probably been living under a rock for the past 3-4 years. Opus is the codec that makes tools like Skype, Hangouts and others work so well. Unlike the traditional g7xx codecs, Opus is a variable bit rate codec, provides HD voice capabilities, has superior network conditions handling (via FEC) and in all – is a far better codec for any VoIP platform. You’re probably asking what is FEC? I’ll explain later.

Consistency and simplicity are a must – and Digium phones are both. One of the things I really like about Digium phones is that they are simple to configure, even without DPMA. The screens are identical to the previous models and are so tight together, that getting a phone up and running takes no longer than a few seconds.

Minor disappointment – the phones were shipped with a firmware that didn’t include the Opus codec – so I had to upgrade the firmware. Ok, no big deal there – but a minor nuisance.

So, I proceeded to get the phone configured to work with our Cloudonix.io platform. What is cloudonix.io? Cloudonix is our home-grown Real Time Communications Cloud platform – but that’s a different post altogether. This nice thing about Cloudonix is that it utilizes Opus to its full extent. Ranging from dynamic Jitter Buffering, Forward Error Correction across the entire media stack, Variable bit rate and sample rate support (via the Cloudonix.io mobile SDK) – in other words, if the Digium phones performs as good as the Cloudonix.io mobile SDK – we have a solid winner here.

So, I hooked the phone up and then proceeded to do some basic condition testing with Opus. All tests were conducted in the following manner:

  • Step 1: Connectivity with no network quality affects
  • Step 2: Introduction of 5% packet loss (using `neteq`)
  • Step 3: Introduction of 10% packet loss (using `neteq`)
  • Step 4: Introduction of 15% packet loss (using `neteq`)
  • Step 5: Introduction of 20% packet loss (using `neteq`)
  • Step 6: Introduction of 25% packet loss (using `neteq`)
  • Step 7: Extreme condition of 40% packet loss (using `neteq`)

Test 1: Media Relay and server located under 150mSec away

  • Step 1: Audio was perfect, HD Voice was exhibited all the way
  • Step 2: Audio was perfect, HD Voice was exhibited all the way
  • Step 3: Audio was good, HD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 4: Audio was good, SD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 5: Audio was fair, SD Voice was exhibited all the way, moderate network reconditioning at the beginning, till FEC kicks fully in
  • Step 6: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 7: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in

Test 2: Media Relay and server located under 250mSec away

  • Step 1: Audio was perfect, HD Voice was exhibited all the way
  • Step 2: Audio was perfect, HD Voice was exhibited all the way
  • Step 3: Audio was good, SD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 4: Audio was good, SD Voice was exhibited all the way, moderate network reconditioning at the beginning, till FEC kicks fully in
  • Step 5: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 6: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 7: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in

Test 3: Media Relay and server located under 450mSec away

  • Step 1: Audio was perfect, SD Voice was exhibited all the way
  • Step 2: Audio was perfect, SD Voice was exhibited all the way
  • Step 3: Audio was good, SD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 4: Audio was good, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 5: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 6: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in
  • Step 7: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in

Ok, I was willing to accept the fact that if I’m able to carry a good audio call, for almost 3-4 minutes, while `neteq` was introducing a static 20% packet-loss condition – sounds like a winner to me.

All in all, till I get my hands on the Digium D80 for testing it’s Opus capabilities, the D65 is by far my “Go To Market” IP Phone for desktop Opus support – 2 thumbs up!

Following yesterday’s post, I’ve decided to take another set of data – this time following the start of the year, with a specific data profile. What is the profile? I will describe:

  1. The honeypot server in this case was a publically accessible Kamailio server
  2. The honeypot changed its location and IP every 48 hours, over a period of 2 weeks
  3. The honeypot was always located in the same Amazon AWS region – in this case N.California
  4. All calls were replied to with a 200 OK, followed by a playback from an Asterisk server

In this specific case, I wasn’t really interested in the attempted numbers, I was more interested to figure out where attacks are coming from. The results were fairly surprising:

The above table shows a list of attacking IP numbers, the number of attempts from each IP number – and the origin country. For some weird reason, 97% of potential attacks originated in Western Europe. In past years, most of the attempts were located in Eastern European countries and the Far-East, but now this is Mainland Europe (Germany, France, Great Britain).

Can we extrapolate from it a viable security recommendation? absolutely not, it doesn’t mean anything specific – but it could mean one of the following:

  1. The number of hijacked PBX systems in mainland Europe is growing?
  2. The number of hijacked Generic services in mainland Europe is growing?
  3. European VoIP PBX integrators are doing a lousy job at securing their PBX systems?
  4. European VPS providers pay less attention to security matters?

If you pay attention to the attempts originating in France, you would notice a highly similar IP range – down right to the final Class-C network, that is no coincidence, that is negligence.

Now, let’s dig deeper into France and see where they are attempting to dial:

So, on the face of it, these guys are trying to call the US. I wonder what are these numbers for?

Ok, that’s verizon… let’s dig deeper…

Global Crossing? that is interesting… What else is in there???

 

So, all these attempts go to Landlines – which means, these attempts are being dialed most probably into another hijacked system – in order to validate success of finding a newly hijacked system.

Well, if you can give me a different explanation – I’m all open for it. Also, if any of the above carriers are reading this, I suggest you investigate these numbers.

 

 

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 (www.sipcapture.org) 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 185.40.4.101 185.62.38.222 195.154.181.149 209.133.210.122 35.166.87.209 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 – 185.62.38.222. 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.

DISCLAIMER:

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: https://news.ycombinator.com/item?id=13354693 for further discussion.

 

 

 

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!”

 

Astricon 2015 is now over, honestly, it flew passed us really fast – at least for me it did. I will refrain from talking about the location of it – as it is more of less a geek’s paradise when it comes to movies and amusement parks. But putting that aside, let’s talk about Astricon itself.

As I see it, Astricon 2015 had distinctively two shining stars – from what I managed to collect. The first one is WebRTC, as it was definitely the talk of the corridors and within the DevCon. Be it a WebRTC controller Lego Puppy, or a connected Tooth Brush – WebRTC is definitely an exciting thing. With the growing popularity of Respoke.io among developers and its inherent connection to Asterisk – I’m confident we’re going to hear more about Respoke in the coming year.

The second one, that is naturally closer to me, is ARI. I’ve seen several people do some really innovative stuff with ARI – and more specifically, PHPARI. I was surprised to learn of a content provider in the Philippines who is using PHPARI to drive over 1500 concurrent calls, topping a total of 5 Million minutes a month – using Asterisk 13 and PHPARI. Man, what a rush! – I started PHPARI about two years ago, I personally know of thousands of installations, but till today, no one really told me what kind of mileage they were getting from it. But learning that someone is packing a 1500 concurrent calls punch with PHPARI, I was ecstatic.

Then, slightly after learning that, I participated a panel with Matt Jordan and Gaston Draque – where we discussed the status of ARI and people had the chance to ask questions. Gaston came to me after the panel saying: “You know, we had a serious fight in the company if to use PHPARI or use GO programming language”. According to Gaston, currently, PHPARI is the most complete toolkit for ARI development – man what a rush. Gaston really knows what he’s doing, I’ve seen some of his work in the past – getting this from Gaston is a serious compliment.

When my wife learned that Astricon this year will be in Orlando, she said: “Take a day off and go have some fun”. So, initially, I was supposed to fly with Eric Klein only. However, we ended up 4 of us in Orlando – which was way more fun. So, for the last day and under the excellent orchestration of Eric, a trip to the Kennedy Space Center was arranged. A group of 21 Telephony geeks got on the bus and took a trip to the Kennedy Space center. Honestly, a highly motivating and inspiring place. Think about it, NASA sent people to the moon, with computer power that is far inferior to your everyday smart phone – simply amazing.

12141558_10153564121736265_7014870291634838053_n[1]

The trip lasted the entire day – we left the hotel at around 8:30, only to come back to the hotel at around 20:30 – a full day! Honestly, if you are going to Orlando, schedule a day trip to KSC – just to see the Apollo rocket in real life – your jaw will drop!

We finished the day back at the hotel, where the first lady of Asterisk joined us for dinner at Jake’s – which was an evening filled with laughter and jokes all around.

12144766_10206916717649129_5376531960455866432_n[1]

So, what’s next? I guess I need to start putting my ass to the chair and cranking up the speed on adding new features to PHPARI .Btw, if you want to help, I will would highly appreciate it – it a work of love, but sharing it around is even better.