Re: [Ekiga-devel-list] svn version - segfault on all incoming calls on hardy
Le dimanche 01 mars 2009 à 07:01 +0100, Thierry Simonnet a écrit : Craig Albrecht wrote: Did a fresh install of today's trunk on a fresh installed and updated Hardy system after removing the distro's ekiga. Get immediate segfault on all incoming calls. Unable to receive incoming calls due to the segfault after clicking accept. Is this problem related to Ubuntu? If so, please indicate a distro that I can use instead and be able to receive incoming calls using the current svn version of ekiga. Thank you Craig Albrecht ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list I have the same trouble using Slackware current, Debian Sid 32, Win32. That's funny, I don't have the problem... -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Versions
Hi, A patch for ekiga to be checked in in my opinion: --- configure.ac2009-02-23 09:22:29.0 +0100 +++ configure.ac-ok 2009-03-02 12:47:01.0 +0100 @@ -18,8 +18,8 @@ BUILD_TYPE=ReleaseCode BUILD_NUMBER=1 -PTLIB_REC_VERSION=2.5.2 -OPAL_REC_VERSION=3.5.2 +PTLIB_REC_VERSION=2.6.0 +OPAL_REC_VERSION=3.6.0 AC_DEFINE_UNQUOTED(MAJOR_VERSION, $MAJOR_VERSION,[fix]) AC_DEFINE_UNQUOTED(MINOR_VERSION, $MINOR_VERSION,[fix]) -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] schema unused keys
Hi, There are two keys in schema which are not used. The first, calls_history, seems to have been renamed to call_history (which does exist). snoopy:~/softs/ekiga/ekiga-svn$ grep -r calls_history . --exclude-dir=\\\.svn --exclude-dir=po|grep -vi ^./changelog ./ekiga.schemas.in.in: key/schemas/apps/@PACKAGE_NAME@/general/user_interface/calls_history_component/calls_history/key ./ekiga.schemas.in.in: applyto/apps/@PACKAGE_NAME@/general/user_interface/calls_history_component/calls_history/applyto snoopy:~/softs/ekiga/ekiga-svn$ grep -r roster_expanded_groups . --exclude-dir=\\\.svn --exclude-dir=po|grep -vi ^./changelog ./ekiga.schemas.in.in: key/schemas/apps/@PACKAGE_NAME@/general/user_interface/main_window/roster_expanded_groups/key ./ekiga.schemas.in.in: applyto/apps/@PACKAGE_NAME@/general/user_interface/main_window/roster_expanded_groups/applyto -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-list] PTLIB alsa plugin status
Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit : Derek Smithies wrote: On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlibopal. The default values for codec sizes in ptlibopal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Damien Sandras wrote: [cut] Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. Yes. OTOH, having a 5 periods hardcoded value for all hardware means, on 8 kHz, 100 ms latency where a value of 40-60 ms would be sufficient for many (most?) hw configurations. I still regard this as a bug, although this patch, which is more like a test case, is to simple. Stay tuned until there is some testing... Besides, things like this should definitely be declared instead of being hardcoded values in implementation code :-) --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] no incoming calls behing an ADSL modem
Le samedi 28 février 2009 à 16:20 -0500, H. S. a écrit : On Sat, Feb 28, 2009 at 3:49 PM, H. S. hs.sa...@gmail.com wrote: Hi, I have just convinced a few of my friends to move from Skype to Ekiga. While testing with one of them, we noticed that he can call me sucessfully but I cannot call him. If I try calling his sip address, I get a message in the status Remote user is unreachable. That user is behing a modem which is working in pppoe mode. His computer computer has a private address. While configure Ekiga, the stun was selected in the network setting. His computer is Ubuntu Hardy, Ekiga 2.0.12. How do we go about solving this problem? Thanks. PS: With echo cancellation off, the voice quality is at least as good as we get with Skype. Good job, ekiga devels! But with echo cancellation on, the quality is not as good. Proving that the suggestion in online docs to use headsets is a good once :) hmm ... he restarted Ekiga and now I am able to call him, even across the pppoe ADSL modem. Looks like a restart of Ekiga fixed something. Does that show what could have been missed? Most probably the NAT binding expired. If it is reproducable, perhaps he could try setting a lower value in /apps/ekiga/protocols/sip/binding_timeout using gconftool-2, gconf-editor or your favorite text editor if it is on windows. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] no incoming calls behing an ADSL modem
Użytkownik Damien Sandras napisał: Le samedi 28 février 2009 à 16:20 -0500, H. S. a écrit : On Sat, Feb 28, 2009 at 3:49 PM, H. S. hs.sa...@gmail.com wrote: Hi, I have just convinced a few of my friends to move from Skype to Ekiga. While testing with one of them, we noticed that he can call me sucessfully but I cannot call him. If I try calling his sip address, I get a message in the status Remote user is unreachable. That user is behing a modem which is working in pppoe mode. His computer computer has a private address. While configure Ekiga, the stun was selected in the network setting. His computer is Ubuntu Hardy, Ekiga 2.0.12. How do we go about solving this problem? Thanks. PS: With echo cancellation off, the voice quality is at least as good as we get with Skype. Good job, ekiga devels! But with echo cancellation on, the quality is not as good. Proving that the suggestion in online docs to use headsets is a good once :) hmm ... he restarted Ekiga and now I am able to call him, even across the pppoe ADSL modem. Looks like a restart of Ekiga fixed something. Does that show what could have been missed? Most probably the NAT binding expired. If it is reproducable, perhaps he could try setting a lower value in /apps/ekiga/protocols/sip/binding_timeout using gconftool-2, gconf-editor or your favorite text editor if it is on windows. If it is NAT-time problem, wouldn't it be better to simply forward ports used by Ekiga on router (5060-5100 for SIP)? W.P. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #15 0x0037b2c3779b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #16 0x0037b2c3af6d in ?? () from
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #15 0x0037b2c3779b
Re: [Ekiga-list] Incoming call failure with 3.1.1
Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #15
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #14 0x003b99809765 in ?? () from
Re: [Ekiga-list] Incoming call failure with 3.1.1
Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist ()
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote: Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from
Re: [Ekiga-list] Incoming call failure with 3.1.1
Mark T.B. Carroll wrote: Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: Yes, can you send -d 4 and gdb, see the wiki, debugging section? -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] fresh svn build segfaults on all incoming calls
Craig Albrecht wrote: Did a fresh install of today's trunk on a fresh installed and updated Hardy system after removing the distro's ekiga. Get immediate segfault on all incoming calls. Is this problem related to Ubuntu? If so, which distros can run the svn version and successfully receive incoming calls? 1. Do you have libnotify installed? If yes, what version? 2. Please send a gdb stacktrace and a -d 4, see wiki, debugging section. -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Call for ekiga testing
Sorry, it's sip:eugen.d...@ekiga.net. Could you test with me? michel memeteau wrote: What is your sip adresse ? you can find some french people who want to test Ekiga on http://forum.ubuntu-fr.org/viewtopic.php?pid=1797590 On Sun, Mar 1, 2009 at 8:41 PM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.frwrote: Hi, Can someone test ekiga SVN version (or debian snapshots/3.1.1) with me tomorrow? We will test various codecs, how video works, if there are problems etc. Something like http://wiki.ekiga.org/index.php/Pre-release_test#Ekiga_2.9_Pre-tests ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Damien Sandras wrote: Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch () from
Re: [Ekiga-list] Incoming call failure with 3.1.1
Eugen Dedu wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Alec Leamas wrote: Damien Sandras wrote: Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : Eugen Dedu wrote: Eugen Dedu wrote: Damien Sandras wrote: Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : Damien Sandras wrote: Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit : Damien Sandras dsand...@seconix.com writes: Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit : I have run through the configuration assistant thing from start to finish. I can call the 5...@ekiga.net echo test and that works just fine. However, calling the 5...@ekiga.net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:5...@ekiga.net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all my outgoing packets out. Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are, There is a known problem with incoming calls and the current snapshot. I will fix it this week-end. Now with the 20090225 one, the incoming call does arrive (yay!), I hit `accept', and it segfaults. I can still send my -d 4 output to somebody. (-: A gdb backtrace would be more useful. waiting for some kind of customer service, taking a backtrace (yes, same problem, trunk as of yesterday). Despite trying 50 times, I can not reproduce it. Are you sure something is not corrupted? Eugen, can you reproduce it? Hi, Sorry for taking so much time to reply. Very interesting, when I call 520, I receive the call and it works (I have audio conversation). I use on debian ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP client - svn version configure: dummy export PTLIBDIR=$$PWD;\ ./configure \ --prefix=/usr \ --libdir=/usr/lib64\ --enable-debug \ --enable-tracing \ --disable-static \ --enable-plugins \ --disable-oss \ --enable-v4l2 \ --disable-avc \ --disable-v4l For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think this is the problem.) By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code. Final configuration === Installing into prefix : /usr [...] libnotify support : disabled Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3sends desktop notifications to a notification daemon ii libnotify1 0.4.4-3sends desktop notifications to a notification daemon In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify... My bad, thou shall not guess. I just compiled a version w libnotify, same problem crash. Relevant thread from gdb: Program received signal SIGSEGV, Segmentation fault. 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 [cut] Thread 1 (Thread 0x76b0f7b0 (LWP 23589)): #0 0x0037b3429a8c in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #1 0x004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #3 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #4 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #5 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #6 0x003167603929 in ?? () from /usr/lib64/libnotify.so.1 #7 0x003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #8 0x0037b340b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #9 0x0037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 #10 0x0037b3422b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #11 0x0037b3423093 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #12 0x003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 #13 0x003b98c0ef7b in dbus_connection_dispatch ()
Re: [Ekiga-list] Call for ekiga testing
In three hours, is it possible to you? chaitanya mehandru wrote: Hi, I can be with you for the testing of ekiga svn. But my timezone is probably different from yours and we can find a suitable time to work things out. On Mon, Mar 2, 2009 at 1:11 AM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.frwrote: Hi, Can someone test ekiga SVN version (or debian snapshots/3.1.1) with me tomorrow? We will test various codecs, how video works, if there are problems etc. Something like http://wiki.ekiga.org/index.php/Pre-release_test#Ekiga_2.9_Pre-tests ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Incoming call failure with 3.1.1
Mark T.B. Carroll wrote: can you send -d 4 and gdb Let me know if you'd like me to run with different options / commands. Mark Mark's output is at http://eugen.dedu.free.fr/incoming.text -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] [Solved] Re: no incoming calls behing an ADSL modem
On Mon, Mar 2, 2009 at 4:52 AM, Damien Sandras dsand...@seconix.com wrote: Le samedi 28 février 2009 à 16:20 -0500, H. S. a écrit : On Sat, Feb 28, 2009 at 3:49 PM, H. S. hs.sa...@gmail.com wrote: While testing with one of them, we noticed that he can call me sucessfully but I cannot call him. If I try calling his sip address, I get a message in the status Remote user is unreachable. That user is behing a modem which is working in pppoe mode. His computer computer has a private address. While configure Ekiga, the stun was selected in the network setting. His computer is Ubuntu Hardy, Ekiga 2.0.12. hmm ... he restarted Ekiga and now I am able to call him, even across the pppoe ADSL modem. Looks like a restart of Ekiga fixed something. Does that show what could have been missed? Most probably the NAT binding expired. If it is reproducable, perhaps he could try setting a lower value in /apps/ekiga/protocols/sip/binding_timeout using gconftool-2, gconf-editor or your favorite text editor if it is on windows. Ekiga has been working fine since then. No further problems with NAT and his adsl modem router. Conclusion: the very time that he configured ekiga, he could call me but I couldn't call him. But after restarting ekiga, it has been working very well since then, no problem at all even after ekiga restarts and computer reboots. It 'just works' :) Regards. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] [Solved] Re: no incoming calls behing an ADSL modem
Le lundi 02 mars 2009 à 14:06 -0500, H. S. a écrit : [...] Most probably the NAT binding expired. If it is reproducable, perhaps he could try setting a lower value in /apps/ekiga/protocols/sip/binding_timeout using gconftool-2, gconf-editor or your favorite text editor if it is on windows. Ekiga has been working fine since then. No further problems with NAT and his adsl modem router. Conclusion: the very time that he configured ekiga, he could call me but I couldn't call him. But after restarting ekiga, it has been working very well since then, no problem at all even after ekiga restarts and computer reboots. It 'just works' :) Unexplainable, but nevertheless a good news! -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Incoming Call Failure
Hi, Latest trunk should fix that. I think it only occured when notifications are disabled or do not work, and you get the real incoming call popup. Can you try ? -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] any screenshots showing off 3.1.1?
Hi, Just wondering if anybody has put up any screenshots showning off 3.1.x's new features or GUI anywhere? Thanks. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Damien Sandras wrote: Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit : Derek Smithies wrote: On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlibopal. The default values for codec sizes in ptlibopal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. With the standard 8 kHz codecs, there is not more than 2-3 errors on 1 Mbyte of data using a two periods hw buffer and a 150 ms jitter buffer from Sweden to the echo server. I've added logging code to the alsa driver to show this. I have not been able to get any usable results using the 16 kHz codecs against 5...@ekiga.net (no sound at all...). If the jitter buffer is decreased to 50 ms there are more errors, but then the sound is so bad anyway that it's not a valid usecase. Thinking about it, I can't really see why two or three periods should be a problem unless the jitter buffer is to small (or the system overloaded). And it's the user who sets the jitter buffer. I really think the defaut value should be smaller 2 (or 3) on Linux. Question is how to adjust this value if needed. Yet another hidden gconf variable? Is it needed, can this be handled by the jitter buffer? Anyway, this is a way to get rid of 40-60 ms of latency on Linux, more on windows. I think it deserves to be thought of, it is a substantial gain. BUt bot until the release is out :-) --a PS: I can now accept calls with the gtk message box. This used to crash. DS --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] ekiga 3.0.1 and pulseaudio problem in Debian
Hi, This is on a Debian Unstable machine running 2.6.26-1 kernel and: ekiga 3.0.1-1 (pulled from Experimental branch of Debian) pulseaudio 0.9.10-3 If pulseaudio (PA) is running, the USB headset (Microsoft LX-3000) does not function with Ekiga. The audio devices chosen in this case are the usb headset with ptlib/alsa. If pulseaudio is killed, then the headset functions properly with ekiga. Any suggestion what is going on here and how to fix it? IIRC, the user installed the new version of ekiga only today. Earlier the system had ekiga 2.0.12 and that was working fine with the audio system on the Debian machine. If there is a problem with the new version, I will suggest to the user to downgrade to the earlier ekiga version. Thanks. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] list manager: could we have this on gmane.org?
On Fri, Feb 27, 2009 at 3:29 PM, H. S. hs.sa...@gmail.com wrote: Hello, This is intended for whoever is maintaining this mailing list. I was wondering if this list can be made available via gmane.org. That way people can read this list as newsgroup on nntp server of gmane as well (list subscription would still be required). I am new to this list and I am not sure if this has been requested or looked into before. Regards and thanks. Just discovered that it is already on gmane but with a different name: gmane.comp.gnome.apps.gnomemeeting Regards. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Call for ekiga testing
Hi, Sorry for late reply. How did the testing go? If you might have some testing to be done,please let me know. We can work out some time. On Mon, Mar 2, 2009 at 9:07 PM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.frwrote: In three hours, is it possible to you? chaitanya mehandru wrote: Hi, I can be with you for the testing of ekiga svn. But my timezone is probably different from yours and we can find a suitable time to work things out. On Mon, Mar 2, 2009 at 1:11 AM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.frwrote: Hi, Can someone test ekiga SVN version (or debian snapshots/3.1.1) with me tomorrow? We will test various codecs, how video works, if there are problems etc. Something like http://wiki.ekiga.org/index.php/Pre-release_test#Ekiga_2.9_Pre-tests ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
