On Thu, Dec 27, 2012 at 1:38 PM, Basil Mohamed Gohar <basilgohar@xxxxxxxxxxxxxx> wrote: > Someone with more networking experience than me should probably reply, I'll do my best to help give some background information here that might be useful. It's probably a bit more than you were expecting, but I've taught this topic for a number of years, and figured that some examples might be of some use. In general, the SIP protocol has *two* major problems with NAT traversal. I'll explain them below. For the sake of illustration, let's say that you have a SIP device behind a NAT firewall, which we'll call Alice, and it has a (private, RFC1918) IP address of 192.168.123.45. Let's say you're trying to communicate with both another SIP device (not behind NAT) on a public IP address of 44.55.66.77 -- let's call this device Bob. Just for the fun of it, let's say you also have a VoIP provider (we'll call it SuperHyperMegaVoIP) that you'd like to use to connect you to the public switched telephone network. It's at the domain sip.superhypermegavoip.com. The first (but less serious) problem of SIP and NAT traversal is that the SIP messages contain IP addresses and ports within the SIP messaging itself. Let's say Alice is trying to register with SuperHyperMegaVoIP, so that SuperHyperMegaVoIP knows where to send inbound calls to Alice. Alice sends a SIP message (a REGISTER message) to sip.superhypermegavoip.com. That SIP REGISTER message says "I'm Alice, I'm trying to register, and my IP address is 192.168.123.45. Assuming that Alice authenticates correctly, SuperHyperMegaVoIP saves Alice's IP address for a limited amount of time. Then an incoming call comes into SuperHyperMegaVoIP for Alice, and they try to route the call to 192.168.123.45, and realize they don't have a route to that network. In a nutshell, a SIP client behind NAT is advertising its private (RFC1918) address, rather than its public address. I'm not an expert on STUN, but what I know about STUN is that it's a service whereby a SIP client (such as Alice in this example) can find out what it's public (masqueraded) IP address is, and use that address in SIP messages instead of its private address. Many SIP registration servers get around this issue by recording the actual IP address and port that the REGISTER message came from, rather than the one which was reported in the REGISTER message. The second (and more serious) problem of SIP and NAT traversal has to do with the way SIP handles voice (or video or other media). The SIP protocol is designed to only handle the messaging of call setup and teardown -- the media is described by the SDP protocol, and the media is transported using the RTP protocol. The SIP messages (containing the SDP session descriptions) are typically transmitted over port 5060 (UDP or TCP, but UDP is used more than 90% of the time). The RTP streams are transmitted using high-numbered randomly assigned UDP ports. So let's dive into an example. Alice wants to call Bob. Alice sends a SIP message (an INVITE message) to Bob. The INVITE message contains Alice's contact information and an SDP section which describes the types of media (audio typically, but could include video or other media types) that Alice is willing to use in the call, as well as the IP address and port on which Alice is going to be listening for media streams. Because UDP is a stateless protocol, when the firewall sees the outgoing UDP packet, it records the destination IP and port in a table and allows return traffic from that IP and port to go back to Alice for a limited amount of time. (And each time another packet goes out, the timer on that table entry gets refreshed.) As long as Alice sends a UDP packet to Bob every so often, Bob will be able to respond to Alice. The problem comes in when Bob tries to send audio (or other media) to Alice. Let's say the SIP messages from Alice say that she's going to listen for Bob's audio on her port 38719 UDP. Bob responds and says "Sure, I'll send you audio in an agreed-upon format, and I'll listen for your audio on my port 44901." Unfortunately, Alice's firewall knows nothing about this inbound audio coming in on port 38719, and is likely to reject the packets outright. (Some firewalls try to use a "fixup" or ALG to be smarter about this, but more often than not they only make matters worse.) The traditional symptom for this type of problem is one-way audio. In our example, Bob can hear Alice's audio, but Alice doesn't hear any audio coming from Bob. To make matters worse, there's very little Alice can do to get around this problem. She can hope that Bob is setup and configured for symmetrical RTP, where Bob sends his audio back from the same port that he's listening for Alice's audio on. (That's not mandated by either the RTP or SIP protocols, unfortunately.) Alice could also configure her firewall to forward tens of thousands of UDP ports to Alice, but that's a VERY BAD IDEA. Obviously you could also use VPNs to make Alice and Bob appear on the same un-NAT'd network, but VPNs tend to force TCP semantics onto UDP packets, and the encryption often adds to latency. Hopefully this background information helps you understand the SIP protocol a bit more, and in particular how the SIP protocol runs into issues with NAT firewalls. -- Jared Smith -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
