VoIP’s Top Techies
Posted on August 8, 2007
Filed Under Contributors | Leave a Comment
As I was having a conversation with a friend, I mentioned that I felt really lucky to have worked with some of the best guys in the business. He asked me who they were, and why, and it triggered something for me. In our industry, as in most, you know the company's names, and maybe you might have heard of the CEOs, but do you ever really hear of the great engineers behind the scenes? No, probably not. So, in honor of the geeks you might not have heard of, here's Tom's list of Gods of VoIP Engineering. The criterion? First, I had to actually work with you(or at least had a meaningful conversation, digital or otherwise) at some point. For instance, Richard Shockey is well known and respected, but I never had a chance to work with him. Rosenberg, too. Yet. Secondly, I tried to pick complete no brainers - practically everybody I know respects these people. Thirdly, my main criterion is that of envy : these are people who's skills I not only admire, but deeply covet. These are the folks who are my teachers, and whom I think are worthy of your respect as well. Sort of my fantasy geek-ball team. If you see one of their resume's cross your desk, jump. Finally, I'm trying to keep the list short, so if your name ISN'T on this list, I reserve the right to amend it at a later date, don't hate me, still love you, all that stuff.
That said, my personal list of geek gods includes :
- Henning - One of the three writers of SIP, currently a Columbia Professor. (Just like Madonna, Sting and Bono, Mr. Schulzrinne needs only one name)
- Doug Tucker - CTO of Ubiquity, and in my opinion, the whole and complete package. He even took Kung Fu back in the day. Gotta love the dangerous geeks.
- Mark Reid - Editor of H.245, big shot at NMS and a perfect technical manager.
- Brough Turner - Long time CTO of NMS, long time leader, long time VON show dancer.
- Eric Burger - Interim CTO of BEA, founder of Snowshore and instantly credible in any room.
- Daniel Biage - CTO of Versatel Networks, old school engineering at it's finest. Go to Quebec to learn how to deeply care about what you do.
- Jeff Bernstein - Founder of 2Wire and PictureTel, really nice, really smart. Really nice, too. God is he smart.
- Dan Petrie - Independent Consultant and smart guy at PingTel, among the first to "get it"
- Ed Bassart - Founder of ShoreTel, been at it since the beginning, and deeply smart.
GigaOm says it’s time to REST
Posted on August 7, 2007
Filed Under Contributors | Leave a Comment
I know that many of my readers are telco guys, so you might not even know the difference between SOAP based web services and REST. I'll make it easier for you... In the parallel universe of SOA, SOAP is like H.323 - big, clunky, slow but complete. REST is like SIP - fast, light, scalable and composable, but incomplete. Anne from GigaOm just wrote a great article declaring a winner, and why.
Technorati Tags: Om Malix, Rest, telco mashups, thomas howe
API of the Week : Amazon Flexible Payments Service
Posted on August 7, 2007
Filed Under Contributors | Leave a Comment
In the "Internet as platform" game, the big gorilla isn't Google - it's Amazon. Amazon announced the private beta of their payment service called Amazon Flexible Payments Service (AFPS), filling out a complete platform for deploying highly scalable, robust and feature complete web applications.
From their site :
Amazon Flexible Payments Service (Amazon FPS) is the first payments service designed from the ground up specifically for developers. The set of web services APIs allows the movement of money between any two entities, humans or computers. It is built on top of Amazon's reliable and scalable payment infrastructure.
Amazon FPS offers developers unmatched flexibility in how they can structure payment instructions, including standing instructions that can remain in place for multiple transactions. These instructions impose conditions and constraints on money movements and can be set by both senders and receivers of funds. For example, a sender might set a spending limit per week for a particular named recipient. Only that named recipient would be able to withdraw funds and only up to an amount per week equal to the spending limit. A piece of FPS functionality called the GateKeeper automatically enforces the constraints you set with payment instructions. When the sender or receiver is a computer system, payment instructions are set programmatically using APIs. FPS also provides a simple set of user interfaces that humans can use. From the users' point of view, they simply see terms of service and a request to accept those terms.
You can use the extensive feature set of Amazon FPS to conduct a wide variety of transactions under virtually any set of constraints. Key features include:
Send and receive money using credit card, bank account or Amazon Payments balance transfer as payment methods.
Create "Payment Instructions" to define conditions and constraints desired for a given transaction, and programmatically obtain payment authorizations or "tokens" that represent these Payment Instructions from customers.
Execute one-time, multiple, or recurring payments on behalf of customers.
Aggregate micro-transactions into a single larger transaction using Prepaid and Postpaid capabilities.
Build payment applications where you are neither the sender nor the recipient of funds. You can build marketplace applications that enable the movement of money between two third parties.
View account balances, transaction histories, and transaction details on the Amazon Payments web site.
Utilize the Amazon FPS sandbox to build and test applications without using real money or incurring any transaction charges.
Technorati Tags: amazon, telco mashups, thomas howe
WITA : Scripting Front End
Posted on August 6, 2007
Filed Under Contributors | Leave a Comment
Let's take a look at each of the three major parts of a Web Integrated Telephony Architecture (WITA) in depth. WITA contains three basic architecture blocks : a voice scripting front end, a Ruby on Rails back end, and a collection of web services to implement telephony applications. Today, I want to talk about the scripting front end.
Summary
The scripting front end provides the user interface for the user. User interfaces may be implemented through traditional web applications or desktop clients, but WITA applications typically use as a primary interface a voice scripting language such as VoiceXML. The VoiceXML script acts exactly as a web site, but instead of filling in forms, you use your voice to fill in forms to be posted to the web site. Instead of reading web pages produced by the site, the VoiceXML script will read the results back to you. VoiceXML scripts can be localized as web pages do, and can speak the native language of the caller. Different views into the application can be rendered to the user by either a voice menu choice (analogous to web site navigation) or through different dial in numbers or SIP addresses (analogous to using different URLs). In general, the scripting front end doesn't provide much in the way of call control, as the telephony features are implemented using the web services back end.
Interfaces
- Interfaces to the user through any telephony device, either from the PSTN to SIP. Can use natural language recognition, DTMF detection, or some combination of both.
- Interfaces to the Web server back end (typically implemented using Ruby on Rails). Fetches VoiceXML forms based on inbound dialing information. Presents data to user as provided by Web server back end. Collects data from user as a form and uses HTTP POST to save on server or to cause some action.
Scaling Concerns
From a human to scripting standpoint, the scripting front end scales linearly with use. You need as many ports of inbound scripting as you have inbound callers. It is unimportant if each of the scripting ports come from a common source, as the scripts have no interaction with each other. Thus, you can use an arbitrarily large number of scripting engines (either hosted or platform) without any architectural impact to the application. Voice is not typically passed from the VoiceXML platform into the larger Internet, so quality of service issues are not typically important at this level. From a scripting to Web server standpoint, common and well known Internet scaling techniques of load balancing, server replication through DNS, etc, are fully available to the system engineer. No additional nor unique requirements are placed on the Web server farm in the WITA architecture.
In terms of business scaling, the WITA front end may be completely functional using a hosted provider (see below) at only a dime or so a minute of use. These hosted providers will be happy to scale with your application, or you can choose to deploy with a platform solution. Platform solutions typically make sense only for large or sensitive installations.
Suppliers
There are many hosted suppliers of voice scripting. My favorite happens to be Voxeo, because they have excellent service, they are well adopted by larger corporations in the US, they are price competitive and I happen to like those guys. There are a few other good choices as well, including BeVocal, TellMe and Angel.com.
For large corporations, there are a number of good options for platform solutions such as Convedia (now Radysis), Snowshore (now Cantata) and Voxeo (another reason I like them). In large measure, VoiceXML scripts are pretty portable, and only small code changes should be required when moving from hosted solutions to platform solutions.
Ruby on Rails Screencasts
Posted on August 3, 2007
Filed Under Contributors | Leave a Comment
If there was a moment for me where the light went on for Telco mashups, it's when I saw the Ruby on Rails Screncasts. They are a bit goofy, but if you actually sit through one, and realize what you are seeing - it's earth shattering. It's earth shattering especially when you realize that the other parts of telephony applications, such as scripting front ends, and web services back ends, have very similar productivity gains associated with them. Just check these out... especially the Flickr screen cast. Be careful that you don't drool.
Technorati Tags: Ruby, telco mashups, thomas howe
Getting Ready for the VON Show
Posted on August 3, 2007
Filed Under Contributors | Leave a Comment
Pat and I had a wonderful surprise yesterday, when Carl Ford and Bill Kelley stopped by for lunch. I'm always talking about how "Brigadoon-ish" I think the VON show is, and it was actually pretty nice to have a friend from the show come to my hometown on Cape Cod for a meeting. I suppose the water view doesn't hurt, either.
As I've said in the past, instead of complaining, I'm committed to helping out at this year's VON show, and as part of that, I'm taking a pretty active role in the "Unconference" potion of VON. More about that later, but as part of that, Carl and I thought that a real cool thing to do was to show the audience, in real time, how much the new web technologies change the game for new services development. Sometimes, you just gotta see it. So, we're going to show you.
I'm planning a two hour session where we are going to develop, from scratch, an WITA (Web Integrated Telephony Architecture) service from scratch, in front of the audience. Three of us are going to work together on each of the major pieces : a scripting front end, a Ruby on Rails framework and a number of web services below us. As we work, we'll work out something were either the developer is explaining it as he goes, or another talks as he works. At the end, it will be an application that not only works, but can scale as high as you want it to - just like a web site.
The application? I like this one : my mother's memory is failing her. I'd like a reminder service that will call her cell phone with a voice message sometime in the future. For instance, you call a phone number, give your Mom's phone number, a voice message, and a time when you want it delivered. Maybe somebody will have another idea that's better, but that's what I got.
For you, if you don't really know how Telco mashups work, or what they look like, or why they are so revolutionary, come and join us. Grab a beer, kick off your shoes, and watch.
Technorati Tags: Carl Ford, telco mashups, thomas howe, VON
Oooma Tech Update
Posted on August 1, 2007
Filed Under Contributors | 1 Comment
Alec Saunders did a fantastic job digging into some of the tech issues in this entry his blog.
Alec, I thought YOU were the marketing guy and I was the engineer. Good job, old man.
An example of a good Ooma feature!
Posted on August 1, 2007
Filed Under Contributors | 1 Comment
I had a pleasant conversation with Ooma CEO Andrew Frame last night. No, really, it was mostly pleasant. Apparently, of my three blog readers, one of them is an Ooma employee. Hey - big shout out. Hollywood in the house.
So, I'm not going to go into too much depth here about our conversation. Andrew promised me my own Ooma box to play with, and I'll give you an honest appraisal of it when it arrives. We couldn't talk long (as my cell phone kept dying), but I frankly didn't hear anything from Andrew that was earth shattering from a business perspective. I hope that Andrew's sudden "I have to go" response to "Tell me why your customer acquisition costs will be substantially less than Vonage's" was about schedule, and not about an uncomfortable question. We've planned to speak again after the box arrives, and I'll tell you how that goes.
No, what I want to mention is a good Ooma feature. According to Andrew, one Ooma feature is that when you are on the phone, if another call comes in, the other phones in the house ring. I love that feature - and I'll tell you why. It's a feature that doesn't require customer education, and doesn't require the customer to change his habits : the two killers of value added services. And, as Andrew rightly states, it works almost by surprise, which might be the best way that consumers learn about their product.
The second reason why I love that feature is because I'm getting excited to see some good engineering. What I mean is, I can't wait to see how they pulled that one off without causing serious head-aches for the installers. Near as I can tell, you need to drive each wired phone in the house independently to pull this off. If you had a multi-line wireless phone driving your house, it would be pretty easy, I suppose, but how many people have that? Typically, don't those Comcast installers cut the main line into the house, and then drive all the phones from their set top box? I don't think most houses have a system where all the wired phones go to the same place in the house, then are bridged together. Andrew told me these guys are the best in the business. I am truly excited to see how good their product is, and how innovative their solutions to problems like this will be.
iPhone Marketing
Posted on July 31, 2007
Filed Under Contributors | Leave a Comment
As I was being a bit lazy (on a conference call), I caught this post from the latest Apple insider. Mike Abramsky, an analyst, details how he believes the iPhone will mature :
Abramsky speculated that upcoming iPhone software updates would include new widgets, peer-to-peer applications (chat, picture messaging, social networking), location-based services, MMS support, home networking, and possibly some integration with Mac OS X Leopard.
"No word however on integration to Microsoft Exchange," he wrote. "It appears to us that Apple, classically, has more pleasant surprises in store for iPhone fans and investors."
After speaking with Joswiak, the analyst also made changes to his predictions for future iPhone models. Although he spoke of "higher resolution" iPhones earlier this month, Abramsky now says he expects Apple to differentiate its iPhone lineup not by features, but by price and memory capacity. The move, he explained, would be similar to how the company grew its iPod lineup, simplifying market positioning.
"This affirms our view of a lower priced ($349-399) iPhone [in the fourth calendar quarter of 2007 or first calendar quarter of 2008], with a higher priced version at higher capacity, to expand its market opportunity," the analyst wrote.
I personally find this fascinating, as Apple plans to differentiate the iPhone not by features, but by price and performance. If you recall, for most of era of competitive phone service, market success was found only through variations in price, as the basic service was essentially feature complete, and value added services had benefits which were only marginally valuable. Could it be that Apple has already caught on to what took telecom 100 years to understand?
WITA : An Architecture Standard for Telco Mashups
Posted on July 30, 2007
Filed Under Contributors | Leave a Comment
One big difference between the Web world and the telecom world are standards. I don't mean that they use different standards (although they do), they have a different approach the standards entirely. Other than the two worlds of standards represented by the Telco and Web world, there's a third sort of standard - an implementation standard. A "this is how we tend to do this sort of stuff" standard. For instance, there's really no one PSTN standard - it's just how we have put together many other standards to make something that works. We need to establish a standard for Telco Mashups; a set of conventions as to how we tend to write these applications. Since I've been at this, I've noticed a standard pattern I'll call the Web Integrated Telco Architecture - WITA. From where I sit, the an application written to the WITA standard is more scalable, more reliable and easier to write than anything else I have seen put forward for telephony enabled services. As I put together my telco mashup applications, and see companies like Gaboogie and Twitter do the same, I see that we all use approximately the same approach. If we can standardize it, give it a name, we can build the community quicker.
- Voice XML: WITA uses VXML to handle inbound interactions with human beings, and most outbound voice messaging applications use VoiceXML to make those messages rich an interesting. The VXML scripts are delivered by a web services application, and post the inputs the collect to a web services application.
- Ruby on Rails : WITA uses Ruby on Rails to implement the web services application. It's responsible for putting the logic on top of the database, and for rendering views to the user in the form of VxML scripts, Web Services APIs and graphically intensive web pages.
- Telco Web Services : WITA uses telco web services to deliver telephony features such as outbound messaging, conference calling, click to dial and SMS messaging. These web services are called from the Ruby on Rails frame work, and provide the scaling and reliability components of the architecture.