http://www.astricon.net/2009/astricon/presentation/FreePBX/index.htm
FreePBX Intro: Past, Present and Future
http://www.astricon.net/2009/astricon/presentation/FreePBX/index.htm
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-internalNOTE: 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.
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
Typically, there are two types of outbound call control that you will want to implement:
USEDEVSTATE=true
Call Forwarding
*21200
7
0
0
1
0