|
|
This chapter provides basic design information related to Service A, Minutes Aggregation and Resale (Including ASP Termination). For the background required to understand the issues discussed, refer to "Solution Architecture."
For Service A, five templates cover the five call topologies introduced in IP Interconnect Variations:
These templates are for simple carrier-interconnect scenarios. In all cases, basic H.323 fault tolerance is achieved as in Fault Tolerance.
For special issues related to limited egress carrier-sensitive routing and interconnect to Clarent-based clearinghouses, see "Deploying Service Options."
This application uses the basic large-scale H.323 dial plan (gatekeeper core) concept as discussed in Basic Dial Plan.
The wholesale provider dedicates separate GWs for each TDM interconnect partner. The billing system is provisioned to identify carriers by means of originating and terminating GW IP addresses. This allows the wholesaler to generate appropriate CDRs to provide settlement.
Calls in this template type are all intradomain calls. Security may be accomplished as discussed in Security.
The basic large-scaleH.323 dial plan concept as discussed in Basic Dial Plan, is still used. To interconnect wholesaler POPs with IP interconnect partners, the peering DGKs simply require additional LRQ route statements to direct certain destination patterns between the wholesaler and the IP-based interconnect partner. Routes between IP interconnect partners and wholesaler POPs are easily added and modified in the DGK, as the rest of the network remains untouched.
In this case, the wholesaler owns only one of the GWs in the conversation, either the originating or the terminating GW, depending on the call direction. The wholesaler's billing application must be able to extract enough information from one side of the call to generate a CDR. This requires correlating either source or destination IP addresses with a particular IP interconnecting carrier, depending on the call direction. To bill the interconnecting customer accurately, the wholesaler's billing system must maintain a database of this information. 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 GWs or PC clients, this list can be extensive. The list may be reduced if the ITSP forgoes performance and uses GKRCS. Once carrier identification issues are solved, AAA billing and settlement are done on the GWs.
Alternatively, the originating ITSP or ASP can include a mutually recognized carrier ID (such as prepended ANI) in the H.323 SETUP message. The terminating GW will then include this information in the AAA record. The billing application may be provisioned to recognize this carrier ID and associate it with an originating carrier. However, this implies a trusting relationship between service providers.
Security may be accomplished as discussed in Security. However, this requires the wholesaler to share a database of all gateway user IDs and passwords with all IP-based interconnecting partners. This implies a trusting relationship with partnering carriers.
There are two methods an OSP-based interconnect partner may use to connect into the wholesaler's network, designed as discussed in Basic Dial Plan. This is by implementing OSP either directly on the GW, or through a back-to-back OSP interconnection zone.
From a call routing perspective, OSP is most readily accepted into the network if an OSP interconnection zone is used. This interconnection zone consists of back-to-back GWs. One GW handles the RAS side of the call and the other the OSP side of the call. From the perspective of the DGK, this simply looks like another TDM zone managed by a local GK. The DGK simply adds LRQ routes to the OSP interconnect-zone GK for specific destination patterns serviced by that OSP interconnect partner.
Provisioning requirements for the GWs within this OSP interconnection zone are only slightly different from requirements that are in a normal wholesaler TDM POP. The OSP-side GW is configured to interface with the OSP server. The RAS-side GW is provisioned like a normal POP RAS GW. The back-to-back GWs are then configured to send all calls received over IP out TDM interfaces to the opposite GW, using single-stage dialing. This method of OSP interconnect isolates provisioning tasks to the back-to-back GW pair, the local hopoff GK configuration, and an added LRQ route in the DGK. The rest of the network is unaffected.
If OSP is implemented without an interconnect zone, dial plan provisioning increases dramatically in order to support OSP directly on the GWs. Separate dial peers are needed on all POP GWs to send calls to the OSP server for route resolution, instead of through RAS. The wholesaler may provision dial peers on the GWs to send calls to the OSP server for specific destination patterns.
For example, if the provider knows that all calls to Australia need to be terminated by OSP, the wholesaler may insert a dial peer into its GWs 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 GWs in the network. This becomes a large burden for a wholesaler with many GWs.
The wholesaler may choose to configure the GW with rotary dial peers, instead of explicit patterns, to handle OSP-based interconnects . Although this may reduce the dial plan's sensitivity to changes, it still requires additional dial-peer provisioning to support failover. In this case, GWs 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 GWs may fall back to a secondary dial peer to reoriginate the VoIP call through OSP.
For instance, the GW is provisioned with two dial peers having identical destination patterns. This is typically a generic pattern (any nonlocally supported number). One dial peer points to session-target RAS and the other points to session-target settlement. The RAS dial peer is given a higher priority than the settlement dial peer, so that the former is always attempted first. In the event that the RAS dial peer fails, the GW then attempts to send the call to an OSP server through the secondary dial peer.
This method reduces the amount of maintenance of OSP dial peers that is required to accommodate dial plan changes, but adds postdial delay to all OSP-based interconnect calls.
In any OSP implementation, the OSP server collects usage information and generates CDRs. This usage information is extracted directly from the GWs registered to the OSP server, regardless of whether they are functioning as back-to-back GWs or as normal POP GWs.
The wholesaler may also send duplicate records to an AAA server for internal accounting. These AAA CDRs may be used to cross-check any settlement issues with the OSP provider. As an option, the wholesaler may employ a mediation application to automate this process.
If OSP is performed directly on the terminating GW, intradomain security continues to use (optionally) Cisco access lists, as in Template A2. Interdomain security uses OSP H.235 tokens for registration only, with the caveats to the dial plan as noted in Security. If a back-to-back GW zone is used, the OSP token management is offloaded from the wholesaler's POP GWs, and is handled instead by the OSP GW in the back-to-back zone. The OSP GW in the back-to-back pair supports the H.235 OSP tokens, whereas the RAS GW (optionally) implements Cisco access lists. This use of the back-to-back OSP transit zone makes it possible to sidestep the security caveats previously mentioned in the direct method.
Interconnections between IP-based service providers are sent to a back-to-back GW transit zone. Each IP interconnecting partner has a dedicated transit zone. If both partners are interconnected through a DGK peering relationship, this adds complexity to the large-scale H.323 dial plan architecture discussed in Basic Dial Plan. The dial plan must be altered to provide dedicated ingress and egress DGKs to route calls properly through the wholesaler network. IP interconnect from one carrier using DGK peering and an OSP-based interconnection partner using a back-to-back OSP interconnection zone is accomplished in essentially the same way as for Template A2.
The back-to-back GW provides a point in the call-signaling path from which the wholesaler may gather accounting information. Billing can be done from the back-to-back GW in the same manner as described as in the simple interconnect method of the TDM-to-TDM scenario in Template A1.
The back-to-back GW zone also allows the wholesaler to obscure an originating ITSP carrier's information from the terminating ITSP carrier, if desired. Calls sent into a terminating ITSP (call it ITSP B) look as if the wholesaler sourced them. ITSP B has no idea that the originating ITSP (call it ITSP A) sourced the call.
Gateway IDs and passwords still must be shared among the wholesaler and interconnecting partners. However, the back-to-back GW allows the wholesaler to isolate interdomain security information between SPs. 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.
This extends the method described in Template A3 to include sending calls to another OSP provider through another back-to-back GW zone or another DGK-based service provider, depending on LRQ routing entries in the DGK.
Billing is between OSP providers and is done just as discussed in Template A3, but for two OSP back-to-back GW zones. The originating zone provides settlement CDRs for the originating carrier, and the terminating zone provides settlement CDRs for the terminating carrier. If the call is instead sent to a DGK interconnect, then AAA RADIUS records are used on that side. If a mediation application is used, the AAA may be reconciled with the OSP usage records.
Security is accomplished as in Template A3.
Posted: Wed Jan 22 15:24:00 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.