post

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.

 

post

Astricon 2014 – Start your engines!

Ok All, this is my official Astricon Countdown – start your engines, as Eric Klein and myself will be attending Astricon this year, Vegas here we come.

So, what are we going to talk about: Security and Cloud computing. Yes, over the past year, I’ve been returning to my old stomping ground, the various cloud infrastructure that is publicly available – and how to exploit it to the max. I will be talking about the various methods of speeding up your clouded Asterisk server, and most importantly, I’ll share some of the methodologies and logic behind building these instances, maintaining them and the various do’s and don’ts I’ve learned along the way.

I’m planning a few surprises and giveaways for my talk, so make sure you stay updated on this page :-)

 

post

Mobile VoIP OTT is Dead! – Long Live Mobile VoIP OTT!

What do the following have in common: Skype, Viber, Whatsapp, Line2, Tango and Kakao? Yes, there are all OTT apps for your mobile phone that enable you to communicate with your peers. Skype, Viber, Line2, Tango and Kakao actually enable you to call one another. Each one dominates a section of the world, where Kakao and Line2 are dominant in the far east, Viber dominates Japan and Eastern Europe and Skype kind’a says: “Look at me bit**es, I’m all of you combined”.

What do the following have in common: VoipDiscount, Nymgo, WiCall, VoIPstunt, Vox Mobile, Cloud Roam, Skuku? All of these are VoIP Mobile OTT apps, similar to the above and yet – no one truly heard about these or is using them. Each one of the above is more or less a replica of the previous one, maybe with one or more added features – but all in general are the same pitch and bit**, make cheap calls over VoIP via our service.

So, what does it all mean? it means one simple thing, no one truly cracked the formula to make money on the Mobile VoIP OTT business – everybody is still looking for the killer business model/VoIP OTT Application. What is the right way? providing low cost calls? providing business oriented services? providing simple roaming solutions? maybe bundling roaming data plans and SIM cards? or maybe, all of these are sooooooo passe that the world just says: “Stop fu**ing about and create some truly new, change how think and how we work completely. Paying 1 or 2 dollars more per month, I’m not gonna change my service for that – it’s pointless.”

So, what are the true killer apps that will truly say: “this is a game changer, from this point onward, VoIP OTT will no longer be the same!” – Here is a list that I believe will make the difference:

1. Make calls completely social – Phone numbers are so 18th century, they are pointless

2. Make your phone aware – Presence and availability is key

3. Drop the stupid things – call recording, visual voicemail, funny sounds, funky tones – stop the bullshit, give me proper services than stupid features

4. Make your service reliable – stop behaving like a website operator and thing like Ebay, every minute your service is down or affected by bad service you are loosing money

5. Make work, then make pretty – application design is important, product design is important, but not more than the product itself

6. Invest in support and monitoring – relying on your suppliers to do it for you is stupid and childish

7. Only blame yourself! – when something fu**s up, it means that you did your job wrong and you cut corners. Don’t start blaming your colleagues or your contractors, they are only doing what you asked them to do

And most importantly, remember the following statement: “I’ve seen the furthest, because I sat on the shoulders of giants.” – don’t tell the world how you’re going to obliterate Whatsapp and Skype, look at them, strive to be them, and then do it better.

I wish all of you good luck.

Building your Asterisk based Business – Part I

** Cross posted from: http://www.greenfieldtech.net/blog/2014/03/building-your-asterisk-based-business-part-i **

Since the inception of GreenfieldTech, back in 2007, we’ve assisted over 20 different VoIP companies to bootstrap their activities and launch their products. During that period, some of these companies had become a great success and some had disappeared from the face of the planet. This series of posts will bring the story of some of them – and we’ll try to analyse what made each company into a success or a failure.

Making the case for Asterisk based business

Let’s be honest and truthful with ourselves, we’re all capitalists. Yes, we are first Open Source evangelists and promoters, but at the end of the day, we do need to pay our bills and make ends meet. Thus, we monetize open source (in our case Asterisk) to the best of our abilities – there is no shame in that, and honestly, we take high pride in our ability to assist companies in monetizing open source tools and project in a productive and lucrative manner.

When people talk about Asterisk based businesses, normally they will consider one of the following tracks:

1. Asterisk PBX Integrator – Integrating Asterisk based PBX systems for companies of various sizes. Normally, this will include infrastructure installation, cabling, server support, hardware sales, etc.
2. Hosted PBX Service Provider – Providing VoIP PBX services, without any in-door server equipment, relying on the Internet or leased lines only. Normally this will include similar activities as the Asterisk PBX integrator.
3. Hosted IVR Service Provider – Providing Hosted Interactive Voice Response services to content providers and enterprises that can’t sustain their own IVR infrastructure.
4. Hosted Premium Services Provider – Identical to “Hosted IVR” with a focus on premium services content and adult content.
5. Telecom Carrier – Whether you are a mobile carrier or a landline CLEC, Asterisk applications can benefit a carrier of any size.
6. Value added services provider – Providing complimentary services to Asterisk and its derivatives.

The above is a very short list, as each item on that list can be expanded to 6 more sub-categories – however, these represent the major business types (not including consultants and developers, who fall under category number 1). There are similarities between these and significant differences as well. What may be true for one, maybe completely wrong for another – it all depends on your business goals and product development life cycle and life span. We will limit ourselves to discuss options 2 through 6.

Case I: Long Distance Calling Cards Operator in the US

June 2007, a representative of a calling cards operator in the US approached. The operator was back then using a hosted service from a company called Solegy (long gone) and was fairly unhappy with the service. Their main complaints were: lack of support responsiveness, lack of feature set, inability to expand existing feature set – and most importantly, inability to sustain a proper business model (unlimited calls), due to high termination and hosting prices.

At that time, the calling card operator had put the following restrictions as to creating the service:

1. Bootstrap pricing should not exceed the $10,000 USD.
2. All existing customers should be migrated to the new system.
3. All existing access numbers should be migrated to the new system.
4. New system should be based upon ready-made software – not customized development.
5. New system should enable additional service development and scalability.
6. New system should allow hosting on hosted servers, without any need for proprietary hardware.

The solution that was chosen (after all, it was 2007) was a mixture of OpenSER, coupled with Asterisk 1.4 and A2Billing. Calls will hit the OpenSER SIP proxy, which will then load balance to the various Asterisk servers. The solution met the various constraints listed above – and later on included a monthly support/maintenance cost that was sustainable for the business. The company continued on to provide direct DID numbers, VoIP termination services, Roaming SIM cards solutions, Hospitality Mobile phones and additional services. In 2010, the company had sold its operations to another company – which was a disaster. During the recent changes in the roaming market in the US and other regulations, the company had seized its operations and is no longer operating.

Was this company a success story? – Complicated Answer

Between the years 2007 and 2010, the company had grown from 1000 customers to a whopping 15,000 customers, paying a monthly service fee ranging from $15 USD to $59 USD. Roughly calculated, that’s an average of $550K USD per month turn-over. In deed, termination costs and operational costs rose up to around $450K USD a month, but considering the fact that the company had only 4 employees and two additional outsourced support resources, a monthly Net revenue of $100K USD is not bad – we can surely mark this as a success. The company realized that in order to sustain its business, they would require proper customer care and support services and they made sure these resources were clearly managed and sourced.

Following the company’s purchase in 2010, the new owner had decided that customer care and support structure aren’t really required, as the sales staff can handle customer care and support can be rendered by an outside resource on a per-incident base, with no binding SLA service.  Within less 12 months, the company customer base shrunk from 15,000 to around 3,000, bringing the entire operation to a stand-still. The new owner tried focusing on new business tracks, without preserving and maintaining the existing lucrative tracks.

So, what went wrong here?

The primary answer would be: failure of the new management to understand the business. Calling cards and VoIP services are customer oriented services. This applies to Mobile VoIP OTT services as well. Asterisk is a solid tool to use when building your business, it will take you a long way and make sure your ROI and TCO will remain as low as possible, while preserving your knowledge and experience in-house as much as possible. When a successful company is acquired by a financial outfit, that has no valid experience in the market sector, in many cases – it will fail. The lack of understanding of customer care structures, proper support, proper monitoring, proper NOC, ticketing handling, NOC liaising and proper technical escalation are the main attributes of a successful service and product in this industry.

In our next post

In our next post we’ll discuss the world of “ad-revenue financed calls” and the “call-back industry”, as it was in 2008, 2010 and what happened to it today.

 

Hardware Review: Allo.Com GSM Card

** 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