Packet Voice Over Broadband

It's replacing telephony. Can it match it as a money-maker? * Technologies * Opportunities * Challenges

March 3, 2005

18 Min Read
Packet Voice Over Broadband

The telecom industry is in the early stages of a major transformation that's likely to see traditional telephone networks replaced with broadband infrastructure over which all sorts of packet-based services will be offered.

A major ingredient of many of these services will be voice – either via the packet equivalent of traditional telephone calls or as part of applications that bring together other media as well, such as instant messaging and video.

There are huge opportunities for carriers and cable operators to launch these sorts of services, both in terms of generating new revenues and in cutting costs. But there are also plenty of practical questions to address before taking the plunge. These include:

  • What are the appropriate packet-voice technologies for different markets?

  • What is the best use of packet voice for residential subscribers? Cheap telephony or sophisticated services sets? Or something else?

  • What will be the best strategy for packet-voice services for enterprises?

  • How easy will it be to deploy packet voice over existing broadband networks? Where are the main problems likely to occur?

This report systematically reviews these and other issues to clarify where packet voice is going for carriers and service providers.

Here’s a hyperlinked contents list:


This report was previewed in a Webinar sponsored by Acterna Corp. It may be viewed free of charge in our Webinar archives by clicking here.Background Reading on Light Reading

  • News Analysis: Carrier VOIP Equipment Rises 69%

  • News Analysis: Ma VOIP?

  • Report: VOIP vs PSTN

  • Report: New DSL Network Architectures

  • Report: Upstream of the DSLAM

  • Report: IP Quality of Service

Related Light Reading Webinar archives:

  • Packet Voice Over Broadband

  • B-RAS Developments

  • Next-Gen B-RAS: The Money Makers

  • Next-Gen DSLAMs

  • The Role of DSLAMs in Delivering Next-Gen Services

  • Upstream of the DSLAM: Beating Broadband Bottlenecks

  • Working Text 81: The B-RAS Blueprint

  • IP: QOS – Delivering Carrier-Class Quality

  • QOS Characteristics of New Carrier Services: What’s Required

  • Service Management Systems: The Triple-Play High Ground

Related Heavy Reading reports:

— Graham Beniston is Principal of Beniston Broadband Consulting and Analyst at Large at Heavy Reading. He is the author of the Heavy Reading report, Next-Generation DSL Equipment: The Path to Profitability; and the Light Reading report, New DSL Network Architectures. He has presented Light Reading Webinars on related topics, including WT-81: The B-RAS Blueprint, Edge Routing: Evolution and Economics, Next-Gen DSLAMs, and Next-Gen B-RAS: The Money Makers.

Plenty of carriers are charging ahead with plans to roll out VOIP services over broadband infrastructure. Prominent examples include:

  • BT Group plc (NYSE: BT; London: BTA), which is planning to transfer millions of residential telephone customers to VOIP in the next few years (see BT Moves Ahead With Mega Project)

  • AT&T Corp. (NYSE: T), which was staking much of its future on supplying VOIP services to enterprises prior to the announcement of its planned merger with SBC Communications Inc. (NYSE: SBC) – see: Ma VOIP? and SBC to Buy AT&T for $16B

Overall, carrier investments in the infrastructure supporting VOIP services will grow by 39 percent a year and reach $4.8 billion in 2007, according to Infonetics Research Inc. (see Carrier VOIP Gear Sales Hit $450M).

The reasons for this surge in investment differ according to the type of service provider and the market it's tackling.

Residential Market

For incumbent telcos the challenge in the residential sector is to increase the average revenue per user (ARPU) in the face of declining POTS usage and revenue. Migrating their POTS infrastructure to VOIP and adding SIP feature servers is a necessary first step, but introducing packet voice over broadband is necessary to enable the new services to be exploited fully. This includes services to softphones on PCs and new terminals such as SIP phones.

Telcos also see a major opportunity to increase ARPU by adding derived voice lines to households.

For cable companies, packet voice over broadband is sometimes the only way to include voice in a triple-play service bundle. It is also a way of differentiating the bundle by offering more advanced voice services than telco competitors.

For all types of service provider, packet voice over broadband is a way of adding customers without building a hugely expensive access network, a fact that creates regulatory issues worldwide.

Business Market

In the business market, VOIP technology can be used to persuade companies to move to an outsourced voice communications service that goes far beyond the old Centrex capability.

The outsourced solution can still be marketed on the total cost of ownership and the low capital expenditure in a rapidly moving technology. It can be further differentiated from IP PBXs by:

  • Adding VOIP VPN and PSTN breakout

  • Including integrated PC applications

  • Making the services available on fixed, cordless phones or virtual phones similar to mobile or cellular phones

Packet voice over broadband also comes into its own for businesses with teleworkers or distributed small offices, as the same accessibility to hosted PBX/IP Centrex services can be offered.

Service providers need to think creatively to discover the most profitable of the numerous services that VOIP makes possible – VOIP is not POTS rewritten, but instead invites a new look at customers and their needs.

For example, VOIP allows services to have a mobile feel to them, so that the subscriber can be found, called, or spoken to as required. Examples are:

  • Find me/follow me

  • Simultaneous ringing

  • Walkie-talkie: push to talk

Equally important to the range of services is the capability for the subscriber to manage them personally, most likely through a Web portal, so that the services are shaped to personal requirements.

Both mobility and self management would be largely new for residential and SOHO customers – and potentially highly appealing.

For business customers, the picture will be different. On the SME side, VOIP VPNs are replacing existing TDM services, and so they are certainly required by newer service providers. A potentially big opportunity for service providers is to use VOIP to replace customer premises equipment (CPE) by outsourced services, and hosted IP PBX and VOIP Centrex are the key services here. Hosted IP PBX requires one softswitch per enterprise in the service provider network, while VOIP Centrex uses one service provider switch to support several outsourced enterprise voice networks.

Other services with high business potential are:

  • Integrated or unified messaging, which stores and treats voice messages similarly to emails, so they can be handled by a PC or other terminal.

  • PC telephony features, such as directory and other application integration, so that calls can be made from PC applications, and information relating to incoming calls be displayed in real time. The major added value with business services comes from integrated group applications and services. A good example of this is instant messaging and presence applications, such as name dialing and dial-when-present, because they show how deeply VOIP services can be integrated with a variety of other IP services.

Light Reading has categorized software products that furnish VOIP services in a past report (see Who Makes What: VOIP Applications Software). The report provides details of 176 products from 106 companies and forms the basis of an IP Services Software Directory scheduled to go live on the Light Reading Website in the coming weeks.

Broadband in "packet voice over broadband" usually means xDSL or cable-modem services, and these have some constraints compared to a direct fiber link to a large enterprise.

Access bandwidth is not usually a major issue, but limited bandwidth in a DSL upstream channel can cause unacceptable delay and jitter in VOIP traffic if small VOIP packets have to wait for long data packets to transit. This can be solved by one of three methods: using voice over ATM (VOATM) instead of voice over IP; using a separate ATM PVC for VOIP; or using IP packet fragmentation. All three methods have drawbacks in some situations.

The first question to ask about any "voice over X" technology is: What mechanisms ensure an adequate quality of service (QOS)? There are four key contenders for X: Asynchronous Transfer Mode (ATM), IP, Wireless LAN (WLAN), and (less plausibly) Multiprotocol Label Switching (MPLS).

The answer for VOATM is very positive, as ATM was designed to carry packet voice and was the first packet voice over broadband technology. Although now seen as expensive and old-fashioned, it is useful in triple-play over DSL systems as it removes the voice from the subscriber IP level and so simplifies the IP QOS handling of the remaining data and video traffic.

VOIP now has several QOS-handling capabilities such as marking, shaping, and scheduling. The delay issue generally goes away on links above about 1 Mbit/s, but there can still be problems at these speeds if there are a lot of traffic types of different priorities, as it can be difficult to achieve the analogous capability of ATM per-VC queuing.

QOS handling for voice over WLAN is being standardized in the IEEE, and this technology could prove very popular as it can be used in residential, enterprise, and hotspot applications, with cellphone convergence possibilities.

Voice over MPLS is a bit of an oddity, as it does not have the granularity to carry individual 64-kbit/s TDM voice streams, and voice will usually have become packets into IP by the time it hits an aggregation point that might be using MPLS.

On the terminal side, there are two approaches:

  • Standard POTS phone + ATA (analog telephone adapter) or gateway: The key technologies here are ATM BLES (broadband loop emulation service), IP MGCP, and H.248

  • VOIP terminals: PC or IP phone, using SIP (session initiation protocol) and H.323

Figure 1 shows a typical example of a residential DSL network delivering voice service. The entry-point terminal is a unit to which an analogue phone can be connected. These analogue telephone adapters (ATAs) were developed for ATM and IP technologies, and are shown as the voice-over-DSL and VOIP gateway and boxes – and the ATM ATA option is shown embedded in the routing gateway. The ATM units use the Broadband Loop Emulation Service (BLES) signaling standard, defined in annex A of DSL Forum Technical Report 36 (downloadable here). For voice over IP, the ATA contains a media gateway that can be controlled by MGCP or H.248.

65509_1.gifThe end target for packet voice terminals is the VOIP phone or the softphone implemented as a PC or PDA application. These use SIP or H.323 signaling, with SIP being preferred in this residential context and for future deployments. This is because they fit into the Internet paradigm of intelligence at the terminal, and they can support a much wider range of value-added services and applications.

Guaranteeing QOS for these services is still problematic, however, for several reasons:

  • There is very little QOS-enabled residential network equipment available or easily configurable. The ideal would be Ethernet switches with IEEE 802.1p prioritization.

  • The terminals would have to use the correct prioritization marking, and use DiffServ marking for the routing gateway to use.

  • Terminals are not trusted by the service provider, because the Diffserv system could be abused to give inappropriate traffic a high priority.

Session border controllers are needed for NAT/firewall traversal (see NAT-Traversal Issues).

Although many of the gateing issues of packet voice-over-broadband deployment involve technical and cost factors on residential premises, there are decisions to be made in the public network as well. Figure 1 shows the option of voice over ATM, which, while enabling the use of a simpler IP QOS regime for other traffic, does require the deployment of the packet-to-packet gateway (PPG) in the public network. This gateway converts voice over ATM to VOIP, and BLES to MGCP or H.248. Voice traffic transcoding may also be required. The two ATM PVCs per subscriber used in this system are shown by the light blue lines.

For other traffic, and for the VOIP options, the downstream QOS is handled by the B-RAS or edge router, which will most likely be an MPLS label edge router. The simplified core network shows the softswitch, which holds the service logic and subscriber database, and a media gateway. Not shown are application servers, media servers, signaling gateways, and other such functions.

Figure 2 shows an example similar to Figure 1, for an enterprise subscriber, and there are interesting similarities and differences with the residential configuration. The enterprise DSL service most often uses symmetric SHDSL running at 1 or 2 Mbit/s, and the enterprise will typically have its own NAT/firewall router. Otherwise, the routing gateway becomes the integrated access device (IAD), which often incorporates an ATM ATA. Other differences concern the deployment of session border controllers for NAT /firewall traversal (see NAT-Traversal Issues).

65509_2.gifWhile most of the world is deploying xDSL for broadband, the majority of broadband users in North America use cable modems on cable networks, which gives very different packet-voice capabilities. Figure 3 shows a typical example of a cable setup.

65509_3.gifThere is no ATM capability, so VOIP is the only possibility. Although there are some similarities in capability to DSL, there are probably more differences. The major similarity is that cable operators can deploy an MGCP ATA that has access to a guaranteed QOS channel to the cable modem termination system (CMTS) and core network. This uses the CableLabs DOCSIS 1.1 QOS system between the cable modem and the CMTS. The only standardized system is the CableLabs PacketCable system, illustrated in the top section of Figure 3, and this uses the PacketCable network-based call signaling protocol, which is a profile of MGCP. The standard specifies client ATAs or multimedia terminal adapters (MTAs), which can be standalone or more often embedded with a cable modem in an integrated telephony cable modem (ITCM). And, like the residential routing gateway, the NAT/firewall router can be integrated as well, creating what at least one vendor calls a cable access router. At the edge of the HFC access network, the CMTS terminates the DOCSIS systems and forwards traffic to a B-RAS or edge router.

An interesting point appears to be that only PacketCable MTAs can access the DOCSIS 1.1 QOS system for guaranteed voice quality. An earlier proprietary approach used an H.323 MTA with DOCSIS 1.0. So SIP phones and SIP softphones accessing the QOS system would appear to be ruled out, which would restrict the attractiveness of packet voice over cable services.

Another approach, shown in the lower section of Figure 3, is used by Vonage Holdings Corp. and others. With Vonage, a SIP MTA is embedded in a voice-terminal/router. The MTA could be connected by Ethernet into a regular home router, but that would jeopardize voice quality and raise the NAT-traversal issues. In the configuration in Figure 3, the MTA still cannot access the cable modem QOS capability, but it can give voice traffic from the MTA absolute priority over other data traffic, and it can bypass the NAT.

Network address translation (NAT) and firewalls in general create big problems for VOIP, as VOIP applications cannot be used across them because protocols such as H.323, MGCP, and SIP (all classed as badly-behaved protocols by the IETF) transfer information that includes media session endpoint IP addresses and UDP port numbers in different layers above OSI Layer 4 (IETF TCP/UDP). This information cannot be seen by a normal firewall or NAT, and so the subsequent sessions set up are not recognized, do not pass through firewalls, and have incompatible IP addresses across NAT boundaries.

There are a couple of workarounds, shown in Figure 4, deployed for residential subscribers, who usually have a broadband router with NAT and/or a firewall enabled. The latest and least expensive is to use a session border controller (SBC) at the edge of the IP network to perform far-end NAT traversal. This works for SIP by the SBC intercepting SIP registration messages and requesting the User Agent to re-register every 30 seconds. This keeps a pinhole open to the user agent so that the SBC can tell it when there is an incoming call. The H.323 protocol is far too complex for this technique, but a similar technique works for an MGCP NAT proxy.

65509_4.gifThe stronger but more expensive solution is to have a signaling proxy or application layer gateway (ALG) on the customer premises. This can be integrated in the routing gateway, as shown in Figure 4. This is effectively a residential SBC.

One interesting point is that traversal is not an issue for voice over ATM, or for an MTA not behind a NAT or firewall in a cable system.

The NAT/firewall-traversal issue for enterprise networks is usually different because there is usually an existing strong firewall that cannot be controlled by a firewall control protocol. The only way around this is to deploy a full session border controller, which can be located in the enterprise network behind the firewall, in the demilitarized zone (DMZ) as illustrated in Figure 5, or actually replacing the NAT/firewall. VOIP connections are then made in two halves: from the terminal on the enterprise network to the SBC, and from the SBC to the next hop in the public network, which may also be to an SBC. The connections usually tunnel through the NAT/firewall, as shown by the red line in Figure 5.

65509_5.gifEnterprise SBCs can also be used to make VOIP enterprise networks without involving the carrier VOIP system.

According to Gary Meyer, VOIP marketing manager of communications test-and-management solutions vendor Acterna Corp., many different components are needed to build a complete VOIP system, and each brings its own set of challenges.Figure 6 shows the major components that contribute to the challenges of VOIP. They are:

  • Enterprise/residential equipment

  • Last-mile or access line

  • Signaling gateway

  • Media gateway and TDM network

  • IP core network

65509_6.gifEnterprise/Residential Equipment

"One of the biggest issues in this area is that VOIP frequently has to contend with other traffic, such as that caused by viruses or server replication," says Meyer. "Network-element configurations can also cause problems – for example, if priority bits are incorrectly set. The overall result is that VOIP traffic can fail to obtain the sufficient network priority that its real-time mode requires for good QOS."

Related to this is the fundamental fact that networks in the past were designed for data applications (such as data replication), not real-time applications. Trying to overlay VOIP on these networks can easily cause call quality problems – transit delays can just be too great, for example. And there are the issues of firewall traversal and session border controller (SBC) misconfiguration, described earlier.

Access Line

The conventional last-mile network or access line brings a specific problem for VOIP. High-speed data services work successfully over this network because they use TCP, and lost packets are not a big issue as TCP is designed to recover from packet loss. But VOIP uses UDP, which does not have this capability, so that lost packets are truly lost. Because conventional access lines are inevitably lossy to some extent through signal degradations (HFC is particularly prone to signal degradation, for example), running a delay-sensitive application such as VOIP on these infrastructures can result in poor call quality from excess packet loss.

Signaling Gateway

In practice, most of the problems with signaling occur in the first 30 days of deploying a service, and are related to provisioning and equipment interoperability. Once the service deployment settles down and the provisioning processes are cleaned up, signaling does not usually become a big issue (this excludes the issues already covered of firewalls and other areas of network security).


"Probably the biggest issue here is echo," says Meyer. "Because TDM networks are so fast and reliable, any echo issues with them have effectively disappeared because the technology has long been developed to overcome them. However, when an IP network is introduced into the voice path, it can cause delays that in turn make echo more prominent. So echo cancellers that have been adjusted for TDM networks may not be set correctly to account for an IP network segment. This is due not only to the inherent delay within the IP segment, but also to changes that can occur over time to the latency of an IP network."

Media gateways can also degrade voice quality, and this can be a cumulative problem if multiple gateways lie in the voice path. Further, many advanced PSTN features are not available for VOIP-to-PSTN calls.

IP Core Network

The IP core is, or is becoming, the most controlled component of the VOIP network because route control and traffic management are absolutely critical. So, although there can be issues with routing and traffic management, this is rare. Further, because of the extensive network builds of a few years ago, there is still plenty of capacity in IP core networks to handle both data and VOIP traffic satisfactorily. And some cores are also deploying QOS mechanisms such as MPLS with class-of-service or DiffServ to ensure call quality. So, on balance, the core is not a problem area for VOIP – most of the service issues are on the periphery of the core.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like