VoIP Network Architectures

One benefit of VoIP technology is that it allows networks to be built using either a centralized or a distributed architecture. Corporate business requirements dictate the architecture and functionality that is required. This section discusses centralized and distributed architectures and the gateway requirements to support these architectures in enterprise and service provider environments.

Support for protocols, signaling capabilities, voice features, and voice applications is changing and growing quickly. You must have a good understanding of voice network architectures to know which business requirements each architecture addresses. Also, gateways play an important role in providing access to the right mix of functionality. You must understand the main features and functions required in enterprise and service provider environments to choose the appropriate gateway.

Centralized Network Architectures

One benefit of VoIP technology is that it works with centralized and distributed architectures. This flexibility allows companies to build networks characterized by both simplified management and endpoint innovation. It is important to understand the protocols that are used to achieve this type of VoIP network agility.

The multisite WAN model with centralized call processing, as illustrated in Figure 5-2, consists of the following components:

Central gateway controller (call agent) The call agent handles switching logic and call control for all sites under the central controller. A central gateway controller includes both centralized configuration and maintenance of call-control functionality. When new functionality needs to be added, only the controller needs to be updated.
Media gateways Media gateways provide physical interconnection between the telephone network, individual endpoints, and the IP network. Media gateways communicate with the call agent to notify it of an event. An example is a telephone going off hook. The gateway also expects direction from the call agent on what action to take as a result of the event. For example, the call agent tells the gateway to provide a dial tone to the port that sees the off-hook condition. After the call-control exchange is completed, the gateways route and transmit the audio or media portion of the calls. This is the actual voice information.
IP WAN The IP WAN carries both call control signaling and voice payload between the central site and the remote sites. QoS configuration is highly recommended when voice packets are transported across a WAN to ensure that the voice packets get priority over data packets in the same network. To minimize bandwidth use for voice streams that are crossing the WAN, the G.729 coder-decoder (CODEC) is used to compress the voice payload. G.729 compresses voice to 8 kbps per call as opposed to the 64 kbps traditionally used in LAN and PSTN environments.

Figure 5-2. Centralized Network Architectures

Centralized call-processing deployments typically offer the following characteristics:

MGCP or Megaco/H.248 protocol for call control
Cisco CallManager at central site for managing call control
Centralized applications pointed to by remote sites
Up to 30,000 IP phones per cluster
Call Admission Control (CAC) to limit number of calls per site
Survivable Remote Site Telephony (SRST) for remote branches

A typical use for centralized architecture is a main site with many smaller remote sites. The remote sites are connected via a QoS-enabled WAN but do not require full features and functionality during a WAN outage. MGCP and Megaco/H.248 are the prevalent signaling protocols used in centralized architectures to control gateways and endpoints.

Applications such as voice mail and IVR systems are typically centralized to reduce the overall cost of administration and maintenance.

Cisco CallManager clusters can support up to 30,000 IP phones per cluster, providing for a scalable solution in enterprise environments. For even more scalability, clusters can be interconnected via intercluster trunks.

CAC is administered by the Cisco CallManager cluster. CAC is critical in enterprise implementations that include WAN connections because these connections typically have limited bandwidth that is shared between voice and data users. Control must be established over the number of calls that can flow concurrently across the WAN at any given time so that as the call volume grows, overall call quality does not diminish.

One disadvantage of implementing a centralized architecture is that if the WAN connection fails between the remote site and the central site that houses Cisco CallManager, no further voice calls can be processed by the remote site. Additional steps need to be taken to ensure that data and voice services at the remote sites remain available. One option is to implement redundant WAN links between the remote sites and the central site. In many cases, this solution is not financially feasible. Alternatively, Survivable Remote Site Telephony (SRST) provides high availability for voice services. SRST provides a subset of the call-processing capabilities within the remote-office gateway. It also enhances the IP phones with the ability to "re-home" to the call-processing functions in the local gateway if a WAN failure is detected. This feature allows the remote site to continue to provide voice connectivity in the absence of the WAN link.

Most centralized VoIP architectures use MGCP or Megaco/H.248 protocols. You can also build session initiation protocol (SIP) or H.323 networks in a centralized fashion. This is done using back-to-back user agents (B2BUAs) or gatekeeper-routed call signaling (GKRCS), respectively.

Figure 5-2 shows a typical centralized call-processing deployment, with a Cisco CallManager cluster acting as the call agent at the central site and an IP WAN with QoS enabled to connect all the sites. The remote sites rely on the centralized Cisco CallManager cluster to handle their call processing but have local voice-enabled routers to perform the voice-gateway translations for media streams. Each remote site connects locally to the PSTN. Long-distance (LD) service might be provided from the head office or through each local PSTN connection.

H.323 Distributed Network Architectures

The multisite WAN architecture with distributed call processing consists of multiple independent sites. Each site has its own call-processing agent, which is connected to an IP WAN that carries voice traffic between the distributed sites.

Each site in the distributed call-processing architecture using H.323 can be comprised of one of the following:

A single site with its own call-processing agent
A centralized call-processing site and all its associated remote sites
A legacy PBX with a VoIP gateway

Figure 5-3 provides an example of a distributed call-processing architecture. Notice, in the figure, that each site contains its own call-processing agents (in the form of CallManager clusters). This type of call-processing approach has the following characteristics:

No call control signaling for intrasite and off-net calls through the IP WAN
Transparent use of the PSTN if the IP WAN is unavailable
Logical hub-and-spoke topology for the directory gatekeeper
Only one type of CODEC configured for the IP WAN

Figure 5-3. Distributed Network Architectures

Multisite distributed call processing allows each site to be completely self-contained. The IP WAN in this model does not carry call-control signaling for intranet and off-net calls because each site has its own Cisco CallManager cluster. Typically, the PSTN serves as a backup connection between the sites in case the IP WAN connection fails or does not have any more bandwidth available.

Distributed architectures are associated with H.323 and SIP protocols. These protocols allow network intelligence to be distributed between endpoints and call control devices. Intelligence in this instance refers to any aspect of call handling including the following:

Call state
Calling features
Call routing
Provisioning
Billing

The endpoints can be VoIP gateways, IP phones, media servers, or any device that can initiate and terminate an H.323 VoIP call. The call control devices are called gatekeepers (GKs) in an H.323 network. In an enterprise environment where many gatekeepers are required, a second level of hierarchy is achieved through the use of directory gatekeepers (DGKs). Directory gatekeepers provide summarization capabilities for multiple configured gatekeepers.

The multisite WAN architecture with distributed call processing consists of the following components:

Media gateways Media gateways provide physical interconnection between the telephone network, individual endpoints, and the IP network. The media gateway translates call signaling between the PSTN or local endpoints and the IP network. The media gateway must contain the call-processing intelligence to perform all call-handling functions related to H.323. Media gateways communicate with gatekeepers for call address resolution and CAC.
Gatekeeper A gatekeeper is an H.323 device that provides CAC and E.164 number resolution. Gatekeepers are among the key elements in the multisite WAN model that have distributed call processing. Gatekeepers provide dial plan resolution, which improves scalability in an H.323 network. Without gatekeepers, each gateway would need to be configured to know where all other reachable telephone numbers were located. The gatekeeper provides a central repository of telephone numbers and the gateways associated with those numbers. When the network is configured for gatekeepers, the learning process is dynamic, because all participating gateways register with the gatekeeper and notify it of available telephone numbers. The gatekeeper also provides CAC to ensure that voice quality is not diminished when a large number of calls enter the network.
IP WAN The IP WAN carries call control signaling and voice payload for intersite voice communication only. Call signaling and voice transmission for all intrasite calls and off-net calls that are going to the local PSTN remain local to the site. QoS configuration is highly recommended when voice packets are transported across a WAN, to ensure the voice packets get priority over data packets in the same network. As in the centralized system, to minimize bandwidth use for voice streams that are crossing the WAN, the G.729 CODEC is typically used to compress the voice payload. G.729 compresses voice to 8 kbps per call as opposed to the 64 kbps that is traditionally used in LAN and PSTN environments.

Few implementations of call control are totally distributed. Although H.323 and SIP operate in a purely distributed mode, for scalability reasons both are most often deployed with common control components that give endpoints many of the advantages of a centralized call control environment. As a result, these implementations also inherit many of the disadvantages of centralized call control.

SIP Distributed Network Architectures

The rapid evolution of voice and data technology is significantly changing the business environment. The introduction of services such as instant messaging, integrated voice and e-mail, and follow-me services has contributed to a work environment where employees can communicate much more efficiently, thus increasing productivity. To meet the demands of the changing business environment, businesses are beginning to deploy converged voice-and-data networks based on SIP.

SIP was originally defined in 1999 by the Internet Engineering Task Force (IETF) in RFC 2543. SIP is the IETF standard for multimedia conferencing over IP, and SIP is an ASCII-based, application-layer control protocol that can be used to establish, maintain, and terminate calls between two or more endpoints. Service development in the SIP environment is made easier because of its use of, and similarity to, Internet technologies such as HTTP, Domain Name System (DNS), and addressing in the form of e-mail addresses. SIP enables the integration of traditional voice services with web-based data services, including self-based provisioning, instant messaging, presence, and mobility services.

A SIP-based network is made up of several components, as depicted in Figure 5-4, including:

SIP user agent Any network endpoint that can originate or terminate a SIP session. This device could be a SIP-enabled telephone, a SIP PC client (known as a softphone), or a SIP-enabled gateway.
SIP proxy server A call control device that provides many services, such as routing of SIP messages between SIP user agents.
SIP redirect server A call control device that provides routing information to user agents when requested, giving the user agent an alternate uniform resource identifier (URI) or destination user agent server (UAS).
SIP registrar server A device that stores the logical location of user agents within that domain or subdomain. A SIP registrar server stores the location of user agents and dynamically updates its data via REGISTER messages.

Figure 5-4. SIP Network Components

Additionally, SIP provides the following capabilities:

Determines the location of the target endpoint SIP supports address resolution, name mapping, and call redirection.
Determines the media capabilities of the target endpoint Via the Session Description Protocol (SDP), SIP determines the "lowest level" of common services between the endpoints. Conferences are established using only those media capabilities that can be supported by all endpoints.
Determines the availability of the target endpoint If a call cannot be completed because the target endpoint is unavailable, SIP determines whether the called party is already on the phone or did not answer in the allotted number of rings. SIP then returns a message that indicates why the target endpoint was unavailable.
Establishes a session between the originating and target endpoint If the call can be completed, SIP establishes a session between the endpoints. SIP also supports midcall changes, such as the addition of another endpoint to the conference or the changing of a media characteristic or CODEC.
Handles the transfer and termination of calls SIP supports the transfer of calls from one endpoint to another. During a call transfer, SIP simply establishes a session between the transferee and a new endpoint specified by the transferring party. SIP then terminates the session between the transferee and the transferring party. At the end of a call, SIP terminates the sessions between all parties.

As a protocol used in a distributed architecture, SIP allows companies to build large networks that are scalable, resilient, and redundant. The SIP protocol provides mechanisms for interconnecting with other VoIP networks and for adding intelligence and new features on either the endpoints or the SIP proxy or redirect servers.

Comparing Network Architectures

Both the centralized and distributed models have advantages and disadvantages. Features that are considered advantages of one type of call control model might be disadvantages of the other type. The main differences between the two models are in the following areas:

Configuration The centralized call control model provides superior control of the configuration and maintenance of the dial plan and endpoint database. It simplifies the introduction of new features and supplementary services. The centralized call control model also provides a convenient location for the collection and dissemination of call detail records (CDRs).
The distributed model requires distributed administration of the configuration and management of endpoints. This approach complicates the administration of a dial plan. Distributed call control simplifies the deployment of additional endpoints while making new features and supplementary services difficult to implement.
Security Centralized call control requires that endpoints be known to a central authority. This approach avoids or reduces security concerns.
The autonomy of endpoints in the distributed model elevates security concerns.
Reliability The centralized model has two points of vulnerability: single point of failure and contention. It places high demands on the availability of the underlying data network, possibly requiring a fault-tolerant WAN design.
The distributed call control model minimizes the dependence on shared common control components and network resources. This approach reduces exposure to single points of failure and contention for network resources.
Efficiency Centralized call control fails to take full advantage of call routing intelligence that resides in the endpoints. It also consumes bandwidth through the interaction of the call agent and its endpoints.
Distributed call control takes advantage of the inherent call routing intelligence in endpoints.

Because the centralized model is more sensitive to IP WAN outages, a centralized model design mandates the implementation of survivability and load management strategies. Few implementations of call control are totally distributed. For example, H.323 and SIP operate in a purely distributed mode, but for scalability reasons, both are most often deployed with common control components that give endpoints many of the advantages of a centralized call control environment. Unfortunately, these implementations also inherit many of the disadvantages of centralized call control.

Simple Multisite IP Telephony Network

To help solidify the concepts of the various call-processing models, consider a case study company, Span Engineering LLC. Span Engineering LLC is migrating to a Cisco IP telephony solution. It has three sites in the United States and a fourth site in Brazil. Figure 5-5 shows the distributed architecture implemented by Span Engineering. Notice in the figure that Post, Telephone, and Telegraph (PTT) is the international term for PSTN. Also, the term LD refers to a long-distance network.

Figure 5-5. Distributed Architecture: Span Engineering Case Study

Span Engineering is a company based in the United States, with headquarters in Chicago and branches in Dallas and on the west coast of the United States. It has recently expanded internationally to Sao Paulo, Brazil. The plan for migrating to Cisco IP telephony includes eliminating all PBXs and migrating to full VoIP in the near future. The overall deployment model used by Span Engineering is multisite distributed and contains both centralized and single-site locations:

Centralized call control (Chicago) Span Engineering has three separate locations in Illinois, with the Chicago location serving as the headquarters. A centralized network architecture is used for the Illinois sites. The Cisco CallManager cluster in Chicago manages call address resolution and CAC for the three Illinois locations.
Centralized call control (West Coast) Span Engineering has recently acquired three West Coast companies. The companies consist of a 12-story location in San Francisco, a 2-story location in Oakland, and a single-story location in San Jose. The San Francisco location houses the Cisco CallManager cluster that serves all three West Coast locations.
Single-site call control (Sao Paulo and Dallas) Span Engineering currently has no plans to expand in these locations but wants to ensure high availability of voice communication capabilities. The company has chosen to put Cisco CallManager clusters in each of these locations as single-site locations. Both the Dallas and Sao Paulo sites have local connections to telephone service providers for local dial tone. In nonNorth American countries, the telephone service provider is referred to as the PTT provider.

Interconnecting VoIP Protocols

Just as companies choose various protocols for their data networks based on business and technical requirements, they also need to choose one or more protocols for their VoIP requirements. In an environment where more than one VoIP protocol is present, companies must support the interconnection between the differing VoIP protocols.

Choices for interconnecting the segments that use differing VoIP protocols typically fall into one of the following three categories:

Translation through TDM In this method, a company uses either TDM equipment or VoIP gateways to translate from one protocol domain to another. The benefit of this method is the widespread availability of devices that provide this translation. The downside is that it introduces latency into the VoIP network and introduces an additional translation (TDM) into the voice path between two protocol domains. This method is usually considered a short-term solution until VoIP translators become available.
Single-protocol architecture In this method, a company moves all its VoIP devices and services to a single protocol, simplifying the network as a whole. The downside to this approach is that it might not be possible to migrate existing equipment to support the new protocol. This situation can limit the ability of the company to take advantage of some existing services. In addition, this method limits the potential connectivity to other networks that are using other VoIP signaling protocols.
Protocol translation In this method, a company uses IP-based protocol translators to interconnect two or more VoIP protocol domains. IP translators allow a company to retain the flexibility of using multiple VoIP protocols. They do not introduce the delay problems that additional TDM interconnections do. IP translators also do not require the wholesale replacement of existing equipment.
The negative aspect of this approach is that there is no standard for protocol translation. Not all VoIP protocol translators are exactly the same. Although the IETF attempted to define a model for translating H.323 to SIP, this model involves more than just building a protocol-translation box. Vendors of protocol translators need in-depth knowledge of all the protocols that are being used in the VoIP network. They must be aware of how various VoIP components use different aspects of the protocol. For example, H.323 and SIP can send dual-tone multifrequency (DTMF) digits in either the signaling path or the media path via RTP. H.323 mandates only that the H.245 signaling path be used. SIP does not specify how DTMF should be carried. This design means that SIP devices could be sending DTMF in the media path (RFC 2833) and H.323 devices could be sending DTMF in the signaling path (H.245). If the VoIP protocol translator cannot properly recognize both the signaling path and the media path, the protocol translator might not function properly.

Understanding Gateways

A gateway is a device that translates one type of signal to a different type of signal. There are different types of gateways, including the voice gateway, as illustrated in Figure 5-6.

Figure 5-6. Gateway Interfaces

A voice gateway is a router or switch that converts IP voice packets to analog or digital signals that are understood by TDM trunks or stations. Gateways are used in several situations (for example, to connect the PSTN, a PBX, or a key system to a VoIP network).

In Figure 5-6, the voice-enabled router (that is, the voice gateway) examines the incoming IP packet to determine whether it is a voice packet and determine the packet's destination. Based on information inside the voice packet, the router translates the digitized signal or voice into the appropriate analog or digital signal to be sent to the PSTN. For a call coming from the PSTN, the gateway interprets the dialed digits and determines the IP destination for the call.

Guidelines for Selecting an Appropriate Gateway

Understanding gateways and being able to select the correct gateway out of numerous gateway options is challenging. Factors to consider include the protocols that are supported, the density and types of interfaces on the gateway, and the features that are required. Knowing the requirements will guide you to the correct solution.

One criterion involves defining the type of site that the gateway supports. Is it a small office/home office (SOHO), branch office, enterprise campus environment, or service provider? Each type of site has its own set of requirements.

A key objective is to identify the number and type of voice interfaces that are necessary and to verify the protocol support. Are supplementary services supported? Which CODECs must be supported? Is fax relay necessary? Many of these functions are features of specific Cisco IOS software releases. Identification of the proper IOS software release necessary to support the features is critical.

Another key consideration is whether the gateway is acting as a gateway only or needs to combine the functions of gateway and router within one device. This will point to a specific set of hardware and software.

When planning gateways for placement in other countries, verify that the device meets the government standards for PSTN connection in that country. If the device supports encryption capabilities, verify the legality of export to the destination country.

For example, consider a network where the requirements are to support Foreign Exchange Station (FXS) and E&M connections. The trunk is to be a T1 PRI from the PBX. In this case, a suitable choice would be a Cisco 3745 Multiservice Access Router with a two-slot voice network module (VNM), 1 FXS voice interface card (VIC), 1 E&M VIC, and a High Density Voice (HDV) module.

Enterprise Central and Remote Site Gateway Interconnection Requirements

As IP telephony services become a standard in the corporate setting, a broad mix of requirements surface in the enterprise environment. The IP telephony deployment is typically initiated by connecting to the PSTN to manage off-net calls while using a Cisco CallManager infrastructure to manage on-net calls.

Table 5-3 shows example questions that you might ask to determine the requirements for gateway interconnections.

Table 5-3. Determining Gateway Interconnection Requirements
Question	Reasoning
How do you control the gateways?	You must ensure support for proper call processing, such as MGCP, SIP, or H.323.
Is cost an issue?	Distributed call processing is easier to implement, but costs are higher when deploying intelligent devices at each site.
Is remote site survivability an issue?	Remote site survivability is not an issue with a distributed model unless there is a need for redundancy. This is an issue for a centralized model that can be addressed by providing SRST. This means ensuring that the version of Cisco IOS software supports the feature.
Are gatekeepers in the design, and if so, how are the zones structured?	Gatekeepers are normally used in enterprise sites for scalability and manageability. The design must include proper planning for zone configurations.
Are the gateways switches or routers?	This question determines how other features, such as QoS, are implemented. Numerous switches and routers are available that have voice gateway functionality along with other core services. These services include Layer 2 and Layer 3 QoS implementations, inline power, and security features.
How will fax and modem transmission be supported?	In a Cisco environment, fax support options include Cisco Fax Relay, T.37, T.38, and Fax Pass-Through. Modem support options include Cisco Modem Relay and Modem Pass-Through.

At the central site, several specific issues need addressing. These issues include:

Dial plan integration Consistent reachability demands that the new dial plan for the IP voice network must integrate with the existing dial plan. It is essential that you have a thorough understanding of how the dial plans interact.
Voice-mail integration After a voice-mail application is selected, the designer must ensure that all users can seamlessly reach the voice mail server. It is also vital that all incoming calls be properly forwarded when the recipient does not answer the telephone. This might mean dedicating gateway connections for an existing voice mail server or dedicating an entire gateway for the express purpose of voice mail server integration.
Gateway for PBX interconnect When the IP voice network interconnects PBXs, the designer must determine which type of connection is supported by the PBX and which gateway will support that connection.
Inline power requirements for IP phones When the design includes IP phones, you need to consider the power requirements. In many cases, it is desirable to provide inline power to the telephones. A number of devices provide inline power, such as routers, switches, and midspan devices. A midspan device sits between an IP phone and a switch and injects in-line power over the non-Ethernet leads, in the cable connecting back to the IP phone. The decision about in-line power requirements is based on capacity and the current power options.

Service Provider Gateway Interconnection Requirements

Service providers must provide a level of service that meets or exceeds PSTN standards. The gateways that service providers implement must offer reliable, high-volume voice traffic with acceptable levels of latency and jitter. The following functions address those requirements:

Signaling interconnection type SS7 interconnect supports a high volume of call setup and benefits from redundant interconnect capabilities directly into the PSTN network.
Carrier-class performance Carrier-class performance can be provided through the proper redundant design for high availability, in addition to the proper implementation of QoS features, to ensure acceptable delay and jitter.
Scalability Scalability is a critical factor in the service provider arena. Customers requesting network access should be serviced promptly. Choosing a gateway with capacity for rapid growth is an important design decision. Gateways can scale upward to T3 capabilities for large-scale environments.

Consider a scenario where an IP telephony service provider needs to upgrade its existing gateway platforms because of business growth. The service provider sells a managed IP telephony service to small- and medium-sized businesses and provides connections to many different low-cost, long-distance carriers. Their issues are call quality over the IP network. Delay and jitter need to be controlled. Service providers must also consider scalability and the ability to provide differentiated levels of service through QoS. They also need connectivity to the SS7 networks of long-distance carriers to reduce costs. Finally, the service provider needs to consider the overall cost of implementation. SS7 capabilities and a redundant design enable the service provider to deliver a reliable level of service.

Practice Scenarios: Network Architecture

Throughout this chapter, practice scenarios will help reinforce what you have learned. In this scenario, Span Engineering is assessing VoIP network architectures and reviewing components and functionality associated with each type of architecture. Your task is to view each scenario and determine the network architecture type and the protocols that are commonly used in support of the network architecture.

Practice Scenario 1: Network Architecture and Protocol Selection

The network shown in Figure 5-7 has the following characteristics:

Cisco CallManager acts as the call agent.
The voice gateway provides physical connectivity for end devices.
The voice gateway does not contain full call-signaling protocol implementation.
The call agent manages voice gateways.
Call control signaling for all calls crosses the IP WAN.
CAC limits the number of calls per site.
SRST is used for remote branches.

Figure 5-7. Practice Scenario 1

Based on the figure and on the preceding characteristics, identify the network architecture type and protocols that are commonly used to support that architecture.

Network architecture: ____________________________

Protocols: _____________________________________

Practice Scenario 2: Network Architecture and Protocol Selection

The network shown in Figure 5-8 has the following characteristics:

The voice gateway provides physical connectivity for end devices.
The voice gateway performs call setup and teardown.
Gatekeepers provide call control and dial-plan resolution.
No call control signaling exists for intrasite and off-net calls through the IP WAN.

Figure 5-8. Practice Scenario 2