Chapter 4: Designing a Solution

This chapter introduces a variety of issues that must be considered in designing a Cisco ASAP Solution, in particular because this solution provides for a mix of voice and data, as well as specific services.

H.323 Network Issues

IP telephony networks of any considerable size will require a network signaling protocol such as H.323, SIP, or MGCP to support resource management, call routing, and security, among other features. H.323 is currently the de facto standard required for voice services, although it provides optional support for data and voice. Initial releases of the Cisco ASAP Solution support large-scale H.323 networks only (see Cisco H.323 Gatekeepers and Directory Gatekeepers), although support will later be provided for networks that rely on protocols such as SIP and MGCP. Issues related to the design of H.323 networks are documented in the Cisco Wholesale Voice Solution Design and Implementation Guide, available at the following URL:

In the that document, Chapter 2, "Provisioning the Gatekeeper Core," provides a good discussion of H.323 design issues, including the roles of the gateway (GW), gatekeeper (GK), and directory gatekeeper (DGK).

Dial Plans and Number Normalization

Unified Dial Plans

A dial plan is essentially a telephony call routing plan for an IP network. The dial plan is the method by which individual blocks of telephone numbers (technically, E.164 addresses) are assigned to physical facilities, or circuits. For large-scale service provider networks, dial plans consist of the following:

•

The normalization, prefixing, and digit stripping of telephone numbers (number translation or "normalization") at the POP GWs

POTS dial peers define the phone numbers or prefixes of attached telephony devices, and the VoIP dial peers define the IP address of the remote device (H.323 GW, GK, or endpoint) that is connected to remote phone numbers. POTS dial peers will always point to a voice port on the router, while the destination of a VoIP dial peer will always be the IP address of a device that can terminate the VoIP call.

Note

Dial plans for VoIP are well-documented. For additional discussion, including design methodology, refer to Dial Plans and Number Normalization in Chapter 2, "Provisioning the Gatekeeper Core," of the Cisco Wholesale Voice Solution Design and Implementation Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm

With the data and voice features of UGs, a unified dial plan is required, in order to support both voice and dial numbers. A unified dial plan differentiates services on a call-by-call basis.

With the Cisco ASAP Solution, Cisco IOS dial peers are used to build a call routing plan. The designer must be able to associate a DNIS with a service. In this case, the DNIS (incoming called-number) is used as the foundation of a dial peer match. If a match is made, the call is handled according to dial-peer parameters; if not, it is simply handled as a dial call. However, a dial access number must not match a dial peer, as in the following example for a debit card dial peer but with a DNIS of 4085552000—destined for dial service.

Note

The software design is such that a failure to match a dial call with a dial peer will automatically cause the dial call to be treated as a modem call.

Number Normalization

Number normalization (or translation) is a term for the prefixing or digit stripping of telephone numbers at the POP GWs. It generates consistent number formats in the core, simplifying GW dial-peer complexity, reducing the number of dial peers, and minimizing prefix configurations on the GKs. Number normalization is performed on the ingress GW before a call enters the VoIP network, and on the egress GW, before the call enters the PSTN. Translation rules and prefixing are applied in accordance with local dialing patterns.

Note

For more information about translation rules, including examples, refer to Configuring Translation Rules on the Gateways in Chapter 2, "Provisioning the Gatekeeper Core," of the Cisco Wholesale Voice Solution Design and Implementation Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm

Dynamic Call-by-Call Handling

In addition to being able to accommodate a variety of different numbering plans, the network designer must be able to map incoming calls to a variety of service applications as appropriate for each call. For example, for a prepaid calling-card service, prompts would have to be provided in, say, Chinese or English, depending upon (for the most part) the home country of the subscriber. To enable a variety of interactive responses, scripts are required.

Call Control Scripts

The Cisco ASAP Solution will use call control scripts written in one of two scripting languages: Cisco TCL IVR (Tool Control Language Interactive Voice Response) scripts are currently supported, whereas VXML (Voice eXtensible Markup Language) scripts will later be supported. Both of these, invoked by dial peer port or DNIS parameters, will play a significant role in the services enabled by UGs, in particular with respect to unified messaging and mobile applications where only voice interaction is practical. Both languages are readily accessible open standards, and provide the following advantages:

Cisco TCL IVR

IVR consists of simple voice prompting and digit collection to gather caller information in order to authenticate the user and identify the destination. IVR applications can be assigned to ports, or can be invoked on the basis of DNIS. An IP PSTN GW can have a variety of IVR applications to accommodate different services, and different interfaces can be presented to different callers. Cisco TCL IVR uses Tool Control Language scripts to gather information, as well as to process accounting and billing.

Note

For more information about Cisco TCL IVR, including a discussion of the TFTP servers required to support the files, refer to Provisioning Services to Support IVR, in Chapter 3, "Provisioning Shared Support Services," of the Cisco Wholesale Voice Solution Design and Implementation Guide.

VXML

VXML (also referred to as VoiceXML), a markup language like HTML, is an extension of XML for voice applications. It runs on an HTTP server and enables voice browsers. Voice browsers are similar in function to standard visual browsers, except that they both interpret voice commands and can either issue synthesized audio prompts or play prerecorded digital audio files. They can also interpret DTMF tones from a keypad.

Note

The VXML specification is available at the following URL:
http://www.w3.org/TR/voicexml/

The VoiceXML Forum (sponsored by IEEE-ISTO) provides additional information at the following URL:
http://www.voicexml.org

SS7 Interconnect

Where SS7 must be supported, the Cisco ASAP Solution relies on the Cisco SS7 Interconnect for Voice Gateways Solution. That solution is a distributed system that provides SS7 connectivity for H.323 VoIP access gateways, by using the Cisco Signaling Controller (also known as the Cisco SC2200) and access gateways as a bridge from the H.323 IP network to the PSTN. The Cisco SS7 Interconnect for Voice Gateways Solution interacts over the IP network with other Cisco H.323 VoIP access gateways; it can also interoperate with H.323 endpoints by using non-SS7 signaling, as in ISDN PRI and channelized T1.

For the most current information about SS7 connectivity as it relates to the Cisco ASAP Solution, refer to the discussion of the Cisco SS7 Interconnect for Voice Gateways Solution, Release 1.1. That solution is described in detail at the following URL:

For an example architecture, refer to Chapter 5, "Provisioning SS7-based POPs," in the Cisco Wholesale Voice Solution Design and Implementation Guide at the following URL:

The same Cisco SC2200 node can be used to support both voice and dial traffic, in either distributed or centralized architectures. Redundancy is inherent in SS7 signaling architectures. The Cisco SC2200 hosts can either be colocated with the GWs, or distributed, so that the Cisco SC2200s are remote with respect to the GWs and the SLTs are remote with respect to the Cisco SC2200s. In any architecture, however, the network must meet requirements for delay, QoS, and loss.

Network Design Guidelines

This section discusses a variety of principles that must be considered in designing a Cisco ASAP Solution network. The guidelines cover the following general areas:

Guidelines for Individual Components

The following discusses design issues that relate to GWs, GKs, and Cisco SC2200 nodes, respectively.

Guidelines for Gateways

With respect to GWs, in a truly mixed environment, it is important to design to universal port numbers. Use enhanced call admission control (see Call Admission Control and RSVP) to ensure the availability of resources in GWs and across the network.

Guidelines for Gatekeepers and Directory Gatekeepers

With respect to GKs, in a voice-only environment, use DGKs to minimize the need to manage configurations on individual GWs, while also simplifying expansion.

Guidelines for Cisco SC2200 Nodes

With respect to a Cisco SC2200 node in a mixed environment, you must take care to accommodate both voice and dial calls. There are two optimization models: one for simultaneous calls, the other for calls per second (CPS). Deciding on which parameter to optimize will depend on understanding your statistical traffic types.

Caution

There are a variety of issues related to optimizing traffic on a Cisco SC2200 node, and you should always consult with your Cisco account representative regarding best practices and to ensure that traffic availability is not impaired. For a general discussion of these issues that will assist you in understanding the tradeoffs, see Optimizing the Performance of the Cisco SC2200, page 2-4.

Solution Resilience

Resilience in networks is achieved through general redundancy—in routes, physical connections, solution components, and uninterruptible power supplies (UPSs), as well as in the software that provides intelligent fault detection and quick failover to healthy components. In SS7 applications, redundant signaling equipment (Cisco SC2200 signaling controllers, Cisco SLT) is required, as are other components throughout the SS7 network.

In large GK-deployment networks, there are three principle ways to provide resilience through fault tolerance (also known as continuous service):

This provides fault tolerance at the GK and DGK level, but is especially effective when applied at the DGK level.

This allows a GW to use up to two alternate GKs as a backup in case a primary GK fails. The GWs are configured to register to a primary and an alternate GK. If the primary GK fails, the alternate GK can then be used for call routing.

This provides coverage while HSRP failover detection is taking place. Here, local GKs are configured to point to an alternate DGK, which in turn can be used to back up an HSRP DGK pair.

Traffic Engineering

A variety of issues must be considered with the advent of UGs and universal service. Some practical guidelines are presented below.

Convergence and Migration Considerations

Although building a network from scratch offers many advantages, the practical case is that networks expand upon their existing base. With the Cisco ASAP Solution, this means that dial services will be added to existing voice services, or that voice services will be added to existing dial services.

Adding Dial to a Voice Network

In adding dial services to an existing voice network, realize that the longer hold times and larger packets associated with data connections will increase the demand for bandwidth. It becomes important to ensure that voice quality is maintained through quality of service (QoS) monitoring and applications.

Adding Voice to a Dial Network

The shorter call hold times and smaller packets associated with voice place greater demands on CPUs throughout the network. In addition, maintaining voice QoS demands tightly controlled delay, loss, and jitter parameters.

Achieving End-to-End Quality of Service

Given that latency and other characteristics of burdened traffic in a network can be forgiving with respect to data, the primary objective of any network must be to achieve and maintain QoS for voice traffic. The following general guidelines must be adhered to:

•

Ideally, there should be no lost packets. The default G.729 codec requires less than 1% packet loss.

Contention

Contention is a collision of demands, and takes a variety of forms: over resources (CPU, DS0), as well as over links (between voice and voice and voice and data calls).

Contention issues cannot be ignored in a network design. Among the contention domains, contention can occur at the UG/PSTN interface, the UG/network edge interface, the edge/core (GK to DGK) interface, and in the core itself. At the link level, voice can contend with data, but voice can also contend with voice if overall bandwidth is not sufficient.

Table 4-1 lists the contention types, as well as their remedies, all of wich are Cisco IOS features. The features are introduced briefly below.

Note

These features are discussed in greater detail in Chapter 3, "Using Management and Shared Support Services," of the Cisco ASAP Solution Implementation Guide.

Table 4-1 Contention Types and Remedies
Contention Type	Remedy	Where Applied
Resource	Call admission control (CAC)	GW
Voice/voice	Resource Reservation Protocol (RSVP)	GW, access network
Voice/voice	RSVP-based CAC	GW, access network
Voice/data	IP precedence	GW
	Low latency queuing (LLQ)	GW, access network, core
	RSVP/LLQ integration	GW, access network

Call Admission Control

When too much data traffic burdens a particular network link, techniques such as queuing, buffering, and packet dropping can relieve the congestion. The extra traffic is simply delayed until the interface is once again available, or, if packets are dropped, either the protocol or the end user initiates a timeout and requests retransmission.

With real-time traffic such as voice, this is not acceptable. Both latency and packet loss jeopardize the QoS expected by users. For delay-sensitive traffic such as voice, it is better to deny network traffic at the outset under certain conditions. Call admission control (CAC) is a set of voice-specific mechanisms designed to do this.

CAC, administered on the GW or NAS, ensures that resources available before the call is answered or completed. There are two forms of CAC: basic and enhanced. The enhanced version has capabilities for monitoring more UG and network resources. Table 4-2 summarizes the features in each form of CAC.

Note

For more information and provisioning details, refer to Chapter 3, "Using Management and Shared Support Services," of the Cisco ASAP Solution Implementation Guide.

Table 4-2 Basic and Enhanced CAC
Basic	Enhanced
PSTN side: •On UGs, monitors DS0s, DSPs, and HDLC framers •Calls not delivered/accepted if any set of required resources are all in use •Enabled by default	UG resources: •Monitors UG health resources •Has call treatment options •Has call rate restrictions
Network side: •On UG, monitors DS0s and DSPs •UG uses RAI to inform GK when threshold is exceeded •Enabled through CLI	Network resources: •Monitors end-to-end bandwidth •Monitors end-to-end voice quality

Resource Reservation Protocol

Resource Reservation Protocol (RSVP) is an IETF standard designed to support resource (such as bandwidth) reservations through networks of varying topologies and media. QoS requests are propagated to all routers along the data path, allowing the network to reconfigure itself to meet the desired level of service.

RSVP-Based CAC

RSVP is an enhancement to CAC that ensures QoS in Cisco H.323 VoIP networks. Its principles are identical to those of the IETF standard. RSVP-based CAC allows applications to request end-to-end QoS guarantees from the network.

IP Precedence

IP precedence is a remedy for voice and data contention by marking traffic for different priority classes. This technique is required if any link in the entire network can become congested—an extremely likely possibility.

Low Latency Queuing

Low latency queuing (LLQ) is another remedy for voice/data contention. The Cisco Low Latency Queuing feature brings strict priority queuing to Class-Based Weighted Fair Queuing (CBWFQ). Strict priority queuing allows delay-sensitive data such as voice to be dequeued and sent first (before packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other traffic.

RSVP/LLQ Integration

RSVP uses weighted fair queuing (WFQ) to provide fairness in flows and assign a low weight to a packet so it can attain priority. However, the RSVP queuing algorithm fails to minimize jitter. Whereas RSVP provides call admission control, the Cisco RSVP Support for Low Latency Queuing feature also provides the needed support for bandwidth and delay guarantees need for voice traffic.

Additional Traffic Engineering Issues

There are a variety of traffic-engineering challenges posed by a Cisco ASAP Solution network, the majority of which are related to varying bandwidth throughout the network. These topics are listed below.

Note

These issues are discussed in Chapter 3, "Using Management and Shared Support Services," of the Cisco ASAP Solution Implementation Guide.

Billing and Settlement

Voice services and even some data services will require reliable billing mechanisms to account for call start and stop times across the various call legs, or definable sections of a call's path. This is especially important in cases where multiple service providers are involved and billing must be partitioned, or settled, according to who "owns" the call legs that are traversed. The features available in the H.323 standard for packet telephony provide for billing from the GW by using the accounting component of AAA/RADIUS capabilities.

Table Of Contents

Designing a Solution

Overview: Design Issues and Choices

H.323 Network Issues

Dial Plans and Number Normalization

Unified Dial Plans

Number Normalization

Dynamic Call-by-Call Handling

Call Control Scripts

Cisco TCL IVR

VXML

SS7 Interconnect

Network Design Guidelines

Guidelines for Individual Components

Guidelines for Gateways

Guidelines for Gatekeepers and Directory Gatekeepers

Guidelines for Cisco SC2200 Nodes

Solution Resilience

Traffic Engineering

Convergence and Migration Considerations

Adding Dial to a Voice Network

Adding Voice to a Dial Network

Achieving End-to-End Quality of Service

Contention

Call Admission Control

Resource Reservation Protocol

RSVP-Based CAC

IP Precedence

Low Latency Queuing

RSVP/LLQ Integration

Additional Traffic Engineering Issues

Billing and Settlement