IP Voice/Video Dial Plan

The IPVTF set out to create a dial plan that would be familiar to users, easy to learn, and feasible to implement on the H.323 network using currently available hardware.

PRIMARY QUESTIONS

• Why do I need a “Dial Plan”?
• What is E.164 Addressing?
• What is an H.323 alias?
• Should Direct Inward Dial (DID) assignments be used for all H.323 endpoints to allow access from H.320 endpoints, using a unique North American Numbering Plan (NANP) assignment?
• Should E.164 compatible numbers be used for the H.323 endpoints, or should domain/alias addressing be used instead?
• What are the implications of these choices for cross technology dialing?
• What are the implications for IP voice telephony?
• Should existing telephone area codes be used or does ITN choose unique prefixes?
• What is the best method to interface with special equipment such as gateways and multipoint conference units (MCUs)?

ANSWERS

Why do I need a “Dial Plan”? A dial plan allows for a standardized format in assigning an identity to an end-user. A dial plan defines the style of the unique identity as well as how to implement it. A direct comparison can be made to the way we dial a telephone today. The telephone company assigns each end-user a unique number. Without that unique number, an end-user could decide to have a new phone number every day or decide to dial a number that does not belong to the end-user that is being called, thus making it very difficult for one person to reach another.

What is E.164 Addressing? E.164 Addressing, an ITU-T standard, is the international public telecommunication numbering plan. This standard allows the ITN to use numbers such as a desk phone for a video conferencing endpoint. With this type of addressing, a number string made up of 0 through 9 can be 15 numbers long. This provides the ability to make each end point unique.

What is an H.323 alias? An alias is another way to describe who an end-user is. This alias can be made from alphanumeric characters, numbers, or both. Some examples of an H.323 alias are: 157913132; Pcom; brickhouse; State Library 2.

Should Direct Inward Dial (DID) assignments be used for all H.323 endpoints to allow access from H.320 endpoints, using a unique North American Numbering Plan (NANP) assignment? After evaluating the current rate of off-network inbound and outbound activity, the Task Force determined that some H.323 endpoints would require or desire a NANP assignment for their terminal. IP voice telephony considerations might make that even more necessary since much of the voice traffic would be off network. However, the expense of NANP assignments for all units and all area code groups may be cost-prohibitive. While DID support is important, due to cost constraints, not all H.323 endpoints may be able to have a NANP number association.

Should E.164 compatible numbers be used for the H.323 endpoints, or should domain/alias addressing be used instead? Based on research of other entities with dial plans, the Task Force first considered support for both domain/alias routing and E.164 number assignments. Due to cross-technology considerations as well as off-network calling, the group eventually decided that E.164 should be the only supported method of dialing.

What are the implications of these choices for cross technology dialing? There would be no support for off-network dialing or call reception if domain/alias were the only dialing format supported. Current ATM terminals would need to be abandoned immediately, instead of allowing a technology transition period. Off-network inbound and outbound calling would be nonexistent or extremely cumbersome.

What are the implications for IP telephony? If ITN uses only a domain/alias dialing scheme, there would be no support for the current IP telephones.

Should existing area codes be used or does ITN choose unique prefixes? Most members of the task force felt that using existing area codes would provide a feeling of familiarity to the technology, since most users have been using the area codes all of their lives. This is also required for DID compatibility for endpoints assigned a NANP number.

What is the best method to interface with special equipment such as gateways and multipoint conference units (MCUs)? Some sort of technology prefix, included in the dial string, is needed to indicate that the call should be routed off network or to an MCU.

Design Goals

• The dial plan should be compatible with legacy H.320 ISDN and H.321 ATM video conferencing endpoints.
• The plan should support E.164 numbers to allow H.323 endpoints to appear as PSTN terminals using DID with NANP allocations.
• The plan should accommodate gateway TCS4 signaling to route calls to endpoints not assigned a DID number.
• The plan should allow support for older style H.320 codecs that do not support TCS4 signaling.
• The dial plan should allow zone administrators to choose their own dialing extensions for endpoints not associated with a DID number.
• The dial plan should keep an eye toward the future convergence of packet based and PSTN technologies.
• The dial plan should support user mobility. Users should be able to relocate their terminal anywhere in the state and not be required to change the numbers used to dial into their codecs.

Recommendations: The IPVTF recommends that:

• The dial plan take the form of: E[*T]ZZZNNNNNNN; where E = Exit zone;
• *T = Technology prefix; Z = Area code; and N = 7 digit dialing extension number
• The dial plan support ISDN codecs that have specific circuit restrictions through the use of Technology prefixes
• A PRI be purchased to support “ISDN off net” to “IP on net” Point-to-Point calls
• An ISDN to IP gateway be purchased to support “ISDN off net” to “IP on net” Point-to-Point calls

The Dial Plan

Determining the gatekeeper topology allowed development of a dial plan.

Based on answers to the primary questions discussed earlier, the IPVTF decided to fully support DID. Due to the cost of NANP assignments, both direct expense and administrative costs, it would be impractical to provide NANP assignment for every H.323 endpoint on the network. A limited number of H.323 endpoints will be able to obtain a NANP assignment; other sites will be supported using TCS4 and other methods of call routing from an inbound ISDN call. Compatibility with existing ATM platforms, as well as support for out-of-network dialing to and from legacy H.320 ISDN based systems, is still required.

One of the options seriously considered by the IPVTF was the concept of domain/alias dialing, similar to the e-mail system currently in use by millions. An example of this kind of dialing would be user 1 dialing user 2, who is connected to the Lafayette network node by dialing: user2@lafayette.ihets.org or possibly: user2.Lafayette.ihets.org.

One can see the simplicity of this scheme. Unfortunately, to ensure compatibility with all gatekeepers, ATM endpoints, off-network H.320 terminals, and IP phones, an alphanumeric dialing scheme is simply not feasible. Even ViDeNet, one of the largest H.323 gatekeeper networks, is expected to change its position regarding endorsement of domain/alias dialing. The IPVTF also considered a dual method using both domain/alias and E.164. Again, the feasibility of this task given the current state of gatekeepers would prohibit this type of system from being implemented easily.

Structure

The structure of the dial string will be based upon the NANP system, although number assignments will be internal to the network. Exceptions would be cases where endpoints wish a true NANP assignment for DID support. The structure of the dial string will be as follows:

E[*T]ZZZNNNNNNN

Where:

E=Exit Zone Prefix. This will typically be a “1” as defined by the dial plan. “1” was chosen because it reminds users that they are making a long distance call. This will preclude users from using local E.164 extensions beginning with “1” due to the method gatekeepers use to parse the string. The gatekeeper would match the “1” and immediately assume it is an out of zone call.

T=Technology Prefix. This will be an optional prefix not required in the dial string. It is a prefix that can only be used by H.323 endpoints. It will be used to force call routing to take a particular path, such as calling out via ISDN to an off-network endpoint. Sometimes, this code is known as a service prefix. Since this is an optional prefix, we have proposed the use of “*” as a delimiter in the string. The delimiter will ensure that the technology prefix does not get confused with a digit in an area code.

Here is the proposed list of technology prefixes:

*9 – This will be the designation for a single channel off-network voice-only call. “9” was chosen because it is a typical code to get an outside line, especially in Centrex style systems.*6 – This will be the designation for a 6-B channel off-network video call consisting of 6 64KB ISDN B channels aggregated to 384K using the Bonding Mode 1 Protocol.

*2 – This will be the designation for a 2-B channel off-network video call consisting of 2 64KB ISDN B channels aggregated to 128K using the Bonding Mode 1 Protocol.

*3 – This will be the designation for a 2-B channel off-network video call consisting of 2 64KB ISDN B channels, dialed separately, and restricted to 56K data rates.

ZZZ=area code. This is the area code the user endpoints are assigned. It will also assist the gatekeepers in routing the call to the correct endpoint and allow seven-digit extension reuse among area codes in the future.

NNNNNNN=the seven digit dialing extension for the end point. All endpoint extensions will be seven digits. The seven-digit extension should be the only dialing string necessary for dialing within a gatekeeper zone.

Dialing Examples

Given an H.323 terminal registered to a gatekeeper located in the 765 area code, with a dialing extension of 4961234, here are some examples describing how to dial into that terminal. Examples 1-4 ONLY apply to inward dialing from an ISDN type endpoint trying to connect to an H.323 endpoint. Examples 5-7 demonstrate point-to-point calls from H.323 endpoints on the network. Example 8 demonstrates how an ATM endpoint on the network would dial an H.323 endpoint.

1. H.320 unit to an H.323 endpoint using DID where the H.323 endpoint has a NANP assignment:

317 496 1234

Notice that the area code for this unit is 317 instead of 765. Due to cost constraints involved in having NANP numbers outside the 317 area code to appear at the ITN Gateway, all codecs wishing to have DID support using a NANP assignment will be required to register with the 317 area code gatekeepers. However, the unit may still be physically located outside the 317 area code. An H.323 endpoint cannot be assigned more than one area code; therefore this unit will only be dialed using a 317 area code, no matter whether the call is on- or off-network.

2. H.320 unit to an H.323 endpoint with no DID assignment from a newer TCS4 capable codec.

317 555 1234 ## 765 496 1234

Where 317 555 1234 is the access number and ## is the delimiter used by the codec. (This delimiter may vary from codec to codec.)

3. H.320 unit to an H.323 endpoint with no DID assignment from a non-TCS4 capable codec:

317 555 1234 (Access Number)

Wait for the voice response, then enter the extension number (765 496 1234) using a DTMF keypad

4. H.320 unit to an H.323 endpoint with no DID assignment from a non-TCS4 and non-DTMF capable codec:

317 555 1234 (Access Number)

After voice response gets no DTMF tones, the call is routed to an available MCU. The receiving party will also be required to make a connection to the MCU, meaning this will be a prearranged meeting.

5. H.323 to H.323 registered with the same gatekeeper:

496 1234

6. H.323 to H.323 in same area code but not same gatekeeper:

1 765 496 1234

7. H.323 to H.323 across area codes:

1 765 496 1234

8. ATM endpoint to H.323 Terminal:

765 496 1234

Technology Prefix Examples

The following examples demonstrate how to use technology prefixes to make off-network calls.

1. To make a 384K Video Call to an ISDN H.320 endpoint with a dialup number of 812 883 1234 from a H.323 endpoint on the network:

1*6 812 883 1234

2. To make a dual channel 56K call from an H.323 endpoint to an endpoint where both B channels of the ISDN line have the same dialup number:

1*3 812 883 1234

3. To make a dual channel 56K call to an endpoint where B channels of the ISDN line have different dial up numbers. NOTE: The comma is a delimiter set up in the gateway. The comma was chosen since it can only be dialed by newer IP based codecs such as Polycom, VCON, and Zydacron.

1*3 812 883 1234, 812 883 1235

4. To make a voice only call to someone’s desk telephone from an H.323 endpoint:

1*9 317 263 8888

Dial Plan Key Points

• All H.323 endpoints will be registered with an ITN gatekeeper or their institutions gatekeeper using RAS. The institutions gatekeeper will be neighbored with the ITN Main Directory Gatekeeper.
• H.323 endpoints will be assigned an E.164 compatible number to use as their H.323 dialing extension.
• Some H.323 terminals may be given NANP assignments to allow direct inward dialing from the PSTN.
• H.323 terminals will be assigned an area code based on their geographic location. These area codes will be the same as their current geographic area code. The exception to this will be devices with a NANP assignment, as these assignments will all have a 317 area code.
• System administrators operating their own gatekeepers will be allowed to assign their own extension numbers as long as they follow the ITN dial plan and coordinate the numbers with ITN to avoid duplications across the network.
• The dial plan will support technology prefixes but will not require them. Technology prefixes will be used to force call routing in case of network congestion or malfunction.
• Inbound calls from the PSTN will first be routed by DID. If no match, then TCS4 will be used. If no match, the caller is sent to an interactive voice response (IVR) and prompted to enter the extension they wish to connect to. If the IVR gets no response, the call will be routed to an MCU where the receiving party may be waiting or can join later.

Because TCS4 is still a relatively new standard, and not all H.320 endpoints would be capable of dialing an extension using IVR, it is the recommendation of the IPVTF that all inbound ISDN calls to endpoints not associated with a DID number should be scheduled in advance. This will provide the opportunity to certify and test H.320 endpoints with the gateway before the actual conference occurs.