Comment 5 for bug 380091

Alvin:

Running ekiga -d 5 > out, the output still goes to the console. If I remember anything correctly about C programming, ekiga is directly dumping output to the console instead of using stdout. You have to use ekiga -d5 2> out.

Alvin & Yannick Defais:

The PDU 1500/1550 thing makes a heckuva lot of sense. The computer running Ubuntu 8.10/Ekiga 2 did not have it's MTU touched, so it's at the default 1500. The computer running Ubuntu 9.04/Ekiga 3 has its MTU set at 7500 because its /home is on an NFS share over gigabit networking. If I'm recalling this correctly (again), UDP packets don't support fragmentation while TCP packets do.

After issuing ifconfig eth0 mtu 1500, Ubuntu 9.04/Ekiga 3 works as expected. But should users be expected to fiddle with MTU settings just for one program? Shouldn't Ekiga be able to pick up on the error and say, "Oh, the packets are too big? Let's try smaller, standard ones." Or is the packet size completely out of the hands of the application?

As it stands now, my options aren't nice:

* take a 50%-66% hit in local gigabit network performance to run Ekiga all the time
* run Ekiga with a script that'll change the MTU as needed (only dragging performance while Ekiga is running)
* set up another computer just to run Ekiga all the time (which is a bit of a waste)
* I don't have dual NICs, so setting one up for the local network and one for the Internet goes right out the window