Recent updates broke our system

General Help
1

About 8 months ago we installed a freepbx machine in front of a legacy pbx. It uses two PRI lines and has worked well until a few weeks ago. After a bunch of debugging, I suspect that module updates partially broke the communication between FreePBX and the legacy.

Originally, the way I setup the dialplan was to forward DID’s to the legacy using misc destinations. This was fine and calls proceeded in and out from both the legacy and the voip phones. After updates a few weeks ago, we started having problems with DTMF failing and audibly sending 2 digit for every one pressed. The problems eventually got worse until calls to the legacy got “lost” and wound up in a default IVR that is incorrect for the DID. I fixed that error by adding directly routing the DID to the DAHDI group in extensions_custom.conf. The problems get even stranger as calls from legacy to legacy phones are muted, don’t complete successfully, etc. Removing FreePBX from the chain fixes all calling issues on the legacy box. Of course, that’s not an acceptable fix.

I’m not sure exactly how to proceed from this point but seeing as the system worked fine a few weeks ago I think reversing some updates would be a good idea. Is there a way to selective back off updates?

2

You didn’t tell us a thing about your setup.

What kind of PRI card? What updates caused the problems? OS, Asterisk and FreePBX version. Did you install from scratch or use a distro?

3

Oops! yeah, that would help!

I compile all the packages myself on CentOS 4.7 (updates include centosplus packages). The PRI card is from Sangoma (a104d). Software versions are:

wanpipe 3.4.1
FreePBX 2.5.1.5
kernel-2.6.9-78.0.22.EL.LSE.1
asterisk-libpri-1.4.9-1.C4.LSE
asterisk-1.4.25.1-D1.C4.LSE
asterisk-perl-0.10-1.C4.LSE
asterisk-devel-1.4.25.1-D1.C4.LSE
iaxmodem-spandsp-1.2.0-1.C4.LSE
iaxmodem-libiax2-1.2.0-1.C4.LSE
iaxmodem-1.2.0-1.C4.LSE
dahdi-tools-2.1.0.2-1.C4.LSE
dahdi-linux-2.6.9-78.0.22.EL.LSE.1-2.1.0.4-1.C4.LSE

I’m not sure what updates caused the problem, only that the problems seemed to start after running updates in freepbx a few weeks ago. The problems with the legacy go away when it’s connected directly to the telco OR when I bypass freepbx with this in extensions_custom.conf:

[from-pstn-custom]
exten => 8505551212,1,SetTransferCapability(SPEECH)
exten => 8505551212,2,Dial(DAHDI/g1/${EXTEN}|45)
exten => 8505551212,3,Congestion()
4

By using the Asterisk SetTransferCapability() extension you are bypassing Asterisk. You can do a ‘show channels’ in the CLI while a call is up and you will notice that Asterisk is not participating in the call. That would explain quite a bit.

You are going to have to do some troubleshooting. Try some softphone calls to the PRI and see if you can replicate the issue.

Call logs are always useful.

5

Hmm, yep, Asterisk becomes a bridge.

logger.c: – Accepting call from ‘’ to ‘8505551212’ on channel 0/5, span 1
logger.c: – Executing [8505551212@from-pstn:1] SetTransferCapability(“DAHDI/5-1”, “SPEECH”) in new stack
logger.c: – Setting transfer capability to: 0x00 - SPEECH.
logger.c: – Executing [8505551212@from-pstn:2] Dial(“DAHDI/5-1”, “DAHDI/g1 8505551212|45”) in new stack
logger.c: – Requested transfer capability: 0x00 - SPEECH
logger.c: – Called g1/8505551212
logger.c: – DAHDI/50-1 answered DAHDI/5-1
chan_dahdi.c: master: 5, slave: 50, nothingok: 0
chan_dahdi.c: Stopping tones on 5/0 talking to 50/0
chan_dahdi.c: Stopping tones on 50/0 talking to 5/0
chan_dahdi.c: Making 50 slave to master 5 at 0
logger.c: – Native bridging DAHDI/5-1 and DAHDI/50-1

I’ll do some more testing and get some more logs. Thanks.

6

It’s been a while since this has been fixed so I wanted to give an update.

What I found, after much trial and error, is that someone added “W” to “Asterisk Dial command options” and “Asterisk Outbound Dial command options” in “General Settings”. The W option borked DMTF from the PSTN to the legacy box and from the legacy to the PSTN although Asterisk DTMF worked just fine. Simply removing the W option caused the DTMF to function normally.

I never researched the option so I don’t know if it’s a feature available only with asterisk 1.2, but, it is fixed and working for a couple months without error now.

Thanks, Andrew