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 ptlib&opal. The default values > > for codec sizes in ptlib&opal 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. 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. 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 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] no incoming calls behing an ADSL modem
Le lundi 02 mars 2009 à 11:01 +0100, W.P. 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. > > > If it is NAT-time problem, wouldn't it be better to simply forward ports > used by Ekiga on router (5060-5100 for SIP)? > It's indeed the easiest approach. -- _ 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] Incoming call failure with 3.1.1
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 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 /lib64/libglib-2.0.so.0 #17 0x0037b2c3b49d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #18 0x0037b99238a7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #19 0x004aa6d4 in main (argc=1, argv=0x7fffe438) at gui/main.cpp:4562
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 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.
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 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
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 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
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 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 0x00
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 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 0x00
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 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
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 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
Re: [Ekiga-list] Incoming call failure with 3.1.1
Mark T.B. Carroll wrote: Damien Sandras 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 wrote: 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 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
Re: [Ekiga-list] Incoming call failure with 3.1.1
Le lundi 02 mars 2009 à 16:10 +0100, Eugen Dedu a écrit : > 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 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-3
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 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/lib
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 wrote: 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 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. 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 ptlib&opal. The default values for codec sizes in ptlib&opal 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. 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 wrote: > 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 >> wrote: >> >> 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
