The dahdi source already specifies an 8 second inter-digit timeout. The
problem is that it's erroneously using the matched pattern timeout instead,
because the error handling part of the dialplan isn't distinguishable from the
'meat' of the dialplan.
>> If you don't have any ambiguity in your
I agree, we could talk around in circles for days.
The only thing I'm trying point out is that I think the intent of splitting the
timeouts into 2 is so that users get an adequate amount of time to input a
number, but not a large delay once the input seems reasonable. This intent is
broken wit
On Thu, 11 Jul 2013 13:53:27 -0700
Justin Killen wrote:
> They won't catch, no (because of priority), but they do match, which
> is enough to trigger the 3 second timeout instead of the 8 second.
> So, if you pickup and dial 1, then you will only get 3 seconds
> (instead of 8) to type in the next
My example is not _X. it is _X It is there to catch single digit misdials.
The only line in my example with a . is the _[24-9]. Which will match neither
3xxx extensions nor any numbers staring with a 1 Hence, no timeouts. We can
talk about this all day, but other PBX admins solve the iss
They won't catch, no (because of priority), but they do match, which is enough
to trigger the 3 second timeout instead of the 8 second. So, if you pickup and
dial 1, then you will only get 3 seconds (instead of 8) to type in the next
digit before it considers it done. The issue I am describing
I'm interested in using the testing a non-DAHDI timing source to have some
assurance I'm on a system that's not likely to give me grief over
timing-related issues.
I'm familiar with dahdi_test and the guideline of needing 99.975% accuracy for
reliable conferencing and such. (Is that an accurat
The catch alls do not catch 1+ or 3+ calls. Look carefully at it. Therefore
there will not be a delay.
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Justin Killen
Sent: Thursday, July 11, 2013 3:14 PM
To:
Right, but when you type any of those, there's only a 3 second inter-digit
timeout because EVERYTHING is a match of the catch-all. There is no excessive
delay, but instead a delay so short that I'm getting complaints.
If I implement your suggestion and change the code in the channel driver, the
Arch = x86_64
OS = CentOS-6.4 (freepbx)
Asterisk = 11.4.0
FreePBX = 2.11.0.4
Snom870 FW = 8.7.3.19 /8.4.8beta
I would like to change the background colours on the BLF vkey field
based on the station status. I posted the following to the Snom
support forums some days back and have had no response
This issue is simple dialplan management, which applies to any PBX. This is
something every PBX admin has to deal with.
Here is an example using 4-digit extensions in the 3xxx range and outside calls
are dialed with a leading 1 so the PBX knows it is an outside call. There
should be no exce
No, I understand - maybe I'm not explaining myself well.
Yes, I can change the source so that pattern-matched input delays 8 seconds
instead of 3, but then the users have to wait 8 seconds for every number they
dial (even internal 3 digit calls). I think what I really want is for the
catch-all
You seem to be confused.
If you want to change the dialing timeouts on Asterisk analog channels, then
you need to change the source code. Now your dialing timeout problem is
fixed. I did that about 10 years ago to handle slow dialing users on asterisk
analog ports.
Then add a catchall pat
Xavier,
DoNotDisturb generates a "Busy" indication. Insert that into my earlier
response, and you have an explanation of why the call tries to go from RING
to BUSY, and confirms my theory.
No you cannot replace the Zaptel card driver on its own (and the problem
was bigger than that anyway), as As
So my only two options then are:
1) Have the timeout be so short that users complain (but they get a fancy
message).
2) The timeouts are reasonable, but when they're wrong the users get a busy
signal (no fancy message).
It's a shame that reasonable timeouts and a nice message are mutually exclu
Update:
I can reproduce the error by putting the reception phone (call queue 0) in Do
Not Disturb mode, then call in from outside using a mobile, then pick up the
call from the 2nd phone in the queue. It will cause the error only if I hang up
_before_ the mobile hangs up. The error doesn't seem
Similar information is included in every Asterisk source tarball as UPGRADE*.txt
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Mike Diehl
Sent: Thursday, July 11, 2013 3:22 AM
To: Asterisk Users Mailing List
I imagine setting up a catch-all extension pattern is your best option. That
is what most seem people do.
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Justin Killen
Sent: Wednesday, July 10, 2013 4:51 PM
T
Hi Xavier,
The issue you are seeing is an old Asterisk/Bristuff bug that was fixed
years ago.
Basically ISDN is unable to understand a call going from RING state to BUSY
state, so Asterisk converts the BUSY into a HANGUP/Normal Clearing, and
warns that this is happening.
Sadly, in that old versi
> Are you using a 3rd party java library such as asterisk-java
> (https://github.com/srt/asterisk-java), or are you doing your own Java
> AMI connector? I use asterisk-java and it has been working great.
I didn't write the Java code, but I think we do use the asterisk-java
library.
Alex
--
__
Are you using a 3rd party java library such as asterisk-java
(https://github.com/srt/asterisk-java), or are you doing your own Java
AMI connector? I use asterisk-java and it has been working great.
Jacob
--
_
-- Bandwidth and C
Chan_zap has been deprecated more then 2-3 yrs back. You might have to ping
ipcortex helpdesk to get fix.
Mitul
On Jul 11, 2013 4:32 PM, "Xavier Singer - EcuTek" wrote:
> We use an IPcortex PABX running Asterisk 1.2.39-BRIstuffed-0.3.0-PRE-1y-y.
> We have recently implemented Call Queuing for ou
We use an IPcortex PABX running Asterisk 1.2.39-BRIstuffed-0.3.0-PRE-1y-y. We
have recently implemented Call Queuing for our main incoming line with hold
music. The call queue type is: Ring all - One call at a time (no position
announcement).
Since implementing this feature we've been receivin
Maybe the Java code is not robust enough. I am using AMI for years and never had a communication
issue (except for my programming errors). Some time ago I wrote a little tool to study the AMI
interface (http://www.jgoettgens.de/Meine_Bilder_und_Dateien/AMOA.7z,
http://www.jgoettgens.de/d9e5cb9b
> Are you using raw AMI or AMI via HTTP?
Raw AMI, on port 5038.
Alex
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
Are you using raw AMI or AMI via HTTP?
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
Have you looked at mohsuggest in the sip configuration?
Regards
Ish
On 10 July 2013 17:55, Andrew Thomas wrote:
> Hi All,
>
> Sorry if this has been covered already, but I don't tend to follow this
> list as close as I should these days.
>
> Problem is that if a call comes in to a queue witho
Hi,
We're using Asterisk 1.8.0 to run a call centre. There is a Java
process which talks to Asterisk through AMI, which is part of the
software stack that presents a user interface to the call centre agents.
We're seeing a strange issue with AMI. Most of the time, it doesn't
cause problems, bec
hello all,
i have a conceptual question.
i have a h323 gateway and it is connected to a h323 gatekeeper. my
question is: can i connect my gateway to another gateway directly? i mean
can these two gateways work with each other without working with
gatekeeper? or when i have connection with a gatek
Thank you! That was very helpful.
Mike.
On Wed, Jul 10, 2013 at 7:38 PM, Matthew Jordan wrote:
>
> On Wed, Jul 10, 2013 at 5:35 PM, Mike Diehl wrote:
>>
>> Hi all,
>>
>> I'm contemplating an upgrade from 10.2.4 to 11.4.x. However, the
>> 1.8.x to 10.4.x upgrade was painful; some of the module
29 matches
Mail list logo