VoIPMashups.com

Lypp announces API- ready for Mashups

patrick — Tue, 23 Oct 2007 18:53:46 +0000

The folks at Lypp formerly Gaboogie have introduced an API for their telephony service. With this API, you can create conferences on the fly for your mashup. An initial review of the API is impressive. It’s the first true REST style API for VoIP deployment that we’ve seen. Erik Lagerway,founder of Lypp, is recognized as one of the most creative minds in next generation telephony so it will be interesting to watch his company’s progress. Great technologists, a real revenue model, and a bit of investment money can certainly be combined to make a terrific business.

As we have stated over and over, we believe these API’s will be identified by enterprises within specific vertical industries ( or by device!) as the most logical and relevant tools for an industry. So, our advice to any API provider is to quickly find ways to get deeply integrated within a couple of industries. In time, there will be many conference calling APIS. Will Lypp be the conference calling API for the Blackberry community? Will this allow Lypp to then get integrated deeply into the financial services industry?

Regardless, Lypp has made a great start.

Evoca- an API for telephony mashups

patrick — Tue, 09 Oct 2007 20:18:56 +0000

To all of you web developers take a look at EVOCA
This API could become the equivalent of a map, calendar, or paypal api for web developers.

I love their tag line, “Get a Phone for Your Website!” Evoca allows website visitors or any community of people to create and manage audio files quickly, simply, and inexpensively.

The concept of bringing communities of people into a branding or campaign experience simply through the use of a cell phone or any phone is a great one.

It will be fascinating to see what verticals of websites becomes the first to adopt this tool. My own favorite idea is that the Evoca API should be added to every local restaurant or shop’s website. Any local business owner interested in improving customer feedback should insist on it. As compared to an instore suggestion box or survey card passed out by a waitress, this is a much better mousetrap.

Brian Mahoney and Jon Arnold Podcast: IPTV

Thomas Howe — Wed, 22 Aug 2007 10:45:00 +0000

When you have a chance, check out Jon and Brian's Podcast on PulverMedia. If you are basically unfamiliar with the IPTV market, this is an excellent introduction by one of the best marketing guys out there. Brian and I worked together at Netcentrex, and now he is the Vice President of Marketing for Espial, a leading vendor of IPTV middle-ware that recently went public. I think my days of PictureTel cured me of video, so I'm not sure I'm moving into IPTV anytime soon, but if you want to see good business cases for small, niched applications and programming, I think the IPTV market has them in spades.

Ruby and The Role of Culture in Development

Thomas Howe — Tue, 21 Aug 2007 12:20:00 +0000

In the Web Integrated Telephony Architecture, I identified the middle piece as being a Ruby on Rails application. It accepts data from the User Interface (commonly implemented as Voice XML forms), and then drives action through Web Services, and for WITA, telephony web services. As I thought about this component, there are actually a number of technology choices. This could certainly be a Java component, as the functionality would be equivalent. You could argue about speed (as Java does run faster), and you could argue about installed base (Java is much more prevalent in the carrier and enterprise). Each is fair, each has technical advantages over Ruby.

The reason why I advocate Ruby is straightforward : it's what the cutting edge Web developers use. When I coined the term WITA, I wanted to emphasize that this was a Web integrated architecture - not an IP integrated architecture. By integration, I mean integration of culture - the way that the community approaches, understands and tackles problems. In order for telephony to spiral into the much larger market of the Web, and therefore into the Enterprise, it needs to be introduced into the culture of Web development. Ruby is the prime ambassador for this, especially on the cutting edge of development.

This will, undoubtedly, cause major headaches for telecom engineers, who by-and-large have no experience with Ruby. (Maybe this is the Karmic payback, as the Ruby developers have no experience with phones). However, when the Web mindset is adopted and understood, then Ruby becomes a natural language for its implementation and development. In time, it may become the lingua franca of Web development; certainly Web development over time will become the definition of programming and architecture. The successful implementation of WITA applications will require the adoption of this mindset. Personally, I have pushed myself down the Ruby road primarily for culture - so that I can learn Web development in it's native tongue.

I feel there is no point where this is clearer to me than when I consider IMS. As an architecture, IMS is clearly the son of the companies that advocate it: big vendors making big equipment for big carriers with big budgets. It is a product of the culture of carrier based telecom development. The essential issue is that IMS, although making claims to enable the deployment of innovative services, makes the implementation of new applications nearly impossible because of culture. It is unreasonable to think that development of high value, niche applications is served by ever larger architectures. It is implausible to think that, with a ratio of nearly ten Web developers to one telecom developer, that the web developers will toss Ruby for P-SCSFs and HLRs. I recall a conversation with Henry Sinnreich a few years ago, where he said that he loved SBCs, as they hastened the demise of carriers because they were wasting their money purchasing them, instead of deploying pure SIP networks. I wonder if IMS has sent him into some sort of Nirvana.

Ruby is about culture. WITA is about deploying telephony architectures where that culture rules.

The Depressing Mashup of the Week

Thomas Howe — Mon, 20 Aug 2007 19:26:00 +0000

Apparently, the one thing you don't want to be in LA is a male Hispanic on Sunday. Avoid that, if you can. Especially if there's a gun around.

I love my hometown on Cape Cod, and (I can't believe I'm saying this) when I see things like this, I wish it could hold more people.

Mashup Competitions (or Telephony Finds it’s Tail)

Thomas Howe — Mon, 20 Aug 2007 13:04:00 +0000

Well, the ten thousand dollar VoxBone competition is now over, and Oigaa from VozTelecom took first prize. Oigaa is a web based telephony service targeted towards small and medium businesses, much like Flat Planet Phone Company. My congratulations go out to them; it is an example of a service that simply could not have existed five years ago. I was considering entering the VoxBone contest, but I know I have the greatest success in my projects when they come from the heart. Personally, I like VoxBone's API for allocating PSTN numbers I can forward anywhere, but every unique and commercially useful idea I had was a bit purient. My Mom might read my blog one day, and I don't think I ought to get myself in that situation. Damn - maybe I just did.

As I'll reveal soon, the mashup contest fad is coming to our neck of the woods too. Have you ever stopped to ask why there are mashup competitions, but not VoIP design competitions? Sure, on the trade show floor they have some "best of shows", but we all know how that game is played. You don't see designs done just for competition in telecom, but you do in the Web / Mashup world. As an example, the 2006 Mashup camp mashup I liked was the blinking Google pin. Some geek took a blinker pin from the Google booth at a trade show, attached it to the serial port of his laptop, used the Google Mail API to check for mail, then it blinks the "G" when new mail arrives. So geeky. But why compete with mashups?

The knee jerk answer is: because you can. Mashups are pretty simple to put together, but more so, you can do pretty creative and impressive things with them. Mashups are more about imagination than shear technological prowess. Designing even the simplest of VoIP devices (say a phone) requires an impressive amount of time and money, much more than the typical engineer can afford. (Never mind skill set.) More so, designing even the simplest of VoIP devices for a competition is more than most companies wish to spend in time and money. Therefore, the marketing kick or product risk doesn't make sense for traditional services, but not so for mashups.

The business answer is: because every Internet technology has a long tail. Amazon proves that products have a long tail. iTunes proves that music has a long tail. EBay proves that junk has a long tail. Mashups prove that Web services have long tails. Telco Mashups prove that telephony services have long tails. And that's stunning, because it means that we finally have an environment in which we can create new services. After all our efforts since the divestiture, it comes down to the simple fact that single greatest reason that new services often fail is not because people don't want them, but they were too expensive to develop and deploy for the masses. When they are inexpensive enough so that you can make one just for yourself, then people develop them just for themselves, or rather, just for mashup competitions. Just like iPTV, if you can make a video in your house that ten thousand people want to see, it makes complete sense to make it. NBC needs what, a million viewers to break even? If you have ten thousand people who will pay ten bucks a month for your find-me-based-on-my-facebook-whatever service, you and your two technicians will make a living. In the grand scheme, a good one too. Mashup competitions are, for me, prima facie evidence that Telephony has finally found its tail.

Technorati Tags: Oigaa, telco mashups, thomas howe

Thank you for some serious link-love

Thomas Howe — Wed, 15 Aug 2007 16:52:00 +0000

Wow - thanks to all of you out there for some serious link love: Ken Camp's Post, Jon Arnold's Post, Solomon Ige's Post, and Phone Boy's. As I told Ken, I sometimes feel like I'm designing in a cave, and never really know if anyone else cares. I absolutely love what I do for a living (and I know some of my clients are hoping I'm going to say that I would do it for free), but it's a pleasure to see someone else cares, too. Thanks.

What's even better, though, is that these bloggers have readers, and at least some of those readers are just like me : telephony guys trying to create cool things that people will use. Each of these guys recognizes that telephony engineers have a new tool in the box : mashups. And hopefully, because of this sort of light weight programming model (I call it the anti-IMS), the wider world of engineers have a new tool in THEIR box : telephony. Telephony was once heavy weight, now it's light weight. Telephony used to be capital intensive, now it's pay-as-you-go. Telephony integration used to mean that enterprises would buy telephony equipment and integrate it, now enterprises can integrate with hosted, online solutions. Telephony mashups provide the right sort of light weight programming models that finally lower the barrier to integrating telephony with applications that will allow all engineers, not just us deep telephony geeks, to include telephony in the application.

Sure, there are a bunch of tools in our tool box, but for me, mashups are a keeper.

Fall VON Innovator’s Track

Thomas Howe — Wed, 15 Aug 2007 15:49:00 +0000

Well, now that the programmable web ball is rolling, we're getting ready for the tradeshow season. A big part of that for us is going to be in our hometown at this year's Fall VON in Boston (Wait a second. Does that mean we have to buy the beer?) Carl Ford, a pretty impressive bunch of telephony guys and I have been working on a new addition to the VON show floor : the innovator's track. The innovator's track is roughly based on an unconference, and is focused on cutting edge telephony innovations. Our basic model is to have eight sessions, and we're sort of looking at the following topics :

Rapid Apps on Rails:
A discussion about the impact of Ruby on Rails, Ajax and other tools that aid the developer in building new services rapidly and how combined with Amazon and Level services represent a new era in service deployments.

Enterprise 2.X
This is a discussion that looks at how the Enterprises are finally gaining the ability to provide services across a network and how it changes service models.

Social Networking
According to Cisco its working. Social networks are eating up the bandwidth and the Internet is again growing. What makes these services compelling and who is going to gain from these changes.

The New Age of Communication
We have talked about the concept of these new services now lets look at some of them and lets talk about why this is the perfect time to
offer services in the marketplace. Is the price of rollout so low that adoption can be small and niche, or do we all need massive viral adoption?

New Services with old lines
Single Number is thing of the past, now we have disposable numbers and with the ILECs having to watch the Cable companies expand into their space the time may be ripe for these kind of services. Best of all by extracting the person from the number the service is much more intriquing.

As you might notice, there's only five topics here. That's where you come in. Not only are we looking for audience participation during these five sessions, but we need to hear what you want hear at the show. Do you have an idea for a topic that's not here? What problem are you trying to solve? Something you really need to learn? Spit it here, and we'll talk about it there. Bring your two feet with you, participate, and let's make this worth more than our time.

The Thomas Howe Company Now In Partnership with Programmable Web

Thomas Howe — Tue, 14 Aug 2007 13:07:00 +0000

Well, the day is here - today we announce our partnership with ProgrammableWeb, the leading go-to place for mashup developers. I met John Musser at the O'Reilly Web 2.0 show this March, and we've become fast friends and partners. John's site is invaluable to everyone in the mashup community, and all of us at the office are flattered and excited to be part of that family. We see our position in the market as ambassadors of telephony to the larger Web community, and as ambassadors of the Web world into the telephony market. ProgrammableWeb is the capital for mashup developers, and now telephony has established an embassy.

If you haven't visited ProgrammableWeb (which is to say, you haven't written a mashup or web services based application), here's some places you ought to look at real quick:

Let's say you want to see what APIs are out there to write your application with. Here's a list of all of them.
Sure there are five hundred APIs, but which are the popular ones? Here's a great twist - mouse over the matrix, so you can drill down and see all the advertising mashups written using the Google AdWords API.
What's a mashup? You can check out the two thousand, two hundred and twenty listed here.
Do you think mashups are simply cool sites that have no business value? Check out the markets section of the site for another opinion. That's where we live, next to shopping and mapping.

So, take a spin and check out the site: you'll be amazed at how much momentum this market has already. If you haven't seen it, I attached the press release below:

THOMAS HOWE COMPANY NOW IN PARTNERSHIP WITH PROGRAMMABLEWEB
Award-winning consulting firm and application developer shares business communications solutions with ProgrammableWeb's online mashup community

W. BARNSTABLE, Mass., and SEATTLE - Aug. 14, 2007 - The Thomas Howe Company, a leading designer and developer of interactive voice and data solutions for businesses, has been named as a premium content partner for ProgrammableWeb, the leading web site for mashups, APIs (application programming interfaces) and the new "Web as Platform" approach to site development.

As a content partner, The Thomas Howe Company is providing expertise in the form of communications mashups, original articles and other materials that are posted in a new channel of ProgrammableWeb.com under the "Mobile/Telephony" section. The content will focus on telephony and mobile web services, APIs and mashups.

"Thomas Howe and team have an entrepreneur's knack for hunting down business-oriented APIs and an engineer's skill for putting them together," said John Musser, founder of ProgrammableWeb.

Howe was the first-place winner of the recent telephony mashup contest sponsored by O'Reilly Media and data-services provider StrikeIron. His entry, "After Hours Doctor's Office," transcribes office voicemails left by patients for doctors into text and then sends them via SMS to the doctor. A case study of this mashup is one of the items posted in the new section of ProgrammableWeb.

"At The Thomas Howe Company, we're interested in building real-time communications systems that help our clients save money while also increasing the quality of service for their customers," said Howe. "I hope that by sharing the information we have found useful, along with details of our own experiences, it will drive further creative thinking within the growing mashup community."

To view content from The Thomas Howe Company on ProgrammableWeb, visit www.programmableweb.com/telephony.

API of the Week : DBpedia API

Thomas Howe — Fri, 10 Aug 2007 13:52:00 +0000

If you were to ask me, I would say the twenty year old software engineer has a distinct advantage over the older telephone guys (such as me) in the realm of innovation. Since the barriers to entry to deploying a service provider have fallen through the floor, the larger challenge is not in complex engineering, but is instead in innovation. The younger engineers are free of the legacy of the PSTN, and many things would occur to an experienced engineer won't to them, and it's not a bad thing.

For the benefit of everyone who actually remembers when Carter was president, I bring you the API of the week : DBPedia. It's not in any way a telephony API, and that's my point. A large number of innovative applications that use telephony will include APIs that have NOTHING to do with telephony. The DBPedia API is an effort to put a Web Services API on top of the Internet's encylopedia. With it, you can query Wikipedia from your application for structured answers such as "Tell me all of the authors born in Canada during 1954". Essentially, it allows you to access all of Wikipedia's 1.6 million articles from your application, whatever that application might be. You can learn more about it on the their site.

What does this have to do with telephony? Nothing. What does this have to do with next generation applications? Everything. Applications that use the Internet as the platform use APIs from a large number of sources, and by and large, these APIs are not telephony. However, nearly every time a telephony API is used, an API such as GoogleMaps, Amazon SQS or DBPedia will be used right alongside it. As a developer in this market, it makes a lot of sense for you to get to know your neighbors for two reasons. First, the more you can make your API play well with others, the faster the adoption of it will be. Secondly, the more you can understand your customers, their problems and how they need your part for their solution, the better you can make your API for them. I'm supposing this means that you need to get familiar with APIs like this.

Which leads me back to my original statement. The twenty-something-don't-know-or-care-about-SS7 engineer will sit down and design their version of the hot-or-not site one day, and use a whole bunch of crazy APIs to put together the application. Then, they will go have a beer, come back, and say "You know, it would be really cool if you could just call the person you want to hook up with. Is there an API for that?" They won't even consider for a minute the words "termination", "LATA" or "CALEA". They're just writing an application. They need an API for some function, and it will take a few minutes to integrate it into their application. And, there are many, many more of these guys than all the telecom engineers that have ever, and will ever, exist.

So, I bring you the DBPedia API, as an example of the hundreds of APIs that will live in the same neighborhood as the Telecom APIs. Go check it out; let your imagination run. And one day, when a web guy surfs for a telecom API, I hope it's your API they choose.