Re: [asterisk-dev] extensions.conf included contexts priorities
On Tuesday 24 April 2007 4:38 pm, Steve Murphy wrote: You only need one such 'catchall' in the include hierarchy. They will all be searched. The first matching exact-match or pattern match will take the prize. That's my point, exactly. If I want a different catchall action in a particular context, it needs to be separated from that context and included, or it will never get used. As far as overriding goes, I'd guess you put your most specific stuff in the highest-level context, and include more general sorts of stuff. Sort of inside-out, but still very workable...? Yeah, I dunno... I'm kind of aggravated with this nonintuitive stuff and am trying to help get the system to a path of least surprise kind of operation. The it's always been that way type of arguments against change have never had much pull with me. We all drove horse-drawn carriages before the motorcar, so why design the motorcar? It's always been done that way! ... or something like that. Cue the I get 12 rods to the hogshead and that's the way I likes it and the old welshmen competition about who had it harder. :-) Back in my day, we had to dial with our fingers and hope that nobody else was using the party line! Party line? Heaven! When I was a youngster we didn't have a telephone, all we could do were send smoke signals, and by gum we liked it, too! Smoke signals? We dinna even have FIRE! -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
Kernic panic: [asterisk-dev] Re: qwell: branch 1.2 r2434 - /branches/1.2/
I agree with Tony! This also screws up the good 1.4 branch. These changes look like trunk stuff at best! This adds a kfree in zaptel-base.c, that is always called, and I think that might be the problem? Anyway it clearly was not tested before being pushed as it always causes a kernel panic. I was going to open a bug, but I did not have time last night... but there is already one open now: 9591 Is there a bug status higher than crash?...like total system failure? Quoting Tony Mountifield [EMAIL PROTECTED]: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Author: qwell Date: Tue Apr 24 13:33:29 2007 New Revision: 2434 URL: http://svn.digium.com/view/zaptel?view=revrev=2434 Log: Backport pre-echocan debugging for ztmonitor Added: branches/1.2/jpah.h (with props) Modified: branches/1.2/zaptel-base.c branches/1.2/zaptel.h branches/1.2/zconfig.h branches/1.2/ztmonitor.c Why is this NEW functionality being backported to the STABLE 1.2 branch? And then being tagged for release so quickly? I tried this new 1.2 from SVN last night, and it gives me a kernel panic when hanging up a call (see below). This is using a TE405P with trunk 1 looped back to trunk 3. Not sure why EC stuff is being called, as I have EC disabled. Also not sure why it was doing a ZT_SETCONF when I wasn't using conferencing (the call was just an IAX call into the box, routed out through Zap and back in through Zap, into MusicOnHold). I haven't had time to investigate it fully yet, so can't file a proper bug yet, but if it IS to be in 1.2, it should be checked out more thoroughly before being released. Cheers Tony Unable to handle kernel NULL pointer dereference at virtual address 00b4 printing eip: d09e3c88 *pde = 0a056067 Oops: [#1] Modules linked in: parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc wct4xxp(U) zaptel(U) crc_cc itt dm_mirror dm_mod button battery ac r8169 e100 mii ext3 jbd CPU:0 EIP:0060:[d09e3c88]Not tainted VLI EFLAGS: 00010082 (2.6.9-42.0.2.EL) EIP is at zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel] eax: ebx: 0001 ecx: ffea edx: esi: ce0c0410 edi: ebp: ce0c0410 esp: ca411df0 ds: 007b es: 007b ss: 0068 Process asterisk (pid: 5958, threadinfo=ca411000 task=c9dcacd0) Stack: cf00e9b8 c1220514 cb74e005 d662d853 0009 cf80dc00 ca411e2c ca411000 c01299d0 3b9aca00 462e6ecb 10bbb3d8 01ff cc1eacc0 cbcde2c4 c014d59d 0153bfd5 ca411f34 005b 0001 Call Trace: [c01299d0] current_fs_time+0x44/0x4c [c014d59d] __generic_file_aio_write_nolock+0x33d/0x36b [c014d604] generic_file_aio_write_nolock+0x39/0x7f [c014d7f3] generic_file_aio_write+0x77/0xcd [d09030af] ext3_file_write+0x19/0x8a [ext3] [c016c2e9] do_sync_write+0x97/0xc9 [c0121853] autoremove_wake_function+0x0/0x2d [c01771fc] sys_stat64+0x1e/0x23 [d09e575b] zt_ioctl+0xc1/0xc7 [zaptel] [c0180401] sys_ioctl+0x297/0x336 [c016c4b9] sys_write+0x5a/0x62 [c0318e57] syscall_call+0x7/0xb [c031007b] build_polexpire+0x81/0xe0 Code: 8b 44 24 74 77 1e 8b 1c 85 a0 ae a0 d0 ba d0 00 00 00 a1 84 ce 36 c0 e8 35 04 77 ef 89 83 b4 0 0 00 00 eb 27 8b 04 85 a0 ae a0 d0 8b 80 b4 00 00 00 e8 e7 07 77 ef 8b 44 24 74 8b 04 85 a0 ae a0 0Kernel panic - not syncing: /usr/src/zaptel-1.2/zaptel-base.c:5593: spin_lock(/usr/src/zaptel-1. 2/zaptel-base.c:ce0c0410) already locked by /usr/src/zaptel-1.2/zaptel-base.c/3832 Badness in panic at kernel/panic.c:118 [c0123ea0] panic+0x135/0x142 [d09e6044] __zt_ec_chunk+0x5d/0x5dd [zaptel] [d09e6a65] __zt_transmit_chunk+0x16/0x33 [zaptel] [d0975577] t4_receiveprep+0x4ea/0x55f [wct4xxp] [d097659f] t4_interrupt+0x1e5/0x484 [wct4xxp] [c0107f00] handle_IRQ_event+0x25/0x4f [c01088ce] do_IRQ+0x18a/0x2bf === [c0319830] common_interrupt+0x18/0x20 [c02b007b] cpufreq_register_driver+0xe5/0x271 [c0129a84] __do_softirq+0x2c/0x79 [c0109446] do_softirq+0x46/0x4d === [c01089f7] do_IRQ+0x2b3/0x2bf [c0319830] common_interrupt+0x18/0x20 [c01068ee] die+0x1d0/0x22b [c011db59] do_page_fault+0x380/0x4dc [d09e3c88] zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel] [c0120114] __wake_up+0x6e/0xca [d084a6a6] journal_stop+0x425/0x42f [jbd] [d090ac72] __ext3_journal_stop+0x19/0x34 [ext3] [d0905471] ext3_ordered_commit_write+0xb6/0xc5 [ext3] [c0317593] __cond_resched+0x14/0x3b [c011d7d9] do_page_fault+0x0/0x4dc [c03198ef] error_code+0x2f/0x38 [d09e3c88] zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel] [c01299d0] current_fs_time+0x44/0x4c [c014d59d] __generic_file_aio_write_nolock+0x33d/0x36b [c014d604] generic_file_aio_write_nolock+0x39/0x7f [c014d7f3] generic_file_aio_write+0x77/0xcd [d09030af] ext3_file_write+0x19/0x8a [ext3] [c016c2e9] do_sync_write+0x97/0xc9 [c0121853] autoremove_wake_function+0x0/0x2d [c01771fc] sys_stat64+0x1e/0x23 [d09e575b] zt_ioctl+0xc1/0xc7 [zaptel] [c0180401] sys_ioctl+0x297/0x336
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wed, 2007-04-25 at 08:18 -0400, Andrew Kohlsmith wrote:
On Tuesday 24 April 2007 8:26 pm, Jared Smith wrote:
Here's just one example of the many ways I use the current behavior.
[long-distance]
exten = _1NXXNXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})
include = local
[local]
exten = _NXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})
exten = _1NXXNXX,1,Dial(no-permissions-to-make-this-type-of-call)
In this case, however, you could not dial locally if your context includes
longdistance!
i.e. don't you use something like this?
[international]
exten = _011.,1,Dial(...)
include = longdistance
[longdistance]
exten = _1NXXNXX,1,Dial(...)
include = local
[local]
exten = _NXXNXX,1,Dial(...)
exten = _NXX,1,Goto(519${EXTEN},1)
[trusted]
include = nine11
include = internal
include = international
[polycom]
include = hints
include = trusted
sip.conf:
[221]
context = polycom
?? In that case, putting a _1NXXNXX,1,Dial(...) in local will never get
executed, since the wildcard match in longdistance will always hit first. In
what I thought it should be, your local will override since wildcards are
lowest-priority, and the local wildcard will match before the LD wildcard
since includes of a context are searched before wildcards of the context.
-A.
Andrew--
Well, I guess the magic of putting the _1NXXNXX exten in the local
context wouldn't be useful until you define an untrusted context:
[untrusted]
include = local
And, maybe, it'd be better to define the local this way instead:
[local]
exten = _NXXNXX,1,Playback(gojumpinthelake)
exten = _011.,1,Playback(gojumpinthelake)
exten = _NXX,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)
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.
It's backwards to what you are accustomed to, but still useful.
murf
___
--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
RE: [asterisk-dev] Re: qwell: branch 1.2 r2434 - /branches/1.2/
I can confirm that I had the same problem trying to upgrade to zaptel 1.4.2 last night. Whenever a call is hung-up, the system crashes immediately. I was offsite and tried to upgrade, so I am unable to provide the specifics at this time. But after I went back to 1.4.1, everything went back to normal. Packages installed when getting kernel panic: asterisk 1.4.3, zaptel 1.4.2, libpri 1.4.0 Since this is a production box, I quickly went back to asterisk 1.4.2, zaptel 1.4.1, libpri 1.4.0 after it crashed the first time and then trying zaptel 1.4 branch with the same results. I didn't have time to try zaptel 1.4.1 with asterisk 1.4.3. Hope this helps. Michael L. Young -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-dev- [EMAIL PROTECTED] On Behalf Of Tony Mountifield Sent: Wednesday, April 25, 2007 6:26 AM To: asterisk-dev@lists.digium.com Subject: [asterisk-dev] Re: qwell: branch 1.2 r2434 - /branches/1.2/ In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Author: qwell Date: Tue Apr 24 13:33:29 2007 New Revision: 2434 URL: http://svn.digium.com/view/zaptel?view=revrev=2434 Log: Backport pre-echocan debugging for ztmonitor Added: branches/1.2/jpah.h (with props) Modified: branches/1.2/zaptel-base.c branches/1.2/zaptel.h branches/1.2/zconfig.h branches/1.2/ztmonitor.c Why is this NEW functionality being backported to the STABLE 1.2 branch? And then being tagged for release so quickly? I tried this new 1.2 from SVN last night, and it gives me a kernel panic when hanging up a call (see below). This is using a TE405P with trunk 1 looped back to trunk 3. Not sure why EC stuff is being called, as I have EC disabled. Also not sure why it was doing a ZT_SETCONF when I wasn't using conferencing (the call was just an IAX call into the box, routed out through Zap and back in through Zap, into MusicOnHold). I haven't had time to investigate it fully yet, so can't file a proper bug yet, but if it IS to be in 1.2, it should be checked out more thoroughly before being released. Cheers Tony Unable to handle kernel NULL pointer dereference at virtual address 00b4 printing eip: d09e3c88 *pde = 0a056067 Oops: [#1] Modules linked in: parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc wct4xxp(U) zaptel(U) crc_cc itt dm_mirror dm_mod button battery ac r8169 e100 mii ext3 jbd CPU:0 EIP:0060:[d09e3c88]Not tainted VLI EFLAGS: 00010082 (2.6.9-42.0.2.EL) EIP is at zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel] eax: ebx: 0001 ecx: ffea edx: esi: ce0c0410 edi: ebp: ce0c0410 esp: ca411df0 ds: 007b es: 007b ss: 0068 Process asterisk (pid: 5958, threadinfo=ca411000 task=c9dcacd0) Stack: cf00e9b8 c1220514 cb74e005 d662d853 0009 cf80dc00 ca411e2c ca411000 c01299d0 3b9aca00 462e6ecb 10bbb3d8 01ff cc1eacc0 cbcde2c4 c014d59d 0153bfd5 ca411f34 005b 0001 Call Trace: [c01299d0] current_fs_time+0x44/0x4c [c014d59d] __generic_file_aio_write_nolock+0x33d/0x36b [c014d604] generic_file_aio_write_nolock+0x39/0x7f [c014d7f3] generic_file_aio_write+0x77/0xcd [d09030af] ext3_file_write+0x19/0x8a [ext3] [c016c2e9] do_sync_write+0x97/0xc9 [c0121853] autoremove_wake_function+0x0/0x2d [c01771fc] sys_stat64+0x1e/0x23 [d09e575b] zt_ioctl+0xc1/0xc7 [zaptel] [c0180401] sys_ioctl+0x297/0x336 [c016c4b9] sys_write+0x5a/0x62 [c0318e57] syscall_call+0x7/0xb [c031007b] build_polexpire+0x81/0xe0 Code: 8b 44 24 74 77 1e 8b 1c 85 a0 ae a0 d0 ba d0 00 00 00 a1 84 ce 36 c0 e8 35 04 77 ef 89 83 b4 0 0 00 00 eb 27 8b 04 85 a0 ae a0 d0 8b 80 b4 00 00 00 e8 e7 07 77 ef 8b 44 24 74 8b 04 85 a0 ae a0 0Kernel panic - not syncing: /usr/src/zaptel-1.2/zaptel-base.c:5593: spin_lock(/usr/src/zaptel-1. 2/zaptel-base.c:ce0c0410) already locked by /usr/src/zaptel-1.2/zaptel- base.c/3832 Badness in panic at kernel/panic.c:118 [c0123ea0] panic+0x135/0x142 [d09e6044] __zt_ec_chunk+0x5d/0x5dd [zaptel] [d09e6a65] __zt_transmit_chunk+0x16/0x33 [zaptel] [d0975577] t4_receiveprep+0x4ea/0x55f [wct4xxp] [d097659f] t4_interrupt+0x1e5/0x484 [wct4xxp] [c0107f00] handle_IRQ_event+0x25/0x4f [c01088ce] do_IRQ+0x18a/0x2bf === [c0319830] common_interrupt+0x18/0x20 [c02b007b] cpufreq_register_driver+0xe5/0x271 [c0129a84] __do_softirq+0x2c/0x79 [c0109446] do_softirq+0x46/0x4d === [c01089f7] do_IRQ+0x2b3/0x2bf [c0319830] common_interrupt+0x18/0x20 [c01068ee] die+0x1d0/0x22b [c011db59] do_page_fault+0x380/0x4dc [d09e3c88] zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel] [c0120114] __wake_up+0x6e/0xca [d084a6a6] journal_stop+0x425/0x42f [jbd] [d090ac72] __ext3_journal_stop+0x19/0x34 [ext3] [d0905471] ext3_ordered_commit_write+0xb6/0xc5 [ext3] [c0317593] __cond_resched+0x14/0x3b [c011d7d9]
Re: [asterisk-dev] extensions.conf included contexts priorities
On Tuesday 24 April 2007 20:26:25 Jared Smith wrote:
On 4/24/07, Steve Murphy [EMAIL PROTECTED] wrote:
Trouble is, is this desired behavior? Or is having the contexts checked
level by level until a match of any kind is found, the better procedure?
Well, I for one desire the current behavior. Everyone else can speak
for themselves, but it makes it easy to override an extension included
in a more-deeply-nested extension by putting its replacement in a
less-deeply-nested context. If they were all pulled together into one
big ball of wax, we'd lose a lot of functionality.
I also agree here. If you change this functionality, people who depend upon it
might come find you and do not such nice things to you :)
Here's just one example of the many ways I use the current behavior.
[long-distance]
exten = _1NXXNXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})
include = local
[local]
exten = _NXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})
exten = _1NXXNXX,1,Dial(no-permissions-to-make-this-type-of-call)
Or this:
[long_distance]
exten = _1NXXNXX,1,Dial(IAX2/${UPSTEAM}/${EXTEN})
exten = h,1,Verbose(1|This would actually get hit, and not the _. pattern)
include = match_all
[match_all]
exten = _.,1,NoOp()
exten = _.,n,Playback(cant-let-you-do-that)
Only the order of includes should matter, and not where they are placed in the
dialplan in relation to extensions in the same context.
Leif.
___
--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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wednesday 25 April 2007 10:04 am, Steve Murphy wrote:
Well, I guess the magic of putting the _1NXXNXX 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 = _NXXNXX,1,Playback(gojumpinthelake)
exten = _011.,1,Playback(gojumpinthelake)
exten = _NXX,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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wednesday 25 April 2007 10:37 am, Leif Madsen wrote:
[long_distance]
exten = _1NXXNXX,1,Dial(IAX2/${UPSTEAM}/${EXTEN})
exten = h,1,Verbose(1|This would actually get hit, and not the _. pattern)
include = match_all
[match_all]
exten = _.,1,NoOp()
exten = _.,n,Playback(cant-let-you-do-that)
Having _. matching oshiatT is a HUGE design mistake, IMO.
Only the order of includes should matter, and not where they are placed in
the dialplan in relation to extensions in the same context.
See, I very much disagree. The order is important, but not the placement...
seems very... awkward. In other words, include placement is only relevant to
other includes, but not to the rest of the dialplan? And wildcards match up
most-specific first, excluding included contexts? It's confusing.
At the *very* least, includes should throw a big fat warning if they are
placed above extensions in a context.
-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
Re: [asterisk-dev] Re: qwell: branch 1.2 r2434 - /branches/1.2/
- Tony Mountifield [EMAIL PROTECTED] wrote: I tried this new 1.2 from SVN last night, and it gives me a kernel panic when hanging up a call (see below). This is using a TE405P with trunk 1 looped back to trunk 3. Not sure why EC stuff is being called, as I have EC disabled. Also not sure why it was doing a ZT_SETCONF when I wasn't using conferencing (the call was just an IAX call into the box, routed out through Zap and back in through Zap, into MusicOnHold). Cheers Tony This has been fixed in svn branches 1.2, 1.4, and trunk in revisions 2443, 2444, and 2445. Zaptel channels always issue a ZT_SETCONF on hangup, to try to clear up any conferencing that was going on. -- Jason Parker Digium ___ --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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wed, 2007-04-25 at 10:37 -0400, Leif Madsen wrote:
On Tuesday 24 April 2007 20:26:25 Jared Smith wrote:
On 4/24/07, Steve Murphy [EMAIL PROTECTED] wrote:
Trouble is, is this desired behavior? Or is having the contexts checked
level by level until a match of any kind is found, the better procedure?
Well, I for one desire the current behavior. Everyone else can speak
for themselves, but it makes it easy to override an extension included
in a more-deeply-nested extension by putting its replacement in a
less-deeply-nested context. If they were all pulled together into one
big ball of wax, we'd lose a lot of functionality.
I also agree here. If you change this functionality, people who depend upon
it
might come find you and do not such nice things to you :)
Well, I certainly wouldn't **that** to happen!!! OK, I'm totally sold on
keeping current functionality.
For the moment...
I do propose that we make the following change to the
extensions.conf.sample file to minimize user
misunderstanding/frustration over include directives the reason this
thread began...
Do you think this might help? Is the English proper?
Index: configs/extensions.conf.sample
===
--- configs/extensions.conf.sample (revision 61639)
+++ configs/extensions.conf.sample (working copy)
@@ -140,15 +140,31 @@
;
; Contexts contain several lines, one for each step of each
; extension, which can take one of two forms as listed below,
-; with the first form being preferred. One may include another
-; context in the current one as well, optionally with a
-; date and time. Included contexts are included in the order
-; they are listed.
+; with the first form being preferred.
;
;[context]
;exten = someexten,{priority|
label{+|-}offset}[(alias)],application(arg1,arg2,...)
;exten = someexten,{priority|
label{+|-}offset}[(alias)],application,arg1|
arg2...
;
+; One may include another context in the current one as well,
optionally with a
+; date and time. Included contexts are included in the order
+; they are listed.
+; The reason a context would include other contexts is for their
extensions.
+; The algorithm to find an extension is recursive, and works in this
+; fashion:
+;a) Try to find a matching extension in the current context
+; and, if found, begin executing the priorities there in
sequence.
+;b) If not found, Search the switches, if any declared, in
sequence.
+;c) If still not found, for each include, make that context the
current
+; context, and recurse to a).
+; This is a depth-first traversal, and stops with the first context
that
+; provides a match. As usual, if more than one pattern in a context
will match,
+; the 'best' match will win.
+; Please note that in a context, it does not matter where an include
directive
+; occurs. Whether at the top, or near the bottom, the effect will be
the same.
+; The only thing that matters is that if there is more than one include
directive,
+; they will be searched for extensions in order, first to last.
+;
; Timing list for includes is
;
; time range|days of week|days of month|months
smime.p7s
Description: S/MIME cryptographic signature
___
--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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wednesday 25 April 2007 11:47 am, Steve Murphy wrote: I do propose that we make the following change to the extensions.conf.sample file to minimize user misunderstanding/frustration over include directives the reason this thread began... Do you think this might help? Is the English proper? I'd mention that wildcards are also searched depth-first, and that if a wildcard in the current context matches, a more specific extension in an included (or switched) context will NOT get executed. This is the most confusing part for me. I was under the impression (and it always seemed to work) that wildcards were searched DEAD LAST, since an included context with an extension with fewer (incl. 0) wildcards was a better match than an extension with more wildcards. What's scary (to me) is that my dialplans have been working just fine until very, very recently. -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
[asterisk-dev] Re: extensions.conf included contexts priorities
AK == Andrew Kohlsmith [EMAIL PROTECTED] writes: AK That's exactly what I'd have expected to happen as well... If not, AK maybe some AK damn-i-seem-to-still-be-a-newbie-after-years-of-using-asterisk AK warning that states include statement encountered before end of AK context, this may not do what you expect it to do type of thing. How about a more general extensions not ordered, this may not do what you expect it to do? Or simply fixing the problem by turning off all this sorting and reordering... /Benny ___ --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
[asterisk-dev] Asterisk 1.2.18 Released
The Asterisk.org development team has released Asterisk version 1.2.18. This release contains a large number of fixes, including: - A recently published security vulnerability in the manager interface (ASA-2007-012) - Another recently published security vulnerability in the SIP channel driver (ASA-2007-011) A full list of changes is available in the ChangeLog. Thank you for your support of Asterisk.org! ___ --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
