its all going to be customized. TL is definitely not going to sanction alteration of tl-userexten-base without serious consideration on how it will impact everyone already using TL. I would first examine if there is a way to add your feature in a pre-base script such as tl-userexten.

For example, some individual really screwed everyone about a year ago thinking it would be such a hot idea to store the last calerid number for each extension in the ASTDB. Without asking they stuck it into tl-userexten-base and pushed the change through. The net result was that whether you wanted that feature or not you were on the hook for a disk i/o write on _every_single_call_ even if you didnt want that stupid feature.

Because every single TL member relies on tl-userexten-base this script must undergo the most scritiny of all the scripts in the TL library. In the above case It would make _entirely_ more sense to clone tl-userexten, the 4line script not the -base one, and insert a line to do the ASTDB writes. Then the extensions that need that *69 feature could select tl-usercloned as their script which eventually sends it along to tl-userexten-base just like tl-userexten and tl-stdexten does.

Regarding your reference to a 'Local context' I think you are misusing the word context versus technology. chan_local is a technology much like chan_sip. It is dialed Local/exten@context instead of SIP/channel . Stay away from chan_local any and every time you can. You are better off using GoTo(exten,priority,context) than you are doing a Dial(local/exten@context) because local makes a 3 legged call and asterisk remains in the middle of the call instead of handing it off for packet2packet bridging.