Designing a Long-Distance VoIP Network
Available Languages
Table Of Contents
Designing a Long-Distance VoIP Network
Long-Distance VoIP Network Overview
Long-Distance VoIP Network Benefits
Long-Distance VoIP Design Methodology
Minutes Aggregation and Termination (Including ASP Termination)
Step 2: Identify Carriers or Providers
Step 3: Determine Interconnection Types
Step 4: Determine Call Topologies
Originating TDM/Terminating TDM Call Topology
Originating TDM/Terminating IP Call Topology
Originating IP/Terminating TDM Call Topology
Originating IP/Terminating IP (Transit VoIP Network) Call Topology
Step 5: Identify Deployment Scenario
Step 6: Identify Functional Areas
Step 7: Identify Required Hardware and Software Components
Additional Components for Shared Services
Step 8: Identify Design and Scalability Issues
Functional Areas Design Issues
Step 9: Configure and Provision Components
Designing a Long-Distance VoIP Network
Version History
The long-distance Voice over IP (VoIP) network solution is a set of network design and configuration strategies that provide trunk-level transport of global switched telephone traffic distributed over VoIP. Calls originate in the Public Switched Telephone Network (PSTN), are routed through interexchange carriers (IXCs), and are handed off to a wholesale VoIP carrier for transport. To the subscriber, the long-distaance service seems like any other inexpensive long-distance service. To the originating long-distance carrier, the wholesale carrier is only one of a number of termination options.
The long-distance VoIP network solution offers service providers the required architecture design, network components, software features, functional groups, and provisioning methodologies needed to run a VoIP wholesale service. This solution enables the service provider to design a wholesale network and sell unbranded voice services to retailers, such as internet telephony service providers (ITSPs), application service providers (ASPs), IXCs, and post, telephone, and telegraph (PTTs) administrations.
This document describes the fundamentals of long-distance VoIP and provides a nine-step methodology for designing and implementing a long-distance VoIP network solution. This document is intended to cover the high-level design of a long-distance VoIP network; therefore, it does not discuss specific configuration information.
This document includes the following sections:
•
Long-Distance VoIP Network Overview
•
Long-Distance VoIP Network Overview
The long-distance VoIP network solution includes multiple components in various combinations from both Cisco and third-party vendors. Voice points of presence (POPs) that are connected to other service providers are a central component in the delivery of wholesale voice services. The types of interconnections or call topologies service providers support will determine the specific components and design methods we recommend. Service providers use the call topologies to build a set of deployment scenarios that enable wholesale applications. Figure 1 shows some of the interconnection possibilities.
Figure 1 Long-Distance VoIP Network Solution Interconnection Possibilities
Long-Distance VoIP Network Benefits
The long-distance VoIP network solution provides the following benefits:
•
•
•
•
•
•
•
•
•
Long-Distance VoIP Design Methodology
To design your own personalized long-distance VoIP solution, systematically perform the following Cisco-recommended steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 1: Identify Services
A key feature of the Cisco long-distance VoIP solution is its ability to support various mixes of services to suit the needs of a single service provider or multiple partnering service providers. Supported services are described in the following sections:
•
Figure 2 depicts all of the components that may be needed to provide these services. These components include gatekeepers (GKs), gateways (GWs), signaling link termination (SLTs) equipment, signaling controllers (SCs), and intermachine trunks (IMTs).
Figure 2 High-Level View of End-to-End Service Possibilities
Minutes Aggregation and Termination (Including ASP Termination)
The Cisco wholesale voice solution supports the originating carrier that hands calls over to a VoIP wholesaler at a profit. Termination settlement rates are generally lower than PSTN termination rates—the key reason why long-distance carriers will choose a VoIP carrier for termination. Furthermore, termination bandwidth is often available over VoIP to countries where PSTN termination is unavailable because of congested international gateway facilities or other reasons. The average call success rate is as good as or better than that provided by PSTN carriers, and voice quality, including echo cancellation, is uncompromised.
Key features of this service include the following:
•
•
•
•
As part of this service, ASP carrier to carrier termination services are supported. The ASP originates the call, often over an Internet-enabled PC-telephony application, or through a PSTN portal for cellular phone callers. The ASP provides pre-call services, such as content delivery (prerecorded messages, voice mail, private number dialing) or supervision-related services, such as "find me/follow me." The ASP then hands off any long-distance calls to a wholesale carrier for termination by the PSTN. This service requires accurate call accounting.
Calling Card Services
The Cisco wholesale voice solution supports the following calling card services:
•
•
Figure 3 illustrates a variety of calling card services, including those provided by third parties.
Figure 3 Calling Card Services
Clearinghouse Services
When multiple partners join to provide wholesale voice services, the services described in the preceding sections may require the assistance of clearinghouse services for billing and settlement. The Cisco wholesale voice solution supports call termination agreements through Open Settlement Protocol (OSP) in Cisco devices.
OSP relies upon Cisco Open Packet Telephony (OPT) framework at the call control layer. Service providers that use OSP (the only standard IP interface for VoIP clearinghouse functions), must do business with only one settlements provider. As a result, there is no need to negotiate separate agreements with carriers in multiple countries, meet varied technical requirements for interconnection, make repeated arrangements for call accounting, or establish multiple credit accounts. The OSP clearinghouse solution virtually eliminates the risk of doing business with new service providers that have a limited credit history—or with carriers in countries subject to currency fluctuations. In addition, it gives virtually every VoIP provider the worldwide calling reach it requires.
OSP uses a standard protocol approved by the Internet Protocol Harmonization over Networks organization of the European Telecommunications Standards Institute (ETSI TIPHON). By allowing gateways to transfer accounting and routing information securely, this protocol provides common ground between VoIP service providers. Consequently, third-party clearinghouses with an OSP server can offer call authorization, call accounting, and settlement—including all the complex rating and routing tables necessary for efficient and cost-effective interconnections.
In most cases, a wholesale provider will subcontract with a clearinghouse partner to provide wholesale voice services with proper settlement. However, a clearinghouse solutions vendor can also independently take advantage of the Cisco wholesale voice solution to achieve market objectives.
Service Options
In addition to the services previously listed, the other two service options are described in the following sections:
•
•
Limited Egress Carrier-Sensitive Routing
As an enhancement to simple carrier-interconnection applications, the Cisco wholesale voice solution makes it possible to route a call to different destination carriers. You have the same considerations as with simple carrier-interconnection models, but with slightly increased call-routing responsibilities. The directory gatekeeper can make limited egress carrier-sensitive routing (CSR) decisions by using the sequential LRQ feature, which is available to the applications using directory gatekeeper routing. Generally speaking, this means any TDM partners and directory gatekeeper peering partners, but also includes any OSP partners in which an OSP interconnection zone is used, as opposed to a direct implementation on your gateways.
In this CSR application, the sequential LRQ feature is used to route a call to different carriers, each of which supports a different destination. For example, you may provision your gatekeepers to route certain destination patterns to carrier A first. If carrier A (an Internet telephony service provider, or ITSP) is unavailable as a result of a location request reject (LRJ) or LRQ timeout, you may decide to route the call to carrier B (an interexchange carrier, or IXC), then to carrier C, and so on. Figure 4 illustrates this application.
Figure 4 Limited Egress Carrier-Sensitive Routing
There are three restrictions to remember with limited egress CSR:
•
•
•
Interconnection to Clarent-Based Clearinghouses
You can interconnect with a Clarent-based service provider (URL www.clarent.com) provided that the gateways register to a Clarent gatekeeper; however, this would mean dedicating specific gateways to be part of the Clarent zone. Back-to-back gateways may be used to provide a "transit" zone between the Cisco and the Clarent-based network. One of the back-to-back gateways registers to a Clarent gatekeeper in the Clarent-based service provider network; the other registers to a Cisco gatekeeper in your network. This architecture is very similar to using back-to-back gateways to interconnect OSP partners, except that here the relationship is H.323 gateway to gatekeeper instead of OSP.
There are two limitations to using Clarent-based interconnection as follows:
•
•
Step 2: Identify Carriers or Providers
As a wholesale voice service provider, you need to interconnect with other service providers (ITSPs and ASPs) and carriers (IXCs and PSTNs) in order to offer the services you selected in Step 1. This interconnection method is referred to as a call topology. Because each call topology is specific to the carrier or service provider with which you plan to connect, you need to first identify the targeted carriers and service providers.
Step 3: Determine Interconnection Types
There are two application interconnection types you can use to interconnect with other service providers: IP and TDM. Your call topology is determined by the application interconnection type you use. The line of demarcation between you and the other service providers determines whether the interconnection type is IP or TDM.
Step 4: Determine Call Topologies
The call topology influences the ultimate configuration requirements of the functional areas within the network to support a given application. For example, if you enable simple carrier interconnection between an ASP and an IXC, then you would use an IP-to-TDM call topology. You would then need to address the configuration requirements for that application (such as call routing and shared support services needed for billing, settlement, and security options) as influenced by that topology type.
Four call topologies or interconnection methods are described in the following sections:
•
•
•
•
Figure 5 summarizes each of these topologies.
Figure 5 Summary of Call Topologies
Originating TDM/Terminating TDM Call Topology
The originating TDM/terminating TDM call topology is a single administrative domain and the most fundamental call topology. With this topology, you receive and terminate traffic from other service providers via TDM interfaces. Figure 6 illustrates this topology.
Figure 6 Topology 1: Originating TDM/Terminating TDM
Because interconnection is confined to TDM interfaces on gateways you administer, deployment considerations in the areas of routing, security, billing, and settlement are fairly straightforward. Limited-egress CSR applications demand additional call routing provisioning tasks. Your concerns are primarily confined to supporting the proper TDM signaling and the transparency of bearer traffic, such as voice, fax, or modem pass-through.
The originating TDM/terminating TDM call topology is appropriate for the following applications:
•
•
•
•
•
Originating TDM/Terminating IP Call Topology
If you want to increase call volume or coverage area by adding interconnections with other IP-based service providers, use the originating TDM/terminating IP call topology. With this topology, you receive traffic from IXC or PSTN providers over TDM interfaces. If the provider cannot terminate the call within its own network POPs, it can send traffic to other service providers such as ITSPs or ASPs over IP. Figure 7 illustrates this topology.
Figure 7 Topology 2: Originating TDM/Terminating IP
In addition to the TDM-related issues described in the originating TDM/terminating TDM call topology, this topology has the added considerations of IP interconnection. You must consider issues pertaining to call routing, interoperable bearer transport, billing, settlement, and security.
The originating TDM/terminating IP call topology is appropriate for the following applications:
•
•
•
•
•
Originating IP/Terminating TDM Call Topology
The originating IP/terminating IP call topology is essentially the same as the originating TDM/terminating IP call topology, but the call direction is reversed. With this topology, you receive traffic from other service providers via IP and terminate traffic at your POPs to IXC or LEC providers through TDM interfaces. Figure 8 illustrates this topology.
Figure 8 Topology 3: Originating IP/Terminating TDM
Because you are now receiving traffic from other providers through IP interconnect, you must be concerned with call routing, originating carrier identification for billing and settlement, interoperable bearer transport, and security.
The originating IP/terminating TDM call topology is appropriate for the following applications:
•
•
•
•
Originating IP/Terminating IP (Transit VoIP Network) Call Topology
If you want to provide transit between different IP-based interconnection partners, use the originating IP/terminating IP call topology. With this topology, you exchange traffic between other service providers using only IP connections. Figure 9 illustrates this topology.
Figure 9 Topology 4: Originating IP/Terminating IP
Typically, you receive traffic from an ITSP or ASP, and if you cannot terminate the call at one of your own POPs, you send the call to another service provider.
When sending and receiving traffic between two IP interconnects, you have increased challenges in the areas of call routing, carrier identification, billing, settlement, security, and potentially masking originating carrier information from the terminating carrier.
The originating IP/terminating IP call topology is appropriate for the following applications:
•
•
•
•
IP Interconnection Variations
In addition to using the call topologies described, you can interconnect with other IP-based service providers (ITSPs and ASPs) using one of the methods described in the following sections:
•
•
Each method has its own provisioning requirements.
Directory Gatekeeper-Based Interconnection Method
With the directory gatekeeper-based interconnection method, you provision call routing between your IP interconnect partners by peering directory gatekeepers to which you send LRQ RAS messages. You can direct certain destination patterns to specific interconnect partners. These destination patterns could have been modified upon ingress into your network to provide limited ingress carrier-sensitive routing applications. Additionally, you can use sequential LRQ features to provide limited egress carrier-sensitive routing applications.
With directory gatekeeper-based interconnect, you benefit from centralizing route provisioning in the directory gatekeeper rather than pushing it to the edge gateways as with OSP. However, billing/settlement functions and security options are processes external to call routing that require some configuration in the gateways, gatekeepers, and related shared-services components.
If you are a large service provider with many POP gateways, provisioning complexities may determine that this is the best option for interconnection. Figure 10 illustrates a directory gatekeeper-based interconnection with other ITSP/ASP partners.
Figure 10 Directory Gatekeeper-Based Interconnection with Other Service Providers
OSP-Based Interconnection Method
With the OSP-based interconnection method, an OSP server performs call routing, billing/settlement, and security functions; however, additional provisioning is required. All edge gateways must be registered with the OSP server, and rotary dial-peer failover must be provisioned to route calls through the OSP interconnection.
OSP may be an attractive interconnection option if you want to combine call routing, security, and billing/settlement into one architecture. However, in current Cisco implementations, limitations with OSP deployments require extensive provisioning in the gateways so that they can interact with the required shared services, support the dial plan architecture, and cover termination caveats.
Figure 11 illustrates an OSP-based interconnection with other ITSP/ASP service partners.
Figure 11 OSP-Based Interconnection with Other Service Partners
Step 5: Identify Deployment Scenario
Select the appropriate deployment scenario based on functional areas (described below) and call topologies.
The Cisco wholesale voice solution supports the deployment scenarios described in the following sections:
•
•
•
•
•
Step 6: Identify Functional Areas
The Cisco wholesale voice solution encompasses the primary functional areas described in the following sections:
Figure 12 shows each of the functional areas.
Figure 12 Functional Areas of the Cisco Wholesale Voice Solution
Your wholesale VoIP cloud may include some or all of the areas depicted in Figure 12, depending on the issues specific to your interconnection methods, billing services, call control, settlement, IVR options, and network management.
Gatekeeper Core
The gatekeeper core functional area, illustrated in Figure 13, is used by all POPs and is the foundation of a large-scale H.323 network design. It consists of Cisco gatekeepers (GKs), Cisco directory gatekeepers (DGKs), and optionally Ecosystem Partner gatekeeper platforms.
Gatekeepers enable a network to scale in growth, performance, and dial-plan administration. Gatekeepers and directory gatekeepers provide for resource management, call routing, security, fault tolerance, external Gatekeeper Transaction Message Protocol (GKTMP) applications, and call detail record (CDR) generation. Gatekeepers support interactions with shared services and provide gatekeeper-based interconnect with other providers if the application demands.
Figure 13 Role of Gatekeepers and Directory Gatekeepers in the Gatekeeper Core
Inbound directory gatekeepers are Cisco 7200 series routers or Cisco 3660 routers. Zone gatekeepers are Cisco 3600 series routers. Cisco 3640s and 3660s routers, and AS5300s and AS5400 universal access servers are examples of gateway platforms.
Shared Services
Shared support services are central resources that enable network applications in the areas of card services, call routing, billing, settlement, security, and network management. The primary elements that enable these applications are OSP servers, TFTP servers, AAA servers, billing systems, NMS platforms, and EMS platforms.
Non-SS7-Based POP
Wholesale service provider networks consist of POPs that house gateways to transport voice traffic between TDM and IP networks. POPs are active components in the originating TDM/terminating TDM, originating TDM/terminating IP, and originating IP/terminating TDM call topologies. Non-SS7-based POPs receive signaling from the TDM network on the same physical interface that supports bearer traffic. There may be a logical separation of signaling and bearer traffic within the interface, such as with ISDN. Actual gateway platforms used at these POPs will depend upon the signaling type offered by the TDM interconnect. Figure 14 shows non-SS7-based POP signaling. The following interfaces are supported through in-band signaling:
•
•
•
•
•
•
Figure 14 Non-SS7-Based POP Signaling
Gateway components include the Cisco 3600 series routers and the Cisco AS5300 universal access servers.
In addition to the physical interface and signaling variations, a number of platform-independent software features and functions must be enabled on the POP gateways to support an application, such as POP size, dial plan, fault-tolerance, security, billing, network management, and bearer transport responsibilities.
SS7-Based POP
These PoPs generally have the same deployment considerations with billing, security, network management, transparent bearer transport, and TFTP servers as the non-SS7 based PoP. However, this PoP has additional considerations related to SS7 interconnect signaling, which is required to conform to the PSTN TDM network. Added considerations also appear in PoP size, dial-plan responsibilities, and fault tolerance.
Gateway components include Cisco 2600 Signaling Link Terminals (SLTs) and Cisco AS5300 universal access servers. Support is provided for Q.767 and TR-113 signaling.
Back-to-Back Gateway System
The back-to-back gateway system is a special component used to provide a variety of functions for a variety of applications. Gateways are deployed as a pair in a back-to-back TDM trunk, single-stage-dialing configuration.
Depending on the application, back-to-back gateways may function as unidirectional or bidirectional call devices. For example, in an IVR application, half of the back-to-back gateway is dedicated receiving calls and the other half is dedicated to originating calls. In contrast, for an OSP interconnect zone application, the back-to-back gateway may process calls in both directions, although each gateway is responsible for separate protocols. For added clarity when discussing back-to-back gateway pairs, we refer to the individual gateways in a pair as an inbound VoIP gateway and an outbound VoIP gateway with respect to the call direction for unidirectional applications. For bidirectional applications, we refer to the gateway by the protocol it supports, where possible.
Figure 15 shows the relationship of the back-to-back gateway to an ingress and egress carrier and to your wholesale VoIP cloud.
Figure 15 Relationship of Back-to-Back Gateways to Wholesalers and Carriers
In many ways, the back-to-back gateway system functions just like a normal non-SS7-based POP. The gateway pair helps with applications that use different bearer transport options (such as codec type or security options) on the two interconnecting networks for which you are providing transit. It allows you to have a presence in the call-signaling path in IP-to-IP interconnect call topologies so that you can generate usage records through AAA, interconnect with Clarent-based and OSP-based environments, and front-end PC-to-phone applications for IP-based interconnect partners. It also provides a way to obscure information about interconnection partners.
The platforms that might be used as back-to-back gateways are the Cisco 3600 series routers, the Cisco AS5300 universal access server, and the Cisco AS5400 universal gateway.
Step 7: Identify Required Hardware and Software Components
This section describes the actual hardware and software components, both Cisco and third-party vendor equipment, that can be used to implement a wholesale voice solution.
Major Components
The major components described in the following sections are used in implementing a wholesale voice solution:
•
Cisco Voice Gateways
Wholesale solutions require a range of small to large-scale PSTN interconnections with the wholesaler TDM-based customers (typically IXCs, PTTs, or other wholesalers), depending on anticipated call volumes. Similar interconnections may be required to offload traffic. Gateways may handle their own signaling, or they may provide intermachine trunks (IMTs) and receive external SS7 signaling through a Cisco SC2200 signal controller running Cisco SS7 Interconnect for Voice Gateways Solution software with Q.931 signaling backhaul.
Possible gateway platforms include the Cisco 3640 and 3660 routers, and AS5300 and AS5400 universal access servers, along with various supporting network modules.
Note
Cisco H.323 Gatekeepers and Directory Gatekeepers
Gatekeepers and directory gatekeepers are mandatory network elements used to scale a wholesale network to large sizes. They consist of specialized Cisco IOS software images running on a dedicated Cisco 3660 or 7200 series router.
Directory gatekeepers further supplement network scalability and are mandatory if gatekeeper-based carrier interconnection is desired. Cisco gatekeepers perform the following tasks:
•
•
•
•
•
Cisco Signaling Controllers
Cisco Signaling Controllers are optional components, but are required in SS7 interconnection solutions. The supported platform is the Cisco SC2200.
Cisco SLT Systems
Cisco SLY systems are optional Cisco 2600 series routers capable of terminating Message Transfer Part (MTP) Levels 1 and 2 SS7 layers and backhauling Level 3 and higher SS7 layers to the Cisco SC2200 in an SS7 interconnection solution.
Additional Components for Shared Services
Additional components, provided by third parties, support shared services and are described in the following sections:
•
•
•
•
RADIUS/OSS Servers
Ecosystem partner OSS servers interface with Cisco gateway and gatekeeper components through AAA RADIUS vendor specific attributes (VSAs) and are mandatory elements of the wholesale network. Current examples include Cisco Secure and Cisco ecosystem partners such as MIND/CTI and Belle Systems billing platforms. Cisco has defined a set of VSAs in the document, RADIUS Vendor-Specific Attributes Voice Implementation Guide. VSAs can be used to achieve the following functions:
•
•
•
Note
•
•
Ecosystem Partner H.323 Gatekeepers
These optional gatekeepers may be used on the network fringe to compliment the Cisco gatekeeper/directory gatekeeper infrastructure and to host a variety of applications. Individual applications will vary between ecosystem partners.
Note
Gatekeeper Application Servers
Enhanced call routing applications may optionally reside on an external server and interface with a Cisco wholesale VoIP network through the Cisco gatekeepers or directory gatekeepers using the GKTMP interface specification.
Note
OSP Servers
To support carrier interconnect, you may choose to use OSP servers. Using OSP for secure settlement transactions requires a clearinghouse entity, or at least a dominant carrier in the interconnect relationship that administers the OSP server. GRIC and TransNexus currently provide OSP-based clearinghouse services. OSP servers perform the following functions:
•
•
•
•
•
Prompt Servers
A prompt server is an optional component that maintains a prompt database for gateways running interactive voice response (IVR) functionality for applications such as card services. Prompt databases may be stored locally on the gateway in flash memory if they are not too large. Larger prompt databases, such as those needed when there are many branded retailers or when many languages must be supported, may be dynamically downloaded as needed from a prompt server using TFTP. TFTP servers are generic third-party devices that can be hosted on a wide variety of platforms.
TFTP Servers
TFTP servers are used to store audio (IVR) files, IOS files, configuration files, dial plans, and other files that do not need to reside on a local machine. These files can be downloaded as needed.
Network Management Systems (NMS)
NMS systems are optional components that are used for network monitoring, fault management, trap correlation, and reporting. Any NMS system can extract this information from wholesale components using SNMP. The Cisco wholesale voice solution recognizes CiscoWorks Internet Protocol Manager (IPM) to monitor network QoS and Cisco InfoCenter (CIC) for fault management and trap correlation. For reporting, it is possible for third-party vendors such as Trinagy to provide reports by interfacing with Cisco Voice Manager (CVM).
Element Management Systems (EMS)
EMS systems are optional components that are used for managing or provisioning other components in the solution. Cisco Voice Manager (CVM) provides limited provisioning support and is the only EMS currently supported in the Cisco wholesale voice solution.
Detailed Component Inventory
The following component hardware and software products and subordinate solutions are relevant to the Cisco wholesale voice solution:
VoIP Gateways
The following Cisco devices can be used as VoIP gateways:
•
•
•
•
•
•
•
These platforms support a variety of analog and digital interfaces. For more information about supported interfaces for a specific platform, please refer to the documentation for that specific platform at http://www.cisco.com.
H.323 Gatekeepers
Candidate gatekeepers are as follows:
•
•
SS7 Elements
Candidate SS7 elements are as follows:
•
•
Shared Services Components
Candidate shared-services components are as follows:
•
•
•
•
•
•
•
•
Step 8: Identify Design and Scalability Issues
Some of the design issues associated with the Cisco wholesale voice solution have already been mentioned in previous steps. The following paragraphs look at these issues in detail and organize them into the following groups:
•
General Design Issues
Because of the many ways in which multifunctional groups interact, there are general design issues associated with the following topics:
•
•
Call Routing
Call routing between IP service providers can be either directory gatekeeper-based or OSP-based. The billing and call routing functions you desire will determine whether your network will be directory gatekeeper-based or OSP-based.
Directory gatekeeper (DGK)-based call routing uses Location Request (LRQ) RAS messages to resolve call routing for desired prefixes. An LRQ is sent from the originating service provider's directory gatekeeper to the terminating service provider's directory gatekeeper to request the terminating gateway IP address. The directory gatekeeper method of call routing can be used when the originating and terminating service providers are trusted peers.
OSP-based call routing uses a separate OSP clearinghouse entity that maintains OSP servers. The OSP servers contain the prefix call-routing tables of all service providers that subscribe to the OSP clearinghouse. The originating gateway sends an OSP Authorization Request to the OSP server; the OSP server responds with an Authorization Response containing a list of possible IP addresses of the terminating gateway plus a security token. This token is included in the setup message to provide security validation at the terminating gateway. The OSP method of call routing is used when carriers want a third party to provide the billing and settlement.
Billing and Settlement
You must accurately identify the originating carrier and terminating carrier for calls in order to properly bill for service. The degree of difficulty of this varies depending upon the call topology used. Furthermore, the usage indication must be extracted from a reliable source. This implies that the devices supplying call usage indications are somewhere within the H.225 call-signaling path. Therefore, if billing is desired, you must own at least one gateway in any given conversation.
Billing and settlement functionality can be AAA/RADIUS-based or OSP-based. These methods may be used either individually or in conjunction with each other and will directly depend upon the method of interconnect. Though differing in protocol, each method addresses the same basic needs for call accounting.
AAA billing must be used for any intradomain calls because OSP is designed to bill for interdomain calls only. AAA may also be used for interdomain calls if interconnect is handled by a peering directory gatekeeper relationship rather than by an OSP server. In this scenario, the billing application correlates the usage records to generate CDRs. The CDRs are then distributed to customers in the form of a periodic bill. Customers can verify this bill against their own records before exchanging money or settling the call. Various mediation vendors exist that help automate the verification and settlement stages.
For interconnect using OSP, you may either own an OSP server or depend upon a third-party clearinghouse OSP server to provide accounting services. The OSP server receives accounting information from your gateway in much the same manner as with AAA. Because usage indications are received from both gateways across administrative domains, the OSP server gets accurate terminating and originating carrier information. The usage records are then correlated to generate CDRs. The CDRs may be distributed as periodic bills to customers. Customers can verify this bill against their own records before exchanging money or settling the call. To provide personal accounting records for verification, parallel AAA accounting records can be used.
It is possible that a third party could manage an interconnecting TDM PoP. If this is the case, you cannot depend upon gateways to send them CDR information. You may therefore choose to do billing from the terminating gateways only (if you own them) or from the gatekeeper.
Billing from the gatekeeper has limitations. Cisco gatekeepers can send call start/stop records to a AAA RADIUS server based upon receipt of ARQ and DRQ RAS messages from gateways. However, RAS messages are sent over UDP and are not guaranteed to arrive at the gatekeeper. Furthermore, this method of billing lacks answer supervision. Also, firewalls between gatekeepers and AAA servers can cause problems because certain ports need to be opened up for these messages to be received.
Therefore, billing is most reliable and accurate if performed at the gateway.
Basic Dial Plans
Dial plan responsibilities are distributed among gateways, gatekeepers, and directory gatekeepers. Because SS7 deployments leverage NI-2 type Q.931 backhaul signaling, the basic H.323 dial plan architecture is the same regardless of whether the PoPs in the network are SS7 based, non-SS7 based, or a mixture of both. Figure 16 depicts a typical large-scale H.323 network design.
Figure 16 Typical Large-Scale H.323 Network Design
Gateways deal with the local PoP portion of the dial plan. This encompasses any digit manipulation needed to normalize numbers or implement local PSTN access rules. It also includes notifying a gatekeeper when resource availability indicator (RAI) thresholds are crossed in order to increase call-completion rates. Furthermore, the gateway may implement rotary dial peers to handle call failover routing options such as trying OSP if normal gatekeeper RAS call routing offers no possible termination.
For example, you may want the gateway to notify the gatekeeper when its resource limits are nearly exhausted, thereby prompting the gatekeeper to select a different gateway. Additionally, to simplify route provisioning in the gatekeepers and directory gatekeepers, you may wish to normalize numbers into a standard format (for example, country code + area code + local number) before sending calls into the VoIP network. Or, you may need to prepend or strip digits such as area codes or access codes, as PSTN access rules require, before sending calls out the TDM interfaces.
Local gatekeepers monitor gateway health levels and maintain detailed routing tables, mapping destination patterns to specific terminating gateways within one or more local zones. The local gatekeepers can use features such as lightweight registration, RAI, and static gateway-priority assignments to influence gateway selection. For all other nonlocally supported destination patterns, the local gatekeeper configures a wild-card route to the directory gatekeeper.
The directory gatekeeper maintains an overall routing table of destination patterns and the corresponding local gatekeepers that support them. The directory gatekeeper simply forwards LRQ requests to the local gatekeeper that handles that destination pattern.
This use of gatekeepers and directory gatekeepers allows the addition of new gatekeeper zones, PoPs, and certain types of IP interconnect partners with minimal impact to dial plan provisioning. Changes are isolated to the local gatekeeper and the directory gatekeeper. The rest of the elements in the network are untouched. Often, the level of dial plan resolution at the directory gatekeeper level can be simplified. For example, a directory gatekeeper may know to route all calls beginning with a country code of 1 to the local U.S. gatekeeper. The local U.S. gatekeeper can then expand selection to more digits to route the call to the proper terminating gateway.
Fault Tolerance in Dial Plans
For intradomain calls and directory gatekeeper-based IP interconnects, you have the option of overlaying fault tolerance onto the basic H.323 VoIP network dial plan design. This is accomplished by using a combination of Cisco IOS software features such as alternate gatekeepers on the gateway, Hot Standby Router Protocol (HSRP) on the directory gatekeeper, and sequential LRQs on the gatekeepers and directory gatekeepers. Figure 17 illustrates a fault-tolerant architecture using alternate gatekeepers.
Figure 17 Fault-Tolerant Architecture Using Alternate Gatekeepers
Gateways may be configured to register to a primary gatekeeper and an alternate gatekeeper in the event that the primary gatekeeper fails. This implies that at any given time, gateways may be registered to either a primary or alternate gatekeeper. Since Cisco gatekeepers do not communicate registration states to each other, sequential LRQs must be configured on the gatekeepers and directory gatekeepers to accommodate zone fragmentation.
For example, a gatekeeper in the Western Zone supports gateways in San Jose (408) and San Francisco (415). Under normal circumstances, when San Jose calls San Francisco, the route is resolved in the local primary gatekeeper. However, let's say that San Jose fails over to the alternate gatekeeper while San Francisco remains on the primary gatekeeper. To continue to support regional call completion within the Western Zone, the primary and alternate gatekeepers must be provisioned to send local prefixes to each other if no local resource exists—that is, if the terminating gateway has failed over to the other gatekeeper. In this case, in order for San Francisco to complete calls to San Jose, the primary gatekeeper must know to send LRQs for the San Jose prefix to the alternate gatekeeper. Similar provisioning is required on both primary and alternate gatekeepers to support calls in both directions.
Provisioning is also required on the directory gatekeeper to prevent zone fragmentation when calls are originated from other zones. For example, if San Francisco sends a call to New York, the directory gatekeeper does not know with which gatekeeper (primary or alternate) the NY gateway is registered. The directory gatekeeper must be provisioned to send sequential LRQ requests to both primary and alternate terminating local gatekeepers for all Eastern Zone supported prefixes (messages 1a and 1b in Figure 17). Similar provisioning is required for the Western Zone prefixes to support calls in the other direction.
HSRP is used to provide fault tolerance for the directory gatekeeper. However, HSRP failover detection may take some time during which no calls will be processed. To cover this possibility, local gatekeepers may be configured to point to more than one directory gatekeeper (that is, an ALTdirectory gatekeeper) for their wild-card routes using sequential LRQs.
For example, the gatekeeper may point to an HSRP directory gatekeeper pair as its primary option (message 1). If no response is received because HSRP failover has not yet been detected, the gatekeeper may initiate another LRQ (message 2) to an ALTdirectory gatekeeper after a configurable timeout of from 100 to 1000 ms. During this time calls will still be completed, but with additional post-dial delay. The ALTdirectory gatekeeper is configured exactly the same as the primary directory gatekeeper HSRP pair (messages 2a and 2b).
Security Considerations Associated with Dial Plans
You can implement various security mechanisms throughout your H.323 VoIP network. The security mechanism you select may have different provisioning needs within multiple functional areas. For intradomain calls, you may use complex access-lists. For interdomain calls, you may use either complex access-lists or, where OSP is used, OSP access tokens.
Note
You may provision your gateways with complex access-lists to accept calls from only known entities; however, this is neither scalable nor friendly to network changes or elements that use DHCP.
Functional Areas Design Issues
There are design issues to consider for each of the following functional areas:
Gatekeeper Core
Consider the following issues when designing the gatekeeper core:
•
•
•
•
•
•
•
Shared Services
Consider the following issues when designing shared services:
•
•
•
•
•
SS7 PoP
Consider the following issues when designing SS7 PoPs:
•
Figure 18 shows the signaling used in an SS7 PoP, and the relationship among Cisco SC2200 nodes and hosts, Cisco AS5x00 gateways, and Cisco SC26xx SLTs.
Figure 18 SS7 PoP Signaling
•
•
Non-SS7 PoP
Consider the following issues when designing Non-SS7 PoPs:
•
Low-density analog interfaces generally discourage carrier interconnects, so calls that ingress the PoP will almost always be for card services and calls that egress the PoP are reoriginated into the PSTN, usually to bypass PTT interconnect tariffs. DS1 and DS3 interfaces generally provide either card services or interconnect wholesale systems to their customers.
•
•
•
•
•
•
•
•
Back-to-Back Gateways
Consider the following issues when designing back-to-back gateways:
•
•
•
•
•
•
•
Service Design Issues
This section describes the issues you should consider for service design. We will consider solutions for the following two kinds of services and discuss the issues associated with each, depending on the call topology used:
•
•
Minutes Aggregation and Termination
This solution enables you to collect traffic from multiple originating providers, then aggregate and deliver it to the termination providers you select. This may include target greenfields, resellers, dial-around callback operators, and international ISPs.
TDM-to-TDM Call Topology
If you select the TDM-to-TDM call topology for this service, consider the following issues:
•
•
•
TDM-to-IP Call Topology Using Directory Gatekeeper-Based IP Interconnect
If you select the TDM-to-IP call topology using directory gatekeeper-based IP interconnect for this service, consider the following issues:
•
•
This requires correlating either source or destination IP addresses with a particular IP interconnecting carrier, depending on the call direction. Your billing system must maintain a database of this information to bill the interconnecting customer accurately. For calls sourced from ASPs, the list of possible originating IP addresses is typically limited to a few call-signaling proxy servers. However, for ITSPs with many gateways or PC clients, this list can be quite extensive. The list may be reduced if the ITSP forgoes performance and uses gatekeeper RCS. Once carrier identification issues are solved, AAA billing and settlement is done on the gateways.
Alternatively, the originating ITSP or ASP can include a mutually recognized carrier ID (for example, prepend ANI) in the H.323 SETUP message. The terminating gateway will then include this information in the AAA record. You can provision the billing application to recognize this carrier ID and associate it with an originating carrier. This implies, however, a trusting relationship between service providers.
•
TDM-to-IP-Based Interconnect with OSP Call Topology
If you select the TDM-to-IP-based interconnect with OSP call topology for this service, consider the following issues:
•
From a call routing perspective, OSP is most readily accepted into the network if an OSP interconnection zone consisting of back-to-back gateways is used. One gateway handles the RAS side of the call; the other the OSP side of the call. From the perspective of the directory gatekeeper, this looks like another TDM zone managed by a local gatekeeper. The directory gatekeeper simply adds LRQ routes to the OSP interconnect zone gatekeeper for specific destination patterns serviced by that OSP interconnect partner.
Provisioning requirements for the gateways within this OSP interconnection zone are only slightly different from the requirements for a normal wholesaler TDM PoP. The OSP-side gateway is configured to interface with the OSP server. The RAS-side gateway is provisioned like a normal PoP RAS gateway. The back-to-back gateways are then configured to send all calls received through IP out TDM interfaces to the opposite gateway, using single-stage dialing. This method of OSP interconnect isolates provisioning tasks to the back-to-back gateway pair, the local hopoff gatekeeper configuration, and an added LRQ route in the directory gatekeeper. The rest of the network is unaffected.
If OSP is implemented without using the interconnect zone, dial-peer provisioning increases dramatically in order to support OSP directly on the gateways. Separate dial peers are needed on all PoP gateways to send calls to the OSP server for route resolution instead of through RAS. You may provision dial peers on the gateways to send calls to OSP for specific destination patterns.
For example, if an interconnect partner knows that all calls to Australia need to be terminated by OSP, you may insert a dial peer into your gateways that sends all calls beginning with a "61" country code to an OSP session target. However, any changes to the OSP dial plan require modification to the dial peers on all gateways in the network.
You may choose to configure the gateway with rotary dial peers to handle OSP-based interconnects instead of explicit patterns. Although this may reduce the dial plan's sensitivity to changes, it still requires additional dial-peer provisioning to support failover. In this case, gateways are configured to try to terminate the call within their own administrative domain, first through RAS. If RAS offers no termination possibilities, either by explicit ARJ or RAS timeout, the gateways may fall back to a secondary dial peer to reoriginate the VoIP call through OSP.
Consider a gateway provisioned with two dial peers having identical generic destination patterns. One dial peer points to session target RAS; the other points to session target settlement. The RAS dial peer is given a higher priority than the settlement dial peer, so that it is always attempted first. In the event that the RAS dial peer fails, the gateway then attempts to send the call to an OSP server through the secondary dial peer.
This reduces the amount of maintenance of OSP dial peers to accommodate dial plan changes, but adds post-dial delay to all OSP-based interconnect calls.
•
You can also send duplicate records to a AAA server for internal accounting. These CDRs may be used to cross-check any settlement issues with the OSP provider. You may optionally employ a mediation application to automate this process.
•
IP-to-IP-Based Interconnect (Transit Network) with DGK Call Topology
If you select the IP-to-IP-based interconnect (transit network) with directory gatekeeper call topology for this service, consider the following issues:
•
•
•
You must still share gateway-IDs and passwords with your interconnecting partners. However, the back-to-back gateway allows you to isolate interdomain security information between service providers. That is, ITSP A does not need to know ITSP B's security information, and vice-versa, for the two to complete calls between each other.
IP-to-IP-Based Interconnect (Transit Network) with OSP Call Topology
If you select the IP-to-IP-based interconnect (transit network) with OSP call topology for this service, consider the following issues:
•
•
•
Card Services (Prepaid and Postpaid)
You can host prepaid services for multiple service providers on their infrastructure. In addition, most prepaid service providers use VoIP wholesalers to terminate long-distance calls that are placed by prepaid subscribers. Using the integrated voice response (IVR) feature in the Cisco VoIP gateways, and real-time authorization and call accounting systems provided by Cisco ecosystem partners, service providers can offer this service over a VoIP network and lower the cost and deployment time of calling-card services.
Like prepaid services, you can also host postpaid services. An example is basic calling that is accessed by the 800 prefix, a calling card number, or a PIN. With postpaid service, the authorization is not tied to call rating. Consequently, call rating does not have to happen in real time, and there may be more partner billing-system options that perform adequately at scale. After calls are made, a billing system contracted by the company charges the carrier.
TDM-to-TDM Call Topology
If you select the TDM-to-TDM call topology for this service, consider the following issues:
•
•
•
•
•
TDM-to-IP Call Topology Using Directory Gatekeeper-Based IP Interconnect
If you select the TDM-to-IP call topology using directory gatekeeper-based IP interconnect for this service, consider the following issues:
•
Alternatively, you can provision the gatekeepers and directory gatekeepers to first route the call to a back-to-back gateway for IVR services, based on the end user dialing a specific access number. The directory gatekeeper knows to send calls destined to this access number to a particular IVR zone consisting of back-to-back gateways. The local gatekeeper is provisioned to send calls destined to this access number to a designated ingress-only gateway of the back-to-back pair. The egress gateway is explicitly given a gateway priority of 0 to avoid sending calls through the back-to-back gateway in the reverse direction.
The ingress back-to-back gateway is provisioned to pass this call through TDM to the egress gateway. The egress gateway then applies the required IVR script, based upon the DNIS received. The egress gateway collects the desired destination pattern and reoriginates the call into the H.323 network as if it were a normal TDM PoP.
•
•
•
•
In the case where IVR is implemented directly on the terminating gateway, the called number is supplied by the end user and is routed to the destination. It is unreliable to identify the originating carrier based upon dialed DNIS. Modifications may be made to ANI, but this is also unreliably enforced on originating PC endpoints. Therefore, multiple branding is not supported in this implementation for IP interconnect partners.
For IP interconnects front-ended with a back-to-back gateway, you may support branding services to individual carriers by providing separate access numbers which PC users dial to reach various back-to-back gateway zones. For example, carrier A is given a special destination number to dial into a back-to-back gateway IVR pool.
TDM-to-IP-Based Interconnect with OSP Call Topology
If you select the TDM-to-IP-based interconnect with OSP call topology for this service, consider the following issues:
•
•
•
•
•
IP-to-IP-Based Interconnect (Transit Network) with Directory Gatekeeper Call Topology
If you select the IP-to-IP-based interconnect (transit network) with directory gatekeeper call topology for this service, consider the following issues:
•
•
•
•
IP-to-IP-Based Interconnect (Transit Network) with OSP Call Topology
If you select the IP-to-IP-based interconnect (transit network) with OSP call topology for this service, consider the following issues:
•
•
•
•
Step 9: Configure and Provision Components
Describing how to configure and provision the components associated with your wholesale voice solution is beyond the scope of this document. For more information about configuring specific devices, please refer to the configuration material that shipped with your network devices, or, for Cisco products, please refer to http://www.ciscco.com.
Related Documents
•
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)