Localization and Practical Security in Asterisk 1.4: Part 2

Local telephony interfaces

Having set the tones, announcements, and language so that your users feel at home, the next task is to physically connect our Asterisk to the outside (telephony) world.

Fortunately, the RJ-45 is ubiquitous as far as Ethernet connectivity is concerned, so attention can be focused on traditional telephony connections.


It is a fairly safe bet that whatever equipment you choose to connect your analog lines and phones to Asterisk, whether you have gone with an ATA or a Digium card, the termination will be with an RJ-11 socket (with the middle two pins used for the pair).

This means that the lead that plugs into that RJ-11 socket becomes a mission-critical accessory, which, in a number of cases, is not shipped with your equipment.

You need to be absolutely sure that the lead you use has the right pin to pin connections as well as the right connectors at each end.

This may seem like stating the obvious, but it is included as a result of a Digium support case where a customer in the UK reported that the analog card they were using was faulty. The case got to the stage where the support team remotely accessed the machine in the UK and established that there appeared to be an unexpected voltage on one of the legs of the telephone line. When someone questioned the patch lead connecting the card to the PSTN, only then was it established that the customer had just picked up a lead that had the right ends and plugged it in, without worrying about whether the electrical connections were right. It turned out that the lead was probably for some old modem and it cross-connected some of the pins.

Of course, physical connectivity is essential, so is ensuring that the pinouts are correct. In the left part of the following picture, we can see the type of lead in question. It has an RJ-11 at one end, and a BT (British Telecom, the main telco in the UK) plug at the other. To the right is a picture of the two ends of the lead that would be required to connect to an analog telephone line in Korea. This has been included to give an idea about the diversity of connectors that are used around the world.


From a regulatory standpoint, it should be pointed out that only analog telephony cards and ATAs with the appropriate approvals should be connected to the telephone network in a given country.

The main learning point here is to ensure that you consider physical connectivity as part of your localization planning.


Digital telephony interfaces will be in two groups—basic rate access (otherwise known as BRI or ISDN2), and primary rate access (otherwise known as PRI, E1, T1, or ISDN, and sometimes ISDN30 in countries where 30 voice channels are used).

BRI is almost universally connected using an RJ-45 patch lead, which will look like a standard Ethernet patch, but if more closely inspected, it becomes apparent that only four wires are connected.

PRI connectivity started being implemented using two BNC connectors (one for transmit and one for receive), but is more commonly connected using RJ-45s these days.

Note that a PRI patch lead with RJ-45s at each end will be different from a BRI patch cable, which as mentioned, is different from an Ethernet patch. So, label your cables!

In countries such as the UK, you would not expect to find signaling systems with telco presentation on co-axial connections, but many countries (for example, those found in South America) still utilize R2 signaling, which may well be presented using co-ax.

Most PRI apparatus (including telephony cards) will use RJ-45 sockets these days. Therefore, it may be possible that in some countries you are presented with a situation where the telco is giving you two BNC connectors, but your equipment wants an RJ-45 plug. This is simply remedied by using a balun (so named because it is connecting a balanced interface, the RJ-45 end, to an unbalanced interface, the BNC end). Here is a picture:


When I say "simply remedied", that is as long as you have thought of it in advance, and ordered these inexpensive, yet very useful adapters. If you have not thought of it prior to implementation and find yourself in need of a balun, be prepared to wait to get them shipped. These are not items you will find at the corner store.

Localizing caller ID signaling on Digium analog interfaces

Given the work we have already identified how to localize your Asterisk telephony solution in the previous article, it will not come as a complete surprise to learn that the method used to send caller ID information over analog lines varies from country to country.

Fortunately, Asterisk is capable of recognizing many different types of caller ID signaling. This should not be a problem as long as you remember to set up the correct type for the country where the system will be connected.

All caller ID settings are made in chan_dahdi.conf (formerly zapata.conf), which is found in the /etc/asterisk/ directory.

When you look into this file, the only lines you see concerning caller ID are:


Asterisk will be using its default type of caller ID signaling, which is North American. You may not even see these lines, as this is the default position.

In order to change things, you will need to add some extra lines to the file. The number of lines you add will depend on the type of signaling you want to work with, and whether you are connecting to analog phones, or lines, or both.

Shown next, is the kind of entry you would expect to see for a connection to an analog telephone line, with the entries that change the caller ID signaling highlighted:

cidsignalling=v23 ;BT CallerID presentation signalling method
cidstart=polarity ;Indication of CallerID data starting
channel => 4

The two highlighted lines are equipping Asterisk to recognize the caller ID as it is sent in the UK over BT (British Telecom) analog lines. The callerid=asreceived line is not part of the change and serves to propagate the caller ID information through Asterisk. Therefore, it will show up on connected extensions when they are called.

What we saw just now covers the case where we want to interpret incoming caller ID data. However, we also need to look at the sending of caller ID to any analog phone that we have connected to our Asterisk. If the analog phones are connected using ATAs, it is those devices that will handle the caller ID. If the phones are connected to a Digium card, then we are back in chan_dahdi.conf.

callerid="David Duffett" <5001>
cidsignalling=v23 ;BT CallerID presentation signalling method
cidstart=polarity ;Indication of CallerID data starting
sendcalleridafter=2;The number of rings before sending data
channel => 1

In the code that we saw just now, the third highlighted line is particular to only a few caller ID signaling systems, and instructs Asterisk to send the caller ID data after (in this case) two rings. This is for systems where the data is sent between rings. It is the kind of system used in the UK.

A final note on caller ID:Do make sure that your customer actually has caller ID enabled on their telephone line before you run around worrying that Asterisk is not recognizing it. There was a guy who spent a good amount of time analyzing why the caller ID was not showing up in Asterisk by changing settings, changing them back, and so on before asking the customers if they actually had caller ID on their line. The response: "No, we never use it". Needless to say, it's the kind of mistake you make only once or twice.

Practical security

This part of the article must be seen as containing security measures below the headline security, which will be within your network as a whole—stuff such as firewalls.

The assumption is that your network is as secure as you want it to be. The measures identified in this section are some ideas on how to prevent abuse of your system by those coming into it on telephony channels of one sort or another.

The first thing to look at is how to stop unauthorized users hooking up to a channel on your Asterisk server. This can be done by allowing only given IP addresses or address ranges to connect with your Asterisk through, say, the SIP channel. It is easily implemented in sip.conf like this:


The example above would only allow a device with the IP address of to connect to that SIP profile. Notice that we first deny "all", before permitting the authorized address.

To allow the 192.168.2.XXX range of addresses, the entry should look like this:


In addition to restricting the IP address of devices hooking up to your system, you also need to pay very close attention to the [general] section of sip.conf and iax.conf, because this section may contain a line that directs unknown callers to a specific context in the dialplan.

A context in the dialplan is actually a mini dialplan in its own right.

In the sample configurations that come with Asterisk (which should not be used for a production system), the line looks like this:


This line may also appear in your chan_dahdi.conf (formerly zapata.conf).

This means that any of the calls that come in on those channels that do not match with one of the profiles specified lower down in the file, will be passed into the dialplan in the [default] context. Therefore, it is vital that you ensure—if you have a context called [default] in your dialplan, you don't allow callers that end up in that context to make calls that could cost you money, or waste the time of those with extensions on the system.

If you've checked your configuration and determined that you don't have a context=default line, don't think that you're safe from this particular feature. Even if there isn't a context=default line in the [general] section, Asterisk will still direct any of the unknown calls to a context called [default] in your dialplan, if you have such a context. So, it might be wise "not" to have a [default] context in your dialplan, or to ensure that if the context is present, it just plays an "unauthorized call" message.

To make things explicitly clear, you may wish to have a [incoming_untrusted] context to which all unknown IP calls are directed by the line context= (in the [general] section of sip.conf or iax.conf), instead of the [default] context. Now, a special message can be played to the calls which end up in the [incoming_untrusted] context.

Talking of contexts, these are our first line of defense against misuse by those who "are" allowed on the system. Once a call comes into a given context in the dialplan, there is no way for it to leave that context unless you allow it with a conditional or unconditional branch (GotoIf or Goto), or unless you have included some other context. In this case, the call will try to find a match in the included context only if no match is found in the first context it came into.

Knowing this enables us to use contexts to deny external callers the ability to make outbound calls, or to build a class of access model where certain internal users can make only locals calls. However, other, more privileged users, can make long distance and international calls too.

We direct a call coming into Asterisk by the line context= for that particular profile in the channel configuration file. Here is an example for a SIP phone:


The highlighted line in this profile, sends any call that comes in through that profile to the [local] context in the dialplan. The calls sent into that context might be allowed to call local numbers, free numbers, and other extensions on the PBX (In some time, we'll see them as four digit numbers that always begin with a "2" in an example).

If we look at the profile for a manager's phone on the PBX, it will look like this:


The highlighted line signifies that the can make long distance and international calls.

To see how this affects their respective abilities to make outside calls, we will need to look at the dialplan in extensions.conf:

exten => _1NXXNXXXXXX,1,Dial(SIP/ld-provider/${EXTEN}
exten => _011.,1,Dial(SIP/international-provide/${EXTEN})
include = > local
exten => _NXXNXXXXXX,1,Dial(SIP/local-provider/${EXTEN})
exten => _NXXXXXX,1,Dial(SIP/local-provider/${EXTEN})
exten => _18XX.,1,Dial(SIP/local-provider/${EXTEN})
exten => _2XXX,1.Dial(SIP/${EXTEN})

As you can see from the previous dialplan excerpt, the calls dropped into the [local] context can only dial local, free, and internal calls. If the dialed number does not match one of the four patterns shown, the call will be rejected as "extension not found".

Calls dropped into the [ld-and-international] context can call long distance and international destinations. Also, by virtue of the include => local part, they can make local, free, and internal calls too.

Please note that the aim here is to demonstrate the principal of restricting access, or creating classes of service, using contexts and includes. You will need to create a set of contexts that match the market you are in. For example, you may wish to limit access to mobile calls in places like the UK (where making calls to mobile phones from a landline is relatively expensive), however, this would be unnecessary in places like the US (here, the cost of making calls to mobile phones is exactly the same as that for calls made to a landline).

Another method of securing access to expensive calls is the Authenticate() dialplan application, which gives the user three tries to enter the specified PIN, and if unsuccessful, Asterisk hangs up the call. Successful PIN entry enables the next priority in the dialplan. Implementing this security method, for international calls made out of the US is as simple as:

exten => _011.,1,Authenticate(1357)
Exten => _011.,1,Dial(SIP/international-provider/${EXTEN})

When users dial a number starting with "011", they will be prompted for a PIN. Unless they enter "1357" within three tries, they cannot make an international call. You can use the ${} referencing to set the PIN, rather than hardcoding it, as I have done in the previous example.

There is also an application called VMAuthenticate(), which does the same as the Authenticate() application that we saw just now. However, it uses mailbox PIN codes to authenticate the users, so each of them can have their own unique PIN (as long as they have a voicemail box).

This security measure is great for hotel house phones or phones on the reception desks of businesses. Here, it would be good to have the convenience of staff being able to use them for say, international calls, but you don't want anyone who wanders in off the street being able to do the same.

There are, of course, a good number of more elegant or sophisticated ways to implement user authentication within Asterisk (perhaps including the use of the AstDB database). However, here the aim has been to highlight a couple of ready-made applications within Asterisk.

Out of hours

The last practical security measure we are going to look at is out of hours calling. Let's assume you, or your customer, want to implement a mechanism to secure office phones, which can currently make unlimited calls at any time of the day or night. To achieve this, you will require authentication for all calls placed between 6.00 pm and 7.30 am during the working week, and for all weekend calls. This prevents the friendly cleaning staff, or anyone else, from making expensive calls during this timeframe.

The next example, would allow a given phone to make outside calls (identified by the prefix "9", which we strip away from the front of the number before calling it) during the working day, but outside of those hours, a PIN (of 1357) will be required to give access to outside calls:

exten => _9.,1,GotoIfTime(07:30-18:00,mon-fri,*,*?allowed)
exten => _9.,n,Authenticate(1357)
exten => _9.,n(allowed),Dial(SIP/my-sip-trunk/${EXTEN:1})

Therefore, when a call is placed (with a leading "9") between the hours of 07:30 and 18:00, Monday to Friday, we jump to the priority label "allowed", which makes the call.

Outside of these hours, the call just drops down to the next priority, which prompts the user to enter a PIN before allowing the call to be made. Two extra lines in our dialplan could easily save the company a lot of money!


Having covered areas such as physical interfaces and security,it is reassuring to know that, although Asterisk was born in the USA, with a few minor changes to some configuration files and the right connectors in place, "you're all set" (as they say in the US) for successful international deployments.

On security, however, Asterisk must be handled at a network level. There is also scope to implement some security measures within Asterisk—both regarding who is allowed to connect to Asterisk, and which calls they are allowed to make once an authorized user is connected.

With these measures being so simple to implement, please put them in as a precaution at the creation of your solution. Don't let them be a reaction to an "issue" that was allowed to occur.

You've been reading an excerpt of:

Asterisk 1.4 - The Professional's Guide

Explore Title