Bug#495325: ekiga: too restrictive listening policy

[Bas Wijnen]

Package: ekiga
Version: 2.0.12-1+nmu1
Tags: upstream

Ekiga goes through some trouble to find out what the "real" network
interface is (as opposed to the loopback, in particular), and starts
listening only on that.  I don't see any advantage of this, but it does
have several drawbacks (compared to listening on all interfaces):

- If ekiga is started when no network is available, it complains about
  being unable to listen for incoming connections.  This is not as
  unusual as it might seem: I start ekiga when my laptop boots.  I would
  prefer ekiga to be silent and start working when I connect my network.
  Being silent can be a commanline option or preferences setting as far
  as I'm concerned; automatically starting to work is very painful to
  implement when keeping the current scheme, but works automatically
  when listening on 0.0.0.0.

- I tried using Ekiga over some ppp interfaces (connecting two subnets).
  I needed to add a route to the public address of the machine to go
  through the tunnel, because I couldn't reach ekiga at the address of
  the ppp interface.  And even then it only worked because the computer
  was masqueraded: if I would have needed to add the real public
  address, it would have destroyed the tunnel (because it would be
  unable to reach the host over the non-tunneled network then).

- For machines with more than one interface in general (the above is an
  example of that), you need to make sure to use the exact interface
  that ekiga expects, and not any of the others.  This leads to
  unexpected "unable to connect" errors.

- I think this may also be the source of several ways to set up a
  "one-way" connection: one side hears (and sees) the other, but there
  is no reply.  This may also be unrelated though.