Second Dial Tone on DAHDI Trunk

First post and not sure if there is a better category, so apologies in advance.

We are trying to route outbound calls to a DAHDI trunk to go out via a landline on a Sangoma A200 card. After dialing the full number, it gives a second dial tone. Adding 1 or multiple w’s to the Outbound Dial Prefix for that trunk causes the proper delay, but still gives second dial tone.Dialing the same number again goes through with proper caller id indicating it went out the right trunk. How can we make the call go through without the second dial tone?

asterisk 11.22.0
FreePBX 2.11.0.34
sangoma A200 card
CentOS release 6.8 (Final)

More detail:

We have two phone servers in this office. IP phones are connected to the new phone server, but landlines have been going out from the old phone server. We have outbound routes to a local trunk to the old phone server, which works correctly.

We now want to swap the landlines to the new phone server. We have a sangoma A200 card in each server. We started with a separate line in port 4 on the new phone server. The other 3 ports have nothing connected. We created a DAHDI trunk to this landline port. It is called Landlines1 and in FreePBX it has CID Options set to Allow Any CID, Asterisk Trunk Dial Options set to Tt, no dial rules or outbound dial prefix, DAHDI Trunks set to Analog Channel 4 or Group 0 Round Robin Ascending behave the same way and no other settings filled in.

The old phone server is an older version of asterisk and FreePBX and its ZAP trunks have a text box for Dial Rules rather than the new style Prepend, Prefix, Match Pattern. The Dial Rules for each trunk entered in this text box is *3x|. to strip off a custom dial pattern to select a trunk, then pass the actual phone number to the trunk.

Does anyone have any ideas why we’re getting a second dial tone and how to send the number immediately?

Thanks

In case anyone finds this useful, we solved this problem by swapping in a new Sangoma A200 card with no configuration changes, so it appears the problem was due to a defect in the card. Possibly related to wait timing.

Hi!

It might just be a defective module (unless all modules are affected)

Before discarding the card I would suggest swapping the affected module for a known good one…

It could have possibly been firmware problems but it has not been updated in ages so I doubt it’s that…

Good luck and have a nice day!

Nick

Hi Nick,

Yes, these cards have a lifetime warranty, so we would return it to Sangoma rather than discarding it.

But there is more to the saga! We were able to get the original card working properly by re-installing and carefully re-seating the card. Sangoma support had earlier told us to re-seat the same model card to elminate unrelated errors. When we got the new card, we swapped the two cards multiple times and that was apparently enough to get it working.

My conclusions are:

  1. These cards are extremely sensitive to being seated perfectly in the computer slot.
  2. The card can partially work, but still have problems when not seated perfectly

So, before giving up on your card or even getting into extensive debugging, make sure to remove the card, blow out any dust with a can of air and re-install and carefully seat the card.

I have the same issue, I’m using a Grandstream PSTN Gateway With SIP Accounts V1.4.1.5. Which indicates all lines are connected and working.