Include's are not complete includes, rather "if nothing matches, look there, then there".
-- Nabeel Jafferali X2 Networks Inc. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Simon P. Ditner Sent: July-22-10 2:45 PM To: [email protected] Subject: Re: [on-asterisk] Tip 'o the day, extending contexts On the subject of includes, the order of your include statements has an unexpected effect on the weighting in which the dialplan within them is considered For example: [master] include => local include => speeddial [local] exten => _NXXXXXX,1,Dial(sip/${ext...@trunk) [speeddial] exten => 5551212,1,Dial(sip/${ext...@trunk) If you do a 'dialplan show 5551...@master', you will likely be surprised to see that the less specific pattern in [local] takes precedence over the more specific pattern in [speeddial]. Anything in [master] however will take precedence over anything in an include statement, regardless of their position. G. I. Joe! On 22 July 2010 11:20, Simon P. Ditner <[email protected]> wrote: > It does warn you, as most people probably don't mean to clobbering > existing extensions, but it doesn't stop you. I wouldn't use the > feature either, as if you are clobbering exten => ...,n,... rules, the > behavior is unpredictable -- but I thought I'd note that it was > possible. > > Do you have an example of what you mean by wildcard matching? I don't > see how the behavior would be different. > > On 22 July 2010 11:10, John Lange <[email protected]> wrote: >> Doesn't it give an error/warning about duplicate extensions when you do >> that? >> >> I've been doing something similar but without the duplicate context >> definitions like so: >> >> extensions.conf: >> [default] >> exten => 1111,1,Dial(sip/abc123) >> #include extensions-extra.conf >> >> extensions-extra.conf: >> exten => 2222,1,Dial(sip/def456) >> >> --- >> And I'm curious how the matching would work if, in your example the >> extensions had wildcard matching? >> >> -- >> John Lange >> http://www.johnlange.ca >> >> >> On Thu, 2010-07-22 at 10:54 -0400, Simon P. Ditner wrote: >>> This has probably been in Asterisk for quite awhile, but I hadn't seen >>> it documented anywhere and I thought it was pretty handy: >>> >>> Contexts are cumulative, and can override existing values: >>> >>> extensions.conf: >>> #include extensions-extra.conf >>> [default] >>> exten => 1111,1,Dial(sip/abc123) >>> >>> + >>> >>> extensions-extra.conf: >>> [default] >>> exten => 1111,1,Goto(2222,1) >>> exten => 2222,1,Dial(sip/def456) >>> >>> = >>> >>> [default] >>> exten => 1111,1,Goto(2222,1) >>> exten => 2222,1,Dial(sip/def456) >>> >>> verify: >>> cli> dialplan show default >>> cli> dialplan show 1...@default >>> >>> When replacing steps (1111), it will overwrite existing ones, leaving >>> any extras in place. So that if you only declared 1-3 in the -extra >>> file, steps 4-6 would still exist. >>> >>> The behavior is slightly different for the globals section, you need >>> to add a (+) to the context >>> >>> extensions.conf: >>> [global] >>> A=B >>> #include extensions-extra.conf >>> >>> + >>> >>> extensions-extra.conf: >>> [global](+) >>> B=C >>> >>> = >>> >>> [global] >>> A=B >>> B=C >>> >>> verify: >>> cli> core show globals >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
