[asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call

[MENEAULT Maxime]

I am experiencing the same issue as syd wonder.

Basically when calling out on a analog channel (using dtmf deferred 
dialing) the number is not dialed at all. That's why we hear a dialtone.

Hopefully I can tell you more about the issue,
this is a regression due to commit revision 3490 from zaptel:

(merging dtmf-twister branch plus a few fixes)

move DTMF/MF generation into tonezone.c (libtonezone) so that it can 
happen at runtime instead of compile time; this allows for DTMF/MF to be 
different on a zone-by-zone basis without requiring a recompile of Zaptel

set DTMF 'twist' for Brazil (zone 'br') to 2dB
===============================================

kpfleming maybe of some help...

syd wonder wrote:
> Yes, using module unload / load from CLI didn't shut the trunk down as did Zap restart.  I've took a stab at capturing the debug log from Chan_zap.c as it outputs when 1.4.7.1 and 1.4.8 were installed (Make install).  You can see that there is an exception 14 generated when 1.4.8 is installed.  Also, I noticed an error message (I think from ztcfg during boot when 1.4.8 was installed) about and error trying to load loadzone=us from zaptel.conf.  I don't know think this is a problem since it didn't complain about loading defaultzone=us (or does the load stop on first error?).  I've removed ZTdummy from my loaded modules, just have wcfxo and wcusb loaded.  Does this output provide any further insight?
>  
> 1.4.8[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Using channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Dialing '4165551212'[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Deferring dialing...[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Exception on 14, channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Got event Hook Transition Complete(12) on channel 1 (index 0)[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Exception on 14, channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Got event Dial Complete(9) on channel 1 (index 0)[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Enabled echo cancellation on channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Engaged echo training on channel 1[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Exception on 14, channel 1[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Got event Dial Complete(9) on channel 1 (index 0)[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Echo cancellation already on
>  
> 1.4.7.1[Jan 19 13:07:54] DEBUG[4095] chan_zap.c: Dialing '4165551212'[Jan 19 13:07:54] DEBUG[4095] chan_zap.c: Deferring dialing...[Jan 19 13:07:56] DEBUG[4095] chan_zap.c: Engaged echo training on channel 1[Jan 19 13:07:58] DEBUG[4095] chan_zap.c: Echo cancellation already on
>  
> Syd
>> Date: Sat, 19 Jan 2008 01:21:28 +0200> From: tzafrir.cohen at xorcom.com> To: asterisk-dev at lists.digium.com> Subject: Re: [asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call> > On Fri, Jan 18, 2008 at 06:03:09PM -0500, syd wonder wrote:> > > > Thanks Tzafrir, kinda weird results though. > >> > cat /sys/module/zaptel/version did report 1.4.8 was installed once > > I issued the ./live_zap unload, load sequence. I was able to make > > a call out through the FXO fine. Not being certain that everything > > was loaded I decided to issue a "zap restart" command from the CLI. > > This totally shut down the trunk. > > If instead you use 'module unload chan_zap.so' followed by: 'module load> chan_zap.so', is it any better?> > > When I issued a "Zap show status" > > command I noticed that ZTDummy/1 was no longer present. If I am > > interpreting the status returned text correctly, ZTDummy is the > > source of my clocking so this scenario of totally loos
ing the trunk > > makes sense. Why would it show ZTDummy (RTC) when I have an FXO card?> > You don't need ztdummy if you have a hardware device. > > -- > Tzafrir Cohen> icq#16849755 jabber:tzafrir.cohen at xorcom.com> +972-50-7952406 mailto:tzafrir.cohen at xorcom.com> http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir> > _______________________________________________> --Bandwidth and Colocation Provided by http://www.api-digital.com--> > asterisk-dev mailing list> To UNSUBSCRIBE or update options visit:> http://lists.digium.com/mailman/listinfo/asterisk-dev
> _________________________________________________________________
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev