|
|
This appendix gives a step-by-step approach to accomplishing some frequently used VRC operations. Most of the tasks are performed within a VRC design session. Multiple tasks can be performed within the same design session. Changes made within a design session do not take effect until the design is committed.
To design a new dial plan in VRC, perform these tasks in the following order:
1. Prepare the dial plan infrastructure.
3. Validate the design and fix any discrepancies found.
6. Distribute the baseline dial plan design.
Use this procedure to prepare the dial plan infrastructure in VRC.
 |
Note Your elements must already be in the topology, gateways must have voice ports assigned, and you are in the Design View. |
To prepare the dial plan infrastructure, perform these tasks in the following order:
1. For the Administrative Domain (AD):
2. Create regions. For each region that you create, you must:
a. Create a directory gatekeeper group (DGKGrp) if you want the region to be hierarchical.
b. Assign directory gatekeepers (DGKs) to the directory gatekeeper group.
c. Create gatekeeper groups (GKGrps).
Use this procedure to create routes for each zone in your dial plan.
|
Note The dial plan infrastructure must already be defined and the dial plan is open in the Design View. If you have not defined the dial plan infrastructure, see Preparing the Dial Plan Infrastructure A-1. |
To create routes, perform these tasks in the following order:
1. Locate the zone in the dial plan.
2. Assign zone prefixes to the zone.
3. Assign hopoff technology prefixes (optional).
4. Assign a gatekeeper group to the zone.
5. Create translation profiles and rules (optional).
6. Create a route scope for the zone.
7. Create egress routes and ingress routes.
Use this procedure to add a new gateway to your dial plan and enhance network capacity. You can configure a new gateway to operate like other gateways in your dial plan.
|
Note The baseline dial plan must be defined, the gateway is in the topology, and you are in the Design View. |
To add a new gateway to an existing network, perform these tasks in the following order:
1. Add a gateway to the dial plan in the desired zone.
2. Verify that existing routes apply to that gateway. For example, any routes with a route scope of the whole managed zone.
3. Add any new routes, if needed.
4. Commit your changes. The baseline dial plan is updated.
Use this procedure to add a new gatekeeper to an existing dial plan for redundancy purposes. You can configure a second gatekeeper as an alternate or configure a cluster (high-capacity gatekeeper feature) with multiple gatekeepers.
|
Note Before you add a redundant gatekeeper, be sure that the baseline dial plan has been defined, the gatekeeper is in the topology, and you are in the Design View. |
To add a redundant gatekeeper, perform these tasks in the following order:
1. Select the gatekeeper group that needs a redundant device.
2. Specify the redundancy mechanism (cluster, overlap, HSRP, or both).
3. Commit your changes to the baseline dial plan.
|
Note Configure an overlap redundant gatekeeper configuration at the gateway. Configure a clustered redundant gatekeeper configuration at the gatekeeper. |
Use this procedure to make adjustments to your dial plan if a Numbering Plan Area (NPA) overlap occurs.
The baseline dial plan must be defined, you are adding no additional gateways, and you are in the Design View.
To adjust the dial plan for an NPA overlap, perform these tasks in the following order:
2. Set up the following parameters for the affected zone:
a. Add new (overlap) zone prefix to the zone.
b. Create egress routes for the new prefix (create new route scopes if necessary).
3. Commit your changes to the baseline dial plan.
Use this procedure to make adjustments to your dial plan if a Numbering Plan Area (NPA) split occurs.
The baseline dial plan must be defined and you are in the Design View.
To adjust the dial plan for an NPA split, perform these tasks in the following order:
2. Create a new zone in the same region.
3. Add gateways to the new zone by one of the following methods:
4. Set up the following parameters for the new zone:
5. Commit your changes to the baseline dial plan.
Use this procedure to set up hairpinning on a gateway. Hairpinning is a call routing capability that sends a call back to the PSTN portion of the network if the call cannot be serviced by the Voice-over-IP (VoIP) portion of the network.
The baseline dial plan is defined and you are in the Design View.
To set up hairpinning, perform these tasks in the following order:
1. Create a route scope for the hairpin route.
a. Set the dial peer type to both.
a. Enter a destination pattern (dial string containing up to 32 digits and ending with the letter T).
c. Set the address resolution authority (ARA) type to GKGrp, OSPServer, or ipv4.
a. Use the same destination pattern as ingress route created in Step 2.
b. Set the dial peer type to POTS.
Use this procedure to configure an egress route for prefix routing. If your CSR route type is set for trunk-label or carrier, see Configuring an Egress Route for CSR.
The managed zone for this route must already exist and you have already defined the route scope for this route.
To configure an egress route for prefix routing, perform these tasks in the following order:
1. Add an egress route to the zone.
2. Specify a VRC feature set (must be dp1.0 for prefix routing).
3. Set a destination pattern for the route.
4. Define an ANI (answer address) and a DNIS (incoming called-number) for the route. An inbound VoIP dial peer is only created if one of these two values is set.
5. Specify a translation profile (optional).
6. Specify a route scope. Choose from the route scope or the managed zone. If you choose route scope, the feature sets must match.
7. Specify a call block (optional).
8. Select a technology prefix (optional).
9. Specify a voice class codec (optional).
10. Set the hunt-stop behavior (optional).
11. Define the necessary route parameters for the route (optional).
Use this procedure to configure an egress route to support carrier sensitive routing (CSR). If the CSR route type for the AD is set to None, see Configuring an Ingress Route for Prefix Routing.
The following conditions must exist before you can configure an egress route to support CSR.
To configure an egress route for CSR, perform these tasks in the following order:
1. Specify a feature set of dp1.1 or later.
2. Associate a source carrier ID from the available list. Use this to define an inbound VoIP dial peer.
3. Associate a target carrier ID from the available list. Use this to define an outbound POTS dial peer.
4. Associate an incoming-side translation profile from the enclosing zone.
5. Associate an outgoing-side translation profile from the enclosing zone.
6. Define a destination pattern for the route (optional).
7. Associate a route scope that supports trunk groups or hunt groups to the route. The hunt group type must be trunk group.
8. Set other egress route attributes and parameters.
Use this procedure to configure an ingress route for prefix routing. If your CSR route type is set for trunk-label or CSR, see Configuring an Ingress Trunk Route for CSR.
The managed zone for this route must already exists and you have already defined the route scope for this route.
To configure an ingress route for prefix routing, perform these tasks in the following order:
1. Add an ingress route to the zone.
2. Specify a VRC feature set (must be dp1.0 for prefix routing).
3. Set a destination pattern for the route.
4. Define an ANI (answer address) and a DNIS (incoming called-number) for the route (optional).
5. Specify a translation profile (optional).
6. Specify a route scope. Choose from the route scope or the managed zone. If you choose route scope, the feature sets must match.
8. Select a technology prefix (optional).
9. Specify a voice class codec (optional).
10. Set the hunt-stop behavior (optional).
11. Define the necessary route parameters for the route (optional).
12. Set the address resolution authority (ARA) type for the route. Choose from GKGrp, OSP Server, Hairpin, or ipv4.
Use this procedure to configure an ingress route to support carrier sensitive routing (CSR). If your CSR routing type is set to None, see Configuring an Ingress Route for Prefix Routing.
The following conditions must exist before you can configure an ingress route to support CSR:
To configure an ingress route to support CSR, perform these tasks in the following order:
1. Specify a feature set of dp1.1 or later.
2. Associate a source carrier ID from the available list. This is used to define an inbound plain old telephone service (POTS) dial peer.
3. Associate an incoming-side call block translation profile from the enclosing zone. This is used to define the call block in an inbound POTS dial peer.
4. Associate an outgoing-side translation profile from the enclosing zone.
5. Define a destination pattern for the route.
6. Define a call block disconnect cause. If there is a call blocking profile, then there can also be a disconnect cause.
7. Associate a route scope that supports trunk groups or hunt groups to the route. The hunt group type must be set to trunk group.
8. Set other ingress route attributes and parameters.
You can set up incoming call blocking based on the call number after the two-stage dialing or overlap dialing finishes. Use a reject rule in the translation rule and apply these rules for calling number, called number, or redirect called number of an incoming call. You can set up call blocking for both ingress and egress routes.
To configure a voice source group for call blocking based on an IP access list, see Adding a Voice Source Group.
To set up call blocking attributes for a route, perform these tasks in the following order:
1. Modify an existing egress or ingress route or create a new route.
2. Set up a call blocking profile for the route.
3. Assign the translation profile with reject rules to the route.
4. Add the disconnect cause to the call blocking profile.
Posted: Fri May 9 17:23:02 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.