This page presents some technical details of VoIP (voice over IP, videoconferencing) related to Ekiga software.
What is SIP?
SIP stands for Session Initiation Protocol. It is defined by RFC3261 and provides a method for registering with VoIP service (or 'Dial-tone') providers and initiating/receiving VoIP calls.
Once a 'call' is created, the audio (and optionally video) is sent directly between caller and callee, although it is possible to use SIP proxies - where the call is routed through the proxy.
The audio/video is encoded/compressed using a codec. Different codecs are available within Ekiga, and each provides a compromise between audio quality and bandwidth required.
A SIP number normally looks like an email address, for example, firstname.lastname@example.org. The part before the '@' represents the user, and the part after represents the service provider.
The user part may be either numeric or alphanumeric, depending on the provider. For example, Ekiga.net uses alphanumeric usernames, but each has a numerical alias to enable dialing from a standard telephone key pad.
To dial a number on an application (such as Ekiga), just enter the SIP number.
With a telephone keypad it is not possible to enter alphanumerical characters, so it is not possible to enter the provider portion. To make calls to other providers, the user can use a peering prefix.
Another problem is that unlike a normal telephone, the full 'user' part of the number must be entered before the call is placed and the number can be any number of digits. In this case, the '#' can be used to indicate that the number is complete. Another solution is to set up a dialplan (which interprets numbers as they are typed).
In order to differentiate a SIP number from an email address, the 'sip:' URI should be used, for example sip:email@example.com.
How contact presence (online, offline) works in SIP
The ekiga.net SIP proxy (kamailio) has a table with SIP addresses, their state, and the users who are subscribed to an address.
If the user eugen for example wants to know the user yannick's state, then:
- eugen's Ekiga client sends to ekiga.net a SUBSCRIBE sip:firstname.lastname@example.org
- ekiga.net adds eugen as subscriber for yannick
- ekiga.net sends a NOTIFY to eugen's Ekiga client containing yannick's current state
- each time yannick changes state (or when he registers), his Ekiga client sends to ekiga.net a PUBLISH sip:email@example.com with his new state
- upon reception, kamailio sends to eugen's Ekiga client (and to all of yannick's subscribers) a NOTIFY with the yannick's updated state
- PUBLISH and SUBSCRIBE (as well as REGISTER) are subject to an expiry period. This is why, even if yannick's Ekiga client does not change state for 500 seconds, it will still send a PUBLISH sip:firstname.lastname@example.org to ekiga.net
- if after 10 - 15 minutes ekiga.net does not receive any PUBLISH sip:email@example.com from yannick's Ekiga client, then it marks yannick as offline in its table, and sends to eugen's Ekiga client (and to all of yannick's subscribers) a NOTIFY with yannick's offline message. The same applies for SUBSCRIBE
ENUM enum allows you to associate your real phone number to a SIP or H.323 address and to be callable by other users using that phone number. Otherwise said, it is a method to provide a unified numbering system between the public switched telephone network (PSTN) and various VoIP providers. It is supported by some (but not all) service providers.
Technicaly speaking, Enum is a mapping of telephone numbers in E.164 format to domain names using a Domain Name System (DNS)-based architecture, specified in RFC3761. As official implementation using the e164.arpa domain is slow to progress, you can use Enum mechanisms with non-official but free registra like e164.org owned by enthusiastic people willing to test the Enum system (the Internet Telephony Users Association, a non-profit association). View the Enum implementations around the world
ENUM works by acting as a look up service. A recipient registers their PSTN number with e164.org (or other ENUM registra) where they can provide a VoIP number, email address and URL.
- Provider registered number: Some providers automatically register the numbers that they provide to their users, in which case you don't need to do anything - it will just work.
- Registering your own PSTN number: You can register an account at e164.org's public ENUM with your PSTN number in international format (ie. +33 123 45 67 89). You can now add your email, your instant messaging account and your (Ekiga.net) VoIP number to this account. Most registrars require some form of authentication to prevent prevent people registering PSTN numbers which aren't theirs. e164.org does this by placing a call to the PSTN in question so that they can confirm that the real owner is the one attempting to register.
- Calling an ENUM: When a caller places a call to a registered phone number, the dialtone provider (PSTN or VoIP) does an ENUM lookup to find out whether the call can be placed via VoIP or PSTN, and then places the call using the cheapest route. If a dialtone provider does not use ENUM, it is often possible to use a peering code (VoIP) or an access number (PSTN) to link to one which does.
Calling from PSTN network
- Using a phone provider that has ENUM lookup: The caller just dials the telephone number. Their provider will check automatically if this phone number exists in the ENUM directories and decides whether to route the call via VoIP. If the phone number is not found in the ENUM directories, the provider will use the PSTN to place the call.
- Using a phone provider that has no ENUM lookup: The caller will need to call via a phone service that links to an ENUM look up service. SIP Broker offers (via sponsors) access phone numbers to connect to its service from the PSTN. If the phone number does not exist within the ENUM directories the call is terminated. For example, in France you may call 01-72-09-04-04 to reach SIPBroker and then dial *673 500# to call the ekiga's echo test.
Calling from a VoIP Network
Some VoIP service providers automatically do ENUM lookup on all numbers dialled, in which case the call will be routed via the best/cheapest route.
Unfortunately Ekiga.net has no automatic ENUM lookup, the user can use another network to do the ENUM lookup. This can be done via SipBroker, to place an ENUM call add *013 (the Sip Broker/ENUM server prefix) to the start of phone number. The current Sip Broker behaviour queries 5 ENUM roots: e164.arpa (the only one official, see RFC3761), e164.org, e164.info, e164.televolution.net, and enum.org.
Peering is the term given to agreement between VoIP Service Providers which enables the users of one service to call users of another.
This is usually implemented by dialing a special prefix number and then the number of the recipient (on the 'other' service).
The prefix numbers
Each provider has its own list of prefix and its own agreements with other PSTN and VoIP providers. Some of these prefixes are standardised to be the same on multiple dialtone providers.
- Peter is calling his friend Mark.
- Mark's phone number is +33 123 45 67 89 (International telephone format).
- Mark's phone provider is Provider M.
- Peter uses Provider A to call Mark.
- The call should go then from Provider A's network to Provider M's network.
- To do this, Peter needs to dial the prefix of Provider M : *789 telling Provider A to switch the call to Provider M.
- So Peter had to dial : *789 33 123 45 67 89 to call Mark
Now, Peter uses his cell phone using then Provider B.
- For Provider B, the prefix for Provider M is *456
- So, from his cell phone, Peter has to dial *456 33 123 45 67 89 to call his friend Mark.
The global prefix numbers
However, a global solution exists, unifying all providers and giving each one an unique prefix
So, Peter, from whatever telephone provider he wants to use, can call his friend Mark either using the global prefix of Provider M. For example *123 33 123 45 67 89.
If you want to call someone on the same network, you do not of course need to add the prefix.
A list of all global prefixes is available of the SipBroker's White page.
Understanding NAT/firewall issues with SIP clients (eg ekiga)
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.
- 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:
- 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)
- 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.)
- Do I need to make a special provision for firewalls and routers to make calls?
- 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.