Asterisk, Greed and Revenue Shares

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:

  1. A content provider wishes to distribute a certain type of content – charging for it.
  2. The content provider has not ability to charge the consumers directly, thus he partners with another party – the transport maintainer.
  3. The transport maintainer charges the consumer, while keeping a certain percentage in his pocket.
  4. 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:

  1. A content provider wishes to distribute a certain type of content – charging for it.
  2. The content provider has not ability to charge the consumers directly, thus he contacts a mediator to find him a transport partner.
  3. The mediator engages the prospective transport maintainer.
  4. The transport maintainer charges the consumer, while keeping a certain percentage in his pocket and passing some funds to the mediator as well.
  5. 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:

  1. Company A provides IVR based content utilizing Asterisk server, connected to the internet.
  2. The mediator engages a premium number company, getting the total revenue of 0.08$ for every inbound minute of traffic.
  3. The premium number company leaves 0.01$ in its pocket and also pays the mediator a fee of 0.01$ per minute.
  4. The content provider gets 0.06$ of the 0.08$ – 75% of the net profit goes to the content provider.
  5. 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”
  6. Content provider contacts the premium provider and starts complaining
  7. 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$
  8. 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”
  9. Premium provider asks mediator to bring in a new customer, providing similar content – mediator has sure incentive here
  10. Premium provider gets new customer and transfers the access number to the new customer – returning back to previous profits
  11. Original content provider is left with no profits and only greed in his hands
Screenshot of a GPL screensaver
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]

Open Source, Philanthropy and Asterisk

Tux, the Linux mascot

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.

Photograph of Mark Shuttleworth by Martin Schm...
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]

Call Analytics – Closed Alpha testing group

Well, it’s been almost a month since I’ve started writing about the humbug project. Now, it’s time to actually get you people involved, at least in the initial levels. We are looking to add 10 additional members into the humbug call analytics suite. Currently available analytics during the alpha testing is inbound call analytics.

Our aim is to gather as much information as we can and as much user requests as we can, humbug is a community oriented project, thus it relies on community oriented input and feature requests. Participating members will  be granted access to the humbug analytics portal, allowing them to gather statistical information regarding their inbound call hits and their top ten DID numbers – we are working on additional statistics. As new stats will become available, we’ll role those out into the service as soon as possible.

In order to participate in the closed alpha testing, please send an email to alphatest at humbuglabs.org, and we’ll send you a short piece of dialplan code to insert into your Asterisk server. Technically speaking, we’ll send you a short AGI command that looks like this:

exten => _X.,n,AGI(agi://somehost/DataReceiver,some_unique_ident)

The above line needs to be inserted into any place you would like to generate call analytics from. We’ll also enclose configuration steps for FreePBX (and other FreePBX compatible distributions). We are hard at work for creating a FreePBX integrated module, so you can do a one-click install.

Reblog this post [with Zemanta]

Call Analytics – Beyond CDR analysis – Part I

“Oh, just get me the CDR‘s and I’ll take it from there” – how many times have I heard these words before? I can’t even imagine the number of times in the past 15 years of IT/Telecom’s work that I’ve done and in the last 8 years of Asterisk in particular – when it comes to billing and fraud management, it would appear that the CDR’s are the Rosetta Stone of the industry.

Over the past 6 months, several of my friends and I had been asking ourselves this question: “Is there more to billing, fraud management and profit leakage? does it really all begins and ends with the CDRs?” – so, here we were, a group of 3 engineers dealing with telecom system and billing systems – we knew that the answer is a definite YES, however, how come most companies and system aren’t even aware of this, in such a way that causes them to leak telecom profits and waste their hard earned profit margins on simple accidental mis-interpretation of CDR records.

So, we’ve decided to sit down and start analyzing calls in real-time, trying to evaluate not only the CDR record that is received upon the completion of the call – but also understand the traversal path of the call, analyzing it in real time and evaluating it profit leakage potential. At the mean time, we’re concentrating our work on Asterisk, as it is the simplest for us to implement – however, we’re not focusing it only on that – we’ll looking at adding it to FreeSwitch, Yate, OpenSer/Kamailio, OpenSIPS and the various varients.

So, what have we done so far? well, one thing we never really had with any of the existing systems was a clear view of what’s going on “right-now” on our systems, so we said: “it would really be great if we could know how many call hits we’ve received during the past 15, 30, 45 or 60 minutes” – so here is what we made:

Inbound call statistics for 30 minutesThe above image shows our top 10 inbound DID numbers, as you can see these are in the 972 and 447 country codes (yes, we work mainly in Israel and the UK). At the backend, our servers are analyzing the data in real time, generating an active alert in the case a DID number’s statistics change in a somewhat drastic change, thus, establish a traffic anomaly. Another thing that interested us was our usage across multiple servers, which we are exhibiting in the below graph:

Traffic by server spread

Now, as you can see, the top graph shows a discrete anomaly:

Discrete traffic anomalyThis anomaly indicates something went wrong on all our servers between 00:45 and 1:15, which gives us a fairly discrete period of time to seek for a problem in the system. What happened was that one of the guys updated a portion of the data traversal API – basically deleting it :-) [we resumed full work after about 40 minutes].

So, where is it all going to? well simple, a new Open Source based service that we’ll be launching within a few months from now. Our intention is to provide a means for simple, straight forward, highly reliable, call analytics, fraud management and profit leakage analysis service. A service which is based upon a simple to use API on one hand and Open Source based data gathering agents. Our belief is that by analyzing large amounts of data, from multiple sources around the world, we’ll be able to ascertain the fingerprint of a telecom bound attack – being able to alert the respective users of the service and maybe in the later future, also provide a means to block the attack as it advances across the world.

I’ll be updating about our advancement as we go along, but for the time being, this is something I felt would interest you.

Reblog this post [with Zemanta]

Beyond the dialtone – PBX user experience revisited

When most of us think about PBX systems, we usually associate these with cumbersome usage, confusing dialing codes and in most cases – a PBX system is automatically associated with the annoying task of transferring a call from one handset to another. Lately, I’ve been thinking deeply about how people use PBX systems, is this really the only way to use a PBX system? is there something else to the mix? can we really enrich one of the oldest operational paradigms in the world? – and for that matter, can the public be re-educated to assimilate a new breed of PBX systems or services?

Hardware-based IP phone
Image via Wikipedia

As to answering the question of re-educating the public, I guess I’ll have to leave that question to the head shrinks. As to answering the latter, enriching the PBX experience is both achievable and advisable. When I say enriching, I mainly talk about your ability to bring to the IP phone functionality usually not associated with it. Imagine to have the ability to receive a stock exchange RSS feed to your phones idle screen, notice that you stock is either rising or falling, and by the flick of a button – either sell or buy. We’ve all come accustomed to IP phones that look like the one of the right. A whole bunch of buttons, that in most cases have no direct use when our phone is utilized using a single account. However, these buttons can be externally re-assigned and re-programmed to achieve greater functionality – surpassing the normal behavior of just making phone calls.

The technology involved exists on almost every high-end IP phone on the market (well, at least those made by SNOM, Aastra, Cisco and Polycom – most of the Chinese makers don’t have this) – it’s called a Mini Browsers. Mini Browsers are exactly what they are called, these are simplified versions of your typical Internet browser. Some vendors had produced their own XML based Mini browser markup language (SNOM, Cisco, Aastra) while others had decided to provide a sub-set of XHTML (Polycom). The variations between the vendors are at the neck deep of the problems of using Mini Browsers, and that is that the formats are considerably different. Sure, SNOM had more or less adopted Cisco’s general structure, however, it still varies.

Through the utilization of this technology, it is possible to create phone based browser applications, that seem native to the phone user, as the general interface resembles the native phone interface. It is now the developers job to make the web interface displayed to the user as seamless and as native as possible, keeping in mind that the developer must remain agnostic to the information retrieval layer. Most companies leave their phone systems and these tasks to their system administrators and infrastructure team, however, this task is far beyond their capabilities and skill set. Creating an agnostic IP phone minibrowser dislplay layer, capable of utilizing multiple vendors and models, is a question of content management and content rendering, very must similar to the content transcoding problem that is common to the mobile content world – in other words, a sys-admin will create an ad-hoc solution, a programmer will create a proper, well structured, well designed solution that carry the enterprise beyond its initial needs and requirements.

A short example of how these interfaces work can be found here – on my company blog.

Reblog this post [with Zemanta]