Design Methodology for Large-Scale Dial Plans 173
latter case, the gatekeeper would forward the location request (LRQ) to the remote
gatekeeper either directly or through a directory gatekeeper. The remote gatekeeper would
ultimately respond with the address of the terminating endpoint.
The communication between gateways and gatekeepers is based on standard H.323v2
registration, admission, and status (RAS) messages. Gateways query gatekeepers for routes
using RAS admission request (ARQ) and admission conﬁrmation (ACF) messages. Cisco
gatekeepers and directory gatekeepers also communicate with each other using RAS
location request (LRQ) and location conﬁrmation (LCF) messages. Real-Time Transport
Protocol (RTP) provides the end-to-end transport functions. Figure 5-2 shows an example
of RAS messages sent between gateways and gatekeepers.
Figure 5-2 Example of RAS messaging when Phone A calls Phone B.
Design Methodology for Large-Scale Dial Plans
It’s important to apply some basic design principles when designing a large-scale dial plan.
Design options in this chapter will consider the following principles:
• Dial plan distribution
• Hierarchical design
• Simplicity in provisioning
• Reduction in post-dial delay
• Availability, fault tolerance, and redundancy
ARQ ACF ARQ ACF
Phone A Phone B
H.225 Fast start setup
H.225 Fast start alerting / connect
174 Chapter 5: Designing Static Dial Plans for Large VoIP Networks
Dial Plan Distribution
Good dial plan architecture relies on effectively distributing the dial plan logic among the
gateway and gatekeeper components. Isolating H.323 devices to a speciﬁc portion of the
dial plan reduces the complexity of the conﬁguration. Each component can focus on
accomplishing speciﬁc tasks. Generally, local POP-speciﬁc details are handled at the local
gateway; higher-level routing decisions are passed along to the gatekeepers and directory
gatekeepers. A well-designed network places the majority of the dial plan logic at the
gatekeeper and directory gatekeeper devices.
Strive to keep the majority of the dial plan logic (routing decision-making and failover) at
the highest component level. The directory gatekeeper is generally considered the highest
device. By maintaining a hierarchical design, the addition and deletion of zones becomes
more manageable. For example, scaling of the overall network is much easier when
conﬁguration changes need to be made to a single directory gatekeeper and a single zone
gatekeeper instead of all the zone gatekeepers.
Simplicity in Provisioning
You should keep the dial plan on the gateways and gatekeepers as simple and symmetrical
as possible. On the gateways, try to keep consistent dial plans by using translation rules to
manipulate the local digit dialing patterns. These number patterns can be normalized into a
standard format or pattern before the digits enter the VoIP core. Putting digits into a
standard format simpliﬁes gatekeeper zone preﬁx provisioning and gateway dial-peer
This methodology helps reduce dial-peer conﬁgurations on the outgoing POTS interface. If
the gatekeeper can be provisioned to direct only calls of a certain area code to a particular
gateway, then it is unnecessary to provision all of the individual gateways with their
respective area codes. Instead, you might be able to generalize the gateway conﬁgurations.
By normalizing the number, you also reduce the zone preﬁx search length, reducing the
time it takes to search for a zone preﬁx match. For example, if you have the 0118943xxxx
digit pattern, you can send the number as 8943xxxx and have the gatekeeper search on 89
as opposed to 01189.
Reduction in Post-Dial Delay
You should consider the effects of post-dial delay in the network. Gateway and gatekeeper
zone design, translation rules, and sequential LRQs all affect post-dial delay. Strive to use
these tools most efﬁciently to reduce post-dial delay.