Insufficient information. As that normally means SIP, any dialtone you hear from a SIP phone is generated, by the phone, before it has made contact with the PABX (unless you are using something like DISA which might generate a secondary dialtone.
Missing audio, or one way audio, on SIP is normally caused by NAT or firewall misconfiguration.
Please be more specific. Does this mean that incoming calls are fine, that calls between extensions are ok, etc?
Do you mean that there is no audio at all in either direction?
Who’s cloud? At many major providers including AWS and GCP, your instance is behind a NAT. If ifconfig shows a private address, it is, and you need to configure the cloud firewall to allow RTP to pass.
In Asterisk SIP Settings, confirm that Local Networks and External Address are correctly set. If you change these, you must restart Asterisk.
Is this something that used to work but doesn’t anymore? If so, do you know what may have caused it (FreePBX or Asterisk update, OS update, etc.)?
If this is a new system, have you tested with e.g. a softphone at home or a SIP app over mobile data, to rule out the remote site firewalls as a cause?
If you still have trouble, paste logs as noted by @david55 . Log the simplest thing that fails (*43 [echo test] , call between extensions at the same site, etc.)
When they or I dial a number out there is no audio, it doesn’t seem to be happening on incoming calls. I have not gotten any reports of it happening calling extensions, although I cannot be sure about this.
The person who is calling cannot hear anything at all, but the person who picks I can hear them, so the audio is in one direction. I have a PCAP file that managed to get, and when I listen to it in Wireshark I can see that there is audio for both sides.
It is a VPS hosted on Linode, which does have an actual public IP address.
It wasn’t an any update, as I was on FreeBPX 15 for a while, and it was happening then and still is happening when I moved over to 16, unsure what could be the cause.
The issue is intermittent, so it’s difficult to test, but I haven’t noticed it happen with a softphone or over mobile data. I’m guessing it has something to with the remote site’s firewall, like @david55 said
Awesome – you’re most of the way there. Confirm that the RTP to the extension is sent to its public IP and the destination port matches the source port of the RTP from the extension.
Assuming the above is ok, the remote firewall should pass the traffic, because it looks like ‘replies’ to the RTP sent from the extension. The firewall has the ability to capture traffic on both its WAN and LAN interfaces, so you can see if it’s getting the incoming RTP and passing it.
If it’s ok on the LAN side, check at the phone or at intermediate switches as indicated.
I was talking to some from the other site as I think the issue I was having was probably related to SIP ALG, but they are still having the issue and it isn’t SIP ALG as the router there doesn’t have SIP ALG option.
Here are the details:
It happens intermittently on all types of numbers for all phones there.
Line just goes dead no dial tone nothing, sometimes the client say their phone rings but when they pick up no one is there.
It will dial correctly and get dial tone client answer, and they will be able to hear them on the 2-3rd go.
You have to be using analogue line or doing something unusual to get real dialtone. I wonder if you mean ringback tone. If not, I think you need to explain what you are doing that would result in true off hook dialling (even if you pick the handset up, before dialling, SIP phones actually do a sort of on-hook dialling, but using their internal dialplans to work out when the number is complete, rather than using handset pickup, or something similar.
I received that information in an email and I just edited their response and pasted it here, they’re not a technical user, so they probably don’t know the difference between dial tone and progress tone. I would assume they mean progress tone.
There is nothing to bump. You have shown that you can successfully capture traffic at the PBX and audio incoming from the trunk is present. You now have to trace why it is being misdirected or lost on the way to the phone, or why the phone isn’t playing it.
You need to follow your network towards the IP address of the SIP trunk, and find out where the packet ceases to be present, then look at each side of that network hop to work out why it is being dropped. If it reaches the SIP Trunk IP, you have to do the same, following the response back.