Re: [asterisk-users] Upgrade from 10.2.4 to 11.4.x, the Reader's Digest version?
Thank you! That was very helpful. Mike. On Wed, Jul 10, 2013 at 7:38 PM, Matthew Jordan mjor...@digium.com wrote: On Wed, Jul 10, 2013 at 5:35 PM, Mike Diehl mdiehlena...@gmail.com 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 modules had been renamed, if I recall correctly. So, is there a list of MAJOR changes and GOTCHA's between 10.x and 11.x? I'm hoping for something a little less granular than the release notes from 10.2.x to 11.4.x. I don't mind reading, but that is almost as long as War and Peace! Does such a document exist, or do I need to start reading.. Upgrade notes: https://wiki.asterisk.org/wiki/display/AST/Upgrading+to+Asterisk+11 While the upgrade notes cover changes to configuration and module status, it is also a good idea to read through what is new: https://wiki.asterisk.org/wiki/display/AST/New+in+11 I wouldn't say it is War and Peace, but yes, there is some content in there. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] have two H323 connection: one with GK, one with other GW. is it possible?
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 gatekeeper, all calls must be set through it? thanks in advance, SAM -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] AMI timeouts
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, because the Java code is written to cope with it, but occasionally it does, and, in rare cases, may even result in calls being dropped. The main problem with the issue is that we haven't been able to reproduce it in a test environment, and that it's not that easy to describe. The fact that we can't reproduce it in test leads me to think that it's somehow related to the load on our production system. I'm hoping that someone else on the list may have seen something similar before, or that an Asterisk developer might read this and think ah, it's this bit of code that's doing it!. :-) Anyway, let me try to describe what's happening. The Java process has an AMI connection to Asterisk which it keeps open continuously. When sending an AMI request, the process will wait a certain amount of time for a response (I think the timeout is 5 seconds) and if it hasn't received it, will retry the request up to 5 times. Occasionally, the Java process logs show AMI requests timing out (after 5 tries). What I see in packet captures of the AMI traffic is: 1. Java process sends a request (e.g., add member to queue) 2. Retries 5 seconds later 3. Retries again 5 seconds later 4. Retries again 5 seconds later 5. Retries again 5 seconds later 6. Logs a timeout 7. After a few more seconds, Asterisk replies to all five requests in one go (in a single packet; so, e.g., for add member to queue it would reply success, then four failures because the member is already added); however at this stage, the Java process has given up It feels like Asterisk queues up the AMI responses and then periodically sends out all the responses in the queue in one go. Is something like this going on? Does the frequency at which Asterisk flushes the queue depend on load? Are there any tunable in the config for this? If anyone has seen this before, or understands what's happening here, I would be very grateful for any info! If you need more details, please do ask and I'll do my best. Thanks in advance, Alex -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] queue moh
Have you looked at mohsuggest in the sip configuration? Regards Ish On 10 July 2013 17:55, Andrew Thomas a...@datavox.co.uk 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 without option 'r' specified - moh plays as expected. Now, when that call is answered, all is fine. Trouble comes when that person then puts the caller on-hold. No moh is heard by the caller (in fact, they get silence). If I use 'r' - then ringing is heard - but the queue's musiconhold/musicclass is ignored completely. When the caller is put on hold, they do hear moh but the default moh context is used - not the moh of the queue. What I need is for the queue's moh to be used when the caller is put on hold (and without using the 'r' feature). Is this possible? * 1.8.16.0 (tried on various flavours of 1.8). Queue static and realtime (same outcome). Cheers Andy -- If you have received this communication in error we would appreciate you advising us either by telephone or return of e-mail. The contents of this message, and any attachments, are the property of DataVox, and are intended for the confidential use of the named recipient only. If you are not the intended recipient, employee or agent responsible for delivery of this message to the intended recipient, take note that any dissemination, distribution or copying of this communication and its attachments is strictly prohibited, and may be subject to civil or criminal action for which you may be liable. Every effort has been made to ensure that this e-mail or any attachments are free from viruses. While the company has taken every reasonable precaution to minimise this risk, neither company, nor the sender can accept liability for any damage which you sustain as a result of viruses. It is recommended that you should carry out your own virus checks before opening any attachments. Registered in England. No. 27459085. -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Ishfaq Malik Department: VOIP Support Company: Packnet Limited t: +44 (0)845 004 4994 f: +44 (0)161 660 9825 e: i...@pack-net.co.uk w: http://www.pack-net.co.uk Registered Address: PACKNET LIMITED, 2A ENTERPRISE HOUSE, LLOYD STREET NORTH, MANCHESTER SCIENCE PARK, MANCHESTER, M156SE COMPANY REG NO. 04920552 -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI timeouts
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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI timeouts
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: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI timeouts
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-c5fa-429b-9974-a7b4f4bf58c3.html). The tool is now outdated (partial DAHDI support, Woomera obsolete), but the SIP channels are usable. If you have a few SIP channels you could compare the behavior of both packages under load. jg -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6
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 receiving the below error daily in the mornings and lunchtime when the queue will jump to the next available phone, as the main reception phone is in Do Not Disturb mode: Jul 11 08:30:54 WARNING[23444] chan_zap.c: 1 Cause code 17 not allowed when disconnecting an active call. Changing to cause 16. Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6! Corrected. Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:47:04 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:08 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:19 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:23 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, The ERROR happens when the call is ended. I can't replicate the error either... I suspect that the chan_zap driver has a bug and is possibly trying to hang up the call on the first phone in the queue, rather than the phone that answered the call. I have investigated the different state and causes listed in the above log file, and this is what I think they mean (please correct me if I got it wrong): ISDN State 6 = not initialised Cause 16 = normal call clearing Cause 17 = user busy TEI 127 = reserved as the broadcast TEI So my questions are: 1. What could be causing the error and any suggestions on how to troubleshoot this issue? 2. Can I upgrade the chan_zap driver for the ISDN card without breaking the IPcortex frontend (we have root access)? 3. Should I supply any config files? Thanks! Xavier -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6
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 xav...@ecutek.com 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 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 receiving the below error daily in the mornings and lunchtime when the queue will jump to the next available phone, as the main reception phone is in Do Not Disturb mode: Jul 11 08:30:54 WARNING[23444] chan_zap.c: 1 Cause code 17 not allowed when disconnecting an active call. Changing to cause 16. Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6! Corrected. Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:47:04 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:08 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:19 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:23 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, The ERROR happens when the call is ended. I can't replicate the error either... I suspect that the chan_zap driver has a bug and is possibly trying to hang up the call on the first phone in the queue, rather than the phone that answered the call. I have investigated the different state and causes listed in the above log file, and this is what I think they mean (please correct me if I got it wrong): ISDN State 6 = not initialised Cause 16 = normal call clearing Cause 17 = user busy TEI 127 = reserved as the broadcast TEI So my questions are: 1. What could be causing the error and any suggestions on how to troubleshoot this issue? 2. Can I upgrade the chan_zap driver for the ISDN card without breaking the IPcortex frontend (we have root access)? 3. Should I supply any config files? Thanks! Xavier -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI timeouts
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 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI timeouts
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 -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6
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 version there was a resource leak of the call object when this happened. I would suggest calling IPCortex directly to see what can be done about this. Regards, Steve On 11 July 2013 12:04, Mitul Limbani mi...@enterux.in wrote: 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 xav...@ecutek.com 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 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 receiving the below error daily in the mornings and lunchtime when the queue will jump to the next available phone, as the main reception phone is in Do Not Disturb mode: Jul 11 08:30:54 WARNING[23444] chan_zap.c: 1 Cause code 17 not allowed when disconnecting an active call. Changing to cause 16. Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6! Corrected. Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:47:04 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:08 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:19 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:23 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, The ERROR happens when the call is ended. I can't replicate the error either... I suspect that the chan_zap driver has a bug and is possibly trying to hang up the call on the first phone in the queue, rather than the phone that answered the call. I have investigated the different state and causes listed in the above log file, and this is what I think they mean (please correct me if I got it wrong): ISDN State 6 = not initialised Cause 16 = normal call clearing Cause 17 = user busy TEI 127 = reserved as the broadcast TEI So my questions are: 1. What could be causing the error and any suggestions on how to troubleshoot this issue? 2. Can I upgrade the chan_zap driver for the ISDN card without breaking the IPcortex frontend (we have root access)? 3. Should I supply any config files? Thanks! Xavier -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] analog phone digit delay
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
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
Okay, so I is no good. Does anybody else have a work-around for this?
-Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, July 10, 2013 1:43 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
I has the same limitations as dialplan timeouts, you have to be in a
Background or WaitExten or similar for them to work.These items are
designed for IVRS.
-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:40 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
It seems likely that this is exactly what is happening. I'd rather not change
the code though, but rather fix the dialplan. I'm thinking using the 'i'
extension would work just the same - would there be a reason to use a wildcard
pattern match instead of i?
-Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, July 10, 2013 1:12 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
From chan_dahdi.c, don't know if it applies to your situation or not.
/*! \brief Wait up to 16 seconds for first digit (FXO logic) */ static int
firstdigittimeout = 16000;
/*! \brief How long to wait for following digits (FXO logic) */ static int
gendigittimeout = 8000;
/*! \brief How long to wait for an extra digit, if there is an ambiguous match
*/ static int matchdigittimeout = 3000;
-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 3:55 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
So then, by saying If the digits already dialed match an extension in the
dialplan...wait 3 seconds..., then we're saying that asterisk has found a
match, and the match is the bad-extension. Here is the bad-number context that
is included:
[bad-number]
include = bad-number-custom
exten = _X.,1,Noop(bad-number, timeouts: absolute: ${TIMEOUT(absolute)} digit:
${TIMEOUT(digit)} response: ${TIMEOUT(response)})
exten = _X.,n,ResetCDR()
exten = _X.,n,NoCDR()
exten = _X.,n,Progress
exten = _X.,n,Wait(1)
exten = _X.,n,Progress
exten =
_X.,n,Playback(silence/1cannot-complete-as-dialedcheck-number-dial-again,noanswer)
exten = _X.,n,Wait(1)
exten = _X.,n,Congestion(20)
exten = _X.,n,Hangup
So then, what you're saying then is that if I was to remove this include, there
would be no match in the dialplan and asterisk will wait for 8 seconds instead
of 3? The next question then is how to accomplish this without using the
wildcard (and how to change it in freepbx).
-Justin
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Richard Mudgett
Sent: Wednesday, July 10, 2013 10:22 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
On Mon, Jul 8, 2013 at 12:14 PM, Justin Killen jkil...@allamericanasphalt.com
wrote:
I have an installation that has analog phones connected via T1 channel banks.
I'm getting complaints from users that they will enter a partial number (eg
91213), then turn away to get the next few digits, and the system will start
dialing before they have a chance to put in the rest of the dialing string. Is
there a way to increase this delay? The only use these 4 dialing patterns:
Internal 3 digit numbers
91 XXX XXX (for backwards compatibility)
9 XXX (also for compatibility)
XXX
The simple switch in chan_dahdi has two hardcoded timeout times for more digits.
1) If the digits already dialed match an extension in the dialplan but could
match another extension if more digits are dialed then chan_dahdi will wait 3
seconds for more digits to arrive.
2) If the digits already dialed do not match any extension in the dialplan but
more digits could match an extension then chan_dahdi will wait 8 seconds for
more digits.
The shorter timeout is so the caller won't have to wait
Re: [asterisk-users] Upgrade from 10.2.4 to 11.4.x, the Reader's Digest version?
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 - Non-Commercial Discussion Subject: Re: [asterisk-users] Upgrade from 10.2.4 to 11.4.x, the Reader's Digest version? Thank you! That was very helpful. Mike. On Wed, Jul 10, 2013 at 7:38 PM, Matthew Jordan mjor...@digium.com wrote: On Wed, Jul 10, 2013 at 5:35 PM, Mike Diehl mdiehlena...@gmail.com 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 modules had been renamed, if I recall correctly. So, is there a list of MAJOR changes and GOTCHA's between 10.x and 11.x? I'm hoping for something a little less granular than the release notes from 10.2.x to 11.4.x. I don't mind reading, but that is almost as long as War and Peace! Does such a document exist, or do I need to start reading.. Upgrade notes: https://wiki.asterisk.org/wiki/display/AST/Upgrading+to+Asterisk+11 While the upgrade notes cover changes to configuration and module status, it is also a good idea to read through what is new: https://wiki.asterisk.org/wiki/display/AST/New+in+11 I wouldn't say it is War and Peace, but yes, there is some content in there. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] FW: IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6
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 to happen if the external call hangs up, or if the call is answered by the reception phone (first call in the queue). Thanks again, Xavier -Original Message- From: Xavier Singer - EcuTek Sent: 11 July 2013 12:02 To: 'asterisk-users@lists.digium.com' Subject: IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6 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 receiving the below error daily in the mornings and lunchtime when the queue will jump to the next available phone, as the main reception phone is in Do Not Disturb mode: Jul 11 08:30:54 WARNING[23444] chan_zap.c: 1 Cause code 17 not allowed when disconnecting an active call. Changing to cause 16. Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6! Corrected. Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:47:04 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:08 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:19 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:23 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, The ERROR happens when the call is ended. I can't replicate the error either... I suspect that the chan_zap driver has a bug and is possibly trying to hang up the call on the first phone in the queue, rather than the phone that answered the call. I have investigated the different state and causes listed in the above log file, and this is what I think they mean (please correct me if I got it wrong): ISDN State 6 = not initialised Cause 16 = normal call clearing Cause 17 = user busy TEI 127 = reserved as the broadcast TEI So my questions are: 1. What could be causing the error and any suggestions on how to troubleshoot this issue? 2. Can I upgrade the chan_zap driver for the ISDN card without breaking the IPcortex frontend (we have root access)? 3. Should I supply any config files? Thanks! Xavier -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] analog phone digit delay
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 exclusive.
--Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Thursday, July 11, 2013 7:08 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
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
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
Okay, so I is no good. Does anybody else have a work-around for this?
-Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, July 10, 2013 1:43 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
I has the same limitations as dialplan timeouts, you have to be in a
Background or WaitExten or similar for them to work.These items are
designed for IVRS.
-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:40 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
It seems likely that this is exactly what is happening. I'd rather not change
the code though, but rather fix the dialplan. I'm thinking using the 'i'
extension would work just the same - would there be a reason to use a wildcard
pattern match instead of i?
-Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, July 10, 2013 1:12 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
From chan_dahdi.c, don't know if it applies to your situation or not.
/*! \brief Wait up to 16 seconds for first digit (FXO logic) */ static int
firstdigittimeout = 16000;
/*! \brief How long to wait for following digits (FXO logic) */ static int
gendigittimeout = 8000;
/*! \brief How long to wait for an extra digit, if there is an ambiguous match
*/ static int matchdigittimeout = 3000;
-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 3:55 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
So then, by saying If the digits already dialed match an extension in the
dialplan...wait 3 seconds..., then we're saying that asterisk has found a
match, and the match is the bad-extension. Here is the bad-number context that
is included:
[bad-number]
include = bad-number-custom
exten = _X.,1,Noop(bad-number, timeouts: absolute: ${TIMEOUT(absolute)} digit:
${TIMEOUT(digit)} response: ${TIMEOUT(response)})
exten = _X.,n,ResetCDR()
exten = _X.,n,NoCDR()
exten = _X.,n,Progress
exten = _X.,n,Wait(1)
exten = _X.,n,Progress
exten =
_X.,n,Playback(silence/1cannot-complete-as-dialedcheck-number-dial-again,noanswer)
exten = _X.,n,Wait(1)
exten = _X.,n,Congestion(20)
exten = _X.,n,Hangup
So then, what you're saying then is that if I was to remove this include, there
would be no match in the dialplan and asterisk will wait for 8 seconds instead
of 3? The next question then is how to accomplish this without using the
wildcard (and how to change it in freepbx).
-Justin
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Richard Mudgett
Sent: Wednesday, July 10, 2013 10:22 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
On Mon, Jul 8, 2013 at 12:14 PM, Justin Killen jkil...@allamericanasphalt.com
wrote:
I have an installation that has analog phones connected via T1 channel banks.
I'm getting complaints from users that they will enter a partial number (eg
91213), then turn away to get the next few digits, and the system will start
dialing before they have a chance to put in the rest of the dialing string. Is
there a way to increase this delay? The only use these 4 dialing patterns:
Internal 3
Re: [asterisk-users] FW: IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6
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 Asterisk is compiled and linked to a specific Zaptel (Dahdi) version. As mentioned, you need to call IPCortex. Regards, Steve On 11 July 2013 16:23, Xavier Singer - EcuTek xav...@ecutek.com wrote: 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 to happen if the external call hangs up, or if the call is answered by the reception phone (first call in the queue). Thanks again, Xavier -Original Message- From: Xavier Singer - EcuTek Sent: 11 July 2013 12:02 To: 'asterisk-users@lists.digium.com' Subject: IPcortex: ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6 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 receiving the below error daily in the mornings and lunchtime when the queue will jump to the next available phone, as the main reception phone is in Do Not Disturb mode: Jul 11 08:30:54 WARNING[23444] chan_zap.c: 1 Cause code 17 not allowed when disconnecting an active call. Changing to cause 16. Jul 11 08:30:54 ERROR[23444] chan_zap.c: You cannot use cause 17 number when in state 6! Corrected. Jul 11 08:30:54 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:54 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:54 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Call specified, but not found? Jul 11 08:30:58 NOTICE[7133] chan_zap.c: Hangup, did not find cref 1, tei 127 Jul 11 08:30:58 WARNING[7133] chan_zap.c: Hangup on bad channel 0/1 on span 1 Jul 11 08:47:04 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:08 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:19 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, Jul 11 08:47:23 WARNING[7133] chan_zap.c: 1 received SETUP message for call that is not a new call (retransmission), peercallstate 19 ourcallstate 0 cr 1, The ERROR happens when the call is ended. I can't replicate the error either... I suspect that the chan_zap driver has a bug and is possibly trying to hang up the call on the first phone in the queue, rather than the phone that answered the call. I have investigated the different state and causes listed in the above log file, and this is what I think they mean (please correct me if I got it wrong): ISDN State 6 = not initialised Cause 16 = normal call clearing Cause 17 = user busy TEI 127 = reserved as the broadcast TEI So my questions are: 1. What could be causing the error and any suggestions on how to troubleshoot this issue? 2. Can I upgrade the chan_zap driver for the ISDN card without breaking the IPcortex frontend (we have root access)? 3. Should I supply any config files? Thanks! Xavier -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] analog phone digit delay
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 pattern for bad numbers and your congestion tone is fixed.
done!
-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 12:26 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
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 exclusive.
--Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Thursday, July 11, 2013 7:08 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
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
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
Okay, so I is no good. Does anybody else have a work-around for this?
-Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, July 10, 2013 1:43 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
I has the same limitations as dialplan timeouts, you have to be in a
Background or WaitExten or similar for them to work.These items are
designed for IVRS.
-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:40 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
It seems likely that this is exactly what is happening. I'd rather not change
the code though, but rather fix the dialplan. I'm thinking using the 'i'
extension would work just the same - would there be a reason to use a wildcard
pattern match instead of i?
-Justin
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, July 10, 2013 1:12 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
From chan_dahdi.c, don't know if it applies to your situation or not.
/*! \brief Wait up to 16 seconds for first digit (FXO logic) */ static int
firstdigittimeout = 16000;
/*! \brief How long to wait for following digits (FXO logic) */ static int
gendigittimeout = 8000;
/*! \brief How long to wait for an extra digit, if there is an ambiguous match
*/ static int matchdigittimeout = 3000;
-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 3:55 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] analog phone digit delay
So then, by saying If the digits already dialed match an extension in the
dialplan...wait 3 seconds..., then we're saying that asterisk has found a
match, and the match is the bad-extension. Here is the bad-number context that
is included:
[bad-number]
include = bad-number-custom
exten = _X.,1,Noop(bad-number, timeouts: absolute: ${TIMEOUT(absolute)} digit:
${TIMEOUT(digit)} response: ${TIMEOUT(response)})
exten = _X.,n,ResetCDR()
exten = _X.,n,NoCDR()
exten = _X.,n,Progress
exten = _X.,n,Wait(1)
exten = _X.,n,Progress
exten =
_X.,n,Playback(silence/1cannot-complete-as-dialedcheck-number-dial-again,noanswer)
exten = _X.,n,Wait(1)
exten = _X.,n,Congestion(20)
exten = _X.,n,Hangup
So then, what you're saying then is that if I was to remove this include, there
would be no match in the dialplan and asterisk will wait for 8 seconds instead
of 3? The next question then is how to accomplish this without using the
wildcard (and how to change it in freepbx).
-Justin
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of
Re: [asterisk-users] analog phone digit delay
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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have the catch-all disabled at the site and things are running smoother. Thanks Eric for your help on this - you helped me to track down the cause of the issue and provided a work-around, which is much appreciated. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 9:48 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern for bad numbers and your congestion tone is fixed. done! -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 12:26 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 exclusive. --Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 7:08 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay Okay, so I is no good. Does anybody else have a work-around for this? -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Wednesday, July 10, 2013 1:43 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay I has the same limitations as dialplan timeouts, you have to be in a Background or WaitExten or similar for them to work.These items are designed for IVRS. -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:40 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay It seems likely that this is exactly what is happening. I'd rather not change the code though, but rather fix the dialplan. I'm thinking using the 'i' extension would work just the same - would there be a reason to use a wildcard pattern match instead of i? -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Wednesday, July 10, 2013 1:12 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay From chan_dahdi.c, don't know if it applies to your situation or not. /*! \brief Wait up to 16 seconds for first digit (FXO logic) */ static int firstdigittimeout = 16000; /*! \brief How long to wait for following digits (FXO logic) */ static int gendigittimeout = 8000; /*! \brief How long to wait for an extra digit, if there is an ambiguous match */ static int matchdigittimeout = 3000; -Original Message- From: asterisk-users-boun...@lists.digium.com
Re: [asterisk-users] analog phone digit delay
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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers there will, of course, be a delay. exten = _1NXXNXX,1,DoYourOutsideDialing exten = _3XXX,1,DoYourInsideDialing exten = _[24-9].,1,DoErrorHandling exten = _X,1,DoErrorHandling -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 1:11 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have the catch-all disabled at the site and things are running smoother. Thanks Eric for your help on this - you helped me to track down the cause of the issue and provided a work-around, which is much appreciated. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 9:48 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern for bad numbers and your congestion tone is fixed. done! -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 12:26 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 exclusive. --Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 7:08 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay Okay, so I is no good. Does anybody else have a work-around for this? -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Wednesday, July 10, 2013 1:43 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay I has the same limitations as dialplan timeouts, you have to be in a Background or WaitExten or similar for them to work.These items are designed for IVRS. -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:40 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay It seems likely that this is exactly what is happening. I'd rather not change the code though, but rather fix the dialplan.
[asterisk-users] Setting the vkey background colour on Snom870
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 so I am asking here in the hope than one or more of you have done something like this: I have the following code in a provisioning file vkey_red perm=BUSY IN_A_CALL IN_A_MEETING HOLDING/vkey_red vkey_orange perm=AWAY INACTIVE/vkey_orange vkey_green perm=AVAILABLE/vkey_green vkey_blue perm=DND/vkey_blue goto_virtual_keys_state_on_activity perm=on/goto_virtual_keys_state_on_activity I have a test phone with f/w 8.7.4.8 and loaded into it the provisioning file that include the instructions given above. When I place that phone on DND the BLF key for that extension does not show any colour change at all but the text changes to [talking]. As well, ringing, and talking actions on other extensions displayed in the BLF do not show any change in background colour at all although the text changes. On phones using 8.7.3.19 using the same provisioning file the background colour for ringing shows green and for talking shows orange but nothing else appears to change any colour and neither red nor blue appears used for anything. Is there an additional setting that I have to turn on in order to use vkey_colours on the BLF in 8.4.8? Is there any way to control the BLF background colours in Snom870s with f/w 8.3.7.19? Is there any way to set the hues to colours other than red/green/orange/blue? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] analog phone digit delay
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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers there will, of course, be a delay. exten = _1NXXNXX,1,DoYourOutsideDialing exten = _3XXX,1,DoYourInsideDialing exten = _[24-9].,1,DoErrorHandling exten = _X,1,DoErrorHandling -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 1:11 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have the catch-all disabled at the site and things are running smoother. Thanks Eric for your help on this - you helped me to track down the cause of the issue and provided a work-around, which is much appreciated. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 9:48 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern for bad numbers and your congestion tone is fixed. done! -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 12:26 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 exclusive. --Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 7:08 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay I imagine
Re: [asterisk-users] analog phone digit delay
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: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers there will, of course, be a delay. exten = _1NXXNXX,1,DoYourOutsideDialing exten = _3XXX,1,DoYourInsideDialing exten = _[24-9].,1,DoErrorHandling exten = _X,1,DoErrorHandling -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 1:11 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have the catch-all disabled at the site and things are running smoother. Thanks Eric for your help on this - you helped me to track down the cause of the issue and provided a work-around, which is much appreciated. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 9:48 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern for bad numbers and your congestion tone is fixed. done! -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 12:26 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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
[asterisk-users] Use of timing test
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 accurate guideline? Where did it come from?) When I started looking at using the timerfd timing source instead, it seemed the timing test command was my go-to for checking it, but I'm not sure it's testing the timing source at the same level dahdi_test did, as it's only testing 50 ticks per second? How much do I really need? Is it worthwhile to go up to timing test 1024 to match? Would really love an authoritative answer to this question, or at least a direction to go in to figure this one out myself. I tried asking this question on Server Fault first, by the way--if anyone wants the rep for answering it there, here's the link: http://serverfault.com/questions/517556/interpreting-and-using-the-asterisk-timing-test-command smime.p7s Description: S/MIME cryptographic signature -- _ -- 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 asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] analog phone digit delay
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 is compounded by the fact that the patter is _X. instead of _X but the core issue is the same - only getting 3 second inter-digit timeouts instead of 8. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 12:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers there will, of course, be a delay. exten = _1NXXNXX,1,DoYourOutsideDialing exten = _3XXX,1,DoYourInsideDialing exten = _[24-9].,1,DoErrorHandling exten = _X,1,DoErrorHandling -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 1:11 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have the catch-all disabled at the site and things are running smoother. Thanks Eric for your help on this - you helped me to track down the cause of the issue and provided a work-around, which is much appreciated. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 9:48 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay You seem to be confused. If you want to change the dialing timeouts on Asterisk analog channels, then you need to change the
Re: [asterisk-users] analog phone digit delay
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 issue with good dialplan planning like in my example. -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 4:53 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 is compounded by the fact that the patter is _X. instead of _X but the core issue is the same - only getting 3 second inter-digit timeouts instead of 8. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 12:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers there will, of course, be a delay. exten = _1NXXNXX,1,DoYourOutsideDialing exten = _3XXX,1,DoYourInsideDialing exten = _[24-9].,1,DoErrorHandling exten = _X,1,DoErrorHandling -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 1:11 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have
Re: [asterisk-users] analog phone digit delay
On Thu, 11 Jul 2013 13:53:27 -0700 Justin Killen jkil...@allamericanasphalt.com 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 digit before it considers it done. The issue I am describing is compounded by the fact that the patter is _X. instead of _X but the core issue is the same - only getting 3 second inter-digit timeouts instead of 8. Well, if you want an 8 second inter-digit timeout, you can do that by changing the DAHDI source. If you don't have any ambiguity in your extensions, you'll never have anyone waiting 8 seconds after they've finished dialing, because once they've dialed a valid number (which would match only one extension), it continues instantly without any timeout at all. So it looks like you'll need both fixes--and then you can have it all. -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 12:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers there will, of course, be a delay. exten = _1NXXNXX,1,DoYourOutsideDialing exten = _3XXX,1,DoYourInsideDialing exten = _[24-9].,1,DoErrorHandling exten = _X,1,DoErrorHandling -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 1:11 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 pattern to not trigger the shorter timeout. It seems to me that if 3/8 second timeouts are standard and a catch-all for fancy messages is commonplace, then the two should work together without too much trouble, but instead they are currently mutually exclusive. I realize that a code change will be required to accomplish standard 3/8 second wait times AND be able to get a fancy message (I'll be submitting an issue to jira - I'm thinking add a special 'no pattern matched' extension like i or t). For the time being, I have the catch-all disabled at the site and things are running smoother. Thanks
Re: [asterisk-users] analog phone digit delay
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 with custom 'please try your call again' catch-alls, since it invalidly makes the dialplan think it's found a valid extension, when in fact it has just found error handling code. I've conceded in the fact that getting this to work in asterisk today *could* be accomplished if a more tedious dialplan was put into place (as I said before, I'm using freepbx so this is a more difficult option). My concern here is more about how we can make the functionality *better* in future asterisk versions. As for your example, even with _X if the user picks up and dials 1 the result is that 3 seconds later they will flow into error handling, where I think the intension is that they should get a full 8 seconds. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 1:57 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 issue with good dialplan planning like in my example. -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 4:53 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 is compounded by the fact that the patter is _X. instead of _X but the core issue is the same - only getting 3 second inter-digit timeouts instead of 8. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 12:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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 excessive delay when dialing extensions or PSTN numbers in the setup below. Calls should match when the last digit is dialed for those calls. For invalid numbers
Re: [asterisk-users] analog phone digit delay
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 extensions, you'll never have anyone waiting 8 seconds after they've finished dialing, because once they've dialed a valid number (which would match only one extension), it continues instantly without any timeout at all. I agree, this would be nice. Really though, what we're talking about is a distinct pattern in the last priority slot that refers to 'everything that hasn't already matched something else'. And that slot leaving the timeout at 8 seconds instead of changing it to 3. It seems silly to me to have to jump through a bunch of hoops in the dialplan just to add matching patterns for an anti-match; it should be something provided for in the codebase. So, in addition to the previous 3 options, there's now a fourth: 4) Change error handling code to not be a match-all, but rather a pattern (or patterns) that don't allow for overlap between themselves and the 'valid' extension patterns above them, so that there is no ambiguity between the 'valid' patterns and the 'error handling' patterns. I agree that this would work, but I think the labor involved with maintaining it would be high. And of course, I'm using FreePBX (I guess I could put in a request to change this for FreePBX, but then I'm sure there's others like AsteriskNOW that would also need to change, so it makes more sense having this within asterisk itself). -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Chad Wallace Sent: Thursday, July 11, 2013 2:05 PM To: asterisk-users@lists.digium.com Subject: Re: [asterisk-users] analog phone digit delay On Thu, 11 Jul 2013 13:53:27 -0700 Justin Killen jkil...@allamericanasphalt.com 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 digit before it considers it done. The issue I am describing is compounded by the fact that the patter is _X. instead of _X but the core issue is the same - only getting 3 second inter-digit timeouts instead of 8. Well, if you want an 8 second inter-digit timeout, you can do that by changing the DAHDI source. If you don't have any ambiguity in your extensions, you'll never have anyone waiting 8 seconds after they've finished dialing, because once they've dialed a valid number (which would match only one extension), it continues instantly without any timeout at all. So it looks like you'll need both fixes--and then you can have it all. -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 12:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] analog phone digit delay 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, then there would be an 8 second delay all the time, even when dialing a number like 3001, which IMHO is excessive (and what I was referring to in the previous post). So, again: my two options as before: 1) Have the timeout be so short (3 seconds) that users complain (but they get a fancy message). 2) The timeouts are reasonable (8 seconds), but when they're wrong the users get a busy signal (no fancy message). Plus we can add a third option: 3) Alter chan_dahdi.c to increase matchdigittimeout to 8 seconds, then: The timeouts on invalid extensions are reasonable (8 seconds), but timeouts are valid extensions are excessive (8 seconds), and we get a fancy message. It's a shame that reasonable timeouts and a nice message are mutually exclusive. -Justin -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling Sent: Thursday, July 11, 2013 10:34 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re:
