Section 4.7. Dial-Plan and PBX Design

4.7. Dial-Plan and PBX Design

The dial-plan is a set of rules that governs the call-routing behavior of a PBX. When a business user picks up his telephone and dials a number, the PBX refers to the rules in the dial-plan in order to determine how best to connect that call. While dial-plans have no standardized syntax or established set of best practices, they are always expected to describe:

How phones are uniquely identified on the networkusually through extension numbers
How to connect calls based on the caller's DTMF digitsi.e., which channels to open to route the call
How to connect or restrict calls based on their origin
What effects the origin of a call has on its priority
How to group phones together for common applications, such as group ring or hunt groups

Dial-plans needn't be confined to a single PBX within an enterprise. A large network can have dozens of PBXs that are all subject to a common dial-plan. Dial-plans aren't exclusive to legacy telephony equipment either. SoftPBX systems support and require a dial-plan, too.

The specifics of configuring a dial-plan vary from platform to platform and from PBX to PBX. One legacy AT&T switch may have a very different configuration approach from an old Panasonic switch. This inconsistency continues among Voice over IP call-switching systems, too. In this book, we've concentrated mainly on Asterisk up until this point. But it's important to know that even though the principle of dial-plan design and capabilities are more or less universal, the platform-specific implementations of dial-plan can be vastly different in structure.

In Project 4.2, we built a very simple dial-plan that assigned extension numbers to two IP phones, allowed them to dial out using a POTS trunk, and put them together as a ring group for all incoming calls. This dial-plan was intended to emulate a conventional key systema simple and relatively easy thing to do on any VoIP call-routing device whose interfaces include Ethernet and FXO. An enterprise-class Avaya MultiVantage server or a simple Cisco media gateway could behave like a simple key system, but that's not how most are set up.

With a traditional PBX, phones are called extensions , connections to the phone company are called dial-tone trunks , and connections to other private PBXs are called private trunks . Usually this terminology is applied the same way in a VoIP network. Many of the same considerations have to be made when creating a dial-plan:

How many phones will there be in the network? Does the extension number allow for enough digits for all of them?
Will phone users dial a special digit (8 or 9) at the beginning of PSTN-bound calls, or will the phone system just figure out how to route their calls?
Will calling between private switches be possible?
Will extension numbers be based on a mitigating or symbolic conventionsuch as the organizational location of the phonei.e., which office location it's at, or a desire to match a particular user's DID phone number? (See the section "DID" earlier in this chapter.)
Will each user's voice mail box number match her extension number?
Will calls routed from a particular user to the PSTN always travel the same trunk, or will the trunks be selected randomly when calls are placed?

Some of these mundane questions can have a big social and economic impact. Using a long extension number (five or six digits) could be unpopular with users but necessary because of the size or growth potential of the voice network. Routing outbound calls to the PSTN on a user-per-line basis, in combination with caller ID, can make it easier for people to get hold of the right person when they return missed calls, but at the cost of complexity.

In circuit-switched telephony, these issues have much greater economic significance than with VoIP. As each dedicated legacy interface is replaced with an extensible, flexible protocol running over a converged network, the cost of hardware maintenance drops . Maintaining individual trunk ports, individual extension cards, and individual phone lines decreases. But in the meantime, a legacy or hybrid/IP-enabled environment's dial-plan must reflect cost-effectively on the physical interfacing available to it. Stated another wayit's especially important not to waste capacity in an analog/TDM environment, where capacity is more expensive.

That means if a particular user is on the phone constantly making outbound callssay a collections personit might make sense to assign a trunk to that user specifically . But you wouldn't want to give a dedicated trunk to the guest phone in the reception area, because it's more economical for this phone to share trunks with other phones.

4.7.1. Extension Numbering

A number of strategies can be used to assign extension numbers.

4.7.1.1 Extensions based on DID

In organizations using DID, extension numbers often match the DID number given to each phone user. That is, if a user's DID phone number is 335-1464, then his extension would be 1464. This approach is popular in organizations that use DID for every user.

4.7.1.2 Extensions based on geography

In organizations that have a geographically diverse network of office locations and PBX switches, giving figures of the extension number a geographical significance can be helpful. For example, in a four-digit extension, one could say that the first two digits represent the office location. Here's a scheme based on this idea:

Extensions 1100-1199: Detroit Sales Office
Extensions 1200-1299: Southfield Sales Office
Extensions 2000-2999: Kalamazoo Customer Service Call Center

In this scheme, 100 extension numbers are available in Detroit and Southfield, while the Kalamazoo office has 1000 available extension numbers. It's up to the dial-plan to enforce proper call routing with regard to this scheme.

4.7.1.3 Extensions based on department

Like the geographic approach, this type of scheme takes groups of extension numbers and assigns them to an organizational unitnot a location, but a department:

Extensions 1000-1199: Marketing
Extensions 1200-1299: Accounting
Extensions 1300-1599: Engineering
Extensions 1600-1649: Information Technology

It's possible to combine geographic and departmental schemes, dividing up the extension numbers in an even more detailed manner.

There's no right or wrong way to establish a call-routing scheme unless its complexity or economy make it unmanageablethen it's wrong, of course. Remember, whatever scheme you, as a voice system designer, cook up, you must also implement and support it. Simplicity is always elegant.

4.7.1.4 Extensions based on type of device

In a PBX, you'll sometimes address trunks and outboard devices like voice mail servers using extension numbers, too. This is because some PBX systems require you to do so. You might pick a block of extension numbers that are very unlike those used to call real human- answered extensions, to prevent accidental dialing by a user. Some PBX systems can restrict users from calling an extension used to signify a trunk or voice mail port, but most don't. Fortunately, VoIP is not as geared around extension numbers as legacy PBX systems are.

4.7.1.5 Extensions "just because"

Some users may request a particular extension because it's the extension number they had on their former employer's system or because it's easy to remember. Other extension numbers may be baggage from generations of phone system upgrades. There may even be a hodgepodge of geography or legacy issues and special number requests cluttering your dial-plan today, before you've even had a chance to add VoIP to the dial-plan mix. Fortunately, VoIP networks can be eminently more programmable than the old PBX system.

4.7.2. Dial-Tone Trunks

Dial-tone trunks are the PSTN pathways of a PBX. Outbound or PSTN-bound traffic flows to the dial-tone trunks, and inward traffic flows across them to the PBX. Traditional dial-tone trunks can be POTS, Centrex, BRI channels, or PRI DS0 channels.

Chapter 12 discusses the impact of voice applications on the selection of PSTN trunk technologies and sizing.

It could make sense to have a very large dial-tone trunk group to make sure the rest of the world never gets a busy signal when calling in to your phone system. But the cost of phone linesor T1 circuitsadds up quickly. There's an easy way to figure an adequate number of dial-tone trunks for your PBX, whether it's a conventional TDM system or a softPBX. Use the Erlang traffic-engineering method, described here, to balance the cost of trunks against your system's capacity requirements.

An Erlang is a unit of voice traffic. Each Erlang is equal to the average number of calls to a system in an hour times the average duration of the calls in seconds, divided by the number of seconds in an hour3,600. The Erlang formula, therefore, is e=cs/3600. For a system with 120 calls per hour at 250 seconds apiece, the formula is applied like this:

 (120 cph x 250 seconds ) / 3,600 = 8.3 Erlangs

You can use this formula to calculate the Erlang rating of your phone system. Remember, the Erlang is a unit of voice traffic, not a unit of physical capacity. You'll need to use something called the Erlang B table in order to correlate your system's Erlang rating with a physical capacity numbera trunk count. So, in a nutshell , figure out the Erlang rating and look it up in Table 4-1 to figure out how many trunks your system requires.

Table 4-1. Erlang B table

Trunks required	Blocking 1%, Erlangs	Blocking 5%, Erlangs
1	.01	.05
2	.15	.4
3	.5	.9
4	.9	1.5
5	1.4	2.2
6	1.9	3.0
7	2.5	3.7
8	3	4.5
9	3.8	5.4
10	4.5	6.2
11	5.2	7.1
12	5.9	8.0
13	6.6	8.8
14	7.4	9.7
15	8.1	10.6
16	8.9	11.5
17	9.7	12.5
18	10.4	13.4
19	11.2	14.3
20	12	15.3
21	12.8	16.2
22	13.7	17.1
23	14.5	18.1
24	15.3	19

By looking up the number of Erlangs in the Erlang B table, you can tell how many trunks are required to satisfy several levels of probability for blocking due to busy state.

So for a system with an Erlang rating of 8.3, 15 or 16 dial-tone trunks is enough to support a 1% probability of blocking, while the same system would need only 12 or 13 trunks to support a 5% probability of blocking.

The blocking formula can be used to size private trunk groups, too, but tolerance for blocking on private trunks may be higher. Because blocking of private trunks can often be overcome using the PSTN as a go-between when the private trunks are blocked, a higher probability percentage can be applied to save money. Ultimately, the size of each trunk group depends on how tolerant your telephony applications, and users, are of busy signals.

Think about your use of the telephone at home. Now, let's apply the Erlang formula. Figuring on two calls per hour with an average length of 120 seconds, we get .06 Erlangs:

 ( 2 cph x 120 seconds ) / 3,600 = .06 Erlangs

By finding that Erlang rating in the Erlang B table, you can see that this fictitious residential telephone setup will have about a 5% probability of blocking with one POTS line. So, 1 out of every 20 calls will be blocked with a busy signal.