Outgoing POTS calls fail, dropped digits

FreePBX is working great; when it’s going right.

Six out of ten outgoing calls fail to dial properly.

Specs: Digium Wildcard 810p w/ echo cancelation, FreePBX v2.8, Polycom IP450, 8 POTS lines

All internal calls work great.
All incoming calls work great.
Only 40% of outgoing calls work.

60% of the time we get error messages from the phone company indicating the dialed number is incomplete. It’s as if a digit is being dropped or otherwise ignored by AT&T (our carrier).

All logging and debugging from Asterisk indicates the proper phone number is being dialed. The outgoing numbers appear properly and pass our dialplans. I captured DAHDI audio into a WAV file. I analyzed it with Audacity and indeed the correct number of digits are being dialed … followed by another digit tone about 1.5 seconds later.


  • What would cause AT&T to ignore a dialed digit?

  • What is that extra digit tone sent about 1.5 seconds after the outgoing number is dialed?

Being an intermittent error this is driving me crazy. Especially since this new phone system was supposed to be humming along this morning. Apparently the system is playing an April fools joke on me.

You help is appreciated!

You state neither what distro and versions of asterisk/dahdi you are using and how it was installed and on what hardware, but :-

I would should check your dahdi_test -vvv is better than 99.99%, without a rock solid timing source the DTMF tones will be off.

Check that the rx/tx gains are set appropriately using dahdi_monitor and asterisk’ milliwatt() application against an external milliwatt test number on your AT&T network. (man dahdi_monitor will indicate the various methods for monitoring and recording audio streams) Bad audio levels and badly setup echo cancellation can spoil your whole day with inband DTMF

I would also add DTMF to your “full” log in /etc/asterisk/logger*.conf files, to verify what is actually being sent, tailf /var/log/asterisk/full|grep DTMF then gives you a realtime log.

Very often the easiest way is to stick a “butt-set” on the FXO pair and listen as things go wrong. . . .

AT&T do not have this problem in general, but to cover flaky setups you might add something like
toneduration=120 in your dahdi channel definitions

I bet you didn’t run the fxotune utility to set your levels.

Does anybody read the documentation or did you just stick your card in the computer and pray?

Yep, I forgot to mention that, AFTER you balance the rx/tx levels, you need to:-

fxotune -i
the trunks after “man fxotune” 'ing :wink:


Avoiding any of the above makes it harder for dahdi and any EC you use, to work with your trunks.

Thank you Dicko & SkyKingOH for the suggestions.

Last night, after posting here, I discovered a comment from 2003 in another message board indicating the trouble may by rxgain/txgain being set too low.

The Digium Wildcard TDM808e has hardware echo cancellation. I haven’t seen any documentation on how to tune the hardware EC. However, I’ve seen methods for tuning software EC with fxotune. Do I need to tune the hardware? And also, if there’s a switch or setting that tells Asterisk to user software VS. hardware EC.

I’ll admit to just dropping the card in the box and expecting it to ‘just work’. That’s what I hoped for with hardware solution. All my testing proved it worked without trouble. Until the day we went ‘live’ and then 60% of the outgoing calls were not getting through.

Today I’ll work on setting rxgain/txgain. Though again, I haven’t found any reasonable how-to but have pieced together enough info that I feel I’ll have a good end result.

I’ve done my best to locate and read whatever documentation I could. In general, Elastix without Tears and voip-info.org have proven to be the most helpful.

BTW - I’m using FreePBX included with Elastix v2.3

Thanks again, I’ll report back my findings.

In addition to the sage advice of Scott and Dicko. (listen to them…they know as much as anybody you’ll encounter here.) Have you prepended several “waits” or “W”'s to the outgoing number?. It may be that Asterisk is dialing before ATT is ready to accept the dial command. Remember, the normal use of a POTS line is to pick it up, listen for a DT and then dial. Asterisk begins dialing as soon as it seizes the line, very likely cutting off the first digit or two.


You can change the EC in /etc/dahdi/system.conf , also the rx/tx settings and toneduration on a per channel basis if you need to.

Echo is caused by many things and it is usually best to turn off all EC to start, then fxotune will massage impedance settings and echo coefficients of the 2-4 wire hybrid, good description of that here:-


That will not change the gains of the signal, so hence the rx/tx tuning, which is best done first :-


explains it well. When the echo, sans EC, is minimal, and the conversations are stress free, (a human engineering thing) , and DTMF is reliably sent and received, then turn on your EC and it will only get better.

Be prepared for downtime, as fxotune needs no asterisk running and is quite lengthy, changes to dahdi configs of this nature require a complete

service asterisk stop
service dahdi restart
service asterisk start

to take effect.

. . * What is that extra digit tone sent about 1.5 seconds after the outgoing number is dialed? . . the # DTMF used to signal “end of outpulse” to the telco, useful for openended dial plans like International calls tend to be.

As a final note, Elastix packages very old and hacked up versions of FreePBX and Asterisk, you might want to think about abandoning them in the same way they have abandoned FreePBX, or sooner or later you will have an unsupported (here) system.

All great suggestions! Thank you! I’ve learned much based on your suggestions and additional google searches.

Unfortunately, none of them have made a difference.

I’ve tried adding ‘w’ to the dialplan in extensions_additional.conf. I verified the changes took affect by watching Asterisk at verbose level 10
asterisk -rvvvvvvvvvv

I stopped asterisk, ran ‘fxotune -i 4 -b3 -e 3 -vv’, restarted dahdi, started asterisk. This didn’t make any difference other than assuring the single channel I currently have connected with the new system was fxotune’d. I verified this by checking the /etc/fxotune.conf file and it matched the output of the fxotune command.

I tried adjusting both rx and tx gain (before and after running fxotune). This was more interesting in that the changes were definitely heard in the office! However, using dahdi_monitor I noted the DTMF levels didn’t change at all. They register around 5900 in dahdi_monitor regardless of the txgain setting. I believe the DTMF amplitude/volume is controlled elsewhere, but rxgain and txgain control the call after it is dialed.

I even tried a different channel and PSTN line on the card to rule out a bad channel port or phone line. After swapping I tried the same variety of tuning, gaining, 'w’aiting the dial and ended up with the same result.

I’m truly at the end of my rope. If I’m unable to sort out the “dropped digit” issue the next step is to pack up the new equipment, sell it at a huge loss and invest $7000 in a replacement for our old, but working, Intertel system circa 1996. This is a terrible solution given we’re a non-profit. But I’m thoroughly stumped.

Any other last suggestions before this ship is sunk?

Are there any other diagnostic tools I’m missing?

It truly seems like one of the first dialed digits is being eaten up.

Maybe this additional info could help?

The lines are all part of a hunt group.

I thought of tinkering with the numeric prefix on the outgoing call. Initially I thought a ‘9’ must be prefixed onto the outgoing call. But upon further experimentation I found that I could prefix any digit and get one of the following results: fast busy, call cannot be completed, or the call goes through properly. Though prefixing a 9 never gives a fast busy.


1 Like

Have you put you Butt Set across the line in monitor mode and listened? You may have to prepend more than 1 wait. Just depends on how quickly your telco responds.


Did you turn your EC off?
Have you set toneduration= (more than 80)?
Did you shut down asterisk BEFORE you reloaded dahdi, did you see (dahdi bitching ?)?
Did you run fxotune -s (should be run by /etc/init.d/dahdi but that depends on your implementation).?
Did you listen to the calls on a “butt-set” (any old phone will do if you get the timing right)?

fxotune -i 4 -b3 -e 3 -vv

is strange, you try to tune only channel 3 (incorrectly, what is the first 4 for) and are you sure you “broke dialtone” (-n), this is why you need a butt-set :wink:

You are wrong in . . .I believe the DTMF amplitude/volume is controlled elsewhere, . . it is not.
Are you using kewlstart signaling?
Is your card broken?

First … THANK YOU to all who have offered great suggestions. I’ve learned much.

However, this is embarassing.

Using the ‘butt dial’ suggestion I connected an old touch tone phone to our line. I tried dialing one of the sequences the phone system has been dialing, and got the same result.

Then, it hit me, try just dialing the phone number without any ‘9’ or ‘8’ etc. prefix. Voila! The call goes through. I try again with success. Now I try and note about how long it takes before I get dial tone. It’s less than a second but there’s a definate delay.

It turned out that my misunderstanding of the outgoing call and prefixing all calls with a digit, any digit, was “mostly” acting as a ‘wait’. But sometimes that incorrectply prefixed digit didn’t work as a proper ‘wait’ and AT&T heard it. Thus giving me ‘incorrectly dialed’ phone number messages.

So, I revised my dialing rule to prepend two waits ‘ww’ (but not any digit) before dialing the outgoing number. Specifically, in the Elastix config file extensions_additional.conf I now have this line in the [macro-dialout-trunk] section:
exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/ww${OUTNUM},300,${DIAL_TRUNK_OPTIONS})

I have to be careful because each change in the Elastix interface will overwrite my dialplan change and remove the ‘ww’ prefix.

Now that I’m able to dial out reliably I am adjusting rx and tx gains in addition to echo tuning.

Though, I’d like to note that changing txgain still does not change the amplitude/volume of the DTMF tones sent while Asterisk dials the number. Regardless o whether my txgain=0 or txgain=60 (yes, I tried 60) the dahdi_monitor -vv shows about 5800 for the DTMF tones when dialing. Maybe there’s something else at work here that I’m missing, but I’m simply indicating what I’ve witnessed.

Now, on to a few other tidbits, like overriding the caller-id for all outgoing calls so they appear to come from our main line, not any of the roll-over / hunt group phone numbers. But that’s for another thread.

to follow up answering dicko’s questions:

  • I turned of echo cancellation through chan_dahdi.conf, echocancel=no and echocancelwhenbridged=no and commented out echotraining

  • toneduration=120 set in chan_dahdi.conf

  • I did shut down asterisk before running fxotune, otherwise the system did complain

  • I ran fxotune -s after restarting dahdi and before starting asterisk

  • The Butt Set call is what tipped me off to the likely issue of incorrectly prefixing the outgoing number.

  • In fxotune -i 4 -b 3 -e 3 -vv ; the ‘4’ was the number to break dial tone, though the default of ‘5’ worked just as well. I was limiting my tests to channel 3, thus the begin and end parameters set to ‘3’

  • Yes, I’m using KewlStart

  • Card broken? I don’t think so but would have now way to tell.

Thanks again to all who’ve offered suggestions. This forum is truly alive and well with talented people willing to donate their time.


I have to be careful because each change in the Elastix interface will overwrite my dialplan change and remove the ‘ww’ prefix.

You shouldn’t be editing any of the “additional” files manually. You manipulate the outbound dial strings either on the Trunk or the Outbound Route setup pages.

Agreed. I want to stick with using the interface because others who will ultimately support this server may not have Linux experience.

However, Elastix v2.3 will not accept ‘w’ as a prepend character via the web GUI in Outbound Routes. And I haven’t come up with a viable alternative method for assuring ‘ww’ is prepended to all outgoing calls.

Suggestions welcome.

Quick follow up – I was able to prepend WW to my Trunk dialing number manipulation rules.