-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nella citazione in data gio 27 dic 2012 20:14:20 CET, Jared K. Smith ha scritto: > 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 Hi Jared. Thank you very much for your closer analysis. If I understood fine, Fedora's firewall allows the outgoing UDP packets sending from Ekiga on condition that the reply (from "Bob") comes back in a prearranged time, although it is not guaranteed. In this way the (Fedora's) firewall setup is not fundamental according to the ekiga wiki page. - -- Antonio Trande "Fedora Ambassador" "Fedora italian translation group" "Blogger" mail: mailto:sagitter@xxxxxxxxxxxxxxxxx Homepage: http://www.fedora-os.org Sip Address : sip:sagitter AT ekiga.net Jabber :sagitter AT jabber.org GPG Key: D400D6C4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ3L36AAoJED2vIvfUANbEoq0P/0eOvI0kuzBEXWIxa48SE9pQ thhPi6aSWynSghySWId9TQxzW5FVofb99jOiJrxIA6G6odA7/PkEkb0W4CcQksH0 BQu4GrT0pXjmwciX4QfGhBYrWZWUFSrr6CeJ6z2SxpVZGHoaB0gP9Xl6gQ5NL3e/ cGg/lLpLkzNRplmOAFkZ6AWFAHbyoDdA7+2qZmy35fHDSiv5orrF97dsoZN4t4kH fwIMsXJFKf1t0KyYcEN7D3fa+VH7TuZq+kzUKGpzW5g/b0Uc4W4Jg2K2ZC3U4kN+ oo1h8DdYrTF100eOFAxRbgEILQdVuAjOvWoyb4h4R2Mqh+5OZfKpvzSy3IGZJwYV yqMGUtiH3yfBEpcDKiwNMmOTLMYg+sOG6VOnW+LOtIk/iCJULOgyuvEWznMX+3dh U8vtYV/ikhdrcrycEvdJ3YdWOFdj4TqmqYFXcdlR/RFdurfHVymmiVs02hPjOcb2 07+EIEyMe+zKvqw/76sHW1Wo62rY5GVA3IH+PbAO05dFDNbDx3TaJlrMET0bya/5 45sd5O4eWmeZx6oeGVqRHa8MWbTIbHBYxirA19sFXG3/JQFsFuaDtYVP3wZ7r0p+ bnwln3FYzjNqxE1E/uQGY2yYAQYtMtKg5ZrUn8EyufKDnh48Wp9036nIvMNdMekj 07iR9l8BtSOK6dcOLLnE =pjbd -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
