Solved FreePBX and SonicWall intermittent inbound calls
-
Is this a remote office? Any reason the phone can't be on the same side of the firewall as the rest of the phone equipment?
-
Yes, this a remote office. The PBX is on the internet, the phone is inside the firewall.
-
On the 10th call you reach the phone and it rings, and you can converse with this employee?
-
@DustinB3403 said in FreePBX and SonicWall intermittent inbound calls:
On the 10th call you reach the phone and it rings, and you can converse with this employee?
yes. It seemed like each time we changed a setting, we thought we had it because the call went through. Then the next time we tried to call we realized the issue hasn't been resolved.
-
@Mike-Davis So if you're able to get a call to go through, across the internet, and connect, even sporadically. The issue has to be with the internet, and not the firewall settings.
If the firewall was denying access to the phone, it wouldn't ever connect.
FreePBX is forwarding you to voicemail because it knows the phone is unreachable.
-
@DustinB3403 said in FreePBX and SonicWall intermittent inbound calls:
@Mike-Davis So if you're able to get a call to go through, across the internet, and connect, even sporadically. The issue has to be with the internet, and not the firewall settings.
If the firewall was denying access to the phone, it wouldn't ever connect.
FreePBX is forwarding you to voicemail because it knows the phone is unreachable.
The odd thing is that when I can't call him, I can IM him and have him call me and everything works fine every time. I just can't call him most of the time.
-
we just added the STUN server address of Stun.ekiga.net and for two calls, it rang twice and then gave the error message, and on the third call failed without delay.
-
Have you setup a wireshark trace to see where the connection is breaking?
-
Doesn't RTP use a huge port range? Could this be a matter of an RTP session getting blocked by the sonicwall for some ports but not others? Although STUN should resolve this issue.
-
Also have the employee setup a wireshark session and see what they get from their side.
-
For giggles and grins, make sure you have ports 10000-20000 open to the PBX. In theory you already do, or at least some of them, and STUN should have fixed the rest, but doesn't hurt to check. You can also get someone to check the PBX logs when you try a call. If you can't during the day I can this afternoon
-
@coliver said in FreePBX and SonicWall intermittent inbound calls:
Doesn't RTP use a huge port range? Could this be a matter of an RTP session getting blocked by the sonicwall for some ports but not others? Although STUN should resolve this issue.
The devices should be configured to use only specific ports though. Just because it can use a wide range, doesn't mean it should be left open.
-
I found this post on spiceworks:
https://community.spiceworks.com/topic/275636-sip-calls-blocked-by-sonicwallIt suggests:
2. If the above is not an option... For SonicWalls, create a LAN > WAN firewall rule with SIP as the service (everything else set to ANY), only have Allow Fragmented Packets checked. In the advanced tab, set the TCP timeout to 15 and the UDP timeout to 1200.- If you still have problems, open up these ports:
5060-5062 UDP
10000-20000 UDP
10000-20000 TCP
-
@DustinB3403 said in FreePBX and SonicWall intermittent inbound calls:
@Mike-Davis So if you're able to get a call to go through, across the internet, and connect, even sporadically. The issue has to be with the internet, and not the firewall settings.
That is completely untrue.
-
@DustinB3403 said in FreePBX and SonicWall intermittent inbound calls:
If the firewall was denying access to the phone, it wouldn't ever connect.
Of course, but it is not denying access. Does not mean everything else is working. Firewall is just one portion of a router functionality.
-
I tend to agree with most here (not Dustin though) that there is a port issue involved.
To make matters worse, SonicWall is notorious for having issues with SIP - I did when I was using SIP through it for a while.
-
If I remember right, I thought in the Sonicwall world you actually wanted to enable SIP transformations. I specifically remember having to do that once for a NTG customer that was connecting to a cloud PBX and getting one-way audio otherwise. That was a little over 3 years ago, so perhaps the setting is no longer counter-intuitive now.
-
Found the magic checkbox. Under SIP settings, had to check the box for Enable consistent NAT. I did have to reboot the phone for the change to take effect.
When we checked the box for "Enable SIP Transformations" we got the one way audio thing. On the remote side. the phone would ring and ring and eventually go to voicemail. On the local side, the phone would ring, and he would answer, but couldn't hear anything.
-
@Mike-Davis said in FreePBX and SonicWall intermittent inbound calls:
Found the magic checkbox. Under SIP settings, had to check the box for Enable consistent NAT. I did have to reboot the phone for the change to take effect.
When we checked the box for "Enable SIP Transformations" we got the one way audio thing. On the remote side. the phone would ring and ring and eventually go to voicemail. On the local side, the phone would ring, and he would answer, but couldn't hear anything.
"Enable Consistent NAT".... I guess maybe I have some learning to do here, but NAT can be inconsistent?!
-
@FiyaFly said in FreePBX and SonicWall intermittent inbound calls:
@Mike-Davis said in FreePBX and SonicWall intermittent inbound calls:
Found the magic checkbox. Under SIP settings, had to check the box for Enable consistent NAT. I did have to reboot the phone for the change to take effect.
When we checked the box for "Enable SIP Transformations" we got the one way audio thing. On the remote side. the phone would ring and ring and eventually go to voicemail. On the local side, the phone would ring, and he would answer, but couldn't hear anything.
"Enable Consistent NAT".... I guess maybe I have some learning to do here, but NAT can be inconsistent?!
By default. That is normal. Every new connection should get a random port. This setting breaks that.
