Hello
I am trying to set up a pulse dial telephone using Asterisk, plugged in via a Sangoma A200 card.
My setup has been working flawlessly with a DTMF phone for years.
I have tested the pulse dial telephone directly plugged into a BT socket and it is fully working.
When the pulse dial telephone is plugged into Asterisk I am only able to receive calls.
When I lift the receiver to make a call I get a dial tone from Asterisk and the Asterisk CLI shows as expected:
Starting simple switch on ‘DAHDI/1-1’
When I dial a number, no output is displayed and eventually times out as Asterisk received no number to dial.
The command “dahdi show channel 1” lists within its output:
Pulse phone: no
I would have expected that line to state ‘yes’ as I have set pulsedial=yes in the chan_dahdi.conf - or does this output not relate to that setting?
I have tried both kewlstart and loopstart signalling without any difference in CLI output.
Any advice gratefully received,
Jason
Not a direct answer, but the ability to pulse dial on BT is going away. It was going to be completely gone by 2025, but the role out of Digital Voice was put on hold last week. The hold will probably only delay it about a year.
The general policy of this forum used to be that support for configuring cards should be obtained from the card supplier, and, in any case, I’m not aware of any DAHDI expert who frequents this forum, let alone one that still uses loop disconnect dialling.
Hi David
Thanks for your reply. I am aware of the changes BT are making, that is one reason I am keen to get the pulse dial telephone to dial via Asterisk, so I can continue to use it over a VOIP lines come 2025/6.
I will post my question on a DAHDI forum too as it may get more relevant views.
Jason
Pulse dialing definitely works in DAHDI as I use it quite frequently without any issues.
Regardless of what BT is doing, most good ATAs nowadays (all Grandstream ones, at least) support pulse dialing as well. Many digital voice interfaces such as FiOS also support pulse dialing, so it’s not like it’s going away.
“Pulse phone:” in dahdi show channel shows you whether DAHDI has detected a pulse dialed digit for the current call. It does not reflect the value of pulsedial=yes in chan_dahdi.conf.
Furthermore, pulsedial=yes is not the right setting anyways. That is for FXO ports (FXS signalled) telling it whether outpulsing should use dial pulse rather than DTMF. Pulse dialing is currently always accepted on DAHDI FXS lines (FXO signaled). I have recently added a feature to allow this to be controlled on a per-channel basis, but it has not yet been merged.
We need some more information: what type of phone are you using exactly? What is the make/break ratio of the dial? Depending on these things, it could be that it’s impairing the ability to pick up pulses.
Additionally, have you tried a different phone? Try a standard rotary phone like a 500 set (or the equivalent there) and see if it dials out. If you have a lineman’s test set, also try that. Those should be very to the specification, 10 pps and 40/60% make break ratio.
Hello Interlinked,
Thank you for clearing up a few things such as the use of pulsedial=yes.
I have made some progress. Turns out the pulse dial was working, I was just not able to see it - I had to enable verbosity on the channel to see the pulses.
Still not working 100% as the digits I dial are not always being interpreted correctly. I can dial from 1 to 0 but the higher I dial, the worse the detection gets. I believe this is due to the cleanliness of the governor.
I have given the governor a quick clean out with a cotton wool bud and this has improved matters significantly but still worse on the higher digits. I am awaiting delivery of some watch oil which I will apply to the mechanism, I hope this will improve the detection even more.
So, now it seems my issue is not Asterisk related but the mechanics of an old rotary phone.
Regards
Jason
I recommend you add “verbose = 4” to your asterisk.conf as there’s no sane reason I can think of to not have verbose always enabled in the CLI. Even without it, though, I would think you would be able to hear whether you were breaking dial tone or not.
Asterisk currently doesn’t deal with dial pulses at all in any meaningful way. Pulses get converted to a DTMF frame as soon as Asterisk gets the events from DAHDI.
I’ve heard other complaints about pulse recognition but it seems to depend on the equipment, dial, etc. rather than any single factor. Sometimes I get an off-by-1-digit, but only rarely.
If you are doing some testing, you may find the dial pulse module I added to Asterisk to be helpful: phreakscript/res_dialpulse.c at master · InterLinked1/phreakscript · GitHub
You can run a dial speed test by connecting to that and dialing “0”.
There are some other patches to DAHDI Linux and chan_dahdi and sig_analog required so you would need to recompile all of them.
However, it will indicate the dial speed of your dials and the make/break ratio of your dials so you can see if they are off in any of those ways. Detection reliability can decrease significantly if these metrics are off.
Hi InterLinked
Thanks for your advice, I will take heed.
I realise it is your YouTube demonstration video I saw recently regarding the dial pulse module, I will give it a go.
Thanks
Jason
Hi Interlinked
I have downloaded the module but am getting the following error when attempting to recompile Asterisk with it enabled. I am using the latest Asterisk version 18.11.3:
res_dialpulse.c: In function ‘dspeed_test’:
res_dialpulse.c:158:83: error: ‘AST_CONTROL_PULSE’ undeclared (first use in this function)
} else if (frame->frametype == AST_FRAME_CONTROL && frame->subclass.integer == AST_CONTROL_PULSE) {
^
res_dialpulse.c:158:83: note: each undeclared identifier is reported only once for each function it appears in
res_dialpulse.c: In function ‘dspeed_exec’:
res_dialpulse.c:315:17: error: ‘struct analog_pvt’ has no member named ‘pulsemakecount’
j = analog_p->pulsemakecount < analog_p->pulsebreakcount ? analog_p->pulsemakecount : analog_p->pulsebreakcount;
^
res_dialpulse.c:315:44: error: ‘struct analog_pvt’ has no member named ‘pulsebreakcount’
j = analog_p->pulsemakecount < analog_p->pulsebreakcount ? analog_p->pulsemakecount : analog_p->pulsebreakcount;
^
res_dialpulse.c:315:72: error: ‘struct analog_pvt’ has no member named ‘pulsemakecount’
j = analog_p->pulsemakecount < analog_p->pulsebreakcount ? analog_p->pulsemakecount : analog_p->pulsebreakcount;
^
res_dialpulse.c:315:99: error: ‘struct analog_pvt’ has no member named ‘pulsebreakcount’
j = analog_p->pulsemakecount < analog_p->pulsebreakcount ? analog_p->pulsemakecount : analog_p->pulsebreakcount;
^
res_dialpulse.c:324:26: error: ‘struct analog_pvt’ has no member named ‘pulsebreaks’
maketime += analog_p->pulsebreaks[i] - analog_p->pulsemakes[i];
^
res_dialpulse.c:324:53: error: ‘struct analog_pvt’ has no member named ‘pulsemakes’
maketime += analog_p->pulsebreaks[i] - analog_p->pulsemakes[i];
^
res_dialpulse.c:326:28: error: ‘struct analog_pvt’ has no member named ‘pulsemakes’
breaktime += analog_p->pulsemakes[i] - analog_p->pulsebreaks[i - 1];
^
res_dialpulse.c:326:54: error: ‘struct analog_pvt’ has no member named ‘pulsebreaks’
breaktime += analog_p->pulsemakes[i] - analog_p->pulsebreaks[i - 1];
^
/usr/src/asterisk/asterisk-18.11.3/Makefile.rules:164: recipe for target ‘res_dialpulse.o’ failed
make[1]: *** [res_dialpulse.o] Error 1
Makefile:393: recipe for target ‘res’ failed
make: *** [res] Error 2
You will need to apply some of the patches in this directory: phreakscript/patches at master · InterLinked1/phreakscript · GitHub
(ast_rtoutpulsing and dahdi_rtoutpulse)
The Asterisk patch depends on the DAHDI patch.
Alternately, if you don’t mind installing Asterisk again, you can simply use the script to install it for you with all the patches integrated:
Something like cd /usr/src && wget https://docs.phreaknet.org/script/phreaknet.sh && chmod +x phreaknet.sh && ./phreaknet.sh make
Then phreaknet install --dahdi
(Eventually, I will submit this for inclusion, but I’m going to wait until the DAHDI side goes in before the Asterisk bit can be included).
I sampled a range of version of Asterisk back to 1.0, and none of them defined that symbol in frame.h. I also did the same for chan_dahdi.c and chan_zap.c. I’d suggest that either you haven’t set the right conditionals, or your third party module will only compile against a patched version of Asterisk.
There do seem to be patches for Asterisk, in the distribution, but none of them define AST_CONTROL_PULSE.
Right, AST_CONTROL_PULSE is something I recently added. I haven’t submitted it for inclusion yet in the official version. The patches linked above do add the control frame.
Hi InterLinked
I have recompiled Asterisk and DAHDI without issue now.
I have added to my dial plan:
exten => s,1,DialSpeedTest()
and to DAHDI configuration:
immediate=yes
Upon testing the application answers and I hear the dial tone. I dial 0 and the dialtone stops but then I hear the dialtone again with no output to the CLI.
Could this be that my phone is having trouble dialing the higher numbers, including 0? I can dial 1, 2 and 3 and they are recognised as such, but anything above these (including 0) is not recognised properly. 0 is generally being recognised as a 9.
Regards
Jason
Sorry, my bad again:
In chan_dahdi.conf, add realtimepulsing = yes to the channels you want to test this on. Then it should work.
The application will wait for ten pulses before it generates its report.
No still not working, I will get my hands on another rotary phone later this afternoon to try too.
I suspect it may be a problem with the phone then. Other people have been able to do the test successfully once installing in that manner and enabling that option.
You might try dialing “1” ten times. That would give you the ten pulses, and the report will be generated, although it will be meaningless as the ten pulses did not belong to the same digit so it would think the dial is super slow.
Also, instead of using the dial, you can try “hookswitch dialing” and see where that gets you. It is a bit hard to do a 0 that way though.
Tried with another rotary phone. Still not working. Both phones are working fine when plugged directly into a BT line, I am able to make calls whichever digits I dial.
Dialing 1 does not break dial tone.
The output I get on the CLI when trying to run the test is as follows:
-- Executing [s@test:1] DialSpeedTest("DAHDI/1-1", "") in new stack
-- Started three way call on channel 1
-- Starting simple switch on 'DAHDI/1-2'
-- Executing [s@test:1] DialSpeedTest("DAHDI/1-2", "") in new stack
-- Building conference call with DAHDI/1-1 and DAHDI/1-2
-- TRANSFERRING DAHDI/1-1 to DAHDI/1-2
== Spawn extension (test, s, 1) exited non-zero on ‘DAHDI/1-1’
== Spawn extension (test, s, 1) exited non-zero on ‘DAHDI/1-2’
– Hanging up on ‘DAHDI/1-2’
– Hungup ‘DAHDI/1-2’
– Hanging up on ‘DAHDI/1-1’
– Hungup ‘DAHDI/1-1’
It thinks your dial pulse 1 is a hook flash so the pulse is really long for some reason.
Set immediate=yes in chan_dahdi.conf to disable the simple switch since that will get in the way.
I do know the make/break ratios of dials over in the UK are somewhat different. I know somebody that was testing this type of thing recently, but it worked for him which is odd.
Hi
Already using immediate=yes
I will try building Asterisk from scratch using your script and then see if works, in case I have missed something when building the modules in.
Regards
Jason
The UK equivalent of hook flash, timed break recall, is essentially a loop disconnect 1. If Asterisk is set for the correct timing, it should be distinguishing the two by whether the line is up.
Hmm, that seems a bit odd. I’m not sure how it really can differentiate in that case, but in the US a flash is several hundred ms as opposed to dozens for a pulse.
A pulse can be sent during an answered call, just like a hook flash. If the timing were the same or overlapping, that would be quite problematic.