I have an old install of FreePBX which has been upgraded over the years and I never solved the one-way audio issue see my previous thread . I intermittently get one-way audio when calling ring groups. Most of time there is no problem but it is an annoyance I really need to fix before my users physically damage the phones.
I have VPN’s that connect remote offices together and PBX lives in a Hyper-V VM. There is no NAT, all branch subnets are declared to FreePBX as local subnets.
I am now using FreePBX 15.0.16.75 with Asterisk Version:16.13.0. Most phones are Snom.
I am able to do a tcpdump on the FreePBX machine and see that Asterisk receives the RTP packets but fails to forward them to the other side causing the 1-way audio.
I have attached a packet capture of this issue and believe the issue is within FreePBX/Asterisk but I have not been able to correlate any messages in the full log with the one-way audio.
Does anyone have suggestions on what type of verbose/debug I should enable in asterisk to debug this further?
Approximately what percentage of calls? If reasonably high, we can try various changes and test to see if it’s fixed. As I can’t see anything wrong in the SIP flow, I suspect that there is a bug related to the STUN transactions. I’m pretty sure this is not codec related – g722 was properly negotiated on both sides.
Port 5061 UDP is not standard for Asterisk. Did you move pjsip there (I’m assuming pjsip because AFAIK chan_sip doesn’t know about PRACK)?
True, but ext. 299 is attempting to do NAT traversal anyway. I don’t see any resulting problem, but is it possible to turn it off, in the hope that the trouble is related to STUN? Does the problem occur with calls from non-Snom phones? Is it feasible to see whether chan_sip makes a difference?
What kind of phones are ext. 221 and 223 (the User-Agent header is blank)? I’m fairly sure that the trouble relates to the calling side, but in case not, does the problem occur when the call is answered on ext. 229 (Grandstream)? Is it possible to turn off the STUN on ext. 223 (the mystery phone that answered the call)?
Do you see any difference in the Asterisk log between successful and failing cases?
I would say one call out of 5 but when issue crops up, calling back right away will usually be without audio again. I believe the issue predates me enabling G.722.
Yes port 5061 is chan_pjsip and port 5060 is chan_sip. The issue was happening with chan_sip which prompted me to try chan_pjsip.
I’ll try turning off STUN on 223 and 299 for troubleshooting but I recall dialing from the outside the ring groups also has the same issue. This installation is pretty old, we experienced the same thing with chan_sip before switching to chan_pjsip.
I didn’t compare them head to head, I was looking for errors. The asterisk “full” log without verbose doesn’t produce anything resulting from these calls.
Can you suggest “proper” logging levels for troubleshooting this? I remember enabling RTP debugging at some point and all it added was a bunch of lines saying RTP sent and received packets.
