I stumbled upon this module last night when trying to delimit access to an outbound route per extension. I added a colleague to my PBX who had purchased an account at voip.ms; problem was when he would dial out it would always display my Caller ID and use my trunk (which is bad if he dials international). I guess this is a frequently asked question so I created a video demonstrating the great power of this module – you will be surprised how easy creating permissive contexts can be This video will show you how to install the module and limit access to outbound routes / trunks per extension. The goal is to partition an Asterisk IP PBX in order to host multiple tenants on one system.

The following information is from this site.  Please check it out for download link and changelog / usage.

Possible Uses

• Restrict access to certain outbound routes or feature codes by a particular extension or group of extensions.
• Give particular extension(s) priority access to certain outbound routes, such as a particular emergency route associated with their geographic location.
• Give certain outbound routes top priority for use during “free” or low cost calling periods, while making those same routes lower priority (or disallowing access entirely) during higher cost time periods.
• Disallow access to outbound routes (with possible exception of Emergency access) to certain (or all) extensions during particular time periods (don’t let night cleaning crew make long distance calls, or disallow outgoing night calls from telephones in children’s rooms, while still allowing emergency number calls).
• Allow two or more families/companies/organizations to use the same FreePBX box, while still allowing each to have access only to “their” outgoing routes and trunks.
• If you have a SIP provider that does not send DID (normally a pain to handle because you can’t create a normal Inbound Route), set up a new custom context (call it idiot-provider), give them no access to anything (deny all), and then specify where you want their calls to go in the Failover Destination. Then put context=idiot-provider in that provider’s trunk user details.

Module Description

One feature which was a bit lacking in Asterisk/FreePBX was the ability to easily create multiple tenants.

This module creates custom contexts which can be used to allow limited access to dialplan applications.

Now allows for time restrictions on any dialplan access!

This can be very useful for multi-tenant systems.

Inbound routing can be done using DID or zap channel routing, this module allows for selective outbound routing.

House/public phones can be placed in a restricted context allowing them only internal calls.

Custom contexts can now be used as destinations. An IVR menu, Time Condition, etc. can now send a caller into a custom context. This feature requires FreePBX 2.2.0rc2 (or the latest SVN version if prior to the release of rc2)

(The following are the module author’s comments, “I” refers to the module author, not the original creator of this wiki page).

A number of improvements have been made to freePbx to handle multiple tenants.

1) inbound routing based on zap channel – i used to have to hack it by putting each zap channel in its own context.

2) authtype = database allows for dividing extension ranges

the main problem for me was outbound routing…

I wanted some extensions to dial out one route, and others out another route.

I had to create a custom context for each, then place each in their own custom context, then include all of the contexts which they should have access to. This became a nuisance as each module added its own context to from-internal-additional which could not be included as it also contains outbound-allroutes.

The purpose of this module is to dynamically list all contexts included in any contexts you choose, and allow you to create custom contexts which can include any of these all without config editing.

Being woken up several times throughout the night from anonymous calls is not fun.  Here is a screencast (shot with my shiny new MacBook) that explains how to delimit these annoying calls while still being able to route incoming SIP calls from Gizmo and IPKall to their appropriate destinations.

Here is the code I used to allow IPKall incoming SIP connections :


[ipkall]
disallow=all
host=66.54.140.46
context=from-trunk
insecure=port,invite
qualify=yes
type=peer
dtmfmode=rfc2833
allow=ulaw
nat=no

[ipkall2]
disallow=all
host=66.54.140.47
context=from-trunk
insecure=port,invite
qualify=yes
type=peer
dtmfmode=rfc2833
allow=ulaw
nat=no


More than 15 people have contacted me looking to receive an invitation to Google Voice, unfortunately Google has decided not to include an invite quota for their invitees as they did GMail back in the day.  Hope this clears up that question :: here are a few reasons why I believe Google has appeared to cease sending invitations to the public at large :

1. PSTN termination is expensive – and as much cash as Google has, I can’t imagine it being extremely lucrative at this point with free North American dialing.
2. Google purchased a block of 1,000,000 DID’s (phone numbers) which very well could be their “beta pool”.  I could be wrong but they may keep their testers to a “small” group until they figure out if they should continue (turn a profit from the service).
3. There have been issues with SIP trunking, apparently they dropped it quickly when some clever folks discovered Google was using shockingly weak passwords.  This may be something they want to clear up before inviting more people.

As soon as I heard peoples patience was wearing thin, I decided I would sign up for another account with my other GMail address (seeing as I received my first invite within two days).  It has now been a month with no response – so don’t fret, you are not the only one.  As far as I can tell there doesn’t appear to be any pattern to their invite protocol, I think in the beginning it was really all about timing.

As frustrated as you may be eventually you will get your invite – lets hope you don’t have to wait another two months… Good luck to you all and in the meantime read my first impressions.

It is Friday evening and after a long work week I decided to pick up something nice to sip on.  This is one of my favourites and is extremely affordable, it is called “Cartier Irish Cream” and can be found in Canada at your local Wine Rack.  Like 99.999% of the world’s population I absolutely love Baileys irish cream, unfortunately for us Canadians a 26ox can run upwards of $30 and does not last long at all.  Cartier sells for half the price of Bailleys at $16.50 in Ontario for the same volume, and is believe it or not quite similar in taste.  In my opinion the texture and flavour is superior to O’Darby and it also mixed wonderful in coffee.

According to the Wine Rack website it is classified as a “Cream wine liquor with flavours of almond and mocha.” Here is a snapshot of what I am enjoying this evening.

ENUM is a brilliant solution for querying a contact identifier and returning other contact information.  Imagine looking up a phone number and being able to identify an email address, website, phone number, SIP URI, address, business name etc.  The reason I bring this up is because I have started working on enumplus.org once again and thought I should shed some more light on why it is beneficial for you to sign up.  Our primary objective for enumplus is being able to call standard DID’s as you would find in your every day phone book and route the call over IP without touching your carrier or ITSP (there is huge savings here).

The biggest prioblem with ENUM lookup sources is that there are so many and they are all very incomplete.  The percentage of numbers I call that actually route over IP is pretty much zero (unless I am calling 1-8XX of course).  The beauty of Enumplus is that we give you a module for free which is easy to install and add additional lookup sources on the fly.  You do not need to be an Enumplus subscriber to have access to the module – just upload it to FreePBX and add whichever ENUM lookup sources you subscribe to.

Enough about that, here is how it works.

When you pick up your phone and dial a number, the first thing your Asterisk system does (when using ENUM) is check the database for lookup sources.  It then queries the lookup source DNS server for a NAPTR record using a command that looks like the following :

dig +short 5.5.5.5.5.5.5.1.lookupsource.org NAPTR

Where the 5.5.5.5.5.5.5.1 is the phone number reversed (seperated by periods) and the domain lookup (DNS Server) source at the end.

If the record exists, the DNS server will respond with something that looks like the following :

100 10 “u” “E2U+SIP” !^\\+15555555555$!sip:did@provider.com!” .

The ENUM script then strips the SIP URI from the result and terminates the call over IP.

If the record doesn’t exist – it will query the next source in line – if it runs out of sources the call will be routed as usual over your ITSP or carrier.  NAPTR records can be used to return other values as well.  Take a look over at e164.org – there you will find a Firefox plugin that converts DID’s to domain names as well as email addresses.

So go sign up at http://enumplus.org and test it out.  Feel free to leave comments below.