About STUN:
Reading it, it would seem like the app could ask about itself and then
forward the "real" IP(s) and ports, avoiding having the STUN server get a
lot of hits. But this is a REAL workaround no matter what. That doesn't make
it a bad thing. The documents really clear that it is a way to deal with
undocumented NAT processes.
It would seem like this might help... but really its probably not useful.
The programmer(s), I think, should be attentive to the idea some
configuration thingus could change the the session using whatever protocol
suddenly can't continue. If so, maybe reinitializing the transactions after
consulting STUN can be done without having the session itself fail.
I guess if the process/program is doing a one to many by any methods...
(multicast, lots of streams, etc), it could keep asking the STUN server
about itself, they try to advise the other end so the STUN server doesn't
get flooded. But its probably a race condition without formal timeouts anyway.
messy.
regs
Dan