|
 |
| Fri, Jul 18th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 22:59 UTC |
|
|
login « register « recover password « |
|
| [Article] | add comment | [Article] |
|
|
|
NAT stands for Network Address Translation. It's the technology which allows most people to have more than one computer in their home and still use a single IP address. Most of the time, a router with NAT support gets data packets from the internal network (with internal IP addresses) and sends them to Internet, changing the internal IP address of each packet to the external one. Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly.
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. Author's bio: Diana Cionoiu is CEO of the Null Team, the company that made YATE. T-Shirts and Fame! We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about. [Comments are disabled]
[»]
SIP + NAT, a problem solved Eyeball Networks offers AnyFirewall Engine (for SIP end Points) 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.
[»]
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 . Anything short of that are simply hacks.
[»]
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:- http://www.voipuser.org/forum_topic_7295.html Here's a working link to an article on ICE:- http://www.newport-networks.com/whitepapers/nat-traversal4.html
[»]
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.
[»]
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
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 ?
[»]
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. --
[»]
Re: A better solution i think there is no need to reinvent the wheel here. this sipping draft 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.
[»]
Re: A better solution
|
|
