Hi Morten,
the problem is, that you not only need to get the call control (SIP) through your NAT routers/firewalls (which you did by the forwarding rule at the firewall), but also the audio streams. Assuming your scenario looks like this:
SIP Client (private IP, 192.168.1.10) ---- (192.168.1.10) NAT Router (217.194.238.1) ----- Internet (Public IPs) ---- Firewall (also NAT ?) ---- SwyxWare (private IPs, too ?)
This means, that the SIP client has to tell the SwyxServer (or a proxy):
1) Please contact me on incoming call to me on IP 217.194.238.1, Port A
2) Please send the audio streams to me on IP 217.194.238.1, Port X, Y
Without a STUN server configuration at the SIP client it is not aware, that it is behind a NAT router and therefore tells as SIP contact address and audio socket address always the private IPs (192.168.1.10) - of course SwyxServer or any other public user cannot contact the client with this private IP.
With STUN the SIP client always asks the STUN server (which is located inside the public internet), hey, STUN server, please tell me how my private IP-address/port does look like from your perspective ?
This means, the SIP client has to send a STUN request to the STUN server from it's private IP 192.168.1.10 and port 5060 to the STUN server. The NAT router on that way inserts inside its masquerading table a mapping from 192.168.1.10:5060 to e.g. 217.194.238.1:54321. This means, that answers to the NAT routers outside leg (217.194.238.1:54321) will get forworded to the SIP client 192.168.10.1:5060. Now the STUN server tells via a STUN response which is send to 217.194.238.1:54321 and therefore forwarded by the NAT router to the SIP client 192.168.10.1:5060, hey your message looked for me as it cames from 217.194.238.1:54321.
The SIP client did wait for this answer and now tells the SwyxServer/Proxy, hey, in case you have SIP messages for me, please send them to 217.194.238.1:54321 (and not the private IP as happend in your first test).
That's the trick with STUN and this must be done for SIP call control and also for the audio streams to be established.
Not yet complicated enough ? Ok, the story continues, because the masquerading table entries inside NAT routers are valid usually for only about 20 seconds. This means the STUN client has to send "dummy" traffic through this IP/port mapping continuously. Want more details ? Ok, there are different strategies implemented on NAT routers, e.g. with symmetrical NAT, STUN does not work at all - here is the only chance to use SessionBorderControlers (SBCs). In case you are interested in details, you can take a look into the STUN RFC: http://www.faqs.org/rfcs/rfc3489.html
In case the SwyxServer is behind a NAT router, too (not only a plain firewall), the same story regarding STUN has to be done on this side again. Currently SwyxIt (not SwyxIt! Now) and SwyxServer do not use STUN, BUT the LinkMgr can be configured to use STUN. In hosted version SwyxWare server will get public IPs and therefore the SwyxServer itself will not do STUN, but the SwyxIt! hosted version (client) has to do it, in case of NAT router usage.
How to help you now:
1) Enable STUN usage at your SIP client
2) Use an "intelligent firewall" at the side your SwyxWare is installed which manipulates the SIP messages regarding IPs and ports and forwards the media streams
3) Alternative to 2): Put the SwyxWare installation on a public, routeable IP address if this is possible
4) Next alternative: Use an ENUM link via the LinkManager (who has STUN support) to do the calls, but this means your SIP client is not registered to the SwyxServer itself as a Swyx-Client, you just can do calls to your other SwyxWare users via the ENUM link
In case you want to play around: Usually you can use any STUN server located in the internet, e.g. stun.gmx.de is a reliable one.
cu,
Stefan