As I cleaned out my basement this weekend, I happened upon some notes from graduate school. After I got over the shock of barely comprehending work I did almost twenty years ago, I sat down to go through some of the papers.  Back then, and for my first few years in industry, I was a digital signal processing guy – in particular, I worked on digital modem design – and the papers were from some work I was doing for a meteor burst modem my team was designing. A meteor burst modem uses the ionized trail that’s left as the meteor enters the atmosphere as a medium to propogate radio waves.  This trail can stick around for nearly a minute, and every minute of the day, one or two trails will appear in the sky . I know it might sound “out there”, but it turns out that if you explode an nuclear device, all communication devices and techniques in the area sort of stops for quite a while, and meteors tend to come back first.  We cared about that twenty years ago.  (As a side story, I also worked on an atmospheric propogation simulator, continuously blowing up a particular Western European city time and time again. Sorry about that.)

Anyways, my work was around trying to figure out just how accurate the analog to digital converters (ADCs) had to be for the problem at hand.  An ADC simply estimates the amplitude of an electrical signal at any particular time, and if you “sample” a signal at regular intervals, and you sample at least twice as fast as the fastest part of the signal, you could recreate the signal. Well, almost, as the ADC only takes an estimate of the amplitude – measured in the number of bits of resolution. Think of weighing yourself on a scale: it’s an estimate.  You don’t actually weigh 170 lbs, but it’s a good estimate. The same thing with an ADC. You design with an 8, 10, 12 bit ADC – the higher the number of bits, the more accurate your estimate (and the higher the price and slower the operation).  It’s silly to overdesign it, but once the information’s gone… it’s gone, so you have to think.

I walked upstairs to write my presentation for the Telco 2.0 show where I’m dealing with this very issue, but instead of making the world safe for democracy (boy, does that sound like a bad joke now), I’m dealing with next generation telco APIs (making the carriers safe for developers, which I hope isn’t as bad of a joke).  In particular, I’m tracking the evolution of the API, and for my talk, I’m looking at what happens when you add a service like location an application.  Location is obviously a fantastic addition, as it adds so much context to decisions and operations, but I was wondering exactly how  much location you needed to know.  Can it be enough to say that I’m in a town? How about within ten yards, like GPS can do.  How much accuracy do we really need before there’s incredible value?  I have an answer: one bit.

As an example of the ridiculous value that APIs can offer to the application designer, I want to put forward that if I just had an API that would answer a one bit question about a user’s location, I could code some seriously cool applications.  I want an API that will tell me if the subscriber’s at work. That’s it. It’s all I need to know, and all I need is one bit for that. Yes or no, black or white, on or off.  If I knew if the subscriber was at work, what could I do with that?

• I could trigger his timecard.
• I could send his cell phone calls to desktop phone.
• I could send his personal calls to voice mail when he’s in the office, and the work calls to voicemail when he leaves.
• I could deliver him lunch coupons from the cafeteria.
• I could populate his information in an emergency response roster.
• I could flag fraudulent credit card transactions when he’s at work, and his credit card is not.

And just imagine what you could do with 12 bits… but that’s not the point.  Every so often, it feels like there’s a massive amount of complexity and work we bring upon ourselves where if we just stuck to simple things, we’d be more productive and effective.  Perhaps the real LBS service isn’t about your lattitude and longnitude, it’s about “I’m at work” and “I’m at home”.  Ok… that’s two bits.  But you get the point.

Like most engineers, when I see a technology that seems really easy to implement, I have this urge to dismiss it.  Perhaps it’s the modern tech equivalent of Samuel Johnson’s quote : “What is written without effort is in general read without pleasure.” Enter click-to-call.  Six months ago, when I thought of click-to-call, it was all I could do to avoid yawning, for indeed, a click-to-call service is nearly trivial to implement, and with open source software, it is trivial. Now that I am putting the finishing touches on my report, I realize that I’ve moved quite a bit from my original stand.  I didn’t fully understand how compelling the business models are it enables, or what a versatile element it can be for the telecommunications architect. I’ll leave the business model analysis for the report, but let’s look at click-to-call from an architectural perspective.

The simplistic view of this service is that it enables a computer user to initiate a call between his phone and somebody else’s.  But, when viewed from a more abstract viewpoint, the hidden power comes out:

1. Click-to-call allows you to separate the physical address from the logical address.  In other words, it allows you to move from “I want to talk to the sales person Joe” to “I want to talk to a sales person”, and for software to figure out who it should be.  Perhaps Joe is not working today. Maybe Joe isn’t the person the customer talked to last.  Using click to call, you can let software figure out (at the last minute) who you need to talk to, allowing for very interesting use cases.  Even better, this “last minute decision” can be written in any language, and isn’t confined to the difficult implementation world of telephony.
2. Click-to-call takes a synchronous service (making a phone call NOW) and makes it asynchronous – you click it when you want to click it.
3. Click-to-call can add authentication and/or authorization onto a call.  For today’s phone conversations, the only authentication for inbound PSTN calls are what you might do as you look at caller ID, or an IVR that interrupts the call.  With click-to-call, you can add authorization that restricts who and when can make the phone call.
4. Click-to-call carries information that can’t normally be carried in a call.  A really good example of this are click-to-call links on e-commerce pages, where the person who receives the call can also receive complete information about what page the caller clicked from (or where he’s been, or how often he’s called before).
5. Click-to-call adds anonymity to one or both legs of the call. Can you say Match.com?

Well, to the telephony gods, I ask forgiveness.  Sometimes simple is best.

Too often, we seek success using complexity. Today, ifByPhone hits it out of the park with a simple and brilliant voice mashup solution: the ability to integrate direct-response call data with Web-based advertising available using Google Analytics, making it possible to gauge the overall effectiveness of a lead-generation campaign.  Simply put,  from a single view, you can judge the effectiveness of a mixed web and traditional advertising based campaign using Google analytics.  The secret sauce? By using pre-determined phone numbers on advertising, you can track which ad generated the call, allowing the company to optimize their overall marketing campaigns.  ifByPhone allows a company to easily track when a call is made from one of it’s numbers, powering the capability.  It’s simple. It’s brilliant.  And, as I paraphrase Ice Cube, will make ifByPhone so much cheese they’ll have to weigh it.

Where’s money? Here’s the money: less than ten percent of advertising budgets are spent online, and mostly with paid-search. Paid search makes a lot of business sense, and is intrinsically more valuable than other forms of advertising because paid-search advertising deals with self-qualified leads.  People who type in “Toyota Corolla” are probably looking to buy a car.  Random people sitting on a couch watching the “Toyota-thon” commercials tend not to be looking for cars.  Even more so, the people who purchase the automobile advertising are assured that their money is doing something: you can measure online succes by simply counting mouse clicks.  It’s really difficult to measure the response from traditional media outlets, until now.  With a voice mashup approach like ifByPhone’s, you can seriously increase the visibility into the effectiveness of traditional media advertising… where 90% of the market still is, and will be for some time to come.  This ability to easily measure advertising effectiveness is valuable to everybody in the value chain.

And, as I am a one note guy these days, notice that the application has nothing (nothing) do with voice.  The application is advertising, but ifByPhone made it better with voice.  Congratulations, gentlemen. You rock.

Earlier this year, I mentioned to Lee that I thought March was a long time to wait to get together again.  I also had this idea that I could say the same for about fifty other people, people who I only get to see at tradeshows, and then it was in a blurr of talks, meetings and plane trips.  Well, instead of whining about it, Lee and I are doing something about.  On November 12th, we’re hosting a dinner at the SFO Marriott for our friends (and friends to be) to network, catch up and have a drink with the only people in the world who actually know what we do for a living.  It’s not a show, it’s just a dinner, and I’d love for you to attend.  It’s during the same week and location as VoiceCon, so I’d love the chance to catch up with you if you’re in town.  Word has leaked out, and we’ve got about half of the seats full – would love to see you there if you’re around.  Here’s some of the details:

• We’re going dutch at $75 a head
• We have some private space in the hotel, drinks start at 5pm , dinner at 7pm
• No sponsors, booths or advertising – it’s just a dinner to meet and make friends
• The initial attendee list is damn impressive.  I think they’re coming to see Lee.

If you’re interested, drop me a note at my personal e-mail address : ghost of basho AT gmail DAWT com.

That time of year again?  Lee dropped me a note about eComm’s Call for Papers. If you are working in emerging telephony, and you’ve got something to say, why don’t you drop your name in the hat and send off a suggestion?  For three years running, eComm has been the place where the people who carry the knives that create the bleeding edge meet, and it’s on my short list of shows I’ll never miss.  I have heard that there’s a deluge of papers coming in, and my sympathies go out to this year’s advisory board, but don’t let that stop you. Send it in.

What did I love last year?

• Norman Lewis’ talk was just fascinating.  Norman is the past directory of Technical Research for Orange, and has his fingers on the pulse of social networking and generational consumerism.  He’s on the advisory board, so I’m sure he’ll be there.
• Hearing Irv Shapiro introduce the full scope of the IfByPhone offering was exciting for me, and made me wonder if eComm would be the place where that kind of cool stuff would be announced again.
• When people talk about voice mashups, it makes me think about my personal hero : David Troy.  My wife didn’t understand why I was so excited to see his Asterisk and Roomba mashup, but then again, she hasn’t lived her career in an industry where our walls have stood for a hundred years. Love to see David tear them down.  What David said I repeat weekly: our major issue is a lack of imagination.
• I loved Dawn Nafus’ talk about presence.  Dawn is an anthropologist for Intel, and she remarked that the use of presence and status derived from  your instant messaging client was exactly wrong: you display as available when you sit down to work on your computer, which is exactly when you’re not available, because you’re just sitting down to work.  I hope she comes back.

I suppose I should drop my name in the hat as well, but you’ll see me either way – hope I see you too.