Hi, I have this issue that happens possibly for everyone on the PBX where when they dial out there is no dial tone and when the person they are calling picks up, but they can’t hear each other.
The PBX is hosted in the cloud and this has happened at 2 different sites with different network setups.
Which log should I be looking at?
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.
Sorry, I am somewhat new to FreePBX, so I’m not sure what logs are important to this issue.
I personally think that it’s unlikely a NAT issue, as I’ve seen happened on two completely different routers (pfSense, EdgeRouter), is there a particular setting that needs to be on/off?
The settings most people get wrong with respect to NAT are not on/off settings, but rather the public addresses, and the list of local network specifications.
qualify and registration intervals can also be relevant if audio fails part way through a call, and again are not on off.
Router port forwarding ranges need to cover those configured for Asterisk (default 10,000 to 20,000, which really should he 10,000 to 19,999.
I guess the main on/off setting is that SIPALG (or equivalents under other names) should be turned off in the router.
Logs are those mentioned in Providing Great Debug - Support Services - Documentation, but you may need to enable debugging for the channel driver (depends on the channel driver), and you may need to turn on RTP debugging (CLI: rtp set debug on).
Generally required is the channel driver in use and network topology (for IP particularly the location of NAT).
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.)
I’ve found that one of the sites that I personally experienced this issue had the option on, but pfSense does not have SIPALG, so I’m not sure about that.
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.
I think that it is this, my colleague was referring to it as progress tone but that might be wrong.
Just bumping this one up
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.
Can you explain this a little bit more? I don’t fully understand just yet.
I’ve opened the PCAP file in Wireshark and the two IP address I see are from the SIP Trunk and FreePBX server. The PCAP was captured using VoIP Monitor just in case that something do with 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.
Hi David,
I’ve found some time to do this, but I’m confused on the exact specifics of how to do this, I have basic networking knowledge but not sure where to start, what tools do I need?
Thanks
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.