Recently, a friend sent me a link to the TED talk appearing below:

I found the talk not only interesting, but also it made me think about the Open Source world, trying to apply the same concepts and thinking. I rapidly realised that the Open Source world also has its own set of Takers, Givers and Matchers.

So, let’s talk a little bit about Open Source Givers. The givers will be those who either initiate in open source project, constantly contribute to open source projects, preach and promote the usage of open source as a way of life and most importantly – they do so not because of a commercial or financial agenda – they do so because that’s what they believe in. These include people like John “Maddog” Hall, Linux Torvalds, Richard Stallman, Brian Kernighan, Dennis Ritchie and many others. These people operate under a premise that their work is vitally important, not the world, to mankind and the well being of others.

So, who are our Open Source takers? sorry to say, the number of Open Source takers is far greater than that of the givers. The takers are your “Script kiddies” or “Closed integrators”. Those people who use and abuse Open Source without acknowledging its existence.  In Israel, as an example, when Open Source was still in its infancy stage – people were roaming about claiming that they created a specific project or other. For example, I recall that in 2006, a company in Israel claimed it was the creator of Asterisk – and that their AMP based PBX system is their own creation. How Rude!

Who are your Open Source matchers? matchers are people who jump from being a giver and a taker according to their requirements. These people utilize open source projects, contribute code from time to time, promote the project – nominally due to a business reasoning – and these constitute a slightly bigger portion than the givers. While Open Source innovation relies on Givers, it’s progress into the business world and adaptation to the enterprise relies mostly on Matchers. Takers do not promote the Open Source industry, in some extreme cases, the actually harm the industry.

So, are you a giver, matcher or a taker?

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!