Issue No.04 - July/August (2005 vol.9)
Published by the IEEE Computer Society
Scott Bradner , Harvard University
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MIC.2005.82
Originally, we wanted this issue's theme to be about the broad topic of Internet media—that is, we wanted to cover all types of video and audio distribution and interaction over the Internet. What we wound up with, however, is the third in a series, spaced three years apart, of issues focused on Internet telephony.
Originally, we wanted this issue's theme to be about the broad topic of Internet media — that is, we wanted to cover all types of video and audio distribution and interaction over the Internet. What we wound up with, however, is the third in a series, spaced three years apart, of issues focused on Internet telephony.
Most of the submissions we received focused on aspects of telephony in IP networking environments, and all four of the accepted articles specifically addressed telephony rather than the broader Internet media topic. We don't take this to mean that no unsolved issues remain in using the Internet to distribute media other than telephony — instead, we think the articles' focus represents the Internet's current importance in the minds of telephony professionals and researchers looking for cutting edge, yet real-world relevant, topics to work on.
Internet and IP telephony is rapidly capturing mindshare across the telecommunications world. Every major US telephone company and many cable TV companies are already offering services, or at least experimenting with them, and the number of independent service providers who aren't associated with ISPs continues to grow. Most of the Fortune 500 enterprises are considering enterprise-level deployment of IP telephony, driven, at least in part, by the fact that almost no research or development work is being done on non-IP-based telephony. Equipment vendors have overwhelmingly bet their R&D dollars on the IP telephony horse.
Moreover, Internet telephony has garnered attention from regulators worldwide, most of whom appear to view it no differently than they do traditional wire-line-based telephony — they're not ready to deal with the fact that IP telephony services aren't necessarily constrained by the limitations of traditional circuit-based telephone connections or the 12-button keypad user interface. Nor are they ready acknowledge that IP-based technologies can provide a wider range of qualities of service (QoS), which could, in turn, provide more products from which customers could select.
Yet, for all the hype and regulatory attention, Internet telephony currently represents a very small part of the overall telephony business. In the US, for example, the Federal Communications Commission (FCC) estimated that roughly one million people were subscribing to Internet telephony at the end of 2004 — less than half a percent of total US telephone subscribers. Internet telephony will take a long time to become as significant economically as it already is in the press.
The guest editor's introduction in the last IEEE Internet Computing issue dedicated to Internet telephony ended with a hope that the topic would no longer be "special" by the time IC was ready to run another theme issue on it. It seems almost quaint to reread the prediction that it would be "just part of the multifaceted service platform and innovation that we will still call the Internet." 1 Yet, the time has come for another theme issue, and Internet telephony remains special. It's still not all that common, and several technical issues remain unsolved, including those addressed by the articles in this issue.
The basic Internet telephony standards are, by now, well defined. The protocol currently getting the most publicity, the IETF's Session Initiation Protocol (SIP), is in its second revision, and the underlying protocol is quite mature. 2 SIP has been adopted by the 3rd Generation Partnership Project ( www.3GPP.org) and 3GPP2 ( www.3gpp2.org) — the organizations working on standards for third-generation cell phone systems — and by the International Telecommunication Union's Next-Generation Network (NGN; www.itu.int/ITU-T/ngn/) effort.
Of course, SIP isn't the only Internet telephony standard that's been defined. The ITU-T's H.323 is still widely used, 3 as is megaco/H.248, 4 which was jointly developed by the IETF and the ITU-T. The Media Gateway Control Protocol (MGCP), 5 developed by an industry consortium, is also in common use. SIP and H.323 both focus on end-to-end (or at least edge-to-edge) architectures, whereas megaco/H.248 and MGCP focus on systems that will replace telephone switches.
Some of the more interesting and innovative Internet telephony efforts, such as Skype, actually use their own protocols rather than these existing offerings. Still other standards might emerge as telephony services become more common.
One major hurdle on the road to IP telephony deployment is support for enhanced 911 (E911, which reports caller location in case of emergency). E911 standards are under development, but enterprises desiring this feature must either wait for the standards to be finished and incorporated into products or use one of the many vendor-propriety solutions.
Few issues stand in the way of widespread IP telephony use in single-site or campus-based enterprises. Current IP routers and Ethernet switches coupled with inexpensive gigabit Ethernet LANs are fast enough to support the highest quality levels for telephony.
Security and QoS controls for intersite links in multisite enterprises are complicated, but because these links can be managed by a single administrator, most of the hard issues can be avoided. This is also mostly true for companies that offer IP telephony over their own physical networks, such as cable TV companies and telephone companies selling DSL Internet connectivity. These networks' shared nature imposes a higher requirement for QoS controls, but again, the links are under common management, so such controls are currently feasible.
Security and QoS controls present a greater challenge when the telephony service provider has no relationship with the IP service provider. Currently, Vonage, Skype, and others must accept whatever quality the underlying network provides and use end-to-end or end-to-server security. Luckily, the underlying networks generally work well enough that telephony users are satisfied with their service, but this might not always be the case — in some locations, it's almost never the case. In the long run, the underlying networks must be designed so that congestion is a very rare event or to support signaling from the end nodes (IP telephones) or servers to request higher QoS levels.
In this Issue
Most IP telephony systems use adaptive playout algorithms to determine when to send a packet's worth of sound to the user's headset. In "Switching between Fixed and Call-Adaptive Playout: A Per-Call Playout Algorithm," Younchan Jung and J. William Atwood propose instead to use an algorithm that determines a fixed playout delay at the start of a call for use throughout it. They report that they've used this simpler mechanism to help minimize data-loss percentage and thus improve perceived voice quality.
Miroslaw Narbutt and colleagues' "Adaptive VoIP Playout Scheduling: Assessing User Satisfaction" describes a new method for gauging user satisfaction with voice quality during IP phone calls. They present an algorithm that can combine several measurable values and the type of voice coding electronics to calculate a voice transmission quality rating score. They also show that their algorithm's results compare favorably with those obtained using traditional quality-measurement techniques.
In "Voice-Quality Monitoring and Control for IP Telephony Systems," Michael Manousos and colleagues propose an endpoint-based strategy for maintaining voice quality over today's IP backbone networks, which all lack QoS guarantees. Such a mechanism would be useful to IP telephony providers that aren't facilities-based.
In "Adapting H.323 Terminals in a Service-Oriented Collaboration System," Wenjun Wu and colleagues describe a prototype global multimedia collaboration system that they've used to bridge four different telephony systems. This system lets users of a particular IP telephony standard communicate with others using a different standard. Given that technology never stands still, or at least that it should not, this type of bridging functionality is required as we migrate from one technology generation to another. It can help bridge the gap between vendors who refuse to agree on a common standard.
Chris Metz's "Internet Multimedia: Answering Basic Questions" rounds out the special issue section with a tutorial on the "media" aspect of the original theme. Specifically, he describes some of the protocols and technologies that facilitate multimedia applications over IP networks and examines how they relate to each other.
Just as we saw three years ago, most of the impediments to widespread deployment of Internet telephony still seem to be nontechnical. Regulatory assumptions and the lack of successful ISP business models are still holding back Internet telephony's proliferation at least as much as assumptions of unpredictable call quality.
The actual percentage of nonwireless telephony subscribers relying on Internet telephony will still be small three years from now, but we trust that at that time Internet telephony truly will, at last, no longer be special.
Scott Bradner is the university technology security officer at Harvard University. His research interests include advanced network technologies and network security. Bradner is coeditor of IPng: Internet Protocol Next Generation (Addison-Wesley, 1996). He is a member of the IEEE, the American Bar Association, and ACM and writes a weekly column for Network World. Contact him at firstname.lastname@example.org.
Chris Metz is a technical leader for Cisco Systems. His research interests include IP/MPLS architectures and protocols. Metz is the author of IP Switching: Protocols and Architectures, (McGraw-Hill, 1999). He is a member of the ACM/Sigcomm and the IEEE. Contact him at email@example.com.