Frank:
I have read your informative and civilized posts over the years and have learned from quite a bit from them. I basically agree on your VOIP analysis, but would like to add some comments to your post.
Back when you were trying to buy SS7 enabled gateways, I was involved in trying to convince some of those telecom manufacturers you mentioned to use SS7. However, SS7 is expensive and complex, and you have to have a good business case to justify the cost, and a good implementation to allay the fears of the operations about putting your messy (i.e. flexible) IP equipment into their protected SS7 network.
There are a) technical issues, and b) business issues in deploying VOIP or any form of packet voice.
The following is the status the signaling issues of VOIP as a technology as I see it:
1. SS7 is not a legacy protocol, except perhaps at the lower layers. At the top layers it defines messages that allow distributed process to perform concurrent and cooperative communication to make a phone call with all the features we have come to expect and demand. We still need it. The first thing VOIP must do is recreate those features. As I understand it, the SIP group at IETF has thrown in the towel, and rather than trying to make their own message set (which would end up very like TCAP and ISUP) they will use TCAP and ISUP over/in SIP. You will also need it whenever you want to talk to someone on the PSTN or Mobile networks (there are ~900 million of them or so right
now).
2. SS7 as a network is expensive, and SS7/IP is hot stuff right now in the committees as it allows you to use a low cost managed IP network instead of a complex SS7 network. The IETF is ready to replace the legacy TCP, with the new SCTP protocol, which allows more real time and reliable signaling over IP. So 'good' SS7/IP is driving the improvement 'bad old' TCP/IP. In this sense, ironically, SS7 is the new driving technology in IP! So there are standards to build a SS7/IP gateway that allows low cost shared access to the SS7 network over IP, but you still have to program TCAP/ISUP call models.
While the IETF in their SIGTRAN working group is working on a massive number of SS7/IP specifications, Cablelabs, the cable service providers standards group, released their SS7/IP specification last year, allowing TCAP and ISUP transport over reliable IP with standardized signaling gateways. I don't believe any equipment is yet deployed, but cable is way ahead (> 1 year) of DSL and wireless VOIP in standards work, and doesn't have to deal with much legacy technology when they do deploy. ITU is way behind, and, with the exception of H.323, the ITU has turned into a 'me-to' body on VOIP, ATM, and wireless, and is still pushing the long ignored AIN stuff.
3. I love the idea of SIP, but it needs a lot of work. Nevertheless, SIP is the future, and combined with XML, MP7, and other neat web stuff, will reach your vision of "the more strenuous, yet aggressive, approach... to pursue true IP telephony, where voice is keyed to IP end points".
However, we have to first build standard mission critical voice and government mandated features such as 800 numbers, credit cards, local number portability, and CALEA (lawful intercept, as well as the usual "class" voice features. This will take some time.
The following is the status of VOIP as a business as I see it.
1. ILD: In the last two years SS7 systems have been deployed as international long distance (ILD) gateways, where you can use IP's 8:1 voice compression to reduce the cost of traffic over an international link, and SS7 is a requirement to access the national network. However, this market is mostly a tariff avoidance (data is not tariffed as voice) and this advantage changes as soon as the local PTT gets wind of what is going on and tells their government to 'stop these pirates!'; then the system is taken off line. Nevertheless, this is a real, if not large, market, and people are trying to start national ILD's all over the place, with some success, in countries that are more open to competition.
2. Access: Cable and DSL will success where a second (or third or more)line is required- ~20% of US homes today, and broadband data is desired- ~40% of US homes today, or in Sub-T1 businesses. Large business get rather good rates ($.03/min) and are not inclined to put mission critical voice over lower quality VOIP. However, most VOIP today (and for a while) will use a TR303 or V5.2 interface to connect to those bad old legacy central office switches to use the existing software and call models and feature, and not fufil your "end point" vision.
3. Bypass Embedded Switching: There is s strong, almost religious, believe that we must bypass those old legacy (evil! bad!) embedded switches and use computers which cost less and let you create new features in days!, no hours! no minuets!. A lot of service providers are refusing to buy any more circuit switches at all. While I share this view to some degree, I developed switches for 25 years, and I will tell you that merely waving "IP" over the problem set like a magic wand won't do much for you. When I last asked about 4 years ago, 20% of switches cost was hardware; 80% software. A typical line cost was ~$200 (after some dickering- this is more a wholesale figure, but the costs have likely lowered in four years). Simply replacing the T1 or Analog Line interface cards by DSPs will cost more, not save more. Your software cost won't change. I have lots to say on the subject of software development productivity, but to make it short, it takes 30-50 people who have extensive telecom experience about 4 years to build the software needed to duplicate central office features (this is absolutely best case; very likely it will take more people and a longer time). Don't look soon for a full switch implementation using SS7/IP, Megaco, and SIP. However, you can make money selling Enhanced Services, and we are seeing roll out of SS7 enable ESP's with unified messaging features
today.
4. Integrated services. This is what I think you meant as the great new future. The real driver for the endpoint, distributed, user call management model will be the thirst for integrating voice, data, web, slow compressed video, and real time video so you can invent neat features. We want to
make voice/data call process as simple as web page sessions. One thing I noticed about the SIP people at the IETF is that they mention only one integrated feature when proceed to try to make a voice call work? The point is, these features aren't defined. This is ok in a stateless web
page, where you don't have to define protocols, and anyone can define a feature that affects only yourself, but integrated features are more complex (more events, states, and protocols) than stateless web pages, and require a bunch of committees to agree on a Layer 7 messaging protocol, so both ends know what is going on.
5. Enterprise- I'll leave this alone for now, expect to say that PBX's are so inexpensive, that it seems only eager early adapters want to try mission critical voice on VOIP based PBX's.
Since this is a silicon investor site, onto stocks. To me, the above implies that cable based ventures have the upper hand in the future (although other technologies will co-exit) when providing these integrated features; even if integrated services are not desired, they have the big advantage of providing one bill for all service. This means, integrated service providers (ATT.ATHM, and AOL), Set top makers (MOT, Scientific Atlanta), set top software developers (Microsoft, Liberate) and chip manufactures, (Broadloom, and ATI).
Of these, ATT, ATHM and ATI are rather beaten down and very attractive right now. If anyone has any recommendations on companies in the integrated cable market, let me know.
Justone opinion. |
