Bug 505583 - Ekiga hangs when making a SIP call
Ekiga hangs when making a SIP call
Product: Fedora
Classification: Fedora
Component: ekiga (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Robinson
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-06-12 10:11 EDT by Steve Hill
Modified: 2009-07-16 10:24 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-16 10:24:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Ekiga debug log (with sensitive data redacted) (121.81 KB, text/plain)
2009-06-12 10:11 EDT, Steve Hill
no flags Details
Ekiga 3.2.4 debug log (126.08 KB, text/plain)
2009-06-15 05:58 EDT, Steve Hill
no flags Details
Ekiga 3.2.4 backtrace (18.56 KB, text/plain)
2009-06-15 05:58 EDT, Steve Hill
no flags Details
Ekiga log connecting directly to Callweaver (101.74 KB, application/octet-stream)
2009-06-23 12:29 EDT, Steve Hill
no flags Details

  None (edit)
Description Steve Hill 2009-06-12 10:11:50 EDT
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):

How reproducible:

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@rivendell.nexusuk.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@rivendell.nexusuk.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.
Comment 1 Peter Robinson 2009-06-13 06:06:40 EDT
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.
Comment 2 Peter Robinson 2009-06-13 10:34:50 EDT

*** This bug has been marked as a duplicate of bug 492889 ***
Comment 3 Steve Hill 2009-06-15 05:33:45 EDT
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).
Comment 4 Peter Robinson 2009-06-15 05:38:40 EDT
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.
Comment 5 Steve Hill 2009-06-15 05:45:21 EDT
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.
Comment 6 Peter Robinson 2009-06-15 05:50:28 EDT
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).
Comment 7 Steve Hill 2009-06-15 05:58:16 EDT
Created attachment 347907 [details]
Ekiga 3.2.4 debug log
Comment 8 Steve Hill 2009-06-15 05:58:49 EDT
Created attachment 347908 [details]
Ekiga 3.2.4 backtrace
Comment 9 Steve Hill 2009-06-15 06:17:33 EDT
Looks like this might be the same bug: http://bugzilla.gnome.org/show_bug.cgi?id=583864
Comment 10 Jan Kratochvil 2009-06-15 06:24:36 EDT
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.
Sure I do not care of ekiga2 nowadays.
Comment 11 Peter Robinson 2009-06-15 06:29:35 EDT
(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
Comment 12 Steve Hill 2009-06-15 06:40:39 EDT
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.)
Comment 13 Peter Robinson 2009-06-15 06:57:14 EDT
(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 :(
Comment 14 Steve Hill 2009-06-15 07:12:55 EDT
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)

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.
Comment 15 Peter Robinson 2009-06-23 09:23:37 EDT
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.
Comment 16 Peter Robinson 2009-06-23 09:29:22 EDT
Oh and the other thing. Can you ensure that all the audio codecs are enabled. Do you know what the other endpoint is running?
Comment 17 Steve Hill 2009-06-23 12:27:53 EDT
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@pabx.nexusuk.org  (no authentication credentials)
 * <- 100 Giving a try
 * <- 401 Unauthorized
 * -> ACK sip:foo@pabx.nexusuk.org
 * -> INVITE sip:foo@pabx.nexusuk.org  (with authentication credentials)
 * <- 100 Giving a try
 * <- 200 OK
 * -> ACK sip:foo@
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).
Comment 18 Steve Hill 2009-06-23 12:29:12 EDT
Created attachment 349110 [details]
Ekiga log connecting directly to Callweaver

This is the log showing the ALSA problem.
Comment 19 Peter Robinson 2009-06-23 12:45:40 EDT
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.
Comment 20 Steve Hill 2009-06-23 12:57:28 EDT
pasuspender doesn't seem to help. :(
Comment 21 Steve Hill 2009-06-23 13:12:40 EDT
I've filed the OpenSER issue as: http://bugzilla.gnome.org/show_bug.cgi?id=586775
Comment 22 Peter Robinson 2009-07-07 09:00:17 EDT
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?

Comment 23 Steve Hill 2009-07-16 10:24:58 EDT
Te updates in testing fix the problem - thank you.

Note You need to log in before you can comment on or make changes to this bug.