Re: [Ekiga-list] Ekiga hopelessly slow...

[listbox snap net nz]

Thank you! Watching the level four debug output, it may be a DNS issue. The 
DNS line is quite regularly followed by a SIP line warning that no SRV record 
is found:

2011/04/09 15:29:04.225   0:00.240                              DNS     SRV 
Lookup ekiga.net service _sip._udp
2011/04/09 15:29:04.511   0:00.527      StunDetector:0xb668e710 PWLib   File 
handle low water mark set: 44 PUDPSocket
2011/04/09 15:29:07.445   0:03.461      StunDetector:0xb668e710 PWLib   File 
handle low water mark set: 42 PUDPSocket
2011/04/09 15:29:07.735   0:03.751      StunDetector:0xb668e710 OPAL    STUN 
server "stun.ekiga.net" replies Restricted NAT, external IP <<REMOVED>>
2011/04/09 15:29:19.174   0:15.190      Network In...0xc9d52710 PWLib   File 
handle low water mark set: 41 PUDPSocket
2011/04/09 15:29:24.245   0:20.261                              SIP     No SRV 
record found.
2011/04/09 15:29:24.293   0:20.309                              OpalUDP 
Binding to interface: 0.0.0.0:5060
2011/04/09 15:29:24.293   0:20.309                              PWLib   File 
handle low water mark set: 37 PUDPSocket
2011/04/09 15:29:24.293   0:20.309                              SIP     
Created transport udp$86.64.162.35:5060<if=udp$*:5060>
2011/04/09 15:29:24.293   0:20.309                              OpalUDP 
Started connect to 86.64.162.35:5060
2011/04/09 15:29:24.294   0:20.309                              OpalUDP 
Writing to interface 0 - "192.168.<<REMOVED>>%eth0"
2011/04/09 15:29:24.294   0:20.309                              OpalMan 
Listener interfaces: associated transport=None
    udp$192.168.34.11:5060
2011/04/09 15:29:24.576   0:20.591                              SIP     
Transaction created.
2011/04/09 15:29:24.577   0:20.592                              DNS     SRV 
Lookup ekiga.net service _sip._udp
2011/04/09 15:29:44.597   0:40.613                              SIP     No SRV 
record found.
2011/04/09 15:29:44.597   0:40.613                              SIP     
Transaction remote address is udp$ekiga.net:5060
2011/04/09 15:29:44.597   0:40.613                              SIP     
Sending PDU (559 bytes) to: 
rem=udp$86.64.162.35:5060,local=udp$192.168.34.11:5060,if=192.168.34.11%eth0
SUBSCRIBE sip:500 ekiga net SIP/2.0

...

After roughly five iterations, and five minutes, the program finally opens. I'll 
hunt for your previous posts on DNS issues...

On Tue, 05 Apr 2011 10:32:21 Eugen Dedu wrote:
> On 03/04/11 02:29, listbox snap net nz wrote:
> > I've been struggling with Ekiga for months now. I could connect to the
> > echo server and hear it speak to me, but the connection broke after the
> > recording finished. I was unable to solve the problem, even with the
> > list's help.
> > 
> > Recently, I bought a new router in hopes of fixing the problem. I
> > connected the new device and launched Ekiga (for the first time in
> > weeks). At first I thought Ekiga had silently died but no, it just took
> > it a very long time to load. Roughly five minutes! When it finally did
> > load it was unusable ... couldn't even make an outbound connection.
> > 
> > So the question: what could cause Ekiga to take this long to load?
> > 
> > I'm using Mandriva 2010.2. MSec is running, and I suspect it may be
> > involved, as it likes to set hosts.deny to:
> > ALL:ALL EXCEPT localhost:DENY
> > 
> > I don't really know enough about msec or hosts.deny to be sure though.
> > Anyway, hopefully someone out there has seen this problem before and can
> > make a useful suggestion. Thanks!
> 
> Your hosts.deny seems wrong, since it has three fields, from man
> hosts_access:
>    All other lines  should  satisfy  the  following  format,  things
> between  []  being optional:
>    daemon_list : client_list [ : shell_command ]
> 
> Anyway, take a glance at the debug output (-d 4) if you see something
> wrong, notably look at my previous e-mailto the list  with DNS server
> lookup.  This is for the very long time to load.
> 
> As for the outbound connection, again: we need to look at the debug
> output (even if I personnally cannot guarantee to solve the problem!)