Ekiga 4.0 released [LWN.net]

Ekiga 4.0 released

Posted Nov 29, 2012 17:53 UTC (Thu) by gwolf (subscriber, #14632)
Parent article: Ekiga 4.0 released

At some point in time, I had high hopes on Ekiga. It handled most Linux-supported hardware, and talked the two major industry standard protocols (SIP and H.323). Yes, both protocols (more the second than the first) are quite firewall unfriendly, but... With the help of STUN, it cannot be that bad, can it?

I had two major (and very different!) use cases for it. One was to allow for remote participation for an online Free Software and Education encounter we held at my university, and the other one was to talk with my girlfriend, who then lived in a different country.

As for the first one, it was very frustrating. The CODEC quality of Ekiga was abysmally low, so conferencing people often had interruptions, broken connections, freezes and whatnot. That, when they could connect — Even if my university has a Tandberg H.323 server/MCU, no amount of STUN was enough to get them to connect reliably. In the end, we did all kinds of hackery (including at some point calling the presentator by phone, because Ekiga sent the picture correctly but no audio was coming through, or locally displaying the presentation following their indications because of the opposite), or let our prejudices down and used Skype for some others.

As for my girlfriend... Well, I can only thank Ekiga for not being more reliably, as she moved to Mexico with me, and we are now married ;-)

(Log in to post comments)

Ekiga 4.0 released

Posted Nov 30, 2012 18:13 UTC (Fri) by Rehdon (guest, #45440) [Link]

All's well that ends well! XD

Rehdon

Ekiga 4.0 released

Posted Dec 3, 2012 18:47 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]

STUN is a complete disaster - it does a trick which most better firewalls (including shorewall, but excluding most consumer routers) manage to block. Worse, you can often end up with only one side of the RTP connection working, so having simplex audio, or no video. Finally, some routers play tricks on top of tricks - this means that a router might do the necessary siproxd stuff for the audio part, but not for the video part!

The reason it's necessary is because the central SIP registration server can easily handle the bandwidth for who is online and call-setup, but not for the actual call (it would make it really expensive for eg ekiga.org, and it would add latency).