What Ekiga is supposed to do, is to
send one message per interface with the interface IP address as
source. If your routing is well configured, then only one of the
various SIP messages should reach the remote user.
Please note that Ekiga 3.3.2 is an old development release which
is not intended for public use...
Le 29/09/13 10:45, cookedbread hushmail com a écrit :
I
want to use Ekiga without a central server by manually entering
IP addresses to connect directly to others. This works fine on a
LAN. But on VPN it doesn't work because of a bug, and this bug
actually exists with the LAN but it's not noticed. I am using
Ekiga version 3.3.2-0ubuntu3 on Ubuntu 12.04.
What happens is that when userA sends a message out to userB,
Ekiga attempts to sends communications out to ALL Internet
interfaces that userA is connected to. I discovered this from
the firewall log. As an example of what's happening in my
situation, say that userA has a LAN address of 192.168.1.1 but
is also on a VPN with a VPN address of 10.8.0.6. When Ekiga is
used to send a direct message to userB who is on the LAN with an
address of 192.168.1.2 (sip:userB 192 168 1 2), Ekiga sends this
signal out from userA on both 192.168.1.2 and 10.8.0.6. So in
the ufw firewall log of userA you will see something like this:
OUT=eth0 SRC="" DST=192.168.1.2
OUT=eth0 SRC="" DST=192.168.1.2
Notice that the second one says "eth0" even though it's using
the tun() interface. That's part of the bug. When this is over
the LAN it's not a problem. But when trying to do it over a VPN
it is a problem. So now let's say userB is far away in another
building, but connected to the same VPN as userA. userB has a
VPN address of 10.8.0.10. This time userA sends a message to
userB using the VPN address. userA will enter
"sip:userB 10 8 0 10" into Ekiga. userA can actually send
messages to userB and userB will see them. However, userB cannot
send any messages back to userA. The firewall logs show why this
is. Here is what the firewall log for userA will look like when
sending the message out:
OUT=tun0 SRC="" DST=10.8.0.10
OUT=tun0 SRC="" DST=10.8.0.10
Notice that the first one is tun0 but using the LAN as source.
That's part of the bug. But it's able to send messages over the
VPN to userB at 10.8.0.10. But when userB tries to send messages
back, it tries to send them to the LAN address of userA. Here is
what the firewall log will look like for userB when trying to
send communications to userA. userB has a LAN address of
172.16.0.1 with a VPN address of 10.8.0.10 and is communicating
to userA with "sip:userA 10 8 0 6". Here is what the firewall
log of userB looks like:
OUT=tun0 SRC="" DST=192.168.1.1
OUT=tun0 SRC="" DST=192.168.1.1
Ekiga for userB is trying to send signals to the LAN address of
userA, which is why userB cannot send signals back to userA over
VPN. But userB shouldn't be able to see the LAN address of
userA. I'm guessing Ekiga is sending this. And again notice that
it's saying both interfaces are tun() when the first one is
eth().
The correct thing to do, which all other programs do correctly
over VPN, is for Ekiga to only use the tun() interface for
sending signals out. If you connect to more interfaces, such
more VPNs, it will do this for each one.
When this is fixed, it will be a nice, easy way of using VOIP to
communicate with anyone through VPN. The most difficult part is
setting up VPN, which is pretty straightforward if following
step-by-step the server guide for Ubuntu 12.04. Ekiga using
direct connect over LAN is easy, so fixing this bug will make
Ekiga into a nice skype alternative for people who are capable
of setting up a VPN using OpenVPN.
_______________________________________________
ekiga-list mailing list
ekiga-list gnome org
https://mail.gnome.org/mailman/listinfo/ekiga-list
|
