Great to see that the Inova boys finally have a website up and running. They are a great bunch of guys to work and hang out with, and have that rare ability to execute as well as innovate. Hopefully having a web presence will mean more people get to see what they can do.
They have some very cool things in the works - Calendar2Conference in particular has been generating plenty of buzz, and rightly so. Looking forward to the trial guys!
It’s taken almost five months. but we are finally making tangible inroads in our quest to open-source Aloha, the stuff under the hood of Web21C SDK voice services (including CallFlow).
As Rags and Robbie wrote recently, Aloha is now out there. Whilst we are continuing to push for an OSI approved licence, we are thrilled to be able to share wihat we believe to be a unique tool for developing SIP-based voice applications.
Since this is the first mention of Aloha here, a brief introduction is in order. Essentially, Aloha is several things - a lightweight SIP application server, a set of high level call contol APIs, and a pluggable framework for media server support (currently Convedia / Radisys via MSML, we would love to add Freeswitch).
Aloha has everything SIP application servers don’t: tiny footprint (only a few megs), an intuitive programming model, non-intrusive and flexible integration with apps, and ability to scale down as well as up.
The special sauce that makes this possible has several key ingredients.
Firstly, Spring is the container of choice, keeping things lightweight and affording flexibility required to create nice APIs, with most of the benefits - but without the complexity - of a servlet-based programming model. This also makes it trivial to integrate Aloha with almost any Java app, and extend almost any part of it - media server drivers or persistence mechanisms, for instance.
Secondly, NIST’s reference implementation of the JAIN-SIP API has been invaluable in our drive to simplify and hide some of the gory bits of SIP. Aloha uses it for all of its SIP message and transaction handling, although we found it necessary to rewrite the dialog handling layer as NIST-SIP keeps this in memory.
Thirdly, an impromptu encounter with a passage from Fowler’s Patterns of Enterprise Application Architecture led me to question the orthodoxy of having to use heavyweight containers and pessimistic concurrency handling for SIP. Something that is basically near-real-time asynchronous messaging, where most (but not all) messages flow sequentially within a given context (a dialog, a call, a conference) would surely lend itself to an optimistic concurrency handling scheme? We tried it, we bashed it - and it worked really well, getting only a tiny fraction of concurrent update conflicts even when pumping many messages per second through the server.
Finally, and most importantly, it’s been a privilege to work with several top-notch engineers and incredibly supportive and protective management in making Aloha real. Yes, folks, it does happen.
So - what started life as a lightweight testing tool and a spike on getting Terracotta working with SIP a little over a year ago, currently manages many thousands of calls a day in production, with ability to scale and without astronomical licence fees.
If you have any interest at all in developing voice apps, please do give Aloha a whirl.
Whilst writing about CallFlow being XML that describes voice interactions, I sensed dissent at the back. ‘But what about VoiceXML and CCXML? Why do we need another XML language for voice?’
Well. I have nothing against either, they have wide adoption and some excellent products built around them, that almost interoperate.
CallFlow solves a different problem though - one of simplifying the creation and integration of voice interactions for people who have a real problem to solve in their domain, and want to spice up their application in a non-intrusive way. They want convergence, Web 2.0-style.
We have ditched the baggage of trying to create a ‘voice browser’ language - although CallFlow happens to be suited to that task too - and feel much leaner for it. On its own, voice is a very poor medium for browsing lots of information. Imagine looking at a webpage through a tiny hole that lets you see at most a few words at a time. It is useful in the absence of a better way, but it’s hard work, and can test the patience of a saint.
Our other big gripe is the amount of business logic VXML and CCXML platforms can swallow - they can be used as both declarative and imperative languages, and often that’s what people do. More than that, it is not uncommon for entire applications to be hopelessly and perpetually tied to some mega-buck IVR platform Usually this is unnecessary, and bad news for your CFO.
Is there anything you can do in CallFlow that you can’t do with VXML / CCXML? Probably not very much. Vendor support will ensure that VXML and CCXML are here to stay - but, to paraphrase Steve Jobs, they just have no taste.
A seriously funky new interactive voice service went into Beta yesterday.
It’s called CallFlow.
Ok so I’m hopelessly biased, but you probably knew that already. So here’s a bias-tainted version of why I think it’s exciting.We wanted to design and built a way of adding voice interactions to applications, without the need to disappear off to Telco School for a semester or two.
Add voice interactions to their application. Not build interactive voice applications. Not add their applications to an interactive voice system.
Add voice interactions to their application.
That’s where we started, and it lead us to all sorts of weird and wonderful places.
Simplicity and accessibility were obviously going to be key.
And functional scalability - no more listener code spaghetti, Giuseppe.
And letting people write application logic the way they want to, where they want to, using tools they like.
And - goes without saying - secure interactions between service and application - this is still work in progress, but hey it’s a Beta.
And mashup-friendliness, and simple APIs mappable to the uniform one we know and (mostly) love.
And, last but certainly not least, we wanted to be able to nest dynamic, server generated callflows, driven by run-time data.
And that’s just for starters.
We toyed with a number of different programming models for describing voice interactions, but a very simple and very flexible one emerged almost immediately - bits of XML with names like ‘call’, ‘prompt’ and ‘audio’ (no telco acronym in sight), chained together to create ‘callflows’. Like this:
<call id=”start” target=”tel:44567890123″ next=”hi”/>
<announcement id=”hi” audio=”welcome.wav” next=”select_option”/>
<prompt id=”select_option” audio=”connect_prompt.wav”>
<input pattern=”1″ next=”connect”/>
<default next=”select_option”/>
</prompt>
<dialog id=”connect” target=”sip:me@mydomain.com”/>
Among other things, this is a big step forward toward disposable comms applications, a concept we’ve had in mind for a long time, and which Ivelin described very nicely indeed. One last hurdle remains, and we’ve already started our run-up…
Hear me now.
Give it up for Mobile Mash - The Movie - a re-enactment of the Mashing Up The Mobile talk Paul and I gave at WWW2007.
Directed by Tim ‘T3′ Stokes, who did an amazing job of making our Monday morning ramblings sound vaguely coherent.
Enjoy.
What a privilege it was to have lunch with Doc in the company of Paul and Gary ‘the Albatross’ Casey earlier today.
We talked about some of the predictable topics - identity (we want more of it…!! and less!!), convergence, the web. We also talked about fencing. I’m taking home plenty of mental notes to throw at Google and Wikipedia.
Great to hear of the ongoing work on VRM. I’ve found Doc’s ideas about the Intention Economy interesting and relevant to the work I’m currently doing. Hungry Offers scratches the surface, there’s plenty more to come.
Furthermore, our discussion implicitly validated group + subscription based features we want to add to webdogandbone.
What is clear is that convergence is beginning to happen, but not where telcos envisaged it would. It will, I believe, continue to happen on the edge, not in the network, and will be driven by technologies that live on the edge.
Doc left us with a fascinating set of anecdotes about how organisations - including the likes of Microsoft, Apple and Walmart - have DNA that to a large extent defines their identity and culture long after their founders and creators are gone. Like the real thing, this DNA forms the very essence of the entity. Although environmental factors mean continuous change, controlled change is difficult.
Doc is scheduled to have dinner with JP and Martin. Blessed are the flies, for they get to sit on walls and listen…
Slides from the WWW2007 Developers’ Track talk Paul and I gave in Banff.
The slides. although up to Paul’s usual top-class standard, only tell part of the story - the narrative, animation and our WebDogAndBone demo app are pretty much an essential accompaniment. We hope to be able to post a video soon.
In the meantime, here’s our ‘Web guy vs. Telco guy’, ‘Budget-Bill-and-Ted’ routine:
<cue ‘convergence vs. collision’ slide>
Time I dived into the blogoshpere.
My reasons?
I hope to learn through sharing ideas. I hope to get better at articulating ideas. And occasionally, just occasionally, post something that others find interesting or useful.
That’s about it. Expect various musings on software engineering, communications, that elusive convergence thing (or should that be ‘collision’?), the web, and so forth.
Let the serendipity (web-style) begin.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
