What’s the status of cable telephony? Will IP telephony overcome integration obstacles? Can cable networks support large deployments? Which operations-systems challenges remain to be solved? What’s the role of constant bit rate (CBR) telephony? Five telephony vendors answer these and other questions.
Nearing the midpoint of 2003, it seems appropriate to take the pulse of cable telephony. Before telephony will reappear on operator radar screens as a leading application, some critical operator issues need to be addressed. Toward that end, I’ve interviewed five leaders in the vendor community to gauge their response to these needs.
Our "virtual panel" consists of Mark Bakies, director of voice systems marketing, Cisco; Stan Brovont, vice president of marketing, ARRIS; Tom Gruenwald, senior vice president, access systems group, Tellabs; David Russell, IP cable director of business development, ADC; and David Spear, vice president of business development, Cedar Point Communications. Junkus: Every year since 2001 has been projected as the "year of IP telephony." Other than the obvious answer that the economy is slow, what factors are hindering IP telephony introduction in cable systems? Gruenwald: "PacketCable is a huge systems integration effort. The local digital switch served many functions, and duplicating it in a large-scale deployment is a challenge." Bakies: "Voice is a complex application. Integration and operations are the two biggest problems. PacketCable is not a mature set of specifications, and someone has to take the integration burden off the MSOs. Operations is a challenge, because telephony needs to be scaleable. Also, CableLabs does not certify products unless there is more than one vendor that can meet certification, and this tends to slow deployment." Russell: "It’s difficult to grow networks until you have a full set of products to build a network. Also lacking has been the expertise to integrate and systems-test a full set of elements and the back office." Spear: "The requirement for interoperability of multiple, discrete network elements has definitely slowed the certification process. Simplification is the key. In the second half of 2003, we will begin seeing integration solutions, and in 2004, there will be further improved systems integration and simplification that will result in large-scale deployments." Brovont: "In addition to all these issues, the fact is that cable operators are simply distracted by events unique to our industry. The Comcast acquisition of AT&T Broadband is one example. Adelphia’s bankruptcy and Time Warner’s need to divest cable properties are other examples. The availability of compliant products will be solved this year. Even now, there is more activity than might be apparent. For example, Charter is doing a deployment in Wausau, Wisconsin." Junkus: How can a vendor help move telephony to the front burner? Spear: "The vendor community needs to come together with a solution with less piece parts. Vendors need to prove they are part of an integrated, end-to-end solution. They need to come together as a consortium, and not leave integration as a task for the operator." Russell: "Vendors are putting increased resources on PacketCable compliance, particularly on detailed interoperability testing in labs and with other vendors in advance of testing at customer sites. In addition to work in our own labs, there is a lot of interaction with emerging systems integrators, such as Lucent, Hewlett Packard, IBM and SAIC. We are also working with solutions vendors who offer complete networks to the operators, such as Net2Phone, Accenture/Imagine Broadband, Gemini and Echo." Brovont: "We also need to explain how PacketCable, IP telephony and packet technology in general present an opportunity from a return on investment (ROI) perspective, and from reduced churn and increased customer loyalty. For some of the smaller operators, this may also involve partnering with other vendors to create a reference network that enables an operator to offer branded telephony service without the need to own the entire solution." Junkus: Our industry has invested substantially in CableLabs and the PacketCable initiatives. From a vendor perspective, what are some of the challenges in meeting compliance with PacketCable? Russell: "We need to get over the issues of CALEA, where some of the interface specifications are still being resolved. We are in relatively good shape for E911 (which was an issue); in fact, in cable, E911 calls will get higher priority than they do in a LEC, so we will be more reliable." Bakies: "PacketCable, like other standards, is based upon vendor contributions. As vendors bring new perspectives, it creates new work. Usually, it means a vendor needs to maintain multiple issues of code and work with operators to plan necessary updates to their systems." Spear: "The biggest challenge is to work through the interoperability specifications and build open interfaces to match the CableLabs specifications. Vendors need to continually build, test and be proactive with partners before the qualification process." Gruenwald: "From a vendor perspective, some of the new network elements will have a tough time standing alone as a business. Development of call manager software, for example, requires market scale, and legacy solutions such as the reverse gateway that use an existing local digital switch slow ramp-up for CMS (call management server) vendors." Junkus: In retrospect, would cable have been better off going with established standards, such as H.323 or session initiation protocol (SIP) for residential telephony? Spear: "Absolutely not! For future value, cable operators need intelligence in the network. There is no value to a dumb pipe." Russell: "H.323 and SIP are not the appropriate approaches for residential carrier class service. For cable to be competitive, it needs primary-line service, with reliability, quality of service (QoS), E911 and CALEA capability. SIP and H.323 cannot meet these needs." Bakies: "Actually, PacketCable evolved from existing standards. Early in the process, Cisco looked at H.323 and began adding features. It became apparent that a distributed call model would require updates to endpoint network-element software for every new feature, so we worked on several protocols that eventually became MGCP (media gateway control protocol), which is the basis for PacketCable NCS 1.0." Junkus: Is there a place in cable for SIP or H.323-based telephony? Does your company offer an H.323 or SIP-based telephony product line? Bakies: "About 25 cable companies, mostly outside the U.S., have initiated telephony services based upon H.323. These offerings do not have an extensive feature list, and in particular lack 911 and CALEA, but they are still viable services where basic phone service is the main need. SIP came from a different perspective—a sort of evolution from the data world’s HTTP. There’s a lot of excitement now about the use of SIP in announcement and media servers. Based on this history, the Cisco philosophy is to support multiple protocols to meet evolving needs. For example, we offer an analog telephone adapter that is used by Vonage for its service offering. That offering meets a need for nonprimary line telephone service, with a very limited feature set." Spear: "SIP is part of the interface to third-party feature developers. We use it to interface to third-party feature servers." Brovont: "SIP and H.323 are not in the PacketCable model for residential endpoints. If the industry remains committed to PacketCable, there is no room for SIP in a residential model." Junkus: What about telephony offerings like Vonage, which use cable as access to its own system for telephony service? Are they synergistic with cable’s desire to offer the triple play of video, data and voice? Russell: "Consumers need to be aware of the limitations of telephony services that are not primary line. These types of services tend to break down under network congestion." Brovont: "These services have a real downside for cable. On the one hand, if they do well, cable operators lose the opportunity to brand telephony for a bundled offering. On the other hand, if they fail, the cable industry will feel the blame because the consumer has used the cable network as part of the service." Junkus: What is the status of constant bit rate (CBR) telephony? What is its role in the next two years? Does it have a place in the world of PacketCable and IP telephony? Russell: "CBR products are in the mature part of the product lifecycle. ADC is supporting existing installations and will take new orders, but the market is definitely those companies that already have installed the network equipment. One advantage of CBR is that we know it can support high penetration rates. Cox, for example, exceeds 30 percent in some markets." Spear: "CBR still has a role where capital and services have already been deployed to support it. For today it has been shown to be very successful and instrumental to the triple play. It will continue until lower-cost alternatives are deployed." Gruenwald: "Service providers that have implemented telephony will continue to use a business model to determine when it should be replaced by new technology. If circuit-switched telephony remains cost-effective, they will continue to buy it. The cable business has yet to define multimedia, so existing applications like telephony provide the only real revenue flow, and circuit-switched is still the only proven technology." Brovont: "The opportunity is definitely with existing customers. There is lots of HDT (host digital terminal) capacity in service provider networks, and payback on incremental customer premises equipment is a matter of months. Cox has just announced it will do one more city with circuit switched technology, and internationally, Jupiter and VTR continue to deploy." Junkus: Some cable engineers have expressed concerns about the capacity of the return path, even with DOCSIS 2.0, to handle telephony traffic, in addition to myriad multimedia services. What measures are available to alleviate the pressure on the return path? Russell: "I don’t think bandwidth is an issue on the return path in the foreseeable future. We may have to worry about it when we reach penetrations of 30 percent in telephony, coupled with 50 percent in high-speed data. Some plants will require upgrades, and QPSK (quadrature phase shift keying) is obviously a ‘non-starter.’ DOCSIS 2.0 supports 64-QAM (quadrature amplitude modulation), and node splitting based upon success can be a further solution." Bakies: "The return path shouldn’t be a limiting factor. Traffic engineering will be very important, but system rebuilds have brought enough fiber to the nodes to last for a long time, and DQoS provides the tunnel needed for voice." Spear: "The biggest change has been improved, royalty-free compression algorithms. Adding the effects of improved compression, 16-QAM in the upstream, and the DOCSIS 2.0 work in general, we have made significant gains in the upstream, and may find that any bottleneck that exists is in the downstream." Gruenwald: "Much depends on how the codecs handle compression. Although it uses a proprietary modem, our circuit-switched product is able to carry up to 30 calls in a 1.9 MHz spectrum. DOCSIS 2.0 alleviates many problems, but it is still dependent upon plant conditions." Brovont: "If multimedia traffic becomes an issue in the upstream, there is a lot more value in video compression than in voice. Lots of design is being done with the Joint Video Taskforce and MPEG-4 extensions to alleviate bandwidth needs." Junkus: Are operations systems ready to support both advanced video services and telephony? What problems are emerging as IP becomes more prevalent, and what are your company’s solutions? Bakies: "The operations environment evolves as systems scale. Each level of scale yields new challenges requiring new solutions. PacketCable and RTP provide lots of telemetry, which give ‘hooks’ between legacy systems and new systems. Automation is the biggest problem to be solved." Spear: "There’s still lots to be done, but progress is being made. Multiple operations systems vendors need to work together to do systems integration. Scale is a big issue. Going to multiple thousands of lines requires automation and simple interfaces to the back office." Brovont: "Provisioning and billing look OK, but we are looking at ways to improve surveillance and fault isolation. Partnering with other vendors is a big part of our strategy." In summary, our "virtual panel" of vendors sees telephony reemerging in 2003, and gaining momentum in 2004. Scalability and systems integration are the main issues to be solved, and vendor partnering is a big part of the solution. Improved compression and DOCSIS 2.0 have solved many potential upstream problems. The consensus is that operators will base their technology decisions on sound business practices that take into account ROI and customer retention through service bundling and brand recognition. Justin J. Junkus is president of KnowledgeLink, Inc., an independent consulting firm, and Communications Technology’stelephony editor. To discuss this topic further, email him at firstname.lastname@example.org. Telephony Retrenches Vendors see telephony re-emerging in 2003 and gaining momentum in 2004. Scalability and systems integration are the main issues to be solved, and vendor partnering is a big part of the solution. Improved compression and DOCSIS 2.0 have solved many potential upstream problems. The consensus is that operators will base their technology decisions on business factors, including ROI and customer retention.