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!

** This post is cross-posted on www.greenfieldtech.net **

Honestly, this is something I should have already done a long time ago. About 4 months ago, Allo.Com approached us (GreenfieldTech) to write a review about some of their products. After they agreed to the terms – mainly that they we’ll publish our findings, good or bad – we had to move offices, so everything kind’a went into limbo. Last week, finally, we got around to start reviewing the hardware. We currently started with 2 products, the Allo.COM GSM card (http://www.allo.com/gsm-card.html) and the Allo.Com MegaPBX (http://www.allo.com/megapbx-line.html).

As Eric is still evaluating the MegaPBX, we’ve decided to publish our findings regarding the GSM Card for Asterisk.

Hands on the product

So, the product itself is nicely packaged – in terms of the electronics involved. I’ve examined the soldering quality, and it would appear that it provides a fairly consistent 60% coverage of soldering, which is fairly acceptable for a card of this scale and quality. One thing I didn’t like was the usage of external wires, however, as this is not the first time I’ve seen that, I can accept it. The card itself is available in 2 form factors, so in general, the “hands on” evaluation passes nicely.

Installation

“Patches? Patches? We don’t need to stink’n Patches!” – I admit it, there is nothing I hate more than patching DAHDI drivers (Old OpenVox Style) or adding some 3rd party middleware for DAHDI to make things work (Sangoma). This card takes a slightly higher road. Yes, you are required to have the Asterisk (I do mean Asterisk) source code available. However, it will compile the “channel driver” and an internal resource, very much like the SIP channel – not requiring you to patch Asterisk or DAHDI at all – so in that respect – KUDOS !

To be honest, it took me about 2 days to get the card running, but I was at fault – well, not completely. While the compilation of a “native asterisk” channel driver is a wonderful idea, the documentation kind’a sucks. They still have milage to go with that, however, after contacting their very professional and helpful support staff – it was compiled at ease.

Operation

One thing to get used to – this card is slower, and I do mean much slower, than a normal analog card. The reason isn’t the card, it’s the GSM network. It takes about 10-30 seconds for the card to become fully active, mainly due to the fact that the SIM cards need to register with the GSM network. Once fully active, it will present a channel type GSM, which operates very much like its DAHDI analog equivalent.

The Fire Test

How the hell do you test a card? you make it work really hard – and I do mean hard. So, in order to do so, I’ve created the below Asterisk dialplan:

[from-ipphone]
exten => _X.,1,Set(TIMEOUT(absolute)=${RAND(600,7200)})
exten => _X.,n,Answer()
exten => _X.,n,Wait(${RAND(10,30)})
exten => _X.,n,Dial(GSM/2/050808XXXX,120,R)

exten => h,1,Originate(Local/111@playback-loop,exten,from-ipphone,1111,1)

[playback-loop]
exten => _X.,1,Answer()
exten => _X.,n,Wait(1)
exten => _X.,n(loop),Playback(demo-congrats)
exten => _X.,n,goto(loop)

This dialplan is designed to create random length calls, with a random waiting period between calls. I then issued the following command from the dialplan, to kick it off:

<div id="_mcePaste">noc*CLI&gt; channel originate Local/111@playback-loop extension 222@from-ipphone</div>

The above will start dialing over and over and over again. My test was really simple, generate X number of calls from my Asterisk host, receive X number of calls on my other SIP gateway. Calls will traverse the GSM network, always playing back the same message and information.

Final Result

Ok, so the test I devised was fairly harsh, specifically due to the fact that I left it running for 5 days !

My origination gateway had originated over 1000 calls in 5 days, sorry to say, only 500+ calls were accepted at the other side. Primary reason appears to be GSM network related and not card related – so it’s hard for me to attribute the result to a specific issue. However, in general, the card performed as I more or less expected it to perform.

Who should use this card?

If you plan to build a GSM gateway – this card isn’t for you, you need something with a bit more control and variability. For a mobile office or as a cellular backup to your PRI line in the office, this will make a nice addition, at a reasonable price range.

Overall mark: 7.5 out of 10

Ok, before all of you jump at my throat for not posting for a long time – I’m sorry. I can’t believe the last time I posted was around June, much has changed since then. So, let’s start with some updates… well, there are no big news updates. Since I left Humbug, I’ve been doing my best to keep busy with GreenfieldTech projects. We’ve successfully completed 10 different custom development projects since June and we’ve started a brand new services branch at GreenfieldTech – the VoIP Security Audits branch – but that’s a different post altogether.

So, I spoke at this years’ Astricon, which took place in Atlanta, Georgia!. This is my first time to the southern parts of the USA and might I add, Southern Hospitality is something you need to experience (I’ll write about that later). Much had changed at Digium in the past 2 years. Many of the long time project members had left to new grounds, Asterisk-SCF is now officially no longer in active development, in other words – this years’ Astricon was a fresh breeze of wind, specifically with new people at the driver seat and new ideas springing about.

So, let’s talk PRI cards. Once every often a company approaches me to evaluate their products. I do my best to be as impartial as I can – after all, Digium products are my favorite. However, I’m always happy to see a product that can compete nicely with Digium, simply because I believe it will make Digium products better and stronger. So, a couple of months ago, Allo.com approached me to evaluate their PRI card. I agreed, and they’ve sent me their PCI-e version of a quad span E1/T1 card.

Allo.Com PRI Card

So, let’s start with what I didn’t like about the card. People, it’s 2012, technology had progressed a great deal since the old Zaptel days, not to talk about the old Xilinx Spartan chips – comm’on, even the crappy Chinese boards don’t use that anymore – move on. Ok, let’s put aside the issue of the actual chips being used on the board – can someone PLEASE explain to me why I need to patch my DAHDI modules to support these cards? How shall I put it, patching DAHDI/ZAPTEL is so 2004. Make your card fully compatible with DAHDI, no patching, stream line the card with the DAHDI stock kernel module – OpenVOX did it, Yeastar did it (do an extent) – you want me to use your hardware, make it easy to install and simple to update and maintain.

OK, regardless of my somewhat reluctant feelings regarding drivers compatibility, I had the unit installed in a test gateway. It performed as I expected from a low-cost compatible. It held up nicely with normal traffic, but when I tried pushing 30 call initiations per second on the card, it heated up slightly and CPU spikes could be observed here and there. Now, in an office scenario – sure this card will do nicely – in a service provider scenario – I’ll think twice. Now, in the past I’ve received similar performance from other clone cards, so my estimate is that there is a group of engineers passing from one company to another, coming in with the know-how for a single design and they wrap that into a card.

Final word regarding the Allo.com card – not my favorite, but definitely a possibility for office environments. I have no idea how their other equipment holds up, but I hope that it holds as well, so that the office/smb market has a new option to choose from.

I will post my Astricon update later on.

If there is one thing I like doing is testing hardware, specifically, testing new hardware that is related to Asterisk. I was more than pleased when OpenVox had approached me, asking to review one of their products – specifically after I once announced that I really dislike cheap clone cards. So, I got OpenVox’s D210P card, which is a fairly similar clone to the TE205/TE210 of Digium, and I decided to take a it for a test drive.

So, first off, lets take a look at Digium’s TE205 card:

Digium TE205P Card

Digium TE205P Card

The card is based upon two specific chips, the Xilinx Spartan FPGA and an Inifineon based Quad E1/T1/J1 framer chip. Technically speaking, the entire brain of the outfit is located in the Xilinx FPGA (naturally), which on the TE205P now enables remote firmware upgrades and some additional features. Digium had been using Xilinx based boards for over 8 years now, and they’ve been doing the job more than well.

Now, let’s take a look at the OpenVox clone board:

OpenVox D210 Card

OpenVox D210 Card

OpenVox utilizes the same Inifineon framer chip (well, it’s a clone after all), while utilizing the Lattice Mico8 FPGA chip. Now, from a technological point of view, I couldn’t really find much differences between the Mico8 and the Spartan, beside a minor differences here and there – but these are not important. So, I proceeded to testing the card with Asterisk. So, the nice thing about this clone is that it doesn’t require patches to the stock version of DAHDI, which in my book means that OpenVox are aiming at being a real-clone, not some would be patched version of a clone – so that’s good. Installation was fairly similar to that of the Digium TE205P card, so I couldn’t really find specifics in there to prefer one over the latter. So, I started testing the card in various situations: Normal telephony, 3G based transmission (64kbps bearer capability),  dropped calls during high loads and checking CPU/Load spikes during high usage.

The Test Scenario and Comparison

All of the above tests were conducted according to the following scenario:

Testing Lab Server

Testing Lab Server

In general, I’ve connected 3 different IP phones to the testing server: A Polycom 650, a SNOM 370 and a Grandstream GXP2000. All IP phones include the latest firmwares and updates and were all working flawlessly with another similar setup, so I assumed they were all bug and issue free for the testing lab. The main reason I’m using 64Bit CentOS is simply due to the fact that all my servers are 64Bit capable (mainly E5410 and E5405).

Test 1: Normal Telephony

Well, in general, the card does exactly what it should – provides a connection to an E1 circuit (we only have E1 circuits in Israel). I’ve conducted normal telephony functions from all the above mentioned phones. In general, I’ve conduct from each phone a total of 40 calls, and repeated the test once for the Digium TE205P card and once for the OpenVox D210P card. The results were fairly similar with a slight advantage for Digium. In general, the OpenVox card had slipped about 4% of the calls, mainly to an IRQ miss that occurred for some reason. With the Digium card, the IRQ misses were not exhibited, allowing for all 120 calls to traverse normally.

Conclusion: In a normal office telephony scenario, the D210P is a fair choice – however, not my preference for a Call Center or a service provider.

Test 2: 3G based transmission (64kbps bearer capability)

I’ve been playing around with IVVR and Asterisk, mainly using the Fontventa H264 packages for Asterisk (that’s why I used 1.4 branch). With this test, the D210P provided less then medium results, specifically when trying to stream large 3gpp based video streams, while the TE205P had showed no specific issue with the transmission. Main issues exhibited were related to choppy video streams, causing jumps in the stream. The Digium card was fully capable of stream the video without a hitch. Now, I won’t hold this again OpenVox, as this usage is fairly advanced and is required by a very small portion of the market, but I believe they still have some work to do there. As they are using the same framer as Digium, I would deduce that their firmware is either an older import from Digium (reverse engineer) or some other firmware related issue.

Conclusion: Not a pick for 3G transmission with Asterisk.

Test 3: Dropped calls during high loads

No matter what test I did, with OpenVox I’ve always received a dropped call ratio of around 3-4% – when at high loads that went up to around 7%. When I mean high loads, I mean generating 30 outbound calls from Asterisk to one circuit, then receiving them on the second port (yes, a back-loop). I’ve conducted 100 runs of this test, at various speeds. It would appear that when generating calls with a 100ms interval between one initiation to another on the circuit, the OpenVox will drop a call here and there – at sporadic intervals. This may be actually related to the IRQ misses exhibited in Test 1.

Conclusion: If you have high load anticipated – OpenVox is not the choice for you.

Test 4: CPU Load/Spikes

It is a well known fact that all card that are used with Asterisk introduce load spikes of a sporadic nature. In the past, the masters of low spikes were Sangoma, however, with the introduction of Digium’s VoiceBus, that balance had tipped and Digium took the upper hand. In order to evaluate the spikes, I’ve monitor the machines’ load while having 30 calls traverse from one port to the other. The calls were playing back a static file of 5 minutes, and after disconnecting the calls would generate and additional one and continue from there. Both cards exhibited slight spikes when multiple calls either originate or disconnect, however, the CPU spikes that the OpenVox card had exhibited were about 40% higher than the ones exhibited by Digium and there were more spikes than with Digium.

Conclusion: If your system isn’t as beefy as mine, and you need full capacity – OpenVox isn’t the choice for you

Overall Operational Conclusion

The OpenVox card promises to be a low-cost alternative to the Digium card, and it surely delivers. Over all, if you have an office PBX system or a low scale IVR environment, the OpenVox alternative can be evaluated, although it’s not my personal favorite. Sure, in many cases I can say: “OpenVox would do the job” – but hey, I would always rather go with the original and not the clone. I believe that OpenVox are far ahead of its clone competitors (Atcom, Yeastar, Varion, PhonicEQ, etc), simply because it does a better job at building and designing a better card – however, they still have some way to go in order to be completely in-lined with Digium and Sangoma.

Reblog this post [with Zemanta]

Well, I guess it’s time for another Israeli Asterisk update post – one that was well due a long time now. This post was written after the recent hectic 3 weeks of Asterisk events and news here in Israel. So, I guess we’ll open with some news – beep, beep, beep.

Asterisk based Contact Centers

EasyRun, a world wide provider of Call Center and Contact Center solutions had announced the availability of its EpicAcce solution.

EasyRun Partners with Xorcom to Offer the Industry’s First Enterprise Grade PBX Agnostic Contact Center

EPICAcce Delivers the Industry’s First PBX Agnostic Enterprise Grade Contact Center Solution

For those in the know, the EpicAcce solution is based upon the Asterisk Open Source PBX system, bundled inside a Xorcom XR3000 appliance. I’m proud to say that I had some involvement in the development of this product, mainly, having trained the EasyRun lead developers in the workings of Asterisk – in the first Asterisk Bootcamp that was held in Israel last year. The EpicAcce appliance is defined as a PBX agnostic contact center solution, thus, it will work in any type of PBX or enterprise installation – making it the ideal solution for any company wishing to embed a contact center to their customer care, without the requirement of changing their entire company telephony infrastructure. In addition, the same unit can also be used as a the company PBX system – after all, it is based on Asterisk underneath and FreePBX as the management interface for Asterisk.

Asterisk gains recognition by the TheMarker.Com

About 3 weeks ago, I got interviewed by Amitai Ziv, a telecom reported from the TheMarker.Com IT news section. The interview (in hebrew) is available at the following URL:

http://it.themarker.com/tmit/article/6255

Now, while the article had mentioned about 25% of the actual interview and also summed up various statements from other people two, in general, it was very supportive of the Asterisk initiative and movement in Israel. I guess, well at least from my point of view, this article is a valid turning point – where the Israeli main stream industry acknowledges Asterisk as a valid business viable solution. In addition, as the founding father of the Israeli Asterisk users forum (www.asterisk.org.il) it is a great honor to be interviewed for this magazine. Sure, I make a living from promoting Asterisk and developing Asterisk based platforms, but having your face (although a horid picture) in the paper and having your name mentioned in a positive manner – is always a good thing.

Israeli Telecom Manager Club recognizes Asterisk

Yesterday I attended the “Israeli Telecom Manager’s Club” quarterly meeting, which was focused entirely on the viability of Asterisk and other Open Source based solutions. While most of the audience was made of large companies and captains of industry (Coca-Cola, TEVA, Israeli Electric Company, others) – I didn’t get the dreaded lazy eye I got almost 3 years ago.

When I started promoting Asterisk in Israel, almost 7 years ago, people looked at me as the crazy guy that has no idea what he was talking about. After all, I was an IP/Web technologies engineer, suddenly, starting to talk about telephony – in a world where 50 year old engineers were controlling and dominating entirely. Suddenly, a new kid on the block comes in and says: “Listen, Open Source can do it as good – if not better“. Yesterday was a turning point, suddenly, all these people came in to listen to me, preach and promote, both Asterisk and proper Open Source adoptation and GPL compliancy.

Israel is changing, companies start realizing that using GPL and modifying GPL products isn’t something to be taken lightly – it must be done with experts, and people that actually know what they are doing in the Open Source world. The old time Open Source geeks are starting to gain the industry recognition – Israel is finally starting to reach the state where the US and Europe are currently located at.

Digium announces availability of Support Services

This is not the first time Digium had tried doing this – first time was about 2.5 years ago. The current support services are based upon a signed service agreement, allowing the customer to receive phone based support services. According to the Digium website, the pricing model is as following:

                               <strong>SMB L1   SMB L2   Enterprise L3   Enterprise L4</strong>
Included Systems (Servers)        1         1          Up to 5         Up to 10
Included Cases (Incidents)        2         5             10           Unlimited
Additional Server Price           —         —          $495.00         $395.00
Named Contacts                    1         1             1                3
Price - 1 Year Subscriptions   $595.00  $1,995.00     $3,995.00        $7,995.00

Ok, not that I have a problem with that – I guess in the world people are willing to pay upto 300$ for a support incident – however, in Israel, that makes no sense. Judging from my experience supporting Asterisk, over 90% of the support calls can be resolved in less than 30 minutes. Charging an amazing price of 300$ for remote hands support, for an incident of 30 minutes – that is outragous. It’s true, I’m a Digium fan and I promote their products where ever I go, however, in Israel – this model will not cut it.

My company, started rendering Asterisk support services in Israel back in December 2008. Our support model is completely different – making it ideal for the Israeli market. Our support model is based upon a base line service agreement, indicating that you pay a total of 2,300 Israeli Shekels (around $500) for up to 10 hours of phone based and remote hands support services. These are rendered for a single server only – additional servers will cost you a couple hundrad more shekels, but the overall agreement in terms of time remains in tact. People in Israel know that support cases happen once every few months, so paying an identical price for getting 2 incidents handled simply doesn’t make any sense in the Israeli Market.

TDM400 Compatible GSM Module

ASTERISK GSM MODULE

ASTERISK GSM MODULE

A new product on the market introduces a GSM module to the ever popular Digium TDM400P card. The new module, available at http://www.asteriskgsmmodule.com/index.html is a plug-in for the TDM400P card, allowing it to accept a GSM SIM card – instead of the standard FXO module.

Finally, a plug-in for Asterisk that negates the need to work with a GSM converter. The bad thing is that it requires a patch to the wctdm.c Zaptel driver, and aparently, isn’t yet available for DAHDI at all – but I guess this will be fixed in the short future. I surely hope that these guys will contact Digium and maybe introduce the driver into the main stream driver distro, after all, Digium doesn’t make GSM modules – so it’s no competing with any Digium product.