Ever since John Gage of Sun first offered the phrase “The Network Is The Computer” to the world, people have been using it as inspiration. Sun use it to explain that they mean Social Networking without actually using the phrase (they prefer the old fashioned “community”).
I think web 2.0 developers are offering a new perspective on the phrase. There was a time that if I wanted my computer to do a job, I would find or buy a piece of software that was engineered to cause that job to be performed. The Internet and the Web 2.0 culture is changing this model completely. Its becoming the case that the computer in front of me is stupid, and some cluster of servers in MarketPost Tower, San Jose actually does all the work.
Enter Mint. Mint is self described as refreshing money management. Sound like what Quicken does if I install it on my computer, but with the word ‘refreshing’ in front? It’s refreshing (well, different) because to use their software I simply need to visit their website and sign up. Mint will learn about your spending via your online banking accounts, and aggregate your personal finance situation into one simple application. It sounds so simple, and solves no problems that weren’t also solved with personal finance software on the ZX Spectrum. And yet on Launch day just a couple of months ago it won $50,000 in the innovation contest, ‘Techcrunch40‘.
There’s two lessons from this. Firstly, there’s a new blueprint for guaranteed success in the web 2.0 world, and that is if you can take all the features of a market leading piece of traditional software, and build that functionality into a website, then you will be heralded an innovator. But you have to be the first person to do that. So hurry.
Secondly, and this is a lesson that wont be learned by the general public for a while, is that putting your private data in a central place that you do not control, is a weak point of attack when someone wants to learn something about you. Maybe someone wants to target your assets. Maybe the government want a nosey in what you’ve been spending. Maybe a consumer profiling company want to run a survey. They only have to get hold of one set of keys to your mint account, and all three of these groups can do what they want with your data. If my computers were stolen, then an expert would be able to find out quite a lot about me. If I put my data online and it gets stolen, the same can happen. And if everyone puts their data online in the same place, then it becomes very attractive to break in and steal it for lots of groups.
I come from an IP engineering background, and now work in a telecoms role with Localphone.com. Huge amounts of crossover exist between the two disciplines, especially now that inter-company telecommunications interconnections are now regularly made over IP, but much of what someone will learn about peering in the voice world will not be mellifluous to someone with a background in IP peering.
I attended a PulverMedia conference on voice peering last week, with some preconceptions about what I imagined voice peering to be. These are some things I learned after talking to people at the conference. Gary Kim gave one of the most useful insights when he complained that he was, “More confused about where peering is going today than he was two years ago.”
“Why can’t I configure a voice peer like I can configure a BGP peer?” is a typical question. The answer is simple. When you peer using IP, the protocol is well known and established, prefixes are in a ubiquitous standard, peering is typically settlement free (and when its not, pricing is transparent and easy to calculate as mostly all traffic is equal – from a billing perspective).
The sad dichotomy is that in the voice world, prefixes (telephone numbers) behaviour is not identical, the protocols different companies use will be different (media codecs, call signalling, dtmf), and thanks to the regulators and history of commercial telephony peering is hardly ever settlement free.
This complexity has led to the emergence of another traditional pattern in telecoms – a barrier to entry. Clearing houses who will abstract peers from each other. They mediate media codecs, signaling differences, and perform CDR mediation. A barrier to entry, because they don’t want to do this for free. This is a model which is not great for many telcos who quite rightly don’t want to yield control of their outbound dialplans to any third party. Abstracting my media might mean callers get lower quality calls, and leave me as a service provider with poor visibility of the route that a call between two parties takes. Abstracting signaling without me being aware means that error messages about calls are lost in translation.
The clearing house model is also a natural monopoly. If a company is a member of one clearing house, and I am a member of another, then there is no way for us to peer using the traditional clearing-house model. Some clearing houses have suggested a protocol that would permit clearing houses to peer (share their registry data) – effectively increasing the reach – but this potentially further increases the layers of abstraction between me as a service provider and a peer.
Before I explain what I think the answer is, let me explain a few of the reasons why peering between telephony companies is good. Peering between competitive telecoms companies reduces their dependency on national incumbent providers. Two large non-incumbent telcos can peer, possibly meaning that TDM legs are removed from a call which is IP at both ends resulting in better quality calls, possibly permitting the use of new ultra-clear wideband-audio codecs, and typically at cheaper rates than connecting through an incumbent party. This gives telecoms customers cheap calls at a higher quality. As a result this is an important strategy for next-gen telcos.
Telecoms companies need to communicate their prefixes and standards bilaterally – that is to say, without a clearing house. I am working with some of the people I met at the conference on a new Internet-Draft to suggest the protocol that would facilitate this (like TRIP, but with enough understanding of commercial logic in the protocol to make it useful). I’m hoping to publish the first draft later this month.