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