Summary:	ASTERISK-13003: pulsedial=yes does not work
Reporter:	Tony Lill (ajlill)	Labels:
Date Opened:	2008-11-02 13:20:35.000-0600	Date Closed:	2008-11-04 13:22:15.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_zap
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Setting pulsedial=yes in zapata.conf does not work. I added debugging statements in process_zap and the file is being parsed properly, and the field  confp->chan.pulse is being set correctly. However, the value is being reset to 0 somewhere, and so it only tries to tone dial. I added an extra line so 'zap show channel' will print the value of that field, and it is 0. This is on Debian Etch. When I was using 1.2.x, it worked fine.
Comments:	By: Tzafrir Cohen (tzafrir) 2008-11-03 01:49:03.000-0600 WORKSFORME. Have you actually tried dialing? But I can easily understand why you were confused. You seem to be confusing two items in the zt_pvt / dahdi_pvt struct (the structure that defines a Zaptel/DAHDI hardware channel). pulse:  send pulse tones to this phones. Meaningful only in places where we  dial to channels that can accept pulse dialing (analog FXO channels,  basically). pulsedial:  The phone is sending me pulses rather than DTMF digits. Applicable mostly  to analog FXS channels. "Pulse phone" in 'zap show channels' shows the value of 'pulsedial'. I wonder if 'dahdi show channels' show show different vlaues for FXO channels to redue confusion. Leaving it open for now just because I got confused enough until I figured it works for me. By: Tony Lill (ajlill) 2008-11-03 19:05:59.000-0600 If I could place a call on that PSTN line, I wouldn't be opening a bug report, now would I ?-} When you say it works for you, does that mean it placed a call, or that you actually verified that it was pulsing. In spite of the stupid names for those variables, I haven't confused them. As an aside, since you've done an s/zt/dahdi/g between .21 and .22, how about renaming those variables to something less confusing, like pulsehandset and pulsetrunk. As I said in in my original report, I ADDED a line of output to 'zap show channel' to display the pulse variable. I also have debug output that shows the dop.dialstr being constructed as T#######w instead of P#######w, and I have a handset on that trunk so I could listen to it try to tone dial. By: Tzafrir Cohen (tzafrir) 2008-11-04 01:31:29.000-0600 The "WORKSFORME" is because it indeed dialed pulses. Checked it by listening on the line. Version: 1.4.21.2 from Debian packages. Can you post your zapata.conf? Any chance this gets overriden in users.conf? By: Tony Lill (ajlill) 2008-11-04 08:09:48.000-0600 I don't have a users.conf file. Here's the zapata.conf file. ;autogenerated by /usr/local/sbin/config-zaptel  do not hand edit ;Zaptel Channels Configurations (zapata.conf) ; ;For detailed zapata options, view /etc/asterisk/zapata.conf.orig [trunkgroups] [channels] context=default usecallerid=no hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no relaxdtmf=yes rxgain=3.0 txgain=0.0 group=1 callgroup=1 pickupgroup=1 immediate=no ;Sangoma A200 [slot:10 bus:0 span:1]  <wanpipe1> context=downstairs group=1 signalling = fxo_ks channel => 1 context=upstairs group=1 signalling = fxo_ks channel => 2 context=work-line group=0 signalling = fxs_ks channel => 3 rxgain=5.0 context=home-line group=0 signalling = fxs_ks channel => 4 pulsedial = yes pulse = yes rxgain=5.0 By: Tzafrir Cohen (tzafrir) 2008-11-04 08:19:12.000-0600 pulsedial here has no effect . It is after the last 'channel' line. In 1.2.13 it did have effect, I think, but only after a reload. This was due to a bug in the parsing of the configuration that was fixed since. By: Jason Parker (jparker) 2008-11-04 13:22:11.000-0600 As tzafrir stated, this appears to be a configuration issue. Move the line up to before the channel(s) that you wish to have use it.