Currently this is an unofficial module that must be manually installed. It can be downloaded from:

choosing the latest version of the customcontext module. The easiest way to install it is to dowload it to your desktop and then choose "Upload Modules" in FreePBX Module Admin and install the module.

Then in FreePBX, click on the Tools tab, Module Admin, and Custom Contexts, select Install, click on Process, and then the red bar to complete installation.

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.

What This Module Is NOT Intended For

  • This module is not intended to provide an alternative way to access code that is found in, or might normally be placed in extensions_custom.conf. You probably want the DialplanInjection module if that is what you are trying to achieve.
  • It's also not intended to give you simplified access to existing features, applications, or destinations (e.g. from an IVR) - you probably want to use Misc. Applications and/or Misc. Destinations (or possibly a Custom Extension) for that.

Known Incompatibility

Please be aware that if you you have installed both this module and HUDlite on the same system, HUDlite will allow users to bypass any restrictions placed upon them by this module. Therefore, restricted users should not be given access to HUDlite. Also, a savy user can bypass the system. As soon as they transfer a call, the current dialplan puts them in a new context which is effectively from-internal taking away any restrictions.


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.

As an added bonus, I added a select list to the devices/extensions page to allow you to easily select any of your custom contexts to place the device in.

Version 0.1.1 - Now has optional Time Groups which allows you to name a set of times to enable the user to not only deny or allow access to certain dialplan contexts, but to control access to each context by time, date or day also.

Version 0.1.2 - Changes
Bugfixes- deleted routes, etc. now are removed.
Context tests for spaces and illegal chars.
Moved admin to tools to reduce confusion.
Added option to allow entire internal dialplan. (Useful for time limit on everything)
Made description for outbound-allroutes clearer that allowing overrides to allow all routes.

Version 0.1.3 - Made it obvious when allowing one include may allow another entire context.

Version 0.2.0 - Added priority feature to allow the user to control in what order the allowed contexts are included.

Version 0.2.1 - Added Duplicate Context option to easily copy an entire set of rules.

Version 0.2.2 - bugfix

Version 0.3.0 - New Features:
Allow or Deny based on pattern matching.
Failover Destination (one for regular extension, one for failed feature codes)
Adjusted Gui, Duplicate context, now duplicates the description too.

Version 0.3.1 - New Features:
Now prompts on delete. After duplicate you are editing new context.
It is now possible to rename contexts.

Version 0.3.2 - New Features:
Optional PIN to protect failover destination.
Contexts can now be used as destinations. An IVR menu, Time Condition, etc. can now send a caller into a custom context.

Version 0.3.3 -
New Feature: Added Set All option to quickly allow/deny all.
Fixed bug which caused routes to be denied after rename/sort/or delete other route.

Version 0.3.4 -
Fix for compatibility issues with FreePBX version

Installation of Beta version

Download the latest Beta version using the instructions in the first paragraph.

If you did not use the instructions for getting and installing the module using wget, then expand the .tgz file into the /var/www/html/admin/modules directory - it will create a new directory called customcontexts. Make sure the group and owner of that directory are asterisk and that the permissions match that of the other module subdirectories.

Browse to FreePBX, Tools | Module Administration. You should see an entry for Custom Contexts. Click on it, click install, then click process and the red bar as usual.

Usage Instructions

Most users will not need to do anything in the Custom Contexts Admin section (now found under the Tools tab) - that is for advanced users. When you "add" or "remove" contexts from the Admin, you are not really adding or removing anything, you are just telling the module where to find all of the includes to list. By default there are three includes which should be sufficient for most users: from-internal, from-internal-additional, and outbound-allroutes. So, skip the Custom Contexts Admin section until you feel comfortable making changes there.

The first thing that you will want to create is time groups, if you plan to use those. The reason for doing this first is so that they will become available in the drop down selections when you create your custom contexts. For each group you create, you can decide which times it should be available. You can define multiple times within one named group, and then each named group then becomes available along with allow/deny for each choice under a custom context (this will become clearer further down), so you can allow, deny, or choose your time group to allow only at specific times/dates/days.

One thing to bear in mind when creating time groups is that this module will not forcibly end calls in progress. So if, for example, you have "free" calling on a particular route from 9:00 PM to 7:00 AM, you probably don't want to set the end time right at 7:00 AM, because then someone could make a call at 6:59 and talk for several minutes into the non-free period.

Now, to actually create a Custom Context, you go to the Custom Contexts page, and add a context - note that the context name may NOT contain spaces. Then add a description (spaces are okay here) and submit.

We'll talk about Dial Rules later - in many cases you will want to leave the Dial Rules blank.

Once the context is created, you can edit it to allow or disallow the features and routes you want a particular extension (or group of extensions) to have access to. There is a "Set All" option to set all the features and routes to Allow or Deny - this is useful when you want to start out with all of the dropdowns in one state, so that you only need to change the exceptions. Then choose "Allow" or "Deny" for each application or route - for example, you may wish to allow all, except for the items you specifically wish to restrict (for example, you probably want to restrict ChanSpy and ZapBarge!). If you have created any time conditions, it will also be possible to select those, to allow a feature or route to be accessed only during certain times. If you have any Dial Rules, you can choose to "Allow Rules" (allow the feature or route only if a Dial Rules pattern is matched) or "Deny Rules" (deny the feature or route only if a Dial Rules pattern is matched).

Certain items are in bold red letters, such as "ENTIRE Basic Internal Dialplan" and "ALL OUTBOUND ROUTES." If you allow ALL OUTBOUND ROUTES, it will override the individual route selections in the following section. So if you want users of this context to have access to all outbound routes, you can just allow outbound-allroutes and ignore the individual route sections (leave them all set to "deny"). But if you want to select routes individually, then make sure that outbound-allroutes is set to "Deny". Of course, you could also use non-overlapping time conditions for outbound-allroutes and individual routes.

If you allow "ENTIRE Basic Internal Dialplan", then it overrides every other selection on the page. You would normally only use this with a time rule, to allow your unaltered dialplan to be used for a portion of the day. Allowing the "ENTIRE Basic Internal Dialplan" without using a time rule is usually pointless. If you want control over individual items, deny "ENTIRE Basic Internal Dialplan", and allow only what you want.

Associated with each item a "Priority" dropdown. All priorities are set to 50 by default (so you can easily make any item higher or lower in priority). The best use of these is in the Outbound Routes section - you WILL want to make sure that any Outbound Routes that you allow are ordered by priority, otherwise your outbound calls may not be routed as you expect. Normally you will want to mirror the priority of the existing routes - the easiest way to do that is add 50 to the number at the start of the route, so for example if you have a route called "outrt-001-Emergency" you could add 50 to the "001" and use 51 as the priority. But note that you do not have to mirror the default priority of routes, which could become useful in certain situations.

For example, let's suppose you have an emergency route that goes to a an emergency answering point in your local area, but you also have another emergency route that goes to an emergency answering point in a community where you have a remote office. You could create two emergency routes going to the two different answering points and let the one going to the local point be higher in priority normally, but create a custom context for your remote extensions and in that custom context, make their community's emergency answering point higher in priority.

One more note about priorities - you can hide the display of the priority dropdowns by clicking on "Hide Sort Option" at the top of any custom context page. BUT - if you click on the "Submit" button while you have the priorities hidden, all the priorities on that page will be reset to the default (50)! So use this option with care!!

Note: This option is no longer available as its purpose was to clean up the page when priorities were listed below each context. Now that the display was fixed, the "hide priorities" option was removed.

At the bottom of the page, you can select a Failover Destination and a Feature Code Failover Destination. The Failover Destination is used when the called number does not start with a * and does not match on any route, while the Feature Code Failover Destination is used when the called number begins with a * and does not match any feature code. Be careful here, because it's possible to send a caller to a destination that gives them access to destinations that you don't intend for them to be able to access. Either or both of the Failover Destinations can be PIN protected, that is, you can enter a numeric PIN to require authentication before continuing to the destination.

Regarding Dial Rules, these can be used when you want to further allow or restrict access based on the number dialed. For example, you could give an internal caller access to a particular route only if 911 was called, or if a local number was called, while restricting their ability to place other calls on the same route. It's also possible to use the | character to strip off initial digits. For example, if you had a dial plan that included something like 90210|1NXXNXXXXXX you could set an outbound route to "Allow Rules" and it would generally restrict access to that route, except for those callers that know that they must dial 90210 prior to the 1+area code+number.

Sometimes you will want to create a new custom context that is very similar to an existing custom context you have already created - perhaps you only want to modify one or two items in the new context. The easiest way to do that is to go into the existing context, then click on "Duplicate Context ..." at the top of the page. This will create a duplicate of the existing context that you can edit as you

Finally, you need to go to your Extensions page and select each extension for which you wish to use a custom context. On each individual extension page, you should now see a dropdown to allow you to select a custom context. This drop-down is simply a convenient way to fill in the correct context in the "context" textbox. When you click on a custom context, it replaces whatever is currently in the "context" textbox with your new selection - if you choose "Default", it resets the extension back to the default "from-internal" context. Don't forget to click "Submit", and then click the red bar when you are all finished making changes.

NOTE that if you disable or uninstall the Custom Contexts module, you MUST reset all the extensions back to the default "from-internal" context. If you delete a time group, anyone who had that time limitation becomes "Allow" with no time restrictions. If you add a new outbound route, by default that route is set as "Deny" in the Custom Contexts, so you should go into each context and set it to "Allow" (or use a time condition) where appropriate.

One more caveat. After you add an outbound route, it is not available until you reload.


olivier1010's picture

I hope to see this module integrated inside the freepbx core as soon as possible. It is a very important function to use Freepbx in a professional world.

About 30 % of the professional freepbx users need custom contexts in their setup.

PaulByte's picture

We have a client that wants to keep Sales from dialing accounting. Sales extensions are 70xx and Accounting are 71xx extensions, can we utilize custom context to do this?

Trying to keep one client calling another

cell's picture

Any news about integrating this module in core of freepbx? Would be possible to integrate this module in freepbx 2.3.x or it will be iavailable in 2.4?

cell's picture

Where is a topic in the forum where is shown what changes have to do to make CustomContexts wrokable in FreePBX 2.3.x:

jl670's picture

'deviceanduser' Devices and Users will be administered seperately, and Users will be able to "login" to devices.

The context is only shown under devices, it would be very helpful if the user also has a context.

this way one can setup the device to only call internal and as soon as someone has to call external they must login using the *11 feature code.
this way one's extension and billing can follow the user.

Please include this

oligau2000's picture

I just finished updating my test vm here with trixbox2.6/freepbx2.4 and I installed
It seems that it works, I managed to configure two different outbound routes and create two different contexts to make one extension call using one outbound route and other extension call with a other outbound route.
I'm testing this before going to a new client installation where three companies share the same pbx. All the three companies are going out using the same T1 line on a sangoma card, but they need to display a distinct Outbound Caller ID so the telephone company can charge them the long distance fees appropriately.

dayres's picture

I'm doing the same thing for the same reason, but I can't seem to get it to work correctly. Depending on the settings, I either get no outbound trunk or all outbound trunks.

Update: I figured it out. I had set a Dial Rule on the trunk with a prefix before I implemented the custom contexts and forgot to remove it.

alek's picture

I have some problems, I've creare a custom context that use trunk 503 and deny trunk 504. I've added this custom context to an extension. But still this extension can use the 504 trunk.

Can you tell me why?

alek's picture

Sorry problem solved I've forgot some deny on the way

razametal's picture


How can I deny outbout to all routes, but permit call to local extensions?

Only the good die young

wiseoldowl's picture

razametal, why even have any outbound routes if all you want is calls between extensions? Sorry, but I think you need to better explain what you are trying to do here, otherwise my answer would be "delete all your outbound routes" (ROUTES not TRUNKS, you may still need trunks to receive incoming calls).

igy's picture

I think he meant that he wanted that behaviour for certain extensions only.
I.e extension 1000 is only allowed to make internal calls, no access to trunks.

The answer is to put those extensions in a custom context that doesn't have access to the outbound routes

m.p.'s picture


I'm using CustomContext 3.4 with FreePBX I have defined to custom contexts to bind extensions to specific outbound routes.

For the first custom context I set

'ALL OUTBOUND ROUTES' to 'Deny' and priority '50',
'Outbound route 1' to 'Allow' and priority '51' and
'Outbound route 2' to 'Deny' and priority '52'.

Extension in this context can call internal and external numbers (on the correct outbound route 'Outbound route 1') without any problems.

For the second custom context I set

'ALL OUTBOUND ROUTES' to 'Deny' and priority '50',
'Outbound route 1' to 'Deny' and priority '52' and
'Outbound route 2' to 'Allow' and priority '51'.

After clicking 'Submit' the settings for 'Outbound Route 1' have changed to 'Deny' and priority '51'. If I apply this configuration, extensions in this context can call internal numbers but outbound calls will take place on 'Outbound route 1' instead on 'Outbound route 2'.

If I change the settings for

'Outbound route 1' to 'Deny' and priority '51' and
'Outbound route 2' to 'Allow' and priority '50'

outbound calls take place on 'Outbound route 2' but if I call an internal number my Asterisks trys to call it on this outbound route.

Do you have any idea why the CustomContexts modules messes up the settings of the second extension? I will give you further information if you need.


jpe_'s picture

Can Custom Contest be enhaced use the Description of the Misc App instead of app-miscapp-x?

pyranetuk's picture

I am in the same position as tadpole, we have setup our box to use Users & Devices. I would like to setup a seperate context for Devices so that phones that aren't logged on can only make internal calls then when a user logs on they have their own set of rules of that particular user. Is there any way of me doing this now?

Tadpole, how did you get on with this?



nkosinebantu's picture

....DIAL RULES box? I've got like a Hundred numbers, and want to be able to label them ..... this is a WHITELIST that i've created using Custom Contexts.

igy's picture

Does anyone know if this works with Freepbx 2.6?

p_lindheimer's picture

I don't recall any changes to 2.6 that would prevent it from working, but if you find it does not work then let us know so that we can take it out of the Extended Repository.

djpinoy's picture

how can i assign group of extensions that can only dial a group of extension and all the groups have outbound routes?

Thank you

nkosinebantu's picture

I find that I can only put 104 numbers into the Dial Rules box in my custom context?
am I using this module incorrectly?
The customer just wants to control what numbers can be dialed I just put the numbers in the DIAL RULES box as a "whitelist"......I'm limited to entering only 104 there a way to make this 1,000 numbers? or should I configure these numbers elsewhere in the Trixbox 2.6.1 system?

wiseoldowl's picture

If you were using FreePBX rather than Trixbox, this is what my answer would be:

Yeah, that's probably not how that module was intended to be used.

Dumb question: Why not just list each whitelisted number explicitly in the outbound route dial patterns? I don't know if there's a limit there, but if there is you might be able to find patterns in some groups of numbers that would let you reduce the actual number of entries needed.

Then just don't provide any outbound route for numbers/patterns you don't want to enable.

But since you are using Trixbox, which has a "forked" version of FreePBX, I have no idea what might or might not work there. It may even be that Custom Contexts will never work right with that forked version - we have no way of knowing. Why not switch to a distribution (such as AsteriskNOW, Elastix, or PBX in a Flash - those are in alphabetical order, by the way, not an order indicating preference) that contains true FreePBX?

nkosinebantu's picture

1st: I will try your suggestion....."Why not just list each whitelisted number explicitly in the outbound route dial patterns? I don't know if there's a limit there, but if there is you might be able to find patterns in some groups of numbers that would let you reduce the actual number of entries needed."

2nd: "Why not switch to a distribution (such as AsteriskNOW, Elastix, or PBX in a Flash - those are in alphabetical order, by the way, not an order indicating preference) that contains true FreePBX?" particular reason, other than I was handed this Trixbox 2.6.1 and was told "use this at this site, learn Trixbox"... Smile If one of these others is a better system, then I will gladly try them......

so if Trixbox is not as good as these others you've mentioned, why is it even on the market? what's the rub?

wiseoldowl's picture

With regard to your last question, if we're really going to have this discussion it should be in the forum, and not in the comments section for a particular module. But to give a quick response, the question really isn't why it's on the market, but rather why they decided to fork FreePBX and go their own way. Suffice it to say that the relations between the FreePBX folks and the "lime green" folks haven't always been as amicable as they might be. The problem now is that because the version of FreePBX in their distribution is forked, you can't easily upgrade it to the latest version of FreePBX, and you have no guarantee that it will work in the same manner as "real" FreePBX, nor whether any particular module designed for FreePBX will work. There's a lot of back story here that I'm just not going to go into in a module comment area (I don't know all of it anyway) but I just suspect you'd find it easier going with one of those other distributions that includes genuine FreePBX (as the developers intended it).

nkosinebantu's picture

...well, since I've done so much work at this current site, I'll see if I can't deal with this module limitation by trying your suggestion:
just list each whitelisted number explicitly in the outbound route dial patterns? I don't know if there's a limit there, but if there is you might be able to find patterns in some groups of numbers that would let you reduce the actual number of entries needed.
Then just don't provide any outbound route for numbers/patterns you don't want to enable.

The customer wants a slew of specific phones to only be able to dial outbound a certain list of numbers, so hopefully I can easily assign the outbound dial patterns to specific ext's. I will be on site tomorrow, so I'll try it then.

sorry to get off the module subject matter into something else. But I will try true FreePBX on the next install.

nkosinebantu's picture

I am in the middle of testing MASS number's in the dial plan.....but then my question is based on your earlier comment (that I didn't not get into):
If you were using FreePBX rather than Trixbox, this is what my answer would be:
Yeah, that's probably not how that module was intended to be used.

But then, what was the intended use of this module? I'm finding NO WHERE else on the interweb Smile where someone else is running into this same 104 number limitation as myself....which seems odd....probably because other people use it differently. But then why the "dial rules" box?

ok....nevermind....I see, from the top of this page, that the DIAL RULES box is intended more for access to "outbound routes" than to specific numbers. Bummer Smile ok, well, I'll start working with the dial plan now Smile

sorry to take so long to comment......this is Africa Smile

nkosinebantu's picture

"Why not just list each whitelisted number explicitly in the outbound route dial patterns?"

I did this....and entered 2,767 numbers....and it I didn't find a limitation on numbers...I COULD have widdled the list down a bit, but I first needed to get the numbers entered. SO thank you for the advice, it worked. Smile

Toxa's picture

Why field context disappearing when I install customcontext module ? I realy need it! Please turn it back!

Or tell me how with customcontext module I can set conext for examle to use a2billing context ?

p_lindheimer's picture

If you need to set your context manually then use the custom context module.

Otherwise, uninstall the custom context module.

The purpose of that module is to have it determine this field and what should be setup for that context.

Toxa's picture

How I can add my own context into custom context module? I can't find how I can add or include my own context into custom context. In early version that was simple, beacause field context doesn't disappeard in extension view. And I could choose custom context or my own context, like a2billing. I really need it, beacause part of my users using custom context with limiting access to routes and part using context a2billing. How I can use this things together? Why need deleting field context?

p_lindheimer's picture

This has not changed from the previous version.

In the old version, the text box was there but as soon as you press submit, it was overwritten with the value of he custom-context select box (or from-internal as the default).

The new version has not changed that at all, it simply hides the text box since before it was very mis-leading as it would let you type something in there but then change it on you anyhow.

If you have a look at the code you will see this has not changed at all other than hiding the mis-leading text box.

Therefore, if you use custom-context, you need to define you desired context, otherwise, uninstall custom-context and you will get your text box back which will allow you to edit it freeform.

Toxa's picture

Thanks fo that, I comented "hiding field" Smile And that what I need.

Thank you very much!

infomediador's picture


I am having trouble understanding how to set up time based outbound routes. What I want to do is allow calls to mobile numbers on a weekend (my telco has a plan which gives me 500 minutes of free calls to mobiles on a weekend).

My first thought was to set up 2 time groups (weekday and weekend) but then I run into problems getting my head around the contexts. Do I set up 2 contexts for weekends and weekdays with their corresponding dialplans? (In which case my outbound route should allow all calls and the contexts will use their own dialplans) and how do I set up the extensions so that they use the contexts based on day of week? (in this case all of the extensions are treated equally, this is residential installation, not an office)

Any ideas would be appreciated.



p_lindheimer's picture

FreePBX 2.8 supports time based outbound routes, there is no need to use Custom Contexts if that is what you are trying to do, just upgrade to 2.8 if not already there.

hhgoth's picture

Hi all,

I'm having problems using the the directed-call-pickup feature if a user is in a custom context group. Calls from outside can be picked up without problems but if a call comes from a member of a different context or initiated by the asterisk manger , we use manager for click-to-dial, it can't be picked up. Has anyone a idea how to solve this ?

p_lindheimer's picture

that's another short-coming of the custom context module.

FreePBX has expectation's as to what context's it will try to pickup based on the standard FreePBX dialplan.

Custom-Contexts introduces new contexts that the pickup dialplan generated does not know about. You would have to add custom dialplan to handle that.

You are welcome to file a feature request for future consideration since the same issue would exist even if other context's were introduced in an extension's configuration with or without this module. (The ticket helps keep site of this when working on parts of the code).

Csabi's picture


I'm using the spa962+932.

The extensions are in the custom context. All options set to allow in the context.

On the SAP932 the all led are orange all subscription is failed, but I can able to use the buttons on the 932 console the extensions are on-line and working.

When I take out from the custom context all is green subscription OK.

Have You any idea what can I set ?

Thank You for helping.
Rgds Csaba

bioffa's picture

<p>I have the same problem , did you resolved it ? Thank's</p>

mdiorio's picture

This module does almost all of what I want. Is there a way to disable in-call detection of feature codes such as *2 for in-call attended transfer?

One of the IVRs we dial into requires entering insurance numbers with letters by pressing *, then the corresponding number key. So to enter an A, the user would dial *2. Which Asterisk is grabbing for attended transfer.


bpm's picture

Some modules/functions are missing from custom-contexts such as ext-paging and hints don't rule match against ext-local properly.

turalo's picture

I have been using custom context already 2 years, and I have to say I'm very thankfull to people who made this possible.
But from the first day that I use this one, I have been having a problem, the problem is the call forward option.
Let's say I have 5 users on my pbx. and I want that each user uses he's own trunk. So I'm using this custom context to do this. I make a context for each user, and in the extension settings I choose the right context.
When users call out, everything goes fine, the custom context selects the given outbound route, and the selected trunk is used. But when extension hase a callforward on. on the phone or via *72 option. then the custom context does not work, the forwarded call uses the first route in the list.
So if let's say we have 5 routes, each route to 1 specific trunk.
if I make a normal call from user b, it goes to Route b, and selects Trunk b.
but if I'm away from office, I turn on call forward on my voip phone, lets'say to my mobile number. then if somebody calls me the call is forwarded fine, but then it goes true the first available route/trunk and that is A. So the A user's Route/Trunk pays the bill Smile
Can anybody tell me how to solve this ?
I would be very thankful.
thanks in advance.

Computers were made to solve problems that did not exist before them.

pakaruoklis's picture

Does it is possible somehow to fix that blind call transfer restriction problem on trixbox 2.6?
I need to restrict to transfer calls from one extension to another. Maybe there is people who can update custom context module call transfer function, we can pay for that.

dr.x's picture

hi ,
i have a dial rule like that

30 | 50 | 100 | 102

i want to allow this dial rule and want to deny anything not included in the dial rule ,
i mean that i have an extention , and want that extention to allow it only for dialing either 30 or 50 or 100 or 102 ,
how should i do it ????

should i put it in the dial rules in custom context module ???


emmet11's picture

Hi friends, i'm using custom-context module long time ago and i have ecountered a bug when you want to deny bad-number option to get compatibility with early dial features (grandstream for example) always are added to extensions_aditional.conf. I think the best way is to fix in new version, because if anybody fix it with this instructions and then update module all changes will gone and you will have problems with your custom-contexts and early dial.

If you want to fix that you need to edit manually your extensions_aditional.cnf file and put ; before line in all your context:

;include => yourcontext_bad-number
:include => bad-number

Then you need to edit /var/www/html/admin/modules/customcontexts/ and remove or comment this lines:


eyexer0's picture

Like others with the module I am having issues with Custom Context and Ext-paging. Works fine on internal but not with custom context, the options to enable it are not in the custom context editor. Does anyone know how to enable it manually I tried adding include => ext-paging and include => app-paging to extensions_additional.conf under my [custom_context] but this does not fix it. any ideas?

networks's picture

Hi Everyone... I'm new to freePBX and asterisk but have been actively experimenting for a little while now...
I'm a little puzzled about how to separate tenants sharing one PBX using custom contexts.
I currently have only two extensions (101 and 102) and i've created two new contexts, and assigned each extension to it's own context. However both extensions are still able to dial one another...
What is the setting that I am missing here?
I have both "ENTIRE Basic Internal Dialplan" and "ALL OUTBOUND ROUTES" set to deny (i don't have any trunks setup at the moment anyways...
Can someone help me understand what i'm doing wrong?

Also, where do I setup time groups?

thank you in advance for any help!

soarertt's picture

That's because custom contexts is not a tenanting module. There are no tenant modules for freepbx/trixbox, the software is not designed to tenant and never will be. Ever. It's a module to allow or disallow outbound routes and or feature codes per extension. Example, extension 1-10 can call international, but 11-20 can not. You create the outbound routes that allow all calls, and one that only allows local calls. You then make a custom contexts like example called "local only" and you assign that context to extensions 11-20. It can also be used if you have different SIP trunk providers you can assign extensions to dial out on the ones you pick. You can also create time schedules so for example... you allow international calling 8am-5pm M/F and on the off hours you do not.

If you wish to multi-tenant you will need to look into solutions like fusionpbx or thirdlane. Fusion is kinda new to the scene and Thirdlane is very tried trued and loved. If your end goal is to multi-tenant resale pretend that freebpx/trixbox/elastix/etc does not exist. Personally I'd go with Thirdlane as it was fully developed to multi-tenant in a hosted solution with very good tech support and 3rd party app support.

networks's picture

Thanks for the explanation... i checked out your recommendations and even tied playing around with fusionPBX today, but it seemed buggy to say the least, and seriously lacks support and how-to's especially as compared to freePBX.
Thirdlane kind of defeats the purpose of finding an inexpensive solution... I emailed them today for pricing and have not heard back as of yet, but I imagine the numbers are going to be somewhat embarrassing!
Also, I read somewhere that the freePBX distro owns the asterisk files it uses, and is not designed to have someone manually edit them, as can be done in a regular version of asterisk, whereby you can make use of contexts to actually create tenancy... is that right?
Thanks again!

SkykingOH's picture

I can tell you (being in the hosted PBX business for almost 5 years and the ISP business for 17) that a free multi-tennant PBX does not exist. FreePBX has hooks in every context for Asterisk extensions but it is not going to help you create isolated DP's. You might as well start from scratch.

We solved the issue by using HP Bladecenter stuff. I can get 20 PBX's in 3U.

Virtualization is finally an option and I should easily be able to reach 30 instances per U not counting the SAN space.

Out of curiosity why is Thirdlane emberrasing?

To be a hosted provider you need many things in addition to a PBX. You need to have some type of front end SIP proxy to distribute DID to each of your hosted systems (wholesale providers will require a reinvite on every call to get any kind of real wholesale rate).

If your subscribers are going to be behind NAT then a Session Border Controller comes in real handy.

Of course a multi-homed IP network is a must.

You also need to have an CALEA solution ready to articulate to law enforcement. If you are a telecom and don't respond to a lawful intercept order your fines can hit $25,000 a day.

networks's picture

Thirdlane got back to me with some pricing shortly thereafter... I was expecting some inflated pricing per extension... I am surprised that their pricing is reasonable, but not for me at the moment, as I am only dabbling in offering VOIP service to some of my customers at this point.
I am an MSP looking to extend my offering, and am experimenting with Asterisk as a solution. I think Asterisk is definitely the right choice for this, but need to get training and real world experience before I can make it an offering, which is what I am attempting to do.
I have abandoned any distro's at this point and have gone back to source, so that I can learn and manipulate files directly, not only to leverage the full power of Asterisk, but also to become familiar with inner workings, as opposed to someone else's distro. This would not serve me well should something go wrong. I know I can pay for support should it come down to it.
Thanks for the 10,000 ft overview of required components as a hosted VOIP provider... I will surely keep them in mind as I progress!
I know this thread is way off context (no pun intended) at this point, but if you have any other suggestions for me in terms of learning and gaining experience with the goal of becoming a VOIP provider, please do let me know. One path I will surely take once i've gotten my feet sufficiently wet is the advanced instructor-led training offered by Digium.

soarertt's picture

Keep in mind that if you don't plan on being that big, you can skip a bunch of those steps and just get your trunking from one of the many fine providers that handles all that. Sure it's more expensive per minute compared to wholesale minutes and doing EVERYTHING yourself, but much of that nightmare is eliminated.

I'm also a small MSP that offers VOIP to business customers that want it and currently I have 500 seats on one trixbox. Sure, it's not multi-tenanted but to date in 3 years only 1 customer found out. We just threw together some old hardware laying around and gave em their own server onsite. Our trunking provider gives us the CDR's per DID in nice formats so not worried about that. That provider also handles our failover, if the main server can not be reached, it sends all DID's to a second one that's registered. Aastra phones do the same in their config file. I use custom contexts to allow customers international or not (and shut off outbound if they didn't pay), and restrict the countries with our provider. I would say that 500 is probably the limit per server just due to complexity and management cause it's all one big mess. It's not perfect, but our customers have never seen 1 minute of downtime and if you don't know how asterisk and linux works you better learn!!! The GUI is useless. Our trunking is through No SBC. Two servers are in colos with external IP's. I backup one to the other. Zero hack issues. Passwords for the users are the phone's mac address or better. All admin web pages are htaccess limited to the static IP of my office (along with any telnet kind of access). Firewall is the built in iptables and any kind of wannabe sip hack attempts are block by fail2ban within 1 wrong try forever. In over a year I have not had ONE single person get through.... they used to try HARDCORE in China and India when the server first came online. Now? Nothing. Maybe 1 try a month from wireless in Canada.

Oh and words of wisdom. Don't allow outside access to voicemail. As in, let them dial into it from the outside world. Just sayin....