I've had a lot of puzzles to solve before I could use sip-communicator successfully.
The SIP/SDP call setup seems to work well, but the establishment of the RTP/RTPC
audio streams has been very tricky. However, I've had similar problems with non-java
softphones, so I've kept banging away.
If you read my other post, you'll find out the details of the only successful software
configuration (that I've found so far).
I use a Cisco Pix firewall. I had to upgrade the software to version 6.3(3) before I
resolved all the problems with NAT and the stateful SIP firewall support. There are a lot
of claims out there that sip doesn't work properly with "symmetric firewalls", but I can
say <nervously> that it seems to work OK with mine.
I've now conducted a series of tests with sip-communicator outside my firewall... I setup
sip-communicator.xml with three different stun server settings...
1. "" (empty string) to disable STUN logic.
2. "stun01.sipphone.com" - the default setting.
3. "stun.fwdnet.net" - because I have a Free World Dialer account.
All three settings work fine outside my firewall. The 2 stun servers provide identical
responses, and these responses are effectively no-op results. As expected, I don't
need stun when my sip-communicator is using a native internet address, but it is nice to
know that it doesn't matter if I leave stun configured.
It is a different matter inside the firewall. Using the latest stateful SIP proxy, I would
expect to succeed with a no-stun configuration. The firewall ought to translate all the
embedded IP addresses and port numbers, but it doesn't work properly. However,
when I define either of the two stun servers, my calls are established successfully and
the 2-way audio traffic flows properly. (I haven't the time or enthusiasm to work out the
I doubt whether anyone is very interested, but I've also tried a double-nat arrangement.
This is a quite common arrangement in corporate networks. A "choke" router acts as a
crude port-based firewall and NAT's addresses between the internet and a dmz lan.
The statefull firewall then NAT's between the dmz lan and the safe internal lan. I
couldn't find a way to make this arrangement work - the stateful firewall proxy and the
stun server were always confused by the presence of the "outer" nat router and so the
media streams were not connected properly.