Return to: Articles Index
Internet telephony, also known as voice over IP, may finally be ready for prime time in 2004. An increasing number of IP telephony providers, traditional phone carriers, and now cable companies—including AT&T, Comcast, Cox Communications, Level 3 Communications, Net2Phone, Verizon, VoicePulse, and Vonage—are offering a growing range of corporate and residential services nationwide.
Internet telephony is attractive to customers because it uses lower-cost equipment and is less expensive to operate than traditional, circuit-switched telephony, thereby enabling carriers to charge lower rates. In addition, the technology conveniently integrates data and voice services on the same carrier's IP network. Bundled voice and data are also less expensive than each service purchased separately.
And by combining the Internet protocol and telephony, voice over IP permits a broader portfolio of converged Web and voice services and applications, added Dan Dearing, vice president of marketing for NexTone Communications, an Internet telephony infrastructure vendor.
Most Internet-telephony traffic consists of international long-distance calls. In 2002, Internet telephony accounted for 11 percent of all international long-distance traffic, according to a report by TeleGeography, a telecommunications-market research firm.
Industry research firms forecast steady growth in the IP-telephony market at least through 2007. For example, ABI Research estimates the market will increase from about $750 million this year to more than $8 billion by 2007. IDC predicts that corporate spending for IP telephony equipment will grow 44 percent to $3.2 billion in 2004.
However, there are technical obstacles that could significantly impede the technology's marketplace growth. Providers' incompatible IP-telephony implementations make it difficult and expensive to move Internet calls between different carriers' networks. And as more calls shift to the Internet, these handoffs will grow in volume and complexity, further complicating the problem.
Researchers are thus working on ways to enhance interoperability.
Many Internet-telephony providers rely on the traditional telephone network to carry their traffic. IP-telephony systems use softswitches, which are open application-program-interface software that links traditional and Internet-telephony networks. They also typically employ media gateways, which use expensive digital signal processors (DSPs) to convert circuit-switched-based traffic originating and terminating on the traditional phone network to and from IP traffic.
A key Internet-telephony interoperability problem involves the different ways that vendors implement two key standards.
The standards. Two of the most important IP-telephony standards—the session initiation protocol and H.323—are at the heart of the interoperability problem.
SIP is an Internet Engineering Task Force signaling protocol for initiating, modifying, or terminating an interactive user session that includes multimedia elements such as voice, video, or gaming. SIP handles communications requests from clients, which can be sent via various transport protocols, and responses from servers. After identifying the participating systems, SIP determines a session's communication media and media parameters, as well as the called party's interest in participating. SIP also enables sessions involving services such as call forwarding, caller authentication, Internet conferencing, and instant messaging.
H.323 is an International Telecommunication Union standard originally designed to promote compatibility in videoconferencing across disparate IP networks. Service providers have also used H.323 for Internet telephony because it addresses call control and management, as well as gateway administration of media traffic, bandwidth, and user participation. The standard represents a very large protocol suite and thus requires extensive memory for code and data.
SIP was designed to be relatively simple and flexible and to enable application programmability and easy feature-set extension. H.323 is more rigid in its implementation but provides better session control and management. H.323 and SIP systems aren't directly compatible.
Different implementations. Vendors have implemented SIP and H.323 in various ways for different reasons, such as to gain operational efficiencies or competitive advantages. In addition, vendors frequently interpret protocols differently or implement a standard's features before they've been approved. Standards also change over time to address market needs, leaving some users with older and different implementations.
Thus, not all H.323 systems can work together, and not all SIP systems can work together. Internet-telephony systems may reject calls because the sending device uses a different interpretation of a standard and behave unexpectedly, such as by omitting mandatory fields from a protocol message or sending information via the wrong IP port.
These factors have hindered the deployment of next-generation network technologies that require interoperability both to work properly and to create a large enough market to generate revenue. Meanwhile, vendors are often slow to spend the time and money necessary to make their systems more easily interoperable, particularly if it entails giving up a possible competitive advantage.
Traditional phone systems carry multiple data streams by using time-division multiplexing. TDM puts multiple data streams on a single signal by separating the signal into many short segments. Each data stream is reassembled properly at the receiving end.
Some IP-telephony carriers send traffic outside their networks via TDM peering, which uses back-to-back media gateways. With this approach, carriers transform packet-based voice traffic to a circuit-switched format and vice versa at the gateways.
Converting Internet-telephony traffic to TDM and then back when it reaches the recipient eliminates the variables that make it difficult for the IP traffic from different systems to work together directly. However, TDM peering is cumbersome to engineer and the media gateways use DSPs, which are expensive.
Researchers are working with session border controllers (SBCs) to overcome Internet telephony's interoperability problems.
"Session controllers have helped resolve [these] problems and enabled Internet-telephony carriers to peer [more easily and inexpensively]," said NexTone's Dearing.
An SBC is a new breed of networking technology that provides routing, control, and security functions, as well as signaling interoperability and service quality, to manage real-time traffic between IP networks.
SBCs offer an H.323 and SIP interworking function (IWF) that uses software to translate between the protocols and thus provide routing services between devices.
When an Internet-telephony call is made between an H.323 end-point device such as an IP PBX and a Session Initiation Protocol device such as an IP phone, the H.323 gatekeeper lets the session controller communicate with H.323 end points. The SIP proxy lets the controller communicate with SIP devices. The IWF translates between H.323 and SIP and thus lets the different types of devices communicate. The media firewall provides security and controls access to a provider's network. The system uses RTP to carry the voice media.
When calls are placed between an H.323 and an SIP device, the SBC views each call as two legs: an ingress leg terminating on the IWF and an egress leg the IWF generates based on the protocol used by the remote destination. SBCs thus eliminate the need to use TDM as a peering technology between IP networks. With session controllers, carriers have to convert packet-based traffic back to TDM only when sending or receiving calls from a traditional telephone network. Companies such as Acme Packet, Jasomi Networks, Kagoor Networks, Netrake, and NexTone Communications produce SBCs.
Industry observers estimate that using SBCs can be up to 80 percent less expensive than TDM peering. SBCs don't use DSPs, which makes the equipment less costly, and the controllers are much easier on network management than media gateways, explained Micaela Giuhat, Netrake's vice president of product management. Also, she said, SBCs can be provisioned in a couple of hours, while media gateways can require weeks.
Even with SBCs, carriers must still test and tweak the points where their networks interconnect to maximize how efficiently they interoperate, particularly as new H.323 and SIP versions are released. Carriers also must provision end-point information—such as vendor type, signaling protocol, and codec—so that the SBCs can determine which signaling changes are necessary to dynamically mediate between end points. As carriers seek new sources of revenue, they are compelled to adopt more flexible business models that include peering with other providers.
"While the use of [IP-telephony] technologies reduces operating costs and provides new revenue-generating applications, it also creates new issues of . . . multivendor interoperability," Dearing noted.
In fact, if some carriers decide not to enable interoperability with other systems, "they will be out of business in five years," said Jeremy Duke, CEO of the Synergy Research Group, a market-research firm.
These factors will encourage carriers to begin standardizing the technology they use so that their systems work basically the same way and will interoperate without SBCs or other intermediary approaches, said Jerry Ezrol, technology leader for AT&T Labs' Voice over IP Development Group. Thus, he contended, the evolution to Internet-telephony interoperability is inevitable.
However, noted Eric Paulak, research vice president of the Network Services Group at Gartner Inc., a market research firm, "It's a migration and evolution in the marketplace. It won't happen overnight."
Neal Leavitt is president of Leavitt Communications, an international marketing communications company with affiliates in Paris, France; Hamburg, Germany; Bangalore, India; Hong Kong, China; and Sao Paulo, Brazil. He writes frequently on Internet and other technology-related issues. Contact him at firstname.lastname@example.org.
Return to: Articles Index