First we’ll quickly talk about cdr_odbc. This allows us to store our CDR data directly to a database. Most people are probably going to be using MySQL. And you probably thought that you had to install the Asterisk-Addons to be able to use MySQL (Due to licensing concerns.) Well, not anymore. Not with ODBC. Okay, so I’m going to assume that you have already installed ODBC and recompiled Asterisk as per my previous post.  In our /etc/odbc.ini file we created database connections. Hopefully you have already created the databases. If not, go ahead and do that now.   Here’s the table structure for CDR:

CREATE TABLE IF NOT EXISTS `cdr` (
`calldate` datetime NOT NULL default ’0000-00-00 00:00:00′,
`clid` varchar(80) NOT NULL default ”,
`src` varchar(80) NOT NULL default ”,
`dst` varchar(80) NOT NULL default ”,
`dcontext` varchar(80) NOT NULL default ”,
`channel` varchar(80) NOT NULL default ”,
`dstchannel` varchar(80) NOT NULL default ”,
`lastapp` varchar(80) NOT NULL default ”,
`lastdata` varchar(80) NOT NULL default ”,
`duration` int(11) NOT NULL default ’0′,
`billsec` int(11) NOT NULL default ’0′,
`disposition` varchar(45) NOT NULL default ”,
`amaflags` int(11) NOT NULL default ’0′,
`accountcode` varchar(20) NOT NULL default ”,
`uniqueid` varchar(32) NOT NULL default ”,
`userfield` varchar(255) NOT NULL default ”,
KEY `calldate` (`calldate`),
KEY `dst` (`dst`),
KEY `accountcode` (`accountcode`),
KEY `dst_2` (`dst`),
KEY `uniqueid` (`uniqueid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

There’s been so much talk about how the CDR system was going to be changed but I never saw any developments from that. ODBC doesn’t support ‘start’,'answer’,'end’ for the CDR. ‘calldate’ is going to be the time that the call hit the PBX.   Anyway, back to it…

You can edit your /etc/asterisk/cdr.conf to include the desired settings you want. I like to enable the following:

[general]
unanswered=yes
loguniqueid=yes
loguserfield=yes

Okay, now edit your cdr_odbc.conf to match the settings from your previous created database and cdr table.

[global]
dsn=asterisk     ;<= This matches your ‘context’ from /etc/odbc.ini
username=asterisk    ;<= Don’t really need these due to the dsn already containing login details.
password=yourpassword
loguniqueid=yes
dispositionstring=yes
table=cdr               ;”cdr” is default table name
usegmtime=no             ; set to “yes” to log in GMT

Restart Asterisk and you should be logging CDR data to your database now. Pretty easy. And you didn’t even have to install Asterisk-Addons.

I’ll be exploring the different applications and functions available within Asterisk, and my favoriate approach to using Asterisk.

STEP ONE: Install CENTOS and Tools
So we’re running the leanest install of CentOS. You probably will only need the first CD (1 of 6) for this install. I customized the installation and unchecked everything. I wanted just the bare install. Anything else we need we’ll be installing via YUM.  Leaner is meaner – right? By the way, I’m installing the latest CentOS 5.x.

Once that’s done, we’ll install the tools that we know we’ll need. This is a nice little list, so I hope your internet connection is good. Or you can install from the CD these packages if you need. So here we go:

rpm -import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
yum -y install nano setuptool ifconfig man nslookup traceroute dig chkconfig system-config-network-tui screen kernel-devel kernel-source bison openssl-devel mysql php-mysql mysql-server mysql-devel gcc libtermcap libtermcap devel newt newt-devel zlib-devel ncurses-devel gcc-c++ compat-gcc-32 compat-gcc-32-c++ unixODBC unixODBC-devel gtk+ libxml2-devel wget mlocate lynx tar nmap bzip2 mod_ssl crontabs vixie-cron libtool-ltdl libtool-ltdl-devel mysql-connector-odbc libidn curl libidn-devel curl-devel lame sox ntsysv httpd php mod_ssl php-mbstring php-mcrypt sudo vixie-cron

Let’s do a quick yum -y update and update the whole system. Then reboot.

I’m a big fan of using a database to drive Asterisk. It gives alot more flexibility for configuring on the fly and can add more redundancy to the system by separating the database from Asterisk. So we’ll be installing ODBC. We’ve already yum installed the ODBC packages. Now we just need to set them up to interface with our database server. We need to do this before we compile Asterisk, so that we can compile func_ODBC, res_ODBC and cdr_ODBC, etc. Check out a previous article here for how to setup ODBC.

The ODBC install tells us how to compile Asterisk, but I’ll note that again here:

cd /usr/src/
wget http://www.asterisk.org/downloads/asterisk/1.6.2.7
tar -zxvf asterisk-1.6.2.7.tar.gz
rm -f asterisk-1.6.2.7.tar.gz
cd /usr/src/asterisk-1.6.2.7
./configure
make && make install
make config

Because we’re using ODBC, there’s no reason that I would install the Asterisk-Addons. I mainly used it for the ability to connect to MySQL. Some others might want it for the MP3 Playback. If that’s you, here’s how you would do that:

cd /usr/src/
wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-addons-1.6.2.1.tar.gz
tar -zxvf asterisk-addons-1.6.2.1.tar.gz
rm -f asterisk-addons-1.6.2.1.tar.gz
cd asterisk-addons-1.6.2.1
./configure
make menuselect

make && make install

Other things you might have to compile…
DAHDI: http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.3.0+2.3.0.tar.gz
LibPRI: http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.10.2.tar.gz

For this example, I’m not installing anything but Asterisk. After all, the title is leaner is meaner. So we’re running the most basic of Asterisk. All connections to our carrier is purely SIP or IAX, so we only need a good Internet connection to make our PBX rock n’ roll.

Okay, so let’s backtrack just a little bit. Let’s go back to before we compiled Asterisk. Let’s take a look at the ‘make menuselect’ options and only get what we need. Obviously, that’s going to depend on your own personal requirements. I’m just going to list a couple that I didn’t need, and you probably aren’t going to need either:

APPLICATIONS:
- app_adsiprog
- app_alarmreceiver
- app_festival

CHANNEL DRIVERS:
- chan_oss
- chan_skinny
- chan_unistim

CODEC TRANSLATORS:
- codec_adpcm
- codec_g722
- codec_g726
- codec_ilbc
- codec_lpc10

FORMAT INTERPRETERS:
- format_g723
- formet_g726
- format_g729
- format_h263
- format_h264
- format_ilbc
- format_jpeg
- format_pcm
- format_siren14
- format_siren7
- format_sln16
- format_sln
- format_vox

There’s so much more than can be disabled. I like having some features around to play around with.

So that’s it. I hope that the leaner, meaner Asterisk is useful to you.

What is ODBC? ODBC is an Open Database Connector. When talking about ODBC, I’m talking about UnixODBC – obviously.   In lame men’s terms, ODBC is a connector that allows me to connect to many different database interfaces. It can be MYSQL, PostgreSQL, MSSQL, and so on.  I configure my database types in one file, and configure the databases (with logins) in another file. Then I can much more easily connect to my database from my application.

So what does that mean to you? Maybe nothing. But for me, it’s awesome. Especially in terms of Asterisk. The Asterisk community understands the value of being able to interface with with the database. As mentioned above, I love it because I like to house my dialplans right within a database, so I can modify them without reloading Asterisk. This is especially important when the dialplan is several thousand lines long. Additional benefits include writing CDR data to databases (perhaps ones that aren’t natively supported by Asterisk – now you can with ODBC.)

So how do you install ODBC and get it working with Asterisk?  That’s the easy part.

I’m going to assume that you are running Asterisk on CentOS. If not, you’re on your own. CentOS is preferred.

To Install:

yum install unixODBC unixODBC-devel

Easy enough huh? Okay, let’s configure it.  Start by editing /etc/odbcinst.ini
If you plan on using PostgreSQL it should be ready to go. You might have to adjust the socket path, depending on your system.  For MySQL, using the following:

[MySQL]
Description     = ODBC for MySQL
Driver          = /usr/lib/libmyodbc3.so
Setup           = /usr/lib/libodbcmyS.so
FileUsage       = 1

Again, you may have to adjust the Driver Path depending on your system.  Now we just need to setup the database connections. Do this by editing /etc/odbc.ini

[asterisk]
Description     = Asterisk realtime
Driver          = MySQL
Socket          = /var/lib/mysql/mysql.sock
Server          = localhost
User            = asterisk
Pass            = yourpassword
Database        = asterisk
Option          = 3

[crazyapp]
Description     = My Crazy Apps database
Driver          = MySQL
Socket          = /var/lib/mysql/mysql.sock
Server          = 192.168.15.166
User            = databaseuser
Pass            = yourpassword
Database        = crazyappdatabase
Option          = 3

Okay, you’re done! But wait! How do I use it with Asterisk? Oh yea, that part. Now we need to let Asterisk know that ODBC is available. If you have already compiled Asterisk, that’s not a problem. You will just have to recompile.

cd /usr/src/asterisk-1.6.2.7
./configure
make menuselect
make && make install

If I can stress anything at all, it’s to make sure that you re-run ./configure — this is what tells Asterisk ODBC is there.  ‘make menuselect’ is another key part. Here’s where we select the functions and applications that would be using ODBC. A few off the top of my head:

‘cdr_odbc’
This one is for inputting CDR data into a database. If you were previously compiling Asterisk-Addons just to have CDR_MYSQL – no need now!

‘res_config_odbc’
This is for realtime over ODBC instead of MySQL. Again, if you were previously compiling Asterisk-Addons, no need now!

‘ODBC Storage’
This one is perfect. You can store voicemails in a database.

Okay, so we have recompiled Asterisk. Give Asterisk a quick restart. Now we can start using ODBC within Asterisk. I’ll be posting some more articles soon which will feature using ODBC for Asterisk Realtime, CDR, Voicemail Storage, and using it within the dialplan. So make sure you check back soon.

STEP ONE:
We’ll start by toasting our bread. I’m using cheap bread in my demo, but I like to get some good multi-grain or potato bread for optimal flavor. Toast it up real nice and don’t forget to butter it when it is fresh out of the toaster. REAL BUTTER adds the best favor.

STEP TWO:
Put some cheese on the toast. Kind of cheese is up to you. But I like pepper jack. Put it on soon, so it has a few minutes to melt while we whip up our tuna salad.

STEP THREE:
Remove any water from the canned tuna. I prefer tuna that’s canned in water not oil. By the way, chicken can be substituted instead of tuna. It’s awesome either way.  So drain the water from the tuna, and dump it into a bowl.  I like to add some lemon juice – for a little zig! And some cajun seasoning for some kick. Instead of using mayonnaise or miracle whip, use ranch dressing. Hidden Valley is the best.   Mix all that up real good.

STEP FOUR:
Load it up on your toasted, cheesed bread. And load some hot sauce on there. Louisana is really good. I like it overloaded, so much that you can barely see the tuna. But for the demo, I’ll be easy on ya.

And now you are ready to eat and enjoy. Let me know what you think!

Keep in mind this will only working with 1.4.23 or higher. It was originally only added to 1.6, but the community decided it was needed as a backport into 1.4.  I hope this is helpful to someone. It took me 3 days of googling to find a working solution. Suspense is killing you I know. The answer is state_interface. This basically allows you to set which device/extension to watch. With AgentCallBackLogin and my alternative using Local Extensions, you still have to tell everyone which SIP or IAX phone/device the agent is sitting at. When this value is placed in the state_interface, Asterisk will check that device to determine if the agent is indeed ‘busy.’ Clever huh?  Here’s how to set it up…

Using Asterisk Realtime – Queue Members
If you using Asterisk Realtime queue_members, you will need to modify the table structure just a bit. You will need to add a column ‘state_interface’ after the ‘pause’ column. So your table will look something like this:

CREATE TABLE IF NOT EXISTS `queue_members` (
`uniqueid` int(10) unsigned NOT NULL auto_increment,
`membername` varchar(40) default NULL,
`queue_name` varchar(128) default NULL,
`interface` varchar(128) default NULL,
`penalty` int(11) default NULL,
`paused` int(1) default NULL,
`state_interface` varchar(128) NOT NULL,
PRIMARY KEY  (`uniqueid`),
UNIQUE KEY `queue_interface` (`queue_name`,`interface`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=23 ;

Then when you add your agents to the table, make sure you set the state_interface. Example:

INSERT INTO `queue_members` (`uniqueid`, `membername`, `queue_name`, `interface`, `penalty`, `paused`, `state_interface`) VALUES
(23, ‘Robert’, ‘CSR1′, ‘local/1005@agents/n’, 5, NULL, ‘SIP/100′);

Robert is logged into CSR1 queue with his local extension being: local/1005@agents/n, but he’s on device SIP/100. Asterisk will be checking SIP/100 for the device status. Is he really ‘busy’ after that call transfer? Probably not.

Using AddQueueMember
In my alternative and some of the examples on voip-info.org, you use AddQueueMember. Well, if you are already running the required version, you probably noted the additions. Layout looks like this:

AddQueueMember(queuename[,interface[,penalty[,options[,membername[,stateinterface]]]]]))

So, using the same info as my previous example, I would create the following in my dialplan:

exten => 701, 1,AddQueueMember(CSR1|local/1005@agents/n|5||Robert|SIP/100)

Using Asterisk CLi
Of course, you can always add the member by CLi:

add queue member local/1005@agents/n to CSR1 as Robert state_interface SIP/100

I hope this has helped someone. I know it was a big pain for us for a long time. And I spent a good amount of time searching for a solution. Well, now you have a solution!

The complicated answer to the above question is this:
SPF means Sender Policy Framework.

What does that mean?  Well, I’ll make it as simple as I can. It’s basically a DNS record that is put in place that lists the allows mail servers (SMTP Servers) that you have authorized to send email for your domain. Why would you want this? Simply to help fight the war against forged or spoofed messages.  How so? Basically, the receiving mail server (or host) if they are checking for SPF records, it will make sure the message it’s receiving is coming from the allowed hosts.

So for example, for bahjons.com, I only want messages to be accepted if it’s coming from the mail server: mailserver2.bahjons.com – I could create an SPF record only allowing this host. When a message is sent to Yahoo Mail, they will check to make sure the message is from mailserver2.bahjons.com.  You can find out how to create an SPF record at www.openspf.org

If you want to be able to check to see if a domain has an SPF record, you can use a validation tool like this one.

I hope that helps.

Actually, I hadn’t done this before myself, before writing this article. In my search of the web, I didn’t find many good tutorials. One useful resource that I did find was the O’Reilly Asterisk: The Future of Telephony, Second Edition.  This book is truly a great find. It’s a great addition to your library of ‘must haves.’  Okay, so let’s get right into it.

To keep things simple, I’m going to say that you have two locations: LocationA and LocationB. And at each of those locations, you have ServerA and ServerB. Now for this to work, each location must have it’s own set of employee extensions. So let’s say, ServerA has employee extensions: 1000-1999 and ServerB has employee extensions: 2000-2999. Now that we’ve setup the scenario, let’s get busy.

On ServerA, let’s make the below additions to the sip.conf. Under the general context, we’ll add the following register line, which will register this server to ServerB, and we’ll setup the peer too.

register => serverA:serverApass@<hostname-or-ip-of-serverB>/serverB

[serverB]
type=friend
secret=serverBpass
context=serverB_incoming
host=dynamic
disallow=all
allow=ulaw

We’ll make the following additions to the extensions.conf on ServerA as well:

[agents]
exten => 1050,1,Set(AGENT_SIP=${DB(agent_sip/1050)})
exten => 1050,n,Dial(SIP/${AGENT_SIP})

exten => 1100,1,Set(AGENT_SIP=${DB(agent_sip/1100)})
exten => 1100,n,Dial(SIP/${AGENT_SIP})

exten => 1150,1,Set(AGENT_SIP=${DB(agent_sip/1150)})
exten => 1150,n,Dial(SIP/${AGENT_SIP})

[phones]
include => agents
include => remote

[remote]
exten => _2XXX,1,Dial(SIP/serverB/${EXTEN},30)
exten => _2XXX,2,Hangup()

[serverB_incoming]
include => agents

Okay, so I’ll explain all of the above.  We have a ‘phones’ context, which we have all of our SIP Phones apart of.  The ‘phones’ context also includes our ‘agents’ context and ‘remote’ context.  The  ‘agents’ context is where we have our agent extensions, and they dial the SIP Phones.  (I’m assuming that you have your agents context created based on my article discussed here.)  We also have a ‘remote’ context which is what makes the connection to ServerB if we dial one of the 2XXX extensions.  If we dial a 1XXX extension, it will ring the local (ServerA) agent.  We have the ‘serverB_incoming’ context including the ‘agents’ context, because this is where calls are routed to if dialed from ServerB

Now let’s setup ServerB. The sip.conf will have the following additions:

register => serverB:serverBpass@<hostname-or-ip-of-serverA>/serverA

[serverA]
type=friend
secret=serverApass
context=serverA_incoming
host=dynamic
disallow=all
allow=ulaw

And the extensions.conf:

[phones]
include => agents
include => remote

[agents]
exten => 2050,1,Set(AGENT_SIP=${DB(agent_sip/2050)})
exten => 2050,n,Dial(SIP/${AGENT_SIP})
exten => 2100,1,Set(AGENT_SIP=${DB(agent_sip/2100)})
exten => 2100,n,Dial(SIP/${AGENT_SIP})

exten => 2150,1,Set(AGENT_SIP=${DB(agent_sip/2150)})
exten => 2150,n,Dial(SIP/${AGENT_SIP})
[remote]
exten => _1XXX,1,Dial(SIP/serverA/${EXTEN})
exten => _1XXX,2,Hangup()

[serverA_incoming]
include => agents

So for explaination, we have basically the reversed on ServerB. We have the same contexts. If someone on ServerA dials a 2XXX extension, it will route through the ‘remote’ context to ServerB, which will ring the local extension on ServerB.

Boy, that can look confusing. But it does work, and works rather well. You can do the samething with IAX for connecting two Asterisk Servers together. You simply need to setup your peers and register lines within iax.conf, and change the ‘remote’ context within extensions.conf

I hope this is useful to everyone.

I previous mentioned a disadvantage being that you can’t block calls per destination DID or phone number. This was a problem for me. I wanted to be able to block callers from calling one of the phone numbers in my PBX, but not another number. So I came up with the following solution. You can modify the solution according to your requirements. I’ll give two ways of doing this, in addition to simple alternative for LookupBlackList – so it functions the same way.

First off, we can store our numbers to be blocked within a SQL database or AstDB. This will determine which method we’ll be using. We’ll start with AstDB.We also need to determine how we want to filter the callers: By caller id name, or caller id number? I personally like the number. This is generally the most unique caller id characteristic.

In this example, we have given each DID an unique id. For this example, I’m going to call it a ‘company’ (assuming each DID is a different company.)

Let’s add our callers to be blocked into AstDB:

database put <companyid> <numberblocked> 1
database put 100 4801115432 1
database put 150 6023321444 1

Now, let’s put together our dialplans:

exten => 18003337123,1,Set(COMPANY=100)
exten => 18003337123,2,Set(CID=${CALLERID(num)})
exten => 18003337123,3,Gotoif($["${DB(${COMPANY}/${CID})}" = "1"]?goaway,1,1)
exten => 18003337123,4,Queue(CSR1)

exten => 18004447123,1,Set(COMPANY=150)
exten => 18004447123,2,Set(CID=${CALLERID(num)})
exten => 18004447123,3,Gotoif($["${DB(${COMPANY}/${CID})}" = "1"]?goaway,1,1)
exten => 18004447123,4,Queue(CSR1)

[goaway]
exten => 1,1,Playback(not-taking-your-call)
exten => 1,2,Playback(vm-goodbye)
exten => 1,3,Hangup()

Now, to example the above dialplan example… We first create a variable ‘COMPANY’ – this is where we set a Company ID for this DID. Second priority, we set the CallerID Number. We are only taking the number from the caller id, because that’s what we’res blocked based on. If we were blocking based on the name, we would change that to show: CALLERID(nam)  – I have not successfully got it to work with CALLERID(all). Third priority, we check to see if the calling party is added to the AstDB for blocking. If so, it will jump to the ‘goaway’ context, to playback a message telling the caller they are blocked. Otherwise it will continue to the 4th priority, where it enters the caller in the queue.   The important thing is, that it’s only looking for blocked calls setup in AstDB for that Company ID. This gives you more control over the blocking per phone number (DID.) That’s it. Pretty simple.

Now, let’s assume that we want to use MySQL for doing the samething. We can do the same thing. I’m one of those that likes to use MySQL for everything. This allows me to create a PHP/MySQL GUI for easy management. I haven’t tested how resource intense this is, so use at your own risk.

Let’s create our database and table first:

CREATE DATABASE asterisk;
GRANT ALL PRIVILEGES ON asterisk.* TO 'asterisk'@'localhost' IDENTIFIED BY 'yourpassword' WITH GRANT OPTION;

CREATE TABLE IF NOT EXISTS `blacklist` (
`company_id` varchar(3) NOT NULL,
`phonenum` varchar(30) NOT NULL,
PRIMARY KEY  (`company_id`,`phonenum`),
FULLTEXT KEY `phonenum` (`phonenum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Now, we can add our blocked numbers. Again, this relies on the company id for it to function.

INSERT INTO `asterisk`.`blacklist` (`company_id`, `phonenum`) VALUES ('100', '16021231141');
INSERT INTO `asterisk`.`blacklist` (`company_id`, `phonenum`) VALUES ('150', '14801231141');

Now let’s setup the dialplan:

[incoming]
exten => 18003337123,1,Set(DID=${EXTEN})
exten => 18003337123,2,Set(CID=100)
exten => 18003337123,3,Goto(cblock,1,1)
exten => 18003337123,5,Queue(CSR1)

exten => 18004447123,1,Set(DID=${EXTEN})
exten => 18004447123,2,Set(CID=150)
exten => 18004447123,3,Goto(cblock,1,1)
exten => 18004447123,5,Queue(CSR1)

[cblock]
exten => 1,1,MYSQL(Connect connid localhost asterisk yourpassword asterisk)
exten => 1,2,MYSQL(Query resultid ${connid} SELECT\ 'phonenum'\ FROM\ 'blacklist'\ WHERE\ 'company_id'\='${CID}'\ AND 'phonenum'\='${CALLERID(num)}'\)
exten => 1,3,MYSQL(Fetch fetchid ${resultid} BLACKLIST)
exten => 1,4,MYSQL(Clear ${resultid})
exten => 1,5,MYSQL(Disconnect ${connid})
exten => 1,6,GotoIf($["${CALLERID(num)}" = "${BLACKLIST}"]?goaway,1,1:cblock,1,8)
exten => 1,7,Goto(incoming,${DID},5)

[goaway]
exten => 1,1,Playback(not-taking-your-call)
exten => 1,2,Playback(vm-goodbye)
exten => 1,3,Hangup()

So in the above example we first set the company extension or DID in a variable, so we can redirect our dialplan back to it later. Then we set the company id as a variable. Next we forward to the call blocking context to see if the caller is allowed through. We query the MySQL database for the phone number. If it appears in the database for the company id, we forward them to the ‘go away’ message/context. If it doesn’t appear, we redirect them back to the next step in the DID’s dialplan.

What if you want to filter for all the phone numbers (DIDs) coming into Asterisk? Okay, so you can simply use the following:

Use AstDB – it will be quicker. Use the following to input the numbers into the blacklist:

database put blacklist <blockednumber> 1
database put blacklist 4801115432 1
database put blacklist 6023321444 1

And your dialplan will be as follows:

exten => 18003337123,1,Set(CID=${CALLERID(num)})
exten => 18003337123,2,Gotoif($["${DB(blacklist/${CID})}" = "1"]?goaway,1,1)
exten => 18003337123,3,Queue(CSR1)

exten => 18004447123,1,Set(CID=${CALLERID(num)})
exten => 18004447123,2,Gotoif($["${DB(blacklist/${CID})}" = "1"]?goaway,1,1)
exten => 18004447123,3,Queue(CSR1)

[goaway]
exten => 1,1,Playback(not-taking-your-call)
exten => 1,2,Playback(vm-goodbye)
exten => 1,3,Hangup()

I hope this is useful to someone. I would like to hear your comments.

It’s actually an older application. But in trying to use it, I didn’t see many examples for using it, or the options that can be used with it. And for good reason. It seems it’s depreciated, in favor of using the GotoIf application. However, I did find it will available with Asterisk 1.4.x so I thought I would give a quick writeup, in the event someone wants to use it.   I’ll also be posting about it’s limitations, and soon will post an article with my quick ‘solution’ to the problems I faced with LookupBlackList app.  So let’s dive right in.

First thing is first. We need to setup our table of callers to block. It’s going to be using AstDB for this. So from the Asterisk CLi:

database put blacklist <blockednumber> 1
database put blacklist 4801115432 1
database put blacklist John Smith 1

Okay, so the tables are set. Once we have the rest of our dialplan setup, any calls coming from the callerid ’4801115432′ or from ‘John Smith’ will be blocked.

Okay, so let’s switch over to our dialplan. I’ll assume that you are using extensions.conf for your dialplans.

exten => 18003337123,1,Answer()
exten => 18003337123,2,LookupBlacklist(j)
exten => 18003337123,3,Queue(CSR1)

exten => 18003337123,103,Playback(not-taking-your-call)
exten => 18003337123,104,Playback(vm-goodbye)
exten => 18003337123,105,Hangup()

To explain the above, 18003337123 is of course, my incoming phone number. First it answers the call, and then runs the LookupBlacklist app. There’s only one option for this app that I could fine – the ‘j’ option, which will jump the dialplan if the callerid is found in the blacklist database. Otherwise, it will take the caller into a queue that I have created. When it comes to jumping, it will always jump within the same context, and extension. It just jumps priorities. It will add 101 priority to whatever the current priority is. So in this case: priority 2 + 101 = 103 as the starting priority. Here I can tell Asterisk want to do with the blocked caller. In the above example, I’m playing an audio file that informs them that I’m not accepting their call, it says goodbye, and then hangs up.

If you are like me, you hate recording your own messages. Luckily there’s already one there. The default Asterisk install doesn’t have it in the sounds directory. But I found one in an older Asterisk Sounds zip. Here’s the file I used above in gsm format. Download it here.

Disadvantages to this application is that it doesn’t allow you to block callers on a per DID bases. What I mean by that, is this… Say you have multiple phone numbers coming into your PBX. You want to allow John Smith to call this phone number, but not another number coming into the PBX. This isn’t so easy with this application – in fact it doesn’t have this ability. What to do this? Check back shortly for a followup article of my little ‘alternative’ solution.

STEP TWO:
Put some vegetable oil in the cooking pan. I usually put in enough to cover the whole bottom of the pan by 1/4 inch. Go ahead and turn the stove on, on Medium-High heat.

STEP THREE:
Once we have the burritos thawed in the microwave, we’ll place them in the pan. We’re gonna cook them until they are golden brown all around. I even like to turn them up on their sides so its all browned.

STEP FOUR:
Enjoy! We’re all done, once they are golden brown. Put them on a plate, and enjoy with your favoriate sausa or hot sauce.

What kind of burritos should you get? I like to get Bean and Cheese. But you can use Chicken, Bean and Beef, Beef and Cheese, etc. They can be purchased anywhere: Fresh and Easy, Walmart, Frys.