The rants and raves of a technogeek
Posts tagged IVR
Asterisk, Greed and Revenue Shares
Apr 23rd
Revenue sharing is one of the oldest methods of earning profits, actually, I believe it may just be right up there with trading of goods and food. For those of you not in the know, I’ll explain what revenue sharing is:
- A content provider wishes to distribute a certain type of content – charging for it.
- The content provider has not ability to charge the consumers directly, thus he partners with another party – the transport maintainer.
- The transport maintainer charges the consumer, while keeping a certain percentage in his pocket.
- Everybody’s is happy.
In general, this model works really well in many markets – specifically those that are driven by unique content – for example the mobile content market (ringtones, screen savers, games, apps) – the Apple App store is a wonderful example of how this works.
In the telecom industry, the revenue shares business is very common – however, in many cases it is highly guarded as a secret – main reason is that now one wants anybody else to know how they do it. This hiding of information, usually results in some problems – as when there is hiding of information, only those in the know are able to access it. Those in the know are called “mediators” or in Herbew “Machers”. In this entire ordeal, the mediator also takes a small percentage – leaving the content provider with slightly less. So, now it looks like this:
- A content provider wishes to distribute a certain type of content – charging for it.
- The content provider has not ability to charge the consumers directly, thus he contacts a mediator to find him a transport partner.
- The mediator engages the prospective transport maintainer.
- The transport maintainer charges the consumer, while keeping a certain percentage in his pocket and passing some funds to the mediator as well.
- Everybody’s is happy.
So, if everybody’s so happy – why am I bitching about it? very simple – people are Greedy and always want more – putting the entire model into a frenzy. In order to give an example, let’s imagine the following scenario:
- Company A provides IVR based content utilizing Asterisk server, connected to the internet.
- The mediator engages a premium number company, getting the total revenue of 0.08$ for every inbound minute of traffic.
- The premium number company leaves 0.01$ in its pocket and also pays the mediator a fee of 0.01$ per minute.
- The content provider gets 0.06$ of the 0.08$ – 75% of the net profit goes to the content provider.
- Content provider says: “Hell, I want the mediators 0.01$ as well, and I think the premium company should only get 0.005$, so I would get 0.075$ at the end”
- Content provider contacts the premium provider and starts complaining
- Premium provider negotiates and strikes a deal for 0.07 to the content provider, leaving the premium provider with 0.005$ and the mediator with 0.005$
- Premium provider says: “I’m not making enough money on this, actually, I’m loosing money – I’ll find a better alternative service for that access number”
- Premium provider asks mediator to bring in a new customer, providing similar content – mediator has sure incentive here
- Premium provider gets new customer and transfers the access number to the new customer – returning back to previous profits
- Original content provider is left with no profits and only greed in his hands
- Image via Wikipedia
Over the past 10 years, I’ve seen this vicious cycle happen over and over and over again, in various formats and scenarios – but always ending in the same outcome – the content provider always suffers. If you’re a content provider and you provide IVR based services, let the people that provide you the access make their cut and the people in the middle, without them, you will have a service with no access – which means no service at all. Don’t go about thinking you can keep all the profits to yourself, you will break the equilibrium of this business, and eventually, no one will want to do business with you.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=b72e0863-eb76-4565-9a7e-d289f2ae6af1)
Open Source, Philanthropy and Asterisk
Apr 16th
Image via Wikipedia
When I started using Open Source software, it seemed like all Open Source projects are driven by philanthropic agendas. We were all focused on “sticking it to the man” – showing all these would be software vendors that community driven projects can do just as well – if not better.
"When I was a child I spoke as a child I understood as a child I thought as a child; but when I became a man I put away childish things." - I Cor. xiii. 11.
Well, I’m not claiming that Open Source is childish – absolutely not, however, when you are a student you tend to look at things in one way, when you have a family to care for – you start looking at things differently. You remember these days in life when your dad said: “When you’ll have children you will understand” – well, now I do.
So, what am I rambling about exactly? I’ll tell you. The day before Passover I attended several meetings, which when I came back home had pissed me off immensely. I feel an urge to write all about these meetings, including who I met exactly, however – I won’t do that. However, I will give a rough idea of these.
Meeting 1 : A world recognized Mobile application player
I came into the meeting with this company, where the CTO of the company explained to me that they are looking to create an Asterisk based solution for their application’s users. My initial question was: how many users? what is your concurrency level? – The answer that I got was: “Oh, we don’t need something major, just a few lines of configurations in Asterisk config files in order to make this work”.
I left the meeting slightly pissed off, thinking to myself: “You bloody inconsiderate prick! You bring me to a meeting, spend my time – and then telling me that this is just a few lines of configuration. If it is that simple, why don’t you do it yourself? you have 20 developers in there, 4 IT people and god knows how many outsourced workers off-shore – if it was that simple, you would have done it already – so probably it isn’t – right?”
Meeting 2 : A well established IVR services vendor
The second meeting was with a well established IVR content vendor, this company runs around 16M minutes of inbound IVR traffic every month. They invited me in order to talk about expanding into new countries, wishing to get premium based access numbers in various countries. So, we started talking, and the guy indicates that he wants a certain kick-back payout, which I know is impossible – at least without charging the user more. Actually, the guy indicated that out of the interconnect fee, he wants to get almost 90% as a kick back.
Meeting 3 : A start up rendering IVR content
The third meeting was the most amazing one – these guys wanted to build an Asterisk system to server around 4000 concurrent channels – outsource the entire development to my company – and pay as a revenue share. When I asked for their business model, marketing plan, investors, profiles – I got a response of – we don’t yet have all of these, we only have an idea at this point that we want to implement.
Garage based companies are built by people who can do the work themselves, not the other way around.
- Image via Wikipedia
At this point, you are probably asking yourself: “What does this have to do with the title?” – Well, all of these meetings had one thing in common. The people I met were under the impression that Open Source is some form of philanthropy. Or to be more exact, people who deal with the Open Source market are philanthropists. My question is this: “Why are we perceived as philanthropists? don’t we have families to care for? don’t we need to pay mortgages and bills just like everybody else?”. I guess when people read about the various Open Source entrepreneurs, such as Mark Shuttleworth – the immediately associate Open Source with Big Exists – this is not the case.
At some level, this is purely our fault – we educated people that Open Source is a highly economical methodology of solving technical challenges. No where along the way, had we educated the public that behind the model there are people, people who need to make a living.
If you are an Open Source consultant, developer, evangelist or just someone who may have an opinion on this, I’d love to read what you say.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=0d6b720b-e2bc-4e1f-bf59-7f5ce2ce1615)
Rock Solid Clouded Asterisk
Feb 9th
This post is somewhat a combination of posts from previous posts, mainly, the posts about virtualization and my latest posts about the utilization of Amazon EC2. As some of you may know, a part of what I do at GreenfieldTech is develop various API’s for the Asterisk Open Source PBX systems. Two of these API’s are the IVR API and the Dialer API. This post if called “Rock Solid Clouded Asterisk” as it will describe the latest production environment that I’ve implemented, using these API’s and Amazon EC2 virtualization framework.
The network diagram
Our implementation consisted of the following general schematic:
Network Diagram
The application logic was based upon a JAVA based web-service, implementing the XML-RPC server side of the IVR API, and a dialer management system that controlled the dialer API located on the remotely located dialers – hosted on Amazon EC2 instances. For simplicity, and we were very much aware this would reduce the overall capacity, we’ve located both the dialer framework and the IVR API execution on each of the servers, while allowing the server s to communicate internally.
Some constraints
As much as we wanted to run many Amazon AMI instances, we were limited to running 5 elastic IPs with a single Amazon AWS account. As a result, we’ve registered 5 accounts, and executed a total of 24 AMI instances with 24 elastic IP’s.
An additional constraint we had realised, but had no way of actually knowing its limitation was the actual number of concurrent calls per server. Initially, we’ve reached the following numbers and configuration on a physical server:
- Intel Quad Core XEON
- 2GB RAM
- 1GB Network Uplink
- CentOS 5.2 64bit
- Total capacity: 120 concurrent calls of Dialer+IVR on a single server
Per our theory, if we managed to reach a similar capacity using amazon c1.medium instances, we would be very happy.
The results
After conducting a test utilizing a single AMI instance, we’ve reached the following results:
- Dual Core instance (c1.medium)
- 180GB Disk Storage
- 8GB of RAM
- Fedora Core 8 32bit
- Total capacity: 80 concurrent calls of Dialer+IVR on a single instance
A decrease of 33% in comparison to the performance observed on a physical server. Ok, so we weren’t all that happy with these results, until we started doing the financial math, realising that using Amazon EC2 with that Dialer+IVR framework would yield a savings of almost 80% in operational costs.
Doing the math
The normal co-located option
Our aim was to reach a capacity of around 2800 concurrent channels. Per the normal physical setup, our hardware requirements would be to use at least 24 servers. At a price of 1500$ per server, that sums up to a total of 36,000$. Adding the time required to install 24 servers, the overall expense for 24 servers would be around the 42,000$ mark. To sustain a total of 2800 concurrent calls, using the g711 codec, we would be required to carry a total of 300Mbps internet uplink – basically talking about 10,000$ of bandwidth.
So, taking all of the above into consideration, we will need a total of 52,000$ just to maintain the hardware installation and operational cost. Taking into consideration that the system would be used at full for no more than a period of 30 hours, we end up with a total of: 1733$ per hour.
The Amazon EC2 option
Now, let’s calculate for Amazon EC2:
2800 concurrent channels translates into 35 instances. Price per c1.medium instance per hour is 0.2$. So, rack that up and you get: 210$ for operating 35 instances for 30 hours.
Elastic IP costs are 0.01$ per hour per server – a total of 10.5$ for 30 hours.
Bandwidth costs are 0.17 per each GB, so according to 300Mbps for 30 hours, with each call duration at 1 minute sums up to be: 5M of data per call. Calculating 2800 concurrent channels for 30 hours gives: 25,200,00 MB, or 25TB of traffic. According to Amazon, first 10TB are at 0.17$ per GB, and then the price goes down. So, let’s take a worst case of 0.17$ per GB. A total of 4284$ for operating 30 hours.
A total of: 4,468 US Dollars, Price per hours calculated at: 148$.
The savings
Per the task at hand, the utilization of Amazon EC2 yielded a savings of 92%
So, is Amazon EC2 good for any usage?
The answer is a definite NO! If your requirement is for a system that works 24×7, like a PBX system or a call center, then your utilization of Amazon EC2 would be identical to leasing a co-located server at any of the world wide co-location providers. If your application is of sporadic nature, or is utilized for short bursts of time, Amazon EC2 is a wonderful tool for lowering your overall expenses. Sure, it will require some work to get running, but the overall savings is more than worth-while.
Asterisk 3rd Party API – and their importance
Jan 30th
As some of may know, I spend most of my time working as an Asterisk Developer and Consultant in my own company – called Greenfield Technologies Ltd. - named GreenfieldTech for short. Since the day I started my company I knew a few facts and truths:
- GreenfieldTech starts as a one man operation – thus, spending more than 15% of my day to day tasks on support issues will surely stress me out and drive my business to the ground.
- I don’t really want to deal with PBX installations and various office telephony aspects of using Asterisk – simply because it requires to much of item 1.
- I need a way to be able to provide a fast response to my customers, maintain a low support over head and make sure that what ever I do, it can be accounted for.
Hence the above, I understood that GreenfieldTech‘s products are not really the various services it provides, but actually the products vary completely from what a product looks and feels like. I understood that in order to provide this fast development turn-around I needed my own development framework. Surely PHPAGI, Adhearsion and Asterisk-JAVA can easily provide for a development framework – but it still doesn’t help me one bit – I needed something different.
I then realized that GreenfieldTech‘s products are the one product line that all developers and vendor steer away from: Programmatical API frameworks. The programmatic framework should provide the most basic feature set, allowing it to be extended and continued onwards at ease. Hence, the suite of GTx API frameworks were born. A set of 3 different APIs provide all the facilities required for building any of the below:
- Dynamic IVR structures – driven via web services
- Recording systems
- Pre-Paid/Post-paid solutions
- Inteligent Network (IN) services
- Automatic Dialers – Predictive, Power, Progressive, Preview
- Broadcasting systems
- and more …
The entire API suite is based upon XML-RPC based web services. When I introduced XML-RPC to one of my customers, he immediately indicated: “But, XML-RPC doesn’t really provide for session oriented persistency. Why are you using XML-RPC?” – The reason is simple – we don’t need session persistency in the API – Asterisk can provide all of that internally. Thanks to Asterisk’s channel oriented architecture, we can regard each of Channel thread in Asterisk as a seperated data container, capable of holding all your session information and persistency information at ease.
Recorder API – http://www.greenfieldtech.net/products/gtrapi
IVR API – http://www.greenfieldtech.net/products/gtvapi
Dialer API – http://www.greenfieldtech.net/products/gtdapi
The best thing about the GTx API suite is this – they are all interconnected. For example, call being handled by the Dialer API can be then handed over to the IVR API, operating within the same Asterisk server or a remotely located Asterisk server (via SIP/IAX2).
In the time to come, I’ll be showing you various XML-RPC structures and example of how to use the GTx API suite, and do all sorts of interesting IVR and Dialer structures.
Hijacked by RTFM to la-la land
Oct 28th
I keep a vigilant eye on Google Alerts. To be more exact, I’ve got a few alerts defined, in accordance to subjects that interest me. Two of these subjects are Asterisk and FreeSwitch. Recently, the following had been posted on a personal blog:
Our PBX/IVR web-based generator Telfa has been moved from Asterisk to Freeswitch. Why?
Asterisk just seems to come from a different world than what I am used to. Inflexible and problematic. Very long configuration files with ancient syntax. Now I’m far from pretending I’ve used Asterisk enough to understand it pros and cons well, but I have a decent software development experience and I can tell when something “smells.” I didn’t want to build our system (that I want to be flexible and scale well) on some old technology that is only living from its past.
And (most importantly) there are many people experienced with both Asterisk and Freeswitch favoring the latter: Anders Brownworth, Jonathan Palley (creator of Telegraph, a Rails plug-in that lets you talk to Freeswitch), or of course the creator of Freeswitch (and former Asterisk developer!) Anthony Minessale himself.
[Extract from: http://onruby.flempo.com/2008/10/28/chose-freeswitch-over-asterisk/#comment-58]
Reading the above simply flames me UP – WHAT A LOAD OF BULL!
The writer admits that: “Now I’m far from pretending I’ve used Asterisk enough to understand it pros and cons well, but I have a decent software development experience and I can tell when something “smells.”” – If he’s such a worthy developer, the above simply proves that he’s simply an RTFM!
Asterisk provides a multitude of methodologies for configuration management, dialplan logic programming, programmatic API structures – basically, all the tools you need to go about and create your application. While I admit that FreeSwitch is slightly better at the “Core Switching” environment, implementing a near true Soft Switching architecture – Asterisk is a totally different thing.
A while back I decided to develop a couple of my better systems on FreeSwitch, as a test of my abilities. To see if I can be as proficient with FreeSwitch as I am with Asterisk. I re-developed the applications on FreeSwitch from scratch, however, FreeSwitch’s somewhat annoying XML configuration structures made it a hell for me to develop something that I would ask my customers to put their money on.
I started working with Asterisk in 2002, and starting 2003 I tried to have people in Israel start using Asterisk. I can honestly say that the first ever true adaptation of Asterisk in Israel came about only late 2005, and even that wasn’t for mission critical applications. Asterisk had achieved a point in which it is now considered a valid replacement for classic IN and NGN applications and engines, such as SigValue. I suspect that FreeSwitch will become a more dominant contender in that part within a period of 18 to 24 months, as its developer community will grow – time will tell.
In my large installations, I like using Asterisk as my IVR/Application engine envrionment and using FreeSwitch as my routing and LCR environment, simply because it’s capable of handling slightly more SIP-to-SIP connections than Asterisk – but that is the only reason, all the rest is Asterisk.
Both projects are wonderful tools, each one with its own set of strengths and weaknesses. Learn how to balance the use of the two, utilize the best of both world – and stop being a bloody purist, that’s exactly what leads to poor technologies such as Microsoft and poor life practices, like wars and terror.
Picasa
Twitter
Facebook
LinkedIn
wikipedia
Youtube
RSS