If you have just started looking at the configuration of a SIP proxy or soft PBX, you have probably observed that the scripting languages provide almost infinite flexibility to route the calls in different ways. If you have been working with such configurations for a while, you may have seen some that have become tremendously convoluted.
Figure 2.3, “Four stages of call routing” demonstrates a high-level approach to routing calls within your site, whether you are using a single SIP proxy or soft PBX or a combination of different components.
There are four general stages.
All calls, whether they come from SIP trunking providers, ISDN or local users should start in an ingress stage. The goal of the ingress stage is simply normalizing the numbers into a standard form that will be useful in all further stages of call processing. For example, if calls are coming in over an ISDN connection the provider may only be sending the last six digits of each destination DDI that has been dialed. The ingress stage handling calls from this ISDN circuit adds the country code and other leading digits to normalize the numbers in the E.164 format (see Chapter 18, PSTN connectivity for more specific details about this type of ingress handling).
When calls are sent to their final destination, whether it is a SIP trunking provider, ISDN circuit or a local user, the final stage it should go through is an egress stage. The format of the number/address usually needs to be modified again in the egress stage. For example, some providers expect E.164 numbers to have a 00 prefix, as this is the dialing prefix many countries use to call international numbers.
Many deployments involve some services where calls are handled by an application. This is the application stage. These applications are typically voicemail services, call queues and DTMF-driven menus.
Finally, all these stages are joined together by a routing stage. The routing stage accepts calls from the ingress stage, considers both the source of the call and the desired destination (both of which have been normalized already) and decides where to send them in the egress and application stages.
All these stages can be implemented in a single system such
as an Asterisk PBX. For ease of administration, it is advisable
to break the extensions.conf file up into
different files for each stage as demonstrated in
Example 2.1, “Splitting Asterisk extensions.conf”.
The more powerful approach is to transpose this paradigm over several individual processes and devices. For example, the ingress stage for calls from local users may be implemented in the SIP proxy and the ingress stage for calls from an ISDN circuit may be implemented using the configuration file in a media gateway.
Example 2.1. Splitting Asterisk extensions.conf
#include "/etc/asterisk/extensions/ingress/local_users.conf" #include "/etc/asterisk/extensions/ingress/trunks.conf" #include "/etc/asterisk/extensions/routing.conf" #include "/etc/asterisk/extensions/applications.conf" #include "/etc/asterisk/extensions/egress/local_users.conf" #include "/etc/asterisk/extensions/egress/trunks.conf"