Moving On Up

Well, the time has come to move the blog off of Google, and on to our new site at The Thomas Howe Company.  Pat and I will be posting to our blog there, and we're just going to let this one mellow with age.  (I'm going to imagine that, in this allegory, I'm George because I'm shorter than Pat.  Pat can be Weezie.)

See you on the other side.

Brian Mahoney and Jon Arnold Podcast: IPTV

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

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

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)

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

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

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

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:

1. 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.
2. 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.
3. What's a mashup? You can check out the two thousand, two hundred and twenty listed here.
4. 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

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. 

VoIP's Top Techies

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 :

1. Henning - One of the three writers of SIP, currently a Columbia Professor. (Just like Madonna, Sting and Bono, Mr. Schulzrinne needs only one name)
2. 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.
3. Mark Reid - Editor of H.245, big shot at NMS and a perfect technical manager.
4. Brough Turner - Long time CTO of NMS, long time leader, long time VON show dancer.
5. Eric Burger - Interim CTO of BEA, founder of Snowshore and instantly credible in any room.
6. 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.
7. Jeff Bernstein - Founder of 2Wire and PictureTel, really nice, really smart. Really nice, too. God is he smart.
8. Dan Petrie - Independent Consultant and smart guy at PingTel, among the first to "get it"
9. Ed Bassart - Founder of ShoreTel, been at it since the beginning, and deeply smart.

I'm sure there are other's I've missed (I might blog this again). Who's on your list? Give'm some love.

GigaOm says it's time to REST

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

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

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

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

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

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!

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.