NAT traversal for the SIP protocol
What's RTP?
RTP stands for Real-Time Transport Protocol. Its purpose is to pass voice data between a caller and the called. The problem is that when you call someone using the RTP protocol, you need to know his IP address and port. This makes RTP quite inconvenient when used alone, since the parts have no way to find one another. This is why people invented SIP.
What's SIP?
SIP (Session Initiation Protocol) looks in syntax like HTTP, human readable text. Its purpose is to help the caller find the IP address and port of the called. It also helps the negotiation of the media types and formats. For example, when you have a PC at home and you want to call your friend from Romania using Free World Dialup (which uses the SIP protocol):
SIP sends an INVITE packet with the caller IP address and port for RTP to the FWD server, and from there, FWD forwards the call to the intended destination. The called accepts the call and sends his own IP address and port for RTP back.
SIP + NAT, an unsolvable problem?
The problem with SIP and NAT is not actually a SIP problem, but the RTP problem. SIP announces the RTP address and port, but if the client is behind NAT, it announces the client's RTP port, which can be different from the port the NAT allocates externally.
Even if a lot of SIP implementations and carriers are based on the fact that NAT will always try to allocate the same port, that assumption is false. In a production environment, you can't tell grandma that she can't talk with her grandson because some router has allocated another number.
If you are a carrier, the solution is simple because you proxy all the data, anyway. The solution is to use a SIP Session Border Controller. The SIP SBC normally stays in front of the internal SIP network of the carrier, solving the NAT traversal problem and protecting the SIP network.
The solution for NAT traversal in this case is to use some tricks.
The first trick is to keep open the hole in the NAT from the SIP client to the server. This is normally done by making all SIP clients use a two byte packet which is sent more often than 30 seconds. Some routers remove apparently unused NAT mappings after 30 seconds; GNU/Linux typically does this after three minutes.
The second trick is one we've used for our project YATE, to figure out the RTP IP and port from the first packet that arrives on the local RTP IP and port of the server, and to use it instead of using the RTP IP and address declared in SDP. This trick solves the NAT traversal problem, no matter how many NATs the client is traversing. However, the main disadvantage is that, in some cases, the client will not receive early media (since at that point, it sends out no voice packets) and it will not hear the ringing.
If you are not a carrier and you are trying to make a peer-to-peer call and both sides are behind the NAT, you must use an external SIP proxy or gateway to pass the SIP between the two points, hoping that the NATs will open the proper ports, one to another, for the RTP connection. However, there is no ultimate solution for that. Two proposed solutions are STUN and ICE, but every solution that currently exists can get in your way sometimes. Skype has found a very simple and nice solution for this problem: They use the Skype clients that are not behind NAT to proxy all the data for clients that are behind NAT.
This solution, technically speaking, is very good. However, there are some moral and political reasons not to use Skype. One of them is that if you are a Skype client outside the NAT, you don't know whose data is passing through your computer. Another is that it is using your bandwidth; after all, someone has to pay one way or another for Internet bandwidth necessary to proxy the voice stream.
My personal hope is that in the near future, most SIP implementations will use the two tricks used by YATE. Skype will probably be around for a long time for home users, but enterprise seems to move slowly to VoIP providers. With a lot of work and a little bit of luck, they will become at least as reliable as PSTN providers, since the technology is better.
A better solution
A cleaner solution is not to burden SIP (or any other application layer protocol for that matter) with NAT traversal logic, but rather handle the problem at a transport layer. Use generic tunneling service instead of UDP and let it worry about connectivity issues. Like Hamachi does it for VPNs for example.
I also believe you are wrong about Skype as it does seem to do a variation of UDP hole punching.
Re: A better solution
You cannot use VPN if you are a SIP carrier, and since there is already a solution there, why adding one more level of complexity, when you can avoid that?
The way Skype get out from the NAT is a long story and i just wanted to make it short. For the details you can use a document regarding Skype protocol.
Re: A better solution
> A cleaner solution is not to burden SIP
> (or any other application layer protocol
> for that matter) with NAT traversal
> logic, but rather handle the problem at
> a transport layer.
Pure BS and clueless. SIP is a layer 5 protocol and maybe the word
Session in it's name would have helped you there?
SIP does not have NAT traversal "logic" hence all the issues.
You want UDP (which is the most common transport layer protocol for RTP)
to handle NAT traversal? Simply amazing.
Full credit for A) the most wrong comment I've read in a long time and
B) for sounding informed to people that (like yourself) have no idea.
Re: A better solution
Slightly dyslexic today, aren't we ?
Neither SIP nor RTP need to run directly on top of UDP. They can utilize an alternative datagram delivery service that is UDP-like, and this service will provide NAT travesal. It may in turn run on top of UDP, but that's optional.
This, my little patronizing friend, called virtualized layering, a concept that you clearly do not understand well.
Re: A better solution
Oh dear. Simply no clue - why not write an article with your revolution? Of course someone who thinks SIP is a layer 7 protocol might not be able too... Maybe explain the magical NAT traversal logic that SIP contains?
Nobody claimed that SIP or RTP had to run on UDP, re-read what I wrote, it’s the most common - SIP also runs on TCP.
Anyway, I spend my days writing software for a leading vendor of SBCs (look it up) I understand the issues (where as you don't obviously) and the article above is well written and correct. Your comments are buzzword bingo and very wrong.
My advice, don't assume you know what you are talking about just because you gained your CCNA last week. You have a lot to learn both about networking (Mr layer 7) and how not to run your mouth off at people who have been kind enough to share their knowledge like the article author. Learn from the knowledge others share, don’t try and prove how much (or in this case how little) you know at their expense.
Re: A better solution
Not a big deal, and not getting in the middle of this, but please see Cisco's site as well as RFC3261 in regards to SIP as an application layer protocol.
>
> % A cleaner solution is not to burden
> SIP
> % (or any other application layer
> protocol
> % for that matter) with NAT traversal
> % logic, but rather handle the problem
> at
> % a transport layer.
>
>
>
>
> Pure BS and clueless. SIP is a layer 5
> protocol and maybe the word
> Session in it's name would have helped
> you there?
>
>
>
> SIP does not have NAT traversal "logic"
> hence all the issues.
>
>
>
> You want UDP (which is the most common
> transport layer protocol for RTP)
> to handle NAT traversal? Simply
> amazing.
>
>
>
> Full credit for A) the most wrong
> comment I've read in a long time and
> B) for sounding informed to people that
> (like yourself) have no idea.
>
>
Re: A better solution
> Anyway, I spend my days writing software
> for a leading vendor of SBCs
Much to their discredit, I'm sure. Please note the advice in large bold letters at the top of the posting page next time.
Re: A better solution
i think there is no need to reinvent the wheel here.
this sipping draft (www.ietf.org/internet-...) at ietf is just about to address this problem.
Re: A better solution
That draf has been made available to the public on March 2, 2006, which is long after we've implemented this in Yate and long after i've wrote the article.
> i think there is no need to reinvent the
> wheel here.
> this sipping draft at ietf is just about
> to address this problem.
>
Bad tricks
The two tricks mentioned in the article and apparently implemented in YATE are a little hokey. (Albeit implemented in many other places as well.)
First, it's very easy to steal the session, if the peer is simply assumed to be whoever sends RTP to the correct IP and port first.
Second, sending dummy packets every 30 seconds is extremely expensive. Using SIP over TCP would yield much longer timeout intervals; however, scaling many simultaneous TCP sessions is a little trickier. Also, another, perhaps safer, way is to simply force the client to re-register every 30 seconds or so.
For the ultimate NAT traversal solution, you should check out ICE (www.ietf.org/internet-...). Anything short of that are simply hacks.
Re: A better solution
> That draf has been made available to the
> public on March 2, 2006, which is long
> after we've implemented this in Yate and
> long after i've wrote the article.
Actually the first revision, -00, of that draft was published on 2002-06-27. Some major updates has been done since then, but from what I can tell there are only minor changes from -03 to -04.
draft-ietf-sipping-nat-scenarios
Re: Bad tricks
This topic has been such a useful read - thank you.
I just wanted to comment on the ICE issue (the link above is 404 btw) - ICE is not a protocol or form of NAT traversal. ICE is a proposed standard to encompass all such methods.
ICE is about being all things to all NAT devices - using systems like combinations of STUN and TURN to do the job. It's a framework.
There's some good background discussion on this here:-
www.voipuser.org/forum... (www.voipuser.org/forum...)
Here's a working link to an article on ICE:-
www.newport-networks.c... (www.newport-networks.c...)
SIP + NAT, a problem solved
Eyeball Networks offers AnyFirewall Engine (for SIP end Points) (www.eyeball.com/produc...) a Software Development Kit (SDK) for guaranteed VoIP and video call completion across NATs, firewalls, and Web proxies. AFE incorporates the most comprehensive implementation of the IETF standards STUN, TURN and ICE.
Re: SIP + NAT, a problem solved
Spammer.