My experience, forward RTP to UA for god's sake

Discussions about using SIP Sorcery on your own computer/server
Post Reply
fixup77
Posts: 93
Joined: Sun Jan 27, 2008 1:56 am

My experience, forward RTP to UA for god's sake

Post by fixup77 » Thu Jan 13, 2011 5:51 pm

I've been running SS for a year now and love it, before I had been running the old version SipSwitch. However, I had been suffering from unreliable calls and finally figured it out recently.

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 199.199.199.199:16384.
As you see, SS only mangled the private IP to public, the UDP port was not mangled.

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
Last edited by fixup77 on Sat Jan 15, 2011 6:49 pm, edited 3 times in total.

User avatar
Aaron
Site Admin
Posts: 4563
Joined: Thu Jul 12, 2007 12:13 am

Re: My experience, forward RTP to UA for god's sake

Post by Aaron » Thu Jan 13, 2011 10:25 pm

Good tips!

What you're hitting there is Port Address Translation (PAT). The solution you've used of retricting the port range on your ATA is an interesting one. It's good to hear it's working although I wouldn't think it's bullet proof. For example if for some reason you ended up with more than 2 calls you'd run out of ports and be up against PAT again. However that's not as important as getting something that works for a single call which is probably the case you'll be delaing with most.

You can read a post I did on the whole NAT and one-way audio thing at http://sipsorcery.wordpress.com/2009/08 ... -problems/. The bit describing PAT is about two thirds of the way down, search for PAT.
So mangling does help and is better than nothing it doesn’t always work depending on what type of NAT device is in front of your phone. Because the sipsorcery service only deals with SIP, and not RTP, mangling is the ONLY thing it can do. There is no other magic it can do to try and get the RTP streams connected up. The best advice for one-way audio and using sipsorcery is to try and set up your router to NOT do port translations on the range your phone uses for RTP.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest