Joel Hughes, General Manager for Mobile Applications at NMS, is moderating the second to last session at Connect 2007 entitled "Mashups: Web Meets Telco" with panelists:
Matt Gross, Director of Product Management, WHERE by uLocate Communications -- a GPS-based platform for location aware services. Other value they bring is that they have negotiated deals with several US operators (Alltel and Sprint) and they make these services available to 3rd parties.
Kevin Nethercott, President and COO, LignUp -- talking about their web platform to program PBX functions and do enterprise mashups, specifically mentioning Mashup Camps and applications prototypes done in 15 minutes.
Sam Aparicio, CTO, Angel.com -- an IVR and call center solution that exposes a web API for control. His example application is a mashup with Salesforce.com.
This real time blogging is new for me. Perhaps the resulting notes will only be useful to me... In any event, this is going to be more stream of consciousness...
First impression: there are several sources of telephony controlled by web interfaces, but they all cost money or are just sandboxes. No one has mentioned APIs that let developers also participate in billing, or ways that web telephony can be available at or near free. Surely one or the other is needed to see this industry take off.
For now, all the discussion is about enterprise developers. Mashups are a new way for enterprises to develop their IVR and call center solutions. So far, no examples of developers targeting consumers. Alan has mentioned that BT's API has also been used for Salesforce.com integration.
Sam just alluded to a Verizon API. I'm not sure what he's referring to. I'll try and ask afterward...
Now Alan is discussing cost. When location data cost 25 pence per inquiry, no one used it. No one has a good suggestion of how these kind of services should be priced. What about an application that needs two database dips, an international phone call and two international SMSs? General agreement that this is an issue, but no specific suggestions or pointers to solutions.
The popular APIs to mashup with (besides Salesforce.com) are Google Maps, Flickr, Facebook and Amazon (for storage), at least today.
Now Joel has explicitly asked how things are priced. Amazon is priced by the GByte per month and Salesforce.com is by user per month. Enterprise telecom groups either buy the platform or pay per transaction until they buy the platform. Their issues are reliability and minimizing costs.
Matt Gross describes the value uLocate brings to Sprint is to handle the long tail of developers that Sprint can't deal with directly.
Alan says BT's Web21c has helped expose issues and challenges. They are still experimenting. As far as location goes, the pricing is still too steep. Alan expects that Google and others will note the GPS coordinates of every cell site, retrieve that from the handset and skip interfacing with the operator. Operators will have to price their location info appropriately or they will be bypassed. Consumers do seem willing to pay for safety-related location-based services.
Relation of mashups with IMS. North American operators are adopting IMS to control VoIP telephony, but IMS is just the base for connection control. The broader service delivery platform is less standard and yet that's what's required as the platform that supports web services. SIP-based applications going a lot slower than web APIs. In the end it's applications that matter. No one on this panel cares about IMS except as an underlying layer that supports their web APIs.
A question from the audience: how do you see the handset interfaces w.r.t. mashups. Kevin is focused on voice telephony. He doesn't see the mobile handset as the application UI for now. In the long term, he expects browser-based user interfaces, but for now, he's doing voice. Alan seems to agree. Handsets are so different that all you can rely on is basic voice and SMS. Sam complains that even the so-called open API phones, you can't actually to deep features on the handset. This crew is focused on voice.