[Home]

Summary:ASTERISK-18209: Dialing an incomplete number via dahdi causes a timeout
Reporter:Gareth Blades (gblades_skymarket)Labels:
Date Opened:2011-07-29 04:54:30Date Closed:2011-08-03 12:43:12
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_dial
Versions:1.6.2.17 Frequency of
Occurrence		Constant
Related
Issues:
Environment:centos 5.6 64bit (kernel 2.6.18-238.5.1.el5) libpri-1.4.11.5 dahdi-linux-complete-2.4.1.1+2.4.1 wanpipe-3.5.18Attachments:( 0) example1.txt
( 1) example2.txt
Description:When dialing out via dahdi to a number which is incomplete the dialplan hangs for about 5 seconds and then gets a timeout
Comments:By: Gareth Blades (gblades_skymarket) 2011-07-29 04:58:01.503-0500

Example asterisk log showing the timeout
By: Gareth Blades (gblades_skymarket) 2011-07-29 05:00:31.648-0500

Second example of a more complex call. This time rather than a timeout it jumps back to step 1 of the current context.
By: Gareth Blades (gblades_skymarket) 2011-07-29 05:03:11.423-0500

Attached a couple of examples. Example 1 shows a simple call to a number which is too short (incomplete) and the dialplan seems to pause after the dial and not go onto the following command. After about 5 seconds it times out and goes to the t extension.

Example 2 is even stranger. In this example the dialplan hangs again but instead of timing out it jumps back to step 1 in the current context.
By: David Woolley (davidw) 2011-07-29 05:17:24.218-0500

That version is no longer supported.  It is also not clear to me why you think this is a bug.

To proceed, you will need to reproduce this on a 1.8 series version and explain why this should not be expected behaviour.
By: Gareth Blades (gblades_skymarket) 2011-07-29 05:44:23.174-0500

How can it possibly be expected behavior?

2011-07-28 11:28:45 | pbx.c:     -- Executing [01268372298@service_nts_nextgen_v2:56] Dial("DAHDI/85-1", "DAHDI/g1/0800849616,,M(service-nts-nextgenv2-register-answer)") in new stack
2011-07-28 11:28:45 | chan_dahdi.c:     -- Requested transfer capability: 0x00 - SPEECH
2011-07-28 11:28:45 | app_dial.c:     -- Called g1/0800849616
2011-07-28 11:28:45 | app_dial.c:     -- DAHDI/23-1 is proceeding passing it to DAHDI/85-1
2011-07-28 11:28:45 | app_dial.c: Unable to forward voice or dtmf
2011-07-28 11:28:45 | chan_dahdi.c:     -- Hungup 'DAHDI/23-1'
2011-07-28 11:28:45 | app_dial.c:   == Everyone is busy/congested at this time (1:0/0/1)
2011-07-28 11:28:45 | pbx.c:   == Spawn extension (service_nts_nextgen_v2, 01268372298, 56) exited INCOMPLETE on 'DAHDI/85-1'

^^^ If a call failed then the dialplan should continue at the next priority. It should not hang until there is a timeout.

2011-07-28 11:28:50 | pbx.c:     -- Timeout on DAHDI/85-1
2011-07-28 11:28:50 | pbx.c:   == CDR updated on DAHDI/85-1
2011-07-28 11:28:50 | pbx.c:     -- Executing [t@service_nts_nextgen_v2:1] NoOp("DAHDI/85-1", "StopMixMonitor") in new stack





2011-07-28 14:54:26 | pbx.c:     -- Executing [08000125245@service_nts_nextgen_v2:56] Dial("DAHDI/52-1", "DAHDI/g1/0116254661,,M(service-nts-nextgenv2-register-answer)") in new stack
2011-07-28 14:54:26 | chan_dahdi.c:     -- Requested transfer capability: 0x00 - SPEECH
2011-07-28 14:54:26 | app_dial.c:     -- Called g1/0116254661
2011-07-28 14:54:26 | app_dial.c:     -- DAHDI/10-1 is proceeding passing it to DAHDI/52-1
2011-07-28 14:54:26 | chan_dahdi.c:     -- Hungup 'DAHDI/10-1'
2011-07-28 14:54:26 | app_dial.c:   == Everyone is busy/congested at this time (1:0/0/1)
2011-07-28 14:54:26 | pbx.c:   == Spawn extension (service_nts_nextgen_v2, 08000125245, 56) exited INCOMPLETE on 'DAHDI/52-1'
2011-07-28 14:54:30 | pbx.c:   == CDR updated on DAHDI/52-1
2011-07-28 14:54:30 | pbx.c:     -- Executing [080001252456@service_nts_nextgen_v2:1] Set("DAHDI/52-1", "__channel1=1311861250.12137_6") in new stack

This example is even worse. Instead of timing out it hangs and then jumps to priority 1 which can lead to totally unexpected behavior and I would argue is a security issue as it can result is the dialplan/billing being exploited.
By: Gareth Blades (gblades_skymarket) 2011-07-29 05:46:28.469-0500

Forgot to include the worst example in previous comment (this is from example2.txt) :-

2011-07-28 14:54:26 | pbx.c:     -- Executing [08000125245@service_nts_nextgen_v2:56] Dial("DAHDI/52-1", "DAHDI/g1/0116254661,,M(service-nts-nextgenv2-register-answer)") in new stack
2011-07-28 14:54:26 | chan_dahdi.c:     -- Requested transfer capability: 0x00 - SPEECH
2011-07-28 14:54:26 | app_dial.c:     -- Called g1/0116254661
2011-07-28 14:54:26 | app_dial.c:     -- DAHDI/10-1 is proceeding passing it to DAHDI/52-1
2011-07-28 14:54:26 | chan_dahdi.c:     -- Hungup 'DAHDI/10-1'
2011-07-28 14:54:26 | app_dial.c:   == Everyone is busy/congested at this time (1:0/0/1)
2011-07-28 14:54:26 | pbx.c:   == Spawn extension (service_nts_nextgen_v2, 08000125245, 56) exited INCOMPLETE on 'DAHDI/52-1'
2011-07-28 14:54:30 | pbx.c:   == CDR updated on DAHDI/52-1
2011-07-28 14:54:30 | pbx.c:     -- Executing [080001252456@service_nts_nextgen_v2:1] Set("DAHDI/52-1", "__channel1=1311861250.12137_6") in new stack

By: Gareth Blades (gblades_skymarket) 2011-07-29 06:19:26.929-0500

Actually I have just noticed in this second example after the dial it actually jumps to 080001252456,1 which is the original extension with a '6' added to the end of it. Looks like some internal memory or variable is being corrupted.
By: David Woolley (davidw) 2011-08-01 09:13:22.610-0500

2011-07-28 11:28:45 | pbx.c: == Spawn extension (service_nts_nextgen_v2, 01268372298, 56) exited INCOMPLETE on 'DAHDI/85-1'

^^^ If a call failed then the dialplan should continue at the next priority. It should not hang until there is a timeout.


The INCOMPLETE doesn't represent a call that has failed.  It means that more digits are needed.  I would expect Asterisk to wait for those additional digits to arrive, or for a timeout, and that looks to me to be what has happened.
By: Gareth Blades (gblades_skymarket) 2011-08-01 10:04:39.792-0500

Ok I can sort of understand that. At least the part about waiting for extra digits.

But what seems very odd to me is assuming the dial command waited and got further digits via DTMF why didnt it just try dialing the new longer number?
Instead I assume it added the extra digits onto the current extension and jumped to priority 1. It seems very odd that would happen as how could you possibly control the call flow when you cant predict what extension will be jumped to next?

It may be just me but if I call the Dial application I would expect it to dial or give an error.
Is there any way this functionality can be disabled so the Dial returns straight away if the number is incomplete?
I cant see any appropriate Dial parameters. Can the digit and response timeout be set to zero so they fail straight away?

By: David Woolley (davidw) 2011-08-01 10:12:56.716-0500

Those are support questions, and, even if I knew the answers, without looking, this would be the wrong place to supply them.  http://www.asterisk.org/support
By: Paul Belanger (pabelanger) 2011-08-03 12:43:05.664-0500

Thanks for your comments. This does not appear to be a bug report and we are closing it. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker, http://www.asterisk.org/support.