[asterisk-users] FreePBX: using context other than the default context and the generation for the configuration

[SamyGo]

See
Route-Permissions module,
It lets you restrict certain phones/extensions to follow a dial-plan
pattern and dial out to the defined trunk etc meanwhile not breaking any
other functionality or features of FPBX- though you can restrict the
features from this too.

http://www.freepbx.org/support/documentation/howtos/how-to-give-a-particular-extension-different-or-restricted-trunk-access

http://www.freepbx.org/support/documentation/module-documentation/third-party-unsupported-modules/outbound-route-permission

http://mirror.freepbx.org/modules/release/contributed_modules/

OR
Custom Context
http://www.freepbx.org/support/documentation/module-documentation/third-party-unsupported-modules/customcontexts


See w/e fits your requirements. What I suggest suits your need is the
Route-permission module. Though it'll be bit complicated but worth giving a
try.

Regards,
Sammy


On Thu, Jul 12, 2012 at 4:01 AM, Warren Selby <wcselby at selbytech.com> wrote:

> On Wed, Jul 11, 2012 at 4:56 PM, bilal ghayyad <bilmar_gh at yahoo.com>wrote:
>
>> Fine, did you read the question well and understand about what I am
>> asking?
>>
>>
> Perhaps I did not understand what you were asking.  I thought you were
> wanting to do something custom per extension (in the case of my example,
> the "something custom" was control outbound call access to either local
> only or local and long distance, etc.  You can figure out you're own
> "something custom"), but still have all the calls have all the standard
> FreePBX features that you only get when using the [from-internal] context.
>
> In my example, the extensions are in the 2XXX range, and they would either
> have a context of [custom-local-only] or [custom-long-distance], depending
> on what you wanted to allow that extension to dial.
>
> To break down my example:
>
>
>
> [custom-local-only]  --> The name of our custom context.  It could be
> anything you want, as long as it's in square brackets
>
> exten => _281NXXXXXX,1,Verbose(Outbound call from local-only context) -->
> This step is purely informational, it has no bearing on CDRs or anything
> else...it's just a useful step for debugging.  I tend to do this for
> everything, it's the same as some people use the "NoOp()" command to have
> debugging information in their CLI output.
>
>  same => n,Goto(${EXTEN},from-internal,1)  --> This step sends the call to
> the [from-internal] context and handles it exactly as if you weren't using
> any custom call controls.  In my example, however, it will only go there if
> it meets the criteria of matching the pattern (in other words, the call
> would have to be placed to a number that matches the _281NXXXXXX pattern).
> "same => n" is a shorthand way of writing "exten => _281NXXXXXX,n".  It was
> added in around 1.6 I think, I'm not entirely sure.
>
> exten => _2XXX,1,Verbose(Internal extension-to-extension call)  --> Again,
> this is purely an informational step, useful for debugging.  It can be
> skipped or expanded as you see fit, it has no bearing on CDR records or
> anything else, other than CLI output.
>
>  same => n,Goto(${EXTEN},from-internal,1)  --> This does the same as the
> previous example, however it will only go to the [from-internal] context if
> the pattern that was dialed matches _2XXX.  This is assuming you're using
> internal extensions in the range of _2XXX.  You can change this to whatever
> works for you.
>
> [custom-long-distance]  --> another custom context, this time it allows
> long distance NANPA calling as well as local and internal calls
>
> exten => _1NXXNXXXXXX,1,Verbose(Outbound call from local and long-distance
> context)  --> I hope you're seeing the pattern by now.  This is simply a
> useful debugging step, with no bearing on anything else.
>
>  same => n,Goto(${EXTEN},from-internal,1)  --> The call passes into the
> [from-internal context if it matches the pattern of _1NXXNXXXXXX, a typical
> NANPA long distance call.
>
> include => custom-local-only  --> include the local dialing context that
> way we don't have to duplicate any code that we've previously written,
> mostly useful for the internal extension dialing.
>
>
>
> So you can see, the Verbose() statement has no bearing on CDR's what so
> ever.  I wasn't aware that FreePBX used any kind of custom CDR database, I
> assumed it was simply using the asterisk CDR database, where any call
> through the system generates a CDR.  Since someone else had mentioned that
> they did not get any CDR logging or any of the other FreePBX features
> without making the extension have a context of [from-internal], I was
> showing how to do simple things like local and long-distance access control
> in the extensions_custom.conf file, and then sending the call into the
> default [from-internal] context. What I provided was mostly just supposed
> to be an example that you could build off of.  You don't have to use
> Verbose() if you don't want to, that's just something I've grown accustomed
> to doing.
>
> I'm by no means an expert at FreePBX.  If you find that using custom
> contexts are not helping in you situation, perhaps you can expand on what
> the actual issue is that you're experiencing, and we can try to help
> troubleshoot from there.
>
>
> --
> Thanks,
> --Warren Selby, dCAP
> http://www.SelbyTech.com <http://www.selbytech.com>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120712/caa5883a/attachment.htm>