Comments on: Features for the killer VoIP app

By: Damien Sandras

Damien Sandras — Sun, 17 Aug 2008 10:00:14 +0000

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

By: Dafydd Harries

Dafydd Harries — Thu, 14 Aug 2008 17:14:32 +0000

I and some others have been working on one:

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

We hope to make our first release soon.

By: simos

simos — Thu, 14 Aug 2008 17:03:47 +0000

This is great info.

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

By: Dafydd Harries

Dafydd Harries — Thu, 14 Aug 2008 16:14:00 +0000

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.

By: Olivier Crête

Olivier Crête — Thu, 14 Aug 2008 15:48:33 +0000

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

By: Damien Sandras

Damien Sandras — Mon, 11 Aug 2008 21:07:54 +0000

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…

By: Hendrik

Hendrik — Mon, 11 Aug 2008 20:59:08 +0000

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.

By: Olivier Crête

Olivier Crête — Mon, 11 Aug 2008 18:14:24 +0000

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.

By: simos

simos — Mon, 11 Aug 2008 13:32:56 +0000

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.

By: Damien Sandras

Damien Sandras — Mon, 11 Aug 2008 10:52:30 +0000

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.