Features for the killer VoIP app

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.

The bug report to add (G)UPnP support to Ekiga is Bug 337166 – UPnP for firewall/NAT penetration.

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.

https://i0.wp.com/farm4.static.flickr.com/3056/2750741519_0f2bdd2515_o.png?w=750

What needs to be done is to put together the details for each provider and maintain a list at ekiga.com. The client would have a copy of the list, and allow on-demand updates. The bug report, Bug 547215 – Ekiga should know all SIP/VoIP providers, allow easy account addition.

Update 11Aug08: Wiki page with PC-to-phone providers and their details.

Permanent link to this article: https://blog.simos.info/features-for-the-killer-voip-app/

12 comments

Skip to comment form

  1. 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.

    • Damien Sandras on August 11, 2008 at 10:52
    • Reply

    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.

  2. 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.

  3. 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.

  4. 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.

    • Damien Sandras on August 11, 2008 at 21:07
    • Reply

    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.

    About ICE, you are 100% right…

  5. @hendrik: Google Talk and the MSN voice calls use ICE draft 6 and TURN (with significant success). So yes, its already deployed and used by millions of users.

  6. 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.

  7. This is great info.

    The next question is, is there an open-source library that implements these protocols?

  8. I and some others have been working on one:

    http://nice.freedesktop.org/wiki/

    We hope to make our first release soon.

    • Damien Sandras on August 17, 2008 at 10:00
    • Reply

    Dafydd, in my opinion, UPnP is better than ICE, because in case of symmetric NAT, it does not require help from a public proxy (which you can already achieve without ICE).

    • Sandy on July 14, 2009 at 14:50
    • Reply

    Great article. The husband and I dumped landlines for voip about 2 years ago and haven’t looked back since. Our friends are cell phone only but we only have prepaid so this works out. Thanks!

Leave a Reply to Olivier CrêteCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.