Sebastian, I know many people don't like STUN. However, I have good experiences with STUN and prefer to use STUN as a "first layer defence." For many NATs I then avoid the proxying. However, there are some things that can go wrong: For one, you need to make sure that the STUN server is running correctly on two ports and two IP addresses. If you for example have a firewall blocking one port, STUN will give the wrong result. But the biggest problem can be faulty STUN implementations in the EUCs. They normally behave ok for the most standard NATs, but there are some non-standard NATs and the EUC's behavior can be unpredictable. Also, some EUCs try to rewrite the IP:port even if they are behind a symmetric NAT (or if the STUN server is not correctly set up, the EUC will conclude with the wrong result). If you know the clients you are going to use, you can test and limit the problems and STUN can be a great cost saver! If your gateway supports active media (direction=active), then you only have IP-2-IP phone calls to proxy. To your question: Sipura has a good implementation of STUN, but has MANY options for NAT. Your problem is that the RTP and RTCP is not traversing the NAT to your Sipura. Either you don't force proxying in onreply for OKs, or something goes wrong. An ngrep trace of the call setup will reveal what the problem can be. g-) Sebastian Kühner wrote: