Understanding NAT/firewall issues with SIP clients (eg ekiga)

From Ekiga
Revision as of 09:13, 21 November 2011 by Eugen (Talk | contribs)
Jump to: navigation, search
Emblem-important.png This page is not yet finished, please contact us if you wish to improve it.


A simple network

Suppose A wants to call B and they are on a network where both have public IP addresses that looks like:

A --- ... --- B

On this simple network, A can call B directly by using B's IP address directly in the URL bar of ekiga. However:

  • A must know the IP address of B, and
  • neither the presence indicator nor other services work.

A more realistic network, with a SIP server

To work around these limitations the classical solution is to use a SIP server interposed between A and B. SIP (the Session Initiation Protocol) is a protocol used by some VoIP servers such as asterisk and ekiga.net. A more realistic network would therefore be more like:

A --- ... --- ekiga.net --- ... --- B

In this case, A and B first need to register with ekiga.net after which they can call each other through ekiga.net.

A more common realistic network, with a SIP server and NAT

In order to be contacted, A and B need public addresses. Nowadays, however, machines more commonly sit behind a NAT router which issues them private addresses and makes them invisible from the outside so they cannot be contacted directly. So a more common realistic network looks like:

A --- NATA --- ... --- ekiga.net --- ... --- NATB --- B

For common protocols, such as HTTP, the server does not need to know client addresses, because communication is always started by client. In the case of communication via SIP, one of the clients will has to be alerted by either the other client (the one initiating the call) or the SIP server, so special mechanisms are needed.

In order to connect A and B, ekiga.net needs to know the public IP addresses of A and B (or their NAT routers to be precise, since private IP addresses have no meaning on the wider Internet). Since communication may take place through proxies (which change the addresses in IP headers), ekiga.net can't obtain them from the IP header of packets.

There are two solutions to that problem:

Before registering, A and B must discover their public IP addresses (corresponding to NATA and NATB respectively) and send them to ekiga.net, so that they can be contacted afterwards. So, before registering, A and B contact another server (eg stun.ekiga.net) to discover their public address (given by NATA and NATB respectively), but also the type of their NAT (see http://www.voip-info.org/wiki/view/STUN for types of NAT).
STUN is a means to take care of this and ekiga 3.x uses it be default.

Version information:
In ekiga 2.x you need to select a check-box in the Assistant/Preferences.

The clients begins with sending a REGISTER with a private IP in *both* Contact and Via, Via also containing rport parameter. The server will reject the request, adding received and rport parameters with the IP and port from the packet. This is done by each proxy in the path, therefore when the client receives the response, the top (and only one) Via contains the external IP and port. Now the client can resubmit the REGISTER with the external IP and port in the Contact (but private IP in Via), which should be accepted. With some more magic (which requires the private address in Via) this can work with almost any type of NAT.
Notice that this is how Linphone and Nokia N900 (and probably other clients) work. However ekiga.net rejects REGISTERs with private Via, which breaks these clients. Also, it seems that some registrars, such as iptel.org, do not use IP address/port from the application-level, but from IP header, so it works without STUN too.

Now, suppose A and B have registered to ekiga.net. If A wants to contact B there are several solutions:

  • The simplest and fastest solution is for the clients to contact each other directly. Unfortunately this doesn't always work (refer to the section below).
  • The communication can be passed can be relayed through a proxy. There is currently no such service available for video, given the amount of traffic it would have to carry. Proxies for audio-only traffic, do however exist.
  • The communication can be relayed through several proxies. This is the approach Skype uses, where proxies are users with public IP addresses.

Direct communication by bypassing NAT

So A wants to initiate communication with B. The public (NAT router) IP addresses of of both clients are known by ekiga.net, which informs B of the incoming transmission. There is still the issue of which destination port should A use to contact B that needs to be addressed. NATB can generally be one of the following (from RFC 3489):

All requests from the a particular internal IP address and port are mapped to the same external IP address and port and any external host can send a packet to the internal host, by sending a packet to the mapped external address.
Workaround: ekiga.net memorises B's ports too, and informs A.
Restricted cone
The same as full-cone NAT but an external host X can send a packet to the internal host only if the internal host has previously sent a packet to X.
Workaround:  ???the same technique as for port restricted cone can be applied???
Port-restricted cone
Like the restricted cone NAT, but the external host can only send a packet to the internal host on a port which the internal host has previously sent a packet to.
Workaround:???B sends a packet from B:ports, and this allows A to send packets to B:ports???
All requests from a particular internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. Different mappings are, however, used for different destinations. Furthermore, only an external host that receives a packet can send a UDP packet back to the internal host.
Workaround:B cannot be contacted ("only the external host that receives a packet can send a UDP packet back to the internal host"). If NATA is symmetric nat, then ???TODO??? (he can call, but cannot be called??)

Open questions and miscellaneous bits

Which ports are used (RTP audio/video, SIP etc.)? (Yannick's answer): All ports are UDP.

SIP (signaling) is by default 5060, unless STUN reports a NAT.

RTP AUDIO stream is usually 5061/5062 (the first port is the steam itself, the second is for statistics; only the first one really matter. Maybe the second one does improve quality under some circumstances)

RTP VIDEO stream is usually 5063/5064 (same as for audio)

I'm not sure audio and video streams really change ports in the case of NATs. I've various logs, I need to perform a search on them...

  • A sends at app-level to B the following information: his IP address, the ports used to receive audio and video.
  • Other solutions for symmetric nat:
    1. SSL VPN like OpenVPN to get outside the restricted network (I use this myself when traveling in countries where the ISP's are not SIP friendly)
    2. STUN but that is more of a NAT Traversal option and very few restrictive firewalls permit STUN if they don't permit SIP???
  • One would assume that it works for OUTgoing calls without any special

provision for firewalls and routers. In fact, I can attest that it _sometimes_ works with an echo test without any special provisions (no ports opened). (But most of the time it doesn't work at all.)


  1. Do I need to make a special provision for firewalls and routers to make calls?
  2. Are there different requirements for different SIP providers, for example, Ekiga.net and Diamondcard.us?
  • I installed version 3.2.6, and it consistently passed the echo test with several sites. I have a Linksys WRT54GL, with no special provision for SIP--no ports open for incoming calls. I did not use STUN.

You do not need STUN or specially opened ports for outgoing calls.

Personal tools