maemo.org Bugzilla – Bug 5523
High latency between UI and SIP events being sent
Last modified: 2010-01-14 12:28:22 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
1. Start tcpdump.
2. Initiate a SIP call.
3. Wait to see the INVITE being sent.
(Or just call another local SIP UA and wait for it to ring).
Nearly immediate call initiation.
Approximately 10-12" lag. A similar but slightly shorter (7-8") delay is also
observed between answering an incoming SIP call and the OK response being sent
back. The CPU is mostly idle during this.
This doesn't seem to affect XMPP or cellular calls.
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
There may be other surprises. I'd like to see at a packet dump for call
(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
Emailed privately, hope that's ok.
Thanks for the observation and the logs. Looks like we have a problem to
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..
I didn't see anything about UPnP in the captures, might it be that the
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
> 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
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.
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.
This has been fixed in package
which is part of the internal build version
(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
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
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
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