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