[asterisk-bugs] [JIRA] Commented: (ASTERISK-20082) Phantom calls open analog DAHDI switch and send dialplan into loop, causing /var to fill up with logs
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Thu Jul 19 16:32:21 CDT 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-20082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195017#comment-195017 ]
Rusty Newton commented on ASTERISK-20082:
-----------------------------------------
bq. Rusty - I have already stated that regular analog calls do work with this dialplan, and do not get stuck in any kind of loop. It's definitely only these weird non-legitimate calls, which always have no caller ID
Based on your dialplan alone I don't understand how any DAHDI based call without DID(not CallerID) would make it out of the loop you constructed without other factors involved besides just that dialplan. You would need to post CLI debug showing a working analog call being answered for us to understand the call path better. Never-the-less, that loop just adds complication, so it should be fixed before troubleshooting any further.
bq. and somehow trick Asterisk into thinking they should have SIP functions applied to them.
You have instructed Asterisk, via dialplan, to CUT a SIP_HEADER on a DAHDI channel. Asterisk is attempting to do what it has been instructed to do.
bq. The loop is only due to the fact that these are not legitimate calls.
If a DAHDI channel, legitimate call or not, enters the three lines of dialplan I referenced on 06/Jul/12 4:57 PM, and Asterisk is behaving appropriately - once hitting the Goto, it should always Goto s,n,1 as ${TOLLFREENUM} would never be populated, seeing as there is no SIP headers on a DAHDI channel. *Any* DAHDI channel should not break out of that loop based on the dialplan alone. Are you doing something AMI or another method to send that channel elsewhere?
bq. Sure, the dialplan could be modified to prevent the loop, but the calls shouldn't be picked up, and even if they are, Asterisk shouldn't be attempting to apply SIP functions to these channels. The fact that it doesn't when a valid call comes in should be enough to show this is more than just a dialplan issue, no?
If DAHDI tells Asterisk that a ring is occurring , it will pick it up. You need to find out whether a ring is occurring on the line or not, and if there is a problem with the line, the board or your driver before looking further into Asterisk.
Asterisk is telling you the SIP function can only be applied on a SIP channel, because your dialplan inappropriately instructs Asterisk to apply the function to a DAHDI channel.
The debug and dialplan we have here does not indicate an issue outside of dialplan. The possibility exists, and we are attempting to point you in the right direction so you can troubleshoot the line, board and driver.
Please contact the support group for the manufacturer of your board and they should help troubleshoot whether there is an issue with the line, board or driver.
bq. I should also note that this does not occur with Asterisk 1.4, using the same dialplan. The only difference is the version of Asterisk and the fact that the 1.4 installation uses Zaptel instead of DAHDI. The hardware, analog lines, telco, and configuration are all otherwise identical.
Thanks for additional information, but it working in an extremely old version of Asterisk and DAHDI doesn't help us out here.
Again, we are trying to help you solve this issue. Contacting your board vendor will get you on the right path. If this is a Digium board, please call 1-256-428-6000, option 2 and 2 to get to support.
> Phantom calls open analog DAHDI switch and send dialplan into loop, causing /var to fill up with logs
> -----------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-20082
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-20082
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Channels
> Affects Versions: 1.8.11.1
> Environment: Ubuntu Server 10.04 (Lucid)
> root at phone1:~# uname -a
> Linux phone1 2.6.32-40-server #87-Ubuntu SMP Tue Mar 6 02:10:02 UTC 2012 x86_64 GNU/Linux
> ii asterisk 1:1.8.11.1-1digium1~lucid Open Source Private Branch Exchange (PBX)
> ii asterisk-config 1:1.8.11.1-1digium1~lucid Configuration files for Asterisk
> ii asterisk-core-sounds-en-gsm 1.4.21-1digium1~lucid asterisk PBX sound files - English/gsm
> ii asterisk-dahdi 1:1.8.11.1-1digium1~lucid DAHDI devices support for the Asterisk PBX
> ii asterisk-dev 1:1.8.11.1-1digium1~lucid Development files for Asterisk
> ii asterisk-doc 1:1.8.11.1-1digium1~lucid Source code documentation for Asterisk
> ii asterisk-moh-opsound-wav 2.03-1digium1~lucid asterisk extra sound files - English/wav
> ii asterisk-sounds-extra 1.4.9-1 Additional sound files for the Asterisk PBX
> ii asterisk-voicemail 1:1.8.11.1-1digium1~lucid simple voicemail support for the Asterisk PB
> ii dahdi 1:2.2.1-0ubuntu2 utilities for using the DAHDI kernel modules
> ii dahdi-dkms 1:2.2.1+dfsg-1ubuntu2 DAHDI telephony interface (dkms kernel drive
> ii dahdi-linux 1:2.2.1+dfsg-1ubuntu2 DAHDI telephony interface - Linux userspace
> Reporter: Ryan Steele
> Assignee: Rusty Newton
> Severity: Critical
> Attachments: asterisk_debug_log-07.03.2012.txt, chan_dahdi.conf, init.conf, modules, system.conf
>
>
> After starting Asterisk, it takes (at most) an hour or two before I seeing calls come in on the analog lines, even when no legitimate call is actually coming in. (Note: I can make successful calls on the analog channels, and they do not appear to cause this issue). For some reason, only these phantom calls trigger the "chan_sip.c: This function can only be used on SIP channels." error, at which point the dialplan goes into an endless loop:
> [Jun 21 13:00:35] VERBOSE[26635] sig_analog.c: -- Starting simple switch on 'DAHDI/1-1'
> [Jun 21 13:00:41] WARNING[26635] chan_sip.c: This function can only be used on SIP channels.
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:1] Set("DAHDI/1-1", "TOLLFREENUM=") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:2] NoOp("DAHDI/1-1", ""Toll free number dialed is: "") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:3] Goto("DAHDI/1-1", ",1") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Goto (inbound,s,1)
> [Jun 21 13:00:41] WARNING[26635] chan_sip.c: This function can only be used on SIP channels.
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:1] Set("DAHDI/1-1", "TOLLFREENUM=") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:2] NoOp("DAHDI/1-1", ""Toll free number dialed is: "") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:3] Goto("DAHDI/1-1", ",1") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Goto (inbound,s,1)
> [Jun 21 13:00:41] WARNING[26635] chan_sip.c: This function can only be used on SIP channels.
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:1] Set("DAHDI/1-1", "TOLLFREENUM=") in new stack
> [Jun 21 13:00:41] VERBOSE[26635] pbx.c: -- Executing [s at inbound:2] NoOp("DAHDI/1-1", ""Toll free number dialed is: "") in new stack
> This repeats endlessly until /var fills up, which causes Asterisk to crash, and kills performance until it does. Again, there is no call coming in to trigger this. I turned down the rxgain to 0 as a test (since doing so makes the phone audio kind of quiet), but I am still seeing this with a regularity that makes it unfeasible to move to these new phone servers (we are currently running an ancient 1.4, and are ready to move to 1.8 once this issue is squashed).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list