John Lind - 2019-11-05

Just went through some real pain tracking down intermittent one-way outbound audio - I could hear the other end, but they could not hear me - and wanted to pass on what I discovered and how I fixed it - at least it's not recurring yet after repeated testing.

Basic Configuration:
Raspberry Pi 3B+; 32GB Class 10 SDHC with partitiion expanded
RasPBX: FreePBX 14.0.13.6 with Asterisk 13.28.1; O/S updated to most current as of this posting
Two trunks, both SIP (versus PJSIP)
Grandstream GXP1625 Basic IP Phone; 2 lines wtih 2 PBX extensions and SIP accounts
Grandstream GXP1628 Basic IP Phone; 2 lines with 2 PBX extensions and SIP accounts
Grandstream ADP720/750 DECT cordless base and handset; 1 extension on ring groups with the other two extensions. I rings and allows pickup on either SIP. This replaced using an iPod Touch on my WiFi with the Grandstream mobile app (which worked quite well once I got it set up). Purpose of this cordless is allowing roaming around my house and being able to answer without having to dash to one of the two desk phones. :-)

The Grandstream phones have a few setup idiosyncracies with minimalist documentation for a noob, but got past the learning curve. They were less expensive than other brands, they seem well-built for SOHO use, and I've not had any reliability issues with them. When I got the ADP720/750 DECT and set it up I discovered intermittent one-way audio on the outbound calls. No problem on inbound. This was a clue the problem was RTP and its negotiation. Audio was indeed passing through my internet gateway from LAN to WAN. Took a while to track down the two issues that were causing one-way outbound audio. One was very reliably causing it, and once that was cleared up, the behavior was intermittent with the new ADP720/750 DECT cordless. If I toggled the "hold" which would start the "hold music" playing, I could sometimes get two-way audio back. Toggling "hold" again would sometimes lose two-way audio back to one-way.

Fix #1 Solving Repeatable One-way Audio On All Outbound from All Devices From FreePBX Admin GUI:
Settings --> Asterisk SIP Settings --> Chan SIP Settings (tab)
Under Media and RTP Settings:
Non-Standard G726 = Yes
Reinvite Behavior = Yes (I don't know if this one is essential, but that's what it's set to now)

Fix #2 Solving Intermittent One-Way Audio On ADP720/750 DECT Cordless:
I found this was a G722 CODEC issue. The ADP720/750 default is G722 at the top of its CODEC list with PCMU (ULAW) and PCMA (ALAW) listed just under it. By comparison, the GXP1625 and GXP1628 have PCMU and PCMA at the top of their CODEC lists, with G722 listed 5th after those plus G723.1 and G729A/B.
Set the ADP720/750 CODEC list to match the default order in the GXP1625 and GXP1628. The cordless has an 8th CODEC, OPUS, and it's the last one in the cordless list.
Settings-->Asterisk SIP Settings-->General SIP Settings (tab):
* Set the eight CODECs from the ADP active (check marks) and disabled the rest
* Set the priority of the CODECs to match the common priority in all three Grandstream devices.

I've now tested the two desk and cordless phones calling a PSTN POTS number, an XFINITY (Comcast) cable system number, and a Verizon cell number, all of which had the previous one-way audio issues. Two-way audio is now reliable, even with rapidly toggling the "hold" and its music. I did test OPUS with the cordless as the #1 priority CODEC set in it and Asterisk. It did not work on any outbound call. Failed with call disconnect when the distant end picked up. Tells me the OPUS CODEC is not ready for prime-time with the outside world of PSTN POTS and cell systems. I've come to the conclusion the number I'm calling want PCMU or PCMA. I did some additional testing with G722 attempting to force it as the only CODEC, and it failed just like OPUS did.

This was my experience with getting RasPBX two-way audio working reliably with its current FreePBX and Asterisk, and my Grandstream phones. My conclusion from this is one of the Usual Suspects with one-way audio, either 100% of the time or intermittent, are the CODEC settings and what CODECs are being used. I thought I might have port forwarding problems across my LAN/WAN gateway, and that had nothing to do with it. Spent an enormous amount of time setting up port forwarding configurations to no avail. That's all set back to the way it was.

Edit:
The Hold Music is all encoded in ALAW, G722, GSM, ULAW and WAV.

Edit #2 DID provider supported CODECs and Firewall ALG:
Out of curiosity, I checked my DID provider, Flowroute, to see what CODECs they supported. Was glad I did and it explained much of the phenomenon. They only support two CODECs: G.711 and G.729. G.711 is also known as PCMU or ULAW (mostly in the Americas), and PCMA or ALAW (mostly in Europe). I've got Shibby Tomato running a mesh LAN on three routers, one of which is the Internet firewall/gateway and LAN DHCP. They all have the ALG SIP Helper turned off (disabled). I've not tested it with this enabled, but have read on numerous sites that it's old, buggy and causes problems. It's working just fine with it disabled, so I'm not going to test it. RTSP and H.323 are both enabled, but have not had any effect on the VoIP inbound or outbound calls.

John

 

Last edit: John Lind 2019-11-05