Created attachment 347573 [details] Ekiga debug log (with sensitive data redacted) Description of problem: Ekiga hangs when making a SIP call. Version-Release number of selected component (if applicable): ekiga-3.2.0-2.fc11.i586 How reproducible: Always Steps to Reproduce: 1. Make a SIP call 2. Ekiga dials and connects, connect time increments, etc. But no sound is produced through the headset and the VU meter in Ekiga's volume control window shows no incoming audio from the peer. 3. Click the "hangup" button. 4. Nothing happens. 5. After a few seconds, Compiz decides that Ekiga isn't responding and greys out the window. Clicking the close button results in the usual "application not responding, force quit?" dialog box. 6. The Callweaver server it is connected to reports: Jun 12 14:22:22 WARNING[3085925264]: chan_sip.c:1564 retrans_pkt: Maximum retries exceeded on transmission 3e1dc2ae-c155-de11-9ef8-0014852b4390.org for seqno 2 (Critical Response) Jun 12 14:22:22 WARNING[3085925264]: chan_sip.c:1586 retrans_pkt: Hanging up call 3e1dc2ae-c155-de11-9ef8-0014852b4390.org - no reply to our critical packet. Expected results: Should receive and play audio for the call, shouldn't crash. Additional info: This is a straight upgrade from Fedora 10, in which Ekiga worked fine.
Can you try the builds for ptlib/opal/ekiga in koji? ptlib - http://koji.fedoraproject.org/koji/buildinfo?buildID=102794 opal - http://koji.fedoraproject.org/koji/buildinfo?buildID=103933 ekiga - http://koji.fedoraproject.org/koji/buildinfo?buildID=102845 The new release fixes alot of hangs. I'm in the process of getting them pushed out to updates-testing but they haven't made it yet.
*** This bug has been marked as a duplicate of bug 492889 ***
I get exactly the same problem with the Koji builds. :( I'm not convinced this is the same as the problem described in 492889 - the symptoms are very different (I don't get a segfault, I get a hang instead). From a cursory look at the log it appears that there are problems with unlocking a mutex - I guess this is probably causing a deadlock (and hence a hang).
please run the 3.2.4 builds from the command like using "ekiga -d 4" and also provide a traceback when you get the hang. There's another new stable build due soon that has alot more hangs fixed.
When receiving an inbound call, Ekiga rings and the notification bubble appears from the system tray with the accept/reject buttons. I can accept the call and outbound audio works but there is no inbound audio (and nothing shows up on the speaker VU meter in the volume control window). Pressing the hangup button on an inbound call results in Ekiga hanging. If the caller hangs up, Ekiga doesn't notice that the call has been dropped (the duration counter is still going). A probably unrelated side-note: When receiving an inbound call, there is no way to answer it from the Ekiga window - the green "off-hook" button is greyed out and you have to use the "answer" button in the system-tray notification bubble instead.
It sounds like a bug that's been fixed in the next release that's due shortly (one X video related bug waiting to be fixed).
Created attachment 347907 [details] Ekiga 3.2.4 debug log
Created attachment 347908 [details] Ekiga 3.2.4 backtrace
Looks like this might be the same bug: http://bugzilla.gnome.org/show_bug.cgi?id=583864
Just a hint there may be (also) some bug in system libraries causing hangs as ekiga2 which was working even on F10 fine now randomly starts hanging in several seconds/minutes of a call. http://people.redhat.com/jkratoch/ekiga2/f11/ Sure I do not care of ekiga2 nowadays.
(In reply to comment #10) > Just a hint there may be (also) some bug in system libraries causing hangs as > ekiga2 which was working even on F10 fine now randomly starts hanging in > several seconds/minutes of a call. I suspect that might be PulseAudio
I should mention that I have Ekiga set to use the real ALSA devices rather than PulseAudio (Ekiga doesn't seem to agree with PulseAudio which leads to really bad audio playback.)
(In reply to comment #12) > I should mention that I have Ekiga set to use the real ALSA devices rather than > PulseAudio (Ekiga doesn't seem to agree with PulseAudio which leads to really > bad audio playback.) If pulseaudio is running it presents a alsa interface which is used so it still goes through PA anyway. The 3.4 release of ekiga will have support for PA but I've not been able to make it work very well at all :(
Pulse does provide an ALSA device, but the "real" devices are still present and can be selected to should allow you to bypass it. On my system I get the following devices: * Default (PTLIB/ALSA) * SB Live! Value [CT4670] (PTLIB/ALSA) * SB Live! Value [CT4670] (1) (PTLIB/ALSA) * SB Live! Value [CT4670] (2) (PTLIB/ALSA) * NVidia CK8 (PTLIB/ALSA) * NVidia CK8 (1) (PTLIB/ALSA) * SILENT (EKIGA/EKIGA) The "Default" device is PulseAudio, but all of the other devices should be real hardware. I currently have my ringing device set to "SB Live! Value [CT4670] (PTLIB/ALSA)" and the input and output devices set to "NVidia CK8 (PTLIB/ASLA)", so none of it should be going through Pulse.
Steve, I've been looking closer at the debug logs that you've provided and I see a lot of "SIP/2.0 401 Unauthorized" errors which looks to be an incorrect password (although searching the net comes up with all sorts of weird and wonderful answers), did this account get migrated from an earlier ekiga or did you recreate it from new? Can you also install gconf-editor and run it. Browse down the tree Apps -> ekiga and click on 'protocols'. There you should see a string of all the account and you can see the password that's entered. Can you confirm it is in fact correct.
Oh and the other thing. Can you ensure that all the audio codecs are enabled. Do you know what the other endpoint is running?
Ok, to answer your questions: It can't be an incorrect password because it successfully registers and successfully accepts and initiates calls. In any case, an incorrect password shouldn't cause it to hang. In my experience, SIP clients generally don't seem to send the authentication credentials until they get a "401 Unauthorised" response back anyway, so this is probably normal. The account listed in gconf has the correct credentials. The whole machine was upgraded from Fedora 10 to Fedora 11 - the Ekiga account configuration has not been changed since the upgrade (it worked ok under Fedora 10). Ekiga has the following codecs enabled (in this order of preference): Speex, PCMU, PCMA, gsm, G722. The remote end (Callweaver) has the following codecs enabled (in order of preference): ulaw, alaw, gsm, all. The following codecs are explicitly disabled: speex, g729. The negotiation picks PCMU/ulaw since this is the first codec both ends agree on. ---------- Now, new information: It was running through an OpenSER proxy. To make things a bit simpler I have now removed the proxy and am connecting directly to a Callweaver server. This has revealed that there may be several problems at work here: 1. When running through the proxy, the one of the ACK packets gets dropped. It looks like the proxy can't identify what transaction the ACK refers to. This basically means the call never gets set up properly. 2. With the proxy out of the equation, the call is set up properly but Ekiga doesn't play any audio. Ekiga logs: "Media Patch:0xb57a0b70 ALSA Could not write 0 160 Success". I'll address these problems one at a time: Problem (1): When making a call via a proxy we see the following sequence of SIP traffic: * -> INVITE sip:foo.org (no authentication credentials) * <- 100 Giving a try * <- 401 Unauthorized * -> ACK sip:foo.org * -> INVITE sip:foo.org (with authentication credentials) * <- 100 Giving a try * <- 200 OK * -> ACK sip:foo.96.201 The proxy drops the final ACK, and it appears that this is because it can't identify the transaction it refers to. All of the packets contain the same Call-ID header. The only thing I can see is that Ekiga suddenly switches to using the IP address of the server instead of the name; I don't know enough about SIP to know if this is allowed, but if the proxy server is using both the callee address and the Call-ID header to identify the transaction then this is going to cause problems. Problem (2): Even though Ekiga is receiving RTP data, I get no audio. The log shows "Media Patch:0xb57a0b70 ALSA Could not write 0 160 Success", so it looks like it is an Alsa problem. This happens when the output device is set to "NVidia CK8 (PTLIB/ALSA)". Setting the output device to "SB Live! Value [CT4670] (PTLIB/ALSA)" works fine (but of course causes the audio to come from the wrong sound card).
Created attachment 349110 [details] Ekiga log connecting directly to Callweaver This is the log showing the ALSA problem.
For the OpenSER proxy issue I suggest you open a bug report directly at bugzilla.gnome.org. Note the bug number here so I can track it as well. Can you try "pasuspender ekiga" and see if that has any effect. It suspends pulseaudio just for ekiga.
pasuspender doesn't seem to help. :(
I've filed the OpenSER issue as: http://bugzilla.gnome.org/show_bug.cgi?id=586775
There's a new stable release that I've just pushed to F-11 testing. It fixes the stuff quoted in the gnome bug plus looking through the changelog quite a few other sip related bugs. Can you test it for me? https://admin.fedoraproject.org/updates/ekiga-3.2.5-2.fc11,opal-3.6.4-2.fc11,ptlib-2.6.4-2.fc11
Te updates in testing fix the problem - thank you.