FreePBX | Register | Issues | Wiki | Portal | Support

Sangoma A200 not working after installing FreePBX 14

(dengel) #1

I have an A200 with 2-FXO, 2-FXS installed. The second FXO port is connected to POTS. The card itself is set up as a PCI passthrough device to a VM running under ESXI 6.7.

Everything worked great with FreePBX 13 (AsteriskNow Distro 10.13). I had no issue making or receiving calls. However, I broke that installation trying to upgrade to FreePBX 14 using the built-in upgrader.

Now, I have a clean install of FreePBX 14 (FreePBX Distro SNG7-FPBX-64bit-1805-1), but the card doesn’t work anymore. It’s detected, and I can even see the ring voltage on incoming calls, but asterisk never picks up. Outgoing calls just hold forever in silence.

When everything works under FreePBX 13, an outgoing call gives me (excerpt):

-- Executing [s@macro-dialout-trunk:24] Dial("PJSIP/225-00000003", "DAHDI/2/wXXXXXX9971,300,T") in new stack
-- Called DAHDI/2/wXXXXXX9971
-- DAHDI/2-1 answered PJSIP/225-00000003
-- Channel DAHDI/2-1 joined 'simple_bridge' basic-bridge <88a799b0-1058-4fb6-be4e-2c6081b49184>
-- Channel PJSIP/225-00000003 joined 'simple_bridge' basic-bridge <88a799b0-1058-4fb6-be4e-2c6081b49184>
-- Channel PJSIP/225-00000003 left 'simple_bridge' basic-bridge <88a799b0-1058-4fb6-be4e-2c6081b49184>
  == Spawn extension (macro-dialout-trunk, s, 24) exited non-zero on 'PJSIP/225-00000003' in macro 'dialout-trunk'
  == Spawn extension (from-internal, 5035629971, 6) exited non-zero on 'PJSIP/225-00000003'
-- Executing [h@from-internal:1] Macro("PJSIP/225-00000003", "hangupcall") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("PJSIP/225-00000003", "1?theend") in new stack
-- Goto (macro-hangupcall,s,3)
-- Channel DAHDI/2-1 left 'simple_bridge' basic-bridge <88a799b0-1058-4fb6-be4e-2c6081b49184>
-- Hanging up on 'DAHDI/2-1'
-- Hungup 'DAHDI/2-1'

With 14, the comparable excerpt is:

-- Executing [s@macro-dialout-trunk:25] Dial("PJSIP/123-00000001", "DAHDI/2/wXXXXXX9971,300,Tb(func-apply-sipheaders^s^1)") in new stack
-- DAHDI/2-1 Internal Gosub(func-apply-sipheaders,s,1) start
-- Executing [s@func-apply-sipheaders:1] NoOp("DAHDI/2-1", "Applying SIP Headers to channel") in new stack
-- Executing [s@func-apply-sipheaders:2] Set("DAHDI/2-1", "SIPHEADERKEYS=") in new stack
-- Executing [s@func-apply-sipheaders:3] ExecIf("DAHDI/2-1", "0?Set(Rheader=1)") in new stack
-- Executing [s@func-apply-sipheaders:4] While("DAHDI/2-1", "0") in new stack
-- Jumping to priority 8
-- Executing [s@func-apply-sipheaders:9] ExecIf("DAHDI/2-1", "0?SIPRemoveHeader(Alert-Info:)") in new stack
-- Executing [s@func-apply-sipheaders:10] ExecIf("DAHDI/2-1", "0?Set(PJSIP_HEADER(remove,Alert-Info)=)") in new stack
-- Executing [s@func-apply-sipheaders:11] Return("DAHDI/2-1", "") in new stack
  == Spawn extension (from-analog, 5035629971, 1) exited non-zero on 'DAHDI/2-1'
-- DAHDI/2-1 Internal Gosub(func-apply-sipheaders,s,1) complete GOSUB_RETVAL=
-- Called DAHDI/2/wXXXXXX9971
-- Hanging up on 'DAHDI/2-1'
-- Hungup 'DAHDI/2-1'

The biggest difference seems to be the lines relating to ‘simple_bridge’, but I don’t know what this is. Adding “w” in the trunk dialing prefix doesn’t change the result.

Of course, since both of these are in VMs, it’s trivial to go back and forth. If I have to I can just keep using 13, but I’d like to make 14 work if I can. I’ve compared configs: the DAHDI and wanpipe configs generated by sangoma-setup are identical except for the PCIBUS IDs that ESXI assigns to the different VMs. The asterisk configs are markedly different, especially ‘extensions_additional.conf’, but I think this would be expected. Besides extensions, I haven’t done much to modify the configs on either system.

Has anybody else had this issue, or gotten an A200 to work with FreePBX 14?


My guess is that your card is probably not configured correctly and all the ports are in the same port group, based on your description, but without seeing your dahdi conf I’m just guessing.

Try setting each port to a different port group and configure the trunk accordingly.

(dengel) #3

I had assumed it wasn’t an issue since both systems attempt to call out on DAHDI/2/wXXXXXX9971. Nevertheless, I’ve now tried different group configurations, and also tried selecting both groups and channels in the trunk configuration.

Here are the most recent contents of ‘chan_dahdi_groups.conf’:





With this configuration, and the trunk configured for “Group2 Ascending”, the only difference in the logs is:

-- Called DAHDI/g2/wXXXXXX9971

instead of

-- Called DAHDI/2/wXXXXXX9971