By Rihards Bauga 1147153
#518966 Hi all,

For a few months now, I've been battling with a problem regarding losing voice comms during flight. After being around 5min on the frequency, communicating and receiving voice just fine, I suddenly stop hearing anybody, that is until I press the PTT again, sometimes all it takes is 1min for voice to timeout, sometimes it's more.
I've read up on the forums where people have had similar issues, and tried all of the offered fixes/workarounds but to not avail.
I've forwarded the UDP 3290 port and disabled firewall through my router, been through each and every setting there is to make sure nothing is blocking the connection, reinstalled vPilot (twice), made sure vPilot isn't being blocked by Windows firewall and so on, but the problem keeps persisting.
Needless to say this has made online flying close to impossible, without annoying the controllers (and myself) or disturbing others.

The only problem that I could think of myself is that my provider uses a virtual IP instead of a fixed one, but so does most of providers in my area..

Any input in this would be greatly appreciated, any suggestions or tips that might help to fix the issue.


By Bradley Grafelman 1242018
#518969 Try changing the Trigger Port to be 3782 and the Trigger Protocol to be TCP. If you're interested in the long-winded explanation behind that...

From the screenshot you posted, this page is attempting to not just do plain "port forwarding" but the more intelligent "port triggering." It's basically a way of telling your router "For as long as you see my computer using an outbound connection on port XXX over protocol YYY, start forwarding incoming packets on port AAA over protocol BBB to my computer." It's really only more useful than the more simplistic port forwarding (which is basically just the latter half of that applied 24/7) if, for example, you used VATSIM pilot/ATC clients on multiple different devices at different times OR if some other application on a different device happened to use the same 3290 UDP port RogerWilco uses for incoming voice.

As for the adjustments I proposed above, note that (IIRC) the voice servers don't receive voice from clients on UDP port 3290. I can't remember the port they use offhand. Either way, if you tried to use that outgoing voice data stream as your trigger rule, you'd still have the same problem - after not transmitting for a period of time, the router would see the rule is no longer being triggered and stop forwarding packets. A better trigger is to use one of the other connections the ATC/pilot clients make to the voice servers - a TCP connection that they keep alive even if no voice transmissions are made or received.

Having said all of that... it could still not work if for some reason vPilot isn't able to begin listening on UDP port 3290. From what I can tell, it seems like the voice software has the ability to handle that failure and instead use a randomly-generated, high-numbered port (e.g. BAW9340D with SEA_TWR right now is listening on UDP port 58968). If you're curious, you can use Windows' netstat utility to easily determine whether this has happened for you as well.
By Rihards Bauga 1147153
#518970 Thanks for the tip and the explanation! Did as you said and at the moment I'm sitting on ground at EGSS airport listening out to London Control, to see will it timeout or not. Hopefully everything works, fingers crossed. Will look into Netstat thanks for the tip.
By Bradley Grafelman 1242018
Rihards Bauga 1147153 wrote:Will look into Netstat thanks for the tip.

For what it's worth, I confirmed your vPilot is currently listening on UDP port 3290, so that last bit I touched on hopefully shouldn't apply/get in the way.