From Ekiga
Revision as of 12:27, 12 July 2013 by Eugen (Talk | contribs)
Jump to: navigation, search
If none of the items listed or linked to below solves your problem, head over to Debugging Ekiga and send the relevant debug messages (and, in the case of crashes, backtrace) to the mailing list.


Video problems

Ekiga only displays a part of the real picture in the video window, what can I do?

Emblem-important.png This section might be obsolete.

If your driver doesn't natively support 176x144, Ekiga will try capturing at a larger size, and scale the picture down. The normal behavior of a driver is the following :

  • Ekiga asks for 176x144, the driver does not support it
  • Consequently the driver reports "FAILED"
  • Ekiga asks for 320x240, the driver supports it
  • Consequently the driver reports "OK"
  • Ekiga captures at 320x240 and resizes to 176x144 which is what it needs

If the picture isn't scaled, please report the problem to us on the mailing list.

My video framerate is slow

On Ekiga 3.0 you can expect up to 30 frames per second if you camera support it. Sometimes you need to configure your webcam driver to get the most out of it.

The pwc Linux driver

To find out whether you're using the pwc driver, run the following command:

lsmod | grep pwc

If the driver is running you should see something like this:

pwc                    92224  1 
compat_ioctl32         11136  2 uvcvideo,pwc
videodev               30720  3 uvcvideo,pwc
usbcore               169904  7 uvcvideo,snd_usb_audio,snd_usb_lib,pwc,ehci_hcd,ohci_hcd

If you're using the pwc driver, you can install setpwc and tell it to use 30 frames per second:

setpwc -f 30

Audio problems

I cannot get the sound to work!

Check that your audio subsystem is configured correctly. You can test your actual ALSA configuration using those echo tests:

 $ arecord -D plughw:0,0 -c 1 -r 8000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 8000 -f S16_LE -

This will test if your sound card can record and play sounds at 8kHz.

 $ arecord -D plughw:0,0 -c 1 -r 16000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 16000 -f S16_LE -

This will test if your sound card can record and play sounds at 16kHz.

You should be able to hear yourself with a small delay. Be sure to have your sound levels up and capture on.

If the test fails, try running the same command with -c 2 instead of -c 1. If you hear yourself now, this fix might help you.

I hear the others, but they do not hear me

This section describes a problem with some soundcards. If you re affected by this problem you should be able to hear others but they should not hear you. Ekiga will not report any errors.

The problem is that your soundcard might support stereo-recording only, but tell ALSA that it is also capable of mono-recording, producing only silence when asked to do that. Programs using mono-mode (like Ekiga) will not report an error.

To check whether you are affected, run these two commands:

$ arecord -D plughw:0,0 -c 1 -r 16000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 16000 -f S16_LE -
$ arecord -D plughw:0,0 -c 2 -r 16000 -f S16_LE - | aplay -D plughw:0,0 -c 2 -r 16000 -f S16_LE -

If the first command will either produce silence or fail with an error, whereas the second will run fine, then you are affected by this bug.

One known affected card is the following:

  • 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
Built into: EEE PC 1005

ALSA provides a fix for this problem: The route-plugin allows users to mix two channels down to one, i.e. record in stereo but output mono to the recording program. For that, put this into the file ~/.asoundrc:

pcm.convert_mic {
	type route
	slave {
		pcm "plughw:0"
		channels 2
	ttable {
		0 {
			1 1.0
			1 1.0

pcm.!default {
	type asym
	playback {
		pcm "plughw:0"
	capture {
		pcm "convert_mic"

The first command above should work now, and Ekiga too.

I'm testing my audio setup with the Ekiga configuration assistant, and I have problems, what can I do?

You have to analyse the error message given by the configuration assistant:

  • The message indicating that the device can't be opened for reading or writing means that there was an error opening the device. If the device could be opened for playing, but that the error message complains that it couldn't be opened for recording, it means that you have full-duplex problems. The solution is to use a different device for playing and recording. If the first error message to appear mentions that the device can't be opened for playing, it can also mean that you have permissions problem.
  • The message indicating that the device could be opened, but that it is impossible to read from or to write to this device means that another program is already using the device, preventing Ekiga from using it. You can check what program is using the device using $ lsof /dev. It can also mean that you have permissions problem.
  • If You get error messageboxes on calls by concurrent sounddevice usage of Ekiga with other applications saying that the audiodevices can't be opened, select the "default" device in all Ekiga audio device settings (for the ringer, too), only the "default" device has dmix access defined implicitely in libasound2, manual dmix setup in ~/.asound.rc or /etc/asound.conf is no longer neccessary for the "default" device with newer ALSA version installations, dmix is now enabled by default for cards not supporting multiple audiostream playback, move such old files out of the way first to test. There is a warning from the Twinkle author(s) for using "default" for the microphone, but I cannot confirm such, report to the ALSA user mailinglist if You run into bad sound issues from the mic, use a broad band codec like G711a (ALAW/PCMA) to test to assure it is not a narrow band codec issue and check Your network performance before reporting to ALSA project.
  • If you don't get any error message, but that you don't hear yourself with a 5 seconds delay while talking in your microphone, it means that you have full-duplex problems. You can test recording with another tool called rec, if recording with this tool works, but that you don't hear yourself with the 4 seconds delay using the Ekiga configuration assistant, it proves the full-duplex problem. If recording with that tool doesn't work either, then you have to check your installation again, and possibly your cables. Beware of non PC-standard headsets and microphones with dynamic mics build in, most usual PC-soundchips have no circuit to support them, only condenser microphones, You'll need expensive audio professional soundcards or preamp adapters for dynamic mic support, mostly.

Choppy sound with Ekiga

From ALSA version 1.0.9, DMIX is enabled by default for soundcards that do not support several channels at the same time. The default configuration of DMIX in ALSA does not necessarily provide good results by default for VoIP applications. The solution is to directly use the soundcard preferences in the 'Audio Settings' or to redefine your "default" soundcard as described above.

Choppy sound when switching desktops or under heavy load

Nothing can be done. We suggest not using DMIX if you experience that problem. If you do not use the 'Default' soundcard in the Audio Settings, then DMIX will not be used.

Problems with Pulse Audio

Some popular distributions of GNU/Linux now ship with the sound server Pulse audio enabled by default (e.g. Ubuntu, Fedora). Pulse audio work on top of ALSA and is now part of GNOME.

In some cases, Pulse audio and Ekiga do not work well together. If you have issue with sound using Ekiga in such setup, you'll better turn off Pulse audio and use ALSA directly.

Sometimes, you just need to select the proper output with pavucontrol.

We are working to fix the issue. If you're willing to give a hand:

Pulse audio is also know to have issue with some audio card drivers. You can check if you are using one of them with this command:

 $ lsmod|grep snd

I do not hear people, but they can hear me, or I can hear people but they don't hear me

The first thing to do is to use the Ekiga configuration assistant, it will help you to test your driver compatibility and to test the robustness of your driver. It will also give you interesting hints to help debugging your problems. Once you are sure that things are working correctly because you have tested your audio setup with the assistant, you can debug further.

The first thing to check is the "General History" (Tools → General History).

  • If you are transmitting sound, you should see that Ekiga starts 2 channels, one for transmission, and one for reception. If no channels are opened for audio transmission and reception, it means that you have no common codec with the remote Endpoint. Please report all codec handshake or interop issues to the Ekiga and developer mailinglists.
  • If audio channels are opened for transmission and reception, ie if there is a common codec, and if you have tested your audio configuration with the Ekiga configuration assistant and that it worked but you have no sound during calls, it means that you or your friend is behind a router or firewall that drops the audio packets. Check that it is not the case. Also make sure that your friend has a correct audio setup. See routers and firewalls section in the manual for more information.

FIXME: more infos here about where the problem is (firewall/router -> which side?)

Echo cancellation doesn't work or not O.K. I use the microphone from my webcam and my sound card for audio output.

Echo cancellation will only work if you use the same sound device for in and out audio. e.g. echo cancellation won't work if you use the microphone on your webcam and the output sound from your soundcard (PCI). The reason is that the echo cancellation mechanism needs to sync the in and out sounds and this can't be done properly yet using two different drivers. Please report echo cancellation issues to the Ekiga and developer mailing list.

We advice using a headset with condenser microphone builtin for best audio quality, because of room acoustic issues, too.

Freeze when using ALSA

If gdb stack backtrace shows that ekiga is frozen somewhere in ALSA, such as:

#0  0x00007fffea9ef208 in snd_pcm_state@plt () from /usr/lib/


#0  0x00007fffe7f47300 in PSoundChannelALSA::Write (this=0x7fffe0018d90, buf=0x10b2d44,


#2  0xb5bfcb34 in snd_pcm_writei () from /usr/lib/

then this might be a bug in ALSA, a case of deadlock in SysV semaphores, see (try whether the posted script helps). Ekiga bug report is

NAT issues

I have 2 Ekiga behind a NAT using STUN: they can't communicate

  • What is the problem ?

If both clients are located behind the same NAT router (not only the same model, physically the same), clients can't communicate.

  • Why ?

When you are using NAT with STUN, STUN will determine what port on the router will be used to route incoming traffic from the outside to your internal client. That way, when an external client sends a SIP PDU on that port, the PDU will be routed to your internal client by the router.

However, in most cases, a router will not accept to route a packet coming from the inside on the external port and route it back inside, it will only accept to route a packet coming from the outside on the external port.

It has been reported it is what happens with IPCop 1.4.15.

  • What can I do ?

To solve this you may use avahi.

I use Ekiga exclusively inside my LAN, how can I make Ekiga not to connect to Internet?

If you do not want that Ekiga connects to Internet at all, then:

  • Disable Network Detection: in the Edit → Preferences → General Settings → Network Settings menu, check off "Enable network detection"
  • and remove the two or three contacts that Ekiga creates by default (Echo test etc.)

I can make calls, but if I let Ekiga running after some time I can't receive any calls

  • The problem

If your host isn't behind NAT and is behind a firewall that behaves like NAT except for the address translation magic, this may happend to you:

 I've got a simple setup, Linux (Fedora 6), no NAT,
 a direct connection to the net, but I've got a strict firewall
 (iptables, stateful). Concerning UDP, only ESTABLISHED,RELATED packets
 are allowed in, all packets are allowed out. Pretty simple, pretty
 common, I suppose. The problem is, with this setup Ekiga (as configured
 by the wizard, with STUN) only receives calls just after connecting to (or any other SIP provider). I can make calls, but if I let
 Ekiga running after some time I can't receive any calls.
  • Why this ?

Ekiga registers with a service using UDP and the service expects to find Ekiga at the port it sent the registration. Well, in Linux with IP iptables, this port is only accessible for 180 seconds after the registration. After this time, the firewall will block the packets coming from the SIP service, as it considers the "session" to be over.

  • There are two ways of coping with that:
    • If you don't have control of your host, you can configure each account to refresh the registration every 180 seconds.
    • If you can control your host (root), you can set the UDP iptables timeout to one hour:
# echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
# echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream

See for more details. You can use the sysctl utility to set kernel variables more easily.

I have many Ekiga clients on my LAN. Is there a better way than STUN?

If you are using SIP, yes. You can use SIPROXD from as outbound proxy.

If you're connecting Ekiga against a local Sip-Gateway (like an asterisk with an e1 line) and don't want it to talk to the outside world directly, STUN may get in your way. Symptoms here are that you might not be able to hear inbound callers from the local network. If you enable debugging or use to track your Ekiga, you might find it anouncing your public ip address to your communication partner. Then you need to disable STUN (shown as network detection in preferences dialog box).

STUN does not give reproducible results

"If your system EVER says it is Cone NAT, then that is your NAT type. If there is some net foo and packets get lost or are slow in response, then it might indicate Symmetric or Port Restricted NAT. (There is also a trade off in how fast the STUN detection is, and how accurate.)" (citation Robert J.)

My router prevents Ekiga from working correctly, what can I do?

Please make sure you have read this FAQ correctly because it should work in all cases. The worst case is when you have to forward ports. If you can not forward ports, or if you do not want to do it, you have alternative solutions. For SIP, you can use SIPROXD as outbound proxy. For H.323, please configure the GNU Gatekeeper as a proxy.

Using Ekiga through a http proxy

When connected to a very restricted network such as a university or a corporate network where usually only 80, 443 and 8080 ports are accessible through a https proxy, a SIP client such as Ekiga just can't work.

In such a case you can tunnel the SIP signaling & RTP via http. If you don't have access to such a service, you can use the free service from realTunnel which is known to work.(proprietary solution, binary-only program):

Polycom communication

We are told that in order to communicate with a Polycom system, you need to have a public IP address or only some types of NAT.

FRITZ!Box Fon users

Issue: The ADSL Router "FRITZ!Box Fon" made by AVM in Germany has a built-in Network address translation (NAT). But this NAT translation does not function reliably for Ekiga because it depends on a random start port number Ekiga chooses from an available range and Ekiga needs more than one open port. Thus the well-known echo test to may work or not: You do hear a sound or not. The status bar may indicate returned audio packages or not. You would have to dial again until an echo is heard.

Cure: In Fritz!Box Fon, add to the "List of port forwardings" ("Liste der Portfreigaben") five entries: Open ports 5061-5065 for UDP protocol. This will provide a reliable (two-way) telecommunication line when you call Ekiga.

Other problems

Cannot call regular phones with some registrars such as Freephonie with ekiga >= 3.3.2

Switch off H264 video codec and call again.

Cannot register to or some other registrar with ekiga <= 3.2.x

Some registrars refuse packets containing extra contact addresses (see for example), even they follow SIP standard. To overcome their limitation, add %limit in your account name (not user name; for ex. call it myAccount%limit).

I reinstalled Linux and I want to import back (migrate) my configuration settings. How?

We assume you have kept the configuration files (the dot files) of your previous home directory. The configuration of Ekiga is found in ~/.gconf/apps/ekiga/ What you need to do is (make sure Ekiga is not running)

$ killall gconfd-2
$ cp -r myoldhome/.gconf/apps/ekiga ~/.gconf/apps/
$ _

Now you can start Ekiga and it will pick up the old configuration.

Explanation: Ekiga stores the configuration in gconf. We need to kill the gconfd service so that when we put the configuration files in ~/.gconf/apps/ekiga, they will be read again. gconfd-2 is started automatically when an application needs configuration option support (such as Ekiga).

I register, but the communication cannot be established

Please start ekiga like this:

$ ekiga -d 4 2>&1 | grep "PDU is likely too large"

and retry the communication which does not work. If you see lines printed, then it is a known problem (Support SIP over TCP), which hopefully will be fixed soon. To workaround this bug, just remove a few unused codecs (such as G726 ones) in Preferences window and retry the communication.

Personal tools