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
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
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
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
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
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
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 =
- 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
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
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
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
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
12 matches
Mail list logo
