Subtitle: Failure of the mighty Intel, growth of Asterisk as a telephony application development environment - and Neapolitan ice cream!!
Hey, this is my first blog entry on TMCnet, and I'm here in LA for the IT Expo West show and conference.
I'm reminded of being here at this same venue (the LA Convention Center) eight years ago, at the turn of the millenium, for another industry event called CT Expo.
Do you remember CT Expo? Do you remember what was going on in our industry at that time?
Intel had purchased Dialogic and were pushing (hard) a new standard CT application design framework deigned by the ECTF (Enterprise Computer Telephony Forum).
The idea was that instead of writing your CT applications to the proprietary API of whichever CT card vendor you were using at the time, you could now write your application to a standard API called (remember???) S.100.
The benefits? Vendor independence was the cry... Use the best of breed hardware for each deployment scenario.
Before I move on to a Neapolitan ice cream-based analogy to explain the ECTF framework, let's just take a moment to examine what was going on...
Intel, by any measure a large and powerful company, was pushing (with all their marketing machinery and dollars) a model where you wrote an application at a very high level and some magic middleware then implemented your application onto the CT hardware you had chosen by using a driver supplied by that hardware vendor. The whole idea was that you did not have to worry about understanding how the CT hardware worked (or how to drive it via the vendor's API) because your application was above the middleware.
So to my Neapolitan ice cream analogy... you write a 'vanilla' S.100 application at the very top level, and some sweet (strawberry) middleware, in the Intel-Dialogic case CT Media, then enables your application to run the hardware of your choice by working through a rich (chocolatey) layer called the Service Provider Interface - this layer is provided by CT hardware vendor to enable the middleware to properly work with their hardware. See the diagram below, which shows the layers of the framework - riding atop an Aculab Prosody PCI card (a true classic of the CT genre):
Around the same time as Intel were flexing their muscles (and trying to push people who had been writing to the Dialogic API for years into writing S.100 applications on top of CT media) Mark Spencer was working on Asterisk - an open source project that created a telephony engine within a PC.
Intel (and Aculab, and others who were implementing this framework) were finding that very few people in real-life really wanted or needed the vendor-independence that this middleware scenario enabled. They also found that those who did want vendor independence had already created their own middleware to do the job.
All of the Intel pushing, history reveals, came to nothing!
Asterisk, on the other hand, grew exponentially as a result of it being an open source project - and CT hardware vendors looked from the sidelines wondering what all the fuss was about.
Soon all the CT hardware companies began to see the momentum Asterisk had build up (while their own HMP offerings were still in development or beta, but that's another story) and contacted Digium (Mark Spencer's company) to see how they could write a software layer to enable their CT cards to be used under Asterisk.
You can see where I'm going with this - right?
Here we are in 2008, and if you want to create a 'vanilla' telephony application, your language of choice is surely the language of the Asterisk dialplan.
A quick comparisson, based on a conferencing application, will show why:
Old days - buy expensive CT hardware, learn the proprietary API, spend a lot of man months writing thousands of lines of code
Today - download Asterisk (for free), add one (YES, 1!) line to the dialplan to add a MeetMe conference, and you're done
If you want to connect Asterisk to the outside world using a telephony card, there is a vast array of choices - top of the pile is Digium (obviously) followed by lots of other...
Do you need to know how any of the cards work? NO
Do you need to learn the API for the card? NO
Have lots of hardware vendors created a 'channel driver' to enable their cards to work with Asterisk? YES
Why, because Asterisk is now the middleware of choice - check out this revised Neapolitan ice cream diagram to see why:
So - Intel pushed, and they failed.
Mark Spencer created Asterisk, and through being pulled by users and open source developers, it has come into position as the 'go to' telephony application development environment of choice for those commencing appropriate projects.
Vendor independence? Continue Reading...
Hey, this is my first blog entry on TMCnet, and I'm here in LA for the IT Expo West show and conference.
I'm reminded of being here at this same venue (the LA Convention Center) eight years ago, at the turn of the millenium, for another industry event called CT Expo.
Do you remember CT Expo? Do you remember what was going on in our industry at that time?
Intel had purchased Dialogic and were pushing (hard) a new standard CT application design framework deigned by the ECTF (Enterprise Computer Telephony Forum).
The idea was that instead of writing your CT applications to the proprietary API of whichever CT card vendor you were using at the time, you could now write your application to a standard API called (remember???) S.100.
The benefits? Vendor independence was the cry... Use the best of breed hardware for each deployment scenario.
Before I move on to a Neapolitan ice cream-based analogy to explain the ECTF framework, let's just take a moment to examine what was going on...
Intel, by any measure a large and powerful company, was pushing (with all their marketing machinery and dollars) a model where you wrote an application at a very high level and some magic middleware then implemented your application onto the CT hardware you had chosen by using a driver supplied by that hardware vendor. The whole idea was that you did not have to worry about understanding how the CT hardware worked (or how to drive it via the vendor's API) because your application was above the middleware.
So to my Neapolitan ice cream analogy... you write a 'vanilla' S.100 application at the very top level, and some sweet (strawberry) middleware, in the Intel-Dialogic case CT Media, then enables your application to run the hardware of your choice by working through a rich (chocolatey) layer called the Service Provider Interface - this layer is provided by CT hardware vendor to enable the middleware to properly work with their hardware. See the diagram below, which shows the layers of the framework - riding atop an Aculab Prosody PCI card (a true classic of the CT genre):
Around the same time as Intel were flexing their muscles (and trying to push people who had been writing to the Dialogic API for years into writing S.100 applications on top of CT media) Mark Spencer was working on Asterisk - an open source project that created a telephony engine within a PC.
Intel (and Aculab, and others who were implementing this framework) were finding that very few people in real-life really wanted or needed the vendor-independence that this middleware scenario enabled. They also found that those who did want vendor independence had already created their own middleware to do the job.
All of the Intel pushing, history reveals, came to nothing!
Asterisk, on the other hand, grew exponentially as a result of it being an open source project - and CT hardware vendors looked from the sidelines wondering what all the fuss was about.
Soon all the CT hardware companies began to see the momentum Asterisk had build up (while their own HMP offerings were still in development or beta, but that's another story) and contacted Digium (Mark Spencer's company) to see how they could write a software layer to enable their CT cards to be used under Asterisk.
You can see where I'm going with this - right?
Here we are in 2008, and if you want to create a 'vanilla' telephony application, your language of choice is surely the language of the Asterisk dialplan.
A quick comparisson, based on a conferencing application, will show why:
Old days - buy expensive CT hardware, learn the proprietary API, spend a lot of man months writing thousands of lines of code
Today - download Asterisk (for free), add one (YES, 1!) line to the dialplan to add a MeetMe conference, and you're done
If you want to connect Asterisk to the outside world using a telephony card, there is a vast array of choices - top of the pile is Digium (obviously) followed by lots of other...
Do you need to know how any of the cards work? NO
Do you need to learn the API for the card? NO
Have lots of hardware vendors created a 'channel driver' to enable their cards to work with Asterisk? YES
Why, because Asterisk is now the middleware of choice - check out this revised Neapolitan ice cream diagram to see why:
So - Intel pushed, and they failed.
Mark Spencer created Asterisk, and through being pulled by users and open source developers, it has come into position as the 'go to' telephony application development environment of choice for those commencing appropriate projects.
Vendor independence? Continue Reading...
Recent Comments