Localization and Practical Security in Asterisk 1.4: Part 2

Exclusive offer: get 50% off this eBook here
Asterisk 1.4 – the Professional’s Guide

Asterisk 1.4 – the Professional’s Guide — Save 50%

Implementing, Administering, and Consulting on Commercial IP Telephony Solutions

£16.99    £8.50
by Colman Carpenter David Duffett Ian Plain Nik Middleton | August 2009 | Linux Servers Networking & Telephony Open Source

In the previous article by Colman Carpenter, David Duffett, Ian Plain, and Nik Middleton, we covered tones, time, date, and changing the language of system prompts. This article will tell us about:

  • What needs to be changed in terms of telephony interfaces
  • Where to change the method of caller ID signaling used
  • Some ways to secure your Asterisk against unauthorized use by internal and external callers

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.

Asterisk 1.4 – the Professional’s Guide Implementing, Administering, and Consulting on Commercial IP Telephony Solutions
Published: August 2009
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:

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.

Asterisk 1.4 – the Professional’s Guide Implementing, Administering, and Consulting on Commercial IP Telephony Solutions
Published: August 2009
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:

About the Author :

Colman Carpenter

Colman Carpenter is the MD of Voicespan, a Kent-based company that offers Asterisk-based systems to the SME market across the UK. He is an IT professional of over 20 years standing, with experience in diverse areas such as IBM mid-range software development, Lotus Notes and Domino consultancy, Data Management, E-marketing consultancy, IT Management, Project Management, Wordpress Website Design, and lately, Asterisk consultancy. He is a qualified PRINCE2 practitioner.

Voicespan (http://www.voicespan.co.uk) offers Asterisk-based systems as the cornerstone of a holistic VoIP-telephony service for SMEs. They offer companies a one-stop shop for implementing a VoIP-capable system, encompassing Asterisk-based systems, endpoints, trunks, telephony interfaces and network equipment, and the consultancy necessary to bring it all together into a coherent whole. This is his first book.

David Duffett

David Duffett delivers Asterisk training and consultancy around the world through his own company (TeleSpeak Limited, www.telespeak.co.uk), in addition to designing and delivering training for a number of companies, including Digium, Inc.

A keen Asterisk enthusiast, David also enjoys podcasting, radio presenting, and teaching public-speaking skills. He is a Chartered Engineer with experience in fields including Air Traffic Control communications, Wireless Local Loop, Mobile Networks, VoIP, and Asterisk. David has been in the telecoms sector for nearly 20 years and has had a number of computer telephony, VoIP, and Asterisk articles published through various industry publications and web sites.

Ian Plain

Ian Plain has worked in the telecoms industry since 1981 and has designed some of the largest PBX networks in the UK. Since the late 1990s, he has been involved with VoIP initially for links between systems, and with IP PBX systems since 1999. Since 2003, he has been running a telecoms consultancy based near Bath in the UK, working primarily on high-availability Asterisk-based solutions for corporate customers.

Nik Middleton

Nik Middleton has been in wide-area communications since the mid-eighties. He spent most of the nineties working in the US, where he developed a shareware Microsoft mail to SMTP/POP3 connector that sold some 287,000 copies. He spent six years working for DuPont in VA, developing remote monitoring systems for their global Lycra business. In late 2000, he returned to the UK where he held various senior positions in British Telecom, LogicaCMG, and Computer Science Corp.

In 2005, tired of working in London, he set up his own company (Noble Solutions) providing VoIP solutions in rural Devon, where he now lives with his wife Georgina and three children, Mathew, Vicky, and Isabel. A keen amateur pilot, his favorite place when not in the office is flying over the beautiful Devon countryside.

Books From Packt

Scratch 1.4: Beginner’s Guide
Scratch 1.4: Beginner’s Guide

Drools JBoss Rules 5.0 Developer's Guide
Drools JBoss Rules 5.0 Developer's Guide

Cacti 0.8 Network Monitoring
Cacti 0.8 Network Monitoring

Building Enterprise Ready Telephony Systems with sipXecs 4.0
Building Enterprise Ready Telephony Systems with sipXecs 4.0

Plone 3 Theming
Plone 3 Theming

Asterisk Gateway Interface 1.4 and 1.6 Programming
Asterisk Gateway Interface 1.4 and 1.6 Programming

trixbox CE 2.6
    trixbox CE 2.6


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software