|
|
This chapter provides basic design information related to Service B, Card Services (Prepaid and Postpaid). For the background required to understand the issues discussed, refer to "Solution Architecture."
For Service B, five templates cover the five call topologies introduced in IP Interconnect Variations:
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."
Card services typically affect dialing habits by employing two-stage dialing. Aside from this, dial plans remain basic. Once inside the wholesaler network, the call may either be terminated at one of the wholesaler's POPs or sent to another service provider through a TDM hopoff, using the basic large-scale H.323 dial plan architecture as discussed in Basic Dial Plan.
Card services for TDM-based interconnecting partners are supported on the wholesaler's originating GW. AAA-based billing is done on the GWs and is settled as discussed in Billing/Settlement. However, in order to offer prepaid services, the billing server must interact in real time with the AAA server.
An IVR script running on the originating GW performs user authentication. This IVR script interacts with an AAA RADIUS security server. Call-level security may be optionally implemented through Cisco access lists, as discussed in Security.
In order to support branding requirements, the wholesaler must be able to identify the necessary IVR script for the carrier. Different call scripts may be invoked, depending on the supplied DNIS. If desired, prompts may be stored remotely on a TFTP server.
For card services provided to TDM interconnect partners, this has the same considerations as outlined in Template B1. However, the wholesaler may want to provide card services for IP interconnecting partners as discussed in Service B: Calling Card Services (Prepaid and Postpaid). In this case, the wholesaler may route incoming VoIP calls directly to the terminating GW as normal and then implement the IVR.
Alternatively, the GKs and DGKs may be provisioned to route the call first to a back-to-back GW for IVR services, based on the end user's dialing a specific access number. The DGK knows to send calls destined to this access number to a particular IVR zone consisting of back-to-back GWs. The local GK is provisioned to send calls destined to this access number to a designated ingress-only GW of the back-to-back GW pair. The egress GW is explicitly given a gw-priority of 0 to avoid sending calls through the back-to-back GW in the reverse direction.
The ingress back-to-back GW is provisioned to pass this call through TDM to the egress GW. The egress GW then applies the required IVR script, based upon the DNIS received. The egress GW collects the desired destination pattern and reoriginates the call into the H.323 network, just as with a normal TDM POP.
AAA-based billing is done on the GWs as discussed in Billing/Settlement. However, in order to offer prepaid services, the billing server must interact in real time with the AAA server. For back-to-back GW scenarios, billing is done on one of the GWs as if it were a normal TDM POP.
Security is accomplished in the same manner as described in the simple interconnect application above. Added security is provided by the IVR script in authenticating IP-based users—either before the call enters the wholesaler's network (as with the back-to-back implementation), or at least before the call is completed through the wholesaler network (as with the terminating GW implementation).
Prompting for TDM interconnects is the same as in Template B1. In order to support the proper welcome announcements and local languages that are required for branding in IP interconnections, the wholesaler must be able to identify the source carrier before authenticating the user.
Where IVR is implemented directly on the terminating GW, the called number is supplied by the end user and is routed to the destination. It is unreliable to identify the originating carrier on the basis of 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 GW, the wholesaler may support branding services to individual carriers by providing separate access numbers, which PC users dial to reach various back-to-back GW zones. For example, carrier A is given a special destination number to dial into its back-to-back GW IVR pool.
Dial plans may be administered in a similar fashion as discussed in the card services application in Template B2. However, in this case, front-ending IVR calls do not require routing to separate back-to-back GW IVR zones. IVR services may be performed directly on the interconnecting OSP back-to-back GW pair.
Billing is done in the same manner as for Template B2.
Security is implemented in the same manner as in Template A2 (Template A2: TDM-to-IP Call Topologies Using DGK-Based IP Interconnect). Added security is provided by the IVR script in authenticating IP-based users either before the call enters the wholesaler network (as with the back-to-back GW implementation), or at least before the call is completed through the wholesaler network (as with the terminating GW implementation).
Prompting is implemented in the same manner as in Template B2. For OSP interconnects using a back-to-back GW zone, the IVR services may be implemented on the RAS side GW as if it were a normal POP GW.
The wholesaler may want to provide card services for IP interconnecting partners by using a back-to-back GW IVR zone as the front-ending application. See Template A2 (Template A2: TDM-to-IP Call Topologies Using DGK-Based IP Interconnect).
Billing is done on one of the GWs as if it were a normal TDM POP. AAA-based billing is done on the GWs as discussed in Billing/Settlement.
Security is accomplished as in Template A4 (Template A4: IP-to-IP-Based Interconnect (Transit Network) with DGK). Added security is provided by the IVR script in authenticating IP-based users before the call traverses the wholesaler's network in the back-to-back GW.
Prompting is done as in Template B2. The back-to-back GW essentially operates as the front-end application.
The wholesaler may want to provide card services for OSP-based IP interconnecting partners by using a back-to-back GW zone, as discussed in Template B2.
Billing is done on one of the GWs as if it were a normal TDM POP, as in Template B2.
Security is accomplished as in Template A5 (Template A5: IP-to-IP-Based Interconnect (Transit Network) with OSP). Added security is provided by the IVR script in authenticating IP-based users before the call traverses the wholesaler's network in the back-to-back GW.
Prompting is done as in Template B2 on the back-to-back GW.
Posted: Wed Jan 22 15:24:37 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.