GNOME Bugzilla – Bug 562352
Ekiga no-longer has a network configuration page
Last modified: 2009-05-22 20:29:56 UTC
Please describe the problem: This is an upstream report from RHBZ 473083 https://bugzilla.redhat.com/show_bug.cgi?id=473083 Description of problem: There is no network configuration page in the Ekiga preferences any more. This means that you cannot turn off STUN, making Ekiga *completely unusable* in many network configurations. Version-Release number of selected component (if applicable): ekiga-3.0.1-2.fc10.i386 Actual results: If the SIP client and the SIP server you are connecting to are both on the internal side of a NAT, you must turn off STUN or the client will present the wrong IP address to the server. Ekiga used to allow the user to configure STUN and choose which NIC to bind to - these options now appear to have been completely removed from the preferences screen. Expected results: The preferences screen should actually contain the preferences needed to configure the application. Additional info: No doubt this is another victim of the Gnome project's propensity for removing configuration options "in case they confuse people". These network options are not irrelevant things that might confuse people, they are things which the user *HAS* to configure correctly or the software just plain won't work at all. Making bad assumptions about a user's network configuration with no way for the user to override them is a really bad move - it makes what was a very good piece of software completely non-functional. It should be noted that this is not an unusual network configuration - this is exactly how almost everyone with a local SIP server is going to set it up. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I don't understand this bug report and/or complaint. When both SIP endpoints/servers are behind the same NAT, Ekiga disables STUN automatically. If the user reports a bug in the current handling of STUN, I'm ready to fix it. But complaining about an improvement telling it won't work when it does, won't help...
Sorry if I'm being a little dense, but how does Ekiga know they are both behind the same NAT? It doesn't seem to work for me - it presents my SIP server with the STUN-discovered address. It also pops up "Ekiga did not manage to configure your network settings automatically. You can still use it, but you need to configure your network settings manually." every time I start Ekiga. The solution was to delete the stun server address using gconf-editor, but having to hack at gconf to change this stuff isn't exactly user friendly.
If you are behind the same NAT, you probably contact your IPBX using a private address, then Ekiga knows it should not use STUN.
On the network I'm using, the servers have global-scope IP addresses, but the routing is such that machines on the LAN (with RFC1918 addresses) do not go through NAT in order to get to them. The border router only has to perform NAT on traffic from RFC1918 addresses that is destined for the internet. This is a fairly sensible setup since it avoids NAT (which generally seems to cause no end of problems for SIP and makes it impossible to set up IP address ACLs on the SIP server) wherever possible. However, Ekiga makes the bad assumption that if you're contacting a server with a global scope address then you must be going through NAT, and thus doesn't work. Ekiga's preferences should allow you to turn off STUN entirely, or at least point it at a different STUN server (if Ekiga was using a STUN server located on the same network as the SIP server it would always do the Right Thing, but there is currently no way to configure it to do so without delving into gconf).
See bug #562347
I had this problem too using ekiga. The issue was, that ekiga-3.0.1-4.fc10.i386 could not sign on to the SIP-Service from the german provider 1&1. With help from Wireshark i could find out, that ekiga obviously send a private IP to the SIP-Server, resulting in "Error 403, not RF1918-IPs allowed.". Further i was looking for the IP Ekiga has send. It was 192.168.122.1. Since my private network is based on 172.16.123.x (Default Gateway is 172.16.123.1) this made me very wondering about that. After shutting down the virtual interface virbr0 (which has IP 192.168.122.1) Ekiga seemed to detect the "right" private IP-Adress (172.16.123.23) which i am using. Signing on to the SIP-Accounts (1&1 and ekiga.net) just works with a STUN-Server enabled. To enable and disable and test i always have to work with gconf. And with the enabled STUN-Server im getting the message too when starting Ekiga which tells me everytime, that ekiga could not find network configuration and so on. But Accounts can sign on and Phoning seems to work perfectly. It seems, that maybe something with the network detection of ekiga is wrong, especially when having more than one network interfaces enabled. Please let me know if i can do something more for you, e.g. getting more detailed information. Regards, Dominic
Thanks Damien - looks like bug #562347 will solve the problem.
Shouldn't this bug be closed? 3.2.0 has a stun preference checkbox.