[asterisk-users] DAHDI inter-digit timeout = 0
Chris.Sohns at discoveryresearchgroup.com
Thu Apr 12 10:46:09 CDT 2012
>> I've had an old server die on me, it was installed by someone else
>> then never maintained. It runs some old version of Elastix on top of
>> Asterisk 1.4.33 with 4x Digium T100P cards. I swapped all the parts
>> into a referb of the same gear and it runs great, but I want to put it
>> in a completely new box. The OS on the old drives was too old to talk
>> to the embedded chipset in the new server so I installed whatever
>> version of Elastix was in the current production repo (Asterisk 1.8.7)
>> and rebuilt the configs from the ground up to utilize a new Digium
>> Long story short, this is the first time I've worked with hardware
>> cards, so I obviously missed something. When a line is picked up, I
>> get dial tone but it immediately goes to a busy signal after the first
>> digit is pressed. I get the same result when I use the new T420P and
>> an old T100P. The log below was generated when I hit 8, three times,
>> as quickly as possible. It's only seeing the first 8 then dumps that 8
>> to extension 'stations' which has no '8', thus the busy signal.
>> "timeout = 0" is my only lead. Set(TIMEOUT(digits)=X) has no affect
>> since the timeout occurs before the call hits the dialplan context, so
>> methinks the issue lies elsewhere. Four hours in, my forehead raw
>> from being smashed against hard surfaces, said "elsewhere" has eluded
>> me... Suggestions? I'm looking for a slap to the face and a finger
>> pointing to my stupid oversight. RTFM + intertubes have failed me (or
>> I them)
>> DEBUG chan_dahdi.c: Monitor doohicky got event Ring/Answered on
>> channel 5 DEBUG sig_analog.c: channel (5) - signaling (2) -
>> DEBUG dsp.c: Setup tone 1100 Hz, 500 ms, block_size=160,
>> DEBUG dsp.c: Setup tone 2100 Hz, 2600 ms, block_size=160,
>> DEBUG sig_analog.c: __analog_ss_thread 5
>> VERBOSE sig_analog.c: -- Starting simple switch on
>> DEBUG devicestate.c: No provider found, checking channel drivers
>> for DAHDI - 5 DEBUG devicestate.c: Changing state for DAHDI/5 -
>> state 2 (In
>> DEBUG devicestate.c: device 'DAHDI/5' state '2'
>> DEBUG sig_analog.c: Begin DTMF digit: 0x38 '8' on DAHDI/5-1
>> DEBUG chan_dahdi.c: Begin DTMF digit: 0x38 '8' on DAHDI/5-1
>> DEBUG sig_analog.c: End DTMF digit: 0x38 '8' on DAHDI/5-1
>> DEBUG chan_dahdi.c: End DTMF digit: 0x38 '8' on DAHDI/5-1
>> DEBUG sig_analog.c: waitfordigit returned '8' (56), timeout =
>> DEBUG sig_analog.c: Can't match 8 from '1505' in context
>> stations DEBUG channel.c: Hanging up channel 'DAHDI/5-1'
>> DEBUG chan_dahdi.c: dahdi_hangup(DAHDI/5-1) DEBUG
>> sig_analog.c: analog_hangup 5 DEBUG sig_analog.c: Hangup:
>> channel: 5 index = 0, normal = 1, callwait = 0, thirdcall = 0
>> DEBUG chan_dahdi.c: Set option TONE VERIFY, mode: OFF(0) on
>> DEBUG chan_dahdi.c: Set option TDD MODE, value: OFF(0) on
>> DEBUG sig_analog.c: Updated conferencing on 5, with 0
>> conference users
>> VERBOSE sig_analog.c: -- Hanging up on 'DAHDI/5-1'
>> VERBOSE chan_dahdi.c: -- Hungup 'DAHDI/5-1'
>Your "clue" of timeout=0 is a red herring. The timeout variable printed is unconditionally set to zero a few lines before the debug message is printed.
>The problem is the dialplan context 'stations' does not have an extension starting with '8'. It is either the wrong context or you need to add an extension to the 'stations' context in your dialplan. The initial context that your phone is going to start in is configured in chan_dahdi.conf. See the chan_dahdi.conf.samples file for more information.
The '8' was just an example, I couldn't dial anything at all. The system instantly kicks to busy before I can enter the second digit. My previous experience with Adtran 900e series analog equipment told me extension pattern matching began after the initial digit timeout, but apparently not when it comes to these Digium cards. I had always *presumed* context 'stations' existed because I copied over all the files from the old server, but I had never actually checked it. Previous versions of Asterisk would have told me the dialplan context did not exist, at least it does for IAX2 and SIP channels.
I cannot exactly test it right now, lacking onsite personnel to swap spans around, but that was most likely the problem. I appreciate the metaphoric face slap, thank you!
More information about the asterisk-users