Tim Panton is a font of knowledge and experience in real-time communications.  We’re really excited he will be joining TADHack.

Tim  is a futurist with a strong pragmatic instinct.  He takes new technologies and combines them to create something that meets an unmet need.  He does this by extensive prototyping and experimentation to see if a thing works and is desirable.

Tim is currently looking at how to apply web technology, thinking and metrics to the entrenched voice communications market (aka the telephone).

He has a bright red rotary dial phone on his desk to remind him how little things have improved in 100 years.  Tim alternates between running startups and consulting for larger companies. He’s currently in a consulting phase with Westhawk.

Past projects have included training simulation for oil platforms, time management of a space telescope and running a mobile phone network at the Burning Man festival.  You can find his blog at babyis60.wordpress.com or follow him on twitter as steely_glint.

What are some of your current and past telecom app development projects?

Currently, I’m consulting on webRTC to a few _exciting_ companies and doing some open source efforts in that area (contributing to phono/asterisk etc). Whilst tinkering with a few of my own ideas.

I’m contributing to the standardization efforts at the IETF for webRTC and trying to get an RFC for “Connecting Mobile Phones to the Internet Simply (CoMPIS)”.

Recent past projects included Phono and Tropo where I worked on APIs that expose telephony to web developers.

How did you get involved in Telecom App Development?

I came in through internet security web development – A customer needed a single purpose app that issued one-time passwords over a number of channels – one of which was telephony. This was 1996/7!

We used SunXTL then Dialogic GlobalCall – I built a cross platform API that supported them both.  It had primitives that look very like what Tropo has today, Dial, Hangup, Digit, Play etc.

We needed that API to be able to adjust to customer requirements quickly without having to dig down into the nuts and bolts each time. (XTL did DTMF recognition in software with a FFT 🙂 )  Also one of the roles of the API was to shift from an event based environment to a procedural one “if this then that”.

More recently Tropo’s Ameche API – which came out of a idea I described at Astricon – addresses that problem in an interesting way – leverageing new ideas from nodeJS.

Basically TADHack and APIs in general allow developers to focus on the customer’s goals and not get distracted by the rude mecanics of telephony.

I judged a UC competition recently – and I loved the fact that many of the entries are laser focused on the customer’s goal, which is rarely ‘I want to make a video call’ – more likely “I want to close this sale”, or “learn about scala” or “find a girlfriend”. Good APIs allow a wider development community to leverage communications to the customers benefit.

What are you hoping to get out of TADHack?

I’m looking forward to TADHack,  it will give me an excuse to build a system that  meets a specific user need, whilst having fun and experimenting with new ideas and APIs. All the while hanging out with the smartest people in the business.