Recent VOIP market forecasts predict a sharp spike in residential VOIP users during the next few years. At the same time there is no shortage of consumer VOIP providers; and the revenues generated in the space aren’t likely to support all of them.
“I definitely think we’re going to see some disruption in the smaller, bring-your-own-access space,” says Katie Griffin, VOIP analyst at The Yankee Group. “There were a lot of people who jumped in -- I think the barriers to entry were pretty low -- but I think a lot of them are now running after shrinking dollars.”
The actual number of residential VOIP providers in North America remains unclear, but an average of analyst estimates puts it at about 400.
One empirical measurement was taken recently by broadband management equipment company Sandvine. It counted traffic from 1,100 VOIP providers on its customers' networks as of April 5th, but many of those were not residential providers, a spokesperson says (see Sandvine Counts 1,100 VOIP SPs).
Infonetics Research Inc. estimates that residential VOIP players reaped a combined $260 million in revenues during 2004, and that subscribers numbered 1.1 million at the end of the year (see Report: VOIP Adoption on Track).
Assuming for a moment that each of those 1.1 million VOIP subscribers paid comparable rates, the average revenue each one would have yielded is $233 ($256 million in revenues divided by 1.1 million subscribers), or roughly $20 per month.
Of course, VOIP providers are not all created equal. The largest players in 2004 were Vonage, which reported 390,000 subscribers at the end of the year, and cable players Time Warner Cable, Cox Communications Inc. (NYSE: COX), and Cablevision Systems Corp. (NYSE: CVC), which combined had roughly 600,000 VOIP customers (see Vonage Raises $200M and VOIP Keeps Fueling Cable Growth). If those four players are removed, only 110,000 subscribers remain and the revenue pool shrinks to $25.6 million.
If each of the remaining 397 providers gets an equal share (297 subscribers apiece), and each of those subscribers contributed the 2004 average per-subscriber VOIP revenue ($233), then each VOIP provider makes $70,253 for the full year. Better not file the IPO papers yet.
Many VOIP providers, of course, are banking on a fast ramp-up in residential VOIP subscribers projected for 2005; and the research shows it is coming. IDC
said in an April 4th report that North American residential subscribers will grow from 3 million by the end of this year to 27 million by the end of 2009, while Infonetics Research said the number will grow to 20.8 million in 2008 in its May 5 report (see IDC Predicts Broadband Voice Growth and Report: VOIP Adoption on Track).
But increasingly it will be large, entrenched players with pre-existing customer relationships and solid brand awareness that will take most of the new customers, analysts say (see AOL VOIP: You've Got Apathy).
Service bundling is also likely to be a key differentiator (see VOIP Parasites Take Heart). Industry research finds that consumers are attracted to VOIP as part of a bundle that saves them money on individual services. Cox Cable, for example, reports that 44 percent of its customer base had subscribed to two or more services at the end of 2004 (see Dittberner Reports on Cable Telephony Gear).
“Cost savings, ease of use, and bundling with existing services are the drivers that will make a difference in consumer VOIP adoption in the long term,” says analyst Gabriel Brown in the Light Reading Insider report Residential VOIP Services Explosion.
Others may find their place in the world by substituting the triple-play and bundling with pure marketing force, but it won't be easy (see Citron: Triple Play Is Tripe).
“Pure-play providers such as Vonage, 8x8, and Skype must strike quickly to gain customers to have any hope of long-term survival,” Brown says. “Vonage has perhaps taken this to heart more than the others, saying it will spend $75 million on marketing and advertising in 2005.”
But it’s likely to be a tough road ahead for smaller residential VOIP players.
“Smaller VOIP players have to be able to leverage some existing asset, like a customer base or a network, or else they’re really swimming upstream,” the Yankee Group’s Griffin says.
Say what? Most SIP phones implement DND as a station feature. If you fire it an INVITE, it's a black hole. It won't know squat about emergency calls. This is the whole problem with fully distributed call processing. If the feature is done by the phone, you have to rely on potentially thousands of different implementations to all get it right. That's why the cellular guys in IMS/3GPP put all the features inside the network subtended from the S-CSCF.
The standard SIP architecture user preferences being enforced at the proxy. This is where CPL is active. There are many reasons for this but a primary one is that the SIP phone may very well be powered off. So the S-CSCF or XW-q/681Z704) or whatever acronym that 3GPP has dreamed up is identifying a standard SIP functional block. SIP-servlets and SIP-CGI are both active in this block so it is well known.
Doing it at this functional block will also ensure that the priorites between personal, enterpise, emergency (911 etc.) can be idenfied and maintained.
dljvjbsl writes: b) special feature handling is required for this type of call. For example, a Do Not Disturb feature can not be honored in the face of an emergency call like this. This can cause dfficulty in a traditional system becuase it tends to require that all affected users must be served by the same switch. In traditional switches, the internal feature logic acts differently than external services. For a SIP implementation, the internal/external difference is non-existant and so feature operation is simplified fo this service
Say what? Most SIP phones implement DND as a station feature. If you fire it an INVITE, it's a black hole. It won't know squat about emergency calls. This is the whole problem with fully distributed call processing. If the feature is done by the phone, you have to rely on potentially thousands of different implementations to all get it right. That's why the cellular guys in IMS/3GPP put all the features inside the network subtended from the S-CSCF.
[referring to the traditional telephone feature set]
Want a good one? How about Fire Crossbar service? In small towns the local telephone companies have an obligation to ring all the phones of the volunteer fire company at once in the case of a fire or other disaster. I can't wait for that to be implemented.
Why would this be difficult for a SIP system in particular?
This is just an outbound conference call which is a standard feature. Multiple calls are initiated from some server (either a SIP server or a server running as a process in a traditional digital switch). When each call is answered, audio is directed to the conference bridge in the same manner for both a SIP and traditional telecom implementation.
Two things are apparent from this:
a) SIP is an ideal protocol for the creation of services from multiple application servers
b) special feature handling is required for this type of call. For example, a Do Not Disturb feature can not be honored in the face of an emergency call like this. This can cause dfficulty in a traditional system becuase it tends to require that all affected users must be served by the same switch. In traditional switches, the internal feature logic acts differently than external services. For a SIP implementation, the internal/external difference is non-existant and so feature operation is simplified fo this service.
I think one of the big issues is things like EBS and some of the more advanced services will be very hard to emulate. And it actually turns out that these are useful and people like them. One of the interesting things about this thread is the base assumption that the features and functions of the current telephone network are not good nor are they powerful.
Want a good one? How about Fire Crossbar service? In small towns the local telephone companies have an obligation to ring all the phones of the volunteer fire company at once in the case of a fire or other disaster. I can't wait for that to be implemented.
SIP really doesn't do telephony all that well. Feature transparency is still a work in progress. Common features like 1A2 key system emulation are incredibly complex to implement. The whole presence concept is half-baked. SIP is just an evolving set of protocols
Now that is talking!
SIP does not do telpehony very well because traditional telephony features were designed for the late 70's and early 80's technological environment when they were developed. In particular, they were not designed for an environment of ubiquitous personal and device mobility. SIP was designed for just such a communications environment and more than that was designed to create applications within that environment. The traditional telpehony feature set has been made obsolete along with the ystems that provide them.
I wonder what use a 1A2 key system will be in a world in which SOHO users will be connected to DSL lines. I do not have the same puzzlement when I think about SIP services and SOHO users.
Feature transparency is an artifact of the technological past. It is a means to try to synchronize the workings of isolated call control feature logics. It has obvious limitations in the types of features that can be supported. One gets the standard lowest common denominator features and is unable to create any feature that would be of specific use either personally or in respect to an enterprise need.
The sooner that feature transparency is dropped as a goal the sooner this inustry will be able to create applications that will be actually ueful and actually attract customer interest. No more check box feautrez that nobody uses in other words.
The SIP purist on seeing the 3GPP architecutre would wonder why it took them so long to create so very little. The 3GPP architecture is just the SIP architecture dressed up in endless acronyms. SIP has no problem with application servers. Indeed it was designed to cater to the needs of application servers. It can route and reroute audio and data almost at will to coordinate the operation of multiple application servers
As an aside, ISDN was not about integrating the backbone, it was intended to create a single network for all services that would be accessed via a single socket type. The ISDN S bus was a long way both physically and conceptually from SONET rings.
ISDN failed for two main reasons. Firstly it failed because the telephone compnaies realized that the best palce for ISDN (like all digital network systems) was at the periphery. This was a threat to their monopoly and so they made sure that ISDN could not provide services at the periphery. In doing so, they made sure that ISDN could offer no useful services and so ensured that ISDN could find no customer base. Secondly, ISDN was developed at the time of the Internet expansion and just as it became available the web was developed. ISDN could not hope to compete agaisnt these two technologies.
dljvjbsl writes: The failure is that all that effort and money have been expended to develop a technology that can carry low bit rate channelized data. What about all of the services that ISDN was to provide. Remember the 'single socket' that ISDN would supply to all homes and offices? It seems that offering a bit pipe cable replacement could not compete against Internet and web protocols.
OK. Let's try this one... Every DSL line uses ATM. That's the ISDN cell relay protocol. The ISDN architecture was all about integrating on the backbone network (SONET rings). It mixed traditional TDM, fixed size cell, and variable length frame technologies down one physical media. As a transport, Ethernet is clearly winning out since it costs so much less than SONET. This cost difference is what is killing off TDM, cell relay, and alternative frame relay methods. The jury is still out on SIP. PacketCable uses MGCP. 3GPP IMS uses a mix of SIP and H. & Q. protocols depending on where you are in the network. The closer you are to a media gateway, the more likely you are to see ITU protocols. SIP really doesn't do telephony all that well. Feature transparency is still a work in progress. Common features like 1A2 key system emulation are incredibly complex to implement. The whole presence concept is half-baked. SIP is just an evolving set of protocols. It adds so much complexity that the promise and hype of rapid service creation looks very unlikely in deployed newtworks. No operator is going to want to touch it once they get it working. That puts them in the same hurt locker they're in today with legacy Class 5 switches. IMS is an attempt to fix this by at least making all the services network-centric. The S-CSCF runs a set of service scripts on every INVITE message that causes it to invoke services provided by application servers. To make this work, they had to dumb down the SIP UA in the cell phone. A SIP purist would howl at that since it violates the fully distributed call processing model. Face the facts. SIP is a lousy protocol and full distribution of call processing is an unworkable architecture.
[describing the massive AIN feature set] Gee. Every 800 call uses AIN. Every local call uses AIN for number portability. The stuff was retrofitted on to 30 year old class 5 switches. By any definition, 800 number portability and LNP are successes. Given how archaic a #5ESS and DMS-100 are, that's about as much as you're going to be able to extend them. It ain't a protocol problem, it's a legacy installed base problem.
So the AIN labors mightily and is able to do 'number translation.' It can receive a message with 800 555 1212 in it, do a database lookup and return 212 555 2368. This is a triumph for TDM technology.
The difference between SIP and the AIN is not about IP and TDM. These are just bit switching technolgies. The difference is that SIP has benefitted from an additinal 20 years of research and development in computer science. It creates services at a fundamentally higher level than the call model trigger points that the AIN uses. It takes advantage of the ditributed intelligence in the network to create services that the AIN is incapable of creating at both the conceptual and technological levels.
[referring to ISDN] Every dialup modem call in the world terminates at a PRI line. Most PBXs in the world use PRI as their interface. What failure?
The failure is that all that effort and money have been expended to develop a technology that can carry low bit rate channelized data. What about all of the services that ISDN was to provide. Remember the 'single socket' that ISDN would supply to all homes and offices? It seems that offering a bit pipe cable replacement could not compete against Internet and web protocols.
dljvjbsl writes: We are all well aware of the failure of both the AIN and ISDN. They both had architectures that would not amke a TDM guy feel ill. What they do not have are customers using their services. Applications enabled by the carrier network are simply non-existant.
Gee. Every 800 call uses AIN. Every local call uses AIN for number portability. The stuff was retrofitted on to 30 year old class 5 switches. By any definition, 800 number portability and LNP are successes. Given how archaic a #5ESS and DMS-100 are, that's about as much as you're going to be able to extend them. It ain't a protocol problem, it's a legacy installed base problem.
Every dialup modem call in the world terminates at a PRI line. Most PBXs in the world use PRI as their interface. What failure?
fgoldstein wrote: The IP guys are still in the Strowger era. SIP is basically inband signaling, ASCII-character (a real IETF fetish there) dial pulsing. At least the MGCP side understood Common Control.
I always think to myself that SIP looks like how a high school student who had never been exposed to TLVs would invent a protocol. I haven't had the nerve to say it in front of the DynamicSoft guys yet. I still don't understand the claims for easy to implement and extend. Text parsers that are robust are incredibly difficult to write. It's a personal failing, I guess, that I'm incapable of writing such a program. TLV parsers are trivial and it's really easy to write a pre-parser that validates the whole packet. To extend a TLV protocol, you just add new TLV objects. What could be easier?
Suffice to say that I have multiple clients involved in it one way or another; some former cow-orkers even helped write the standard.
I meet quite a few people who claim to have "invented PacketCable". I don't know for sure who changed them from DCS (SIP) to NCS (MGCP) master-slave topology but that guy deserves a gold star. In my opinion, most of the standards are a disaster where there's far too much complexity. CableLabs never had anybody as a lead who understood KISS. It takes something crazy like 50 steps to boot and initialize an MTA. You need to be an architect to debug it. All the interfaces have too many "knobs" and "dials". The recent work to bolt in T.38 had too much SIP influence where the endpoints get to pick what flavor of T.38 the might want to run rather than strictly profile it and use the master-slave architecture you're supposed to use in an MGCP environment. The complexity explains why MSO VoIP took an extra 3 years to roll out.
Being a closed network, the IP header could be compressed away and it could still do the job. (I'm not sure if that's actually implemented, though.) One VoIP guru I know was CTO of a now-failed provider. He developed his own system that compressed the whole IP+UDP+RTP headers down to two bytes. Worked, too, and it let the investors have "VoIP".
Broadcom has pushed something like that for many years, too. I can't say more since it's under NDA. The native DOCSIS packet header supression can squash most of the MAC and IP header but it doesn't do UDP or RTP. I've never seen PHS turned on in a live network and I've never checked to see how well-supported it is by MTA and CMTS vendors. DOCSIS 3.0 is supposed to take another look at PHS but until VoIP starts consuming 50% of their access network bandwidth a couple of years from now, I don't think they'll apply enough sense of urgency to make CMTSs and MTAs support an optimal PHS. In RTP, pretty much the whole header is invariant other than the sequence number and timestamp. You have to be careful not to screw it up since the PacketCable RTP security method uses the first 12 bytes of the each RTP header as a seed for the security initialization vector (overkill to protect against replay attacks). If you screw up PHS, the packet will get tossed at the other end since it will fail authentication.
The blogs and comments are the opinions only of the writers and do not reflect the views of Light Reading. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Digg
Del.icio.us
Reddit
