Eric "ManxPower" Wieling wrote:
Larry Alkoff wrote:
Eric "ManxPower" Wieling wrote:
Larry Alkoff wrote:
Eric "ManxPower" Wieling wrote:
Larry Alkoff wrote:
Hello Eric.

I don't fully understand your example.

I _think_ you have in extensions.conf:

[incoming]
include => extensions

[extensions]
exten => 667
more exten here

[toll-trunks]
exten => 91NXXNXXXXXX
more exten here

[toll-access]
include => extensions
include => toll-trunks

My understanding of 'include' is it's as if the 'include'
were typed line by line into the context.

Since both extensions and toll-trunks are mixed together in [toll-access], doesn't that give anyone who gains access to extensions in [incoming] also access to toll-trunks? How does anyone on the inside gain access to [toll-access]?

Also I don't understand the 'doubling' of [extensions] by including it
in another context.

I'm probably missing something here. Can you help me understand this better?

No. Any device in the [incoming] context will only have access to anything in the [incoming] and [extensions] context. i.e. it will not have access to any exten => lines that allow dialing out of the system. include => is only "one-way"

I have a feeling that the answer is contained in your words but still don't quite get it.

Let me ask this: How do inside devices get access to [toll-access]? I would like my inside devices to have access to everything unless I specifically deny access.

Contexts are both one of the most important and most difficult concepts to understand in Asterisk.

Calls from inside devices land in the toll-access context in extensions.conf. This is because of the context=toll-access line in that device's section of sip.conf. This context in extensions.conf include =>'s the toll-trunks context. Therefore, the inside device gets access to the toll-trunks context.

I _think_ we are getting somewhere.

You are essentially saying that, in order to have access to [toll-access] I would need a line context=toll-access
in a specific device(s).

In my case, the system is for my house. So I have it setup to ring _all_ phones when a call comes in and would like my wife and I to be able to call _anywhere_. Since we never know which phone will be handy, it's necessary to give full access to all phones, which I think means context=toll-access in sip.conf for all phones.

Doesn't that give access to any outside caller who can break into the system?

Yes, any phone you want to dialout would have a context=toll-access in the device's sip.conf [section]. But that is not a security issue because contexts are really something only used for calls from a device to Asterisk. The context= line of a device is ignored when sending calls to it.

My examples might be overly complex because I took them from my standard context design for production systems in a corporate enviroment where we also have contexts like [exten-access] (devices that can only dial extensions and 911) and [local-access]/[local-trunks] (devices that can only dial extensions, local calls, and 911)

Thanks very much for your definitive statement that [any_context] must relate to a sip.conf context=any_context, either directly or via an include statement. I've kinda verified this by experiment but have not seen this in the documentation.

If it's not a security issue I might as well have all phones with context=default in sip.conf even though voip-info specifically warns against that. Wonder why?

Actually, context=default is what I had before today and nothing has happened _yet_. I'll just have to look for other methods of preventing malefactors from accessing toll calls. I've already blocked (have no access to) 900 calls - my wife and I don't use that <g>

Any final thoughts on my automatic password idea?

Thanks very much for your help.

Larry

--
Larry Alkoff N2LA - Austin TX
Using Thunderbird on Linux
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to