Robert Shearman Jr Posted December 15, 2017 at 12:33 PM Posted December 15, 2017 at 12:33 PM Hi Ross (et.al.) -- Much ado is made here in the forums regarding the issue where vPilot ceases receiving incoming transmissions due to a timeout of the data port on the pilot's router. I am currently having an issue where, even with the port forwarding set up properly, I still have issues receiving transmissions when switching to a new channel, possibly due to a firewall setting on my PC itself -- I'm still investigating that. However -- and I'm not a tech guru so please let me know if this is ridiculous -- what would be the feasibility of having vPilot send a periodic "ping" to the voice server, set to an interval just below the "usual default" timeout duration, to keep the port open both on the originating PC's firewall and the local network's router? Would the voice servers be overloaded by this or would it be a reasonable amount of bandwidth as not to adversely affect it? And more importantly, would it solve the issue for most, where we would stop seeing the weekly messages posted to the forum asking "why do I stop hearing incoming transmissions every few minutes until I press my push-to-talk?"? Cheers, -R. Link to comment Share on other sites More sharing options...
Ross Carlson Posted December 15, 2017 at 06:28 PM Posted December 15, 2017 at 06:28 PM Hi Robert, I looked into this back when I first got involved in VATSIM software dev (talking 14 years ago now ... wow) and I discussed it with the guys that wrote the voice code. I don't remember what it was, but there was a reason why we couldn't simply enable pings (or "heartbeats" as they're commonly called) to prevent UDP timeouts. It might be because the voice protocol doesn't support the ability to send a piece of data that is NOT considered to be actual voice data, so if we were to send a ping, it would have to be a "blip" transmission, and everyone in the channel would see their RX light illuminate briefly for every ping sent by each user in the channel. That would get annoying. I'll reach out to the devs again to refresh my memory on what the issue was. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Ross Carlson Posted December 15, 2017 at 08:37 PM Posted December 15, 2017 at 08:37 PM After talking with one of the original voice devs, it should be pretty simple to add a keepalive packet. One of the other current devs would have to handle that, VVL modifications are not something I do. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
1275389 Posted December 15, 2017 at 08:51 PM Posted December 15, 2017 at 08:51 PM After talking with one of the original voice devs, it should be pretty simple to add a keepalive packet. One of the other current devs would have to handle that, VVL modifications are not something I do. Would you be able to add this to vSTARS and vERAM as well? Link to comment Share on other sites More sharing options...
Ross Carlson Posted December 15, 2017 at 09:04 PM Posted December 15, 2017 at 09:04 PM After talking with one of the original voice devs, it should be pretty simple to add a keepalive packet. One of the other current devs would have to handle that, VVL modifications are not something I do. Would you be able to add this to vSTARS and vERAM as well? It would be a modification to VATSIM's core voice library, which is used in all my clients. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Recommended Posts