On Wednesday 25 April 2007 10:04 am, Steve Murphy wrote: > Well, I guess the magic of putting the _1NXXNXXXXXX exten in the local > context wouldn't be useful until you define an "untrusted" context:
I generally build my contexts as small and modular blocks, and then build "grouping" contexts which assemble them into various classes (trusted, untrusted, internal, etc.) > [untrusted] > include => local Pretty much, yes... > And, maybe, it'd be better to define the local this way instead: > > [local] > exten => _NXXNXXXXXX,1,Playback(gojumpinthelake) > exten => _011.,1,Playback(gojumpinthelake) > exten => _NXXXXXX,1,Dial(...) > > > so, sip.conf might have > [lobbyphone] > context = untrusted > > (all you want folks using the phone in the lobby for is dialing local > numbers) Very close. sip.conf is pretty much identical to how I'd do it, but untrusted would look like this: [untrusted] include => nine11 include => local exten => _X.,1,Playback(invalid) which, of course, doesn't work under this system, since _X. will match before anything that is included. I'd have to have this: [untrusted] include => nine11 include => local exten => i,1,System(/usr/local/scripts/detonate_handset ${CID(num)}) > So, now, a single local context can serve both trusted and untrusted > situations. > The gojumpinthelake message will only get played when not overridden by > higher contexts. Yes, but a hell of a lot messier, no? > It's backwards to what you are accustomed to, but still useful. I don't doubt that the system works, I'm just trying to understand the reasonings behind it and suggest better ways of doing things. Having wildcard matches in [local], [longdistance], etc. to handle this seems like a hell of a way to do it. -A. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev