[asterisk-users] Trouble with upgrading - RBS T1

Russ Meyerriecks rmeyerriecks at digium.com
Tue Dec 10 16:18:56 CST 2013


Looks like DTMF tone generation is too short. That first digit '7'
only lasted 0ms. The rest of the digit tone durations look about right
(80ms). Does this happen on every dial sequence, or just the first?

On Tue, Dec 10, 2013 at 8:35 AM, Ryan Wagoner <rswagoner at gmail.com> wrote:
> I have a system with two Sangoma A104D cards running Asterisk 1.8.11-cert10,
> Dahdi 2.5.0.1, LibPRI 1.4.12, and Wanpipe 3.5.23. The PRI spans are
> configured with esf,b8zs. Everything has been working great, which is why I
> haven't updated it further. You might try an older Dahdi version just to
> see. Although this might be tricky depending on the OS version.
>
> Ryan
>
>
> On Mon, Dec 9, 2013 at 5:56 PM, Jeff LaCoursiere <jeff at jeff.net> wrote:
>>
>> Upgrading an ancient customer installation... was running 1.4.23.1
>> (Trixbox) with Zaptel 1.4.12.9 and a Sangoma A102D, which has been running
>> fine for 5+ years.  Customer getting anxious about hardware failure, so we
>> built a new box and installed 1.8.24.0, Dahdi 2.7.0.1, and a new Sangoma
>> A104D.  The single active span is an RBS T1 B8ZS/ESF/E&M Wink.
>>
>> I tried to move one span over one night which was working fine on the old
>> box.  Once plugged in there were no alarms, Sangoma wanpipemon utility
>> showed "connected".  I tried calling in on a DID number, and in the 'full'
>> log, with debug and verbose set to 100:
>>
>> [Dec  5 00:51:37] VERBOSE[5283] sig_analog.c:     -- Starting simple
>> switch on 'DAHDI/9-1'
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=1.17E+04, Et=1.45E+06,
>> s/n=      0.01
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=2.76E+03, Et=1.10E+06,
>> s/n=      0.00
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=2.06E+04, Et=1.39E+06,
>> s/n=      0.01
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=4.68E+03, Et=1.40E+06,
>> s/n=      0.00
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00,
>> s/n=      -nan
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00,
>> s/n=      -nan
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00,
>> s/n=      -nan
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00,
>> s/n=      -nan
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00,
>> s/n=      -nan
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=1.30E+10, Et=2.11E+12,
>> s/n=      0.01
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: analog_exception 9
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: Exception on 15, channel 9
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: __analog_handle_event 9
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: Got event
>> UNKNOWN/OTHER(131127) on channel 9 (index 0)
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: DTMF Down '7'
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: Begin DTMF digit: 0x37 '7' on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DEBUG[5283] chan_dahdi.c: Begin DTMF digit: 0x37 '7' on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DTMF[5283] channel.c: DTMF begin '7' received on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DTMF[5283] channel.c: DTMF begin ignored '7' on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=2.02E+10, Et=4.01E+12,
>> s/n=      0.01
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=1.88E+10, Et=3.89E+12,
>> s/n=      0.00
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=4.78E+10, Et=1.17E+12,
>> s/n=      0.04
>> [Dec  5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=5.10E+03, Et=6.26E+06,
>> s/n=      0.00
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: analog_exception 9
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: Exception on 15, channel 9
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: __analog_handle_event 9
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: Got event
>> UNKNOWN/OTHER(262199) on channel 9 (index 0)
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: Detected digit '7'
>> [Dec  5 00:51:38] DEBUG[5283] sig_analog.c: End DTMF digit: 0x37 '7' on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DEBUG[5283] chan_dahdi.c: End DTMF digit: 0x37 '7' on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DTMF[5283] channel.c: DTMF end '7' received on
>> DAHDI/9-1, duration 0 ms
>> [Dec  5 00:51:38] DTMF[5283] channel.c: DTMF end accepted without begin
>> '7' on DAHDI/9-1
>> [Dec  5 00:51:38] DTMF[5283] channel.c: DTMF end passthrough '7' on
>> DAHDI/9-1
>> [Dec  5 00:51:38] DEBUG[5283] chan_dahdi.c: Enabled echo cancellation on
>> channel 9
>> [Dec  5 00:51:38] VERBOSE[5283] sig_analog.c:     -- Unknown extension '7'
>> in context 'from-pstn' requested
>> ...
>>
>> At this point I hear 'invalid extension' and get hung up on, but if you
>> grep out all the DTMF events from this call, you get:
>>
>> root at astsouth:/var/log/asterisk# grep 'DTMF end' /tmp/foo | grep received
>> [Dec  5 00:51:38] DTMF[5283] channel.c: DTMF end '7' received on
>> DAHDI/9-1, duration 0 ms
>> [Dec  5 00:51:41] DTMF[5283] channel.c: DTMF end '1' received on
>> DAHDI/9-1, duration 80 ms
>> [Dec  5 00:51:41] DTMF[5283] channel.c: DTMF end '5' received on
>> DAHDI/9-1, duration 80 ms
>> [Dec  5 00:51:41] DTMF[5283] channel.c: DTMF end '7' received on
>> DAHDI/9-1, duration 80 ms
>> [Dec  5 00:51:41] DTMF[5283] channel.c: DTMF end '6' received on
>> DAHDI/9-1, duration 80 ms
>> [Dec  5 00:51:41] DTMF[5283] channel.c: DTMF end '0' received on
>> DAHDI/9-1, duration 80 ms
>> [Dec  5 00:51:41] DTMF[5283] channel.c: DTMF end '0' received on
>> DAHDI/9-1, duration 80 ms
>>
>> And '715-7600' is the DID number I dialed.  So why is the new box
>> immediately answering the call before it gets all the ANI digits?  I've
>> poured over all Sangoma's docs online for debugging RBS lines - I'm not
>> having any transmission errors, no overruns, and even the audio of 'invalid
>> extension' seems clear before it hangs up on me.
>>
>> The next maintenance window I swapped out the A104D for a Digium TE122.
>> Exactly the same issue!  Some problem with Dahdi then?
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Jeff LaCoursiere
>> SunFone
>>
>> --
>> _____________________________________________________________________
>> -- 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



-- 
Russ Meyerriecks
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
direct: +1 256-428-6025
Check us out at: www.digium.com & www.asterisk.org



More information about the asterisk-users mailing list