Reading the console output, I see something like this:
Code: Select all
DialPlan 08:49:55:996: SDP on UAC response had RTP socket mangled from 192.168.1.101:16384 to 22.214.171.124:16384.
Therefore, a straight solution is to change the RTP port range from 16384-16482 to 16384-16385 and forward these two UDP ports to the UA (PAP2 in this case). This resolution is simple and reliable, problem solved.
The other solution is to use NAT mapping and STUN. Then the SDP from the UA has public IP:port and thus SS won't need to do mangling. Seems perfect and elegant? In reality, it is not reliable.
After about 2 hours, the DNS of STUN server is expired (most DNS servers have a TTL of 7200). When a call comes in or goes out, the UA has to get the IP of STUN again with a new DNS request to the DNS server. This takes time, especially if the network connection is not so fast (mine is EVDO) and the network and/or the DNS server is busy at the moment. Then again, the following request to the STUN also takes time and sometimes no response at all from the STUN due to unreliable UDP instead of reliable TCP.
The result: the UA takes a long time to ring, sometimes so long that it does not ring at all. Sometimes when it finally rings, no audio, because it did not get its public IP:port from the STUN server in time. When SS sees its private IP:port in its SDP, SS mangles the IP but not the RTP port - audio trouble. Sometimes no CID, because SS sends the CID to the UA via UDP (not TCP), the UA was so busy with DNS and STUN at the moment and missed the UDP packets, partially or entirely.
Even if all is well, there is still a chance that the UDP port that STUN sees is not the one for audio, you are still in the dark side of silence.
So, for reliable calls, please narrow down the RTP port range and forward them to the UA. You don't have to narrow down the port range, but then you'll have unnecessarily too many ports to forward. If you have to use STUN, use its IP address instead of its DNS name and use a reliable STUN server nears you, and beg god for successful STUN requests each and every time. For STUN to work, PAP2/SPA1001 requires at least 3 RTP ports (e.g. 16384-16386).
[for example, at this very moment stun.counterpath.com is blocked. 2011/01/13 14:30 PST.]See how unreliable stun can be:
Code: Select all
C:>\stun stun.counterpath.com STUN client version 0.96 Primary: Firewall Return value is 0x00000b C:\>stun stun01.sipphone.com STUN client version 0.96 Primary: Blocked or could not reach STUN server Return value is 0x00001c C:\>stun stun01.sipphone.com STUN client version 0.96 Primary: Open Return value is 0x000001 C:\>stun stun01.sipphone.com STUN client version 0.96 Primary: Open Return value is 0x000001