VoIP dropping calls (go silent on both ends, but still look connected)
We have an M470 (12.7.2) setup with a VoIP VLAN, using 8x8.com as our VoIP provider and using Polycom vvx310 and vvx311 phones. They have worked great for years. Now we have calls drop (go silent on both ends, but still look connected) randomly throughout the day. The drops do not appear to impact multiple users at a time. There are only about 6 people in the office regularly. There is a an AltaFiber Fiber 1000/250 Gbps connection. I monitor the connection from time to time and do not see any outbound denials from the VoIP VLAN. I do have fairy detailed policies to allow and optimize VoIP traffic and taking this link into account https://support.8x8.com/cloud-phone-service/voice/network-setup-voice/x-series-technical-requirements. As a troubleshooting measure, I have allowed all outbound traffic from the VoIP VLAN. It does not seem to help. Could it be some kind of obscure timeout or global networking setting? Please let me know your thoughts and suggestions. thx.
Comments
I would contact your VOIP provider and open a support ticket with them as issues like this need looked at from both ends.
You could also perform a TCP dump on the WAN interface while the issue is happening. Open the dump file in Wireshark and use Wireshark's built in tools to search for VOIP issues.
Or maybe your IP phones are EOL and no longer compatible with your VOIP provider.
It's usually something simple.
If nothing has changed configuration-wise on your firebox, I would suggest starting that with a call to the VoIP provider to see if/what changed on their end.
-If you have the Outgoing policy, or if you made an outbound policy for your phones, all ports should be allowed that the phones are using.
-a SIP-ALG isn't in use on the Firebox by default, and is only enabled if you make a SIP-ALG proxy policy. Packet filters don't use SIP-ALG.
-An inbound policy isn't generally needed as the phones will make the initial connection and keep that connection open (in the same way that you don't need an inbound policy to surf the web.)
-James Carson
WatchGuard Customer Support
Just based on what you described, the call control info that occurs over port 5060 is staying connected, but the actual RTP streams (there's one for each direction) is dropping.
If you open a support case with WatchGuard, the technician may be able to help determine why the RTP stream is dropping. This will usually involve taking a packet capture of a call waiting for it to drop, and seeing what the call control data on port 5060 is doing at that time.
-James Carson
WatchGuard Customer Support
James,
Thank you for your thoughts on this. Unfortunately, I have never been able to observe the drop call behavior while monitoring the FW activity. I'm not even exactly sure what to look for. The VoIP vendor has not been very helpful. They state that is that is occurring it is a FW misconfiguration, but that is a very broad statement. I'm by no means an expert. I kind of operate on a need to know basis. I'll probably end up open another tik with the vendor and one with WG. Biggest problem is we cannot recreate the problem at will, the the issue is real. I had it happen to me twice the other day.
No one uses SIP-ALG, no one. In general you need a packet filter for the needed ports to the IP's or FQDN of the IPT vendor (or system).
A common one...
TCP and UDP 5060->9
UDP - 10,000-30,0000
UDP - 5222
And depending on other things, well, other things. 80 and 443 are already handled in theory.
I also create an alias for my handsets (in general PolyCom) so that I can easily apply rules to the handsets on their subnet.
As a note - "Any" never seems to work. I have to create packet filters with the needed ports to the needed (external) IP's and things work very well. There are a few options for the handsets (option 150 or 66).