firewalld and Ekiga

[Jared K. Smith]

On Thu, Dec 27, 2012 at 1:38 PM, Basil Mohamed Gohar
<basilgohar at librevideo.org> 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