Tech Series

Cisco Unified CM 6.1 to Asterisk and FreePBX SIP Trunks (Powered by Bandwidth.com)

Posted on by cosmicwombat
One of the systems I manage is an 875 Extension Cisco Unified Call Manager(UCM). At the moment the system uses SCAN trunks for long distance calling. These SCAN Trunks are provided by the state of Washington and interconnect via a four port FXO card. Callers use a PIN to make long distance calls. This is some seriously old school technology and as such has sound quality to match.

So, armed with a four port SIP trunk account from Bandwidth.com, I set forth to make a SIP trunk from the UCM to Bandwidth.com. Long story short… it does not look like I can. I can set things up that should work, but don’t. There is an active TAC open with Cisco and when(if) we make it work then I’ll be back in a new blog entry.

Instead, we have “Cisco Unified CM 6.1 to Asterisk as SIP Proxy for Long Distance service.”

What is difficult to impossible with UCM is trivial in Asterisk w/FreePBX.

For Bandwidth.com I made a new SIP Trunk with the name of “freepbx” and here are the PEER Details:

username=myusername
type=peer
sendrpid=yes
secret=mypassword
qualify=yes
insecure=very
host=trunk.freepbx.com
fromdomain=trunk.freepbx.com
context=from-trunk

The Register name was formated like this:

myusername:mypassword@trunk.freepbx.com/360746XXXX
——-
For the UCM, I made a SIP Trunk named “ucm” and here are the PEER Details:

type=peer
context=from-callmanager
host=10.XXX.XXX.XXX
disallow=all
allow=ulaw&alaw
nat=no
canreinvite=no
qualify=yes

and in extensions_custom.conf, courtesy of Philippe, I added ( to have these calls bypass most of the dialplan logic )

[from-callmanager] include => from-internal
exten => _1NXXNXXXXXX,1,Dial(${OUT_12}/${EXTEN});
exten => _1NXXNXXXXXX,n,hangup

NOTE: the the “OUT_12” reflects the “freepbx” trunk and the last thing to do is allow anonymous SIP as the calls are routed w/o authentication from the UCM ( for now.)

From CallManagerToSIP

Now on to UCM.

From CallManagerToSIP

Since we are using no authentication to send calls from UCM to Asterisk this part is somewhat straight forward. First step is to define a “SIP Trunk Security Profile Configuration” making sure the “Outgoing Transport Type” is UDP, which looks like:

From CallManagerToSIP

Then we create the SIP Trunk, noting that the “Calling Search Space” in this case is “Reserved Incoming Calls” which basically does not allow inbound calls to go anywhere:

From CallManagerToSIP

The last three items to set up are the “Route Group, Route List and Route Pattern.”

Here is the Route Group:

From CallManagerToSIP

Here is the Route List:

From CallManagerToSIP

And since we need a way to direct calls out this SIP Trunk to make long distance calls, here is the Route Pattern so users dial “891NXXXXXXXXX” to dial out:

Bare in mind, I only want calls going out this trunk ( not in) so if you wanted bi directional calls… You would adjust the “Calling Search Space” in the trunk to allow it.

Otherwise, that is the setup that is live for now. Once an Authenticated SIP Trunk can be sorted out on the UCM, I plan to go directly to Bandwidth.com and skip the proxy.

Restricting outbound calls in FreePBX (whitelist)

Posted on by mbrevda
Previously, we discussed [b]preventing [/b]outbound calls from FreePBX by using two methods: Misc Applications and outbound routes. There is also (at least) two ways to [b]allow [/b]outgoing calls using a whitelist, i.e. allowing calls [b]only [/b]to the numbers specified.

The first one is extremely simple, and I can already hear you saying “Duh!”. But sometimes the answer to a problem is staring us right in the face and we miss it anyway. So at the risk of insulting some of you, and hopefully enlightening some of you, here it is: Password protect your outbound routes. Yes, extremely primitive – but it works! Password protect those routes that you don’t want your users calling, and just leave the others unprotected. This will allow for an environment where you have very tight control over outbound calls.

The second way to restrict outbound calls is much more sophisticated and allows for refined control of which extensions/user are restricted and which aren’t (obviously without the use of a password). One of the goals of this method are to restrict the outbound calls but [b]nothing else[/b]. This method will keep all other FreePBX applications available to the restricted user: Voice Mail, Conferences, Paging, Call Forwarding, etc. – will all be available. The only thing restricted will be outgoing calls.

The first step is to segregate the restricted context form the other users. Start by opening /etc/asterisk/extensions_custom.conf and adding the following context:

[from-internal-restricted] #exec /var/lib/asterisk/bin/restricted.sh

The next step is to make sure asterisk will ‘follow’ the ‘exec’. Open /etc/asterisk/asterisk.conf and make sure you have a line that reads:

execincludes=yes ; support #exec in config files

(specifically, ensure there is no ; at the begging of the line). Next download this script, and save it to /var/lib/asterisk/bin/restricted.sh. Now, create /etc/asterisk/whitelist and add a list of numbers that you want whitelisted. Here a helpful hint: you can a space and a description after the number so that you remember who’s number it is and why its there. Here’s an example:

2125551212 bob
6565552121 marry
4264441212 bill

The last step is to place any extension that you want restricted in to the restricted context. In FreePBX, click Extensions -> select the extension -> and scroll down to the context option. Append -restricted to the text and click submit.

Finally, from the linux cli, type amportal chown and reload the asterisk dialplan in your usual way, either by clicking the orange reload bar in FreePBX or by entering dialplan reload from the asterisk cli.

Now, try to place a call from your restricted context – it should be blocked!

The way this works is as follows: when you reload asterisk, it executes the restricted.sh scrip and includes its output in the dialplan (dynamically). The scipt reads the FreePBX generated dialplan and copys the entire from-internal-additional dialplan in to our custom context (well, not the entire dialplan per se – just the includes. For more on how this works see my previous articles). It then reads the numbers listed in your whitelist file and creates routes for them as Local channels (which are callable by restricted extensions as they can call all [b]internal[/b] extensions).Cool, eh?

Got another way to restrict outgoing calls? Lets hear about them in the comments!

[b]Moshe Brevda, FreePBX Development Team[/b] lazytt – FreePBX forums
hi365 – IRC

Restricting outbound calls in FreePBX (blacklist)

Posted on by mbrevda
Perhaps one of the most requested features in FreePBX is the ability to configure calling permissions. While this is a complex and costly request from a development point of view, there are some simple techniques which can be used to provide some level of outbound call control. It is said that well written software can be used in a way totally different to what its author intended. Some of the current FreePBX modules can be ‘exploited’ to provide just such functionality. You may also want to have a look at the custom contexts module, however that is (still) considered a ‘contributed’ module, and isn’t supported by FreePBX.



Typically, there are two types of outbound call control that you will want to implement:

  1. Call all numbers except these (blacklist)
  2. Block all number except these (whitelist)

For both blacklists and white lists, there are (at least) two methods to block/allow calls. For this article, we will focus on blacklisting numbers. Merriam-Webster defines a blacklist as "a list … who are disapproved of". While only one method described here is actually a "list", both serve he same purpose: to restrict outbound calls. Which one you should use depends on your needs – and the length of our list.

If you only need to block one number you could set up a Misc Application with a destination of Hangup. To do this, click on Misc Applications from the module tool bar on the left hand side of the FreePBX window (if you don’t see the module, you will need to install it by clicking Module Admin -> Check for updates online -> Misc Application -> Download and Install -> Process (top or bottom of the page) ). Once the module page opens, you have the option to enter a new Misc Application. Enter a description in the Description box and the number that you wish to block in the Feature Code box. Now select a Hangup (or Busy) from the Terminate Call destinations option.Hit submit, click the orange bar, and reload FreePBX. Try to call the blocked number – your phone should disconnect the call (or play a busy signal).

You can take this a step further by sending the call to an announcement explaining that (and why) the call is barred, and then going to Hangup.
While this method is good if you want to block one specific mother (your wife/girlfriend from calling her mother?) what do you do if you want to block a whole list of numbers? (Premium rate numbers come to mind here). This can be accomplished quite simply as well (seems everything is simple when using FreePBX!).
First click on Trunks, and click Add Custom Trunk. In the dialstring add BARRED and click Submit. Next, click on outbound routes. Use standard dial rules to create dial rules for all your blocked numbers – list them one at a time or use dial patterns. You should probably call this Outbound Route BARRED (enter it in the Route name box). In the Trunk Sequence, select BARRED. Now click submit.

Here comes an important step: using the arrows under the route BARRED, move the route to the top of the list. Now click submit, click the orange bar, and reload FreePBX. Your calls should now be blocked. Once again, should you need to play a specific message or explanation, you can get fancy by sending the custom trunk to a specific destination or even a custom context.

Check back here soon for the next installment of this topic: Restricting outbound calls in FreePBX (whitelist)

update: Philippe has pointed out that best practice would be to always have an EMERGENCY route, and keep that as your first route. You would then place your BARRED route in second place. Click here to find out how you can hear more best practices.
Moshe Brevda, FreePBX Development Team
lazytt – FreePBX forums
hi365 – IRC

Found this tip useful? Don’t forget to donate by click the donate button!

BLF and FreePBX feature codes

Posted on by mbrevda
One of the really cool things added to the latest version of FreePBX is support for Russell’s devstate backport for Asterisk 1.4. Today I decided to have a look at how it works, and I found it to be extremely simple and straightforward to set up. Obviously, you need to add the backport to asterisk. Luckily, that is extremely easy – just follow the directions in the readme.

Next, add the following line to amportal.conf (if it isn’t already there):

USEDEVSTATE=true

I was looking to see the status of my Follow-Me, so I needed to configure one of the BLF’s on my phone to reflect on the its status. To do that I needed to set the BLF to watch feature code that I would normally dial to activate the Follow-Me: *21200. I updated my 00000000.xml directory configuration file for my Polycom 650 as follows:


Call Forwarding
*21200
7
0
0
1
0


I then rebooted my phone, and like the magic that FreePBX is, I can now tell by a glance what the Follow-Me status is. Now if only setting up an orb would be as simple!

Moshe Brevda, FreePBX Development Team
lazytt – FreePBX forums
hi365 – IRC

Miscellaneous/Custom application/extensions: How to extend FreePBX with custom dialplan (part 2 of 2)

Posted on by mbrevda
In part 1, we were discussing the basics of how the Asterisk dialplan works. To recap: asterisk is made up of contexts, which can in turn include more context, creating the whole dialplan. FreePBX takes advantage of this structure by creating a lot of contexts and then included these in each other. Until now, the easiest way to include your own custom dialplan was to put it in one of custom context that FreePBX intentionally leaves blank for the purpose of customization. Now (actually since version 2.3) FreePBX includes a module to make the process easier, simpler and cleaner.

To include your own dialplan in the call flow, we use a combination of modules. First, we need to tell FreePBX where in our dialplan we would like to point to. To do this, we set up a Custom Destination (from the tools tab) with the custom description pointing to out custom dialplan in the format of context, extension, priority. To refer back to our previous example, we would set the custom destination to: play-monkeys,66,1. We will also add a Description so that we can easily remember what this dialplan refers to. Lets call it play-monkeys. Then click submit.
Next, we need to create a Miscellaneous Application. The Misc Application module allows us to set up an extension (remember, in Asterisk an extension is somewhere in the dialplan that you can call – not necessarily a phone) that can point to anywhere. For example, if you want your users to be able to call an IVR which is usually only heard by inbound callers, you can set a feature code to call the IVR every time the feature code is dialed. Now we will set up a feature code to call out custom context: Click Misc Application from the setup tab, and enter a feature code, say 11234. Next Enter a description, say call monkeys. Finally, chose our custom Application form the Destination menu Custom Application: play-monkeys and finally click submit.
Now your all set! Reload FreePBX by clicking the orange bar, and call 11234 – you should hear the tt-monkeys file being played back!
There is one more thing to keep in mind. Sometimes, for whatever reason, you don’t want to call your custom dialplan directly from FreePBX. Nevertheless, it is important to make sure that you don’t accidentally assign a duplicate extension in both FreePBX and the dialplan. Being that FreePBX automatically picks a lot of the extensions it assigns, we need to let it know which extensions NOT to use. To do that, we use the
Custom Extension module (tools tab), and we enter the extension number we want to prevent FreePBX from using. This will prevent FreePBX from chosing an extension that you already assigned manually in the dialplan.
That’s all. Be sure to check back again next week for a tip on how to list all of the contexts and their includes from the dialplan!
Moshe Brevda, FreePBX Development Team
lazytt – FreePBX forums
hi365 – IRC