August 10, 2008

I see two issues that plague FLOSS VoIP apps and do not allow their widest adoption. The first VoIP app that gets these, should get fame and glory.

First, the majority of users are broadband users, with a router that protects the inside systems. It is not possible for an outsider to initiate a network connection to a system inside the LAN. If both users that try to communicate have this typical network configuration, then the current tools say something like «You have a symmetric NAT, and at the moment the way to fix this is to either put your computer in the DMZ or enable manually port-forwarding for specific ports.» Ekiga discusses this issue at Ekiga behind a NAT router and directs the affected users (when using the program) to that page. Twinkle (QT-based SIP-phone) shows you a dialog box with the exact ports to enable for port-forwarding on your router.

The issue of a symmetric NAT can be solved in most of the cases by using the UPnP protocol. If the router supports UPnP (most do by default), then the VoIP app can enable the port-forwarding by itself, transparently from the user, and it will just work.

Until recently there was no good UPnP library, which was probably the reason for the lack of support. However, this changed with GUPnP.

Ekiga already supports STUN and Zeroconf. With UPnP, the vast majority of users would be covered.

The other issue is the difficulty in configuring your third-party VoIP SIP account, that allows you to make inexpensive voice conversations to telephones and mobiles. The reason why it is difficult is because the user has to figure out the SIP server and other configuration details. The terminology is confusing, registrar, domain, etc.

Ekiga has good support in configuring Diamondcard. The user is presented with a Wizard when configuring for the first time Ekiga.

11 Responses to “Features for the killer VoIP app”

One thing to remember about upnp, many distros today run SELinux or AppArmor as well as firewall. You will need some (hopefully not to insecure) means of granting privilages to open the local firewall otherwise you are negating it’s effect.

If this is even possible to do securely, one has to wonder.

Another FLOSS VoIP problem for me is that we are competing with Skype, they have a product that requires little configuration, runs everywhere and comes bundled with devices.. hell my cellphone does skype (implemented in Java, it’s very cool, I have all my Skype contacts directly in my contactlist). It’s a mighty task to beat this level of saturation, so we need to be easier to use (e.g. do all the magic for me, then afterwards let me change it if I so desire), and we need to run everywhere. Ideally we would offer to integrate VoIP into our platform, empathy can help us here I suspect.

Another problem, we may have to reverse engineer Skypes protocol and keep playing catchup for a while. We will want to keep their existing contacts and we can’t expect everyone to switch just because we release a nice FLOSS application.. afterall Skype works for them. I e.g. would love to swith my VoIP needs to FLOSS but everyone I know uses Skype and are stuck there, for me to switch I need to first be able to keep talking to them, then I can graduately convince them to switch as well. This I suspect will be a metric shit ton of really unpleasant work.

David, you seem to confuse simple VoIP aimed at chatting and IP Telephony, like many other people.

It is a bit disappointing.

Can you use Skype with your PBX at the office ? Can you transfer calls ? Can you put a call on hold and have the remote hear music on hold ? Can you configure Skype to redirect the call to another phone if you are already in a call ?

Skype, or MSN or even Jabber do not implement IP Telephony, they are limited to trivial VoIP chatting between peers. They are different software and have a different purpose than software like Ekiga.

For SELinux and AppArmour, I believe this would be a just request to the respective teams to enable rules for Ekiga so that it works with UPnP.

Skype is proprietary and there is big effort from their company to keep it closed. You can search for attempts to reverse-engineer the Skype protocol.

One thing that Skype does well is it uses aggressive methods to work when the network configuration is restrictive. Comparing Ekiga and Skype on this respect, Ekiga requires to have support for UPnP so that for the vast majority of users it would work out of the box. For the users with symmetric NAT and no UPnP, Skype “uses” the computer resources of random customers as proxy servers. In addition, if required, Skype can also use non-standard ports (such as 80 and 443) in order to bypass firewalls. Shall Ekiga replicate all these aggressive methods? The issue is to get UPnP support first, and then we see what comes next.

There is a standard being finalize called ICE (interactive connection establishment) that will allow establishing NAT connections between people who are behind a NAT (a bit like Skype does it). This is especially useful if you NAT does not allow you to do UPnP&co. Obviously, there are cases where this is impossible, in those cases, you need a relay server. Google talk/MSN provide that (only for voice, not video), and those will work with any NAT.

I do not like the idea of spending time to create and maintain a list of VoIP providers. There is something way better: DNS SRV entries.
You want to know the mailserver responsible for whatever.com? You do a MX type DNS lookup. The same is true for SIP. Implement RFC 3263 and you are pretty much done. In a nutshell you do a _sip._udp.whatever.com SRV lookup to obtain the list of UDP SIP servers responsible for whatever.com.
If whatever.com decides to not set this up they don’t know s*** about SIP and the service they are offering. So one should probably better steer clear from them.
This also works for STUN!
In the end this might also help solving the SIP outbound proxy misery inside Ekiga. Each account should/could use a different outbound proxy

Regarding NAT there are ICE and TURN. ICE kinda brute forces ‘ICE candidates’ which are IP port tuples which might work to establish connections. I have yet to see a deployed solution but it sounds like an interesting approach for some NAT cases. SIP over TCP (use DNS SRV to check if the ISP supports it) might help as well.
In the end most ITSPs will have an SBC and one endpoint in each connection will be sitting on the open internet thus eliminating some NAT issues.

I believe one remaining issue is that Ekiga tries to claim port 5060 on the local machine. Running kphone and Ekiga on the same box is thus impossible. Ekiga should bind to a random port and do STUN to obtain the port number visible on the external side.
Sticking to port 5060 (and expecting it in some cases) makes things break down. Most DSL routers shipped in Germany for instance are VoIP enabled and even if the functionality is disabled would still absorb messages directed to port 5060 thus rendering Ekiga unusable.

Hendrik: in Ekiga 2.00, you can change the listen_port using gconf-editor, in Ekiga 3.00 (upcoming), it is indeed dynamic.

Ekiga implements DNS SRV lookups, but the purpose of the list of PC-To-Phone providers is to have the user choose “Vonage”, and only have to enter the username and password, without entering “vonage.com” or “vonage.org”. Moreover, not all providers implement DNS SRV.

Like Olivier says, ICE works even better than UPnP because it doesn’t require co-operation from your NAT. It even works when you have multiple layers of NAT. Even better, it can be used in conjunction with protocols like UPnP IGD and NAT-PMP (the punched addresses obtained with these protocols just become extra candidates). Jabber’s VoIP protocol, Jingle, uses ICE to do NAT punching.