4.2. Dialplans

The previous sections already addressed issues regarding the dialplan that is used. There is no ideal solution to address all different needs but just a number of techniques to solve specific. This section addresses the most common problems faced when dealing with dialplans.

  1. IP telephony numberblocks

    The general situation is that there is an already existing PBX dialplan and IP telephony shall be integrated into this dialplan. If the existing dialplan has a free number block then the first approach would be to give IP telephony the whole block. This makes the configuration very simple because it allows prefix based routing (see Section 4.1.1.1.1). The problem is that either only new telephone users get an IP telephone or that every user who wants to use IP telephony gets a new phone number. So this approach is not suitable for a seamless migration towards IP telephony

  2. IP telephony service prefix

    Another solution is to define a prefix that has to be dialed to reach an IP telephone. As mentioned before prefix routing is the easiest option to configure. An IP telephony prefix would also allow a user changing from a legacy phone to an IP telephony phone to keep his number modified in a way that is easy to remember (e.g. if the internal number was 2972 and the prefix for VoIP is 99 than the new number is 992972 - which applies for all numbers).

    On the other hand there must be a way to decide of a call that originates on the IP side has an IP telephony target or a phone on the PBX. This can again be realized with a service prefix for legacy phones or by making the PBX the default route for targets that are not registered at the same server. This must be carefully considered to avoid that a call from an IP phone to another IP phone target that is not currently registered is routed back and forth between IP telephony server and PBX.

    The problem with this solution is that you have to know if the person you want to call has an IP phone or not and this constitutes a number change which still requires all business cards to be reprinted.

    To avoid this number change to be "visible" the PBX might set up a mapping table that maps outdated old addresses to the new addresses. So the PBX maps the dialed 2972 to 992972 and routes the call to the IP world.

  3. Per number routing

    The cleanest way to handle call routing is to perform routing decisions on the individual number (see Section 4.1.1.1.2). The fact that a number belongs to an IP phone or PBX phone is fully transparent to the user and no error-prone default routes are required. It is also the solution that has the highest configuration and administration effort because there are most probably at least two databases that must be kept consistent.

  4. The call routing problem gets worse as soon as multiple call signaling protocols are deployed in the IP world and no single server supporting all of them at once (see Figure 4.5). Every IP telephony server must be aware that a number that belongs to another server must be routed to the gateway, or otherwise the gateway must be the default route for unknown targets. In any case, calls for unknown targets land on a gateway. Now the gateway needs to decide where to route a call. Because it is desirable that gateways are dumb (to prevent having yet another place to configure routing details) the gateway will hand the call to the PBX which makes the final routing decision - which eventually means to hand the call to another gateway (or back to the originating if there is only one multi-protocol gateway).

All problems and solutions mentioned above are highly dependent on specific products and the features they support, so unfortunately there can be no general advice on how to implement dialplan migration.