|
|
This chapter introduces the functional areas, interconnection types, and components that make up the architecture of the Cisco Wholesale Voice Solution. This provides a foundation for understanding the deployment of various solutions, and introduces a variety of issues that must be taken into consideration for each solution.
This chapter presents the following major topics:
The wholesale VoIP provider may need to accommodate a variety of factors in various combinations, depending on the SP's partners. These factors include, but are not limited to, interconnection methods, billing services and settlement, call control, IVR options, and network management. To support this variability, the Cisco Wholesale Voice Solution encompasses five functional areas designed to respond to those requirements.
Figure 2-1 depicts these functional areas with respect to the wholesale VoIP network. Each of the areas, including interconnection methods and related issues, will be discussed later.
Each functional area has responsibilities and deployment considerations that are influenced by the application and call topology. For example, in the case of simple carrier interconnect with an ITSP, the wholesale provider must consider the configurations and components of each functional area throughout the network, such as POPs, GKs, and the shared support services needed to support routing, billing, settlement, and security options. The functional areas are discussed below.
The GK functional area, illustrated in Figure 2-2, consists of Cisco GK, Cisco DGK, and optional Ecosystem Partner GK platforms; it is the foundation of a large-scale H.323 network design. GKs enable a network to scale in growth, performance, and dial plan administration. They also enable some intelligent call routing and fault tolerance features. In addition, GKs support interactions with shared services and provide GK-based interconnections with other providers if the application demands.
 |
Note Note: Cisco 3660s and 7200s are used as GK or DGK platforms. |
Issues related to the gatekeeper core are discussed below.
Large H.323 VoIP networks are segmented into different regional zones, each managed by a GK. Segmentation is based upon several factors, such as the desired call throughput (for example, BHCA), the dial plan, and the number of active endpoints.
As network coverage and capacity grows, the service provider may expand by simply adding new GWs or POPs to GKs until performance limitations for the GK platform are met. At that point, the service provider may expand by simply adding new GKs. Traffic is routed between GK zones by means of LRQ/LCF RAS messages.
As more GKs are added to the network, inter-GK routing configurations increase dramatically. The smallest change to the dial plan requires configuration changes to all GKs in the network. At medium scales (that is, where the number of zones is relatively small), these changes can be managed by having a single dial plan that is downloaded through TFTP to all of the GKs within the wholesaler's administrative domain. As scale increases, the number of zones and the rate of dial plan updating increases. In this case, rather than burdening every GK with routing information for the entire network, a DGK is used to isolate and alleviate dial plan provisioning. For more information about dial plan provisioning across functional areas, see Basic Dial Plan.
Cisco GKs and DGKs can be designed to enable redundancy in the dial plan. At the edge, GWs at each POP are configured to support registration with an alternate GK in the event the primary GK fails. In the core, GKs are configured to support sequential LRQ messages to provide redundant paths to alternate DGKs (ALTDGKs) and also accommodate local zone-fragmentation conditions. At the DGK level, both sequential LRQs to accommodate zone fragmentation and HSRP (Hot Standby Routing Protocol) are configured to provide redundancy at the highest layer. For more information about fault-tolerant architectures across functional areas, see Fault Tolerance.
Wholesale providers have the option to interconnect routes with other service providers by using a DGK. In this model, the wholesaler and the interconnect partner configure the DGKs to exchange LRQ RAS messages between their administrative domains to resolve call routing for desired prefixes. Sequential LRQs may be implemented on the DGK to support limited-egress CSR applications. Back-to-back GWs may be used to support IP-to-IP call topologies. Specific details are discussed for the deployment templates presented later in this document.
To validate whether or not a call was originated from a valid endpoint, Cisco GWs and GKs may optionally implement access lists to provide secure gateway registration. In order to support this, GKs must be configured to interact with an AAA server. For more information about security across different functional areas, see Security.
GKs must be enabled to support SNMP community strings, so that external management platforms such as CiscoWorks2000 Voice Manager (CVM) version 2.0.2 and Cisco Info Center (CIC) can provision networks, access reporting information, and receive traps through SNMP. Cisco Voice Manager is part of the CiscoWorks2000 suite.
If the wholesaler desires, the GK may be configured to support the remote downloading of, for example, software images, configurations, TCL scripts, and audio files through a TFTP server.
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 AAA servers, billing systems, OSP servers, EMS platforms, NMS platforms, and TFTP servers.
Issues related to shared support services are discussed below.
An AAA server collects usage records directly from the GWs. Alternatively, an OSP server may also collect usage records for only interdomain calls. The details of billing implementations vary according to the application enabled.
Complex access lists may be provisioned on the GWs to implement security functions. In this case, a TFTP server may be used as a central location for storing, administering, and uploading GW configurations. (However, this method is highly unscalable.)
An OSP server supplies security functions for OSP interconnect methods. For more information about implementing security across functional areas, see Security.
|
Note The Cisco Wholesale Voice Solution supports Cisco H.235 security for registration only. For reasons of AAA latency, H.235 security is not supported on a per-call basis. When per-call security is required, Cisco recommends that you use access lists. |
For OSP-based interconnect scenarios, an OSP server handles call routing functions, as well as some complementary provisioning, on the OSP GW dial peers. Additionally, it is possible for an external server to provide enhanced call routing functions by interfacing with Cisco GKs and DGKs through GKTMP (GateKeeper Transaction Management Protocol). For a discussion of the impact of call routing on the dial plan, see Basic Dial Plan.
|
Note GKTMP applications are not specified for the Cisco Wholesale Voice Solution, nor are they tested. |
Standard SNMP NMS platforms (for example, HP OpenView) may be used to provide generic SNMP management functions. CVM 2.0.2 provides SNMP-based statistics collection, as well as a very limited dial plan and component provisioning tool. Reports may be generated by means of Ecosystem Partner reporting engines that integrate with CVM 2.0.2. CIC (Cisco Info Center) may be used if fault management is desired. Additionally, Cisco's Internetwork Performance Monitor (IPM) may be used to monitor network QoS.
|
Note CVM 2.0.2 is recommended as the NMS platform. The Cisco Wholesale Voice Solution recognizes Trinagy (http://www.trinagy.com) as a vendor of report-generating applications. |
A remote TFTP server may be used to store IVR prompts, TCL scripts, software images, and configurations for download.
Wholesale service provider networks consist of POPs that house gateways to transport voice traffic between TDM and IP networks. POPs are active components in call topologies 1, 2, and 3, as discussed in IP Interconnect Variations. Non-SS7 based POPs, which tend to be smaller than their SS7-based counterparts, receive signaling from the TDM network on the same physical interface that supports bearer traffic. There may be a logical separation between signaling and bearer traffic within the interface, as there is with ISDN. Actual gateway platforms used at these POPs will depend upon the signaling type offered by the TDM interconnect. Figure 2-3 illustrates non-SS7-based POP signaling. Interfaces supported through in-band signaling are FXO/FXS, E&M, BRI/PRI, DS1/DS3, E1/R2, and T1 CAS.
|
Note The Cisco AS5800 is not currently supported in the Cisco Wholesale Voice Solution. |
In addition to the physical interface and signaling variations, there are also a number of platform-independent software features and functions that must be enabled on the POP GWs to support an application. These include POP size, dial plan, fault-tolerance, security, billing, network management, and bearer transport responsibilities.
Issues related to non-SS7-based POPs are discussed below.
The signaling types can vary greatly and can include analog FXO, analog E&M, , DS1 interfaces with E1/R2 variations or T1 CAS variations, and may include DS3 interfaces on the upper boundary.
Low-density analog interfaces generally discourage carrier interconnects, so calls that ingress the POP will almost always be for card services. Calls that egress the POP are re-originated into the PSTN, usually to bypass PTT interconnect tariffs. Generally, DS1 and DS3 interfaces either provide card services or interconnect wholesale systems to their customers.
Additional considerations arise with small-scale POPs. The hardware footprint of the equipment, as well as the amount of nonbearer traffic, must be minimized, because the IP network bandwidth coming into the POP from the wholesaler is likely to be extremely low (assume sub-E1 bandwidth).
Dial plans encompass more than one functional area, and their responsibilities are distributed among GWs, GKs, and DGKs. The GWs have to deal with the local POP portion of the dial plan. This includes provisioning the required dial peers, translation rules, and RAI thresholds. For more information refer to Basic Dial Plan.
For reasons of performance and accuracy, Cisco recommends that billing be done from the GW whenever possible. The wholesaler must configure the Cisco GWs to interact with shared AAA services to support billing and optional debit card applications.
If the wholesaler desires, the GW may be configured to support an alternate GK with which it will register should the primary GK fail. To support this concept fully, this implies a related configuration in the GK functional area. For more information about fault tolerance and its requirements across functional areas, see Fault Tolerance.
Different security options are available to a wholesaler. To support security, GWs may be configured with complex access lists. For OSP-based interconnect scenarios, the GWs must be provisioned to interact with the OSP server to support OSP security options. For more information about implementing security across functional areas, see Security.
GWs must be enabled to support SNMP community strings, so that external management platforms such as CVM 2.0.2 and CIC can provision, access reporting information, and receive traps through SNMP.
Unless the wholesaler has previously agreed to limit the types of calls exchanged between other carriers, the wholesaler providing interconnect may receive traffic of any bearer type. The wholesaler GWs must be able to pass voice, real-time fax, and modem traffic transparently across the VoIP network.
If the wholesaler desires, the GW may be configured to support the remote downloading of prompts, software images, and configurations through a TFTP server.
These POPs have generally the same deployment considerations as the non-SS7-based POPs with respect to billing, security, network management, transparent bearer transport, and TFTP servers. However, here there are additional considerations related to SS7 interconnect signaling. Added considerations also appear with respect to POP size, dial plan responsibilities, and fault tolerance.
Issues related to SS7-based POPs are discussed below.
SS7-based POPs tend to be larger than their non-SS7 counterparts, and consist of DS1 and DS3 IMTs to the GWs. PSTN-side call control is provided by using Q.931 backhaul from Cisco SC2200s running Cisco SS7 Interconnect for Voice Gateways to Cisco AS5300 series GWs. POPs may optionally support Cisco SLTs (Signaling Link Terminals) to terminate SS7 signaling on behalf of the Cisco SC2200 Signaling Controller.
Figure 2-4 illustrates the signaling used in an SS7 POP, showing the relationship among Cisco SC2200 hosts, Cisco SC2611 SLTs, and Cisco GWs.
For SS7-based POPs, the wholesaler has the option of performing number modification in either the GW, the Cisco SC2200 signaling controller, or both. The Cisco SC2200 allows digits in the called or calling party number fields to be added, deleted, or modified. It is also possible to modify the nature of address (NOA), perform black listing and white listing, and do AIN triggering. In addition to normal H.323 configurations, the GW must be provisioned with an RLM (Redundant Link Management) group in order to interface with the Cisco SC2200. Once the Cisco SC2200 and GW are provisioned to interface with each other, the rest of the H.323 dial plan remains the same as discussed in Basic Dial Plan.
The GW may support a backup Cisco SC2200 in case the primary SC2200 fails. It may take up to 3 seconds for the GW to detect and fail over to the other Cisco SC2200. During this time, any new calls will not be processed. Furthermore, any calls that were in the process of being set up are also lost. Calls that are active at the point of failover, however, remain in progress.
GWs may support the same H.323 fault-tolerance conditions for GK failover as discussed in Fault Tolerance.
|
Note Cisco recommends that you provide redundant Cisco SC2200 hosts and Cisco SLTs in SS7 applications. |
The back-to-back GW is a special component used for a variety of applications—particularly in billing (see Billing), by establishing a point in the call-signaling path from which to bill. GWs are deployed as a pair in a back-to-back TDM T1 CAS, ISDN PRI, or E1/R2 trunk, single-stage dialing configuration. Depending on the application, back-to-back GWs may function as unidirectional or bidirectional call devices.
|
Note Cisco recommends that you use ISDN T1/E1 signaling between the GWs in a back-to-back pair. |
For example, in an IVR application, the back-to-back GW has a dedicated half that receives all calls while the other half is dedicated to originating calls. In contrast, for an OSP interconnect zone application, the back-to-back GW may process calls in both directions, although each GW is responsible for separate protocols.
Although consisting of two GWs, the term "back-to-back GW" is most frequently used to refer to both units as an integrated pair. For unidirectional applications, to provide added clarity in discussing back-to-back GW pairs, we refer to the individual GWs in a pair as an ingress (inbound) VoIP GW and an egress (outbound) VoIP GW with respect to the call direction. For bidirectional applications, we generally refer to the GW by the protocol it supports.
Figure 2-5 illustrates the relationship of the back-to-back GW to the wholesaler and an ingress and egress carrier.
The GW pair allows wholesalers to insert themselves into the call-signaling path in IP-to-IP interconnect call topologies. This allows them to generate usage records by means of AAA, interconnect with Clarent-based and OSP-based environments, and front-end PC-to-phone applications for IP-based interconnect partners. In many ways, the back-to-back GW area functions just like a normal non-SS7 POP, with the implications discussed in the subsections that follow.
Back-to-back GWs simply need to be configured with similar TDM signaling types. Platforms considered for back-to-back configurations are the Cisco 3600 series, Cisco AS5300, Cisco AS5350, and Cisco AS5400.
Voice quality suffers especially in the case of tandem compression. The addition of back-to-back GWs introduces additional postdial delay as well as added latency for all calls. There is even greater impact if more than one back-to-back GW zone is traversed. Fax relay may also suffer. Modem passthrough is highly unreliable, and as a result is not supported in scenarios that employ back-to-back GWs.
The back-to-back GW is responsible for manipulating digits and tech prefixes to fit into the general GK and DGK dial plan, as discussed in Basic Dial Plan. It also includes separating ingress and egress GWs in the GK call routing table. The extent of these considerations depends upon the application and the DGK/GK dial plan design. Dial plan responsibilities are discussed in more detail in the specific application templates presented later in this document.
One of the main benefits of the back-to-back GW is that it establishes a point in the call-signaling path from which to bill for IP-to-IP call topologies. The back-to-back GW largely functions just as a normal POP GW. Billing options vary by application type, and are discussed in more detail in the specific application templates presented later in this document.
If the wholesaler desires, the back-to-back GWs may be configured to support an alternate GK with which it will register should the primary GK fail, just as with a normal TDM POP GW. For more information about fault tolerance and its requirements across functional areas, see Fault Tolerance.
Back-to-back GWs have the same security options and implications as do normal POP GWs. For more information about security token mechanisms across functional areas, see Security.
Back-to-back GWs have the same responsibilities as in a normal TDM POP.
This is the same for back-to-back GWs as in a normal TDM POP.
Wholesale providers need to interconnect with other SPs, ITXCs, and other entities in order to offer minutes aggregation and termination, ASP termination, or card services. The interconnection method used is referred to as a call topology. A key question must be answered before a Cisco Wholesale Voice Solution can be initiated:
What is the interconnection type between the wholesale provider and other service providers?
The appropriate template that the SP will use to deploy the Cisco Wholesale Voice Solution is determined by the functional areas required, as previously discussed, as well as the call topology and SP interconnection methods that are used.
Figure 1-1 showed the possible interconnection options that the wholesale VoIP service provider (SP) may need to accommodate at both the call ingress and egress sides. The possibilities are TDM at both ends, IP at both ends, and TDM at one end and IP at the other. The answer to the above question is determined by the nature of the demarcation between the wholesaler and those partner providers.
The call topology influences the configuration needs of the other functional groups within the network in supporting a given application. For example, if the wholesale provider enables simple carrier interconnect between an ASP and an IXC, then an IP-to-TDM topology would be used. The wholesale provider would then have to address the configuration considerations for that application, such as call routing, as well as shared support services for billing, settlement, and security in a way that is particular to that topology type.
Consider the following simple carrier-interconnect scenarios. Only raw telephony minutes are exchanged, without the need for prompts, messages, or other user interaction. However, attention must be paid to routing, billing, and settlements.
1. Wholesaler sends traffic to an IXC, LEC, or other wholesaler over TDM.
This is fairly straightforward. The wholesaler must ensure that the POP supports the offered TDM signaling type. Billing may be done at the terminating GW through AAA RADIUS, or on the TDM switch that provides the interconnect.
2. Wholesaler receives traffic from an IXC, LEC, or other wholesaler over TDM.
Receiving traffic is fairly straightforward, with billing essentially as above. However, the wholesaler will most likely need to identify the source carrier in billing records. To determine which TDM interconnect partner originated the call, source-carrier information can be collected on either the originating GW or the TDM switch.
3. Wholesaler sends traffic to an ITSP or ASP over IP.
IP interconnections complicate configurations. The wholesaler must choose how to route calls over IP to the terminating ITSP, ensure interoperability in bearer transport (by supporting, voice, fax, and modem calls), settle calls properly (through either OSP or CDR mediation), and provide support for desired security options (for example, through either H.235 or OSP).
4. Wholesaler receives traffic from an ITSP or ASP over IP.
In addition to the considerations in the preceding scenario, the wholesaler must identify the source carrier for billing purposes. This is not trivial for a GK-based interconnection, as the wholesaler does not own the CDRs of the originating GW at the ITSP/ASP. The wholesaler must therefore extract that information at the terminating GW under that GW's administrative control (by means of either OSP or AAA).
Alternatively, in interconnects that use OSP, the wholesaler may either own an OSP server or depend on a third-party clearinghouse OSP server to provide information about the originating carrier for settlement.
5. Wholesaler provides IP-to-IP transit network between two ITSPs/ASPs.
This is a special case in which the wholesaler owns neither the originating nor the terminating GW, but rather simply provides transit between two ITSPs/ASPs. A wholesaler providing this service must therefore insert itself into the call signaling path to bill and settle calls, as well as to obscure originating carrier information from the terminating carrier and vice-versa. The wholesaler must also be aware of potentially different bearer transport options (such as codec types) and security options between the two interconnecting networks for which the wholesaler is providing transit.
To accommodate this application, the Cisco Wholesale Voice Solution applies the concept of a back-to-back GW functional area.
The above scenarios, and others, can be accommodated by four fundamental call topologies:
These topologies, which are the foundations of a solution design, are discussed below. Some application examples are included in each description.
This is a single administrative domain, and is the most fundamental call topology. Here the wholesale service provider both receives and terminates traffic between other service providers (for example, IXCs or LECs) over TDM interfaces at each end. Figure 2-6 illustrates this topology.
Because the interconnect is confined to TDM interfaces on GWs that are administered by the wholesale provider, deployment considerations with respect to routing, security, billing, and settlement are fairly straightforward (assuming no CSR applications are required).
The provider must take the following issues into account:
Applications for Topology 1 include the following:
The wholesaler may want to increase call volume or coverage by adding interconnections with other IP-based service providers. Here the wholesale service provider receives traffic from other service providers (such as IXCs or LECs) over TDM interfaces. Figure 2-7 illustrates this topology.
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.
In addition to the TDM-related issues discussed under Topology 1, the wholesale provider must take into account the following issues related to the IP interconnect:
Applications for Topology 2 include the following:
This is essentially the same as Topology 2, except that the call direction is reversed. Here the wholesale service provider receives traffic from other service providers (such as ITSPs or ASPs) over IP and terminates traffic at its POPs to other service providers (such as IXCs or LECs) over TDM interfaces. Figure 2-8 illustrates this topology.
Because the wholesale provider is now receiving traffic from other providers over an IP interconnect, the wholesale provider must take into account the following issues:
Applications for Topology 3 include the following:
Finally, the wholesaler service provider may want to provide transit between different IP-based interconnect partners. Here the wholesaler exchanges traffic among other service providers (such as ITSPs or ASPs) over IP connections only. Typically, the wholesaler receives traffic from an ITSP or ASP. If the wholesaler cannot terminate the call at one of its own POPs, it passes the call off to another service provider. (This is simply a transit VoIP network.) Figure 2-9 illustrates this topology.
In sending and receiving traffic between two IP interconnects, the wholesale service provider has increased challenges with respect to the following issues:
Applications for Topology 4 include the following:
Finally, in addition to the above interconnection possibilities, deployment templates are determined on the basis of whether a DGK or OSP server is used. The following scenarios are considered:
2. TDM to IP with DGK-based interconnect
3. TDM to IP with OSP-based interconnect
4. IP to IP with DGK-based interconnect
5. IP to IP with OSP-based interconnect
For the two service types, these scenarios are discussed in detail, in the above sequence, in the following chapters:
Posted: Wed Jan 22 15:16:55 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
