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…
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:
Asterisk not sending RTP
Sending it to the wrong IP address or port.
Sending with incorrect codec.
Something else wrong with the RTP structure, e.g. packetization or timestamps.
The RTP structure is ok but the contents are silent.
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.
Hi @jburk worth to take pcap at vega end to make sure you are getting RTP packets in vega or not ? https://wiki.freepbx.org/display/VG/Packet+Capture
If you are not getting RTP packet from FreePBX then for sure some issue in your networking to fix.
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.
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.
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.
