I've just bought Hell Let Loose - it's a lot of fun but very hard. However, I noticed that voice appeared to randomly work on some servers, but not others. I was watching my FW logs as I was playing the game and adding individual UDP ports in as they showed up as denied.
It seems that the initial voice packet is tried once - if it fails, then the game appears to just give up and doesn't try and send any more on some servers, others it retries on multiple ports (I will say that I haven't analysed the traffic in detail because cba, so this could be other traffic apart from VOIP wrt to retries), so it was generally just a single deny line in the logs. The servers where voice worked, happened to be on one of the ports I'd already allowed. If it didn't... well.
I ditched all the individual ports and put a range in for the game (originally the range was 27000-30000 but that wasn't enough. Edit 3: dropped initial port to 12000 and maxed 32000 as there was a UDP packet at 13950 this morning. A Vivox post below suggested 12K - 32K):
UDP: 12000 - 32000
UDP: 4350 - 4400
20K ports is a fair old range, and now edges Discord with 13,500 ports.
I will update this with a larger range as and when things break.
Note: The policies are from 'Trusted Internal' (i.e. my PC) to 'Any External', as my FW will automatically deny outgoing traffic to a random port somewhere on the internet.
Note 2: Some evidence that this may be your issue, before you try messing about with your FW policies, is if when you press the voice chat keybind, you do not see the little graphic in the bottom left that shows your active mic. It appears that the software tries to send packets before triggering the voice icon on the overlay, so if it cannot do so successfully, then the icon will fail to appear. This appeared consistent across various games when voice did/did not work. If the icon appears, this is probably not your issue.
Note 3: I did notice that my FW was also blocking some traffic due to DDoS protection features. The limits were set at 100 connections/sec (per server/per client quota). I upped this to 500, and the traffic flowed again. I have done no testing on actual rates, so 120 connections/sec might have been enough; I may revise it down when I can be arsed. 100 connections/sec is a fair number, so I was surprised this limit was reached. A note of caution: correlation is not causation, so it might have been a combo of this game and other things too, the game just pushing it over the limit.
Note 4: Even writing (Note 3) made me feel dirty, with such a profligate approach to FW settings. Turns out the traffic limits were being breached by the 'Refresh Server' button, so was fairly easy to iterate over. Reset the 'Per Server' rate limit to 100, and appear to have settled on a figure of 170 connections per second for 'Per Client' quota to stop the packets from being dropped. This makes me feel better. The fact it happens on 'Per Client' leads me to believe that it's not just the game software, but will include other background activity too; but there's no denying that it certainly bursts traffic.
Note 5: Some people have reported having a VPN solves this - this lends credence to me that the problem may lie with a user's gateway hardware firewall/router (where it comes into your house) more. If the VPN from your PC is encrypting traffic in a tunnel straight out of your network, then your hardware firewall cannot interfere with the traffic.
Note 6: This post talks about requiring ports 12000 - 32000 UDP for Vivox, but so far I haven't found any out of the range above. https://sites.google.com/site/tecolaproject/virtualworld/technical-support
Addendum:
I didn't need to check this stuff in this addendum as it seemed to work, but while fiddling about checking out Vivox, there's a customer help page on solving Vivox issues, with a whole suite of checks to run through:
with this link being the most interesting on how to disable SIP-ALG (Vivox uses SIP apparently) on your router:
Be interested to see how well it works.
Addendum 2:
This is getting silly. Many games seem to use Vivox, and thus is a SIP based service. Discord does not use SIP, it uses WebRTC, while similar to SIP, just uses whatever protocol the devs choose to deliver the data - in this case, I think Discord rolled their own delivery mechanism, so did not need to use SIP as a protocol. This means that when someone says, 'Discord works, but not this!' - they are comparing Apples to Oranges.
A number of other posts discussing fixes for SIP-based in game voice (for other games like PubG, Foxhole etc. etc.) chat seem to coalesce around disabling SIP-ALG wherever possible on hardware router/firewalls (it works like a kind of NAT, but mangles the endpoint IP address, so delivery fails. As they are all UDP packets, there is no error checking. Why not use TCP! TCP is no good for voice chat, as it takes too long due to the in-built error-checking. You just need a stream of packets as fast as possible.).
