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 <dsandras 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 500 ekiga net echo test and that works just fine. However, calling the 520 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:500 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?


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          \

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-3            sends desktop notifications to
a notification daemon
ii  libnotify1         0.4.4-3            sends 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...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]