VATUSA Forums
General => General Discussion => Topic started by: Josh Glottmann on April 11, 2018, 12:43:49 AM
-
I'm on a university WiFi network and as a result, I have to consistently (every 20-60 seconds) tap my PTT in order to keep the voice port open. If I don't do this, I cannot hear pilots on the frequency when I'm controlling.
I know others have experienced this issue in the past and I'm wondering what the best solution may be. I'm not sure if my university would be able to open ports for me.
Is there any application which may be able to send a small packet every few seconds in order to keep the port open? Any other suggestions on how to resolve this?
-
I had this same problem. Never was able to fix it. I’ve moved since then.
It’s super annoying.... I feel your pain. I’d be interested to know if anyone else knows a fix?
-
Other than hitting the PTT key every 2 minutes...
No.
-
Is the issue related to your internet or is it a software thing? I have the same issues and it seems to be centered around VRC. I do not have these issues with the pilot clients. Do you experience this with the other ATC clients?
-
I have also had this issue with VRC in the past, but ever since I forwarded the appropriate ports, have not had any further problems with this. I have had some problems with pilots having the same issue on my frequency as well.
The port not being kept open is kind of a pain, but the only way I know of is to have the port opened on the router or firewall. Try making specific rule sets in the windows firewall settings and see if that helps any.
K
-
When I'm not on university WiFi, the clients work fine. It's the school's end that is causing the problems.
Perhaps someone could make a client to send an empty packet every 5-10 seconds through the ports used for voice.
EDIT: can someone provide me with the ports used for voice comms?
-
VRC uses UDP 3290
There are 2 others for vstars but I don't know them off hand. Easy to find with a google search.
-
It's weird for me. Some days I have the exact same problem, and some days my VRC doesn't have that problem. I just play luck with it really.
-
EDIT: can someone provide me with the ports used for voice comms?
Here: http://www1.metacraft.com/VRC/docs/doc.php?page=installing_or_upgrading_vrc (http://www1.metacraft.com/VRC/docs/doc.php?page=installing_or_upgrading_vrc)
-
I used to have the exact same issue, but it seemed to fix itself when we got upgraded internet speed. Wished I knew what the actual fix was because so many people have this issue but I'm not sure.
-
Network Engineer here! I can shed some light on the issue.
VRC uses UDP port 3290 for voice traffic. By definition, UDP traffic is stateless - it does not rely on the 2 parties agreeing on how/when to send it. When a pilot transmits on frequency, the voice server relays that to you as a UDP stream. The problem occurs when your router receives that traffic and does not know where to send it (your computer vs your phone vs your smart TV). The reason why keying up every so often alleviates the problem is because your router will track the UDP stream for some period of time (usually 30 seconds to a minute). When you key up, your router keeps track of that connection and while your router is tracking the connection, if it receives the UDP stream from the voice server, it is smart enough to see the two are related and sends it to your computer where VRC gets it. Port forwarding also alleviates the problem because now your router has a permanent rule telling it that ANY UDP data it receives on port 3290, send it to your computer (whether from the voice server or not).
This boils down to the fact that NAT sucks. It is a hack that was implemented to stretch the lifetime of the IPv4 address space. Most of the time, it works great, but things like this show its flaws.
Hope this helps someone understand :)
-
The real question is, can we trick it to keeping the port open with a small and simple lightweight application that sends a stream every so often?
-
This boils down to the fact that NAT sucks. It is a hack that was implemented to stretch the lifetime of the IPv4 address space. Most of the time, it works great, but things like this show its flaws.
Thanks for the input, do you have any recommendation?
-
This boils down to the fact that NAT sucks. It is a hack that was implemented to stretch the lifetime of the IPv4 address space. Most of the time, it works great, but things like this show its flaws.
Hope this helps someone understand :)
Super interesting post.
-
The real question is, can we trick it to keeping the port open with a small and simple lightweight application that sends a stream every so often?
No. Operating systems don't allow two applications to bind to the same UDP port. The easiest method is to port forward or be directly connected to the modem. There is not a way to have a small application sit and send blank packages over a port bound by vPilot, VRC, vSTARS, vERAM, etc. Windows, Linux, Mac OS, etc. will refuse the connection identifying that the port is already in use.
-
No. Operating systems don't allow two applications to bind to the same UDP port.
A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.
-
A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.
I did some thinking about this when Toby was trying to solve it months ago... Didn't think about muting the mic, but did think about pressing the PTT every 30 seconds for about a half second, just to keep it awake. I think the issue then became trying to figure out the particular code to do that (from my inexperienced perspective). If anyone has that ability, maybe they can take a whack at it? Seems like this could be a useful thing to have fixed.
-
Not an ideal solution but if all you want to do is send a PTT every 'x' amount of seconds AutoHotKey https://autohotkey.com/ (https://autohotkey.com/) works. I use this script to keep my screen saver from running. It presses the right shift key every 1 minute, 60000 milliseconds. You could easily modify to what ever keystroke you wanted.
CoordMode, Mouse, Screen
Loop
{
Send {RShift}
Sleep 60000
}
-
No. Operating systems don't allow two applications to bind to the same UDP port.
A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.
Easier solution is the port forward. What you're asking for is a rather convoluted solution that adds several new risks and failure modes.
-
No. Operating systems don't allow two applications to bind to the same UDP port.
A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.
Easier solution is the port forward. What you're asking for is a rather convoluted solution that adds several new risks and failure modes.
But he cannot do a port forward due to the internet he is using, that's why he is looking for an alternative.
-
But he cannot do a port forward due to the internet he is using, that's why he is looking for an alternative.
I get that.
Unfortunately, there isn't much of an alternative. A dedicated IP VPN would be easier than the aforementioned suggestions.
-
No. Operating systems don't allow two applications to bind to the same UDP port.
A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.
Would running a Macro program solve this? I.E have it hit your PTT every 30 seconds for 1 second?
-
No. Operating systems don't allow two applications to bind to the same UDP port.
A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.
Would running a Macro program solve this? I.E have it hit your PTT every 30 seconds for 1 second?
Sure it would, but there's risk associated with that. Most of us have other things going on while we control, and if you have that going and you pick up the errant swear, it's bad for everybody.
The next logical step would be to have that macro also mute your mic to mitigate that risk, but as we add complexity, we reduce reliability and resiliency, and we'll be back at square one before we know it. New risks, same problems, unfortunately.
-
I've just run into an interesting related problem as I have just started training for ATC again within the last month. I fly on one PC in my household and control on another, as my flight sim setup has the keyboard in a position that's not convenient to do a lot of typing on. My router forwards the appropriate port to my flight sim PC to avoid PTT issues while flying, but the other day while controlling Ground at a very slow airport, I had the issue come up on my controlling PC.
I don't suppose there's a way to open the port on my router to both machines? I'm certainly not a tech guru so maybe there is. Otherwise, I'm going to try Andrew's suggestion and will report back in a few weeks, I guess.
-
I don't suppose there's a way to open the port on my router to both machines? I'm certainly not a tech guru so maybe there is. Otherwise, I'm going to try Andrew's suggestion and will report back in a few weeks, I guess.
No.. because when "stuff" comes into that port that isn't part of an already established connection, the router won't know which computer to push it to. So when the connection gets dropped, there isn't an established.. so it defaults to the forwarded port setting. If you were able to have more than 1, well, it won't know where to send it.
-
I don't suppose there's a way to open the port on my router to both machines? I'm certainly not a tech guru so maybe there is. Otherwise, I'm going to try Andrew's suggestion and will report back in a few weeks, I guess.
No.. because when "stuff" comes into that port that isn't part of an already established connection, the router won't know which computer to push it to. So when the connection gets dropped, there isn't an established.. so it defaults to the forwarded port setting. If you were able to have more than 1, well, it won't know where to send it.
Gotcha. That was my understanding, but I didn't know if it perhaps could be sent to both where it would be ignored by one. But I appreciate the confirmation.
-
Question -- if using AutoHotKey to send a {LCtrl} every so often, should I see the "Tx" light light up on my primary frequency? Because, I don't. I'm seeing it when I physically press Left-Control, but not at any other time. I even modified the script to (a) reduce the wait time to 15 seconds, just for testing purposes, and (b) included a "SoundBeep" command just for testing so I would know when it was being sent. I hear the beep every 15 seconds but I see no activity on the Transmit light. I'm aware that AutoHotKey sends only to the "Active" window and I am sure that the VRC window has the primary focus at the time. Any advice is appreciated. Otherwise, maybe I'll just be sure to control when the frequency isn't bound to be so dead, lol...
-
Question -- if using AutoHotKey to send a {LCtrl} every so often, should I see the "Tx" light light up on my primary frequency? Because, I don't. I'm seeing it when I physically press Left-Control, but not at any other time. I even modified the script to (a) reduce the wait time to 15 seconds, just for testing purposes, and (b) included a "SoundBeep" command just for testing so I would know when it was being sent. I hear the beep every 15 seconds but I see no activity on the Transmit light. I'm aware that AutoHotKey sends only to the "Active" window and I am sure that the VRC window has the primary focus at the time. Any advice is appreciated. Otherwise, maybe I'll just be sure to control when the frequency isn't bound to be so dead, lol...
Yes. If the AHK is actually hitting it and causing the client to burp a Tx, you'll the Tx light. If it's so quick you don't see it for some reason, you could have a buddy get on your freq when you're doing this and tell you if they see or hear the rx flag.