Another Linux myth: 'We have voice communication!..'

There is much noise about voice in the open source world.

People use this and that application for voice and video calls with varying success. Truth is, most of the time this is not working as advertised.

Let's look at the XMPP clients advertized as supporting voice and video.

Gajim

Gajim is a Python application using 3d party library for voice/video suppot. That 3d party library is available only under Linux. Does Gajim voice work under Linux then? No, it does not inter-operate with the other XMPP clients. Perhaps one Gajim works with another Gajim, but then we are not talking about voice over XMPP - we are talking about Gajim working with Gajim, which is no longer 'voice over XMPP' - it is voice from Gajim to Gajim. I do not know if it works actually, as I don't have anyone else out there who are using Gajim to test.

Jitsi

Jitsi is a one trick pony. First of all, it requires lots of real estate to work. Jitsi is a Java 1.6 application which uses 3d party native libraries for virtually everything. If these native libraries crash your system, you are responsible, not Jitsi team, even if no other similar software (Skype? Real Audio? Adobe Premiere? Virtual Dub? SIP softphones?) ever crashed it.

To work, Jitsi has to talk to a STUN server running on 2 external IP addresses (not behind a router or firewall) in order to gather data for its ICE protocol which is used to establish voice and video chat. For an average user having such STUN server is virtually impossible for an obvious reason: not everyone has 2 static IP addresses for a machine that can run STUN server.

Many installations where Jitsi would be used for voice communication would be those where XMPP and STUN servers are behind routers and the other party could be behind routers or directly connected via modem.

The last scenario will work! If you are directly connected and your party too, or you are behind a router and your party is directly connected, then Jitsi will work with voice, video and desktop sharing. But if both parties are behind routers, than ICE fails. It is normal and expected behavior according to Jitsi developer Dr. Emil Ivov. That pesky RFC 5389 should not stand in his way. 2 external IP addresses and that's it!

Be careful with his prescriptions though, as he never mentioned this restriction in Jitsi documentation... Wait, there is no documentation! So let me make it perfectly clear for everyone: STUN protocol is specifically designed to inter-operate with ICE from behind NAT on both ends of communication. This is its purpose and defeating it by requiring that STUN server resided on the 2 external IPs is deviation from STUN standard.

Every attempt to obtain specific requirements for Jitsi to successfully establish voice communication over the Internet from the development team failed. They would not answer direct and very specific questions as to the ports and protocols that would have to be translated on the router's NAT. Their only reply was: 'Try with our own server jit.si and if it works there, then it should work for you too'. Clearly using another 3d party's server is not helpful, as otherwise we could just stick with Skype or Google Talk: it's free and does not require any setup.

According to RFC 5389 STUN works over TCP/UDP and not just UDP, so if you are experimenting with voice over XMPP and using a STUN server (such as a plugin built into OpenFire for example), then when you are translating ports 3478/3479 on your router, please remember to specify TCP/UDP as your protocol.

Posted by: LinuxLies at 11:53 AM | No Comments | Add Comment
Post contains 627 words, total size 4 kb.