Weird one-way audio issue between FreePBX and Gateway

Hi All, I have FreePBX running on a PBXact Appliance with a Vega 60G 4FXO Gateway

I configured the trunk between the 2 following this guide:
other than CHAN_SIP is using 5160 on my FreePBX so I used that port for SIP Registrar on my Vega.

I have a one-way audio issues on outbound calls from FreePBX to the PSTN - the FreePBX side can hear the remote caller, but the remote caller cannot hear the PBX side.

Inbound Calls are not affected at all.

There is no firewall between PBXact and Vega, they are both on the same VLAN along with the phones and all can ping each other just fine. Phones are Sangoma S500

I verified that the subnet is whitelisted in the FreePBX firewall and whitelisted in the Intrusion Prevention as well.

I can’t find a network issue and I’m ready to pull my hair out - I only have uLaw allowed on the trunk and it looks like that is what is always used for all calls. My first thought was codec mismatch…

What else can I be missing?

SIP reinvite is not allowed on Chan_SIP also…

Since this is an outbound call, I assume that you mean that the remote party (callee) cannot hear.

I’m not familiar with Vega but if it has any settings related to NAT or STUN, make sure they are off.

If that’s not it, at the Asterisk console do
sip set debug on
and make a test call. If the 200 OK response to Asterisk’s INVITE has anything other than the Vega’s LAN address in the SDP, that’s a problem and you need to find the setting to fix that.

Otherwise, capture packets on the PBX with tcpdump, make a failing call, stop capture, copy file to your PC and open it with Wireshark. Possibilities include:

  1. Asterisk not sending RTP
  2. Sending it to the wrong IP address or port.
  3. Sending with incorrect codec.
  4. Something else wrong with the RTP structure, e.g. packetization or timestamps.
  5. The RTP structure is ok but the contents are silent.
  6. The RTP is fine but for some reason the Vega isn’t playing it.

Post what you find and we’ll suggest what to try next. If it’s (6), you’ll need to debug at the Vega, which I know nothing about, though there are likely others here who can help.

Another thought, since you mentioned VLANs:

Are the PBX and Vega on the same subnet?

Are packets for this VLAN tagged on either the PBX or the Vega?

What kind of switch(es) between them? If they have any layer 3 ‘smarts’, please post settings details.

Yes, I meant Callee - not caller

The VLAN is all untagged, they’re on the same Cisco switch. No Layer 3

Show Support and a PCAP are attached!ApYWvUgRoszk7UUwf1533u-yCN1r

Hi @jburk worth to take pcap at vega end to make sure you are getting RTP packets in vega or not ?
If you are not getting RTP packet from FreePBX then for sure some issue in your networking to fix.

Yes thank you, that pcap was from Vega.

I assume RTP is good because incoming calls have audio both ways.

That’s what I am saying, I have ruled out networking - was hoping somebody could point me in the right direction. Been beating my head against the wall all day on this.


Wonder if this could be it?

This is just like those old Verizon ads, except it’s the caller asking “Can you hear me now?” and the guy on the Verizon mobile says “Still can’t.” AFAICT, the RTP is perfectly fine.

I suspect that the trouble is that line_reversal_detect was set to 1 for advanced.pots.fxo.1, but the Cox MTA isn’t providing a polarity reversal when the call is answered. Try setting it to 0 and see if your outbound audio works.

If Cox is supposed to provide answer supervision, use a voltmeter on the analog line to see whether polarity actually reverses when the call is answered. I suspect not; otherwise there would have been an audible pop on the line. If that’s the case (and answer supervision is important to you) then open a ticket with Cox.

1 Like

Thank you Stewart! That was it -

I had enabled battery reversal detection because we were having a problem with FXO calls not releasing the line after hanging up. I made the change some time ago though…

It works very reliably on Cisco voice gateways so I did not even think to try disabling it - thank you for pointing me in that direction!

Glad to hear that the one-way audio issue is fixed.

I believe that your Vega offers three methods of far-end disconnect detection.

Most reliable, if your Cox MTA supports it, is loop_current_detect and associated parameters. If the loop current doesn’t momentarily drop on disconnect, it’s possible that the MTA has the feature but it’s disabled. If you can find someone at Cox with sufficient knowledge, they may be able to enable it for you.

Next best, the MTA may play a ‘disconnect tone’ when the far end disconnects. Test by connecting an analog phone directly, make a call, answer the remote end, then hang up the remote end. You should hear what sounds like a reorder tone. With luck it will be the US standard; see

The Vega can detect this by setting tone_detect and related parameters.

Finally, Vega can detect a long silence to drop the call; see voice_lost_disc_time and related parameters. Since the remote user might be silent for long periods, e.g. he dialed into a conference and is just listening, you need to set this very long, perhaps an hour or more, but it’s better than nothing.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.