ahhaha, thanks for the opening to discuss VoIP as it relates to ATHM.
To reiterate, the link which I referenced last night, and which you have re- introduced today for backgrond purposes:
applied-research.com
...contains assertions and positions that are not accurate in their attribution, and I permitted it to stay in print for its provocative value, only. For that purpose, at the very least, and for its tutorial value, it has proved very successful.
(Brad, If you're looking in here, I just want you to know that you've gone and done it again!)
---
Having said that, and to get serious concerning Voice over Internet Protocol (VoIP) as it relates to ATHM, you are IMO correct to suggest that it should be re-considered as a component of their product mix, from a number of different perspectives. Not the lease important of which, may be profit margins.
But there are other implications to consider that could be equally as, or even more, profound than margins, for ATHM.
To draw a parallel, VoIP is in some ways like the "touch-tone" dialing feature of the past and present... but it's touch tone's past and evolutionary path that is important here.
Touch tone, through the use of dual-tone multi-frequency (DTMF) signaling, originally only satisfied a very rudimentary dialing function, and was viewed as an extravagance if one had to pay extra for it. The killer application that bumped touch tone to the status where people were at last forced to pay for it? What was it? Was it the original pager? Remote character-based data entry? Interactive Voice Response? You tell me.
Whatever, touch tone or DTMF evolved over time to become an indispensable part of modern day communications, for more purposes than I can list here. Look at all of the uses of DTMF today that you yourself use, as it sits as an embedded element in almost every part of your communications infrastructure, that you can neither escape nor do without. Yet, it had its beginnings, ostensibly, as a means of avoiding the drudgery of the old-fashioned mechanical rotary dial.
VoIP may be viewed in much the same way today, as a novelty for some, as a convenience for others, and as a substantial money saver for the price-sensitive international caller. Tomorrow (pick a date, starting 2H99 and beyond) it will be an integrated staple with a growing number of uses. VoIP will grow in relevance and stature to something that any full-featured ISP would be very hard-pressed to not provide, or claim to not have in their plans.
Think of a CLEC today attempting to survive if they refused to adapt to the rules of touch tone signaling. ISPs face the same set of choices with regard to not only VoIP, but in adapting to an entirely old and legacious set of PSTN rules as well, such as SS7 and other Operations Support Systems- (OSS-) supported functions, such as Local Number Portability, E-911, etc., but now I'm starting to really digress.
Simply put, there would be more elegant and less painful ways to go out of business as an ISP in the future, than through the omission of VoIP offerings. Even from an e-commerce standpoint, virtual call center attendants at the Web-based mall will need to be able to communicate orally with customers. But it goes far beyond that kind of niche application.
---
Once some of the more problematic IETF and ITU issues are resolved, from both the technical and the administrative perspectives, new switch architectures which are now only awaiting the proper code will start rolling out with next generation features of a more finalized nature. Well, a "more" more finalized, nature, in any event.
Througout the period which makes up the next several months to a year it will be possible to establish a new costing model in order to facilitate a more accurate assessment of capital needed in the VoIP model. That model will likely have a shelf life of about 18 months. Then it will also be possible to compare the cost-of-entry of VoIP versus that of traditional end-office switching platforms used by the ILECs (who, themselves, like the CLECs and the DLECs are looking seriously into this as we speak, as well).
Today's cost elements which are used as benchmarks for financial modeling are still very flimsy and unstable, for they only address for the moment the 1st thru 3rd generations of gateway-based hardware platforms, and T-1 lines. The gateways still depend on end office and tandem switches, for the most part, relegating them to mere adjunct units which do not stand on their own yet. Instead they are situated between the CO Switch and a Router. Some routers themselves [3rd generation gateways] which possess VoIP codecs in their innards, themselves must hand off, in turn, to end office switches, as well.
Right now we are on the cusp of a new generation of devices known as IP switches [we've already seen some of the earlier models releases, waiting for the proper code to load in their stores] which will comprise routing and circuit switched attributes, as well as administrative hooks to the established data bases that have served the PSTN up to this time.
These newer devices will also support future directory services models, as well, allowing for migration to new levels of linkage and routing achievable in an economical way only through IP modeling [and integrated services protocols], at this time. The old and the new will interwork through processes which have been dubbed "harmonization processes" under various initiatives now under way at the ITU and IETF/ATMForum levels. And various other ITU/IETF-related fora and consortia now working to these ends.
I suppose it's possible to extrapolate what the costs of these new platforms will be, unless they are integral to what the ISP puts in place as its main routing platform for other IP services as well, and then it's an individual case basis assessment based on what the traffic mix will be that that ISP will support. In other words, allocating the costs per port, or per MegaByte, or whatever, will be dependent on weighting the different traffic forms that go across them. It's sure a funny way of amortizing the cost of a port, but you know what they say? It's what the traffic will bear? Almost. Rather, it's what type of traffic it will bear! And how it is priced.
Tomorrow's pricing elements will not be solely based on such hardware considerations as gateways, switches and routers, and T-1s. Rather, it will also include, and be much heavier dependent on, quality-of-service- (QoS- ) and policy-based metrics that ISPs will employ in their provisioning of guaranteed service levels, and for the purposes of class-of-service (CoS) differentiation.
Many of these price- point-solutions have yet to be established for public VoIP applications, except for some isolated situations where they are prototyping. There must first be substantive platforms developed supporting these features, then they must be deployed by competing entities, before they can settle into dependable pricing ranges. Or, perhaps, if these voice applications are truly only the cyber- cockroaches which swim in the free ketchup we get at MacDonnalds,which has been suggested by Sidgemore and Chambers, then they will indeed be free for some.... but essential, nonetheless.
For the record, I don't agree with the free aspect, at least not for the public voice services of the future which will displace the PSTN services of today. Another point I'd like to make is that tomorrow's voice will undoubtedly be packet-based, and in the distribution part it will likely be IP... but in the transiting parts of the inter-network, it could be anything from PCM to ATM to IP of any of a dozen different compression algorithm types. DSPs will flash convert them on the fly, to reconcile numerous disparate packet modes to the end user's ultimate platform requirements through automatic means. It will not necessarily be IP through and through, in other words.
---
During the Summer of '97 my team and I finalized a year's work with a client, and actually brought before Tier One Backers on Wall Street a business plan for a VoIP carriers' carrier business. Five- and eight- year flows intact, reaching EBITDA crossover within the second quarter of the third operating year.
The design was far ahead of its time, and even by today's standards it merits a nod, but we clutched going forward, and at one point we decided to put it in neutral. The reason: some very revealing last minute due dilly findings that uncovered work being done within the last two months of our undertaking. Internet time was at that point defined for me in no uncertain terms.
What had been obvious to us for a year, and hardly spoken about by anyone else, was in a flash soon to be commoditized on the open market. Good Morning America!
I dug a lot deeper into several top vendors' portfolios of non-disclosures, and some of the heavy-hitting service providers plans. The ones who we had slated as future 'customers.' Luckily, we stalled when we did, IMO.
One thing that struck home was the inevitability of an early field saturation of pure plays (I envisaged the nation being carpet bombed by Internet Telephony Service Providers, or ITSPs), and the ensuing shake out, or the strong possibility of one. Risks went too high for a fledgling with less than 8 zeros of initial backing, I felt, so we remained low at the time.
At the same time I had heard Tom Evslin's now-famous inaugural speech for his startup company, ITXC, which he made at a Merklermedia VON event in Chicago during July of '97.
I think that this 45-minute combined speech + Q&A was well worth the time spent listening to it. It can be heard on streaming audio at:
audionet.com
---
In any event, this is a complex issue, and does not lend itself to a simplistic, single-conversation solution. Instead, it requires a lot of conversations, but at some point those discussions can be rolled up into a single assessment. That assessment, however, would be less than trustworthy, unless you step through all of the conversations. No mean feat. It's a bitch to resolve, and not for the faint of heart if you are a provider, to endure.
And it requires that you have the expertise of individuals from multiple disciplines sitting at the same table. But for posters here, and for ATHM itself, it could well-be worth the time spent exploring this further. I would suspect that ATHM has already done this. Perhaps they did it at a time when the pricing and state-of-the-art metrics were not where they are today. Maybe they do it on an ongoing basis.
Or, perhaps they are precluded from entertaining such an addition to their portfolio mix, through covenants of sorts with the owners. I don't know.
What I do know is that to be without VoIP handling capabilities in a few short years will put them at a severe disadvantage.
A complete taxonomy of the issues that affect this sector would take a considerable amount of time to develop. Perhaps I'll do that at some point and post it as a graphic in my profile. Then I could retire and feel that yet another of my accomplishments was anachronized before it was complete. Nah... just kidding... [?]
More later on, as the topic progresses, if it progresses.
Regards, Frank Coluccio
|
