Comment 1 Mikhail Zabaluev 2009-10-19 14:57:17 UTC

The biggest culprit is waiting for a response from a STUN server which is
misconfigured or down. What do you have for STUN settings? If you have STUN
server auto-discovery enabled, what does a DNS lookup like "dig SRV
_stun._udp.<account_domain_name>" retrieve?

There may be other surprises. I'd like to see at a packet dump for call
establishment.

(In reply to comment #1)
> The biggest culprit is waiting for a response from a STUN server which is
> misconfigured or down.

Sounds plausible, but:

> What do you have for STUN settings? If you have STUN
> server auto-discovery enabled, what does a DNS lookup like "dig SRV
> _stun._udp.<account_domain_name>" retrieve?

same behaviour with auto or an empty STUN server setting.  The domain doesn't
have any stun SRV records.

> There may be other surprises. I'd like to see at a packet dump for call
> establishment.

Emailed privately, hope that's ok.

Comment 3 Mikhail Zabaluev 2009-10-20 19:00:09 UTC

Thanks for the observation and the logs. Looks like we have a problem to
address...

From your log, I can see what the problem is. Since you dont have a stun
server, it does upnp discovery up to the maximum timeout which is now set to 10
seconds.. It should be a lot shorter..

Comment 5 Mikhail Zabaluev 2009-10-20 19:12:46 UTC

I didn't see anything about UPnP in the captures, might it be that the
submitter
had filtered some interesting traffic out, e.g. broadcasts?

(In reply to comment #5)
> I didn't see anything about UPnP in the captures, might it be that the
> submitter
> had filtered some interesting traffic out, e.g. broadcasts?

Ah, yes I did, sorry :-(  I guess this is new in Fremantle, and I thought the
UPnP traffic was media-related.  On closer inspection it's 6 "M-SEARCH *"
requests originating from "User-Agent: Maemo Telepathy Stream Engine", starting
roughly 10-11 seconds before the INVITE gets sent.

(In reply to comment #4)
> Since you dont have a stun server, it does upnp discovery

Thanks for that info, using a manual STUN setting of "stun.ekiga.net" the
INVITE is sent out almost immediately.  The call is still not properly
established, but that's a separate problem.

(In reply to comment #7)
> The call is still not properly established, but that's a separate problem.

That was timer-related, solved after applying the suggestion in bug 5614
comment 9.

I changed the default upnp timeout to 2 seconds, it should be in the next
upgrade (or the following one).

Thanks, looking forward to testing it :-)

Silly question: would it make sense to perform the STUN/UPnP discovery once per
connection instead of before every call?

(In reply to comment #10)
> Thanks, looking forward to testing it :-)
> 
> Silly question: would it make sense to perform the STUN/UPnP discovery once per
> connection instead of before every call?

Every connection uses a local port, and stun/upnp also deals with ports.

Comment 12 Mikhail Zabaluev 2009-10-26 16:39:15 UTC

Even the UPnP IGD service could be added into or removed from the network over
the lifetime of a device's network connection (it's plug and play tech,
innit?), so it's not enough to discover it just once.

Comment 13 Andre Klapper 2009-11-12 16:08:09 UTC

This has been fixed in package
farsight2 0.0.16-0maemo3+0m5
which is part of the internal build version
2009.45-7
(Note that 2009 is the year and the number after is the week.)

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

With 2.2009.51-1 the delay is down to around 3" which is a definite improvement
but not quite ideal.  The "Discover public address" option makes no difference
on this.

With a STUN server set it's nearly instant.  Is there some other way to disable
the UPnP discovery?

*** Bug 7339 has been marked as a duplicate of this bug. ***

If the stun server answers, it ignore the upnp discovery.

Perhaps I'm a corner case as I'm not behind NAT when I'm making SIP calls so
don't need STUN, UPnP etc.  Oh well, I'll mark this VERIFIED since there's a
workaround and there's no obvious way to improve it without breaking things for
NATed cases.

Comment 18 Andre Klapper 2010-01-14 12:28:22 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.